Fwd: Re: [rfc-ise] Request for publication of "jms" URI scheme as an independent submission

 FYI, here are a bunch of comments from Alexey Melnikov about the JMS
URI scheme.  I have been remiss in getting these back to the group....

I suggest we discuss the "jms" URI scheme at the next meeting.

-Eric.

-------- Original Message --------
Subject:  Re: [rfc-ise] Request for publication of "jms" URI scheme as
an independent submission
Date:  Wed, 04 Aug 2010 12:14:17 +0200
From:  Alexey Melnikov
To:  Eric Johnson <eric@tibco.com>
CC:  Peter Saint-Andre, Graham Klyne



Eric Johnson wrote:
>  Hi Graham, Alexey,
>   
Hi Eric,
[I truncated the email exchange from my reply, as history was getting 
rather long]
> Hmmm - maybe you're on vacation?
>   
Sorry for the delay. I was actually attending an IETF meeting last week. 
I just came back home.
> In any event, could you let me know what the next logical steps might
> be, given all that we've discussed?  I submitted again to the
> independent submission editors.
>   
Graham just replied to you what to do if you want to submit this through 
RFC Editor.

I have reviewed your document, although I didn't get around to sending 
my comments. See my review below.
I suggest you address these comments whether you want to publish 
directly through RFC Editor, or do an AD-sponsored document.
> Are there other mailing lists that I should join?  Other people I should
> talk/email with?  RSS feeds I should watch?
>   
I think it might be worth discussing this document on Applications Area 
mailing list: apps-discuss@ietf.org
If your document starts generating too much traffic, the discussion can 
be moved elsewhere (and Peter or I can create a new mailing list for 
you, if you want.)
> Please advise....
>   
Ok, below are my comments:

1.  Introduction

  As a consequence of building upon an API, rather than a protocol, the
  utility of a "jms" URI depends on the context in which it is used.
  Critical details affecting utility include agreement on the same JMS
  provider or underlying protocol, agreement on the context for looking
  up endpoints, and when using serialized Java object messages,
  sufficiently similiar Java Class environments that the object can be
  appropriately read and written.  Uses of this scheme must establish
  the necessary shared context - a context which can span the globe, or
  merely a small local network.  With that shared context, this URI
  scheme enables endpoint identification in a uniform way, and the
  means to connect to those endpoints.

I have to say that I have some concern about specifying shared state and 
not describing what it is.


3.  Syntax of a jms URI

  The following ABNF describes the jms scheme URI syntax:


   jms-uri = "jms:" jms-variant ":" jms-dest
       [ "?" param *( "&" param ) ]

Is the order or parameters significant?
If not, this needs to be spelled out, as this affects comparison of 2 
jms URIs for equality.

Also, can a parameter appear more than once?


  The URIs are percent-encoded UTF-8.  Please see Section 5 for
  encoding considerations.

The reference to RFC 3629 (which defines UTF-8) is missing.
I think this reference is also Normative.


4.  URI scheme semantics

  JMS URI schemes are used to locate JMS Destination resources and do
  not specify actions to be taken on those resources.  Operations
  available on JMS destinations are fully and normatively defined by
  the JMS specification and as such, are out of scope for this URI

A reference is needed here.

  specification.


In Section 4:

  Each variant may have query parameters specific to that variation.
  All such parameters that cannot be shared across schemes should use
  the name of the variant as the prefix to the parameters.  Parameters
  that apply across multiple variants, perhaps because they are
  generally applicable, such as JMS settings, should not have any
  particular prefix, and should not begin with any known prefix.

s/should not/SHOULD NOT (twice)?

  This
  latter convention enables tools that are otherwise unfamiliar with a
  particular variant to recognize that a particular URI includes
  parameters specific to that variant.

I think an IANA registry for parameters is needed.

Also, need to be more clear about what is "prefix" (it doesn't seem to 
end with any special delimiter)


4.1.1.  deliveryMode

  Indicates whether the request message is persistent or not.  This
  property corresponds to the JMS message header field
  "JMSDeliveryMode" defined in section 3.4.2. of the JMS 1.1
  specification.  This may be "PERSISTENT" or "NON_PERSISTENT".

Is the value case sensitive or not?

  If this parameter is not specified then the JMS default SHOULD be used.

Why SHOULD and not a MUST?
(The same question for all other properties in sections 4.1.X)


And finally, the document needs more text on URI comparison, e.g. 
missing parameter, versa explicitly specified parameter with the default 
value,
etc.

Received on Monday, 23 August 2010 18:09:32 UTC