Re: Last Call: <draft-nandakumar-rtcweb-stun-uri-05.txt> (URI Scheme for

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?

#g
--


On 15/08/2013 11:04, Harald Alvestrand wrote:
> On 08/15/2013 11:04 AM, Graham Klyne wrote:
> > Hi Harald,
> >
> > On 14/08/2013 19:49, Harald Alvestrand wrote:
> > > On 08/13/2013 12:14 AM, 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.
> > > >
> > > > 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.
> > > 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.
> > 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?
>
> > > > ...
> > > >
> > > > 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.
> > > 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.
> > 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.