http://logs.xmpp.org/council/2018-08-08/#15:00:48

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
None.

7) Close
Thanks all.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________

Reply via email to