Re: [Standards] Namespaces, specifications, and protocol life cycles

[Peter Saint-Andre]

Here is what I propose in XEP-0053, for a more readable version see
...

***

4. Namespace Issuance

The XMPP Registrar shall be responsible for issuing namespaces to be
used in XMPP Extension Protocols (XEPs) developed through the XMPP
Standards Foundation's standards process as specified in XEP-0001. The
policies and procedures for namespace issuance shall be as follows:

   1. When a XEP is first published in the Experimental state, the XMPP
Registrar shall work with the author(s) to generate an appropriate
namespace name, which shall be of the form "urn:xmpp:ShortName:0" or,
where appropriate, "urn:xmpp:ShortName:SubName:0". The following
considerations apply:
 a. Each name shall adhere to the format defined in RFC 4854 [10].
 b. Each name shall be of the form "urn:xmpp:ShortName[:SubName]".
 c. The "ShortName" string shall be unique within the XMPP URN
tree and any "SubName" strings shall be unique within the scope of the
ShortName.
 d. Each name should be relevant and memorable. Names may be
determined in consultation with the author(s) of the XEP and may be
requested by the author(s) in the XMPP Registrar Considerations section
of the XEP; however, the issuance of namespace names is the sole
responsibility of the XMPP Registrar, which may modify or ignore any
names requested.
 e. Each name shall be checked against the registry of existing
names located at  to
ensure that no duplicate names are issued.
 f. The XMPP Registrar shall issue all XMPP URNs directly and
shall not assign secondary responsibility for management of any sub-trees.

   2. While the XEP is in the Experimental state, if appropriate and in
consultation with the author(s), the XMPP Registrar shall update the
namespace version number at the end of namespace (e.g., from "0" to
"1"); the XMPP Registrar shall do so only if the protocol defined in the
XEP has been modified in a way that is not backwards-compatible with an
earlier version of the protocol, or if significant new features have
been added to the protocol.

   3. When the XMPP Council votes to advance the XEP to a status of
Draft, the XMPP Registrar shall update the namespace registry in
accordance with the procedures specified in the Registry Creation and
Maintenance section of this document.

   4. Any namespaces defined after advancement of the relevant XEP to a
status of Draft shall be handled in the same manner.

   5. While the XEP is in the Draft or Final state, if appropriate and
in consultation with the author(s) and the XMPP Council, the XMPP
Registrar shall update the namespace version number at the end of
namespace (e.g., from "1" to "2"); the XMPP Registrar shall do so only
if the protocol defined in the XEP has been modified in a way that is
not backwards-compatible with an earlier version of the protocol, or if
significant new features have been added to the protocol. The XMPP
Council must approve any change to the namespace version while the XEP
is in the Draft or Final state.

The XMPP Registrar shall not issue XMPP URNs except as specified above
(e.g., it shall not issue XMPP URNs to private parties or in relation to
specifications that are not published in the XEP series). However, the
XMPP Registrar may at its discretion add namespace names other than XMPP
URNs to its namespace registry, e.g. to register "legacy" namespace
names (of the form "jabber:iq:ShortName", "jabber:x:ShortName", and
"http://jabber.org/protocol/ShortName"; as well as namespace names
produced by recognized standards development organizations (such as
names issued in the IETF URN tree).

***

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Dave Cridland]

On Wed Oct  8 05:24:51 2008, Jack Moffitt wrote:

I'd like to see a clearer statement of the problem to solve rather
than so much debate over nuances of a proposed solution.  It seems
there is some hesitancy over implementing a protocol containing  
:tmp:

in the name.  There is also of course the problem if distinguishing
between versions of a particular protocol when it has gone through
some major revisions.



That's essentially the statement you're looking for.

Some protocols look fine for deployment when they're still in this  
:tmp: namespace. Others, we find in rare cases, need radical,  
non-interoperable change between revisions - it turns out, basically,  
that we broke something. Hopefully, this is rare, and hopefully  
there's another solution to, in effect, throwing away the protocol  
and replacing it with something else.



