ietf-822
[Top] [All Lists]

The "final" draft

1992-01-07 13:15:23
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?

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