Happily, we seem to be converging nicely on the few remaining points
of concern. Detailed comments below.
% RFC-MNEM currently states:
Although
this memo specifies ways of doing character set conversions,
it is strongly advised not to use other character sets than
ASCII or its proper subset ICS for general Internet use with
the specifications in this memo.
% I would be happy to change "strongly advised not" to "not allowed".
% I will add wordings on that the other RFCs specify what is allowed
% as described below.
Great.
Although I have been concerned that reading RFC-MNEM and RFC-CHAR
might accidentally cause someone to misconstrue it as encouraging the
use of non-recommended character sets, my chief remaining concern is
that someone will accidentally implement RFC-MNEM in a system without
also implementing RFC-XXXX.
In the context of Internet mail, RFC-MNEM depends on the header
definitions and such of RFC-XXXX. Outside the Internet mail context,
it might not. Some sort of note indicating that within the Internet
mail context RFC-MNEM should not be implemented unless done with
RFC-XXXX also being implemented would eliminate this area of possible
confusion. See below also.
% I have told Randall that the RFC does not primarily specify
% conversions, but a message format for transport.
Fine. See Below.
"This supplements the set defined in [1], and specifies the format
referred to as Text/Quoted-Readable in RFC-XXXX. In all cases where
this quoted-readable format is used in Internet mail, messages using
this format must be RFC-XXXX compliant."
% I state that the RFC-MNEM is "compatible" to RFC-XXXX, is that not enough?
% If we should work further along this line I would rather have any
% wordings that are non-compliant with RFC-XXXX pointed out and
% corrected, or just have RFC-MNEM incorporated in RFC-XXXX - The
% technical part of the text is less than 2 pages, and it is referenced
% anyway in RFC-XXXX. I really do not see any conflict with RFC-XXXX.
% Of cause I want the reference in RFC-XXXX changed from Quoted-Readable
% to Mnemonic, as Quoted-Readable has been seen to be mixed up with
% quoted-printable in some instances.
I would fully support the change in terminology to "Mnemonic"
because there has been inadvertant confusion between Quoted-Readable
and Quoted- Printable in several cases (even where people have been
paying attention).
I would also be happier if the RFC-MNEM material were merged into
the RFC-XXXX draft. That would preclude the implementation concerns I
noted above and tend to generally eliminate potential confusion
amongst future readers and implementers. As Keld notes, the technical
content of RFC-MNEM is quite short and wouldn't greatly expand
RFC-XXXX.
How do others feel ?
Is there general agreement that we should take the content of RFC-MNEM
and integrate it into RFC-XXXX as a single draft ?
% I have asked Randall to identify the difference between the
% information that I have got and what he thinks it should be.
% To my knowledge there is none. If there were, it would
% create a major havoc in the character set world.
I'm told by someone at ISO that the most recent definition of ANSI
X3.4 is materially different from the ISO-646-US definition. It isn't
clear to me if the difference is one in the control-code area as some
posters have suggested or whether it is in the displayable character
area. I'm just trying to raise the question and don't know what the
answer is. I think it is something that is worth looking into. I'm
glad that Keld agrees that if there is a meaningful difference that
we should try to address that.
4) The example header refers to "ISO_8859-1" while RFC-XXXX uses
"ISO-8859-1". RFC-MNEM should change to use the format and
syntax specified in RFC-XXXX.
% As John has pointed out "ISO-8859-1" is not consistent with
% ISO naming. I think we should harmonize the character set names
% on some sound ground, as John also has pointed out.
Fine. Any reasonable naming scheme would make me happy as long as
all the RFCs use the same naming scheme.
5) RFC-CHAR should make very explicit that it is not specifying the
character sets or character set names for use in Internet mail.
The current wording will cause confusion amongst the readers.
% I have added a phrase in the forthcoming RFC-CHAR draft:
% RFC-CHAR does not indicate anything about the validity of using
% these specifications in any Internet standard, but you should consult
% each individual Internet standard to see which character sets and
% names are allowed.
Great. Such an addition should significantly reduce the potential
for confusion.
RFC-XXXX also requires that the existing standard "X-something"
format be used for those character sets defined by local agreement
and that the IANA is the sole authority for adding all other charset
names to Internet standard status.
% I would be unhappy about specifying non-allowable RFC-XXXX names
% with an "X-" as the RFC-CHAR could be very usable in other Internet
% standards, eg. Internet OSI specifications. Then it would be ugly if
% the OSI RFC would have to use names like "X-" for something that would
% be perfectly valid in their RFC. I would rather advice RFC-XXXX to
% advice users of the "X-" convention to use the names whenever possible
% from RFC-CHAR with a prepended "X-".
Perhaps the reference in RFC-XXXX will suffice in conjunction with
the statement in the future draft of RFC-CHAR indicating that readers
should consult the relevant Internet standards (e.g. RFC-XXXX for
mail) and the IANA for guidance on which character set names are
currently valid and which character sets are recommended for use in
the Internet.
6) It would be desirable for all references to "ASCII" in RFC-MNEM and
RFC-CHAR be changed to "US ASCII" so that people outside the US who
are accustomed to referring to ALL 7-bit character sets as "ascii" in
common usage do not inadvertently misread the content of the RFCs.
% I have told Randall that I would be happy to do that, provided that
% US ASCII will be put into one token, like "US-ASCII".
% But then I also share Jonh's view that ASCII is ASCII and that US
% is superfluous. Anyway this needs resolvement of the naming,
% as I certainly would prefer the naming of each character set
% to be one token.
I have no objection to the use of "US-ASCII" versus "US ASCII".
I am aware of recurring problems both inside and outside the US of
people referring to various ISO 646 variants and even proprietary
8-bit-enhanced variations all as "ASCII". This is something that I
have seen for several years in the course of my work in developing
internationalised software and in working with other standards groups.
I think that the people on this list are well aware of what ASCII
really is, but many people are not as precise in the common usage.
By prepending "US" or "US-" it will eliminate another area likely to
cause accidental confusion and incompatible implementation.
7) It isn't clear to me that "quoted printable" is useful for many
non-European languages because many glyphs cannot be usefully
represented using strings of US ASCII. I'm not sure that this is
fixable, but I'm concerned that we not end up being Euro-centric.
We should in fact try to address the non-European concerns
(Chinese, etc.) as well.
% I share your concerns about quoted-printable. I even think that
% in Europe qouted-printable will be a nuisance, reading all these
% hex values will not make life easy. We have a discussion on some
% news group on 8-bit *news* and that conversation is partly carried
% out in stripped 8-bit (which is like quoted-printable, but more
% compact). The last stripped articles I almost gave up reading
% as they were too ugly to read. Other persons had comments to the
% same effect. Quoted-printable will be worse.
% You did not mean "quoted-readable", did you?
Well I meant both really.
I should have explicitly indicated quoted-readable as well.
As I've mentioned to Erik Van der Poel (spelling ?) in email,
I do not see a solution to the non-European-language support issue
in Mnemonic/Quoted-Readable. So this isn't a criticism of the RFC
author, but rather just an ongoing concern. Maybe someone else will
see some solution (which is the reason I raised it on this list :-),
but I've thought about it a fair bit and haven't yet seen one.
To be honest, I'm really quite pleased overall with how the set of
RFCs is shaping up. It certainly sounds from Keld's note that the
next drafts of RFC-CHAR and RFC-MNEM will resolve most or all of my
concerns. I look forward to them.
Ran
randall(_at_)Virginia(_dot_)EDU