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

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 3 Oct 2001 12:53:32 -0400

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:[email-masked]]
Sent: Wednesday, October 03, 2001 11:20 AM
To: Webdav WG; [email-masked]
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

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 3 Oct 2001 19:36:27 +0200

Geoff,

maybe it's obvious for people who constantly deal with these issues, but
many people blindly copy from examples, not knowing exactly what they do...
Of course properly declaring the charset is a Good Thing (and often
necessary), but then maybe the spec should come with a warning that the
charset declarations in the examples are just that -- examples -- and must
match the *actual* encoding used for the request/response bodies.

For instance:

<?xml version="1.0" encoding="UTF-8"?>
<town>Münster</town>

may look completely innocent -- until it appears within something which
actually is encoded in a different (and incompatible) charset. I guess this
mail will be transferred in some ISO encoding, so the XML fragment wouldn't
parse when given byte-by-byte to an XML parser, right?.

The examples in the specs generally don't need anything outside the ASCII
range, so maybe it would be wiser to leave out the encoding declarations
(and have a separate paragraph in RFC2518++ explain the issue).

(sorry for cross-posting to "both" lists).

Julian

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Wednesday, October 03, 2001 6:54 PM
> Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs
>
>

---

From: "Larry Masinter - [email-masked]" <[email-masked]>
Date: Wed, 3 Oct 2001 23:37:12 -0700

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

> affects XML declarations in the specs.

The charset parameter is strongly recommended in
RFC 3023.

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 4 Oct 2001 09:53:37 +0200

> [mailto:[email-masked]]On Behalf Of Larry Masinter -
> [email-masked]
> Sent: Thursday, October 04, 2001 8:37 AM
> To: Clemm, Geoff; Webdav WG; [email-masked]

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

> The charset parameter is strongly recommended in

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) :-)

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 29 Oct 2001 18:09:03 +0100

Hi,

a related discussion is going on in xml-dev right now [1]. It seems to me it
would be wise if WebDAV and related specs would switch to use a content type
of application/xml -- at least both server and client implementors should be
advised to accept both.

Julian

[1] <http://lists.xml.org/archives/xml-dev/200110/msg01021.html>