[Standards-JIG] xmpp.org Namespaces

Dave Cridland dave at cridland.net
Fri Oct 13 08:51:02 UTC 2006

On Fri Oct 13 09:12:04 2006, Jacek Konieczny wrote:
> On Fri, Oct 13, 2006 at 09:54:08AM +0200, Olivier Goffart wrote:
> > Le vendredi 13 octobre 2006 00:01, Joe Hildebrand a écrit :
> > > They aren't URLs.  They are URIs.
> > > http://en.wikipedia.org/wiki/Uniform_Resource_Identifier
> > > I know that, read my mail again.
> > But an URI starting with http:// when it's not at all http is 
> wrong IMO
Well, it is a valid opinion. Just not one that's shared by everyone. 
I believe it's even detailed in that page.

> It is about identity and globally unique identifier assigned with 
> some
> identity. http:// URLs are automatically assigned to persons owning
> given URL space (controlling server under given domain and URL 
> path).
> That is very convenient for anyone that wants his own XML namespace
> -- I guess it is much easier for an average Joe to get his http://
> namespace (just get some HTTP hosting) than to get hist own URN 
> prefix
> (does URN work this way? I am not sure).

Yes, although webhosting agreements, and even domain name 
assignments, are not persistent, so it's not a perfect solution, 
whereas URN assignments are, I believe, persistent and also free. Not 
that I'm suggesting that everyone rushes out and gets a URN for their 
very own - but it makes some sense to consider having the JSF get one 
for XMPP namespaces, and assign from within it.

For anyone going to the IETF in a couple of weeks, it might be 
worthwhile finding out about URN assignments and registries from 
IANA, and discussing ways and means of accomplishing what we want 
with the IESG people.

There's even a reasonable chance we could make a switchover from http 
schemed URL namespaces to URN based ones, for the core protocol, 
although I might be clutching at straws, there, and besides, I'm not 
sure there's sufficient benefit to outweigh the cost.

>  And it won't make sense to
> assign URN for Joe if the XML namespace will be just temporary (e.g.
> some testing or prototyping).
This is certainly true. But http scheme URIs are spot on for that 
kind of work, being (by comparison) ephemeral. No prototyping work or 
experimentation is likely to outlive the website it's detailed on.

Of course, for that kind of work, an xmpp: scheme URI might be more 
than just a wild idea.

> For JSF things are simpler, of course. But http URIs may be still
> convenient. Just add the HTTP redirection from the namespace URIs 
> to the
> XEPs URLs and it will be trivial to find a documentation for a new 
> protocol. For URNs some additional registry will be required.
I think a registry is still needed for JSF-originated extensions - 
ie, XEPs and XMPP itself. I don't think you can precisely ignore 
that, although there is, as I said before, a certain amount of 
cuteness in encouraging any http scheme namespaces to point to, or 
redirect to, the definition of the namespace - and, of course, the 
act of doing so in effect creates its own registry of sorts - but a 
simple listing of namespaces is more useful.

And, indeed, the only one I tried works, to a degree: Look at 
http://jabber.org/protocol/activity for example. I'd be highly 
curious to know what sort of traffic that page (and others presumably 
like it) get.

In fact, you could go further, and use the fully qualified name of 
the element as a link to that element's definition.

It's all very cute, but I can't see any practical benefit sufficient 
to outweigh the administrative time this would use up. The people 
interested in the definition of the namespace and elements within it 
are, hopefully, capable of finding and looking through 
http://www.xmpp.org/registrar/namespaces.html - I did, without much 
effort, and I'm not exactly an XML genius.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list