stpeterI seem to recall that Kev sent his regrets?
MattJHe said he might be late
m&mI think so, too
m&mbut I think we can get started, and he can catch up
MattJNow ralphm's here, +1
m&m0) Roll call
m&m1) XEP-0297: Move to draft?
m&mThere's a typo in the intro that I'm sure the XEP Editor will fix
m&m"There are many situations is which" ...
m&mAlso, I think I agree with other sentiments that extensions MUST contain <forwarded/>, not merely SHOULD
MattJ+1 (after consideration)
m&mI'm −1 until the SHOULD is a MUST
m&munless a good argument for the SHOULD?
m&m"unless there is a good argument for the SHOULD?"
MattJI can't think of oneright now
m&mneeds last message correct
MattJI can't think of one right now
ralphmI had suggestions about PubSub some time, where people asked why the payload of events were embedded. If they were not, the original message might be interpretable, (like with Atom), even if PubSub wasn't.
ralphmI'm not sure if that's an argument here, though
m&mso far the embeddings of <forwarded/> provide important context
ralphmarguably, the same holds for pubsub
ralphmbut there you could think of some 'see my sibling' semantics
ralphmI am just thinking aloud about this, while we can
Lanceas a client dev, i strongly prefer the embedded version over sibling
ralphmin <iq/>s it would not work anyway, as it can only have one child (not counting error)
MattJWell the XEP "strongly prefers" it already
MattJJust there might be exceptions
MattJHowever none of us can think of one :)
ralphmI'm totally ok with embedding
MattJand this SHOULD isn't even for implementations as much as future protocol developers