[Top] [All Lists]

Re: RFC-MNEM & RFC-XXXX compatibiity

1991-07-04 12:46:37
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

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

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 

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.


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