Re: [Uri-review] Fwd: TURN/STUN URI Drafts
Bjoern Hoehrmann <derhoermi@gmx.net> Wed, 09 January 2013 23:25 UTC
Return-Path: <derhoermi@gmx.net>
X-Original-To: uri-review@ietfa.amsl.com
Delivered-To: uri-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E9821F8644 for <uri-review@ietfa.amsl.com>; Wed, 9 Jan 2013 15:25:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oiAyThHZqpt0 for <uri-review@ietfa.amsl.com>; Wed, 9 Jan 2013 15:25:05 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id F259921F85CB for <uri-review@ietf.org>; Wed, 9 Jan 2013 15:25:04 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LpihM-1TNZkn2BIU-00fVtV for <uri-review@ietf.org>; Thu, 10 Jan 2013 00:25:03 +0100
Received: (qmail invoked by alias); 09 Jan 2013 23:25:03 -0000
Received: from p5B063D83.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.6.61.131] by mail.gmx.net (mp020) with SMTP; 10 Jan 2013 00:25:03 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX18k++xEuo8kV/E9DEdDc7M0pO+VR/iiz3IO9YLmqI cKBqyJkhxyuWfQ
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Gonzalo Salgueiro <gsalguei@cisco.com>
Date: Thu, 10 Jan 2013 00:25:04 +0100
Message-ID: <5usre81edqts3ef76hmu4um4dnrd0b1b4j@hive.bjoern.hoehrmann.de>
References: <50E5B080.8000609@qti.qualcomm.com> <C65ADC5D-6D77-48A4-A556-9F64A327A81A@cisco.com>
In-Reply-To: <C65ADC5D-6D77-48A4-A556-9F64A327A81A@cisco.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: Cullen Jennings <fluffy@cisco.com>, Marc Petit-Huguenin <petithug@acm.org>, uri-review@ietf.org, "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>
Subject: Re: [Uri-review] Fwd: TURN/STUN URI Drafts
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 09 Jan 2013 23:25:06 -0000
* Gonzalo Salgueiro wrote: >TURN URI: >http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris There are some formatting problems like in the space preceding the full stop in "URI scheme semantics: See [RFC5928] ." It also seems incorrect to reference nothing but RFC 5928 there (which has nothing to say about the semantics of the scheme, it seems). Further The TURN protocol supports sending messages over UDP, TCP or TLS- over-TCP. The "turns" URI scheme SHALL be used when TURN is run over TLS-over-TCP (or in the future DTLS-over-UDP) and the "turn" scheme SHALL be used otherwise. This seems to use RFC 2119 terms incorrectly (how would it be possible to do otherwise, and what would be non-conforming in that case?). Also, The <port> part, if present, denotes the port on which the TURN server is awaiting connection requests. If it is absent, the default port SHALL be 3478 for both UDP and TCP. The default port for TURN over TLS SHALL be 5349. URI scheme specifications have to define what the default port is, not what it "shall be". It also seems this should refer to the schemes by name, not their usage (think: "default port for 'turn' is 3478, default port for 'turns' is 5349"). Section 3.1 should define the syntax by reference to STD 66, or there should be rationale in the specification explaining why it has its own, for instance, `IPv4address` production (is it different from STD 66?). Including literals like "?transport=" in the grammar requires discussion of how %hh-escapes are handled (when you escape the "o" for instance). In section 2 it's not clear to me why the draft tries to explain various RFC 2119 keywords, right after saying they are to be interpreted as per RFC 2119. In section 1 'The "turn/turns" URI scheme' is poorly phrased, better write it out. >STUN URI: >http://tools.ietf.org/html/draft-nandakumar-rtcweb-stun-uri Some of the comments above apply to this document aswell. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
- [Uri-review] Fwd: TURN/STUN URI Drafts Gonzalo Salgueiro
- Re: [Uri-review] Fwd: TURN/STUN URI Drafts Bjoern Hoehrmann
- Re: [Uri-review] Fwd: TURN/STUN URI Drafts Marc Petit-Huguenin