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/