Subject: Re: [Gen-art] Gen-ART review of draft-ietf-alto-protocol-25

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 3 Feb 2014 23:57:09 -0500

Hi Martin,

Wendy gave a good summary on the reasoning of not using URIs. We are
wondering if you may have some additional comments so that we can address.
Thank you so much!

Richard
On Jan 27, 2014 11:16 AM, "Wendy Roome" <[email-masked]> wrote:

> Here's my response for "why resource ids instead of uris":
>
> An "ALTO Server" is a collection of services provided by a provider. That
> provider may distribute these services over several different physical
> servers, and that distribution may change over time. If we used URIs to
> identify those services, the IDs would have to change whenever the provider
> redistributed services.
>
> Therefore we defined "Resource IDs" as persistent, location-independent,
> IDs for those services. Resource IDs must be unique, but only within the
> context of one provider's services -- that is, the services defined by the
> tree of IRDs reachable from a root IRD. That IRD tree maps those Resource
> IDs to URIs, and allows the provider to change the mapping without
> disrupting clients. Thus ALTO Resource IDs are relative to the URI of the
> provider's IRD tree. If a provider had to use globally unique,
> location-dependent URIs, instead of location-independent relative IDs, the
> provider would have an unnecessary administrative burden.
>
> (Yes, I know "URIs", unlike URLs, are supposed to be "location
> independent." But let's face reality: that only works if there's some
> higher level mapping of URIs to locations. For all practical purposes,
> "URI" means host-specific "URL".)
>
> Another way to look at it is that "Resource IDs" are like using relative
> addresses within a web page. They make it easier to move a tree of related
> pages from one host to another.
>
> - Wendy Roome
>
> From: "Y. Richard Yang" <[email-masked]>
> Date: Sun, January 26, 2014 at 16:40
> To: Martin Thomson <[email-masked]>
> Cc: "N:" <[email-masked]>, "[email-masked]"
> <[email-masked]>, Richard Alimi <[email-masked]>, "Reinaldo Penno,
> (repenno)" <[email-masked]>, Wendy Roome <[email-masked]>,
> Sebastian Kiesel <[email-masked]>
> Subject: Re: Gen-ART review of draft-ietf-alto-protocol-25
>
>
> Section 10.2 defines a resource ID.  Why do this when you could use
> URIs?  After all, that's what URIs are for.  I realize that this would
> be something of a major change to the protocol, but I think that the
> question is particularly important.
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 4 Feb 2014 10:14:29 -0800

On 27 January 2014 08:16, Wendy Roome <[email-masked]> wrote:
> An “ALTO Server” is a collection of services provided by a provider. That

That might be considered a feature.  Let me try to explain.

What you are suggesting is a very common reaction to REST.  Stuff does
need to move, and it frequently does in practice.  But that doesn't
necessarily change the way that things are identified.

If it is more convenient for a provider to use a form of internal
identification, using a URI does not prevent this.  That happens all
the time.  The unique ID column in your SQL database frequently gets
mapped to some portion of a URI.

Moving can still happen, but it doesn't work quite how you are
thinking (I think).  You don't really move data, you make new data.
And the IRD helps your clients discover the new data.  For example, a
network map at https://a.example.com/map/12 is moved to a new location
at https://b.example.com/maps/primary/12.  The data might be the same,
but it is a different thing (caches will have to download a copy, even
if the content is the same).  Clients using cost maps will see a new
location upon which the cost map depends.

The key point here is that this doesn't require the use of mechanisms
that are duplicative of these existing functions.

---

From: Elwyn Davies <[email-masked]>
Date: Wed, 05 Feb 2014 13:01:59 +0000

This is not really anything to do with me but I would point out that the
Information Centric Networking folks would probably disagree with the
view on "new data" that Martin expresses below - ICN would prefer that
if the data is the same then it has a single way of naming it and any
copy is as good as any other (and the recipient can check it).

