Henry Spencer writes...
I think
most people here do feel that the problem of non-ASCII in headers needs
solving, and are willing to help rather than just watch and flame.
Agreed.
However, it is becoming fairly clear that:
a) This is a non-trivial problem with no tidy solution.
And, I might add, reinforcing Dave Crocker's comments, that we had
better get it right the first time. The only interim solution is "live
with it a bit longer, don't violate any norms you are not violating
already, and let's work on this as quickly as possible".
d) The header and body problems are not so interdependent that
they must be solved together.
Despite the assertion of "clear", I don't think this has yet been
demonstrated. If it could be clearly demonstrated in some way, at least
a few of us would become instantly happier with a separate and parallel
effort.
But, even if there are no *technical* interdependencies (that isn't
quite "clear" to me yet either), we have been told repeatedly on this
list that people don't want to open mail systems and start upgrading
them unless they have a menu of desired features. I am concerned about
a vendor who opens its mail systems to provide RFC-XXXX support, changes
documentation, retrains people, and does all of the other expensive
things, and then closes them up again. Will that vendor see a
sufficient internationally-sensitive market to justify going through
those costs again. By contrast, if we can launch procedures for
extended (non-ASCII) characters in headers simultaneously with RFC-XXXX
(whether they are the same document is not important), I think we can
assume that vendors who are willing to upgrade their mail systems will
just do it all at once.
Before someone says "if the market isn't there, they don't deserve
these features", let me suggest that there are several features of
RFC-XXXX that would not survive if asked to stand out there on their
own.
e) While both problems are important, the body problem definitely
has priority.
Depends on your perspective, obviously. At least a few of the
participants in this list care much more about plain, ordinary, mail
extended to be suitable for international use and for non-English
communications, than we do (at least short-term) in multimedia, multiple
part mail.
It is also an historical artifact of the fact that people on this
side of the water were much more agressive and much more able to easily
express themselves in great detail and at great length in English than
some of the other actors in the drama. The WG really was initiated, if
I recall, with "international characters" as a (if not "the") principal
agenda item, and no one was saying "except in the headers" at the time.
Being forced to put the Subject in ASCII is
annoying, to be sure, but it's not at the same level as
being limited to ASCII everywhere in the body.
Stated that way, one has to agree. But assume that you are a system
manager in Europe (see footnote) (or a large province in your country,
Henry) and you have been limping along on 646 NLVs. You are under
pressure from users below and management above to do something to
accomodate new equipment and permit more flexible communications. You
know, to paraphrase Ned Freed, that your own opinions about conformance
to standards and The Right Way to Behave effectively end when someone
comes along and says "do something now or we will fire you and find
someone who will". And you know that users consider subject lines and
maybe even personal names to be part of the message text, not part of
protocol-specialized headers (the better a job we do of following Mark's
observation that headers are for computers and UAs should arrange
appropriate presentation the more likely the users are to believe that).
And educating people to understand the difference isn't going to be
pleasant, especially when they say "why didn't you get it right" or when
you say "well, maybe sometime soon, we will be able to do that".
I don't know that, in that position, "not at the same level" would be
quite as clear.
The obvious response to the situation is to get XXXX out the door before
we settle in to the battle over the header problem. Agreed that it would
be best to solve both at once.
The other possibly obvious response is to push XXXX part-way out the
door and freeze it there, "battle over the header problem", then
review XXXX to see if it needs any further changes based on what we have
learned from the header enterprise, and then push them the last few
inches out the door together. Maybe pushing XXXX in the direction of
"proposed" and holding it there until the headers are done would
accomplish exactly that, but I'd be a lot happier about that strategy if
the separability of the two issues were as clear to me as it apparently
is to you.
--john
------
Footnote: I don't want to start another round of Euro-bashing here, so
let me state an impression for people to think about. The Japanese
didn't settle on 7bit ISO 2022-based solutions out of any particular
virtue. They settled on them because it is instantly clear to any
competent observer that circa 216 Kanji are just not going to cut it--
one needs either switching (per 2022) or a >> 7 bit character set. In
Europe, things were different. It was not clearly obvious that 646 NLVs
were inadequate, then it was possible to believe that 180+ non-numeric
graphics were enough. If those decisions were being made for the first
time in the "1992" political climate and increasing needs for
communications and interoperability with the eastern parts of the
continent, we might never have seen 8859-n. But they weren't. And, as
a result, we see a very complex (and therefore possibly fairly general
or generalizable) solution emerging to a very complex problem, and
attempts at simplier (and possibly simplistic) solutions emerging to
simple-looking problems. No particular virtue, state of grace, or lack
of either in any of this.