Subject: cc: Re: Charset

From: [email-masked]
Date: Sat, 08 Mar 2003 00:53:36 -0600

I would suggest:

4 iCalendar Object Specification
   The following sections define the details of a Calendaring and
   Scheduling Core Object Specification. This information is intended to
   be an integral part of the MIME content type registration. In
   addition, this information can be used independent of such content
   registration. ******** In particular, this memo has direct 
applicability for
   use as a calendaring and scheduling exchange format in file-, memory-
   or network-based transport mechanisms. ******** We wouldn't maintain 
the MIME wrapper for file-, memory, or network-based transports AND "can 
be used independent of such content" --RP

On the CHARSET issue... Doesn't this suggest the use of UTF-8 for the 
objects?
4.1 Content Lines
...
NON-US-ASCII       = %x80-F8
     ; Use restricted by charset parameter
     ; on outer MIME object (UTF-8 preferred)
... ********** Non-US-ASCII was specifically restricted to OUTER MIME 
objects only (UTF-8 preferred) -- RP

4.1.4 Character Set

   There is not a property parameter to declare the character set used
   in a property value. The default character set for an iCalendar
   object is UTF-8 as defined in [RFC 2279].

   The "charset" Content-Type parameter can be used in MIME transports
   to specify any other IANA registered character set.
********** the CHARSET can be used in MIME transports -- not iCalendar 
object -- RP

I would have to look at the rest but these are a couple of quick 
references.
Regards,
Ralph Patterson

On Friday, March 07, 2003  9:15 AM, John Stracke wrote:
>
>Date: Fri, 07 Mar 2003 10:15:42 -0500
>From: John Stracke
>To: "[email-masked]" <[email-masked]>
>Subject: Re: Charset
>
>[email-masked] wrote:
>
>>The original spec (RFC2445) required that the fidelity of the iCalendar
>>object be maintained even after all of the MIME information was stripped
>>off.
>>
>Can you cite a section, please?
>
>--
>/=================================================================\
>|John Stracke      [email-masked]                          |
>|Principal Engineer|http://www.centive.com                        |
>|Centive           |My opinions are my own.                       |
>|=================================================================|
>|"We can't duplicate the bug." "Have you tried the Xerox machine?"|
>\=================================================================/
>
>

---

From: Doug Royer <[email-masked]>
Date: Sat, 08 Mar 2003 18:25:43 -0700

I think the issues here is that none of the RFCs mandate how the
data is to be stored by the application. They talk about interoperability,
not implementation.

So it is working as specified and as you sited in your reply. We have
defined how to transport 2445 objects using e-mail and now CAP. And
the 2445 objects can be used in small devices and it will never
matter to any RFC how the small devices store the 2445 objects.
When small devices export a 2445 object they will take what ever
their internal format and charset, then send e-mail or use CAP.
If the small device uses another transport then it is ether going
to be some future proposed protocol or a proprietary protocol.
No one has proposed any other transport or protocol so I SEE
that as covering all of the issues.

>>Can you cite a section, please?

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards