Hello Stephen, others,
On 2012/06/08 20:21, Stephen Farrell wrote:
Hiya,
On 06/08/2012 01:35 AM, Jonathan A Rees wrote:
On Thu, Jun 7, 2012 at 3:15 PM, Stephen Farrell
<stephen.farrell@xxxxxxxxx> wrote:
On 06/06/2012 09:33 PM, Jonathan A Rees wrote:
---------- Forwarded message ----------
From: Jonathan A Rees<rees@xxxxxxxxxx>
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.melnikov@xxxxxxxxx>, Barry Leiba
<barryleiba@xxxxxxxxxxxx>, "S. Farrell"<stephen.farrell@xxxxxxxxx>,
"P. Hallam-Baker"<pbaker@xxxxxxxxxxxx>
Here are some opinions on
http://tools.ietf.org/html/draft-farrell-decade-ni-06 :
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.
It is certainly strongly promoted by the W3C web architecture document, see
http://www.w3.org/TR/webarch/#internet-media-type
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.
Sophistry is great, but security is better :-).
Seriously, (1) URIs can be seen as (extremely small) protocols, (2) they
are used in many protocols and formats, which might be better served
with having the content type being taken care off rather than having to
do it on their own, and (3) in order for the protocols to do the right
stuff, they need the right information.
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
the purpose.)
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
fix later.
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.
In my opinion, the decision on whether to use the authority part or not
is probably more a theoretical one than a practical one. Either way
seems to be fine. Strictly speaking on abstract "authority" grounds, the
mailto: URI could have used // because mumble.net is the authority for
mail to rees@xxxxxxxxxx.
But I agree with Jonathan that once we start putting other information
such as full URIs from which the resource can be retrieved, alternate
'authorities' where it may be available, and so on, after the hash, then
putting all that stuff there seems cleaner.
Regards, Martin.