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

[Frank Dawson <fdawson@xxxxxxxxxxxxx>]

Alec:

Let's cool our jets. I was replying to the following comment by Lewis Geer relative to the vCalendar specification not supporting request/reply of appointments. The IETF version of the vCalendar document is the "-calsch-csct-00.txt" and "-calsch-csp-00.txt". These do support these constructs. I was just referring Lewis to these documents. 

Lewis wrote, in part:

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

Cheers.

- - Frank Dawson


----------
From: 	Alec Dun[SMTP:AlecDu@Exchange.MICROSOFT.com]
Sent: 	Monday, December 09, 1996 3:53 PM
To: 	'ietf-calendar@imc.org'; Lewis Geer (Exchange); 'Roland H. Alden'; 'Frank Dawson'
Subject: 	RE: MIME as a vCalendar element separator - bad move... 

What does your response have to do with Lewis' question?  There's
nothing in that document that is at all useful to this dicsussion.

Thanks,
Alec.

> ----------
> From:
> owner-ietf-calendar@imc.org[SMTP:owner-ietf-calendar@imc.org] on
> behalf of Frank Dawson[SMTP:fdawson@earthlink.net]
> Sent: 	Monday, December 09, 1996 8:48 AM
> To: 	'ietf-calendar@imc.org'; Lewis Geer (Exchange); 'Roland H.
> Alden'
> Subject: 	RE: MIME as a vCalendar element separator - bad move... 
> 
> 
> 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...
> > 
> 
>