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

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Larry Masinter -
> LMM@acm.org
> Sent: Thursday, October 04, 2001 8:37 AM
> To: Clemm, Geoff; Webdav WG; ietf-dav-versioning@w3.org
> Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs
>
>
> I think that you should limit unnecessary changes. Quoted
> parameters are valid, and removing things in examples that
> might not work in some broken implementations doesn't
> seem like it's a "necessary change".

So, could you please clarify some more?

1) Both unquoted and quoted parameters are valid (according to HTTP 1.1)?
2) RFC3023 uses quoted parameters in it's examples, but unquoted parameters
would be OK as well?
3) Known broken implementations regarding quoted parameters are: ...

> > In general, I think it really doesn't make sense to specify
> character sets
> > in specs (unless the spec is talking about encodings, of
> course). The spec
> > contains characters after all (not an octet stream). Of course this also
> > affects XML declarations in the specs.
>
> The charset parameter is strongly recommended in
> RFC 3023.

Yes. But my point is that an encoding declaration is only meaningful for a
given octet stream -- which we don't have in an example in an RFC. If these
declarations are in, they should come with a warning that this example
assumes that the request/response body actually *is* encoded in UTF-8 (or a
subset of it), and that otherwise it must match the actual encoding.

BTW: as XML parsers may reject any encoding other than Unicode (and
subsets), I'd also propose to add wording that request/response bodies
SHOULD be encoded in one of the standard XML encodings (or refer to a
section in RFC3023 that says that).

I've seen "WebDAV" implementations that send reponse bodies in
(properly-declared) Windows encodings (it is Hotmail) :-)

Received on Thursday, 4 October 2001 04:13:07 UTC