Re: [Uri-review] End of Last Call for draft-ietf-behave-turn-uri

Marc Petit-Huguenin <petithug@acm.org> Fri, 13 November 2009 07:11 UTC

Return-Path: <petithug@acm.org>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D4F03A6901; Thu, 12 Nov 2009 23:11:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.693
X-Spam-Level:
X-Spam-Status: No, score=-101.693 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100]
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 lpzDGfzqU1-K; Thu, 12 Nov 2009 23:11:22 -0800 (PST)
Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 71C663A688E; Thu, 12 Nov 2009 23:11:22 -0800 (PST)
Received: by server.implementers.org (Postfix, from userid 1001) id DD650DC0409E; Fri, 13 Nov 2009 07:11:51 +0000 (UTC)
Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id D5783DC0409C; Fri, 13 Nov 2009 07:11:50 +0000 (UTC)
Message-ID: <4AFD06B6.9090000@acm.org>
Date: Thu, 12 Nov 2009 23:11:50 -0800
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)
MIME-Version: 1.0
To: "Roy T. Fielding" <fielding@gbiv.com>
References: <4AF85F9F.4060407@acm.org> <6e04e83a0911091956v7f70d9c8l54b73b40136ec0d2@mail.gmail.com> <4AFC4C7D.4040801@acm.org> <92C70012-D3C0-4421-89F0-B9A5A619B505@gbiv.com>
In-Reply-To: <92C70012-D3C0-4421-89F0-B9A5A619B505@gbiv.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, Ted Hardie <ted.ietf@gmail.com>, "behave@ietf.org" <behave@ietf.org>, ops-dir@ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [Uri-review] End of Last Call for draft-ietf-behave-turn-uri
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2009 07:11:23 -0000

Hi Roy,

Roy T. Fielding wrote:
> On Nov 12, 2009, at 9:57 AM, Marc Petit-Huguenin wrote:
> 
>> Hi Ted,
>>
>> Ted Hardie wrote:
>>> Hi Marc,
>>>
>>> Thanks for the changes; I thought you had suggested using new
>>> productions, rather than re-using the existing ones from the
>>> hierarchical
>>> URI mechanism.  Sorry if I did not reply on that--I think that would
>>> be a good idea, but if there is rough consensus for the current approach,
>>> I am happy to go along.
>>>
>> OK I'll replace the following text:
>>
>> "  turnURI   = scheme ":" host [ ":" port ] [ "?transport=" transport ]
>>   scheme    = "turn" / "turns"
>>   transport = "udp" / "tcp" / transport-ext
>>   transport-ext = 1*unreserved
>>
>> <host>, <port> and <unreserved> are specified in [RFC3986].
>>
>> Note that the usage of components defined in the [RFC3986] as part of
>> a generic hierarchical URI does not mean that a TURN/TURNS URI is
>> hierarchical."
>>
>> by this text:
>>
>> "  turnURI   = scheme ":" host [ ":" port ] [ "?transport=" transport ]
>>   scheme        = "turn" / "turns"
>>   transport     = "udp" / "tcp" / transport-ext
>>   transport-ext = 1*unreserved
>>   host          = IP-literal / IPv4address / reg-name
>>   port          = *DIGIT
>>   IP-literal    = "[" ( IPv6address / IPvFuture  ) "]"
>>   IPvFuture     = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
>>   IPv6address   =                            6( h16 ":" ) ls32
>>                 /                       "::" 5( h16 ":" ) ls32
>>                 / [               h16 ] "::" 4( h16 ":" ) ls32
>>                 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
>>                 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
>>                 / [ *3( h16 ":" ) h16 ] "::"    h16 ":"   ls32
>>                 / [ *4( h16 ":" ) h16 ] "::"              ls32
>>                 / [ *5( h16 ":" ) h16 ] "::"              h16
>>                 / [ *6( h16 ":" ) h16 ] "::"
>>   h16           = 1*4HEXDIG
>>   ls32          = ( h16 ":" h16 ) / IPv4address
>>   IPv4address   = dec-octet "." dec-octet "." dec-octet "." dec-octet
>>   dec-octet     = DIGIT                 ; 0-9
>>                 / %x31-39 DIGIT         ; 10-99
>>                 / "1" 2DIGIT            ; 100-199
>>                 / "2" %x30-34 DIGIT     ; 200-249
>>                 / "25" %x30-35          ; 250-255
>>   reg-name      = *( unreserved / pct-encoded / sub-delims )
>>
>>
>>   <unreserved> <sub-delims> and <pct-encoded> are specified in
>>   [RFC3986]."
>>
>> I will also add this in the Acknowledgments section:
>>
>> "The <port> and <host> ABNF productions have been copied from
>> [RFC3986]."
> 
> Umm, why don't you just use the RFC3986 ABNF directly, make it
> a normative dependency, and not recreate that which is already
> a standard?

Ted Hardie suggested the exact opposite.

> 
> While you are at it, please redesign the URI to be hierarchical.
> The proposed syntax goes out of its way to create arbitrary
> differences from STD66.

Your advice contradicts RFC 4395 section 2.2:

"Avoid improper use of "//".  The use of double slashes in the first
 part of a URI is not an artistic indicator that what follows is a
 URI: Double slashes are used ONLY when the syntax of the URI's
 <scheme-specific-part> contains a hierarchical structure as described
 in RFC 3986.  In URIs from such schemes, the use of double slashes
 indicates that what follows is the top hierarchical element for a
 naming authority.  (See Section 3.2 of RFC 3986 for more details.)
 URI schemes that do not contain a conformant hierarchical structure
 in their <scheme-specific-part> SHOULD NOT use double slashes
 following the "<scheme>:" string."

> 
> Transport does not belong as a query parameter.  Transports are
> a fundamental part of authority management.  The traditional way
> of handling multiple transports is to provide a unique scheme for
> each one, since that is how clients will determine which identifier
> to use on the basis of whether they support the different transports.
> TLS is a transport.

Can you please provide the RFC # and section that says this?  I was not able to
find it.  Thanks.

> 
> In other words:
> 
>  turnURI = "turn" [ "." transport ] "://" authority
>  transport = "tls" / "udp" / "sctp"        ; TCP is the default
>  authority = <authority, as defined in STD66>
> 
> I would also suggest appending path-abempty [ "?" query ]
> as well, if there is any chance (no matter how remote) that
> you might find a use for path or query information in the future.


-- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org