Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data

Doug Royer <douglasroyer@gmail.com> Thu, 11 December 2014 19:59 UTC

Return-Path: <douglasroyer@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 8BF551A6F6F for <tzdist@ietfa.amsl.com>; Thu, 11 Dec 2014 11:59:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 034njGf895Ob for <tzdist@ietfa.amsl.com>; Thu, 11 Dec 2014 11:59:34 -0800 (PST)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665A81A1BC8 for <tzdist@ietf.org>; Thu, 11 Dec 2014 11:59:34 -0800 (PST)
Received: by mail-pa0-f44.google.com with SMTP id et14so5688531pad.31 for <tzdist@ietf.org>; Thu, 11 Dec 2014 11:59:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=SenShoW7ZHDdjDP5Nhia/AWEeclFbb0+d2/B0LK8hsY=; b=oHUUaurD3BK+MgVE+qehWqo48pnOoxsMRpQH1yZWAyqPSzXiOHVJkOlw66fMn0achI gScFIC+XYczHOQdtid83dzrWrGJeJl8+xKowKwfjBFhHD6jvlGl6Yse7bBKMMmhkkYWa WIOSK7Gi1Q3vCfCnmVmY9iwkjhzfUP3XlGFTwTJQutjJTuYeCzkDv4m2ADl57nbUeeqL aR0QIoj/TBuRnt8ShOpzn/7tu7pyqQzA1gSxV1e2YconyfwTbzimdQTK4ffPgwPBqd5U arv3t79hzPm2oam4q1Twwb1dREuK3OLSilgdOP9yyMSlS1j/Gab1LYV/TBsQA9UIqSpt n9cQ==
X-Received: by 10.70.22.227 with SMTP id h3mr20356420pdf.160.1418327973520; Thu, 11 Dec 2014 11:59:33 -0800 (PST)
Received: from [192.168.1.4] (184-76-96-188.war.clearwire-wmx.net. [184.76.96.188]) by mx.google.com with ESMTPSA id ov2sm2049961pdb.91.2014.12.11.11.59.32 for <tzdist@ietf.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Dec 2014 11:59:32 -0800 (PST)
Message-ID: <5489F79E.4080909@gmail.com>
Date: Thu, 11 Dec 2014 12:59:26 -0700
From: Doug Royer <douglasroyer@gmail.com>
Organization: http://SoftwareAndServices.NET
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: tzdist@ietf.org
References: <059.5da79d7c9d394e20e3c22513cfe04c33@tools.ietf.org> <54877E06.5020409@lsces.co.uk> <39981BA759F3923868CCFBD3@caldav.corp.apple.com> <54888249.9080607@lsces.co.uk> <CAFpi07z8NauUZ5aBqqg9sXDsmSA+hG4HuZNDkLe7fnk=mg4wgA@mail.gmail.com> <676B23282D9F7F1DCE6A54C7@caldav.corp.apple.com> <CAFpi07x79gJLEBWmpxWv7V13CiwmeKGy7bwS1=+ukp-sKmwFxA@mail.gmail.com> <5488921B.8020900@lsces.co.uk> <5488973F.7050400@andrew.cmu.edu> <54889C39.1080103@lsces.co.uk> <D2BE5C3BFE11019ECF4BEF62@caldav.corp.apple.com> <5488A6E6.8050903@lsces.co.uk> <CADC+-gTiyJ4QHZT6m3je9M9-ifSELnSWgmgy7iXSWNS+p8pthg@mail.gmail.com> <5488C0EA.8090505@lsces.co.uk> <CADC+-gTgckSe1ca6Sai6RguQid=ReM7bH6K8+dVVFm-YfbpFbA@mail.gmail.com> <5488DA56.2090306@lsces.co.uk> <CADC+-gQN=Qb2y8M-bHnPzMcK8r=xUG-seQ7XzvZwwcWsHpHnBQ@mail.gmail.com> <54895986.6060806@lsces.co.uk> <5489CA90.1070307@gmail.com> <35BC5886C9A58F866E8A46A8@caldav.corp.apple.com> <5489D9F7.3080207@gmail.com> <D196D63077FEC1B090DF7C86@caldav.corp.apple.com>
In-Reply-To: <D196D63077FEC1B090DF7C86@caldav.corp.apple.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms020800070101070002030501"
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/NlHs8PuYgqzE5h0Zizv-syVXkZ4
Subject: Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data
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 Dec 2014 19:59:36 -0000

On 12/11/2014 11:11 AM, Cyrus Daboo wrote:
> Hi Doug,
>
> --On December 11, 2014 at 10:52:55 AM -0700 Doug Royer 
> <douglasroyer@gmail.com> wrote:
>
>> If the organizer is responsible for redistribution, then irrelevant or
>> out of event time changes do not need to be fetched or recalculated by
>> every CUA for every event every time the CUA starts. The organizer 
>> simply
>> iTIP dispatches on relevant changes only.
>
> And how does an organizer know what is relevant?

Thank you - organizers CUA, not organizer. :-)

As in:  The CUA would know that the event is not in 2016 and ignore the 
TZ change, and not redistribute it because this specific TZ change is 
irrelevant.

> The organizer has no knowledge about which time zone a particular 
> attendee might be in at the time of the meeting. If the attendee's 
> time zone changes between when they accepted the meeting and the 
> actual meeting time then that change is relevant to the attendee, but 
> the organizer has no idea that is the case and so will not know to 
> send out an update.

Fetching your own TZ data is important. Updating your CUA with what you 
think the events TZ should be or should have been, is not the same subject.

Perhaps some kind of a 'do you really want that old TZ' message could be 
used. Both ways someone needs to notice/notify the other of an error. 
Without sending the organizers TZ, how would anyone know?

>
> The point is that BOTH the organizer and attendee need to track 
> changes to time zones so they can each decide what may or may not be 
> relevant to each one of them. When they detect a change that may cause 
> a problem, then yes they can use iTIP to communicate appropriate 
> changes to the event. Just relying on the organizer to do that is not 
> sufficient.

Yes, however the attendee needs to compare their latest TZ with what the 
organizer uses for TZ, even when the organizer is wrong. As that is when 
the organizer will have the event.

How does updating your view of what you think organizers TZ should be 
help? You would then be relying on the attendees to notice the organizer 
TZ is incorrect and informing the organizer manually. If no one notices 
or manually notifies the organizer (iTIP or phone) - you still are not 
on the same time slot. It could be that no one would have a clue until 
the event starts.

Both ways there may be an error. One way you break existing compliant 
CUAs. The other way you do not.

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
DouglasRoyer@gmail.com
714-989-6135