Return-Path: 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 AB36E3A69E1 for ; Tue, 24 Mar 2009 17:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 hGYRbzONpFZW for ; Tue, 24 Mar 2009 17:46:43 -0700 (PDT) Received: from mail-gx0-f208.google.com (mail-gx0-f208.google.com [209.85.217.208]) by core3.amsl.com (Postfix) with ESMTP id CC8973A6A31 for ; Tue, 24 Mar 2009 17:46:43 -0700 (PDT) Received: by gxk4 with SMTP id 4so7121548gxk.13 for ; Tue, 24 Mar 2009 17:47:35 -0700 (PDT) MIME-Version: 1.0 Sender: mark@coactus.com Received: by 10.150.189.9 with SMTP id m9mr16071790ybf.18.1237942055144; Tue, 24 Mar 2009 17:47:35 -0700 (PDT) In-Reply-To: <49C483AD.2000700@alvestrand.no> References: <498B7309.5080006@alvestrand.no> <49C43146.1070100@tibco.com> <49C483AD.2000700@alvestrand.no> Date: Tue, 24 Mar 2009 17:47:35 -0700 X-Google-Sender-Auth: e3f69200ef5d1b06 Message-ID: From: Mark Baker To: Harald Alvestrand Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: derek.rokicki@softwareag.com, apps-review@ietf.org, Lisa Dusseault , peaston@progress.com, Eric Johnson , roland@uk.ibm.com Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 00:46:44 -0000 On Fri, Mar 20, 2009 at 11:05 PM, Harald Alvestrand wrote: > Thanks - those words help. > The important point is that use of the URI depends on a shared context, and > that context cannot be identified from the URI. Indeed, there may be valid > cases where the same URI is resolvable in two different contexts, with two > different results. > > That leaves me sad, because it is exactly opposite to what the "U" in "URI" > sometimes stood for, Me too 8-( IMO this registration should be provisional, not permanent, because it doesn't meet the requirements of sec 2.1 of RFC 4395; The use and deployment of new URI schemes in the Internet infrastructure is costly; some parts of URI processing may be scheme-dependent, and deployed software already processes URIs of well-known schemes. Introducing a new URI scheme may require additional software, not only for client software and user agents but also in additional parts of the network infrastructure (gateways, proxies, caches) [11]. URI schemes constitute a single, global namespace; it is desirable to avoid contention over use of short, mnemonic scheme names. For these reasons, the unbounded registration of new schemes is harmful. New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes. Mark. Return-Path: 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 AB4AF3A6847 for ; Fri, 20 Mar 2009 23:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 WvVnxDd4L0bD for ; Fri, 20 Mar 2009 23:04:57 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by core3.amsl.com (Postfix) with ESMTP id 4C5423A63EC for ; Fri, 20 Mar 2009 23:04:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EABC839E25B; Sat, 21 Mar 2009 07:05:43 +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 GG2VxaiKYL1Z; Sat, 21 Mar 2009 07:05:39 +0100 (CET) Received: from [192.168.16.101] (unknown [12.233.205.2]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 78CCD39E0C1; Sat, 21 Mar 2009 07:05:37 +0100 (CET) Message-ID: <49C483AD.2000700@alvestrand.no> Date: Sat, 21 Mar 2009 07:05:33 +0100 From: Harald Alvestrand User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Eric Johnson References: <498B7309.5080006@alvestrand.no> <49C43146.1070100@tibco.com> In-Reply-To: <49C43146.1070100@tibco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: peaston@progress.com, Lisa Dusseault , derek.rokicki@softwareag.com, roland@uk.ibm.com, apps-review@ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 06:04:58 -0000 Eric Johnson wrote: > Hi Harald, > > Thank you for your feedback. Sorry for the long delay in responding to you. > > The SOAP/JMS working group at the W3C has a response to all but one of > your concerns, I think. Those responses are noted below. > > Harald Alvestrand wrote: > >> 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. >> >> > > The answer is slightly more subtle - JMS URIs can span the globe, but > that implies a shared context that also spans the globe. I'm thinking > that the following additional paragraph in the introduction might help > to clarify: > > 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. > Critical details affecting utility include agreement on the same JMS > provider or underlying protocol, agreement on the context for looking up > endpoints, and when using serialized Java object messages, sufficiently > similiar Java Class environments that the object can be appropriately > read and written. Uses of this scheme must establish the necessary > shared context - 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. > Thanks - those words help. The important point is that use of the URI depends on a shared context, and that context cannot be identified from the URI. Indeed, there may be valid cases where the same URI is resolvable in two different contexts, with two different results. That leaves me sad, because it is exactly opposite to what the "U" in "URI" sometimes stood for, but it's a valid specifier choice. The added paragraph indeed makes it clearer. > > >> 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?) >> >> > > I've been aware of this this point since we introduced the variants. I > see variants as so rare that this is essentially a moot issue. In > practice, I think there is at most one additional variant per vendor, > and the market pressures are such that there will not be many > implementations. > Is there a reason to claim a registry for variants? > > >> - 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? >> > > We're still discussing this in the working group. We've not settled on > an answer because I think there multiple tensions here, such as between > brevity and completeness, familiarity vs. convention, and so forth. > We'll hopefully have a more complete answer soon. > Good. > >> - 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. >> > > There's a trade-off here. We could move the entire section here up to > be a sub-section of #3. I think there's some value to having an top > level-"encoding considerations" section called out in the TOC, and I > don't see how we move that closer to the front. > One way would be to place in #3 a note saying "The URIs are percent-encoded UTF-8. See section 5 for encoding considerations". > > >> 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. >> > > Indeed! > > Thanks. > -Eric Johnson. > My pleasure. Good luck with getting the final details nailed! Return-Path: 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 16BE228C294 for ; Fri, 20 Mar 2009 17:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 B7ENln4l9YBy for ; Fri, 20 Mar 2009 17:13:11 -0700 (PDT) Received: from mx2.tibco.com (mx2.tibco.com [63.100.100.182]) by core3.amsl.com (Postfix) with ESMTP id 1D3F728C1C9 for ; Fri, 20 Mar 2009 17:13:11 -0700 (PDT) Received: from mx2.tibco.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 18B201F051F; Fri, 20 Mar 2009 17:13:58 -0700 (PDT) Received: from na-pa-fe01.na.tibco.com (tibco-5.tibco.com [63.100.100.5]) by mx2.tibco.com (Postfix) with ESMTP id 0308B1F051E; Fri, 20 Mar 2009 17:13:53 -0700 (PDT) Received: from [10.98.39.28] ([10.98.39.28]) by na-pa-fe01.na.tibco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Mar 2009 17:13:52 -0700 Message-ID: <49C43146.1070100@tibco.com> Date: Fri, 20 Mar 2009 17:13:58 -0700 From: Eric Johnson User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Harald Alvestrand References: <498B7309.5080006@alvestrand.no> In-Reply-To: <498B7309.5080006@alvestrand.no> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Mar 2009 00:13:52.0851 (UTC) FILETIME=[EAB47A30:01C9A9B9] X-Mailman-Approved-At: Sat, 21 Mar 2009 10:48:33 -0700 Cc: peaston@progress.com, Lisa Dusseault , derek.rokicki@softwareag.com, roland@uk.ibm.com, apps-review@ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2009 00:13:12 -0000 Hi Harald, Thank you for your feedback. Sorry for the long delay in responding to you. The SOAP/JMS working group at the W3C has a response to all but one of your concerns, I think. Those responses are noted below. Harald Alvestrand wrote: > 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. > The answer is slightly more subtle - JMS URIs can span the globe, but that implies a shared context that also spans the globe. I'm thinking that the following additional paragraph in the introduction might help to clarify: 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. Critical details affecting utility include agreement on the same JMS provider or underlying protocol, agreement on the context for looking up endpoints, and when using serialized Java object messages, sufficiently similiar Java Class environments that the object can be appropriately read and written. Uses of this scheme must establish the necessary shared context - 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. > 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?) > I've been aware of this this point since we introduced the variants. I see variants as so rare that this is essentially a moot issue. In practice, I think there is at most one additional variant per vendor, and the market pressures are such that there will not be many implementations. > - 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? We're still discussing this in the working group. We've not settled on an answer because I think there multiple tensions here, such as between brevity and completeness, familiarity vs. convention, and so forth. We'll hopefully have a more complete answer soon. > > - 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. There's a trade-off here. We could move the entire section here up to be a sub-section of #3. I think there's some value to having an top level-"encoding considerations" section called out in the TOC, and I don't see how we move that closer to the front. > > 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. Indeed! Thanks. -Eric Johnson.