Re: [Uri-review] Fwd: TURN/STUN URI Drafts

Marc Petit-Huguenin <> Thu, 10 January 2013 00:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5EA41F0CF5 for <>; Wed, 9 Jan 2013 16:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.385
X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8-lH02oHEP7X for <>; Wed, 9 Jan 2013 16:14:27 -0800 (PST)
Received: from ( [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by (Postfix) with ESMTP id 515DA1F0CF6 for <>; Wed, 9 Jan 2013 16:14:26 -0800 (PST)
Received: from [IPv6:2601:9:4b80:32:8484:92a2:8e76:46ce] (unknown [IPv6:2601:9:4b80:32:8484:92a2:8e76:46ce]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "" (verified OK)) by (Postfix) with ESMTPS id 6B406200D1; Thu, 10 Jan 2013 00:14:16 +0000 (UTC)
Message-ID: <>
Date: Wed, 09 Jan 2013 16:14:27 -0800
From: Marc Petit-Huguenin <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11
MIME-Version: 1.0
To: Bjoern Hoehrmann <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <>,, "Suhas Nandakumar \(snandaku\)" <>
Subject: Re: [Uri-review] Fwd: TURN/STUN URI Drafts
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Proposed URI Schemes <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Jan 2013 00:14:28 -0000

Hash: SHA256

Hi Bjoern,

Thanks for the review.  See my responses inline.

On 01/09/2013 03:25 PM, Bjoern Hoehrmann wrote:
> * Gonzalo Salgueiro wrote:
> There are some formatting problems like in the space preceding the full 
> stop in "URI scheme semantics: See [RFC5928] ."

Yes, an artifact of the tool I use to generate the xml2rfc document.  I'll fix
that in the next version.

> It also seems incorrect to reference nothing but RFC 5928 there (which has
> nothing to say about the semantics of the scheme, it seems).

Right, it should reference section 3 instead.

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

Right.  SHALL -> MUST.

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

Well, I did it this way following a review in this mailing-list, back in 2009:

So, I'll keep it this way for now.

> Including literals like "?transport=" in the grammar requires discussion of
> how %hh-escapes are handled (when you escape the "o" for instance).

I am not sure to understand why this need to be discussed, beyond what is in
RFC 3986.  Can you elaborate?

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

That's my standard boilerplate, as RFC 2119's SHOULD created too many interop
problems for me over the years.  This said, there is no SHOULD in this
document, so I will remove this in the next version - and also remove the
SHOULD in the first paragraph, to be sure that I do not forget to put it back
if a SHOULD is added later.

> In section 1 'The "turn/turns" URI scheme' is poorly phrased, better write
> it out.


- -- 
Marc Petit-Huguenin
Version: GnuPG v1.4.12 (GNU/Linux)