Re: [Gen-art] Gen-ART review of draf-merrick-jms-uri-10

[Eric Johnson <[e-mail]>]

Hi Vijay,

Thanks for your review!  I was just wondering if I should be "ping"ing 
anyone about it.

I'm more than happy to post a new draft with some edits, but I have 
questions below:

On 12/6/10 7:37 AM, Vijay K. Gurbani wrote:
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments
> you may receive.
>
> Document: draf-merrick-jms-uri-10
> Reviewer: Vijay K. Gurbani
> Review Date: Dec-06-2010
> IETF LC End Date: Dec-28-2010
> IESG Telechat date: Not known.
>
> Summary: This draft is ready as an Informational.
> Major issues: 0
> Minor issues: 0
> Nits/editorial comments: 3
>
> *  S4 -- "The required particles in the JMS URI ...", here it may be
>  better to stick with the nomenclature established by rfc5234 and
>  parsing literature regarding "elements" and "terminals".  Under that
>  nomenclature, "the scheme part ("jms") would be a terminal and the
>  variant identifier and the <jms-dest> portions would be elements.

OK.  What if I change this:
The required particles in the JMS URI are the scheme name ("jms"), the 
variant identifier, and the <jms-dest> portions. The three recognized 
variants (<jms-variant> above) are "jndi", "queue", and "topic". The 
<jms-dest> portion identifies the JMS destination object in a way that 
is determined by the particular variant. Both the variant, and the 
jms-dest portions of the URI are case-sensitive.

To this:

"The required portions of the syntax include the terminal of "jms" for 
the URI scheme name, the <jms-variant> element to indicate the variant 
of the scheme, and the <jms-dest> element, which identifies the 
destination based on the chosen variant.  For the <jms-variant> element, 
this document defines three values: "jndi", "queue", and "topic".  Both 
the <jms-variant>, and the <jms-dest> elements of the URI are 
case-sensitive.

>
> *  S4.2.2, S4.2.2.1 -- The long URI that spans multiple lines is
>  presumably on one logical line when specified in a browser URL field or
>  programmatically, right?  I do not know whether it is worth adding
>  that distinction in your draft.  I will leave it to your discretion.

Hmmm - I thought the whole point of disallowing spaces in URIs was 
specifically to eliminate this ambiguity!

This is all generated from an XML document, of course.  I poked a little 
deeper, and noticed that much of the text appearing in the "<artwork>" 
tag was not indented.  I've gone ahead and indented it (and wrapped 
differently where necessary, and it is much more obvious that it is a 
single URI now.  Minor formatting change, but does better convey the 
intent, so thanks.

>
> *  S4.4 -- I am not sure why the second paragraph starts with
>  an underline character: _Warning_.  This will probably render using a
>  different font, etc. on a browser, but in the printed page it will
>  loose its meaning.  Maybe best to s/_Warning_/Warning/

This is how XML 2 RFC appears to render something with emphasis.  Looks 
fine in the HTML rendering.  Can you suggest an alternate construct I 
could put in the XML form, rather than the current form?

<spanx style="emph">Warning</spanx>

Thanks!

-Eric.