Keld, Ned, Greg, and other ietf-822 people,
I owe an apology to all of you.
Upon careful re-reading of the "RFC-CHAR" document, it turns out that
some of my previous concerns were unfounded. I have no excuse for this
neglect, so I feel that I must apologize. In the future, I will try to
read the documents more carefully, before making comments.
Specifically, there were a couple of paragraphs that nullified some of
my previous concerns (from draft-ietf-822ext-charsets-02.txt):
This memo does not indicate anything about the validity of using these
specifications in any Internet standard, so you should consult each
individual Internet standard to see which coded character sets and
names are allowed there.
And:
Data encoded in a mnemonic charset is intended to be read by the end
user possibly without further treatment. If the transport encoding
and the presentation encoding for the user differ, it is recommended
that the data be translated into a mnemonic representation in the
presentation encoding.
This second paragraph could be taken to mean that e.g. Japanese is
encoded in e.g. 2022 "on the wire" (i.e. "transport encoding"), and
that it may be converted to mnemonics for "presentation" on the
display (e.g. in Europe, where many people can't display Japanese).
Now to respond to Keld's message:
3. mnemonic with & as intro-char: you have a good idea what
is in the text, but the & is disrupting your reading.
Have you tried using underline "_" as the intro-char? In my opinion,
it seems to be less disruptive. (But I do not read text with accented
letters very often, so I guess actual users like you should be the
judge.)
Well, I would be unhappy about removing the specification of japanese
character sets from RFC-CHAR. This is because I need it to specify
iso-2022-jp.
OK, I think I now understand why you want to include iso-2022-jp in
RFC-CHAR. (Just to make sure, perhaps I should write down my current
interpretation of the situation: You want to include the information
that is needed to be able to convert between current "transport"
encodings and the mnemonic "presentation" encoding. Japanese is
usually encoded in iso-2022-jp, so you need to include its
specification as well.)
I'm not sure about this, but would it make any sense to factor
iso-2022-jp out of RFC-CHAR and MIME? Perhaps it would be a good idea
to make RFCs rather modular? To quote from the "standards process"
document (draft-iab-standardsprocess-01.txt):
3.1.1. Technical Specification (TS)
A Technical Specification is any description of a protocol,
service, procedure, convention, or format.
...
3.1.2. Applicability Statement (AS)
An Applicability Statement specifies how, and under what
circumstances, one or more TSs are to be applied to support a
particular Internet capability.
...
However, a TS that is likely to apply to more than one domain of
applicability should be developed in a modular fashion, to
facilitate its incorporation by multiple ASs.
Well, I'm sorry to say that I have not found Keld at all willing to
make changes that I propose.
I think this is too negative wordings for our relations.
I agree. I think I over-reacted, and I'm sorry.
If IETF WG meetings mean anything, we have decided to make RFC-CHAR
a RFC a couple of times. I think there are minutes showing this.
The WG cannot make RFC-CHAR an RFC. The WG can recommend making it an
RFC, but I believe that the final decision is made by the IAB and
IESG.
Also, it is obvious that there are people that cannot attend the
meetings, so decisions should not be made solely by the attendees.
The IETF WGs are made up of individuals not necessarily representing
their organizations, so one cannot expect these people to have the
funds to travel to far-away meetings.
Latin-1 would be only a small fraction of the work, and
unsatisfactory for the scope I have tried to address.
I understand your position. How should we proceed from here? Since
RFC-CHAR is so big and difficult to check, it may take a long time to
get it accepted as an RFC. Perhaps we should split it into several
parts? Or maybe have separate documents that point to specific parts
of RFC-CHAR? I'm quite convinced that a mnemonic-like approach for
Latin-1 is a great idea, and really needed soon.
Best Regards,
Erik