Re: [alto] Reprise of REST comments

[Richard Alimi <[e-mail]>]

On Tue, Jan 4, 2011 at 4:39 PM, Thomson, Martin
<[e-mail]> wrote:
> Hi Rich,
>
> Regarding complexity, there are some things that are unavoidable.  Essential complexity exists for describing formats, as well as the filtering service (that arises because you are optimizing - one of the most common sources of complexity :)
>

Agreed.  I just meant to point out that I didn't think it would
significantly slim down the document, but it your suggestions do have
their benefits beyond that.

> By re-using existing work, you also gain experience in dealing with known problems rather than having to tackle them for yourself.  The linking work is a good example of that.  As is MIME+conneg for versioning.
>

Agreed.

>> I'm not sure the proposed solution will handle the redistribution case
>> discussed in Section 8.1.1.1 of draft-ietf-alto-protocol-06 (perhaps
>> you can convince me otherwise).  The use case is about retrieving ALTO
>> information from another ALTO Client (not via HTTP).  Since it comes
>> from another, perhaps un-trusted, ALTO Client, the information itself
>> is digitally signed by the original ALTO Service.  The Service ID is
>> simply an identifier for the Service which might be implemented by
>> multiple physical servers without relying on each service being behind
>> a single DNS name.  Perhaps I am missing it, but perhaps you could
>> suggest how making the ALTO Protocol REST-ful might handle this use
>> case as well?
>
> I'm not sure if I'm just not understanding the problem, so let me describe what I think that you are trying to achieve.
>
> The problem is where information travels from Server A to Client A to Client B.  Client B finds that they don't trust Client A to pass the information on faithfully.  You wish to have a way for Client B to validate that the information is correct.  Right?
>

Yes.

> Let's do away with the idea that Server A and Server B have different identities.  Logically, to the clients, there is a single authority that is providing this information.  The resource has a single identity (a URI).
>
> Load sharing and content distribution don't need to play into this.  Any server that is reached by following a URI MUST be authoritative for that resource, whether it be load balanced through DNS, anycast or reverse proxy.  That server can choose to redirect as it chooses without compromising the integrity of the result.
>
> The task then is in determining if a particular representation is faithful for that resource.  You are talking of an optimization that doesn't result in downloading the entire representation all over.
>
> Digital signatures are one way of checking, but there are other options:
>
>  - MD5 is pretty weak by modern standards, but a HEAD request to the URI could produce a Content-MD5 header.
>  - Use a link header (and a HEAD request) to include a link to a digest if MD5 is no good.
>  - Wait for someone else to invent some better HTTP integrity mechanism.  Mark Nottingham is interested in designing something for more general caching applications.
>
> I'm going to advise that the latter is the course you want to follow, perhaps leaving other options open in the meantime.  No point in inheriting more complexity than absolutely necessary.
>

Each of these three options requires the ALTO Client to send a message
to the HTTP server to verify, right?  One of the goals of
redistribution is to allow ALTO Clients to not contact an ALTO Server
at all in the common case. With the existing solution, ALTO Clients
need only download a certificate upon initial contact with the server,
and can then verify ALTO Responses without contacting the server at
all.  http://tools.ietf.org/html/draft-ietf-alto-protocol-06#section-12.4
has some additional discussion on this.

Rich