http://logs.xmpp.org/council/2018-11-21/#16:00:06

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]

_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to