Re: [Uri-review] draft-merrick-jms-uri-01.txt
Eric Johnson <eric@tibco.com> Fri, 29 February 2008 19:28 UTC
Return-Path: <uri-review-bounces@ietf.org>
X-Original-To: ietfarch-uri-review-archive@core3.amsl.com
Delivered-To: ietfarch-uri-review-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAF5B28C409; Fri, 29 Feb 2008 11:28:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.434
X-Spam-Level:
X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 Wwv-tWt0tUSV; Fri, 29 Feb 2008 11:28:53 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6FF128C184; Fri, 29 Feb 2008 11:28:53 -0800 (PST)
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6EBF3A6DB8 for <uri-review@core3.amsl.com>; Fri, 29 Feb 2008 11:28:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 ECc+VwUoxnv0 for <uri-review@core3.amsl.com>; Fri, 29 Feb 2008 11:28:51 -0800 (PST)
Received: from mx1.tibco.com (mx1.tibco.com [63.100.100.181]) by core3.amsl.com (Postfix) with ESMTP id C52713A68D4 for <uri-review@ietf.org>; Fri, 29 Feb 2008 11:28:51 -0800 (PST)
Received: from mx1.tibco.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5B30E4C5E5; Fri, 29 Feb 2008 11:28:40 -0800 (PST)
Received: from na-h-inhub1.tibco.com (unknown [10.106.128.33]) by mx1.tibco.com (Postfix) with ESMTP id 464934C428; Fri, 29 Feb 2008 11:28:38 -0800 (PST)
Received: from na-pa-fe01.na.tibco.com (na-pa-fe01.tibco.com [10.106.136.111]) by na-h-inhub1.tibco.com (8.13.6/8.13.6) with ESMTP id m1TJScUu029238; Fri, 29 Feb 2008 11:28:38 -0800 (PST)
Received: from [10.98.39.31] ([10.98.39.31]) by na-pa-fe01.na.tibco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Feb 2008 11:28:37 -0800
Message-ID: <47C85CF2.2020906@tibco.com>
Date: Fri, 29 Feb 2008 11:28:50 -0800
From: Eric Johnson <eric@tibco.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20071119)
MIME-Version: 1.0
To: Mark Baker <distobj@acm.org>
References: <47B5F1D7.10808@tibco.com> <e9dffd640802152100w700128b1o798ff432549799b8@mail.gmail.com> <47C4F47D.2080609@tibco.com> <e9dffd640802262207w3a29b6f6t598f2e5f2fda33dd@mail.gmail.com> <47C5068C.509@tibco.com> <e9dffd640802281038p37a4419cpf4bfd8fd74d46e1a@mail.gmail.com>
In-Reply-To: <e9dffd640802281038p37a4419cpf4bfd8fd74d46e1a@mail.gmail.com>
X-OriginalArrivalTime: 29 Feb 2008 19:28:37.0809 (UTC) FILETIME=[484E9210:01C87B09]
Cc: uri-review@ietf.org, SOAP over JMS <soapjms@progress.com>
Subject: Re: [Uri-review] draft-merrick-jms-uri-01.txt
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: uri-review-bounces@ietf.org
Errors-To: uri-review-bounces@ietf.org
Hi Mark, Mark Baker wrote: > Hi, > > On 2/27/08, Eric Johnson <eric@tibco.com> wrote: > >> I wonder if we're talking about the same kinds of operations though: >> would the JMS operations be ones that could be invoked remotely? >> Because that's what the registration template is asking for, e.g. HTTP >> GET for http:, FTP RETR for ftp:, etc... A quick look at the JMS >> Javadocs for ConnectionFactory and Destination doesn't reveal any >> application layer operations such as those AFAICT. >> >> I believe you're right, we do disagree on the "kind" of operations. In >> your response above, you indicate that you're expecting an "application" >> layer operation, but Section 2.4 doesn't actually use that qualification. >> > > Right. But it does ask what operations can be performed on the thing > identified by the URI. I don't think that leaves much room for > interpretation, whether or not you use the language "application layer > operation". > Hmmm. Now I cannot figure out whether there are *additional* terms we somehow don't agree on. In the email that lead to this thread, we suggested a further revision to our 01 revision of the JMS URI scheme that includes the following text - text which unfortunately been dropped in the email exchanges leading to this one: "The operations which can be performed on the ConnectionFactory and Destination resources are defined by the JMS specification and so a detailed description is outside the scope of this specification, but a JMS application typically uses a ConnectionFactory to create a connection to a messaging provider, and sends and receives messages to and from Destinations." There it is - the available operations defined. What am I missing? >> While section 2.4 proposes HTTP as a model for a URI that provides such >> operations, I don't read it as excluding other models. For a clear >> counterpoint, the current treatment of the "mailto" URI in RFC 2368 does not >> require the use of "SMTP", nor should it. I can think of uses where email >> gets sent with IMAP, a local sendmail agent, MAPI, or an HTTP web form (new >> in Firefox 3, I believe). The "send" operation, then, is clearly decoupled >> from the application layer. >> > > Avoiding "application layer" - sorry for muddying the waters with a > confusing term - yes, the send operation is the kind of operation > which should be documented with the registration. > Clearly it would be a mistake to inline the contents of a normative reference describing those references in detail, and the reference from the suggested text above is preferable, no? -Eric. _______________________________________________ Uri-review mailing list Uri-review@ietf.org https://www.ietf.org/mailman/listinfo/uri-review
- Re: [Uri-review] draft-merrick-jms-uri-01.txt Mark Baker
- Re: [Uri-review] draft-merrick-jms-uri-01.txt Eric Johnson
- Re: [Uri-review] draft-merrick-jms-uri-01.txt Mark Baker
- Re: [Uri-review] draft-merrick-jms-uri-01.txt Eric Johnson
- Re: [Uri-review] draft-merrick-jms-uri-01.txt Mark Baker
- Re: [Uri-review] draft-merrick-jms-uri-01.txt Eric Johnson
- Re: [Uri-review] draft-merrick-jms-uri-01.txt Mark Baker