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

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 9 Jan 2013 13:51:51 -0500

URI Reviewers,
 
As a component of the RTCWEB work we are trying to define and register the TURN and STUN URI schemes. As part of that work these drafts are now normatively referenced by the W3C (http://www.w3.org/TR/webrtc/ and http://dev.w3.org/2011/webrtc/editor/webrtc.html) and have already been implemented in Google (Chrome) in their current STUN/TURN server configuration code and is in the process of being implemented by Mozilla (Firefox)]. I have left the below thread to provide a bit of context on these drafts. These drafts can be found here:

TURN URI:
http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris 

STUN URI:
http://tools.ietf.org/html/draft-nandakumar-rtcweb-stun-uri

The TURN URI scheme was first proposed several years ago and has already been through uri-review back in late 2009 (https://www.ietf.org/mail-archive/web/uri-review/current/msg01063.html). The current TURN URI proposal is a result of that discussion.  The STUN URI came about more recently but is intended to be complementary.
 
We kindly request that you review the proposed URI schemes.
 
We look forward to your feedback.

Thanks!

Gonzalo

Begin forwarded message:

> From: Pete Resnick <[email-masked]>
> Subject: Re: TURN/STUN URI Drafts
> Date: January 3, 2013 11:23:28 AM EST
> To: Marc Petit-Huguenin <[email-masked]>
> Cc: Gonzalo Camarillo <[email-masked]>, Gonzalo Salgueiro <[email-masked]>, "Suhas Nandakumar (snandaku)" <[email-masked]>, Paul Jones <[email-masked]>, Cullen Jennings <[email-masked]>, Barry Leiba <[email-masked]>
> 
> Happy New Year to you as well.
> 
> You should probably first send these drafts to [email-masked] to see if there everyone is OK. Assuming that's true (from a quick peek, there's nothing obviously horrible), either Barry or I can AD sponsor the documents. But I'd like to hear what Graham and the other uri-review folks have to say.
> 
> Cheers,
> 
> pr
> 
> On 1/2/13 11:23 AM, Marc Petit-Huguenin wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>> 
>> Happy New Year to everybody.
>> 
>> I did not see any progress on this topic since this email.  Would it be
>> possible to have a status update on what is blocking this, and how I can help
>> to make this happen?
>> 
>> Thanks.
>> 
>> On 11/05/2012 11:50 AM, Gonzalo Camarillo wrote:
>>   
>>> Hi Pete,
>>> 
>>> so, per our conversation in the welcome reception, please have a look at
>>> the email below and let the authors know how to proceed (i.e., whether or
>>> not they need a standards track RFC).
>>> 
>>> If I need to take care of something (e.g., AD sponsoring a draft), let me
>>> know as well.
>>> 
>>> Cheers,
>>> 
>>> Gonzalo
>>> 
>>> On 04/11/2012 11:44 PM, Gonzalo Salgueiro wrote:
>>>     
>>>> Gonzalo/Pete -
>>>> 
>>>> As requested, this is the follow up email regarding the TURN/STUN URI
>>>> drafts that require AD-sponsoring:
>>>> 
>>>> TURN URI:
>>>> http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris STUN URI:
>>>> http://tools.ietf.org/html/draft-nandakumar-rtcweb-stun-uri
>>>> 
>>>> To provide a bit of context this all began with Marc Petit-Hugenin six
>>>> years ago attempting to standardize the TURN URI scheme in the BEHAVE WG.
>>>> At that time there were no applications of this on the Internet, so it
>>>> was deemed premature and remained a draft. Recently, the need for a
>>>> standard URI scheme for TURN and STUN has arisen in the context of
>>>> RTCWeb.  Cullen (on Cc:) pointed this out and under his guidance we
>>>> produced the drafts referenced above. These drafts are now normatively
>>>> referenced by the W3C (http://www.w3.org/TR/webrtc/ and
>>>> http://dev.w3.org/2011/webrtc/editor/webrtc.html) and have already been
>>>> implemented in Google (Chrome) in their current STUN/TURN server
>>>> configuration code and is in the process of being implemented by Mozilla
>>>> (Firefox).
>>>> 
>>>> Over the years the TURN draft (and much later the STUN draft) have
>>>> received feedback from both the BEHAVE and RTCWEB WGs and we feel they
>>>> are nearing completion. We certainly would welcome any additional
>>>> feedback but more practically in the context being progressed within the
>>>> IETF to RFC status.  Please let us know how we can facilitate this and if
>>>> there is anything we can do make this as expeditious and painless for you
>>>> guys as possible.
>>>> 
>>>> Sincere thanks for all your help and guidance.
>>>> 
>>>> Cheers,
>>>> 
>>>> Gonzalo
>>>> 
>>>>       
>>>     
>> 
>> - -- Marc Petit-Huguenin
>> Email: [email-masked]
>> Blog: http://blog.marc.petit-huguenin.org
>> Profile: http://www.linkedin.com/in/petithug
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.12 (GNU/Linux)
>> 
>> iQIcBAEBCAAGBQJQ5G0mAAoJECnERZXWan7EP6IP/0eylpav+SHT3DzVrZ6IvdYr
>> zkBSb+8osVPHYXkC8BXHBE5cT/9SKYvfLRMMMX4X92ILIGpeVeWF9SDMNuxGAGsG
>> QIE3gWZErhrF3m3JBkbHxG+un6IW0DPlKBGj4/ZL3+eVueMQVL+lxIPyGorgwJEi
>> YAjvxuTzmrT3NjujC2qPqlPqphdlq/bJK89sSCsH7pY68THZUIcWTSIhzq446NFB
>> B+utwPoPI2Rubyx9AR6uMWSPAjB7x5uGzE2DP8B5ZU55qq4iAGPup6qFGHOWHvXE
>> q9WoqX0zXjNFNYEIC/DLYZI99WCPN0Ouj5GYtZklHK7cKcngknNNw5T8tz6jPBj9
>> kiQbC2YjoXVZ9Gk3B/XAdk4BBDz6jDzo+q1N0WkgCIwGITn6xg9tOIVei6CwgC2i
>> mDXT6HwVgXHjSwXYNBkRTuTmUZlJmd3A5bl8wdx3XVe0dtcTEkJAdk6F/ScBFXz1
>> Ah2XB8OdqaCd5YyBbdYXMEcDmztsS9THdVhSd3IlHmAtGtj0nYyvkLuKdKsBfrCM
>> bKkfuvpjLOFk8kmkEu0zgtsGA9JA2ROkk0nKeMoJhBkSAJY4Y8qMSxWoJbegyJ5C
>> k8TePgYMGO8aROFI6+iC0+ekcinc3CPeen/MnneNH1t9+Zvk00/X9t8bCSizLLFt
>> mDdyOAv6Stfiax/sMFHa
>> =gCwm
>> -----END PGP SIGNATURE-----
>>   
> 
> -- 
> Pete Resnick<http://www.qualcomm.com/~presnick/>
> Qualcomm Technologies, Inc. - +1 (858)651-4478
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 10 Jan 2013 00:25:04 +0100

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

>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:[email-masked] · 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/

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 09 Jan 2013 16:14:27 -0800

Hi Bjoern,

Thanks for the review.  See my responses inline.

On 01/09/2013 03:25 PM, Bjoern Hoehrmann wrote:
>> TURN URI: http://tools.ietf.org/html/draft-petithuguenin-behave-turn-uris
>> 
> 
> 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.

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

> 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