RE: CounterOffer issue

[Alec Dun <AlecDu@xxxxxxxxxxxxxxxxxxxxxx>]

Vinod,

Thanks for the compliment on the date/time section.  I know Derik 
worked very hard reading/gathering all the feedback on timezones from 
the list to put that togeather.

You bring up a good point, and that is that counter offer and tasks 
were not included in the draft.  The reasoning behind this is that it 
is very challenging to get everyone to reach concensus on a particular 
draft.  The larger the draft, the more contentious points there will be 
and the longer it will take to turn the draft into a standard.    By 
breaking the problem into smaller pieces, we can get agreement on the 
very basic stuff (sending and responding to meeting requests), and then 
we can move onto the less important issues (tasks, counter offer, etc) 
while people can start shipping products based on the very basic stuff. 
 This is good for customers since they will have a useable, 
interoperable product sooner.

I'm very interested in what the group thinks about this and I believe 
this topic is on the agenda, so we'll have a chance to talk about this 
face-to-face on Tuesday.  If people think it should be in the draft, it 
will be done.

I'm worried about you and other vendors embracing vCalendar (and I'll 
talk with you about vCard privately since that is being discussed on a 
different working group).  It seems very unlikely to me that the 
standard that emerges from this working group will be compatible with 
vCalendar.  Some issues have been already discussed on the list, for 
example, timezone issues, recurrance patterns, international calendars, 
etc. for which the proposed solutions are not compatible with vCalendar 
as it appears today.  I'd recommend (in the interest of having 
everyone's products interoperate) that you embrace the standard that 
emerges as a concensus from this group.

On the topic of code for parsing (and I think Frank & Derik also have 
this on the issues list for discussion on Tuesday).  I think it's 
better to have the content easy to parse rather than having it so 
complex that I need to get parsing code from someone.  Also having a 
lot of extra-generic parsing code means that users need more memory to 
run your products (which is a very bad thing for some customers that 
have machines with a very small amount of memory).  For example:

     DALARM:19960415T235000;PT5M;2;Your Taxes Are Due !!!

is made up of a datetime, a string, a number and a string.  This means 
I would have to write a special praser specifically for the DALARM 
property that would extract out the information I need.  Instead if it 
were as follows:

	DALARM-DATE:19960415T235000
	DALARM-REMIND:000500
	DALARM-SNOOZE:2
	DALARM-MESSAGE:Your Taxes Are Due !!!

...then you could write a generic datetime parser, a generic time 
parser, a generic number parser, and a generic string parser that would 
allow you to parse this content.  The generic parsing code would of 
course be applied to all properties in the standard which means we'd 
only need about 5-6 data types to parse.

How do other people feel about this issue?

Thanks,
Alec.
+1 (206) 936-4544.

> ----------
> From: 	owner-ietf-calendar@imc.org[SMTP:owner-ietf-calendar@imc.org] on 
> behalf of Vinod 
> Seraphin/CAM/Lotus[SMTP:Vinod_Seraphin/CAM/Lotus.LOTUS@crd.lotus.com]
> Sent: 	Thursday, December 5, 1996 2:15 PM
> To: 	Gilles Fortin
> Cc: 	ietf-calendar
> Subject: 	Re: CounterOffer issue
> 
> 
> > The usual case meeting has been addressed by the current proposal: one
> > person (OWNER) calls a meeting and the other attendees can only(?) 
> accept
> >or decline.
> 
> Looks like you have only read the Microsoft draft 
> (draft-ietf-calsch-sch-00.txt).
> The Versit drafts (draft-dawson-csp-01.txt and 
> draft-dawson-csct-01.txt) do
> discuss counter proposals, as well as delegation and also deals with 
> tasks.
> Any useful scheduling protocol must support this meeting negotiation 
> process.
> 
> Having finally read through all these, I strongly feel the Versit draft 
> has much
> more meat and would be a better starting point for a merge.  The 
> Microsoft
> draft does have some good explanations in the Date, Time and Time zone
> issues section.
> 
> People also need to keep in mind that many vendors today are 
> implementing
> support for vCalendar.  It would be a shame to make all this obsolete 
> rather
> than building upon it.  The next version of Lotus Organizer shall 
> support both
> vCard and vCalendar as exchange formats.  You can cut a vCalendar or 
> vCard
> stream of text and paste it into Organizer and have it correctly 
> inserted as an
> appointment, task or address entry (hence the importance for the 
> BEGIN/END
> delimiters).  Organizer Web Calendar also supports publishing vCalendar
> items.  For more info see...http://www.lotus.com/organizer
> 
> Versit also provided vendors common parsing code (in the form of a 
> library)
> which greatly helped vendors support this format in a relatively short
> timeframe.  I'd encourage us to provide similar tools to help everyone 
> use
> whatever standards we finally arrive at.
> 
> - Vinod Seraphin
> 
>  
>