Re: [alto] Should we allow relative URIs in resource directories?

To  reinforce that, how about using relative URIs in the 6.7.3 example?  Eg,
replace
        "uri" : "http://alto.example.com/networkmap",
with
        "uri" : "/networkmap",
etc.

- Wendy

From:  Richard Alimi <rich@velvetsea.net>
Date:  Fri, February 15, 2013 01:06
To:  Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Cc:  Bill Roome <w.roome@alcatel-lucent.com>, "alto@ietf.org"
<alto@ietf.org>
Subject:  Re: [alto] Should we allow relative URIs in resource directories?

On Wed, Feb 13, 2013 at 10:56 PM, Ben Niven-Jenkins
<ben@niven-jenkins.co.uk> wrote:
> Wendy,
> 
> On 13 Feb 2013, at 14:38, Wendy Roome wrote:
> 
>> > RFC 3986 does define relative URIs, so technically that's sufficient. But
>> > I think that's like a lawyer burying some critical information -- like
>> > "double every amount that you owe us" -- in tiny type in a footnote.
>> > Legal, but sleazy.
>> >
>> > The problem is that software libraries with a simple connectToServer(uri)
>> > function require an absolute uri. If the uri might be relative, the client
>> > must first resolve the uri in the context of some absolute base uri. Most
>> > libraries provide a function to do that, but it's easy to forget that step.
>> >
>> > Case in point: My client, which passed all the interop tests, failed when
>> > it contacted a server that returned relative URIs. (And yes, I've since
>> > fixed my client.)
>> >
>> > So if we want to allow relative URIs, we should be more explicit. At the
>> > very least, add this sentence to the end of Ben's revised uri section:
>> >
>> >    Relative URIs should be resolved using the URI of the Information
>> > Resource Directory as the base URI.
> 
> Or a reference to section 5 of RFC 3986 rather than re-specifying its
> semantics.
> 
> Maybe something like:
>    URIs can be relative and MUST be resolved according to section 5 of
>    [RFC3986].

+1 for allowing relative URIs.  If there are no dissenting opinions, we'll
update the draft with Ben's proposed text.

> 
> Ben
> 
> 
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto