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

Jonas Wielicki jonas at wielicki.name
Mon Nov 6 07:03:13 UTC 2017


On Mittwoch, 1. November 2017 08:30:25 CET Peter Saint-Andre wrote:
> On 11/1/17 6:40 AM, Matthew Wild wrote:
> > [… snip by jwi …]
> >  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.
> 
> [… snip by jwi …]
> 
> 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).

"no known security issues" must be defined carefully. Most of our XEPs have 
some Security Considerations which imply that there are security issues which 
need to be taken into account. Most of these have clear directions on how to 
avoid the implications of the security issues (for example XEP-0280 (Message 
Carbons) tells you to ignore carbons from entities other than your own account 
to avoid spoofing), but others only mention trade-offs.

The reason I’m pointing this out is that I think there are different views 
within the XSF how much of a trade-off and how much of a complexity is allowed 
within a Security Considerations section (see the recent XHTML-IM discussion).

If we are going to include the term "security issue" or the notion of security 
issues in the XEP process, I wonder whether we’re all thinking about the same 
thing and whether or not it’ll cause issues down the road.

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171106/5a82a8fe/attachment.sig>


More information about the Standards mailing list