1) RFC-MNEM should be revised to explicitly state that mail messages
using RFC-MNEM must also be fully compliant with RFC-XXXX. To do
otherwise might cause RFC-MNEM messages to be sent that are not
RFC-XXXX compliant and that could cause interoperability requirements.
Is there any problems?
The RFC was designed to be compatible with RFC-XXXX and RFC 1049.
Maybe RFC-XXXX is flawed in not being flexible enough for
providing transformation of the individual body parts.
I am not sure at the moment, but somebody advocated that it
was not needed that transformations could be done - my memory may fail me.
2) I'd really like to see RFC-CHAR to review it for other interoperability
issues. It is an essential part of the RFC-MNEM procedure since
it details the encoding.
If Keld doesn't feel it is worth mailing, maybe it could be made
available for anonymous ftp with the file name and host published
on a note to the ietf-822 list.
OK, they are both (RFC-MNEM and RFC-CHAR) available from
dkuug.dk:~ftp/pub
3) I'm concerned about the "charset" item on page 3 of the RFC-MNEM draft,
it isn't clear but it might be read as encouraging the use of character
set encodings that aren't part of RFC-XXXX in some cases. I hope that
this isn't the intention and it is just a wording problem.
I am not encouraging anything but ASCII and (which was not in the draft
I mailed previously) ICS - invariant ISO 646. The memo specifies
that other character sets may be used when agreed upon, and specifies
via the RFC-CHAR something like 120 different character sets.
But in difference to RFC-XXXX these are not intended at all for
general use. It is intended for User Agent to MTA conversions.
4) I would also like to see the text reference to "ASCII" changed to
"US ASCII" with a reference to RFC-XXXX added and a reference to
ANSI X3.64 added. Someplaces people use "ASCII" when they really
mean ISO 646 or a ISO 646 variant and it is important for the RFC
to be unambiguous.
Well, this is why I did the RFC-CHAR, so that we may get uniform
references to character sets. The RFC-CHAR has the nessecary
identifying characteristics, that was not included in RFC-XXXX.
RFC-XXXX actually explicitely refers to a RFC on character sets,
and I promised Nathaniel to write such an RFC.
When RFC-MNEM refers to "ASCII" it explicitely refers to the definition
of ASCII in RFC-CHAR. There the encoding of every single byte is defined
unambiguesly.
5) How should the Content-Type: header be changed when transformation
occurs ? This isn't clear to me. A detailed example of before and
after transformation would help me.
OK, an example:
The UA generates:
Content-Type: Text/Mnemonic ISO_8859-1 29 1.0 ISO_8859-1 29
This is received by the MTA which is responnsible for transfering
and it does its job in ASCII with intro 38, so the header will be:
Content-Type: Text/Mnemonic ASCII 38 1.0 ISO_8859-1 29
6) Is "communication character set" the character set used during
transport using SMTP or is it the sender's character set encoding
or the receiver's character set encoding ?
This RFC is not directly related to SMTP. It can also be used with uucp
or other protocols. It is meant to be the transport character set,
as also described in the same clause. It can only be something
else than ASCII or ICS if both parties agree and then it is
both the receivers and the senders character set encoding.
7) The example header refers to "ISO_8859-1" while RFC-XXXX uses
"ISO-8859-1".
Yes, we should try to harmonize. I have guidelines for design
of character set names in RFC-CHAR. RFC-CHAR allows multiple
names for the same character set, e.g. also LATIN1.
Keld