Subject: Last Call: <draft-nandakumar-rtcweb-stun-uri-05.txt> (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard

From: Graham Klyne <[email-masked]>
Date: Mon, 12 Aug 2013 23:14:53 +0100

> From: The IESG <[email-masked]>
> To: IETF-Announce <[email-masked]>
> Reply-To: [email-masked]
> Sender: <[email-masked]>
> Subject: Last Call: <draft-nandakumar-rtcweb-stun-uri-05.txt> (URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to Proposed Standard
>
>
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'URI Scheme for Session Traversal Utilities for NAT (STUN) Protocol'
>   <draft-nandakumar-rtcweb-stun-uri-05.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2013-08-16. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>   This document is the specification of the syntax and semantics of the
>   Uniform Resource Identifier (URI) scheme for the Session Traversal
>   Utilities for NAT (STUN) protocol.
>
>
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-stun-uri/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-nandakumar-rtcweb-stun-uri/ballot/
>
>
> No IPR declarations have been submitted directly on this I-D.

As IANA designated expert for reviewing URI scheme registrations, I've been 
asked to approve this scheme for registration.  If there is IETF consensus to 
publish this document, it is clear to me that the scheme should be registered.

But, in a personal capacity, not as designated reviewer, I have to ask *why* 
this needs to be a URI.  As far as I can tell, it is intended for use only in 
very constrained environments, where there seems to be little value in having an 
identifier that can appear in all the contexts where a URI may be recognized.

The criteria for new URI schemes in http://tools.ietf.org/html/rfc4395 include:

"New URI schemes SHOULD have clear utility to the broad Internet community, 
beyond that available with already registered URI schemes."
-- http://tools.ietf.org/html/rfc4395#section-2.1

This "utility to the broader community" is not clear to me, but I don't fully 
understand the intended scope of this protocol, so I could be missing something. 
  So, in declaring consensus for this specification, I would request that this 
aspect at least be considered.

...

Further, according to http://tools.ietf.org/html/rfc5389 it appears that there 
are security considerations with regard to the STUN protocol that it should not 
be used in isolation:
[[
    Classic STUN also had a security vulnerability -- attackers could
    provide the client with incorrect mapped addresses under certain
    topologies and constraints, and this was fundamentally not solvable
    through any cryptographic means.  Though this problem remains with
    this specification, those attacks are now mitigated through the use
    of more complete solutions that make use of STUN.

    For these reasons, this specification obsoletes RFC 3489, and instead
    describes STUN as a tool that is utilized as part of a complete NAT
    traversal solution.
]]
-- http://tools.ietf.org/html/rfc5389#section-2

It seems to me that creating a URI for STUN could encourage its use in 
environments outside the "more complete solutions that make use of STUN".  This 
seems to be further reason that STUN[S] should not be a URI scheme.

I have also suggested that, if registered, the URI scheme registration should 
carries a "health warning" to this effect, and that it is not suitable for 
general use that is not part of a "complete NAT traversal solution".  But I also 
recognize that I do not fully grasp the security implications, and that if those 
that do know better can agree that there is no potential for creating security 
risks here, this suggestion may be unnecessary.

#g
--

---

From: S Moonesamy <[email-masked]>
Date: Tue, 13 Aug 2013 12:03:49 -0700

At 15:14 12-08-2013, Graham Klyne wrote:
>But, in a personal capacity, not as designated reviewer, I have to 
>ask *why* this needs to be a URI.  As far as I can tell, it is 
>intended for use only in very constrained environments, where there 
>seems to be little value in having an identifier that can appear in 
>all the contexts where a URI may be recognized.

This is an individual comment.  I reviewed 
draft-petithuguenin-behave-turn-uris-05.  I wondered why a URI was 
needed given the limited use.  The same argument is applicable for 
draft-nandakumar-rtcweb-stun-uri-05.  There is running code for both 
drafts.  Both draft qualify for "DNP".  I would describe the 
proposals as trying to fit the solution within a URI instead of 
designing a URI scheme.  Both proposals sound like UNSAF.

Regards,
S. Moonesamy

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Aug 2013 20:49:43 +0200

On 08/13/2013 12:14 AM, Graham Klyne wrote:
>> Subject: Last Call: <draft-nandakumar-rtcweb-stun-uri-05.txt> (URI 
>> Scheme for Session Traversal Utilities for NAT (STUN) Protocol) to 
>> Proposed Standard
>>
>>
> As IANA designated expert for reviewing URI scheme registrations, I've 
> been asked to approve this scheme for registration.  If there is IETF 
> consensus to publish this document, it is clear to me that the scheme 
> should be registered.
>
> But, in a personal capacity, not as designated reviewer, I have to ask 
> *why* this needs to be a URI.  As far as I can tell, it is intended 
> for use only in very constrained environments, where there seems to be 
> little value in having an identifier that can appear in all the 
> contexts where a URI may be recognized.
>
> "New URI schemes SHOULD have clear utility to the broad Internet 
> community, beyond that available with already registered URI schemes."
> This "utility to the broader community" is not clear to me, but I 
> don't fully understand the intended scope of this protocol, so I could 
> be missing something.  So, in declaring consensus for this 
> specification, I would request that this aspect at least be considered.

I can only give  my personal opinion....

1) This is a format for a piece of data. This data cannot be expressed 
using any existing URI scheme - indeed, I don't think there exists 
another well-defined textual representation of this piece of data.

1) This is defining an identifier that will be used in W3C-defined APIs. 
W3C tends to use URIs every time they want a self-defining piece of data 
with a clearly defined structure.
In the particular API where this is wanted, one wants to have STUN URIs, 
TURNS URIs and TURN URIs passed over the same interface. Thus, keeping 
with the W3C tradition of URIs seems reasonable.

