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

> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Jim Whitehead
> Sent: Wednesday, October 03, 2001 9:13 PM
> To: Webdav WG; ietf-dav-versioning@w3.org
> Subject: 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.

Wait-a-second. Do you say that there is a *requirement* to declare the
charset if we have text/xml, and the actual encoding is UTF-8 (or a subset
of that)? That would be new to me.

> 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.

Correct.

Therefore I'd say put in an "xxx" both in the header and in the XML
declaration, and add a clear description about when and how it needs to be
set (the answer doesn't seem to be obvious after all...).

> 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.

A good point, but this shouldn't stop us from discussing it for future
specs.

> 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.

I agree that the specs should conform to RFC3023.

It seems that RFC3023 uses the quoted charset value as well. This seems to
conflict with my experience what the servlet API expects...

Received on Wednesday, 3 October 2001 15:40:40 UTC