Re: [apps-discuss] APP Area Review of draft-merrick-jms-uri-09

 Hi Mark,

Thanks for your feedback.  I'm looking to incorporate your changes, and
have a few questions.

On 09/24/2010 06:52 PM, Mark Nottingham wrote:
> Hello,
>
> 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-09
> Reviewer: Mark Nottingham
> Review Date: 2010-09-25
>
> Summary: This draft is not ready for publication as an Informational RFC and should be revised before publication.
>
> Major Issues: 
>
> 1. Section 3: The proposed syntax reuses "path-rootless" from RFC3986. However, it does not match the "absolute-URI" production from the same RFC, because of the introduction of the extra "jms-variant" rule. This means that URI parsing implementations may not be able to recognise the hierarchical components and expose them meaningfully, and is in conflict section 2.2 of RFC4395. That specification requires that such issues be documented in provisional registrations.

Point of confusion - the JMS URI scheme does not have any hierarchical
parts, so there is no way to extract them and expose them meaningfully. 
It is more like a URN in this regard.

So far as I can tell, the syntax does match up:

(3986): absolute-URI  = scheme ":" hier-part [ "?" query ]
(jms) jms-uri = "jms:" jms-variant ":" jms-dest [ "?" param *( "&" param ) ]

<"jms"> corresponds to <"scheme">.  The question the is whether
<hier-part> matches <jms-variant ":" jms-dest>.

Of the four options for <hier-part>, we've chosen "path-rootless" to match:

(3986): path-rootless = segment-nz *( "/" segment )
(jms) .... = jms-variant ":" jms-dest
(jms) jms-variant = segment-nz-nc
(jms) jms-dest = path-rootless

If <path-rootless> is taken without any "/" segments, then this seems to
patch the production.

Did I miss something?  Perhaps if we change the <jms-dest> production to
"segment-nz", will that address your concern?

> 2. The proposed URI scheme does allow resources to be located, but does not define a protocol to do so; rather it defines it in terms of an API (JMS). Thus, there is no wire-level protocol that can be used to build an interoperable implementation; rather, one needs to rely on a vendor's mapping of the API to a wire-level protocol (an issue which Section 1 attempts to address). 

Strictly speaking, this is true.  Unfortunately, it is utterly out of
our control to actually address this situation, yet we find ourselves
with the need to put something like the "jms" URI in WSDL & SCA
documents in places that take HTTP URLs in other use cases.

Also, some vendors have defined mappings to well known (AMQP) or
publicly available protocols [1], so to us, saying there is "no
wire-level protocol" for interoperability seems like a generalization,
or it depends on your definition of interoperability.  I guess I tend to
look at the "interoperability" question at two different levels - is the
protocol mapping properly documented - in which case interoperability is
possible - and at the second level, has the mapping been standardized
via a standards development organization.  Clearly, we don't have the
latter, but we do have the former, at least for some implementations.

Also, to cast ourselves in a slightly more favorable light, 99% of the
uses of HTTP employ a library that does the real work, and there are
only a relatively small collection of those libraries in the world,
compared to the number of applications that use HTTP.  People who
*don't* use those libraries tend to be quite vulnerable to security
risks....

This doesn't excuse the lack of a standardized protocol for JMS, but as
I mentioned, that situation is out of our control.

Is there additional text, or even an outline of key points that would
clarify the answer to the concerns you raise here?

> It doesn't necessarily follow that the registration is invalid as a result, but allowing a URI scheme to specify an API rather than a protocol for purposes of interoperability is counter to widely-held beliefs in the IETF, and arguably also conflicts with the spirit of the Architecture of the World Wide Web <http://www.w3.org/TR/webarch/#dereference-uri>. Besides effectively limiting the use of this URI scheme to one language (Java), it also means that interoperability will be difficult to achieve between implementations.

As to conflicting with the "Architecture of the World Wide Web", I agree
that it doesn't fit there.  In a sense, this question can devolve in an
endless discussion on the merits of REST vs. SOAP.  The JMS URI
identifies a communication endpoint resource, not a document resource. 
In that sense, it is much like a "mailto:" URI or a "tel" URI -
dereferencing those will be just as meaningless.

Many JMS implementations do have clients in other languages, so use of
this URI is not restricted to a single language.

Many JMS clients write to the JMS API, and can transfer between
implementations without difficulty, so in that sense, the marketplace
has already provided interoperability.  The authors of this
specification are working on defining a mapping of SOAP over JMS, and in
doing so, we are relying on the fact that it will be possible to switch
out the underlying JMS implementation as our customers wish.

Again, the question - is there specific text, or key points we should
touch on that you think we should add?

> While it may be appropriate to register widely-used schemes in order to document current use, but that doesn't appear to be the case here (as evident in the abstract). As such, the document should more prominently warn about interoperability issues inherent in this approach.

JMS schemes are in current use.  Here we are attempting to address the
shortcomings of all those existing approaches.  I don't know exactly how
to define "widely-used", so I won't argue for or against that, but I do
note that (as the draft itself notes) there are two standards efforts
currently underway that use the draft form of the JMS URI scheme we've
defined.

The last paragraph of the introduction isn't warning enough?  What more
do you have in mind?

> 3. It's not clear whether this registration reflects the position of all potential users. In particular, the specification of JMS and associated APIs is maintained by the Java Community Process <http://jcp.org/>, but this request does not state what its relation to the JCP is. An informal liaison might clarify this issue.

So far as we can tell, there is no ongoing work in the JCP for JMS. 
We've not been successful in finding ways to contact those people
involved in the original creation of the specifications.

I have thought of contacting all the obviously known implementations of
JMS [2] to directly solicit their input, at least where we haven't heard
from us already.  Would that ameliorate this concern?

> Minor Issues: 
>
> 1. The proposed scheme specifies an extensibility point, "jms-variant", but does not specify a registry or other means of disambiguating variants and avoiding collisions. 

We see very little chance of any registration of jms-variants.  What
would it mean to specify a registry?  What's the infrastructure to do
that?  How hard is it to register?

-Eric

> Regards,
>
>
> --
> Mark Nottingham     http://www.mnot.net/

[1] http://activemq.apache.org/openwire.html
[2]
http://en.wikipedia.org/wiki/Java_Message_Service#Provider_implementations

> _______________________________________________
> apps-discuss mailing list
> apps-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss

Received on Tuesday, 5 October 2010 22:46:23 UTC