https://logs.xmpp.org/council/2021-04-28?p=h#2021-04-28-eb39ac41316e139e
1) Roll Call Present: Zash, Daniel, Jonas, Dave, Georg. 2) Agenda Bashing The agenda was sent very late and very empty, but Georg has enough AOB to entertain everyone. 3) Editor's Update Nothing, but Editor didn't do anything. Bad Editor! 4) Items for Voting None. 5) Pending Votes All clear. Zash is thrilled. 6) Date of Next 2021-05-05 1500 UTC Georg will be resting his eyes for the next two weeks. 7) AOB Jonas thinks Georg had some things - Georg is unprepared for the responsibility. Georg recalls something about bringing up the CVE thing on-list, which he hasn't done yet, and he has a hard time remembering last week's conclusions of what to do about 'private' and 'no-copy'. Dave will be getting a COVID vaccine shortly, which seems a bit pointless when his phone doesn't even do 5G. Jonas scrolls through history in search of answers; Zash thinks there was something about not removing 'private'. Jonas summarises: if Georg wants to remove the strange 'private' behaviour then a feature should be added to indicate that the server executes the new behaviour, otherwise there will be chaos. Georg wonders why a feature wasn't added the last time 'private' stripping was changed - Jonas presumes it was an oversight, but past wrongs don't justify new wrongs; Georg had hoped a new wrong would cancel out the old one. Georg is unsure, given the amount of server developer feedback on this issue - Jonas says the lack of feedback doesn't allow forming a conclusion, so it's best to play safe - Georg will move forward by removing the stripping requirement and adding a no-stripping feature. Goerg now asks what to do about 'no-copy' hints - Jonas has no opinion, nor a clear picture of the implications; asks Georg for a summary of the current situation and why it's bad, and Georg's preferred changes. Georg explains that 'no-copy' was added as an additional requirement after 'private' was already there; the requirements for servers are vague, at best; removing 'no-copy' will do no harm to specification-abiding implementations; the only foreseen corner case is when a receiving client relies on 'no-copy' being present while 'private' is stripped by a stripping server. Daniel says the only time 'no-copy' is used in Conversations is when sending a direct-invite to the user's own connected resources to inform them of joining a new MUC, which is probably now obsolete with Bookmarks in PEP. Jonas still has no strong opinion on this, but assumes many implementations would handle 'private' even if 'no-copy' were absent - Georg had a similar conclusion. Georg thanks everybody for the fruitful discussion, and may finally be out of AOBs (for now, at least.) Daniel wonders what stripping, or not stripping, achieves - Georg wants to get rid of legacy protocol. Zash has lost track of exactly what the question was - so has Daniel - Zash thinks 'no-copy' should be stripped from the XEP and 'private' should not be stripped from stanzas - Georg thinks that sounds about right. Dave notes that the past half hour has been spent on protocol design in a Council meeting, and maybe there should be a proposal sent to the list to see if there is a consensus on what to do - Georg, Jonas, and Zash think that's a smart idea - Georg adds it to his personal agenda. 8) Close Jonas wishes everyone a pleasant rest of the day. Thanks all. Thanks Jonas, Tedd, and all. Daniel thinks Message Carbons is weird legacy anyway - doesn't think anything is gained from messing with 'no-copy' and 'private'; introducing 'no-copy' was a mistake, but the extra bytes don't matter considering the overhead Carbons already has - Georg doesn't think there is a need to cement that mistake into eternity - Daniel hopes Carbons doesn't hang around for an eternity; Dave wonders whether it would matter when it's already in implementations. Daniel notes that stripping 'private' was a requirement even before 'no-copy' was introduced, so stripping 'private' isn't to remove redundant information after the introduction of 'no-copy' because it was there before; even if 'no-copy' is removed, there's no need to mess with stripping of 'private'. Kev thinks it was a mistake; Zash thinks human evolution was a mistake. Considering the very few use cases for 'private' and 'no-copy', Daniel suggests just accepting that Carbons is not pretty, but it is de fact Draft now, so leave everything as is. Jonas thinks the stripping of 'private' might be considered actively harmful, so fixing that before Draft may be worthwhile - Kev does consider it to be actively harmful. Daniel suggests removing 'no-copy' and not stripping 'private' - Georg thinks that's a great idea. Daniel checks whether anyone can think of a scenario where a receiving client relies on 'private' being stripped, assuming that's the possible breaking change - Kev can't. Zash asks whether anyone remembers why it is stripped, presumably some privacy issue - Kev thinks it was a mistake, and the changelog says it was removed, but instead it was added. Georg thinks there was a version of Carbons that required the sending server to strip, but then somebody realised the receiving server also needs that information - Zash thinks Prosody might still follow that. Daniel changes his mind and gives Georg his blessing to remove the 'no-copy' hint from the XEP, and to remove the requirement to strip 'private'. Zash adds the correction that Prosody only strips 'private' from the receiving end. Georg notices the lack of Council Minutes for this month.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
