[Standards] XMPP Council Meeting 2018-11-21

Tedd Sterr teddsterr at outlook.com
Fri Nov 23 18:13:55 UTC 2018


1) Is there anybody out there?
Out there: Georg, Dave, Kev, Daniel
Way out there: Sam

2) Agenda
Dave assumes the only items for voting are those outstanding from last week, and that nobody is mad enough to try adding something new; Georg considers it, but manages to restrain himself.

3) Outstanding votes
Kev thinks it's everything left over from last week.
Dave thinks he, Georg, and Sam are up to date.
Kev dumps his votes in one go: XEP-0357 = -1; XEP-0359 = -1; PR #692 = +1; PR #693 = +1; PR #715 = +1; PR #716 = -1.

3.1) XEP-0359 Discussion
Georg anticipated objections to his requirement of making the stanza and origin-id id attributes equal; Daniel previously suggested doing the same thing, but the author objected; as had Georg, with the same outcome.
Dave suspects that it's desirable, but could be difficult for libraries which set the stanza id on send; Georg suggests the library should also add the origin-id at the same time; Dave says that libraries often bake-in support once they're being actively used.
Kev doesn't see a reason not to make them equal.
Georg is sure there is an easier solution to this problem than having multiple mismatching ids on a message, but Receipts and LMC need to be fixed with origin-id in place. Georg considers origin-id a hack to work around bad servers and so would rather burn it; can see some benefit in stanza-id for MAM purposes as it's added by an independent entity -- originally, origin-id was to allow identification of reflected messages from MUC and transports, but as MUC was changed to discourage this, and transports probably don't retain XML payloads, origin-id could go away. Dave could go along with this.
Kev thinks this has become a mailing list of after-meeting discussion; Dave agrees.
Georg thinks his conditional -1 vote may now just be an unconditional -1.

3.2) XEP-0357 Discussion
Dave asks Kev about his rejection reasons - Kev thinks his on-list responses are enough, especially as he's the one who needs to make the changes. Dave congratulates Kev on [again!] rejecting his own XEP.

3.3) PR #716 Discussion
Dave is in favour of dropping the need to signal disco#info support over disco#info.
Georg says it was previously mentioned that the Capabilities hash would be inconsistent, and that it's a MUST in a Final XEP.
Kev thinks the normative change is wrong at this stage, and noting that it may be elided from examples is reasonable, also that some implementations may even elide it.
Dave thinks a client that includes the disco#info feature in the response surely includes it in the hash calculation; Georg thinks having it implicitly defined leads to corner cases, also because Final XEP. Dave would be more convinced by 'Final XEP' if it affected inter-op, or if this were actually followed. Kev notes that Final XEPs can be modified, but every effort should be made not to.
Kev's inclination would be to leave the normative language, but note that not all examples include it, and that some implementations may elide it; Georg seconds that. Dave is feeling persecuted, but can go along with Kev's suggestion.
Dave thinks that if implementations were inconsistent then Caps would be failing and people would have noticed; Kev thinks Dave is right, but worries it might make matters worse by adding language about this being optional, though isn't strictly opposed if that can be prevented.

4) Thanks, All
Kev would like to thank everyone for their work this term.
Dave thanks everyone for their efforts - not just Council, but Jonas for his work as Editor too.
Everyone thanks everyone and then thanks everyone for the thanks.
Dave also thanks anyone who's made a useful contribution from the floor.

5) Fin
So long, and thanks all for the fish.

[Time and date of the next meeting to be decided by the new Council - tentatively, 2018-11-28 1600 UTC]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20181123/7b8d5c93/attachment.html>

More information about the Standards mailing list