Bob, Neil, and others...
I can't speak for Mark, but I am concerned about what Bob describes as
orthogonality, along with a few other issues. Most of those also have
to do with the various failure cases.
Regardless of the procedural issues--even if everyone who was interested
in these issues in the world had been polled and had agreed--I don't
think there is any way to say "it was decided, chisel it into stone,
further discussion is prohibited". There are two reasons for that view:
(i) This whole mail business is a system, and the issues are issues as
part of that system. Things change, understanding changes, we make
other changes that have impact and change understandings. A change in
the position about nested encodings, changes the significance of
distinguished recognition of character sets (independent of syntax
choices) and may change the relative merits of syntax choices.
Intermittent debates about the organization of types and subtypes may
also change things, if they ever lead to anything. And so on.
In this regard, while the separate identification of character sets
(something I've been arguing for at least as long as Neil has) didn't
come, to use Bob's phrase, "out of the hat" in Atlanta, pulling the
optional content-type parameters out into separate headers arguably did.
As long as the information is present, those, too, are aesthetic
decisions about syntax as long as one can ignore the failure cases. If
one considers the possibility of failure cases, then, those decisions,
too, are part of the system and don't exist in isolation.
(ii) I am less sure with each passing day what we are talking about with
RFC-XXXX-Atlanta as distinguished from the internet-draft version of
RFC-XXXX. I cannot evaluate much of this stuff properly unless I can
look at text that specifies what is going on, what the cases and
restrictions are, and which really spells all of this out. I happen to
think that a near-orthogonality by same-header binding of character set
to content type will create greater robustness.
But it is possible, indeed likely, that I'm not understanding some of
the safeguards that the people who advocate lots of headers intend to
build in. If I did, I might change my mind, since my personal aesthetic
instincts usually favor more headers, each very simple, to fewer headers
with more complex syntax.
So, when I read the procedural complaints, I am inclined to respond
with one of my own. The Atlanta minutes contain almost no details.
They imply that someone is going to go out and write some text and
provide some details. I'm still waiting and would argue that, if no one
does that job within some finite time, the "Atlanta decisions" should
just expire. To put this differently, the advocates of the proclaimed
Atlanta changes to RFC-XXXX should be posting text that would modify
RFC-XXXX (or new versions of it) that reflect those changes and getting
agreement (at least among those who were there) that the text actually
reflects the decisions made.
--john