Re: Content-Disposition changes

> > 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.

Correct.

> > 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.

				Ned