With all respect to Keith, I think he is too pessimistic on behalf of
RFC 1522.
I agree.
After all, his proposal came after a flurry of different proposals (some
of them mine) had been roundly trounced as totally unusable, and we all
sat back and said "Yes, this works", or words to that effect.
Nobody, including Keith, likes to look at them, I think, but they WORK!
They do indeed.
Since nobody has come up with a better wheel, I suggest that we go on
using them, perhaps with suitable profiling, like:
- State that the whole filename has to be in encoded-words if any of
it is, to avoid the "we don't know where it ends" argument
I think this is appropriate. This only applies to file names, however. There
may be other sorts of disposition parameters where other uses of
encoded words are appropriate.
For example, I could readily see us defining a "print" disposition with lots of
printer-queue handling stuff. This might include parameters like "job name",
"document title", or "operator instructions". These fields might involve
multiple character sets as well as mixtures of encoded-words and US-ASCII text.
On the other hand, such a disposition might have parameters like "header page
sequence", "trailer page sequence", "burst page sequence", and "form name" that
have characteristics similar to filenames.
The distinction here is between fields that are intended for display
purposes and fields that are intended to provide machine-readable content.
Both sorts of fields are going to come up in dispositions, so we'd best
plan to handle them. The RFC1522 scheme provides the flexibility we need and
can be tightened up as needed to provide the exactness we require.
- State that the rules of RFC 1522, section 5, bullet (1) are applicable
to the "filename" field
Agreed.
- State that the mapping between encoded-words and the local filename
character set is a local matter
It has to be. You don't even need encoded words for this to be the case.
For example, a mixed case file name has to be mapped on systems that
don't support file name case. In practice this can lead to several
different mappings even on the same system:
(1) Map to uppercase.
(2) Map to an encoded filename where case shifts are called out by particular
character sequences, e.g. "$M$akefile" instead of "Makefile".
I agree that the ambiguity on significant whitespace in 1522 needs to
be fixed - if it is as ambiguous as people say; I'm not sure.
I don't think this is an issue here -- if it is I'd like to see an example.
Ned