Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10

[Alexey Melnikov <[e-mail]>]

Hi Tim,
I am sorry I haven't replied to your message earlier (and didn't make 
sure that one of the editors do).

Tim Bray wrote:

>Dear IESG, sorry, got the wrong address for you first time around.
>This also went to: SM <[e-mail]>, Apps Discuss
><[e-mail]>, [e-mail], [e-mail],
>[e-mail], [e-mail], Alexey Melnikov
><[e-mail]>
>======================================================
>I have been selected as the Applications Area Review Team reviewer for
>this draft (for background on apps-review, please see
>http://www.apps.ietf.org/content/applications-area-review-team).
>Please resolve these comments along with any other Last Call comments
>you may receive. Please wait for direction from your document shepherd
>or AD before posting a new version of the draft.
>
>Document: draft-merrick-jms-uri-10
>Title: URI Scheme for Java(tm) Message Service 1.0
>Reviewer: Tim Bray
>Review Date: Dec 16, 2010
>Summary: The draft has some mechanical issues which are not
>show-stoppers. I have questions whether this ought to be an RFC since
>there seems very modest expectation of interoperability between
>implementations; why, then, an IETF RFC, which suggests that the
>resulting URIs should be useful for identification of resources on an
>internetworked scale.
>Major Issues:
>
>1. the draft suggests that given a “jms:” URI, there is little
>expectation that, without checking on the value of the “variant” and
>for the presence of vendor-specific parameters, it can be used
>interoperably in more than one implementation. In which case, I have
>to wonder about the appropriateness of using a *Uniform* resource
>identifier for whatever purposes are contemplated for these things; no
>motivations or use-cases are provided.
>The last paragraph of section 1 is troubling. For convenience, I quote:
><<<<<
>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.
>That context includes agreement on the same JMS provider or underlying
>protocol, agreement on how to look up endpoints (JNDI), and when using
>serialized Java object messages, sufficiently similar Java Class
>environments that serialized objects can be appropriately read and
>written. Users of this scheme need to establish the necessary shared
>context parts as just enumerated - 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.
>  
>
>Given this, what are the advantages of having a *Uniform* resource
>identifier, if there is not much expectation of uniformity in
>implementations?
>  
>
I have to say that I was a bit concerned about this text as well, but I 
liked editors honesty regarding the state of affairs.

Considering that this URI scheme is already in use (and referenced by 
other specs) and considering that it is a provisional registration, I 
think it is Ok. Personally, I would much prefer to register a URI scheme 
as provisional, then to reject the URI scheme registration and pretend 
that it doesn't exist. As other people already pointed out it is 
important to register URI schemes to at least avoid URI scheme name 
conflicts.

>2. Section 3.3 says “ If users plan switching between JMS vendors,
>they might also need to plan on regenerating resources that contain
>URIs in this vendor specific form”; this sharpens my concerns about
>the lack of interoperability...
>
>I’m getting the impression, reading this, that “jms:jndi” is probably
>quite interoperable,
>
I got the same impression.

>but the variants are maybe a back-door for vendor abuse.
>
It is possible. But personally, I prefer to provide some extensible 
framework to begin with than to let vendors extend URIs is completely 
unpredictable ways.

>Minor Issues:
>
>1. Section 1. Need references for terms like javax.jms.Destination for
>people who aren’t familiar with Java pathname voodoo.
>
>2. Section 4 para beginning “Each variant can have query
>parameters...” - did you consider separating the variant prefix from
>the rest of the parameter name with “.” or some other syntax marker? I
>note that you use “jndi-” for another class of parameter names below.
>
>3. Same paragraph. Should the variant be used as a prefix even if it’s
>a vendor-supplied one starting with “vnd.”? An example of this would
>be nice.
>
I think these 3 issues were addressed.

>4. 4.1.1 and so on, should the draft impose any constraints on the
>syntax of these parameter values? Perhaps they are inherited from the
>referenced sections in the JMS 1.1 spec? If so, please say so. Ah, I
>see that 4.1.3 does specify some syntax, albeit loosely; there are a
>lot of different syntaxes which may be used to specify “ number
>between 0 and 9, inclusive”. Are you OK with 0x3 or, for timeToLive,
>“1,500”?
>
I think this was at least partially addressed.

>5. 4.2.1 Perhaps a note prior to launching into all the parameters on
>syntax constraints, with, I’m assuming, normative references into the
>JMS spec?
>
Addressed.

>6. 4.2.2 includes great gobs of Java code illustrating how to use such
>an endpoint. Does this not contradict with the assertion at the top of
>section 4 which says “ Operations available on JMS destinations are
>fully and normatively defined by the JMS specification and as such,
>are out of scope for this URI specification”?
>
>In any case, 4.2.2 needs a bit of preparatory language explaining what
>it is. Is it normative behavior for implementations? Is it there for
>illustrative purposes? Is it required to use Java, or could I code
>something equivalent in C# or Ruby? A few paragraphs in there’s a
>passing reference to “the following (non-normative) code...”
>
>7. 4.3.1, see comments on 4.2.2 above. Is this description of
>programming practice normative, illustrative, or what?
>
I think the updated text is clearer on these 2 issues.

>8. Section 6, 3rd para: I haven’t ever seen anything like the note
>about what an OASIS TC might be doing in an RFC before, but possibly
>I’ve just missed the examples.
>
I think this point was addressed.

>9. Section 7, last para: “As described in Section 4, others can define
>additional variants”... there is no description in Section 4 of how to
>define additional variants.
>
Right, I've missed that.

>Also, while the language in the opening of
>the draft suggests that the set of variants is open-ended, this is the
>first explicit mention of this possibility that I encountered. Is
>there a registry?
>
>Oh, there it is in section 9.2. OK, I think that the beginning of the
>doc needs to say that the set of variants is open-ended and
>vendor-extensible. It also smells like a big huge honking
>interoperability hole.
>
I think it does now.

>Nits:
>
>1. Section 4 para 3, superfluous comma after “Both the variant”.
>
>2. Section 4 para beginning “Each variant can have query
>parameters...” - did you consider separating the variant prefix from
>the rest of the parameter name with “.” or some other syntax marker? I
>note that you use “jndi-” for another class of parameter names below.
>
>3. Section 4.1 I assume “shared” means “available in all variants”? If
>so, why not say so?
>
Fixed.

>4. Section 4.1 first para, the word “property” suddenly appears for
>the first time. Is this a synonym of “parameter”?
>
>5. Section 4.1.1 Lots of references here need to be turned into RFC
>style with square brackets
>
I think RFC Editor will take care of this.

>5. Same section, missing full stop after “following shared parameters”.
>
>6. 4.1.1 Probably more idiomatic of normative text to say, instead of
>“This MUST be”, “The value of this parameter MUST be...”
>
>7. 4.1.1 Missing full-stop at end.
>
>8. 6, 2nd para: What’s an “SPI”?
>
All of these were fixed as well.