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.

ICS validation is clearly a trailing-edge thing, and I wouldn’t expect or recommend that it should siphon effort away from the leading-edge initiatives you mention.

That said, there’s a vast quantity of ICS in circulation, it continues to grow, and it’ll be around for many years to come.

And yet a very basic use for this stuff — RSS-like pub/sub — has largely been overlooked, and can still make a big impact in ways that matter to, really, just about everyone.

So I’m thinking a quiet rear-guard action to help people discover and use ICS pub/sub makes sense.

Folks like Ben Fortuna, Doug Day, and others are already invested in providing ICS libraries, so it’s in their interest to promote and try to support this use case.

Whatever could be done along the lines of the suite of test cases at feedvalidator.org/testcases would be a boon to ICS in its current form. And I think it could also create a model — and an expectation — for how validation could work for future incarnations of ICS.

My subjective impression is that, currently, the major focus of the calendaring and scheduling community is on several new standards intended to provide greater interoperability among calendaring and scheduling software packages. These include CalDAV, which should ultimately permit you to use your choice of desktop or mobile device client software with any vendor’s calendaring server; and CalDAV Scheduling, which should make it possible to schedule meetings across servers from multiple vendors, and even – given the appropriate permissions – servers run by different organizations. This is exciting work, and is demanding a great deal of time and attention within that community.

Because of that focus, the core iCalendar specification – and iCalendar validation – is, I believe, of less interest right now to this community.

Another part of the reason is that the first major “refresh” of iCalendar is nearly out the door. This work has also taken attention away from any validation-related efforts, although it may ultimately assist those efforts. The new, cleaned up specification, currently known as RFC 2445 bis (although it will have a new ID when ratified) is being shepherded under the aegis of an IETF working group at:

http://www.ietf.org/html.charters/calsify-charter.html

This forthcoming revision of the venerable, core iCalendar spec is intended to help rationalize iCalendar, cleaning up ambiguities in the original iCalendar spec, and includes some modest simplification efforts, as well.

Agreed. The most likely approach is to improve the validation capabilities of existing iCalendar programming frameworks and libraries, then build validation services – such as web services and web-based front ends to same – on top of these. Regarding the latter, Mark Pilgrim’s and Sam Ruby’s Feed Validator and the W3C’s HTML and CSS validators are obvious sources of inspiration for an iCalendar validator, but it will take some considerable amount of work to get to that place.

Ben Fortuna (author of iCal4j, a Java-based framework) has indicated his willingness to accept issue reports and patches to improve iCal4j’s validation capabilities, and given Doug Day’s active participation in this thread, one might infer that he’d be receptive to suggestions regarding DDay.iCal’s validation features.

Jon also points out that even with XML-based formats, there are often a great many subtle issues that can arise. That’s accurate. Nonetheless, with XML data, it’s possible to use well-established tools, such as schema validators (in XML Schema or Relax NG) and rules validation tools (e.g. Schematron). This can help make the job of identifying such issues in an XML representation of iCalendar somewhat easier.

Nevermind :)