From nobody Fri Mar 1 01:10:10 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B643412E7C1 for ; Fri, 1 Mar 2019 01:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=MBOJniGH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=opSrT56F 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 ktCcV4jPMUsS for ; Fri, 1 Mar 2019 01:10:07 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1889912D4E7 for ; Fri, 1 Mar 2019 01:10:07 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 2F37022115 for ; Fri, 1 Mar 2019 04:10:06 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Fri, 01 Mar 2019 04:10:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm2; bh=my6IPeedlN/WK+rB+QryEgosq7YM 8vqNjfpXIbZWmeQ=; b=MBOJniGHuaZLnyF2Zll24GAuJYv8EnefZEnYFtojG0B7 reYCALVmrOwlFYuZNOVAHAw3qY0Fg6vcOaK2hK2m1qFoy+VdgJHf+rCMWVosc6lF 7MX8MW3QDQdMx0Cohp/wcYjTv+73KVIykmeYvTI0knE2ibJDoXgIxhRjioxcyHjy 0g87kSOMjxTDV4xjyvYk0aRBjCYaF4FOB2HGcokGJLPgh9ZiWEAfBVXgZUXrvf8Y PZ8W390okdDSIUYUkCakr41BdAzhMfqQpte0vdTefICX4yPqcSVqfJS7+qFRH8JC U77A0gi8tIY7O+nKAoFajKSXR38xhv7ZUOhUn7Jwsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=my6IPeedlN/WK+rB+ QryEgosq7YM8vqNjfpXIbZWmeQ=; b=opSrT56FSOAJo+8Cxr/9zpkiLi9Z870Rp Q4ZxquZzk0W0ocZDkn0frnABqyy0gsP32gkSMkvfDg7aQutTckq6LCNxLIL3U2GS j0aKKrWfMV7yMiZlN0LpPxvmljBG7jbvAABoWSlTEdlu5MuJaZnWrmkfftgbd7Vu 2rxiRKObklr0c5WYQTfPo0Au9HHsu3URtyptokYBLwkhji/w/6XSawhzqLkGZujA EhCnL5XbKvQedWQXQlHBA0WcdcZ6lef79a0Ku/IGMAcbXbgDK4dzv5yl77bYWC93 qlNZWH6s7/eC0BYisMm7CleoUJPszPStup5p55ejX+SxMpgBFF/dw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrvdeggddufedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A1B082058C; Fri, 1 Mar 2019 04:10:05 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 91525120 Message-Id: In-Reply-To: <297FECCD-0F2E-44D4-BD39-5FBC9D596C30@me.com> References: <6909f082-e5c2-4cc5-afb8-c1096f1ce574@beta.fastmail.com> <033621e8-bc55-84ce-c973-994b18468fc1@gmail.com> <79518eee-1c66-0c1d-0e76-fb53afdadb0a@fastmail.com> <297FECCD-0F2E-44D4-BD39-5FBC9D596C30@me.com> Date: Fri, 01 Mar 2019 04:10:05 -0500 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=854e33f6f1c146ac936c350d922ec8ea Archived-At: Subject: Re: [calsify] jscalendar, alarm and related X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 09:10:09 -0000 --854e33f6f1c146ac936c350d922ec8ea Content-Type: text/plain The next RFC update will define a SignedDuration type for alert triggers. Cheers, Robert On Thu, Feb 28, 2019, at 9:06 PM, Andrew Laurence wrote: > IIRC, negative durations are in the 8601-2 draft. > > -Andrew > >> On Feb 28, 2019, at 4:08 AM, Ken Murchison wrote: >> >> I'm in agreement with Mike and Alexander in that we should allow negative durations in jcalendar in the same fashion as iCalendar. >> >> On 2/25/19 10:19 PM, Michael Douglass wrote: >>> >>> On 2/25/19 22:14, Neil Jenkins wrote: >>>> On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote: >>>>> I don't think it needs a new syntax - it's (["+"] | "-") followed by duration. >>>> >>>> That's a new syntax by definition. And that doesn't go in to the point of existing object interpretations may not support negative durations (e.g. may use an unsigned int for the internal representation); the point is you may now have compatibility issues with existing code and whether this is sufficiently better to be worth that tradeoff. >>> What existing code? This is in reference to alarms which in icalendar are specified by negative or positive trigger values. Any reimplementation of alarm code for jscalendar will have to take account of the difference. >>> From icalendar 3.3.6 >>> dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) >>> >>> I already have a parser which handles negative durations. I already check for and disallow negative durations for events. >>> >>>> Neil. >>>> >>>> _______________________________________________ calsify mailing list >>>> calsify@ietf.org >>>> https://www.ietf.org/mailman/listinfo/calsify >>>> >>> >>> _______________________________________________ calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >>> >> -- Ken Murchison Cyrus Development Team FastMail US LLC >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --854e33f6f1c146ac936c350d922ec8ea Content-Type: text/html
The next RFC update will define a SignedDuration type for alert triggers.

Cheers,
Robert

On Thu, Feb 28, 2019, at 9:06 PM, Andrew Laurence wrote:
IIRC, negative durations are in the 8601-2 draft.

-Andrew

On Feb 28, 2019, at 4:08 AM, Ken Murchison <murch@fastmail.com> wrote:

I'm in agreement with Mike and Alexander in that we should allow negative durations in jcalendar in the same fashion as iCalendar.


On 2/25/19 10:19 PM, Michael Douglass wrote:


On 2/25/19 22:14, Neil Jenkins wrote:
On Tue, 26 Feb 2019, at 14:12, Michael Douglass wrote:
I don't think it needs a new syntax - it's (["+"] | "-") followed by duration.

That's a new syntax by definition. And that doesn't go in to the point of existing object interpretations may not support negative durations (e.g. may use an unsigned int for the internal representation); the point is you may now have compatibility issues with existing code and whether this is sufficiently better to be worth that tradeoff.

What existing code? This is in reference to alarms which in icalendar are specified by negative or positive trigger values. Any reimplementation of alarm code for jscalendar will have to take account of the difference.

From icalendar 3.3.6

       dur-value  = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
I already have a parser which handles negative durations. I already check for and disallow negative durations for events.

Neil.

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
<murch.vcf>_______________________________________________
calsify mailing list
https://www.ietf.org/mailman/listinfo/calsify
_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify


--854e33f6f1c146ac936c350d922ec8ea-- From nobody Fri Mar 1 13:18:21 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB065130FBF; Fri, 1 Mar 2019 13:10:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: calsify@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147461575.6101.1665738724628806928.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:15 -0800 Archived-At: Subject: [calsify] calext - Requested session has been scheduled for IETF 104 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:10:32 -0000 Dear Bron Gondwana, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. calext Session 1 (1:00 requested) Monday, 25 March 2019, Morning Session II 1120-1220 Room Name: Athens/Barcelona size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/calext.ics Request Information: --------------------------------------------------------- Working Group Name: Calendaring Extensions Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 6 Conflicts to Avoid: First Priority: jmap extra dispatch People who must be present: Alexey Melnikov Donald E. Eastlake 3rd Daniel Migault Bron Gondwana Resources Requested: Special Requests: We have some people would like to participate remotely from the USA, so please give us an afternoon slot. --------------------------------------------------------- From nobody Tue Mar 5 04:42:46 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD1312941A; Tue, 5 Mar 2019 04:42:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <155178975863.24587.12974674032226501117@ietfa.amsl.com> Date: Tue, 05 Mar 2019 04:42:38 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-12.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 12:42:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : JSCalendar: A JSON representation of calendar data Authors : Neil Jenkins Robert Stepanek Filename : draft-ietf-calext-jscalendar-12.txt Pages : 58 Date : 2019-03-05 Abstract: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative to the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process. In contrast to the JSON-based jCal format, it is not a direct mapping from iCalendar and expands semantics where appropriate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-jscalendar-12 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 5 04:48:39 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0E71312B0 for ; Tue, 5 Mar 2019 04:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=KmBwvdCz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aKsLOZu0 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 BhieF2LUinWq for ; Tue, 5 Mar 2019 04:48:33 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D02B7131291 for ; Tue, 5 Mar 2019 04:48:32 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C022C231BD for ; Tue, 5 Mar 2019 07:48:31 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 05 Mar 2019 07:48:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm2; bh=B/mwNhHv+Rd3kudOAc59E0iVd8RjGG0oZ2BITkl ZVGc=; b=KmBwvdCzvOAp0EKoCtBRm3vmy3kuK00EMGG4j5QU0+zmzv1LU63gQye 6UkS/m04Fvu0INzMZKP5JD288fpwirJkCEuyZKlr3/JL/iw6B2CHqUBrssSCjhqW QyRnJ2mdoZ0LQDJjcMbO4EnISqRaE1eis6YswpRVyok10MjTQCefpKKdwJowt/GO PF5I7LSBp3irkGFAlMke73wNGChUnnez1qFgt5eG3+5jqU7qBnueX1kwP8kNdQA1 2ZnD/MDL+XONHJTWE7+Arj3IlRC49sL3uDS92GlG9hdbqsutF1MJhgycG6QXg3Re COf7I1QRO5rN3ub/ssNdLMNSwmPbXzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=B/mwNhHv+Rd3kudOAc59E0iVd8RjGG0oZ2BITklZVGc=; b=aKsLOZu0 I1hGJmFOFSOZHMHpFw46bdj7o5lOsp34gH/K0IE10uyFFor0AIZALxfxrVDYmmoi KGDiCPnEFYKElBedQ0x64e4/Gs6UdrFuw7ut0OpmPDykhGd+IhhrS6wIfz2jK8YB 6ne7kn+YRrI3oxlNuDg8BawkJoZoBl+nX2f/ggB8VigIuKtEPFQ5dpnu5h5Vr5/2 zKAY1sYSBZpo+HqyhY6opnHmdJGgc7HOg+rtG6E754Gf2iKovovuIYNyBvLVHCtn 2wLRWcBg/QtLj2pEGl0WMk2rKwIHx9Tjmgew9JEG4jbAMuOAedLA+4g3p9qhw45d Va4qn/azqAoBAQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeefgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfffhffvufgtsegrtderreerre dtnecuhfhrohhmpedftfhosggvrhhtucfuthgvphgrnhgvkhdfuceorhhsthhosehfrghs thhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfrrg hrrghmpehmrghilhhfrhhomheprhhsthhosehfrghsthhmrghilhhtvggrmhdrtghomhen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6DD152032A; Tue, 5 Mar 2019 07:48:31 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 91525120 Message-Id: <923ac25c-cb72-4362-9c99-aec84a5f25c2@www.fastmail.com> Date: Tue, 05 Mar 2019 07:48:31 -0500 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=a91ff14f54114d01aa7a955ecc537cbc Archived-At: Subject: [calsify] Updated JSCalendar RFC draft version 12 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 12:48:37 -0000 --a91ff14f54114d01aa7a955ecc537cbc Content-Type: text/plain Hi All, I have just submitted version 12 of the JSCalendar RFC draft. This version includes all feedback received on this list as well as CalConnect XLIV last month in Zurich. *Main changes:* * *timeZones*: this new property allows to embed custom time zones in JSCalendar objects * *alerts*: the alerts{offset} property has been respecified to define alert trigger offsets using negative durations, as done in iCalendar. *Other changes:* * Identifiers need only be unique within the JSCalendar object, if not noted otherwise. This has always been the case, but it is now explicitly mentioned. * The replyTo and participants either must both be defined, or neither. * Added note that the iCalendar RFC 7986 URL property should be mapped to a Link object. * All-day objects MUST NOT have a time zone. * The recurrence rule "until" property may have a non-zero time value even for all-day objects. *Open items:* * None. Please let us know of any remaining feedback as soon as possible. Cheers, Robert --a91ff14f54114d01aa7a955ecc537cbc Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

I have just submitted version 12 of the J= SCalendar RFC draft. This version includes all feedback received on this= list as well as CalConnect XLIV last month in Zurich.
Main changes:
  • timeZones: this= new property allows to embed custom time zones in JSCalendar objects
  • alerts: the alerts{offset} property has been respecifie= d to define alert trigger offsets using negative durations, as done in i= Calendar.

Other changes:
  • Identifiers need only be unique within the JSCalendar object,= if not noted otherwise. This has always been the case, but it is now ex= plicitly mentioned.
  • The replyTo and participants either must= both be defined, or neither.
  • Added note that the iCalendar = RFC 7986 URL property should be mapped to a Link object.
  • All= -day objects MUST NOT have a time zone.
  • The recurrence rule = "until" property may have a non-zero time value even for all-day objects= .

Open items:
  • N= one.

Please let us know of any remainin= g feedback as soon as possible.

