My assumption is the group's primary goal, right now, is to get MIME
published as a Proposed Standard. If any of you think that there is
a higher-level goal, which thereby will prevent the Internet from
pursuing use of MIME, please get the working group to agree with you, or
else please delay such discussion until after MIME is published, or please
take it elsewhere.
Strong language? You bet.
The group is discussing a number of issues and I am hoping that we can
make sure that our goals are kept in focus.
I think that all of the points being raised are interesting. But it is
not clear to me that any of them, except the newline issue, should be
discussed at this time. Why?
1. MNemonic.
The IESG has expressed a concern that MIME not create dependencies or
have citations to work that is not fully adopted by the IETF. Those who
object to this point of view are free to debate it with the IESG. If the
working group, as a whole, objects to the IESG's view, then it should
represent itself as such. While I do see that there is some constituency
for the objection, it does not appear to have the sway of the bulk of
the working group.
I will stick my neck out farther and observe that such adamant objections
as are being raised about this issue appear to reflect the erroneous
belief that citation in MIME is required for legitimate use. It isn't,
as I and others have observed repeatedly. The IANA registration process
is entirely adequate for gaining formal acceptability of use, and separate
standardization is entirely adequate for gaining formal mandate of that
use. To my way of thinking, that eliminates the issue.
The IETF has a practise of doing what it can, when it can, and carving off
the stuff that takes longer. This is one of those cases (IMnot-veryHO).
2. Body-Part, Body, Part, etc.
This is an issue of MIME linguistics. I think it is important to get such
writing correct, but it is not required that it be 100% debugged in order
to go to Proposed. Significant "writing" changes may be made to a spec,
as long as it does not significantly alter the technical content, without
altering the spec's progression along the standards path. Hence, this issue
should be pursued, but not right now.
3. Transfer-encoding (10646, UTF, etc.)
This does not discuss any failure of MIME to function. It discusses a
future *possible* case of inefficiency. As such, the need for this is
not immediate or guaranteed, though my own opinion is that attending
to this possibility, IN THE FUTURE, sounds quite worthwhile.
4. Compress
MIME has a mechanism for citing various conversions, but does not
specify the detail, leaving that instead as a private item, though
open to public registration through IANA. Hence, it involves nothing
that is critical to the current MIME spec or goals.
-----
That is the list of issues that I gleaned from the last week's comments.
The only item which pertains to the possibility of a TECHNICAL FAILURE
of MIME is with respect to the handling of newlines, local versus network,
with quoted-text. I find it curious that there have been so many people
implementing MIME, yet this issue has not yet caused them to beat
Nathaniel and Ned up for clarification. Curious.
My understanding is that Transfer-encoding is only to get the message to
go over "crippled" wires which don't politely handle 8-bit types of
data. As such, this says that just-prior to being sent to the
Transfer-encoding engine, the mail object must be in inter-operable
format. For text, this means that "newlines" must be in CRLF form,
although CR and LF, as pure data characters, my exist also.
How one implements this on one's system is irrelevant. Hence, some
may build the functionality in a split between UA and MTA code, but
the object that goes out needs to have anything that is multi-line
text have its line-termination be in network-standard fashion. To
me, this means that any quoted CR, LF, or CRLF is not a newline.
Whether my own interpretation is correct or not, I will request that
Nathaniel, Ned and Greg drive the wg discussion to focus on only this
issue and get closure. NOW!
The IESG is having a telecon on Thursday. It will be a shame not to
have MIME able to be submitted to them (modulo the LAst Call again being
issued) and, instead having to wait until after the upcoming IETF.
(The IESG can decide to recommend MIME, pending the 2week Last Call, so
that only a major rumble from the Last Call would disrupt the spec.)
Focus, people. Focus.
Dave