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

Hi Eric,

Responses inline.

On 05/10/2010, at 3:46 PM, Eric Johnson wrote:

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

Yes.


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

At the risk of having a tangental discussion, I think you're wrong here.


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

See below.


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

No; there is a specific concern here that, historically, the IETF has achieved interoperability on the wire by defining protocols. My purpose in pointing this out was to make sure that the community was aware of this aspect of the proposed registration when evaluating the draft.


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

It would be helpful if there were a paragraph inserted in the Introduction, before the last paragraph there:

While the "jms" URI scheme allows the location of network resources, it does not map to a single underlying protocol, unlike most other URI schemes that do so. Instead, it achieves interoperability through use of a common Java API for messaging. Because of this, interoperability is dependent upon the implementation of the API and its capabilities; two implementations of JMS may or may not interoperate in practice. Furthermore, it may be impractical to use "jms" URIs in non-Java environments.


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

The text above would achieve this.


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

I was thinking that the IETF (e.g., the responsible AD) should ping the JCP to assure they're at least aware of this effort, and to give them an opportunity to comment. I appreciate you've done your best to gather consensus on this; it's just good form for the IETF to ask.


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

Normally, IANA is used for IETF registries; see RFC 5226.


One additional comment - it sounds like your use cases for these URIs might need some scheme-specific comparison / canonicalisation guidelines. If so, it would be appropriate to include those in the draft.


Cheers,

--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 6 October 2010 19:58:23 UTC