Re: [Uri-review] draft-farrell-decade-ni

[Graham Klyne <[e-mail]>]

On 07/05/2012 10:08, Eric Johnson wrote:
> Hi Graham,
>
> I'm not sure I see how your conclusion about treating this as a relative URI
> makes sense.

It's a simple consequence of applying the resolution rules in RFC 3986.  That's 
all I claimed.

> If "ni://example.com/index.html" is the obvious result of the relative
> computation, but is in fact meaningless in the context of the definition of the
> scheme, then I don't think that's harmless result. The expectation of a
> hierarchical scheme seems to me that you can apply standard hierarchical
> manipulations, and get a new valid URI, even if there's no "there" there at the
> given endpoint.

Oh, it's a perfectly valid URI according to the rules of RFC3986, just not 
having a defined meaning according to the rules of the ni: scheme.  I don't 
think it's the task of a specification, or even possible, to catch and somehow 
prohibit every clueless operation that might be attempted.

> With the "ni" scheme as proposed, almost the whole universe of relative
> computations implied as allowed because of the "//" will result in URIs that are
> not actually valid according to the scheme definition. That seems ... harmful.

I'm not seeing the harm here.

#g
--

> For the work I did on the "jms" URI scheme, we also had to address the question
> of an "authority" for resolving some of the URIs, and we were able to readily
> incorporate that into a non-hierarchical scheme.
>
> -Eric.
>
> On 5/6/12 9:37 AM, Graham Klyne wrote:
>> On 04/05/2012 10:22, Eric Johnson wrote:
>>> I looked at this proposal, and had three points of confusion.
>>>
>>> a) Why is this being done as a "hierarchical" URI scheme, when the URI is not,
>>> in fact, hierarchical?
>>>
>>> That is, why ni://example.com/....?
>>
>> I think the document explains that.
>>
>> And I even have a possible use-case for this in an application I'm working on
>> - a hashed identifier where further information may be available from the
>> given authority.
>>
>>> When implementations that manipulate URIs encounter the :// after the scheme,
>>> that should be a signal for them to associate meaning to "relative" URIs, as in:
>>>
>>> base URI: ni://example.com/sha-256;f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
>>>
>>> ... what does it mean to do "index.html" relative to said URI?
>>
>> The answer to that is clear from RFC 3986: ni://example.com/index.html ...
>> even if it's not very useful.
>>
>>> Can I compute a "sha-512" relative to the given URI? (Answer: no)
>>
>> I'm not sure I understand the question, but one might want to express an
>> already-known sha-512 with respect to the same base.
>>
>>> I conclude that this should not be a hierarchical scheme.
>>
>> I don't see any harm, and some possible (small) benefits.
>>
>> #g
>> --
>>
>>> b) Why isn't this just a URN with a particular namespace identifier?
>>>
>>> As in:
>>>
>>> urn:nhi:example.com:sha-256:f4OxZX_x_FO5LcGBSKHWXfwtSx-j1ncoSt3SABJtkGk
>>>
>>> (where nhi I just made up, but stands for "named hashed id", because URNs
>>> require at least three letters for namespace ids)
>>>
>>> That seems like a better fit.
>>>
>>> c) Since there are more known SHA standards, why not declare them all in this
>>> initial proposal, so that sha-384, and sha-512 are already defined?
>>>
>>> -Eric.
>>>
>>> On 4/30/12 5:56 PM, Stephen Farrell wrote:
>>>> Hi,
>>>>
>>>> We have a draft [1] that requests two new URI schemes.
>>>>
>>>> The core WG are likely to want to use these we think
>>>> and possibly decade, but they're intended to be generally
>>>> useful as well.
>>>>
>>>> Barry Leiba is planning to AD sponsor this and Alexey
>>>> Melnikov will be shepherding so if you can cc them ase
>>>> well as the authors on any questions or comments that'd
>>>> be good.
>>>>
>>>> I hope the plan is to IETF LC this soon, once this
>>>> review and the .well-known registration review are
>>>> done.
>>>>
>>>> Thanks,
>>>> Stephen.
>>>>
>>>> [1] http://tools.ietf.org/html/draft-farrell-decade-ni-05
>>>> _______________________________________________
>>>> Uri-review mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/uri-review
>>> _______________________________________________
>>> Uri-review mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/uri-review
>>>
>>
> _______________________________________________
> Uri-review mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uri-review
>