[APPS-REVIEW] Review of draft-merrick-jms-uri-05
Harald Alvestrand <harald@alvestrand.no> Thu, 05 February 2009 23:15 UTC
Return-Path: <harald@alvestrand.no>
X-Original-To: apps-review@core3.amsl.com
Delivered-To: apps-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154F23A688D for <apps-review@core3.amsl.com>; Thu, 5 Feb 2009 15:15:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.569
X-Spam-Level:
X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599]
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 3BQ9SRViTFbg for <apps-review@core3.amsl.com>; Thu, 5 Feb 2009 15:15:28 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id DA1263A6403 for <apps-review@ietf.org>; Thu, 5 Feb 2009 15:15:24 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2149839E40A; Fri, 6 Feb 2009 00:15:25 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fS1nah8PPxOZ; Fri, 6 Feb 2009 00:15:24 +0100 (CET)
Received: from [192.168.1.198] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 7649339E320; Fri, 6 Feb 2009 00:15:24 +0100 (CET)
Message-ID: <498B7309.5080006@alvestrand.no>
Date: Fri, 06 Feb 2009 00:15:21 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 2.0.0.19 (X11/20090105)
MIME-Version: 1.0
To: apps-review@ietf.org, Lisa Dusseault <lisa@osafoundation.org>, roland@uk.ibm.com, peaston@progress.com, derek.rokicki@softwareag.com, eric@tibco.com
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [APPS-REVIEW] Review of draft-merrick-jms-uri-05
X-BeenThere: apps-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Applications Review List <apps-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-review>
List-Post: <mailto:apps-review@ietf.org>
List-Help: <mailto:apps-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-review>, <mailto:apps-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Feb 2009 23:15:29 -0000
Document: draft-merrick-jms-uri-05 Reviewer: Harald Tveit Alvestrand Type of review: Apps area review Date: February 5, 2009 Summary: This document is strange, but just about ready. This specification is highly unusual in that it really doesn't document an URL for a protocol that can be resolved across the Internet - it documents a way to describe the parameters that one should send across a Java API. I think it a pity that the examples given give the impression that these mechanisms are strictly local in scope - a "jndi name" of REQ_QUEUE, and a "jndiURL" of file:/C:/JMSadmin both give the impression that these URLs won't ever be resolvable outside of a quite local context. I suspect that it is possible to construct JMS URLs that can be shared globally with an expectation of uniform interpretation - if such exist, it would be better for the document if they had been used in examples. On the other hand, if this possibility does not exist, the document should be very clear that these URIs are *not* possible to use in Internet interchange without a prenegotiated context for interpretation, and that they have no more global semantics than the "file:" URL scheme. Apart from that, the document seems to do its job of describing how to pick apart one of these URLs and push the pieces through a Java API. Some nits: - in section 4.1, some "shared" parameters are defined, but in section 4, it says that new variants can be defined, whose parameters should begin with the variant name as prefix (without specifying a separator character). Is there an expectation that there will never be a variant called "delivery", "time" or "priority"? If so, should this expectation be documented? (what about the "del" variant? possible or not?) - in section 4.2.1, it seems somewhat bizarre that the JNDI-specific parameters all start with "jndi", while section 4.2.1.4 states that additional JNDI-specific parameters should start wiht "jndi-" (note the additional dash). Why not be uniform? - the fact that the URI needs to be in UTF-8 only surfaces in section 5, long after the definition of the URI, and long after I'd started wondering about it. I think it would be better if this section was moved up after section 3, just after the URI syntax is defined. The security section seems reasonably comprehensive - if one wants additional review of this, it should be by someone who understands the JMS and JNDI security models and can tell how they relate to this scheme - this reviewer doesn't. Good luck!
- [APPS-REVIEW] Review of draft-merrick-jms-uri-05 Harald Alvestrand
- Re: [APPS-REVIEW] Review of draft-merrick-jms-uri… Harald Alvestrand
- Re: [APPS-REVIEW] Review of draft-merrick-jms-uri… Eric Johnson
- Re: [APPS-REVIEW] Review of draft-merrick-jms-uri… Mark Baker
- Re: [APPS-REVIEW] Review of draft-merrick-jms-uri… Eric Johnson
- Re: [APPS-REVIEW] Review of draft-merrick-jms-uri… Eric Johnson
- Re: [APPS-REVIEW] Review of draft-merrick-jms-uri… Harald Alvestrand
- Re: [APPS-REVIEW] Review of draft-merrick-jms-uri… Mark Baker
- Re: [APPS-REVIEW] Review of draft-merrick-jms-uri… Eric Johnson
- Re: [APPS-REVIEW] Review of draft-merrick-jms-uri… Mark Baker