I think this answers the question about "utility to the broader 
community" to my satisfaction - your mileage may differ, of course.

>
> ...
>
> Further, according to http://tools.ietf.org/html/rfc5389 it appears 
> that there are security considerations with regard to the STUN 
> protocol that it should not be used in isolation:
> [[
> environments outside the "more complete solutions that make use of 
> STUN".  This seems to be further reason that STUN[S] should not be a 
> URI scheme.
>
> I have also suggested that, if registered, the URI scheme registration 
> should carries a "health warning" to this effect, and that it is not 
> suitable for general use that is not part of a "complete NAT traversal 
> solution".  But I also recognize that I do not fully grasp the 
> security implications, and that if those that do know better can agree 
> that there is no potential for creating security risks here, this 
> suggestion may be unnecessary.

This URI scheme does not represent STUN. It represents configuration 
data that is used to initialize a protocol machine that utilizes STUN.

This configuration data has to be passed no matter what the format of 
the data is - whether it be URI or not.

Thus, I do not think the argument raised is really relevant to the 
context. The data will be passed, and registering an URI scheme will 
cause no more and no less data to be passed.

Again, my opinion.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 14 Aug 2013 20:51:45 +0200

On 08/13/2013 09:03 PM, S Moonesamy wrote:
> drafts.  Both draft qualify for "DNP".  I would describe the proposals 
> as trying to fit the solution within a URI instead of designing a URI 
> scheme.  Both proposals sound like UNSAF.

FWIW, UNSAF = Unilateral Self Address Fixing, or "figuring out what my 
address is on the Internet", and is exactly what STUN is useful for.

In a world of NATs, UNSAF is, unfortunately, a necessary thing to do. 
These URI schemes allow us to pass configuration data for performing 
these operations in a standardized form.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Aug 2013 12:04:49 +0200

On 08/15/2013 11:04 AM, Graham Klyne wrote:
> Hi Harald,
>
> On 14/08/2013 19:49, Harald Alvestrand wrote:
> [...]
>>> ask *why*
>>> very constrained environments, where there seems to be little value 
>>> in having
>>> an identifier that can appear in all the contexts where a URI may be 
>>> recognized.
>>>
>>> The criteria for new URI schemes in 
>>> http://tools.ietf.org/html/rfc4395 include:
>>>
>>> community,
>>> don't fully
>>> understand the intended scope of this protocol, so I could be missing
>>> something.  So, in declaring consensus for this specification, I 
>>> would request
>>> that this aspect at least be considered.
>>
>> 1) This is a format for a piece of data. This data cannot be 
>> expressed using any
>> existing URI scheme - indeed, I don't think there exists another 
>> well-defined
>> textual representation of this piece of data.
>>
>> 1) This is defining an identifier that will be used in W3C-defined 
>> APIs. W3C
>> tends to use URIs every time they want a self-defining piece of data 
>> with a
>> In the particular API where this is wanted, one wants to have STUN 
>> URIs, TURNS
>> URIs and TURN URIs passed over the same interface. Thus, keeping with 
>> the W3C
>> tradition of URIs seems reasonable.
>>
>> community" to my
>> satisfaction - your mileage may differ, of course.
>
> Some thoughts occur to me:
>
> 1. My reading was that this is a generic NAT traversal protocol, so 
> the requirement here is not Web/W3C specific.  But you do say "used in 
> W3C-defined APIs"...

