[Ietf-calsify] Character set restriction in section 4.3.11 Text

[Ned Freed]

> Mark Crispin wrote:

> > On Mon, 21 Aug 2006, Alexey Melnikov wrote:
> >
> >>>   If any revision is made, it should be to delete US-ASCII and make
> >>> UTF-8 mandatory.
> >>
> >> However we can't do this, as absence of the charset parameter means
> >> US-ASCII.
> >> So any iCalendar object in UTF-8 MUST have charset=utf-8.
> >
> > That's unfortunate.  I admit that I am not up to speed on this
> > specification; is there really no way to fix this problem?

> To clarify, the default charset=US-ASCII comes from MIME specs.
> I am not sure if text/calendar can change the default character set
> used. Somebody with better MIME expertise should clarify this.

This is a tricky point in MIME. The idea behind the text top-level type was in
part to support fallback display of textual material even when the specific
type isn't understood. To this end, text types are required to use the charset
parameter in a manner that's compatible with text/plain. text/plain uses the
charset parameter to specify the charset (duh) and has a default of US-ASCII.
See RFC 2046 section 4.1.2 for specifics.

In any case, RFC 2046 recommands but does not actually require that all text
types have the same default of US-ASCII. And pretty much the first other
text subtype, text/html, opted for iso-8859-1 as it's default. In retrospect
UTF-8 would have been a better choice for both text/plain and text/html, but
please remember that UTF-8 didn't even exist at the time this stuff was
defined.

So what's the right course of action? I think the right thing to do is
make the default UTF-8 but strongly recommend that the charset parameter
be present.

> > If there is some way of defining the charset as always being UTF-8,
> > then charset parameters can be removed from the specification as
> > extraneous.

> Yes, that would be nice.

Nice but not really possible. See above.

				Ned