ietf-822
[Top] [All Lists]

Re: Let us finish RFC-XXXX NOW! (Re: non-ascii headers)

1991-09-26 14:48:51
Quoting:  Harald Tveit Alvestrand 
<harald(_dot_)alvestrand(_at_)delab(_dot_)sintef(_dot_)no>

- RFC-XXXX should be finished WITHOUT a mechanism for extending headers.

Reason: 6 months (or whatever needed) more of this discussion before
RFC-XXXX is "cast in concrete" is TOO LONG.

Are you -- and all you other Europeans out there -- aware of what this
really means?

Yes, we are used to not allways being able to spell our names
correctly but we are *NOT*, repeat *NOT* used to treating mail subject
separately from the mail text, as now is being imposed on us.

As I hope you all know: Ever since email first was used in Europe, we
have used ISO646 variants (ASCII with 10 characters changed --
different in different countries) for all communication whithin each
country. This naturally also includes the subject line.

From RFC-XXXX of may -91:

The message body is coded in the character set of American Standard Code
for Information Interchange, sometimes known as "7-bit ASCII". This is
not an arbitrary seven-bit character code, but indicates that the
message body uses character coding that uses the exact correspondence of
codes to characters specified in ASCII.  National use variations of
ISO646 [REF-ISO646] are not ASCII ...

... and ...

Beyond US-ASCII, one can imagine an enormous proliferation of character
sets.  It is the opinion of the authors of this memo that a large number
of character sets is NOT a good thing.  ...
For this reason, we define names for
a small number of character sets for which a strong consituent base
exists.  ...

As this is stated, and if we try to use it, the subject line will
suddently be different from the rest of the letter. Tell me how we
(the systems managers) are supposed to explain this strange decrease
in usability to the users?  Simply impossible. We will either get
laught at or be forced to break the rules in some way or another.

Please, americans, you can't do this to us!

How do we solve this? No, I'll not open the whole debate again, I'm
just requesting a solution for part of the problem.  So far I have not
seen anybody argue that there would be any parsing problems with the
headers which contains only text: Subject, Comments and (from
RFC-XXXX) Content-Description. How about adding two new header-fields,
to be applied to *only* those headers:

        Text-Header-Field-Type
        Text-Header-Field-Transfer-Encoding

which are directly parallel to Content-Type and Content-Transfer-
Encoding respectively, with the restriction that the only permitted
values for the former is Text/* and Text-Plus/* (and X-*).  (This idea
is not mine, I'm just supporting and forwarding it.)

If you give us just this little concession we promise to sit quiet
(well, for a while) and wait for the RFC which will solve the other
problems. Please...
---
Peter Svanberg, NADA, KTH                       email: 
psv(_at_)nada(_dot_)kth(_dot_)se
Dept of Num Analysis and Comp Science, 
Royal Institute of Technology
Stockholm, SWEDEN