Truth in advertising: One W3C-defined API.
The specific reference:

http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtciceserver-members

>
> 2. If this is being driven by W3C activities, this should probably be 
> flagged with W3C TAG.  I'll raise it there.
>
> 3. URIs are not generally used as *data* formats, but rather as 
> identifiers for resources.  Web architecture and REST principles tend 
> to discourage information encoded in URIs in favour of data 
> representation formats.  Cf. 
> http://www.w3.org/TR/webarch/#uri-opacity, 
> http://www.w3.org/2001/tag/doc/metaDataInURI-31.html

Well, it is. The data encoded is the identification of a STUN server, 
which is a resource.

>
> 4. If the purpose here is simply to encode data, then there does 
> already exist a suitable URI scheme, viz data:.  A new content type 
> can be defined to actually encode the required data, and the whole be 
> wrapped in a data: URI.  This approach has the advantage that 
> alternative mechanisms (other than URIs) can be used to transfer the 
> traversal data if required (though that may be moot in the very 
> restricted intended scope of deployment for stun:, etc.)

Yes, but why?

>>> that there
>>> are security considerations with regard to the STUN protocol that it 
>>> should
>>> not be used in isolation:
>>> [[
>>> STUN".
>>> This seems to be further reason that STUN[S] should not be a URI 
>>> scheme.
>>>
>>> general use that is not part of a "complete NAT traversal 
>>> solution".  But I
>>> also recognize that I do not fully grasp the security implications, 
>>> and that
>>> if those that do know better can agree that there is no potential 
>>> for creating
>>> security risks here, this suggestion may be unnecessary.
>>
>> data that
>> is used to initialize a protocol machine that utilizes STUN.
>>
>> context. The
>> data will be passed, and registering an URI scheme will cause no more 
>> and no
>> less data to be passed.
>>
>> Again, my opinion.
>>
>
> If the URI is used only in very constrained contexts, then I agree.
>
> But the whole point of using a URI is that, due to URI opacity, it can 
> be used a a range of contexts where URIs are used.  If it cannot 
> properly be used in those other contexts, I have to question if it 
> really is a URI, as opposed to a string that happens to look like a URI.

The subject of "if it really is an URI" has plagued the whole URI space 
since day one. My current opinion is that if it looks like an URI, and 
parses according to the URI spec, it should probably be called an URI.

So far, we know of one context where we need this (RTCWEB). It's the 
first context I know of where the Web and STUN intersect. It's not 
certain that it'll be the last one.

>
> I also note that this looks as if it may fall foul of the 
> "confidential metadata" practice noted in the W3C TAG finding about 
> metadata in URIs 
> (http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#hideforsecurity)

That's why we took the "credentials" part out of the URI scheme.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Aug 2013 09:16:00 -0400

I agree with Harald.

Both the STUN and TURN URIs really do represent what we traditionally use URIs for: they identify a physical resource, a protocol for accessing the resource, etc.  Unlike a data URL, the STUN/TURN URI is not locally/directly self-contained data - it's a resource identifier, only meaningful when resolved and accessed using the scheme's protocol and host address, with whatever attributes are encoded in the URI.

Today only W3C has an immediate need for it, for the Javascript API for WebRTC, but one can envision this might be used by others as well in the future:

1) SIP might use this in a UA-config profile to tell a SIP client what STUN/TURN resources to use, or even in a REGISTER response someday.

2) XMPP might use this someday to indicate to clients what STUN/TURN servers to use for Jingle/etc.  Today it's done with a 'services' element I think, but it could be changed in the future.

3) BEHAVE WG might define a new DHCP option to tell DHCP clients a STUN/TURN server to use, in which case they could use this URI for that. (I don't know if BEHAVE's already done that, or decided not to do such a thing, but just sayin' it's another potential use-case)

