Sigh. In a pleasant, relaxing, weekend, I had finally decided to throw
in the towel and stop objecting to a content-charset header, in the
interest of peace and consensus. This morning I come in only to find
that there's no consensus there, and that Mark won't let me back down...
Join the club ;-)
Is there anyone for whom the attribute/value syntax is a show-stopper?
Certainly I can live with it, and apparently Mark can't live with the
alternative. How about moving all charset information into
attribute/value pairs, and merging text & text-plus? Whose ox does that
gore?
Not mine. I think it is a poor idea, but I can live with it.
As to Mark's suggestion that we simplify the entire content-type syntax
to something like
type [/subtype] *[attribute=value]
The only thing this really afects is the multipart type, which is the
only one for which anything else is currently defined. Does anyone
object to adopting Mark's change, and making multipart something like
multipart/mixed ; boundary=foobar
In the interests of peace, harmony, and consensus, I am prepared to
accept all of these changes.
I accept them also, for the same reasons. I have only one quibble -- if
we are going to do this, I want it done RIGHT NOW. I don't insist on a new
draft (it would be nice) but I want to hear some additional voices on
the list saying that this is OK. I don't want to get into this only to find
out it is someone's show-stopper in Santa Fe.
In another matter, Alain Fontaine has convinced me that a checksum would
be a good idea. I'm inclined to do this via a separate (and
optional/ignorable, for those who so desire) Content-checksum header.
Does anyone object to this? Is it necessary to include this as part of
the RFC, or can we allow it to be added by a later RFC?
I agree. I think we need one. I know a fair amount about this stuff and
also have a fair amount of experience with the various algorithms. We should
talk offline about developing the text that describes this.
Ned