Subject: Comments on draft-many-ical-xmldoc-01.txt

From: John Stracke <[email-masked]>
Date: Tue, 29 Jun 1999 21:24:10 +0000

A Draft just came across by Frank, Surendra, and Doug, called
draft-many-ical-xmldoc-01.txt; it defines an XML representation of
iCalendar.  It's pretty restrictive--so restrictive that it removes just
about every advantage of using XML.  Some examples:

   * 1: "XML applications that conform to this memo and also use
     namespaces MUST NOT include other non-iCalendar namespaces in an
     iCalendar XML document."
        o You can't take advantage of any other XML syntaxes (for
          example, by using XHTML in parameter values).
   * 2.3: "Internet applications conforming to this memo MUST only send
     the iCalendar XML document in a "multipart/alternative" MIME entity
     that also contains an equivalent iCalendar object in the standard
     format defined by [RFC2445]."
        o You have to waste bandwidth.
        o The receiver has to be able to process multipart/alternative
          (which is required by MIME, but was rejected by this group in
          the case of iMIP--see the thread "Intolerant iMIP receivers",
          March 1999).
        o If you aren't using a MIME-based protocol, you're out of luck.
        o You cannot send an XML document that expresses anything that
          can't be expressed in text/calendar.
        o A better rule would be something like, "An iMIP sender which
          does not know whether the recipient(s) can understand XML MUST
          send a multipart/alternative which includes a text/calendar
          body part before the XML body part".
             + iMIP only because that's our only binding to MIME.
             + text/calendar first because that means the XML part may
               be a more faithful representation; that way, if the
               receiver doesn't understand XML, or doesn't understand
               some part of the XML document, it knows it can fall back
               to the text/calendar.
             + Obviously, any extensions in the XML section must be
               expendable (i.e., it can't break anything if the receiver
               doesn't get them); but that's the case for any sort of
               extension.
   * 2.12 and 2.13 suggest a MIME type and filename extension that will
     prevent iCalendars in XML from being treated as XML.
   * The DTD doesn't seem to have any room for extensibility (no ANYs,
     for example), not even the x- tokens of RFC-2445.  (It mentions
     them in some comments, but I don't think it ever actually provides
     a way to make them valid.)

Some other points:

   * 2.5: to include binary content by reference, you have to define a
     NOTATION and an ENTITY for each attachment.  This is extremely
     inconvenient; it means you can't generate the XML in one
     pass--while generating the <!DOCTYPE>, you have to make a
     preliminary pass through your data structures searching for
     external attachments, and then make the second pass to generate the
     content of the document.
        o A simpler approach would be something like <attach
          src="uri"/>.
   * 2.12, editing nit: "a recipient mail user agent must
     (MUA)"--transposition.

I understand that the first attempt should be conservative; but it
should also lead to experimentation that will inform the next attempt.
This spec constrains experimentation to the point where there's no value
in using it at all.

--
/=============================================================\
|John Stracke    | My opinions are my own | S/MIME & HTML OK  |
[email-masked]|============================================|
|Chief Scientist | NT's lack of reliability is only surpassed |
|eCal Corp.      |  by its lack of scalability. -- John Kirch |
\=============================================================/

---

From: Doug Royer <[email-masked]>
Date: Wed, 30 Jun 1999 08:03:28 -0700 (PDT)

> Date: Tue, 29 Jun 1999 21:24:10 +0000
> From: John Stracke <[email-masked]>
> 

This was done for two reasons:

	1) This draft describes how to represent the proposed
	   standard iCal (RFC2445) as an XML document. It is
	   not a new iCal object and it is not a way to extend
	   the iCal object or data types or data value types.
	   
	2) It is designed to be used inside an XML object. Example:
	   
	   If you wished to have an XML document that contained
	   iCal data, then define your own XML document and include
	   this one.
	   
By allowing other names spaces inside of this definition, it will
be polluting the object and making it yet another way to describe
an calendar object. We wanted RFC2445 to be the definition. And
this to be a document that describes how to represent the standard
iCal object iCal in XML.

>         o You have to waste bandwidth.

Again, iCal is the standard, not this one. In order for there to
be interoperability in the calendar world there MUST be one
standard representation for a calendar object. And iCalendar is it.
This draft simply describes our proposal for the way to represent
that object in XML.

So by using MUST be part of multipart/alternative we are allowing
CUA's that know the iCalendar object to be able to use the MIME object.
And we are forcing the XML and text/calendar object to be equivalent.
It will not be difficult to extend the XML object without extending
the iCalendar object. We think that we need one standard calendar
object - and iCalender is it.

>           the case of iMIP--see the thread "Intolerant iMIP receivers",

I believe that this WG has agreed that an iMIP receiver MUST be able
to parse multipart/alternative and that it was an error in the past to
not have made it a MUST in iMIP.  This was mentioned on the WG mailing
list and discussed in Orlando.

