Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10

[Tim Bray <[e-mail]>]

I'm glad you believe all these problems were fixed: perhaps in future it
would be beneficial to include the person who reported them in the fix-up
email trail.

As for the larger issue, I remain entirely unconvinced that this particular
class of identifiers meets the expectations reasonable people have of
something that claims to be a URI, but it seems the IESG disagrees with me.

-Tim

On Jan 30, 2011 5:41 AM, "Alexey Melnikov" <[e-mail]>
wrote:
Hi Tim,
I am sorry I haven't replied to your message earlier (and didn't make sure
that one of the editors do).



Tim Bray wrote:

> Dear IESG, sorry, got the wrong address for you first time around.
> This also ...
I have to say that I was a bit concerned about this text as well, but I
liked editors honesty regarding the state of affairs.

Considering that this URI scheme is already in use (and referenced by other
specs) and considering that it is a provisional registration, I think it is
Ok. Personally, I would much prefer to register a URI scheme as provisional,
then to reject the URI scheme registration and pretend that it doesn't
exist. As other people already pointed out it is important to register URI
schemes to at least avoid URI scheme name conflicts.



> 2. Section 3.3 says “ If users plan switching between JMS vendors,
> they might also need to pla...
I got the same impression.



> but the variants are maybe a back-door for vendor abuse.
>
It is possible. But personally, I prefer to provide some extensible
framework to begin with than to let vendors extend URIs is completely
unpredictable ways.



> Minor Issues:
>
> 1. Section 1. Need references for terms like javax.jms.Destination for
> peopl...
I think these 3 issues were addressed.



> 4. 4.1.1 and so on, should the draft impose any constraints on the
> syntax of these parameter v...
I think this was at least partially addressed.



> 5. 4.2.1 Perhaps a note prior to launching into all the parameters on
> syntax constraints, with...
Addressed.



> 6. 4.2.2 includes great gobs of Java code illustrating how to use such
> an endpoint. Does this ...
I think the updated text is clearer on these 2 issues.



> 8. Section 6, 3rd para: I haven’t ever seen anything like the note
> about what an OASIS TC migh...
I think this point was addressed.



> 9. Section 7, last para: “As described in Section 4, others can define
> additional variants”......
Right, I've missed that.



> Also, while the language in the opening of
> the draft suggests that the set of variants is open...
I think it does now.



> Nits:
>
> 1. Section 4 para 3, superfluous comma after “Both the variant”.
>
> 2. Section 4 para...
Fixed.



> 4. Section 4.1 first para, the word “property” suddenly appears for
> the first time. Is this a ...
I think RFC Editor will take care of this.



> 5. Same section, missing full stop after “following shared parameters”.
>
> 6. 4.1.1 Probably mo...
All of these were fixed as well.