It's possible other protocols might use this as well someday, for example RTSP or H.323.  I'm not saying any of them *will*, but it's possible.

-hadriel

On Aug 15, 2013, at 6:04 AM, Harald Alvestrand <[email-masked]> wrote:

>>>> very constrained environments, where there seems to be little value in having 
>>>> an identifier that can appear in all the contexts where a URI may be recognized. 
>>>> 
>>>> something.  So, in declaring consensus for this specification, I would request 
>>> 1) This is a format for a piece of data. This data cannot be expressed using any 
>>> existing URI scheme - indeed, I don't think there exists another well-defined 
>>> 1) This is defining an identifier that will be used in W3C-defined APIs. W3C 
>>> tends to use URIs every time they want a self-defining piece of data with a 
>>> clearly defined structure. 
>>> In the particular API where this is wanted, one wants to have STUN URIs, TURNS 
>>> URIs and TURN URIs passed over the same interface. Thus, keeping with the W3C 
>>> I think this answers the question about "utility to the broader community" to my 
>> 1. My reading was that this is a generic NAT traversal protocol, so the requirement here is not Web/W3C specific.  But you do say "used in W3C-defined APIs"... 
> 
>> 2. If this is being driven by W3C activities, this should probably be flagged with W3C TAG.  I'll raise it there. 
>> 
>> 3. URIs are not generally used as *data* formats, but rather as identifiers for resources.  Web architecture and REST principles tend to discourage information encoded in URIs in favour of data representation formats.  Cf. http://www.w3.org/TR/webarch/#uri-opacity, http://www.w3.org/2001/tag/doc/metaDataInURI-31.html 
> 
> Well, it is. The data encoded is the identification of a STUN server, which is a resource.
> 
>> 
>> 4. If the purpose here is simply to encode data, then there does already exist a suitable URI scheme, viz data:.  A new content type can be defined to actually encode the required data, and the whole be wrapped in a data: URI.  This approach has the advantage that alternative mechanisms (other than URIs) can be used to transfer the traversal data if required (though that may be moot in the very restricted intended scope of deployment for stun:, etc.) 
> 
> Yes, but why?
> 
>> 
>>>> 
>>>> ... 
>>>> 
>>>> are security considerations with regard to the STUN protocol that it should 
>>>> environments outside the "more complete solutions that make use of STUN". 
>>>> This seems to be further reason that STUN[S] should not be a URI scheme. 
>>>> 
>>>> general use that is not part of a "complete NAT traversal solution".  But I 
>>>> also recognize that I do not fully grasp the security implications, and that 
>>>> if those that do know better can agree that there is no potential for creating 
>>> This URI scheme does not represent STUN. It represents configuration data that 
>>> This configuration data has to be passed no matter what the format of the data 
>>> is - whether it be URI or not. 
>>> 
>>> Thus, I do not think the argument raised is really relevant to the context. The 
>>> data will be passed, and registering an URI scheme will cause no more and no 
>>> less data to be passed. 
>>> 
>>> Again, my opinion. 
>>> 
>> 
>> But the whole point of using a URI is that, due to URI opacity, it can be used a a range of contexts where URIs are used.  If it cannot properly be used in those other contexts, I have to question if it really is a URI, as opposed to a string that happens to look like a URI. 
> 
> The subject of "if it really is an URI" has plagued the whole URI space since day one. My current opinion is that if it looks like an URI, and parses according to the URI spec, it should probably be called an URI.
> 
> So far, we know of one context where we need this (RTCWEB). It's the first context I know of where the Web and STUN intersect. It's not certain that it'll be the last one.
> 
>> 
>> I also note that this looks as if it may fall foul of the "confidential metadata" practice noted in the W3C TAG finding about metadata in URIs (http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#hideforsecurity) 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Aug 2013 10:01:11 -0400

Some comments on this STUN draft and the TURN one:

1) The ABNF in these drafts leaves no room for future extension such as adding parameters.  Was that intentional?

