A couple of weeks ago I sent a list of outstanding issues with the
current RFCXXXX document. To recap:
1) better define the content- types so that interoperation can be
assuered. This involves definitions such that a sane person can
determine where to position and register their foo files. A sub issue
is whether or not foo-file can be registered under two content-types.
2) indication of "proper" conversion of message in the event they are
needed. The origional theory of the group from all the way back in
St. Louis was that any conversion can be used for any body part (See
Ned's messages). A new view not fully discredited is that there is a
"prefered" conversion for some types and that should somehow be
indicated.
A third issue unresolved that I did not point out was the issue of 8
bit text in the header. Glad to see that my omission did not cause
folks to overlook this important issue :-)
Discussion on the first issue seems to have died out, and I have
received no fundamental disagreements with the strawman defininition
of the content-types. With the suggested changes, Nathaniel should
include them in the next version.
An issue of whether to allow cross-registration of sub-types did not
seem to come to closure, but the prevaling sentiment seems to be to
allow cross-listing as long as they are registered with the IANA
(Internet Assigned Numbers Authority).
Now, I do not think we have made any progress on the second point.
This rather religous point had two viewpoints, 1) Any encoding will
work with any content type and it is up to the gateway or UA to guess
at a "better" encoding and 2) Certian encodings have advantages in
certian places and the user should be able to have control over how
the message gets encoded if done so by a gateway. Ned vs John. Last
person standing seemed to be Ned, with the "any encoding, any time"
position. Either John is KO'd or he has reluctantly agreed. (I can't
see the floor). In any event, at this point, I would like Nathaniel
to put explicit wording indicating that the five transport encodings
imply nothing about the content-type other than how it was encoded, or
what the transport environment is required if it was not. This leaves
the following definitions. Base 64 & Quoted Printable (Understood
meanings), 7 bit (A regular transportable message over old-fashioned
SMTP), 8 bit (A regular transportable message over 8 bit text capable
SMTP's), and Binary (A new kind of scary message transportable only on
new-fangled hard to implement Not So Very SMTP).
AGAIN, Lets not debate the wisdom of BINARY on this mailing list or in
this document.
Now to the Character-set-in-header problem. No resolution and a lot
of calls for punting. The current proposals are 1) Real-headers 2)
Nmonic encoding with a new header-charset line, and 3) quoted
printable encodings with a new header-charset line. Pardon me if I
got these slightly wrong, flame me if they are radically wrong. In
any event the choice of a scheme seems a bit too wrapped up with the
many 822 syntactic clarifications needed. This group did take on an
action in one of these face to face meetings to begin work on a new
822 document or at least a series of patches going beyond Host
Requirements.
As the Chair, I cast my big vote for punting. I have personally
pushed hard (Too hard?) for addressing the character set problems both
in the body and the headers. This is still important, but it is also
important to get this document out right after the November IETF.
Nathaniel, skip this issue, but add text to the effect that this
problem is intended to be addressed in a future unnamed document.
If there are any serious disagreements with the strategy above, feel
free to comment, but please keep in mind the goal of a finished
document in 2 months.
Thanks to all who expressed interest in an Interop meeting of this WG.
There were a lot of folks, including many of the regular face to
face'ers and list folks, but Interop is a hectic week and there does
not seem to be a clear agenda that needs addressing provided the above
makes sense.
Greg Vaudreuil
Message Format Extensions WG Chair.