Mark Crispin writes:
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?
Because before I was just hacking some code. A standards document is a
different thing entirely.
The question is, can someone, reading just the RFCs and/or documents
referenced by RFCs, and knowing how character sets work on their own hardware,
convert ISO-2022-JP to the format they need? If they cannot, we're missing
something that we should have.
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 currently have software capable of supporting Japanese. However, I don't have
a good idea of how the whole thing works overall, and I certainly have no way
of testing it since I both lack the expertise to know if it is working properly
and I lack a specification to tell if it is working properly.
This is fine as long as what I have is a crude hack. Once it becomes a
standards-derived application I feel rather differently about this situation.
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.
I agree completely. Poor choice of words on my part.
You're offering a red herring to
try to get something that previously has not existed and has not been needed.
Speak for yourself about what is needed and what is not. I am decidedly
uncomfortable with how things "work" right now. I take no issue with the
technical side, but the lack of a quality specifications bothers me a lot.
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.
The most damaging thing we can possibly do in RFC-XXXX is reference
ill-defined objects. This ISO-2022-JP stuff is just such an object as it
stands.
I have to write code to support the various types and subtypes RFC-XXXX
specifies. As such, it is in my interest to keep things out of it that are not
well-defined.
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.
Fine -- if the Japanese user community wants to write the specification they
are welcome to. I don't think anyone would object.
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.
Also fine -- let them get on with doing it then.
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.
I'll agree to this with one proviso. The use of the placeholder will NOT
become legal until the RFC is written or a reference is given that provides the
specification. Until then it is a placeholder and nothing more; any use of it
is illegal until the specification is also available.
Maybe I've missed something and this document is already available. If so,
can we please have a reference to it to cite?
Note that the IAB may see this differently and refuse to issue an RFC that
references a nonexistent document in ANY context. If this is in fact the case
we may have to remove the placeholder pending completion of the document it
references.
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.
Actually, what is racist is offering the Japanese user community special
consideration that we as a group seem to be unwilling to offer to any other
entity. I don't see the Europeans you are so fond of criticizing trying to
ram in a subtype for which no specification exists. On the contrary, they
went to the trouble of writing an RFC to describe the stuff they want.
Ned