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