W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2019

Re: [Anima] Content-Transfer-Encoding and HTTP 1.x in ANIMA BRSKI

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 13 Jun 2019 19:38:20 +1200
To: ietf-http-wg@w3.org
Message-ID: <15eb1597-bd6e-cdb7-f4ca-eca7d1118fc1@treenet.co.nz>
On 13/06/19 6:27 pm, Carsten Bormann wrote:
> On Jun 12, 2019, at 19:26, Julian Reschke wrote:
>>
>>> 2) Assuming the answer to (1) is no, what should we make of RFC7030
>>>    that says to use it, and to base64 binary objects?
>>
>> Raise an erratum :-).
> 
> Not sure about the smiley here.  This is an erratum.
> Now how to resolve this depends on what option causes the smallest damage.
> 
> RFC 7030 is supposed to be a widely deployed protocol, so it should not be hard to find out what people out there are actually doing.
> 
> Grüße, Carsten
> 

IME the desired behaviour is for the agent mapping into HTTP(S) to
decide between three actions, in order of preference:

 1) remove the encoding and send binary of the resources native
Content-Type.

 2) if all agents end-to-end are wanted to retain the same encoding -
AND the final recipient is known able to decode; then C-T-E can be
mapped to HTTP's Content-Encoding header and the body sent as-is.

 3) if the next hop (only) is expected to be able to decode, but other
hops uncertain; then C-T-E can be mapped to HTTP Transfer-Encoding
header and the body sent as-is.
 * T-E is a mechanism without widespread support. So this option usually
turns out to be not available at the HTTP next-hop.


Amos
Received on Thursday, 13 June 2019 07:39:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:34 UTC