[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Quick comments on the "sch" and "csct" drafts
Yep, that's what I'm suggesting.
One disagreement bites the dust!
> ----------
> From:
> owner-ietf-calendar@imc.org[SMTP:owner-ietf-calendar@imc.org] on
> behalf of Frank Dawson[SMTP:fdawson@earthlink.net]
> Sent: Monday, December 9, 1996 4:38 PM
> To: Alec Dun; 'Frank Dawson'
> Cc: 'Ross Finlayson'; ietf-calendar@imc.org; mjh@ISI.EDU
> Subject: RE: Quick comments on the "sch" and "csct" drafts
>
>
> Alec:
>
> I hope we can agree on a *whole* spec by the time we are done here.
>
> Correct me if I am mistaken, but aren't you suggesting that the DST
> rule info might appear more than one to define, say, 1996, 1997, 1998,
> 1999 DST rules? If this is the case, then you can certainly have the
> DAYLIGHT property appear multiple times in a vCalendar with DST rules
> for successive years. There is no reason why we can't allow the
> standard and DST begin date/times to be a recurrence rule either.
>
> -- Frank
>
> ----------
> From: Alec Dun[SMTP:AlecDu@Exchange.MICROSOFT.com]
> Sent: Monday, December 09, 1996 3:40 PM
> To: 'Frank Dawson'
> Cc: 'Ross Finlayson'; ietf-calendar@imc.org; mjh@ISI.EDU
> Subject: RE: Quick comments on the "sch" and "csct" drafts
>
> Your just skipping the entire point.
>
> vCalendar only allows one daylight & one standard time shift, which
> means I can effectively only have a recurring meeting that lasts a
> year.
> We discussed this a lot on the list and the general concensus was that
> multiple timezone shifts are needed so we can schedule a recurring
> meeting that lasts more than a year.
>
> Can't we just agree on this one thing? I don't understand why it is
> contentious for you? It doesn't seem like it will break vCalendar
> backward compatibility or anything... How hard is it to address this
> in
> vCalendar?
>
> If we can just agree on this uncontentious point, then we'll be one
> step
> closer to reaching concensus in the group.
>
> 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:24 AM
> > To: Alec Dun; 'fdawson@earthlink.net'
> > Cc: 'Ross Finlayson'; ietf-calendar@imc.org; mjh@ISI.EDU
> > Subject: RE: Quick comments on the "sch" and "csct" drafts
> >
> >
> > Alec:
> >
> > Your "sch" draft is conceptually similar to the "csct" draft. The
> > "csct" draft though uses the data model of the POSIX time zone
> > property...as I understand it. This was based on comments that we
> > received from a date/time guru in the US govt. The "sch" draft
> appears
> > to use a data model that is borrowed from Win95/NT's registry values
> > for time zone. Isn't the POSIX model more cross-platform?
> >
> > - - Frank
> >
> >
> > ----------
> > From: Alec Dun[SMTP:AlecDu@Exchange.Microsoft.com]
> > Sent: Saturday, December 07, 1996 1:43 PM
> > To: 'fdawson@earthlink.net'
> > Cc: mjh@ISI.EDU; ietf-calendar@imc.org; 'Ross Finlayson'
> > Subject: RE: Quick comments on the "sch" and "csct" drafts
> >
> > Frank,
> >
> > The current draft is pretty close to vCalendar on the timezone
> issue.
> > The last key deviation is that the current draft allows multiple
> > timezone shifts while vCalendar only allows for two timezone shifts
> > (one to daylight time and one from daylight time), which pretty much
> > means you can only have a recurring meeting across multiple
> timezones
> > for one year.
> >
> > I think it's a pretty trivial step to go to multiple shifts. If you
> > are ok with this then I think the fundamental timezone issues are
> > solved.
> >
> > Thanks,
> > Alec.
> >
> > > ----------
> > > From:
> > > owner-ietf-calendar@imc.org[SMTP:owner-ietf-calendar@imc.org] on
> > > behalf of Ross Finlayson[SMTP:finlayson@lvn.com]
> > > Sent: Saturday, December 7, 1996 1:03 AM
> > > To: ietf-calendar@imc.org
> > > Cc: mjh@ISI.EDU
> > > Subject: Quick comments on the "sch" and "csct" drafts
> > >
> > >
> > > Hi, it's me again :-)
> > >
> > > Because of a conflict with another working group, I won't be able
> to
> > > attend
> > > the "calsch" meeting next Tuesday. But having just caught up
> again
> > > on the
> > > latest email and I-Ds, I wanted to add some final comments.
> > >
> > > When I joined in the email discussions last month, my primary
> > concern
> > > was
> > > ensuring that event specifications would be able to accurately and
> > > unambiguously describe 'international' events, including the
> > > nontrivial
> > > issue of recurring events that span daylight savings timeshifts.
> > > (This
> > > concern was based upon our experiences with the IETF "mmusic"
> > working
> > > group's SDP specification, which we are using regularly to
> describe
> > > international multiparty events.)
> > >
> > > In a nutshell, the main requirement was that the event description
> > > contain
> > > sufficient information for a receiver anywhere in the world to be
> > > able to
> > > interpret it properly, without *requiring* additional out-of-band
> > > communication (i.e., separate from the event description) to
> figure
> > > out the
> > > event location's UTC-offset and DST rules.
> > >
> > > Having read the two I-Ds in question
> (draft-ietf-calsch-csct-00.txt
> > > and
> > > draft-ietf-calsch-sch-00.txt), I believe that they both address
> this
> > > issue
> > > adequately.
> > >
> > > I particularly liked section 3.3.1 ("Date, Time, and Time zone
> > > issues") in
> > > the "sch" draft, and would very much like to see this text - or
> > > something
> > > like it - appear in the final specification. It's always a good
> > idea
> > > for
> > > specifications to include discussion of the motivations behind the
> > > various
> > > design decisions.
> > >
> > > I did, however, notice a typo (I hope) in section 3.1.3.7 of the
> > > "csct"
> > > draft, where it says:
> > > "Where local time is specified, the inclusion of the UTC
> > > offset
> > > should also be included to avoid time zone ambiguities."
> > > ^^^^^^
> > > change to "must"
> > >
> > > In closing, it seems that we've achieved concensus on this
> > particular
> > > issue,
> > > and I look forward to a future merged draft.
> > >
> > > Ross.
> > >
> > > ps. (Note that I'm being agnostic regarding the ongoing "MIME
> > > separator
> > > versus vCalendar separator" debate - that's a completely
> orthogonal
> > > issue.)
> > >
> >
> >
>
>