Subject: [Uri-review] draft-merrick-jms-uri-01.txt

From: Eric Johnson <[email-masked]>
Date: Fri, 15 Feb 2008 12:11:03 -0800

To whom it may concern,

Based on previous feedback from the [email-masked] mailing list, 
our group has gone back and made improvements based on the suggestions 
we received.

Our new submission is here: 
http://www.ietf.org/internet-drafts/draft-merrick-jms-uri-01.txt

Thanks for any additional feedback you might provide.

Sincerely,
Eric Johnson.
_______________________________________________
Uri-review mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/uri-review

---

From: "Mark Baker" <[email-masked]>
Date: Sat, 16 Feb 2008 00:00:20 -0500

> Thanks for any additional feedback you might provide.

Eric, I'm not understanding how your section 4 relates to the
description in sec 2.4 of RFC 4395.  The semantics of the scheme refer
to what a recipient of a URI can expect to be able to do with it.  For
example, with an http URI one can GET a representation of the resource
identified by the URI.  What can I do with a jms URI if a would-be
business partner sends me one in an email?

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
_______________________________________________
Uri-review mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/uri-review

---

From: Eric Johnson <[email-masked]>
Date: Tue, 26 Feb 2008 21:26:21 -0800

Hi Mark, (and others,)

> business partner sends me one in an email?
Thanks for your feedback.

After discussing among ourselves, we've got a proposal for better text 
at the beginning of the document that we think addresses this concern.

Specifically, in the introduction, change this:

"The "jms" URI scheme is used to designate a javax.jms.Destination 
object and an associated javax.jms.ConnectionFactory object, and 
optionally provide additional information concerning the way that the 
Destination object is to be used. Probably the most common, ..."

To this:

"The "jms" URI scheme is used to designate a javax.jms.ConnectionFactory 
object and associated javax.jms.Destination objects, and optionally 
provides additional information concerning the way that the Destination 
objects are to be used.  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.

"Probably the most common, ..."

Comments?

-Eric.

---

From: "Mark Baker" <[email-masked]>
Date: Wed, 27 Feb 2008 01:07:07 -0500

Hi Eric,

On 2/27/08, Eric Johnson <[email-masked]> wrote:
>  specification,

You don't get off the hook that easily 8-)  The registration requires
documentation of the operations.

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.

Mark.
-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com
_______________________________________________
Uri-review mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uri-review

---

From: Eric Johnson <[email-masked]>
Date: Tue, 26 Feb 2008 22:43:24 -0800

Hi Mark,

Mark Baker wrote:

Hi Eric,

To this:

???

Section 2.4 of RFC 4395 says that we *should* provide documentation of
the operations, not that we must.  However, I think that is a
distraction from the core concern, since we do document the operations
by reference.

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.  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.  On the "operation" front, our JMS proposal seems to
be in good company.

-Eric Johnson

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 28 Feb 2008 13:38:46 -0500

Hi,

On 2/27/08, Eric Johnson <[email-masked]> wrote:
> 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".

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

>  On the "operation" front, our JMS proposal
> seems to be in good company.

Do you mean that jms URIs all identify resources to which one can send
data, ala email?  If so, then that's what you should document.

Mark.

---

From: Eric Johnson <[email-masked]>
Date: Fri, 29 Feb 2008 11:28:50 -0800

Hi Mark,

> interpretation, whether or not you use the language "application layer
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?
> 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.