There is another solution to the reluctance to implement which also
takes some of the ambiguity out of the time line here.  That is to
issue the canonical urn as soon as a XEP draft is accepted by the
council.  Why wait until it has reached some nebulous maturity  
level?
If we accept a XEP, immediately issue it a urn.  This is early  
enough
in the life cycle that it should not affect implementers, and urns  
are

infinite in number.  We need not worry about wasting them


First off, I took it that the community felt there was value in  
having some form of signal that "This protocol is still under radical  
discussion and has not stabilized sufficient to bother coding." This  
is a useful signal for people not following every message in the  
process. It's just unfortunate that we signal this to people  
implementing experimental state protocols, because this can be a very  
good time to, well, experiment. And if the experiment works, these  
bleeding edge people should be benefiting by being ahead of the game,  
not stuck with a non-interoperable protocol that's only  
non-interoperable by a side-effect of a bureaucratic housekeeping  
process performed by fiat.


Secondly, I'm not worried about "wasting urns" either. My proposal of  
using a version number wasn't based on the notion of namespace  
collisions or exhaustion, but on the exhaustion of Good Names. I've  
seen protocols start off with fine, reasonably catchy names, and then  
go through radical refactoring, forcing a name change, and end up  
with awkward names.


This last might sound like frivolity, but names are important. We  
humans like to name things, and the names mean more than just a  
string of letters, irregardless of what any specification tells us  
they should mean. Hence the enormous thread on resource naming - and  
hence my actually quite serious post comparing resource naming with  
usernames, which, from a technical standpoint, would be fine, and has  
privacy improvements too. But names have an impact far beyond the  
technical. A rose by any other name might well smell as sweet, but  
would people still bother smelling it?


So in order to conserve not namespaces, but creativity, I suggested  
keeping the name, and attaching something else to it in order to  
distinguish the rare, and unfortunate, but sometimes required,  
protocol refactorings. I'm not wed to version numbering for this, but  
they have advantages in as much as I don't think that people are  
likely to consider urn:xmpp:foo:4 as being better or worse than  
urn:xmpp:bar:2 - or at least, not in quite the same way as they might  
consider urn:xmpp:foo:2008 vs urn:xmpp:bar:2010. But I'm not sure  
there is a terribly good solution here.


Technical argument stops here after my first paragraph, incidentally.  
The remainder is soft-science, not hard, there are no proofs that  
version numbering is better than years, or vice-versa. Technically,  
we could assign random names to each protocol (considering each time  
a protocol is revised so heavily that it ceases to interoperate as  
replacement with a new protocol), but that's not going to sit well  
with developers either.


Now, I happen not to be a big fan of years-as-versions. To us - I  
hope - an old protocol is a good one, assuming it's seen deployment.  
It's a success. But to the market, it's old technology, and the  
cutting edge is where it's at. It's why people get excited over  
Blackberries - "Latest technology mobile email! Optimized for low  
bandwidth!" instead of IMAP "Two decades of deployment! Designed over  
2400 baud!".


So, if you don't like version numbers - and I'll admit I just grabbed  
at the first thing I could think of:


1) Protocols start off as :tmp:, and in this state, standards  
developers can feel free to make incompatible changes.


2) If someone wants to implement them to the point they need a stable  
namespace, they can simply ask, and the :tmp: shall be removed. In  
other words, only one implementor need do so. Should we last-call  
this? Give a week's warning? I don't know, but I suspect that someone  
saying "Hey, I'm doing t

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Jack Moffitt]

> urn:xmpp:protoname:1
>
> That last portion we'll treat as a version number. Any time we cause
> incompatibility between versions of the XEP, we update it. (Note, that's not
> "every new XEP").

I dislike this solution.  One reason is that matching against two
choices (one with :tmp: and one without) is a fairly easy XPath
expression.  It's also easy to transition code from :tmp: to code
without :tmp: over time.  Adding in a number means that you now have
to use regular expressions in your XPath or have potentially three or
more possible choices.

Another reason is that we may end up with various incompatible
implementations instead of delaying implementation.  It's pretty easy
to make an argument that server XYZ should drop the :tmp: namespace in
the next major version once a draft has reached a certain point.  It's
a lot different to ask people to switch from version 2 to version 3.

