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

[Alec Dun <AlecDu@xxxxxxxxxxxxxxxxxxxxxx>]

You and Derik can do it togeather when you merge the drafts.

Please make sure you don't leave out any key points that were discussed
by 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:12 AM
> To: 	'Ross Finlayson'; ietf-calendar@imc.org
> Cc: 	mjh@ISI.EDU
> Subject: 	RE: Quick comments on the "sch" and "csct" drafts
> 
> 
> Ross:
> 
> I will parrot this text into the revised -calsch-csct-01.txt, if this
> is okay.
> 
> - - Frank
> 
> ----------
> From: 	Ross Finlayson[SMTP:finlayson@lvn.com]
> Sent: 	Friday, December 06, 1996 8:03 PM
> 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.)
> 
> 
> 
>