Okay, I admit that I rushed into this debate at a quarter past
twelwe, screaming about how wrong I think you are doing. I apologize
for that!
The history is that we in Sweden have been very involved in this
issues from the start and have contributed quite a lot.
We havn't had the time to follow the huge information flow on these
two lists the latest months, but does that exclude us the right to
raise our voices when we hear what is going on? I felt that I at least
should tell you our views, and as I also felt it was a great hurry, I
just wrote and wasn't so careful about *how* I wrote it.
Now to the problems.
As I said in my first contribution, I am now only concerned with the
"*text" fields (actually only the Subject field), isn't it reasonable
to treat them separately from the fields which are parsed?
Quoting "Ned Freed, Postmaster" <NED(_at_)HMCVAX(_dot_)CLAREMONT(_dot_)EDU>
Simple: Today there is no character limitations for the subject
line. Tomorrow there will be (with RFC-XXXX).
Wrong. 8 bit characters are presently illegal on the Subject: line, or any
other header. See RFC822. It may work now, but only because your software
does
not enforce existing standards. Software does exist that enforces standards,
and your mail does not interoperate with it.
Yes we have been violating RFC822 when we have been using non-ASCII,
but what would you expect? That we all should have been communicating
in english? Besides, in the "*text" headers, the violation consists of
that the "}"s and "{" etc was not to be interpreted by the receiver as
braces etc. Do you have examples of problems this have caused?
The users will naturally want to continue to use our special
characters, as they allways have. But suddently -- as those characters
now will be 8-bit -- we have to stop them from doing that on the
subject line. This is a severe decrease in functionality.
RFC-XXXX changes nothing in this regard. It simply restates what is presently
stated in RFC822, and explicitly specifies the character set that was not
completely specified in RFC822.
No, nothing is changed, but that's the problem -- the body character
set changes, but not the subject ditto! Observe that I'm not talking
theory but reality -- the users *has* been using and *will* continue
to use special characters.
You are living in a fantasy world if you think
your present violations of RFC822 and RFC821 are not causing operability
problems. Sorry, it does cause them. We're trying to come up with a
scheme that does not.
Could you give examples? Does this really include the Subject line?
... And consequently I have a little trouble with dealing with your input
now. If you want to solve these problems, offer up a proposal that addresses
the issues at hand, or endorse one or more of the proposals we have in
front of us that addresses the issues.
I thought I did that, but as several seem to have missed it, I repeat:
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 include something like this in this RFC-XXXX, then we can take
our time to solve all the other problems with non-ASCII in headers.
If you don't then you either must rush out the other RFC or else you
will probaly see quite a few 8-bit characters in quite a few Subject
headers... That's what I think, but I may be wrong.
---
Peter Svanberg, NADA, KTH email:
psv(_at_)nada(_dot_)kth(_dot_)se