[Http-crcsync] General comments on crcsync document

[Pedro R]

Hi Patrick, 


>Hi! It must be kind of late in Portugal, no?

It was about 4 AM :-)

>I've got no problem with just sending if-block to any old server you know nothing about. You 
>don't need to verify beforehand that it knows how to do this  particular delta spec.  If we use 
>the current spec terminology, I don't see the need for a new accept-encoding token to do so, 
>though as a separate >issue I do agree that it makes sense to talk about whether this should 
>all be done with accept-encoding/content-encoding/vary instead of the way it is currently deined.

It would be great to use "Accept-Encoding: crcsync" on the client side and "Content-Encoding: 
crcsync" on the server side, since this kind of implementation is much easier to do by leveraging 
on existing mechanisms for gzip and deflate. Once again, this is as an independent clients' point 
of view, not sure if can make things more complicated server-side?

Alex and Toby, what do you think of this? It may also make the IM and A-IM headers redundant.

>so you don't require OPTIONS in your implementation (either client or server). I agree. But you 
>might _want_ to use OPTIONS to probe for deltas simply because creation of the If-Block header 
>is conceivably pretty expensive. This is where the comparison with gzip breaks down.. adding the 
>gzip request header is just a matter of appending a constant string, where the If-Block is considerably 
>more involved - so you might want to know if the other end even understands it before you do so.. 
> and yes, that can cost a round trip and still be a worthwhile endeavor (especially if you can reliably 
>cache and  reuse the result). I think "Expect: 100-continue" is kind of a similar thing.

I still think you haven't quite understood what I meant to say (my fault, English is not my native language).

Upon first contact, the client will never send a full "If-Block" header. It will only send "If-Block: 0", because 
it does not have anything in the cache. So constructing the If-Block header does not have a cost in this
situation.

Of course, this will not be necessary if we use the Accept/Content-Encoding as described above...

>meanwhile as an alternative, you might define a response header similar to accept-ranges which would allow 
>the server to advertise its support for deltas even on responses that do not contain them.. (i.e. it means "I can 
>do deltas" not "this is a delta") this eliminates the need for either probing with options or having the client
>proactively computing if-block lists (which hit the server side cache) on the first request submission while 
>maintaining the separation between capability and use. (the key difference between accept-ranges and 
>accept-encoding is that accept-ranges is a response header instead of a request header.. it is the only 
>accept-* header that is a response header that leaps to mind.)

>make sense?

Yes it does make sense!

Pedro