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

Just commenting on comparable schemes....

Eric Johnson wrote:
> Hi Mark,
>
> Thanks again for your additional feedback.
>
> Mark Baker wrote:
>   
>> On Fri, Mar 20, 2009 at 11:05 PM, Harald Alvestrand
>> <harald@alvestrand.no> 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-(
>>     
>
> 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.
>
> It is certainly hard for us to know whether this current situation is an
> accident of the historical adoption of JMS, or whether it generally
> isn't useful on the internet global scope.
>
> Certainly, one of the reasons we're putting this proposal forward is to
> facilitate the adoption of SOAP over JMS.  This seems relevant to me,
> because we currently have an enormous amount of code and effort going
> into handling SOAP messages over HTTP in a reliable and secure fashion.
>  With JMS, you get these characteristics (almost) without having to
> define additional layers of specification to handle reliability and
> encryption at the payload layer.
>
> Given an available standard for SOAP over JMS, could that drive a more
> global use for JMS itself?  Hard to say.
>
> As a few simple counterpoints, the "file", "opaquelocktoken", "cid", and
> "mid" URI schemes has a similarly local interpretation, but a global use.
>   
"cid" and "mid" are defined to be globally unique. They don't have a 
resolution mechanism, but by definition, they are globally unique.

"opaquelocktoken" is based on an UUID (another globally unique item 
without a lookup mechanism), and its definition says:

   An opaquelocktoken URI is constructed by concatenating the
   'opaquelocktoken' scheme with a UUID, along with an optional
   extension.  Servers can create new UUIDs for each new lock token.  If
   a server wishes to reuse UUIDs, the server MUST add an extension, and
   the algorithm generating the extension MUST guarantee that the same
   extension will never be used twice with the associated UUID.

I won't attemt to defend "file".

Received on Tuesday, 14 April 2009 10:02:44 UTC