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

[Tim Bray <[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?

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, but the variants are maybe a back-door for vendor
abuse.

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.

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”?

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?

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?

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.

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. 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.

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?

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

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”?