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

Marc Petit-Huguenin <petithug@acm.org> Mon, 16 November 2009 20:38 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 B77F028C0E0; Mon, 16 Nov 2009 12:38:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 udOOC3aGuqla; Mon, 16 Nov 2009 12:38:16 -0800 (PST)
Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id B0C1E3A680D; Mon, 16 Nov 2009 12:38:16 -0800 (PST)
Received: by server.implementers.org (Postfix, from userid 1001) id 8ABE2DC0409E; Mon, 16 Nov 2009 20:38:15 +0000 (UTC)
Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 92888DC0409C; Mon, 16 Nov 2009 20:38:14 +0000 (UTC)
Message-ID: <4B01B835.3010408@acm.org>
Date: Mon, 16 Nov 2009 12:38:13 -0800
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>, Dan Wing <dwing@cisco.com>
References: <4AF85F9F.4060407@acm.org> <6e04e83a0911091956v7f70d9c8l54b73b40136ec0d2@mail.gmail.com> <4AFC4C7D.4040801@acm.org> <92C70012-D3C0-4421-89F0-B9A5A619B505@gbiv.com> <4AFD06B6.9090000@acm.org> <6e04e83a0911160940x53675f34t503463b60070da51@mail.gmail.com>
In-Reply-To: <6e04e83a0911160940x53675f34t503463b60070da51@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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 20:38:17 -0000

Ted Hardie wrote:
> 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:
>>>

[...]

>>> 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.

Well, I had other private discussions about this, and I am now seriously
considering dropping the TURN/TURNS URI and just keeping the resolution
mechanism.  The only purpose of the URI is to carry the 3 pieces of information
needed for the resolution algorithm (host/IP address, port and TURN transport),
but this 3 pieces of information can be stored in the client configuration
individually.  That is not as neat as having one, single character string, but
seeing all the difficulties in having the syntax approved, this is probably the
best solution.  I used RFC 4501 as a guideline for this design, but now people
are telling me that a DNS URI was a bad idea...

So unless someone objects to this, the next version (probably released Monday
23rd) will be without the URI stuff.

The only problem is that the name of the I-D (draft-ietf-turn-uri) will no
longer reflect the content.  Dan, any suggestion here?

Thanks.

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