Subject: [Uri-review] Two new URI schemes for review

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Apr 2012 16:56:52 +0100

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

---

From: Eric Johnson <[email-masked]>
Date: Fri, 4 May 2012 11:22:49 +0200

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/....?

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?

Can I compute a "sha-512" relative to the given URI? (Answer: no)

I conclude that this should not be a hierarchical scheme.

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:
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review

---

From: Ted Hardie <[email-masked]>
Date: Fri, 4 May 2012 07:44:23 -0700

Hi Eric,

I had some similar questions about this, but I believe this text in Section 3:

      The optional authority component may assist
      applications in accessing the object named by an ni URI.

provides the explanation.  They are using the hierarchical portion to indicate
where you might access the object named by the non-hierarchical portion.

While this is probably okay, it suffers a bit from the lack of an
access method being indicated within the URI.  The provided method
(using .well-known and HTTP) could have been made extensible by
shifting the access method into a parameter.

Note that this is not an objection to the URI scheme going forward on
my part; it's a style preference for how to manage extensibility.

regards,

Ted

On Fri, May 4, 2012 at 2:22 AM, Eric Johnson <[email-masked]> wrote:
> a) Why is this being done as a "hierarchical" URI scheme, when the URI is
> not, in fact, hierarchical?
>
> scheme, that should be a signal for them to associate meaning to "relative"
> URIs, as in:
>
> base URI:
> (where nhi I just made up, but stands for "named hashed id", because URNs
> require at least three letters for namespace ids)
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 05 May 2012 18:28:41 +0100

Thanks guys,

I'll take your (slightly conflicting:-) advice, I'll
go re-read the relevant RFCs and get back.

I've no particular attachment to the "//" other than
I'll have to change a bit of code if we change, but
that's more of an irritant, so doing the right thing
is the plan. I need to check with co-authors as well
though and of course decide for sure what I think the
right thing is:-)

On the URN thing - we were advised before that URNs
weren't suitable for this. Would have to go dig out the
reason for that but I think it was because we're naming
possibly very very many things. (But I don't want to
get in the middle of a urn/uri police bust-up:-)

In terms of hash algs, I'd rather keep the initial set
smaller since that gets better interop, so I will argue
against inclusion of other hash variants until they're
really needed.

S

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Sat, 05 May 2012 13:39:16 -0400

> though and of course decide for sure what I think the

Now, one more thing about that is, if you do in fact continue to use 
the "//" part, why is that part mandatory even if no authority 
section is used?  Why not just omit it in cases where there is no 
hostname, and start such URIs with no slashes or one slash after the 
colon (depending on whether a hierarchical path is involved)?

I know the "file:" URI scheme also requires the double slashes, which 
makes for a messy structure when the authority section is usually 
null and thus you have three slashes.  It would seem to have made 
more sense there too to omit the double slash when no hostname is 
needed, as was done with the "news:" URI, which can optionally 
specify a server with double slashes but can omit that part as well.

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 05 May 2012 18:58:45 +0100

> colon (depending on whether a hierarchical path is involved)?

Again, not something I feel strongly about but I'd say its
a teeny bit easier to code if the // is there always (assuming
it stays) and generally doesn't make much difference.

> specify a server with double slashes but can omit that part as well.

I guess for me these are just style things (e.g. whether /// is
"messy"), so we just picked a thing to do and wrote our code for
that.

I'm not sure if out choices will really help folks add support
for these new schemes to existing libraries/scripts or not, but
we figured it might so that's mostly why we aped other what's
already out there.

S.

PS: Sorry if I'm missing the importance of all this. If I am,
(and I am, if its actually important) then it needs to be
explained to me, which might be a fine offlist thing to do
if someone has the energy.

---

From: Graham Klyne <[email-masked]>
Date: Sun, 06 May 2012 08:37:40 +0100

On 04/05/2012 10:22, Eric Johnson wrote:
> a) Why is this being done as a "hierarchical" URI scheme, when the URI is not,
> in fact, hierarchical?
>

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
>

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
--

> 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.
>

---

From: Eric Johnson <[email-masked]>
Date: Mon, 7 May 2012 11:08:51 +0200

Hi Graham,

I'm not sure I see how your conclusion about treating this as a relative 
URI makes sense.

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.

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.

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:
> 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.
>
>> scheme,
> The answer to that is clear from RFC 3986:  
> ni://example.com/index.html ... even if it's not very useful.
>
> 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.
>
>> URNs

---

From: Graham Klyne <[email-masked]>
Date: Mon, 07 May 2012 21:38:06 +0100

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.

> 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.

> 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.
>
>> 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.
>>
>> The answer to that is clear from RFC 3986: ni://example.com/index.html ...
>> even if it's not very useful.
>>

---

From: Eric Johnson <[email-masked]>
Date: Tue, 8 May 2012 11:06:06 +0200

Hi Graham,

On 5/7/12 10:38 PM, Graham Klyne wrote:
> 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. 

Taking your point, perhaps at a minimum the proposal should document 
which hierarchical operations will yield a result with "a defined 
meaning according to the rules of the ni: scheme", and which ones won't. 
Especially so since the proposed scheme uses the "//" indicator which 
implies hierarchical operations, and we've already agreed that some such 
operations are meaningless.

Even simpler, though, would be to change the syntax to remove the 
indication of hierarchical syntax, since, as I understand it, *none* of 
the hierarchical operations possible will yield a useful result "having 
a defined meaning according to the rules of the ni: scheme." (Well, OK, 
some might have a defined result, but only in the sheer-dumb-luck sense 
that an infinite # of typing monkeys in an infinite time would 
eventually produce the works of Shakespeare.) But maybe I've 
misunderstood the proposal?

-Eric.

---

From: Graham Klyne <[email-masked]>
Date: Tue, 08 May 2012 13:12:28 +0100

On 08/05/2012 10:06, Eric Johnson wrote:
> Taking your point, perhaps at a minimum the proposal should document which
> hierarchical operations will yield a result with "a defined meaning according to
> the rules of the ni: scheme", and which ones won't. Especially so since the
> proposed scheme uses the "//" indicator which implies hierarchical operations,
> and we've already agreed that some such operations are meaningless.

Not quite: my original response suggested an application of this structure which 
might have useful meaning.  It's just your example that is not given a defined 
meaning by the ni: spec.

I think it's pretty clear which hierarchical operations have defined meaning: 
apply the resolution rule and see if the result has defined meaning per the 
spec.  (I suppose one might add a warning:  "Injudicious resolution of relative 
URI references with respect to an ni: base URI may yield an ni: URI whose 
interpretation is not defined by this specification.")

...

(I feel that I'm spending more time on this than the issue deserves.  I don't 
feel especially strongly that the scheme should be hierarchical or not, and 
hierarchical seems OK to me.  I mainly feel it's not worth changing a spec that 
others have thought about more deeply than I without a compelling reason.)

#g
--