Re: [alto] Info Resource Dirs, OPTIONS, 300 Multiple Choices and all that jazz ....

[Richard Alimi <[e-mail]>]

Hi Robert,

On Thu, Jul 28, 2011 at 1:57 PM, Robert Varga <[e-mail]> wrote:
> On 07/28/11 13:43, Thomson, Martin wrote:
>>
>> On 2011-07-28 at 14:56:19, Bill Roome wrote:
>>>
>>> So the directory server DOES have an authoritative list of uris --
>>
>> The IRD is not authoritative.  Sorry if you got an impression otherwise.
>>  The directory is much like a DNS delegation - a hint from the parent domain
>> that the child domain might be present at a particular place.
>>
>> Keep in mind that the IRD might be on a different server to the individual
>> resources.
>
> Coming from HTTP, yes. Two questions arise:
> - who has the authoritative information? OPTIONS request seems to be the
> last instance, but it does not have to exist...

Well, whether it exists or not is under discussion.  Currently, if
OPTIONS doesn't exist, the one providing the directory is supposedly
authoritative.

To answer your question, the last server to give the client a
resource's URI is authoritative for that resource.  In a REST-ful
design (similar to DNS delegation as Martin pointed out), the root
(and if used, intermediate) directories only help you get there.

> - could we not be a limit this a bit in exchange for greatly simplifying
> clients?

I'm not convinced this is difficult for clients.  For example, beyond
code that was already written for requesting and parsing requests, my
code for finding the URI for a resource is only 30 lines of code
(including logging), plus another 30 lines of code for determining if
a particular directory entry matches (which would be significantly
reduced if it weren't C++).  As Martin pointed out in another thread,
cachability is important on these responses, so once those are
appropriately specified by servers, the extra RTT's are typically
non-existent.

> I really would like to see this simplified, as all this complexity does not
> seem to be founded on documented ALTO deployment use cases...

Please don't let us return to -07....

Seriously though, REST-ful principles aren't as much about capturing
existing deployments (there are no deployments that speak this
protocol AFAIK).  They purposefully allow for very flexible deployment
scenarios, and give clients simple tools to allow for such flexible
deployments.

But, for what its worth, I could easily imagine a deployment scenario
in which endpoint cost and filtering are offloaded to a third party.
The existing scheme lets a server accomplish that painlessly and hides
the actual URLs used by the third party from the original ALTO Server
as implementation details.

Thanks,
Rich

>
> Bye,
> Robert
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>