Re: [decade] FW: Last Call: <draft-farrell-decade-ni-07.txt> (Naming Thi

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(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>  wrote:
> > > On 06/06/2012 09:33 PM, Jonathan A Rees wrote:
> > > > ---------- 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 Leiba
> > > > <barryleiba(_at_)computer(_dot_)org>, "S. 
> > > > Farrell"<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>,
> > > > "P. Hallam-Baker"<pbaker(_at_)verisign(_dot_)com>
> > > >
> > > > 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(_at_)mumble(_dot_)net.
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.