parallel namespace developments

["Greg FitzPatrick" <greg.fitzpatrick@xxxxxxxxxxxxx>]

I asked Graham Kline if he would like to add anything to our namespace
discussion based on his participation in other efforts.  He was kind enough
to write the following, which I believe is of interest to us all.



Greg, I've taken a quick look at a few messages on your list, but can't
really get any traction on the specific problem you're trying to solve.  So
rather than wade in, I'll refer you to some other work-in-progress.  Feel
free to post this, in part or in whole, to the CALSCH list if you think
it's relevant to your discussion.

I've just submitted an I-D for IMPP, developed with Derek Atkins, that
proposes a message format based on MIME but incorporating the XML
namespaces extension model.  The syntax may be too strict for some folks
taste -- I'm not fixated on that.  But in other ways, it shows how one can
take an extensibility model that seems to be working very well (in the XML
world) and apply it to a more traditional IETF style of protocol.

Basically, it allows anybody to create extensions to the base protocol by
associating those extensions with a globally unique URI.  The URI is quoted
just once, so it doesn't involve using URI syntax for the new protocol
elements themselves.  The advantage of URIs is that there are several ways
of creating unique identifiers, and they do form a universal namespace in
that any other namespace can be embedded in URI form.  I am working with
some others on a proposal for a URN namespace (a subset or URIs) that can
be used for IANA registered values.

Another aspect of this proposal is that it borrows from SIP a mechanism to
indicate whether or not an extension MUST be understood -- this is another
very important aspect of protocol extensibility:  some extensions can be
ignored if not understood, without harm;  others require that they must be
understood if the associated protocol elements are to be processed
correctly.

Look out for <draft-ietf-impp-cpim-msgfmt-00.txt>.

You might find it interesting to compare this with
<draft-klyne-message-rfc822-xml-01.txt>, which embeds much of RFC822
semantics in an XML message format.

#g

------------
Graham Klyne
(GK@xxxxxxx)