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

From: Eric Johnson <[email-masked]>
Date: Mon, 13 Apr 2009 12:02:02 -0700

Hi Harald,

Further responses, inline below.

Harald Alvestrand wrote:
> Eric Johnson wrote:
>> Hi Harald,
>>
>> Thank you for your feedback.  Sorry for the long delay in responding
>> to you.
>>
>> The SOAP/JMS working group at the W3C has a response to all but one of
>> your concerns, I think.  Those responses are noted below.
>>
>> Harald Alvestrand wrote:
>>  
>>> Document: draft-merrick-jms-uri-05
>>> Reviewer: Harald Tveit Alvestrand
>>> Type of review: Apps area review
>>> Date: February 5, 2009
>>>

[snip]

>>>
>>> I think it a pity that the examples given give the impression that these
>>> mechanisms are strictly local in scope - a "jndi name" of REQ_QUEUE, and
>>> a "jndiURL" of file:/C:/JMSadmin both give the impression that these
>>> URLs won't ever be resolvable outside of a quite local context.
>>> I suspect that it is possible to construct JMS URLs that can be shared
>>> globally with an expectation of uniform interpretation - if such exist,
>>> it would be better for the document if they had been used in examples.
>>>
>>>     
>>
>> The answer is slightly more subtle - JMS URIs can span the globe, but
>> that implies a shared context that also spans the globe.  I'm thinking
>> that the following additional paragraph in the introduction might help
>> to clarify:
>>
>> As a consequence of building upon an API, rather than a protocol, the
>> utility of a "jms" URI depends on the context in which it is used.
>> Critical details affecting utility include agreement on the same JMS
>> provider or underlying protocol, agreement on the context for looking up
>> endpoints, and when using serialized Java object messages, sufficiently
>> similiar Java Class environments that the object can be appropriately
>> read and written.  Uses of this scheme must establish the necessary
>> shared context - a context which can span the globe, or merely a small
>> local network.  With that shared context, this URI scheme enables
>> endpoint identification in a uniform way, and the means to connect to
>> those endpoints.
>>   
> 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, but it's a valid specifier choice. The added
> paragraph indeed makes it clearer.

It is possible, with the current definition, to have a jms URI that
points to its JNDI server somewhere "out there."  So all is not lost.
It just seems like an unlikely case, given how JMS is currently deployed.

>>>
>>> - in section 4.1, some "shared" parameters are defined, but in section
>>> 4, it says that new variants can be defined, whose parameters should
>>> begin with the variant name as prefix (without specifying a separator
>>> character). Is there an expectation that there will never be a variant
>>> called "delivery", "time" or "priority"? If so, should this expectation
>>> be documented? (what about the "del" variant? possible or not?)
>>>
>>>     
>>
>> I've been aware of this this point since we introduced the variants.  I
>> see variants as so rare that this is essentially a moot issue.  In
>> practice, I think there is at most one additional variant per vendor,
>> and the market pressures are such that there will not be many
>> implementations.
>>   
> Is there a reason to claim a registry for variants?
>>
>>  
>>> - in section 4.2.1, it seems somewhat bizarre that the JNDI-specific
>>> parameters all start with "jndi", while section 4.2.1.4 states that
>>> additional JNDI-specific parameters should start wiht "jndi-" (note the
>>> additional dash). Why not be uniform?
>>>     
>>
>> We're still discussing this in the working group.  We've not settled on
>> an answer because I think there multiple tensions here, such as between
>> brevity and completeness, familiarity vs. convention, and so forth.
>> We'll hopefully have a more complete answer soon.
>>   
> Good.

Here's the break-down.  There are actually three classes of properties
being specified in the parameters:
 1. Standard properties for identifying JNDI
    * jndiInitialContextFactory
    * jndiURL
 2. Custom properties for connecting to JNDI - need to spell out the
runtime name for these parameters.
    * Parameters we currently suggest start with "jndi-"
 3. JDNI Resources to retrieve once connected\
    * jndiConnectionFactoryName

