ietf-822
[Top] [All Lists]

RFC-XXXX, 'content-encoding'.

1991-04-26 08:08:45
Given the fact that this encoding is done just to avoid mutilation in
transport, I don't see any reason to have many options. HEX is wasteful
and should be dropped. UUencode should not be reintroduced - how many times
did have have to help poor users trying to recover binary objects mangled
by mail gateways while in their uue suit...

I do understand that Base64 has been retrieved from RFC1113, but does it
really need to be so restrictive by specifying exactly 64 characters in
each line ? One can of course specify that an encoder should put that many
characters on each line, but a decoder could be more liberal in what it
does accept. Suppose a line has been splitted from some reason ; should the
decoder be allowed to refuse to decode because lines do not contain exactly
the right number of characters ?

On the other hand, if I were to design such a thing, I would certainly
put some checksum. Of course, this checksum would be computed on the
encoded byte values, and not on the binary values of the codes of the
characters used for encoding. Don't forget that the characters used for
the encoding are themselves encoded, and that this code can be changed
in gateways.
                                                              /AF

<Prev in Thread] Current Thread [Next in Thread>
  • RFC-XXXX, 'content-encoding'., Alain FONTAINE (Postmaster - NAD) <=