[standards-jig] informational vs. standards-track

Robert Norris rob at cataclysm.cx
Wed Jul 30 01:17:52 UTC 2003

> Right, but again you get to create a de-facto standard by writing and
> publishing an informational JEP. The distinction between
> "informational" and "standards-track" is pretty subtle at the moment
> and I think very few developers understand the difference.

Perhaps the distinction between information and standards-track is
subtle (though I don't think so - the IETF has had informational and
standards-track documents for years, and everyone seems to understand
those). However, none of this means that a JEP is not a suitable place
for any kind of Jabber protocol document.

> I do think it's valid to document "here's how we did it", but it
> should be extremely clear that it's not a standard. To me, that means
> it can't be a JEP. Also, I think a valid question is -- what's the
> point of publishing something if it's not going to become a standard.

Its a question of scope. Its generally recognised that Service Discovery
is a required building block of the Jabber world, so we call it a
standard. Distributing mood information via pubsub, on the other hand,
is hardly a make or break protocol, so we don't call it a standard.

However, if I want to implement a piece of code that publishes moods, I
want to know how other people are doing it so that I can talk to them
effectively. For this case, it makes perfect sense to have the method
that everyone else is using available in a known location so I don't
need to search, ask for help, possibly get mixed responses, etc.

> >Just because a JEP is informational doesn't mean its been "blessed"
> >by the JSF.
> I think it has the perception of being blessed at the moment. It's
> published on the JSF website, is listed with other JEP's, doesn't
> include any warnings, etc. The only difference is a tiny bit of text
> labelling the JEP as "informational" vs. "standards track". I can tell
> you for sure that most outside developers don't understand the
> distinction.

Thats a matter of perception, and is something that can be changed with
a minimum of fuss.

> >An example - several servers support the old jabber:component:accept
> >for hooking up components via TCP. It works and is widely understood
> >and implemented, but I don't think that anyone would be silly enough
> >to suggest it should be on the standards track. Something like this
> >is perfect for an informational JEP - it is documented in a well
> >known location, and anyone can use it.
> If it's written up as a JEP many developers will simply implement it
> assuming it's some sort of standard. Now, if we named it a "Legacy
> Protocol Description" or something instead of a JEP, I think most
> people would "get it". It's really just a matter of presentation.

So we're debating what it means for a document to be a JEP. Are you
against having "informational" (whatever they are called) documents
available on the JSF website? Or do you simply not want to call them

FWIW, calling something a JEP isn't magic fairy dust. Use the word "JEP"
when talking to anyone who hasn't been involved in the JEP process
themselves, and you'll quickly find that noone has a clue what you're
talking about ;)

I note that the two other "standards" process on which the JEP process
is based (those being the Python PEP process and the IETF RFC process)
both include the concept of "informational" documents, and they don't
seem to be having any problem with misunderstandings.

> >Interesting you bring up the vacation JEP - I will be changing it to
> >informational with the next revision. This is another nice example -
> >its a feature that requires a protocol extension. Its not specific to
> >any project, but is something that to work, needs to be implemented
> >by both clients and servers. Where is the proper home for this, if
> >not as a JEP?
> If it's not good enough to be standards-track then it's not worth
> making it a JEP. However, I do think the attitude needs to shift a bit
> on what should be standards-track. At the moment, it's only things
> that are "core". I think there is a much broader range of JEP's that
> can be standards-track as long as we add classifications as I
> suggested in my previous email.

It seems we need to clarify a terms before we can proceed much further.

JEP-0001 (an Informational JEP, I note) says that a Standards Track JEP
"defines a proposed enhancement or extensions to the official Jabber
protocol", while an Informational JEP "defines an existing protocol in
use within the Jabber community without proposing that it be added to
the standard protocol".

So, a Standards Track JEP adds to the "official" or "standard" protocol.
An Informational JEP, on the other hand documents an _existing_ protocol
that is not to be considered a part of the "standard" protocol.

The only thing that hasn't been defined is what the "official" or
"standard" protocol actually is. Peter has proposed that this be
considered protocol that is required for compliance testing (ie protocol
that is required by a protocol suite, like IM Basic).

Based on these definitions, the vacation JEP (along with many others)
clearly _is_ good enough to be an Informational JEP, but not good enough
to be Standards Track (something I will rectify shortly).


Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030730/2e9fdec4/attachment.sig>

More information about the Standards mailing list