ietf-822
[Top] [All Lists]

Re: ISO-2022 as a separate RFC

1991-11-13 00:57:16
On Tue, 12 Nov 1991 19:01 PDT, Ned Freed, Postmaster wrote:
OK, Mark, if it is the height of arrogance to specify usage in any way, why
should we presume to deal with it at all?

Because it is even more arrogant to ban it, which RFC-XXXX will do unless an
appropriate place-holder is made.

I have software that
has to support this stuff, and without a specification I cannot do so. I
currently support conversion of the Japanese 2022 usage to/from the
character
set people use on the hardware I run on. Will this new usage be the same
thing?
How can I be sure without a (shudder) specification?

Question: did you have a `specification' before?  If you did, why can't you
copy it verbatim to RFC-XXXX and instead of flaming at me?  If, as I suspect,
you merely took people's word and observation of actual usage, what is wrong
with doing the same thing for RFC-XXXX?

If you have hardware/software capable of supporting Japanese, you know
everything you need to know about supporting ISO-2022-JP.  If you don't, it
isn't relevant, but you MUST NOT consider a message undisplayable just because
it is ISO-2022-JP.  It may be 100% US-ASCII without a bit of JIS in it.

I had a specification
(specifically, code that was known to work) to work from before. What do I
have
now?

That is not a specification and you know it.  You're offering a red herring to
try to get something that previously has not existed and has not been needed.

If your `code that was known to work' stops working or fails to work in a
particular case, it's the fault of the author of that code.  If RFC-XXXX's
specification stops working or fails to work in a particular case, it's the
fault of RFC-XXXX and can potentially damage the credibility of RFC-XXXX.

I hear Neil offering to help with either (1) or (2). This sounds good to me!
Apart from the fact that he's caucasian
and works for an American company, what's the
problem with his coordinating this specification?

I do not believe that any US entity -- including myself -- should specify what
is an internal Japanese matter.  This should come from the Japanese user
community, not from us.  More to the point, the Japanese and other East Asian
nations have a history of rejecting and/or ignoring specifications for the
representation of their national language that they did not have a part in
producing.  National pride is involved in this, and previous incidents have
shown that this is ignored at peril.  I do not want to see RFC-XXXX torpedoed
in Japan because some foolish Americans decided to twit Japanese
sensitivities.

It is one thing for us to tell the Japanese how they should identify their
internal usage to us.  It is quite another for us to specify their internal
usage, even if that specification presently matches our perception of current
usage or even a description of that usage unofficially stated by a Japanese
source.  They, not us, have the right to produce such a specification.

RFC-XXXX should specify ISO-2022-JP, and our Japanese friends should be asked
to come up with a subsequent document to formally specify this usage and all
other usages involving Japanese characters.  But the provision of a
placeholder should not be delayed pending this.

RFC-XXXX would lose a great deal of credibility with me if it bans the use of
Japanese in e-mail.  In fact, I would go so far as to claim it would be racist
for RFC-XXXX to ban Japanese and not simultaneously ban all other non-ASCII
character sets.

-- Mark --


<Prev in Thread] Current Thread [Next in Thread>