So would it work to add this:
"
Note that relative ni URIs can occur, for example as shown in
Figure 5. In such cases, user agents MUST construct the absolute URI
as they would in the case of an HTTP URL, that is, in the example
shown the absolute URI for "this third document" would be
"ni://example.com/sha-256-128;...".
<html>
<head>
<title>ni: relative URI test</title>
<base href="ni://example.com">
</head>
<body>
<p>Please check <a href="sha-256;f4OxZX...">this document</a>.
And <a href="sha-256;UyaQV...">this other document</a>.
And <a href="sha-256-128;...">this third document</a>.
</p>
</body>
</html>
Figure 5: Example HTML with relative ni URI
"
Better suggestions welcome.
Ta,
S.
On 06/12/2012 11:43 AM, "Martin J. Dürst" wrote:
> Hello Stephen,
>
> On 2012/06/09 10:45, Stephen Farrell wrote:
>
>> On 06/09/2012 01:43 AM, Sam Hartman wrote:
>
>>> It's a naming
>>> hierarchy. My main concern is whether the relative reference algorithm
>>> described in section 5/4.2 of RFC 3986. In particular take a look at the
>>> last part of section 1.2 of RFC 3986 regarding the disallowing of
>>> /. Consider how you want relative references in an HTML document
>>> resolved through a ni: URI to work. I don't think your use of authority
>>> provides good results. However I'm not sure that better results would be
>>> achieved without hierarchy. I hope though that these comments will help
>>> inject some ways of reasoning about authority that are less mystical and
>>> that lead to more practical discussion.
>>
>> Thanks.
>>
>> I think your comment about relative URIs is fair and we maybe ought
>> say there are no such things for ni URIs. (Or however that kind of
>> thing is stated best).
>
> You can't say that. It's perfectly okay to have an HTML document like this:
>
> <html>
> <head>
> <title>ni: relative URI test</title>
> <base href="ni://example.com">
> </head>
>
> <body>
> <p>Please check <a href="sha-256;f4OxZX...">this document</a>.
> And <a href="sha-256;UyaQV...">this other document</a>.
> And <a href="sha-256-128;...">this third document</a>.
> </p>
> </body>
> </html>
>
> ("..." used for brevity). What the browser will try to interpret when
> the links are activated is:
> ni://example.com/sha-256;f4OxZX...
> ni://example.com/sha-256;UyaQV...
> ni://example.com/sha-256-128;...
>
> If you don't think that makes sense, then you might just leave it to
> users to not use it that way. On the other hand, if you think that's
> actively harmful (I couldn't come up with a reason for that), then you
> have to change to the form without //.
>
> [Well, actual browser behavior is a bit more mixed:
>
> IE does what's explained above, and tries to go to the address, but says
> that this page can't be displayed.
>
> Safari uses the above resolved URIs when asked to copy the link, and
> also tries to follow the link saying that the page can't be opened.
>
> Mozilla doesn't even show the link texts as links, nor allows to
> activate them, probably because it decides that it doesn't want to
> disappoint the user when she clicks.
>
> Chrome shows the underlined links, but doesn't want to show any
> destination when hoovering. When activating, it goes to about:blank.
>
> Opera shows and tries to go to ni://sha-256;f4OxZX... and similar, i.e.
> it seems to drop the authority, possibly because it doesn't have ni:
> registered as a hierarchical scheme. But that would be fixed when the
> scheme is getting implemented.]
>
>> I guess a sentence or two about relative URIs would be worthwhile
>> and I'll ponder that.
>
> Yes, please do. I'm willing to check it.
>
> Regards, Martin.
>
>
