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

[Mark Baker <[e-mail]>]

On Mon, Apr 13, 2009 at 5:31 PM, Eric Johnson <[e-mail]> 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.