MIME Folk,
First of all I would like to applaud the group for the fine work in
creating MIME. I know how difficult it has been and the work hasn't
always been pleasant. However, I think that we will soon see the
rewards since MIME fills a long standing need.
The IESG has some questions and concerns about the MIME document that I
would like to put to the Working Group. I apologize for taking this
long to get this to you, but catching up on the group discussions (that
are still going on at a furious rate!) has taken some time, plus my
employer has wanted me to do some of the things that they think that
they pay me for ;-).
There has been a lot of discussion about what is stable enough to go
into this document and what should be pulled out for now. I view MIME
to similar to SNMP where there will be the protocol definition and
standard objects that will be defined over time. SNMP has MIBS, MIME
has body-parts. The purist would say that they should all be separate
documents, but we also know the value of not having to gather a dozen
documents and then figure out how to fit them together. As was
discussed, it is possible to separate the "trouble makers" out of the
document later to allow MIME to progress. So if possible, you should
make sure that any potential trouble makers that are left in the
document can be easily removed without degrading the rest of the
document.
I also have concerns about references to other standards that are not
yet finished or do not yet show a strong likelihood for international
use. I think that this is an area where the IAB might bounce it back
for policy reasons. Either there needs to be a firm spec from another
standards body that can be referenced, or the spec created in the IETF
and documented in an RFC.
Specifically, online files and Internet Drafts are not acceptable for
citation. Note that documents on the standards tracks of other
organizations can be cited (e.g., an ISO DP) but those documents must
be full standards by the time MIME becomes an Internet Standard. Since
this causes MIME to have a serious dependency upon the work of outside
agencies, the group should strongly consider removing any such
citation, unless the basic MIME mechanisms will not work without the
cited specification. It is the opinion of the IESG that there are no
such MIME requirements, so that citations to outside specifications
which are not yet formal and full standards is not required.
The IESG has reviewed the document and sees the following changes as
necessary for advancement to Proposed Standard. There are also several
outstanding questions which need clarification.
1) IANA registration procedures. The document needs to state
explicitly that IANA maintains the registry of ALL character sets and
content-types which are publicly authorized. So, there should be a
new appendix contain a template for submissions of new character sets
and content-types to the IANA.
Also, there is some ambiguity in the model of the extension
mechanisms of the current document. The document appears to allow
extensions both by defining new content-types and by defining new
values for content-type attributes. The relationship between
registered content-types and "attributes" like character sets and
access types is unclear. The SNMP MIB documents present a well
defined model for extensions.
2) Message/External-body - The current specification seems
inadequately precise or constrained. The specification should be
fleshed out so that a "new" reader of it will have all of the
necessary information to implement it. It is the impression of the
IESG that the difficulties, here, are only with the language of the
specification and not with the intent or apparent capabilities of
this feature. In other words, all that seems necessary is more and
better words. In particular, it should state what access scenarios
it supports, and how to regiser additional access-types, should
provide full specification of the information needed for each those
scenarios, should properly provide formal citations for relevant
access methods (e.g., the FTP RFC and Host Requirements) and should
specify exactly when and how the contained "text body" part can and
should be used for "LISTSERV" types of file servers.
4) RFC-CHAR. This, too, is fairly new. Further, the area of
character sets is ripe with disparate points of view, so that the
IESG recommends that RFC-CHAR be pursued and discussed independently
of MIME, with IANA registration being open for later inclusion of
RFC-CHAR when it has shown significant adoption.
5) Several character sets referred to in the document have a state of
"real soon now", in particular ISO-8859-10, ISO-2022-jp, and
ISO-10646. If they are referred to in the document, they need a
citable reference now.
Since ISO-2022-jp involves a sphere of Internet usage with which the
IETF has little experience, and recent comments from Korean and other
groups suggests continuing questions, the IESG recommends that its
citation should be removed from MIME, with IANA registration offering
a path for later inclusion, but through an independent (set of)
document(s) with their own authors.
6) Image formats: A number of the citations do not give the reader
adequate ability to locate the specifications. Whenever this is due
to the lack of formal publication and standardization of an image
specfication, its reference should be removed. In particular, I know
that the document coming from the FAX WG is not hard document yet, so
it seems unreasonable to have it in the document. (I guess this is
the down side of things being inter-related in the IETF)
Technically MIME looks like it will meet all our needs. I like the
historical additions so that people won't have to wonder why certain
decisions were made.
Russ
Russ Hobby INTERNET:
rdhobby(_at_)ucdavis(_dot_)edu
IETF Area Director - Applications BITNET: RDHOBBY(_at_)UCDAVIS
UUCP: ...!ucbvax!ucdavis!rdhobby