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

From: "Clemm, Geoff" <[email-masked]>
Date: Wed, 3 Oct 2001 13:58:52 -0400

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.

But I don't feel strongly about this, so if there is working group consensus
that these charset/encoding info should be stripped from the examples
(or have their values be replaced by "xxxx"), I'm happy to make that change
to the DeltaV spec (assuming that consensus is reached before the
author 48 hour period has expired :-).

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]]
Sent: Wednesday, October 03, 2001 1:36 PM
To: Webdav WG
Subject: RE: Content-Type / charset in RFC2518, deltaV and ACL specs

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

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Wednesday, October 03, 2001 6:54 PM
> To: Webdav WG; [email-masked]
> Subject: 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:[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 20:05:10 +0200

I think making it "xxx" is an excellent idea.

> Sent: Wednesday, October 03, 2001 7:59 PM
> To: Webdav WG

---

From: "Jim Whitehead" <[email-masked]>
Date: Wed, 3 Oct 2001 12:13:15 -0700

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

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.

> author 48 hour period has expired :-).

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.

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.

- Jim

---

From: "Julian F. Reschke" <[email-masked]>
Date: Wed, 3 Oct 2001 21:40:53 +0200

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jim Whitehead
> Sent: Wednesday, October 03, 2001 9:13 PM

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.

> effect the examples have.  Developers sometimes code to the examples, not

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

> raised an issue during last call if these values were not in the

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

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