RE: Quick comments on the "sch" and "csct" drafts

[Alec Dun <AlecDu@xxxxxxxxxxxxxxxxxxxxxx>]

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