[Standards] Renaming XEP status 'Draft' to 'Stable'

Peter Saint-Andre stpeter at stpeter.im
Wed Nov 1 14:30:25 UTC 2017


On 11/1/17 6:40 AM, Matthew Wild wrote:
> On 1 November 2017 at 12:35, Matthew Wild <mwild1 at gmail.com> wrote:
>> As such, I've prepared a change of XEP-0001 here:
>> https://github.com/mwild1/xeps/commit/9cebf36e11d5918352b49c1a3e27fec2f17d8005
> 
> Without my Board hat on... a couple of things jumped out at me with
> this change (which currently is mostly a simple word replacement and
> the addition of a note):
> 
> 1) "Although [...] backwards-incompatible modifications shall be
> avoided if at all possible, deployment of a Stable protocol in
> mission-critical application may not be advisable."
> 
> The name "Stable" implies that the specification is, well, stable. I
> would suggest that we either remove or modify this sentence.
> 
>  2) "In order for a XEP to advance from Stable status to Final status
> (version 2.0), it must be shown to be stable and well-received by the
> XMPP developer community."
> 
> Here the text talks about the protocol needing to be "stable" before
> it advances from Stable to Final. Again, this just feels a bit wrong,
> and we might want to reconsider how we define the transition from
> Stable -> Final.

In both cases, we don't have objective criteria, and the desire to
change termininology for marketing purposes has exposed that fact.

As to the first point, there are many reasons why an organization might
not want to deploy an implementation of a Draft or even Final protocol
(e.g., it might have unknown security issues). It's not really up to the
XSF to tell organizations when or when not to deploy. We might just say
that "backward-incompatible modifications shall be avoided if at all
possible" and let people draw their own conclusions.

As to the second point, it would be good to define more objective
criteria for advancement (e.g., no significant changes in 12 months,
widespread implementation and deployment, no known security issues).

Peter


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 873 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171101/49569ddb/attachment.sig>


More information about the Standards mailing list