Return-Path: X-Original-To: apps-discuss@core3.amsl.com Delivered-To: apps-discuss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 249C43A6B0A for ; Sun, 30 Jan 2011 08:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.935 X-Spam-Level: X-Spam-Status: No, score=-2.935 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRPNZlWi7eDy for ; Sun, 30 Jan 2011 08:45:11 -0800 (PST) Received: from mail-fx0-f49.google.com (mail-fx0-f49.google.com [209.85.161.49]) by core3.amsl.com (Postfix) with ESMTP id 5660C3A6B20 for ; Sun, 30 Jan 2011 08:45:09 -0800 (PST) Received: by fxm19 with SMTP id 19so6090199fxm.22 for ; Sun, 30 Jan 2011 08:48:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.72.197 with SMTP id n5mr4902411faj.8.1296406100500; Sun, 30 Jan 2011 08:48:20 -0800 (PST) Received: by 10.223.126.212 with HTTP; Sun, 30 Jan 2011 08:48:20 -0800 (PST) X-Originating-IP: [216.113.201.123] Received: by 10.223.126.212 with HTTP; Sun, 30 Jan 2011 08:48:20 -0800 (PST) In-Reply-To: References: <4D456A15.8080708@isode.com> Date: Sun, 30 Jan 2011 08:48:20 -0800 Message-ID: From: Tim Bray To: Alexey Melnikov Content-Type: multipart/alternative; boundary=20cf3054a4f91ae124049b1311e8 Cc: iesg@ietf.org, discuss@apps.ietf.org, derek.rokicki@softwareag.com, m8philli@uk.ibm.com Subject: Re: [apps-discuss] apps-team review of draft-merrick-jms-uri-10 X-BeenThere: apps-discuss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: General discussion of application-layer protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jan 2011 16:45:13 -0000 --20cf3054a4f91ae124049b1311e8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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" 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 =93 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=92t ever seen anything like the note > about what an OASIS TC migh... I think this point was addressed. > 9. Section 7, last para: =93As described in Section 4, others can define > additional variants=94...... 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 =93Both the variant=94. > > 2. Section 4 para... Fixed. > 4. Section 4.1 first para, the word =93property=94 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 =93following shared parameters= =94. > > 6. 4.1.1 Probably mo... All of these were fixed as well. --20cf3054a4f91ae124049b1311e8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I'm glad you believe all these problems were fixed: perhaps in futur= e 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 particu= lar class of identifiers meets the expectations reasonable people have of s= omething that claims to be a URI, but it seems the IESG disagrees with me.<= /p>

-Tim

On Jan 30, 2011 5:41 AM, "Alexey Melnikov= " <alexey.melnikov@iso= de.com> wrote:
Hi Tim,
I am sorry I haven't replied to your message earlier (and didn't ma= ke sure that one of the editors do).



Tim = Bray wrote:

> Dear IESG, sorry, got the wrong address for you fir= st time around.
> This also ...

I have to say that I was a bit concerned about this text as well, but I lik= ed 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 i= s Ok. Personally, I would much prefer to register a URI scheme as provision= al, then to reject the URI scheme registration and pretend that it doesn= 9;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 =93 If users plan = switching between JMS vendors,
> they might also need to pla...

I got the same impression.



> but the v= ariants are maybe a back-door for vendor abuse.
>

It is possible. But personally, I prefer to provide some extensible framewo= rk to begin with than to let vendors extend URIs is completely unpredictabl= e ways.



> Minor Issues:
>
> 1. Section 1. Need references for terms like javax.jms.Destination for=
> peopl...

I think these 3 issues were addressed.



&g= t; 4. 4.1.1 and so on, should the draft impose any constraints on the
&g= t; 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 paramete= rs on
> syntax constraints, with...

Addressed.



> 6. 4.2.2 includes great g= obs of Java code illustrating how to use such
> an endpoint. Does thi= s ...

I think the updated text is clearer on these 2 issues.



> 8. Section 6, 3rd para: I haven=92t ever seen anything l= ike the note
> about what an OASIS TC migh...

I think this point was addressed.



> 9.= Section 7, last para: =93As described in Section 4, others can define
&= gt; additional variants=94......

Right, I've missed that.



> Also, w= hile 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 =93Both the variant=94.=
>
> 2. Section 4 para...

Fixed.



> 4. Section 4.1 first para, th= e word =93property=94 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 =93following shared paramet= ers=94.
>
> 6. 4.1.1 Probably mo...

All of these were fixed as well.

--20cf3054a4f91ae124049b1311e8--