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

[Ross Finlayson <finlayson@xxxxxxx>]

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