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
- [Uri-review] End of Last Call for draft-ietf-beha… Marc Petit-Huguenin
- Re: [Uri-review] End of Last Call for draft-ietf-… Ted Hardie
- Re: [Uri-review] End of Last Call for draft-ietf-… Marc Petit-Huguenin
- Re: [Uri-review] End of Last Call for draft-ietf-… Roy T. Fielding
- Re: [Uri-review] End of Last Call for draft-ietf-… Marc Petit-Huguenin
- Re: [Uri-review] End of Last Call for draft-ietf-… Ted Hardie
- Re: [Uri-review] End of Last Call for draft-ietf-… Marc Petit-Huguenin