We use the hyphen in case #2 to flag that what follows the hyphen is an
actual string value for the name of a property to set when constructing
the Map for the initial context.  We discussed always using the actual
Java constants even for case #1, but that would mean that instead of
specifying "jndiURL", we'd have to specify:

 * jndi-java.naming.provider.url (jndiURL)
 * jndi-java.naming.factory.initial (jndiInitialContextFactory)

In this case, we think convention, brevity, and clarity trumps
consistency, in that most JMS developers think of the "jndiURL" instead
of the "java.naming.provider.url"

That does, however, leave the question open - what should we do about
the "jndi-" case, where the URI needs to contain the actual name of the
property to use?  We had chosen the "jndi-" prefix over an alternate
prefix of "jndiContextParameter-", because we thought that we didn't
lose much in the brevity.

Now that we observe that we apparently did lose something in the
brevity.  In our first encounter outside our working group we got the
equivalent of a "huh?" from you. To remedy, we propose switching back to
the more verbose prefix of "jndiContextParameter-".

Do you think switching prefixes allays your concerns?

>>  
>>> - the fact that the URI needs to be in UTF-8 only surfaces in section 5,
>>> long after the definition of the URI, and long after I'd started
>>> wondering about it. I think it would be better if this section was moved
>>> up  after section 3, just after the URI syntax is defined.
>>>     
>>
>> There's a trade-off here.  We could move the entire section here up to
>> be a sub-section of #3.  I think there's some value to having an top
>> level-"encoding considerations" section called out in the TOC, and I
>> don't see how we move that closer to the front.
>>   
> One way would be to place in #3 a note saying "The URIs are
> percent-encoded UTF-8. See section 5 for encoding considerations".

Excellent.  I'll keep this in mind for the next small round of edits.

Thanks again for your time.

-Eric Johnson.

---

From: Eric Johnson <[email-masked]>
Date: Mon, 13 Apr 2009 14:31:17 -0700

Hi Mark,

Thanks again for your additional feedback.

Mark Baker wrote:
> On Fri, Mar 20, 2009 at 11:05 PM, Harald Alvestrand
> <[email-masked]> wrote:
>> 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.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 Apr 2009 10:04:29 +0200

Just commenting on comparable schemes....

> "mid" URI schemes has a similarly local interpretation, but a global use.
"cid" and "mid" are defined to be globally unique. They don't have a 
resolution mechanism, but by definition, they are globally unique.

"opaquelocktoken" is based on an UUID (another globally unique item 
without a lookup mechanism), and its definition says:

   An opaquelocktoken URI is constructed by concatenating the
   'opaquelocktoken' scheme with a UUID, along with an optional
   extension.  Servers can create new UUIDs for each new lock token.  If
   a server wishes to reuse UUIDs, the server MUST add an extension, and
   the algorithm generating the extension MUST guarantee that the same
   extension will never be used twice with the associated UUID.

I won't attemt to defend "file".

---

From: Mark Baker <[email-masked]>
Date: Tue, 14 Apr 2009 10:51:31 -0400

> jndiURL parameter could point to a remote, globally accessible JNDI host.

But AIUI, even that doesn't provide sufficient context to permit a
third party to exchange information with the service, right?

Anyhow, even if I'm mistaken about that, the important point is that
this property isn't intrinsic to the scheme.

> "mid" URI schemes has a similarly local interpretation, but a global use.

I don't see those as analogous.  file URIs (even those without host
parts) aren't interpreted locally, they're just resolved locally.
Their interpretation is global.  For example, "file:///etc/passwd"
globally identifies the local /etc/passwd file, but of course,
dereferences to a different file depending upon where it was resolved.

For jms URI, only when a producer and consumer share the same context
is an interpretation consistent.  It's somewhat akin to defining a
file-like scheme that used "foo:///asdfasdfas" to identify the local
/etc/group file, where the knowledge of that mapping wasn't part of
the scheme definition, or otherwise obtainable by any potential
consumer of that URI.

Mark.