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

[Frank Dawson <fdawson@xxxxxxxxxxxxx>]

Lewis:

You should read the working group document -calsch-csp-00.txt. It is a usage profile for vCalendar that has full scheduling functionlity. This is also documented in the PROFILE property in -calsch-csct-00.txt. "It's in there..."

- - Frank

----------
From: 	Lewis Geer (Exchange)[SMTP:lewisg@Exchange.Microsoft.com]
Sent: 	Saturday, December 07, 1996 9:29 PM
To: 	'Roland H. Alden'; 'ietf-calendar@imc.org'
Subject: 	RE: MIME as a vCalendar element separator - bad move... 

I don't think you will find much of a difference size- or time-wise to
implement a parser based on MIME or a document structure that is made
up for just for calendaring.  I'd estimate that a decent MIME-parser
from scratch for an email app will take about 4 man-months, including
testing.  The size is concurrently as small.  There are public domain
MIME parsers available, such as that included in Mark Crispin's
c-client source code.  I further suspect that you will see MIME parsing
libraries available commercially.  

I'm not sure 26k is a reasonable estimate either.  Vcalendar, when I
last looked at it, did not include semantics for appointment requests,
acceptances, etc.  In fact, this is precisely what drove me and others
to work on our draft.  I believe these additions will increase the
parser size.

I'm interested in any responses to my reply to Keith Moore about the
necessity of using MIME.  

Lewis


> From:	owner-ietf-calendar@imc.org [SMTP:owner-ietf-calendar@imc.org]
> On Behalf Of Roland H. Alden
> 
> 
> 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...
>