2) Why do both of these docs repeat a lot of ABNF from RFC 3986, instead of just referencing it?  It says in the appendix some ABNF was repeated because RFC 3986 "are for hierarchical URIs".  I'm not exactly sure what that means other than you don't have a path component, but as far as I can tell the copied ABNF components in these STUN/TRUN drafts are verbatim copies of RFC 3986, all the way down to their final expansion.  

For example, 'IP-literal' and all of its sub-defined parts ('IPv6address', 'IPvFuture', 'h16', 'ls32') appear identical to those in RFC 3986.  In fact, so is 'stun-host' and 'turn-host' - it's just RFC 3986 'host' by another name.  Am I missing something?

Why not just have this:
   stunURI       = scheme ":" stun-host [ ":" stun-port ]
   scheme        = "stun" / "stuns"
   stun-host     = host      ;see section 3.2.2 of [RFC3986]
   stun-port     = port      ;see section 3.2.3 of [RFC3986]

Not a big deal, but it just seems simpler and cleaner to me to not repeat ABNF from other RFCs, especially when the RFC in question is the one for general URI syntax and you're defining a specific URI syntax based on it.

-hadriel

On Aug 12, 2013, at 6:14 PM, Graham Klyne <[email-masked]> wrote:

> As IANA designated expert for reviewing URI scheme registrations, I've been asked to approve this scheme for registration.  If there is IETF consensus to publish this document, it is clear to me that the scheme should be registered.
> 
> But, in a personal capacity, not as designated reviewer, I have to ask *why* this needs to be a URI.  As far as I can tell, it is intended for use only in very constrained environments, where there seems to be little value in having an identifier that can appear in all the contexts where a URI may be recognized.
> 
> "New URI schemes SHOULD have clear utility to the broad Internet community, beyond that available with already registered URI schemes."
> This "utility to the broader community" is not clear to me, but I don't fully understand the intended scope of this protocol, so I could be missing something.  So, in declaring consensus for this specification, I would request that this aspect at least be considered.
> 
> ...
> 
> Further, according to http://tools.ietf.org/html/rfc5389 it appears that there are security considerations with regard to the STUN protocol that it should not be used in isolation:
> [[
> It seems to me that creating a URI for STUN could encourage its use in environments outside the "more complete solutions that make use of STUN".  This seems to be further reason that STUN[S] should not be a URI scheme.
> 
> I have also suggested that, if registered, the URI scheme registration should carries a "health warning" to this effect, and that it is not suitable for general use that is not part of a "complete NAT traversal solution".  But I also recognize that I do not fully grasp the security implications, and that if those that do know better can agree that there is no potential for creating security risks here, this suggestion may be unnecessary.
> 
> #g
> --

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Aug 2013 16:10:21 +0200

On 08/15/2013 04:05 PM, Graham Klyne wrote:
> Harald,
>
> Briefly:
>
> 1. Thanks for the reference,
>
> and
>
> 2. I misunderstood what you meant by "This is a format for a piece of
> data".  In light of your clarification, I withdraw my comments 3 & 4. 
> Identification of the STUN service would appear to be a perfectly
> reasonable use.
>
> ...
>
> So the remaining issues from my questions are whether the intended
> highly constrained use of these services justifies allocating a URI
> scheme.
>
> If the community consensus is that it is of sufficient value, I might
> suggest an annotation to the scheme registration along the lines of:
>
> "This URI scheme is intended for use in very specific NAT traversal
> environments, and should not be used otherwise on the open Web or
> Internet."
>
> Would such a comment run contrary to your expectations for its use?

I would prefer to run the comment as "This scheme is intended for use in
specific environments that involve NAT traversal. Users of the scheme
need to carefully consider the security properties of the context in
which they are using it."

Echoing the warning in the STUN scheme - "use this when you know what
you're doing only".

Frankly, like Hadriel indicated, I have no idea whether it will be
useful in other contexts or not, and I'm hesitant to put language that
seems to claim that we've evaluated all possible contexts and say that
there aren't other contexts in which it can be useful.

>
> #g
> -- 
>
>
> On 15/08/2013 11:04, Harald Alvestrand wrote:
>>> 1. My reading was that this is a generic NAT traversal protocol, so the
>>> requirement here is not Web/W3C specific.  But you do say "used in
>>> W3C-defined
>>> APIs"...
>>
>>> 2. If this is being driven by W3C activities, this should probably
>>> be flagged
>>> with W3C TAG.  I'll raise it there.
>>>
>>> identifiers
>>> for resources.  Web architecture and REST principles tend to discourage
>>> information encoded in URIs in favour of data representation
>>> formats.  Cf.
>> which is a
>> resource.
>>> already exist
>>> a suitable URI scheme, viz data:.  A new content type can be defined to
>>> actually encode the required data, and the whole be wrapped in a
>>> data: URI.
>>> This approach has the advantage that alternative mechanisms (other
>>> than URIs)
>>> can be used to transfer the traversal data if required (though that
>>> may be
>>> moot in the very restricted intended scope of deployment for stun:,
>>> etc.)
>>
>> Yes, but why?
>>
>>>
>>>>>
>>>>> ...
>>>>>
>>> But the whole point of using a URI is that, due to URI opacity, it
>>> can be used
>>> a a range of contexts where URIs are used.  If it cannot properly be
>>> used in
>>> those other contexts, I have to question if it really is a URI, as
>>> opposed to
>>> a string that happens to look like a URI.
>>
>> The subject of "if it really is an URI" has plagued the whole URI
>> space since
>> day one. My current opinion is that if it looks like an URI, and parses
>> according to the URI spec, it should probably be called an URI.
>>
>> first
>> context I know of where the Web and STUN intersect. It's not certain
>> that it'll
>> be the last one.
>>
>>>
>>> I also note that this looks as if it may fall foul of the "confidential
>>> metadata" practice noted in the W3C TAG finding about metadata in URIs

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Aug 2013 08:20:42 -0600

On 8/15/13 8:10 AM, Harald Alvestrand wrote:
> useful in other contexts or not, 

I tend to think not.

> and I'm hesitant to put language that
> seems to claim that we've evaluated all possible contexts 

Agreed.

> and say that

Too many negatives. :-) You are hesitant to say that it won't be useful
in other contexts, or you would prefer to say that it was designed for a
specific contexts and probably wouldn't be useful outside that context?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Aug 2013 16:24:46 +0200

> specific contexts and probably wouldn't be useful outside that context?

I'm hesitant to say that it won't be useful in other contexts - that is,
I'd prefer to say nothing about whether it will be useful elsewhere or not.

Others understand other contexts better than I do; if they come forward
(as Hadriel just did) and say "This is useful to me", I don't want the
draft to say "Sorry, but we decided you can't use it".

---

From: Graham Klyne <[email-masked]>
Date: Thu, 15 Aug 2013 10:04:23 +0100

Hi Harald,

[...]

1. My reading was that this is a generic NAT traversal protocol, so the 
requirement here is not Web/W3C specific.  But you do say "used in W3C-defined 
APIs"...

2. If this is being driven by W3C activities, this should probably be flagged 
with W3C TAG.  I'll raise it there.

3. URIs are not generally used as *data* formats, but rather as identifiers for 
resources.  Web architecture and REST principles tend to discourage information 
encoded in URIs in favour of data representation formats.  Cf. 
http://www.w3.org/TR/webarch/#uri-opacity, 
http://www.w3.org/2001/tag/doc/metaDataInURI-31.html

4. If the purpose here is simply to encode data, then there does already exist a 
suitable URI scheme, viz data:.  A new content type can be defined to actually 
encode the required data, and the whole be wrapped in a data: URI.  This 
approach has the advantage that alternative mechanisms (other than URIs) can be 
used to transfer the traversal data if required (though that may be moot in the 
very restricted intended scope of deployment for stun:, etc.)

But the whole point of using a URI is that, due to URI opacity, it can be used a 
a range of contexts where URIs are used.  If it cannot properly be used in those 
other contexts, I have to question if it really is a URI, as opposed to a string 
that happens to look like a URI.

#g
--

---

From: Graham Klyne <[email-masked]>
Date: Thu, 15 Aug 2013 15:05:29 +0100

Harald,

Briefly:

and

2. I misunderstood what you meant by "This is a format for a piece of data".  In 
light of your clarification, I withdraw my comments 3 & 4.  Identification of 
the STUN service would appear to be a perfectly reasonable use.

...

So the remaining issues from my questions are whether the intended highly 
constrained use of these services justifies allocating a URI scheme.

If the community consensus is that it is of sufficient value, I might suggest an 
annotation to the scheme registration along the lines of:

"This URI scheme is intended for use in very specific NAT traversal 
environments, and should not be used otherwise on the open Web or Internet."

#g
--

On 15/08/2013 11:04, Harald Alvestrand wrote:
>> 3. URIs are not generally used as *data* formats, but rather as identifiers
>> information encoded in URIs in favour of data representation formats.  Cf.
>> 4. If the purpose here is simply to encode data, then there does already exist
>> actually encode the required data, and the whole be wrapped in a data: URI.
>> This approach has the advantage that alternative mechanisms (other than URIs)
>> can be used to transfer the traversal data if required (though that may be
>> moot in the very restricted intended scope of deployment for stun:, etc.)
>
> Yes, but why?
>
>>
>>>>
>>>> ...
>>>>
>> But the whole point of using a URI is that, due to URI opacity, it can be used
>> a a range of contexts where URIs are used.  If it cannot properly be used in
>> those other contexts, I have to question if it really is a URI, as opposed to
> The subject of "if it really is an URI" has plagued the whole URI space since
> So far, we know of one context where we need this (RTCWEB). It's the first
> context I know of where the Web and STUN intersect. It's not certain that it'll
> be the last one.
>
>>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 16 Aug 2013 07:54:17 -0700

Hi Hadriel,

Note that the STUN URIs design is based on the TURN URI design, which was
discussed back in 2008-2009.  See my answers below.

> adding parameters.  Was that intentional?

Yes.  There is two very different kind of parameters in an URI:

1. Parameters that are used to guide the selection of the resource (basically
parameters that are input to RFC 5766 and RFC 5928).  The BEHAVE WG decided in
Dublin to not support this[1] (i.e. to not have either URI parameters or their
counterpart in the DNS).

2. Other parameters that are not used to guide the selection but that are used
by the protocol, e.g. "username",  "password", etc...  "password" was removed
for security reasons.  It was decided (although I cannot find exactly when)
that these non-guiding parameters should not be part of a TURN URI, so
"username" was removed too, as was the "auth" parameter proposed recently
(i.e. all these parameters should be part of the WebRTC RTCIceServer dictionary).

Not supporting extensibility (i.e. not being able to add these parameters
later) was agreed by default also in Dublin (see slide 5 of [2]).  IIRC,
extensibility for the first kind of parameters was found too difficult (how
implementation reacts to a new parameter?).  Extensibility for the second type
of parameters would create less issues, but as they were rejected anyway on
principle, there was no point of having a way to add them later.

For the record, I still disagree with the decision of not supporting the first
kind of parameters (RFC 5928 was even designed to support TWIST ;-) ), but
that was the consensus at the time.  I still agree with not supporting the
second kind of parameters.

