- From: Clemm, Geoff <gclemm@rational.com>
- Date: Wed, 3 Oct 2001 12:53:32 -0400
- To: Webdav WG <w3c-dist-auth@w3c.org>, ietf-dav-versioning@w3.org
Actually, section 3.6 states that a "value" is either a "token" or a "quoted-string", so the examples in 2518 are syntactically valid. But that doesn't mean that they are acceptable to common implementations, so it's a fair question. There is time to strip off the quotes in the DeltaV spec in the final editing pass, but that is likely to be soon, so if anyone feels strongly about this, please let me know ASAP. I don't follow your rationale for why examples in specs should not contain encoding information. An example is supposed to accurately reflect what the client should send and expect to receive, and a client should send encoding information in a charset parameter in the Content-Type header. Cheers, Geoff -----Original Message----- From: Julian F. Reschke [mailto:julian.reschke@greenbytes.de] Sent: Wednesday, October 03, 2001 11:20 AM To: Webdav WG; ietf-dav-versioning@w3.org Subject: Content-Type / charset in RFC2518, deltaV and ACL specs Hi, I just noticed that in their examples, all these specs specify: Content-type: text/xml; charset="utf-8" However, as far as I understand RFC2616 (section 3.6 and section 3.7), and from experience when setting the encoding in Java servlets, it should be Content-type: text/xml; charset=utf-8 (so the value is not quoted). 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. Julian
Received on Wednesday, 3 October 2001 12:54:39 UTC