[Standards] XMPP Council Minutes 2018-08-08

Tedd Sterr teddsterr at outlook.com
Thu Aug 9 15:56:57 UTC 2018


In which there is much on-listing…

1) Rolls
Present: Kev, Georg, Sam, Daniel
Apologies: Dave

2) PR #693 - XEP-0060: Remove unused 'node' attribute on pubsub#event item - https://github.com/xsf/xeps/pull/693
Kev: [on-list] (didn't get a chance to review before the meeting)
Sam: +1
Georg: [on-list] (only just realized the three PRs 15mins ago)
Daniel: [on-list]
Dave: [pending]

3) PR #692 - XEP-0060: correct "entity" to "<subscription/>" - https://github.com/xsf/xeps/pull/692
Kev: [on-list]
Sam: [on-list]
Georg: [on-list] (will probably bring this up next meeting with further questions)
Daniel: [on-list]
Dave: [pending]

4) PR #690 - XEP-0184: Make the schema require @id in <received/> - https://github.com/xsf/xeps/pull/690
Kev: [on-list]
Daniel: [on-list]
Georg: -1 (the change makes the schema inconsistent with the text)
Sam: [on-list]
Dave: [pending]

Georg thinks that 'id' should be made mandatory in both places, but doesn't want to cause a namespace version bump; would be okay changing it to MUST, without the bump, since the protocol doesn't make sense otherwise. But if there were to be a bump, Georg would also like to add multi-ACKs.
Peter thinks the original assumption was that not everyone would want to do tracking, but would be okay with saying that a <received/> element MUST include an 'id' attribute; Kev thinks it would be meaningless otherwise.
Georg suggests that the alternative would be treating a receipt without 'id' as acknowledgement for all previous messages, which would inevitably lead to race conditions.
The author says he did interpret SHOULD as MUST in this case, as it doesn't make sense otherwise, and can easily change it to MUST (as it SHUOLD be.)
Peter doesn't see the necessity of a namespace bump - an entity receiving acknowledgement (with an 'id') would now simply get more information, which shouldn't break anything. Kev suggests an argument for the bump would be that a previously compliant implementation would cease being compliant if it didn't already include the 'id'.
Kev doesn't think the disruption caused by a bump is warranted, and a note to the effect of "you might receive an acknowledgement without the 'id' attribute due to previous versions" would be sane; the author proposes to update the PR to include such a note - Kev and Georg are appreciative.

5) Date of next
2018-08-15 1500 UTC

6) AOB

7) Close
Thanks all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180809/d0904208/attachment.html>

More information about the Standards mailing list