Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10
Larry Masinter <masinter@adobe.com> Fri, 17 December 2010 17:45 UTC
Return-Path: <masinter@adobe.com>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B9F63A6975 for <apps-discuss@core3.amsl.com>; Fri, 17 Dec 2010 09:45:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.115
X-Spam-Level:
X-Spam-Status: No, score=-106.115 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u26vgl3laSOA for <apps-discuss@core3.amsl.com>; Fri, 17 Dec 2010 09:45:34 -0800 (PST)
Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by core3.amsl.com (Postfix) with ESMTP id 67CDD3A697A for <discuss@apps.ietf.org>; Fri, 17 Dec 2010 09:45:34 -0800 (PST)
Received: from source ([192.150.11.134]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKTQuiGfl8w2k3Yz4SR44skSBzc/lJkPwi@postini.com; Fri, 17 Dec 2010 09:47:22 PST
Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oBHHke3f009472; Fri, 17 Dec 2010 09:46:40 -0800 (PST)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id oBHHkxtm003352; Fri, 17 Dec 2010 09:46:59 -0800 (PST)
Received: from excas01.corp.adobe.com (10.8.188.201) by nacas03.corp.adobe.com (10.8.189.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 17 Dec 2010 09:46:59 -0800
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by excas01.corp.adobe.com ([10.8.188.201]) with mapi; Fri, 17 Dec 2010 09:46:59 -0800
From: Larry Masinter <masinter@adobe.com>
To: Tim Bray <tbray@textuality.com>, SM <sm+ietf@elandsys.com>, Apps Discuss <discuss@apps.ietf.org>, "m8philli@uk.ibm.com" <m8philli@uk.ibm.com>, "peaston@progress.com" <peaston@progress.com>, "derek.rokicki@softwareag.com" <derek.rokicki@softwareag.com>, "eric@tibco.com" <eric@tibco.com>, Alexey Melnikov <alexey.melnikov@isode.com>, The IESG <iesg-secretary@ietf.org>
Date: Fri, 17 Dec 2010 09:47:48 -0800
Thread-Topic: [apps-discuss] apps-team review of draft-merrick-jms-uri-10
Thread-Index: Acudfd5/7SCzBBNDTz+TU+YLUbd/mAAlFsjA
Message-ID: <C68CB012D9182D408CED7B884F441D4D04FAEE1E17@nambxv01a.corp.adobe.com>
References: <AANLkTimCZHmzaC+t2hGDkhcTmQgOe6k1aeG1q+FKVOAG@mail.gmail.com>
In-Reply-To: <AANLkTimCZHmzaC+t2hGDkhcTmQgOe6k1aeG1q+FKVOAG@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 17 Dec 2010 14:11:38 -0800
Subject: Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Dec 2010 17:45:36 -0000
I'm wondering if the process for review of registration material should include a provision for incorporation of reviewer comments (or a pointer to them) in the registry itself. Larry -- http://larry.masinter.net -----Original Message----- From: apps-discuss-bounces@ietf.org [mailto:apps-discuss-bounces@ietf.org] On Behalf Of Tim Bray Sent: Thursday, December 16, 2010 4:01 PM To: SM; Apps Discuss; m8philli@uk.ibm.com; peaston@progress.com; derek.rokicki@softwareag.com; eric@tibco.com; Alexey Melnikov; The IESG Subject: [apps-discuss] apps-team review of draft-merrick-jms-uri-10 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"? _______________________________________________ apps-discuss mailing list apps-discuss@ietf.org https://www.ietf.org/mailman/listinfo/apps-discuss
- Re: [apps-discuss] apps-team review of draft-merr… S Moonesamy
- [apps-discuss] apps-team review of draft-merrick-… Tim Bray
- Re: [apps-discuss] apps-team review of draft-merr… Larry Masinter
- Re: [apps-discuss] apps-team review of draft-merr… Alexey Melnikov
- Re: [apps-discuss] apps-team review of draft-merr… Eric Johnson
- Re: [apps-discuss] apps-team review of draft-merr… Tim Bray
- Re: [apps-discuss] apps-team review of draft-merr… Eric Johnson
- Re: [apps-discuss] apps-team review of draft-merr… Tim Bray