Subject: Re: Last Call: <draft-alakuijala-brotli-08.txt> (Brotli Compressed Data Format) to Informational RFC

From: Piotr Jurkiewicz <[email-masked]>
Date: Thu, 7 Apr 2016 03:20:30 +0200

(I sent this comment already two weeks ago to [email-masked], as 
suggested in the Last Call announcement, but received no response or any 
other kind of acknowledgement. Therefore, I am sending this to this 
mailing list, hoping to find someone interested in it here.)

This document requests a registration in the HTTP Content Coding 
Registry. Its authors proposed the 'br' token, which is an abbreviation 
of the algorithm name ('brotli').

However, by reviewing existing entries in the HTTP Content Coding 
Registry, you can notice that so far established convention is to use 
*full* algorithm name, rather than its abbreviation. For example:

- 'gzip' is used instead of 'gz'
- 'compress' is used instead of 'z'
- etc.

This convention is also respected by implementations when they create 
unofficial/non-standardized tokens. For example lighttpd and lynx 
support bzip2 compression and use 'bzip2' token for indicating it, 
rather than 'bz2' abbreviation.

I would urge to not break this convention and maintain the existing 
consistency, that is, to select and register 'brotli' as a HTTP Content 
Coding token for Brotli Compressed Data Format, instead the 'br' 
abbreviation.

Piotr Jurkiewicz
Department of Telecommunications
AGH University of Science and Technology
Kraków, Poland

---

From: Matthew Kerwin <[email-masked]>
Date: Thu, 7 Apr 2016 14:42:50 +1000

I think it's a bit too bike-sheddy for people to be interested in getting
involved.

Note that 'br' is already in use in the wild (Firefox, cURL [I think], my
webservers at work, etc.) and is actually the second name for the encoding
since 'bro' drew complaints.
On 07/04/2016 11:26 AM, "Piotr Jurkiewicz" <[email-masked]> wrote:

> (I sent this comment already two weeks ago to [email-masked], as suggested
> in the Last Call announcement, but received no response or any other kind
> of acknowledgement. Therefore, I am sending this to this mailing list,
> hoping to find someone interested in it here.)
>
> This document requests a registration in the HTTP Content Coding Registry.
> Its authors proposed the 'br' token, which is an abbreviation of the
> algorithm name ('brotli').
>
> unofficial/non-standardized tokens. For example lighttpd and lynx support
> bzip2 compression and use 'bzip2' token for indicating it, rather than
> 'bz2' abbreviation.
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 7 Apr 2016 08:06:22 -0300

The only thing I'll add is that there isn't any such constraint on registered names in the RFC defining the registry. That doesn't mean that it's not possible to argue for a name change, but I think there'd need to be a good reason and strong supporting consensus, which seems to be lacking here.

Regards,

> On 7 Apr 2016, at 1:42 AM, Matthew Kerwin <[email-masked]> wrote:
> 
> I think it's a bit too bike-sheddy for people to be interested in getting involved.
> 
> Note that 'br' is already in use in the wild (Firefox, cURL [I think], my webservers at work, etc.) and is actually the second name for the encoding since 'bro' drew complaints.
> 
> (I sent this comment already two weeks ago to [email-masked], as suggested in the Last Call announcement, but received no response or any other kind of acknowledgement. Therefore, I am sending this to this mailing list, hoping to find someone interested in it here.)
> 
> This document requests a registration in the HTTP Content Coding Registry. Its authors proposed the 'br' token, which is an abbreviation of the algorithm name ('brotli').
> 
> However, by reviewing existing entries in the HTTP Content Coding Registry, you can notice that so far established convention is to use *full* algorithm name, rather than its abbreviation. For example:
> 
> This convention is also respected by implementations when they create unofficial/non-standardized tokens. For example lighttpd and lynx support bzip2 compression and use 'bzip2' token for indicating it, rather than 'bz2' abbreviation.
> 
> I would urge to not break this convention and maintain the existing consistency, that is, to select and register 'brotli' as a HTTP Content Coding token for Brotli Compressed Data Format, instead the 'br' abbreviation.
> 
> Piotr Jurkiewicz

--
Mark Nottingham   https://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 7 Apr 2016 13:58:30 +0200

On Thu, Apr 07, 2016 at 08:06:22AM -0300, Mark Nottingham wrote:
> The only thing I'll add is that there isn't any such constraint on registered
> names in the RFC defining the registry. That doesn't mean that it's not
> possible to argue for a name change, but I think there'd need to be a good
> reason and strong supporting consensus, which seems to be lacking here.

While I'm not fond of starting to use shortened tokens to describe slightly
longer names, I'd remind that over the last 3 years we've been discussing a
lot about how to shrink request sizes to save bytes on the wire and reduce
page load time. This passes via reducing header field names and also token
values. We need to start somewhere. Yes H2 did a great job in this area but
that doesn't save us from being careful in all situatoins. From a technical
point of view it seems to me that it makes sense to use a short name like
"br". We won't run short of tokens for accept-encoding because of this.

I think that a valid objection would be the discovery of some obscure
implementation that already uses "br" and which would cause breakage.

Regards,
Willy