[Top] [All Lists]

Re: Content-Disposition changes

1995-02-02 15:04:46
No matter what scheme you choose it pretty much has to work like
encoded words do inside of quoted string. You can play games with the
introductory characters and the delimiter characters but that's about
all. Any scheme put forward has to allow for long parameter values,
which means there has to be a way of putting padding spaces in so
header field wrapping won't mess things up, which in turn requires
that quotes around the whole thing have to be allowed.

Will it really work to have quoted-strings that wrap from one line to
another?  I realize it's okay according to RFC 822, but this violates
my sense of what seems likely to work in practice.  Not that I recall
seeing it fail...

We use this all the time in the messages we send. Thus far we've encountered
only one MIME gateway that cannot deal with it.

Unlike message headers, I don't trust existing line wrapping code to
properly handle anything in the message body.  So for instance a long
encoded-word could be split in half.  But this problem exists for all
headers embedded in a message body, independently of which encoding
scheme is used.


As such, I see such a caution as being irrelevant. What does need to
be in there is a specification that this can ONLY be used for
parameters where character set information is meaningful. In other
words, use with any particular parameter is absolutely forbidden
unless the definition of that parameter specifically permits it.

I can live with that.  However, there might be someday be a parameter
that requires "binary" (non-character) values.  This could be handled
with an empty charset field, but that use needs to be specified.

Better still, just use base64 in the definition of that parameter's value.
(Note that you can put spaces in the base64 so it breaks cleanly.)

As long as the value is pure binary there's no need for any of the
encoded word junk.


<Prev in Thread] Current Thread [Next in Thread>