On Namespaces, Was: [Council] VOTE: JEP-0013 (POP3 Handling of Offline Messages)

David Waite mass at akuma.org
Thu Jan 17 23:08:19 CST 2002

----- Original Message -----
From: "Peter Saint-Andre" <stpeter at jabber.org>
To: <council at jabber.org>
> This JEP proposes the addition of two namespaces: 'jcs:offline:pop' for IQ
> gets and replies between the client and the server, and 'xdbid:uid' for
> the storage, retrieval, and removal of messages stored in XDB. Note that
> neither of these proposed namespaces begins with the 'jabber:' prefix. So
> assuming that this JEP is accepted as a draft protocol, it raises a
> question about the naming of standard namespaces. Because this JEP
> describes a working implementation that is supported both in a Jabber
> server (the commercial one maintained by Jabber Inc.) and in Jabber
> clients that are written to interact with that server, forcing a change to
> the proposed namespaces would introduce non-trivial migration issues. On
> the other hand, because the 'jabber:*' namespaces are reserved, a working
> implementation could not have been created using (in this instance) a
> namespace such as 'jabber:iq:offline:pop'. I see two solutions if this
> JEP is accepted:

New accepted namespaces should not be required to be prefixed by "jabber:" -
for example, XHTML.

XML Namespace usage in Jabber is odd because it has so much usage
information linked into each namespace. Most of the world uses XML for
representation of data, we use them as a way of specifying the format of a
specific request. As result, we usually have less reusability in our
namespaces, because they specify a way of accomplishing a very specific

It is partially because we use namespaces to differentiate protocols that
things within Jabber do not have version numbers. Much more often than not,
a new namespace is used to represent the new request or a specifically
different type of action. Some complicated problems, such as multi-user
chat, have had several different namespaces, each indicating a separate new
protocol. This is because the namespaces are very much intertwined with the
protocol - adding new capabilities hardly ever fit into the existing
namespace, and in many cases did not fit in with the existing protocol.

Because of this we have the original groupchat, "jabber:iq:gc",
"jabber:iq:groupchat", "jabber:iq:conference", "jabber:iq:conferencing", and
so on. There was no standards track, so people just started using these
names. Once this happened, they were stuck, as both deployed clients and
servers used them. I used "jabber:iq:conference" for my original JCF (Jabber
Conferencing Framework) draft for groupchat, but quickly found out that it
was not possible to use, as it conflicted with an existing protocol. There
were too many servers deployed which used this different protocol, such that
clients would not have any simple way to differentiate which server they
were speaking with. As result of this, I changed my working namespace to
"jcf-draft3", which has worked out quite well.

So to the point - I am not in favor at all for having 'jabber:*' namespaces
available to *anything* but JEPS approved by this council. This of course
excludes extensions which were documented before the existance of the
Foundation. There are only so many nouns that can be used to indicate a
particular concept, and reuse creates nothing but problems.

If someone is not interested in establishing a standard, they should not use
a jabber: namespace, ever. This includes informational JEPS where the
document just details an existing protocol.

If someone is interested in establishing something as a standard, they
should not come to us with a "jabber:" namespace. The best way of choosing a
namespace would be by a web URL to a document describing that namespace. The
next best would be a unique name or acronym.

In either case, the namespce should be chosen with two basic understandings:
1. that any published draft most likely will be implemented.
2. that any initial draft may be significantly changed before being

If there ever is a fourth draft of the JCF spec, it *will* be incompatible
with jcf-draft3 in at least three ways. There is a good chance that if there
was another draft between fourth and final, it would also be incompatible.
But by having a different namespace, both clients and implementations can
support both and remove support for one at their leasure.

So I propose the following rules:
1. Any JEP containing "jabber:" prefixed on a namespace will not be accepted
if the protocol was neither documented nor implemented before this date.
2. Any JEP proposed as informational (provided for compatibility and
documentation of services) can use whatever namespace they want, as long as
it does not begin with "jabber:".
3. Any JEP put on the standards track can use whatever namespace they want,
but should not rely on the final standard either having the same namespace
or being compatible with that specification.

-David Waite

More information about the Council mailing list