Elsewhere in this thread someone stated that MIME is stuck at 1.0.
HTTP is at 1.1 and may never move.  In reality the standards don't
change so much that version numbers are needed in the URNs.

I'd like to see a clearer statement of the problem to solve rather
than so much debate over nuances of a proposed solution.  It seems
there is some hesitancy over implementing a protocol containing :tmp:
in the name.  There is also of course the problem if distinguishing
between versions of a particular protocol when it has gone through
some major revisions.

I don't know that there is a good solution for the latter problem.
All protocols experience this catch-22 at the start.  Implementations
are slow to move forward when the protocol changes enough to warrant
significant investment to retool code.  It's true that some protocols
use version numbers for this, but typically the amount of versions
being supported is either quite low, or care is taken such that each
version is merely a superset of an earlier version (ie, HTML, HTTP).
The other mechanism is to make new protocol or layer over one.  This
happened with TLS for example. In our own world, vcard avatars are an
example where the protocol got, not a new version, but a new name.

> When they pass a certain maturity level, they become "urn:xmpp:protoname".
> This is great, but we don't do this until they pass a maturity level which
> is often hard to judge without implementation experience.

There is another solution to the reluctance to implement which also
takes some of the ambiguity out of the time line here.  That is to
issue the canonical urn as soon as a XEP draft is accepted by the
council.  Why wait until it has reached some nebulous maturity level?
If we accept a XEP, immediately issue it a urn.  This is early enough
in the life cycle that it should not affect implementers, and urns are
infinite in number.  We need not worry about wasting them.  If we are
worried about name space collisions I suggest adopting a year into the
urn like so:

urn:xmpp:2008:microblogging

If that protocol became historic or was otherwise out of us, we could
issue urn:xmpp:2010:microblogging to whatever took over.  I'm not sure
we have so many XEPs that such a convention is needed.

Hopefully I'm not missing something.  As it stands, I'm not convinced
versioning URNs is warranted or helpful.

jack.

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Remko Tronçon]

> urn:xmpp:protoname:1

Sounds good to me.

cheers,
Remko

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Pavel Simerda]

I'm deligted you finally took my idea.

Pavel

On Tue, 23 Sep 2008 12:24:40 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:

> Kevin Smith wrote:
> > On Tue, Sep 9, 2008 at 4:36 PM, Dave Cridland <[EMAIL PROTECTED]>
> > wrote:
> >> urn:xmpp:protoname:1
> > 
> > Sane.
> 
> Kev and I just chatted about this via IM. So I take it that we'd start
> with urn:xmpp:protoname:0 and increment from there? I'm fine with
> that, and it does seem more sane than the :tmp: approach.
> 
> I'm working on Jingle right now, so I wonder about things like this:
> 
> urn:xmpp:tmp:jingle:apps:rtp
> 
> Which of the following does that become?
> 
> 1. urn:xmpp:jingle:0:apps:rtp
> 
> or:
> 
> 2. urn:xmpp:jingle:apps:rtp:0
> 
> I think I prefer the number at the end in all cases.
> 
> Shall we update all the Jingle namespaces along these lines? I'd be
> happy to do that during the current revision cycle. Speaking of which,
> back to work...
> 
> /psa
> 
> 
> 


-- 

Pavel Šimerda
Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Kevin Smith]

On Tue, Sep 23, 2008 at 7:24 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Kev and I just chatted about this via IM. So I take it that we'd start
> with urn:xmpp:protoname:0 and increment from there? I'm fine with that,
> and it does seem more sane than the :tmp: approach.
>
> 2. urn:xmpp:jingle:apps:rtp:0

This.

> I think I prefer the number at the end in all cases.

Yes.

> Shall we update all the Jingle namespaces along these lines? I'd be
> happy to do that during the current revision cycle. Speaking of which,
> back to work...

I don't see a reason not to start now. Especially if Jingle is
something we want to encourage adoption of :)

/K

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Peter Saint-Andre]