Note that only the second type of parameters would apply to STUN URIs, but
they were not permitted in STUN for symmetry with the TURN URIs.

[1] https://www.ietf.org/proceedings/72/minutes/behave.txt
[2] https://www.ietf.org/proceedings/72/slides/behave-0.pdf

> 
> 2) Why do both of these docs repeat a lot of ABNF from RFC 3986, instead
> of just referencing it?  It says in the appendix some ABNF was repeated
> because RFC 3986 "are for hierarchical URIs".  I'm not exactly sure what
> that means other than you don't have a path component, but as far as I can
> tell the copied ABNF components in these STUN/TRUN drafts are verbatim
> copies of RFC 3986, all the way down to their final expansion.
> 
> For example, 'IP-literal' and all of its sub-defined parts ('IPv6address', 
> 'IPvFuture', 'h16', 'ls32') appear identical to those in RFC 3986.  In
> fact, so is 'stun-host' and 'turn-host' - it's just RFC 3986 'host' by
> another name.  Am I missing something?
> 
> Why not just have this: stunURI       = scheme ":" stun-host [ ":"
> stun-port ] scheme        = "stun" / "stuns" stun-host     = host      ;see
> section 3.2.2 of [RFC3986] stun-port     = port      ;see section 3.2.3 of
> [RFC3986]
> 
> Not a big deal, but it just seems simpler and cleaner to me to not repeat 
> ABNF from other RFCs, especially when the RFC in question is the one for 
> general URI syntax and you're defining a specific URI syntax based on it.

