W3C home > Mailing lists > Public > public-soap-jms@w3.org > July 2010

Moving forward on the JMS URI scheme

From: Eric Johnson <eric@tibco.com>
Date: Fri, 02 Jul 2010 15:13:03 -0700
Message-ID: <4C2E646F.6000004@tibco.com>
To: SOAP-JMS <public-soap-jms@w3.org>
In light of the recent responses to our proposed JMS URI scheme, the
question is, how do we move forward?

I see several options:
 * Provisional registration
 * Register a URN scheme, instead of a URI scheme.
 * Find an IETF working group that will take this work on.
 * Don't register
 * Other suggestions?

By the way, for anyone who is interested, up until 2003, the W3C made an
attempt to capture all unregistered URI schemes:
http://www.w3.org/Addressing/schemes

Details:
--------

** Provisional:  I don't really understand what this means, other than
that it isn't permanent, and can be revoked.  Someone needs to research it.

** URN scheme:  This will not dramatically affect what we've done,
except to add a "urn:" on the front of what we've got, plus whatever the
changes are for addressing the needs of URN registration

Looks like information on URNs is here:
http://tools.ietf.org/html/rfc3406

As per section 3.3 (http://tools.ietf.org/html/rfc3406#section-3.3), I
wonder if this really is any different:
"For example, a namespace may make use of a fee-based, privately
managed, or proprietary registry for assignment of URNs in the
namespace, but it may still provide benefit to some Internet users if
the services associated have openly-published access protocols."

Of course, JMS doesn't have an openly-published access protocol....

** Find an IETF working group: We did sort of try this previously, but
the folks with whom I exchanged emails did not readily identify a
natural fit for the set of existing IETF WGs and the JMS URI scheme.
Obviously, with a different set of people now aware of this, we might
fare better this time.

** Don' register: We can develop the specification for the "JMS" URI
scheme as part of the SOAP/JMS working group, or in the OASIS SCA
Bindings TC, and simply reference the darn thing as output from
whichever group.  There is one gotcha here, in that we will have to go
back to all contributors up to this point, and get their consent to move
the work to such a group.  Seeing as Oracle has been problematic in
responding to date, this may be challenging - except that if it happens
in the SCA Bindings TC at OASIS, then
Received on Friday, 2 July 2010 22:13:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:16:24 GMT