> On 2 Jun 2017, at 11:57, Daniel Gultsch <[email protected]> wrote: > > 2017-06-01 13:12 GMT+02:00 Kevin Smith <[email protected]>: >> On 1 Jun 2017, at 11:22, Daniel Gultsch <[email protected]> wrote: >>> I went ahead an created a PR for XEP-0384 to match what is actually >>> implemented in the wild. >>> ... >>> I changed the track from Standards to Historical. >>> I checked: Track changes have happened before and are apparently >>> possible if Council agrees. >>> I think this is the best way forward given that developers and users >>> who are *currently* looking for the OMEMO spec are probably looking >>> for this XEP and not OMEMO-NEXT. >>> Also we don't have to assign a new author as it would be the case if >>> XEP-0384 would become OMEMO-NEXT. >> >> I think that, while someone interested in implementing OMEMO-SIACS might >> find it convenient for 384 to be changed in this way, what the XSF wants is >> to push people towards Standards Track XEPs and in this case, 384 seems to >> be the logical place. >> >> Conceptually, changing 384 to historical and changing the content is very odd > > If it is easier 'conceptually' I'm also fine with leaving it in the > Standards track and marking it as deprecated. > > The point is that OMEMO in its current form is extremely popular. How > many XEPs have Wikipedia and online news media (LWN, Golem) articles > written about them?
I think that’s a significant argument for why 384 needs to remain the location of the XSF’s ongoing work on this. Many people are, as you note, interested that the XSF is working on a standard here, so saying “We’ve stopped working on it” would be misleading and unhelpful. > If the current consensuses is to take OMEMO in a different direction > with OMEMO-NEXT that's fine. But don't water down the current state by > sending it to the attic. > The state of OMEMO as described in my PR is what people will use for > the foreseeable future. I can see an argument for publishing a standards-track version of 384 reflecting the current state, so there’s a stable identifier for it under version 0.x, to reflect what’s deployed, before moving on with further development. Another option would be publishing a Historical XEP, and having a prominent reference to that in 384. > If the XSF wants to push people in a different > direction (OMEMO-NEXT) they can do this by deprecating XEP-384 (and > create a link to OMEMO-NEXT) I think the XSF’s focus should be on the ‘right solution’, not on how to best support some pre-standardisation implementations. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
