RE: Content-Type / charset in RFC2518, deltaV and ACL specs

> I think there are good arguments on either side, but I personally
> believe that the risk of someone blindly copying the example and
> leaving out a needed charset parameter or an encoding attribute are
> higher than the risk of someone using a non-UTF-8 encoding, but leaving
> in the UTF-8 charset parameter and encoding attributes from the example.

Before we placed the charset parameter in *every* example of the
specification, I found that implementations were not including the charset
parameter at all. Since this would make it very difficult to correctly
implement i18n features later, I added the charset parameter to all
examples.  I still don't think that all implementations use the charset
parameter, or use it correctly, but I do believe it helped.

One thing I learned from the DAV specification was the large normative
effect the examples have.  Developers sometimes code to the examples, not
the specification.

> But I don't feel strongly about this, so if there is working
> group consensus
> that these charset/encoding info should be stripped from the examples
> (or have their values be replaced by "xxxx"), I'm happy to make
> that change
> to the DeltaV spec (assuming that consensus is reached before the
> author 48 hour period has expired :-).

I feel very strongly that the charset values should be left in the DeltaV
specification, with their current values. This is the form the specification
was approved as, and the form in which it passed last call. I would have
raised an issue during last call if these values were not in the
specification.

Furthermore, RFC 3023 ("XML Media Types") states that use of the charset
parameter is STRONGLY RECOMMENDED, and so if we do not use the charset
parameter, the burden of explanation clearly rests on showing why it is
better to omit it, than to include it.

- Jim

Received on Wednesday, 3 October 2001 15:16:58 UTC