Kevin Smith wrote:
> On Tue, Sep 9, 2008 at 4:36 PM, Dave Cridland <[EMAIL PROTECTED]> wrote:
>> urn:xmpp:protoname:1
> 
> Sane.

Kev and I just chatted about this via IM. So I take it that we'd start
with urn:xmpp:protoname:0 and increment from there? I'm fine with that,
and it does seem more sane than the :tmp: approach.

I'm working on Jingle right now, so I wonder about things like this:

urn:xmpp:tmp:jingle:apps:rtp

Which of the following does that become?

1. urn:xmpp:jingle:0:apps:rtp

or:

2. urn:xmpp:jingle:apps:rtp:0

I think I prefer the number at the end in all cases.

Shall we update all the Jingle namespaces along these lines? I'd be
happy to do that during the current revision cycle. Speaking of which,
back to work...

/psa

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Peter Saint-Andre]

Dave Cridland wrote:

On Wed Sep 10 02:54:19 2008, Peter Saint-Andre wrote:

Dave Cridland wrote:

the advantage here is that if the protocol is stable earlier than its 
move to Draft - and actually, this is normally the case, a lot of the 
pre-draft stuff is specification wrangling rather than proptocol 
redesign - people can go ahead and implement it, and it'll continue 
to work.


Otherwise, as we get closer to Draft, we're actually putting people 
off implementation at the very moment we want to encourage it.


I think that's the key bit.

But how much are developers scared off by the need to support both 
urn:xmpp:tmp:foo and urn:xmpp:foo? It seems to me that's just a simple 
switch statement in your code.


No, it's not, because urn:xmpp:tmp:* is actually meaningless. These 
namespaces are used for documents in wild fluidity, and one 
implementation's urn:xmpp:tmp:foo may well be completely different from 
another's.


I see your point.

A specification might stay stable for months, if not years, with a :tmp: 
namespace, only to change later.


True. We try to avoid that, but it happens.

And in any case, if urn:xmpp:tmp:foo really is just a swich statement 
away from urn:xmpp:foo, then why bother with tmp at all?


Because we want to make it clear that until a XEP is Draft, it's not 
really official. It's merely a form of signalling, as far as I can see.


FWIW, I definitely prefer to have :tmp: instead of a 0-version, because 
it makes it clear that version changing is unusual, whereas  :tmp: 
really means "unknown namespace".


OK.

I'm not deeply objecting to the idea, just getting used to it...

Peter


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Pavel Simerda]

On Wed, 10 Sep 2008 15:29:53 +0100
Dave Cridland <[EMAIL PROTECTED]> wrote:

> On Wed Sep 10 02:54:19 2008, Peter Saint-Andre wrote:
> > Dave Cridland wrote:
> > 
> >> the advantage here is that if the protocol is stable earlier than  
> >> its move to Draft - and actually, this is normally the case, a
> >> lot of the pre-draft stuff is specification wrangling rather than  
> >> proptocol redesign - people can go ahead and implement it, and  
> >> it'll continue to work.
> >> 
> >> Otherwise, as we get closer to Draft, we're actually putting  
> >> people off implementation at the very moment we want to encourage  
> >> it.
> > 
> > I think that's the key bit.
> > 
> > But how much are developers scared off by the need to support both  
> > urn:xmpp:tmp:foo and urn:xmpp:foo? It seems to me that's just a  
> > simple switch statement in your code.
> 
> No, it's not, because urn:xmpp:tmp:* is actually meaningless. These  
> namespaces are used for documents in wild fluidity, and one  
> implementation's urn:xmpp:tmp:foo may well be completely different  
> from another's.
> 
> A specification might stay stable for months, if not years, with a  
> :tmp: namespace, only to change later.
> 
> And in any case, if urn:xmpp:tmp:foo really is just a swich
> statement away from urn:xmpp:foo, then why bother with tmp at all?
> 
> FWIW, I definitely prefer to have :tmp: instead of a 0-version,  
> because it makes it clear that version changing is unusual, whereas   
> :tmp: really means "unknown namespace".

After thinking it through, I agree with you. But then I think we should
push the 0-version (after :tmp:) when we expect wider implementation and
not :tmp:. This is much earlier than we do with non-:tmp: versions now.

