ietf-822
[Top] [All Lists]

Re: ISO-2022 as a separate RFC

1991-11-13 04:00:36
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


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