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

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Jun 2015 18:16:12 +0200

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-latest.html>

Feedback appreciated,

Julian

-------- Forwarded Message --------
Subject: I-D Action: draft-reschke-http-oob-encoding-00.txt
Date: Thu, 04 Jun 2015 04:45:11 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

         Title           : 'Out-Of-Band' Content Coding for HTTP
         Authors         : Julian F. Reschke
                           Salvatore Loreto
	Filename        : draft-reschke-http-oob-encoding-00.txt
	Pages           : 11
	Date            : 2015-06-04

Abstract:
    This document describes an Hypertext Transfer Protocol (HTTP) content
    coding that can be used to describe the location of a secondary
    resource that contans the payload.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-reschke-http-oob-encoding/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-reschke-http-oob-encoding-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Julian Reschke <[email-masked]>
Date: Sun, 21 Jun 2015 19:54:21 +0200

> <http://greenbytes.de/tech/webdav/draft-reschke-http-oob-encoding-latest.html>

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

---

From: John Mattsson <[email-masked]>
Date: Sun, 21 Jun 2015 21:11:56 +0000

Some quick comments:

- Several: “contans” -> “contains”

- “encrytion” -> “encryption”

- “encryted” -> “encrypted”

- When the key parameter is used, https high enough security should be mandated for the first request. I suggest something like:
“The Encryption-Key Header MUST only be used with https fulfilling at least the requirements in [RFC7540] Section 9.2”.

Cheers,
John

On 21 Jun 2015, at 19:54, Julian Reschke <[email-masked]<mailto:[email-masked]>> wrote:

Pretty HTML over here:

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Jun 2015 14:40:36 +0200

On 2015-06-21 23:11, John Mattsson wrote:
> - When the key parameter is used, https high enough security should be
> mandated for the first request. I suggest something like:
> “The Encryption-Key Header MUST only be used with https fulfilling at
> least the requirements in [RFC7540] Section 9.2”.
> ...

...but which of these two specs does this belong into?

---

From: Mike Bishop <[email-masked]>
Date: Mon, 22 Jun 2015 17:57:22 +0000

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:[email-masked]] 
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:

Feedback appreciated,

Julian

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 22 Jun 2015 18:09:11 +0000

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 <[email-masked]> wrote:
>