Cheers,
=
Robert
--a91ff14f54114d01aa7a955ecc537cbc-- From nobody Tue Mar 5 08:45:16 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C87313131D; Tue, 5 Mar 2019 08:45:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <155180430426.24619.15403082175073104430@ietfa.amsl.com> Date: Tue, 05 Mar 2019 08:45:04 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-caldav-attachments-04.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:45:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : CalDAV Managed Attachments Authors : Cyrus Daboo Arnaud Quillaud Kenneth Murchison Filename : draft-ietf-calext-caldav-attachments-04.txt Pages : 39 Date : 2019-03-05 Abstract: This specification defines an extension to the calendar access protocol (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server. This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards Track due to its noncompliance with multiple best current practices of HTTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-attachments/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-caldav-attachments-04 https://datatracker.ietf.org/doc/html/draft-ietf-calext-caldav-attachments-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-caldav-attachments-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 5 08:47:21 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E39126D00 for ; Tue, 5 Mar 2019 08:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=D9gjxx2w; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JNaJ3blo 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 s5Mcn4ECwRc1 for ; Tue, 5 Mar 2019 08:47:15 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3459E1200D8 for ; Tue, 5 Mar 2019 08:47:15 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 474CD3501 for ; Tue, 5 Mar 2019 11:47:14 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 05 Mar 2019 11:47:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm2; bh=0P/EdDR751UVT+vqH4u0a7t7Nek nRkf7y8DZNkFyKzs=; b=D9gjxx2wIu7UUDIbcarvrEFIw1av6T88OqlXAsUX0+q hdYIyW28dAMSUIJPjSD4NQ9qWBmeVkUgrB5ELiY+QLNUMFVYdSqewOiMeqLd+Mf9 P34WpzG+9QTjd4RWr6kn83K4dmJgj/opdGSgK+neUu3MZ+6p5rPKQ6z31AVSn+gE hqPdIWOOb1YRVtJ/unK+imGTGZmlJtpSYbVzbZeJEVR9Bx4U+t/BqEvr1Pw3Db4N TfNoUl7kPX0iknNTFg3ilSKCyDx/mfuyDxgyQ9h6mzs8c/mPfHdml5UVqm3l3SLa GyTrK5m4PU3q/+bcIGp9P4Vr6OoKXuhHVofTld4xKpw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0P/EdD R751UVT+vqH4u0a7t7NeknRkf7y8DZNkFyKzs=; b=JNaJ3blogQSoC4WX+VAjFj 9n/2LkJnjHkQ4HyOs81Lw1+lDa0hqa92RBH7DUkDW3RZ1Eoa1r8xKxqxGfdtb3/5 KuNcKYHuhq2GXqldg/uRchdc0MFk9E7gx9lWwNBnVk8asLvV9JV7cREgZ3wyWzic o8PghrGKOJ32LcLwj8fT4RRmHDWQTBT3IyedhE9fTDTYrJi5M3glnhe/Skq/b7IM TiXq1lmP+Miv+BnbgqOSBahQ8ZOeiljjXp4j14geU2hhvoISxkRCzdAn+WHtcnw8 Fw+x7XxQs529PXUWQvEMx63bisH5atQzzacbw5Y4+lKLRD5kmYsf09AJsfIvX3Dg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeefgdelfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhohfkffgfgggjtgesmhdtre ertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepjeegrd ejjedrkeehrddvhedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghs thhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 40C6B10335 for ; Tue, 5 Mar 2019 11:47:13 -0500 (EST) To: calsify@ietf.org References: <155180430426.24619.15403082175073104430@ietfa.amsl.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <0e318f42-6b99-cd09-dcc5-e7456dde6223@fastmail.com> Date: Tue, 5 Mar 2019 11:47:12 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <155180430426.24619.15403082175073104430@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------68F1D718DA96C2F28DA8D77A" Content-Language: en-US Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-caldav-attachments-04.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:47:19 -0000 This is a multi-part message in MIME format. --------------68F1D718DA96C2F28DA8D77A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit All, I hope this version addresses all of the WGLC and IESG comments. If not, please provided suggested textto address any outstanding issues. On 3/5/19 11:45 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Calendaring Extensions WG of the IETF. > > Title : CalDAV Managed Attachments > Authors : Cyrus Daboo > Arnaud Quillaud > Kenneth Murchison > Filename : draft-ietf-calext-caldav-attachments-04.txt > Pages : 39 > Date : 2019-03-05 > > Abstract: > This specification defines an extension to the calendar access > protocol (CalDAV) to allow attachments associated with iCalendar data > to be stored and managed on the server. > > This specification documents existing code deployed by multiple > vendors. It is published as an Informational specification rather > than Standards Track due to its noncompliance with multiple best > current practices of HTTP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-attachments/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-calext-caldav-attachments-04 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-caldav-attachments-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-caldav-attachments-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team FastMail US LLC --------------68F1D718DA96C2F28DA8D77A Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------68F1D718DA96C2F28DA8D77A-- From nobody Wed Mar 6 17:24:40 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1B81312B2 for ; Wed, 6 Mar 2019 17:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 rH09831SSGjV for ; Wed, 6 Mar 2019 17:24:36 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 8B9051312A9 for ; Wed, 6 Mar 2019 17:24:36 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id b3so12630594otp.4 for ; Wed, 06 Mar 2019 17:24:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=HGhTFZHPmR8hjx0zT2EvIS5N2hXTh5ghlyGg7IqxY/c=; b=Q9ZgyXNL8jxOSUV8kPMcBjqnArZ+//zNIMh8ghp0H44qsCtMSmiQCSx8xxDVoqvl+k oyOXKx9ffYHOGB7A/id0UpwWB9TT4+bwD1CN5vIQO6sGJRYvVCsp3ROh8Mv6S3mas3Go q0V9NzLYiwJ0T9b70ZWc9vTTFNaf/6ksEX+GMyRB/PzdR9tEg23yRJZS1hnOQMJG8o/T b5uEVyjIMnTZTfOEohe842K+7KIu9GnhS5Aah0tbMH0B1db82TATBAa0awl4rD2+xs7k PABWvExbv7H7L/1yGg+GUfz2u/BQ3P5YA1RmB9Kx9y0YOVDWCgmCzMISl9fK9oTOI697 F1WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language; bh=HGhTFZHPmR8hjx0zT2EvIS5N2hXTh5ghlyGg7IqxY/c=; b=UoQ850Mnqbp+JxRPmd5qM9N3AO/+sS4fHxjLEdua41yDiGxgfx98uFuJOlB2YEARQ9 Ex/4sQ1QMJTsWxRrBmprB+n0GLCZD4vzlmAIJKIUIHciMlqCVynARahSj2uxKM0qYXgc ZcqduTXQX3bNoo/eihm2eK4PsY/dMbAh7n9ae4Q3wJLr5BOzRBM66ZlMfjyRR2rhRki5 KrAOwDcHGpY/ER/+PEKtHx1Bnxtmk4oiTcQ8RIfOkoCDerc3Tq9qqr8J5JtnAeuZxAv+ OZMWECugV4RHXphBCP0y02QBpPuokr3uzNIBFchjN4rTLa5eTjDCTooHtXJPu7j4a2/O OPKw== X-Gm-Message-State: APjAAAV04sVrzjzGtkp+ZkzPPaYaKszpwUMYlGr2p+/QnCyCu4j1lMAD md74RpNKMigueWsQQhvhXZII7LA+kgHh X-Google-Smtp-Source: APXvYqzUF9qbkbOn9MMBBCCvNb6NlKN14FQLW/PRd5ia67nU124Pg+BDfBs9TJ46RMOv4MYL41d1qg== X-Received: by 2002:a05:6830:1193:: with SMTP id u19mr6232431otq.221.1551921875442; Wed, 06 Mar 2019 17:24:35 -0800 (PST) Received: from [192.168.1.7] (75-174-58-238.boid.qwest.net. [75.174.58.238]) by smtp.gmail.com with ESMTPSA id 39sm1352006ota.11.2019.03.06.17.24.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 17:24:34 -0800 (PST) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> Organization: http://SoftwareAndServices.US Message-ID: <6fa84bbb-8f97-44e5-74a7-2dc99e4ef0c6@gmail.com> Date: Wed, 6 Mar 2019 18:24:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary="------------6397BEFE7B7659F64DE4E4F2" Content-Language: en-US Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 01:24:39 -0000 This is a multi-part message in MIME format. --------------6397BEFE7B7659F64DE4E4F2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On 2/14/19 9:02 AM, Robert Stepanek wrote: > During CalConnect XLIV in Zurich last week,=C2=A0discussion arose if th= e=20 > JSCalendar duration property is enough to define the time span of an=20 > event, or if an end time should be allowed as well (see the latest=20 > spec here = ). This was a big debate at the time 2445 was coming out. The argument was=20 that DURATION is a finite length of time. And that DTEND is a variable=20 amount of time. My argument against DTEND was: DTSTART:2am DTEND:2am looks meaningless, except on the date when the=20 clock kicks back 1 hour in which case it is a 1 hour meeting. And for=20 recurring meetings, 6 months later it is a zero seconds long meeting. Similar with: DTSTART:2am DTEND:1:30am for a 30-minute meeting on=20 daylight saving change date. Now throw in recurrences that happen to span those two dates and time=20 zone change issues per year. DTSTART:2am DURATION:1-hour makes sense to a person reading it. Many argued that the ~odd~ DTSTART/DTEND may be desirable. I doubt=20 anyone ever used it on purpose. So they are not always equal. I argued for only one to exist, obviously=20 I was in the minority. I have always been in favor of deprecating DTEND. However - iCalendar is the spec, and other representations of it, must=20 adhere to whatever the latest spec says, or the result will be the IETF=20 has 2 or more 'iCalendar' specifications. --=20 -- Doug Royer (http://DougRoyer.US http://SoftwareAndServices.US) --------------6397BEFE7B7659F64DE4E4F2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 2/14/19 9:02 AM, Robert Stepanek wrote:
During CalConnect XLIV in Zurich last week, discussion arose if the JSCalendar duration property is enough to define the time span of an event, or if an end time should be allowed as well (see the latest spec here).

This was a big debate at the time 2445 was coming out. The argument was that DURATION is a finite length of time. And that DTEND is a variable amount of time.

My argument against DTEND was:

DTSTART:2am DTEND:2am looks meaningless, except on the date when the clock kicks back 1 hour in which case it is a 1 hour meeting.  And for recurring meetings, 6 months later it is a zero seconds long meeting.

Similar with: DTSTART:2am DTEND:1:30am for a 30-minute meeting on daylight saving change date.

Now throw in recurrences that happen to span those two dates and time zone change issues per year.

DTSTART:2am DURATION:1-hour makes sense to a person reading it.

Many argued that the ~odd~ DTSTART/DTEND may be desirable. I doubt anyone ever used it on purpose.

So they are not always equal. I argued for only one to exist, obviously I was in the minority.

I have always been in favor of deprecating DTEND.

However - iCalendar is the spec, and other representations of it, must adhere to whatever the latest spec says, or the result will be the IETF has 2 or more 'iCalendar' specifications.

-- 

--
Doug Royer (http://DougRoyer.US http://SoftwareAndServices.US)
--------------6397BEFE7B7659F64DE4E4F2-- From nobody Thu Mar 7 00:09:10 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3477130ED0 for ; Thu, 7 Mar 2019 00:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=G7eZbs7L; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Pv+l8UQs 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 OHYQmDCMjZfe for ; Thu, 7 Mar 2019 00:09:06 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7CE130EDA for ; Thu, 7 Mar 2019 00:09:06 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 76A1C3530 for ; Thu, 7 Mar 2019 03:09:05 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 07 Mar 2019 03:09:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm2; bh=0Y/EtfanKo8UrT9Z5HVcQcfoxGHv rM/B2qgMgDDgiz0=; b=G7eZbs7LkMBkYMhrwTj5nyGTcaTZe3kHE/CXwI3zYCl6 HdBtTmhZshI8sHFBG/KvX06v8mY2q3JsEnMFV0ZkSX8Oodu7W36DJXo8IZg/5ceT u5rdIzKPI56zvpZhXM7MeCrOyF5falj+myNb6zQv056PGyaafa1JSSSRIINKP4dl COlsBqkIYAr28dtP37BKqu5C6XoUfa0YO6spRjmgrWWQyq9aRhqBPwQ1WOtG6FyA w8U2dt4L88w0SuiwLbykzhacH6l/HRXMXPTa+njn+vNaTLUT0hZtwQE62GlbQim2 wDuMSMOW75BEpeVqIEpd4B+zBsC/697mU62Rs0lHsg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0Y/EtfanKo8UrT9Z5 HVcQcfoxGHvrM/B2qgMgDDgiz0=; b=Pv+l8UQseyea0m6EubRpVqanc4PjhMfCt EWZA7tF8L4rHGsJD8n5JVIcsyLhNtpBdtNmoci9eiZM7u4gb7cLION9JbcxUm6wE IFARzlFwY+irFcwLdf1+ArrqZJCy1X4AqXKcodhRkaKXC31gnmqhxnaqm/R8nvQy EE8teRPLbJShIIujpU7k+Vk4FfhGgvwrY4+EcSIwyie907jOgOQmXPTIKY4dY4Pl 4q9oxtBIX5+0AlUsqJQMnOIm5EHZaH8MF36RA5emWkQRRDw5vt6YY3StbS9B2Xjn 70d/kVyDVfMMeTRWPYlWvdaG040A2tBz/hC+QKw2LNoR8ftOnAqBw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrfeejgdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdftohgsvghrthcuufhtvghprghnvghkfdcuoehrshhtohes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgne curfgrrhgrmhepmhgrihhlfhhrohhmpehrshhtohesfhgrshhtmhgrihhlthgvrghmrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6289E20430; Thu, 7 Mar 2019 03:09:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 91525120 Message-Id: <5fb5e30d-f499-4825-8e91-ccedc00e0dac@www.fastmail.com> In-Reply-To: <6fa84bbb-8f97-44e5-74a7-2dc99e4ef0c6@gmail.com> References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <6fa84bbb-8f97-44e5-74a7-2dc99e4ef0c6@gmail.com> Date: Thu, 07 Mar 2019 03:09:04 -0500 From: "Robert Stepanek" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=fa9419a689714d23ad5f9e0283be0c00 Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 08:09:09 -0000 --fa9419a689714d23ad5f9e0283be0c00 Content-Type: text/plain On Thu, Mar 7, 2019, at 2:25 AM, Doug Royer wrote: > On 2/14/19 9:02 AM, Robert Stepanek wrote: >> During CalConnect XLIV in Zurich last week, discussion arose if the JSCalendar duration property is enough to define the time span of an event, or if an end time should be allowed as well (see the latest spec here ). > This was a big debate at the time 2445 was coming out. The argument was that DURATION is a finite length of time. And that DTEND is a variable amount of time. > [...] Thanks for the insight, Doug. Much appreciated to understand the history of this. > However - iCalendar is the spec, and other representations of it, must adhere to whatever the latest spec says, or the result will be the IETF has 2 or more 'iCalendar' specifications JSCalendar isn't another representation of iCalendar. While the two data models have much in common, we do not aim at 100% compatibility. The spec explicitly aims to avoid ambiguities and pitfalls of iCalendar. Cheers, Robert --fa9419a689714d23ad5f9e0283be0c00 Content-Type: text/html
On Thu, Mar 7, 2019, at 2:25 AM, Doug Royer wrote:
On 2/14/19 9:02 AM, Robert Stepanek wrote:
During CalConnect XLIV in Zurich last week, discussion arose if the JSCalendar duration property is enough to define the time span of an event, or if an end time should be allowed as well (see the latest spec here).

This was a big debate at the time 2445 was coming out. The argument was that DURATION is a finite length of time. And that DTEND is a variable amount of time.

[...]


Thanks for the insight, Doug. Much appreciated to understand the history of this.

However - iCalendar is the spec, and other representations of it, must adhere to whatever the latest spec says, or the result will be the IETF has 2 or more 'iCalendar' specifications


JSCalendar isn't another representation of iCalendar. While the two data models have much in common, we do not aim at 100% compatibility. The spec explicitly aims to avoid ambiguities and pitfalls of iCalendar.

Cheers,
Robert
--fa9419a689714d23ad5f9e0283be0c00-- From nobody Fri Mar 8 04:07:56 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6292127968 for ; Fri, 8 Mar 2019 04:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=FzUx16LO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tr42Sl5n 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 dbp0tpN5Holo for ; Fri, 8 Mar 2019 04:07:52 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D613126E5C for ; Fri, 8 Mar 2019 04:07:52 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 7908E21D45 for ; Fri, 8 Mar 2019 07:07:51 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Fri, 08 Mar 2019 07:07:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm2; bh=SiaVIo0QWUCm+hkwtZVXoJQ5e+1z0eN92GcNtkk gkTM=; b=FzUx16LOOyr4PpZO9Rud6/fjPXgv/85MRPY8wv9FhY6Jl00G4naqMca dwuV2/poiOjtb3zae+Un+Sq7H5//TYbSKJ1b6MCaamylwelji4N7mx1CULQGF+92 8ygBEG4s/lnnG6q/sPy+kg7FKQDx53miwwJ5xArd5zhZQkoBoGK2T3Su+MIpx6qR C0jfsVZICskxLARKbLhmqU1bCuOq1lNTOmab5u8lriCRjxPTaVOI8wwBwkn+Kqo7 LT4HubjfMNqcDRZ8ofEjAy+RIShbXmrRyO3Lv1pBPwTbT3cpxMX9LcFxjUBHY0cD frQ/Hjcz4sDqfAKgmTHr6HVWf4mEb/A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=SiaVIo0QWUCm+hkwtZVXoJQ5e+1z0eN92GcNtkkgkTM=; b=tr42Sl5n QxQara+KRQnWHbGo1zu1Zat2gHnwHjrSyRBht+2bOwT6ISWrRMOTWubqQQ7JfWIB 9UsBMPEYSjgW91bFC7pJ18IWk0utpi7TjovBRjFA/N8XBbL7oI0Sdu6WYNTnlPnA imKK3PNQ/pPQjlHlfWOtoFORwcPfyO8MaEKAsO4wfm4Ryd9UnhgAS9Yr8FZ3XLPV vBnAatM7hVIY+DoVSVPFzS0TQjkB16ZwT59QH6lcsuUZNQ5NExGxDUe93j4DAKr5 it0M3iV8tNvPAwFM+LnXixUP/n/LRuTesFmrDv5bogexygMM6xQSp/51KHrByd3P 1DgmzXfW3rbZPA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrgedtgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfffhffvufgtsegrtderreerre dtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshht mhgrihhlthgvrghmrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomhen ucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D250E20431; Fri, 8 Mar 2019 07:07:50 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 56629417 Message-Id: Date: Fri, 08 Mar 2019 07:07:50 -0500 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=c2362e88b3714f9b876a22a459e86298 Archived-At: Subject: [calsify] Request for adoption: draft-gondwana-caldav-scheduling-controls X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 12:07:54 -0000 --c2362e88b3714f9b876a22a459e86298 Content-Type: text/plain It's a bit cheeky asking this as a recent chair myself, but I had started work on this document as a purely FastMail suggestion, and during discussion at CalConnect last month in Zurich it came up that Google had done much the same thing themselves to handle bulk import, so I ran the idea past Lucia and put this draft together. There's still some work to do, and I'm happy to hand over authorship to somebody else if anyone wants it, or to continue working on it myself. I've renamed things to be a bit more consistent than our implementation at FastMail, but of course we'd update to match the standard once the spec is done. https://datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/ (still plenty of work to do on it, but the bones are there) I believe this is within the scope of this group's existing charter and would like to see it adopted. Regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --c2362e88b3714f9b876a22a459e86298 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
It's a bit cheeky asking this as a recent chair myself, bu= t I had started work on this document as a purely FastMail suggestion, a= nd during discussion at CalConnect last month in Zurich it came up that = Google had done much the same thing themselves to handle bulk import, so= I ran the idea past Lucia and put this draft together.

T= here's still some work to do, and I'm happy to hand over authorship to s= omebody else if anyone wants it, or to continue working on it myself.&nb= sp; I've renamed things to be a bit more consistent than our implementat= ion at FastMail, but of course we'd update to match the standard once th= e spec is done.

https://datatracker.ietf.= org/doc/draft-gondwana-caldav-scheduling-controls/

(s= till plenty of work to do on it, but the bones are there)

I believe this is within the scope of this group's existing charter and= would like to see it adopted.

Regards,

Bron.

--
=
  Bron Gondwana, CEO, FastMail Pty L= td
  brong@fastmailteam.com


--c2362e88b3714f9b876a22a459e86298-- From nobody Fri Mar 8 04:19:51 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8EFA127968 for ; Fri, 8 Mar 2019 04:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=WAcfRJ9c; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FcN9xhuL 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 CNPcRjUT6HRq for ; Fri, 8 Mar 2019 04:19:48 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0341279A9 for ; Fri, 8 Mar 2019 04:19:48 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 86AC321D39 for ; Fri, 8 Mar 2019 07:19:47 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Fri, 08 Mar 2019 07:19:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:date:from:to:subject :content-type; s=fm2; bh=q5Up1437e/reiwPRcOYdA8aZ+P9aIgLu4YTfNG5 yKs0=; b=WAcfRJ9chGINNX6A/QTlgkMG9Gudv3u4wKMCww8DENR9D/9esR2jVMg /rW33wBuNXUqJh0BsWuLaMt/4eMZYv7mt2NKCjxdkcAZZlI1sypS64qJuCI81wcw oBKDK/rR2v083Ybmq+ICRhicAmL16d8ZQV+c/ZQoss/Y6gXsa6EllqPMci2alIFO BPjYjYUeO7MbzyP9dvJAHiNrnGZ81BuWpKB2IxsCVDVCxiqMZQuGEZAuu8Oe49kB dpJJTdtc0DCOCV2sg2UOr8/vD0LZGjlsbAXcIpC6bvg7EmtsSdpvawqi6/PJApsP BJgLMp9C3PYMWKuDA0/ff+vR9DwsNyg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id:subject :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=q5Up1437e/reiwPRcOYdA8aZ+P9aIgLu4YTfNG5yKs0=; b=FcN9xhuL 8bqrMp/lFY3rlzGdxhrjBjgYkzJOF8z5RwyGh2E4V2wdIdJgcbClYGHIyNy2SDlP m7IEe8Cp5e5GKT7PJXLQHiuoDNhq3Zx82XFUgh2lYpDP9aZ9HUKzYh/GKaOOhp+X mt34jjPwZwNdQeV786y9fEjMW0JhhHcir7ANpBq+evov/v8JgF3knvgFA5K+mrzm 3HgF/drGoVjbSQz99Y3O4UUwnd6N4e4kiPT4JA6VDHIaXKxH0yTCGMkU/GK3UXo/ gs2WktgFaoRPaUHr1zTjEKhqWU2ytotyj0rq/27HQvOJpGy0mC5czzSfVnrFEgtI lz3LBsuxnFYH3w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrgedtgdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfkfffhffvufgtsegrtderreerre dtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshht mhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhngh esfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0742E20431; Fri, 8 Mar 2019 07:19:47 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 56629417 Message-Id: Date: Fri, 08 Mar 2019 07:19:46 -0500 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=47c13fc9e8174d91841723f3b987f72f Archived-At: Subject: [calsify] Proposed charter update X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 12:19:50 -0000 --47c13fc9e8174d91841723f3b987f72f Content-Type: text/plain Hi all, As your newest chair, I've been reviewing the existing charter and noticed that it's rather outdated - we've delivered most of the work mentioned in there already, and we are working on things which don't strictly fit within the charter. This is an early draft for a replacement charter. I'd love feedback on it, and discussing a new charter is something I intend to have on the agenda for Prague. I welcome feedback on the below! Thanks, Bron. --- The Calendaring Extensions working group is chartered to develop extensions to the iCalendar (RFC 5545), iTIP (RFC 5546), and CalDAV (RFC 4791) standards. This working group will do the following: - Define a new JSON-based format for calendaring and a mapping from icalendar to the new format. - Define a new set of iCalendar properties to improve management of alarms and default notifications on calendar events. - Define a standard way for CalDAV clients to control the creation and delivery of scheduling messages by a server, when cleaning up after abuse, migrating events, or restoring from backups. - Define a set of new iCalendar properties and parameters to standardise some existing experimental X- properties in common use, based on a survey of existing implementations. - Define an extension to iCalendar to support consensus scheduling, where members of an event or task vote on alternatives. - Maintain the existing standards for calendaring by vetting errata, and where necessary writing specifications to clarify, update or replace the existing documents. The working group will work under the following parameters: - The extensions developed are expected to be backwards-compatible with the existing calendar standards. Incompatibilities must be identified, minimized, and justified. - For each set of extensions, examine their impact on the iTIP protocol (RFC 5546), and define any necessary extensions to iTIP to accommodate such impact. - For each set of extensions, examine their impact on the CalDAV protocol (RFC 4791), and define any necessary extensions to CalDAV to accommodate such impact. Interface with the httpbis working group to ensure that any CalDAV changes are consistent with good http practices. - Where any implementations already exist and have been shipping for some time, either document existing behaviour as well as the preferred standard, or just document the existing behaviour as an informational RFC. The following are out of scope for the working group: - Any change that impacts backwards compatibility with existing deployed iCalendar/iTIP/CalDAV clients and servers will be discussed by the working group with a view to minimizing disruption to deployed implementations without compromising desirable new function. - Any attempt to develop non-Gregorian calendar systems/calculations. --- -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --47c13fc9e8174d91841723f3b987f72f Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,

As your newest chair, I've been rev= iewing the existing charter and noticed that it's rather outdated - we'v= e delivered most of the work mentioned in there already, and we are work= ing on things which don't strictly fit within the charter.

This is an early draft for a replacement charter.  I'd love feedb= ack on it, and discussing a new charter is something I intend to have on= the agenda for Prague.

<= /div>
I welcome feedback on the below!<= br>

Thanks,

Bron.

---

The Cal= endaring Extensions working group is chartered to develop
extensions to the iCalendar (RFC 5545= ), iTIP (RFC 5546), and
CalDA= V (RFC 4791) standards.

<= /div>
This working group will do the fo= llowing:

- Define a new JSON-based format for calendaring= and a mapping from icalendar to the new format.

- Define= a new set of iCalendar properties to improve management of alarms and d= efault notifications on calendar events.

- Define a stand= ard way for CalDAV clients to control the creation and delivery of sched= uling messages by a server, when cleaning up after abuse, migrating even= ts, or restoring from backups.

- Define a set of new iCal= endar properties and parameters to standardise some existing experimenta= l X- properties in common use, based on a survey of existing implementat= ions.

- Define an extension to iCalendar to support conse= nsus scheduling, where members of an event or task vote on alternatives.=

- Maintain the existing standards for calendaring by vet= ting errata, and where necessary writing specifications to clarify, upda= te or replace the existing documents.

The working group w= ill work under the following parameters:

- The extensions= developed are expected to be backwards-compatible with the existing cal= endar standards.  Incompatibilities must be identified, minimized, = and justified.

- For each set of extensions, examine thei= r impact on the iTIP protocol (RFC 5546), and define any necessary exten= sions to iTIP to accommodate such impact.

- For each set = of extensions, examine their impact on the CalDAV protocol (RFC 4791), a= nd define any necessary extensions to CalDAV to accommodate such impact.=   Interface with the httpbis working group to ensure that any CalDA= V changes are consistent with good http practices.

- Where= any implementations already exist and have been shipping for some time,= either document existing behaviour as well as the preferred standard, o= r just document the existing behaviour as an informational RFC.

The following are out of scope for the working group:

- Any change that impacts backwards compatibility with existing depl= oyed iCalendar/iTIP/CalDAV clients and servers will be discussed by the = working group with a view to minimizing disruption to deployed implement= ations without compromising desirable new function.

- Any a= ttempt to develop non-Gregorian calendar systems/calculations.
=

---

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--47c13fc9e8174d91841723f3b987f72f-- From nobody Fri Mar 8 11:00:20 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE184130F2B for ; Fri, 8 Mar 2019 11:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 E6YD0WXTYL5p for ; Fri, 8 Mar 2019 11:00:11 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61BA130F25 for ; Fri, 8 Mar 2019 11:00:10 -0800 (PST) Authentication-Results: mail.aegee.org/x28J02rc011734; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1552071603; i=dkim+MSA-tls@aegee.org; r=y; bh=JZFdsi7AsecAWleQOwqMXT07lcOVR8fyH8xlolmOa/U=; h=Subject:From:To:Date:In-Reply-To:References; b=r1Ve6el3IPS52+mmqXcrlkQveCmxqHefPjT+AuEoygFUtXTusWslA56o00cUrNYTK JyaqDseaKrgquYC1UToIC4ZN4YaGn5lsgnsKW1J/uKqI/51YEbYT6zTuBfdcHPAzVo OYGsy3SVUZ3sSql4X813Y+YoxtN9M/y31dWXvkyoRrHXWw+4TT0A05V2w89xc9dJCd BjbVXU/2AiF6zYSrwKc1j1mYJh/dss5NW8naBhKnE9x6T7fyPJzzMjbGeQw3ivBLHO Jny86cYHCTPcQuArNWt5PTtwhrjC7NeC9yp7E+cTIm+R6/e5Z4M5o51jjQU8RuSyLp XEv4ehoC+++DhAMt5NMfD/N7oxjl0PRXXreU+t8vpAuGZvDmuTXme/M4SIBhoogtCW fwLS2jgV2aJ1E3F+czd+7QQ0aGPe/eZBZRlz7kRzYl4H6sRLixMneN7Zs4ZE84sXpi UGxoYwpw9QFvzCJHzMzgWgtwlY/oCugOQo+Wfj8g1AZYk0h5LrpPlCBQIyICdWEwPM wxgW4KgBkivtZI9K6KYuf4Z3e/Cd2lFVfABa5GFeMGmErsHaNwEkQg4nfpM65JqA6z alm0O4MaFn2T5wYBGKOyGVPTv2jE27w75PW0r9Qo9w4KvFN9CrDFTYW5UUAT6P/G2g xXlv31MHs4v7t/izewybjx8w= Authentication-Results: mail.aegee.org/x28J02rc011734; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x28J02rc011734 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 Mar 2019 19:00:02 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Bron Gondwana , calsify Date: Fri, 08 Mar 2019 19:00:01 +0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.92 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [calsify] draft-gondwana-caldav-scheduling-controls X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 19:00:15 -0000 Hello Bron, irrespective of the WG-addoptation, CALDAV:calendar-user-address-set (https://tools.ietf.org/html/rfc6638#section-2.4.1) defines per principal all the aliases a user has, so the server does not have to guess anything. When the Schedule-User-Address header is skipped, your draft says, that the CALDAV:schedule-user-address property on a calendar or user/principal shall be used. The draft references only RFC6638 “Scheduling Extensions to CalDAV” and the latter does not say anything about CALDAV:schedule-user-address. Where is CALDAV:schedule-user-address defined? Are CALDAV:schedule-user-address and CALDAV:calendar-user-address-set supposed to mean the same? In any case, it would be good to be able to specify several addresses in the Schedule-User-Address header: an invitation having Organizer and Attendee, where the same person is both the organizer and the attendee, but uses different addresses for both, is supposed not to trigger any scheduling to the same person. This assumes that the system can match the addresses as Attendee and Organizer belonging to the same person and both addresses could arrive as headers. Section 7: The "Scheduling" header only allows reduction of the cases in which the server will ??? creating scheduling requests. Regards Дилян What is the difference between Scheduling: NO and On Fri, 2019-03-08 at 07:07 -0500, Bron Gondwana wrote: > It's a bit cheeky asking this as a recent chair myself, but I had started work on this document as a purely FastMail suggestion, and during discussion at CalConnect last month in Zurich it came up that Google had done much the same thing themselves to handle bulk import, so I ran the idea past Lucia and put this draft together. > > There's still some work to do, and I'm happy to hand over authorship to somebody else if anyone wants it, or to continue working on it myself. I've renamed things to be a bit more consistent than our implementation at FastMail, but of course we'd update to match the standard once the spec is done. > > https://datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/ > > (still plenty of work to do on it, but the bones are there) > > I believe this is within the scope of this group's existing charter and would like to see it adopted. > > Regards, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Fri Mar 8 11:38:02 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0C612799B for ; Fri, 8 Mar 2019 11:37:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 3_SaMb5WUTM9 for ; Fri, 8 Mar 2019 11:37:58 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C98C8127978 for ; Fri, 8 Mar 2019 11:37:57 -0800 (PST) Authentication-Results: mail.aegee.org/x28JboLj018846; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1552073871; i=dkim+MSA-tls@aegee.org; r=y; bh=m3U4YkfTuqiK8cF/Nu/u7igxFm6mJ92xat3jVSpme0E=; h=Subject:From:To:Date:In-Reply-To:References; b=HGmetgasvm+2QYTdx8ysA91/6c5E4lhv+vzwlgOOnEvEjLx5+jMhgd/Hj/SuuWl6f IlPIy8CKAW/Yw3WERE4AlJKMZdKQ6vPdZmDqbT6w7cn0JwkgkcGGwplEMJpqa5jxFR qxirA31Fhg47H8TP+9TVCjC4IEdCSLJ+JeFUWO/p3T+frXGwm/DNAslU7C8oMJX/WV si9TZLbsD7cMrygqqZSASJGUrNcS4Kn3wueCE9En8RqF0MeWnedHd8tCR6L6qm7fYP xV11x9vlcy0HKzCH2z5EdARssJ1w4Kt3AE5cmmMZTDEA+rFi/RKJgpBlC+bkytPf/9 Pdh/QtL77GzveqGHC4vLbheocxPdmkRpi/7lVaP/y6C/oQqtg7dbI7jzaHauWv5POY JfrT/x9dnApRY220jW92FD82HOCNa8OLjYzgHa0CKkt2+2Z6+G1qGYTYJKHa5Eh5ri cnenotUGNvEzgWvRoDGOyYOaRCSla6t62cbtBN3YP6aquq5ezz6KsmzoNiGKHkHf3v pYK0F8IF/ZfeIP+R9crH/nnXVfdqMcWkHWL45tJAj9JGCJIocnpJ67uA0PyumSqLPi OQdf1xRJLAlaCJTnLy50klCElswZUnfbrd0+g6PptY0PfUCrz8IUIlB4XyKQFNj89y czrM70dvyLSOXRt22D70vwEM= Authentication-Results: mail.aegee.org/x28JboLj018846; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x28JboLj018846 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 Mar 2019 19:37:50 GMT Message-ID: <53c5912a8b973aeb0ab67a0d8b7ed0072c5f23b7.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Robert Stepanek , calsify@ietf.org Date: Fri, 08 Mar 2019 19:37:50 +0000 In-Reply-To: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.92 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 19:38:00 -0000 Hello, imagine you book a room for 3:45 hours, and want to have there a session “Topic A” for one hour, a 0:15 hours for coffee-break and then a session “Topic B” for two hours. You map this in iCalendar/CalDAV as (imprecise syntax): -- DTSTART: 8am DTEND: 9am (or if you prefer DURATION: 1h) SUMMARY: Topic A UID: 1 -- DTSTART;RELTYPE=FINISHTOSTART;REL-TO=UID:1 (per https://tools.ietf.org/html/draft-ietf-calext-ical-relations - the start is defined as the end of the other event) DURATION: 15minutes SUMMARY: Tee time UID: 2 -- DTSTART:RELTYPE=FINISHTOSTAR;REL-TO=UID:2 DTEND: 11:45am SUMMARY: Topic B UID: 3 -- So far so good. Now, imagine the first session get longer as expected, e.g. 75 minutes. The last session has to end in 11:45am, because the room is booked only until then. Under circumstances, the only event that needs to be updated is the first one, and the rest of the agenda will magically align, provided draft-ietf-calext-ical-relations makes progress. In this case, for UID:2 you have to use DURATION and for UID:3 you have to use DTEND → Both are needed. Regards Дилян On Thu, 2019-02-14 at 17:02 +0100, Robert Stepanek wrote: > During CalConnect XLIV in Zurich last week, discussion arose if the JSCalendar duration property is enough to define the time span of an event, or if an end time should be allowed as well (see the latest spec here). > > Two arguments were raised in favor of adding an end time > It simplifies translation of VEVENTs with DTSTART/DTEND from iCalendar. > It allows to specify recurring events with a fixed end time even in case of time gaps (e.g. a recurring night club that has to close at a fixed time for legal reasons). > > Our main concerns with adding an end time are: > Having two representations to define an event time span adds complexity. This contradicts the stated goals of JSCalendar. > Translation of DTSTART/DTEND to duration for one-time events is in almost all cases trivial. It does not require to rewrite existing calendar data. > The "night club scenario" isn't covered by iCalendar either, as the same exact duration of a recurring even with DTEND must be applied to all members of the generated recurrence set (see RFC 5545, section 3.8.5.3). If anything, this scenario speaks for a new parameter on the RRULE. > Durations are guaranteed to be zero or positive, which makes it harder to produce invalid events. > > As it currently stands we therefore see no need for an end time property. Please let us know if you disagree. > > Thanks, > Robert > > > > > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Fri Mar 8 11:44:28 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2343E1277E2 for ; Fri, 8 Mar 2019 11:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=shinkuro-com.20150623.gappssmtp.com 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 m31ccywVR-r1 for ; Fri, 8 Mar 2019 11:44:23 -0800 (PST) Received: from mail-yw1-xc29.google.com (mail-yw1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 28596124B19 for ; Fri, 8 Mar 2019 11:44:23 -0800 (PST) Received: by mail-yw1-xc29.google.com with SMTP id x20so2903503ywd.5 for ; Fri, 08 Mar 2019 11:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oGf0Rl1Uf7gCBuQHqRmz2Nu23DQSul0G1FvwYcaNdlk=; b=BFa871PF+paJUjibjbpnog/arHxFrv1XcgA8hjMhoIJJXbgqo+CEJAwrbgDuBmEpfw gwHtmfHwnJLNK4I8xiIIJgtnRb7I7L3fsfa3EzHFa2R8r9EfAxykU40NnENLHiDJ2FON aTbcrYamo//L+gaQy/tVHBXZ/DZ4dg5nvfmPmHA3Nw8EXnis0P0xJ/Lv7qa0m/uzoGKX dB5zPNWQxxcz1WNOJtZr0+1M4XAnyWUrYIwUrSnUxEmI1iMaAem91pwYxG/orXQuHjL8 y9/BAfukA7HMqECOUOy9oPc0act4Hu9THOg4bawdF2j4J0WI4L6Zu/6NHa5hMftYkk+B Trxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oGf0Rl1Uf7gCBuQHqRmz2Nu23DQSul0G1FvwYcaNdlk=; b=HcgQbfaUqJXYzGMguLocUj/iyDS+nKMwxGYwnUH3gP1dSviqTzsLiZuzXKl+7DULQI X6CofphM1sLg6EgpG++mdEuiRgHJzN3lAX4NVNzEBD84/9/zJMmRyzjlHAmJlLLwMVSK tcXbu/4i++bq/fQIFENaAWtiprMlLCRP/0G9CDw7aBjKCaD8M9qrs1s3R0S4lugREq4n W5sLn23b9o2O2WLrjVNl9druHMmmOYrXxdl8lOO0RyHdmB7ub+hMe4yocBKzGzS8Ber7 n1vieoLEnPNzbUhwvrft29W5NPpVvsziPuf+rcBiG10L854drpZVfrckGVp6UKFVMowM ly2w== X-Gm-Message-State: APjAAAVnSumW3fbCD186fhn5pFgG+jT/BNQROZ+LH+ENplrg3dvLrLdE +HPOgfnCLIhm3erTjv1sBnKXCe1wKx8sN2+89t4OEndoISg= X-Google-Smtp-Source: APXvYqyfT4QhwEA6kJILPNGe07jh94eDc4cYooKxvgi+iCipZBN2gGhx4sUeO4E0rInwKjHDA+uSMg1K7/ZQ/xW0tsk= X-Received: by 2002:a0d:efc2:: with SMTP id y185mr16596264ywe.252.1552074260706; Fri, 08 Mar 2019 11:44:20 -0800 (PST) MIME-Version: 1.0 References: <87879E7D-A55B-4A88-80B8-B503C89E52CB@iab.org> <20131030081355.GA23990@nic.fr> <7F135C08-A550-450F-82B4-1F239E115BC3@tzi.org> <20131030083611.GA27804@nic.fr> <01P06PWP9XG4004X76@mauve.mrochek.com> <527119E9.5050407@cisco.com> <01P06RD9XM60004X76@mauve.mrochek.com> <4FBA1270FC906838EB82345F@cc0102a-dhcp145.apple.com> In-Reply-To: From: Steve Crocker Date: Fri, 8 Mar 2019 14:40:22 -0500 Message-ID: To: IETF-Calsify Content-Type: multipart/alternative; boundary="000000000000f98dd805839a7227" Archived-At: Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 19:44:27 -0000 --000000000000f98dd805839a7227 Content-Type: text/plain; charset="UTF-8" Bron, et al, In response to your note about the charter and direction of the working group, here's a note I sent more than five(!) years ago that garnered no response at all. Nonetheless, I think including some sort of expected propagation time in the specification is -- or least ought to be -- within scope. Steve Crocker On Tue, Nov 5, 2013 at 5:38 PM Steve Crocker wrote: > I was very pleased to see the work on the Timezone Service Protocol. I > have no argument about the format of the data elements or actions, but the > timing model is incomplete. One of the motivations is make sure accurate > timezone data is distributed in a timely fashion. In order to make good on > this, we need to say more about the timing. As noted in the anecdote cited > below, time zone changes are sometimes abrupt. How much notice is required > in order to make sure time zone changes are guaranteed to be propagated to > all devices? And on the other end of the system, how frequently do devices > need to poll or otherwise be notified of changes? > > Historically, IETF protocols have tended to be a bit vague about timing > parameters and it's been left to operational practice. The results are > frequently messy. We have a chance for this one to be much clearer. The > timezone database now maintained by IANA is a pretty solid solution for the > source of reliable, authoritative information, but there's not been much > written other than anecdotes about how often the data changes and how much > lead time is required to distribute the information. > > In the present draft, the only wording I could find is at the section > 4.1.3: > > > Clients SHOULD NOT poll for such changes too frequently, typically once > a day ought to be sufficient. See Section 8 on expected client and server > behavior regarding high request rates. > > and the cautions in Section 8. > > I don't have an axe to grind regarding the design of the protocol, but I > will note that if the timezone data were published via DNS, both the > throttling problem and the model of propagation time would be dealt with > automatically. In any case, even if there's no desire to distribute this > data over DNS, I do believe we need to provide much stronger statements > about the expected time to propagate changes and to be clearer about how > the design implements such statements. > > Steve > > > > > On Oct 30, 2013, at 11:23 AM, Cyrus Daboo wrote: > > > Hi ned+ietf@mauve.mrochek.com, > > > > --On October 30, 2013 at 7:52:55 AM -0700 ned+ietf@mauve.mrochek.com > wrote: > > > >>>> Which argues for including the local time when the event will take > >>>> place. If you want to mandate that the time also appear in UTC, great, > >>>> but it's quite important that the local time also be there. > >> > >>> And local time should be normative to deal with such unforeseen > >>> circumstances as a papal visit. From the southamerica file in the TZ > >>> database: > >> > >>> # From Daniel C. Sobral (1998-02-12): > >>> # In 1997, the DS began on October 6. The stated reason was that > >>> # because international television networks ignored Brazil's policy on > >>> # DS, they bought the wrong times on satellite for coverage of Pope's > >>> # visit. This year, the ending date of DS was postponed to March 1 > >>> # to help dealing with the shortages of electric power. > >> > >>> ;-) > >> > >> Good point. I agree. > > > > Timezones can (and do) change at very short notice in different parts of > the world. Typically computer systems have timezone data cached as part of > the OS, and only get updates when the OS is itself updated - often long > after a timezone change has occurred or long after future events were > booked but are now out of sync for participants in different timezones. To > address that a number of folks in the calendaring and scheduling community > have been working om a timezone service protocol - < > https://datatracker.ietf.org/doc/draft-douglass-timezone-service/> - our > initial focus for that has been iCalendar (RFC5545) based VTIMEZONE > component delivery to calendar and scheduling clients and servers. However, > we would like to also deliver OS-style timezone data to devices to break > out of the requirement for those to be updated only when the OS itself > updates. For unix-based OS's that means being able to deliver "raw" > zoneinfo" data over that protocol. > > > > Anyway, if you are interested in that work please comment over on the > ietf-calsify list (cc'd) - we (the authors of that draft) - intend to get > it moving to last call soon. There are already several implementations that > have undergone testing at the Calendaring and Scheduling Consortium > (CalConnect) interop events, so we are happy with it, but would appreciate > more feedback. > > > > -- > > Cyrus Daboo > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --000000000000f98dd805839a7227 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bron, et al,

In respon= se to your note about the charter and direction of the working group, here&= #39;s a note I sent more than five(!) years ago that garnered no response a= t all.=C2=A0 Nonetheless, I think including some sort of expected propagati= on time in the specification is -- or least ought to be -- within scope.

Steve Crocker

On Tue, Nov 5, 2013 at 5:38 PM St= eve Crocker <Steve@shinkuro.com> wrote:
I w= as very pleased to see the work on the Timezone Service Protocol.=C2=A0 I h= ave no argument about the format of the data elements or actions, but the t= iming model is incomplete.=C2=A0 One of the motivations is make sure accura= te timezone data is distributed in a timely fashion.=C2=A0 In order to make= good on this, we need to say more about the timing.=C2=A0 As noted in the = anecdote cited below, time zone changes are sometimes abrupt.=C2=A0 How muc= h notice is required in order to make sure time zone changes are guaranteed= to be propagated to all devices?=C2=A0 And on the other end of the system,= how frequently do devices need to poll or otherwise be notified of changes= ?

Historically, IETF protocols have tended to be a bit vague about timing par= ameters and it's been left to operational practice.=C2=A0 The results a= re frequently messy.=C2=A0 We have a chance for this one to be much clearer= .=C2=A0 The timezone database now maintained by IANA is a pretty solid solu= tion for the source of reliable, authoritative information, but there's= not been much written other than anecdotes about how often the data change= s and how much lead time is required to distribute the information.

In the present draft, the only wording I could find is at the section 4.1.3= :

> Clients SHOULD NOT poll for such changes too frequently, typically onc= e a day ought to be sufficient.=C2=A0 See Section 8 on expected client and = server behavior regarding high request rates.

and the cautions in Section 8.

I don't have an axe to grind regarding the design of the protocol, but = I will note that if the timezone data were published via DNS, both the thro= ttling problem and the model of propagation time would be dealt with automa= tically.=C2=A0 In any case, even if there's no desire to distribute thi= s data over DNS, I do believe we need to provide much stronger statements a= bout the expected time to propagate changes and to be clearer about how the= design implements such statements.

Steve




On Oct 30, 2013, at 11:23 AM, Cyrus Daboo <cyrus@daboo.name> wrote:

> Hi n= ed+ietf@mauve.mrochek.com,
>
> --On October 30, 2013 at 7:52:55 AM -0700 ned+ietf@mauve.mrochek.com wrote:=
>
>>>> Which argues for including the local time when the event w= ill take
>>>> place. If you want to mandate that the time also appear in= UTC, great,
>>>> but it's quite important that the local time also be t= here.
>>
>>> And local time should be normative to deal with such unforesee= n
>>> circumstances as a papal visit.=C2=A0 From the southamerica fi= le in the TZ
>>> database:
>>
>>> # From Daniel C. Sobral (1998-02-12):
>>> # In 1997, the DS began on October 6. The stated reason was th= at
>>> # because international television networks ignored Brazil'= ;s policy on
>>> # DS, they bought the wrong times on satellite for coverage of= Pope's
>>> # visit. This year, the ending date of DS was postponed to Mar= ch 1
>>> # to help dealing with the shortages of electric power.
>>
>>> ;-)
>>
>> Good point. I agree.
>
> Timezones can (and do) change at very short notice in different parts = of the world. Typically computer systems have timezone data cached as part = of the OS, and only get updates when the OS is itself updated - often long = after a timezone change has occurred or long after future events were booke= d but are now out of sync for participants in different timezones. To addre= ss that a number of folks in the calendaring and scheduling community have = been working om a timezone service protocol - <https://datatracker.ietf.org/doc/draft-douglass-timezone-ser= vice/> - our initial focus for that has been iCalendar (RFC5545) bas= ed VTIMEZONE component delivery to calendar and scheduling clients and serv= ers. However, we would like to also deliver OS-style timezone data to devic= es to break out of the requirement for those to be updated only when the OS= itself updates. For unix-based OS's that means being able to deliver &= quot;raw" zoneinfo" data over that protocol.
>
> Anyway, if you are interested in that work please comment over on the = ietf-calsify list (cc'd) - we (the authors of that draft) - intend to g= et it moving to last call soon. There are already several implementations t= hat have undergone testing at the Calendaring and Scheduling Consortium (Ca= lConnect) interop events, so we are happy with it, but would appreciate mor= e feedback.
>
> --
> Cyrus Daboo
>

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--000000000000f98dd805839a7227-- From nobody Fri Mar 8 12:38:44 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05501277CD for ; Fri, 8 Mar 2019 12:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xAnKoOmlO8EZ for ; Fri, 8 Mar 2019 12:38:41 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 9B97C1274A1 for ; Fri, 8 Mar 2019 12:38:41 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id b3so890126qtj.3 for ; Fri, 08 Mar 2019 12:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=mQgGjrmD1Y498btMWpgLJFC/cbaRKQJmAMTuum0R/8k=; b=G9xIXG4EBN/xrkdM1KPhNb9F3UV9TwmsbcO1a9oIVG0ZGmQY0hmW3oSb/w72KU1pm+ 191laWAL8gxMOa5Cq4mHNzXfejJ5G3Cc6oqILPDoAv55h8467rgj69NP862aKEbi1tSF QXJI5VbNHOzsnrE0Uk1Ms3sNAfkzJJeVvvxOOr8SMg2EfufZFq0e+eIyWSKOLjoMzJgm oZ/bKGgazBlYs9WrEB7Z3yM4ApvetKpiKX1t+SULX2cNdQ6qb/pPt06k0Orp+WkUsTJ2 yTbAtC/0CHtVZ++d6sY7X0pLXC3kmrh2agSvhwTAKrHZWPpOfsrIyPZBB6uzKus7jNtd II3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=mQgGjrmD1Y498btMWpgLJFC/cbaRKQJmAMTuum0R/8k=; b=rMWspihFCIvLmEqGaVtX7QI3sVY2YuYn77lcMp039sqOBPhR/QThBrtb9rH2m1iv0+ 4X77yY1x1MVm158Rc3B/ZjZKXTqDmh7wGwxFEqlYqMAJK0pCPu+cw9wXUFd3xZof835F 4Re535/PBb60P1C5ClpXCtE233zfG4yODUNrtEx3ulCn+HIDxESK6vleqU7RJ3MelY7I kZby6yLnEoHn81Wuf+aINM0hsS8oewuyT/NVt+fToPVmhRbc4PxdiiTasEL9aH6gsl7u BokUoQW+IMLSNJzTVod+VwLpcr4UkAw5VpFdiHDsGdervCcYfNOpQaELOMxNAaMeu0Bq 3DMA== X-Gm-Message-State: APjAAAV2/XD91mb75JkTDAmgqKQ4VDNK7bjt3F95tvHGgDrW0RBwSKnJ AKCfgFe5G2J76v6/WlFsEntERRFR X-Google-Smtp-Source: APXvYqxZRD4rmM2RyrXaWYA4P8kP0OJvwh6CQkyPevpCJzy91J0rqP92xE0Dtdnt+pPouFr7YKJx9Q== X-Received: by 2002:a0c:954d:: with SMTP id m13mr16430130qvm.243.1552077520334; Fri, 08 Mar 2019 12:38:40 -0800 (PST) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id 17sm5863169qtt.18.2019.03.08.12.38.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 12:38:39 -0800 (PST) To: calsify@ietf.org References: From: Michael Douglass Message-ID: Date: Fri, 8 Mar 2019 15:38:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5ECFB92D22B55064B9ED2BF4" Content-Language: en-US Archived-At: Subject: Re: [calsify] Request for adoption: draft-gondwana-caldav-scheduling-controls X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 20:38:44 -0000 This is a multi-part message in MIME format. --------------5ECFB92D22B55064B9ED2BF4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Cyrus wrote a spec for bulk import/updates https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calendarserver-bulk-change.xml I have the impression it's used but not certain. The spec says nothing about scheduling. On 3/8/19 07:07, Bron Gondwana wrote: > It's a bit cheeky asking this as a recent chair myself, but I had > started work on this document as a purely FastMail suggestion, and > during discussion at CalConnect last month in Zurich it came up that > Google had done much the same thing themselves to handle bulk import, > so I ran the idea past Lucia and put this draft together. > > There's still some work to do, and I'm happy to hand over authorship > to somebody else if anyone wants it, or to continue working on it > myself.  I've renamed things to be a bit more consistent than our > implementation at FastMail, but of course we'd update to match the > standard once the spec is done. > > https://datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/ > > (still plenty of work to do on it, but the bones are there) > > I believe this is within the scope of this group's existing charter > and would like to see it adopted. > > Regards, > > Bron. > > -- >   Bron Gondwana, CEO, FastMail Pty Ltd >   brong@fastmailteam.com > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------5ECFB92D22B55064B9ED2BF4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Cyrus wrote a spec for bulk import/updates

https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calendarserver-bulk-change.xml

I have the impression it's used but not certain.

The spec says nothing about scheduling.

On 3/8/19 07:07, Bron Gondwana wrote:
It's a bit cheeky asking this as a recent chair myself, but I had started work on this document as a purely FastMail suggestion, and during discussion at CalConnect last month in Zurich it came up that Google had done much the same thing themselves to handle bulk import, so I ran the idea past Lucia and put this draft together.

There's still some work to do, and I'm happy to hand over authorship to somebody else if anyone wants it, or to continue working on it myself.  I've renamed things to be a bit more consistent than our implementation at FastMail, but of course we'd update to match the standard once the spec is done.


(still plenty of work to do on it, but the bones are there)

I believe this is within the scope of this group's existing charter and would like to see it adopted.

Regards,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com



_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------5ECFB92D22B55064B9ED2BF4-- From nobody Fri Mar 8 18:31:01 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5AFF12796B for ; Fri, 8 Mar 2019 18:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 cSZd_FDVatGt for ; Fri, 8 Mar 2019 18:30:58 -0800 (PST) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 19930126C15 for ; Fri, 8 Mar 2019 18:30:58 -0800 (PST) Received: by mail-ot1-x333.google.com with SMTP id v20so19086951otk.7 for ; Fri, 08 Mar 2019 18:30:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=/MrujCp1OOtkkZfBtlk0XjNkhbU58WFkJXaw7cmMhpg=; b=NLceqQ9pagtkiT8rsr/RXuQPSK/pbGor8dhd43xObX1kYCjobbGJgieNQzpZT+hr6m xzF5T6FvRY6Xfd30Z66f577GGfsUDMTmlSkbLp34dkfXoQQSG5PLx9tI3zE/JRicAe6o cUiY/dSl8Pjv5Poz8NDNb8bB8e9YenbcC82FEHFoiUT58MsnZmW9FpZcdXOlvr6rsaJQ A/o+iMXI3N5tqozaQpGUhuEggYxc/VI5YpliwPjnrvwcWoO/JCnWNY19BySjTTBURngT tBYRXkpAA2Uds67rJGKeQMjMRGJvlmyqJPTT2Bjo/nJ3B+dbwugVhY2JgZf4RLVSm36X t+7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=/MrujCp1OOtkkZfBtlk0XjNkhbU58WFkJXaw7cmMhpg=; b=P+TnV+0qf/KM+tq9SBSBxE9eEWZEJQMzBFubr3s72JQwqhYVAJrS0JXUlMaPSGFg/1 D/5LeS/wTdlzVRzIBFN5f0kRp3KiXQ5uPJX+LEmHQIK6AMh+mPt3WPBs0s3RbTrsvZh3 FzeMAFEk5HoHLcrbSM3c1p7ON+6aZXOETmgPYCmCHRlKzmGqol/BKsuQahOM1nujDz0f +GkbbnH9D1l56YG6qOA5VikwS/X89B/VRmbpH4x1giJvPumf9mT2bRTeGcw3XQY8Zse/ nGGy7qaTOiK0b8MrClHK1pixAjiHCkErhlYAH1LPAvEsc/WmSmtjeAg/Ke09Tp58Bm4M Bynw== X-Gm-Message-State: APjAAAW2qJrJH4Cf/4YHdvzj5dusWdh7P1U7DiAObor3J6EvKkdIWLkt qxU53WrHJKp9rSPZ0xQj2z4NiJ0rZ0M8 X-Google-Smtp-Source: APXvYqzZ1jc8buFRqgB1X58ir8yLay7VWGw1f2aRVaztRgWc5Q6CkvEXOr3wK+eAitIm3U6dBHqWBQ== X-Received: by 2002:a9d:73c2:: with SMTP id m2mr13706808otk.91.1552098656849; Fri, 08 Mar 2019 18:30:56 -0800 (PST) Received: from [192.168.1.7] (75-174-58-238.boid.qwest.net. [75.174.58.238]) by smtp.googlemail.com with ESMTPSA id e24sm3778811otl.2.2019.03.08.18.30.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 18:30:55 -0800 (PST) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <53c5912a8b973aeb0ab67a0d8b7ed0072c5f23b7.camel@aegee.org> Organization: http://SoftwareAndServices.NET Message-ID: Date: Fri, 8 Mar 2019 19:30:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <53c5912a8b973aeb0ab67a0d8b7ed0072c5f23b7.camel@aegee.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020801010101050801070507" Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 02:31:00 -0000 This is a cryptographically signed message in MIME format. --------------ms020801010101050801070507 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/8/19 12:37 PM, =C3=83=C2=90=C3=82=C2=94=C3=83=C2=90=C3=82=C2=B8=C3=83= =C2=90=C3=82=C2=BB=C3=83=C2=91=C3=82=C2=8F=C3=83=C2=90=C3=82=C2=BD=20 =C3=83=C2=90=C3=82=C2=9F=C3=83=C2=90=C3=82=C2=B0=C3=83=C2=90=C3=82=C2=BB=C3= =83=C2=90=C3=82=C2=B0=C3=83=C2=91=C3=82=C2=83=C3=83=C2=90=C3=82=C2=B7=C3=83= =C2=90=C3=82=C2=BE=C3=83=C2=90=C3=82=C2=B2 [Masked] wrote: >=20 >=20 > Hello, >=20 > imagine you book a room for 3:45 hours, and want to have there a sessio= n =E2=80=9CTopic A=E2=80=9D for one hour, a 0:15 hours for > coffee-break and then a session =E2=80=9CTopic B=E2=80=9D for two hours= =2E You map this in iCalendar/CalDAV as (imprecise syntax): >=20 > -- > DTSTART: 8am > DTEND: 9am (or if you prefer DURATION: 1h) > SUMMARY: Topic A > UID: 1 > -- > DTSTART;RELTYPE=3DFINISHTOSTART;REL-TO=3DUID:1 (per https://tools.ietf.= org/html/draft-ietf-calext-ical-relations - the start > is defined as the end of the other event) > DURATION: 15minutes > SUMMARY: Tee time > UID: 2 > -- > DTSTART:RELTYPE=3DFINISHTOSTAR;REL-TO=3DUID:2 > DTEND: 11:45am > SUMMARY: Topic B > UID: 3 > -- >=20 > So far so good. >=20 > Now, imagine the first session get longer as expected, e.g. 75 minutes.= The last session has to end in 11:45am, because > the room is booked only until then. Under circumstances, the only even= t that needs to be updated is the first one, and > the rest of the agenda will magically align, provided draft-ietf-calext= -ical-relations makes progress. >=20 > In this case, for UID:2 you have to use DURATION and for UID:3 you have= to use DTEND =E2=86=92 Both are needed. So your choice is to make the calendar not match reality, or reissue=20 some new instances with the corrected values. When you re-issue new=20 instances, simply adjust them to be correct. If you do not re-issue instances, the calendar does not match reality=20 anyway - so the point is really not relevant. Your simply picking which=20 properties in which components are incorrect. If you reissue, simply set the 1st session end time to an accurate limit = (or ignore it is wrong). Set the break time to the correct start time=20 and 15 minute duration (or ignore it is wrong). And set the 2nd session=20 time to the correct values. There is no one way to solve these issues. I think that makes it=20 ambiguous and poorly designed. There is no wrong way to get it done. The = meetings over times zone changes is a pain when implementations change=20 everything to DTEND, and relative entries are kind of correct in the=20 example you provide - or you have to reissue them anyway to make them=20 correct. In both ways of thinking, the changed VEVENT components need to be=20 updated. It is just a matter of one of several ways of getting it done. Which is why I say it is ambiguous. There should be one way to get it=20 done recognized by all implementations. I assert that all VEVENTs have some kind of duration, even when zero,=20 and can never be negative. However DTEND when not in UTC, is not always=20 obvious and a real pain over time zone changes. I have found that developers will push for the method that makes any=20 changes to their current implementation easier. And sometimes, that=20 makes for ambiguous or difficult to understand specifications. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms020801010101050801070507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyYwggU4MIIEIKADAgECAhEAhiSk7ZnwaFDrCut2h4/AtjANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNzAxMDAw MDAwWhcNMTkwNzAxMjM1OTU5WjAnMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21h aWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvt4TUC6EmKlZIK4JddvF U6ELAaWYZyNrUyJpYXhDBrVknyn10KdWb5n8WrY3yDu0XduwkKTMmPcXokA1AxqnI5qSbin/ fPz7YaU4A+dMEMXEatxqrObK7Op2K12TikNGuM7zo54PfHoryJnobBZXPAgQ4u9LiLDTOuRJ tpnYr46ez/2LcgVxnZ+T3AEmlYsXu7BNCC8/STpfqQwk37zI5dUtfgJ3LCnChDXZNuRD6K5X Ds8nH9/QaRBmpmXzcKfRzyhaw1B1ifmFQWq6amuAIpsmoewL/A9pv2fKEVjZSzvDGEgs6811 B5CqQ16nWcGO+XVRWU1JCwhiSGQA6hz+CQIDAQABo4IB7DCCAegwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEkHmatyXIB08cH7hwoPjNJPX4gzMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wIQYDVR0RBBowGIEWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEAZZORUWLOnd0ylV6acyCrzyTcMdQa3usU/h95NhleWhL3ouKDWJttZeZE8Uald+nv ppmQi8E1uJCNN9nBiN3Mu8Coj7Bzqaai0zic0NDvjVfJsNqL1F1PnlflBjn/AHt8AxIKsMJr PkqbyG5gGoNuW1Gf+m+5mhmv14dgjTISCDQBZKC6ubEhcMUU/q8QtqJS5wFpyKyJEBc1h246 0F6u4oZ6NUam74hKZwLJ+zVTQjdvsmipw+5hITMvUKISL52DzqZnolGLkpFS0e+pdiPQFIZg dFZ6YR63arpx67MCD4ZVOnM8Qmzmv+8lNmNvMfYOBxiAMySM1orQdlqO/dT7xzCCBeYwggPO oAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypV pVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRik w8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsU tQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0O BBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3Js LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3f QP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb +SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU /PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+ E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnM rwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZ dRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VY nwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCC BDQCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQD EzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAhiSk7ZnwaFDrCut2h4/AtjANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzA5MDIzMDU0WjAvBgkqhkiG9w0BCQQx IgQgONlPN5XlOT677EI+d9aUi72Unp1Yoh57rNbQiEV3A68wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGw MIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYk pO2Z8GhQ6wrrdoePwLYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYkpO2Z8GhQ6wrrdoePwLYwDQYJKoZI hvcNAQEBBQAEggEAoZFvi4jcyE3C452tCtv6hfAz9X0BzgbAeayA4v8hqot3WZ7Wg98Z67dP rk1f943CYOPvooQQDwrsOZO6KZ6FyvQgV4vTY21rqb3Y9YD7xlZu03zJ0ymkFPa2HTvGFUdn UOEgqkRBXFkfS5xpY9vq0kCN4K7wI6CPbcDQ+aWtZ41UrsZYKE1XnZj35XHfhH9c+6/scutn IH3v2BH/YdnT61V/sx7nR9K/xoJKxYW+tzX19UNW9VEUvku+fYOb47Y6YdoIK+dBoxJvV9d3 Fd9als8mRsjoEMYaPyEk8xZYGSOBz176UOMgrIIBV9qsXGM6JEyNd3rcwtOu51dx8h8HLgAA AAAAAA== --------------ms020801010101050801070507-- From nobody Sat Mar 9 11:52:20 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C010812865D for ; Sat, 9 Mar 2019 11:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 tn_0IKqOHmmR for ; Sat, 9 Mar 2019 11:52:15 -0800 (PST) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE77A1279A9 for ; Sat, 9 Mar 2019 11:52:14 -0800 (PST) Authentication-Results: mail.aegee.org/x29JqAwY017379; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1552161131; i=dkim+MSA-tls@aegee.org; r=y; bh=lZi5A6u0wNeQYPp0irOZAb24ZI65drLC7YXGIQhUmRo=; h=Subject:From:To:Date:In-Reply-To:References; b=b/GBZDz6rgD7NfjJA3bA+hAVMU3e3PumuDFxcbsE/fc2T8eWl8thE83ZNgsw6vCgy 8KrRpU+SYSUNH6TlUTwUbzBj7QdpkpXAKxUg5fvug8ix4gdbPaHy85XIboLXSvS40Z 8eYPj1tzNm0Pp1DXRAbALI4TlkvhJaMb2Q3eEVMx5yfuM+TFOZIcwrBhWYkilL4XHD fWswzyrrhXF2i4ufoyYuy4UoaN+lTH7JvOllqR9ozCEaoQNA8nKh5OPb1/EM3BCo+c i6nd6aPYnHr6ZVGwyBNsQEyFN1057zDvRUwlrHxT9EfEl0/8GvhNFbnQgx7449ODtj VJ43v0FbIpZ8IxCi4fhqL+Qmmp3izFX/5ZY1DnIsuX/5YkhUL4/rpRjUeKTnI2XCVm To8jiitoBdJkHxpNZwYimC6fQv1wrqkZv6hjINyE2jRPfKzF6vT4D5+gWUxvoL7Ay0 T3BoijG3hXgWFiqyInt16nlm9xaX1j7XmdUiweK1Z3v+LhuQwRQiJ6PtuRZ+ZxXsMH T8Qp4qtGga3MVKUznx32MnFzknhtyHtZacen8TP/mB8wp3E2IFz5b5Eo6YlHP49K1P HW2eoAds2O14UkLJm6HxXp2xAiNQAf/9yte0QcB4/qvzvIPq8p1ikc614cana8Lefb bYeLq/8gU7YDVq+9YXf9NNpw= Authentication-Results: mail.aegee.org/x29JqAwY017379; dkim=none Received: from Tylan (87-118-146-153.ip.btc-net.bg [87.118.146.153]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x29JqAwY017379 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 Mar 2019 19:52:11 GMT Message-ID: <50391a5de6edf4b9caa22c49839d6a11c0f6dde6.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: Doug Royer , calsify@ietf.org Date: Sat, 09 Mar 2019 19:52:10 +0000 In-Reply-To: References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <53c5912a8b973aeb0ab67a0d8b7ed0072c5f23b7.camel@aegee.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.31.92 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.1 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 19:52:19 -0000 Hello Doug, for an event with five slots, each slot containig six parallel meetings, there are 4 breaks and 30 sessions (so 34 events). If the first slot gets prolonged/shortened, 28 events (4 breaks and 24 sessions) that are in the future, need to be reissued, unless they have relative times. If for each of the five slot, one of the events has relative time to the previous break, and the other parallel events have start/stop/duration as that event, only one event per slot needs adjustment. The benefit of having relative times (start/end) is to reissue less changes. In this case it could be reissuing one..four event(s) versus reissuing 28 events. The latter option is … error prone. Regards Дилян On Fri, 2019-03-08 at 19:30 -0700, Doug Royer wrote: > On 3/8/19 12:37 PM, Дилян > Палаузов [Masked] wrote: > > > > Hello, > > > > imagine you book a room for 3:45 hours, and want to have there a session “Topic A” for one hour, a 0:15 hours for > > coffee-break and then a session “Topic B” for two hours. You map this in iCalendar/CalDAV as (imprecise syntax): > > > > -- > > DTSTART: 8am > > DTEND: 9am (or if you prefer DURATION: 1h) > > SUMMARY: Topic A > > UID: 1 > > -- > > DTSTART;RELTYPE=FINISHTOSTART;REL-TO=UID:1 (per https://tools.ietf.org/html/draft-ietf-calext-ical-relations - the start > > is defined as the end of the other event) > > DURATION: 15minutes > > SUMMARY: Tee time > > UID: 2 > > -- > > DTSTART:RELTYPE=FINISHTOSTAR;REL-TO=UID:2 > > DTEND: 11:45am > > SUMMARY: Topic B > > UID: 3 > > -- > > > > So far so good. > > > > Now, imagine the first session get longer as expected, e.g. 75 minutes. The last session has to end in 11:45am, because > > the room is booked only until then. Under circumstances, the only event that needs to be updated is the first one, and > > the rest of the agenda will magically align, provided draft-ietf-calext-ical-relations makes progress. > > > > In this case, for UID:2 you have to use DURATION and for UID:3 you have to use DTEND → Both are needed. > > So your choice is to make the calendar not match reality, or reissue > some new instances with the corrected values. When you re-issue new > instances, simply adjust them to be correct. > > If you do not re-issue instances, the calendar does not match reality > anyway - so the point is really not relevant. Your simply picking which > properties in which components are incorrect. > > If you reissue, simply set the 1st session end time to an accurate limit > (or ignore it is wrong). Set the break time to the correct start time > and 15 minute duration (or ignore it is wrong). And set the 2nd session > time to the correct values. > > There is no one way to solve these issues. I think that makes it > ambiguous and poorly designed. There is no wrong way to get it done. The > meetings over times zone changes is a pain when implementations change > everything to DTEND, and relative entries are kind of correct in the > example you provide - or you have to reissue them anyway to make them > correct. > > In both ways of thinking, the changed VEVENT components need to be > updated. It is just a matter of one of several ways of getting it done. > Which is why I say it is ambiguous. There should be one way to get it > done recognized by all implementations. > > I assert that all VEVENTs have some kind of duration, even when zero, > and can never be negative. However DTEND when not in UTC, is not always > obvious and a real pain over time zone changes. > > I have found that developers will push for the method that makes any > changes to their current implementation easier. And sometimes, that > makes for ambiguous or difficult to understand specifications. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Sat Mar 9 12:02:12 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB59130E68 for ; Sat, 9 Mar 2019 12:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Un9OP46xgMF3 for ; Sat, 9 Mar 2019 12:01:56 -0800 (PST) Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) (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 2FEB0130ECF for ; Sat, 9 Mar 2019 12:01:56 -0800 (PST) Received: by mail-ot1-x330.google.com with SMTP id z19so752313otm.2 for ; Sat, 09 Mar 2019 12:01:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:organization:message-id:date:user-agent :mime-version:in-reply-to; bh=jqx6Sc2wqkh0u2d/K6PSzO3PnlrNlQtqoZZjOO/CmdI=; b=GgFm52ouNUQfk5dea6bwyfi5qqIcYnUgSDzlsB5+AdRIqv4xQVbuR9ns7Fx8c4ReEI QIkjG1yav+JoFfmI/jjvOCtirfkFyergA2g/ZXfalKpDV0/uljJ5XJZn/4fCcbFwCY1V lynekom6n/GASlGgthu/Andy7empaPpL8ERnYY2aq0u8hilqQBj8XspVDRZFTbKZ6LnW VfnOLvGy4VMArkFiSRXmxjiqwmi4CI0lrJiE32/wQb8e1kri+SdapsbD8MYXjFydIdWw D+6gHJKtlKrNZUkshkKxSkd9drHwftC3aX0rOpXa/Q6oUZhuXwltohg1f38BPtWrdTwd /fmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:organization :message-id:date:user-agent:mime-version:in-reply-to; bh=jqx6Sc2wqkh0u2d/K6PSzO3PnlrNlQtqoZZjOO/CmdI=; b=pCg1SRDofCsbIBVpFvDGmgz78N0vrQER9nBw0xDIXa9WuW644zOkHf21VlUlW3XQ8u ObQyXMfXq2qz24lKPAVofeLCxYU/3AuIqdxxcwErg5zmdz1GQWhyPsUXtHk3NnFvH4mr saupcIqJ7rjP+6JMi1XD7fBzcqYB6Q7/lrMgT0ImDcqAeTbHKJB0H1A304bb2pGnfvjD cnGSPE6r18lDjYJVZxZkSGKkGhuuSgURaj/5eeYSUvzUZJXD6lV3MUQj/3ayxGVuo3TM ACKof/tJdal+7QOzwCFmWdW27dREIi9JZHFkMh/ipR5ifKbd1SVDNFMswX99vK9oV/0m K8BA== X-Gm-Message-State: APjAAAUMJqYvt2AxtG5cypdYZDZ1g3P83CaNvseJEDYbYOuWq+bolyzw z6WCHiueDTls37/lmEL7PXggUVsRpPu+ X-Google-Smtp-Source: APXvYqzBRX/EXvEK6xZxKjW4jbyR56HVpSocpfQcJjKmIDl84t20KP6Rg0JSCkLD+RBUmu6HW90Aow== X-Received: by 2002:a9d:4809:: with SMTP id c9mr15086587otf.215.1552161715222; Sat, 09 Mar 2019 12:01:55 -0800 (PST) Received: from [192.168.1.7] (75-174-58-238.boid.qwest.net. [75.174.58.238]) by smtp.googlemail.com with ESMTPSA id q1sm454326oth.42.2019.03.09.12.01.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Mar 2019 12:01:54 -0800 (PST) From: Doug Royer X-Google-Original-From: Doug Royer To: =?UTF-8?B?0JTQuNC70Y/QvSDQn9Cw0LvQsNGD0LfQvtCy?= , calsify@ietf.org References: <1550160126.3602072.1658018976.28709BD3@webmail.messagingengine.com> <53c5912a8b973aeb0ab67a0d8b7ed0072c5f23b7.camel@aegee.org> <50391a5de6edf4b9caa22c49839d6a11c0f6dde6.camel@aegee.org> Organization: http://SoftwareAndServices.NET Message-ID: <94a90dc2-8008-d6e2-0463-f5274d5de73f@gmail.com> Date: Sat, 9 Mar 2019 13:01:53 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <50391a5de6edf4b9caa22c49839d6a11c0f6dde6.camel@aegee.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040902090207060909020005" Archived-At: Subject: Re: [calsify] JSCalendar duration vs. end time X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Mar 2019 20:02:11 -0000 This is a cryptographically signed message in MIME format. --------------ms040902090207060909020005 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 3/9/19 12:52 PM, =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0=D0=BB=D0=B0= =D1=83=D0=B7=D0=BE=D0=B2 wrote: > Hello Doug, >=20 > for an event with five slots, each slot containig six parallel meetings= , there are 4 breaks and 30 sessions (so 34 > events). If the first slot gets prolonged/shortened, 28 events (4 brea= ks and 24 sessions) that are in the future, need > to be reissued, unless they have relative times. >=20 > If for each of the five slot, one of the events has relative time to th= e previous break, and the other parallel events > have start/stop/duration as that event, only one event per slot needs a= djustment. >=20 > The benefit of having relative times (start/end) is to reissue less cha= nges. In this case it could be reissuing > one..four event(s) versus reissuing 28 events. The latter option is =E2= =80=A6 error prone. >=20 > Regards > =D0=94=D0=B8=D0=BB=D1=8F=D0=BD And when they end across time zone changes, it is still a mess and=20 ambiguous. Coming up with more of the same examples does not make it=20 unambiguous. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 --------------ms040902090207060909020005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CyYwggU4MIIEIKADAgECAhEAhiSk7ZnwaFDrCut2h4/AtjANBgkqhkiG9w0BAQsFADCBlzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxPTA7BgNVBAMTNENPTU9ETyBSU0Eg Q2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTgwNzAxMDAw MDAwWhcNMTkwNzAxMjM1OTU5WjAnMSUwIwYJKoZIhvcNAQkBFhZkb3VnbGFzcm95ZXJAZ21h aWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvt4TUC6EmKlZIK4JddvF U6ELAaWYZyNrUyJpYXhDBrVknyn10KdWb5n8WrY3yDu0XduwkKTMmPcXokA1AxqnI5qSbin/ fPz7YaU4A+dMEMXEatxqrObK7Op2K12TikNGuM7zo54PfHoryJnobBZXPAgQ4u9LiLDTOuRJ tpnYr46ez/2LcgVxnZ+T3AEmlYsXu7BNCC8/STpfqQwk37zI5dUtfgJ3LCnChDXZNuRD6K5X Ds8nH9/QaRBmpmXzcKfRzyhaw1B1ifmFQWq6amuAIpsmoewL/A9pv2fKEVjZSzvDGEgs6811 B5CqQ16nWcGO+XVRWU1JCwhiSGQA6hz+CQIDAQABo4IB7DCCAegwHwYDVR0jBBgwFoAUgq9s jPjF/pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFEkHmatyXIB08cH7hwoPjNJPX4gzMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBP oE2gS4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGlj YXRpb25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAC hklodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlv bmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j YS5jb20wIQYDVR0RBBowGIEWZG91Z2xhc3JveWVyQGdtYWlsLmNvbTANBgkqhkiG9w0BAQsF AAOCAQEAZZORUWLOnd0ylV6acyCrzyTcMdQa3usU/h95NhleWhL3ouKDWJttZeZE8Uald+nv ppmQi8E1uJCNN9nBiN3Mu8Coj7Bzqaai0zic0NDvjVfJsNqL1F1PnlflBjn/AHt8AxIKsMJr PkqbyG5gGoNuW1Gf+m+5mhmv14dgjTISCDQBZKC6ubEhcMUU/q8QtqJS5wFpyKyJEBc1h246 0F6u4oZ6NUam74hKZwLJ+zVTQjdvsmipw+5hITMvUKISL52DzqZnolGLkpFS0e+pdiPQFIZg dFZ6YR63arpx67MCD4ZVOnM8Qmzmv+8lNmNvMfYOBxiAMySM1orQdlqO/dT7xzCCBeYwggPO oAMCAQICEGqb4Tg7/ytrnwHV2binUlYwDQYJKoZIhvcNAQEMBQAwgYUxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNV BAoTEUNPTU9ETyBDQSBMaW1pdGVkMSswKQYDVQQDEyJDT01PRE8gUlNBIENlcnRpZmljYXRp b24gQXV0aG9yaXR5MB4XDTEzMDExMDAwMDAwMFoXDTI4MDEwOTIzNTk1OVowgZcxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQx GjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvrOeV6wodnVAFsc4A5jTxhh2IVDzJXkLTLWg0X06WD6cpzEup/Y0 dtmEatrQPTRI5Or1u6zf+bGBSyD9aH95dDSmeny1nxdlYCeXIoymMv6pQHJGNcIDpFDIMypV pVSRsivlJTRENf+RKwrB6vcfWlP8dSsE3Rfywq09N0ZfxcBa39V0wsGtkGWC+eQKiz4pBZYK jrc5NOpG9qrxpZxyb4o4yNNwTqzaaPpGRqXB7IMjtf7tTmU2jqPMLxFNe1VXj9XB1rHvbRik w8lBoNoSWY66nJN/VCJv5ym6Q0mdCbDKCMPybTjoNCQuelc0IAaO4nLUXk0BOSxSxt8kCvsU tQIDAQABo4IBPDCCATgwHwYDVR0jBBgwFoAUu69+Aj36pvE8hI6t7jiY7NkyMtQwHQYDVR0O BBYEFIKvbIz4xf6WYXzoHz0rcUhexIvAMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBMBgNVHR8ERTBDMEGgP6A9hjtodHRwOi8vY3Js LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDZXJ0aWZpY2F0aW9uQXV0aG9yaXR5LmNybDBxBggr BgEFBQcBAQRlMGMwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9E T1JTQUFkZFRydXN0Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wDQYJKoZIhvcNAQEMBQADggIBAHhcsoEoNE887l9Wzp+XVuyPomsX9vP2SQgG1NgvNc3f QP7TcePo7EIMERoh42awGGsma65u/ITse2hKZHzT0CBxhuhb6txM1n/y78e/4ZOs0j8CGpfb +SJA3GaBQ+394k+z3ZByWPQedXLL1OdK8aRINTsjk/H5Ns77zwbjOKkDamxlpZ4TKSDMKVmU /PUWNMKSTvtlenlxBhh7ETrN543j/Q6qqgCWgWuMAXijnRglp9fyadqGOncjZjaaSOGTTFB+ E2pvOUtY+hPebuPtTbq7vODqzCM6ryEhNhzf+enm0zlpXK7q332nXttNtjv7VFNYG+I31gnM rwfHM5tdhYF/8v5UY5g2xANPECTQdu9vWPoqNSGDt87b3gXb1AiGGaI06vzgkejL580ul+9h z9D0S0U4jkhJiA7EuTecP/CFtR72uYRBcunwwH3fciPjviDDAI9SnC/2aPY8ydehzuZutLbZ dRJ5PDEJM/1tyZR2niOYihZ+FCbtf3D9mB12D4ln9icgc7CwaxpNSCPt8i/GqK2HsOgkL3VY nwtx7cJUmpvVdZ4ognzgXtgtdk3ShrtOS1iAN2ZBXFiRmjVzmehoMof06r1xub+85hFQzVxZ x5/bRaTKTlL8YXLI8nAbR9HWdFqzcOoB/hxfEyIQpx9/s81rgzdEZOofSlZHynoSMYIEODCC BDQCAQEwga0wgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQD EzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENB AhEAhiSk7ZnwaFDrCut2h4/AtjANBglghkgBZQMEAgEFAKCCAlswGAYJKoZIhvcNAQkDMQsG CSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzA5MjAwMTUzWjAvBgkqhkiG9w0BCQQx IgQgRyGPVELI8tNz7aWUIV4mI2mzz6ruIAr1ry2JlP6UUkcwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvgYJKwYBBAGCNxAEMYGw MIGtMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYk pO2Z8GhQ6wrrdoePwLYwgcAGCyqGSIb3DQEJEAILMYGwoIGtMIGXMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAIYkpO2Z8GhQ6wrrdoePwLYwDQYJKoZI hvcNAQEBBQAEggEAvsTMLQKbtPzT96uMGMfsAPw9b/1SlMpt9jpwa2/ghIVlHgniaz90Cddv 1WcKWhdFgiaYzD1+VtzH0DleLtVE4zJVNtGdam4HveZ6FqTb7RWqGPO5AUpHwx00hKAuyv5a 65OU+yM/f59qfRm05BBV+MK9WZDyaidPKv7oddq2MU+2MaoyM70Q943Ip5n7dBDIcWUe3mdC sX57rbZZcClhwuCoR7kWh+5+ps+kOXsz1oA2bBZH3fyqOO0uY01zYMdKwUV5+NgvOx+uoKAa AI1D0V9r2pykHpP8A4AYawzw5Te8bkMenW2gDknq1XQacF8WdGOVE+EJSJBsbcAUQtigWAAA AAAAAA== --------------ms040902090207060909020005-- From nobody Tue Mar 12 17:17:09 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B68131164 for ; Tue, 12 Mar 2019 17:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 vjHkj12FIicB for ; Tue, 12 Mar 2019 17:17:06 -0700 (PDT) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (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 9C542124B19 for ; Tue, 12 Mar 2019 17:17:05 -0700 (PDT) Received: by mail-lf1-f49.google.com with SMTP id 10so113504lfr.8 for ; Tue, 12 Mar 2019 17:17:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uQMgm2HqNE4jskfuBiSoz1VEzoF2ktarYpvcrVSoJ/w=; b=gKr+LxOvI0267GdXfktDRMAgXXkGnDPRy4Yy9FSO6lWqTiwO8Rx8sH21DNIF75S+Uz gEle/N4krmIkKfZtc/2FpMbAp34ptci+r16z4wL/C9CroafaaRLPaC7rF7q/j7KBD+9k 4vbB9ePB8khJUsYX8Sarv02+TkU3VNh0JzL5Cic/RQyW2HTq/8JQfFa13PNn3dOVod/u q5KaXIDyaAks9oJlg0EunZgeRnhPqt4dUqztSUwZaOlX23EkZ4ip2/fd2TDftn3c10IZ 7ek8NACDGcyDi8P39HwXVOPIkNx7UUxEchmP6IckA8E4wIAYP+SFHdyAl6UJo+ck2kIL OFaw== X-Gm-Message-State: APjAAAWjWWI6YsQb3l+smKAl+2eN4/ws64vTshm4lDh+x0yjlmLReYbZ Q1l1yfHHvcZFm7LSQi43Tqve/ukvl8SlzNjg+QmOQANTue8= X-Google-Smtp-Source: APXvYqw2lmyTdRRJbHC60d5chkFyAuPYsn9kkmZwIjpOSg6dmrmbD0vOkmQC0sJ0sjjeYPB/eXUI1pvDjnXy6i5mtFU= X-Received: by 2002:ac2:514a:: with SMTP id q10mr5972935lfd.17.1552436221059; Tue, 12 Mar 2019 17:17:01 -0700 (PDT) MIME-Version: 1.0 References: <87879E7D-A55B-4A88-80B8-B503C89E52CB@iab.org> <20131030081355.GA23990@nic.fr> <7F135C08-A550-450F-82B4-1F239E115BC3@tzi.org> <20131030083611.GA27804@nic.fr> <01P06PWP9XG4004X76@mauve.mrochek.com> <527119E9.5050407@cisco.com> <01P06RD9XM60004X76@mauve.mrochek.com> <4FBA1270FC906838EB82345F@cc0102a-dhcp145.apple.com> In-Reply-To: From: Daniel Migault Date: Tue, 12 Mar 2019 20:16:49 -0400 Message-ID: To: Steve Crocker Cc: IETF-Calsify Content-Type: multipart/alternative; boundary="0000000000007e291c0583eeb938" Archived-At: Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 00:17:08 -0000 --0000000000007e291c0583eeb938 Content-Type: text/plain; charset="UTF-8" Thanks Steve for raising this point. Anyone opposed to add this item to the charter ? At least that would be good to provide guidance and quantification of the propagation so "best effort" becomes more specific. Please provide your thoughts on how we could probably address this on the mailing list. Yours, Daniel On Fri, Mar 8, 2019 at 2:44 PM Steve Crocker wrote: > Bron, et al, > > In response to your note about the charter and direction of the working > group, here's a note I sent more than five(!) years ago that garnered no > response at all. Nonetheless, I think including some sort of expected > propagation time in the specification is -- or least ought to be -- within > scope. > > Steve Crocker > > On Tue, Nov 5, 2013 at 5:38 PM Steve Crocker wrote: > >> I was very pleased to see the work on the Timezone Service Protocol. I >> have no argument about the format of the data elements or actions, but the >> timing model is incomplete. One of the motivations is make sure accurate >> timezone data is distributed in a timely fashion. In order to make good on >> this, we need to say more about the timing. As noted in the anecdote cited >> below, time zone changes are sometimes abrupt. How much notice is required >> in order to make sure time zone changes are guaranteed to be propagated to >> all devices? And on the other end of the system, how frequently do devices >> need to poll or otherwise be notified of changes? >> >> Historically, IETF protocols have tended to be a bit vague about timing >> parameters and it's been left to operational practice. The results are >> frequently messy. We have a chance for this one to be much clearer.. The >> timezone database now maintained by IANA is a pretty solid solution for the >> source of reliable, authoritative information, but there's not been much >> written other than anecdotes about how often the data changes and how much >> lead time is required to distribute the information. >> >> In the present draft, the only wording I could find is at the section >> 4.1.3: >> >> > Clients SHOULD NOT poll for such changes too frequently, typically once >> a day ought to be sufficient. See Section 8 on expected client and server >> behavior regarding high request rates. >> >> and the cautions in Section 8. >> >> I don't have an axe to grind regarding the design of the protocol, but I >> will note that if the timezone data were published via DNS, both the >> throttling problem and the model of propagation time would be dealt with >> automatically. In any case, even if there's no desire to distribute this >> data over DNS, I do believe we need to provide much stronger statements >> about the expected time to propagate changes and to be clearer about how >> the design implements such statements. >> >> Steve >> >> >> >> >> On Oct 30, 2013, at 11:23 AM, Cyrus Daboo > > wrote: >> >> > Hi ned+ietf@mauve.mrochek.com, >> > >> > --On October 30, 2013 at 7:52:55 AM -0700 ned+ietf@mauve.mrochek.com >> wrote: >> > >> >>>> Which argues for including the local time when the event will take >> >>>> place. If you want to mandate that the time also appear in UTC, >> great, >> >>>> but it's quite important that the local time also be there. >> >> >> >>> And local time should be normative to deal with such unforeseen >> >>> circumstances as a papal visit. From the southamerica file in the TZ >> >>> database: >> >> >> >>> # From Daniel C. Sobral (1998-02-12): >> >>> # In 1997, the DS began on October 6. The stated reason was that >> >>> # because international television networks ignored Brazil's policy on >> >>> # DS, they bought the wrong times on satellite for coverage of Pope's >> >>> # visit. This year, the ending date of DS was postponed to March 1 >> >>> # to help dealing with the shortages of electric power. >> >> >> >>> ;-) >> >> >> >> Good point. I agree. >> > >> > Timezones can (and do) change at very short notice in different parts >> of the world. Typically computer systems have timezone data cached as part >> of the OS, and only get updates when the OS is itself updated - often long >> after a timezone change has occurred or long after future events were >> booked but are now out of sync for participants in different timezones. To >> address that a number of folks in the calendaring and scheduling community >> have been working om a timezone service protocol - < >> https://datatracker.ietf.org/doc/draft-douglass-timezone-service/> - our >> initial focus for that has been iCalendar (RFC5545) based VTIMEZONE >> component delivery to calendar and scheduling clients and servers. However, >> we would like to also deliver OS-style timezone data to devices to break >> out of the requirement for those to be updated only when the OS itself >> updates. For unix-based OS's that means being able to deliver "raw" >> zoneinfo" data over that protocol. >> > >> > Anyway, if you are interested in that work please comment over on the >> ietf-calsify list (cc'd) - we (the authors of that draft) - intend to get >> it moving to last call soon. There are already several implementations that >> have undergone testing at the Calendaring and Scheduling Consortium >> (CalConnect) interop events, so we are happy with it, but would appreciate >> more feedback. >> > >> > -- >> > Cyrus Daboo >> > >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --0000000000007e291c0583eeb938 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Steve for raising this point. Anyone opposed to add= this item to the charter ? At least that would be good to provide guidance= and quantification of the propagation so "best effort" becomes m= ore specific. Please provide your thoughts on how we could probably address= this on the mailing list.

Yours,=C2=A0
Daniel<= /div>

On Fri, Mar 8, 2019 at 2:44 PM Steve Crocker <steve@shinkuro.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
Bron, et al,

In response to your note about the= charter and direction of the working group, here's a note I sent more = than five(!) years ago that garnered no response at all.=C2=A0 Nonetheless,= I think including some sort of expected propagation time in the specificat= ion is -- or least ought to be -- within scope.

St= eve Crocker

On Tue, Nov 5, 2013 at 5:38 PM Steve Crocker <Steve@shinkuro.com>= wrote:
I was ve= ry pleased to see the work on the Timezone Service Protocol.=C2=A0 I have n= o argument about the format of the data elements or actions, but the timing= model is incomplete.=C2=A0 One of the motivations is make sure accurate ti= mezone data is distributed in a timely fashion.=C2=A0 In order to make good= on this, we need to say more about the timing.=C2=A0 As noted in the anecd= ote cited below, time zone changes are sometimes abrupt.=C2=A0 How much not= ice is required in order to make sure time zone changes are guaranteed to b= e propagated to all devices?=C2=A0 And on the other end of the system, how = frequently do devices need to poll or otherwise be notified of changes?

Historically, IETF protocols have tended to be a bit vague about timing par= ameters and it's been left to operational practice.=C2=A0 The results a= re frequently messy.=C2=A0 We have a chance for this one to be much clearer= ..=C2=A0 The timezone database now maintained by IANA is a pretty solid sol= ution for the source of reliable, authoritative information, but there'= s not been much written other than anecdotes about how often the data chang= es and how much lead time is required to distribute the information.

In the present draft, the only wording I could find is at the section 4.1.3= :

> Clients SHOULD NOT poll for such changes too frequently, typically onc= e a day ought to be sufficient.=C2=A0 See Section 8 on expected client and = server behavior regarding high request rates.

and the cautions in Section 8.

I don't have an axe to grind regarding the design of the protocol, but = I will note that if the timezone data were published via DNS, both the thro= ttling problem and the model of propagation time would be dealt with automa= tically.=C2=A0 In any case, even if there's no desire to distribute thi= s data over DNS, I do believe we need to provide much stronger statements a= bout the expected time to propagate changes and to be clearer about how the= design implements such statements.

Steve




On Oct 30, 2013, at 11:23 AM, Cyrus Daboo <cyrus@daboo.name> wrote:

> Hi n= ed+ietf@mauve.mrochek.com,
>
> --On October 30, 2013 at 7:52:55 AM -0700 ned+ietf@mauve.mrochek.com wrote:=
>
>>>> Which argues for including the local time when the event w= ill take
>>>> place. If you want to mandate that the time also appear in= UTC, great,
>>>> but it's quite important that the local time also be t= here.
>>
>>> And local time should be normative to deal with such unforesee= n
>>> circumstances as a papal visit.=C2=A0 From the southamerica fi= le in the TZ
>>> database:
>>
>>> # From Daniel C. Sobral (1998-02-12):
>>> # In 1997, the DS began on October 6. The stated reason was th= at
>>> # because international television networks ignored Brazil'= ;s policy on
>>> # DS, they bought the wrong times on satellite for coverage of= Pope's
>>> # visit. This year, the ending date of DS was postponed to Mar= ch 1
>>> # to help dealing with the shortages of electric power.
>>
>>> ;-)
>>
>> Good point. I agree.
>
> Timezones can (and do) change at very short notice in different parts = of the world. Typically computer systems have timezone data cached as part = of the OS, and only get updates when the OS is itself updated - often long = after a timezone change has occurred or long after future events were booke= d but are now out of sync for participants in different timezones. To addre= ss that a number of folks in the calendaring and scheduling community have = been working om a timezone service protocol - <https://datatracker.ietf.org/doc/draft-douglass-timezone-ser= vice/> - our initial focus for that has been iCalendar (RFC5545) bas= ed VTIMEZONE component delivery to calendar and scheduling clients and serv= ers. However, we would like to also deliver OS-style timezone data to devic= es to break out of the requirement for those to be updated only when the OS= itself updates. For unix-based OS's that means being able to deliver &= quot;raw" zoneinfo" data over that protocol.
>
> Anyway, if you are interested in that work please comment over on the = ietf-calsify list (cc'd) - we (the authors of that draft) - intend to g= et it moving to last call soon. There are already several implementations t= hat have undergone testing at the Calendaring and Scheduling Consortium (Ca= lConnect) interop events, so we are happy with it, but would appreciate mor= e feedback.
>
> --
> Cyrus Daboo
>

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--0000000000007e291c0583eeb938-- From nobody Tue Mar 12 21:45:42 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC7412D826 for ; Tue, 12 Mar 2019 21:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.982 X-Spam-Level: X-Spam-Status: No, score=-1.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HEADER_CTYPE_ONLY=0.717, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=BG/BM1ba; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3H+Z6hZz 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 aoIde_Ups4l7 for ; Tue, 12 Mar 2019 21:45:37 -0700 (PDT) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 846FA12AF80 for ; Tue, 12 Mar 2019 21:45:37 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 4EBC517A4B for ; Wed, 13 Mar 2019 00:45:34 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 13 Mar 2019 00:45:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=message-id:in-reply-to:references:date:from :to:subject:content-type; s=fm2; bh=h5QaxZPBy2wS2oJvqEi3rdcZp5YX 2zxzHAwl3eVVPNY=; b=BG/BM1baDC39J1DN8eel9TOqnTjvi9yQuIlcL/bHGdJb Su9S7kXaE8cUh3qmJuAA9da3FRRKgrnzxhy37XxwIlX2D6rNXm3eJMGLFAdXSLZz 96SEenFwwoFx7AemWQcbM7vUdlZML5/kf87swI4cLpjXDOp1ZvhDRPyYt36xU1sA 7DsKjfEez3vZpoi8QLo9lduLO/GT6iHPYKp+CvBTe9SybmjmfyxX1U4JvWRcqJSm lCx4rpmEkka4x3qVEmHmN+AB0I/9mP0/zPUvC3kRIEVSBDRKwbWo5duXGx/OmgaS 1KNFfKvNRY7J5yaQzFpeLkXzlFls9AUkZpw+zGsKcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=h5QaxZPBy2wS2oJvq Ei3rdcZp5YX2zxzHAwl3eVVPNY=; b=3H+Z6hZzzEwj6kKvf0rqtvw0PE8FWmdkV fGMl0yKAR3nffGUqKqSAzxUNGY/KvOsB74I3Ri0dYdyhRJxSxi2YDd9SByxIOAOw XgwrYzGYvlmxHTkWcoNv/yn6sG89TB9htSmjjf2PvlRuUvC9HXW8PurhUeJQtYp3 UlJMR6rXLBuWBldX6LQE4tk2xfauIGmOlM5dOpu4hAHfsnePX+XJzmWZV2TSLfgd 4XaFjSTZ2KY9mF6n/IBag7VvvN3GBBp5MpdHYOAjx+8jtr7D3w8MluTZRK4Jvdau /iFaLQmjZjbqOaIKlhNMO4W8cyR6ClXEmCaVFxB4vCYnGqzW2mKHA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrgeelgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfthfevqddqufhushhpvggtthfgmhgrihhlohhrkf guqdffohhmrghinhculddutddtmdenucfjughrpefofgfkjghffffhvffutgesrgdtreer reertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrg hsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfr rghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AA28D2058C; Wed, 13 Mar 2019 00:45:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-925-g644bf8c-fmstable-20190228v5 X-Me-Personality: 56629417 Message-Id: <18c99085-7ab6-4df7-bab8-9b16520f216f@beta.fastmail.com> In-Reply-To: References: <87879E7D-A55B-4A88-80B8-B503C89E52CB@iab.org> <20131030081355.GA23990@nic.fr> <7F135C08-A550-450F-82B4-1F239E115BC3@tzi.org> <20131030083611.GA27804@nic.fr> <01P06PWP9XG4004X76@mauve.mrochek.com> <527119E9.5050407@cisco.com> <01P06RD9XM60004X76@mauve.mrochek.com> <4FBA1270FC906838EB82345F@cc0102a-dhcp145.apple.com> Date: Wed, 13 Mar 2019 00:45:33 -0400 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=758110d7e8d04cb7a83d4878f1b1a673 Archived-At: Subject: Re: [calsify] Timezone Service Protocol not quite complete X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2019 04:45:40 -0000 --758110d7e8d04cb7a83d4878f1b1a673 Content-Type: text/plain Thanks Daniel - and thanks Steve for bringing this up. It was pinned for me to reply to, but I've been moving house over the last week, so not dealing with things quickly! Shooting from the hip (I actually spent a while thinking about this while I was unpacking boxes) I would put a minimum bound of "once per day" and a maximum bound of "once per month" on how often devices should check for changes, with a sensible idea being something like: "once per week, on Friday". Anyways, I certainly support adding this to the charter and talking about it in a more structured way rather than me guessing stuff. Bron. On Wed, Mar 13, 2019, at 11:17, Daniel Migault wrote: > Thanks Steve for raising this point. Anyone opposed to add this item to the charter ? At least that would be good to provide guidance and quantification of the propagation so "best effort" becomes more specific. Please provide your thoughts on how we could probably address this on the mailing list. > > Yours, > Daniel > > On Fri, Mar 8, 2019 at 2:44 PM Steve Crocker wrote: >> Bron, et al, >> >> In response to your note about the charter and direction of the working group, here's a note I sent more than five(!) years ago that garnered no response at all. Nonetheless, I think including some sort of expected propagation time in the specification is -- or least ought to be -- within scope. >> >> Steve Crocker >> >> On Tue, Nov 5, 2013 at 5:38 PM Steve Crocker wrote: >>> I was very pleased to see the work on the Timezone Service Protocol. I have no argument about the format of the data elements or actions, but the timing model is incomplete. One of the motivations is make sure accurate timezone data is distributed in a timely fashion. In order to make good on this, we need to say more about the timing. As noted in the anecdote cited below, time zone changes are sometimes abrupt. How much notice is required in order to make sure time zone changes are guaranteed to be propagated to all devices? And on the other end of the system, how frequently do devices need to poll or otherwise be notified of changes? >>> >>> Historically, IETF protocols have tended to be a bit vague about timing parameters and it's been left to operational practice. The results are frequently messy. We have a chance for this one to be much clearer... The timezone database now maintained by IANA is a pretty solid solution for the source of reliable, authoritative information, but there's not been much written other than anecdotes about how often the data changes and how much lead time is required to distribute the information. >>> >>> In the present draft, the only wording I could find is at the section 4.1.3: >>> >>> > Clients SHOULD NOT poll for such changes too frequently, typically once a day ought to be sufficient. See Section 8 on expected client and server behavior regarding high request rates. >>> >>> and the cautions in Section 8. >>> >>> I don't have an axe to grind regarding the design of the protocol, but I will note that if the timezone data were published via DNS, both the throttling problem and the model of propagation time would be dealt with automatically. In any case, even if there's no desire to distribute this data over DNS, I do believe we need to provide much stronger statements about the expected time to propagate changes and to be clearer about how the design implements such statements. >>> >>> Steve >>> >>> >>> >>> >>> On Oct 30, 2013, at 11:23 AM, Cyrus Daboo > wrote: >>> >>> > Hi ned+ietf@mauve.mrochek.com , >>> > >>> > --On October 30, 2013 at 7:52:55 AM -0700 ned+ietf@mauve.mrochek.com wrote: >>> > >>> >>>> Which argues for including the local time when the event will take >>> >>>> place. If you want to mandate that the time also appear in UTC, great, >>> >>>> but it's quite important that the local time also be there. >>> >> >>> >>> And local time should be normative to deal with such unforeseen >>> >>> circumstances as a papal visit. From the southamerica file in the TZ >>> >>> database: >>> >> >>> >>> # From Daniel C. Sobral (1998-02-12): >>> >>> # In 1997, the DS began on October 6. The stated reason was that >>> >>> # because international television networks ignored Brazil's policy on >>> >>> # DS, they bought the wrong times on satellite for coverage of Pope's >>> >>> # visit. This year, the ending date of DS was postponed to March 1 >>> >>> # to help dealing with the shortages of electric power. >>> >> >>> >>> ;-) >>> >> >>> >> Good point. I agree. >>> > >>> > Timezones can (and do) change at very short notice in different parts of the world. Typically computer systems have timezone data cached as part of the OS, and only get updates when the OS is itself updated - often long after a timezone change has occurred or long after future events were booked but are now out of sync for participants in different timezones. To address that a number of folks in the calendaring and scheduling community have been working om a timezone service protocol - - our initial focus for that has been iCalendar (RFC5545) based VTIMEZONE component delivery to calendar and scheduling clients and servers. However, we would like to also deliver OS-style timezone data to devices to break out of the requirement for those to be updated only when the OS itself updates. For unix-based OS's that means being able to deliver "raw" zoneinfo" data over that protocol. >>> > >>> > Anyway, if you are interested in that work please comment over on the ietf-calsify list (cc'd) - we (the authors of that draft) - intend to get it moving to last call soon. There are already several implementations that have undergone testing at the Calendaring and Scheduling Consortium (CalConnect) interop events, so we are happy with it, but would appreciate more feedback. >>> > >>> > -- >>> > Cyrus Daboo >>> > >>> >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --758110d7e8d04cb7a83d4878f1b1a673 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks Daniel - and thanks Steve for bringing this up.&nbs= p; It was pinned for me to reply to, but I've been moving house over the= last week, so not dealing with things quickly!

Shooting = from the hip (I actually spent a while thinking about this while I was u= npacking boxes) I would put a minimum bound of "once per day" and a maxi= mum bound of "once per month" on how often devices should check for chan= ges, with a sensible idea being something like: "once per week, on Frida= y".

Anyways, I certainly support adding this to the chart= er and talking about it in a more structured way rather than me guessing= stuff.

Bron.
On Wed, Mar 13, 2019, at 11:17= , Daniel Migault wrote:
Thanks Stev= e for raising this point. Anyone opposed to add this item to the charter= ? At least that would be good to provide guidance and quantification of= the propagation so "best effort" becomes more specific. Please provide = your thoughts on how we could probably address this on the mailing list.=

You= rs, 
Daniel

On Fri, Mar 8, 20= 19 at 2:44 PM Steve Crocker <st= eve@shinkuro.com> wrote:
<= div dir=3D"ltr">
Bron, et al,
=

In response to your note about the charter and direc= tion of the working group, here's a note I sent more than five(!) years = ago that garnered no response at all.  Nonetheless, I think includi= ng some sort of expected propagation time in the specification is -- or = least ought to be -- within scope.

Steve Cr= ocker

On Tue, Nov 5, 2013 at 5:38 PM Steve Crocker <Steve@shinkuro.com> wrote:
I was very pleased to= see the work on the Timezone Service Protocol.  I have no argument= about the format of the data elements or actions, but the timing model = is incomplete.  One of the motivations is make sure accurate timezo= ne data is distributed in a timely fashion.  In order to make good = on this, we need to say more about the timing.  As noted in the ane= cdote cited below, time zone changes are sometimes abrupt.  How muc= h notice is required in order to make sure time zone changes are guarant= eed to be propagated to all devices?  And on the other end of the s= ystem, how frequently do devices need to poll or otherwise be notified o= f changes?

Historically, IETF protocols have tended to = be a bit vague about timing parameters and it's been left to operational= practice.  The results are frequently messy.  We have a chanc= e for this one to be much clearer...  The timezone database now mai= ntained by IANA is a pretty solid solution for the source of reliable, a= uthoritative information, but there's not been much written other than a= necdotes about how often the data changes and how much lead time is requ= ired to distribute the information.

In the present draf= t, the only wording I could find is at the section 4.1.3:

> Clients SHOULD NOT poll for such changes too frequently, typical= ly once a day ought to be sufficient.  See Section 8 on expected cl= ient and server behavior regarding high request rates.

= and the cautions in Section 8.

I don't have an axe to g= rind regarding the design of the protocol, but I will note that if the t= imezone data were published via DNS, both the throttling problem and the= model of propagation time would be dealt with automatically.  In a= ny case, even if there's no desire to distribute this data over DNS, I d= o believe we need to provide much stronger statements about the expected= time to propagate changes and to be clearer about how the design implem= ents such statements.

Steve


=


On Oct 30, 2013, at= 11:23 AM, Cyrus Daboo <cyrus@d= aboo.name> wrote:
>
> --On October 30, 2013 at 7:52:55 AM -0700 ned+ietf@mauve.mrochek.com wrote:
=
>
>>>> Which argues for including the local= time when the event will take
>>>> place. If you want to mandate that the time also app= ear in UTC, great,
>>&= gt;> but it's quite important that the local time also be there.
<= /div>
>>
>>> And local time should be normative to= deal with such unforeseen
&= gt;>> circumstances as a papal visit.  From the southamerica = file in the TZ
>>> = database:
>>
>>> # From Daniel C. Sobral= (1998-02-12):
>>> = # In 1997, the DS began on October 6. The stated reason was that
>>> # because internationa= l television networks ignored Brazil's policy on
>>> # DS, they bought the wrong times on s= atellite for coverage of Pope's
>>> # visit. This year, the ending date of DS was postponed= to March 1
>>> # t= o help dealing with the shortages of electric power.
>>
>>> ;-)
>= >
>> Good point. I= agree.
>
> Timezones can (and do) change at very= short notice in different parts of the world. Typically computer system= s have timezone data cached as part of the OS, and only get updates when= the OS is itself updated - often long after a timezone change has occur= red or long after future events were booked but are now out of sync for = participants in different timezones. To address that a number of folks i= n the calendaring and scheduling community have been working om a timezo= ne service protocol - <https://datatracker.i= etf.org/doc/draft-douglass-timezone-service/> - our initial focus= for that has been iCalendar (RFC5545) based VTIMEZONE component deliver= y to calendar and scheduling clients and servers. However, we would like= to also deliver OS-style timezone data to devices to break out of the r= equirement for those to be updated only when the OS itself updates. For = unix-based OS's that means being able to deliver "raw" zoneinfo" data ov= er that protocol.
>
<= /div>
> Anyway, if you are interest= ed in that work please comment over on the ietf-calsify list (cc'd) - we= (the authors of that draft) - intend to get it moving to last call soon= . There are already several implementations that have undergone testing = at the Calendaring and Scheduling Consortium (CalConnect) interop events= , so we are happy with it, but would appreciate more feedback.
=
>
> --
> C= yrus Daboo
>

_______________________________________________
calsify mailing list
_____________________________________________= __
_______________________________________________
calsify mailing list
calsify@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/calsify


--
 = Bron Gondwana, CEO, FastMail Pty Ltd
=   brong@fastmailteam.com


--758110d7e8d04cb7a83d4878f1b1a673-- From nobody Sat Mar 23 03:29:57 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC55127AC2 for ; Sat, 23 Mar 2019 03:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=R4wLK1ar; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nyOxZISE 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 tjtNcLKBcHDD for ; Sat, 23 Mar 2019 03:29:53 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F3312D4F2 for ; Sat, 23 Mar 2019 03:29:53 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 529B238A7; Sat, 23 Mar 2019 06:29:52 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sat, 23 Mar 2019 06:29:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=MJIqj79 EJftbzueZeREtI+SxfRXeWe0eQe27FlLm8nQ=; b=R4wLK1artqriQ0a9p4Xb7+m 7nDdi72+IMu2SZ8XIwF/vRIUCq2MntpBj1YQJ8DhD3eCEK2InZbzIcJ75de9eJdH OmJXYtLvHKcpH0qEvIF0yAobx/bI3j8h9GpA3pE5NyU5+hh/Al61Doj9uPJ/PRi7 8PgYkXHaKZY0aUAR69/t0xtyx6a8OMx+7+DCBuZdVKCd+viXqeP2DeKR0gKPDE2L loVKjPlwcnJSc1RCgkq8gZAh/yF3zxOmPDYvmv0VDvPWmE2uCHKXChOdq6GfHmwc WFvgZOf3caLob0y3omkWaqAuzPUmw6CJPcqGSFMmynN4SaCh697HWOlNN08WkQQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=MJIqj7 9EJftbzueZeREtI+SxfRXeWe0eQe27FlLm8nQ=; b=nyOxZISEM/wr6bYY2uC6Wr 3X/eBRAK4Xo5+MInnP7q471tWS5AnDPcp1QlxHZQirWFa8LkBowLfAjd5hA9albd xBF9MEn8snA5kz2ntL6QlXTVoxHdBPI5qezag0XHFX4+5kis627U4sxqyaT1qW74 Yi1/E+KbFm6hP9C4BGTZ0TbnVjLbV0KVAO5VXdyc7z9mrHSqo+7JV3Mo04OSQQk0 Y95jloNc6cnYJmiL4oMUlipYLcnwGjQRCJPWEkZhqGkJcksi4LtaYTeGrqpEPSJB p5Vj7YSPztGRjZWp6kRcQyFFsHkq/XDHiUan3Ljm9Fx3SDvnl5tN085OWHTLXiGg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrjeefgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghenuc frrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgt ohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7258620617; Sat, 23 Mar 2019 06:29:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-976-g376b1f3-fmstable-20190314v3 Mime-Version: 1.0 X-Me-Personality: 56629417 Message-Id: <45d24d8d-0f39-41f4-bd43-1966d2e36892@www.fastmail.com> In-Reply-To: References: Date: Sat, 23 Mar 2019 06:29:47 -0400 From: "Bron Gondwana" To: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_=D0=9F=D0=B0=D0=BB=D0=B0=D1=83?= =?UTF-8?Q?=D0=B7=D0=BE=D0=B2?= , calsify Content-Type: multipart/alternative; boundary=c217ab4885134138950d534c3765efd7 Archived-At: Subject: Re: [calsify] draft-gondwana-caldav-scheduling-controls X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 10:29:55 -0000 --c217ab4885134138950d534c3765efd7 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat, Mar 9, 2019, at 06:00, =D0=94=D0=B8=D0=BB=D1=8F=D0=BD =D0=9F=D0=B0= =D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote: > Hello Bron, >=20 > irrespective of the WG-addoptation, CALDAV:calendar-user-address-set (= https://tools.ietf.org/html/rfc6638#section-2.4.1) > defines per principal all the aliases a user has, so the server does n= ot have to guess anything. >=20 > When the Schedule-User-Address header is skipped, your draft says, tha= t the CALDAV:schedule-user-address property on a > calendar or user/principal shall be used. The draft references only RF= C6638 =E2=80=9CScheduling Extensions to CalDAV=E2=80=9D and the > latter does not say anything about CALDAV:schedule-user-address. Where= is CALDAV:schedule-user-address defined? >=20 > Are CALDAV:schedule-user-address and CALDAV:calendar-user-address-set = supposed to mean the same? Yes - I expect that was an early mistake that I just didn't notice. Oops= . I'll fix that up in the next one. > In any case, it would be good to be able to specify several addresses = in the Schedule-User-Address header: an invitation > having Organizer and Attendee, where the same person is both the organ= izer and the attendee, but uses different > addresses for both, is supposed not to trigger any scheduling to the s= ame person. This assumes that the system can > match the addresses as Attendee and Organizer belonging to the same pe= rson and both addresses could arrive as headers. The server will always have you acting as a particular user when you're = updating the record - but yeah, to avoid scheduling to multiple addresse= s makes sense. This will also be something interesting to discuss in JMA= P calendars. Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --c217ab4885134138950d534c3765efd7 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Sat, Mar 9, 2019, at 06:00, =D0=94=D0=B8=D0=BB=D1=8F= =D0=BD =D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2 wrote:
=
Hello Bron,

irrespective of the WG-addoptation= , CALDAV:calendar-user-address-set (https://tools.ietf.org/html/rfc6638#= section-2.4.1)
defines per pr= incipal all the aliases a user has, so the server does not have to guess= anything.

When the Schedule-User-Address header is skipp= ed, your draft says, that the CALDAV:schedule-user-address property on a=
calendar or user/principal s= hall be used.  The draft references only RFC6638 =E2=80=9CSchedulin= g Extensions to CalDAV=E2=80=9D and the
latter does not say anything about CALDAV:schedule-user-addre= ss.  Where is CALDAV:schedule-user-address defined?

= Are CALDAV:schedule-user-address and CALDAV:calendar-user-address-set su= pposed to mean the same?

Yes - I expect that= was an early mistake that I just didn't notice.  Oops.  I'll = fix that up in the next one.
=
In any case, it would be good to be able to specify= several addresses in the Schedule-User-Address header: an invitation
having Organizer and Attendee, = where the same person is both the organizer and the attendee, but uses d= ifferent
addresses for both, = is supposed not to trigger any scheduling to the same person.  This= assumes that the system can
= match the addresses as Attendee and Organizer belonging to the same pers= on and both addresses could arrive as headers.

The server will always have you acting as a particular user when you'= re updating the record - but yeah, to avoid scheduling to multiple addre= sses makes sense.  This will also be something interesting to discu= ss in JMAP calendars.

Bron.

--
  Bron Gondwana, CEO, FastMai= l Pty Ltd
  brong@fastmailteam.co= m


--c217ab4885134138950d534c3765efd7-- From nobody Sat Mar 23 07:32:12 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAF61279AB for ; Sat, 23 Mar 2019 07:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=LO8oDdta; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Mg/tnwUl 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 dgpKDr9qUX48 for ; Sat, 23 Mar 2019 07:32:08 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B15127964 for ; Sat, 23 Mar 2019 07:32:08 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id C5CCF3715 for ; Sat, 23 Mar 2019 10:32:07 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Sat, 23 Mar 2019 10:32:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=DvrFkTUsSTpQR1tKS5XHxiJdE5T0uivKHmfLrly C0LE=; b=LO8oDdtaGs5R2rgPd4CNIoQtyyUQsRMsFTZ7iycl+g36v4xygvoqEp0 E7QCNW3uk6T3fNPslOBVC3Mr2lT0Ams2YDI9RGEsaUSwXIECzh/AqKuMhegn9CUw IQXakUoa7ifS7bgF69Xf7foUeFSk8HqatM30G604Y3MHRbAR0DiQ3tYMcfLgUyXu 9dtELdY1DwtkQtAqBcfU8DvzaYka3YJ5Xp34cNQjOhEBq1UO6VrxJ2yGgLYSjTqa 3nwzWvGMB4Xb5D3iiDOzx2m2LHNZCE28Rxknp0WPx/guPZWmOurGfk7iwBmehxkH 3FojQW+fypHgE4+zpvS67UOczfG/lDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=DvrFkTUsSTpQR1tKS5XHxiJdE5T0u ivKHmfLrlyC0LE=; b=Mg/tnwUlqA9AzhWrrvikw0dM+PUY99sAE+1ljcVoVp+uf JqgVKHqsuPFybqEjWNtjDWkpnfSNAoMtGkX8fC9dAzlKfRiWhbDqQ6Nz1wovfxqB R7h2ZiesaQ9gOfD8dKMBA5XivRQBrOAWoasYEpSQmAQyO31t8PLfEI4w06jLPwv+ BmjGx/vh+QIdobReznSWolj/DcMS31PQn2ikqXS9keCTHRWFqVFGFE21RT1e9WAk JnNgGbAld6V/m3Mn4cdwl3jGxD7uenfb6yJwgCixGlTmTWkSWEuRaRx0lcmJQlnp hf/qgn+bXT8ROxPopE7vRxVl6kcceGK28eIP+a5pg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrjeefgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpih gvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 12C1C20617; Sat, 23 Mar 2019 10:32:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.5-976-g376b1f3-fmstable-20190314v3 Mime-Version: 1.0 X-Me-Personality: 56629417 Message-Id: <2805845a-0613-4f01-96fe-25baca76d670@www.fastmail.com> Date: Sat, 23 Mar 2019 10:32:06 -0400 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=9062f5bc741f443484f9822b79c964ba Archived-At: Subject: [calsify] Prague session agenda uploaded X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 14:32:10 -0000 --9062f5bc741f443484f9822b79c964ba Content-Type: text/plain Hi all, I've just uploaded an agenda for our session on Monday here: https://datatracker.ietf.org/meeting/104/materials/agenda-104-calext-00 Here's some useful reading material before the meeting: In publication queue drafts: https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-attachments/?include_text=1 https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/?include_text=1 Active drafts: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/?include_text=1 Proposed new documents: https://datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/?include_text=1 https://datatracker.ietf.org/doc/draft-daboo-valarm-extensions/?include_text=1 https://datatracker.ietf.org/doc/draft-stepanek-jscontact/?include_text=1 CalConnect items: https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/subscription-upgrade ( or https://www.ietf.org/archive/id/draft-douglass-subscription-upgrade-03.txt ) https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/vpoll ( or https://www.ietf.org/archive/id/draft-york-vpoll-04.txt ) https://www.ietf.org/archive/id/draft-pot-caldav-sharing-01.txt (unsure if source code still exists!) Charter draft: https://datatracker.ietf.org/meeting/104/materials/slides-104-calext-calext-charter-00 Cheers, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --9062f5bc741f443484f9822b79c964ba Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi all,
I've just uploaded an agenda f= or our session on Monday here:

<= div style=3D"font-family:Arial;">
Here's some useful reading material before the meeting:

In publication queue drafts:


Active drafts= :


Proposed= new documents:

https://= datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/?incl= ude_text=3D1

CalConnect items:




--
  Bron Gondwana, CEO, FastMai= l Pty Ltd
  brong@fastmailteam.co= m


--9062f5bc741f443484f9822b79c964ba-- From nobody Mon Mar 25 01:17:28 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593FB1203F2 for ; Mon, 25 Mar 2019 01:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 z0TWdZXbmFbl for ; Mon, 25 Mar 2019 01:17:24 -0700 (PDT) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com [209.85.167.42]) (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 C7DF01203C6 for ; Mon, 25 Mar 2019 01:17:22 -0700 (PDT) Received: by mail-lf1-f42.google.com with SMTP id 10so5315559lfr.8 for ; Mon, 25 Mar 2019 01:17:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ezKIa9/37n82ZXliLa0F7wfK9tgyNhQl7f/8mTI/XSE=; b=H19yIPsSiZr2gKpx5REn4Cw3KxS9PEpoxfnb4o65xkpOvCZicdEqP1L8WCRz2k20ji bwFfAYSest/sXfcwP+4G2OL09/KeEumZzy1C0132DIm2Wn8GWwtGf9+GFET5QmRRALkV qrbOw7pcVa5A5VhC4JgHxLwwxadSsxdr54Hzc8IBCpquwr0GoS0G90RT7vmuiAmxiz8l r74BMxpvSr5rBCrVAqIeT09jOCwcqgtJc/UhlN+L1PRCl7tTg8gdDENNLD/wFO/IIYvN IPRmuCCPMkc6y57K0X43hXsTZuge28pUvJ3LwqqafQ4OBFxutqR2Pb8HtDsfWg22hN2w mAYA== X-Gm-Message-State: APjAAAWekaF/Hp4aYm1GkUguDjyKK8Z/6o3HjU2gKwbk1nRRlUyURV7u MjFPT2TE8tC+ZwBiegnipwYzNSd8FXW3C0fzwAHpnHfN X-Google-Smtp-Source: APXvYqyXV4A6Nv1ZJwOP0eLivL9uw5UambrFoj2D3a38pbkX10oJ8GxgOxmRbnj1gKUlC3jIOtRspCZkkHVyqyC74RY= X-Received: by 2002:a19:2789:: with SMTP id n131mr11452787lfn.142.1553501837770; Mon, 25 Mar 2019 01:17:17 -0700 (PDT) MIME-Version: 1.0 References: <2805845a-0613-4f01-96fe-25baca76d670@www.fastmail.com> In-Reply-To: <2805845a-0613-4f01-96fe-25baca76d670@www.fastmail.com> From: Daniel Migault Date: Mon, 25 Mar 2019 04:17:05 -0400 Message-ID: To: Bron Gondwana Cc: IETF-Calsify Content-Type: multipart/alternative; boundary="00000000000032c5970584e6d59e" Archived-At: Subject: Re: [calsify] Prague session agenda uploaded X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 08:17:26 -0000 --00000000000032c5970584e6d59e Content-Type: text/plain; charset="UTF-8" We are looking for minute takers and jabber scribes. Please raise your hand! Yours, Bron and Daniel On Sat, Mar 23, 2019 at 10:32 AM Bron Gondwana wrote: > Hi all, > > I've just uploaded an agenda for our session on Monday here: > > https://datatracker.ietf.org/meeting/104/materials/agenda-104-calext-00 > > Here's some useful reading material before the meeting: > > In publication queue drafts: > > > https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-attachments/?include_text=1 > > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/?include_text=1 > > Active drafts: > > > https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/?include_text=1 > > Proposed new documents: > > > https://datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/?include_text=1 > > https://datatracker.ietf.org/doc/draft-daboo-valarm-extensions/?include_text=1 > https://datatracker.ietf.org/doc/draft-stepanek-jscontact/?include_text=1 > > CalConnect items: > > > https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/subscription-upgrade > ( or > https://www.ietf.org/archive/id/draft-douglass-subscription-upgrade-03.txt > ) > https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/vpoll > ( or https://www.ietf.org/archive/id/draft-york-vpoll-04.txt ) > > https://www.ietf.org/archive/id/draft-pot-caldav-sharing-01.txt (unsure > if source code still exists!) > > Charter draft: > > > https://datatracker.ietf.org/meeting/104/materials/slides-104-calext-calext-charter-00 > > > Cheers, > > Bron. > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --00000000000032c5970584e6d59e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We are looking for minute takers and jabber scribes. Pleas= e raise your hand!
Yours,=C2=A0
Bron and Daniel
On Sat, = Mar 23, 2019 at 10:32 AM Bron Gondwana <brong@fastmailteam.com> wrote:
Hi all,

I've just uploaded an agenda for our session on = Monday here:


Here's som= e useful reading material before the meeting:

In publication queu= e drafts:


Active drafts:


Proposed new documents:
=


CalConnect items:



Charter draft:



Cheers,

Bron.

--
=C2=A0 Bron Gondwan= a, CEO, FastMail Pty Ltd
=C2=A0 brong@fastmailteam.com


_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--00000000000032c5970584e6d59e-- From nobody Mon Mar 25 06:29:07 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A111203E7; Mon, 25 Mar 2019 06:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 1ipBtWkZHMET; Mon, 25 Mar 2019 06:29:02 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820085.outbound.protection.outlook.com [40.107.82.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87EF8120381; Mon, 25 Mar 2019 06:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m7/0yUxv67WJ3C1l91Tl1mPn6aIn6P6pkVbkm6jPsgA=; b=MOUBOd90Y2syvZqnlYVc68dbXLFCtqnoHlcOaCOnlzbpESmBAFiHeP9UqdXXr5CDSxRDgAijbi6omvC1B7DZDj2ftViXg816US1tzmDjK8IhrSxgOyikw259HkUxID2yKLtT5qoE+B12yNOeds68RF60bbRJQfWrgXUDypmXSJ8= Received: from MN2PR15MB3310.namprd15.prod.outlook.com (20.179.21.142) by MN2PR15MB3343.namprd15.prod.outlook.com (20.179.20.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Mon, 25 Mar 2019 13:29:00 +0000 Received: from MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::7da8:cba6:329d:1206]) by MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::7da8:cba6:329d:1206%4]) with mapi id 15.20.1730.019; Mon, 25 Mar 2019 13:28:59 +0000 From: Daniel Migault To: Calsify CC: Jim Fenton , "calext-chairs@ietf.org" Thread-Topic: Note from wg meeting Thread-Index: AQHU4vsl+Rtj46zo+Uy3DjLqbVOfT6YcU8iA Date: Mon, 25 Mar 2019 13:28:59 +0000 Message-ID: References: <569a4eea-521b-19f0-bd67-105c917ffd7d@bluepopcorn.net> In-Reply-To: <569a4eea-521b-19f0-bd67-105c917ffd7d@bluepopcorn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [62.168.35.125] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 634fa96a-8246-4157-aa5e-08d6b125d712 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:MN2PR15MB3343; x-ms-traffictypediagnostic: MN2PR15MB3343: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(346002)(396003)(136003)(199004)(189003)(476003)(102836004)(53946003)(186003)(26005)(3846002)(81166006)(316002)(105586002)(97736004)(446003)(99286004)(6506007)(3480700005)(53546011)(76176011)(14454004)(25786009)(74316002)(11346002)(486006)(966005)(66066001)(54906003)(52536014)(86362001)(55016002)(229853002)(53936002)(14444005)(5024004)(5660300002)(71190400001)(71200400001)(68736007)(7736002)(478600001)(44832011)(2906002)(606006)(6916009)(8676002)(7696005)(81156014)(790700001)(33656002)(4326008)(6116002)(6246003)(256004)(6306002)(54896002)(6436002)(106356001)(8936002)(236005)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR15MB3343; H:MN2PR15MB3310.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: z6E5d9ee+sMULHyvTsO/c2rTTeTr+CysTKBam9lfFgghfXnBRTZZIGD5bpn8m2cWlCCpKdb275h37QrkTE9fkhARyjUjHtf2hHB4JPQA9zONmG7t8gVdX4X/4PXQQXuYNo9q65r85Fh2yG7HBErs+cyj30A7ODl8rDG03OUH3PH++Y58FJECA8p3MwQJ/y73NcqbhaLe5o2ExU0iP+Ly+IISXD0dg/iW72+fGnHtmqG/T9EbuD/bWCWmKfb/IKOIWWcDQhy584hl4jSdOnBl7DboJ1TLbBgTunIn3y1I1mTRvn96YgmMVAnkRsBBxcTyfyRGMjrA2aWlDSYRB1eipogodclcbWdSGFjxvV3Qu+eung305EyPyNwToeaaVaedsMvIVgwyoPZconWIxhL9TZa2V8oU81zaQmGmPEtvxAI= Content-Type: multipart/alternative; boundary="_000_MN2PR15MB331068621461127848C55A2DE35E0MN2PR15MB3310namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 634fa96a-8246-4157-aa5e-08d6b125d712 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 13:28:59.8443 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB3343 Archived-At: Subject: Re: [calsify] Note from wg meeting X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 13:29:06 -0000 --_000_MN2PR15MB331068621461127848C55A2DE35E0MN2PR15MB3310namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEppbSBmb3IgdGhlIG5vdGVzLiBGb3IgdGhvc2UgdGhhdCBhdHRlbmRlZCB0aGUgbWVl dGluZywgcGxlYXNlIGxldCB1cyBrbm93IGlmIHRoZXJlIGFyZSBhbnkgdXBkYXRlIHRvIGJlIG1h ZGUuDQoNCllvdXJzLA0KRGFuaWVsDQoNCkZyb206IEppbSBGZW50b24gPGZlbnRvbkBibHVlcG9w Y29ybi5uZXQ+DQpTZW50OiBNb25kYXksIE1hcmNoIDI1LCAyMDE5IDEyOjA5IFBNDQpUbzogY2Fs ZXh0LWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogTm90ZSBmcm9tIHdnIG1lZXRpbmcNCg0KDQpU aGV5J3JlIGFsc28gaW4gRXRoZXJwYWQgYXQgaHR0cHM6Ly9ldGhlcnBhZC5pZXRmLm9yZy9wL25v dGVzLWlldGYtMTA0LWNhbGV4dD91c2VNb25vc3BhY2VGb250PXRydWUNCmNhbGV4dCB3ZywgSUVU RiAxMDQNCg0KQW5ub3VuY2VtZW50OiBCYXJyeSB0YWtpbmcgb3ZlciBhcyByZXNwb25zaWJsZSBB RCBmb3IgV0cgZnJvbSBBbGV4ZXkNCg0KY2FsZGF2LWF0dGFjaG1lbnRzOg0KICAgIEJyb24gbm93 IHNoZXBoZXJkLCBhd2FpdGluZyBBRCBhcHByb3ZhbCAoQWxleGV5KQ0KICAgIEJyb24gdG8gdGFs ayB0byBKdWxpYW4gYXMgcHJveHkgZm9yIEtlbi4NCiAgICBBbGV4ZXkgd2lsbCB0cnkgdG8gcmV2 aWV3IHRoZSBkaWZmLg0KDQpldmVudHB1Yi1leHRlbnNpb25zOg0KICAgIEFsZXhleSBuZWVkcyB0 byBjaGVjayBjaGFuZ2VzIGFnYWluc3QgaGlzIHJldmlldy4gKHVwZGF0ZTogY29tbWVudHMgd2Vy ZSBub3QgYWRkcmVzc2VkKQ0KICAgIFdpbGwgdGFrZSB1cCBjb21tZW50cyB3aXRoIGF1dGhvcg0K ICAgIEJhcnJ5IGFuZCBBbGV4ZXkgd2lsbCB0aGVuIHdvcmsgb3V0IHdobyB0YWtlcyBpdCBmb3J3 YXJkIChJRVRGIExhc3QgQ2FsbCkNCg0KSlNDYWxlbmRhciAoUm9iZXJ0IFN0ZXBhbmVrKQ0KDQog ICogICBTdWJzdGFudGlhbCBsYXN0IGNhbGwgaW5wdXQNCg0KICAqICAgdGltZSB6b25lcyBhbGxv dyBjdXN0b20gdGltZSB6b25lcw0KDQogICogICBSaWNoZXIgbW9kZWxzIGZvciBsb2NhdGlvbnMs IGxvY2FsaXplZCBjb250ZW50IGZvciBkZXNjcmlwdGlvbnMNCg0KICAqICAgSGFuZGxpbmcgb2Yg dW5rbm93biBpQ2FsZW5kYXIgZmllbGRzPw0KDQogICogICBOZXh0IHN0ZXBzPw0KDQogICogICBS b2JlcnQgcHVzaGluZyB2MTMgdXAgdG8gSUVURiByZXBvIHRoaXMgd2Vlaywgbm8gbmVlZCB0byBy ZXBlYXQgV0cgTEMgYmVjYXVzZSBvZiBzbWFsbCBzaXplIG9mIFdHLg0KVFpEaXN0Og0KDQogICog ICBTaG91bGQgdHpkaXN0IHdvcmsgKGRyYWZ0LW11cmNoaXNvbi10emRpc3QtZ2VvbG9jYXRlKSBi ZSB0YWtlbiBvbiBpbiB0aGlzIGdyb3VwPw0KDQogICogICBDaGFpcnMgdG8gY29udGFjdCBFbGlv dCBMZWFyLCBzZWUgaWYgaGUgd2FudHMgdG8gY28tY2hhaXIgKEFsZXhleSBsZWFuaW5nIHRvIHNl cGFyYXRlIFdHKQ0KDQogICogICBCYXJyeSBwb2ludHMgb3V0IG5lZWQgdG8gbWFrZSBUWiB3b3Jr IG1vcmUgdmlzaWJsZSBieSBiZWluZyBpbiBzZXBhcmF0ZSBXRy4NCkNhbENvbm5lY3Qgd29yazoN CiAgICAyIGRyYWZ0cyAoVnBvbGwsIHN1YnNjcmlwdGlvbiB1cGdyYWRlKSBpbiBnb29kIHNoYXBl IHRvIGJyaW5nIHRvIElFVEYNCiAgICBOZXh0IGNhbGNvbm5lY3QgaW4gTG9uZG9uLCBidXQgZm9s bG93aW5nIG9uZSBpbiBQaGlsYWRlbHBoaWEgd2hpY2ggaXMgbG9jYWwgZm9yIEJhcnJ5DQogICAg QnJvbiB0byBzZW5kIGNhbGwgZm9yIGFkb3B0aW9uIHRvIG1haWxpbmcgbGlzdA0KDQpSZWNoYXJ0 ZXINCg0KICAqICAgQnJvbiBzZW50IG91dCBkcmFmdCBjaGFydGVyIGEgd2hpbGUgYmFjay4NCg0K ICAqICAganNvbiB2Y2FyZD8gKGp1c3QgZGlzY3Vzc2VkIGluIGRpc3BhdGNoKQ0KDQogICogICBC YXJyeSBwcmVmZXJzIGVpdGhlciBzZXBhcmF0ZSBXRyBvciBqbWFwIGFzIGhvbWUgZm9yIHRoYXQg d29yaw0KDQogICogICBCYXJyeSBpcyBoYXBweSB3aXRoIGRyYWZ0IGNoYXJ0ZXIgd2l0aCBtaW5v ciB3b3JkaW5nIGNoYW5nZXMuDQoNCkFkam91cm5lZCAxMjowNQ0K --_000_MN2PR15MB331068621461127848C55A2DE35E0MN2PR15MB3310namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNv LXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5hdXRob3ItYS1wa3F3Zno4N3oydmZlejg2ejFnejg0 emp6ODZ6DQoJe21zby1zdHlsZS1uYW1lOmF1dGhvci1hLXBrcXdmejg3ejJ2ZmV6ODZ6MWd6ODR6 ano4Nno7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXtt c28tbGlzdC1pZDo0OTg5MTA5OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTE4NjcwNzI4O30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo2NTk2MDYxMTsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6MjU2OTYyMjEwO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMg0KCXttc28tbGlzdC1pZDozNzgwOTY0OTg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0 NzQxOTM1ODg7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwy OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjYy MjI3MDYxMjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA4NzI4MTYyMjt9DQpAbGlzdCBsMzps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6OTY3MDA3MjY3Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotNzE0OTQ5NTA2O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlk aS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNQ0KCXtt c28tbGlzdC1pZDoxMDY3NDYxOTY5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMDI1MDc1MjAy O30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNTpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNTpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNg0KCXttc28tbGlzdC1pZDoxMzI5ODcwMzIy Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTg4ODU1OTcyODt9DQpAbGlzdCBsNjpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDY6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDY6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDcNCgl7bXNvLWxpc3QtaWQ6MTM4Mzc0NTI5ODsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MjAzNTYxMDgxNjt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw3OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDc6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDc6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDc6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDgNCgl7bXNvLWxp c3QtaWQ6MTQ1MTc3OTE5NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTgxMDM4NzU2Mjt9DQpA bGlzdCBsODpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw4OmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDg6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDg6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDg6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDkNCgl7bXNvLWxpc3QtaWQ6MTUzMTE4NjQwNjsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6NzE0NjMwOTcwO30NCkBsaXN0IGw5OmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsOTpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsOTpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsOTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsOTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsOTpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsOTpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsOTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTANCgl7bXNvLWxpc3QtaWQ6MTYzMDQzMDQxNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTIzODE1MDAwMDt9DQpAbGlzdCBsMTA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTA6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDEwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExDQoJe21z by1saXN0LWlkOjE5ODIzNDcxODA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjI1ODEyMDk4Njt9 DQpAbGlzdCBsMTE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTE6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMTE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDExOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMTpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTE6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTE6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEyDQoJe21zby1saXN0LWlkOjE5 OTU3OTMzNjE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjQ5NjM5OTU4NDt9DQpAbGlzdCBsMTI6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTI6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMTI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEyOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMjpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDEyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMjps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTI6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+ VGhhbmtzIEppbSBmb3IgdGhlIG5vdGVzLiBGb3IgdGhvc2UgdGhhdCBhdHRlbmRlZCB0aGUgbWVl dGluZywgcGxlYXNlIGxldCB1cyBrbm93IGlmIHRoZXJlIGFyZSBhbnkgdXBkYXRlIHRvIGJlIG1h ZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Zb3VycywgPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQiPkRhbmllbCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBKaW0gRmVudG9uICZsdDtmZW50 b25AYmx1ZXBvcGNvcm4ubmV0Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2gg MjUsIDIwMTkgMTI6MDkgUE08YnI+DQo8Yj5Ubzo8L2I+IGNhbGV4dC1jaGFpcnNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gTm90ZSBmcm9tIHdnIG1lZXRpbmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cD5UaGV5J3JlIGFsc28gaW4gRXRoZXJwYWQgYXQgPGEgaHJlZj0iaHR0cHM6 Ly9ldGhlcnBhZC5pZXRmLm9yZy9wL25vdGVzLWlldGYtMTA0LWNhbGV4dD91c2VNb25vc3BhY2VG b250PXRydWUiPg0KaHR0cHM6Ly9ldGhlcnBhZC5pZXRmLm9yZy9wL25vdGVzLWlldGYtMTA0LWNh bGV4dD91c2VNb25vc3BhY2VGb250PXRydWU8L2E+PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJt YWdpY2RvbWlkNyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEt cGtxd2Z6ODd6MnZmZXo4NnoxZ3o4NHpqejg2eiI+Y2FsZXh0IHdnLCBJRVRGIDEwNDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDgiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2lj ZG9taWQ5Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1wa3F3 Zno4N3oydmZlejg2ejFnejg0emp6ODZ6Ij5Bbm5vdW5jZW1lbnQ6IEJhcnJ5IHRha2luZyBvdmVy IGFzIHJlc3BvbnNpYmxlIEFEIGZvciBXRyBmcm9tIEFsZXhleTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDEwIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMTEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLXBrcXdmejg3ejJ2ZmV6 ODZ6MWd6ODR6ano4NnoiPmNhbGRhdi1hdHRhY2htZW50czo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxMiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXV0aG9yLWEtcGtxd2Z6ODd6MnZmZXo4NnoxZ3o4NHpqejg2eiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7IEJyb24gbm93IHNoZXBoZXJkLCBhd2FpdGluZyBBRCBhcHByb3ZhbCAoQWxl eGV5KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDEz Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1wa3F3Zno4N3oy dmZlejg2ejFnejg0emp6ODZ6Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQnJvbiB0byB0YWxrIHRvIEp1 bGlhbiBhcyBwcm94eSBmb3IgS2VuLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0ibWFnaWNkb21pZDE0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJh dXRob3ItYS1wa3F3Zno4N3oydmZlejg2ejFnejg0emp6ODZ6Ij4mbmJzcDsmbmJzcDsmbmJzcDsg QWxleGV5IHdpbGwgdHJ5IHRvIHJldmlldyB0aGUgZGlmZi48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxNSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDE2Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1wa3F3Zno4N3oydmZlejg2 ejFnejg0emp6ODZ6Ij5ldmVudHB1Yi1leHRlbnNpb25zOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDE3Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJhdXRob3ItYS1wa3F3Zno4N3oydmZlejg2ejFnejg0emp6ODZ6Ij4mbmJzcDsm bmJzcDsmbmJzcDsgQWxleGV5IG5lZWRzIHRvIGNoZWNrIGNoYW5nZXMgYWdhaW5zdCBoaXMgcmV2 aWV3LiAodXBkYXRlOiBjb21tZW50cyB3ZXJlIG5vdCBhZGRyZXNzZWQpPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMTgiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLXBrcXdmejg3ejJ2ZmV6ODZ6MWd6ODR6ano4Nnoi PiZuYnNwOyZuYnNwOyZuYnNwOyBXaWxsIHRha2UgdXAgY29tbWVudHMgd2l0aCBhdXRob3I8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxOSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtcGtxd2Z6ODd6MnZmZXo4Nnox Z3o4NHpqejg2eiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJhcnJ5IGFuZCBBbGV4ZXkgd2lsbCB0aGVu IHdvcmsgb3V0IHdobyB0YWtlcyBpdCBmb3J3YXJkIChJRVRGIExhc3QgQ2FsbCk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQyMCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtcGtxd2Z6ODd6MnZmZXo4NnoxZ3o4NHpq ejg2eiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9ImF1dGhvci1hLXBrcXdmejg3ejJ2ZmV6ODZ6MWd6ODR6ano4NnoiPkpTQ2FsZW5kYXIg KFJvYmVydCBTdGVwYW5layk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 Im1hZ2ljZG9taWQyMiI+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwzIGxldmVsMSBsZm8xIj4NCjxzcGFuIGNsYXNzPSJhdXRob3ItYS1wa3F3Zno4 N3oydmZlejg2ejFnejg0emp6ODZ6Ij5TdWJzdGFudGlhbCBsYXN0IGNhbGwgaW5wdXQ8L3NwYW4+ PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBpZD0ibWFnaWNkb21pZDIzIj4N Cjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEwIGxl dmVsMSBsZm8yIj4NCjxzcGFuIGNsYXNzPSJhdXRob3ItYS1wa3F3Zno4N3oydmZlejg2ejFnejg0 emp6ODZ6Ij50aW1lIHpvbmVzIGFsbG93IGN1c3RvbSB0aW1lIHpvbmVzPC9zcGFuPjxvOnA+PC9v OnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMjQiPg0KPHVsIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsOCBsZXZlbDEgbGZvMyI+ DQo8c3BhbiBjbGFzcz0iYXV0aG9yLWEtcGtxd2Z6ODd6MnZmZXo4NnoxZ3o4NHpqejg2eiI+Umlj aGVyIG1vZGVscyBmb3IgbG9jYXRpb25zLCBsb2NhbGl6ZWQgY29udGVudCBmb3IgZGVzY3JpcHRp b25zPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2Rv bWlkMjUiPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMTEgbGV2ZWwxIGxmbzQiPg0KPHNwYW4gY2xhc3M9ImF1dGhvci1hLXBrcXdmejg3ejJ2ZmV6 ODZ6MWd6ODR6ano4NnoiPkhhbmRsaW5nIG9mIHVua25vd24gaUNhbGVuZGFyIGZpZWxkcz88L3Nw YW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgaWQ9 Im1hZ2ljZG9taWQyNiI+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwxMiBsZXZlbDEgbGZvNSI+DQo8c3BhbiBjbGFzcz0iYXV0aG9yLWEtcGtxd2Z6 ODd6MnZmZXo4NnoxZ3o4NHpqejg2eiI+TmV4dCBzdGVwcz88L3NwYW4+PG86cD48L286cD48L2xp PjwvdWw+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdiBpZD0ibWFnaWNkb21pZDI3Ij4NCjx1bCB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDUgbGV2ZWwxIGxmbzYiPg0KPHNw YW4gY2xhc3M9ImF1dGhvci1hLXBrcXdmejg3ejJ2ZmV6ODZ6MWd6ODR6ano4NnoiPlJvYmVydCBw dXNoaW5nIHYxMyB1cCB0byBJRVRGIHJlcG8gdGhpcyB3ZWVrLCBubyBuZWVkIHRvIHJlcGVhdCBX RyBMQyBiZWNhdXNlIG9mIHNtYWxsIHNpemUgb2YgV0cuPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMjkiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLXBrcXdmejg3ejJ2ZmV6ODZ6 MWd6ODR6ano4NnoiPlRaRGlzdDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Im1hZ2ljZG9taWQzMCI+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0Omw0IGxldmVsMSBsZm83Ij4NCjxzcGFuIGNsYXNzPSJhdXRob3ItYS1wa3F3 Zno4N3oydmZlejg2ejFnejg0emp6ODZ6Ij5TaG91bGQgdHpkaXN0IHdvcmsgKGRyYWZ0LW11cmNo aXNvbi10emRpc3QtZ2VvbG9jYXRlKSBiZSB0YWtlbiBvbiBpbiB0aGlzIGdyb3VwPzwvc3Bhbj48 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDMxIj4NCjx1 bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzgiPg0KPHNwYW4gY2xhc3M9ImF1dGhvci1hLXBrcXdmejg3ejJ2ZmV6ODZ6MWd6ODR6ano4 NnoiPkNoYWlycyB0byBjb250YWN0IEVsaW90IExlYXIsIHNlZSBpZiBoZSB3YW50cyB0byBjby1j aGFpciAoQWxleGV5IGxlYW5pbmcgdG8gc2VwYXJhdGUgV0cpPC9zcGFuPjxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPC9kaXY+DQo8ZGl2IGlkPSJtYWdpY2RvbWlkMzIiPg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsOSBsZXZlbDEgbGZvOSI+DQo8c3Bh biBjbGFzcz0iYXV0aG9yLWEtcGtxd2Z6ODd6MnZmZXo4NnoxZ3o4NHpqejg2eiI+QmFycnkgcG9p bnRzIG91dCBuZWVkIHRvIG1ha2UgVFogd29yayBtb3JlIHZpc2libGUgYnkgYmVpbmcgaW4gc2Vw YXJhdGUgV0cuPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2IGlkPSJt YWdpY2RvbWlkMzQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1h LXBrcXdmejg3ejJ2ZmV6ODZ6MWd6ODR6ano4NnoiPkNhbENvbm5lY3Qgd29yazo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQzNSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtcGtxd2Z6ODd6MnZmZXo4NnoxZ3o4NHpq ejg2eiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDIgZHJhZnRzIChWcG9sbCwgc3Vic2NyaXB0aW9uIHVw Z3JhZGUpIGluIGdvb2Qgc2hhcGUgdG8gYnJpbmcgdG8gSUVURjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDM2Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGNsYXNzPSJhdXRob3ItYS1wa3F3Zno4N3oydmZlejg2ejFnejg0emp6ODZ6Ij4mbmJz cDsmbmJzcDsmbmJzcDsgTmV4dCBjYWxjb25uZWN0IGluIExvbmRvbiwgYnV0IGZvbGxvd2luZyBv bmUgaW4gUGhpbGFkZWxwaGlhIHdoaWNoIGlzIGxvY2FsIGZvciBCYXJyeTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNkb21pZDM3Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1wa3F3Zno4N3oydmZlejg2ejFnejg0emp6ODZ6 Ij4mbmJzcDsmbmJzcDsmbmJzcDsgQnJvbiB0byBzZW5kIGNhbGwgZm9yIGFkb3B0aW9uIHRvIG1h aWxpbmcgbGlzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibWFnaWNk b21pZDM4Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhdXRob3ItYS1wa3F3 Zno4N3oydmZlejg2ejFnejg0emp6ODZ6Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQzOSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXV0aG9yLWEtcGtxd2Z6ODd6MnZmZXo4NnoxZ3o4 NHpqejg2eiI+UmVjaGFydGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtYWdpY2RvbWlkNTEiPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsNyBsZXZlbDEgbGZvMTAiPg0KPHNwYW4gY2xhc3M9ImF1dGhvci1hLXBrcXdm ejg3ejJ2ZmV6ODZ6MWd6ODR6ano4NnoiPkJyb24gc2VudCBvdXQgZHJhZnQgY2hhcnRlciBhIHdo aWxlIGJhY2suPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+DQo8ZGl2IGlkPSJt YWdpY2RvbWlkNDEiPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMSBsZXZlbDEgbGZvMTEiPg0KPHNwYW4gY2xhc3M9ImF1dGhvci1hLXBrcXdmejg3 ejJ2ZmV6ODZ6MWd6ODR6ano4NnoiPmpzb24gdmNhcmQ/IChqdXN0IGRpc2N1c3NlZCBpbiBkaXNw YXRjaCk8L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2lj ZG9taWQ0MiI+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwyIGxldmVsMSBsZm8xMiI+DQo8c3BhbiBjbGFzcz0iYXV0aG9yLWEtcGtxd2Z6ODd6MnZm ZXo4NnoxZ3o4NHpqejg2eiI+QmFycnkgcHJlZmVycyBlaXRoZXIgc2VwYXJhdGUgV0cgb3Igam1h cCBhcyBob21lIGZvciB0aGF0IHdvcms8L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rp dj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxMDEiPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNiBsZXZlbDEgbGZvMTMiPg0KPHNwYW4gY2xhc3M9ImF1 dGhvci1hLXBrcXdmejg3ejJ2ZmV6ODZ6MWd6ODR6ano4NnoiPkJhcnJ5IGlzIGhhcHB5IHdpdGgg ZHJhZnQgY2hhcnRlciB3aXRoIG1pbm9yIHdvcmRpbmcgY2hhbmdlcy48L3NwYW4+PG86cD48L286 cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2ljZG9taWQxMDUiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1hZ2lj ZG9taWQxMjAiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImF1dGhvci1hLXBr cXdmejg3ejJ2ZmV6ODZ6MWd6ODR6ano4NnoiPkFkam91cm5lZCAxMjowNTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MN2PR15MB331068621461127848C55A2DE35E0MN2PR15MB3310namp_-- From nobody Tue Mar 26 02:54:24 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAA01202E6 for ; Tue, 26 Mar 2019 02:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=kmWPGX8Q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=O5GVOIsL 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 TADFi9uLopKy for ; Tue, 26 Mar 2019 02:54:10 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36ADC1202B9 for ; Tue, 26 Mar 2019 02:54:10 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 2BF5922751 for ; Tue, 26 Mar 2019 05:54:09 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 26 Mar 2019 05:54:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=2Vo+3L3 BsqBbY/4xHV29ulrODNo4ixebJ/f0T8rPudg=; b=kmWPGX8QRQM2JnE2m5TnGpS ABWwgoSgFstMaU+/8o7vs2pKfkbZKF/SEGyKtQC6LD1b/i85ajKDo/nB7vYP8Xgl ukDIBIS5JtanVeveKKooV6PIpCXcu67UWk5uzYjS0E++3wLTD8/JdY4aEQ7b2t7D FHUy+Eq9FnljSNPn6FvIqDDu7qdLk1QNkChrHBxTBZtO4VqkkmPptfEuSsr5XWRB IuNjgJ5dtcM1UecU1Rwt1gvprnMh5J+EW1drFk78zcdU2LREHBKzoJ7/xJaubqp8 C0gax1SkAdM9P7pZehOauUoKhzMkqtYX4pWDsb770QH2+7K/FMVC/7TA6Hh2T5A= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=2Vo+3L 3BsqBbY/4xHV29ulrODNo4ixebJ/f0T8rPudg=; b=O5GVOIsLyzCJtQQ+dDjOlR tLLezAv56ngcV2pATz0S6SmihFvBe11Ig1LriAwkDrqRXQoOgp8qWC+6wIwF5WZb 9lT7jbWbi6koTzXAKtMdlSyrCFxy234ylL02xXrbpEy6g8sbBg2zp8shpOmWCpzz 4psewbH9P4LRlDD7Glp1/OaExRco0SftCsGnRb2vX2oEcixZVVRzD1nfgM7ZMEEn kUSq50hfKfAhfGkjcH0bHjartszBdsRXAzDHxJed8/hzOo/IpfYh2b8PaevqZ92I xQ+Srtk3owWH1Qxk/e1OAoXcIEdCYcUpD86vQkrYS0WtS59oo0LCKbuoflyN0cPA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedtgddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh dpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id A298420578; Tue, 26 Mar 2019 05:54:08 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-328-g40d9e92-fmstable-20190325v1 Mime-Version: 1.0 X-Me-Personality: 56629417 Message-Id: <3bc83990-7ffe-45ff-81f7-ac5c987d45fa@www.fastmail.com> In-Reply-To: References: Date: Tue, 26 Mar 2019 05:54:08 -0400 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=c7e331e530894ebabdf4c558ad6a4d84 Archived-At: Subject: Re: [calsify] =?utf-8?q?Request_for_adoption=3A_draft-gondwana-calda?= =?utf-8?q?v-scheduling-controls?= X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 09:54:23 -0000 --c7e331e530894ebabdf4c558ad6a4d84 Content-Type: text/plain Thanks Mike - sorry about the delay in replying. Do you think we should progress bulk-change as a separate document, or merge it into scheduling controls? Ken implemented it in the Cyrus IMAPd server, but we aren't using it ourselves. I guess you could "bulk update" a single item to avoid scheduling as an alternative method. Bron. On Sat, Mar 9, 2019, at 07:38, Michael Douglass wrote: > Cyrus wrote a spec for bulk import/updates > https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calendarserver-bulk-change.xml > I have the impression it's used but not certain. > The spec says nothing about scheduling. > On 3/8/19 07:07, Bron Gondwana wrote: >> It's a bit cheeky asking this as a recent chair myself, but I had started work on this document as a purely FastMail suggestion, and during discussion at CalConnect last month in Zurich it came up that Google had done much the same thing themselves to handle bulk import, so I ran the idea past Lucia and put this draft together. >> >> There's still some work to do, and I'm happy to hand over authorship to somebody else if anyone wants it, or to continue working on it myself. I've renamed things to be a bit more consistent than our implementation at FastMail, but of course we'd update to match the standard once the spec is done. >> >> https://datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/ >> >> (still plenty of work to do on it, but the bones are there) >> >> I believe this is within the scope of this group's existing charter and would like to see it adopted. >> >> Regards, >> >> Bron. >> >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> >> _______________________________________________ calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --c7e331e530894ebabdf4c558ad6a4d84 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks Mike - sorry about the delay in replying.
<= /div>

Do you think we should progress bulk-change as a separate doc= ument, or merge it into scheduling controls?

Ken implemen= ted it in the Cyrus IMAPd server, but we aren't using it ourselves. = ; I guess you could "bulk update" a single item to avoid scheduling as a= n alternative method.

Bron.

On Sat, Mar 9,= 2019, at 07:38, Michael Douglass wrote:

Cyrus wrote a spec for bulk import/updates=

https://github.com/apple/ccs-calendarserver= /blob/master/doc/Extensions/calendarserver-bulk-change.xml

I have the impression it's used but not certain.

The spec say= s nothing about scheduling.

On 3/8/19 07:07, Bron Gondwana wrote:
It's a bit cheeky asking this as= a recent chair myself, but I had started work on this document as a purely FastMail suggestion, and during discussion at CalConnect last month in Zurich it came up that Google had done much the same thing themselves to handle bulk import, so I ran the idea past Lucia and put this draft together.

= There's still some work to do, and I'm happy to hand over authorship to somebody else if anyone wants it, or to continue working on it myself.  I've rename= d things to be a bit more consistent than our implementation at FastMail, but of course we'd update to match the standard once the spec is done.
https://datatra= cker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/

(still plenty of work to do on it, but the bones are there)

I believe this is within= the scope of this group's existing charter and would like to see it adopted.

Regards,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.co= m

= 


_=
______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/=
calsify
____________________________________________= ___
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
=

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--c7e331e530894ebabdf4c558ad6a4d84-- From nobody Tue Mar 26 03:02:56 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B72A31202A2 for ; Tue, 26 Mar 2019 03:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=hrkr8+xz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=b2aF4yRZ 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 3U1ayAYanygY for ; Tue, 26 Mar 2019 03:02:40 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34EA120309 for ; Tue, 26 Mar 2019 03:02:40 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 8CFB2231DE for ; Tue, 26 Mar 2019 06:02:39 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 26 Mar 2019 06:02:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=P7JbolwStXWTVO69sWReJEtmn9aGt1fw7Nnq5vg AzWY=; b=hrkr8+xzi4woBEkvaY5m9XxVeSZwqmgscBx7lkqcNiuA7QHilY4kJcg UiqDEiyYyYU7VZVZWwhOgBKlSWS6lK/MIegpq9lMjRKROMGohJLpDgdshx2XefN5 0OLIiUi25CpTL3IXJybq0DiOeb37LajRb47bHnp4BgjqJoQAgRBLdGDnzcrOsWxQ hxwZC6TbiWbiUcLurSQSE6uNLJR+2pSkJ8yf7ZziyQLLdZY1jWTx5ODSmL3Dh160 lHwnYHnB2Gz5Q6WXNXLJVlGZa7S1Ujy94PgSdsrf7Ie8Qhozk9HhItFQRNQvcqLh jPqO/xOXDAuy8ogHMNrMvdTKWQ9fB3A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=P7JbolwStXWTVO69sWReJEtmn9aGt 1fw7Nnq5vgAzWY=; b=b2aF4yRZ9a1um0x30+9F6JlDWuy4KH4bG6YApdQDbjcAW pSae6fZuz63cfLcZacBGLOPmMTt4RLPzbfDya53bjEvjP3paQbXGCJVAtb0QbZyi zWPs0rhAeXypDr1LVPbu3PXz5lDzrvKouLluJEJ6wT4HPeF67EXeYZ+3+QYyCj6f 34mgoCYCROgd1Az7TfaannM6E1hBBw8GbCCgFcaO+R00TzejASyPw5O8kkTWVEME 7yqDTrLoMoZEXSl64aA2zzw8K9aR5t7qUxbofZeUv45AQnmqS7PyJyzZklfmWBhX NHXtzNhnHNGewPmZ0DfBGOqDV14zPH9EfqNaKYHKA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedtgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpih gvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3149A20578; Tue, 26 Mar 2019 06:02:39 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-328-g40d9e92-fmstable-20190325v1 Mime-Version: 1.0 X-Me-Personality: 56629417 Message-Id: <0d660d52-4771-409c-a91f-031ad103404f@www.fastmail.com> Date: Tue, 26 Mar 2019 06:02:32 -0400 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=03cd0390cec74e51a735e58e5829bf5c Archived-At: Subject: [calsify] Call for adoption of vpoll - please reply by April 15 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 10:02:55 -0000 --03cd0390cec74e51a735e58e5829bf5c Content-Type: text/plain Hi All, As discussed in the Prague meeting, this is a formal call for adoption of work on a mechanism for consensus scheduling of events, based on the VPOLL work which can be seen in: https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/vpoll and https://www.ietf.org/archive/id/draft-york-vpoll-04.txt It is expected that after adopting this work, we would aim for Q3 2019 as a milestone for working group last call, with a possibility of dealing with it earlier if the current documents process quickly! Please reply to this message by April 15th if you do not wish the working group to adopt this work. Regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --03cd0390cec74e51a735e58e5829bf5c Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,

As discussed in the Prague meeting,= this is a formal call for adoption of work on a mechanism for consensus= scheduling of events, based on the VPOLL work which can be seen in:
=


and

=

<= /div>
It is expected that after adoptin= g this work, we would aim for Q3 2019 as a milestone for working group l= ast call, with a possibility of dealing with it earlier if the current d= ocuments process quickly!
Please reply to this message by= April 15th if you do not wish the working group to adopt this work.
=

Regards,

Bron.

= --
  Bron Gondwana, CEO, FastMail= Pty Ltd
  brong@fastmailteam.com=


--03cd0390cec74e51a735e58e5829bf5c-- From nobody Tue Mar 26 03:04:33 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A071202A3 for ; Tue, 26 Mar 2019 03:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=m9fTEmE+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KNKN3eQI 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 04xbncc5unks for ; Tue, 26 Mar 2019 03:04:30 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182281202A1 for ; Tue, 26 Mar 2019 03:04:30 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 1D87821AAA for ; Tue, 26 Mar 2019 06:04:29 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Tue, 26 Mar 2019 06:04:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=pGtX2G3mUcxVRhoJSyBS65i1aGa6Qf3K0C6Fdkh B740=; b=m9fTEmE+0G6Y8qMEV+g3mfYWc63wB3TGHVGqkv2rwV+1e9pH/QIH/g5 uh/FTxfpFVlK7+zrtoPKSy74yQyVjn2epWPbF1ggnkCHvMuv+VbXVEgYC+5DngtF QwkNjxv5EMgzYl/xOHWLB8YS5M5QEu7bSp+942sP6fnntj3JjNgBV74yNUBuvJ81 HRVsq4uw6UDLWvQKkOUxOL6JGv3r/KpJyfvbcDmZN3iAz9rqmn0nyMDczkKizLdb kz3bNpNjvNIvzUnOpZD4bwWhfai8sU79dcwqaIMvUd830k+yFxLYlzqYo3ApP5wS 6yzUQID8WWzZxfcJ6nVqfik1ciBeLBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=pGtX2G3mUcxVRhoJSyBS65i1aGa6Q f3K0C6FdkhB740=; b=KNKN3eQIQYFXk++D+iKkh/p8ZoajcPed/Aic6nA06Msmj ZWUugvBr+FTbB9TwcY0+tWYWY2fwSvnipqEDrVypzK434lYlNYzAtgcnHqHSRLGi ciy4WCp17g5hPvRufZUefstKstroNR7o+hoUR1p984fXa6vebJOrYMViy20NXSiG N1ulk7R4cNCVFw4yok+3N4FWfY107pHh6NHLYNGWjgGUoW8WXEItUGbFMh+MIMww Ed9CwvM80zNvtZe2+yAXdp789xvBauM2smUscJFWkjlCaKDEQQuMJGp27h7dOhqw wgHo91aFEXmghaHrm2EhSwWtQZqUBqvZek8PhazCQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedtgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre ertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpih gvthhfrdhorhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhm rghilhhtvggrmhdrtghomhenucevlhhushhtvghrufhiiigvpedu X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8303D20578; Tue, 26 Mar 2019 06:04:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-328-g40d9e92-fmstable-20190325v1 Mime-Version: 1.0 X-Me-Personality: 56629417 Message-Id: Date: Tue, 26 Mar 2019 06:04:28 -0400 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=80d5890e54c7407bbff867c9766f17c1 Archived-At: Subject: [calsify] Call for adoption of subscription upgrade - please reply by April 15 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 10:04:32 -0000 --80d5890e54c7407bbff867c9766f17c1 Content-Type: text/plain Hi All, As discussed in the Prague meeting, this is a formal call for adoption of work on a mechanism for upgrading .ics calendar feeds to more efficient sychronisation mechanisms, based on the documents here: https://github.com/CalConnect/PUBLIC_DRAFTS/tree/master/subscription-upgrade and https://www.ietf.org/archive/id/draft-douglass-subscription-upgrade-03.txt It is expected that after adopting this work, we would aim for Q3 2019 as a milestone for working group last call, with a possibility of dealing with it earlier if the current documents process quickly! Please reply to this message by April 15th if you do not wish the working group to adopt this work. Regards, Bron. -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --80d5890e54c7407bbff867c9766f17c1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi All,
As discussed in the Prague mee= ting, this is a formal call for adoption of work on a mechanism for upgr= ading .ics calendar feeds to more efficient sychronisation mechanisms, b= ased on the documents here:


and

I= t is expected that after adopting this work, we would aim for Q3 2019 as= a milestone for working group last call, with a possibility of dealing = with it earlier if the current documents process quickly!

Please reply to this message by April 15th if you do not wish the worki= ng group to adopt this work.
=
Regards,

Bron= .

--
&nb= sp; Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

<= /div>

--80d5890e54c7407bbff867c9766f17c1-- From nobody Tue Mar 26 04:00:32 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B476120328 for ; Tue, 26 Mar 2019 04:00:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155359802530.20680.17400225035212670352.idtracker@ietfa.amsl.com> Date: Tue, 26 Mar 2019 04:00:25 -0700 From: IETF Secretariat Archived-At: Subject: [calsify] Milestones changed for calext WG X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 11:00:31 -0000 Changed milestone "Send attachment dratf to IESG", set due date to April 2019 from June 2019. URL: https://datatracker.ietf.org/wg/calext/about/ From nobody Tue Mar 26 04:07:15 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0FC1202C9; Tue, 26 Mar 2019 04:07:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <155359843401.20774.2083514655275819527@ietfa.amsl.com> Date: Tue, 26 Mar 2019 04:07:14 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-caldav-scheduling-controls-00.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 11:07:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Calendaring Extensions WG of the IETF. Title : CalDAV Extension for scheduling controls Author : Bron Gondwana Filename : draft-ietf-calext-caldav-scheduling-controls-00.txt Pages : 6 Date : 2019-03-26 Abstract: This document adds headers to control and restrict the scheduling behaviour of CalDAV servers when updating calendaring resources. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-scheduling-controls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-caldav-scheduling-controls-00 https://datatracker.ietf.org/doc/html/draft-ietf-calext-caldav-scheduling-controls-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 26 04:16:41 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659381202D1 for ; Tue, 26 Mar 2019 04:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=pwQfBESo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ct/zH1tO 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 olSRwa0fSTQN for ; Tue, 26 Mar 2019 04:16:37 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BAC21202D0 for ; Tue, 26 Mar 2019 04:16:37 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 408B223171 for ; Tue, 26 Mar 2019 07:16:36 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 26 Mar 2019 07:16:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm2; bh=0X5nhWzhkdFNrQ9jOdsSIz0QISD KnohGO4P9fr+wWVA=; b=pwQfBESoN3C8oH8yzOopSCFmd0gmLpC8IOIvUqJEScL /LjHSnYtUVMfJn2VdsPy74y43XFEafgVX/+u9J94Fi4n6csfM6x+0LT44LWbECMA tg7Ol4yp2vO+UbsVV7wBnBCOmUGD6+WSkSICaMgU2Ry9OPuh2OP3/vcFt9c/RO8/ 8iGojlUAQ0fC8N8a0dkyHWsqTKPBxoMMjmC1gMkaf0aIru2uR2xdJZ43pKVMw//j ahYpTgYTKJtAuYzL+cMufOnY2/AxuOQgF8cmW2o9eAWLk1cas38Nk3+E8nj69VOb 2OrMFayQRrclKy4EdcTDioCh7nkPkG6MFZh5+/tdhkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0X5nhW zhkdFNrQ9jOdsSIz0QISDKnohGO4P9fr+wWVA=; b=ct/zH1tOjqO19m+EqZM9R8 C/8e7+ElU7xQedgxMyFO2pISmHmTsyNm6b/IbLNQIdPGfTceUJbMYCpanOBIcIQp lo9y9NgfYVVYcKKJN4nigYVO1pss8E7z18RwCLc3hnSgh/3R1DTi2XORm8qOGppD M6pcy4ItU9V9i1bNgLdNplZxSJQivMaJei7PIscdy0gILq2D8vaL6/mkcmnIS4zK RnhifT2e0ejSvs8kRu+4BQuaWZgaEqQ4vN9Sz1S07TF0jFiXOJBUpfKxwA/dFLnD b/U2rP3M2jM+F8bHGzUvt0YAKfWiiPlvYPV94tbyd42vnW8IihGvR7xvaCqezkXw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedtgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhohfkffgfgggjtgesmhdtre ertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrd horhhgnecukfhppeejgedrjeejrdekhedrvdehtdenucfrrghrrghmpehmrghilhhfrhho mhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D1B2E4805 for ; Tue, 26 Mar 2019 07:16:35 -0400 (EDT) To: calsify@ietf.org References: <3bc83990-7ffe-45ff-81f7-ac5c987d45fa@www.fastmail.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <6474185c-9f34-7cbe-8875-790cb866058e@fastmail.com> Date: Tue, 26 Mar 2019 07:16:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <3bc83990-7ffe-45ff-81f7-ac5c987d45fa@www.fastmail.com> Content-Type: multipart/mixed; boundary="------------36B03FFFCBFC233BCEDA8457" Content-Language: en-US Archived-At: Subject: Re: [calsify] Request for adoption: draft-gondwana-caldav-scheduling-controls X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 11:16:40 -0000 This is a multi-part message in MIME format. --------------36B03FFFCBFC233BCEDA8457 Content-Type: multipart/alternative; boundary="------------59B137188B3D3C6E59D3F1C0" --------------59B137188B3D3C6E59D3F1C0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit To clarify, I implemented bulk import only.  I haven't implemented bulk update. On 3/26/19 5:54 AM, Bron Gondwana wrote: > Thanks Mike - sorry about the delay in replying. > > Do you think we should progress bulk-change as a separate document, or > merge it into scheduling controls? > > Ken implemented it in the Cyrus IMAPd server, but we aren't using it > ourselves.  I guess you could "bulk update" a single item to avoid > scheduling as an alternative method. > > Bron. > > On Sat, Mar 9, 2019, at 07:38, Michael Douglass wrote: >> >> Cyrus wrote a spec for bulk import/updates >> >> https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calendarserver-bulk-change.xml >> >> I have the impression it's used but not certain. >> >> The spec says nothing about scheduling. >> >> On 3/8/19 07:07, Bron Gondwana wrote: >>> It's a bit cheeky asking this as a recent chair myself, but I had >>> started work on this document as a purely FastMail suggestion, and >>> during discussion at CalConnect last month in Zurich it came up that >>> Google had done much the same thing themselves to handle bulk >>> import, so I ran the idea past Lucia and put this draft together. >>> >>> There's still some work to do, and I'm happy to hand over authorship >>> to somebody else if anyone wants it, or to continue working on it >>> myself.  I've renamed things to be a bit more consistent than our >>> implementation at FastMail, but of course we'd update to match the >>> standard once the spec is done. >>> >>> https://datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/ >>> >>> (still plenty of work to do on it, but the bones are there) >>> >>> I believe this is within the scope of this group's existing charter >>> and would like to see it adopted. >>> >>> Regards, >>> >>> Bron. >>> >>> -- >>>   Bron Gondwana, CEO, FastMail Pty Ltd >>> brong@fastmailteam.com >>> >>> >>> >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >>> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> > > -- >   Bron Gondwana, CEO, FastMail Pty Ltd >   brong@fastmailteam.com > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team FastMail US LLC --------------59B137188B3D3C6E59D3F1C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

To clarify, I implemented bulk import only.  I haven't implemented bulk update.


On 3/26/19 5:54 AM, Bron Gondwana wrote:
Thanks Mike - sorry about the delay in replying.

Do you think we should progress bulk-change as a separate document, or merge it into scheduling controls?

Ken implemented it in the Cyrus IMAPd server, but we aren't using it ourselves.  I guess you could "bulk update" a single item to avoid scheduling as an alternative method.

Bron.

On Sat, Mar 9, 2019, at 07:38, Michael Douglass wrote:

Cyrus wrote a spec for bulk import/updates

https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calendarserver-bulk-change.xml

I have the impression it's used but not certain.

The spec says nothing about scheduling.

On 3/8/19 07:07, Bron Gondwana wrote:
It's a bit cheeky asking this as a recent chair myself, but I had started work on this document as a purely FastMail suggestion, and during discussion at CalConnect last month in Zurich it came up that Google had done much the same thing themselves to handle bulk import, so I ran the idea past Lucia and put this draft together.

There's still some work to do, and I'm happy to hand over authorship to somebody else if anyone wants it, or to continue working on it myself.  I've renamed things to be a bit more consistent than our implementation at FastMail, but of course we'd update to match the standard once the spec is done.


(still plenty of work to do on it, but the bones are there)

I believe this is within the scope of this group's existing charter and would like to see it adopted.

Regards,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com



_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
_______________________________________________
calsify mailing list


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com



_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------59B137188B3D3C6E59D3F1C0-- --------------36B03FFFCBFC233BCEDA8457 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------36B03FFFCBFC233BCEDA8457-- From nobody Tue Mar 26 05:17:26 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AA01202DB for ; Tue, 26 Mar 2019 05:17:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155360264545.20765.853075386646019306.idtracker@ietfa.amsl.com> Date: Tue, 26 Mar 2019 05:17:25 -0700 From: IETF Secretariat Archived-At: Subject: [calsify] Milestones changed for calext WG X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 12:17:25 -0000 Changed milestone "Adopt a document for consensus scheduling", set state to active from review, accepting new milestone. Changed milestone "Adopt a document for subscription upgrade", set state to active from review, accepting new milestone. Changed milestone "Submit scheduling controls document to IESG for publication", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/calext/about/ From nobody Tue Mar 26 09:39:22 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69478120404 for ; Tue, 26 Mar 2019 09:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8wH5i_5gTtHI for ; Tue, 26 Mar 2019 09:39:18 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 D56391203EB for ; Tue, 26 Mar 2019 09:39:17 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id x12so15338404qts.7 for ; Tue, 26 Mar 2019 09:39:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=IAVuxPbUGm59gJW64ZdwGQsqWj5N7jAA+fvFjyA0/Yw=; b=FAbjp9QpPm7AwpHG1CRv3A6BWVgJgJ2n4I14/lcAQTXAyuL1njh5TonMbXKEFyp6SB HvePNWsf0cmbkEdo/IFR4qeeN9Zhwdx0rKap2KiC5eItKnkM1dCUNXUGUlL8l8qVoS7g KMmlXKW72QU0M5YjCSbCIActiJMXIOeaN8V657mwroDNHZGajOnqK+uj9I3lzUAubBZ/ vVzLiU4+qSfVqUglyBxIzeQJwNFRnEJbE6Yt/i4g8MqaYmSLolbOAE5MyjVyOyOvQjwR 1FmRdsp8oK7rFsZ88teDYCQVkjSMreZtxbmPJ8Onoe12ZAQfllpDxXjHAHIFfhshvR47 uy/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=IAVuxPbUGm59gJW64ZdwGQsqWj5N7jAA+fvFjyA0/Yw=; b=ilyTLglLOKGOjR0DU/bsD/ZMLthSH28fAwrdKffOpi7nOTmPg5H98LkhR+blUzeA+C ZNt1eyxABvTCTwr+ZWn9OV0KE2+1uVnhtbre6G84rRfSh9T+k+brl8sNhW0L/UKg5Kns KmcP1ewjDsD13I9ViivKTz+ZAKdCC+unAgA8NcsrpNOO8m89nhEcsp2sK4cygyuLNm4q fzgHBF782XpL25NntDZWicTv3r9ewKVlT1W5X3D2E4vvHbaSTH+gzuOtueje8v50tnXm i7uSdoMA5eyRLaSWk0Zj5/3hkqrHpwfsSG7F53sToNeZlHUSqWjoarShX1AipJu/bVre kvvg== X-Gm-Message-State: APjAAAW6rsJQvR8OBFPlrj+wRP3jWEBJu6Ouhr2Pc2SZEZxAnXyw/0l2 LjsGvFAvAofMLfyyLBzI8nZOIJR2XQA= X-Google-Smtp-Source: APXvYqwEXJVdhmkywPMXdo9FXoNES+Q7IhK3VVq/+GENrve1QRQ4SF445y8W83kFTiG1KA2R4RokIQ== X-Received: by 2002:a0c:9973:: with SMTP id i48mr26991235qvd.9.1553618356745; Tue, 26 Mar 2019 09:39:16 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id e6sm10926438qkb.77.2019.03.26.09.39.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 09:39:16 -0700 (PDT) To: calsify@ietf.org References: <3bc83990-7ffe-45ff-81f7-ac5c987d45fa@www.fastmail.com> <6474185c-9f34-7cbe-8875-790cb866058e@fastmail.com> From: Michael Douglass Message-ID: Date: Tue, 26 Mar 2019 12:39:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <6474185c-9f34-7cbe-8875-790cb866058e@fastmail.com> Content-Type: multipart/alternative; boundary="------------F7E880B5A983453FB71E4B3D" Content-Language: en-US Archived-At: Subject: Re: [calsify] Request for adoption: draft-gondwana-caldav-scheduling-controls X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 16:39:20 -0000 This is a multi-part message in MIME format. --------------F7E880B5A983453FB71E4B3D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I think it probably would bear some investigation. I suspect the bulk import would work better for the special cases you mentioned. My recollection is that you get some sort of per record status and that would be helpful. Maybe we should talk about this - I see some other less importy uses - for example updating a whole bunch of related resources. That gets very messy if it has to be done as a bunch of requests and one of them fails. On 3/26/19 07:16, Ken Murchison wrote: > > To clarify, I implemented bulk import only.  I haven't implemented > bulk update. > > > On 3/26/19 5:54 AM, Bron Gondwana wrote: >> Thanks Mike - sorry about the delay in replying. >> >> Do you think we should progress bulk-change as a separate document, >> or merge it into scheduling controls? >> >> Ken implemented it in the Cyrus IMAPd server, but we aren't using it >> ourselves.  I guess you could "bulk update" a single item to avoid >> scheduling as an alternative method. >> >> Bron. >> >> On Sat, Mar 9, 2019, at 07:38, Michael Douglass wrote: >>> >>> Cyrus wrote a spec for bulk import/updates >>> >>> https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calendarserver-bulk-change.xml >>> >>> I have the impression it's used but not certain. >>> >>> The spec says nothing about scheduling. >>> >>> On 3/8/19 07:07, Bron Gondwana wrote: >>>> It's a bit cheeky asking this as a recent chair myself, but I had >>>> started work on this document as a purely FastMail suggestion, and >>>> during discussion at CalConnect last month in Zurich it came up >>>> that Google had done much the same thing themselves to handle bulk >>>> import, so I ran the idea past Lucia and put this draft together. >>>> >>>> There's still some work to do, and I'm happy to hand over >>>> authorship to somebody else if anyone wants it, or to continue >>>> working on it myself. I've renamed things to be a bit more >>>> consistent than our implementation at FastMail, but of course we'd >>>> update to match the standard once the spec is done. >>>> >>>> https://datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/ >>>> >>>> (still plenty of work to do on it, but the bones are there) >>>> >>>> I believe this is within the scope of this group's existing charter >>>> and would like to see it adopted. >>>> >>>> Regards, >>>> >>>> Bron. >>>> >>>> -- >>>>   Bron Gondwana, CEO, FastMail Pty Ltd >>>> brong@fastmailteam.com >>>> >>>> >>>> >>>> _______________________________________________ >>>> calsify mailing list >>>> calsify@ietf.org >>>> https://www.ietf.org/mailman/listinfo/calsify >>>> >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >>> >> >> -- >>   Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > -- > Ken Murchison > Cyrus Development Team > FastMail US LLC > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------F7E880B5A983453FB71E4B3D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I think it probably would bear some investigation.

I suspect the bulk import would work better for the special cases you mentioned.

My recollection is that you get some sort of per record status and that would be helpful.

Maybe we should talk about this - I see some other less importy uses - for example updating a whole bunch of related resources. That gets very messy if it has to be done as a bunch of requests and one of them fails.

On 3/26/19 07:16, Ken Murchison wrote:

To clarify, I implemented bulk import only.  I haven't implemented bulk update.


On 3/26/19 5:54 AM, Bron Gondwana wrote:
Thanks Mike - sorry about the delay in replying.

Do you think we should progress bulk-change as a separate document, or merge it into scheduling controls?

Ken implemented it in the Cyrus IMAPd server, but we aren't using it ourselves.  I guess you could "bulk update" a single item to avoid scheduling as an alternative method.

Bron.

On Sat, Mar 9, 2019, at 07:38, Michael Douglass wrote:

Cyrus wrote a spec for bulk import/updates

https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calendarserver-bulk-change.xml

I have the impression it's used but not certain.

The spec says nothing about scheduling.

On 3/8/19 07:07, Bron Gondwana wrote:
It's a bit cheeky asking this as a recent chair myself, but I had started work on this document as a purely FastMail suggestion, and during discussion at CalConnect last month in Zurich it came up that Google had done much the same thing themselves to handle bulk import, so I ran the idea past Lucia and put this draft together.

There's still some work to do, and I'm happy to hand over authorship to somebody else if anyone wants it, or to continue working on it myself.  I've renamed things to be a bit more consistent than our implementation at FastMail, but of course we'd update to match the standard once the spec is done.


(still plenty of work to do on it, but the bones are there)

I believe this is within the scope of this group's existing charter and would like to see it adopted.

Regards,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com



_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
_______________________________________________
calsify mailing list


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com



_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------F7E880B5A983453FB71E4B3D-- From nobody Tue Mar 26 09:41:32 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3448E12047D for ; Tue, 26 Mar 2019 09:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=zVeWFPWt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lfWSdfBY 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 LedA0eecro0P for ; Tue, 26 Mar 2019 09:41:28 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91D88120407 for ; Tue, 26 Mar 2019 09:41:28 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 9B1AE23128 for ; Tue, 26 Mar 2019 12:41:26 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 26 Mar 2019 12:41:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm2; bh=r9MTBetRWJHbCpAfydZNxMkX+0e 840KnobMSo9wTe/M=; b=zVeWFPWt1d5OKvz1NtNcH4t4MI1baxwI8JbLpTXFktR 2EIYqDG2Zj0bWqbeuYtVT0APZfzWoPtvA4vmjUDR8Y0ozpz5u7XAbcb2H1/nS2b1 ww2BGVFHkg/qp4DSdPItcC9y0brOnD2Tc7Tm9mqBskUkf3OfaZj+aK7009kWk/A0 m7FBaO9t/RtKct7D7aObuWAuq2yLtE6K+EZUWTMD8FXIWBOxHRvXVk/2JIdZQRt+ Fb2AKXYBPfoY/tDnuqW5jsIpQR7xkFbKTzhR8XRz+NFdhpFjB58aX8hd53fndMLi QhcYO2RCSTJkTdn7GA15/zIXxxCv9Ybr9ye3Ev98H2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=r9MTBe tRWJHbCpAfydZNxMkX+0e840KnobMSo9wTe/M=; b=lfWSdfBYnTn0fJxLdrsESS Te2RPBXyHGk51Iud1QUXn6Cg5yd0q2G8X2X3Doj+H8e4Do5uaoP7XeBCGf6vL/LJ Kj+XYaJlyPdx+ojNHJ2c56atYAFnzuML24ke6JzWg9s0CkTAQ0PsP2uucyNuWC2m 6B6LZWEOf6bHgS3sx67ONJWREnmFMRrMv9P8KSPvpKzdKlXUSsN/yJ0hQ0xZv2/7 Oy4pIoNWw8FMjVooygStoBrTBr5W3VcjYtY0zHdxUEzb52E8o1OQCaVlz74MpX8z fN2qea5hdJppEiGlFJUoy+Kd622wESLRPv2rlLgU20f2j2Rp3uJDg66RB7Ay21cw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedtgdekkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhohfkffgfgggjtgesmhdtre ertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrd horhhgnecukfhppedujeegrddvvdegrddufedtrdeijeenucfrrghrrghmpehmrghilhhf rhhomhepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhmnecuvehluhhsthgvrhfuihiivg eptd X-ME-Proxy: Received: from localhost.localdomain (67.sub-174-224-130.myvzw.com [174.224.130.67]) by mail.messagingengine.com (Postfix) with ESMTPA id 9BEDBE442F for ; Tue, 26 Mar 2019 12:41:25 -0400 (EDT) To: calsify@ietf.org References: <3bc83990-7ffe-45ff-81f7-ac5c987d45fa@www.fastmail.com> <6474185c-9f34-7cbe-8875-790cb866058e@fastmail.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <89e06e3c-d617-e198-5c69-e502045355a9@fastmail.com> Date: Tue, 26 Mar 2019 12:41:24 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------913199692E7909217DD2FC0E" Content-Language: en-US Archived-At: Subject: Re: [calsify] Request for adoption: draft-gondwana-caldav-scheduling-controls X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 16:41:31 -0000 This is a multi-part message in MIME format. --------------913199692E7909217DD2FC0E Content-Type: multipart/alternative; boundary="------------928D25965D0E9E2FCCCA7469" --------------928D25965D0E9E2FCCCA7469 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 3/26/19 12:39 PM, Michael Douglass wrote: > > I think it probably would bear some investigation. > > I suspect the bulk import would work better for the special cases you > mentioned. > > My recollection is that you get some sort of per record status and > that would be helpful. > Yes, bulk import as defined in the Daboo draft uses a 207 (Multi-status) response. > Maybe we should talk about this - I see some other less importy uses - > for example updating a whole bunch of related resources. That gets > very messy if it has to be done as a bunch of requests and one of them > fails. > > On 3/26/19 07:16, Ken Murchison wrote: >> >> To clarify, I implemented bulk import only.  I haven't implemented >> bulk update. >> >> >> On 3/26/19 5:54 AM, Bron Gondwana wrote: >>> Thanks Mike - sorry about the delay in replying. >>> >>> Do you think we should progress bulk-change as a separate document, >>> or merge it into scheduling controls? >>> >>> Ken implemented it in the Cyrus IMAPd server, but we aren't using it >>> ourselves.  I guess you could "bulk update" a single item to avoid >>> scheduling as an alternative method. >>> >>> Bron. >>> >>> On Sat, Mar 9, 2019, at 07:38, Michael Douglass wrote: >>>> >>>> Cyrus wrote a spec for bulk import/updates >>>> >>>> https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calendarserver-bulk-change.xml >>>> >>>> I have the impression it's used but not certain. >>>> >>>> The spec says nothing about scheduling. >>>> >>>> On 3/8/19 07:07, Bron Gondwana wrote: >>>>> It's a bit cheeky asking this as a recent chair myself, but I had >>>>> started work on this document as a purely FastMail suggestion, and >>>>> during discussion at CalConnect last month in Zurich it came up >>>>> that Google had done much the same thing themselves to handle bulk >>>>> import, so I ran the idea past Lucia and put this draft together. >>>>> >>>>> There's still some work to do, and I'm happy to hand over >>>>> authorship to somebody else if anyone wants it, or to continue >>>>> working on it myself.  I've renamed things to be a bit more >>>>> consistent than our implementation at FastMail, but of course we'd >>>>> update to match the standard once the spec is done. >>>>> >>>>> https://datatracker.ietf.org/doc/draft-gondwana-caldav-scheduling-controls/ >>>>> >>>>> (still plenty of work to do on it, but the bones are there) >>>>> >>>>> I believe this is within the scope of this group's existing >>>>> charter and would like to see it adopted. >>>>> >>>>> Regards, >>>>> >>>>> Bron. >>>>> >>>>> -- >>>>>   Bron Gondwana, CEO, FastMail Pty Ltd >>>>> brong@fastmailteam.com >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> calsify mailing list >>>>> calsify@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/calsify >>>>> >>>> _______________________________________________ >>>> calsify mailing list >>>> calsify@ietf.org >>>> https://www.ietf.org/mailman/listinfo/calsify >>>> >>> >>> -- >>>   Bron Gondwana, CEO, FastMail Pty Ltd >>> brong@fastmailteam.com >>> >>> >>> >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >> -- >> Ken Murchison >> Cyrus Development Team >> FastMail US LLC >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team FastMail US LLC --------------928D25965D0E9E2FCCCA7469 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 3/26/19 12:39 PM, Michael Douglass wrote:

I think it probably would bear some investigation.

I suspect the bulk import would work better for the special cases you mentioned.

My recollection is that you get some sort of per record status and that would be helpful.


Yes, bulk import as defined in the Daboo draft uses a 207 (Multi-status) response.



Maybe we should talk about this - I see some other less importy uses - for example updating a whole bunch of related resources. That gets very messy if it has to be done as a bunch of requests and one of them fails.

On 3/26/19 07:16, Ken Murchison wrote:

To clarify, I implemented bulk import only.  I haven't implemented bulk update.


On 3/26/19 5:54 AM, Bron Gondwana wrote:
Thanks Mike - sorry about the delay in replying.

Do you think we should progress bulk-change as a separate document, or merge it into scheduling controls?

Ken implemented it in the Cyrus IMAPd server, but we aren't using it ourselves.  I guess you could "bulk update" a single item to avoid scheduling as an alternative method.

Bron.

On Sat, Mar 9, 2019, at 07:38, Michael Douglass wrote:

Cyrus wrote a spec for bulk import/updates

https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/calendarserver-bulk-change.xml

I have the impression it's used but not certain.

The spec says nothing about scheduling.

On 3/8/19 07:07, Bron Gondwana wrote:
It's a bit cheeky asking this as a recent chair myself, but I had started work on this document as a purely FastMail suggestion, and during discussion at CalConnect last month in Zurich it came up that Google had done much the same thing themselves to handle bulk import, so I ran the idea past Lucia and put this draft together.

There's still some work to do, and I'm happy to hand over authorship to somebody else if anyone wants it, or to continue working on it myself.  I've renamed things to be a bit more consistent than our implementation at FastMail, but of course we'd update to match the standard once the spec is done.


(still plenty of work to do on it, but the bones are there)

I believe this is within the scope of this group's existing charter and would like to see it adopted.

Regards,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com



_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
_______________________________________________
calsify mailing list


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com



_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------928D25965D0E9E2FCCCA7469-- --------------913199692E7909217DD2FC0E Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------913199692E7909217DD2FC0E-- From nobody Wed Mar 27 11:09:28 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7439E120321 for ; Wed, 27 Mar 2019 11:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=bimGA712; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rNIH6Vx2 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 aggB0I85s6Uq for ; Wed, 27 Mar 2019 11:09:24 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4291312031D for ; Wed, 27 Mar 2019 11:09:24 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 5D39021B8B for ; Wed, 27 Mar 2019 14:09:23 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute6.internal (MEProxy); Wed, 27 Mar 2019 14:09:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm2; bh=iE2fblqqcJyTyDo4XXRM4TGrjP2MvP6NBew05nL l+zw=; b=bimGA712UQi/yuwYZ0PXSlvliQ2mfpznPO8j0c2b4yMvDfp0E409GQ5 CgkW0oGjpBJTo9iXvn4eLCGJuJDOCFkO7qYLLeBGAHbTindvpak316wKxazuMIhU y48Dl4GQDHDYbbw3fwtSd2idNH1T0d1COoOZULO6R1xH7b0btUmdS+r8o6L9fBma XjfbkCRgVNYX9IwajXQd1oekVGkN+NYmX6lUvOM9ES3B0wGEqHKcBjd8HgiuiPK+ O2Gmsxh/gvku8l+884+LzpQtUP81nbdk/Lsf7gDX5NHLTEMAI5HYsGPNNS6KGlXm mPkc/qG2HqIcBwjWTJWhPRJl6LbDz3Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=iE2fblqqcJyTyDo4XXRM4TGrjP2Mv P6NBew05nLl+zw=; b=rNIH6Vx2YWN9gvxHdjvDQxtrFEm025G9oIx8FpCUYUsk/ jKmOiKuIxwTukn2KILz5TcmO3kpqjA8GfAG+Nr8ysmT7QvR5jHX6KuA9tcViSKSg c+kN4EL8CBghIvfjAiUMmr483ERvkdqHuC7zX2qWh6xSlkt6lO5APeBJHsUCZlyX C2C6VgWY5t9TI+KuX0NkXsH3Zdx8R8+PZGJARKXlIILYaMhrRDqOS/+9k/1ZdG8D C1R9EnL2/Xk54Ab5cCTxa45uQnz1nxkxM0iTR+WkdaW1Okv6bVkVnF3clYqN6eTN XpQLyUslMuMDlhiGC/Rl7XR0BKZ70l+Knli0ZOfUA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedvgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucfrrghrrghmpehmrghilhhfrhhomhepsghroh hnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CCBA820578; Wed, 27 Mar 2019 14:09:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-328-g40d9e92-fmstable-20190325v1 Mime-Version: 1.0 X-Me-Personality: 56629417 x-forwarded-message-id: <155370975513.10385.7730189669232648712.idtracker@ietfa.amsl.com> Message-Id: <1e5f0d3b-d293-43a1-90ca-661c34c7c6c0@www.fastmail.com> Date: Wed, 27 Mar 2019 14:09:22 -0400 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=77c0aad905394572a12ec3c8052d7ffc Archived-At: Subject: [calsify] Fwd: Personnel change for calext WG X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 18:09:26 -0000 --77c0aad905394572a12ec3c8052d7ffc Content-Type: text/plain Thanks Alexey for your work as our AD, and welcome Barry! Regards, Bron. ----- Original message ----- From: IETF Secretariat To: barryleiba@computer.org, iesg-secretary@ietf.org, calext-chairs@ietf.org, aamelnikov@fastmail.fm Subject: Personnel change for calext WG Date: Thursday, March 28, 2019 05:02 Shepherding AD added: Barry Leiba Shepherding AD deleted: Alexey Melnikov -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --77c0aad905394572a12ec3c8052d7ffc Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks Alexey for your work as our AD, and welcome Barry!<= br>

Regards,

B= ron.

----- Original message -----
From: IETF Secretariat <ietf-secretariat-reply@ie= tf.org>
To: barryleiba@com= puter.org, iesg-secretary@ietf.org, calext-chairs@ietf.org, aamelnikov@f= astmail.fm
Subject: Personnel= change for calext WG
Date: T= hursday, March 28, 2019 05:02

Shepherding AD added: Barry Leiba <barryleiba@computer= .org>
Shepherding AD delet= ed: Alexey Melnikov <aamelnikov@fastmail.fm>

<= br>
--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com

<= br>
--77c0aad905394572a12ec3c8052d7ffc-- From nobody Wed Mar 27 11:11:24 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D4712032D for ; Wed, 27 Mar 2019 11:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=PxPfDgst; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JlfTLpZ/ 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 mFMIM1LvSK5Z for ; Wed, 27 Mar 2019 11:11:19 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D7F120389 for ; Wed, 27 Mar 2019 11:11:10 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C680821D4E for ; Wed, 27 Mar 2019 14:11:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 27 Mar 2019 14:11:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm2; bh=XFyejiLkFrgDD4J2INRso4d3xUf 644ZnUvRMA/5H6ac=; b=PxPfDgstud1YnZy6QrikeR6yEzJzH5jaW1zempGGOGH ccicyotbUZEvf3ubaz/xI6SPBWOBS+gFuBGAg4w9OB2zvmsJCCpysCKZpVCt8w2y QpNZtpFE0oY07C2c/I7UJuDZi2kzOVqAZdtiDghFfeSWY0A3nGzEjoIQ1sQf98Bj 4poO+ezrTnhW+JVVMNtIVaNrfDylN5NkmEl5eF67gOxKRx+u7ffOkOlAhyW40PhU GFMtmSpeYrPTgXJ/imxVvxWoJEuDASSddxH2StvHmROGSr5iKPFb8TfKMLO47Hrp GLDAfmJl3nnmIwfHBtBPXulb7RVt301XkTV2P38e5TQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=XFyeji LkFrgDD4J2INRso4d3xUf644ZnUvRMA/5H6ac=; b=JlfTLpZ/+pLHkCPDT/E1Ow a5Eaw+s0zp8WtN+mJ/8MQ9M6hnAMiPrQ0mM+3/LhKl99DPHwtLMDWL2/IeBYS4N+ jLOPX6JBEUQ042n8Ylx1jovlAVwE0XzgIcv2Qjla2mudatNeDnjAGe/komfnphE+ MhKZpyTC4GHukewmSt/jAwAnwOYPekgmnYqg/Uc6T7V6WHR+mr5nl6M6oaoXPaA+ YOkoQVfaFDobk62dMsEs/Nk0TFYcdaCTCysXiJtJkX/qBTKoaFFCO4swr9ZTwT9q eXgauewAZR2VCIWDoSBkZ4XED/B7mwyUYi8ZiiHaqAgehEx4C3nqAqxjBkEz7xiQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrkedvgddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhfhokffffgggjggtsehmtd erredtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeejge drjeejrdekhedrvdehtdenucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgr shhtmhgrihhlrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from localhost.localdomain (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id CB2B71031A for ; Wed, 27 Mar 2019 14:11:06 -0400 (EDT) To: calsify@ietf.org References: <1e5f0d3b-d293-43a1-90ca-661c34c7c6c0@www.fastmail.com> From: Ken Murchison Organization: FastMail US LLC Message-ID: <5badd170-e90d-9755-5b4c-d49c6c67a378@fastmail.com> Date: Wed, 27 Mar 2019 14:11:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <1e5f0d3b-d293-43a1-90ca-661c34c7c6c0@www.fastmail.com> Content-Type: multipart/mixed; boundary="------------9A3EFDB5C972FE255DA9FF38" Content-Language: en-US Archived-At: Subject: Re: [calsify] Fwd: Personnel change for calext WG X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 18:11:23 -0000 This is a multi-part message in MIME format. --------------9A3EFDB5C972FE255DA9FF38 Content-Type: multipart/alternative; boundary="------------2E75D750DD349EACFCC5AFF0" --------------2E75D750DD349EACFCC5AFF0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I second both sentiments. On 3/27/19 2:09 PM, Bron Gondwana wrote: > Thanks Alexey for your work as our AD, and welcome Barry! > > Regards, > > Bron. > > ----- Original message ----- > From: IETF Secretariat > To: barryleiba@computer.org, iesg-secretary@ietf.org, > calext-chairs@ietf.org, aamelnikov@fastmail.fm > Subject: Personnel change for calext WG > Date: Thursday, March 28, 2019 05:02 > > Shepherding AD added: Barry Leiba > Shepherding AD deleted: Alexey Melnikov > > > -- >   Bron Gondwana, CEO, FastMail Pty Ltd >   brong@fastmailteam.com > > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team FastMail US LLC --------------2E75D750DD349EACFCC5AFF0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I second both sentiments.



On 3/27/19 2:09 PM, Bron Gondwana wrote:
Thanks Alexey for your work as our AD, and welcome Barry!

Regards,

Bron.

----- Original message -----
From: IETF Secretariat <ietf-secretariat-reply@ietf.org>
Subject: Personnel change for calext WG
Date: Thursday, March 28, 2019 05:02

Shepherding AD added: Barry Leiba <barryleiba@computer..org>
Shepherding AD deleted: Alexey Melnikov <aamelnikov@fastmail.fm>


--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com



_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC
--------------2E75D750DD349EACFCC5AFF0-- --------------9A3EFDB5C972FE255DA9FF38 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------9A3EFDB5C972FE255DA9FF38-- From nobody Wed Mar 27 11:16:33 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1626120315 for ; Wed, 27 Mar 2019 11:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 KV-vk751_lda for ; Wed, 27 Mar 2019 11:16:30 -0700 (PDT) Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com [209.85.208.177]) (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 0EB97120255 for ; Wed, 27 Mar 2019 11:16:28 -0700 (PDT) Received: by mail-lj1-f177.google.com with SMTP id v13so15292887ljk.4 for ; Wed, 27 Mar 2019 11:16:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0dzDbK91JFEGBs1ZMrZEETVr8k0YZAYGiGAxQTPzgLQ=; b=tG2MT3gPH8uh5rXFMaqjkDUs+Aj3oAoUZJGNKtU8wWP4E8FVPvmj9WPLHYAdjhw9Nk gWOBVSlkDZAaSRXxlGMan/BQaxmNEHE8feQk42kIcuPTpWkgXsdkHODGmDd7nbmX1+ti 7Q7Cyxxhgnsp781nh0WEbgNHuJHHJB5B0x5kLLXBHcGDzPG/qoBwlTygL6aBedNrZglX kbw2M8+QmaEoLEebwfST09zNJ9d18D4kx/88TyiAOxMcTrfa+xqxR52CFAbqeg9j8Pej qjZStQcV731MDoKsC+FqBPRiXckmc8kG0n+q/NCFnPDEc6vLJFKbSIrZrzhqwOOvAM0z Hzaw== X-Gm-Message-State: APjAAAWGmzZdcTaxAgTWNZet7ltV81x4a+Kxw08P+9mPXAVAdaG3R9Pe gnpp723z5zO7GoJxei+KUmu8tpCrvW7MMjv8Tf8BIoyD X-Google-Smtp-Source: APXvYqyV+52uXhxLWn33ti+oUEQ7Bu7kUwg147nzdn1GYE0nyi9/8VRUkmbYdY2nwCXrPmvYhfFTtJlZLPzpcNxeDaE= X-Received: by 2002:a2e:9753:: with SMTP id f19mr14440009ljj.54.1553710586204; Wed, 27 Mar 2019 11:16:26 -0700 (PDT) MIME-Version: 1.0 References: <1e5f0d3b-d293-43a1-90ca-661c34c7c6c0@www.fastmail.com> <5badd170-e90d-9755-5b4c-d49c6c67a378@fastmail.com> In-Reply-To: <5badd170-e90d-9755-5b4c-d49c6c67a378@fastmail.com> From: Daniel Migault Date: Wed, 27 Mar 2019 14:16:13 -0400 Message-ID: To: Ken Murchison Cc: IETF-Calsify Content-Type: multipart/alternative; boundary="0000000000009315cd0585176fdd" Archived-At: Subject: Re: [calsify] Fwd: Personnel change for calext WG X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 18:16:32 -0000 --0000000000009315cd0585176fdd Content-Type: text/plain; charset="UTF-8" I would like to thanks Alexey for all the special attention he provided to the WG and welcome Barry! Yours, Daniel On Wed, Mar 27, 2019 at 2:11 PM Ken Murchison wrote: > I second both sentiments. > > > > On 3/27/19 2:09 PM, Bron Gondwana wrote: > > Thanks Alexey for your work as our AD, and welcome Barry! > > Regards, > > Bron. > > ----- Original message ----- > From: IETF Secretariat > > To: barryleiba@computer.org, iesg-secretary@ietf.org, > calext-chairs@ietf.org, aamelnikov@fastmail.fm > Subject: Personnel change for calext WG > Date: Thursday, March 28, 2019 05:02 > > Shepherding AD added: Barry Leiba > > Shepherding AD deleted: Alexey Melnikov > > > > -- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam.com > > > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify > > -- > Ken Murchison > Cyrus Development Team > FastMail US LLC > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --0000000000009315cd0585176fdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to thanks Alexey=C2=A0for al= l the special attention he provided to the WG and welcome Barry!=C2=A0
Yours,=C2=A0
Daniel

On Wed, Mar 27, 2019 at 2:11 PM Ke= n Murchison <murch@fastmail.com> wrote:
=20 =20 =20

I second both sentiments.



On 3/27/19 2= :09 PM, Bron Gondwana wrote:
=20 =20 =20
Thanks Alexey for your work as our AD, and welcome Barry!

Regards,

Bron.

----- Original message -----
Subject: Personnel change for calext WG
Date: Thursday, March 28, 2019 05:02

Shepherding AD added: Barry Leiba <barrylei= ba@computer..org>
Shepherding AD deleted: Alexey Melnikov <aamelni= kov@fastmail.fm>


--
=C2=A0 Bron Go= ndwana, CEO, FastMail Pty Ltd
=C2=A0 brong@fastmailteam.com



= 
____________=
___________________________________
calsify mailing list
calsify@ietf.org
https://www.ie=
tf.org/mailman/listinfo/calsify

--=
=20
Ken Murchison
Cyrus Development Team
FastMail US LLC
_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--0000000000009315cd0585176fdd-- From nobody Wed Mar 27 11:17:31 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C05D120255 for ; Wed, 27 Mar 2019 11:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=calconnect.org 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 fQli4hU2xrVm for ; Wed, 27 Mar 2019 11:17:27 -0700 (PDT) Received: from bonobo.maple.relay.mailchannels.net (bonobo.maple.relay.mailchannels.net [23.83.214.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE3B120315 for ; Wed, 27 Mar 2019 11:17:27 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|dave.thewlis@calconnect.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 017BE3E510C; Wed, 27 Mar 2019 18:17:26 +0000 (UTC) Received: from pdx1-sub0-mail-a40.g.dreamhost.com (unknown [100.96.28.55]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 88E7E3E19CA; Wed, 27 Mar 2019 18:17:25 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|dave.thewlis@calconnect.org Received: from pdx1-sub0-mail-a40.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 27 Mar 2019 18:17:25 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|dave.thewlis@calconnect.org X-MailChannels-Auth-Id: dreamhost X-Coil-Sponge: 48c9d93b3085ff2c_1553710645822_1502789201 X-MC-Loop-Signature: 1553710645822:160608301 X-MC-Ingress-Time: 1553710645822 Received: from pdx1-sub0-mail-a40.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a40.g.dreamhost.com (Postfix) with ESMTP id 1E22980C78; Wed, 27 Mar 2019 11:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=calconnect.org; h= content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; s=calconnect.org; bh=zG351nMQ0xiIi0Jk A0S/AKLGZOM=; b=RgMpsid12dXDNjpuNrHILSuRq5YJKlZTidnnFsZW9/L+BNyp jQKWCHygXVTf2Xo7RQHZcG9QKNKST0QicX5PMbMEZ4CjHU0N3bcXSKA8KoEESjXD fcasNEAAq+tmkdoabVbRqlsEOMtHr1E8OLOldaj/Sq3Jpazr0Hl1UjLzTzs= Received: from [192.168.0.218] (47-208-67-174.erkacmtk02.res.dyn.suddenlink.net [47.208.67.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: dave.thewlis@calconnect.org) by pdx1-sub0-mail-a40.g.dreamhost.com (Postfix) with ESMTPSA id BA60683412; Wed, 27 Mar 2019 11:17:23 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C9EEF7CA-83A4-46AA-868A-787CC725861F" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) X-DH-BACKEND: pdx1-sub0-mail-a40 From: David Thewlis In-Reply-To: <5badd170-e90d-9755-5b4c-d49c6c67a378@fastmail.com> Date: Wed, 27 Mar 2019 11:17:23 -0700 Cc: calsify@ietf.org Message-Id: References: <1e5f0d3b-d293-43a1-90ca-661c34c7c6c0@www.fastmail.com> <5badd170-e90d-9755-5b4c-d49c6c67a378@fastmail.com> To: Ken Murchison X-Mailer: Apple Mail (2.3445.102.3) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrkedvgddutdegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurheptggguffhjgffkfhfvffosegrtdhmrehhtdejnecuhfhrohhmpeffrghvihguucfvhhgvfihlihhsuceouggrvhgvrdhthhgvfihlihhssegtrghltghonhhnvggtthdrohhrgheqnecuffhomhgrihhnpegtrghltghonhhnvggtthdrohhrghdpihgvthhfrdhorhhgnecukfhppeegjedrvddtkedrieejrddujeegnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopegludelvddrudeikedrtddrvddukegnpdhinhgvthepgeejrddvtdekrdeijedrudejgedprhgvthhurhhnqdhprghthhepffgrvhhiugcuvfhhvgiflhhishcuoegurghvvgdrthhhvgiflhhishestggrlhgtohhnnhgvtghtrdhorhhgqedpmhgrihhlfhhrohhmpegurghvvgdrthhhvgiflhhishestggrlhgtohhnnhgvtghtrdhorhhgpdhnrhgtphhtthhopegurghvvgdrthhhvgiflhhishestggrlhgtohhnnhgvtghtrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [calsify] Fwd: Personnel change for calext WG X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2019 18:17:30 -0000 --Apple-Mail=_C9EEF7CA-83A4-46AA-868A-787CC725861F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 > On Mar 27, 2019, at 11:11, Ken Murchison wrote: >=20 > I second both sentiments. >=20 >=20 >=20 >=20 >=20 > On 3/27/19 2:09 PM, Bron Gondwana wrote: >> Thanks Alexey for your work as our AD, and welcome Barry! >>=20 >> Regards, >>=20 >> Bron. >>=20 >> ----- Original message ----- >> From: IETF Secretariat = >> To: barryleiba@computer.org , = iesg-secretary@ietf.org , = calext-chairs@ietf.org , = aamelnikov@fastmail.fm >> Subject: Personnel change for calext WG >> Date: Thursday, March 28, 2019 05:02 >>=20 >> Shepherding AD added: Barry Leiba = >> Shepherding AD deleted: Alexey Melnikov = >>=20 >>=20 >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify = > --=20 > Ken Murchison > Cyrus Development Team > FastMail US LLC > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Dave Thewlis, Executive Director CalConnect - The Calendaring and Scheduling Consortium +1 707 840 9391 voice | +1 707 498 2238 mobile | +1 415 946 3454 fax http://www.calconnect.org | Dave.Thewlis@calconnect.org --Apple-Mail=_C9EEF7CA-83A4-46AA-868A-787CC725861F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1


On Mar = 27, 2019, at 11:11, Ken Murchison <murch@fastmail.com> = wrote:

=20 =20

I = second both sentiments.



On 3/27/19 2:09 PM, Bron Gondwana wrote:
Thanks Alexey for = your work as our AD, and welcome Barry!

Regards,
=

Bron.

----- Original = message -----
From: IETF = Secretariat <ietf-secretariat-reply= @ietf.org>
To: barryleiba@computer.org, iesg-secretary@ietf.org, calext-chairs@ietf.org, aamelnikov@fastmail.fm
Subject: Personnel = change for calext WG
Date: Thursday, March = 28, 2019 05:02


--
  Bron Gondwana, CEO, FastMail Pty = Ltd
  brong@fastmailteam.com



_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.or=
g/mailman/listinfo/calsify

--=20
Ken Murchison
Cyrus Development Team
FastMail US LLC
<murch.vcf>__= _____________________________________________
calsify = mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify


--
Dave Thewlis, Executive Director
CalConnect - The Calendaring and = Scheduling Consortium
+1 707 840 9391 voice | +1 = 707 498 2238 mobile | +1 415 946 3454 fax
http://www.calconnect.org | Dave.Thewlis@calconnect.org

= --Apple-Mail=_C9EEF7CA-83A4-46AA-868A-787CC725861F-- From nobody Wed Mar 27 21:01:30 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485F9120286 for ; Wed, 27 Mar 2019 21:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 K61PTbpQBUUt for ; Wed, 27 Mar 2019 21:01:26 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8640F1201EE for ; Wed, 27 Mar 2019 21:01:26 -0700 (PDT) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-07v.sys.comcast.net with ESMTP id 9Lglh3wcrtQPw9MEHht7D6; Thu, 28 Mar 2019 04:01:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1553745685; bh=VpB35M/jj1rYLff+VuKewSs7cZuRLHHXWi/Xl0tU4HY=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=ikV7W8G6RVNXOu+ycNnPd8h77D1u5uz12io/Oy/bKPzQ37NtjRUxGQ7QDuaGUSTxv jtTJJ8M8rOKzZ1h27WnIFEXmiQ2AdKi/yigxhe+YDe0INyQl0lyDq227hL9fWqKYoT frJ4guULRyEM0tn5dLqC1IhpR+m3yR4m5nusK8zDpMwEq2gigSmJeUuMh9pLnFYvnJ 9/HPcZBdxzGMmdp601FoFD7T8SScWXuYTZcQySbKMzq5ZGA4443qYAx+IITyISgeHz y/ffdEGbSQ+w8e+awDRklUWR8qd1MQGE2w9pVgBDmaiy3+1GMiiWn5K67MzK5uiHrc giVDaXSXd2rkA== Received: from THARE ([98.192.130.240]) by resomta-po-02v.sys.comcast.net with ESMTPA id 9MEGhOE6H8DRM9MEHh0bE7; Thu, 28 Mar 2019 04:01:25 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedutddrkeefgdejjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfggtgfothesrgdtghepvddtvdenucfhrhhomhepfdfvihhmucfjrghrvgdfuceovfhimhfjrghrvgestghomhgtrghsthdrnhgvtheqnecukfhppeelkedrudelvddrudeftddrvdegtdenucfrrghrrghmpehhvghlohepvffjteftgfdpihhnvghtpeelkedrudelvddrudeftddrvdegtddpmhgrihhlfhhrohhmpehtihhmhhgrrhgvsegtohhmtggrshhtrdhnvghtpdhrtghpthhtoheptggrlhhsihhfhiesihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd X-Xfinity-VMeta: sc=0;st=legit From: "Tim Hare" To: Date: Thu, 28 Mar 2019 00:01:23 -0400 Message-ID: <06d001d4e51a$e94a7b70$bbdf7250$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06D1_01D4E4F9.623B2560" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdTlGr5VDB2Sz9hpTeScq5Gbb+D/1g== Content-Language: en-us Archived-At: Subject: [calsify] A few questions X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 04:01:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06D1_01D4E4F9.623B2560 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 1. Does CalConnect have any guidance on a "discovery mechanism" for discovering an iCalendar "feed" for a website? Something like or something like an icon and link as is used for RSS? 2. Are there guidelines/recommendations for organizations publishing calendar information? Thanks Tim Hare Interested Bystander, Non-Inc. ------=_NextPart_000_06D1_01D4E4F9.623B2560 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1.       = Does CalConnect have any guidance on a = “discovery mechanism” for discovering an iCalendar = “feed” for a website?  Something like <link = rel=3D”calendar” href=3D >  or something like an = icon and link as is used for RSS?

2.       Are = there guidelines/recommendations for organizations publishing calendar = information?

 

Thanks
Tim Hare
Interested Bystander, = Non-Inc.

------=_NextPart_000_06D1_01D4E4F9.623B2560-- From nobody Wed Mar 27 21:17:39 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE757120158 for ; Wed, 27 Mar 2019 21:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CyNEm7OLZHJa for ; Wed, 27 Mar 2019 21:17:36 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 E6987120196 for ; Wed, 27 Mar 2019 21:17:35 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id h39so21627345qte.2 for ; Wed, 27 Mar 2019 21:17:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=bQo5vPEWLvaCvz9ypeLXoF1cJr3QimotsLP35dlW4Vc=; b=mfdYTldYR1dxX7W3EhGMqGzAToQ2+Xu20OuF7Ug9bqPsMPgYNxWHFnGI3O3A+ZGXeq mGz96Fz01KSEQSnrcj68Ka3QBzcd+k2EhqgvLAJFzZXncbCTbhEPOKhSSmpoZbMe7Gqb GYLH/lzTCOAAR2mKICBcwNZw16iX/aR9hvH2NLZCm9Bxw2IGgGt1NJgn5BH1u/SJAzRs cpedRP61LUBafA5jsS+8/AkOwRpG0DK/Q6pMFtl7vUTdYsF/qNKT1jUH4O/noAR/rs9S EFTA8leBkBNXZjPu5UZjXIxZ+ADe/uVxkGYlmIPD5t5KPuwnDgvir33Q06VeO+RMpL1G xM2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=bQo5vPEWLvaCvz9ypeLXoF1cJr3QimotsLP35dlW4Vc=; b=sANMFE+CTsRYJavNJxMlklym42Fvoh8F2nkxGJgyEwxJqmhrB5sMK8ssO42G24XpTj m2awK91Xc8ZFQC7PfcQS92RnclwEOvwdf1/+PFGa0b0FN1xpcztL9pVkhZ3K9rNpQc3E NdAAoo8etv7pGc2lJ0rOlamM+reJt6qqCb9N8Oc4u8CY3Om02RqTAiEqG+f58usY9ZtM NGdGvLwTz4t/5/fKRexDLVpk1YA9Z7PO426AdSJ+lU5GT8j5+b6nIqvtFOwRf29rfUZY ScuUQKRYO8Y9FNfK3nwoisHkScl8HYvTrWT4+YZ4zF8EmMbEffzUBYcNQVE71anb1BD+ /6dQ== X-Gm-Message-State: APjAAAX8YIO6Y8GnPfxNwzojiL5lCx3nCvACECi+OAZvtuj6QY/t0irs CLddilmcrS38EPDWxRO6BeLZbl1MV+E= X-Google-Smtp-Source: APXvYqwkYdck4bazNQyoPjlVLgKIGKRPnBcqLZ7FNDKJzGZc6qWq6VDfOa2/mkl2SYN3GHaR6yxYGw== X-Received: by 2002:ac8:14c:: with SMTP id f12mr34488493qtg.138.1553746654988; Wed, 27 Mar 2019 21:17:34 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id i24sm8401381qtm.3.2019.03.27.21.17.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 21:17:34 -0700 (PDT) To: calsify@ietf.org References: <06d001d4e51a$e94a7b70$bbdf7250$@comcast.net> From: Michael Douglass Message-ID: <03bcbbe4-d814-0104-5320-b9b04e92b38d@gmail.com> Date: Thu, 28 Mar 2019 00:17:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <06d001d4e51a$e94a7b70$bbdf7250$@comcast.net> Content-Type: multipart/alternative; boundary="------------2F38CF9D073E41F66EB582EE" Content-Language: en-US Archived-At: Subject: Re: [calsify] A few questions X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 04:17:38 -0000 This is a multi-part message in MIME format. --------------2F38CF9D073E41F66EB582EE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 3/28/19 00:01, Tim Hare wrote: > > 1.Does CalConnect have any guidance on a discovery mechanism for > discovering an iCalendar feed for a website? Something like rel=calendar href= > or something like an icon and link as is used > for RSS? > We are actually working on exactly that. We have the outlines of a query that will return interesting public calendars. Something like - send a query with the terms "baseball movies" and you get a response back showing a sorted result of matching calendars (possibly 0 in that case) > 2.Are there guidelines/recommendations for organizations publishing > calendar information? > Looks like we don't - but this https://devguide.calconnect.org/Table-of-Contents/ would be the place to put it. > Thanks > Tim Hare > Interested Bystander, Non-Inc. > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------2F38CF9D073E41F66EB582EE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 3/28/19 00:01, Tim Hare wrote:

1. Does CalConnect have any guidance on a discovery mechanism for discovering an iCalendar feed for a website? Something like <link rel=calendar href= > or something like an icon and link as is used for RSS?


We are actually working on exactly that. We have the outlines of a query that will return interesting public calendars.

Something like - send a query with the terms "baseball movies" and you get a response back showing a sorted result of matching calendars (possibly 0 in that case)


2. Are there guidelines/recommendations for organizations publishing calendar information?

Looks like we don't - but this

https://devguide.calconnect.org/Table-of-Contents/

would be the place to put it.


Thanks
Tim Hare
Interested Bystander, Non-Inc.


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------2F38CF9D073E41F66EB582EE-- From nobody Thu Mar 28 05:06:21 2019 Return-Path: X-Original-To: calsify@ietf.org Delivered-To: calsify@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3154120479; Thu, 28 Mar 2019 05:05:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , brong@fastmailteam.com, calext-chairs@ietf.org, draft-ietf-calext-caldav-attachments@ietf.org, calsify@ietf.org, alexey.melnikov@isode.com, Bron Gondwana , rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155377475873.1422.11116663611014594690.idtracker@ietfa.amsl.com> Date: Thu, 28 Mar 2019 05:05:58 -0700 Archived-At: Subject: [calsify] Document Action: 'CalDAV Managed Attachments' to Informational RFC (draft-ietf-calext-caldav-attachments-04.txt) X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2019 12:06:07 -0000 The IESG has approved the following document: - 'CalDAV Managed Attachments' (draft-ietf-calext-caldav-attachments-04.txt) as Informational RFC This document is the product of the Calendaring Extensions Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-caldav-attachments/ Technical Summary This specification defines an extension to the calendar access protocol (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server. The attachments are not stored inline in the RFC5545 ATTACH property, but instead a link is created in a managed fashion. Working Group Summary Version -00 was created in October 2016. As far as I can see there have been no major discussions on the calsify mailing list until draft -01 was uploaded. At this point, multiple vendors have voiced their support and indicated that they have implemented this draft on their servers. The document originates from draft-daboo-caldav-attachments, which was originally created in 2011. Since then the document has been discussed and developed within the CalConnect organization among relevant vendors in the sector. Some concerns were raised by ARTART reviewer about use of HTTP. As this specification has multiple interoperable implementations, the decision was made to downgrade it to Informational specification. Document Quality Multiple vendors have indicated that they have already implemented this draft and successfully tested it with clients. The operations of this draft are part of the CalDAVTester suite, which is being run by multiple vendors during CalConnect interoperability testing sessions. Personnel The Document Shepard is Philipp Kewisch, the Responsible Area Director is Alexey Melnikov. From nobody Thu Mar 28 21:49:46 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F23120195 for ; Thu, 28 Mar 2019 21:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Hoe7MQMIhD1U for ; Thu, 28 Mar 2019 21:49:41 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 72E2F1201AB for ; Thu, 28 Mar 2019 21:49:41 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id t28so1207800qte.6 for ; Thu, 28 Mar 2019 21:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=IZMwT3qdhmLOHLJ9x8LrD/IKYgEUYO/3JIbXrZwoz+Y=; b=UdX1XBm3lqooRSSeW5xL+ALkoh6WwOYmeaNb7F6eETvMo/5y+brZ3v/I66UB5Ixy5P upwUtQmsIPIXWS4PE/aqyLeCcZRXq8L2KaiP1bjt7BeS4/fBwrBA+Q0PYYj7uIOejswy 8MvHXqiknwQD7VbWF5BkqhcKSbQKyuHy73yVyquMVPIjo4tSWH4Uq9efglw67I2ghvSi sW2xllQTA9PUQiFY5MCoGLQoHonWBNCae6pQYg/N6uwbUkwnux/xy1p4lJnII/PRtdIo w3vJjF/OjwNsqsjeEpG2RmYjYXfRo1LGX21XrAumticD9OtlH1Ntpnny8pTrU4nb6ZiH 3q3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=IZMwT3qdhmLOHLJ9x8LrD/IKYgEUYO/3JIbXrZwoz+Y=; b=gLK9nGA5S6B81LEfCd2ZM1m4z95fCKKdX9KgPzP0hQ5HWiH9h3m31BsSkWjEJNseT0 VuoAkGtvllBNX8q+TlREb5jfiXwra4fWTyPcdbiWwLYqko8kEtuKmG4sJzHsPKH5fG1R jkBg1IlH143fCvryOLiyeqPYQVLMEm81TzsiuHhyaTWcWram0LBltOqzn1K3iLeK6NqZ xS7FCodQDjT+uexzAeA6g1FXIOs23exPANjDtaz1UFORdh2Xl4lM1NS/fqI6P162LI7f NsHfC2eC7I9X5UrD8P7CysvR0DHI0PiEuDEEkq4dBHe2KLqWou5PnuOGUJIWN3tsnVWg DFRw== X-Gm-Message-State: APjAAAWs4q8BqkdCLgWjgpAlANqBiu3uCXUYGmZ9u4wiC4Zs51bBtNMr KUOcgQwS/c4xIxSy6mPUO0lB5DICoH8= X-Google-Smtp-Source: APXvYqwkSdXhXxYJuWILfM3UrCEJBprrSmCzRXlk46KygTtBs8D0i1p5poBF4TKI43ZhFar55qBQGw== X-Received: by 2002:ac8:355c:: with SMTP id z28mr28404340qtb.286.1553834980382; Thu, 28 Mar 2019 21:49:40 -0700 (PDT) Received: from Michaels-MacBook-Pro.local (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id o136sm688265qke.48.2019.03.28.21.49.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Mar 2019 21:49:39 -0700 (PDT) To: Alexey Melnikov Cc: calsify@ietf.org References: <009b5762-3b36-61c7-86a4-716391b6ed43@isode.com> From: Michael Douglass Message-ID: <7446205e-303e-74e5-d375-30b210f6eb39@gmail.com> Date: Fri, 29 Mar 2019 00:49:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <009b5762-3b36-61c7-86a4-716391b6ed43@isode.com> Content-Type: multipart/alternative; boundary="------------4FBB079BD98B6111DE5A904E" Content-Language: en-US Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-eventpub-extensions-10 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 04:49:45 -0000 This is a multi-part message in MIME format. --------------4FBB079BD98B6111DE5A904E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Alexey- sorry I missed this. Some questions and comments below: On 10/29/18 08:37, Alexey Melnikov wrote: > Hi, > > I've done my review of the document. Other people found some of the > same issues, so you might have already fixed some of them. > Also note that I might ask for an extra review from people more > familiar with use of geo-location in IETF protocols. > > In Section 3: XML and JSON need Informative References. The text I have is these extensions as a component rather than a property. This is a better match for the way XML and JSON handles such structures and allows richer definitions. This is just a reference to the hierarchical nature of XML and JSON rather than any particular data representation. What should I be referencing? > > In 7.3: > Due to use of RFC 2119 "SHOULD": "text/html" needs an Normative > Reference, most likely to HTML5. I have: resource is not given by the "FMTTYPE" parameter. If the media type remains unknown, calendar applications SHOULD treat it as type "text/html". > > In 7.6: >    Property Name:  STRUCTURED-DATA > >    Purpose:  This property specifies ancillary data associated with the >       calendar component. > > This is rather vague and I think this has implications for Security > Considerations (so you should mention something there), because > anything can be stuffed here, including executable content. > >    Value Type:  TEXT, BINARY or URI > > But the ABNF: > >      sdataprop   = "STRUCTURED-DATA" sdataparam >                        (":" text) / >                        ( >                          ";" "ENCODING" "=" "BASE64" >                          ";" "VALUE" "=" "BINARY" >                          ":" binary >                        ) / >                        ( >                          ";" "VALUE" "=" "URI" >                          ":" uri >                        ) >                        CRLF > > doesn't include TEXT "value" choice > > 8.1.  Participant > >    Component name:  PARTICIPANT > >    Purpose:  This component provides information about a participant in >       an event or optionally a plain text typed value. > > What does "or optionally a plain text typed value" mean here? This is > a component, not a single property. Yes - hangover from earlier. Changed to This component provides information about a participant in an event or task. > Format Definition: > >    This property is defined by the following notation: > >      participantc  = "BEGIN" ":" "PARTICIPANT" CRLF >                    partprop *alarmc >                    "END" ":" "PARTICIPANT" CRLF > > Is inclusion of "alarmc" intentional? (If it is, that is fine. I just > think I check.) That I can't remember - it has the flavor of per-user properties. However I can remove it. > >    Example: > >    The following is an example of this component.  It contains a SOURCE >    property which points to a VCARD providing information about the >    event participant. > >                      BEGIN:PARTICIPANT >                      PARTICIPANT-TYPE:PRINCIPAL_PERFORMER > > PRINCIPAL_PERFORMER is not defined as a valid value for PARTICIPANT-TYPE. > > SOURCE:http://dir.example.com/vcard/aviolinist.vcf >                      END:PARTICIPANT > > >    The following is an example for the primary contact. > >                      BEGIN: PARTICIPANT >                      SOURCE;FMTTYPE=text/vcard; > http://dir.example.com/vcard/contacts/contact1.vcf >                      PARTICIPANT-TYPE:PRIMARY-CONTACT > > PRIMARY-CONTACT is not defined either. > >                      DESCRIPTION:A contact: >                      END:PARTICIPANT Changed to PERFORMER and CONTACT > > > > In Section 9.1: > >    STRUCTURED-LOCATION;LABEL="The venue": >     http://dir.example.com/venues/big-hall.vcf >    STRUCTURED-LOCATION;LABEL="The venue": >     http://dir.example.com/venues/parking.vcf > > Should different instances have different LABEL values? Done in v-11 > > > > 11.  Privacy Considerations > > I think this section needs to talk about unintended exposure of Geo > location. > Could you elaborate - are we talking about geo location of participants? That's beginning to sound like an update to 5546 > > > 12.2.  New Registration Tables > >    This section defines new registration tables for PARTICIPANT-TYPE and >    RESTYPE values.  These tables may be updated using the same >    approaches laid down in Section 8.2.1 of [RFC5545] > > Section 8.2.1 of [RFC5545] implies that IANA registration procedure is > "Expert Review" > or "Specification Required" (which implies "Expert Review"). Please > clarify this for IANA here. And it looks like that section has an error. It states... designated expert and published in an RFC. A Standards Track RFC is REQUIRED for the registration of new value data types that modify existing properties, as well as for the registration of participation status values to be used in "VEVENT" calendar components. partstat is used for tasks so it should really have been less specific. Returning to your comment... I duplicated the approach taken in e.g. https://tools.ietf.org/html/rfc6638 so I think that the text ought to be fine. However - I have to admit I hadn't fully absorbed the implications so I do need to send emails to the specified lists > > > Best Regards, > > Alexey > > --------------4FBB079BD98B6111DE5A904E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Alexey- sorry I missed this. Some questions and comments below:

On 10/29/18 08:37, Alexey Melnikov wrote:
Hi,

I've done my review of the document. Other people found some of the same issues, so you might have already fixed some of them.
Also note that I might ask for an extra review from people more familiar with use of geo-location in IETF protocols.

In Section 3: XML and JSON need Informative References.

The text I have is

these extensions as a component rather than a property.  This is a
better match for the way XML and JSON handles such structures and
allows richer definitions.

This is just a reference to the hierarchical nature of XML and JSON rather than any particular data representation. What should I be referencing?


In 7.3:
Due to use of RFC 2119 "SHOULD": "text/html" needs an Normative Reference, most likely to HTML5.

I have:

resource is not given by the "FMTTYPE" parameter.  If the media
type remains unknown, calendar applications SHOULD treat it as
type "text/html".





In 7.6:
   Property Name:  STRUCTURED-DATA

   Purpose:  This property specifies ancillary data associated with the
      calendar component.

This is rather vague and I think this has implications for Security Considerations (so you should mention something there), because anything can be stuffed here, including executable content.

   Value Type:  TEXT, BINARY or URI

But the ABNF:

     sdataprop   = "STRUCTURED-DATA" sdataparam
                       (":" text) /
                       (
                         ";" "ENCODING" "=" "BASE64"
                         ";" "VALUE" "=" "BINARY"
                         ":" binary
                       ) /
                       (
                         ";" "VALUE" "=" "URI"
                         ":" uri
                       )
                       CRLF

doesn't include TEXT "value" choice

8.1.  Participant

   Component name:  PARTICIPANT

   Purpose:  This component provides information about a participant in
      an event or optionally a plain text typed value.

What does "or optionally a plain text typed value" mean here? This is a component, not a single property.

Yes - hangover from earlier. Changed to 

This component provides information about a participant
in an event or task.
   Format Definition:

   This property is defined by the following notation:

     participantc  = "BEGIN" ":" "PARTICIPANT" CRLF
                   partprop *alarmc
                   "END" ":" "PARTICIPANT" CRLF

Is inclusion of "alarmc" intentional? (If it is, that is fine. I just think I check.)
That I can't remember - it has the flavor of per-user properties. However I can remove it.

   Example:

   The following is an example of this component.  It contains a SOURCE
   property which points to a VCARD providing information about the
   event participant.

                     BEGIN:PARTICIPANT
                     PARTICIPANT-TYPE:PRINCIPAL_PERFORMER

PRINCIPAL_PERFORMER is not defined as a valid value for PARTICIPANT-TYPE.

SOURCE:http://dir.example.com/vcard/aviolinist.vcf
                     END:PARTICIPANT


   The following is an example for the primary contact.

                     BEGIN: PARTICIPANT
                     SOURCE;FMTTYPE=text/vcard;
http://dir.example.com/vcard/contacts/contact1.vcf
                     PARTICIPANT-TYPE:PRIMARY-CONTACT

PRIMARY-CONTACT is not defined either.

                     DESCRIPTION:A contact:
                     END:PARTICIPANT
Changed to PERFORMER and CONTACT



In Section 9.1:

   STRUCTURED-LOCATION;LABEL="The venue":
    http://dir.example.com/venues/big-hall.vcf
   STRUCTURED-LOCATION;LABEL="The venue":
    http://dir.example.com/venues/parking.vcf

Should different instances have different LABEL values?
Done in v-11



11.  Privacy Considerations

I think this section needs to talk about unintended exposure of Geo location.

Could you elaborate - are we talking about geo location of participants?

That's beginning to sound like an update to 5546



12.2.  New Registration Tables

   This section defines new registration tables for PARTICIPANT-TYPE and
   RESTYPE values.  These tables may be updated using the same
   approaches laid down in Section 8.2.1 of [RFC5545]

Section 8.2.1 of [RFC5545] implies that IANA registration procedure is "Expert Review"
or "Specification Required" (which implies "Expert Review"). Please clarify this for IANA here.

And it looks like that section has an error. It states...

   designated expert and published in an RFC.  A Standards Track RFC is
   REQUIRED for the registration of new value data types that modify
   existing properties, as well as for the registration of participation
   status values to be used in "VEVENT" calendar components.

partstat is used for tasks so it should really have been less specific.

Returning to your comment...

I duplicated the approach taken in e.g. https://tools.ietf.org/html/rfc6638 so I think that the text ought to be fine. However - I have to admit I hadn't fully absorbed the implications so I do need to send emails to the specified lists

 



Best Regards,

Alexey


--------------4FBB079BD98B6111DE5A904E-- From nobody Sun Mar 31 03:50:56 2019 Return-Path: X-Original-To: calsify@ietfa.amsl.com Delivered-To: calsify@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493CE120188 for ; Sun, 31 Mar 2019 03:50:55 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=aegee.org 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 JmRdf3uCo0Ue for ; Sun, 31 Mar 2019 03:50:53 -0700 (PDT) Received: from mail.aegee.org (mail.aegee.org [144.76.142.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC58312017B for ; Sun, 31 Mar 2019 03:50:52 -0700 (PDT) Authentication-Results: mail.aegee.org/x2VAolOa005575; auth=pass (PLAIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1554029448; i=dkim+MSA-tls@aegee.org; r=y; bh=rV3RTJjk5D+LrmpQ01qksWEc65/ywzeq96qCT6+kO7M=; h=Subject:From:To:Date; b=hzevpdTzdOq23jwQ8JWzfn+bOq5YeK9+b+5CVZKBobv9kDF29bo07eEVqTF/7XiLW TJpF+X6y8Pxe09zljBtnP9oB37CmaBRsoANbsJUxEcIngzSl4ORYW9vQt8WzTe8cfB 1wyiFlCkP6cG8+QsQb8HryAkt5zH5grGilpU0piB3ORBOfahua6u2UV+imJ1BbpW4f AeoUOAPo5P+JGwMP5GIk5hDvU0jTe4DzM9gj++Vng0vZUUvNBc0Vun4RgySGOJtKnU EmhtwYOqCLSDyQydk/z67PsNcnjtJPuXOWlStPhb6KiaKIkf47k3+OwOT0l+HkzCPt PFLHZS8Ts5sYkkRnRfVMCFfrAydG3xxgoWVe4dgea5zvf9j4N1FvCjqpg6GHFxT+OZ TZAZq2RdTvptc5cBj6nhnLqMHbCtjRV86dhlpQEusSOPWwFvqOQckPTKmpQFOUl/Oh kEC0k11q71YwXVLW2d4GpYE8QXtYdhHcKEsAFgorsfWSh1ZSHSKRz0/KM6EIQ83aiu C4iEfZxl8N+n7SILBDlRtSSIb/JJTfNJrvjT+V2fd803WSC6aAdq3Ixr8wXdLxb1h1 wF/X/WxlT97cy8K7Wv3oWaHBFPi5HEli/znvyg7XXiU6GpEZT1aTH2Rd4FNpJAW1hy FSl6Nwa7lA5lGSKZPexpbx2E= Authentication-Results: mail.aegee.org/x2VAolOa005575; dkim=none Received: from Tylan (x5d853524.dyn.telefonica.de [93.133.53.36]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x2VAolOa005575 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sun, 31 Mar 2019 10:50:48 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: calsify@ietf.org Date: Sun, 31 Mar 2019 10:50:47 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.101.2 at mail.aegee.org X-Virus-Status: Clean Archived-At: Subject: [calsify] Scheduling VJOURNAL X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 10:50:55 -0000 Hello, iCalendar says VTODO, VEVENT and VJOURNAL can contailn ORGANIZER and ATTENDEEs. iTIP forsees for VTODO and VEVENT the methods PUBLISH, REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, DECLINECOUNTER. For VJOURNAL the methods are PUBLISH, ADD and CANCEL and for all methods it says “It MUST NOT have "Attendees".” For ADD it says “it updates some instances not sending all the data … as it would have to do if the "REQUEST" method were used.”. But there is no REQUEST for VJOURNAL. iMIP says nothing about VJOURNAL. Scheduling Extensions for CalDAV mentions VTODO only on two places: in “Appendix A. Scheduling Privileges Summary/A.1. Scheduling Inbox Privileges” and in „A.2. Scheduling Outbox Privileges” both in the context of the methods REQUEST, REPLY, ADD and CANCEL. * Is METHOD: PUBLISH (without attendees, for any component time) the same as METHOD: REQUEST where the ATTENDEEs have RSVP=FALSE and the other property parameters like PART-STATUS are ignored? * What is the function of PART-STAT for ATTENDEE in VJOURNAL? For users on other domains, uploading a VEVENT/VTODO with ATTENDEEs over HTTP sends emails to the attendees. Shall the server send also emails to the attendees of VJOURNAL and with which method? Provided that the PUBLISH method is used for that operation, how shall a VEVENT/VTODO be WebDAV-uploaded, so that the server uses also the PUBLISH method for iMIP? Regards Дилян