Hi Daniel, 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 - it’s changing the intent of the XEP from the one that was accepted. 384 was accepted as a Standards Track XEP that’s going to be developed through the usual community consensus process. I (quite strongly) believe that if there’s going to be a XEP published that is not the process of the normal community consensus process we should publish a new XEP with a new number to reflect this. The confusion of “I thought 384 was the XSF standard? Oh, no, that’s (the not-yet-published) XEP-0xxx, 384’s a deprecated legacy approach now” is weird. While the publishing of a Historical XEP covering a pre-standardisation version of the protocol is something I think we’re prepared to do just in order to be able to move on with this, this is not the normal way we operate and is just us trying to get out of the situation where we’ve got people contributing specs and implementing them while not understanding the environment in which they’re doing it. We shouldn’t want to bend the normal standards process further than needed. I am concerned that, amongst other things, re-appropriating 384for OMEMO-SIACS sends the clear message that this is the spec the XSF wants people to implement going forwards - which is exactly not the case. This Historical publication of OMEMO-SIACS is a sticking-plaster that has limited life, particularly as it’s then essentially immutable (Historical protocol isn’t under active development), so proposed changes like ODR won't be added. (As an aside, I don’t believe we have a mechanism for changing a Standards Track XEP to Historical, although we do for updating a Historical XEP to be Standards Track, but could be wrong (I’ve not double-checked XEP1)) /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
