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

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