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

From: Bill Roome <[email-masked]>
Date: Fri, 17 Jun 2011 10:03:26 -0400

>>For that matter,
>>what happens if a client gives the same address twice in the same form?
>
>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

I just realized that's a non-issue. The costs are returned in a JSON
dictionary. That allows only one value per key. So if a client gives an
address or PID twice, the server can only return it once.

BTW, I don't know how other have implemented a server, but the simple way
to handle a endpoint cost request is with

    for each client source addr
        for each client destination addr
             lookup src=>dest cost
             insert cost into output JSON object

With that, it's natural to use the client's string representation in the
response.
And it would take extra work to determine if the client had
given the same address in two different forms.

	- Bill Roome

---

From: "Zhang, Ning" <[email-masked]>
Date: Fri, 17 Jun 2011 10:20:40 -0400

I agree with Bill's comments, based on the experience of our ALTO client/server implementations.

If the same address format is used, the client implementation would be much easier and straightforward in various devices and applications.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bill Roome
Sent: Friday, June 17, 2011 10:03 AM
To: [email-masked]
Subject: Re: [alto] alto Digest, Vol 32, Issue 14

	- Bill Roome

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

---

From: Bill Roome <[email-masked]>
Date: Fri, 17 Jun 2011 11:18:12 -0400

>
>On Thu, Jun 16, 2011 at 11:40 AM, Ben Niven-Jenkins
><[email-masked]> wrote:
>>Bill,
>>
>>I've included my view inline.
>>
>>On 16 Jun 2011, at 17:53, Bill Roome wrote:
>>
>>>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.
>>
>>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.

But how does a client know whether a resource supports the GET method?

Unless the client can determine that from the IRD, I think it still boils
down to "maybe the server will, and maybe it won't, and the only way to
find out is to send a GET and see if the server accepts it."

Speaking as a client implementor, I find that to be really annoying.

As a slight aside, I believe protocols should be designed to simplify life
for the client. If that makes the server more complicated ... tough!
That's why the server implementors get paid the big bucks (or euros, or
yen, or ...) ;-)

It's been my experience that when a protocol gives the server a lot of
choices, the clients get harder to implement, and less likely to
interoperate.

	- Bill Roome

---

From: Bill Roome <[email-masked]>
Date: Fri, 17 Jun 2011 12:46:49 -0400

>>>
>>>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.
>>
>>That is the correct interpretation.
>>
>>>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.
>
>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?

So if a resource has multiple media types,

* That uri MUST respond to an OPTIONS request and return an IRD, and

* When given a POST request, that uri MAY return the desired media type,
or it MAY return a 300 status with an IRD.

Okay, at least that's clear. However, I don't know about the rest of you,
but as a client implementor, I'd never use the second option. It's not
worth the hassle. I'd always send an OPTION request, get the IRD, and
parse that. Furthermore, if I wanted to use the second option, I'd have to
test my client with both flavors of server.

So here's my suggestion. Simplify the protocol by removing the second
option.

More specifically, how about this:

If the media-type list includes "application/alto-directory+json", it
means that the uri responds to a GET and returns an IRD. And that is the
only request that uri accepts! The other media types and accepts are the
union of the types in the IRD that the uri returns. And it's illegal to
have more than one media-type or accepts unless the uri is a dictionary --
eg, unless it includes application/alto-directory+json as a media type.

This also means the OPTIONS request isn't needed. Just send a GET.

I think this simplifies the protocol description, the server, the client,
testing, and improves interop. And the only feature it removes is one that
I doubt any client would bother to use.

	- Bill Roome -- as I duck the bricks that come flying my way! :-)

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 17 Jun 2011 18:15:22 +0100

Bill,

> Speaking as a client implementor, I find that to be really annoying.

OK, How about we make the semantics of the IRD entries more explicit with respect to supported methods, so:

An IRD entry containing "media-types" but not "accepts" MUST support GET.
An IRD entry containing "media-types" and "accepts" MUST support POST.
If a server wants to support both GET & POST on a single URI it puts two entires in the IRD.

Thoughts?

Ben

---

From: Bill Roome <[email-masked]>
Date: Fri, 17 Jun 2011 13:30:25 -0400

>If a server wants to support both GET & POST on a single URI it puts two

That works for me! Seems like an excellent definition of the semantics.

Although isn't "media-types" irrelevant? The real key is whether or not
the entry has "accepts" types.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 17 Jun 2011 18:32:22 +0100

Bill,

> test my client with both flavors of server.

As I said in my previous response I don't think POSTing to expect a 300 "multiple choices" response is what folks should be doing and I don't recall it being a case we discussed when REST-ifying the protocol (although I may be wrong).

I do remember discussing a different use of 300 responses with the protocol draft editors (for connection negotiation of cost map types in the case where a server may support list multiple ones on a single resource but only be capable of returning a single one at a time) so I think the text on using a POST to get a IRD should be removed.

I would note though that there may still be cases where a POST causes a 300 response from the server but like I say above it shouldn't be the general approach clients take to obtaining an IRD.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 17 Jun 2011 18:35:14 +0100

