http://logs.xmpp.org/council/2020-01-15?p=h#2020-01-15-fedc88f3c5761fda
1) Roll Call Present: Georg, Daniel, Zash, Jonas, Dave 2) Agenda Bashing Jonas mentions that there's something about OMEMO, and Georg has something for AOB; Georg adds PR #878, but Jonas says it belongs with the OMEMO discussion. 3a) Something about OMEMO Jonas summarises: last week, Council expressed a desire to demote the current OMEMO XEP; options suggested were: move to Proposed and then reject, change to Historical, or change to Informational and set to Obsoleted. Jonas would prefer Informational+Obsoleted. Ralph doesn't see how it is Informational, and Obsoleted implies it has already been Active - Jonas thinks it's Informational because it is deployed in a major share of software right now. Ralph thinks that, as it's Experimental, changes are a natural thing. Daniel says people (himself included) have proposed to produce a revised OMEMO specification by mid-February; voting now to move it to a state from which it can't be recovered would force the creation of a new XEP - Jonas thinks this is desirable. Pep questions why it would be desirable, as OMEMO is still Experimental - Jonas says discovering the individual versions would be troublesome, particularly with the high degree of deployment; a major version bump is needed. Daniel sees both sides of the argument, and is torn on whether 'newmemo' should have a new number - Jonas thinks it needs both a new name and number to avoid confusion. Kev suggests that 'fixing' OMEMO without changing the name might help with future adoption, as implementers of Experimental XEPs should be expecting future updates. Daniel suggests it might weaken the OMEMO 'brand' if there are incompatible implementations. Pep points out that the whole point of Experimental is to be able to experiment. Ralph notes that it was originally based on Olm - Dave confirms, having read through the original discussion, that the plan was to alter it in situ once there was a version with the deployed design. Kev thinks the roll-back to Signal was only allowed in the first place with the intention of 'fixing' it. Jonas proposes to issue a Last Call with an extended period due to the expected discussions; either the new OMEMO team has a new draft ready in that time, or Council votes to reject. Ralph thinks Council can deem it not ready for advancement with the arguments already presented, and then advise it be revised not to depend on libsignal. Daniel asks why the LC - Jonas says to allow moving to Rejected, as per XEP-0001, and it could bring more feedback from the wider community - Ralph doesn't expect any new arguments. Dave is unsure of the LC - it can't advance along the Standards Track, so it's only useful as a process workaround. Kev thinks an LC at this point would just create more noise; why not wait a few weeks for the next version to take shape, and work things out from there. Jonas doesn't think more feedback would be a bad thing. Kev suggests the only reason for urgency is that IPR process says attempts should be made to replace it because it's encumbered - which would be happening. Daniel thinks there's enough feedback, now it just needs to be processed and a working specification produced. Pep doesn't like that this is being rushed, and it is only due to the recent drama - Jonas says the dates aren't fixed, and this is more about the concept; Dave adds that it has been over two years, so it's hardly a rush. Pep asks when Council reminded the author or community of the issue - Jonas says it's not their job to do so. Larma says that discussions have been ongoing for some time, but there are no visible results yet; two years isn't much time for designing a cryptography protocol, especially with unpaid volunteers. Dave asks whether there should be a discoverable copy of the current OMEMO version in the future, which was a requirement of the original compromise - Kev thinks this already comes out of the versioning; Jonas thinks the versioning is not discoverable. Kev thinks the most important thing is that there is a plan to resolve this mess, and that the current OMEMO version is sunset in some way; the nature of XEP numbers is less important. Ralph suggests that, as the current state is Deferred, if somebody takes it out and either reworks it into OMEMO:2, or Proposes it as-is, then Council must act; so the question is whether the currently published version is a problem (regarding objective 4 and IPR policy) - Dave thinks it is, as far as being on the Standards Track, which seems to show intent - Ralph agrees. Pep doesn't think it's a problem, as the XEP is Experimental, and the IPR explicitly states requirements "after approval" which means 'Draft' in XEP-0001. Jonas thinks the situation has changed in the past week (there is a clear statement of people actively working on new-OMEMO, at least), and proposes leaving the attempt to move OMEMO into another state until shortly after the Summit, and revisit then. Kev suggests, as a minimum, that it would be sane to explain (at the top of the XEP) that the current XEP is encumbered, so it can't be advanced in the standards process, and the XSF is looking to replace it - this would at least satisfy policy. Larma thinks this is essentially what PR #878 does - Kev thinks PR #878 says "this isn't Signal, even though we call it Signal" - Larma says it indicates not using Signal in the future. Jonas thinks PR #878 is nonsensical; Ralph think it makes matters worse; Georg agrees that it's not helping; Larma thinks it reflects the truth. Jonas proposes wording: "This specification is currently under special review by the XSF for potential encumbrance as per XEP-0001 ยง X Objective 4. New implementations are discouraged while work is in progress to replace large portions of this document." - everyone is broadly supportive; Dave thinks it's better than nothing, but suspects a better fix is needed longer term, and will propose something policy-ish later. Jonas repeats the suggestion of leaving the topic of demoting OMEMO for a few weeks (until after FOSDEM), to see how the SIG-E2EE plays out - Pep says they meet after FOSDEM, so there will be little progress. 4) Outstanding Votes Jonas notes the three ProtoXEP votes expiring today [technically tomorrow, given the Thursday meeting after the New Year.] 4a) SIG-E2EE Dave asks whether anything happened concerning his "representation" remark - Jonas isn't aware of anything, but hasn't had time to look into it. Daniel queries whether this refers to the addition of a footnote explaining that XSF representation must be approved members, but the SIG itself is open to the public - Dave confirms. Pep notes that as SIGs have no authority, it shouldn't matter who represents them - Dave thinks maybe not internally, but more so externally. Zash asks whether there is a leader for the proposed SIG-E2EE - Ralph hasn't seen suggestions, and this is holding it back. Pep suggests the author (Paul Schaub) as an obvious choice; Georg asks Paul whether he accepts the position - he does. Dave asks whether the SIG only becomes active when the XEP becomes Active - Ralph thinks so; Jonas intends to research this and many other SIG questions. Georg asks whether it makes sense to vote on making Paul its leader before the SIG has been accepted - Jonas doesn't think so. 4b) Outstanding votes on three other ProtoXEPs Jonas notes that Georg cast a few votes earlier on-list, but there are still some open (notably his own) Jonas votes +1 on MAMFC, and +1 on Fallback Indication; on-list for SIG-E2EE. 5) Date of Next 2020-01-22 1600 UTC Jonas will be at an event, and requests a replacement Chair - Dave volunteers. Georg is also at an event, but will peek in. Dave will be travelling in two weeks; as will Daniel (and presumably others.) 6) AOB Georg wants to talk about PR #874, or more accurately, regarding his mail [1]. The author of XEP-0401 has asked for feedback from the wider community, and PR #874 may be potentially controversial (though less than the previous IBR non-dataform form hack) - Daniel had no troubles implementing it client-side. Georg is using a pre-IBR authenticated IQ for the server to assign a pre-auth token to the current non-session, and use that token in IBR; was made aware that pre-auth IQs are problematic for servers. Jonas doesn't like the decoupling, as it seems like a weird state to keep server-side - Georg doesn't either, but it's straightforward to implement (for clients, at least.) Dave suggested some time ago that IBR, et al., would be better done by authenticating anonymously and then doing the IBR, then reconnecting. Jonas isn't going to stand in the way of implementation experience here, but still finds it weird; it's Experimental, and can easily be moved to SASL2 before Draft. Georg would like some progress this decade, so hacks are passable for now; in the long term, hopes IBR will be reinvented by way of SASL2. Jonas suggests input from server developers - Georg notes there is already an implementation [2]. Daniel thinks ejabberd is traditionally more careful with such session states, particularly as clustering makes it more complicated, so somebody should ask them. Most are accepting of the approach, or not entirely against it, but Dave will kill it at Proposed if it stays this way - Georg hides behind dreams of SASL2. 7) Close Gracias. [1] https://mail.jabber.org/pipermail/standards/2020-January/036848.html [2] https://modules.prosody.im/mod_easy_invite.html
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
