Subject: Re: [alto] alto Digest, Vol 32, Issue 12

From: Bill Roome <[email-masked]>
Date: Thu, 16 Jun 2011 16:04:09 -0400

>
>On Wed, Jun 15, 2011 at 9:32 AM, Zhang, Ning <[email-masked]>
>wrote:
>>Hi, Rich,
>>
>>Here is another comment regarding to the IP addresses in an endpoint
>>cost lookup response, specified in Section 7.7.5.1.5.
>>
>>It would be better to make it clear that each IP address in the response
>>must be encoded in the same format as specified in the incoming request.
>>
>>For example, if "ipv6:FF00::192.1.1.1" is specified in the request, the
>>server should use the same one in the response, instead of other
>>equivalent formats, such as "ipv6:FF00::C001:0101".
>>
>
>I'm not convinced there needs to be such a requirement - can you say
>why this should be?  For example, in implementation I would imagine
>parsing the addresses in the request into the raw bytes (since that is
>presumably the format used for the longest-prefix-matching).  It seems
>like extra work (and messy) to ask the ALTO Server to return addresses
>in a particular format since it needs to also store this bookkeeping
>information along with the parsed request. Furthermore, what if the
>ALTO Client put two addresses in different formats in the request?
>Which format should the ALTO Server use in the response?  This seems
>much more complicated than it needs to be.
>
>Thanks,
>Rich

The reason is to allow a client to deal with addresses as strings, without
decoding them into byte arrays. For example, consider a P2P client. It
gets a bunch of addresses, as strings, and sends them to the ALTO server,
again as strings. If a client can rely on the server using the same string
representation, the client doesn't need to parse the addresses.

On the server end, I recently wrote a ALTO server in java, and it turned
out to be easier to return the same string that the client used.

But in any case, I think the protocol should take a stand one way or the
other. Either the protocol should tell server implementors that they must
use the same string representation as the client, or else it should warn
client implementors that the server may return a different string
representation.

As for the client giving the same address in two different forms, the
server could return one, return both, or return an error. For that matter,
what happens if a client gives the same address twice in the same form?

	- Bill Roome

---

From: Bill Roome <[email-masked]>
Date: Thu, 16 Jun 2011 16:17:33 -0400

>>2. Suppose a resource directory entry lists multiple media types, as in
>>  "uri" : "http://custom.alto.example.com/
>><http://custom.alto.example.com/directory>maps",
>>  "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.
>
>That is the correct interpretation.

Then why does Section 7.6.3 say:

An ALTO Client could discover the maps available via
"custom.alto.example.com" by either:
  * Successfully performing an OPTIONS request to
"http://custom.alto.example.com/maps", or
  * Attempting a POST request for a desired Network or Cost Map to
"http://custom.alto.example.com/maps" and receiving a HTTP 300 status code
("Multiple Choices") response with an Information Resource Directory.

That sounds like the server is expected to return a 300 for the POST
request.

---

From: Richard Alimi <[email-masked]>
Date: Thu, 16 Jun 2011 23:10:34 -0700

> out to be easier to return the same string that the client used.

That may be entirely true. The spec still allows this implementation,
but it just doesn't say that it must be so.

> client implementors that the server may return a different string

I'd opt for the latter if there is indeed clarification needed.  We
can address that in the next version.

> server could return one, return both, or return an error.

The current spec would indicate that it it can return one or both.
However, it is valid input so the server can't return a syntax error
(if indeed the rest of the request is properly formatted).

> For that matter,

There's a more general question of what the server does if given an
identical address (either in the same form or different forms)
multiple times in a single list (and for that matter, multiple PIDs
that are identical).  It seems to me a reasonable server behavior
would be to behave as if the address only appeared once.  Objections?

Thanks,
Rich

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

---

From: Richard Alimi <[email-masked]>
Date: Thu, 16 Jun 2011 23:13:04 -0700

Hi Bill,

> That sounds like the server is expected to return a 300 for the POST

In this example, the ALTO Server does not provide them directly but
instead via separate URIs under custom.alto.example.com. The
distinction is that this is a specific example, while above I was
talking about the more general case.  If it helps, this can be made
more explicit in the draft.

Thanks,
Rich

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 17 Jun 2011 07:36:23 +0100

Bill,

> That sounds like the server is expected to return a 300 for the POST

I think the text needs cleaning up.

In general if an entry in an Information Resource Directory lists multiple media-types the client can select the media-type it would like returned using HTTP connection negotiation. The entry in the Information Resource Directory lists all the media-types that the resource supports that the client may request. In the case of a POST request the applicable media-types that may be returned is further constrained by the media-type of the POST (e.g. if the client posts a costmapfilter then a networkmap is not an appropriate response).

OPTIONS is an HTTP method to allow clients to query a resource to determine what it supports and in the case of ALTO the semantics are that it should return a "mini" Information Resource Directory containing entries related to only that resource.

A resource may return "300 Multiple Choices" to any request (as per HTTP semantics). IMO the text on 300 responses is meant to indicate that clients may get a 300 response but IMO using POST and hoping for a 300 should not be the general mechanism clients use to discover what a resource supports.

HTH
Ben