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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
