http://logs.xmpp.org/council/2019-02-06/#16:01:14
In which there is a lot… 1) Wrap Call [healthier] Present: Dave, Jonas, Link, Kev AFK-busy: Georg 2) Agenda bashing Dave thinks everything has been caught, thanks to Jonas's diligence. 3a) PR #739 - XEP-0410: pre-LC and LC feedback - https://github.com/xsf/xeps/pull/739 Georg noted this has been merged, but is an indication of what's been changed since Council's last reading. 3b) PR #752 - XEP-0410: add application-specific <not-an-occupant/> condition - https://github.com/xsf/xeps/pull/752 [Postponed until Georg's return.] 3c) Advance XEP-0410 (MUC Self-Ping) to Draft - https://xmpp.org/extensions/xep-0410.html [Postponed until Georg's return.] 3d) PR #745 - XEP-0234: Use <hash-used/> to signify the hash function being used, instead of an (invalid) empty <hash/> - https://github.com/xsf/xeps/pull/745 Link has a big set of changes and would like to avoid bumping the namespace before they're merged; Jonas notes that he has already been waiting for these changes for over a year. Link explains that the addition of <hash-used/> was already a breaking changing without an accompanying namespace-bump, and so it might be excusable to make another change without the bump, and then finally bump once after his own changes are pushed. Dave doesn't think this needs a bump, and is not happy about delaying it for not-yet-existent PRs. Jonas agrees with Link, that the current version is 'broken,' but the namespace-bump would be undesirable. Jonas queries Link how realistic it will be to have his changes ready by next meeting - Link will make it a high priority, so it's a possibility. Dave concedes that the "hash-used" change is breaking, and so can live without the namespace change on that basis. Jonas: +1 (without namespace change, else -1) Kev: [on-list] Dave: +1 (I think) Link: +1 (without namespace change) Georg: [pending] 3e) Proposed XMPP Extension: XMPP Over RELOAD (XOR) - https://xmpp.org/extensions/inbox/xor.html Jonas has no knowledge of RELOAD. Georg makes an appearance; Dave notes the order of agenda items has been shuffled to put Georg's interests at the end. Dave votes +1, on the basis of knowing little more about RELOAD than its abstract, but it seems believable. Link skimmed through, and had read the author's previous comments on this protocol, though knows little about RELOAD otherwise, but votes +1 on the basis that it appears to be an interesting proposal. Jonas would like to mention that the XEP contains material inappropriate for a Standards Track document, specifically the part about prescribing Certificate Authority (CA) responsibility to the XSF - at least without involving Board; Dave suggests it may need splitting to accommodate this. Jonas summons Ralph (from Board) for suggestions - Ralph meditates on the matter. Jonas suggests the author remove the XSF CA obligations, and submit an additional "Procedural" document on how the CA should operate. Dave requests noting the requirement of a single CA, and then create a new XEP to define the XSF-based CA; Jonas says this is correct and sensible. Georg thinks that a wire format for exchanging CSRs and CRTs between XMPP entities, based on JIDs, would be a welcome addition and solve the technical issue. Ralph thinks it would be weird to have the XSF as the only entity for this, i.e. the XMPP network is not, and should not be, controlled by the XSF. Georg asks why it should even be XSF-based - there could be an external entity, as long as it's documented as the root of trust for RELOAD-XMPP. The author agrees the XSF CA parts could be removed, but that doesn't solve the practical problem of requiring certificates signed by a trusted CA (further, one that will not produce numerous certificates that attackers could take advantage of). Dave advises noting that requirement and removing the XSF CA part - possibly submitting those details as an additional XEP for Board to consider. Jonas advises similarly, and to describe what's necessary on a procedural level to make it work securely as a follow-up document. The author suggests rejecting this proto-XEP, on expectation of the advised changes being ready by next meeting. Dave: -1 (expect a new submission will pass) Jonas: -1 (on the basis that the presented ProtoXEP has Procedural content which needs to be acked by Board) Link: -1 (waiting for next version) Kev: [on-list] Georg: [pending] Ralph doesn't agree this is a requirement for rejecting the XEP as Experimental, but agrees Board should be involved if a CA needs to be set up; Dave and Jonas would prefer Board decides whether to adopt an XSF CA document. 3f) PR #744 - XEP-0001: Clarify proposing Deferred XEPs for advancement to Draft - https://github.com/xsf/xeps/pull/744 Link: +1 Georg: -1 (as-is, +1 with "thereby taking up the role of XEP author" removed) Jonas: -1 (as-is, +1 with "thereby taking up the role of XEP author" removed) Dave: +0 (don't think it matters in practice, but the authorship change is curious) Kev interprets this to mean that someone can automatically take authorship of an XEP simply by proposing it for advancement, which would be wrong and the two things should be independent; Jonas agrees. Dave thinks that anyone asking for advancement seems fine. Jonas says it will still be voted on, and if ready for Draft then it doesn't really matter whether the author is still around; and Council will be the gatekeeper for further changes. Georg kind of likes that one can't propose advancement without also committing to maintaining. Jonas thinks the authorship change is unnecessary. Kev says it's unclear whether the old author would be replaced; the PR author thought that accepting the change of ownership would be up to the Editor. The PR author says the problem is that an XEP Author is needed to process Last Call feedback; Kev says Council can try to find a new Author if needed. Jonas requests some new wording to make it clear that the proposer becomes responsible for processing LC feedback. Georg thinks it makes sense to put that burden on the proposer. The PR author says the intent was for the proposer to take up ownership in the case of abandonment; but if they are allowed to process LC feedback, why wouldn't this make them an author. Kev thinks some new text would be a good idea. The PR author is unsure how to proceed and would like to discuss details further. Peter says this sounds a bit like the IETF's Document Shepherd role [1]. 3g) PR #746 - XEP-0060: Add missing @publisher in pubsub schema - https://github.com/xsf/xeps/pull/746 Link: +1 (obviously, as the author) Dave: +1 (this looks satrightforward) Jonas: +1 Georg: +1 Kev: [on-list] 3h) PR #747 - XEP-0084: Bump the maximum of @width and @height to 65535 - https://github.com/xsf/xeps/pull/747 Georg says this changes the schema and thus, technically, requires a namespace-bump; Jonas say it doesn't change any normative part and is probably just an oversight. Dave wants to do some digging first, to decide whether Georg is right. Georg says if you follow the old schema and use unsignedByte, you'll end up overflowing your data field. Kev says schemas are non-normative in XEPs; Dave also says schemas have usually been held as non-normative. Jonas says that if you're parsing the XML strictly by schema, without validating, you're doing it wrong; Link says if you do validate, as it is now, you'll reject many otherwise valid images. Jonas prays for not namespace-bumping avatars. Georg says Link owes a non-namespace-bumping XEP change, then. Link: +1 (as the author) Jonas: +1 (doesn't change any normative part and is probably just an oversight) Dave: [on-list] Georg: +1 (I want to see the world burn) Kev: [on-list] 3b') PR #752 - XEP-0410: add application-specific <not-an-occupant/> condition - https://github.com/xsf/xeps/pull/752 Georg explains that this was the result of a discussion, from which he concluded that it would be great to have an application-specific <not-an-occupant/> or maybe <not-in-room/> condition in MUC. Jonas is supportive of this, or any other of the commonly-encountered RFC 6120 stanza error condition accompanying not-an-occupant. Dave asks why this isn't using the error element's 'by' attribute instead; Jonas thinks this is a good addition, but having an additional, distinct, MUC-specific <not-an-occupant/> is a good thing too. Georg didn't want to PR XEP-0045 yet (the dreaded namespace-bump), but really wants this new condition added. Dave suggests doing it as a MUC extension under a different namespace, e.g. <feature var="urn:xmpp:muc:errors:0"/>, and then send application-specific errors using that; Link thinks this sounds like the way forward. Georg says adding this into XEP-0410 is defining MUC errors in an XEP that has a different purpose. Georg proposes that Jonas writes a separate "Application Specific Errors for MUC" XEP, for having instigated this mess (with the original discussion.) Georg will add the 'by' attribute into XEP-0410 and then publish it, if nobody is against that. Link: +1 Dave: -1 Jonas: +0 Georg: -1 (despite being the author, this needs its own XEP) Kev: [on-list] Georg thanks everyone for the enlightening discussion. Dave thinks it's great when people reject their own stuff. 3c') Advance XEP-0410 (MUC Self-Ping) to Draft - https://xmpp.org/extensions/xep-0410.html Georg: +1 (with a @by added into the error) Dave: +1 (with @by) Jonas: +1 (with @by added) Link: +1 Kev: [on-list] 4) Outstanding Votes There are none, but Dave demands they are made on-list anyway as the meeting has overrun considerably. 5) Next Meeting 2019-02-13 1600 UTC 6) AOB Dave really hopes not. Jonas thanks Tedd Sterr for doing the minutes all the time and the vote summaries; others agrees that is helpful. 7) Close Kev would like to keep meetings to 30 minutes. Dave generally agrees, but there were a lot of items to vote on, and infinitely prefers voting in-meeting to on-list, where possible. Jonas says remaining items could have been moved to the following week; and doesn't want to cut own on in-meeting discussions as they are valuable. Dave says the meeting after the Summit is always likely to be busy. Kev thinks it will be counter-productive if it becomes a habit, as all votes will end up being on-list. Council meetings often used to run over, but that was eventually constrained to a sensible 30 minutes, and Kev isn't keen to go back - would rather push items to the following week than have people appearing to be present, but actually busy elsewhere once the meeting over-runs. [1] https://www.ietf.org/blog/iesg-statement-document-shepherds
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
