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

[Alec Dun <AlecDu@xxxxxxxxxxxxxxxxxxxxxx>]

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