I've submitted the latest version of the MIME document to the Internet
drafts people, and Greg will then be submitting it to the IESG for
consideration as a proposed standard.
I put the word "final" in quotes because, of course, it ain't. In
particular, the IESG will likely be very concerned with issues of
references, etc. In particular, they may not let us keep certain
references to character sets or image formats without improving our
citations to point to definitve references. Toward that end, I would be
very grateful if anyone who can point me at a standard citation for such
things as GIF, G3FAX, JPEG, etc. would do so.
The new draft is very much like the last one -- the changes are all
textual and not substantive, with the exception of the "local-file"
access-type for message/external-body. You can retreive the full
document in the usual way, anonymous ftp from thumper.bellcore.com, in
pub/nsb/BodyFormats.{ps,txt,ez}. Or you can wait for the internet draft
publication.
Here is a summary of the changes:
0. Fixed 41 more typos or minor clarifications sent in by astute
readers (32 by Erik van der Poel -- nice job!)
1. Added the following sentence to the character set prose:
The use of the string "ISO-10646" as a character set
specification is hereby reserved for future use, once the
ongoing efforts to define a standard universal character set are
completed.
2. ISO-2022-jp charset prose simplified:
ISO-2022-jp -- ISO-2022, as defined in [ISO-2022] specifies ways
of designating and accessing character sets, rather than,
itself, being a character set. Its use in mail will probably be
strongly desired by communities who are already using it locally
to handle multiple sets of characters and multi-byte characters.
It appears necessary to explicitly specify the ISO-2022 methods
that will be permitted in text mail so as to avoid the need for
private agreements about, e.g., the specific character sets
being used in messages. A specification corresponding to the
existing practice of ISO-2022 use in Japan is included as
Appendix F.
3. First paragraph of ISO-2022-jp appendix simplified:
This appendix briefly describes the existing practice for the
use of ISO-2022 in Japanese electronic mail. This description
is for informational purposes only, and is not intended to guide
an implementation of ISO-2022-jp mail senders or readers.
4. Added access-type "local-file" to application/external-body.
There's virtually no additional prose, because its semantics are
essentially identical to AFS, so that the discussion of the two is
combined.
5. Strengthened IANA registration prose slightly:
2. New "Standard" values must be documented, registered with,
and approved by the Internet Assigned Numbers Authority (IANA)
at ISI, by email to IANA(_at_)ISI(_dot_)EDU(_dot_) Where intended for
public
use, the formats they refer to should also be defined by a
published specification, and possibly offered for
standardization.
6. Clarification in appendix a:
2. Recognize the Content-Transfer-Encoding header field, and
decode all received data encoded with either the
quoted-printable or base64 implementations. Encode any data
sent that is not in seven-bit mail-ready representation using
one of these transformations and include the appropriate
Content-Transfer-Encoding header field, unless the underlying
transport mechanism supports non-seven-bit data, as SMTP does
not.
7. Fixed the richtext-to-text translator to handle nested comments properly.
8. The charset discussion has the following changed paragraph:
An initial list of predefined character set names can be found
at the end of this section. Additional character sets may be
regisetered with IANA, although the standardization of their use
requires the usual IAB review and approval. Note that if the
specified character set includes 8-bit data, a
Content-Transfer-Encoding header field and a corresponding
encoding on the data are required in order to transmit the
message via some mail transfer protocols, such as SMTP.
9. Added a few similar phrase-tightenings from Dave Crocker, though
probably not enough to satisfy him. :-)
That's all. Let's take a break for a while now, OK?