On Thu, 24 Oct 91 13:37:39 PDT, Neil Katin wrote:
We've gone over this territory many times; I suspect that consensus
will not appear via email, since the loudest people tend to drown
out everyone else.
I am totally disinterested in any standards that are not decided by e-mail,
since only those who can afford to attend IETF meetings en masse go to IETF
meetings.
It used to be, up until a few years ago, that protocol design decisions were
done by e-mail. Now what we have are protocol design by coup d'etat, with
IETF meetings undoing months of e-mail work because critical people felt it
was unnecessary to waste their limited travel budgets on what seemed a
foregone conclusion.
I think that the list has admitted that character sets are needed for
more than just type "text". So we need a header somewhere to represent
this. Given that point, I am against representing the character set
both as an optional parameter and as a subtype. Since it cannot
always be a subtype (for application types, for instance), I strongly
fell that character sets should be represented via a parameter.
I don't think there is any disagreement here.
Content-type: Type/Subtype; charset=character-set
and:
Content-type: Type/Subtype
Content-charset: character-set
No matter how much people flame about this, it seems clear that there
is no semantic difference between the two proposals; one proposal
uses the existing header name space; the other creates a new namespace
under content-type.
Although this may appear to be syntactic sugering, there is a major difference
in how the two are represented internally in an application. In the first
case, `charset' is an attribute name, one of an open-ended set of name/value
pairs that comprises the parameter top-level value.
In the latter case, `Content-charset' is a top-level value, and as such exists
for all types including those which are meaningless. More importantly, it
creates a new entity which must be parsed at the lowest level. As a
parameter, no extra parsing is needed, since you need parameter parsing code
for other stuff.
Let me ask you something: Are you an RFC-XXXX implementor? What code are you
writing, and what is the current state? I am an RFC-XXXX implementor, and I
have finished an implementation.