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

 FYI:

-------- Original Message --------
Subject: 	[apps-discuss] APP Area Review of draft-merrick-jms-uri-09
Date: 	Sat, 25 Sep 2010 11:52:23 +1000
From: 	Mark Nottingham <mnot@mnot.net>
To: 	draft-merrick-jms-uri@tools.ietf.org
CC: 	IESG IESG <iesg@ietf.org>, apps-discuss@ietf.org



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.

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

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.

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.

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.

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. 

Regards,


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

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

Received on Monday, 27 September 2010 17:31:25 UTC