Re: [alto] Reprise of REST comments

["Thomson, Martin" <[e-mail]>]

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 :)

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.

> 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?

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.

--Martin