Re: MIME as a vCalendar element separator - bad move...

[Mike Weston <mweston@xxxxxxxxxxxx>]

The best argument for MIME seems to be that it is small because everyone
will have the MIME code anyway.

But one of the goals for the calendar core object specification is to be
useful outside of the IETF transport protocols as well as inside of it. 
This can be demonstrated by the fact that some people on this list have
said that they do want to use this format outside of e-mail, and for
them requiring MIME would require more code rather than less code.

Discussions of how much extra code it takes to parse begin/end within a
larger MIME object have not yielded specific numbers, but it seems
difficult to me to argue that it is more than a couple of KB.

So using MIME exclusively saves a couple of KB for a subset of products,
and requires additional code for a different subset.  Even if there are
more products in the former category, the small difference in code size
makes this an insignificant argument.

Using begin/end, on the other hand, brings better compatibility with
current and future vCalendar products from ON Technology, Netscape, and
others.  Not using MIME to separate individual components of a calendar
data object also decouples the user's calendar product decision from the
e-mail product decision, which is clearly a good thing.

-- Mike W.

Alec Dun wrote:
> 
> I would agree about it being easier to parse (and the reason is because
> it doesn't do 1/2 as much, if it was as good as MIME, it would be just
> as much code as MIME).  One key problem is that in all proposals I've
> seen, you need BOTH MIME and vCalendar parsing code.  Wouldn't we be
> better off just having MIME?  That way implementers don't have to have
> extra code and understand extra concepts and everything.  It just
> complicates things.
> 
> The only argument I've seen so far is a vCalendar backward
> compatibility argument, but I would rather pay the compatibility price
> (since there isn't really much vCalendar out there) than bloat the code
> with all this extra parsing code.  I think customers want everyone's
> code to be fast and small so they don't have to buy so much memory for
> their machines.
> 
> Speak up now if your company likes small, efficient products.
> 
> - Alec.
> 
> > ----------
> > From:
> > owner-ietf-calendar@imc.org[SMTP:owner-ietf-calendar@imc.org] on
> > behalf of Keith Moore[SMTP:moore@cs.utk.edu]
> > Sent:         Friday, December 6, 1996 4:35 PM
> > To:   Lewis Geer (Exchange)
> > Cc:   'Mike Weston'; ietf-calendar@imc.org; moore@cs.utk.edu
> > Subject:      Re: MIME as a vCalendar element separator - bad move...
> >
> >
> > > I have yet to hear a reason why the
> > > vcalendar separators are *better* than using MIME.  What additional
> > > functionality do they give that MIME does not have?
> >
> > vCalendar framing is MUCH easier to parse than MIME.
> >
> > Keith