Pavel

> 
> Dave.


-- 

Pavel __imerda
Freelancer v oblasti pota__ov__ch s__t__, komunikace a bezpe__nosti
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Pavel Simerda]

On Tue, 09 Sep 2008 19:54:19 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:

> Dave Cridland wrote:
> 
> > the advantage here is that if the protocol is 
> > stable earlier than its move to Draft - and actually, this is
> > normally the case, a lot of the pre-draft stuff is specification
> > wrangling rather than proptocol redesign - people can go ahead and
> > implement it, and it'll continue to work.
> > 
> > Otherwise, as we get closer to Draft, we're actually putting people
> > off implementation at the very moment we want to encourage it.
> 
> I think that's the key bit.
> 
> But how much are developers scared off by the need to support both 
> urn:xmpp:tmp:foo and urn:xmpp:foo? It seems to me that's just a
> simple switch statement in your code.
> 
> Also, it's not clear how we'd handle sub-namespaces:
> 
> urn:xmpp:foo:4:sub

This one looks better and more logical to me.

Pavel

> 
> or
> 
> urn:xmpp:foo:sub:4
> 
> ?
> 
> Peter
> 


-- 

Pavel Šimerda
Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Pavel Simerda]

I believe it both helps with the discipline (a little bit)
and helps to maintain graceful transitions in cases we fail.

Furthermore it simplifies (sometimes allows at all) maintaining
compatibility if used (very) carefully and with as little major
version transitions as possible.

Pavel

On Tue, 09 Sep 2008 19:51:26 -0600
Peter Saint-Andre <[EMAIL PROTECTED]> wrote:

> Pavel Simerda wrote:
> 
> > This would also affect the best practice in protocol changes and
> > versioning. I personally believe this would provide more help than
> > harm. For version 0, incompatible changes would by allright, for
> > higher versions it would be sensible to add new features as
> > optional (we still have discovery) and possibly, in the future,
> > they would be marked REQUIRED all at once with a major protocol
> > change.
> > 
> > I believe the incompatible changes for higher versions would be
> > rare.
> 
> That's what we strive for. Certainly once something is Final, and 
> usually when something is Draft. But I don't see exactly how the 
> namespace versioning helps us here -- what we need is more discipline 
> about standardization, not fancy namespacing. If the latter helps us
> be more disciplined, that's great. If not, it's just confusing. IMHO.
> 
> But I'm willing to be convinced otherwise. :)
> 
> /psa
> 
> 


-- 

Pavel Šimerda
Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Dave Cridland]

On Wed Sep 10 02:54:19 2008, Peter Saint-Andre wrote:

Dave Cridland wrote:

the advantage here is that if the protocol is stable earlier than  
its move to Draft - and actually, this is normally the case, a lot  
of the pre-draft stuff is specification wrangling rather than  
proptocol redesign - people can go ahead and implement it, and  
it'll continue to work.


Otherwise, as we get closer to Draft, we're actually putting  
people off implementation at the very moment we want to encourage  
it.


I think that's the key bit.

But how much are developers scared off by the need to support both  
urn:xmpp:tmp:foo and urn:xmpp:foo? It seems to me that's just a  
simple switch statement in your code.


No, it's not, because urn:xmpp:tmp:* is actually meaningless. These  
namespaces are used for documents in wild fluidity, and one  
implementation's urn:xmpp:tmp:foo may well be completely different  
from another's.


A specification might stay stable for months, if not years, with a  
:tmp: namespace, only to change later.


And in any case, if urn:xmpp:tmp:foo really is just a swich statement  
away from urn:xmpp:foo, then why bother with tmp at all?


FWIW, I definitely prefer to have :tmp: instead of a 0-version,  
because it makes it clear that version changing is unusual, whereas   
:tmp: really means "unknown namespace".


Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Peter Saint-Andre]

Dirk Meyer wrote:

Peter Saint-Andre wrote:

Dirk Meyer wrote:


it would be nice to have a list of implementations
that support a specific XEP. A second step would maybe some inter-op
testing. There are two at the summit, but I guess that is not enough.

