Re: [dispatch] Zstandard compression

I think that the right approach here is to approach this similarly
cryptographic algorithms.  It seems like the basic compression
structure is independently useful.  Document the format in one place,
then have short documents that describe content codings and other
things independently.  Then HTTP can take the content-coding work on
at their discretion (or it can progress independently).

I realize that RFC 7932 (brotli) didn't do this, so it would be OK to
just follow that pattern.  It also didn't define a media type. Did you
have a use case in mind for that?

On Thu, Nov 2, 2017 at 9:40 AM, Mark Nottingham <mnot@mnot.net> wrote:
> To be clear - HTTPbis needs a heads up and might want to have discuss the registration of the content-coding (Section 3.2). The whole spec probably belongs elsewhere.
>
> Cheers,
>
>
>> On 2 Nov 2017, at 8:35 am, Murray S. Kucherawy <superuser@gmail.com> wrote:
>>
>> <chair hat clearly off>
>>
>> In September, I submitted draft-kucherawy-dispatch-zstd, which introduces a new compression  mechanism and seeks to register media types and content encodings for it.  The most obvious application for it is HTTP payloads, but it has other possible applications.
>>
>> I don't know of IETF venues other than this one and maybe the ART list where this kind of thing might be discussed, or how we might dispatch it.  Offlist conversation with Mark Nottingham suggested maybe HTTPBIS might like to at least discuss this, but I haven't looked to see if it fits within their current charter.
>>
>> Suggestions for discussion venues or processing options are welcome.
>>
>> -MSK
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch