Re: [Tzdist] shepherd review and issues for draft-ietf-tzdist-caldav-timezone-ref

Steve Allen <sla@ucolick.org> Thu, 11 June 2015 16:12 UTC

Return-Path: <sla@ucolick.org>
X-Original-To: tzdist@ietfa.amsl.com
Delivered-To: tzdist@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57F51B304A; Thu, 11 Jun 2015 09:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP45iwqfj9La; Thu, 11 Jun 2015 09:12:45 -0700 (PDT)
Received: from smtp.ucolick.org (hunan.ucolick.org [128.114.23.233]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741FC1B3047; Thu, 11 Jun 2015 09:12:45 -0700 (PDT)
Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id 3B3D421EE; Thu, 11 Jun 2015 09:12:44 -0700 (PDT)
Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.ucolick.org (Postfix) with ESMTP id 287B120FC; Thu, 11 Jun 2015 09:12:44 -0700 (PDT)
Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (8.14.4/8.13.8) with ESMTP id t5BGCgMV004490; Thu, 11 Jun 2015 09:12:42 -0700
Received: (from sla@localhost) by geneva.ucolick.org (8.14.4/8.14.4/Submit) id t5BGCecj004489; Thu, 11 Jun 2015 09:12:40 -0700
Date: Thu, 11 Jun 2015 09:12:40 -0700
From: Steve Allen <sla@ucolick.org>
To: Cyrus Daboo <cyrus@daboo.name>
Message-ID: <20150611161240.GB12824@ucolick.org>
References: <5576EC33.2080400@cisco.com> <54AC31AD1BECBDDA68142398@[17.45.162.247]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <54AC31AD1BECBDDA68142398@[17.45.162.247]>
User-Agent: Mutt/1.5.20 (2009-12-10)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/8Fozej_epCJUXD30Mczy2yYP8Vs>
Cc: Time Zone Data Distribution Service <tzdist@ietf.org>, draft-ietf-tzdist-service.all@ietf.org, Eliot Lear <lear@cisco.com>
Subject: Re: [Tzdist] shepherd review and issues for draft-ietf-tzdist-caldav-timezone-ref
X-BeenThere: tzdist@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <tzdist.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tzdist>, <mailto:tzdist-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tzdist/>
List-Post: <mailto:tzdist@ietf.org>
List-Help: <mailto:tzdist-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tzdist>, <mailto:tzdist-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jun 2015 16:12:47 -0000

On Thu 2015-06-11T11:33:10 -0400, Cyrus Daboo hath writ:
> >Section 3.1.3:
> >
> >>
> >>   If the
> >>   "vtimezone=no" preference is set by a client on any HTTP request that
> >>   returns iCalendar data, then the server MUST NOT return any
> >>   "VTIMEZONE" components if the time zone identifier matches one
> >>   provided by any of the advertised time zone distribution servers (see
> >>   Section 3.1.2).  However, the server MUST return the appropriate
> >>   "VTIMEZONE" component for each time zone with an identifier not
> >>   available on the advertised time zone distribution servers.
> >
> >
> >I understand the intent here.  In what circumstance would the server and
> >client both be aware of a timezone that the tzdist service is not, and
> >is that an error or simply local configuration?  My point: if this is a
> >case that won't happen, let's not clutter the text.
>
> It is possible a non-standard time zone has been sent in an iTIP
> (scheduling message) to an attendee and they have stored that on
> their CalDAV server. In that case the correct thing to do is
> maintain the original VTIMEZONE component in the data as the
> attendee is not really allowed to "coerce" it into the closest match
> standard TZID, as that could cause problems with any replies they
> send back. I do think this is a situation that will happen a fair
> bit as we wait for everyone to start using tzdist and get IANA tzids
> used everywhere.

I think this situation will happen indefinitely.  The Lick Observatory
telescope schedules have always operated in a time zone where the new
day begins at noon PST, or 20 hours behind Greenwich.  This will never
be a standard timezone, but the de facto practice is unlikely to change.

--
Steve Allen                 <sla@ucolick.org>               WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165   Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046          Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/    Hgt +250 m