At 02.27 1/18/95, Ned Freed wrote (quoted Olle Jarnefors):
Considering that the conservative approach # 1 makes
"self-explaining" filenames impossible in most cases (mostly
because of the length restriction) I propose that a new
parameter, Portable-Filename, is introduced. Its values would
have a restricted syntax. It could be used together with the
Filename parameter like in this example:
Content-Description: A table showing all glyphs of the main
runic font Futhark A, in 300 dpi resolution.
Interesting idea -- I think its fine unless it proves to be controversial.
If it does we can always define it in a separate document.
As we already have support for 1522 en-/decoding in the software, what
is the problem with having 1522 encoding of this field also? Isn't that
the easiest thing to implement?
I also must say that I don't like the "portable filename" thing. My view
is that it's the receiving mailer which should filter the filename and
create a new one which suits the operating system it runs on.
The ability of sending other character sets than US-ASCII in the filename
_is_ very important. I agree that it is our fault, we who demand it, that
we have not written any suggeston on this matter, but me myself have
benn thinking on using 1522 encodings everywhere it's needed in the
header-fields. Is that not a solution to use?
I don't want to say this, but personally I think that if you can not
have national characters in the headers, ala 1522 or whatever, that
software/functionality of MIME will not be accepted in sweden...which
is a pitty, because we really do use MIME over here, or at least is
really heading for MIME. You can see of MIME in every questionnaire
about MIME software to companies, government and educational systems.
They _all_ demand that 1522 is used.
Unfortunately, it's still lot's of (good) MIME software that is not
using 1522, and because of that can not be sold in sweden.
Let's go for 1522 everywhere. It might be seen as "ugly", but as you
have the algorithms in the software etc etc.