ietf-822
[Top] [All Lists]

Re: Content-Disposition changes

1995-02-02 14:17:50
It all depends on how it is done. If the new syntax for value is
simply a new way of interpreting already-legal material I see no real
problems with it.  Sure, some things won't be able to interpret the
new value strings, but for the most part I figure that new parameter
uses will require new software capabilities anyway.

Fine.  If the use of encoded-words in strings is restricted to
newly-defined parameters, it won't create a backward compatibility
problem.  This effect of this is that some parameters will be treated
differently than others.  

For example, with metamail, this would probably mean that the special
parameter decoding would either be indicated by some magic cookie in
the mailcap file, or handled completely within a content-type-specific
decoder.

But I probably prefer this to retroactively re-defining the meaning of
all existing parameter values.

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

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.

Mind you, I'd *really* like to have MIME be consistent in the way it
treats parameters, but I would be surprised if we could justify a
retroactive change.  (am I the only one who thinks this is shaky?)

I see nothing shaky about it.

I only see a problem if we retroactively define the meaning of all
existing parameters.

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.

--

And as for my objection to the use of encoded-words in general: they
can obviously be made to work.  My main concern has always been that
using encoded-words for this purpose would cause additional confusion.
But since this falls into the category of "fear and uncertainty"
rather than "strong technical objection", I'm not going to insist any
longer that encoded-words not be used for this purpose.  (As in many
other cases, I think the group consensus is a better predictor of how
well this will work in practice, than the fears in my own mind.)

If other people have objections to using encoded-words in MIME
parameters, now is the time to air them.

Keith



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