Hi Martin, On 06/12/2012 10:49 AM, "Martin J. Dürst" wrote: > 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'm looking into this since a number of people seem to want it and it does have some real value. My main concern is with adding it is to see if it can be done without over-complicating a basic implementation. The danger would be that we'd say "you MUST be able to verify name-data integrity for any MIME Content Type" which'd get hard quickly. I expect we'll shoot out a proposal for how ct could be included at the end of IETF LC. (We may still argue against, but we'll likely float a version including it in any case.) >>>>> 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. Right. A few people seem to prefer it like that. We prefer it as is. I agree with you that this isn't significant so I'd really rather go with the running code here. Cheers, S. > > Regards, Martin. > >