Subject: [alto] Questions on draft 8

From: Bill Roome <[email-masked]>
Date: Thu, 16 Jun 2011 12:53:57 -0400

A few questions on draft 8:

1. If a resource directory entry gives an "accepts" type, is the client
*required* to send an input object of that type to the ALTO server? Or is
the input optional? Eg, consider a resource that provides a filtered
network map:

{
  "uri" : "http://custom.alto.example.com/networkmap/filtered",
  "media-types" : [ "application/alto-networkmap+json" ],
  "accepts" : [ "application/alto-networkmapfilter+json" ]
	}

Clearly this resource accepts filter input and returns a filtered map.

But is the input required? The "unfiltered" network map service returns
the same media type. So that resource spec could be interpreted to mean
that if the client sends a GET with no input data, the service returns the
entire network map.

Yes, Section 7.7.3.1.3 does say

"If the list of PIDs is empty, the ALTO Server MUST interpret the list as
if it contained a list of all currently-defined PIDs."

But I interpret that to mean that the client provides a networkmapfilter
input, but it doesn't have a PID list. It's not clear what the server will
do if given no input at all.

2. Suppose a resource directory entry lists multiple media types, as in

    {
  "uri" : "http://custom.alto.example.com/directory",
  "media-types" : [
     "application/alto-networkmap+json",
     "application/alto-costmap+json"
  ],
  "accepts" : [
     "application/alto-networkmapfilter+json",
     "application/alto-costmapfilter+json"
  ],
	}

One interpretation is that resource provides both network map and cost map
services. That is, if a client sends that uri a POST request with a
networkmapfilter input, the server returns a network map, but if the
client sends a costmapfilter input, the server returns a cost map. That's
easy to implement, both for the server and the client.

However, my guess is that's not what the authors intended. I suspect that
when a uri is listed as returning multiple media types, it really means
that uri itself doesn't provide any of those services directly. Instead,
the client must send a directory request to that uri to get more
information.

Or maybe the server could work either way, at the whim of whoever
implemented it.

So I suggest you make it clear which interpretation we're to use.

3. The filtered network map and cost map services return the entire map if
the client doesn't specify the PIDs. That makes the unfiltered services --
Sections 7.7.2.1 & 7.7.2.1 -- redundant. So why not just drop Section
7.7.2, in the interest of simplifying the protocol specification?

4. I think the resource directory needs some sort of "time to live." Eg,
consider the following. When the client starts, it gets the the directory
from the alto server, and uses that for all subsequence requests. But a
long-lived client could run for days or weeks. What happens if the ALTO
server restarts with a different uri structure?

An alternative to a TTL is for the server to put a "directory vtag" in all
the uris. If a client sends a request to an expired uri, the server
responds with an "resource out-of-date" error. That tells the client to
refresh the resource directory. The only protocol change would to add such
an error code to Section 7.4.3, and add an "application note" suggesting
that servers do that.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 16 Jun 2011 19:40:44 +0100

Bill,

I've included my view inline.

> that if the client sends a GET with no input data, the service returns the

The input is not required, all the "accepts" is saying is the list of media types that the resource (URI) supports for POSTs/PUTs. A GET should return the entire network map provided the resource supports the GET method.
 
> do if given no input at all.

IMO it is down to the server to decide what to do. For example, it could return the entire network map or it could return a redirect to a URI (even the same URI as where the POST was made to) to request that the client make a GET request for the resource in the redirection or return a another response compatible with the HTTP semantics of a POST.

> easy to implement, both for the server and the client.

That is the correct interpretation.

> 7.7.2, in the interest of simplifying the protocol specification?

The unfiltered services are useful because they are directly accessible via GET and can be implemented without requiring dynamic code to run on the server.

During the production of -08 I did suggest that we combine the textual descriptions of the unfiltered & filtered services to reduce the verbosity of the draft and to make the linkage between the two clearer. At the time the authors of -08 felt that keeping them separate better fitted the way -07 structured the two services as separate services and so -08 should continue to follow that model so that the changes were kept to making a RESTful version of -07 rather than re-structuring the way the individual services are described which may introduce additional confusion.

> server restarts with a different uri structure?

A TTL can be specified using Expires HTTP header.

Under failure conditions where clients are seeing failures such as a URI suddenly disappearing the client should re-request the Information Resource Directory (and re-initiate discovery of the resource directory if appropriate) to learn the current location of the resources it requires.

HTH
Ben

---

From: Richard Alimi <[email-masked]>
Date: Thu, 16 Jun 2011 22:56:14 -0700

Hi Bill and Ben,

> IMO it is down to the server to decide what to do. For example, it could return the entire network map or it could return a redirect to a URI (even the same URI as where the POST was made to) to re…

+1 to what Ben said. It would be nice to not fall into the hole of
clients being built this way to exploit corner cases, so do you think
it is reasonable to indicate in the spec that the server MAY elect to
respond with the full network map (in some way, up to the
implementation), with the intention of getting across that a client
shouldn't rely on this?

>> So I suggest you make it clear which interpretation we're to use.

It works either way, and is up to the server implementation.  As
discussed in http://tools.ietf.org/html/draft-ietf-alto-protocol-08#section-7.6.2,
both are valid responses from the ALTO Server. If this isn't clear, do
you have suggestions that can help to clarify the text?

> During the production of -08 I did suggest that we combine the textual descriptions of the unfiltered & filtered services to reduce the verbosity of the draft and to make the linkage between the tw…

Yes.  This is something that we can clean up without affecting the
actual messaging, but we wanted to keep changes to the overall
structure of the document manageable since it was already quite a
large delta from the previous version.

>> an error code to Section 7.4.3, and add an "application note" suggesting

Yes, as Ben mentioned HTTP already specifies mechanisms and behavior for these.

Rich

>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>