As regards locations and URIs, the ni naming scheme (RFC 6920) for data
objects is a URI scheme that specifically avoids incorporating locations
in the components that uniquely identify the data whilst allowing a
location to be added as a hint.

I am not familiar with the details of the ALTO story, so I don't know
whether it is sensible to expect all the resources to be effectively
just data items - perhaps there is a distinction to be made?

Regards,
Elwyn

On Tue, 2014-02-04 at 10:14 -0800, Martin Thomson wrote:
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Feb 2014 09:53:25 -0800

> copy is as good as any other (and the recipient can check it).

It's always nice to conceptualize the next highest layer of
abstraction, but I find that when enacting anything, the lowest
abstraction layer that works is often best.

There's nothing wrong with the concept you describe.  But I haven't
found that the abstraction is as useful in practice as it is in
theory.

> location to be added as a hint.

I didn't suggest ni, for two reasons: ni isn't widely used; and the
document already has an additional layer of indirection, my concern
was that the additional indirection was unnecessary, not that a
different form would be more appropriate.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 5 Feb 2014 13:03:13 -0500

Thank you very much Martin for your review, and Richard for the quick responses and your interest in correcting issues.

I expect a new version of the draft is needed for the string issue. 

Jari

On Feb 3, 2014, at 11:57 PM, Y. Richard Yang <[email-masked]> wrote:

> Hi Martin,
> 
> Wendy gave a good summary on the reasoning of not using URIs. We are wondering if you may have some additional comments so that we can address. Thank you so much!
> 
> Richard
> 
> Here’s my response for “why resource ids instead of uris”:
> 
> An “ALTO Server” is a collection of services provided by a provider. That provider may distribute these services over several different physical servers, and that distribution may change over time. If we used URIs to identify those services, the IDs would have to change whenever the provider redistributed services.
> 
> Therefore we defined “Resource IDs” as persistent, location-independent, IDs for those services. Resource IDs must be unique, but only within the context of one provider’s services — that is, the services defined by the tree of IRDs reachable from a root IRD. That IRD tree maps those Resource IDs to URIs, and allows the provider to change the mapping without disrupting clients. Thus ALTO Resource IDs are relative to the URI of the provider’s IRD tree. If a provider had to use globally unique, location-dependent URIs, instead of location-independent relative IDs, the provider would have an unnecessary administrative burden.
> 
> (Yes, I know “URIs”, unlike URLs, are supposed to be “location independent.” But let’s face reality: that only works if there’s some higher level mapping of URIs to locations. For all practical purposes, “URI” means host-specific “URL”.)
> 
> Another way to look at it is that “Resource IDs” are like using relative addresses within a web page. They make it easier to move a tree of related pages from one host to another.
> 
> 	- Wendy Roome
> 
> Cc: "N:" <[email-masked]>, "[email-masked]" <[email-masked]>, Richard Alimi <[email-masked]>, "Reinaldo Penno, (repenno)" <[email-masked]>, Wendy Roome <[email-masked]>, Sebastian Kiesel <[email-masked]>

---

From: Wendy Roome <[email-masked]>
Date: Thu, 06 Feb 2014 10:22:47 -0500

Here¹s another take on using URIs for resource ids:

Suppose we define the uri of an ALTO resource as

   [uri-of-alto-ird] # [resource-id]

Eg, the uri of the default network map in the {9.2.3} example would be:

   http://alto.example.com/directory#my-default-network-map

In the IRD, we use the resource-id as the key for simplicity, because all
ids have the same prefix.

BTW, this makes it easier to configure a client to use a specific resource
(e.g., a specific non-default network map) ‹ just give the client the uri
of that format.

Also, the resource id can be in any IRD reachable from the IRD in the
resource uri. e.g., the uri of the filtered cost service in {9.2.4} would
be

   http://alto.example.com/directory#filtered-cost-map

What do y¹all think of that interpretation?

	- Wendy Roome