On 06/08/2012 01:35 AM, Jonathan A Rees wrote:
On Thu, Jun 7, 2012 at 3:15 PM, Stephen Farrell
On 06/06/2012 09:33 PM, Jonathan A Rees wrote:
As requested I am sending comments on this last call draft to
ietf(_at_)ietf(_dot_)org. I sent them to the authors on 6 May but received
Once again, sorry about that. No idea why I missed responding,
your mail is in my client even. Ah well.
---------- Forwarded message ----------
From: Jonathan A Rees <rees(_at_)mumble(_dot_)net>
Date: Sun, May 6, 2012 at 7:57 PM
Subject: comments on http://tools.ietf.org/html/draft-farrell-decade-ni-06
To: Alexey Melnikov <alexey(_dot_)melnikov(_at_)isode(_dot_)com>, Barry
<barryleiba(_at_)computer(_dot_)org>, "S. Farrell"
"P. Hallam-Baker" <pbaker(_at_)verisign(_dot_)com>
Here are some opinions on
I think this URI scheme would be a welcome addition to web
architecture. Wide review should be sought, because this might become
quite important and if there are problems they will be very difficult
to fix later.
I think using .well-known is a good idea.
I think integration into the ecosystem, such as browser support,
should be anticipated; for this reason I think content type should be
elevated from an 'optional feature' to a 'required feature'.
[i.e. conformant implementations must support it, even if providing
the content type in the URI is itself optional.]
I could certainly live with that, and I suspect my co-authors too,
but I'd need to ask 'em. However, we'd like to see more support for
it before doing that. If we only hear from you on this, then I
think leaving it in the other draft would be right. (See below
for why we want to keep that draft.) I guess others have a few
weeks to chime in on this.
OK, I suspect I can find other W3C TAG members who would agree; will
Great. Just note though that in figuring rough consensus its
not really useful for a bunch of (esp. previously unknown)
people to just say "+1" to something. A note like yours that
shows they've read the draft and have their own comment is
much more useful. (Its happened in the past that quite
well-meaning folks have jumped in like that and with no
context it makes it hard for anyone to figure what to make
It is certainly strongly promoted by the W3C web architecture document, see
so I think I have W3C consensus (as of 2005) behind my claim.
Well I could argue that that says that protocols SHOULD
do stuff and we're just defining the URI here and not a
protocol. But let's see if we get more input on this.
don't do this, you are just encouraging sniffing and privilege
escalation attacks. Sniffing would be a big step backwards. Better to
do what the data: scheme does and say that there is a default content
type of, say, text/plain, and that otherwise the content type ought to
be specified in the URI.
Content-type privilege escalation risk (and incorrect sniffing risk)
should be mentioned in the security considerations section in any
Would appreciate text if you can offer some. (Always happy to
make the sec. cons. bit better.)
Hmm. Hot potato.
Maybe something can be derived from Adam's draft
which I assume you've seen... obviously I'd prefer you do the
drafting, but will consider myself pressured.
I look forward to seeing that text then:-)
Maybe the risk that the host used for retrieval might be spoofing the
content-type (by providing a bogus content-type in an HTTP response)
should also be mentioned.
Good one. Yep, we should mention this whereever ct= is described
No, this is a threat even if ct= isn't used. Suppose that the document
is intended as an unscriptable media type, but the (malicious) server
sets the content-type: header in the response to a scriptable type.
Not good. I think this threat is described in Adam's draft.
(A possible design would be to put the
content-type (and maybe other headers like Expires:?) in the hashed
content, to be pulled out into the HTTP response when the content is
served by an http server and then checked by the client, but I
understand that this would be a tooling headache.)
Yep. We thought about it but agree that it gets too complex too
quickly. Maybe with a bit of experience...
(I don't understand why you want to separate the 'optional' features
into a separate spec. This made me miss the ct= feature entirely at
The intent is to put stuff there if we're not sure if its
ready or needed everywhere. ct= is definitely the main
candidate feature for moving to the "base" spec though.
Some other things (e.g. handling dynamic content) are
way more experimental and should definitely not move
and maybe need more time before we want them in an RFC.
If all this does get popular then the RFCs can be revised later
based on experience in any case. (If nobody cares, then it
won't be a problem:-) So I don't think where things are
documented now is hugely important in the long term.
Hmm... if this spec takes off like I hope it will, you will have more
influence than you think now, so the implicit messages will be
important... by putting ct= in a separate document you're saying that
it's not important, and you'll encourage implementations that use
sniffing instead of some rational way to convey the media type.
Maybe, maybe not. What's more important is what gets used
IMO. Again, let's see if we get more input.
I think the documentation should say that the hash and content type
together identify the resource,
Well, IMO the hash identifies the resource (if name-data integrity
is verified) so I don't think I agree that the content type is
key for identification. It is for interpretation (or whatever
the right term there is, maybe rendering?) and probably other
Well maybe we're quibbling over terminology, but in the HTTP spec and
in all the W3C documents, the media type is part of the resource (or
"representation" in HTTPbis; the distinction is immaterial for your
URI scheme), and therefore part of its identity.
Immaterial for this scheme is the bit that I like:-) So yes
we don't need to solve any philosophical problems now.
It would be
unfortunate to introduce an incompatible world view into the RFC
The RFC corpus has lots of good and lots of dodgy stuff and is
not a bible.
and that because the content can be
verified, the resource can be sought (using the .well-known path, or
any other path for that matter) from any source that the client thinks
might have it.
Absolutely. That's our primary motivation for all this.
The primary and alternate domain name(s), and 'wrapped'
URLs, are only provided as hints.
I agree with other commenters on the peculiarity of using // to
provide the location hint since the named host is not being trusted as
an authority. I don't understand why the 'primary' location isn't just
encoded in the query, just like the alternate domain(s) and "wrapped
URL(s)". This would have the nice property that you can put the
identifying parts (i.e. hash and content type) first, and the less important
location hints parts all together after the identification. The various
location hints (whether primary or secondary) would go together and
their similarity would be clearer.
(Unless I'm misunderstanding something and the part after the //
actually has status other than a hint? That would seem to defeat
I think we could argue this (and we did already between the authors;-)
and it'd come down to "pick a way." We did already and wrote code
for that, so we'd prefer to stick with it as-is, especially if there's
no compelling reason to change. I think its likely we can agree that
there's no compelling differences here in whether we use "//" or
a "?loc=" or whatever.
Well, you have a chance to fix this now, and it will be impossible to
Its true we won't be able to change this later but not true
IMO that any fix is needed, now or later.
Using // is contrary to RFC 3986, which very clearly says
"governance of the name space defined by the remainder of the URI is
delegated to that authority". This is certainly not what this URI
scheme does, so use of // is contrary to the appicable normative spec.
I disagree. The full quote there is:
"Many URI schemes include a hierarchical element for a naming
authority so that governance of the name space defined by the
remainder of the URI is delegated to that authority (which may, in
turn, delegate it further)."
There are no SHOULDs nor MUSTs there with which we're not
complying, and "many" != "all." Yes, ni URIs differ in some
respects from HTTP URLs, but if they didn't then this draft
wouldn't be needed, so that's ok.