[lemonade] Compress, future algorithm and their arguments

[Arnt Gulbrandsen <arnt at gulbrandsen.priv.no>]

A couple of people have proposed including general arguments for future 
compression algorithms. At least that's how I read their mail.

My basic position on such issues is that until we know at least a little 
about what these arguments might be, it's best to not specify them in 
any way. The best way to cater for the completely unknown is to not 
specify it at all.

I could attempt to specify it in the way Mark did in the RFC 3501 
body-extension or Barry and Alexey in listext's return-option, but I'm 
wary that a) it's practically untestable at present and b) that if/when 
these unknown arguments become known, they just might not fit into a 
list-of-lists.

Because of this, I would prefer to leave it open. I would prefer to 
state the syntax as
    "COMPRESS" SP algorithm
and if some day an RFC comes along and needs arguments, it can extend 
the syntax somewhat generally, and it can do at least as good a job 
then as we can now.

Arnt

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade