Until now, that is :-):

xCal: The XML Format for iCalendar (published August 8, 2011)
https://tools.ietf.org/html/rfc6321

X-ALT-DESC;FMTTYPE=text/html:

It does not show html as plain text , render html as it is..

Thanks for posting

Yes, even the quoted-printable. Sec Sec 3.4 of RFC 2445, and page 18 of RFC 1521. 2445 allows use of Quoted-Printable in encoding data in general use throughout the iCal file. 1521 describes the Quoted-Printable format itself, including the fact that the trailing ‘=’ indicates a soft newline.

Also, none of these points are new, your other commenters mentioned this before. Apparently it got side tracked by talk about CalConnect, which even now, still hasn’t produced a mainstream XML version of iCal.

Long live 2445! :P

html description is not getting displayed.

If you want HTML use X-ALT-DESC instead of DESCRIPTION.

example:
X-ALT-DESC;FMTTYPE=text/html:***FULL HTML BODY HERE***

To prvnhs: There is a Java library for generating and parsing iCalendar data: iCal4j http://http://ical4j.sourceforge.net/ If you’re not just writing a single DESCRIPTION property but need to generate valid calendar events, that’s an excellent tool to use for that purpose. As for the CID (Content-ID), my understanding is that is essentially a way within iCalendar of referring to external, non-iCalendar data (such as vCard ‘business card’ data for a person) that may be carried along as a separate MIME body part, along with the iCalendar data, in a common transport message. There are some usage examples of a CID (for several other properties, although not for the DESCRIPTION property) in the iCalendar spec, RFC 2445, http://www.ietf.org/rfc/rfc2445.txt, as well as some examples on how to package this all up in the iMIP specification, RFC 2447, http://www.ietf.org/rfc/rfc2447.txt

here i need Description to print the text in formated way to icalender from java code.

can anybody explain what is “CID:xyz” here?
where to declare below things in java code?

Content-Type:text/html
Content-Id:xyz

Enhanced description here Body of
enhanced description.

thanks in advance
prvnhs

With regard to embedding iCal in a feed, I was mostly thinking about using the feed-level text constructs as an alternative to a Quoted-Printable “DESCRIPTION” or “ALTREP” which look like major PITAs to both produce and consume. If there’s a real need to embed rich and structured HTML representations of calendar event descriptions, it seems like an easier solution to provide this through the feed directly than embedded within iCal within the feed, through archaic escaping and attachment techniques.

Two issues:
1. There is no canonical XHTML representation of an iCalendar object. The closest thing we have is a microformat, hCalendar, which currently encompasses only a fraction of iCalendar’s data richness.
2. By embedding iCalendar (RFC 2445) data in a feed entry, a calendaring client (e.g. Outlook, Apple iCal, Google Calendar, Mozilla Sunbird) can import this data. None of these clients would know what to do with “an alternate XHTML representation.”

Asbjørn also writes:
> I think the [CalConnect XML TC] working
> group is going in a direction that looks
> like it could have been thought up
> 10 or more years ago. DOCTYPE?
> No namespaces?

One possibility is that you’re looking at the wrong draft – an old draft of “xCal,” a former proposal for an XML representation of iCalendar, dating back at least three years. That document is linked from the CalConnect XML TC’s home page, but is *not* their work.

In their current draft, the CalConnect XML TC is using Relax NG as their schema language, as mentioned in this October 2008 CalConnect Roundtable report:

http://www.calconnect.org/roundtable13rpt.shtml

I believe the XML TC’s draft schema has been released within the CalConnect organization, but I don’t know whether it is yet publicly available.

On another note, I welcome an XML-based calendar format, but I think the working group is going in a direction that looks like it could have been thought up 10 or more years ago. DOCTYPE? No namespaces? Cryptic element names, attribute names and values?

If an XML-document in and of itself isn’t even close to being self-explanatory, the design of the document have, in my humble opinion, utterly failed. What the working group should be thinking is: “How can the format we’re creating most elegantly, easilly and interoperably be embedded in another XML document, like for example, RFC 4287 (Atom)?”.

The DOCTYPE and having no namespace, for instance, are both huge show-stoppers.

Lack of a Validator is an issue, as Jon says, but I would say an even larger issue is the lack of test suites. Data format standards without test suites are going to get interop only by long drawn-out pain.

We need an iCalendar equivalent of http://tools.ietf.org/html/rfc4134

Oh come on, and there haven’t been problems with invalid XML and lousy parsers? Please.

Jon, you’re right on the money, keep up the good work.

I agree. This is why feedvalidator.org is such an interesting/important project — not just w/respect to the formats it cares about, but in general.

It demonstrates a solid approach to creating a frame of reference for the reading-between-lines and interpretation that is always necessary.

>And actually, once the XML format is done and in >use, there will continue to be a need for a >robust validator.

Parsing of data is actually a very small part of ICS validation, so the question of XML vs. folded content lines is probably not the main issue here.

The interoperability concerns of iCalendar are not so much the result of syntactic ambiguity, but rather semantic ambiguity, which I think highlights a need for “drawing a line in the sand”, even if it’s just to provide a basis for discussion and to highlight the differences in the semantic interpretation of each CUA.