Re: I-D Action: draft-reschke-http-oob-encoding-00.txt

Hi Mike

thanks a lot for your comments and form mentioning MS BranchCache
I was not aware of that solution

br
Salvatore

> On 22 Jun 2015, at 20:57, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 
> That aspect feels similar to something Microsoft did a number of years ago in a feature called BranchCache.  The server provides block hashes and keys for the content; the client attempts to retrieve the blocks locally (multicast to peers or unicast to a cache server) and decrypt them with the keys.  If the blocks can't be found locally, the client goes back to the server to make a range request for the missing content.  What it downloads then becomes available to other peers, or is offered to the cache server.
> 
> (And no, the original owners didn't register it with IANA as a Content-Encoding.  Perhaps I should correct that....)
> 
> The model is different here largely because the content owner controls the secondary retrieval information, not the client (or rather, client's affiliated organization).  That means there's more deployment complexity but less trust required between the actors.
> 
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de] 
> Sent: Sunday, June 21, 2015 10:54 AM
> To: HTTP Working Group
> Subject: Re: Fwd: I-D Action: draft-reschke-http-oob-encoding-00.txt
> 
> On 2015-06-04 18:16, Julian Reschke wrote:
>> FYI -- see below.
>> 
>> This is another proposed building block for a system in which an 
>> origin server would delegate parts of the content delivery to a 
>> secondary server (usually a cache); it's supposed to work together 
>> with Martin's encryption content coding.
>> 
>> Pretty HTML over here:
>> <http://greenbytes.de/tech/webdav/draft-reschke-http-oob-encoding-late
>> st.html>
>> 
>> 
>> Feedback appreciated,
>> 
>> Julian
> 
> One thing I'd like to get people to think about is the way both specs stretch the concept of content codings beyond what has been done before:
> 
> 1) To undo the content coding defined in draft-thomson-http-encryption-00, the recipient will need encryption related information which is not part of the actual payload; it might be out-of-band, or provided in a response header field.
> 
> 2) To unwrap the content coding defined in draft-reschke-http-oob-encoding, the client will need to do an additional request to a secondary server.
> 
> Feedback appreciated,
> 
> Julian
> 
> 
> 
>

Received on Monday, 22 June 2015 18:09:39 UTC