For "major" XMPP technologies we've started documenting that:

http://xmpp.org/tech/

Much more work is required, however.


Very much work (Pubsub rocks is true but not very helpful). 


Well, yeah, those are stub pages, not yet live on the website for the 
general public. :)



Since the
is a Wiki page for all XEPs, maybe we could use it. Each client or
server can add itself as "I support this starting from version foo".

I see it is done with BOSH:
http://wiki.jabber.org/web/Bidirectional-streams_Over_Synchronous_HTTP_(BOSH)_(XEP-0124)


OT: I hate those long URLs.

The thing is, those pages are tied to a particular XEP. If you want to 
learn about Jingle, you need to go to 6 different wiki pages. Better, I 
think, to have one page about each major technology (however we define 
that) so people can understand the various building blocks. Now, maybe 
we'd also have a wiki page related to each XEP, but then I wonder how 
many developers would bother to visit each page and input the the fact 
that their library supports it. There are a lot of XEPs and therefore a 
lot of wiki pages. The only wiki page that has this kind of information 
right now is the XEP-0124 page, and that's only because I poked one of 
our GSoC students about moving some information from his blog to that page.


/psa





smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Dirk Meyer]

Peter Saint-Andre wrote:
> Dirk Meyer wrote:
>
>> it would be nice to have a list of implementations
>> that support a specific XEP. A second step would maybe some inter-op
>> testing. There are two at the summit, but I guess that is not enough.
>
> For "major" XMPP technologies we've started documenting that:
>
> http://xmpp.org/tech/
>
> Much more work is required, however.

Very much work (Pubsub rocks is true but not very helpful). Since the
is a Wiki page for all XEPs, maybe we could use it. Each client or
server can add itself as "I support this starting from version foo".

I see it is done with BOSH:
http://wiki.jabber.org/web/Bidirectional-streams_Over_Synchronous_HTTP_(BOSH)_(XEP-0124)


Dirk

-- 
Hard work never killed anyone, but why give it a chance?

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Peter Saint-Andre]

Dirk Meyer wrote:


it would be nice to have a list of implementations
that support a specific XEP. A second step would maybe some inter-op
testing. There are two at the summit, but I guess that is not enough.


For "major" XMPP technologies we've started documenting that:

http://xmpp.org/tech/

Much more work is required, however.

/psa



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Peter Saint-Andre]

Dave Cridland wrote:

the advantage here is that if the protocol is 
stable earlier than its move to Draft - and actually, this is normally 
the case, a lot of the pre-draft stuff is specification wrangling rather 
than proptocol redesign - people can go ahead and implement it, and 
it'll continue to work.


Otherwise, as we get closer to Draft, we're actually putting people off 
implementation at the very moment we want to encourage it.


I think that's the key bit.

But how much are developers scared off by the need to support both 
urn:xmpp:tmp:foo and urn:xmpp:foo? It seems to me that's just a simple 
switch statement in your code.


Also, it's not clear how we'd handle sub-namespaces:

urn:xmpp:foo:4:sub

or

urn:xmpp:foo:sub:4

?

Peter



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Peter Saint-Andre]

Pavel Simerda wrote:


This would also affect the best practice in protocol changes and
versioning. I personally believe this would provide more help than harm.
For version 0, incompatible changes would by allright, for higher
versions it would be sensible to add new features as optional (we
still have discovery) and possibly, in the future, they would be
marked REQUIRED all at once with a major protocol change.

I believe the incompatible changes for higher versions would be rare.


That's what we strive for. Certainly once something is Final, and 
usually when something is Draft. But I don't see exactly how the 
namespace versioning helps us here -- what we need is more discipline 
about standardization, not fancy namespacing. If the latter helps us be 
more disciplined, that's great. If not, it's just confusing. IMHO.


But I'm willing to be convinced otherwise. :)

/psa




smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Dave Cridland]

On Tue Sep  9 17:04:32 2008, Jehan wrote:
But there is a very interesting point also: currently a feature  
never
gives its version (as far as I can remember). You only have a  
version
for core XMPP (in the opening stream tag), but not for the  
additionnal

features inside the stream.


