[Tzdist] draft-ietf-tzdist-caldav-ref-02

Ken Murchison <murch@andrew.cmu.edu> Mon, 04 May 2015 16:14 UTC

Return-Path: <murch@andrew.cmu.edu>
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 662F71A6F11 for <tzdist@ietfa.amsl.com>; Mon, 4 May 2015 09:14:03 -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 TzVcJf_jj41g for <tzdist@ietfa.amsl.com>; Mon, 4 May 2015 09:14:02 -0700 (PDT)
Received: from smtp.andrew.cmu.edu (SMTP.ANDREW.CMU.EDU [128.2.157.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D821A88B1 for <tzdist@ietf.org>; Mon, 4 May 2015 09:13:48 -0700 (PDT)
Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id t44GDkPD011021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <tzdist@ietf.org>; Mon, 4 May 2015 12:13:47 -0400
Message-ID: <55479ABA.1050701@andrew.cmu.edu>
Date: Mon, 04 May 2015 12:13:46 -0400
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Time Zone Data Distribution Service <tzdist@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.5.4.160616
X-SMTP-Spam-Clean: 33% ( SXL_IP_DYNAMIC 3, TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_900_999 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, NO_URI_FOUND 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, __CANPHARM_UNSUB 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_FROM 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_POOLED_1 0, __SANE_MSGID 0, __SUBJ_ALPHA_START 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __USER_AGENT 0)
X-SMTP-Spam-Score: 33%
X-Scanned-By: MIMEDefang 2.74 on 128.2.157.37
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/OHrBQjvVRCswIYcPImqthhh7eXM>
Subject: [Tzdist] draft-ietf-tzdist-caldav-ref-02
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: Mon, 04 May 2015 16:14:03 -0000

All,

My only comment/concern on this document is the new text in Section 
3.1.3 regarding use of the Prefer header field for clients to require a 
'calendar-no-timezone' capable server to include VTIMEZONE components in 
the iCalendar data.  My reading of RFC 7240 (Section 2, para 1) leads me 
to believe that a server is free to ignore any/all preferences in the 
Prefer header, therefore a client would have no guaranteed way to 
opt-out of the tz-by-ref behavior.

I could be reading RFC 7240 incorrectly, or maybe we can force 
'calendar-no-timezone' capable servers to implement and obey the 
'vtimezone' preference as this document leans towards doing.  Either 
way, we may want to reach out to the HTTPbis folks to get some input.

Other alternatives OTH (perhaps not good ones) might be to use the 
Expect header field, or doing something with the Accept header field.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University