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

[Marc Petit-Huguenin <[e-mail]>]

-----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: [e-mail]
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-----