http://logs.xmpp.org/council/2020-01-08?p=h#2020-01-08-07328054a6023d16
1) Roll Call Present: Jonas, Dave, Daniel, Zash, Georg 2) Agenda Bashing There is nothing to add. 3a) Proposed XMPP Extension: Special Interests Group End to End Encryption - https://xmpp.org/extensions/inbox/sige2ee.html Jonas realises that SIG Proposal/Formation have their own XEP types, so that will have to be adjusted by the Editor. Jonas is unclear on the procedure around this and doesn't want to waste meeting time trying to figure it out. Dave: +1 (generally in favour; had some comments on the second bullet point) Jonas: [on-list] (procedure is unclear to me) Georg: +1 Daniel: [on-list] (haven't had time to read; assuming +1) Zash: [pending] 3b) Do something about the OMEMO XEP Dave has suggested moving XEP-0384 (OMEMO Encryption) to Rejected, as it's not clear that OMEMO can (or should) be made Draft - this relates to whether it can be implemented without using a GPL library; some people have argued that it can and others that it can't. Jonas asks whether that's a strict requirement for Draft - Dave thinks the objectives in XEP-0001 suggest it is, since GPL (or any license restrictions) would count as an encumbrance. Ralph agrees and doesn't believe XEP-0384 can move forward in its current form. Jonas thinks that, while proof isn't normally required (beyond the IPR), uncertainty over the Signal protocol requires extra proof to let this move forward; and that proof may be difficult as this looks like a grey area of copyright law, which is not good for an open standard. Dave notes that the XEP doesn't reference the libsignal documents, though whether they are sufficient to implement a non-GPL version is ambiguous. Dave knows of at least one effort to make a non-GPL client using OMEMO which failed with the author deciding it wasn't possible given the available information; also knows other people who claim that it is possible. Jonas suggests that XEP-0384 is changed to Historical and frozen, and if the community wants to pursue Signal-esque E2EE under the XSF umbrella, they will need a proper document with the minimal references required to describe implementation from basic principles; longer-term, we should probably pursue MLS. Zash thinks this sounds sensible. Daniel thinks the intent was to move this to Historical, but switching tracks was deemed impossible. Jonas thinks this fits Historical (stretching the meaning of "before the XSF's standards process was instituted" somewhat), conveniently allowing voluntary blindness with regard to the encumbrance question (XEP-0001 objective 4). Ralph doesn't think this XEP meets the definition of Historical, and isn't sure how changing to Historical is addressing objective 4 - Jonas thinks it's unfit for Standards, mainly due to licensing, but documenting the ecosystem is still worthwhile; while it doesn't entirely fit the definition of Historical, it may be the best place if it's still wanted as an XEP (Informational could also work, but with Deprecated state). Zash wouldn't be opposed to tweaking the definition of Historical. Ralph would be opposed to tweaking process purely to accommodate having a specification like OMEMO. Daniel mostly agrees with what Jonas said. Dave would be fine with any status that doesn't suggest this is a recommendation by the XSF. Georg would be fine with Historical or Informational+Deprecated, with a slight preference for the former. Pep is not entirely fine with Deprecated while there's no replacement, but Informational is probably okay. Jonas proposes that Council instruct the Editor to create a patch which moves the XEP to Informational, changes it to Deprecated, and adds the necessary wording to clarify this is an embedding of the Signal protocol and not a preferred or open E2EE scheme. Ralph suggests either not moving it forward until the objective is met (e.g. by switching back to Olm, or forward to MLS), or dismiss the XEP as unacceptable; neither Historical nor Informational+Deprecated carry the right message - Rejected would. Jonas would be okay with Rejected, but it would have to go through Proposed first. Georg expects that either change will cause contention in the community. Pep wonders what kind of message this is sending (that the XSF doesn't care about E2EE.) Jonas asks for a quick show of hands on whether the XEP (in its current form) should be demoted and put in a dead end (specifics to be figured out later). Zash paraphrases Pep, "this isn't the Right Way" - Ralph says we don't base our standards on libraries. Dave is fine with putting it through a Last Call, which would then allow it to be declared counter to the objectives, and Rejected. Georg is supportive of the general direction. Zash shows a hand. Dave shows a hand. Jonas sees the time, and that this requires further discussion; encourages everyone to take it the list or XSF MUC. 4) Date of next 2020-01-15 1600 UTC Georg may find himself trapped in another meeting next week. 5) AOB Jonas confesses to accidentally merging PR #870, but has reverted the change and republished to avoid any appearance of a cover-up. Georg notes that the author asked for feedback on the proposed change. 6) Close Thanks everyone!
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