To make this useful, you'd need major/minor versioning - so 1.1  
implementations were safe talking to 1.5, but the 1.5 implementation  
would have to "talk down".


I did briefly contemplate suggesting this, before I realised that I'd  
never implement it in a million years, and the knock-on effect in  
terms of complexity of protocol design was so huge I'd never forgive  
myself.


So don't go there, really. :-)

FWIW, there is a version in XMPP like this, yes. There is also a  
version in MIME like this, which has remained at 1.0 for the past  
couple of decades, and similarly shows no intention of changing.


Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Pavel Simerda]

Hello,

historic reasons are IMO the main ones.

Dave's proposal is to avoid breaking already working
implementation. It's purely practical, not psycological.

The :tmp: proposal was a good start. But we see it was not good enough.
I suggest thinking and talking a bit before we agree on a new way.

Dave's reasons are good but the particualar schema could be still
improved.

Just to point out:

Some protocols further subdivide its URNs
 * urn:xmpp:tmp:[name]:[section]
 * urn:xmpp:[name]:[section]
where section may be a discovery feature PubSub namespace or whatever.
Replacing it by
 * urn:xmpp:[name]:[version]:[section]
(consistently with what Dave said)

If you use this style of versioning, I suggest to (if there are no
severe reasons against):

1) use the major versions of the XEPs as major versions are usually
intended for this sort of incompatible redesign. This would avoid
confusion with "just another revision number" and help maintain
backwards compatibility where necessary.
Examples:
 * urn:xmpp:pubsub:2
   (if PubSub reaches version 2.x, otherwise we'd better keep
   http://jabber.org/protocol/pubsub)
 * urn:xmpp:pubsub:2:errors
   (same but for http://jabber.org/protocol/pubsub#errors)

2) drop the 'tmp' and use major version 0.x instead (as it's already
done)
Examples:
 * urn:xmpp:search:0
 * urn:xmpp:search:0:users
 * urn:xmpp:search:0:servers

Note: This would also affect the best practice in protocol changes and
versioning. I personally believe this would provide more help than harm.
For version 0, incompatible changes would by allright, for higher
versions it would be sensible to add new features as optional (we
still have discovery) and possibly, in the future, they would be
marked REQUIRED all at once with a major protocol change.

I believe the incompatible changes for higher versions would be rare.

Pavel

On Tue, 9 Sep 2008 18:04:32 +0200
Jehan <[EMAIL PROTECTED]> wrote:

> 
> Hello,
> 
> this is interesting, but does it bring something else than just
> psychology (not to make people afraid... which is already a good
> point, for sure)?
> 
> I am not sure this is really necessary to force the maturity of a
> protocol if we have no way to really check it (which means: no real
> implementation).
> 
> But there is a very interesting point also: currently a feature never
> gives its version (as far as I can remember). You only have a version
> for core XMPP (in the opening stream tag), but not for the additionnal
> features inside the stream.
> 
> And I finish by a question for my personal knowledge, because I guess
> this has been discussed somewhere: why are the protocol namespaces (
> http://www.xmpp.org/registrar/namespaces.html ) in different forms,
> and especially the one in the form of an http url (for instance:
> "http://jabber.org/protocol/activity"; )? Is it just historic for older
> XEP? Or another reason?
> 
> Jehan
> 
> 


-- 

Pavel Šimerda
Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Dirk Meyer]

Hi,

first of all: sounds like a good idea. But reding this I got some
questions I had before:

Dave Cridland wrote:
> We currently create new protocols with a "urn:xmpp:tmp:protoname"
> namespace. This is useful to avoid collisions, as well as avoiding
> incompatible implementations in the wild.
>
> When they pass a certain maturity level, they become
> "urn:xmpp:protoname". This is great, but we don't do this until they
> pass a maturity level which is often hard to judge without
> implementation experience.

First question: what implementations are out there for a specific XEP?
IMHO that is important when coding stuff. Some code only requires
client to client communication, I can test that against my one
implementation at the beginning. But you wrote about XEP-0198 and that
is more complicated. IMHO it is a MUST HAVE extension and I will
implement it as soon as I can, but I have no server to test it
with. And the same is true for server developer: they have no
client. I guess this is one important reason why many XEPs have no
implementation: server developer see no need on client side and
clients have no server to test it with.

As a first step it would be nice to have a list of implementations
that support a specific XEP. A second step would maybe some inter-op
testing. There are two at the summit, but I guess that is not enough.


Dirk

-- 
With sufficient thrust, pigs fly just fine. However, this is not necessarily a
good idea. It is hard to be sure where they are going to land, and it could be
dangerous sitting under them as they fly overhead.
-- RFC 1925

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Jehan]

