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

Marc Petit-Huguenin <petithug@acm.org> Thu, 10 January 2013 00:14 UTC

Return-Path: <petithug@acm.org>
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 E5EA41F0CF5 for <uri-review@ietfa.amsl.com>; Wed, 9 Jan 2013 16:14:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.385
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-lH02oHEP7X for <uri-review@ietfa.amsl.com>; Wed, 9 Jan 2013 16:14:27 -0800 (PST)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 515DA1F0CF6 for <uri-review@ietf.org>; 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 "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 6B406200D1; Thu, 10 Jan 2013 00:14:16 +0000 (UTC)
Message-ID: <50EE07E3.3010101@acm.org>
Date: Wed, 09 Jan 2013 16:14:27 -0800
From: Marc Petit-Huguenin <petithug@acm.org>
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 <derhoermi@gmx.net>
References: <50E5B080.8000609@qti.qualcomm.com> <C65ADC5D-6D77-48A4-A556-9F64A327A81A@cisco.com> <5usre81edqts3ef76hmu4um4dnrd0b1b4j@hive.bjoern.hoehrmann.de>
In-Reply-To: <5usre81edqts3ef76hmu4um4dnrd0b1b4j@hive.bjoern.hoehrmann.de>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: Cullen Jennings <fluffy@cisco.com>, 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: Thu, 10 Jan 2013 00:14:28 -0000

-----BEGIN PGP SIGNED MESSAGE-----
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:
>> 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] ."

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

OK.

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

https://www.ietf.org/mail-archive/web/uri-review/current/msg01070.html

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.

OK.


- -- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQ7gfhAAoJECnERZXWan7Ei8YQAJnHb+TqxWGXv8C0GOTq6wyK
SPOXfH03Ra9w83hVY8ymf1Sbc9SAUEyPOXR0u7u0FTYjFwP92ayGLOARchnoEIew
hcSozg6rBarzo9zPhaRRqxCkkdrvuhI0mPv/zQJAAE4dk/fSYoi2/4L5m4HMS0xL
FQ82FjcqNEIDwIn7bT6jjVFsE7/+zBG8iakEJnIGFXwJtsmCpqWZkXa1zdyQ9ff0
myyRz1N1KpSULyiRhN6pRld8JUOFCv2MK40+zb+an0mtSW7eagLbXn3iYN0zjncK
FukyT2bqhjhaanlW4ZaikpU6l/r+x+6Bu++FfhFU+b8T55nQKW7Oaj5NUoV9qAaF
ZLPemNJ0MJO55ShCPoT3XH+9airLLPbeJvHdJUKDWxc3dpss+c41fLS7L9nFKkY9
Og8LCNTFHfcxB3C88JV9kCLVZngUy+JOTNDDqwCIr50gmAA1z77LAju129EMSbv4
Ci9sHSCjJ9+n8lnJcrsO9D5E87VN8me/CLKgLU4BHgtOWsi8pw0aag0OQhpYbN14
Pi30d0Ksy/aCUravUoYL4XeZPITvlJ8V2mwXhf2lkLsnrF0YSdJVBkjGPMJEORCa
X7p/AXq0FquSUtfskFrWhG4EQn+mlVPSq7E00Nx01dENMv0RGJz4wk0pNzuvUlsc
lXVkMKFBkfgHaMg7qHJE
=WRPC
-----END PGP SIGNATURE-----