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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 06 Dec 2010 09:37:30 -0600

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.

*  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.

*  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/

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Eric Johnson <[email-masked]>
Date: Mon, 06 Dec 2010 09:54:49 -0800

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:

>  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.

>  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.

>  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.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 06 Dec 2010 12:45:04 -0600

> Thanks for your review! I was just wondering if I should be "ping"ing

Eric: For that I have no idea.  You may want to check with your
co-authors regarding the edits and with Alexey on next steps since
this is an AD-sponsored draft.

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

Please see inline.

> the <jms-variant>, and the <jms-dest> elements of the URI are

I think it is fine with one caveat: the last sentence can simply
state that "All the terminals resulting from <jms-variant> and
<jms-dest> production rule are case-sensitive."

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

Ah, OK.  I was not aware of the <spanx> element in xml2rfc.  If
that's what it does then that's what it does.

Thanks,

- vijay