-----------------------------
Application message id: 04112292011991/4015 X400
Grade of Delivery: Normal
-----------------------------
VMSmail To information: MUVAXA::MRGATE::"mci
_mta::*emsinternet::*mbx1ietf-822(a)dimacs.rutgers.edu::su=IETF_822
_WG"
Sender's personal name: John C Klensin
I'd like to make a very small and tentative dent in the deafening
silence, both about audio and about several other things, including the
growing checksum consensus. Personally, I don't know enough to have an
opinion on the one, and I am strongly in favor of the checksums on
Base64
binary. But this rush to incorporate ideas that were un-thought-of and
un-heard-of only a month ago is a bit scary. Are these things that
ought
to be segregated into separate RFCs, turning the corresponding sections
of
RFC-XXXX into placeholder/pointers?
Again, I'd personally favor a single RFC that covers everything, but,
if
we are not going to have it (for any reason at all), I'd prefer that
RFC-XXXX cover only those things that we are rock-solid certain about
and
provide a framework but minimal details for the rest.
Two observations from experience with related things...
-- Optional/ignorable checksums are about as bad as "no checksums".
Make it required or forget it. Conversely, apply them only to that w
hich
can be protected against all of the "normal" things that happen to
mail,
i.e., to Base64-coded-binary stuff only. If the checksum business
requires deferring, then defer specification of the details of binary
body
parts along with it (I don't think it does, and favor the proposal to
incorporate the checksum at the end of Base64).
-- While I'm comfortable with Keith's proposal as it seems to be
evolving, I share Dave Crocker's concerns about anything that drives us
toward the "local option" or "profile" business, as well as concerns
expressed by him (and others, including myself) about creating
inter-header dependencies, order dependencies, etc.
Finally, on a less philosophical topic...
Content-type: TEXT/ISO-2022; charset=US-ASCII
Remember, ISO-2022 is not a character set, it is a means of
representing
character set shifts.
This mailer accepts ISO-2022 input from the user. This could be pure
ASCII,
or it could have ISO-2022 sequences that shift into JIS. There is no
way the
lower level can know, unless it actually examined the text. Actually,
it is
perfectly valid ISO-2022 even if there are no shift sequences in the
message!
Mark (and others),
I'm still waiting to see a real proposal for how to handle 2022 (if
at
all), and continue to believe that it should be banned from/by RFC-XXXX
until such a proposal appears. In particular, I think there is a very
strong case to be made that a 2022 header should announce all of the
character sets that might be designated (note "might", which avoids
extra
burden on the lower level--I'm requesting a repertoire, not an exact
list). So I'd want to see your example read (without quibbling about
how
the names are spelled)...
Content-type: TEXT/ISO-2022; charset=US-ASCII,JIS
That, of course, provides another little problem for the proposed
syntax.
Maybe
Content-type: TEXT/ISO-2022; charset=(US-ASCII,JIS)
but this gets more and more complicated from a parsing standpoint. :-(
Aside to Nathaniel and others:
Content-type: text; charset=iso-2022
ISO-2022 is NOT a character set. NOT a character set. NOT a
character
set....
john
p.s.: Please ignore the "From" address on this mail. I'm not
responsible
for it and can't get it fixed in the near term. Flames, if any, to the
gateway maintainers.