Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-ietf-behave-turn-uri (Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers) to Proposed Standard]
Ted Hardie <ted.ietf@gmail.com> Thu, 15 October 2009 21:33 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 E46FA28C18E; Thu, 15 Oct 2009 14:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
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 G3QKs7GFQzgr; Thu, 15 Oct 2009 14:33:56 -0700 (PDT)
Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id E41AD28C188; Thu, 15 Oct 2009 14:33:55 -0700 (PDT)
Received: by pwi4 with SMTP id 4so206477pwi.29 for <multiple recipients>; Thu, 15 Oct 2009 14:33:56 -0700 (PDT)
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=X2tLzom6P1hSetd0LIFhR2SW1IuvswWXfuMncPNmBHQ=; b=HVI4KrU6YvtYRhmyNidLMb1hJm65zWfkkuTPrOsPMiPo31yDyLA6DxLQsYo81S0BdY Dlspjxlxk2A70Lxc5CfbGv4qDestzN3otDn3YYJ2pzHglvmCFzTmN/aa9VEO5znK7ysQ VdeTAjSr1dhhrq1HAlQX7VnIQgdb/rrSYOstM=
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=DSm41RXRKRCtm3plSdUWvCn0UuKSjFMTatmSrdW6Wt/dUcyLE6JFW6DMgcEyQGUa9n BrTrs3R9tpYvoEhNmL5REafG1bGgOW46YMDg5mbS6VKk9tU+ylyTX86HcjTaRoVLccHK NOZhM5QCwwbvsnvl3Cz+/WuiMzESeythdnABc=
MIME-Version: 1.0
Received: by 10.143.20.42 with SMTP id x42mr58398wfi.225.1255642436426; Thu, 15 Oct 2009 14:33:56 -0700 (PDT)
In-Reply-To: <4AD7387A.7060901@ericsson.com>
References: <4AD7387A.7060901@ericsson.com>
Date: Thu, 15 Oct 2009 14:33:56 -0700
Message-ID: <6e04e83a0910151433y2007a015ia77a407e702a3841@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: uri-review@ietf.org, ietf@ietf.org, app-ads@tools.ietf.org
Subject: Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-ietf-behave-turn-uri (Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers) to Proposed Standard]
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: Thu, 15 Oct 2009 21:33:57 -0000
Howdy, I do not believe this document is ready for publication, as I believe the URI scheme documentation needs work. As it stands now, the scheme-specific processing required for this scheme is so great that I believe a standard URI parser will not work with the scheme as it is intended. Looking, for example, at the CPAN module PERL::URI, the operation of the standard behavior for path and port seem likely to work contrary to this scheme's intention. I also could not follow the details of how this would work in relation to a DDDS remote hosting option, as mentioned in section 1, and I believe that more descriptive text may be required. One area of particular concern is this: "The URI resolution algorithm uses <scheme>, <host>, <port> and <transport> as input. It also uses as input a list ordered by preference of TURN transports (UDP, TCP, TLS) supported by the application using the TURN client. The output of the algorithm is a list of {IP address, transport, port} tuples that a TURN client can try in order to create an allocation on a TURN server." Having a URI resolution method rely on a preference order associated with a calling application seems very fragile. There seems to be no way to guarantee that the information on calling application would be preserved in passing the URI to a parser. If this input list is required, I suspect that that it must be noted within a URI parameter to avoid unexpected or incorrect results. Since this mechanism involves a fairly distinctive URI resolution mechanism, I suggest that this document also be reviewed by the URI mailing list, in addition to URI-review. It seems more likely to be able to discuss how to best meet the requirements expressed within a URI syntax more likely to be handled correctly by parsers already deployed. regards, Ted Hardie On Thu, Oct 15, 2009 at 7:58 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote: > Hi, > > As responsible AD I would really appreciate an URI review of the two > proposed URI schemes. > > Thanks > > Magnus Westerlund > > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > The IESG has received a request from the Behavior Engineering for > Hindrance Avoidance WG (behave) to consider the following document: > > - 'Traversal Using Relays around NAT (TURN) Uniform Resource Identifiers ' > <draft-ietf-behave-turn-uri-03.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2009-10-29. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-uri-03.txt > > > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18080&rfc_flag=0 > > _______________________________________________ > Behave mailing list > Behave@ietf.org > https://www.ietf.org/mailman/listinfo/behave > > > _______________________________________________ > Uri-review mailing list > Uri-review@ietf.org > https://www.ietf.org/mailman/listinfo/uri-review > >
- [Uri-review] [Fwd: [BEHAVE] Last Call: draft-ietf… Magnus Westerlund
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Ted Hardie
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Dan Wing
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Ted Hardie
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Ted Hardie
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Magnus Westerlund
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Marc Petit-Huguenin
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Marc Petit-Huguenin
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Ted Hardie
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Ted Hardie
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Magnus Westerlund
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Marc Petit-Huguenin
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Marc Petit-Huguenin
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Marc Petit-Huguenin
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Andrew Newton
- Re: [Uri-review] [Fwd: [BEHAVE] Last Call: draft-… Andrew Newton