[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Merged Draft containing feedback from all of you.
> As requested by the working group at the BOF held earlier this year,
> Darren Shakib, Derik Stenerson and I have attempted to merge Frank
> Dawson's draft and our previous draft into a single document (see URL
> below). There are still a couple of issues that we have been unable to
> resolve that have not gotten much coverage on the list; I've included
> them at the end. The draft has also been updated to reflect the
> group's discussion over the last few weeks.
>
http://www.imc.org/ietf-calendar/draft-calsch-sch-00.txt
> Also, here is the URL to the MIME-DIR draft since this draft refers to
> it:
> http://ds.internic.net/internet-drafts/draft-ietf-asid-mime-direct-02.tx
> t
>
> There are many topics in the draft where multiple solutions were
> discussed on the list. Where this is the case, Derik has tried to
> represent the best concensus of the group. This was merely done for
> the sake of completeness so we'd have a draft to work from, not to say
> "this absolutely the way it must be". If there are errors (items that
> do not properly represent the opinion of the group), then the draft
> will be iterated until it accurately reflects the opinion of the group.
>
> One new addition to the draft is an overview which discusses the
> timezone issues for recurring meetings; this will hopefully allow folks
> that are new to the recurring meeting issues to come up to speed
> quickly on the complexities/issues. Several examples have been added
> to the draft, which should make it easier to discuss the issues.
>
> To help keep the meeting running smoothly, we've drawn up a list of
> open issues that might be of use on the agenda:
>
>
> -------------------------------------------------
>
> TIMEZONE AND DAYLIGHT SAVINGS ISSUES FOR RECURRING MEETINGS
> - How important is it to allow a recurring meeting that lasts 2 years?
> 5 years? 10 years? should we bound this part of the problem?
> - What TZ should be used when scheduling a meeting. creator location?
> event location?
> - How should a change in TZ rules be handled? sender re-issues meeting
> request?
> - Is a server which is a world-wide authority on DSTs changes feasible?
>
> Also, there are multiple solutions to the problem. I propose that each
> unique working solution should get a time slot for discussion. Here is
> a very brief description of the solution (which I think has some
> limitations) that is in the draft:
> - DST shifs are explicitly specified in the meeting request by the
> creator of the meeting and are relative to the timezone of the location
> of the creator of the meeting.
>
>
> GENERAL RECURRANCE PATTERN ISSUES
> - How important are non-Gregorian calendars?
>
>
> DRAFT CONSOLIDATION ISSUES
> - begin/end vs. MIME
> - recurrance pattern format
> - recurrance pattern capabilities
> - property names
> - normalization of properties
>
>
> Thanks,
> Alec.
>
>
> ----------
> From: owner-ietf-calendar@imc.org[SMTP:owner-ietf-calendar@imc.org] on
> behalf of Alec Dun
> Sent: Tuesday, November 5, 1996 1:59 AM
> To: ietf-calendar@imc.org
> Cc: fdawson@earthlink.net
> Subject: Merging the drafts.
>
> Folks,
> Frank and I met and we tried to work out the differences in the drafts.
> At this point, I would say we're back to square one on merging our
> drafts. The right thing to do at this point is push the issues to the
> group so we can resolve them.
> The most important first milestone for the working group is to be able
> to exchange meeting requests and responses in e-mail, so I've focused
> on that in my discussion of the issues below.
> First, I've included some examples of what meeting requests and
> responses look like in both the Microsoft and Versit drafts. It helps
> to see examples when going thru the issues. Below each set I have a
> list of issues that need to be resolved.
> At the end of this message, I have included a list of generic issues
> that are not discussed in the examples.
> Lastly, I am working with Tim Howes in the ASID working group to merge
> the MIME-PROP draft into the MIME-DIR draft. This merge is going well.
> At this point, both the vCalendar and PROP-CAL drafts are built on top
> of the MIME-DIR draft.
> Hopefully we can get lots of feedback on these issues.
> Thanks,
> Alec.
> ************************************************************************
> ********************
> MEETING REQUEST
> ---------------Microsoft Draft.------------------
> Mime-Version: 1.0
> Date: Thu, 4 Nov 1996 01:30:00 -0400
> To: ietf-calendar@imc.org
> From: anik@ontime.com (Anik Ganguly)
> Subject: Meeting during Dec. IETF meeting
> Content-Type: text/calendar; charset="us-ascii"; profile="appointment"
> Profile: appointment
> Variant: OneTime
> Description:First IETF-Calendaring and Scheduling Working Group Meeting
> Summary:IETF Calendaring Working Group Meeting
> Location: San Jose, CA - Fairmont Hotel
> Start: 10 Dec 96 21:00:00 Z
> End: 10 Dec 96 22:00:00 Z
> Confidentiality:Public
> Category:Meeting
> ID:<foo@bogus.com>
> AppointmentVersion:4 Nov 96 14:00:00 Z
> --------------- Versit Draft.---------------
> Mime-Version: 1.0
> Date: Thu, 4 Nov 1996 01:30:00 -0400
> To: ietf-calendar@imc.org
> From: anik@ontime.com (Anik Ganguly)
> Subject: Meeting during Dec. IETF meeting
> Content-Type: text/calendar; profile="event/request"
> BEGIN:VCALENDAR
> DAYLIGHT:TRUE;-06:00;19960407T025959;19961027T010000;EST;EDT
> PRODID:-//RDU Software//NONSGML HandCal//EN
> TZ:-05:00
> VERSION:1.0
> BEGIN:VEVENT
> ATTENDEE;EXPECT=REQUEST:ietf-calendar@imc.org
> DESCRIPTION:First IETF-Calendaring and Scheduling Working Group
> Meeting
> CATEGORIES:MEETING
> CLASS:PUBLIC
> DCREATED:19961022T083000
> SUMMARY:IETF Calendaring Working Group Meeting
> DTSTART:19961210T210000Z
> DTEND:19961210T220000Z
> LOCATION:San Jose, CA - Fairmont Hotel
UID:guid-1.host1.com
> END:VEVENT
> END:VCALENDAR
> --------------- Issues ---------------
> 1. Grouping/nesting the properties into VCALENDAR and VEVENT parts is
> unnecessary. We can reduce complexity and not detract from the meaning
> by simply omitting all the BEGIN/END blocks completely from the above
> example.
> 2. MIME-DIR and begin/end. The begin/end blocks are non in the spirit
> of the MIME-DIR draft. The correct way to delimit content in a message
> is to use MIME. By inventing a new content delimiting scheme, folks
> are forced to write additional parsers for no reason. Instead they
> could just use their existing mime parsing code-base.
> 3. Date/time formats. If we use the existing RFC 822 date format,
> then developers only need one date/time parsing routine. If we use
> something else, they have to have two date/time parsing routines. The
> ISO 8601 draft isn't any better, just different. Both allow UTC times,
> so there is no ambiguity either way.
> 4. Attendee. We should not need to repeat the recipient list in the
> message; that's what the 822 headers are for.
> 5. Attendee: parameters before the ":". This does not follow the
> spirit of the MIME-DIR draft. The parameters before the ":" should be
> used for attributes which give some information on how to parse the
> content after the ":". Some examples are charset and encoding. In
> examples like this, this should be broken into two properties, or the
> data should be placed behind the ":":
> ATTENDEE: ietf-calendar@imc.org
> REQUESTTYPE: REQUEST
> or
> ATTENDEE: ietf-calendar@imc.org, REQUEST
> ************************************************************************
> ***********************
> RECURRING MEETING REQUEST (3rd Wednesday of every month at 10-11am)
> ---------------Microsoft Draft.---------------
> Mime-Version: 1.0
> Date: Thu, 4 Nov 1996 01:30:00 -0400
> To: ietf-calendar@imc.org
> From: anik@ontime.com (Anik Ganguly)
> Subject: Meeting during Dec. IETF meeting
> Content-Type: text/calendar; charset="us-ascii"; profile="appointment"
> Profile: appointment
> Variant: Recurring
> Description: Monthly staff meeting
> Summary: Monthly staff meeting
> Location: Conference room 12
> DaysOfMonth: 15, 16, 17, 18, 19, 20, 21
> DaysOfWeek: Wed
> MonthInterval: 1
> InstanceStartTime: 10:00
> InstanceEndTime: 11:00
> StartDate: 6 Nov 96
> ReferenceTimeZone: EST
> PatternDescription: "3rd Wednesday of every month at 10-11am"
> Confidentiality:Public
> Category:Meeting
> ID:<foo@bogus.com>
> AppointmentVersion:4 Nov 96 14:00:00 Z
> ---------------Versit Draft.---------------
> Mime-Version: 1.0
> Date: Thu, 4 Nov 1996 01:30:00 -0400
> To: ietf-calendar@imc.org
> From: anik@ontime.com (Anik Ganguly)
> Subject: Meeting during Dec. IETF meeting
> Content-Type: text/calendar; Content-Profile:event/request
> BEGIN:VCALENDAR
> DAYLIGHT:TRUE;-06:00;19960407T025959;19961027T010000;EST;EDT
> PRODID:-//RDU Software//NONSGML HandCal//EN
> TZ:-05:00
> VERSION:1.0
> BEGIN:VEVENT
> ATTENDEE;EXPECT=REQUEST:ietf-calendar@imc.org
> DESCRIPTION:First IETF-Calendaring and Scheduling Working Group
> Meeting
> CATEGORIES:MEETING
> CLASS:PUBLIC
> DCREATED:19961022T083000
> SUMMARY:IETF Calendaring Working Group Meeting
> DTSTART:19961106T140000Z
> DTEND: 19961106T150000Z
> RRULE: MP1 3+ WE #0
> LOCATION:San Jose, CA - Fairmont Hotel
> UID:guid-1.host1.com
> END:VEVENT
> END:VCALENDAR
> --------------- Issues ---------------
> 1. Daylight property. Daylight savings time is not the same date
> every year. The property described as is just doesn't work.
> Furthermore this is really only important for a recurring meeting.
> Also, the TZ does not work alone since there could be various daylight
> savings schemes in a particular time-zone. We should just stick with
> the three letter time-zones. There are problems in that some
> time-zones have duplicate names, but we should work to fix that. One
> nice thing about time-zones is that they encapsulate all the rules for
> the specific region.
> 2. Recurring format readability. The recurring format "MP1 3+ WE #0"
> is not human readable. I've been told (ok, beaten up) that readability
> is important when constructing and receiving mime messages. Nobody is
> going to figure out when this meeting is without a vCalendar spec.
> 3. Recurring format problems. There is no way to specify certain
> dates in the vCalendar recurrance format, for example election day,
> which is the first tuesday after a Monday in November every four years.
> 4. Recurring format localization problems. There are other calendar
> systems used by other countries, for example Hijri and Lunar calendar
> systems. Many cultures want to be able to schedule recurring meetings
> based on these other systems. By breaking the recurrance pattern into
> several properties, it is simple to add simply add properties to
> support these other patterns, for example:
> DaysOfLunarMonth: 15
> LunarMonthInterval: 1
> ************************************************************************
> ********************************
> APPOINTMENT RESPONSE
> ---------------Microsoft Draft.---------------
> Mime-Version: 1.0
> Date: Thu, 4 Nov 1996 01:30:00 -0400
> To: anik@ontime.com
> From: alecdu@microsoft.com
> Subject: RE: Meeting during Dec. IETF meeting
> Content-Type: text/calendar; charset="us-ascii";
> profile="appointmentresponse"
> Profile: appointmentresponse
> Variant: OneTime
> Response: Accept
> AppointmentID: <foo@bogus.com>
> AppointmentVersion:4 Nov 96 14:00:00 Z
> Start: 10 Dec 96 21:00:00 Z
> End: 10 Dec 96 22:00:00 Z
> Summary:IETF Calendaring Working Group Meeting
> ---------------Versit Draft.---------------
> Mime-Version: 1.0
> Date: Thu, 4 Nov 1996 01:30:00 -0400
> To: anik@ontime.com
> From: alecdu@microsoft.com
> Subject: Meeting during Dec. IETF meeting
> Content-Type: text/calendar; profile="event/request"
> BEGIN:VCALENDAR
DAYLIGHT:TRUE;-06:00;19960407T025959;19961027T010000;EST;EDT
> PRODID:-//RDU Software//NONSGML HandCal//EN
> TZ:-05:00
> VERSION:1.0
> BEGIN:VEVENT
> ATTENDEE;ROLE=ATTENDEE;STATUS=CONFIRMED: alecdu@microsoft.com
> DESCRIPTION:First IETF-Calendaring and Scheduling Working Group
> Meeting
> CATEGORIES:MEETING
> CLASS:PUBLIC
> DCREATED:19961022T083000
> SUMMARY:IETF Calendaring Working Group Meeting
> DTSTART:19961210T210000Z
> DTEND:19961210T220000Z
> LOCATION:San Jose, CA - Fairmont Hotel
> UID:guid-1.host1.com
> END:VEVENT
> END:VCALENDAR
> --------------- Issues ---------------
> *** I couldn't really find any examples or mention of what a meeting
> response looks like in the vCalendar spec, so I just took a wild guess
> and I'm probably wrong. Perhaps there is no spec for this in
> vCalendar. Regardless, the response needs to be a little more compact
> than I've made it out to be, and maybe it is.
> In any event, being able to respond to a meeting request is important
> functionality as a deliverable for the working-group, and the final
> merged draft needs to clearly describe how to respond to meeting
> requests to say if you are attending a meeting or not.
> ************************************************************************
> ***************************
> OTHER ISSUES
> 1. In the final draft, there need to be good clear examples of what
> meeting requests and responses should look like.
> 2. Attachments. Attachments should just be another body part in the
> message, or attach an HTML body part which contains meeting information
> and one or more relative/absolute URL.
> 3. Alarms. Alarms can be most simply expressed and easily read as a
> set of properties for which parse code exists rather than a complex
> string that you have to write new code to parse. It would be as below.
> In a recurring meeting request, I would omit the Alarm Date. For
> example, an audio alarm would look like this:
> AAlarmDate: 10 Dec 96
> AAlarmTime: 20:45:00 Z
> AAlarmAudio: http://www.ibm.com/taps.wav
> AAlarmSnoozeTime: 15
> AAlarmSnoozeRepeat: 4
> 4. String-list delimiters. Whichever string-list delimiter we choose,
> it should be consistent so we don't end up writing multiple sets of
> parse code. semicolon seems like a good choice, especially since it
> allows us to share parsing code with RFC 822 header parsing code.
> 5. Exceptions to recurring patterns. We should simply list the dates
> of exceptions. If we need a recurrance pattern for exceptions for
> recurrance patterns, then that means we've just done a crappy job of
> defining the recurrance patterns.
>
>
>
>
>