Thanks Ned, your comments are always sharp and precise.
On 17/Jun/10 18:57, Ned Freed wrote:
On 15/Jun/10 17:21, S Moonesamy wrote:
> There is currently a WGLC for
> draft-ietf-yam-rfc5322bis-msgfmt-pre-evaluation.
RFC 5322 mentions MIME extensions a few times, e.g. in section 2.1:
That's incorrect. Although the specifications allow for it, there's no such
thing as a "MIME extension" presently. What you're referring to is the fact
that MIME extends the basic message format. A very different thing.
Note: This document specifies that messages are made up of
characters in the US-ASCII range of 1 through 127. There are
other documents, specifically the MIME document series ([RFC2045],
[RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that
extend this specification to allow for values outside of that
range. Discussion of those mechanisms is not within the scope of
this specification.
I'm not a MIME expert, but I thought that MIME had been designed to be
transparent to old software.
Also incorrect. MIME can be used in a variety of ways. One of those ways -
where all 8bit and binary material is encoded - is backwards compatible with
old software. Other ways - where either 8bit or binary material is
allowed, are not.
This was all part of MIME from the very beginning.
Although it seems correct to mention
MIME, as it provides further structure, the specs that actually break
US-ASCII are RFC 1652 and possibly RFC 5336.
Nope. RFC 1652 (or more properly, the 1652bis draft) provides a means of
transporting 8bit MIME over SMTP. But it refers back to RFCs 2045 and 2046 for
the specification of 8bit content. It in no way, shape or form extends the
message format itself; it only provides the means for transporting that
extended format.
Setups exist that use RFC 5322 format messages extended by MIME to 8bit or even
binary and which don't use SMTP at all.
As for RFC 5336, while it does extend the formt of RFC 5322 messages very
substantially, it's an experimental RFC. Not informational or standards track.
Moreover, the current plan is to replace it with a document specifying a
considerably different approach, at which point it will move to historic.
It would therefore be totally inappropriate to reference it, or any of the
other current EAI documents, in a standards track RFC. That will probably
change once EAI produces a new set of standards track documents, but we'll
deal with that issue once it arises, not before.
What am I missing?
Basically you're confusing format and transport specifications. They are in no
way the same thing.
Ned
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
