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

Ted Hardie <ted.ietf@gmail.com> Mon, 16 November 2009 17:40 UTC

Return-Path: <ted.ietf@gmail.com>
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 919D728C1BD; Mon, 16 Nov 2009 09:40:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_37=0.6]
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 YCkGdoV6Yzxs; Mon, 16 Nov 2009 09:40:21 -0800 (PST)
Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 4BE6C28C1DC; Mon, 16 Nov 2009 09:40:18 -0800 (PST)
Received: by pzk6 with SMTP id 6so4412630pzk.29 for <multiple recipients>; Mon, 16 Nov 2009 09:40:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HrpnbLri9WwpWk6aHps5zGyt7rSPCGRpkECE9pWmjKA=; b=K3BDmZAFx6DMqwK5o1RE90cF9Km+9a1fBMvGATNkR5RBXNWZoR1VyYajcye1+N4ev2 l6JagJpEbg7EpaVLl2E5zGgZaAU9ngbkmugDB+ZCrQrA/fnoVDXYH+UAvd3BPI0JOrF+ qrGny5j8UYaJV7VteiNv+w1jDafW1DeEkBOic=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vGG9+dDibRtBNTMT2bl0kCqwOGpNr7MS8qx79iCxDhi/nr3U2QaM8Rlqr0FWZ0B2Ov U0C1jFuX9fWerd+am2IbkuxOWAUIfZBgsEZzDUqoIvUPWPyBvBfbSZTv6o+2Ml/46QII kwOlkL4l0JMbqgMi2WBMo9ccCzG3LzIFrjkqc=
MIME-Version: 1.0
Received: by 10.143.129.7 with SMTP id g7mr879514wfn.241.1258393214693; Mon, 16 Nov 2009 09:40:14 -0800 (PST)
In-Reply-To: <4AFD06B6.9090000@acm.org>
References: <4AF85F9F.4060407@acm.org> <6e04e83a0911091956v7f70d9c8l54b73b40136ec0d2@mail.gmail.com> <4AFC4C7D.4040801@acm.org> <92C70012-D3C0-4421-89F0-B9A5A619B505@gbiv.com> <4AFD06B6.9090000@acm.org>
Date: Mon, 16 Nov 2009 09:40:14 -0800
Message-ID: <6e04e83a0911160940x53675f34t503463b60070da51@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Marc Petit-Huguenin <petithug@acm.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: uri-review@ietf.org, "Roy T. Fielding" <fielding@gbiv.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: Mon, 16 Nov 2009 17:40:26 -0000

On Thu, Nov 12, 2009 at 11:11 PM, Marc Petit-Huguenin <petithug@acm.org> wrote:
> 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.

Howdy,

Sorry for the episodic nature of these comments; jet-lag combined with
day-job issues have really taken their toll on my response time.  My apologies
especially that I wasn't able to discuss this in person in Hiroshima with
any of the relevant folks--I had to leave early.

The thrust of my list comment was intended to find some way of distinguishing
the way this URI scheme uses its components.  Using new ABNF productions
was one fairly low-impact way of signaling these were different, but I believe
that re-using the same names and copying the ABNF doesn't really qualify
as new productions.  At the very least, I think you'd need new names that
highlighted the roles these play; even that is not much of a signal
once these are
in the wild.

As you recall, I'd originally suggested that the URI mailing list be
cc'ed for ideas
on other approaches, and Roy is certainly one of the folks that I'd hoped would
review it there.  If I can help by setting up a conference call or
otherwise getting
some more real-time communication going, please let me know.  I remain hopeful
that we can find some way of approaching the problem that doesn't involve
a complete pushback.  I apologize again for any delay my own response time has
induced.

regards,

Ted Hardie