>         o If you aren't using a MIME-based protocol, you're out of luck.

Same with iCalendar [xx].

>           can't be expressed in text/calendar.

Good - iCalendar is the standard, not the XML draft.
That is one reason we said that.

>           body part before the XML body part".

Impossible to know - for example - please tell me the names of the
tools that I use for receiving calendar appointments and when you list
them, mark the ones that can understand XML.

>              + iMIP only because that's our only binding to MIME.

Not sure of your point here, seem to me to conflict with your point [(xx]
above.

>                some part of the XML document, it knows it can fall back

MIME defines the precedence.

>                doesn't get them); but that's the case for any sort of

It would be easy to generate an extended XML-CAL object that could
not be represented in the standard iCalendar way. Now you broke
interoperability.

>      prevent iCalendars in XML from being treated as XML.

Why?
 It works for me, what does it break?

>      a way to make them valid.)

Described in "3.2 Adding non-standard, experimental extensions".
This section talkes about the iCalendar X- names.

>      external attachments, and then make the second pass to generate the

I'll let Frank address this one.

> This spec constrains experimentation to the point where there's no value

Experimental extensions should be in iCalendar first as it
is the proposed standard for calendar objects. An XML representation
is not the standard and we do not think it should be the standard.

I think that any object that can be represented in iCalendar,
can now be represented in XML (the purpose of the draft).

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: Doug Royer <[email-masked]>
Date: Wed, 30 Jun 1999 09:36:28 -0700 (PDT)

> Date: Wed, 30 Jun 1999 16:01:24 +0000
> Frank Dawson/CAM/Lotus wrote:
> 
> > If what you want is to mix iCalendar
> > namespace elements with elements from other namespaces, you can do this by
> > creating a third document type. If it is an iCalendar document, then it can
> > only have iCalendar based element types.
> 
> Right--and that's my basic objection to this approach.  I see no benefit to
> being able to express iCalendar in XML if you can't blur the lines between
> iCalendar elements and other XML elements.

The benefit is no new parser needs to be written for programs that
already know how to parse XML. 

> > <fd>Ah, iCalendar is a MIME content type.
> 
> >From RFC-2445:
> 
>      This memo is formatted as a registration for a MIME media type per
>      [RFC 2048]. However, the format in this memo is equally applicable
>      for use outside of a MIME message content type.
> 
> ...however, the objection is weakened because CAP sends iCalendar tagged with
> Content-Type:.  (Not sure how I missed that...)

Why?

> > <fd>Well, yes and no. You can't do anything that is not in the capabilities
> > of RFC 2445 (including extensions). The folks who worked on this draft got
> > some guiding principles from our area directors. We did not want this
> > representation to be a vehicle for creating a new, competing content type
> > for calendaring. This would be counter productive.
> 
> That makes some sense.  However, the upshot is that we have a new format that
> does nothing more than the existing one.

Not a new format. A new way to represent the same format - iCalendar.

> > <fd>Huh? Not sure what you mean here. Tell us more.</fd>
> 
> Whenever you extend a protocol, you have to deal with new implementations
> talking to old ones.  (I know you know this; I'm just trying to show my
> reasoning.) To preserve interoperability, you either put in a negotiation
> system (not always possible with a mail-based system), or design the new
> features so that an old implementation can just ignore them.  If you take the
> latter approach, the new implementation needs to make sure that it doesn't use
> the new features for anything too vital.  In this case, this means that, if I
> send a multipart/alternative with text/calendar and text/xml, then I need to
> make sure the text/calendar expresses everything vital.

We did not extend the calendar object (I don't think you said that).
If you want to extend an iCalendar object, use the experimental X-
names. The entire purpose of the CALSCH WG is to provide a standard
interpretable way to represent calendar objects. We do NOT want
vendors adding things. That breaks interoperability.

We did describe how to translate X- names into iCal XML format.
So write your object in iCalendar and translate to iCal XML for
Cue's that want it.

We in NO WAY obsolete the iCalendar object. We simply proposed
a way to represent the object in XML.

> > <fd>Huh? ANY as an occurrence type is totally ambiguous. It means "anything
> > goes".
> 
> Right.  There are places in iCalendar where this could be appropriate.  For
> example, <attach> could contain an <xml> element which could contain ANY,
> allowing an attached XML document to be specified inline without using
> base64.  Or elements that currently contain PCDATA (e.g., <summary>) could
> contain ANY, so that the text could be formatted with XHTML.

Exactly why we do not want it. It would them allow vendors to create
XML calendar objects that would not interoperate. As RFC2445 is the
standard way to represent calendar objects.

> Or, if iCalendar parameters were represented as elements rather than
> attributes, then the elements could be ANY, so that you could put formatted
> text into a parameter.

Again - not the standard way to do that.
The standard way is RFC2445.

-Doug