IETF Logo Mail Archive

Re: [Tzdist] AD review of draft-ietf-tzdist-caldav-timezone-ref-03

Barry Leiba <barryleiba@computer.org> Fri, 28 August 2015 15:13 UTC

Return-Path: <barryleiba@gmail.com>
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 5523D1A0338; Fri, 28 Aug 2015 08:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 X8OelZOhjR2z; Fri, 28 Aug 2015 08:13:18 -0700 (PDT)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41A361A0395; Fri, 28 Aug 2015 08:13:18 -0700 (PDT)
Received: by vkbf67 with SMTP id f67so5440077vkb.0; Fri, 28 Aug 2015 08:13:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4KOjFp1eqWsHG6pR4/qfCWfFMJEaXs9WXTJ1XUtVcd8=; b=ich2iv0WLZViuM2OqHXS6UiQi3YjC3L3XWjPoWuWfhUX8nj2fZ+jJWOmdrHdHrc1oZ oyUNP/BQLM7zxSQ4CNXAlRO0/4VD1mX6kiSe8ffrQRYC3Hcdy7Dam/2EaJMbRqZhCl+S RXyXPLQWb1Y2ywTekrM+otwufYCAkNBx6nsxgh8uvCv60XInCL+0y4kvB9mb0aKXxdlA gHJM/tSaAHVbfMLaa1Dj8NwXO6TrgCjpl5FlM8WhhxM4YL7YBEb24Le9wxi0TCe71YZh 9eP4ripAaHu48a0mIYh5ZZq9YnCfT2a/38BzEkor74xdO+CYQ6/ON902KwGwjbUfpHwn CBcQ==
MIME-Version: 1.0
X-Received: by 10.52.108.233 with SMTP id hn9mr4532618vdb.27.1440774797492; Fri, 28 Aug 2015 08:13:17 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.31.88.196 with HTTP; Fri, 28 Aug 2015 08:13:17 -0700 (PDT)
In-Reply-To: <55E07137.2020704@andrew.cmu.edu>
References: <CALaySJKAephrJS=XHfMSM3C3qpH4_Monn+Ear1vhCjMtqVZ+4w@mail.gmail.com> <4733A6EDE125B3121612FE24@caldav.corp.apple.com> <CALaySJLy-yoCwGaeOvr1F+2t7ZOApvtNurN3Bfsq6eQGSDVf7Q@mail.gmail.com> <55DBFCD3.4060703@cisco.com> <7F54FB4C7591CBD0A4C19BD8@caldav.corp.apple.com> <ABF86F9F2D7866DEFC1F5CFE@caldav.corp.apple.com> <55E07137.2020704@andrew.cmu.edu>
Date: Fri, 28 Aug 2015 11:13:17 -0400
X-Google-Sender-Auth: OB5yrAQRunTNtedDP9RNL6L3ISo
Message-ID: <CALaySJ+-pcYdp+H56RnmXWpG8-Z1PFboZhvMGN0mJQSajeriGQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Ken Murchison <murch@andrew.cmu.edu>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tzdist/JeFXSMqyJUErkK5J8rEH4xNeEPw>
Cc: Cyrus Daboo <cyrus@daboo.name>, tzdist@ietf.org, draft-ietf-tzdist-caldav-timezone-ref@ietf.org, Eliot Lear <lear@cisco.com>
Subject: Re: [Tzdist] AD review of draft-ietf-tzdist-caldav-timezone-ref-03
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 28 Aug 2015 15:13:19 -0000

I'm with Ken here: mild preference for the default being as things
were, but not a strong preference.  You guys know the actual
deployment issues.

Barry

On Fri, Aug 28, 2015 at 10:33 AM, Ken Murchison <murch@andrew.cmu.edu> wrote:
> On 08/28/2015 10:29 AM, Cyrus Daboo wrote:
>>
>> Hi Eliot, Barry,
>>
>> --On August 25, 2015 at 5:18:02 PM -0400 Cyrus Daboo <cyrus@daboo.name>
>> wrote:
>>
>>> In summary, two choices for the WG (with #1 being the currently defined
>>> behavior):
>>>
>>> 1) In the absence of the new request header, by default the server does
>>> not send VTIMEZONE components, but it SHOULD provide an option to
>>> override that behavior for specific clientsE, based on User-Agent, that
>>> always require a VTIMEZON.
>>>
>>> 2) In the absence of the new request header, by default the server always
>>> sends VTIMEZONE components, but it MAY provide an option to override that
>>> behavior for specific clients, based on User-Agent, that are known to
>>> ignore VTIMEZONEs in the data.
>>
>>
>> Any comment on this before I update the spec? In the absence of any
>> preference I will leave the spec as is (i.e., choice #1).
>>
>
> I believe that choice #2 would be the norm for new behavior (opt-in), but I
> don't have a strong opinion either way since it appears that most, if not
> all, clients use their own VTIMEZONE data anyways.
>
>
> --
> Kenneth Murchison
> Principal Systems Software Engineer
> Carnegie Mellon University
>

v2.23.0 | Report a Bug | By Email