[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
On 3/17/98 at 8:03 PM -0600, Doug Royer [N6AAW] wrote:
>How about non-MIME transports? How do you specify a non-default
>charset? How would you store that information into the calendar
>object? When CAP comes out, is it going to have to specify all
>get/put operation in MIME so that the charset information is saved?
The charset information is going to have to be out of band somewhere.
Obviously if you use MIME, then it's in the MIME charset parameter to the
Content-Type field. If the transport does not use MIME, it's going to have
some other mechanism to communicate that information if it wants to.
>Why not add a parameter (similar to LANGUAGE and used as a
>parameter in the same properties as LANGUAGE)
That would be very bad. It invites messes like conflicting character sets
in the MIME Content-Type and the internal CHARSET. It makes interpretation
of the internals dependent on the externals and (as mail has shown) creates
a big hairy mess. This was (I believe) discussed some time ago.
>If that is not acceptable, then I would see 4.1.4 would
>need to be changed to say something like this about the iCal-object:
> ...The default character set for an iCalendar object is [UTF-8].
> Would have to be:
> ...The only character set for an iCalendar object is [UTF-8].
I don't see why. It seems perfectly reasonable to allow the specification
of other charsets (and perhaps we want to change that wording so as not to
confuse "charset" with other uses of the words "character set") for the
representation of these objects.
Pete Resnick <mailto:email@example.com>
Work: (217)337-6377 or (619)651-4478 / Fax: (217)337-1980