Tuesday, May 9, 2006, 4:47:55 PM, James M Snell wrote:
> <entry> > ... > <link rel="edit" type="application/atom+xml" href="/entry/foo" /> > <link rel="edit-resource" type="text/calendar" href="/entry/foo" /> > <content type="text/calendar"> > BEGIN:VEVENT > ... > END:VEVENT > </content> > </entry> Not sure how well known this problem is, so I thought I'd mention it: There are basically two versions of the address/calendar formats: vCard 2.1 and vCalendar are the old style, vCard 3.0 and iCalendar are the new style. The new style formats are fine. The old style formats are still widely used, in both the mobile space and the desktop space, but they suffer from encoding problems. Basically they use text/directory and text/calendar as their MIME types, and support the "charset" parameter; but are incompatible with the definition of text/* described by the MIME RFCs. text/* formats should define character streams. The issue with these older formats is that they are defined as a byte-streams, not character-streams. The "charset" parameter is used to provide a default character set for the value fields, but the default can be overridden on a field-by-field basis by CHARSET parameters inside the body. This isn't how text/* formats are supposed to work. You can get away with embedding these old style formats in XML only if you know that they won't contain any illegal control-codes in the 00-1f range (which would be unlikely), and basically widen each byte into a Unicode code-point (0000-00ff) and set the element text to the resulting Unicode string; to decode, truncate the Unicode code-points to an 8-bit byte. Use the charset parameter of the atom:content/@type MIME type to interpret the bytes. It is probably easier to stick to vCard 3.0 / iCalendar... -- Dave