Hello,

this is interesting, but does it bring something else than just
psychology (not to make people afraid... which is already a good point,
for sure)?

I am not sure this is really necessary to force the maturity of a
protocol if we have no way to really check it (which means: no real
implementation).

But there is a very interesting point also: currently a feature never
gives its version (as far as I can remember). You only have a version
for core XMPP (in the opening stream tag), but not for the additionnal
features inside the stream.

And I finish by a question for my personal knowledge, because I guess
this has been discussed somewhere: why are the protocol namespaces (
http://www.xmpp.org/registrar/namespaces.html ) in different forms, and
especially the one in the form of an http url (for instance:
"http://jabber.org/protocol/activity"; )? Is it just historic for older
XEP? Or another reason?

Jehan


-- 
Jehan

Jehan's Profile: http://www.jabberforum.org/member.php?userid=16911
View this thread: http://www.jabberforum.org/showthread.php?t=738

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Alexey Melnikov]

Dave Cridland wrote:


urn:xmpp:protoname:1

That last portion we'll treat as a version number. Any time we cause  
incompatibility between versions of the XEP, we update it. (Note,  
that's not "every new XEP").


So by the time it moves out of Experimental and to Draft, it might be:

urn:xmpp:protoname:4

And there it stays - the advantage here is that if the protocol is  
stable earlier than its move to Draft - and actually, this is  
normally the case, a lot of the pre-draft stuff is specification  
wrangling rather than proptocol redesign - people can go ahead and  
implement it, and it'll continue to work.


Not surprisingly I like that, as Curtis and I were complaining to Dave 
about this before.

Re: [Standards] Namespaces, specifications, and protocol life cycles

[Kevin Smith]

On Tue, Sep 9, 2008 at 4:36 PM, Dave Cridland <[EMAIL PROTECTED]> wrote:
> urn:xmpp:protoname:1

Sane.

/K

[Standards] Namespaces, specifications, and protocol life cycles

[Dave Cridland]

We currently create new protocols with a "urn:xmpp:tmp:protoname"  
namespace. This is useful to avoid collisions, as well as avoiding  
incompatible implementations in the wild.


When they pass a certain maturity level, they become  
"urn:xmpp:protoname". This is great, but we don't do this until they  
pass a maturity level which is often hard to judge without  
implementation experience.


Moreover, sometimes a section of the community really wants to  
implement, but the wider community hasn't quite made up our  
collective minds yet. An example of this was XEP-0158, for instance,  
and was reminded again while looking through XEP-0198.


So, I'd like to propose we change this a bit:

urn:xmpp:tmp:protoname - we keep this for really early days, probably  
stuff that's either still protoXEP or in its first XEP incarnation.  
The authors can apply for a namespace from the XMPP Registrar (Peter,  
you get to talk to yourself again), who will grant it if he believes  
the specification to have obtained a reasonable degree of stability.


urn:xmpp:protoname:1

That last portion we'll treat as a version number. Any time we cause  
incompatibility between versions of the XEP, we update it. (Note,  
that's not "every new XEP").


So by the time it moves out of Experimental and to Draft, it might be:

urn:xmpp:protoname:4

And there it stays - the advantage here is that if the protocol is  
stable earlier than its move to Draft - and actually, this is  
normally the case, a lot of the pre-draft stuff is specification  
wrangling rather than proptocol redesign - people can go ahead and  
implement it, and it'll continue to work.


Otherwise, as we get closer to Draft, we're actually putting people  
off implementation at the very moment we want to encourage it.


Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade