> 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.