Bill,

> the entry has "accepts" types.

Depends how pedantic you want to be, an entry containing an "accepts" but not a "media-types" is an invalid entry and so isn't guaranteed to respond to anything :-)

Ben

---

From: Richard Alimi <[email-masked]>
Date: Sat, 18 Jun 2011 10:03:13 -0700

Hi Bill and Ben,

> I would note though that there may still be cases where a POST causes a 300 response from the server but like I say above it shouldn't be the general approach clients take to obtaining an IRD.

Fine with me. It was there for completeness, but if it is causing
confusion it can be removed from that list of approaches to get an
IRD. Though, documenting that it is a possible response from the
server still seems necessary.

Thanks,
Rich

---

From: Richard Alimi <[email-masked]>
Date: Sat, 18 Jun 2011 10:04:53 -0700

Hi Ben,

> If a server wants to support both GET & POST on a single URI it puts two entires in the IRD.

Works for me.

Rich

---

From: Richard Alimi <[email-masked]>
Date: Sat, 18 Jun 2011 10:09:58 -0700

Hi Bill,

> choices, the clients get harder to implement, and less likely to

Yes - it was known before going to the REST-ful approach that the
server gets more flexibility, and relies on additional logic at the
client. The current discussion is good in that we're making sure that
the client still has all of the information it needs to do its job
efficiently, and its wonderful that client-side implementers are
getting involved.

Thanks,
Rich

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 20 Jun 2011 10:04:02 +0800

RFC 5952 defines a canonical format.  If both client and server conform to the recommendations in 5952, there is no problem.  From memory, -08 references 5952.

On 2011-06-18 at 00:20:40, Zhang, Ning wrote:
> If the same address format is used, the client implementation would be 
> much easier and straightforward in various devices and applications.
> 
> 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
> 
> dictionary. That allows only one value per key. So if a client gives 
> an address or PID twice, the server can only return it once.
> 
> BTW, I don't know how other have implemented a server, but the simple 
> way to handle a endpoint cost request is with
> 
> With that, it's natural to use the client's string representation in 
> the response.
> And it would take extra work to determine if the client had given the 
> same address in two different forms.
> 
> 	- Bill Roome
> 
>

---

From: Richard Alimi <[email-masked]>
Date: Mon, 20 Jun 2011 09:33:19 -0700

> RFC 5952 defines a canonical format.  If both client and server conform to the recommendations in 5952, there is no problem.  From memory, -08 references 5952.

That's what I had thought, but re-reading it I saw no absolute
requirement that the IPv4 part of such an address be in decimal or
hexadecimal. Section 5 roughly captures the debate we are having, but
does not give any firm requirements (only recommendations that refer
to knowledge from external methods not covered in that RFC).  Am I
missing something?

Thanks,
Rich

---

From: Richard Alimi <[email-masked]>
Date: Mon, 20 Jun 2011 09:53:28 -0700

> given the same address in two different forms.

Okay, so lets assume that there is a case where a single address has
multiple textual representations (Martin had a doubt about that, but
my reading of the RFC5952 looks to be the same as yours), we have a
few options:
(1) Make it so that there is only one possible textual representation.
 I'm not sure whats typical in the IETF for this, but this seems more
like a debate to be had elsewhere in the IETF and not in the ALTO WG.
Correct me if I'm wrong and we should actually be considering that.
(2) Have the client deal with the complexity of: converting received
addresses to bytes and converting addresses queried via its API to
bytes.  I'll note that if you intend to write a client that does a
lookup into the Network Map, you need to convert to bytes anyways to
do longest-prefix-match.
(3) Have the server deal with the complexity of: remembering the exact
representation that was used in the query, do its internal processing,
and serialize the response according to the representation that was
used in the original query.  This would have to be done under possibly
high load, and in order to scale to large request loads, this may be
accomplished across multiple distributed servers.

Given these tradeoffs, (2) sounds a lot better to me.  I'll note that
I am sympathetic to the needs of client implementations too; when
doing the P4P implementation (both client and server), we used (2).

>From the pseudocode quoted earlier in this thread, it makes it appear
like there isn't a clean separation between protocol encoding and the
API being exposed to the application making use of ALTO.  This is a
personal preference, but coupling the API that strongly to the
wire-format seems troubling.

Of course, these are personal preferences. If others from the WG have
strong feelings, please make them known.

Thanks,
Rich

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 21 Jun 2011 13:39:48 +0800

On 2011-06-21 at 02:33:19, Richard Alimi wrote:
> > RFC 5952 defines a canonical format.  If both client and server
> conform to the recommendations in 5952, there is no problem.  From 
> memory, -08 references 5952.
> 

The mixed representation is a bit of a nuisance, and that's from someone who has benefitted many times from its existence :)

Section 5 of 5952 takes the coward's path.  That means that if you need canonical, you need to fix it, which is easy.  Either prohibit the mixed hexa/decimal form, or specify that it MUST be used for ::ffff:0:0/96 and nothing else.  Prohibition is easiest - particularly given the usage context - I expect that user input will be mediated by some sort of UI (which can handle any translation).

--Martin