This was done back in 2009 during the first uri-review of the TURN URI,
following a comment by Ted Hardie.  The problem is that the TURN and STUN uris
are opaque URIs, but using these ABNF productions make them look like
hierarchical URIs, because these productions are defined in RFC 3986 only for
hierarchical URIs.  So the point was that developers may misinterpreting this
as meaning that TURN and STUN URIs can be parsed by a generic hierarchical
parser, which would be a very bad idea (as username and password would then be
parsed).

Version -06 will contain a more complete design note about this (we decided
that the design notes will stay in the RFC), here's the current version:

"o  The ABNF in this document duplicates the <IP-literal>,
    <IPv4address>, and <reg-name> productions and other dependent
    productions from [RFC3986], instead of referencing them.  This is
    because the definitions in RFC 3986 are for hierarchical URIs, so
    using these references in an opaque URI made reviewers think that
    a hierarchical URI parser could be used to parse the URIs defined
    in this document."

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Graham Klyne <[email-masked]>
Date: Fri, 16 Aug 2013 11:32:05 +0100

Hadriel,

I think you are making a fair case that this URI is more than just an internal 
string for use in a single protocol, which is the impression I got from the 
registration draft.

I think you're saying the URI schemes proposed provide ways for applications to 
be told about NAT-traversal resources they should use?  I can see that even if 
their in-use deployment is limited, the benefits can be relevant to a wider 
audience.

I think it would be useful if the URI scheme description could clarify that it 
is being used to identify a NAT traversal service (or something like that).

#g
--