W3C home > Mailing lists > Public > public-soap-jms@w3.org > April 2009

Re: [APPS-REVIEW] Review of draft-merrick-jms-uri-05

From: Mark Baker <distobj@acm.org>
Date: Tue, 14 Apr 2009 10:51:31 -0400
Message-ID: <e9dffd640904140751w44941s98ee4afd708bdc8@mail.gmail.com>
To: "SOAP/JMS (list)" <public-soap-jms@w3.org>
Cc: Harald Alvestrand <harald@alvestrand.no>, Lisa Dusseault <lisa@osafoundation.org>, apps-review@ietf.org
On Mon, Apr 13, 2009 at 5:31 PM, Eric Johnson <eric@tibco.com> wrote:
> As I pointed out in the email to Harald (are you on that mailing list?),
> the jms URI, as spec'd, could be global in scope.  For example, the
> jndiURL parameter could point to a remote, globally accessible JNDI host.

But AIUI, even that doesn't provide sufficient context to permit a
third party to exchange information with the service, right?

Anyhow, even if I'm mistaken about that, the important point is that
this property isn't intrinsic to the scheme.

> As a few simple counterpoints, the "file", "opaquelocktoken", "cid", and
> "mid" URI schemes has a similarly local interpretation, but a global use.

I don't see those as analogous.  file URIs (even those without host
parts) aren't interpreted locally, they're just resolved locally.
Their interpretation is global.  For example, "file:///etc/passwd"
globally identifies the local /etc/passwd file, but of course,
dereferences to a different file depending upon where it was resolved.

For jms URI, only when a producer and consumer share the same context
is an interpretation consistent.  It's somewhat akin to defining a
file-like scheme that used "foo:///asdfasdfas" to identify the local
/etc/group file, where the knowledge of that mapping wasn't part of
the scheme definition, or otherwise obtainable by any potential
consumer of that URI.

Mark.
Received on Tuesday, 14 April 2009 14:52:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:16:20 GMT