A first pass at the October draft of RFC-XXXX:
RECOMMENDED/NOT RECOMMENDED/ETC:
This material is currently scattered in a few places in the
document. I would prefer to see it collated together exclusively in
an appendix because ultimately only the IAB determines what is and
isn't currently in what state. By having it collated in a single
appendix of the document, potential future confusion when the status
of things in this RFC changes (e.g. when the ISO-10646 email use RFC
gets published) is minimised.
In my mind I see three potential kinds of tokens and combinations:
1) a single recommended character set and encoding (I strongly
prefer ISO-10646 + BASE64 once that happens)
2) other permitted ones (e.g. ISO-10646 in Mnemonic form or
ISO-8859-N in either BASE64 or native or Mnemonic form or
other similar ones)
3) not recommended ones (all private agreements, things not
described in an RFC, etc.)
AUDIO:
I gather that the Sun and Next (X-SUN & X-NEXT) formats for audio
data are the same. If so, I'd like to suggest that that header format
and a reference to the appropriate telephony standard document be put
into a separate very small RFC along with some standard (not
X-something) token name for use with that format in RFC-XXXX mail
bodies. My point in doing so is to try to encourage other folks to
implement at least that same sound file format and mail exchange
format. If it is inside an email RFC, it will be hard to get people
to consider it for use as a portable file format and that will make
the transmission of sound in email less likely to be interoperable.
Another thing is that RFC-XXXX is already quite large and complex and
so putting that into a separate RFC helps keep the documentation
manageable (in the same way that having RFC-MNEM and RFC-CHAR as
separate is helpful). I'm not at all religious about this idea, but
wanted to throw it out as food for thought.
OPTIONAL HEADERS:
I'm not very enthusiastic about any of these. I'm not sure that
they are worth the added complexity and it isn't at all clear to me
that they will be widely implemented since the mandatory
implementation is so complicated already. If there were a sudden
swell of desire to remove some or all of them, I'd support it. I'm
not adamant that they go however. (You may safely assume that they
won't be implemented in any RFC-XXXX software that I write -- though
I'm in real deep with implementing Secure SNMP just now anyway :-)
TRANSPORT:
The document is laced throughout with implicit assumptions that the
only SMTP transport widths available will be 7-bit or 8-bit with
a future potential for "binary" (whatever that means :-). Those
assumptions are no longer valid thanks to the efforts of John Klensin.
I think that RFC-ZZZZ will end up mandating 7- and 8-bit transport
and providing the architectural hooks for clean extensions in a very
small additional RFC to support 16- and 32-bit transport. I think that
the same rationale that has caused us to move towards 8-bit transport
will end up eventually causing a movement towards 16/32-bit transport
once the IS 10646 happens and vendors start implementing it widely.
We need to be sure that RFC-XXXX doesn't have architectural impediments
to that possibility.
To that end, under section 5's discussion of Content-Transfer-Encoding
I would like to see the discussion of the "8bit" and "binary" tokens
to be generalised a bit. Proposed text (edit however suits) follows:
"The difference between "8bit" or bit-width tokens and the "binary"
token is that "binary" does not require adherance to SMTP limits
on line length and CR/LF semantics while the bit-width tokens do
require such adherance. If the message contains unencoded data,
the appropriate bit-width Content-Transfer-Encoding token must be
used (e.g. "8-bit" for unencoded 8 bit wide data). If the message
contains unencoded binary data, the "binary" Content-Transfer-Encoding
token must be used."
"NOTE: The distinction between the Content-Transfer-Encoding
values may seem unimportant in that all of them really mean
"none" -- that is that there has been no encoding of the
data for transport. However clear labelling will be of enormous
value for RFC-ZZZZ to RFC-821 gateway implementations.
[Propose moving this second paragraph of notes to the appendix
dealing with conformance and what is recommended, etc. ]
[Keep 3rd para of notes as is]
[Keep next para of text as is]
"If a Content-Transfer-Encoding header field appears as part of
a message header, it applies to the entire message body. If a
Content-Transfer-Encoding header field appears as part of a
multipart message encapsulation's headers, it applies only to the
body of the encapsulated part. If the encapsulated part is itself
of type multipart, of course, the Content-Transfer-Encoding is
not permitted to have any value other than a bit-width (e.g. 7-bit)
or "binary".
NEW CONTENT-TRANSFER-ENCODINGS:
Please add a sentence on page 13 towards the end of 5.0 to
read something like:
"The definition of new content-transfer-encodings is explicitly
discouraged and should only occur when absolutely necessary. All
content-transfer-encoding namespace except that beginning with "X-" is
explicitly reserved to the IANA for future use. Private agreements
about content-transfer-encodings are also explicitly discouraged."
TEXT SUBTYPES:
Please drop "ISO-10646" as being a legal predefined subtype in the
BNF-like material on page 19. The text on page 21 in the ISO 10646
subtype subheading should be expanded to clearly indicate that the
intent of the working group is that an RFC specifying in detail its
use will be published very soon after ISO 10646 is approved and that
that ISO 10646 subtypes will be the preferred subtypes for use in
enhanced Internet mail after they are defined.
Similarly, pending the work that Erik has agreed to undertake,
ISO-2022 should be dropped as a legal predefined subtype in the
BNF-like material on page 19. It isn't clear what token name
will end up being selected by Erik's sub-working-group and
so RFC-XXXX should just use the text on page 21.
Please rephrase the ISO 646 text at the bottom of page 19 to read
more along these lines:
"National use variations of ISO 646 are not ASCII
and their use in Internet mail is explicitly discouraged.
The omission of ISO 646 Text-Subtype values is deliberate in
this regard. The Text-Subtype of "US-ASCII" explicitly refers
to ANSI X3.4-1986 only. The Text-Subtype value "ASCII" is reserved
and must not be used for any purpose.
(I think the existing "should not" phrasing is too weak and really
want "must not" and "non conforming" phrasing as in the example above)
On page 21 where ISO-10646, ISO-2022 and MNEMONIC are discussed,
the wording should be changed to make clear that the headings are
topical and don't specify the string tokens that will be used by
the separate RFCs for those 3 cases.
Also, (in line with my first comment at the top) the sentence that reads:
"Their use is not recommended in advance of their complete
specification" should be changed to something more like:
"These future subtypes should not be used until RFCs
describing their complete specification and use, including the values
of their standard subtype strings, are published and approved as
standards-track RFCs by the Internet Activities Board. The IAB
has sole authority to determine standards in the Internet and the
status of various RFCs does change with time."
Please change the last sentence on page 21 to indicate that all name
space not beginning with the string "X-" is explicitly reserved to the
IANA and may not be use in any private agreements.
UNICODE:
Please remove or rephrase the paragraph at the top of page 22 in
section 7.1 to indicate the apparent rapproachment (sp?) that has
occurred between UNICODE and the DIS 10646 communities during the
summer of 1991. Removal might be best since it isn't normative
material anyway.
MULTIPART:
I'm unlikely to ever use this, but I know that it is likely
to be used a lot to add audio to messages and such like. I haven't
looked this over in detail and have no really strong opinions about
it -- other than a general desire to keep it as simple as practical.
TEXT-PLUS:
I'm concerned about the inclusion of troff and its current syntax
because most troff is written using one or another macro packages
and it isn't clear how that macro information is passed with the
data. I don't use TeX and assume that sufficient information is
being passed in that case. To me, only richtext has a sufficient
definition.
BINARY Content-Type:
I see this as insufficiently specified, particularly with regard to
the conversions and binary data types. Either add more definition of
allowed types (e.g. tar) and conversions (can't think of any desirable
ones) or make this a place holder with rationale deferring to a future
RFC. At a minimum, the mechanism for defining new legal types (IANA ?)
should be mentioned and some steps taken to preserve the namespace
from private agreement intrusion.
APPLICATION Content-Type:
Same comments as for binary.
IMAGE content-type:
It would be desirable to point to a readily available document
for ppm and pgm since man pages are not universal and the contact
email address may change with time.
APPENDIX A:
Item 4 should be slightly rephrased to change "ability to remove
any Content-Transfer-Encoding" into "ability to remove any Content-
Transfer-Encoding standardised in this RFC."
APPENDIX D:
I'd rather delete and just refer to ANSI X3.64-1986 on the same
grounds that you don't replicate the RFC-822 BNF here -- namely
potential accidental undiscovered error or confusion. Since we
really do mean ANSI X3.4-1986 let's just incorporate it by reference.
Ran
atkinson(_at_)itd(_dot_)nrl(_dot_)navy(_dot_)mil