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

["Roland H. Alden" <ralden@xxxxxxxxxx>]

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

Just to put this in proper perspective the core
parser for vCard and vCalendar from Versit compiles
to a 26K object code file. An entire DLL (Win95)
that contains a parse tree API and a bunch of helper
APIs is 69K. That includes overlap with stuff you'd
find in a MIME parser, like BASE64 encoder/decoder,
etc.

In the context of email clients a full MIME implementation 
is a given, but the C&S solution will not be MIME alone, the 
WG must add more stuff to MIME, and if the above measurements 
are at all indicative it won't amount to much code (the 
parser won't anyway, I know the apps will be potentially 
complex).

However, if a client was a really small PDA like
device, like a Sharp Wizard, it might credibly
be able to receive appointments and vCards via an
infrared port. In THAT scenario having to deal with
ALL of MIME just to find the appointment and vCards
might be a lot to ask. I think the SUBSET of MIME
that we are really talking about on this list would
not be a problem (it's verbose but it wouldn't greatly
inflate the code). The problem is, who's going to
define that subset or explain how it's OK if this
little device doesn't do "all" of MIME? Are we going
to have an appendix to the spec that says what's OK
and what's not? (...uh, it's based on MIME but, uh, 
you can't really do that...). At some point it's like 
saying you're going to do Unicode but only support 
the first 256 characters...



>----------
>From: 	Alec Dun[SMTP:AlecDu@Exchange.Microsoft.com]
>Sent: 	Saturday, December 07, 1996 4:59 PM
>To: 	Lewis Geer (Exchange); 'Keith Moore'
>Cc: 	'Mike Weston'; ietf-calendar@imc.org
>Subject: 	RE: MIME as a vCalendar element separator - bad move... 
>
>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
>> 
>