Re: [APPS-REVIEW] Review of draft-merrick-jms-uri-05

[Eric Johnson <[e-mail]>]

Hi Mark,

Thanks again for your additional feedback.

Mark Baker wrote:
> On Fri, Mar 20, 2009 at 11:05 PM, Harald Alvestrand
> <[e-mail]> wrote:
>> Thanks - those words help.
>> The important point is that use of the URI depends on a shared context, and
>> that context cannot be identified from the URI. Indeed, there may be valid
>> cases where the same URI is resolvable in two different contexts, with two
>> different results.
>>
>> That leaves me sad, because it is exactly opposite to what the "U" in "URI"
>> sometimes stood for,
> 
> Me too 8-(

As I pointed out in the email to Harald (are you on that mailing list?),
the jms URI, as spec'd, could be global in scope.  For example, the
jndiURL parameter could point to a remote, globally accessible JNDI host.

It is certainly hard for us to know whether this current situation is an
accident of the historical adoption of JMS, or whether it generally
isn't useful on the internet global scope.

Certainly, one of the reasons we're putting this proposal forward is to
facilitate the adoption of SOAP over JMS.  This seems relevant to me,
because we currently have an enormous amount of code and effort going
into handling SOAP messages over HTTP in a reliable and secure fashion.
 With JMS, you get these characteristics (almost) without having to
define additional layers of specification to handle reliability and
encryption at the payload layer.

Given an available standard for SOAP over JMS, could that drive a more
global use for JMS itself?  Hard to say.

As a few simple counterpoints, the "file", "opaquelocktoken", "cid", and
"mid" URI schemes has a similarly local interpretation, but a global use.

Question: How is the proposed "jms" scheme different in character from
the above?

> 
> IMO this registration should be provisional, not permanent, because it
> doesn't meet the requirements of sec 2.1 of RFC 4395;

That could be an interesting option.  I have to say, I poked around for
a while, and was not able formulate any clear understanding of what a
"provisional" registration meant, other than that one "should" adhere to
the requirements for a URI that one normally "must" adhere to.  It
doesn't look like it is used much, given the vast difference between:

http://esw.w3.org/topic/UriSchemes/
http://en.wikipedia.org/wiki/URI_scheme#Unofficial_but_common_URI_schemes

and the provisional list at

http://www.iana.org/assignments/uri-schemes.html


> 
>    The use and deployment of new URI schemes in the Internet
>    infrastructure is costly; some parts of URI processing may be
>    scheme-dependent, and deployed software already processes URIs of
>    well-known schemes.  Introducing a new URI scheme may require
>    additional software, not only for client software and user agents but
>    also in additional parts of the network infrastructure (gateways,
>    proxies, caches) [11].  URI schemes constitute a single, global
>    namespace; it is desirable to avoid contention over use of short,
>    mnemonic scheme names.  For these reasons, the unbounded registration
>    of new schemes is harmful.  New URI schemes SHOULD have clear utility
>    to the broad Internet community, beyond that available with already
>    registered URI schemes.

What criteria, here, exactly, do you think we're missing?  I don't know
of any contention over the use of the "jms" scheme.  JMS software is
widely deployed, but obviously cannot take advantage of a JMS URI scheme
without one being defined.  As for clear utility, I'm aware of /two/
specifications that are already using the "jms" scheme as proposed, and
would like to see it completed.

-Eric.