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

From: "Frank Dawson/CAM/Lotus" <[email-masked]>
Date: Tue, 29 Jun 1999 23:25:19 -0400

John:
Thank you for taking the time to review this draft.

Response to your comments below in "fd" element type tags:

-- Frank

   * 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).

<fd>The primary goal is not to create a calendar namespace, but to provide
an alternative XML representation of the standard iCalendar format defined
by RFC 2445. Our overriding consideration is for interoperability. The fact
of the matter is that namespaces are a double-edged sword. They were
designed to make it easy to create a compound document consisting of
element types from multiple document type definitions. THIS IS NOT THE GOAL
OF AN ICALENDAR XML DOCUMENT. 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.</fd>

   * 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.

<fd>You can send an iCalendar XML document by itself. But it will not be a
conforming implementation. That will be cool for many applications. But, if
you use the XML document and want interoperability, the fact of the matter
is that most current implementations will only support the standard format
defined by RFC 2445. Yep, it add to the bandwidth, but for conforming
implementations this a small price for interoperability.</fd>

        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).

<fd>Wrong. It was _not_ rejected by the IETF CALSCH WG.
Multipart/alternative is included in iMIP. See RFC 2447. For applications
that support iCalendar, but not the XML document you need to provide
support for the alternative representation, as required by this spec.</fd>

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

<fd>Ah, iCalendar is a MIME content type. I think that we are assuming an
IETF Internet protocols/formats environment. This doesn't prevent folks
from borrowing this format for non-Internet protocol/format environments.
Have at it.</fd>

        o You cannot send an XML document that expresses anything that
          can't be expressed in text/calendar.

<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. The editors of this
draft agree 100% with our area directors.</fd>

        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".

<fd>This sounds good.</fd>

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

<fd>Not exactly. We also have a draft for a real-time binding. We also have
a CAP spec that utilizes iCalendar.</fd>

             + 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.

<fd>Wrong. RFC 2445 is the authoritative definition of iCalendar, not the
XML representation. We don't need two evolutionary forms of iCalendar. See
our area director's guidance to us above.</fd>

             + 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.

<fd>Huh? Not sure what you mean here. Tell us more.</fd>

   * 2.12 and 2.13 suggest a MIME type and filename extension that will
     prevent iCalendars in XML from being treated as XML.

<fd>Not at all. File extensions don't prevent me from submitting an
iCalendar XML document to a XML parser. If anything, we avoid the aliasing
of objects by a singular MIME type and file type, as you have today with
text/xml or application/xml and the .xml file type.</fd>

   * 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.)

<fd>Huh? ANY as an occurrence type is totally ambiguous. It means "anything
goes". This is totally counter to iCalendar, which has a precise definition
for its object model and the structuring of content in an "iCalendar
object". For example:

<!ELEMENT event (ANY)>

doesn't represent our ABNF for VEVENT in the least.</fd>

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.

<fd>But by placing this overhead on the originator, the recipient can parse
the document once and understand what object handlers it needs to process
the contents of the document. We think that this makes it much easier to
process iCalendar XML documents. This is also accepted practice for
specifying binary content in a XML document type definition.</fd>

        o A simpler approach would be something like <attach
          src="uri"/>.

<fd>The URI along can be so ambiguous to only be understood by the
originator. We need more discipline than this to preserve interoperability
of calendar data.</fd>

   * 2.12, editing nit: "a recipient mail user agent must
     (MUA)"--transposition.

<fd>THANKS!</fd>

---

From: John Stracke <[email-masked]>
Date: Wed, 30 Jun 1999 16:01:24 +0000

Frank Dawson/CAM/Lotus wrote:

> If what you want is to mix iCalendar
> 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.

> <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...)

> 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.

> <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.

> 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.

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.

> the contents of the document.

No, it can't, because it doesn't know what your NOTATION means.  It needs a
MIME type, not a public identifier or a URI (which is what a SYSTEM is
supposed to be [see section 4.2.2 of the XML spec]--the "Executable Module
Format" in your example doesn't work).  If you want, you could provide a MIME
type in the <attach> tag as a hint so it doesn't have to do a HEAD (or
whatever) on the URI; but you should not be creating a parallel namespace for
content types.

> originator.

But the NOTATION is not going to be understood by anybody, either.

Oh, one other editing nit: in 2.3.2, you use "isomeric" when you mean
"isomorphic"

--
/=============================================================\
|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: [email-masked] (Greg Scallan)
Date: Wed, 30 Jun 1999 09:42:33 -0700

> iCalendar elements and other XML elements.

If I have a product or service and must *aggregate* and parse content from
multiple
sources, XML is my preferred mechanism.  Stop forcing me to parse "yet
another file format".

Different representations for the same data type can be a benefit without
adding function.

Greg