From rgunter@justin.tv Wed Jul 3 13:41: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 B82FC120618 for ; Wed, 3 Jul 2019 13:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=twitch.tv 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 I0Ea5rNikNd5 for ; Wed, 3 Jul 2019 13:41:41 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 AE70B1206A7 for ; Wed, 3 Jul 2019 13:41:40 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id p11so4241925wre.7 for ; Wed, 03 Jul 2019 13:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitch.tv; s=google; h=mime-version:from:date:message-id:subject:to; bh=CYikeul3V47LYU/KQhMKBdCB2ANxdf32sTrSEdh4yvw=; b=OjFQLgfghJb9OsAMeKO4mtnq0K6g0wRcFwL/iCYVy/oyw+ijyONshMy7yGk77AtriQ Yeyt4C9wv7W3XbUXgxbMyj8ysPN6tI7p0eu5bZQvInHwbQi8pE8OoRHa4U2qYm/t1zeL 1QD7fBmX1n7eNL0JhaIvISakAZ97Xfekr5tEE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CYikeul3V47LYU/KQhMKBdCB2ANxdf32sTrSEdh4yvw=; b=KDGvI51qWawtdmmjfZxfhActrzAsZ/NOds4mZuIMehh4gikAaoy23zX+BUf8Rm+Ae/ lQ+FAyg94qV036ZnSreSqezCXpLqYkR4A8upvMczvduA+hgP24dW0+wMgZFy34XtwOzG HfqJv0xeosGyU9ZYh8HcXMGEuDZB0Y/9XKShVa2dQrKkKjVwpgL5cEDU32zPLLsdncBj mupqBQhzNMqjFoJq4b+izGnFMLkt4qE+wPTj7C0IcnPWJVEnwAqbPeUedAR1dxI5ckNx OSQW38LAyDDWnuY0lf4VmWDBIdZlGG3huzHQvqHZfo76g7L7aU4nC3OEvwwM/pHgRHJ8 AjTQ== X-Gm-Message-State: APjAAAUCGAIENnVY/nkT48+OgM5gppGqE1ATdxJbr0L/h6nX7RYlXibu EbBrT0sMtUWb/LshGaWtNR3E6H9YdJaU34LJYnz6xOPiE7MB X-Google-Smtp-Source: APXvYqwZX9V94/K00YlkTtdOshfT/IrgVx8tu/B9LRm/P0MPO90alx+Lnu3j+dlQpKPsZONUNd3YDsbKK2Ep9na42Tg= X-Received: by 2002:adf:f80a:: with SMTP id s10mr6165564wrp.39.1562186498893; Wed, 03 Jul 2019 13:41:38 -0700 (PDT) MIME-Version: 1.0 From: Ryan Gunter Date: Wed, 3 Jul 2019 14:41:03 -0600 Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary="00000000000057021f058ccce3c2" Archived-At: Subject: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 03 Jul 2019 20:54:24 -0000 --00000000000057021f058ccce3c2 Content-Type: text/plain; charset="UTF-8" Hello, I wanted to inform everyone of a new draft my team recently submitted, "Maintenance Notification Improvements Using iCalendar." We would appreciate any feedback and hope this found useful by the community. https://datatracker.ietf.org/doc/html/draft-gunter-calext-maintenance-notifications Ryan Gunter | *Twitch* | Network Engineering | +1.415.568.7607 --00000000000057021f058ccce3c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I wanted to inform ev= eryone of a new draft my team recently submitted, "Maintenance Notific= ation Improvements Using iCalendar."

We would= appreciate any feedback and hope this found useful by the community.
=

https://datatrac= ker.ietf.org/doc/html/draft-gunter-calext-maintenance-notifications


Ryan Gunter=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0Twitch=C2=A0=C2=A0=C2=A0|=C2=A0<= font style=3D"font-family:Helvetica;font-size:12px" color=3D"#666666">=C2= =A0 Network Engineering=C2=A0 =C2=A0= | = =C2=A0=C2=A0+1.415.568.7607
=
--00000000000057021f058ccce3c2-- From nobody Wed Jul 3 14:12: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 A27B41200C7 for ; Wed, 3 Jul 2019 14:12:38 -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=mt7NnsSQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=n70uersw 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 mzTvJC8WW8p3 for ; Wed, 3 Jul 2019 14:12:36 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728B4120096 for ; Wed, 3 Jul 2019 14:12:36 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A3DFD20A3C for ; Wed, 3 Jul 2019 17:12:35 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 03 Jul 2019 17:12:35 -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=fm3; bh=OFLQp9703Ewm0ESSQeSUVIXyYbM KGhWi7AUT06tY5ro=; b=mt7NnsSQJO6bx/xTf5oEvQszIDnFNA7sJmRd0ks6tIm 6wTPetXnKPWrQenzjXArtxlDehpcGZfjk7bOn3Nhm1r+tYfZwoy0VuomdGvEaZKT orXYmZVikdleFqm9K1OXnmhYY74zqinbLp6O9l17u8ueSznuG+Y2qwnxyyI9VRQI RncuEuavk9EmMg4O6bcwgBl7KbeCL2tLbiReBhDKRQq1tUNAbSGnn3k9x94iycjI reI4aSlwwJjTpeYui82iBioCO0eCK+Bc9Ki8O5+CO3PbagusLHp2B5TqHVvDyPvB huzGMt8bKOhxHYu2bn6LYnFrz7gJ1aP123Se6WWlz+g== 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=fm3; bh=OFLQp9 703Ewm0ESSQeSUVIXyYbMKGhWi7AUT06tY5ro=; b=n70uerswcoDaQ4AUqHVypR xzRl1t3ts9inMGU+V9TfRfN+kZ18SGxeLnbRQlL4zq2/aEgnJh1X7tFzJwnIpezo M8H1NIsCRrUVsMfWrW4u+HPLYAsWwM2/YrnKS+cidvKc+kgeuw1mgpyershBG8Bt EhQlyXT8TkX6hnLA2UZkOMgSVjPvJZ4EPtfu+Tc2sUlQDwctQRj2Sg7SVkABB42f Br5c/t15lU1QSu2X/Oz6FlTN0PGoqF4mwuZRc2fGXQOvmoVr2SK2/RqAj1BahAmd IW2JP8WL0ifyL1SmN8IiKPGBqyrBwS8/wuS8kpdg9tSjwf2VQhMcaRDaHImTQ0yQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrfedtgdduheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhfhokffffgggjggtsehmtd erredtfeejnecuhfhrohhmpefmvghnucfouhhrtghhihhsohhnuceomhhurhgthhesfhgr shhtmhgrihhlrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgpdhtfihithgthh drthhvnecukfhppeejgedrjeejrdekhedrvdehtdenucfrrghrrghmpehmrghilhhfrhho 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 EB70B380083 for ; Wed, 3 Jul 2019 17:12:34 -0400 (EDT) To: calsify@ietf.org References: From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Wed, 3 Jul 2019 17:12:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------E8D32F6EEAE2375939E75477" Content-Language: en-US Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 03 Jul 2019 21:12:39 -0000 This is a multi-part message in MIME format. --------------E8D32F6EEAE2375939E75477 Content-Type: multipart/alternative; boundary="------------FBAD9E0D26C833AD3391B32C" --------------FBAD9E0D26C833AD3391B32C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Ryan, My initial reaction to reading this is that all of the new maintenance properties should be grouped under a single entity such as a STRUCTURED-DATA property or a new MAINTNOTE sub-component, similar to PARTICIPANT. On 7/3/19 4:41 PM, Ryan Gunter wrote: > Hello, > > I wanted to inform everyone of a new draft my team recently submitted, > "Maintenance Notification Improvements Using iCalendar." > > We would appreciate any feedback and hope this found useful by the > community. > > https://datatracker.ietf.org/doc/html/draft-gunter-calext-maintenance-notifications > > > Ryan Gunter | *Twitch* |   Network Engineering| > +1.415.568.7607 > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team Fastmail US LLC --------------FBAD9E0D26C833AD3391B32C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Ryan,

My initial reaction to reading this is that all of the new maintenance properties should be grouped under a single entity such as a STRUCTURED-DATA property or a new MAINTNOTE sub-component, similar to PARTICIPANT.


On 7/3/19 4:41 PM, Ryan Gunter wrote:
Hello,

I wanted to inform everyone of a new draft my team recently submitted, "Maintenance Notification Improvements Using iCalendar."

We would appreciate any feedback and hope this found useful by the community.



Ryan Gunter  |   Twitch   |   Network Engineering   |   +1.415.568.7607

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

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC
--------------FBAD9E0D26C833AD3391B32C-- --------------E8D32F6EEAE2375939E75477 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------E8D32F6EEAE2375939E75477-- From nobody Thu Jul 4 04:19: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 8E6DD12044A for ; Thu, 4 Jul 2019 04:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=web.de 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 Jdm0Rb2AxMqI for ; Thu, 4 Jul 2019 04:19:23 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) (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 C2F691206C5 for ; Thu, 4 Jul 2019 04:19:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1562239153; bh=p5duYGYORm+i95YrTTjnInWhoU4knYlA/3iNNeKW5Xo=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=r0jrXSZoPTyecOLGm0j2qVr8DKn6dq1kL5Rde/FQLRUdrL7PTsREtsNRAMbv6fUBv by5j2XtN+uSsCZaZMKY3XhQN+zMa3Ydeq9Agu8+4UfhrnxAfHT74HJ++1PUh6LCArK z3yAtrwP+vhKOmnCFYCy7djuPA9bBp94CVfENrbI= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [82.165.233.96] ([82.165.233.96]) by web-mail.web.de (3c-app-webde-bs17.server.lan [172.19.170.17]) (via HTTP); Thu, 4 Jul 2019 13:19:12 +0200 MIME-Version: 1.0 Message-ID: From: =?UTF-8?Q?=22Thomas_Sch=C3=A4fer=22?= To: "Ken Murchison" Cc: calsify@ietf.org Content-Type: text/html; charset=UTF-8 Date: Thu, 4 Jul 2019 13:19:12 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: Content-Transfer-Encoding: quoted-printable X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:Kg6jzPDti+d+UMdeIOg2v63Nc6BV/8RQISftKtsv6Gutt5uuXPJJ63WQXr/gg8KGGpoSn Weu7uorlBttWJU0oB3OMQX31jML4FB4fbrBcERrijPiKrTFUE5cvix6eGS4fp4OwNiI8WBjlLOLx JJEj6sXdwJg6vf0X8cK5ohmnq4Yz1bTVUmTduNs2Ud5/wNQYqrV4B4neJSSs4e8Qwsk0JQM7K1aD k9+uPpJ6NyrKzlfSy5WRf3lTgQDxGtyYh0Kaf2Ths5Zz5ZStU+DYxbSv3Hh+d3mZpX+lLtQI3Zgt AI= X-UI-Out-Filterresults: notjunk:1;V03:K0:sRqSpbIbKBU=:0cYDJO63NKJK0+66QEIE4V M9hJ+Dv3egxVPAmiEGrABVXXYC41CsEpja0SviKkcKpEXnkM0kG/SzbunidqRMkNa31aXrbGS 9bdR0XqKBUZLI4E3+9ZOLa0HzIzTC8292D/U1GOWAORTHXMPIRyxvkBVcRGf7s92L+JiRVkik 7cZEJMiPDJCDyAt+HJilxqWU3ZfQmICiixsu8eDAN1mHf1kdm+hipD6/BveL5Q1GDFfeNocNV KGkHwT5a70OPTk1Bol6NMQOBnURdgMHG90a7dlxtyiTXb2LGRSUg00ryAn3uOYQXvthJTkTR2 90qZ01xILw0egYofAwdINWaBPCscc1dPE/FGLwXGyVlfbknlLJhbVhgoSKr3sXYrPs53GB4db N4vqpFlbapKQvyEcc1cunrbyt0AHjAV+sVbApqaWomm72R7z5XB0Ild6KSutpYYDEfaLmOiro OCyVloOVGeS0Mh+Mr1+4hSzOTYf8qZPbHbzsQrn+DMBN/MQshDrJIOBRI4lqG/pDjwwXk2nNI MpXAoVlyAcscSajz1eNDmrSX37IyZf0dWn4i1oczYn9yNoZztQx+twW/uxQVsPhRLXQTjJs+n Ql/jLn+VmzueKZnRaWqWmwZhObdMeHWr1PnVBsGeRErYCYqTXM5f2zKQ== Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 04 Jul 2019 11:19:31 -0000
Hi Ryan,
 
what also come to my mind, when reading this is, that it looks to me,= that there are redundant information included: X-MAINTNOTE-STATUS:IN-PROCE= SS=2E
 
The event includes a start and end-time and wouldn't it be assume= d, that during this time period, the maintenance is in progress? The approa= ch you took will need explicit changes to the event even if it happens as a= nnounced to update only the status of the maintenance=2E
 
Thomas
 
Gesendet: Mittwoch, 03= =2E Juli 2019 um 23:12 Uhr
Von: "Ken Murchison" <murch@fastmail=2Ecom> An: calsify@ietf=2Eorg
Betreff: Re: [calsify] New Draft - Maintenance Notifications U= sing iCalendar

Hi Ryan,

My initial reaction to reading this is that all of the new maintenance = properties should be grouped under a single entity such as a STRUCTURED-DATA property or a new MAINTNOTE= sub-component, similar to PARTIC= IPANT=2E

 
On 7/3/19 4:41 PM, Ryan Gunter wrote:
Hello,
 
I wanted to inform everyone of a new draft my team recently submitted= , "Maintenance Notification Improvements Using iCalendar=2E"
 
We would appreciate any feedback and hope this found useful by the co= mmunity=2E
 
 
 
Ryan Gunter  |&n= bsp;  Twitch   |   Network E= ngineering   |   +1= =2E415=2E568=2E7607
 
 
_____________________________________________=
__
calsify mailing list
calsify@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/list=
info/calsify

--=20
Ken Murchison
Cyrus Development Team
Fastmail US LLC
_______________________________________________ calsify mailing list calsi= fy@ietf=2Eorg https://www=2Eietf=2Eorg/mailman/listinfo/calsify
From nobody Thu Jul 4 04:29: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 F205E1206DA for ; Thu, 4 Jul 2019 04:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 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, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=web.de 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 WE2yXPK4NZAU for ; Thu, 4 Jul 2019 04:29:08 -0700 (PDT) Received: from mout.web.de (mout.web.de [212.227.15.4]) (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 853391206A8 for ; Thu, 4 Jul 2019 04:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=web.de; s=dbaedf251592; t=1562239743; bh=D4Zykt7GSFkQZM0ewK+0KniiBakFyl5JHSwGT5SNIX8=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=oUf5gNblEI5r1jEBby+uAW4UypuTRyd9BZrmsuBr1AGEa89SGgjGDAtHo41E4ULJB uYlFkfG2a+Okb8h7i0FWLm8pf14lI4lknA8MSBos406POp8wc4vTxbqS+mSlxkp7UB l462s9jsSg+jzBUZk/g3/UlY6d+osCXVRKNPfoEA= X-UI-Sender-Class: c548c8c5-30a9-4db5-a2e7-cb6cb037b8f9 Received: from [82.165.233.96] ([82.165.233.96]) by web-mail.web.de (3c-app-webde-bs17.server.lan [172.19.170.17]) (via HTTP); Thu, 4 Jul 2019 13:23:57 +0200 MIME-Version: 1.0 Message-ID: From: =?UTF-8?Q?=22Thomas_Sch=C3=A4fer=22?= To: "Ryan Gunter" Cc: calsify@ietf.org Content-Type: text/html; charset=UTF-8 Date: Thu, 4 Jul 2019 13:23:57 +0200 Importance: normal Sensitivity: Normal In-Reply-To: References: Content-Transfer-Encoding: quoted-printable X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:P7sdz/dc/Wr1ZEcr8yliATjsZZLGgzqY22nhQXYZKxq41YenU6uJrPGUgLD5mMxbUg5hw BJNEY6lWAgMH8NOq6KX2DRaKmQD72Ire4JdI06Y8CUMooVOGJyNAwdGPVKogd5bpacare91r0IE5 9sKBcXBeVsm06d02Kr6HV5OV9KACfudxRG7pUq9Y/qmjEyzmVuuAcsebMjMX1K3sT2j9EEHNawDX TRJMfm6Xhc7CJ8hwSrOKcTJcxxEt1erh4+08ShSNkZwxJw0RM49tlz7ezxsS0gbdDCHKju4jQyjL /Y= X-UI-Out-Filterresults: notjunk:1;V03:K0:fZ0/C9390eg=:KeZTXC7ICd0A5IXdDH0REW Q/TmhV9geFw02niRRb6eEXkJ0BcPsLxjHDLjWA8S6zfPbGu5PXSa3ZO8ctOvRXSxAwZ5EaW1q RoGurxSjnHIqjD0SKsJiMIOlRyBC4dPP38KtOq/0zNXaXDYNUh+QxNBl874HqedFufBCsqCDd 2BgEIEEy9ChWAGzXOq2G1RLaD822OPTUbgNTrFhHr6cJ1VjW1QC9aX7qto+Mf3ZuL1/Yk2Yuk OVEfWHL0COnYJPJdZlEHTDe3UZs0aKDar1gwDXfQsAacDRktVUGFBG7EGon8teKrtPkK5yB91 STVFpW7XhcEl2D2IJaqopnQkOre4UImM3VSsM8numV8Kj0VY1mE+61cCLyDa8DVD95kt7dlQ6 xT+IYm+Dkcs1CmvQb2QtT3Q9sITGsSyD+IqNJqL6yWm2BNVtTTKlo3/V8xyvscR1IiiGpq3bq bseODIaJKQwQdUO0BpxzKGziLs6VV4hJkodssdHEhfAl+7guXQzwIw0yXOJwur9zSsP/Op5mw 1ty1V4mkqiY/n0qu9+KxvlV6Uv52tdZ1hmr8GiQzsF4KhxCKYzOdLyCeJLXri4DzY36E5RPhn DYjfTOij5nDF/2XogOCoWEmyhezU+wwzZg0cqXlghJP/mhbVhek0eQzA== Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 04 Jul 2019 11:29:11 -0000
Hi Ryan,
 
There is also a common mistake made in the examples in choosing simpl= e numbers as UIDs of events: UID:42
 
The DEVGUIDE of CalConnect https://devguide=2Ecalconnect=2Eorg/Data-M= odel/UID/ describes this issue and how UIDs should always be generated and = why=2E
 
Thomas
 
Gesendet: Mittwoch, 03=2E Ju= li 2019 um 22:41 Uhr
Von: "Ryan Gunter" <rgunter=3D40twitch=2Etv@dmarc= =2Eietf=2Eorg>
An: calsify@ietf=2Eorg
Betreff: [calsify] New Draft - Maintenance Notifications Using= iCalendar
Hello,
 
I wanted to inform everyone of a new draft my team recently submitted= , "Maintenance Notification Improvements Using iCalendar=2E"
 
We would appreciate any feedback and hope this found useful by the co= mmunity=2E
 
 
 
Ryan Gunter  |&n= bsp;  Twitch   |   Network E= ngineering   |   +1= =2E415=2E568=2E7607
_______________________________________________ calsify mailing list calsi= fy@ietf=2Eorg https://www=2Eietf=2Eorg/mailman/listinfo/calsify
From nobody Thu Jul 4 17:48:47 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 1E6E9120169 for ; Thu, 4 Jul 2019 17:48:46 -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_HELO_NONE=0.001, 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 pnsHPDHR_Hqw for ; Thu, 4 Jul 2019 17:48:43 -0700 (PDT) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (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 69E111200D6 for ; Thu, 4 Jul 2019 17:48:43 -0700 (PDT) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-05v.sys.comcast.net with ESMTP id jCInh3n1GPM4njCP4hwQE3; Fri, 05 Jul 2019 00:48:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1562287722; bh=NgJHiyG2jnFRGu8EtepIofO5joTU5b2ngrfT2EHuKhk=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=PEoNN0iWBkNQwInOy1SlBfWIT13uCIhEGYVcQwX90K22lKge82rA22KG74GcP6LlS O/201MNcvi5PpJurMBls+qy17G8KgZioyqdYSIPmqG3PdwrE/Rfr5X5998b3gMHjzv PONtmJQNkauigs4DG8GTMNGL2p6CgCBcMQ/O7zADudhIQgGvqkudE8EehvSi/nBJ9p /VcOYrK4KhPkj6ifqfJEswZKSQPyP19kT0xVi8ZjpMzbZIuWRSbnn2Tsw7vYam9WX6 pFKqQinA2yjnLalfw7RnMctnNMP5+hyqhk2FH+X9iCaml4NakUOzG328XHBEVin2w0 x3/TJviDxWwEQ== Received: from THARE ([98.192.130.240]) by resomta-po-13v.sys.comcast.net with ESMTPA id jCP3hblEoMBm8jCP3hE9WI; Fri, 05 Jul 2019 00:48:42 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduvddrfeefgdeflecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfhfjgfufffkgggtofhtsegrtdhgpedvtdejnecuhfhrohhmpedfvfhimhcujfgrrhgvfdcuoefvihhmjfgrrhgvsegtohhmtggrshhtrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgpdhtfihithgthhdrthhvnecukfhppeelkedrudelvddrudeftddrvdegtdenucfrrghrrghmpehhvghlohepvffjteftgfdpihhnvghtpeelkedrudelvddrudeftddrvdegtddpmhgrihhlfhhrohhmpehtihhmhhgrrhgvsegtohhmtggrshhtrdhnvghtpdhrtghpthhtoheptggrlhhsihhfhiesihgvthhfrdhorhhgpdhrtghpthhtohepmhhurhgthhesfhgrshhtmhgrihhlrdgtohhmpdhrtghpthhtohepthhsseifvggsrdguvgenucevlhhushhtvghrufhiiigvpedt X-Xfinity-VMeta: sc=-100;st=legit From: "Tim Hare" To: =?utf-8?Q?'=22Thomas_Sch=C3=A4fer=22'?= , "'Ken Murchison'" Cc: References: In-Reply-To: Date: Thu, 4 Jul 2019 20:48:39 -0400 Message-ID: <003001d532cb$63c2fa50$2b48eef0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01D532A9.DCB3CB50" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQGEixvEEqPFJ3M5xn9ULchYELafUgJLMA7MAWfVqvGnPrE00A== Content-Language: en-us Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 05 Jul 2019 00:48:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0031_01D532A9.DCB3CB50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I see this as looking for a specific =E2=80=9Cpayload=E2=80=9D of = information for a VEVENT. I would like to see a more general extension, = with a EVENTTYPE: property that named a =E2=80=9Cschema=E2=80=9D for = DESCRIPTION: . The calendar CUA could then invoke a = =E2=80=9Chelper=E2=80=9D/plug-in to process that schema; if EVENTTYPE = was not there, or the CUA was not EVENTTYPE-aware, the client/UA would = just display the text of DESCRIPTON: as happens now which would still = show the structured fields, there just wouldn=E2=80=99t be anything to = process them. In your use case EVENTTYPE: would contain =E2=80=9CMaintenance = Notification=E2=80=9D or =E2=80=9CMAINTNOTE=E2=80=9D and the = application would search for =E2=80=9CProvider=E2=80=9D, = =E2=80=9CAccount=E2=80=9D, =E2=80=9CMaintenance ID=E2=80=9D, = =E2=80=9CObject ID=E2=80=9D, =E2=80=9CImpact=E2=80=9D, and = =E2=80=9CStatus=E2=80=9D within the DESCRIPTION text. =20 Other types of specialized events could use different EVENTTYPEs = =E2=80=93 for example =E2=80=9COUTAGE=E2=80=9D with schema for = =E2=80=9CReason=E2=80=9D, =E2=80=9CReported By=E2=80=9D, = =E2=80=9CResolved By=E2=80=9D, and =E2=80=9CResolution=E2=80=9D. Tim Hare Interested Bystander, Non-Inc. From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of "Thomas = Sch=C3=A4fer" Sent: Thursday, July 4, 2019 7:19 AM To: Ken Murchison Cc: calsify@ietf.org Subject: Re: [calsify] New Draft - Maintenance Notifications Using = iCalendar =20 Hi Ryan, =20 what also come to my mind, when reading this is, that it looks to me, = that there are redundant information included: = X-MAINTNOTE-STATUS:IN-PROCESS. =20 The event includes a start and end-time and wouldn't it be assumed, that = during this time period, the maintenance is in progress? The approach = you took will need explicit changes to the event even if it happens as = announced to update only the status of the maintenance. =20 Thomas =20 Gesendet: Mittwoch, 03. Juli 2019 um 23:12 Uhr Von: "Ken Murchison" An: calsify@ietf.org Betreff: Re: [calsify] New Draft - Maintenance Notifications Using = iCalendar Hi Ryan, My initial reaction to reading this is that all of the new maintenance = properties should be grouped under a single entity such as a = STRUCTURED-DATA = property or a new MAINTNOTE sub-component, similar to = PARTICIPANT. = =20 =20 On 7/3/19 4:41 PM, Ryan Gunter wrote: Hello, =20 I wanted to inform everyone of a new draft my team recently submitted, = "Maintenance Notification Improvements Using iCalendar." =20 We would appreciate any feedback and hope this found useful by the = community. =20 https://datatracker.ietf.org/doc/html/draft-gunter-calext-maintenance-not= ifications =20 =20 Ryan Gunter | Twitch | Network = Engineering | +1.415.568.7607 =20 _______________________________________________ calsify mailing list calsify@ietf.org =20 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 ------=_NextPart_000_0031_01D532A9.DCB3CB50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable 
I see this as looking for a specific =E2=80=9Cpayload=E2=80=9D of =
information for a VEVENT.=C2=A0 I would like to see a more general =
extension,=C2=A0 with a EVENTTYPE:=C2=A0 property that named a =
=E2=80=9Cschema=E2=80=9D for DESCRIPTION: .=C2=A0=C2=A0=C2=A0 The =
calendar CUA could then invoke a =E2=80=9Chelper=E2=80=9D/plug-in to =
process that schema;=C2=A0 if EVENTTYPE was not there, or the CUA was =
not EVENTTYPE-aware,=C2=A0 the client/UA would just display the text of =
DESCRIPTON: as happens now which would still show the structured fields, =
there just wouldn=E2=80=99t be anything to process them.

In your =
use case EVENTTYPE: would contain =E2=80=9CMaintenance =
Notification=E2=80=9D or =E2=80=9CMAINTNOTE=E2=80=9D and =C2=A0the =
application would search for =E2=80=9CProvider=E2=80=9D, =
=C2=A0=E2=80=9CAccount=E2=80=9D, =C2=A0=E2=80=9CMaintenance ID=E2=80=9D, =
=C2=A0=E2=80=9CObject ID=E2=80=9D, =C2=A0=E2=80=9CImpact=E2=80=9D, and =
=E2=80=9CStatus=E2=80=9D within the DESCRIPTION text.=C2=A0=C2=A0 =


Other types of specialized events could use different EVENTTYPEs =
=E2=80=93 for example =E2=80=9COUTAGE=E2=80=9D with schema for =
=E2=80=9CReason=E2=80=9D, =E2=80=9CReported By=E2=80=9D, =
=E2=80=9CResolved By=E2=80=9D,=C2=A0 and =
=E2=80=9CResolution=E2=80=9D.



Tim Hare

Interested Bystander, Non-Inc.

From:<= /b> = calsify [mailto:calsify-bounces@ietf.org] On Behalf Of = "Thomas Sch=C3=A4fer"
Sent: Thursday, July 4, = 2019 7:19 AM
To: Ken Murchison = <murch@fastmail.com>
Cc: = calsify@ietf.org
Subject: Re: [calsify] New Draft - = Maintenance Notifications Using = iCalendar

 

Hi = Ryan,

 

what also = come to my mind, when reading this is, that it looks to me, that there = are redundant information included: = X-MAINTNOTE-STATUS:IN-PROCESS.

 

The event = includes a start and end-time and wouldn't it be assumed, that during = this time period, the maintenance is in progress? The approach you took = will need explicit changes to the event even if it happens as announced = to update only the status of the = maintenance.

 

Thomas

  =

Gesendet: Mittwoch= , 03. Juli 2019 um 23:12 Uhr
Von: "Ken = Murchison" = <murch@fastmail.com>
An: calsify@ietf.org
Betr= eff: Re: [calsify] New Draft - Maintenance Notifications Using = iCalendar

Hi = Ryan,

My initial = reaction to reading this is that all of the new maintenance properties = should be grouped under a single entity such as a STRUCTURED-DATA property or a new = MAINTNOTE sub-component, similar to PARTICIPANT.

  =

On 7/3/19 = 4:41 PM, Ryan Gunter wrote:

Hello,

 

I wanted to = inform everyone of a new draft my team recently submitted, = "Maintenance Notification Improvements Using = iCalendar."

 

We would = appreciate any feedback and hope this found useful by the = community.

 

 

 

Ryan Gunter  |   Twitch   |   Network Engineering   |   +1.415.568.7607

    = 

______________________________________________=
_
calsify mailing =
list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify<=
/o:p>
-- =

Ken =
Murchison
Cyrus =
Development Team
Fastmail US LLC

______________= _________________________________ calsify mailing list calsify@ietf.org = https://www.ietf.org/mailman/listinfo/calsify<= /o:p>

------=_NextPart_000_0031_01D532A9.DCB3CB50-- From nobody Sun Jul 7 11:06: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 8A2781200CE for ; Sun, 7 Jul 2019 11:06:10 -0700 (PDT) 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_HELO_NONE=0.001, SPF_PASS=-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 8hPEjpOFZolb for ; Sun, 7 Jul 2019 11:06:08 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 4C14E120308 for ; Sun, 7 Jul 2019 11:05:47 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id u17so6002401pgi.6 for ; Sun, 07 Jul 2019 11:05:47 -0700 (PDT) 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:content-transfer-encoding; bh=gfTc5qCjTLHggt3S4OSfg88ckW248BlcGn1+Jg4eYVg=; b=s7jPHDcuKrRvLA4gGCIYOphsRkVnxeY8ZQIUf8mdYYbdEq5v0WY4gOJO0qDw3N61SL g+DINjdVRjssISLOGxQQOMNprQht8vghfWvURG3uT44Z02+nSje0b5zBuzYEg7gHOuQV hcsOEUBZbSN3p1Gh7V6yEIq7mP0tVilf7ORd+oRAEFKlNXnYEX2gXV997FmhtWvViMsc urUQdR6lIEcYofjOEYnQXU8QviOESyLQfguFGcR1funCULDxXt6VysnWJ1oA5m/nzai6 EBdpXmSZmTp1GRfFWjx+3cPXcOgiNqtUENJzw9ksok82GAKQJkKtQD//ad/+7qEen7xb zDaw== 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:content-transfer-encoding; bh=gfTc5qCjTLHggt3S4OSfg88ckW248BlcGn1+Jg4eYVg=; b=iOdZZZkWSDLXsz73jNGLZKPQQFuat4a0UniQJ73ZF9UwhgbCKX59W2bZtktU6Gu5EB vW8yraziF+aFMkByg3aWc0AYvXNMAD6yjsRDMfzdQKlBA0Pjx0QTcbW6rl7WZP/UhUWK lMQVXMFfIfmk3Ef1/Rnzy7wL+8Lu2FA3MadpncQ6U3J7L7tmYQLD7zBUlSBSQhe/CTJp RyDlLgOIZum+4Vev67PDNc4e/vMPJKViV83Lyt5UhBS7tJMCeUpOsSkjSsx7lI2uLo2o TuySToxqgPMCoDMnpiFG/mYHAqMQXI5NwjDmy0Mn6/q0nzuBifvgBUznLphij5VAw+it JXVA== X-Gm-Message-State: APjAAAWH1BOkaK3sQowR0ui7zP4pCSP105IkuaJNBSmaYm5qoEeWcrt4 45W9YXCTy6IJsQrDAgDKB2mPj6Ab+f/p X-Google-Smtp-Source: APXvYqxGZWIBWV8iZXAtKn8LucmC6qt5VmQ/rcNfNt76u+vjm8YmDy7KGtNXRZLZ9ml9DQ3BgVzUjg== X-Received: by 2002:a65:5c0a:: with SMTP id u10mr18671951pgr.410.1562522746235; Sun, 07 Jul 2019 11:05:46 -0700 (PDT) Received: from [192.168.1.7] ([174.27.175.146]) by smtp.googlemail.com with ESMTPSA id q63sm24715805pfb.81.2019.07.07.11.05.45 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sun, 07 Jul 2019 11:05:45 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: Organization: http://SoftwareAndServices.NET Message-ID: <482a9dba-6d92-3b78-a9be-d90682f4d4f2@gmail.com> Date: Sun, 7 Jul 2019 12:05:45 -0600 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 07 Jul 2019 18:06:11 -0000 Drop the "X-" in front of your property names in your draft, as when (if) this makes it to RFC status, they will be IANA registered. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Mon Jul 8 15:53:14 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 7EDA6120354 for ; Mon, 8 Jul 2019 15:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=twitch.tv 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 mV02eqMBecyv for ; Mon, 8 Jul 2019 15:53:01 -0700 (PDT) Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 65DF1120346 for ; Mon, 8 Jul 2019 15:53:01 -0700 (PDT) Received: by mail-wm1-x32c.google.com with SMTP id h19so1034083wme.0 for ; Mon, 08 Jul 2019 15:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitch.tv; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BmbIbS2SQKr3MfgWD0L12VH9wSM2S25b4gHAF2+rVzk=; b=hZH7AvPduszbA/Zts7mQ1xgD3JNxJBG8bjpY7jgWulTgtQPBprkZVMeh3avHEjg+1F 6khpp2K53CyqmzR7+DpQiylOGJWPH0YVE7SpUaNlJ8F/z4KwbkaCdw3oYWVkilSWizPc geh9jlbLt9r6GmdlV9ftLvnHbVL/KxH4CHJQM= 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=BmbIbS2SQKr3MfgWD0L12VH9wSM2S25b4gHAF2+rVzk=; b=IzknYn4hzYMHU4Kcwh7FDV9rN+l/yv53l7qfsB2AL1tbWf3LEgWatmSMqM9PPK/zj1 nqUDOTgY8CJjOL3l5y5SYW9yMk1jstPIiLPet0ZoLcJWISxaW+6+R4GXBZczcmHILGXB hfrPNsk6mhEU5Os2RlqRJ+BkVBCX4tEFm9GbWZpj7OASkqLx9KyHSDyVHpuJixFjG41Q EL4/1AfsTPQZUvO9B3oS3/rNr2cSaugw/E5nnSDe9PKWdC6eBZb3cx+ZCgx6edrBUyE5 bIhaKBP3+smE1V6l8Jf82W33yz+FLoj7WK40P4w0IV9lGaPWTXtSDjxNvwxZoVHHa3AS 8oUg== X-Gm-Message-State: APjAAAWyd0tyYDVCTQgaPZLgqe8wkQdTPPrO7DvjvhtAEsSXPl6pIeFi QDrGm0NCJUHSrh8OhmFe7FzYFiWA5ZMPihMyact4tbUdbA== X-Google-Smtp-Source: APXvYqxLWEg4mnz5yDDY9GRLUD+O8k7QwF5ABzOKw2Gcets6lUK+e2Gpy8HKJ6cuuVV5JdYvEmNPoy4zpgdVAWBZ9pc= X-Received: by 2002:a05:600c:254b:: with SMTP id e11mr17225031wma.171.1562626379537; Mon, 08 Jul 2019 15:52:59 -0700 (PDT) MIME-Version: 1.0 References: <482a9dba-6d92-3b78-a9be-d90682f4d4f2@gmail.com> In-Reply-To: <482a9dba-6d92-3b78-a9be-d90682f4d4f2@gmail.com> From: Ryan Gunter Date: Mon, 8 Jul 2019 16:52:23 -0600 Message-ID: To: calsify@ietf.org Content-Type: multipart/alternative; boundary="00000000000044f687058d334e48" Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 08 Jul 2019 22:53:13 -0000 --00000000000044f687058d334e48 Content-Type: text/plain; charset="UTF-8" Hello everyone, We really appreciate the feedback! There are several things to digest and research. I will reply shortly with comments/questions. Thank you! Ryan Gunter | *Twitch* | Network Engineering | +1.415.568.7607 On Sun, Jul 7, 2019 at 12:06 PM Doug Royer wrote: > > Drop the "X-" in front of your property names in your draft, as when (if) > this makes it to RFC status, they will be IANA registered. > > > > -- > > Doug Royer - (http://DougRoyer.US) > Douglas.Royer@gmail.com > 714-989-6135 > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --00000000000044f687058d334e48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

We really ap= preciate the feedback!=C2=A0 There are several things to digest and researc= h.=C2=A0 I will reply shortly with comments/questions.

=
Thank you!

<= div dir=3D"ltr">
Ryan Gunter=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0Twitch= =C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0 Network Engineering=C2=A0 =C2=A0| =C2=A0=C2=A0+1= .415.568.7607
<= br>

On Sun, Jul 7, 2019 at 12:06 PM Doug Royer <douglasroyer@gmail.com> wro= te:

Drop the "X-" in front of your property names in your draft, as w= hen (if) this makes it to RFC status, they will be IANA registered.



--

Doug Royer - (http://DougRoyer.US)
Douglas.Royer@= gmail.com
714-989-6135

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--00000000000044f687058d334e48-- From nobody Mon Jul 8 19:25: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 85A51120307 for ; Mon, 8 Jul 2019 19:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 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, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 yJLDXSS-UzvD for ; Mon, 8 Jul 2019 19:25:39 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 9E3DB1202F8 for ; Mon, 8 Jul 2019 19:25:39 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id n11so20137094qtl.5 for ; Mon, 08 Jul 2019 19:25:39 -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=aXPMYtzbEIzVHqYLCzmUjHBxMl2g4zVm3ROGN72Y1xE=; b=BeztWIb5DhEAMaPNWq9RnIxVREXELCVvBHpf4Wy7BFOzgrfctK8cyoZ1k+t7leetND riDmDz5IFcYf9mSJnlYBmp6gaQtJYp2IeemMmWkeN+y+kNhj75VRZwOA/fHUmk6m/Ju1 Dp4Lmp+VB6Zb+8eviMbq98iXGBXBbXNIfOOH91MAvtMafTbv3hFycpFUBN0R/bSToCo/ 3skBgOvnn1dRymDLZ7yP8JsasEcDtnBzktRtDBEvGY0pUrAgLE0PY1Xru2MILRhD2tsN HGd0R1R8A0tb2X0+/F0TmcXEcfQdkRuzTwXTIxZBxrT9rn7z26Zq/33iWj154fn5HPTo yhUw== 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=aXPMYtzbEIzVHqYLCzmUjHBxMl2g4zVm3ROGN72Y1xE=; b=Xrqv5zbSkwZTPLKJwJfoyUy28bQrVBhbC038LKp91WrHl8gTF24Hq3v4XRbXIajuHd wtxpfsw19iagS2yNFuTfzJN+HtN0pb0ypvtLrrT8RFRpdvGJ44A8t+P8fXLqKFwoFdSA xnhTDUwoOza6nwxQcLxF2Nh5Ig4qZZErEmiwmnjn7rbO1g2B7H449AZbnZ4sOFgCpKFw x28eT45F7iMx0d8OboVMQgGIaI5aWIuY71CO3KW36ylNlxLy8Xr0TL6gbj4+RvAs34ab A2v5C+Fac/hQ7GaTOi+D1lw6BPtRsE/wgAXbOLPDn+cL5qy6djvO0mB6R0gldsfN0uzH eLHw== X-Gm-Message-State: APjAAAWqtqEyJdNl35z94cTfPVTbPpkwXsjVgrwc95stLcBHM+my0Dii s5+JpxG487xkR1AYeHqNCQZR/w75 X-Google-Smtp-Source: APXvYqxOAXTkQbtEXQQSeLXmQcaoeG9QLsptJWfsNpE1oWJ4DzdBK9u3ZRYiNWcq+0S67RnixMKDzg== X-Received: by 2002:a0c:8b49:: with SMTP id d9mr17202346qvc.178.1562639138432; Mon, 08 Jul 2019 19:25:38 -0700 (PDT) Received: from a-192-168-128-212.dynapool.vpn.nyu.edu (vpnrasa-wwh-pat-01.natpool.nyu.edu. [216.165.95.84]) by smtp.googlemail.com with ESMTPSA id y20sm8602751qka.14.2019.07.08.19.25.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 19:25:38 -0700 (PDT) To: Ryan Gunter , calsify@ietf.org References: <482a9dba-6d92-3b78-a9be-d90682f4d4f2@gmail.com> From: Michael Douglass Message-ID: Date: Mon, 8 Jul 2019 22:25:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------89213BEFB54BF278985310F4" Content-Language: en-US Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 09 Jul 2019 02:25:42 -0000 This is a multi-part message in MIME format. --------------89213BEFB54BF278985310F4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit As Ken said earlier this is a perfect use for the new Structured-Data property defined in the eventpub-extensions draft https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ (I will try to get a new version out this week) The benefit of this approach is that it requires no further extensions to iCalendar - your maintenance data is carried as a payload with a known schema. You're free to define this schema in whatever way seems appropriate but it would make sense to provide some indication as to how clients should handle it. A question: is this more like a task than an event? There is a task extensions draft https://datatracker.ietf.org/doc/draft-apthorp-ical-tasks/ currently expired but I think due to be revived. This defines an ESTIMATED-DURATION property so that the task dtstart/end defines a window within which the task should be accomplished. On 7/8/19 18:52, Ryan Gunter wrote: > Hello everyone, > > We really appreciate the feedback!  There are several things to digest > and research.  I will reply shortly with comments/questions. > > Thank you! > > Ryan Gunter | *Twitch* |   Network Engineering| > +1..415.568.7607 > > > On Sun, Jul 7, 2019 at 12:06 PM Doug Royer > wrote: > > > Drop the "X-" in front of your property names in your draft, as > when (if) this makes it to RFC status, they will be IANA registered. > > > > -- > > Doug Royer - (http://DougRoyer.US) > Douglas.Royer@gmail.com > 714-989-6135 > > _______________________________________________ > 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 --------------89213BEFB54BF278985310F4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

As Ken said earlier this is a perfect use for the new Structured-Data property defined in the eventpub-extensions draft

https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/

(I will try to get a new version out this week)

The benefit of this approach is that it requires no further extensions to iCalendar - your maintenance data is carried as a payload with a known schema.

You're free to define this schema in whatever way seems appropriate but it would make sense to provide some indication as to how clients should handle it.

A question: is this more like a task than an event? There is a task extensions draft

https://datatracker.ietf.org/doc/draft-apthorp-ical-tasks/

currently expired but I think due to be revived. This defines an ESTIMATED-DURATION property so that the task dtstart/end defines a window within which the task should be accomplished.



On 7/8/19 18:52, Ryan Gunter wrote:
Hello everyone,

We really appreciate the feedback!  There are several things to digest and research.  I will reply shortly with comments/questions.

Thank you!

Ryan Gunter  |   Twitch   |   Network Engineering   |   +1..415.568.7607


On Sun, Jul 7, 2019 at 12:06 PM Doug Royer <douglasroyer@gmail.com> wrote:

Drop the "X-" in front of your property names in your draft, as when (if) this makes it to RFC status, they will be IANA registered.



--

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

_______________________________________________
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
--------------89213BEFB54BF278985310F4-- From nobody Mon Jul 8 20:24: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 B090B12023F for ; Mon, 8 Jul 2019 20:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.686 X-Spam-Level: X-Spam-Status: No, score=-1.686 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 NLnhNB-Ya7mt for ; Mon, 8 Jul 2019 20:24:06 -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 539B71200F8 for ; Mon, 8 Jul 2019 20:24:06 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-07v.sys.comcast.net with ESMTP id kgg7hvAX4OOQpkgjdhmp3M; Tue, 09 Jul 2019 03:24:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1562642645; bh=BXbky56ps6VPU1P1GMEjtC5C1JiXxwz9UqcEb72xyKY=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=Ob2O0gaUOGfqBhV7c5eWheWIQVTn54NDV+2SbQ1g1VvTNkrn04PpPmhqKQUn9bwlV xYpfb6F3+NYBtFaOeAZts8pPzLxz5mJngyIJykFOozJfotMxi2cKfJRBIMVUny2AQg 4XKL8pfxQSFMM7M0Eqr8VlUHNPVOzz2xkfYHdbwmTcmfaEv2o61nJeTUzxpCnUnsiT kmRJgTRsyfSU7slu/vOExM5sBbLHYJJ1xDO/QuZb/KqGqYVHcxUqHGdOz8ifgcgb2w zPjnt0ew5Ri4Bz73iS6rGIJvJSZQezJFFWkJWd3xi49Onz/dMwU97zpPbjtUklkry3 isFMtCwfSDiMQ== Received: from THARE ([98.192.130.240]) by resomta-po-15v.sys.comcast.net with ESMTPA id kgjchfxEu3T9ukgjdhMF9B; Tue, 09 Jul 2019 03:24:05 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduvddrgedugdejudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfhfjgfufffkgggtofhtsegrtdhgpedvtdejnecuhfhrohhmpedfvfhimhcujfgrrhgvfdcuoefvihhmjfgrrhgvsegtohhmtggrshhtrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgpdhtfihithgthhdrthhvpdguohhughhrohihvghrrdhushenucfkphepleekrdduledvrddufedtrddvgedtnecurfgrrhgrmhephhgvlhhopefvjfettffgpdhinhgvthepleekrdduledvrddufedtrddvgedtpdhmrghilhhfrhhomhepthhimhhhrghrvgestghomhgtrghsthdrnhgvthdprhgtphhtthhopegtrghlshhifhihsehivghtfhdrohhrghdprhgtphhtthhopehmihhkvggrughouhhglhgrshhssehgmhgrihhlrdgtohhmpdhrtghpthhtoheprhhguhhnthgvrhepgedtthifihhttghhrdhtvhesughmrghrtgdrihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd X-Xfinity-VMeta: sc=-100;st=legit From: "Tim Hare" To: "'Michael Douglass'" , "'Ryan Gunter'" , References: <482a9dba-6d92-3b78-a9be-d90682f4d4f2@gmail.com> In-Reply-To: Date: Mon, 8 Jul 2019 23:24:03 -0400 Message-ID: <00aa01d53605$c2877010$47965030$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AB_01D535E4.3B7A8B00" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGEixvEEqPFJ3M5xn9ULchYELafUgMiEm+CAlR89OUA2KHNaacwef1A Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 09 Jul 2019 03:24:08 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00AB_01D535E4.3B7A8B00 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable STRUCTURED-DATA and SCHEMA would satisfy, I think, what I was trying to = say with EVENTTYPE in my previous post. Tim Hare Interested Bystander, Non-Inc. =20 From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Michael = Douglass Sent: Monday, July 8, 2019 10:26 PM To: Ryan Gunter ; calsify@ietf.org Subject: Re: [calsify] New Draft - Maintenance Notifications Using = iCalendar =20 As Ken said earlier this is a perfect use for the new Structured-Data = property defined in the eventpub-extensions draft https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ (I will try to get a new version out this week) The benefit of this approach is that it requires no further extensions = to iCalendar - your maintenance data is carried as a payload with a = known schema. You're free to define this schema in whatever way seems appropriate but = it would make sense to provide some indication as to how clients should = handle it. A question: is this more like a task than an event? There is a task = extensions draft=20 https://datatracker.ietf.org/doc/draft-apthorp-ical-tasks/ currently expired but I think due to be revived. This defines an = ESTIMATED-DURATION property so that the task dtstart/end defines a = window within which the task should be accomplished. =20 =20 On 7/8/19 18:52, Ryan Gunter wrote: Hello everyone, =20 We really appreciate the feedback! There are several things to digest = and research. I will reply shortly with comments/questions. =20 Thank you! =20 Ryan Gunter | Twitch | Network = Engineering | +1..415.568.7607 =20 =20 On Sun, Jul 7, 2019 at 12:06 PM Doug Royer > wrote: Drop the "X-" in front of your property names in your draft, as when = (if) this makes it to RFC status, they will be IANA registered. --=20 Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com =20 714-989-6135 _______________________________________________ calsify mailing list calsify@ietf.org =20 https://www.ietf.org/mailman/listinfo/calsify _______________________________________________ calsify mailing list calsify@ietf.org =20 https://www.ietf.org/mailman/listinfo/calsify ------=_NextPart_000_00AB_01D535E4.3B7A8B00 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

STRUCTURED-DATA and SCHEMA would satisfy, I think, what I was trying to = say with EVENTTYPE in my previous post.

Tim Hare
Interested Bystander, Non-Inc.

 

From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of = Michael Douglass
Sent: Monday, July 8, 2019 10:26 = PM
To: Ryan Gunter = <rgunter=3D40twitch.tv@dmarc.ietf.org>; = calsify@ietf.org
Subject: Re: [calsify] New Draft - = Maintenance Notifications Using = iCalendar

 

As Ken said earlier this is a = perfect use for the new Structured-Data property defined in the = eventpub-extensions draft

https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-exten= sions/

(I will try to get a new version out this = week)

The benefit of this approach is that it requires = no further extensions to iCalendar - your maintenance data is carried as = a payload with a known schema.

You're free to define = this schema in whatever way seems appropriate but it would make sense to = provide some indication as to how clients should handle = it.

A question: is this more like a task than an event? = There is a task extensions draft

https= ://datatracker.ietf.org/doc/draft-apthorp-ical-tasks/

<= p>currently expired but I think due to be revived. This defines an = ESTIMATED-DURATION property so that the task dtstart/end defines a = window within which the task should be = accomplished.

 

 <= /p>

On 7/8/19 18:52, Ryan Gunter = wrote:

Hello everyone,

 

We really appreciate the feedback!  There are = several things to digest and research.  I will reply shortly with = comments/questions.

 

Thank you!

 

Ryan Gunter  |   Twitch   |   Network Engineering   |   +1..415.568.7607

 

 

On = Sun, Jul 7, 2019 at 12:06 PM Doug Royer <douglasroyer@gmail.com> = wrote:


Drop = the "X-" in front of your property names in your draft, as = when (if) this makes it to RFC status, they will be IANA = registered.



--

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

____= ___________________________________________
calsify mailing = list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify<= /o:p>



___________________________=
____________________
calsify mailing =
list
calsify@ietf.org
https://www.ietf.o= rg/mailman/listinfo/calsify
------=_NextPart_000_00AB_01D535E4.3B7A8B00-- From nobody Mon Jul 8 20:44: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 D6A341200EB for ; Mon, 8 Jul 2019 20:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 STq999u90ZBW for ; Mon, 8 Jul 2019 20:44:07 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 6B7E01200DB for ; Mon, 8 Jul 2019 20:44:07 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id b13so3986064pfo.1 for ; Mon, 08 Jul 2019 20:44:07 -0700 (PDT) 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:content-transfer-encoding; bh=nU9t/8xBp4m1fTAUg5D4BMUF0TPDb9P70W9vmE95KVU=; b=L1YTMnymFp/mXiYcvUs9RC03EdWN5VELo76IXFzxDSItc6y9o3vMJ2eqo9fqBn/HwD e9ChuM2XG62SlnRkt2NqyI+AUr6LlQSjbSvdaMe5Ck7cKC81iWGuHx9puCI0Sy9JTTCI FFIF2l7/pcDdWmfx/AqlJLE6nDD/Ui7ihfldSf4UHZk9ipurmJKiYHnCfcZG66HTAdm+ yWb8lUYwePFM7fSLFngHCJNTA5nvw+NJUom33/ffPfviqyQ2sUFYZqvPV8c3pHO5Edly /CNCsPOoHN48n/lSC1Bxo6kVZloiTqNwHO/1eGnoEVCKCVFSQGq2s2mjk3jzOFuCE/d6 yGPA== 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:content-transfer-encoding; bh=nU9t/8xBp4m1fTAUg5D4BMUF0TPDb9P70W9vmE95KVU=; b=d+I5Wh5OXtaOigsmgdrI9BNZ8o1lWocGxjGP8RZ0if1bJSq7kix0GVrsXJ96cZQ2eT B7oJeVJVWin3Nvhd9I9/3gRIfH5/x6nxqEpeivAkVN2J3e3B9tPcwOigOj6qRhu9uvgC Uo6zWVs8Gc1BcNnNChlPaYVZOtYd4Uafyh/KV5w3NJGsSETFSPkX4dY3QL/mkTrnI3jX EKk2pGR/Vh88+1u5elMU2NZmS8Ngz00z4I1SZjDmq8NDvzxqIgw9WTUakEPhRbzgSdMV Guw0bwek5LRd+/+3Q7ZUfBfSTcUOlRLDlKSWEKZqXF6cbT+XDuI5ZSPsE3NX2FMHqt0A 05cw== X-Gm-Message-State: APjAAAWgwjl4kxyqR1KosFyN9tXHUweJOYIAh8d98yhhH9T1M3rcQZMY BTNIGqYqhynqZW/ro2pabn7rLHrMLe8E X-Google-Smtp-Source: APXvYqx60hEHzSoVNSyNK976QpPACJdKQE4VAlZlw0fuW85KMxRxpu2n9pWG0KZ/YXtX/oVe1n9uAg== X-Received: by 2002:a63:9245:: with SMTP id s5mr13076387pgn.123.1562643846353; Mon, 08 Jul 2019 20:44:06 -0700 (PDT) Received: from [192.168.1.7] ([174.27.175.146]) by smtp.googlemail.com with ESMTPSA id a26sm6678684pgl.77.2019.07.08.20.44.05 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 20:44:05 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <482a9dba-6d92-3b78-a9be-d90682f4d4f2@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <05079bf2-6494-4c6b-00dc-1a9ecd6beda0@gmail.com> Date: Mon, 8 Jul 2019 21:44:04 -0600 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [calsify] SCHEMA vs New Property 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, 09 Jul 2019 03:44:09 -0000 On 7/8/19 8:25 PM, Michael Douglass wrote: > As Ken said earlier this is a perfect use for the new Structured-Data property defined in the eventpub-extensions draft > > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > (I will try to get a new version out this week) > > The benefit of this approach is that it requires no further extensions to iCalendar - your maintenance data is carried as a payload with a known schema. You say "no further extensions". They would still have to be documented. So would that save any documentation work? If released as an RFC, then the SCHEMA uri and content value would be documented. That seems identical in function as placing them in their own property name. The only difference is that STRUCTURED-DATA allows, and forces, iCalendar implementations to include parsers for each unique SCHEMA. And does that without *any* restriction to the content (VALUE) format. Where as, by defining them as new properties, any compliant iCalendar implementation can parse them now, preserve them, even when they do not know what to do with them. They can even display them as KEY/VALUE pairs. STRUCTURED-DATA just forces multiple and unlimited new and random data formats into the VALUE. While still requiring them to be documented and published. Seems like more documentation work, and more implementation work. With one new data type parser for each new SCHEMA published. Why have 2+ data formats in the same object? It looks to me as if STRUCTURED-DATA is just a way of passing opaque data that will contain proprietary information. This completely reverses the idea of a standard calendar object. If your going to document a new data-set. Document it in iCalendar format. Not in unlimited, unrestricted and random formats. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Mon Jul 8 20:57: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 C6C0F12024E for ; Mon, 8 Jul 2019 20:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 F4SfwqM5BrQ9 for ; Mon, 8 Jul 2019 20:57:04 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 084C61200FD for ; Mon, 8 Jul 2019 20:57:04 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id b3so6042781plr.4 for ; Mon, 08 Jul 2019 20:57:04 -0700 (PDT) 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:content-transfer-encoding; bh=hWJzd5vtNlUdq7mLbIT89Du45zOFP0VcQSPJYZ07MKA=; b=BO5PvyH+qbZ/SYi3m/14Oq4Bd3KTLDbVnHctAZ/9CRr7gtx2kYbbuvF28f595mda6s IaQfG1jMN4zEpSWppryCQdsaiX5zWvL9JOYH+ToHcapWH8k76jOzmhSYnVUlNLE0WMq9 CqQ3VQRBUz66m9n0krskxZaXCiQeY+fNugTQHvRpuqUqRNGr0Ry2Chn1bbAI8HBszps3 mrOCgKNHdpgPUW9ELNzAdX5zlxdcjbGFmDIwHtZfLAPxPW62Xt88MsWpMXblzAvbTWN2 RLkR9FS17BD7eN1JfCmIVSA2fcUvsnHGKSKqcGb9J1Gn8UoXqVKPj38VIR18FyOe8SEY GGKw== 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:content-transfer-encoding; bh=hWJzd5vtNlUdq7mLbIT89Du45zOFP0VcQSPJYZ07MKA=; b=pY2aYzMaitWY/5G8qMjOzkmixLw9eiRN9fFxt/yyo60DpyGZyLOtyBn9VY/8wV8mo1 PQkFhYvpL5g7d2wNPH/aG4pVCP3Povau0osLnUQC1T6eXssYL5qVPws9bni8JSEVr18X +KebMDSRaPzLPIOGEWpPH/2+vNEdBR9THe2YjoTe65WVwvGIrte4W0gNh/5rmlL09U+e Q3N/jKvF6EZO1Tqw6DLE0VSbmnDIZesnljb0a/XekWEDaIq0wB2F62xiasa7sGhSaVLg YoTXZho9T5fWEbjRmXXNSDhcIq9SWrcFlKXQJWjZH7rI1fuTvW8tVpdNxLOHcXD8LOj5 759Q== X-Gm-Message-State: APjAAAU/OwoU7pjPHGRpExzv2pHa0zZajiTNGx4PmPrlA/2oSf3SBtTN evuzPRFB2ZVV5lWA6EdXhI2zel1/uBsf X-Google-Smtp-Source: APXvYqzzFDENuWA2x8Ji6hQlyG7+JwZ8B9W3d7CYZFkMFZi8oFr9be/qEnQ5KgR9sv9c11N+2hpR+w== X-Received: by 2002:a17:902:8205:: with SMTP id x5mr29752395pln.279.1562644623197; Mon, 08 Jul 2019 20:57:03 -0700 (PDT) Received: from [192.168.1.7] ([174.27.175.146]) by smtp.googlemail.com with ESMTPSA id 23sm22100321pfn.176.2019.07.08.20.57.02 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 20:57:02 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: Organization: http://SoftwareAndServices.NET Message-ID: Date: Mon, 8 Jul 2019 21:57:01 -0600 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 09 Jul 2019 03:57:06 -0000 On 7/3/19 3:12 PM, Ken Murchison wrote: > Hi Ryan, > > My initial reaction to reading this is that all of the new maintenance properties should be grouped under a single entity such as a STRUCTURED-DATA property or a new MAINTNOTE sub-component, similar to PARTICIPANT. New MAINTNOTE component - great idea. Then existing implementation should still be able to parse and preserve the content without knowing or acting on the content. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Mon Jul 8 21:04: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 4675912024E for ; Mon, 8 Jul 2019 21:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 KoxvWO2eZr0a for ; Mon, 8 Jul 2019 21:04:40 -0700 (PDT) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 C7FDF12023F for ; Mon, 8 Jul 2019 21:04:39 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id l9so12052905qtu.6 for ; Mon, 08 Jul 2019 21:04:39 -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-transfer-encoding:content-language; bh=AuN3c/vXSFhGuj1GsjJiQv7PG5GLngXBp/WnlMHKpao=; b=lC6J/nxP3vzbbNvPpTLQbDtAlwj8+PvV/RCWsSCNbI8sNpnkCzTl7ir0jQQHLe0Ugh /qbQFxje/2YRCdjFBxsL7E791FyitUeay49a3fNh4DkRzxjrJNe0o6PqMee/wGrosNpJ UiCnU2aUyaFwhQUuEk6eVDP7IR5cqb/QhdMYxIAyQM72P2DExV6zl8xPxaXwxZQKWp+C K/BiNf45r74Q7HaLlLWcq3ntbFGDs5s85/5u+ZdRGmhp9O8QEEyqA3HXb8Ow4eFUZbB7 sTbgi7kWwbUIamKOiXTceMkhm6v95vi7H0RxU5vPBqbNhYWX9YSTGmAr9UjTNAXnp/0O oi0g== 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-transfer-encoding :content-language; bh=AuN3c/vXSFhGuj1GsjJiQv7PG5GLngXBp/WnlMHKpao=; b=pBxuVfLcmwGuTXc20GNetQDTFS5R1YQdJV6pF/HAajQQKUT93NhEC7vNfgvJ2NTvGH MGR8NjS69+2PtwWg31jJeRWUVVE91i1rKZFwF0xVxus0OZjU9r8R40UB3gWVypyuD3t/ ZXqmy+sdCQwOBynSpVOIqU6q2IVsX+jlYh7NsUrvvH4R9oEI6atjXXaPE3AzvQcc2tpF I9HZE4hrT/8aZ6MV4MPU3Uw7H7XVl0399pbunCWMmAfVApPeIdiY8xa6h62z9Xnq6row E3NDy724/DeWpNTIkSlDx5dOAbqX7sxXn6DtGOpRNWLBl2nux3/e+tNKDVx7EA2lN8Q+ jr3Q== X-Gm-Message-State: APjAAAWRf/mCLm4OIxaLfh+gjaYBW1+k9c59BcZZCeg9D7FYKNq/8j+o kEcCUqf6dNgFD5lhq7CdcdUWwf2S X-Google-Smtp-Source: APXvYqwCVGC52t/4EKhsfWsq0QnfSdN6SBWs8DiJj1sZVG6rfXWpnkJy2CSRSkj2E5Oxcllg9CIBNA== X-Received: by 2002:ac8:4252:: with SMTP id r18mr16792924qtm.357.1562645078542; Mon, 08 Jul 2019 21:04:38 -0700 (PDT) Received: from a-192-168-128-212.dynapool.vpn.nyu.edu (vpnrasa-wwh-pat-01.natpool.nyu.edu. [216.165.95.84]) by smtp.googlemail.com with ESMTPSA id q56sm9546061qtq.64.2019.07.08.21.04.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 21:04:38 -0700 (PDT) To: calsify@ietf.org References: <482a9dba-6d92-3b78-a9be-d90682f4d4f2@gmail.com> <05079bf2-6494-4c6b-00dc-1a9ecd6beda0@gmail.com> From: Michael Douglass Message-ID: <968f0c5a-c198-19eb-8e56-7be6e2b6820a@gmail.com> Date: Tue, 9 Jul 2019 00:04:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <05079bf2-6494-4c6b-00dc-1a9ecd6beda0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] SCHEMA vs New Property 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, 09 Jul 2019 04:04:42 -0000 On 7/8/19 23:44, Doug Royer wrote: > On 7/8/19 8:25 PM, Michael Douglass wrote: >> As Ken said earlier this is a perfect use for the new Structured-Data >> property defined in the eventpub-extensions draft >> >> https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ >> >> (I will try to get a new version out this week) >> >> The benefit of this approach is that it requires no further >> extensions to iCalendar - your maintenance data is carried as a >> payload with a known schema. > > You say "no further extensions". They would still have to be > documented. So would that save any documentation work? > If released as an RFC, then the SCHEMA uri and content value would be > documented. That seems identical in function  as placing them in their > own property name. > > The only difference is that STRUCTURED-DATA allows, and forces, > iCalendar implementations to include parsers for each unique SCHEMA. > And does that without *any* restriction to the content (VALUE) format. STRUCTURED-DATA DOES NOT force any client to parse the data. If it doesn't recognize the schema it's free to ignore it completely. > > Where as, by defining them as new properties, any compliant iCalendar > implementation can parse them now, preserve them, even when they do > not know what to do with them. They can even display them as KEY/VALUE > pairs. > > STRUCTURED-DATA just forces multiple and unlimited new and random data > formats into the VALUE. While still requiring them to be documented > and published. Seems like more documentation work, and more > implementation work. With one new data type parser for each new SCHEMA > published. > > Why have 2+ data formats in the same object? I see no requirement for publishing anything about the schema other than to reserve it. The only requirement for publishing is if the schema definer wishes 3rd parties to make use of it. It doesn't even have to be defined and published with the ietf. It's payload > > It looks to me as if STRUCTURED-DATA is just a way of passing opaque > data that will contain proprietary information. This completely > reverses the idea of a standard calendar object. > > If your going to document a new data-set. Document it in iCalendar > format. Not in unlimited, unrestricted and random formats. So if somebody has XML or JSON data they wish to transport - already defined by a schema - they are required to recast that as iCalendar? I think not. Without STRUCTURED-DATA they'll just push it across as an x-prop or attachment then it's even more opaque. > From nobody Tue Jul 9 05:38: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 8B57E12014E for ; Tue, 9 Jul 2019 05:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.297 X-Spam-Level: X-Spam-Status: No, score=-1.297 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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_HELO_NONE=0.001, 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=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 DmoaPAwiV4ni for ; Tue, 9 Jul 2019 05:38:36 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (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 8D4F3120143 for ; Tue, 9 Jul 2019 05:38:36 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-10v.sys.comcast.net with ESMTP id kpKshqsDyjs8SkpOFhkHc4; Tue, 09 Jul 2019 12:38:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1562675915; bh=Mrt3PPgqM5GZj44WX951knY5I3BOKeYfnP4C/WVAL2g=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=kr9HZ2Vc6ePyJpSDGy4EnrzxgJpLOFDJuVe5MCxlDZgJDv+Is/hEZ2+EsihBGUHrE d128pzADyDddQNNfulqbe9STyqvg3NSD0rgd5H186Eqb6Rqvvbqs6us09LJZWgATwD JFmAb+PZBRobUTLbDfImOnYrUomqwZiC4HTUL6vNjoAyTKCXK7+d29vC5zu9AlhRAR lDxrKhBrogPc4/OBUW7eV2cu7Tmc+5VRa9X9v4lUSXVEGmzdS2VhRlE4wsvC62zq8C 3wVMZ+c/KEP0fGF241ozyNu/52uEGNO14BTH3lveNzKnnYHlWguENCKQLxhPCdWcxB RVkzekKt4NhKA== Received: from THARE ([98.192.130.240]) by resomta-po-09v.sys.comcast.net with ESMTPA id kpOEhRpMfC6m1kpOFhTbfT; Tue, 09 Jul 2019 12:38:35 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduvddrgedvgdehjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfggtgfothesrgdtghepvddtvdenucfhrhhomhepfdfvihhmucfjrghrvgdfuceovfhimhfjrghrvgestghomhgtrghsthdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucfkphepleekrdduledvrddufedtrddvgedtnecurfgrrhgrmhephhgvlhhopefvjfettffgpdhinhgvthepleekrdduledvrddufedtrddvgedtpdhmrghilhhfrhhomhepthhimhhhrghrvgestghomhgtrghsthdrnhgvthdprhgtphhtthhopegtrghlshhifhihsehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-Xfinity-VMeta: sc=0;st=legit From: "Tim Hare" To: Date: Tue, 9 Jul 2019 08:38:33 -0400 Message-ID: <00d001d53653$38fcba50$aaf62ef0$@comcast.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D1_01D53631.B1EB1A50" X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AdU2BdEnla0k/fMQTjGL9B+Bj+c3FQ== Archived-At: Subject: [calsify] question about STYLED-DESCRIPTION in the eventpub extensions document 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, 09 Jul 2019 12:38:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D1_01D53631.B1EB1A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Now that I've skimmed through https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ I have a question about STYLED-DESCRIPTION, VALUE=TEXT. Should FMTTYPE be required in that instance? If it is not required and/or not specified, what default 'style' SHOULD be applied to the text of the STYLED-DESCRIPTION: ? Should it be 'text/plain' making it essentially DESCRIPTION: or should some other format like 'text/markdown' be specified as a default? Tim Hare Interested Bystander, Non-Inc. ------=_NextPart_000_00D1_01D53631.B1EB1A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Now that = I’ve skimmed through https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-exten= sions/  I have a question about STYLED-DESCRIPTION, = VALUE=3DTEXT.   Should FMTTYPE be required in that instance? = If it is not required and/or not specified, what default = ‘style’ SHOULD be applied to the text of the = STYLED-DESCRIPTION:  ?  Should it be = ‘text/plain’  making it essentially DESCRIPTION:  = or should some other format like ‘text/markdown’ be = specified as a default?

Tim Hare
Interested Bystander, = Non-Inc.

 

 

 

------=_NextPart_000_00D1_01D53631.B1EB1A50-- From nobody Tue Jul 9 13:57:43 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 4D6BC12011B for ; Tue, 9 Jul 2019 13:57:42 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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=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 byJIm2IEkL0I for ; Tue, 9 Jul 2019 13:57:39 -0700 (PDT) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (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 C77BB12068C for ; Tue, 9 Jul 2019 13:57:39 -0700 (PDT) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-06v.sys.comcast.net with ESMTP id kx0nhHQ3pMC2xkxBDh7IjY; Tue, 09 Jul 2019 20:57:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1562705859; bh=F/JMhoquLEUteHNgSkUTUfVvJxHTQIsGohDsCWDGVsg=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=qh1VyRi9ZyJJ20Xc4HOIfdyfakuGRiLi0mkJabhyAqVmgUI277sCTYnxTp0VFb9mA C5BNlRvH+UDRgNJnrt49nsgon/pIPqGaU9H8FaC+fSLTGGm/4KTmRGQ6r2PmXoQJNj dcrm9OcAQ5feYwm9lIxsVM0IstVjlHV+AMfGya1Pk28YXSlgOQUxDObPDRwlw3XE0d 7KT0zPI0S5bvJdPX+Mi5ronkLJ0m3P9z531F3DabDqy1+kymvYHwfjcR2tzpYN5dWa 6A74qIUWc3mnoXix8izfi7Xx6gXm0tWpv2WhHqFeqqSjqdpptkckuppybyBvS4lIeq CkmfMIO6KmxEA== Received: from THARE ([98.192.130.240]) by resomta-po-15v.sys.comcast.net with ESMTPA id kxBChisnI3T9ukxBChN7pG; Tue, 09 Jul 2019 20:57:39 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgeduvddrgeefgddulecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvfhgjufffkfggtgfgofhtsehtjehgtddvtddvnecuhfhrohhmpedfvfhimhcujfgrrhgvfdcuoefvihhmjfgrrhgvsegtohhmtggrshhtrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgpdguohhughhrohihvghrrdhushenucfkphepleekrdduledvrddufedtrddvgedtnecurfgrrhgrmhephhgvlhhopefvjfettffgpdhinhgvthepleekrdduledvrddufedtrddvgedtpdhmrghilhhfrhhomhepthhimhhhrghrvgestghomhgtrghsthdrnhgvthdprhgtphhtthhopegtrghlshhifhihsehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedt X-Xfinity-VMeta: sc=0;st=legit From: "Tim Hare" To: References: <482a9dba-6d92-3b78-a9be-d90682f4d4f2@gmail.com> <05079bf2-6494-4c6b-00dc-1a9ecd6beda0@gmail.com> In-Reply-To: <05079bf2-6494-4c6b-00dc-1a9ecd6beda0@gmail.com> Date: Tue, 9 Jul 2019 16:57:36 -0400 Message-ID: <019701d53698$f0864d40$d192e7c0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Content-Language: en-us Thread-Index: AQGEixvEEqPFJ3M5xn9ULchYELafUgMiEm+CAlR89OUA2KHNaQI0JcIrpx/+uWA= Archived-At: Subject: Re: [calsify] SCHEMA vs New Property 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, 09 Jul 2019 20:57:42 -0000 What is needed is documentation that says all calendar UAs are not required to handle STRUCTURED-DATA and SCHEMA, perhaps that if STRUCTURED-DATA is used then DESCRIPTION SHOULD be present to describe what the structured data is so that any CUA can display _that_ text, but consumers of the calendar item that DO understand the SCHEMA can use it. In my view, defining new properties for every possible kind of VEVENT or VTODO amounts to the same amount of work as defining a SCHEMA for that structured data. CUAs would fail, graciously, to process those properties in the just about same way as they'd fail to handle the structured data. The difference, to me, is that using STRUCTURED-DATA and SCHEMA means the RFC isn't constantly updated for new use cases involving new kinds of data that is related to the calendar event but not calendar data per se. Tim Hare Interested Bystander, Non-Inc. -----Original Message----- From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Doug Royer Sent: Monday, July 8, 2019 11:44 PM To: calsify@ietf.org Subject: [calsify] SCHEMA vs New Property On 7/8/19 8:25 PM, Michael Douglass wrote: > As Ken said earlier this is a perfect use for the new Structured-Data property defined in the eventpub-extensions draft > > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > (I will try to get a new version out this week) > > The benefit of this approach is that it requires no further extensions to iCalendar - your maintenance data is carried as a payload with a known schema. You say "no further extensions". They would still have to be documented. So would that save any documentation work? If released as an RFC, then the SCHEMA uri and content value would be documented. That seems identical in function as placing them in their own property name. The only difference is that STRUCTURED-DATA allows, and forces, iCalendar implementations to include parsers for each unique SCHEMA. And does that without *any* restriction to the content (VALUE) format. Where as, by defining them as new properties, any compliant iCalendar implementation can parse them now, preserve them, even when they do not know what to do with them. They can even display them as KEY/VALUE pairs. STRUCTURED-DATA just forces multiple and unlimited new and random data formats into the VALUE. While still requiring them to be documented and published. Seems like more documentation work, and more implementation work. With one new data type parser for each new SCHEMA published. Why have 2+ data formats in the same object? It looks to me as if STRUCTURED-DATA is just a way of passing opaque data that will contain proprietary information. This completely reverses the idea of a standard calendar object. If your going to document a new data-set. Document it in iCalendar format. Not in unlimited, unrestricted and random formats. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 _______________________________________________ calsify mailing list calsify@ietf.org https://www.ietf.org/mailman/listinfo/calsify From nobody Tue Jul 9 15:18:50 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 3C9611201B8 for ; Tue, 9 Jul 2019 15:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 AXZfSJ0ufTgT for ; Tue, 9 Jul 2019 15:18:46 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 DE70A120141 for ; Tue, 9 Jul 2019 15:18:45 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id a27so381595qkk.5 for ; Tue, 09 Jul 2019 15:18:45 -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-transfer-encoding:content-language; bh=kPi1EhAz8EWICSxYrb35MoHE03d4D4Dc8AaROoOS7+A=; b=oNdFxxeBii7DZ9ppgo2vZpfqjG4z2ltJC92GFebSI2xpDqDAVvpb0b0XZkjqGd5IW8 p+5nsTPR3Cz/uF/u2lx44TEKZ3WY/c9vMCEYpPXxzpBjF4nj9i0yHciEM7jI1z8wVemL ic0CMKODIwTI60kyBBqrl5xsBZWplbCg6I24ajYAbvpYeh93O6thXP//jiyPMRSP8ZRz sBJiX1RWjYJoRFmwOZeNpkGz95e0zSGofeAl9/VebAaLdK/eVLye/GgwcZxm5ONZPRr7 DQMH3JMlg9p3/AQ9LfMcvDXOZg6IRhvQrWr+ek9nim3zTbujls3iz7wz+tHC81Tbb/dv LIHg== 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-transfer-encoding :content-language; bh=kPi1EhAz8EWICSxYrb35MoHE03d4D4Dc8AaROoOS7+A=; b=f3wJgBWNAahhhSXigxGDCtsPv2DNunZ5+xx9sYSg3Ag2DOsdRHeRZisn+cn3lDpMhJ am1iF0lvnUnUhtR4gojMhrC5b0PfVjBzTIsuDdKRbANocvT017GQX8wYuLe4QrNTnhY+ DXJSbWlu8IraGa+4WaNCLSPFjv7YdxGp3BqFxY1lmWOod54hTykENLjPzZEOL65xtotm iOLrKa76gKfVbrj9TX6MMZwrkcdoNT/+Qv4fM5CCxTMODJWYhOgbEsMXJtoRZH3spGwY g85JqV9d1OhgnK/CV5y5rcG3kmhdc8oKIWTbOAza768q8tLoEiXhn2ZHmrbolLEonhqV X6cw== X-Gm-Message-State: APjAAAW87EOF3NjRGf3R3izRY9NKxsL+psCCB9aR8/V7eTpCsLgckeBE zhTgj3hRFFs2CH/ksrUDHCqtjRZRakY= X-Google-Smtp-Source: APXvYqyvRkriaypg/0f4/m0QjbgQkFPLINJT2pXZBelQkqnNiaDsFyCg+UC/ZsdRvOzASukwVGXXTQ== X-Received: by 2002:a37:6b42:: with SMTP id g63mr20480429qkc.80.1562710724736; Tue, 09 Jul 2019 15:18:44 -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 p3sm121352qta.12.2019.07.09.15.18.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 15:18:44 -0700 (PDT) To: Tim Hare , calsify@ietf.org References: <482a9dba-6d92-3b78-a9be-d90682f4d4f2@gmail.com> <05079bf2-6494-4c6b-00dc-1a9ecd6beda0@gmail.com> <019701d53698$f0864d40$d192e7c0$@comcast.net> From: Michael Douglass Message-ID: <1887200c-8a74-6e6a-7cf8-abb0409749b3@gmail.com> Date: Tue, 9 Jul 2019 18:18:43 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <019701d53698$f0864d40$d192e7c0$@comcast.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [calsify] SCHEMA vs New Property 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, 09 Jul 2019 22:18:48 -0000 On 7/9/19 16:57, Tim Hare wrote: > What is needed is documentation that says all calendar UAs are not required > to handle STRUCTURED-DATA and SCHEMA, perhaps that if STRUCTURED-DATA is > used then DESCRIPTION SHOULD be present to describe what the structured > data is so that any CUA can display _that_ text, but consumers of the > calendar item that DO understand the SCHEMA can use it. > > In my view, defining new properties for every possible kind of VEVENT or > VTODO amounts to the same amount of work as defining a SCHEMA for that > structured data. CUAs would fail, graciously, to process those properties > in the just about same way as they'd fail to handle the structured data. > The difference, to me, is that using STRUCTURED-DATA and SCHEMA means the > RFC isn't constantly updated for new use cases involving new kinds of data > that is related to the calendar event but not calendar data per se. Additionally - data that is incompatible with the iCalendar format can be transported easily. And I don't think it's quite the same amount of work. New iCalendar properties need to be generally useful in calendars and scheduling. Very specific properties used to address a need such as this are probably better contained in data with their own schema. There's a whole other discussion as to whether or not these properties are generally useful - probably not as something only for maintenance. As an aside having reread the draft - email is not the only possible transport mechanism. CalDAV or some other protocol might be appropriate. Any draft should probably allow for different ways of transporting the messages. > > Tim Hare > Interested Bystander, Non-Inc. > > > > > -----Original Message----- > From: calsify [mailto:calsify-bounces@ietf.org] On Behalf Of Doug Royer > Sent: Monday, July 8, 2019 11:44 PM > To: calsify@ietf.org > Subject: [calsify] SCHEMA vs New Property > > On 7/8/19 8:25 PM, Michael Douglass wrote: >> As Ken said earlier this is a perfect use for the new Structured-Data > property defined in the eventpub-extensions draft >> https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ >> >> (I will try to get a new version out this week) >> >> The benefit of this approach is that it requires no further extensions to > iCalendar - your maintenance data is carried as a payload with a known > schema. > > You say "no further extensions". They would still have to be documented. So > would that save any documentation work? > If released as an RFC, then the SCHEMA uri and content value would be > documented. That seems identical in function as placing them in their own > property name. > > The only difference is that STRUCTURED-DATA allows, and forces, iCalendar > implementations to include parsers for each unique SCHEMA. And does that > without *any* restriction to the content (VALUE) format. > > Where as, by defining them as new properties, any compliant iCalendar > implementation can parse them now, preserve them, even when they do not know > what to do with them. They can even display them as KEY/VALUE pairs. > > STRUCTURED-DATA just forces multiple and unlimited new and random data > formats into the VALUE. While still requiring them to be documented and > published. Seems like more documentation work, and more implementation work. > With one new data type parser for each new SCHEMA published. > > Why have 2+ data formats in the same object? > > It looks to me as if STRUCTURED-DATA is just a way of passing opaque data > that will contain proprietary information. This completely reverses the idea > of a standard calendar object. > > If your going to document a new data-set. Document it in iCalendar format. > Not in unlimited, unrestricted and random formats. > From nobody Tue Jul 9 20:36:26 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 453981200B7 for ; Tue, 9 Jul 2019 20:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 U-AYqutj2UrV for ; Tue, 9 Jul 2019 20:36:23 -0700 (PDT) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (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 E3DC612008B for ; Tue, 9 Jul 2019 20:36:22 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id ay6so461055plb.9 for ; Tue, 09 Jul 2019 20:36:22 -0700 (PDT) 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:content-transfer-encoding; bh=wU73Vr60x0DDHFuHNmsIFXVC7YzBUXBf2+8VWUaD2pk=; b=IPJXjSEz4NrsiytLsExs5R6Xt3n1Us7qge5FV7PM7BpFcxQNlRbtCkEIA6veYwLwK7 Aefo4/2ls9R0z2UwP703rG7Tj55KkSHccijiViNcqeh1yhVtiO3SjOnsVcazr4YHbmFG bQOhn6nXaSbQVuQwLku0wOIrh9OyFYsdulLXRQzs3UNxIVB/Rpao5tWmmziqpNsCjU+R fFPuv/lpPLaS7aRtkuBQHZtWml5Hxl6TaoF5PfwL5lP9+53SGQDs44NSyKR53vemQalX 2xW66fZSluazYHijoblDulLWTEqnwtj3pYp5BlVXKj2b0LPlBJiV26PfktOFUsVEGCkP u+NQ== 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:content-transfer-encoding; bh=wU73Vr60x0DDHFuHNmsIFXVC7YzBUXBf2+8VWUaD2pk=; b=S1xvGeI9kym1NHKJWYNIK36JMXaKLXG8izQmn3zQo0Q/pAajrCwCvWxysi9I5Swp1Y braburoRQkCyEJAQiBVJZk+aetAS5u56mf46/Gr0A01d9ix3aLtvR73IpNkWcZZS0TIu bB0ALlbUmOUJucXW6StELy0T1LIHjPdNmwGRtXzwjZT5r4w2VFdO/MGGG48RI+3oSt1o UTzj2LtW+O/UsENfyjTdxCGIKpma3BNDSr12qaeZqWbF3xowKXkbRP5u/2DL3fC0vugw lR902k1/KOpiEWkmSYp5DDjn3AhdIiQKDWdMQWrF3sT+63cpiUlBVOvhu7OKlTB/nu1z s4xg== X-Gm-Message-State: APjAAAUF5zUZCgx32xZ80XsHDnPU63WcxUgbQD24Y0Kp+kWwxPbCz7q7 jq7PAhjBBiXAbnrtqrJ42NXPgqoR7S03 X-Google-Smtp-Source: APXvYqwieIz5KxdvqlrEx5ZK8VWfHM1H+DJtvsBXEFNNIVfTBWXGq0rdq4VPqGRD9tDrk1PALKZKaA== X-Received: by 2002:a17:902:8547:: with SMTP id d7mr36971819plo.171.1562729782032; Tue, 09 Jul 2019 20:36:22 -0700 (PDT) Received: from [192.168.1.7] ([174.27.175.146]) by smtp.googlemail.com with ESMTPSA id d14sm508534pfo.154.2019.07.09.20.36.21 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 20:36:21 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <482a9dba-6d92-3b78-a9be-d90682f4d4f2@gmail.com> <05079bf2-6494-4c6b-00dc-1a9ecd6beda0@gmail.com> <968f0c5a-c198-19eb-8e56-7be6e2b6820a@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Tue, 9 Jul 2019 21:36:20 -0600 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: <968f0c5a-c198-19eb-8e56-7be6e2b6820a@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] SCHEMA vs New Property 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, 10 Jul 2019 03:36:24 -0000 On 7/8/19 10:04 PM, Michael Douglass [Masked] wrote: > > > > On 7/8/19 23:44, Doug Royer wrote: >> On 7/8/19 8:25 PM, Michael Douglass wrote: >>> As Ken said earlier this is a perfect use for the new Structured-Data property defined in the eventpub-extensions draft > > I see no requirement for publishing anything about the schema other than to reserve it. The only requirement for publishing is if the schema definer wishes 3rd parties to make use of it. It doesn't even have to be defined and published with the ietf. It's payload Yes, your proposing a free for all data object. Do whatever you want. The opposite of a standard object. >> It looks to me as if STRUCTURED-DATA is just a way of passing opaque data that will contain proprietary information. This completely reverses the idea of a standard calendar object. >> >> If your going to document a new data-set. Document it in iCalendar format. Not in unlimited, unrestricted and random formats. > So if somebody has XML or JSON data they wish to transport - already defined by a schema - they are required to recast that as iCalendar? I think not. Without STRUCTURED-DATA they'll just push it across as an x-prop or attachment then it's even more opaque. They both are opaque data, except you saying it is different. X-PROP and STRUCTURED-DATA are the same thing. Random non standard blobs of data to implementations that do not know what they mean. The ATTACH base-64 encoding/decoding value allows for any kind of data. X-MY-PROP;x-myparam-data-set-3:base-64-text They both contain the same thing. That was the debates with X-PROP. A standard way to parse random blobs of propitiatory data. It makes you want to standardize the data sets to use it across vendors. And STRUCTURED-DATA is a name that implies structure. It is not. It could be unstructured data, blobs of weather data, blobs of random disk errors. It has no added value over X-PROP or ATTACH. The data could be base-64 encoded or not, it is just text. Example: ATTACH;FMTTYPE=text/html;...:base-64 encoded html page, or URL or CID to that page vs STRUCTURED-DATA:SCHEMA=http://www.w3.org/TR/html4;...:base-64 encoded html page, or URL or CID to that page, or text that may have to be base64 encoded anyway because of its content. vs STRUCTURED-DATA:SCHEMA=http://MyPrepratorySchema;...:base-64 encoded html page, or URL or CID to that page, or text that may have to be base64 encoded anyway because of its content. Use ATTACH with a CID value, pointing to MIME object and set the mime-type value. Set the ATTACH fmttypeparam and CID part MIME-TYPE to text/xml or application/json (or whatever) and include anything you can transport. Or set the ATTACH value to an external URL with ATTACH fmttypeparm set to the correct data type. If you need to, define and register a new mime-type for your data (schema). Or use an x-mime-type with ATTACH with your preparatory data. Did I miss something that STRUCTURED-DATA can do, that X-PROP or ATTACH can not do? Creating it simply because you do not want to base64 encode text is a heavy solution when you can already ATTACH the value in binary, text, or whatever by using a CID URI or a URL URI all of which can contain plain text. iCalendar is a MIME object. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Wed Jul 10 10:08:48 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 98F161200FE for ; Wed, 10 Jul 2019 10:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.297 X-Spam-Level: X-Spam-Status: No, score=0.297 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 gnDSIMZXxHHA for ; Wed, 10 Jul 2019 10:08:45 -0700 (PDT) Received: from mail-pf1-x442.google.com (mail-pf1-x442.google.com [IPv6:2607:f8b0:4864:20::442]) (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 C387D120047 for ; Wed, 10 Jul 2019 10:08:45 -0700 (PDT) Received: by mail-pf1-x442.google.com with SMTP id q10so1378332pff.9 for ; Wed, 10 Jul 2019 10:08:45 -0700 (PDT) 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:content-transfer-encoding; bh=sDBkkUC0o//L6wKox6JMv6ObS04fThC8hI0b4Bthfac=; b=Kio1PEsaY5NlrnrYgCzfBrpnkpMVf/AsIQ8z0m7XOkHoEhiBW1HDngLwbHoqQL3QRs VYi7zlKUb/z0zJcycf/sgg3p6cF01ll14Vmoxli0/3AxkJzlFXlU4Ck9NIpX0GXLvQrV yMvlecds0nF3Fm1uDm6y0m4bCT6Dd8hhr9pZk5Q3M8vyvjlTU3OuAR87jvw58VYXgN/6 wt49dE+7O5z6HkOcgpjzSbLsevCDFyDsgx6JdTwoBOM5VXrAbe5+R6ZNo0aqdClTnh8W zAZmGSock5JjsyZYl0WYfMWURHPNwyE9pWhch7jqDRAzRZigy2VQ5UvIZ7yKe2p2e5PL v9pQ== 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:content-transfer-encoding; bh=sDBkkUC0o//L6wKox6JMv6ObS04fThC8hI0b4Bthfac=; b=pXtjc/TAUij5d6cLFyfSmGw9B4ePCovc4TjnQ2EmHvDBIohv4Vkw9ZppLM/GK9V+xq DCdJgr614Kzu4l7iOwiCGPQTJjUiZIqEa8szjAu3M/b8szOu49ykj3/35+8YW+6IceLj EWN1AHtzDCwnP/HdTCNXnT3hWtqf0q51L8KT5kdFslwpH2MRFTZCG4ze8PnhsuNS1fpB JLoAQ40Wft7ZGXRKNIakvwlsehkcPMwZzsk/Wm8SNyElwvfaS5nBujGnlCT8FEStTfPl ke7iQgx5PDgxkmQ9HoDfq5HyQa3hJ5+n/XR5248rR+4sUE6DqpEjto1MHgEQzR+VEUfT v0Aw== X-Gm-Message-State: APjAAAWEiN8f5it1UYu2nOO6cBx7SL2rSQZFC7PrjXR5I6Io9so5tPFE ZliuJmZ+0obCsqRvJ+4n0jXILMBmDLE+ X-Google-Smtp-Source: APXvYqwJ1/h6FwQwnCZ6u7TS707KBV+C4QQowyxEcby7CXGDrZvgcmtZBFKDoqrwKOwcJBpPzWtmZw== X-Received: by 2002:a65:6152:: with SMTP id o18mr37033052pgv.279.1562778524493; Wed, 10 Jul 2019 10:08:44 -0700 (PDT) Received: from [192.168.1.7] ([174.27.175.146]) by smtp.googlemail.com with ESMTPSA id f72sm5305310pjg.10.2019.07.10.10.08.43 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jul 2019 10:08:43 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <482a9dba-6d92-3b78-a9be-d90682f4d4f2@gmail.com> <05079bf2-6494-4c6b-00dc-1a9ecd6beda0@gmail.com> <019701d53698$f0864d40$d192e7c0$@comcast.net> <1887200c-8a74-6e6a-7cf8-abb0409749b3@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <46e5f495-385a-e93e-088a-0316da3cb387@gmail.com> Date: Wed, 10 Jul 2019 11:08:42 -0600 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: <1887200c-8a74-6e6a-7cf8-abb0409749b3@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] SCHEMA vs New Property 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, 10 Jul 2019 17:08:47 -0000 On 7/9/19 4:18 PM, Michael Douglass wrote: > > On 7/9/19 16:57, Tim Hare wrote: >> What is needed is documentation that says all calendar UAs are not required >> to handle STRUCTURED-DATA and SCHEMA,  perhaps that if STRUCTURED-DATA is >> used then DESCRIPTION  SHOULD be present to describe what the structured >> data is so that any CUA can display _that_ text,  but consumers of the >> calendar item that DO understand the SCHEMA can use it. >> >> In my view, defining new properties for every possible kind of VEVENT or >> VTODO amounts to the same amount of work as defining a SCHEMA for that >> structured data.  CUAs would fail, graciously, to process those properties >> in the just about same way as they'd fail to handle the structured data. >> The difference, to me,  is that using STRUCTURED-DATA and SCHEMA  means the >> RFC isn't constantly updated for new use cases involving new kinds of data >> that is related to the calendar event but not calendar data per se. The effect of SCHEMA would be to create an entirely new object identifier to replace mime-type. If the data is proprietary, the X-PROP with an undocumented data type works now and no documentation needed. Implementations are free to ignore X-PROP. If the data is to be shared between vendors, then documenting is what is needed, and is the reason for the IETF, RFCs, and standards. It can be released as a proposed standard, or informational. The issue with maintenance is work flow, and not so much data values. They are proposing both the flow and the data. The draft needs work and feedback. > Additionally - data that is incompatible with the iCalendar format can be transported easily. It already can, iCalendar is a MIME content type that can contain internal to the same MIME object - via CID, or external with a URL object sets. That is in the introduction of 5545. A fact is that, some (many?) user interfaces do not take advantage of that may make it appear that a new object identifier is needed. From 5545: "...Note: While there is no restriction imposed on the URI schemes allowed for this parameter, Content Identifier (CID) [RFC2392], HTTP [RFC2616], and HTTPS [RFC2818] are the URI schemes most commonly used by current implementations. ..." > And I don't think it's quite the same amount of work. Same is relative to where the code is at, and the final version. > New iCalendar properties need to be generally useful in calendars and scheduling. Very specific properties used to address a need such as this are probably better contained in data with their own schema. There is no restriction on the type of attachments that can added. The proposal to replace Mime-Type identifiers inside of a MIME object, would be creating an entire new set of identifiers. Something that would be in parallel and out of step with how the IETF has decided to define object types. The 'how to define any object in the world' debate has no solution. So the IETF decided on Mime-Type and a process to register new ones. And a process to use proprietary types of data. These defied mime types are known to many operating systems already. The IETF has a process in place to define new object types. With many applications, I can copy/paste an attached object and the mime headers tell the drop point what the data is. It would be tossing all object identifiers new object identifiers. > There's a whole other discussion as to whether or not these properties are generally useful - probably not as something only for maintenance. Workflow is a great topic for iCalendar. Which I think is at the heart of their proposal. Perhaps their draft could be released (when ready) as an informational RFC, simply to document how it is done by several vendors. Then a parallel discussion about workflow would not delay them. > As an aside having reread the draft - email is not the only possible transport mechanism. CalDAV or some other protocol might be appropriate. Any draft should probably allow for different ways of transporting the messages. iCalendar is a MIME content type, that does not mean it must be transported via iMIP. And 5545 makes that point in the introduction section. And one reason that 2445 chose it as a MIME content type, was for attachments. I can not think of any transport that can not transport a multipart MIME object. I do not see any plus to internalizing any random kind of attachment, inventing a new object identifier, simply to make it a property value. If a need exists, use ATTACH with fmttypeparam set to a mime-type that has been defined or can be registered, and base64 encode it. Or for proprietary use, make up an X-PROP and include any proprietary value in any format needed. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Wed Jul 10 15:05:45 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 43DDF120359 for ; Wed, 10 Jul 2019 15:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=twitch.tv 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 9o916viREQPr for ; Wed, 10 Jul 2019 15:05:36 -0700 (PDT) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (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 6F89C12025D for ; Wed, 10 Jul 2019 15:05:35 -0700 (PDT) Received: by mail-wm1-x336.google.com with SMTP id l2so3758439wmg.0 for ; Wed, 10 Jul 2019 15:05:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitch.tv; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9a2obn/1+YNSkANU9BQSkKx+ZGRXW93dM9RF4VH73Kc=; b=gMMnS5tQlSw6xWx01Upf6TFvzjc/EhUDJkWPO3gaoUYs7rF+QF+k4BNHV5kY//lu1E 77ilnalYepJMckHd5MOFeP/u+BBNZCAB7xM/4R7lXMuzJRicXN15oGdCkdWL3u7+JG41 ZVfQedBaK7x9vo8tod9d5VG6pMTaS4+bfWOpw= 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=9a2obn/1+YNSkANU9BQSkKx+ZGRXW93dM9RF4VH73Kc=; b=m+fmyGud4xjzQ4g1VpT6Vt0dCAQgenQYbVVxQ42zlt8A/+wntT8IBu8Br1ile925Yz gg47/ktwLZZ8ThTGfvCgQkXJiZwj6iuxgnp8lPBjQXSGfJDPQrYAH0XA5se435oV+NzR 6LADmrULviafVpfzowSrdlJgkkU00zes28TWVNoLW0P0QFQYbJZzYRwiDlUKbFcTJLgn 9wgb9YQ78FKT9GmlW4mHxbBgzWL60Qiq7XTWUoGK8be9/Ufn1wt3WmyV0adzZyG/jObC 57KuP6uM4hMf83Oyopgse7mESOdmbAzWX4ZXkUZsp8p9hW+MjMJJ0wrmDIvFpxiZNnMM xyfA== X-Gm-Message-State: APjAAAWWwYTEAAuuTcB99dFWYssYX48MqD+EOY6QVNfJJC6gxvRLD4Wn 0u25g9gKNgRi5OfNy4oHsISCpd2r+m5Vl8FPGRcr X-Google-Smtp-Source: APXvYqxmSKTlvRTXlDTgsFNbj8HvF1F2kc68SunELv7Jtl2dJjlFgsBzg3JXw9KX9I2AtU6kJSuHwGKJBgZAWmJDTkI= X-Received: by 2002:a7b:c751:: with SMTP id w17mr48553wmk.127.1562796333477; Wed, 10 Jul 2019 15:05:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Gunter Date: Wed, 10 Jul 2019 16:04:57 -0600 Message-ID: To: Doug Royer Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary="000000000000504ba9058d5ae029" Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 10 Jul 2019 22:05:44 -0000 --000000000000504ba9058d5ae029 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, Again, the feedback is appreciated. The new Event Publishing Extensions draft does indeed have some useful properties that would be serve the purpose of providing parseable maintenance information. The suggestions provided 2 options, and I have questions about both. *STRUCTURED-DATA* 1. Since the fields in the proposed draft are not part of any standard schema, one would need to be defined. I=E2=80=99m assuming another version= of the draft would define the schema for maintenances within the property? *New MAINTNOTE Component* 1. My initial thought is this seems like a simpler solution. Is it being suggested this could possibly be included into the Event Publishing Extensions draft, or something separate? 2. To ensure I=E2=80=99m understanding this correctly, would the component = be structured something similar to this? BEGIN:MAINTNOTE MAINTNOTE-PROVIDER:example.com MAINTNOTE-ACCOUNT: Twitch MAINTNOTE-MAINTENANCE-ID: WorkOrder-31415 MAINTNOTE-OBJECT-ID: ABC123 MAINTNOTE-IMPACT: OUTAGE MAINTNOTE-STATUS: CONFIRMED END:MAINTNOTE Ryan Gunter | *Twitch* | Network Engineering | +1.415.568.7607 On Mon, Jul 8, 2019 at 9:57 PM Doug Royer wrote: > On 7/3/19 3:12 PM, Ken Murchison wrote: > > Hi Ryan, > > > > My initial reaction to reading this is that all of the new maintenance > properties should be grouped under a single entity such as a > STRUCTURED-DATA < > https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-13#sect= ion-7.6> > property or a new MAINTNOTE sub-component, similar to PARTICIPANT. > > New MAINTNOTE component - great idea. Then existing implementation should > still be able to parse and preserve the content without knowing or acting > on the content. > > -- > > Doug Royer - (http://DougRoyer.US) > Douglas.Royer@gmail.com > 714-989-6135 > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --000000000000504ba9058d5ae029 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

Again, the feedback is appreciated.=

The new Event Publishing Extensions draft does indeed have some use= ful properties that would be serve the purpose of providing parseable maint= enance information. The suggestions provided 2 options, and I have questio= ns about both.

STRUCTURED-DATA
1.=C2=A0 Since the fields = in the proposed draft are not part of any standard schema, one would need t= o be defined.=C2=A0 I=E2=80=99m assuming another version of the draft would= define the schema for maintenances within the property?

New MAIN= TNOTE Component
1. My initial thought is this seems like a simpler = solution.=C2=A0 Is it being suggested this could possibly be included into = the Event Publishing Extensions draft, or something separate?
2. To ens= ure I=E2=80=99m understanding this correctly, would the component be struct= ured something similar to this?

BEGIN:MAINTNOTE
MAINTNOTE-PROVIDER:example.com
MAINTNOTE-ACCOUNT: Twitch=
MAINTNOTE-MAINTENANCE= -ID: WorkOrder-31415
MAINTNOTE-OBJECT-ID: ABC123
MAINTNOTE-IMPACT: OUTAGE
MAINTNOTE-STATUS: CONFIRMED
END:MAINTNOTE

=C2=A0 =C2=A0 =C2=A0 =C2=A0
Ryan Gunter=C2=A0=C2=A0|=C2=A0= =C2=A0=C2=A0Twitch=C2=A0=C2=A0= =C2=A0|=C2=A0=C2=A0 Network Engineering=C2=A0 =C2=A0= | =C2=A0=C2=A0+1.415.568.760= 7

On Mon, J= ul 8, 2019 at 9:57 PM Doug Royer <douglasroyer@gmail.com> wrote:
On 7/3/19 3:12 PM, Ken Murchiso= n wrote:
> Hi Ryan,
>
> My initial reaction to reading this is that all of the new maintenance= properties should be grouped under a single entity such as a STRUCTURED-DA= TA <https://tools= .ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-7.6>= property or a new MAINTNOTE sub-component, similar to PARTICIPANT.

New MAINTNOTE component - great idea. Then existing implementation should s= till be able to parse and preserve the content without knowing or acting on= the content.

--

Doug Royer - (http://DougRoyer.US)
Douglas.Royer@= gmail.com
714-989-6135

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--000000000000504ba9058d5ae029-- From nobody Wed Jul 10 17:32:49 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 9512D120046 for ; Wed, 10 Jul 2019 17:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, 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=fastmail.com header.b=Q4i1ga2w; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=tqe8zDXz 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 BZTn9DqwrZgr for ; Wed, 10 Jul 2019 17:32:44 -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 731D4120019 for ; Wed, 10 Jul 2019 17:32:44 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 743593F7 for ; Wed, 10 Jul 2019 20:32:43 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 10 Jul 2019 20:32:43 -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=fm3; bh=LJVzyb1ihncSUDA9E7lAe8EPiaS 9obytKvpMu0ujWaw=; b=Q4i1ga2wQhamb+KE+x1vZdy+v3epXr7gr9Yks3eG9f+ fi1QLPUDZisCA5DsCGkPirp0K8wuVHlKaZgAuV942ipbuVODh0PwxOAcmUivoh70 RZl8AO/+nJDruwWb3aFkEtKEvqB4zt/TEAodKzEXKTca3bpO8GE2HNsM58K2D7r8 qJx8xQ2nKNA9n0OhPWpdnth6FCuDPz2ms0LZ9rFRR7UXSg1QEYpKAn/jhdoIopnG 1SKfJcSYcGeFuCWFsQp2uKbR3+XbfMb5hER5im4z2ZT52ukxCRy9d1YLz7QEnDuX aiDNthQtTx/1et3HRXZdhZD7jZdbQ3FmU1jJj8lolWQ== 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=fm3; bh=LJVzyb 1ihncSUDA9E7lAe8EPiaS9obytKvpMu0ujWaw=; b=tqe8zDXzTaUEtsKLnBVS4I JIdI05oJfIdFs0xWkSZ6k2A5jtdVxgcs9hGS/jk33dp2Pdc8uhNs2xpBVnenAXOx g6P54x85WMf6Q+ciQxgrSFFAu8aAaJCreuWKR7uEJ7pjk58sW+jhoS62PaO2yG4n 1jiGShILRp4VGI4hFqgfqJByJy05Qo+i2USi52r4yr8dMUh7MAw979IT1LbZzx7h Ga9b9BlfMSc89chOmuyBbRp9b35oGAXp1APPo+54nlYpqY4QZUF3JFs9mC66lr4E pcgF1ku6GbkuHctjgKmhAbENTrO2NWqeabloJLehqkyRUEKAP8ltRtfR1aokGJVA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeejgdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhohfkffgfgggjtgesmhdtre ertdefjeenucfhrhhomhepmfgvnhcuofhurhgthhhishhonhcuoehmuhhrtghhsehfrghs thhmrghilhdrtghomheqnecuffhomhgrihhnpehivghtfhdrohhrghdpvgigrghmphhlvg drtghomhdpthifihhttghhrdhtvhdpughouhhgrhhohigvrhdruhhsnecukfhppeejgedr jeejrdekhedrvdehtdenucfrrghrrghmpehmrghilhhfrhhomhepmhhurhgthhesfhgrsh htmhgrihhlrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd 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 767ED380074 for ; Wed, 10 Jul 2019 20:32:42 -0400 (EDT) To: calsify@ietf.org References: From: Ken Murchison Organization: FastMail US LLC Message-ID: Date: Wed, 10 Jul 2019 20:32:42 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------E2971FE357F48F5A4D8F639C" Content-Language: en-US Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 11 Jul 2019 00:32:47 -0000 This is a multi-part message in MIME format. --------------E2971FE357F48F5A4D8F639C Content-Type: multipart/alternative; boundary="------------204B41C4A144391007E70F4F" --------------204B41C4A144391007E70F4F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hy Ryan, If you go the MAINTNOTE component route, you can drop the MAINTNOTE- prefix on all of the properties. On 7/10/19 6:04 PM, Ryan Gunter wrote: > Hello everyone, > > Again, the feedback is appreciated. > > The new Event Publishing Extensions draft does indeed have some useful > properties that would be serve the purpose of providing parseable > maintenance information. The suggestions provided 2 options, and I > have questions about both. > > *STRUCTURED-DATA* > 1.  Since the fields in the proposed draft are not part of any > standard schema, one would need to be defined.  I’m assuming another > version of the draft would define the schema for maintenances within > the property? > > *New MAINTNOTE Component* > 1. My initial thought is this seems like a simpler solution.  Is it > being suggested this could possibly be included into the Event > Publishing Extensions draft, or something separate? > 2. To ensure I’m understanding this correctly, would the component be > structured something similar to this? > > BEGIN:MAINTNOTE > MAINTNOTE-PROVIDER:example.com > MAINTNOTE-ACCOUNT: Twitch > MAINTNOTE-MAINTENANCE-ID: WorkOrder-31415 > MAINTNOTE-OBJECT-ID: ABC123 > MAINTNOTE-IMPACT: OUTAGE > MAINTNOTE-STATUS: CONFIRMED > END:MAINTNOTE > > > Ryan Gunter | *Twitch* |   Network Engineering| > +1.415.568.7607 > > > On Mon, Jul 8, 2019 at 9:57 PM Doug Royer > wrote: > > On 7/3/19 3:12 PM, Ken Murchison wrote: > > Hi Ryan, > > > > My initial reaction to reading this is that all of the new > maintenance properties should be grouped under a single entity > such as a STRUCTURED-DATA > > > property or a new MAINTNOTE sub-component, similar to PARTICIPANT. > > New MAINTNOTE component - great idea. Then existing implementation > should still be able to parse and preserve the content without > knowing or acting on the content. > > -- > > Doug Royer - (http://DougRoyer.US) > Douglas.Royer@gmail.com > 714-989-6135 > > _______________________________________________ > 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 --------------204B41C4A144391007E70F4F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hy Ryan,

If you go the MAINTNOTE component route, you can drop the MAINTNOTE- prefix on all of the properties.


On 7/10/19 6:04 PM, Ryan Gunter wrote:
Hello everyone,

Again, the feedback is appreciated.

The new Event Publishing Extensions draft does indeed have some useful properties that would be serve the purpose of providing parseable maintenance information. The suggestions provided 2 options, and I have questions about both.

STRUCTURED-DATA
1.  Since the fields in the proposed draft are not part of any standard schema, one would need to be defined.  I’m assuming another version of the draft would define the schema for maintenances within the property?

New MAINTNOTE Component
1. My initial thought is this seems like a simpler solution.  Is it being suggested this could possibly be included into the Event Publishing Extensions draft, or something separate?
2. To ensure I’m understanding this correctly, would the component be structured something similar to this?

BEGIN:MAINTNOTE
MAINTNOTE-PROVIDER:example.com
MAINTNOTE-ACCOUNT: Twitch
MAINTNOTE-MAINTENANCE-ID: WorkOrder-31415
MAINTNOTE-OBJECT-ID: ABC123
MAINTNOTE-IMPACT: OUTAGE
MAINTNOTE-STATUS: CONFIRMED
END:MAINTNOTE


       
Ryan Gunter  |   Twitch   |   Network Engineering   |   +1.415.568.7607


On Mon, Jul 8, 2019 at 9:57 PM Doug Royer <douglasroyer@gmail.com> wrote:
On 7/3/19 3:12 PM, Ken Murchison wrote:
> Hi Ryan,
>
> My initial reaction to reading this is that all of the new maintenance properties should be grouped under a single entity such as a STRUCTURED-DATA <https://tools..ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-7.6> property or a new MAINTNOTE sub-component, similar to PARTICIPANT.

New MAINTNOTE component - great idea. Then existing implementation should still be able to parse and preserve the content without knowing or acting on the content.

--

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

_______________________________________________
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
--------------204B41C4A144391007E70F4F-- --------------E2971FE357F48F5A4D8F639C Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------E2971FE357F48F5A4D8F639C-- From nobody Mon Jul 15 12:56: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 6582012016C for ; Mon, 15 Jul 2019 12:56:22 -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_HELO_NONE=0.001, SPF_PASS=-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 q2m_uucjeg_d for ; Mon, 15 Jul 2019 12:56:20 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 45AE91200F9 for ; Mon, 15 Jul 2019 12:56:20 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id h21so16946135qtn.13 for ; Mon, 15 Jul 2019 12:56:20 -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=f6VhJJfs5WrSeTQq0IwMeESVthr57FBS1HUrF4NdFSU=; b=bAd0d+dIrtJG4lharRt3cU0IebaV+nCRkqb9ToSai/PKv5aCgaXUqF3j2S9TV68z5g XXECGDwor7J3pM+aDVeRs3vitvJiaLcWFe7W9+Hb5vcjgF/8V8jeANo0u82w1dVn9TFb r9yX0iyDYH7je0Vj8Q9ar6VMbkePJ0/I2appQHG2VoeptgGK5I/KqxkP7r34mmqvNrWi iVFAI1gyHA0wvwQgDhw/OYrEEAfpjC57hjhPTqucu8RvPCeawHwIZaEB1oGC7Ku3O3jN +xJ3+m9qHj6JRgKde7vpMlDVGEHoUilNkuyeQfqSqkbuKiHwOCqTdzXqWnsq6A5nKLe4 yf4Q== 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=f6VhJJfs5WrSeTQq0IwMeESVthr57FBS1HUrF4NdFSU=; b=nkqBj74/1mQnH4QyR/0n0Jp0lCSdG2GI5h+oJC0yu7YZDxPDoXhhgnVRn2Fd7A8xT6 tLTOd3Cau1MDvtPtmsq8WbscY0ytRn4R0ictivjspUQ11B/jejTSvDlJx7bLtFWyzLj+ IjrnnJxfqApMbw5J5nRts/IVqP6dk5tCuzvQKexG1bSu8wVNfjyx+KYtlGLTnu2uiXkP 2yfGapOWKp1sjr2CG1atXAGL8yaLpH4FeeRc6EPwnjB5CgvenwoTV2q0A3IRQKnoNa4z d0AnXR/4aHWiQQyqeMz65f8xx9yDCokpOsW2Sov5IpDDfxRtiPqODL2/X7VxxXjb9ftN Wbtg== X-Gm-Message-State: APjAAAWa+FpVSXc+Rj5yCue6WeHE0FJUHLZJnjckRYiZaCXJCMHEIpaF 5/0kEYls+Twln3DfAMnew8XqeF5e X-Google-Smtp-Source: APXvYqziJxmN0bOtwBJDQss3e6IoK/eo7bIBxnApYqoEScpH2jB4Nf1Mty0AynNTeZ3QzAmSaYE8dw== X-Received: by 2002:a0c:9932:: with SMTP id h47mr20393954qvd.147.1563220579325; Mon, 15 Jul 2019 12:56:19 -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 o12sm7990568qkg.99.2019.07.15.12.56.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 12:56:18 -0700 (PDT) To: Tim Hare , calsify@ietf.org References: <00d001d53653$38fcba50$aaf62ef0$@comcast.net> From: Michael Douglass Message-ID: Date: Mon, 15 Jul 2019 15:56:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <00d001d53653$38fcba50$aaf62ef0$@comcast.net> Content-Type: multipart/alternative; boundary="------------926086475C84DEFBF7E06C4E" Content-Language: en-US Archived-At: Subject: Re: [calsify] question about STYLED-DESCRIPTION in the eventpub extensions document 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, 15 Jul 2019 19:56:23 -0000 This is a multi-part message in MIME format. --------------926086475C84DEFBF7E06C4E Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Tim On 7/9/19 08:38, Tim Hare wrote: > > Now that Ive skimmed through > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > I have a question about STYLED-DESCRIPTION, VALUE=TEXT. Should FMTTYPE > be required in that instance? If it is not required and/or not > specified, what default style SHOULD be applied to the text of the > STYLED-DESCRIPTION: ? Should it be text/plain making it > essentially DESCRIPTION: or should some other format like > text/markdown be specified as a default? > There is this text in the spec: Applications MAY attempt to guess the media type of the resource via inspection of its content if and only if the media type of the resource is not given by the "FMTTYPE" parameter. If the media type remains unknown, calendar applications SHOULD treat it as type "text/html" > > Tim Hare > Interested Bystander, Non-Inc. > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------926086475C84DEFBF7E06C4E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi Tim

On 7/9/19 08:38, Tim Hare wrote:

Now that Ive skimmed through https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ I have a question about STYLED-DESCRIPTION, VALUE=TEXT. Should FMTTYPE be required in that instance? If it is not required and/or not specified, what default style SHOULD be applied to the text of the STYLED-DESCRIPTION: ? Should it be text/plain making it essentially DESCRIPTION: or should some other format like text/markdown be specified as a default?

There is this text in the spec:

Applications MAY attempt to guess the media type of the
resource via inspection of its content if and only if the media
type of the resource is not given by the "FMTTYPE" parameter.  If
the media type remains unknown, calendar applications SHOULD treat
it as type "text/html"


Tim Hare
Interested Bystander, Non-Inc.


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------926086475C84DEFBF7E06C4E-- From nobody Tue Jul 16 09:17:59 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 519D812087C for ; Tue, 16 Jul 2019 09:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=twitch.tv 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 I7GXgV7Qtk8h for ; Tue, 16 Jul 2019 09:17:46 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 C192C12066C for ; Tue, 16 Jul 2019 09:17:45 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id f9so21584204wre.12 for ; Tue, 16 Jul 2019 09:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitch.tv; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IH90NA0Jsn1C3p/Ke8SyfotThsEnyq+QdLremDTW4NE=; b=rE5f6BjmLMQkxyCty857LTawSDrpSHS5CF40KEOBCE9n5g0U0OEwi2ET/+/Z1TigFW 6GTHPc52XPnR5YCFh5rmcAbwJTEiHPbrt6TS3dL8sbioloCybjFm0dWhqX3GoLZXyMyk 8R0+vaQRHUR/hb3P3fzMwPNXRN6UGM5f6UsLE= 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=IH90NA0Jsn1C3p/Ke8SyfotThsEnyq+QdLremDTW4NE=; b=UCQ041mwZolCmjtOfAQL6UKCArdQKqqAb0MyR01Ow/9BfjLirC+yxcQNz52GXp/PO2 rrchWmBlRZpl+SzGCHjOhjdRgdp7ClARCfRlNMMKAjKRNGZrVTOU6H/6OqaQV3cNvGec eG3kI+WBWlvlvYKCiMhUljkKTX8Q1Eww+S7YqEi6KGjdTk26vI71V6SL6gvy1ZBAa3/u nbvOPPrNn4EkGIkLLkFe9nUBbMAoakDHR0bZ87q1bVU9Tgsbyj/LJAr8EUqFRbRNIW/X Kdg4E7tUlNgWcF/0lL/lKsBBNOlq4sKFDPK8HTqEwF7vUwIwNiOMdupYs1XVYekrSpqR tsow== X-Gm-Message-State: APjAAAU2s9514Y87O2gx38EZuD6pnvq5/Wjs150rQuaYAM/dyeU6lB/B wMnLYe6Hr4SWBEY7QJZ+KCLzMWhhyTdofpxj3TXj X-Google-Smtp-Source: APXvYqzxp+sWoJwtYTt8N8s1+iZKU65KrsL5+9D8Idfovc6P9dUQIVtHXfdohQgj7fzMpF0S3yDYFA3GQ53TqB1AvVg= X-Received: by 2002:adf:dfc4:: with SMTP id q4mr36181211wrn.54.1563293864179; Tue, 16 Jul 2019 09:17:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Gunter Date: Tue, 16 Jul 2019 10:17:08 -0600 Message-ID: To: Ken Murchison Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary="000000000000745293058dceb79b" Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 16 Jul 2019 16:17:51 -0000 --000000000000745293058dceb79b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ken / All, Thank you very much for the help. This is my first IETF process so I'm still learning. Our team has been discussing the options, and the STRUCTURED-DATA field might be better fit for our network maintenance use case. Has there been any discussion about coding support / libraries / tooling for this property? Also, the draft indicates using standardized schemas from schema.org or hosting your own is acceptable, however we were curious if there were any thoughts on storing schemas specifically for STRUCTURED-DATA= ? Since the Calendaring Extensions document is still in a draft state, is there any current rough time frame for it being ratified? It looks to be in the final stages after looking at the comments from v12. Ryan Gunter | *Twitch* | Network Engineering | +1.415.568.7607 On Wed, Jul 10, 2019 at 6:32 PM Ken Murchison wrote: > Hy Ryan, > > If you go the MAINTNOTE component route, you can drop the MAINTNOTE- > prefix on all of the properties. > > > On 7/10/19 6:04 PM, Ryan Gunter wrote: > > Hello everyone, > > Again, the feedback is appreciated. > > The new Event Publishing Extensions draft does indeed have some useful > properties that would be serve the purpose of providing parseable > maintenance information. The suggestions provided 2 options, and I have > questions about both. > > *STRUCTURED-DATA* > 1. Since the fields in the proposed draft are not part of any standard > schema, one would need to be defined. I=E2=80=99m assuming another versi= on of the > draft would define the schema for maintenances within the property? > > *New MAINTNOTE Component* > 1. My initial thought is this seems like a simpler solution. Is it being > suggested this could possibly be included into the Event Publishing > Extensions draft, or something separate? > 2. To ensure I=E2=80=99m understanding this correctly, would the componen= t be > structured something similar to this? > > BEGIN:MAINTNOTE > MAINTNOTE-PROVIDER:example.com > MAINTNOTE-ACCOUNT: Twitch > MAINTNOTE-MAINTENANCE-ID: WorkOrder-31415 > MAINTNOTE-OBJECT-ID: ABC123 > MAINTNOTE-IMPACT: OUTAGE > MAINTNOTE-STATUS: CONFIRMED > END:MAINTNOTE > > > > Ryan Gunter | *Twitch* | Network > Engineering | +1.415.568.7607 > > > On Mon, Jul 8, 2019 at 9:57 PM Doug Royer wrote: > >> On 7/3/19 3:12 PM, Ken Murchison wrote: >> > Hi Ryan, >> > >> > My initial reaction to reading this is that all of the new maintenance >> properties should be grouped under a single entity such as a >> STRUCTURED-DATA < >> https://tools..ietf.org/html/draft-ietf-calext-eventpub-extensions-13#se= ction-7.6 >> > >> property or a new MAINTNOTE sub-component, similar to PARTICIPANT. >> >> New MAINTNOTE component - great idea. Then existing implementation shoul= d >> still be able to parse and preserve the content without knowing or actin= g >> on the content. >> >> -- >> >> Doug Royer - (http://DougRoyer.US) >> Douglas.Royer@gmail.com >> 714-989-6135 >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> > > _______________________________________________ > 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 > --000000000000745293058dceb79b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ken / All,

Thank you ver= y much for the help.=C2=A0 This is my first IETF process so I'm still l= earning.

Our team has been discussing the options,= and the STRUCTURED-DATA field might be better fit for our network maintena= nce use case.=C2=A0 Has there been any discussion about coding support / li= braries / tooling for this property? Also, the draft indicates using standa= rdized schemas from schema.= org or hosting your own is acceptable, however we were curious if there= were any thoughts on storing schemas specifically for STRUCTURED-DATA?
=

Since the Calendaring Extensions document is stil= l in a draft state, is there any current rough time frame for it being rati= fied? It looks to be in the final stages after looking at the comments from= v12.


Ryan Gunter=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0<= /font>Twitc= h=C2=A0=C2=A0=C2=A0|=C2= =A0=C2=A0 Network Engineering=C2=A0 =C2=A0| =C2=A0=C2=A0+1.415.568.7607

On Wed, = Jul 10, 2019 at 6:32 PM Ken Murchison <murch@fastmail.com> wrote:
=20 =20 =20

Hy Ryan,

If you go the MAINTNOTE component route, you can drop the MAINTNOTE- prefix on all of the properties.


On 7/10= /19 6:04 PM, Ryan Gunter wrote:
=20
Hello everyone,

Again, the feedback is appreciated.

The new Event Publishing Extensions draft does indeed have some useful properties that would be serve the purpose of providing parseable maintenance information. The suggestions provided 2 options, and I have questions about both.

STRUCTURED-DATA
1.=C2=A0 Since the fields in the proposed draft are not part of any standard schema, one would need to be defined.=C2=A0 I=E2=80=99m as= suming another version of the draft would define the schema for maintenances within the property?

New MAINTNOTE Component
1. My initial thought is this seems like a simpler solution.=C2=A0 = Is it being suggested this could possibly be included into the Event Publishing Extensions draft, or something separate?
2. To ensure I=E2=80=99m understanding this correctly, would the component be structured something similar to this?

BEGIN:MAINTNOTE
MAINTNOTE-PROVI= DER:example.com=
MAINTNOTE-ACCOU= NT: Twitch
MAINTNOTE-MAINT= ENANCE-ID: WorkOrder-31415
MAINTNOTE-OBJEC= T-ID: ABC123
MAINTNOTE-IMPAC= T: OUTAGE
MAINTNOTE-STATU= S: CONFIRMED
END:MAINTNOTE


=C2=A0 =C2=A0 =C2=A0 =C2=A0
Ry= an Gunter=C2=A0=C2=A0|=C2=A0= =C2= =A0=C2=A0Twitch<= /font>=C2=A0=C2=A0=C2=A0|=C2=A0<= /font>=C2=A0 Network Engineering=C2=A0 =C2=A0| =C2=A0=C2=A0+1.415.568.7607


On Mon, Jul 8, 2019 at 9:57 P= M Doug Royer <douglasroyer@gmail.com> wrote:
On 7/3/19 3:12 PM, Ken Murchison wrote:
> Hi Ryan,
>
> My initial reaction to reading this is that all of the new maintenance properties should be grouped under a single entity such as a STRUCTURED-DATA <https://tools..ietf.org/html/draft-ietf-calext-e= ventpub-extensions-13#section-7.6> property or a new MAINTNOTE sub-component, similar to PARTICIPANT.

New MAINTNOTE component - great idea. Then existing implementation should still be able to parse and preserve the content without knowing or acting on the content.

--

Doug Royer - (http://DougRoyer.US)
Doug= las.Royer@gmail.com
714-989-6135

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

_______=
________________________________________
calsify mailing list
calsify@ietf.org
https://w=
ww.ietf.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
--000000000000745293058dceb79b-- From nobody Tue Jul 16 09:45:05 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 DF928120911 for ; Tue, 16 Jul 2019 09:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 bPrqPUU2Ac9o for ; Tue, 16 Jul 2019 09:44:53 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 C7FF7120927 for ; Tue, 16 Jul 2019 09:44:52 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id d79so15076596qke.11 for ; Tue, 16 Jul 2019 09:44:52 -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=A9lSEC6ngnoDPO7zeu2juwlHLsiZISY8fxlcVDj9yRs=; b=Un4ObLgVoi+phO/U8EoY2FLzskcCOz1XTZDLRv9P048ctAh3EODX8l5/yl44vYxQNm zkNQf8uRF8VxC6rl8+mGJtBab/1RnharBAzCqQwAeA4EwUOnUA5yjDMLiN9BvkPUxg+1 /z1QwGTQmM2IbpO335sXAxRHYRjBbs2rZtLw5rYX/6jc0hHnJ8ASZtF2ezQKADZvoLn8 gzxnc0tC/cMX05/lR5c7iq4oJ+okggfjYh+qxyyjBYuYPAg2qjMsqGv9s6U9okBO77pV PpqyqY/RBrQ6aTOae4Jk6M5PquycecQr2avvVV4Ek4CluKMahenOt+Vb5zm1VfMOintt 2TjA== 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=A9lSEC6ngnoDPO7zeu2juwlHLsiZISY8fxlcVDj9yRs=; b=gc+UyQIn4k99QAuqdGTyCmlFXDFb6fvgwujm/jG2EQras+TqgmGLjWncEbT5gXNUBa kc+MDhFg1IoLquxrLjAzwJJc57asS9ZN8NcIssdk/yxtoO0y152wZmxLPdqiayHQ7gvm hFI8Y9beJTN7bE8BApGcQgygaeoXKDk2uFW+u1/5WFQ/SmKfc1L/w4Yb8i6nfMK1dztj 8BACpxF3UGC+q2rsPn25MSJg+7uL8YrF3QiJF3FLvRl4b48v9iniBquG3lfY1IX0RE0y T+TqGyLiDXnV6uLoUB3jZlfSzR1OsbxXG80gFA3VWdqEoaBmA2qP6NHQTxcDrZN3ia2A h/kA== X-Gm-Message-State: APjAAAVPtlQ4G+l3qQbMUBEAQFWGZFwFKLsovRkaXLRLPOAlDV8F33Xs WgQdy3tD4l+Qtb7GUYceZb+u1a9u X-Google-Smtp-Source: APXvYqysoEyxti9D88tU6vjriBWmCGZM2wUZHWc7hbLbR+5Oa4SZvPRYw+o2b3v3is9c9irD78D29g== X-Received: by 2002:a05:620a:1097:: with SMTP id g23mr5428586qkk.185.1563295491646; Tue, 16 Jul 2019 09:44:51 -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 t26sm9102453qtc.95.2019.07.16.09.44.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2019 09:44:51 -0700 (PDT) To: Ryan Gunter , Ken Murchison Cc: calsify@ietf.org References: From: Michael Douglass Message-ID: <9f5eb363-fe55-e72a-8d86-0ca29a508f6a@gmail.com> Date: Tue, 16 Jul 2019 12:44:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------40980163DE28D6BFD7092A9C" Content-Language: en-US Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 16 Jul 2019 16:45:00 -0000 This is a multi-part message in MIME format. --------------40980163DE28D6BFD7092A9C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/16/19 12:17, Ryan Gunter wrote: > Ken / All, > > Thank you very much for the help.  This is my first IETF process so > I'm still learning. > > Our team has been discussing the options, and the STRUCTURED-DATA > field might be better fit for our network maintenance use case.  Has > there been any discussion about coding support / libraries / tooling > for this property? Also, the draft indicates using standardized > schemas from schema.org or hosting your own is > acceptable, however we were curious if there were any thoughts on > storing schemas specifically for STRUCTURED-DATA? I hadn't thought so - I'd assumed that the process at schema.org might be appropriate. I don't suppose there's any problems with defining such schemas within the ietf but it migth be worth trying the schema.org approach first? > > Since the Calendaring Extensions document is still in a draft state, > is there any current rough time frame for it being ratified? It looks > to be in the final stages after looking at the comments from v12. I'm hoping to get a new draft out when things get opened up again (20th). This will resolve issues over the changes to the SOURCE property (by dropping it in favor of STRUCTURED-DATA). > > > Ryan Gunter | *Twitch* |   Network Engineering| > +1.415.568.7607 > > > On Wed, Jul 10, 2019 at 6:32 PM Ken Murchison > wrote: > > Hy Ryan, > > If you go the MAINTNOTE component route, you can drop the > MAINTNOTE- prefix on all of the properties. > > > On 7/10/19 6:04 PM, Ryan Gunter wrote: >> Hello everyone, >> >> Again, the feedback is appreciated. >> >> The new Event Publishing Extensions draft does indeed have some >> useful properties that would be serve the purpose of providing >> parseable maintenance information. The suggestions provided 2 >> options, and I have questions about both. >> >> *STRUCTURED-DATA* >> 1.  Since the fields in the proposed draft are not part of any >> standard schema, one would need to be defined. I’m assuming >> another version of the draft would define the schema for >> maintenances within the property? >> >> *New MAINTNOTE Component* >> 1. My initial thought is this seems like a simpler solution.  Is >> it being suggested this could possibly be included into the Event >> Publishing Extensions draft, or something separate? >> 2. To ensure I’m understanding this correctly, would the >> component be structured something similar to this? >> >> BEGIN:MAINTNOTE >> MAINTNOTE-PROVIDER:example.com >> MAINTNOTE-ACCOUNT: Twitch >> MAINTNOTE-MAINTENANCE-ID: WorkOrder-31415 >> MAINTNOTE-OBJECT-ID: ABC123 >> MAINTNOTE-IMPACT: OUTAGE >> MAINTNOTE-STATUS: CONFIRMED >> END:MAINTNOTE >> >> >> Ryan Gunter | *Twitch* |   Network >> Engineering| +1.415.568.7607 >> >> >> On Mon, Jul 8, 2019 at 9:57 PM Doug Royer > > wrote: >> >> On 7/3/19 3:12 PM, Ken Murchison wrote: >> > Hi Ryan, >> > >> > My initial reaction to reading this is that all of the new >> maintenance properties should be grouped under a single >> entity such as a STRUCTURED-DATA >> > > >> property or a new MAINTNOTE sub-component, similar to >> PARTICIPANT. >> >> New MAINTNOTE component - great idea. Then existing >> implementation should still be able to parse and preserve the >> content without knowing or acting on the content. >> >> -- >> >> Doug Royer - (http://DougRoyer.US) >> Douglas.Royer@gmail.com >> 714-989-6135 >> >> _______________________________________________ >> 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 --------------40980163DE28D6BFD7092A9C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 7/16/19 12:17, Ryan Gunter wrote:
Ken / All,

Thank you very much for the help.  This is my first IETF process so I'm still learning.

Our team has been discussing the options, and the STRUCTURED-DATA field might be better fit for our network maintenance use case.  Has there been any discussion about coding support / libraries / tooling for this property? Also, the draft indicates using standardized schemas from schema.org or hosting your own is acceptable, however we were curious if there were any thoughts on storing schemas specifically for STRUCTURED-DATA?
I hadn't thought so - I'd assumed that the process at schema.org might be appropriate. I don't suppose there's any problems with defining such schemas within the ietf but it migth be worth trying the schema.org approach first?

Since the Calendaring Extensions document is still in a draft state, is there any current rough time frame for it being ratified? It looks to be in the final stages after looking at the comments from v12.
I'm hoping to get a new draft out when things get opened up again (20th). This will resolve issues over the changes to the SOURCE property (by dropping it in favor of STRUCTURED-DATA).


Ryan Gunter  |   Twitch   |   Network Engineering   |   +1.415.568.7607


On Wed, Jul 10, 2019 at 6:32 PM Ken Murchison <murch@fastmail.com> wrote:

Hy Ryan,

If you go the MAINTNOTE component route, you can drop the MAINTNOTE- prefix on all of the properties.


On 7/10/19 6:04 PM, Ryan Gunter wrote:
Hello everyone,

Again, the feedback is appreciated.

The new Event Publishing Extensions draft does indeed have some useful properties that would be serve the purpose of providing parseable maintenance information. The suggestions provided 2 options, and I have questions about both.

STRUCTURED-DATA
1.  Since the fields in the proposed draft are not part of any standard schema, one would need to be defined.  I’m assuming another version of the draft would define the schema for maintenances within the property?

New MAINTNOTE Component
1. My initial thought is this seems like a simpler solution.  Is it being suggested this could possibly be included into the Event Publishing Extensions draft, or something separate?
2. To ensure I’m understanding this correctly, would the component be structured something similar to this?

BEGIN:MAINTNOTE
MAINTNOTE-PROVIDER:example.com
MAINTNOTE-ACCOUNT: Twitch
MAINTNOTE-MAINTENANCE-ID: WorkOrder-31415
MAINTNOTE-OBJECT-ID: ABC123
MAINTNOTE-IMPACT: OUTAGE
MAINTNOTE-STATUS: CONFIRMED
END:MAINTNOTE


       
Ryan Gunter  |   Twitch   |   Network Engineering   |   +1.415.568.7607


On Mon, Jul 8, 2019 at 9:57 PM Doug Royer <douglasroyer@gmail.com> wrote:
On 7/3/19 3:12 PM, Ken Murchison wrote:
> Hi Ryan,
>
> My initial reaction to reading this is that all of the new maintenance properties should be grouped under a single entity such as a STRUCTURED-DATA <https://tools..ietf.org/html/draft-ietf-calext-eventpub-extensions-13#section-7.6> property or a new MAINTNOTE sub-component, similar to PARTICIPANT.

New MAINTNOTE component - great idea. Then existing implementation should still be able to parse and preserve the content without knowing or acting on the content.

--

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

_______________________________________________
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
--------------40980163DE28D6BFD7092A9C-- From nobody Tue Jul 16 11:46:25 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 6325E120D62 for ; Tue, 16 Jul 2019 11:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 SDuDp1AJ1vqM for ; Tue, 16 Jul 2019 11:46:22 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 27D25120D4C for ; Tue, 16 Jul 2019 11:46:22 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id s7so41537027iob.11 for ; Tue, 16 Jul 2019 11:46:22 -0700 (PDT) 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:content-transfer-encoding; bh=7SgzBbR6UdQn3PNGq95ixXmwwgw5Ru/rIAL60EwnPSM=; b=m4VVy5muuT2FAg69INDEUMaxyLpp0JU1A1HQtXWDKYrhK7PaVDUk1Meo9DoZ4gRUpN dRh9U8ZhjzwG4GI+myrXb/30FBMRIEQtoAkyLjYBOlitAWks0JfwhKpYC9cJHzCO1Y8R yzhN8wjkufOjcn1UfNFoy3A6A20jHvSJv9XpGEt8gEuBvd/boxZ3mM9Ejtxyk0Qy0ooM G4cYbSN8iXaTEJ1dOh/ChgwfDFNAwVvRXM8YzDpVFa/SHyJ1xh5D9GYbi7fmZlV/cLiF lJOBLu+XbINGVfR3z9bmuDxK6UE6NJZur1RZfOX4QNia9UZjwSfQVdfXACaR21I+8kuM PzwA== 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:content-transfer-encoding; bh=7SgzBbR6UdQn3PNGq95ixXmwwgw5Ru/rIAL60EwnPSM=; b=uLTDRGfIFt8bEYYkwNXQT7f/tAmkwCOFQMm0AUeR4zQKLwQClnaJT+GrIHKDp/QaWA iT7NABihb+Pwnm9arJzWqyHm9HcH/mkScDKGEcsXKeVroUfV8Tu1fPzP7ozsAN1mNiNX H33YtT6Yf3b3E2AMugOq2QNXE07IUVavmWM+ip6a0jbhfWHWY9u6G84/41ZW98h5bdG9 ZscPBjffEFYLTtzvkhquuf17pm8/XRBVEbpqaF8Mm6so8EOUAWaoG63afWPlgiI9qhl8 fHH3XiI1wiOJrrjlYpk46YbbPkmdOFZ7NstulHBzB2JgYUXI8k3TTi9bIWkgqn9GKUnP e0qg== X-Gm-Message-State: APjAAAVYYs1fo96B3uCvO/RZfHcJYGxZtII7uwelZzTjcEZQXcqMgkvH kR+kVJoTaa1Fy//hAi+algZ9eCvECZsk X-Google-Smtp-Source: APXvYqwNa6EW9ptp22dbaesyktBnNb67o5ypm/RdqSPcOQjTPpUIsRZmr7o5/QgNMvsspgB0orjJPQ== X-Received: by 2002:a05:6602:2248:: with SMTP id o8mr31389419ioo.90.1563302781165; Tue, 16 Jul 2019 11:46:21 -0700 (PDT) Received: from [192.168.1.7] ([174.27.175.146]) by smtp.googlemail.com with ESMTPSA id w23sm20363171ioa.51.2019.07.16.11.46.19 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2019 11:46:20 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: Organization: http://SoftwareAndServices.NET Message-ID: <12d2d82e-121f-3583-592b-fcbd17f2b0d1@gmail.com> Date: Tue, 16 Jul 2019 12:46:19 -0600 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 16 Jul 2019 18:46:23 -0000 On 7/16/19 10:17 AM, Ryan Gunter [Masked] wrote: > Preview: Ken / All, Thank you very much for the help. This is my first --> SPAM? CLICK to BLOCK > > This email is Masked using Blur - it was sent from ietf.org to c52sjc4j7tsm@opayq.com (your reply stays Masked). To protect your privacy , do not forward this message, or add new recipients like CCs or BCCs. > > Thanks for being a Blur customer! If you haven't yet, [ Try DeleteMe at a discount. ] > > Ken / All, > > Thank you very much for the help.  This is my first IETF process so I'm still learning. > > Our team has been discussing the options, and the STRUCTURED-DATA field might be better fit for our network maintenance use case.  Has there been any discussion about coding support / libraries / tooling for this property? Also, the draft indicates using standardized schemas from schema.org or hosting your own is acceptable, however we were curious if there were any thoughts on storing schemas specifically for STRUCTURED-DATA? Is this a workflow process that involves scheduling? Or are you looking for an XML/HTML (schema.org) web page solution? A massive percentage of the schema.org schemas are CSS or HTML content. From the NANOG mailing list, it looked as if you wanted to automatically track a log of calendaring events (past or future) and have a standard way to describe and parse the description to keep track of what was done or needs to be done. (looks like calendaring/scheduling to me) If your content is primarily for automated display (html or otherwise) of data, then maybe schema.org web content will be what you want. If your content is for processing and work flow (that may be displayed), then you may want an iCalendar (or other type) object. The two are not incompatible, as schema.org ties to MIME-types (attachments). - See the schema.org contentType as one example. Structured-Data has no benefit over ATTACH. I think people misunderstand the ATTACH property. The W3C (schema.org) and the IETF are in agreement on object identifiers. Schema.org allows for the definition of data sets, and they are tied to mime types when sent as separate, non-web-page objects. Don't over complicate your data set. Define it, then map it to agreed on names, value types, and when needed specific acceptable values. Then decide if its values are primarily web-page-content, or a stand alone transported objects. And if stand alone objects tied to calendar date/time, then keep with the same format and do not invent another one, it will just complicate parsers. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Tue Jul 16 15:45:00 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 646CC12011C for ; Tue, 16 Jul 2019 15:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 H_tcxc2H4cn1 for ; Tue, 16 Jul 2019 15:44:56 -0700 (PDT) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 6481112002F for ; Tue, 16 Jul 2019 15:44:56 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id z4so21384979qtc.3 for ; Tue, 16 Jul 2019 15:44:56 -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=W0gMsNzZIegokMn4UeOkg+4iEV60PcuifTqMpbNHJNU=; b=FdX73agRWtg74hSCrFa4wvNuV6Ph6mtlSh3RRv2k6Gl2J5lp/SfqZa5B5gftfskr4z HG71RpoE4MfTS+ZugQbCD2Fnr8V0z6IbT+2k+dMsazNzaUiNQkk9ar+znMjovZ2fBFcJ Yc3nNjKgbDB50E8gxSYRQOM43PmS1DHc1xcFpgYaj8N5gg78a993zk1ZY0FhCqTObWo2 XamYq430inllgjG7k6l0sI96gJO5B2HKIP8NJDvP54BXf7+7qx7nVrWFjZunCFePNWcT KE8D8slmy2KMkpfLgXM/cX2aMGeqdsQJKkowWkKVNoo7rVKnk50nS9LeD9JqwV1a9T6z r4ag== 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=W0gMsNzZIegokMn4UeOkg+4iEV60PcuifTqMpbNHJNU=; b=oawmM4KcxCNw/NhxfcNxmtDAKJYjzpeZoY8gBR2C+KNy301ZWqjyd3l74MoiSlsLe/ 5tttvLWs/Jhrikpn4KttzlkylgRVP0dmOgKQeotCe2N+Z3s5o4mfdwXUxzi5Yr6nX7HU +tL6QYfCqhWpotMh2kfA8oM8mILM1CK4BdGq3cj/q23asohTUkGhlJL0L55dzWkkOYi7 TwuZz1tb7Sw+0BNv1rauIOgsBTig37dgOXQHrzX2Yz+3c3t8yPYcy7exE4VNXZndagQk GkMvTCqtMDnmkpb/k9LrApkp+z2Am+80rbTqS3n0xiXGVzfoNP3edBDjQcTjt0VElAho EqEg== X-Gm-Message-State: APjAAAURO3yTqnb1VCu4lHcydj+/3D2b/XPgs0Z9+UjI1wj5XiBipl96 kql618dZ0m+PIujD/wjRZN6k8XUn X-Google-Smtp-Source: APXvYqz1iGwKTuBA7V6xEzOCOtfAF8sBnOXwvV2GnGR5ds/Csbamcndj4unJiXec6w2OCLVKBUDyvw== X-Received: by 2002:ac8:6702:: with SMTP id e2mr7959120qtp.317.1563317095295; Tue, 16 Jul 2019 15:44:55 -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 y14sm9973409qkb.109.2019.07.16.15.44.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2019 15:44:54 -0700 (PDT) To: Doug Royer , calsify@ietf.org References: <12d2d82e-121f-3583-592b-fcbd17f2b0d1@gmail.com> From: Michael Douglass Message-ID: <17ad7de3-5957-eb65-a052-d6f9f93f2b23@gmail.com> Date: Tue, 16 Jul 2019 18:44:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.1 MIME-Version: 1.0 In-Reply-To: <12d2d82e-121f-3583-592b-fcbd17f2b0d1@gmail.com> Content-Type: multipart/alternative; boundary="------------8162EE9EC37814EFBEBF2D9F" Content-Language: en-US Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 16 Jul 2019 22:44:59 -0000 This is a multi-part message in MIME format. --------------8162EE9EC37814EFBEBF2D9F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/16/19 14:46, Doug Royer wrote: > On 7/16/19 10:17 AM, Ryan Gunter [Masked] wrote: >> Preview: Ken / All, Thank you very much for the help. This is my >> first --> SPAM? CLICK to BLOCK >> >> >> This email is Masked using Blur - it was sent from ietf.org to >> c52sjc4j7tsm@opayq.com (your reply stays Masked). To protect your >> privacy , do not forward >> this message, or add new recipients like CCs or BCCs. >> >> Thanks for being a Blur customer! If you haven't yet, [ Try DeleteMe >> at a discount. >> >> ] >> >> Ken / All, >> >> Thank you very much for the help.  This is my first IETF process so >> I'm still learning. >> >> Our team has been discussing the options, and the STRUCTURED-DATA >> field might be better fit for our network maintenance use case.  Has >> there been any discussion about coding support / libraries / tooling >> for this property? Also, the draft indicates using standardized >> schemas from schema.org or hosting your own is >> acceptable, however we were curious if there were any thoughts on >> storing schemas specifically for STRUCTURED-DATA? > > Is this a workflow process that involves scheduling? Or are you > looking for an XML/HTML (schema.org) web page solution? A massive > percentage of the schema.org schemas are CSS or HTML content. > > From the NANOG mailing list, it looked as if you wanted to > automatically track a log of calendaring events (past or future) and > have a standard way to describe and parse the description to keep > track of what was done or needs to be done. (looks like > calendaring/scheduling to me) > > If your content is primarily for automated display (html or otherwise) > of data, then maybe schema.org web content will be what you want. > > If your content is for processing and work flow (that may be > displayed), then you may want an iCalendar (or other type) object. > > The two are not incompatible, as schema.org ties to MIME-types > (attachments). - See the schema.org contentType as one example. > Structured-Data has no benefit over ATTACH. I think people > misunderstand the ATTACH property. So how as an attachment would we represent the example: STRUCTURED-DATA;FMTTYPE=application/ld+json; SCHEMA="https://schema.org/SportsEvent"; VALUE=TEXT:{\n "@context": "http://schema.org"\,\n "@type": "SportsEvent"\,\n "homeTeam": "Pittsburgh Pirates"\,\n "awayTeam": "San Francisco Giants"\n }\n > > The W3C (schema.org) and the IETF are in agreement on object > identifiers. Schema.org allows for the definition of data sets, and > they are tied to mime types when sent as separate, non-web-page objects. > > Don't over complicate your data set. Define it, then map it to agreed > on names, value types, and when needed specific acceptable values. > Then decide if its values are primarily web-page-content, or a stand > alone transported objects. And if stand alone objects tied to calendar > date/time, then keep with the same format and do not invent another > one, it will just complicate parsers. I don't see how this complicates parsers: the value of structured-data can be ignored if you're not interested and presumably you havea parser if you are. > > > --------------8162EE9EC37814EFBEBF2D9F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 7/16/19 14:46, Doug Royer wrote:
On 7/16/19 10:17 AM, Ryan Gunter [Masked] wrote:
Preview: Ken / All, Thank you very much for the help. This is my first --> SPAM? CLICK to BLOCK <https://dnt.abine.com/#/block_email/c52sjc4j7tsm@opayq.com/FWD.chozigimwf2x@opayq.com>

This email is Masked using Blur - it was sent from ietf.org to c52sjc4j7tsm@opayq.com (your reply stays Masked). To protect your privacy <https://www.abine.com/faq.html#caniaddcc>, do not forward this message, or add new recipients like CCs or BCCs.

Thanks for being a Blur customer! If you haven't yet, [ Try DeleteMe at a discount. <https://joindeleteme.com/?utm_campaign=blur-offer&utm_source=masked-email-header> ]

Ken / All,

Thank you very much for the help.  This is my first IETF process so I'm still learning.

Our team has been discussing the options, and the STRUCTURED-DATA field might be better fit for our network maintenance use case.  Has there been any discussion about coding support / libraries / tooling for this property? Also, the draft indicates using standardized schemas from schema.org <http://schema.org> or hosting your own is acceptable, however we were curious if there were any thoughts on storing schemas specifically for STRUCTURED-DATA?

Is this a workflow process that involves scheduling? Or are you looking for an XML/HTML (schema.org) web page solution? A massive percentage of the schema.org schemas are CSS or HTML content.

From the NANOG mailing list, it looked as if you wanted to automatically track a log of calendaring events (past or future) and have a standard way to describe and parse the description to keep track of what was done or needs to be done. (looks like calendaring/scheduling to me)

If your content is primarily for automated display (html or otherwise) of data, then maybe schema.org web content will be what you want.

If your content is for processing and work flow (that may be displayed), then you may want an iCalendar (or other type) object.

The two are not incompatible, as schema.org ties to MIME-types (attachments). - See the schema.org contentType as one example. Structured-Data has no benefit over ATTACH. I think people misunderstand the ATTACH property.

So how as an attachment would we represent the example:

STRUCTURED-DATA;FMTTYPE=application/ld+json;
 SCHEMA="https://schema.org/SportsEvent";
 VALUE=TEXT:{\n
   "@context": "http://schema.org"\,\n
   "@type": "SportsEvent"\,\n
   "homeTeam": "Pittsburgh Pirates"\,\n
   "awayTeam": "San Francisco Giants"\n
 }\n

The W3C (schema.org) and the IETF are in agreement on object identifiers. Schema.org allows for the definition of data sets, and they are tied to mime types when sent as separate, non-web-page objects.

Don't over complicate your data set. Define it, then map it to agreed on names, value types, and when needed specific acceptable values. Then decide if its values are primarily web-page-content, or a stand alone transported objects. And if stand alone objects tied to calendar date/time, then keep with the same format and do not invent another one, it will just complicate parsers.
I don't see how this complicates parsers: the value of structured-data can be ignored if you're not interested and presumably you havea parser if you are.



--------------8162EE9EC37814EFBEBF2D9F-- From nobody Tue Jul 16 16:05: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 BA67B120162 for ; Tue, 16 Jul 2019 16:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 f8kSCFED_yNo for ; Tue, 16 Jul 2019 16:05:24 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 57D7512008D for ; Tue, 16 Jul 2019 16:05:24 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id j5so38533623ioj.8 for ; Tue, 16 Jul 2019 16:05:24 -0700 (PDT) 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:content-transfer-encoding; bh=HQU88EAnC/SF4lZkMABMu1TGHxYSGa/hTBLnmf2pK9A=; b=BAOSNLPbgwUScp5wBYwR6cCaTzvUYby9DqHdU/WyhX0VM7dfl4wj7u8Dv0ldZjnTdJ coeDzuchItAdoOpLfqVGJua8KmU9ZqflJy5N5eNxECzpztd6h4fnWA8RqE4OAxS2I+OX c/xkj0OulE4CrxJH3qEBcoM+yed/Mz670MOGEnkiYWSctFhEKqw3oI2fxH0cVEvmVmoc fhYHvf9+kfFezwO0826tuUP2v1rbgcHqL1qJ0sKmm7Vgb7uk3by6W1BpSyPkRwJcZXFK YX/m0D5QeJaIelS+msbkjhPOW8kjLA3n4Og+2OpQULEPH/gX9ioZ9JPDA8DeXAY8GvTp 2pMA== 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:content-transfer-encoding; bh=HQU88EAnC/SF4lZkMABMu1TGHxYSGa/hTBLnmf2pK9A=; b=ji8EAjmffkp8edn8xs1J088zi1Od50vJoKKOaae4afUh5VhRLHCSJbcYTX//34+CsR IrRe3g3h902Vx/Qstqp26Y5aLhxMyFn7vRYYazTmt7CybGf4OYwdTkpINcgpsD9Hhyu/ 2zIDTvknwPmKKfyFwGCOdQIKkoo9YCfabC0bcqeEQ2ra+IY+JoEQ3QLWptZ9JeVLLqXa ao8lxa4poKMdRILkylqQ466FlTH94401E2X2Qly9NssD914Z3uPe1/CKgMvA1N8v2mAU 9T44A9Ls9aI2RRdKw/ZFs7PR0LJdXy5aNJlHHSwH4fi9t4Tm/dihXKCGQHU3OsssLVd5 oygQ== X-Gm-Message-State: APjAAAU31qjhaXobQ+Z3JHkJO78M8Oo1MQzDu7DWsw+myYVj6f14kllb LPSXDxg7gMcb/Jneuhlo90XCpqVnCW2i X-Google-Smtp-Source: APXvYqzW8hJ3xmYctUPP8Ni1W1x1yRjEBA3SV7ItXdKBwGEnZdAXrUA+BAh0H0HK5zaOfqURkiEVig== X-Received: by 2002:a6b:fb0f:: with SMTP id h15mr33843904iog.266.1563318323383; Tue, 16 Jul 2019 16:05:23 -0700 (PDT) Received: from [192.168.1.7] ([174.27.175.146]) by smtp.googlemail.com with ESMTPSA id t5sm18456624iol.55.2019.07.16.16.05.21 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 16 Jul 2019 16:05:21 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <12d2d82e-121f-3583-592b-fcbd17f2b0d1@gmail.com> <17ad7de3-5957-eb65-a052-d6f9f93f2b23@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Tue, 16 Jul 2019 17:05:20 -0600 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: <17ad7de3-5957-eb65-a052-d6f9f93f2b23@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 16 Jul 2019 23:05:26 -0000 On 7/16/19 4:44 PM, Michael Douglass wrote: ject. >> >> The two are not incompatible, as schema.org ties to MIME-types (attachments). - See the schema.org contentType as one example. Structured-Data has no benefit over ATTACH. I think people misunderstand the ATTACH property. > > So how as an attachment would we represent the example: > > STRUCTURED-DATA;FMTTYPE=application/ld+json; > SCHEMA="https://schema.org/SportsEvent"; > VALUE=TEXT:{\n > "@context":"http://schema.org"\,\n > "@type": "SportsEvent"\,\n > "homeTeam": "Pittsburgh Pirates"\,\n > "awayTeam": "San Francisco Giants"\n > }\n Versus the current way, for which parsers already can read: ATTACH;FMTTYPE=text/SportsEvent;...:CID:sport-attachement1 ... ATTACH;FMTTYPE=text/Maintenance;...:CID:maint-attachement1 >> >> The W3C (schema.org) and the IETF are in agreement on object identifiers. Schema.org allows for the definition of data sets, and they are tied to mime types when sent as separate, non-web-page objects. >> >> Don't over complicate your data set. Define it, then map it to agreed on names, value types, and when needed specific acceptable values. Then decide if its values are primarily web-page-content, or a stand alone transported objects. And if stand alone objects tied to calendar date/time, then keep with the same format and do not invent another one, it will just complicate parsers. > I don't see how this complicates parsers: the value of structured-data can be ignored if you're not interested and presumably you havea parser if you are. Because you now have to write new code, to do the same as ATTACH. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Wed Jul 17 13:35:19 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 654DA120086; Wed, 17 Jul 2019 13:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 yE9VnyxdfZGi; Wed, 17 Jul 2019 13:35:17 -0700 (PDT) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (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 5255D120018; Wed, 17 Jul 2019 13:35:17 -0700 (PDT) Received: by mail-ua1-f43.google.com with SMTP id c4so10205795uad.1; Wed, 17 Jul 2019 13:35:17 -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:from:date:message-id:subject:to; bh=AiVhnihOrwinEw29pbpp0GtFvbBYJpKpefbdC8JfYUY=; b=Dn5VEKJHkOIZpYhwabPIvC3N3v8JNY7BJdmKncjWBrNHL+iKNFb2DH1uKJnRMr8KrP U+ulN4uJUnxfb/PWcusgxXnpmKLTO7HLbEZNNt4klwF/Dd5T48eiLJWtS9KhDwspuvU7 XtWO0TsgNIo3rO/XplUdWsB6nPFC3sMNc9VHh3CiZJtpQxNdzcTjGBp/QfEN4V7g5d+c 2FNMCeEyF8bCmaFJm1BDVr9aTlwR/s5efR+1v1U1X/A55WRsOVrKrle6SQagx+2m7Lf4 1LbKnkAM3rWA3rRuO2TUEs8qid3bSzyQWwwNNgD+dcJXuDGhKTrUYV4+M9+7xdXth/1y CtBw== X-Gm-Message-State: APjAAAXARrMDSpaj1KYPxx9GfY3qYglz+S+wC8cGYqOgPs8OrjcIyij2 qH3qPuA+CD6cF3DEl8te5V59wbJV9+SsepGPdZ55ErxL X-Google-Smtp-Source: APXvYqztQqZqcOTFxk7npNNs7Axi564D1bQIKclCrhyI8ilWZ7XGXb/yIA+Opc6s/Jlz/BMQKbbFmUqvJW7DAti1lS0= X-Received: by 2002:ab0:614d:: with SMTP id w13mr8055462uan.66.1563395716205; Wed, 17 Jul 2019 13:35:16 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Wed, 17 Jul 2019 16:35:05 -0400 Message-ID: To: IETF-Calsify , tzdist-bis@ietf.org Content-Type: multipart/alternative; boundary="0000000000004ed061058de66ebd" Archived-At: Subject: [calsify] tzdist and IANA 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, 17 Jul 2019 20:35:18 -0000 --0000000000004ed061058de66ebd Content-Type: text/plain; charset="UTF-8" Hi, IANA is budgeting its next 4 year plan, they are taking comments until end of July. In short inputs need to be provided before next IETF. This has already been suggested in the past that IANA could operate a tzdist server and I would like to get the opinion of the WGs on that. Please provide your feed backs if possible by the end of the week, as we expect to meet IANA people during the IETF in Montreal. I am in favour of having a global system to distribute the time zones, however, it seems maybe difficult to request IANA to operate the service alone. I believe we need a more scalable system. I would rather suggest that we work with IANA to build a scalable system within these four years. This may in turn require a revision of the tzdist protocol. I see the tzdist situation a bit similar as the one with the DNS root zone, where IANA provides the data and the root zone being served by multiple operators. In the case of tzdist I believe it would be helpful that IANA may be one of the operators. Yours, Daniel --0000000000004ed061058de66ebd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

IANA is budgeting its next 4 = year plan, they are taking comments until
end of July. In short inputs n= eed to be provided before next IETF.

This has already been suggested= in the past that IANA could operate a tzdist server and I would like to ge= t the opinion of the WGs on that. Please provide your feed backs if possibl= e by the end of the week, as we expect to meet IANA people during the IETF = in Montreal.

I am in favour of having a global sys= tem to distribute the time zones, however, it seems maybe difficult to requ= est IANA to operate the service alone. I believe we need a more scalable sy= stem. I would rather suggest that=C2=A0we work with IANA to build a scalabl= e system within these four years. This may in turn require a revision of th= e tzdist protocol.=C2=A0

I see the tzdist situatio= n a bit similar as the one with the DNS root zone, where IANA provides the = data and the root zone being served by multiple operators. In the case of t= zdist I believe it would be helpful that IANA may be one of the operators.= =C2=A0

Yours,=C2=A0
Daniel

=
--0000000000004ed061058de66ebd-- From nobody Wed Jul 17 13:42:19 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 C28051200FD; Wed, 17 Jul 2019 13:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 qjZQ-16z2GFb; Wed, 17 Jul 2019 13:42:15 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 45EAB120018; Wed, 17 Jul 2019 13:42:15 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id z4so24858691qtc.3; Wed, 17 Jul 2019 13:42:15 -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=PCVAeVKgfwY7dJPTSn/cDcZyiDhs3mwLqqAK9hFKnCQ=; b=U+qQWYYh/lZ0X305KhSgwgKfIuRXcB5Vf/U8xAHAr4YSL6U0c/SakjXmxyKHB9+thC baUuobOC8pM01J2L65CLJQRcoCR7awkjiPq/mJre7qPUGuSJGbxRwHyZFApdXNM1nodb Cc7qd8NZonf0fnjxEdTOP+LWevAs9Wuvl3f2vm6xBk+9VbPYj78nm1ZZL+02M/x/UH+S RKMBO2jaoGa6OqlELn/WUL67zHqtAEsd6HLrCPt1o38fM2HhU2YkcXUWeqSFVC2sbz/T BvOkKLFpGc85ND8QB26v4QQdicT7O+ciDxIiS9rUgFtEhZIyPz8I7NHlgVzEapVt6wJN vk2Q== 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=PCVAeVKgfwY7dJPTSn/cDcZyiDhs3mwLqqAK9hFKnCQ=; b=ccLhDS24YkmsF/2l6BB+9W6ezwlDZc+vjCH4g1KM3S3BUBwMVwnq1d0Kc+zo3OQJnU SjbVK2bvVucFNPbCWzQYHEdrXjBBDBQTaOX62owVnhB8liP++BuDB+k7UnCmMPeq675D p+GH01Ah8ot5IqCG9ZsJd86z6Mkqb+lqyNfDM74wigiAHN5cvNzChuCKIWWACVW37tYs bCRyryc0e/HnujI6LUAzhbkEHXFLPW4mR1DSajH+Zanf/CnnevuraQ8ojWo823pUrEFf cBOC2HSl1gXxXs6eDRKhdOh7yojLpStXi/VCqor70/pH2llm5pxW+1dEoLbZlRLyWvlG NTvw== X-Gm-Message-State: APjAAAVJcRSPqpwM7ambjG7eEcsBcS3T5gbCmmruayp0diskz7An8fhA zT85VaLNdCNEzYMgZOaBif8O9kr7 X-Google-Smtp-Source: APXvYqzHgEuxZgrsFel7Fyljwu0Lz0DQWTlICtwgdleaHPbuSwoiwXSB/C6qrTe0a/7GlLpkP/bwHQ== X-Received: by 2002:ac8:7611:: with SMTP id t17mr29689217qtq.112.1563396134042; Wed, 17 Jul 2019 13:42:14 -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 r189sm11768421qkc.60.2019.07.17.13.42.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jul 2019 13:42:13 -0700 (PDT) To: Daniel Migault , IETF-Calsify , tzdist-bis@ietf.org References: From: Michael Douglass Message-ID: Date: Wed, 17 Jul 2019 16:42:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B9E66CB4F3B19FB7503F88D9" Content-Language: en-US Archived-At: Subject: Re: [calsify] tzdist and IANA 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, 17 Jul 2019 20:42:18 -0000 This is a multi-part message in MIME format. --------------B9E66CB4F3B19FB7503F88D9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sounds good. We should include those currently maintaining the data as this probably implies some changes in that process. On 7/17/19 16:35, Daniel Migault wrote: > Hi, > > IANA is budgeting its next 4 year plan, they are taking comments until > end of July. In short inputs need to be provided before next IETF. > > This has already been suggested in the past that IANA could operate a > tzdist server and I would like to get the opinion of the WGs on that. > Please provide your feed backs if possible by the end of the week, as > we expect to meet IANA people during the IETF in Montreal. > > I am in favour of having a global system to distribute the time zones, > however, it seems maybe difficult to request IANA to operate the > service alone. I believe we need a more scalable system. I would > rather suggest that we work with IANA to build a scalable system > within these four years. This may in turn require a revision of the > tzdist protocol. > > I see the tzdist situation a bit similar as the one with the DNS root > zone, where IANA provides the data and the root zone being served by > multiple operators. In the case of tzdist I believe it would be > helpful that IANA may be one of the operators. > > Yours, > Daniel > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------B9E66CB4F3B19FB7503F88D9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Sounds good. We should include those currently maintaining the data as this probably implies some changes in that process.

On 7/17/19 16:35, Daniel Migault wrote:
Hi, 

IANA is budgeting its next 4 year plan, they are taking comments until
end of July. In short inputs need to be provided before next IETF.

This has already been suggested in the past that IANA could operate a tzdist server and I would like to get the opinion of the WGs on that. Please provide your feed backs if possible by the end of the week, as we expect to meet IANA people during the IETF in Montreal.

I am in favour of having a global system to distribute the time zones, however, it seems maybe difficult to request IANA to operate the service alone. I believe we need a more scalable system. I would rather suggest that we work with IANA to build a scalable system within these four years. This may in turn require a revision of the tzdist protocol. 

I see the tzdist situation a bit similar as the one with the DNS root zone, where IANA provides the data and the root zone being served by multiple operators. In the case of tzdist I believe it would be helpful that IANA may be one of the operators. 

Yours, 
Daniel


_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------B9E66CB4F3B19FB7503F88D9-- From nobody Wed Jul 17 13:46:29 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 04A8C12012D; Wed, 17 Jul 2019 13:46:28 -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=V7JCAgTT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DU8HQtFw 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 V-uFN4hJ0cf0; Wed, 17 Jul 2019 13:46:26 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B011200FD; Wed, 17 Jul 2019 13:46:26 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 46F7E21C0F; Wed, 17 Jul 2019 16:46:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 17 Jul 2019 16:46:25 -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=fm3; bh=6Z+DVvpRtPSUneqRgfcPYrbKZoU OJHFK2r5U9OKLrK0=; b=V7JCAgTT+06Pn4VqtO00aYgMGMns3ef522P4ldxbz59 YUUy+5tyC0eLVN5/7c+KaGXyS5PYdfnNQkuIIv/FagYX8jH5l7UCXsiy04eSYqwh uuiZtpebwp+wVwBTynDiPT0rvBzuJESRdj7iwlhMFzA6aBOCB+VONCqDxtPhOGdW VIpVhSLHCVkd18urUKk1L+ViSAg9CjBLicv3KVWcx9X2VIz3tDgw/C3eqKUoIScp Cvb6yyRn1WItLhaQ68DRL5RMFagLnZgvbgU8lpMdxadsyyFine5WkaQDcSuWFNnr 6GWRO90XHqxaGA0ZHhwSt5TFwZo/AKb8va/kogUHvhA== 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=fm3; bh=6Z+DVv pRtPSUneqRgfcPYrbKZoUOJHFK2r5U9OKLrK0=; b=DU8HQtFw7AWhr/aRk87B2/ wUtNNYXDGsjBsNJnlibTneyfotIjwvRgJJPYb7frZ3wIlTnT42sYNI8IS5mqKFDP YMs58S04OH+yMBGZ24iHI4gpYMCgOZAQiA/8EgcikFlQPkoyxjWJREAH2jhrjU7/ jGY6Q1aKmzMUhd7A7QDtvTsO/bvpkcMvwuWC5LUxaSANgOJTWxTj+PeImk61avm+ q02wDlz20dEIESk6E1djFud6BfP02aV7mTdaNb4GmPaauwgiJwmHrbafowVgG+yx yUzekQ5nXxw6pOA/hq65OHthZjoSmkr3w8uxBtnsht2HVQG3JzDMmkwIa4WT4VFQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrieefgddufedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgesmhdtreertdefjeenucfhrhhomhepmfgvnhcu ofhurhgthhhishhonhcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepjeegrdejjedrkeehrddvhedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomhenucevlhhush htvghrufhiiigvpedt 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 6B51C8005B; Wed, 17 Jul 2019 16:46:24 -0400 (EDT) To: Daniel Migault , IETF-Calsify , tzdist-bis@ietf.org References: From: Ken Murchison Organization: FastMail US LLC Message-ID: <9bf84b35-1918-e282-0c7c-bab8aee45f43@fastmail.com> Date: Wed, 17 Jul 2019 16:46:23 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------E7EE03BF72AA74F7FB8077DE" Content-Language: en-US Archived-At: Subject: Re: [calsify] tzdist and IANA 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, 17 Jul 2019 20:46:28 -0000 This is a multi-part message in MIME format. --------------E7EE03BF72AA74F7FB8077DE Content-Type: multipart/alternative; boundary="------------BD3E85223DCB3BC3D6A13DAB" --------------BD3E85223DCB3BC3D6A13DAB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I completely agree that we should approach IANA about hosting a root/primary TZDIST server, whether it be for iCalendar data (RFC5545) or TZif data (RFC 8536) or both. On 7/17/19 4:35 PM, Daniel Migault wrote: > Hi, > > IANA is budgeting its next 4 year plan, they are taking comments until > end of July. In short inputs need to be provided before next IETF. > > This has already been suggested in the past that IANA could operate a > tzdist server and I would like to get the opinion of the WGs on that. > Please provide your feed backs if possible by the end of the week, as > we expect to meet IANA people during the IETF in Montreal. > > I am in favour of having a global system to distribute the time zones, > however, it seems maybe difficult to request IANA to operate the > service alone. I believe we need a more scalable system. I would > rather suggest that we work with IANA to build a scalable system > within these four years. This may in turn require a revision of the > tzdist protocol. > > I see the tzdist situation a bit similar as the one with the DNS root > zone, where IANA provides the data and the root zone being served by > multiple operators. In the case of tzdist I believe it would be > helpful that IANA may be one of the operators. > > Yours, > Daniel > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify -- Ken Murchison Cyrus Development Team Fastmail US LLC --------------BD3E85223DCB3BC3D6A13DAB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I completely agree that we should approach IANA about hosting a root/primary TZDIST server, whether it be for iCalendar data (RFC5545) or TZif data (RFC 8536) or both.


On 7/17/19 4:35 PM, Daniel Migault wrote:
Hi, 

IANA is budgeting its next 4 year plan, they are taking comments until
end of July. In short inputs need to be provided before next IETF.

This has already been suggested in the past that IANA could operate a tzdist server and I would like to get the opinion of the WGs on that. Please provide your feed backs if possible by the end of the week, as we expect to meet IANA people during the IETF in Montreal.

I am in favour of having a global system to distribute the time zones, however, it seems maybe difficult to request IANA to operate the service alone. I believe we need a more scalable system. I would rather suggest that we work with IANA to build a scalable system within these four years. This may in turn require a revision of the tzdist protocol. 

I see the tzdist situation a bit similar as the one with the DNS root zone, where IANA provides the data and the root zone being served by multiple operators. In the case of tzdist I believe it would be helpful that IANA may be one of the operators. 

Yours, 
Daniel


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

-- 
Ken Murchison
Cyrus Development Team
Fastmail US LLC
--------------BD3E85223DCB3BC3D6A13DAB-- --------------E7EE03BF72AA74F7FB8077DE Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------E7EE03BF72AA74F7FB8077DE-- From nobody Wed Jul 17 15:20:52 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 44C9D120203; Wed, 17 Jul 2019 15:20:42 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 wQC0VKR7_ryn; Wed, 17 Jul 2019 15:20:40 -0700 (PDT) Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) (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 C9E59120170; Wed, 17 Jul 2019 15:20:39 -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 E77D75018AD; Wed, 17 Jul 2019 22:20:38 +0000 (UTC) Received: from pdx1-sub0-mail-a68.g.dreamhost.com (100-96-11-126.trex.outbound.svc.cluster.local [100.96.11.126]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 33910501B82; Wed, 17 Jul 2019 22:20:38 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|dave.thewlis@calconnect.org Received: from pdx1-sub0-mail-a68.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.3); Wed, 17 Jul 2019 22:20:38 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|dave.thewlis@calconnect.org X-MailChannels-Auth-Id: dreamhost X-Cold-Desert: 0993eae81de4afcb_1563402038738_1988730191 X-MC-Loop-Signature: 1563402038738:1867493010 X-MC-Ingress-Time: 1563402038738 Received: from pdx1-sub0-mail-a68.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a68.g.dreamhost.com (Postfix) with ESMTP id 740CE82B61; Wed, 17 Jul 2019 15:20:34 -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=9IxuGdF4hYF2MnzR R4s/1Ap3I+Q=; b=OSbiQV1ulWGST9Ujk3fkBfd6Rz9nWhbh2okqcNyQBUkMfz47 Q4ji+qWwOwk+mfatMDC186r1TsAeahz3t4h47/68db7N/g+t0lI4nXTOTobiSDm9 Yq4btb/5PhoC+GZ5A8yr9qwN2db8NnDj0JBNDrvJHOnijJ9WY6kxCq+B+wY= Received: from [192.168.0.108] (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-a68.g.dreamhost.com (Postfix) with ESMTPSA id 5A65382B60; Wed, 17 Jul 2019 15:20:32 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_12395A41-AF5B-4F12-AD66-317C15028CD9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) X-DH-BACKEND: pdx1-sub0-mail-a68 From: David Thewlis In-Reply-To: <9bf84b35-1918-e282-0c7c-bab8aee45f43@fastmail.com> Date: Wed, 17 Jul 2019 15:20:31 -0700 Cc: Daniel Migault , IETF-Calsify , tzdist-bis@ietf.org Message-Id: <71F326FF-1B26-4280-B496-DC8687A268D3@calconnect.org> References: <9bf84b35-1918-e282-0c7c-bab8aee45f43@fastmail.com> To: Ken Murchison X-Mailer: Apple Mail (2.3445.104.11) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrieeggddtjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjfffkfhfvofesrgdtmherhhdtjeenucfhrhhomhepffgrvhhiugcuvfhhvgiflhhishcuoegurghvvgdrthhhvgiflhhishestggrlhgtohhnnhgvtghtrdhorhhgqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeegjedrvddtkedrieejrddujeegnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopegludelvddrudeikedrtddruddtkegnpdhinhgvthepgeejrddvtdekrdeijedrudejgedprhgvthhurhhnqdhprghthhepffgrvhhiugcuvfhhvgiflhhishcuoegurghvvgdrthhhvgiflhhishestggrlhgtohhnnhgvtghtrdhorhhgqedpmhgrihhlfhhrohhmpegurghvvgdrthhhvgiflhhishestggrlhgtohhnnhgvtghtrdhorhhgpdhnrhgtphhtthhopegurghvvgdrthhhvgiflhhishestggrlhgtohhnnhgvtghtrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [calsify] tzdist and IANA 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, 17 Jul 2019 22:20:42 -0000 --Apple-Mail=_12395A41-AF5B-4F12-AD66-317C15028CD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree. =20 > On Jul 17, 2019, at 13:46, Ken Murchison wrote: >=20 > I completely agree that we should approach IANA about hosting a = root/primary TZDIST server, whether it be for iCalendar data (RFC5545) = or TZif data (RFC 8536) or both. >=20 >=20 >=20 > On 7/17/19 4:35 PM, Daniel Migault wrote: >> Hi,=20 >>=20 >> IANA is budgeting its next 4 year plan, they are taking comments = until >> end of July. In short inputs need to be provided before next IETF. >>=20 >> This has already been suggested in the past that IANA could operate a = tzdist server and I would like to get the opinion of the WGs on that. = Please provide your feed backs if possible by the end of the week, as we = expect to meet IANA people during the IETF in Montreal. >>=20 >> I am in favour of having a global system to distribute the time = zones, however, it seems maybe difficult to request IANA to operate the = service alone. I believe we need a more scalable system. I would rather = suggest that we work with IANA to build a scalable system within these = four years. This may in turn require a revision of the tzdist protocol.=20= >>=20 >> I see the tzdist situation a bit similar as the one with the DNS root = zone, where IANA provides the data and the root zone being served by = multiple operators. In the case of tzdist I believe it would be helpful = that IANA may be one of the operators.=20 >>=20 >> Yours,=20 >> Daniel >>=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 --Apple-Mail=_12395A41-AF5B-4F12-AD66-317C15028CD9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = agree.  



On Jul 17, 2019, at 13:46, Ken Murchison <murch@fastmail.com> = wrote:

=20 =20

I = completely agree that we should approach IANA about hosting a root/primary TZDIST server, whether it be for iCalendar data (RFC5545) or TZif data (RFC 8536) or both.


On 7/17/19 4:35 PM, Daniel Migault wrote:
Hi, 

IANA is budgeting its next 4 year plan, they are = taking comments until
end of July. In short inputs need to be provided before next IETF.

This has already been suggested in the past that IANA could operate a tzdist server and I would like to get the opinion of the WGs on that. Please provide your feed backs if possible by the end of the week, as we expect to meet IANA people during the IETF in Montreal.

I am in favour of having a global system to = distribute the time zones, however, it seems maybe difficult to request IANA to operate the service alone. I believe we need a more scalable system. I would rather suggest that we work with = IANA to build a scalable system within these four years. This may in turn require a revision of the tzdist protocol. 

I see the tzdist situation a bit similar as the = one with the DNS root zone, where IANA provides the data and the root zone being served by multiple operators. In the case of tzdist I believe it would be helpful that IANA may be one of the operators. 

Yours, 
Daniel


_______________________________________________
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

= --Apple-Mail=_12395A41-AF5B-4F12-AD66-317C15028CD9-- From nobody Wed Jul 17 17:12: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 9C20812064B; Wed, 17 Jul 2019 17:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 H3Nr0zbbMUJv; Wed, 17 Jul 2019 17:12:42 -0700 (PDT) Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29BD11204D4; Wed, 17 Jul 2019 17:12:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id D562C161672; Wed, 17 Jul 2019 17:12:41 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id CLbsq7SNl_7b; Wed, 17 Jul 2019 17:12:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 58BF416260C; Wed, 17 Jul 2019 17:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Fj5hn1Hx3kMJ; Wed, 17 Jul 2019 17:12:40 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 2D1AB161672; Wed, 17 Jul 2019 17:12:40 -0700 (PDT) To: Daniel Migault References: From: Paul Eggert Organization: UCLA Computer Science Department Cc: IETF-Calsify , tzdist-bis@ietf.org Message-ID: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> Date: Wed, 17 Jul 2019 17:12:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 00:12:49 -0000 Daniel Migault wrote: > I am in favour of having a global system to distribute the time zones, > however, it seems maybe difficult to request IANA to operate the service > alone. Due to privacy concerns I'd rather have servers distribute the entire tz database compactly, rather than gather information about clients' preferred time zones as tzdist currently does. Is this improvement something that we could propose to IANA as well? Currently the entire tzdb database (including version info and legal notice) fits into 22388 bytes compressed. I got this number by using lzip on tzdata.zi. From nobody Wed Jul 17 17:19:52 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 4BEAE1202D3; Wed, 17 Jul 2019 17:19:50 -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, FREEMAIL_FROM=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=fastmail.com header.b=wMvvI2KY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RIkO175t 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 5QJN-nddZRM7; Wed, 17 Jul 2019 17:19:47 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251EB12023E; Wed, 17 Jul 2019 17:19:47 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 186A121ED6; Wed, 17 Jul 2019 20:19:46 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 17 Jul 2019 20:19:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=VOc2XO6E3J/DX32DFK62PQ5XvQH 8yjCwFJIx1K5irB4=; b=wMvvI2KYavnRfq22v5dbJ6LDXHzzu8r4nHrV4QNQ399 fkjkkfUlOJ6/h4Pmjvrz6naM58OrSVq7PY8N376RCYVNS8q7hcEhgP4BHOsvlxmI Tdipzke/+iPMOLI6ixyoJs4zTpq5AMpKUqh6n4smMHI8LgwOzHe0eLUs6Eeg/pZh KERRgReZBt+q868qppMRoFyRYKh5OJOfbsTgkdIZACHYj6tS9/JNmr3Ys1xEj7Do QRCkZsOrHzbMcXvl08fxzgapFgpzPdWsM5cH8uoEpJYtfAWvhLBwY8KcIx4IAg1E PjVO4ziMMWCKsDfRc43Rs53qEsDHPNVtFI7thDLzXKQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=VOc2XO 6E3J/DX32DFK62PQ5XvQH8yjCwFJIx1K5irB4=; b=RIkO175tqOEEH2A57/zdJQ YXdyN+14csw4kIV4yL6fV+sz6e2WDKkU5r3h4WdLp3cCyJ+w62FlFgat/2WiGM78 VHJzAk8HU3PDqVJ9dLWPvqepyk9SE6ntEnzS1bZSq2SjpBwFerPe99RZO3Gx2p7v +KrwA8UgNz8UNfH8aGNS5eXaX/dYkroPQCyPY+C9e488K/U6VPyrAlPJW0Px9Q79 wMNtujuCv6lvLqvz15uqU9cTujLqWWKDoRiTAMGB4vo4Cp5Tok8cGHgBtnXMn3xl 6ssw1Pb05dFYgzJEjabw0CCXOSr/HUFcL6BoivP0LBo3An/tYQZxuBEGCtLsaqNA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrieeggdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhfhokffffgggjggtsehmtderredtfeejnecuhfhrohhmpefmvghnucfo uhhrtghhihhsohhnuceomhhurhgthhesfhgrshhtmhgrihhlrdgtohhmqeenucfkphepje egrdejjedrkeehrddvhedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehf rghsthhmrghilhdrtghomhenucevlhhushhtvghrufhiiigvpedt 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 3A306380074; Wed, 17 Jul 2019 20:19:45 -0400 (EDT) To: Paul Eggert , Daniel Migault Cc: tzdist-bis@ietf.org, IETF-Calsify References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> From: Ken Murchison Organization: FastMail US LLC Message-ID: <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> Date: Wed, 17 Jul 2019 20:19:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> Content-Type: multipart/mixed; boundary="------------C25E34A3A917870C7E078C8F" Content-Language: en-US Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 00:19:50 -0000 This is a multi-part message in MIME format. --------------C25E34A3A917870C7E078C8F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/17/19 8:12 PM, Paul Eggert wrote: > Daniel Migault wrote: >> I am in favour of having a global system to distribute the time zones, >> however, it seems maybe difficult to request IANA to operate the service >> alone. > > Due to privacy concerns I'd rather have servers distribute the entire > tz database compactly, rather than gather information about clients' > preferred time zones as tzdist currently does. Is this improvement > something that we could propose to IANA as well? "Clients" of the IANA TZDIST server would either be primary or secondary servers and would be fetching ALL changed zones.  There should be no end-user clients talking to an IANA TZDIST server. > > Currently the entire tzdb database (including version info and legal > notice) fits into 22388 bytes compressed. I got this number by using > lzip on tzdata.zi. There is no way to serve up raw tzdata via TZDIST because it can't be broken down into individual zones.  TZif is the format that can be used to distribute that data. -- Ken Murchison Cyrus Development Team Fastmail US LLC --------------C25E34A3A917870C7E078C8F Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------C25E34A3A917870C7E078C8F-- From nobody Wed Jul 17 17:40: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 4824F1200FA; Wed, 17 Jul 2019 17:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 o2irj59kDBna; Wed, 17 Jul 2019 17:40:37 -0700 (PDT) Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF2D12008D; Wed, 17 Jul 2019 17:40:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DFB2B16260C; Wed, 17 Jul 2019 17:40:36 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Ho167ACMVv_r; Wed, 17 Jul 2019 17:40:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2FD5B1626D4; Wed, 17 Jul 2019 17:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4AuejcIKGQXZ; Wed, 17 Jul 2019 17:40:36 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 01DBE16260C; Wed, 17 Jul 2019 17:40:35 -0700 (PDT) To: Ken Murchison , Daniel Migault Cc: tzdist-bis@ietf.org, IETF-Calsify References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> Date: Wed, 17 Jul 2019 17:40:35 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 00:40:38 -0000 Ken Murchison wrote: > "Clients" of the IANA TZDIST server would either be primary or secondar= y servers=20 > and would be fetching ALL changed zones.=C2=A0 There should be no end-u= ser clients=20 > talking to an IANA TZDIST server. True, I was worried more about privacy between clients and the secondary = servers. > There is no way to serve up raw tzdata via TZDIST Yes, and part of the proposal would be to improve TZDIST so that clients = can=20 obtain the entire tzdb efficiently. For secure clients there should be li= ttle=20 reason to request just a subset of tzdb when the entire database is so sm= all. From nobody Wed Jul 17 19:14:03 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 83F63120623; Wed, 17 Jul 2019 19:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 vw5HViTs6CDn; Wed, 17 Jul 2019 19:13:59 -0700 (PDT) Received: from mail-vs1-f65.google.com (mail-vs1-f65.google.com [209.85.217.65]) (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 56309120617; Wed, 17 Jul 2019 19:13:59 -0700 (PDT) Received: by mail-vs1-f65.google.com with SMTP id a186so16376608vsd.7; Wed, 17 Jul 2019 19:13:59 -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=6OhN1bHxzi4EPFagrR5dwjygi9hamdrsUWDx+pdR41M=; b=IIia3xIlwOetL9cTTLirq/vg2+CSpkWucbmoHM8QCyCyFoBlUIH6+GyQ2RRSGT1Ms7 0FHeu+q/R6Ue/YN+FC+sV3jrlLTpPee1Y00Fk8HYaWXWNu++3z5Ki4l+JQXMznEA3Nod GEjEC3UyrIAx3vx/47vXEGU6NV0/ZewuNcAmfXA1mM378D6u579fpepFBhqM8Av2gERo hLA9FBY2BclAR3UWVEYWYIZIyD53FMKlbzGFdBEHgXaPuRsLqnuza2vl0hYEVLs/Zarg UgcMkkPhECaY71pnj+QiVZpjPc+7OhJpHKf2TG4DvZ180DcvTiEzebAhL1zYW2+g9tPT dZnA== X-Gm-Message-State: APjAAAWtza/mVipZ5WOh/jPA7Kppmx3i/uEWIw47pEOXeCsgMl7zA3n7 AqocDYzr/FSQSYlgh9Yn/+4owGwF7GXGhkwPY6Y= X-Google-Smtp-Source: APXvYqzI3rWMqXJdB6/r9SVO83Irhl+8hKDGl9gfIDDkjWLAhBmEjGdCJFJF5AZCHZeuPxKm4h7oif6jAIfi/eRfCr8= X-Received: by 2002:a67:fb0d:: with SMTP id d13mr27881225vsr.69.1563416038394; Wed, 17 Jul 2019 19:13:58 -0700 (PDT) MIME-Version: 1.0 References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> In-Reply-To: <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> From: Daniel Migault Date: Wed, 17 Jul 2019 22:13:47 -0400 Message-ID: To: Paul Eggert Cc: Ken Murchison , tzdist-bis@ietf.org, IETF-Calsify Content-Type: multipart/alternative; boundary="0000000000009acdec058deb29eb" Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 02:14:02 -0000 --0000000000009acdec058deb29eb Content-Type: text/plain; charset="UTF-8" If I understand correctly the suggestion is to have tzdist server uploading the tzdata from IANA and client connecting to these tzdist servers. While some local network may have a local tzdist server, I would have expected that we could end up in having a global tzdist service that could be used by default by any client - let say tzdist.org. of course tzdist.org could be operated by multiple operators, and one of these could be the IANA. I am wondering if that is something in line with the latest messages. Retrieving the tzdb from IANA for example by a tzdist server is already something that can be done via FTP HTTP for the full tzdb or incrementally via rsynch. If IANA is operating a tzdist server, we could use a request with a "changedsince" parameter. Using the mechanism defined by tzdist seems to me appropriated as the root zone is distributed using a distribution master. My understanding is that we define an efficient way to do that in tzdist. Is that correct ? If the iana is not expected to serve client, I am wondering how the difference between clients and secondary would be made. Do we expect specific prmary/secondary relation being pre-agreed ? I understand Paul's suggestion as a generic suggestion that client generally should retrieve the full tzdb rather than a specific tz, in which case, this request should be optimised. As I understand it the privacy concern is more associated to the information leaked to the tzdist server as I assume that all exchanges would be performed over TLS. One concern I have regarding the use of TLS is that it protects the channel to the tzdist server, but I am not sure how the client can effectively check the data is in accordance to the one distributed by IANA. I am also wondering if we should not look at mechanisms that authenticate the data. This could in return prevent the need to use TLS. Yours, Daniel On Wed, Jul 17, 2019 at 8:40 PM Paul Eggert wrote: > Ken Murchison wrote: > > > "Clients" of the IANA TZDIST server would either be primary or secondary > servers > > and would be fetching ALL changed zones. There should be no end-user > clients > > talking to an IANA TZDIST server. > > True, I was worried more about privacy between clients and the secondary > servers. > > > There is no way to serve up raw tzdata via TZDIST > > Yes, and part of the proposal would be to improve TZDIST so that clients > can > obtain the entire tzdb efficiently. For secure clients there should be > little > reason to request just a subset of tzdb when the entire database is so > small. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --0000000000009acdec058deb29eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If I understand correctly the suggestion is to have t= zdist server uploading the tzdata from IANA and client connecting to these = tzdist servers. While some local network may have a local tzdist server, I = would have expected that we could end up in having a global tzdist service = that could be used by default by any client - let say tzdist.org. of course tzdist.org= could be operated by multiple operators, and one of these could be the= IANA. I am wondering if that is something in line with the latest messages= .=C2=A0

Retrieving the tzdb from IANA for example = by a tzdist server is already something that can be done via FTP HTTP for t= he full tzdb or incrementally via rsynch. If IANA is operating a tzdist ser= ver, we could use a request with a=C2=A0"changedsince" parameter. Using the mechanism d= efined by tzdist seems to me appropriated as the root zone is distributed u= sing a distribution master. My understanding is that we define an efficient= way to do that in tzdist. Is that correct ?
=C2=A0
If the iana is not expec= ted to serve client, I am wondering how the difference between clients and = secondary would be made. Do we expect specific prmary/secondary relation be= ing pre-agreed ?

I understand Paul's suggestion = as a generic suggestion that client generally should retrieve=C2=A0the full= tzdb rather than a specific tz, in which case, this request should=C2=A0be= optimised. As I understand it the privacy concern is more associated to th= e information leaked to the tzdist server as I assume that all exchanges wo= uld=C2=A0be performed over TLS. One concern I have regarding the use of TLS= is that it protects the channel to the tzdist server, but I am not sure ho= w the client can effectively check the data is in accordance to the one dis= tributed by IANA. I am also wondering if we should=C2=A0not look at mechani= sms=C2=A0that authenticate the data. This could in return prevent the need = to use TLS.=C2=A0 =C2=A0

Yours,=C2=A0
Daniel


<= span style=3D"font-size:13.3333px">
=C2=A0
=C2=A0


=C2=A0
=C2=A0



<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jul 17, 2019 at 8:40 PM Paul E= ggert <eggert@cs.ucla.edu> = wrote:
Ken Murch= ison wrote:

> "Clients" of the IANA TZDIST server would either be primary = or secondary servers
> and would be fetching ALL changed zones.=C2=A0 There should be no end-= user clients
> talking to an IANA TZDIST server.

True, I was worried more about privacy between clients and the secondary se= rvers.

> There is no way to serve up raw tzdata via TZDIST

Yes, and part of the proposal would be to improve TZDIST so that clients ca= n
obtain the entire tzdb efficiently. For secure clients there should be litt= le
reason to request just a subset of tzdb when the entire database is so smal= l.

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--0000000000009acdec058deb29eb-- From nobody Wed Jul 17 20:03:14 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 467E31200C4; Wed, 17 Jul 2019 20:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 J4ifSVhKBwfx; Wed, 17 Jul 2019 20:03:10 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (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 45842120045; Wed, 17 Jul 2019 20:03:10 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id l9so25625339qtu.6; Wed, 17 Jul 2019 20:03:10 -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=H+Hr+QQt9Omr2fuszR7vhv5A0p9orOui2WDp8axuovI=; b=TbtWE5ZHqXVOH/7tRvDFsM5AQxnUJCawkl7smDQv8xiIx9ou76QH5nLcEVOZxeAUGs xaXUI3qqRpaPDQYC9NvSZfxA+yS4+WUACcYUnxw4c2iJJLmNdWlq9wvHqnm20WUDERU2 HJ9+3SUY6chTnTx/R24W5OeBzTHINoSHYq65rvtApcIo1v2LQi5nRB7ZgztlLAJ7NCvL 3nYlO0+SD090N+HQDPEkKmw9td0uymSjUpWBP4yTylqnuSSkn4B6HsUobSyRpzbNDPQB rHgRkTHISPrFY36vs63bb7UykCrPm861/23qvkXG0zwae8VLAfh+Msdv7tCRGJSluJXN cuCg== 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=H+Hr+QQt9Omr2fuszR7vhv5A0p9orOui2WDp8axuovI=; b=EDCnCeAnJpRMGPg1+2rJCRBGECePovUG+LUAOA9HbyB4xGQXcAsxEFZGeRktkbYSSU lm3Vofx3hQzNHkmOvc269BKPuff3h23ZyHseCEMLh+3k4/Tuo4UnXybxI6mNmNPZ3Jxr dJ6PXbhi6igPDJs48DwFN686QDmS2wDkqAdW8QXuDDQTZ2wPPGNSo3v8hYIBT/oxKcTv lL0R4cuguqxrKamtY5O/oRq2Y9+2KLkdvQ6/imQi6EIKvURp5UkhzRqO2bEZNAADh1Gd dw+ciYVnwQF727iAnyIy2HUVe3igWE6qZyj1VG61FrOGM0vO7XMddDGnDdaorvlaIgAy ydFA== X-Gm-Message-State: APjAAAVZxqIXOvnDojGpWddAX+idm2DUpGwcsw6gofp5ReOLPf4EVZxc yWKvveMGRXGIdacFj4Mxvm4Q1ye2 X-Google-Smtp-Source: APXvYqynU4iayNwjoQBeu5mwiMVoIpS7ebWu+p2qwAMIZub1UIA1hyOFbFZ12hsZCtXzr432sR3YgA== X-Received: by 2002:a0c:9e27:: with SMTP id p39mr31097895qve.151.1563418989209; Wed, 17 Jul 2019 20:03:09 -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 i17sm11198010qkl.71.2019.07.17.20.03.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jul 2019 20:03:08 -0700 (PDT) To: Daniel Migault , Paul Eggert Cc: tzdist-bis@ietf.org, IETF-Calsify References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> From: Michael Douglass Message-ID: <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> Date: Wed, 17 Jul 2019 23:03:07 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------97A650E07728F632FA096704" Content-Language: en-US Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 03:03:13 -0000 This is a multi-part message in MIME format. --------------97A650E07728F632FA096704 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I guess my feeling on the privacy issues is that it should be a client choice. Certainly for a mobile device such as a phone the entire data set would be reasonable - especially if there were a way to reduce it to currently active data. However, for small devices - often with a fixed location - being able to retrieve a single zone is probably appropriate. I suspect the current approach we have implemented for updating downstream servers (though all downstream servers are really clients) would work for anybody. However - it does assume that we can have a sequence#/timestamp per zone On 7/17/19 22:13, Daniel Migault wrote: > If I understand correctly the suggestion is to have tzdist server > uploading the tzdata from IANA and client connecting to these tzdist > servers. While some local network may have a local tzdist server, I > would have expected that we could end up in having a global tzdist > service that could be used by default by any client - let say > tzdist.org . of course tzdist.org > could be operated by multiple operators, and one > of these could be the IANA. I am wondering if that is something in > line with the latest messages.. > > Retrieving the tzdb from IANA for example by a tzdist server is > already something that can be done via FTP HTTP for the full tzdb or > incrementally via rsynch. If IANA is operating a tzdist server, we > could use a request with a "changedsince" parameter. Using the > mechanism defined by tzdist seems to me appropriated as the root zone > is distributed using a distribution master. My understanding is that > we define an efficient way to do that in tzdist. Is that correct ? > If the iana is not expected to serve client, I am wondering how the > difference between clients and secondary would be made. Do we expect > specific prmary/secondary relation being pre-agreed ? I don't know there is any difference between clients and secondary servers. I would expect servers nearer the root to not be open to anybody but only to a small set of pre-registered servers as you suggest. I suspect that vendors - if they use this service would want to provide their own servers to their systems - e.g. Apple, MS, Ubuntu, AWS etc etc > > I understand Paul's suggestion as a generic suggestion that client > generally should retrieve the full tzdb rather than a specific tz, in > which case, this request should be optimised. As I understand it the > privacy concern is more associated to the information leaked to the > tzdist server as I assume that all exchanges would be performed over > TLS. One concern I have regarding the use of TLS is that it protects > the channel to the tzdist server, but I am not sure how the client can > effectively check the data is in accordance to the one distributed by > IANA. I am also wondering if we should not look at mechanisms that > authenticate the data. This could in return prevent the need to use TLS. I'm guessing the use of tls for most isn't an issue. tzdata is fairly slow moving and we're probably considering a once or twice a day check. Nothing compared to your facebook interactions. For small devices though it might be useful on a per zone basis > > Yours, > Daniel > > > > > > > > > > On Wed, Jul 17, 2019 at 8:40 PM Paul Eggert > wrote: > > Ken Murchison wrote: > > > "Clients" of the IANA TZDIST server would either be primary or > secondary servers > > and would be fetching ALL changed zones.  There should be no > end-user clients > > talking to an IANA TZDIST server. > > True, I was worried more about privacy between clients and the > secondary servers. > > > There is no way to serve up raw tzdata via TZDIST > > Yes, and part of the proposal would be to improve TZDIST so that > clients can > obtain the entire tzdb efficiently. For secure clients there > should be little > reason to request just a subset of tzdb when the entire database > is so small. > > _______________________________________________ > 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 --------------97A650E07728F632FA096704 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I guess my feeling on the privacy issues is that it should be a client choice. Certainly for a mobile device such as a phone the entire data set would be reasonable - especially if there were a way to reduce it to currently active data.

However, for small devices - often with a fixed location - being able to retrieve a single zone is probably appropriate.

I suspect the current approach we have implemented for updating downstream servers (though all downstream servers are really clients) would work for anybody. However - it does assume that we can have a sequence#/timestamp per zone

On 7/17/19 22:13, Daniel Migault wrote:
If I understand correctly the suggestion is to have tzdist server uploading the tzdata from IANA and client connecting to these tzdist servers. While some local network may have a local tzdist server, I would have expected that we could end up in having a global tzdist service that could be used by default by any client - let say tzdist.org. of course tzdist.org could be operated by multiple operators, and one of these could be the IANA. I am wondering if that is something in line with the latest messages.. 

Retrieving the tzdb from IANA for example by a tzdist server is already something that can be done via FTP HTTP for the full tzdb or incrementally via rsynch. If IANA is operating a tzdist server, we could use a request with a "changedsince" parameter. Using the mechanism defined by tzdist seems to me appropriated as the root zone is distributed using a distribution master. My understanding is that we define an efficient way to do that in tzdist. Is that correct ?
 
If the iana is not expected to serve client, I am wondering how the difference between clients and secondary would be made. Do we expect specific prmary/secondary relation being pre-agreed ?
I don't know there is any difference between clients and secondary servers. I would expect servers nearer the root to not be open to anybody but only to a small set of pre-registered servers as you suggest. I suspect that vendors - if they use this service would want to provide their own servers to their systems - e.g. Apple, MS, Ubuntu, AWS etc etc

I understand Paul's suggestion as a generic suggestion that client generally should retrieve the full tzdb rather than a specific tz, in which case, this request should be optimised. As I understand it the privacy concern is more associated to the information leaked to the tzdist server as I assume that all exchanges would be performed over TLS. One concern I have regarding the use of TLS is that it protects the channel to the tzdist server, but I am not sure how the client can effectively check the data is in accordance to the one distributed by IANA. I am also wondering if we should not look at mechanisms that authenticate the data. This could in return prevent the need to use TLS.  

I'm guessing the use of tls for most isn't an issue. tzdata is fairly slow moving and we're probably considering a once or twice a day check. Nothing compared to your facebook interactions.

For small devices though it might be useful on a per zone basis



Yours, 
Daniel



 
 


 
 




On Wed, Jul 17, 2019 at 8:40 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
Ken Murchison wrote:

> "Clients" of the IANA TZDIST server would either be primary or secondary servers
> and would be fetching ALL changed zones.  There should be no end-user clients
> talking to an IANA TZDIST server.

True, I was worried more about privacy between clients and the secondary servers.

> There is no way to serve up raw tzdata via TZDIST

Yes, and part of the proposal would be to improve TZDIST so that clients can
obtain the entire tzdb efficiently. For secure clients there should be little
reason to request just a subset of tzdb when the entire database is so small.

_______________________________________________
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
--------------97A650E07728F632FA096704-- From nobody Wed Jul 17 23:03:17 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 AD074120125; Wed, 17 Jul 2019 23:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 LDAymmFmTC_X; Wed, 17 Jul 2019 23:03:00 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A071A1200B7; Wed, 17 Jul 2019 23:02:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17416; q=dns/txt; s=iport; t=1563429779; x=1564639379; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=SfPCANJzDAY+2yEDmQIy+HDwt/cfuCafVmrycB18GKY=; b=WRo/mzVaeLdi6AdfUStwxyDGFDONuV+pFIW+OVNvi9NZHnfe+Qv6hxSd vXa27naSGqcEoyPZ8FeSBI5IWsVhGqTswXkQFYT3x0PaPJB7URgVKRaM6 n2ydh3hBxFxXKdWVrM0IOG9YO7rEGj7R2prFKPCD4i7NADQGF5H1nrar2 c=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACaCjBd/xbLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBFIFvUQEgEiqMOV+LACWHNIIgiSeGA4F7Agc?= =?us-ascii?q?BAQEJAwEBGAEKDAEBg3pGAoJrNAkOAQMBAQQBAQIBBW2FPAyFSgEBAQECAQE?= =?us-ascii?q?BbAQHBQsLDgonByEGHxEGE4MiAYFqAw4PD60TH4Uogk0NghcQgTQBgVCKJYF?= =?us-ascii?q?/gREnDBOCTD6CGkcBAYE6EUyDB4ImBIoOghCIU5UFLUAJghuCH4EMgiaBB4R?= =?us-ascii?q?uhFKDdBuDGoodilOUfYF1iwiDCwIEBgUCFYFQOESBFDMaCBsVOyoBgkEJNYs?= =?us-ascii?q?IhUE9AzCLFYJSAQE?= X-IronPort-AV: E=Sophos;i="5.64,277,1559520000"; d="asc'?scan'208,217";a="14366072" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jul 2019 06:02:57 +0000 Received: from [10.61.214.125] ([10.61.214.125]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x6I62uIP016899 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Jul 2019 06:02:56 GMT From: Eliot Lear Message-Id: <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_83CC8AD2-6D68-4074-A595-B3865B0DFD9B"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 18 Jul 2019 08:02:56 +0200 In-Reply-To: <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> Cc: Daniel Migault , Paul Eggert , tzdist-bis@ietf.org, IETF-Calsify To: Michael Douglass References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.214.125, [10.61.214.125] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 06:03:04 -0000 --Apple-Mail=_83CC8AD2-6D68-4074-A595-B3865B0DFD9B Content-Type: multipart/alternative; boundary="Apple-Mail=_CA1BD584-5F26-4085-ABF5-2B61BECE8DB3" --Apple-Mail=_CA1BD584-5F26-4085-ABF5-2B61BECE8DB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi everyone, While the IANA does a great job at servicing our assigned number needs = and delivering the TZ database to developers, they is not set up, nor do = they have any experience, to handle the load that end clients could = place on them. Moreover, they are in no position to support millions of = people if something goes wrong. And make no mistake: something will go = wrong. I would be okay with a limited tzdist service for those who are = going to be distributing the data themselves, but the order of receivers = should be on 100s not millions. Eliot > On 18 Jul 2019, at 05:03, Michael Douglass = wrote: >=20 > I guess my feeling on the privacy issues is that it should be a client = choice. Certainly for a mobile device such as a phone the entire data = set would be reasonable - especially if there were a way to reduce it to = currently active data. >=20 > However, for small devices - often with a fixed location - being able = to retrieve a single zone is probably appropriate. >=20 > I suspect the current approach we have implemented for updating = downstream servers (though all downstream servers are really clients) = would work for anybody. However - it does assume that we can have a = sequence#/timestamp per zone >=20 > On 7/17/19 22:13, Daniel Migault wrote: >> If I understand correctly the suggestion is to have tzdist server = uploading the tzdata from IANA and client connecting to these tzdist = servers. While some local network may have a local tzdist server, I = would have expected that we could end up in having a global tzdist = service that could be used by default by any client - let say tzdist.org = . of course tzdist.org could be = operated by multiple operators, and one of these could be the IANA. I am = wondering if that is something in line with the latest messages.. >>=20 >> Retrieving the tzdb from IANA for example by a tzdist server is = already something that can be done via FTP HTTP for the full tzdb or = incrementally via rsynch. If IANA is operating a tzdist server, we could = use a request with a "changedsince" parameter. Using the mechanism = defined by tzdist seems to me appropriated as the root zone is = distributed using a distribution master. My understanding is that we = define an efficient way to do that in tzdist. Is that correct ? >>=20 >> If the iana is not expected to serve client, I am wondering how the = difference between clients and secondary would be made. Do we expect = specific prmary/secondary relation being pre-agreed ? > I don't know there is any difference between clients and secondary = servers. I would expect servers nearer the root to not be open to = anybody but only to a small set of pre-registered servers as you = suggest. I suspect that vendors - if they use this service would want to = provide their own servers to their systems - e.g. Apple, MS, Ubuntu, AWS = etc etc >>=20 >> I understand Paul's suggestion as a generic suggestion that client = generally should retrieve the full tzdb rather than a specific tz, in = which case, this request should be optimised. As I understand it the = privacy concern is more associated to the information leaked to the = tzdist server as I assume that all exchanges would be performed over = TLS. One concern I have regarding the use of TLS is that it protects the = channel to the tzdist server, but I am not sure how the client can = effectively check the data is in accordance to the one distributed by = IANA. I am also wondering if we should not look at mechanisms that = authenticate the data. This could in return prevent the need to use TLS. > I'm guessing the use of tls for most isn't an issue. tzdata is fairly = slow moving and we're probably considering a once or twice a day check. = Nothing compared to your facebook interactions. >=20 > For small devices though it might be useful on a per zone basis >=20 >=20 >=20 >>=20 >> Yours, >> Daniel >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Wed, Jul 17, 2019 at 8:40 PM Paul Eggert > wrote: >> Ken Murchison wrote: >>=20 >> > "Clients" of the IANA TZDIST server would either be primary or = secondary servers >> > and would be fetching ALL changed zones. There should be no = end-user clients >> > talking to an IANA TZDIST server. >>=20 >> True, I was worried more about privacy between clients and the = secondary servers. >>=20 >> > There is no way to serve up raw tzdata via TZDIST >>=20 >> Yes, and part of the proposal would be to improve TZDIST so that = clients can >> obtain the entire tzdb efficiently. For secure clients there should = be little >> reason to request just a subset of tzdb when the entire database is = so small. >>=20 >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify = >>=20 >>=20 >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify = > _______________________________________________ > Tzdist-bis mailing list > Tzdist-bis@ietf.org > https://www.ietf.org/mailman/listinfo/tzdist-bis --Apple-Mail=_CA1BD584-5F26-4085-ABF5-2B61BECE8DB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi everyone,

While the IANA does a great job at servicing our assigned = number needs and delivering the TZ database to developers, they is not = set up, nor do they have any experience, to = handle the load that end clients could place on them.  Moreover, = they are in no position to support millions of people if something goes = wrong.  And make no mistake: something will go wrong.  I would = be okay with a limited tzdist service for those who are going to be = distributing the data themselves, but the order of receivers should be = on 100s not millions.

Eliot


On 18 Jul 2019, at 05:03, Michael Douglass <mikeadouglass@gmail.com> wrote:

=20

I = guess my feeling on the privacy issues is that it should be a client choice. Certainly for a mobile device such as a phone the entire data set would be reasonable - especially if there were a way to reduce it to currently active data.

However,= for small devices - often with a fixed location - being able to retrieve a single zone is probably appropriate.

I suspect the current approach we have implemented for = updating downstream servers (though all downstream servers are really clients) would work for anybody. However - it does assume that we can have a sequence#/timestamp per zone

On 7/17/19 22:13, Daniel Migault = wrote:
=20
If I understand correctly the suggestion is to = have tzdist server uploading the tzdata from IANA and client connecting to these tzdist servers. While some local network may have a local tzdist server, I would have expected that we could end up in having a global tzdist service that could be used by default by any client - let say tzdist.org. of course tzdist.org could be operated by multiple operators, and one of these could be the IANA. I am wondering if that is something in line with the latest messages.. 

Retrieving the tzdb from IANA for example by a = tzdist server is already something that can be done via FTP HTTP for the full tzdb or incrementally via rsynch. If IANA is operating a tzdist server, we could use a request with = a "changedsince" parameter. Using the mechanism defined by tzdist seems to me appropriated as the root zone is distributed using a distribution master. My understanding is that we define an efficient way to do that in tzdist. Is that correct = ?
 
If the iana is not expected to serve client, I am wondering how the difference between clients and secondary would be made. Do we expect specific prmary/secondary relation being pre-agreed ?
I don't know there is any difference between clients and secondary servers. I would expect servers nearer the root to not be open to anybody but only to a small set of pre-registered servers as you suggest. I suspect that vendors - if they use this service would want to provide their own servers to their systems - e.g. Apple, MS, Ubuntu, AWS etc etc

I understand Paul's suggestion as a generic suggestion that client generally should retrieve the full tzdb rather = than a specific tz, in which case, this request should be optimised. As I understand it the privacy concern is more associated to the information leaked to the tzdist server as I assume that all exchanges would be performed = over TLS. One concern I have regarding the use of TLS is that it protects the channel to the tzdist server, but I am not sure how the client can effectively check the data is in accordance to the one distributed by IANA. I am also wondering if we should not look at = mechanisms that authenticate the data. This could in return prevent the need to use TLS.  

I'm guessing the use of tls for most = isn't an issue. tzdata is fairly slow moving and we're probably considering a once or twice a day check. Nothing compared to your facebook interactions.

For small devices though it might be useful on a = per zone basis



Yours, 
Daniel



 
 


 
 




On Wed, Jul 17, 2019 at = 8:40 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
Ken Murchison wrote:

> "Clients" of the IANA TZDIST server would either be primary or secondary servers
> and would be fetching ALL changed zones.  There = should be no end-user clients
> talking to an IANA TZDIST server.

True, I was worried more about privacy between clients and the secondary servers.

> There is no way to serve up raw tzdata via TZDIST

Yes, and part of the proposal would be to improve TZDIST so that clients can
obtain the entire tzdb efficiently. For secure clients there should be little
reason to request just a subset of tzdb when the entire database is so small.

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

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

= --Apple-Mail=_CA1BD584-5F26-4085-ABF5-2B61BECE8DB3-- --Apple-Mail=_83CC8AD2-6D68-4074-A595-B3865B0DFD9B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXTALkAAKCRBugA9nE248 uHAMAJ0bA7usHrCNHqoAymKtond3FlCexgCgwnLe4tIznqp5rRiROov4lTtCACg= =3YxD -----END PGP SIGNATURE----- --Apple-Mail=_83CC8AD2-6D68-4074-A595-B3865B0DFD9B-- From nobody Thu Jul 18 01:29:34 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 A74C7120111; Thu, 18 Jul 2019 01:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 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_LOW=-0.7, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=burnicki.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 yLlo7LB2Dcms; Thu, 18 Jul 2019 01:29:30 -0700 (PDT) Received: from www52.your-server.de (www52.your-server.de [213.133.104.52]) (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 152C112016D; Thu, 18 Jul 2019 01:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=burnicki.net; s=default1902; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Kzh6XUwpaxP8GQaoaw2iPe6Muhf8ZczCx+TDtJTuf9U=; b=qh1d7xbZwBuRppu407lI1ZeJrz /Aj070e0s2V7tJdcmeE1+WSJCwfGGezb461hdTtHVcAmygMrwzqQ11dyu+jjX7rA+fFVAXOyBpt5A xJcNTd/RHHDUJ7gQCtPyl9ODVIobBHXn3vDikSnwdl9m3rkE17Yf6kb5/B7UmuHuntkULzNPiqq1Z ZdK9aMEb+B5nTiMpvEAnXQ2l+Pnw63b3ydhQikAfeVPe7j2D7y+OWPIZ4QSZwoBiDpsOhX7GnuAVC D0agpKov22A2ULdlkwJwSTa6L+YeWh3zZn6yrJKkOkNkk8c8ZufGZ0jhrL0H5pmNfHaOAaGys23ka kwFzPUmg==; Received: from [78.46.172.2] (helo=sslproxy05.your-server.de) by www52.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1ho1n1-0005ZS-Hu; Thu, 18 Jul 2019 10:29:23 +0200 Received: from [193.158.22.2] (helo=[172.16.14.10]) by sslproxy05.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ho1n1-000BaA-AP; Thu, 18 Jul 2019 10:29:23 +0200 To: Eliot Lear , Michael Douglass Cc: Daniel Migault , Paul Eggert , tzdist-bis@ietf.org, IETF-Calsify References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> From: Martin Burnicki Openpgp: preference=signencrypt Autocrypt: addr=martin.burnicki@burnicki.net; prefer-encrypt=mutual; keydata= xsFNBFUJbhwBEADpbjlFJrR+RWZSc5WFFmRVQUFQ+XwgRBrAtTkJyu+xhu6DvD6zq2IgnXQ3 W8pz/MoMMfKWaNOJ1qCxMfd8XrCR1WaO1m98Re9RqB9948ZH2VZIRN0MiLVVYLU0I0EufAUo y5P9TgyRet7Ojuy3j7LqOEjhYpIkkz1XNup2CjfNAN3xxrx8KJJ4iErtLL35X+UyNpHd57tx Y+OzOdBOfweHNyaj1vtY5cAQuzR66hom+gK0YyuXdGDeN5Gb1nvk8H9tj5Fd/VIm4nZdIxam n63Mdk8mQ7dO8f04B0XzhAxF0+B9uZqdC0twUuRvROuDC6eAjO3JganfXvCE6QKTb3rOM8l1 c8bTA/Pg3WF6y2Jnq4Rs4I1SiU9Oy5elr6pJJdhi7RY0b2Lj4l/7SaiwUCyMBX3Gm00sWOYF OU9fYa6cs/IvW9JQbeQu9Ph8QYczH51sNBpL7RfkjGybqZyU+HKs0EUe6nlpuIPL3MZ3QoKl G1M7PhV2BGkn3fzLHsDp1Nxuv1bbdfW4dkdyW/yLcu994VYSFrgDStt9g1Or0mkk+HeR0m3O 46w/FHw7ykvA8bp+2WMzJmyenj2/LN15l3CGewAbjjzgN9A1AOKlxGKcLOeTObxDMzj6qFWN O/g5GEsvYTe0qA3JEnNboJFJurBQJg7GBkAske0oJzTh9SgcTwARAQABzS5NYXJ0aW4gQnVy bmlja2kgPG1hcnRpbi5idXJuaWNraUBidXJuaWNraS5uZXQ+wsF7BBMBAgAlAhsvBgsJCAcD AgYVCAIJCgsEFgIDAQIeAQIXgAUCVg53sAIZAQAKCRDngzsH2I4xxZFMD/sE01cEvOva3nJW G9aUTmiKZJGfZHQ5I4JJUbixxPJxlV/U3oA7W9iEzH8Wn86HqZREEwKHLkFCWH6ij4riCyxV pq8i5xrq5nQm3ZEqfC2T7oi2FunOzGn6RDY7dK5x+o4OVaisWPFiT0fh23SvDsyxdjwHU81C eV+CDVwnhqjXjt+jwMOJ8Ix0aZ2CrOv5T029iaFwwYtF8s1HoXpYAgbataLFMZg7SCeJ8cmF F7XvSRbx9lWS2LQiKfwSoN0kU7s9cXz7lDNrSTdn7x0GiawrCGl6eknJ0/t2Qig3K3uRMxyU 0m1n7K2XuprLRBiobNqAQeyQlvf8Zw/CYbZ6DSoZnYB6WIz7xnp3fkXsxrxvaJabtGvzLX9R 5MjgtzFHEv5aAA8H66KsbM94L9sYI7aEjWe1RXN4VdDe5S4Y8GufYXtUmY20U81+XfVu3NUo v2iKl5Ynmp8DkFeYQ/P8vVve6fY8efctkyXtfV+WmkjGu0sTTYONnK+r10HxC0LxUo0Fg53v 6eK5uSwssPhE0guJ80qyasgAJg9zxkiJfg+px6YcTxsYgO9DQYdKEN5bX1eAfedXKAMLBIdq NwJIgGXT36Wd+GOVIGWDDIuhyHdzWp3RX69Qy8Ffdt9Jvg43D7TvQeEooigGxqfaq+g3wGOK P+QsVuCUcxaJQFSUCVrqOs7BTQRVCW4cARAA+fD7nDYh16eR+qE8ZRv2A+Oxv1OJxPdIJPwl yILGzwY1iQuG4IdEsFX2889aOiydmZRTvEcEcBu4hZ2o8IQlPF7Z8YAtb57RU71QDXU6P/v2 f851nDh6PWhx3SiaNbaluFenEv5l3gwn0oJrTJ3sfQqfcFi8ovlKGH35ZfZowo5lb5mg2B/P kWaZ84e23or7r6XxbilcY/2YSkf6w60wPVqUDnRMVNOsJPKzgpNhhMoxl0PeHRf/P5frx0YO q2rCxLF4OmlKQQeCNL/NiATxDe0zlmmsIdzujADlmmFD1cb/ioX0qDSU3duLaxmzt3lLj4K4 gOHEHUMoxbO5X3ANXa5WbbqeVRmG0NpV04xn0z9ZMNB02+/dHYzcd3FQdd0c41REDm//EzYm pmePcyYUVxzJTO1ZOe/Wm1jfCtNDqJUuaqsFgFIHWxfqC/lNTYpsRTFroF9qUc9GVGZiWc19 csMEiRUe1zF3ptR32/AtKn/ENRGG9wg64K/QL394zp+bi/3ZUrZXmhDhk2yT7nAGGP8OTZNW c9fPyLA2ZhDSdtGWaCXI0x+9BpWdxMJNK8KDSKlKkq9WS8pAh7fTKfm/ZgHksREn5EMgBlLD ZqLTnisi27pTpZdEdw056OYSlsS8wbGjskR4fSwSVf8poKkjg+xWiWJK3guULEHAqJc/8f0A EQEAAcLDfgQYAQIACQUCVQluHAIbLgIpCRDngzsH2I4xxcFdIAQZAQIABgUCVQluHAAKCRD+ 8+9OQlkOPUdcD/wPqaOmOEqbXR1vtiGYIwndveXaHOaJHQFZJ6dBGOoz1uz5AeJqCDWl/T60 w9rQ027JI2QNpc7FXc+9qzfKY0BmFcAKw8zB8Vd8fBWrFeg3VZ1SV/EiJqsc+6EVeXRuus0h v+UrpyXz4fhzhPGmNU8xyEZK9TTcHwLKWZyFgb+CUeKrJPZyckd4xsm0D3snaGIUe4itDsoi 2nXUehtJ5/QFInmgV3Xood7w1em9SQAc3pwYagDrWuTjjYni0fqWf2h/K3Q5nRjYc+Z/G/py WI/PqrMJ40gXUiI6o2xa2Hro+JVMb1O5Hv6fFmUPWNOJRuurg/0j8XYMLgAKg1sJua4/f8Ky jGYhJo82cXMHRvXEvMOnG8/vd42s4A1M96eOuxaVKZCdipTNWqIKQzkEVOixUPgie8sM/DPY 8TXhrsmRsWy9gb+pmszqmyvkTf4N1nP8yhS0wujtxxp6OHuzZs6EA2PB3t6CY4jFQ9Wx/YY8 A2abAhDb321Y79JhciNhBeBSTHivDnG3gsOy17LulRlkVN18vfTacxfQpJ0cafWExMmCE+o8 TMz85rQF8S7ftKIl9pJCcD6sZnxOTfkUa8C1NI93t+n4xe93wb+/8DiyVw8ZEa02RRYh/3ua +/2CDUvwR+qozbM4+1xb1skWYt81Vi7eLzGeZP2HscaieTYsKLgqD/sES5rNrNDKrItZKpP4 /r+c7F1zwCBxLyW2wcZyi5weEL8UaAu31HhoWT32y54m0ZyVrPVRwDXV8iHpCgMck26VLinj yFfi8WZsolS1lxLPOdD2B67sVNKXISJQk/Y2CN1CXA0vWLc0ENsaQyZAZjAbuo+TT37WjoXT nO8lOJJ5D9LhyjFjW0hYMFJq3eBAdxfGROyFOK9N29FU3hoU+tsYPSKrl3ws3PMg45cyRHLV Rip0xr0yXPYUYb70FnE70nVGICvMgUpmrM4XH1Yr7kt+5cBM583yuJ94rF/hOFHuR4GQWeFR xBSWd41qArjdABIxhZrnMICSW3fMyo9yfiQ6tXoyD1cHD/i2WmOnqCKEOtFScVeQJZJhqQb5 4NBx+viRax9d+X066AKYiBspm7kYwBVzNsng3uHOfyQXnVmcCEawxWIPyCtxSoV6fCKYdAfJ CQeElBXE89inkdGmdb0KLmYkHDoV4L1deAsPUI/t6qZjwqF3pKcr8kdGExqHwvytL8n1KGbY PyJ6Fn1z/idOOiTYgN+Q7FWRRX0QplyVpSBU4OnD0Gd3KkP+a0+kErokA1Lk3/YCE45VT8J8 8f4YGbRsIkf0xW+Ei0fk3fl9VPOrbTD+gFv+AzbT+Gp1+kElwVKj0VzXy0OC6UIQJ3J1on0l ArkcfPTIMcWxGmfGPw== Message-ID: Date: Thu, 18 Jul 2019 10:29:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-Sender: mailout@burnicki.net X-Virus-Scanned: Clear (ClamAV 0.100.3/25513/Wed Jul 17 10:15:42 2019) Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 08:29:33 -0000 Hi all, Eliot Lear wrote: > Hi everyone, > > While the IANA does a great job at servicing our assigned number needs > and delivering the TZ database to developers, they is not set up, nor do > they have *any*experience, to handle the load that end clients could > place on them. Moreover, they are in no position to support millions of > people if something goes wrong. And make no mistake: something will go > wrong. I would be okay with a limited tzdist service for those who are > going to be distributing the data themselves, but the order of receivers > should be on 100s not millions. Wouldn't it be nice to have an infrastructure similar to what the NTP pool provides for time synchronization? https://www.ntppool.org/en/ There could be one or more primary servers that might have restricted access, and there could be servers operated by companies, ISPs, or volunteers that get the information from the primaries and make the service available to customers or the general public. Depending on their preferences or policies, users could choose specific servers provided by the company they work for, or by their ISP. If none of those is appropriate they could just use the TZDIST pool where a DNS server provides the IP address of a nearby available TZDIST server, just like this is done for the NTP pool. Of course it would be good if the final client could verify that the provided TZ information is authentic. I'm not sure if this can be achieved by access via https, or if the TZ/TZDIST data should include a cryptographic signature. Martin From nobody Thu Jul 18 01:40:36 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 61A9712013C; Thu, 18 Jul 2019 01:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 428-Uj5whUZM; Thu, 18 Jul 2019 01:40:26 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC866120111; Thu, 18 Jul 2019 01:40:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2038; q=dns/txt; s=iport; t=1563439226; x=1564648826; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=1XraiBT1L8DU0O3sZ2N1qLabllX3Ek4zV4okxYx0P54=; b=UATLv2lr6w5ui/XRdrDRinycHortLFv2A7JcnE+HOMkoZcFry0GygmgI BXiuFPgDsiABecOt7xrW0NJewEPknqj0AayuF7OJcO4RCoJD10cVumjeR Fd6cwtFL2rzmLsRY7O1yMdvHsnvlEniszImdHWBhHlLkPsH65mo3JEOvs U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAABhLzBd/xbLJq1mGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4FogW0BIBIqjRiLJn6ZewIHAQEBCQMBAS8BAYRAAoJtOBM?= =?us-ascii?q?BAwEBBAEBAgEFbYVIhUoBAQEBAgF5BQsLGC5XBhODIgGBew+tX4VHhHEQgTS?= =?us-ascii?q?BUYolgX+BEScfghc1PoQdg2SCJgSMHjOIIJVyCYIbgh+BDIgbiEYbjTeKU6F?= =?us-ascii?q?6gwsCBAYFAhWBZyFEgRQzGggbFWUBgkE+kEk9AzCKe4JSAQE?= X-IronPort-AV: E=Sophos;i="5.64,276,1559520000"; d="asc'?scan'208";a="14432613" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jul 2019 08:40:23 +0000 Received: from [10.61.214.125] ([10.61.214.125]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x6I8eLbl018189 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Jul 2019 08:40:22 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_875DA367-2155-45C5-8D46-5C79A9C9A0B4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 18 Jul 2019 10:40:21 +0200 In-Reply-To: Cc: Michael Douglass , Daniel Migault , Paul Eggert , tzdist-bis@ietf.org, IETF-Calsify To: Martin Burnicki References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.214.125, [10.61.214.125] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 08:40:29 -0000 --Apple-Mail=_875DA367-2155-45C5-8D46-5C79A9C9A0B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 18 Jul 2019, at 10:29, Martin Burnicki = wrote: >=20 > Hi all, >=20 > Eliot Lear wrote: >> Hi everyone, >>=20 >> While the IANA does a great job at servicing our assigned number = needs >> and delivering the TZ database to developers, they is not set up, nor = do >> they have *any* experience, to handle the load that end clients could >> place on them. Moreover, they are in no position to support millions = of >> people if something goes wrong. And make no mistake: something will = go >> wrong. I would be okay with a limited tzdist service for those who = are >> going to be distributing the data themselves, but the order of = receivers >> should be on 100s not millions. >=20 > Wouldn't it be nice to have an infrastructure similar to what the NTP > pool provides for time synchronization? I guess I would want to see commitment from those who provide TZ service = to their customers today to go to such a new service before investing a = lot of money. Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any = of the others want to use it? I also realize that ICANN is well = positioned to fund this sort of thing, but it is not clear to me that it = is right for them to do so. There has to be a real need, and those who = really need it perhaps should foot the bill. Eliot --Apple-Mail=_875DA367-2155-45C5-8D46-5C79A9C9A0B4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXTAwdQAKCRBugA9nE248 uBaxAJ9EGg68vQfDR9tD+LIeJkAC21Ry0QCg8w4v+ICYCO0MqnVR3YztvU+tFHA= =XXGX -----END PGP SIGNATURE----- --Apple-Mail=_875DA367-2155-45C5-8D46-5C79A9C9A0B4-- From nobody Thu Jul 18 02:41:26 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 C14DF12017C; Thu, 18 Jul 2019 02:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 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_LOW=-0.7, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=burnicki.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 BnbuWZnmhygs; Thu, 18 Jul 2019 02:41:14 -0700 (PDT) Received: from www52.your-server.de (www52.your-server.de [213.133.104.52]) (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 0910A1200B6; Thu, 18 Jul 2019 02:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=burnicki.net; s=default1902; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MlPkrYbRYUEoDzEhJKwrw/kVkGTY7GtQ05N7r/+2vl4=; b=iNqwUN67kK00hbpU+UHAlThpbs vvqmN1ErBpiBKly115P4PEc7PpLsXSpesUtdAQeo5rQc7CoSKdoatMuIakKPNARoE2jwToKIIQ4yv 6PA6ZApjodRtqE8bhOBIS3yY03JT7nCkid/4tCJ7ZW0wuuFWHUIgmUTXViRf7MTLab71rR/TRKJbL r1biYCtGBPJtH3ZHoWM/jx1HUGdeFZXrSLxxg/eHAAyjsyEUe+dbv7WN+JIjZsEfKXhh4lkwMOlj0 ka30Xc1zbGxTwDiS2k4u708FtdAA2mjB59ATiH0ghTGQ4Becv+D7rzyBMXffK1z8r5cQiH6woAsoM lgRhngOg==; Received: from [78.46.172.2] (helo=sslproxy05.your-server.de) by www52.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1ho2uR-0002GU-E4; Thu, 18 Jul 2019 11:41:07 +0200 Received: from [193.158.22.2] (helo=[172.16.14.10]) by sslproxy05.your-server.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1ho2uR-000HQF-0R; Thu, 18 Jul 2019 11:41:07 +0200 To: Eliot Lear Cc: Michael Douglass , Daniel Migault , Paul Eggert , tzdist-bis@ietf.org, IETF-Calsify References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> From: Martin Burnicki Openpgp: preference=signencrypt Autocrypt: addr=martin.burnicki@burnicki.net; prefer-encrypt=mutual; keydata= xsFNBFUJbhwBEADpbjlFJrR+RWZSc5WFFmRVQUFQ+XwgRBrAtTkJyu+xhu6DvD6zq2IgnXQ3 W8pz/MoMMfKWaNOJ1qCxMfd8XrCR1WaO1m98Re9RqB9948ZH2VZIRN0MiLVVYLU0I0EufAUo y5P9TgyRet7Ojuy3j7LqOEjhYpIkkz1XNup2CjfNAN3xxrx8KJJ4iErtLL35X+UyNpHd57tx Y+OzOdBOfweHNyaj1vtY5cAQuzR66hom+gK0YyuXdGDeN5Gb1nvk8H9tj5Fd/VIm4nZdIxam n63Mdk8mQ7dO8f04B0XzhAxF0+B9uZqdC0twUuRvROuDC6eAjO3JganfXvCE6QKTb3rOM8l1 c8bTA/Pg3WF6y2Jnq4Rs4I1SiU9Oy5elr6pJJdhi7RY0b2Lj4l/7SaiwUCyMBX3Gm00sWOYF OU9fYa6cs/IvW9JQbeQu9Ph8QYczH51sNBpL7RfkjGybqZyU+HKs0EUe6nlpuIPL3MZ3QoKl G1M7PhV2BGkn3fzLHsDp1Nxuv1bbdfW4dkdyW/yLcu994VYSFrgDStt9g1Or0mkk+HeR0m3O 46w/FHw7ykvA8bp+2WMzJmyenj2/LN15l3CGewAbjjzgN9A1AOKlxGKcLOeTObxDMzj6qFWN O/g5GEsvYTe0qA3JEnNboJFJurBQJg7GBkAske0oJzTh9SgcTwARAQABzS5NYXJ0aW4gQnVy bmlja2kgPG1hcnRpbi5idXJuaWNraUBidXJuaWNraS5uZXQ+wsF7BBMBAgAlAhsvBgsJCAcD AgYVCAIJCgsEFgIDAQIeAQIXgAUCVg53sAIZAQAKCRDngzsH2I4xxZFMD/sE01cEvOva3nJW G9aUTmiKZJGfZHQ5I4JJUbixxPJxlV/U3oA7W9iEzH8Wn86HqZREEwKHLkFCWH6ij4riCyxV pq8i5xrq5nQm3ZEqfC2T7oi2FunOzGn6RDY7dK5x+o4OVaisWPFiT0fh23SvDsyxdjwHU81C eV+CDVwnhqjXjt+jwMOJ8Ix0aZ2CrOv5T029iaFwwYtF8s1HoXpYAgbataLFMZg7SCeJ8cmF F7XvSRbx9lWS2LQiKfwSoN0kU7s9cXz7lDNrSTdn7x0GiawrCGl6eknJ0/t2Qig3K3uRMxyU 0m1n7K2XuprLRBiobNqAQeyQlvf8Zw/CYbZ6DSoZnYB6WIz7xnp3fkXsxrxvaJabtGvzLX9R 5MjgtzFHEv5aAA8H66KsbM94L9sYI7aEjWe1RXN4VdDe5S4Y8GufYXtUmY20U81+XfVu3NUo v2iKl5Ynmp8DkFeYQ/P8vVve6fY8efctkyXtfV+WmkjGu0sTTYONnK+r10HxC0LxUo0Fg53v 6eK5uSwssPhE0guJ80qyasgAJg9zxkiJfg+px6YcTxsYgO9DQYdKEN5bX1eAfedXKAMLBIdq NwJIgGXT36Wd+GOVIGWDDIuhyHdzWp3RX69Qy8Ffdt9Jvg43D7TvQeEooigGxqfaq+g3wGOK P+QsVuCUcxaJQFSUCVrqOs7BTQRVCW4cARAA+fD7nDYh16eR+qE8ZRv2A+Oxv1OJxPdIJPwl yILGzwY1iQuG4IdEsFX2889aOiydmZRTvEcEcBu4hZ2o8IQlPF7Z8YAtb57RU71QDXU6P/v2 f851nDh6PWhx3SiaNbaluFenEv5l3gwn0oJrTJ3sfQqfcFi8ovlKGH35ZfZowo5lb5mg2B/P kWaZ84e23or7r6XxbilcY/2YSkf6w60wPVqUDnRMVNOsJPKzgpNhhMoxl0PeHRf/P5frx0YO q2rCxLF4OmlKQQeCNL/NiATxDe0zlmmsIdzujADlmmFD1cb/ioX0qDSU3duLaxmzt3lLj4K4 gOHEHUMoxbO5X3ANXa5WbbqeVRmG0NpV04xn0z9ZMNB02+/dHYzcd3FQdd0c41REDm//EzYm pmePcyYUVxzJTO1ZOe/Wm1jfCtNDqJUuaqsFgFIHWxfqC/lNTYpsRTFroF9qUc9GVGZiWc19 csMEiRUe1zF3ptR32/AtKn/ENRGG9wg64K/QL394zp+bi/3ZUrZXmhDhk2yT7nAGGP8OTZNW c9fPyLA2ZhDSdtGWaCXI0x+9BpWdxMJNK8KDSKlKkq9WS8pAh7fTKfm/ZgHksREn5EMgBlLD ZqLTnisi27pTpZdEdw056OYSlsS8wbGjskR4fSwSVf8poKkjg+xWiWJK3guULEHAqJc/8f0A EQEAAcLDfgQYAQIACQUCVQluHAIbLgIpCRDngzsH2I4xxcFdIAQZAQIABgUCVQluHAAKCRD+ 8+9OQlkOPUdcD/wPqaOmOEqbXR1vtiGYIwndveXaHOaJHQFZJ6dBGOoz1uz5AeJqCDWl/T60 w9rQ027JI2QNpc7FXc+9qzfKY0BmFcAKw8zB8Vd8fBWrFeg3VZ1SV/EiJqsc+6EVeXRuus0h v+UrpyXz4fhzhPGmNU8xyEZK9TTcHwLKWZyFgb+CUeKrJPZyckd4xsm0D3snaGIUe4itDsoi 2nXUehtJ5/QFInmgV3Xood7w1em9SQAc3pwYagDrWuTjjYni0fqWf2h/K3Q5nRjYc+Z/G/py WI/PqrMJ40gXUiI6o2xa2Hro+JVMb1O5Hv6fFmUPWNOJRuurg/0j8XYMLgAKg1sJua4/f8Ky jGYhJo82cXMHRvXEvMOnG8/vd42s4A1M96eOuxaVKZCdipTNWqIKQzkEVOixUPgie8sM/DPY 8TXhrsmRsWy9gb+pmszqmyvkTf4N1nP8yhS0wujtxxp6OHuzZs6EA2PB3t6CY4jFQ9Wx/YY8 A2abAhDb321Y79JhciNhBeBSTHivDnG3gsOy17LulRlkVN18vfTacxfQpJ0cafWExMmCE+o8 TMz85rQF8S7ftKIl9pJCcD6sZnxOTfkUa8C1NI93t+n4xe93wb+/8DiyVw8ZEa02RRYh/3ua +/2CDUvwR+qozbM4+1xb1skWYt81Vi7eLzGeZP2HscaieTYsKLgqD/sES5rNrNDKrItZKpP4 /r+c7F1zwCBxLyW2wcZyi5weEL8UaAu31HhoWT32y54m0ZyVrPVRwDXV8iHpCgMck26VLinj yFfi8WZsolS1lxLPOdD2B67sVNKXISJQk/Y2CN1CXA0vWLc0ENsaQyZAZjAbuo+TT37WjoXT nO8lOJJ5D9LhyjFjW0hYMFJq3eBAdxfGROyFOK9N29FU3hoU+tsYPSKrl3ws3PMg45cyRHLV Rip0xr0yXPYUYb70FnE70nVGICvMgUpmrM4XH1Yr7kt+5cBM583yuJ94rF/hOFHuR4GQWeFR xBSWd41qArjdABIxhZrnMICSW3fMyo9yfiQ6tXoyD1cHD/i2WmOnqCKEOtFScVeQJZJhqQb5 4NBx+viRax9d+X066AKYiBspm7kYwBVzNsng3uHOfyQXnVmcCEawxWIPyCtxSoV6fCKYdAfJ CQeElBXE89inkdGmdb0KLmYkHDoV4L1deAsPUI/t6qZjwqF3pKcr8kdGExqHwvytL8n1KGbY PyJ6Fn1z/idOOiTYgN+Q7FWRRX0QplyVpSBU4OnD0Gd3KkP+a0+kErokA1Lk3/YCE45VT8J8 8f4YGbRsIkf0xW+Ei0fk3fl9VPOrbTD+gFv+AzbT+Gp1+kElwVKj0VzXy0OC6UIQJ3J1on0l ArkcfPTIMcWxGmfGPw== Message-ID: Date: Thu, 18 Jul 2019 11:41:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-Sender: mailout@burnicki.net X-Virus-Scanned: Clear (ClamAV 0.100.3/25514/Thu Jul 18 10:12:59 2019) Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 09:41:17 -0000 Eliot Lear wrote: > >> On 18 Jul 2019, at 10:29, Martin Burnicki wrote: >> >> Hi all, >> >> Eliot Lear wrote: >>> Hi everyone, >>> >>> While the IANA does a great job at servicing our assigned number needs >>> and delivering the TZ database to developers, they is not set up, nor do >>> they have *any* experience, to handle the load that end clients could >>> place on them. Moreover, they are in no position to support millions of >>> people if something goes wrong. And make no mistake: something will go >>> wrong. I would be okay with a limited tzdist service for those who are >>> going to be distributing the data themselves, but the order of receivers >>> should be on 100s not millions. >> >> Wouldn't it be nice to have an infrastructure similar to what the NTP >> pool provides for time synchronization? > > > I guess I would want to see commitment from those who provide TZ service to their customers today to go to such a new service before investing a lot of money. Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any of the others want to use it? I also realize that ICANN is well positioned to fund this sort of thing, but it is not clear to me that it is right for them to do so. There has to be a real need, and those who really need it perhaps should foot the bill. > I'm working at Meinberg https://www.meinbergglobal.com/ and we are manufacturing NTP/PTP servers, beside related time synchronization stuff. In the past, whenever governments as of Egypt, Morocco, etc. decided to start or end DST just a couple of days before this really happens we get support requests from industries, telecommunication companies, etc., asking if our time servers could fix the problem to update the TZ data quickly enough. We always have to tell them they need to wait until a new TZ DB has been released, and then hope that their OS maintainers (Microsoft, Apple, Linux distros, etc.) pick up the new TZ DB version and provide a software/firmware update just to provide the latest changes quickly. Providing these updates also requires quite some effort for the maintainers, and it would be much easier for them if this kind of information could be updated automatically, which should also be faster than with manual intervention required. TZ data must not be requested from a server as often as the current time, so I think that even if the data size is larger than an NTP packet the overall load compared to NTP will not be much higher than for a server that provides NTP services, and if I remember correctly then data only needs to be transferred if changes have become available. So I think this type of service and its advantages just need to be made more public, to let the OS maintainers learn that they have less work with rolling out and deploying software updates if they just use TZDIST. I'd expect that a TZDIST pool could be operated by volunteers, just like the NTP pool. Martin From nobody Thu Jul 18 06:08:13 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 D286F12026D; Thu, 18 Jul 2019 06:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 BsFH-hiIUZpT; Thu, 18 Jul 2019 06:08:10 -0700 (PDT) Received: from mail-vk1-f173.google.com (mail-vk1-f173.google.com [209.85.221.173]) (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 C7136120167; Thu, 18 Jul 2019 06:08:09 -0700 (PDT) Received: by mail-vk1-f173.google.com with SMTP id v68so2037727vkd.1; Thu, 18 Jul 2019 06:08:09 -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=k5kHuu11dXSl+BJaZUHzW2S5XgXgxoDZtQYd7Rfm9Mo=; b=ucCcG3+uziUyWlFr7JYKsfkTtQq/D6ozCaN4OAnFTXndkhRlaOfPWFTgKqvxEH6IHs YvRGfgXwgwY2G3ga/B0EQz6kqXczIVts2Ywq5JcVPXR2QTO6mKl2onR2+X1Uj4HNPSd4 uCVXX8Tb+rUA6siKYfYU+EpxSYcR1H9xMmyCl/Y+3Pnx/jF7wqxYPL7ZQBTLWbAHb/Lb ME+oHdnHUb0OmdOPGeZdxlF6CCY7lCU7PiVXqW821ESFPvoybyiyAbvuNRvaA5kGNOti LnexGFTaatAYrqt3mYQMlVGWpIAiTycY6oNJxQZOGcqz49mxijJqlkfzGAg/y/O1EXHz gNEQ== X-Gm-Message-State: APjAAAVSsq8V7CQ2Ic43DeIr1hjfPt8a0/9Ybb3doQi6PTri0fqlD+Ka GnPh9AHGUVkS573tc8HK7XOz8Ofez6Md8D6dzx0= X-Google-Smtp-Source: APXvYqy/cJEKRieUSlJ+o2SnlZD+xymTczStl6Z4nc+2AdOr/BeDLrHkfC5f9xcVv95Nr4nRBYP3DwQQeMYPTPqPvHE= X-Received: by 2002:a1f:ab04:: with SMTP id u4mr18384011vke.40.1563455288437; Thu, 18 Jul 2019 06:08:08 -0700 (PDT) MIME-Version: 1.0 References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> In-Reply-To: From: Daniel Migault Date: Thu, 18 Jul 2019 09:07:57 -0400 Message-ID: To: Martin Burnicki , "tz@iana.org mailing list" Cc: Eliot Lear , IETF-Calsify , Paul Eggert , tzdist-bis@ietf.org, Michael Douglass Content-Type: multipart/alternative; boundary="00000000000016f296058df44d60" Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 13:08:12 -0000 --00000000000016f296058df44d60 Content-Type: text/plain; charset="UTF-8" adding the tz mailing in the discussion Yours, Daniel On Thu, Jul 18, 2019 at 5:41 AM Martin Burnicki < martin.burnicki@burnicki.net> wrote: > Eliot Lear wrote: > > > >> On 18 Jul 2019, at 10:29, Martin Burnicki > wrote: > >> > >> Hi all, > >> > >> Eliot Lear wrote: > >>> Hi everyone, > >>> > >>> While the IANA does a great job at servicing our assigned number needs > >>> and delivering the TZ database to developers, they is not set up, nor > do > >>> they have *any* experience, to handle the load that end clients could > >>> place on them. Moreover, they are in no position to support millions > of > >>> people if something goes wrong. And make no mistake: something will go > >>> wrong. I would be okay with a limited tzdist service for those who are > >>> going to be distributing the data themselves, but the order of > receivers > >>> should be on 100s not millions. > >> > >> Wouldn't it be nice to have an infrastructure similar to what the NTP > >> pool provides for time synchronization? > > > > > > I guess I would want to see commitment from those who provide TZ service > to their customers today to go to such a new service before investing a lot > of money. Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any of the > others want to use it? I also realize that ICANN is well positioned to > fund this sort of thing, but it is not clear to me that it is right for > them to do so. There has to be a real need, and those who really need it > perhaps should foot the bill. > > > > I'm working at Meinberg > https://www.meinbergglobal.com/ > > and we are manufacturing NTP/PTP servers, beside related time > synchronization stuff. > > In the past, whenever governments as of Egypt, Morocco, etc. decided to > start or end DST just a couple of days before this really happens we get > support requests from industries, telecommunication companies, etc., > asking if our time servers could fix the problem to update the TZ data > quickly enough. > > We always have to tell them they need to wait until a new TZ DB has been > released, and then hope that their OS maintainers (Microsoft, Apple, > Linux distros, etc.) pick up the new TZ DB version and provide a > software/firmware update just to provide the latest changes quickly. > > Providing these updates also requires quite some effort for the > maintainers, and it would be much easier for them if this kind of > information could be updated automatically, which should also be faster > than with manual intervention required. > > TZ data must not be requested from a server as often as the current > time, so I think that even if the data size is larger than an NTP packet > the overall load compared to NTP will not be much higher than for a > server that provides NTP services, and if I remember correctly then data > only needs to be transferred if changes have become available. > > So I think this type of service and its advantages just need to be made > more public, to let the OS maintainers learn that they have less work > with rolling out and deploying software updates if they just use TZDIST. > > I'd expect that a TZDIST pool could be operated by volunteers, just like > the NTP pool. > > Martin > > _______________________________________________ > Tzdist-bis mailing list > Tzdist-bis@ietf.org > https://www.ietf.org/mailman/listinfo/tzdist-bis > --00000000000016f296058df44d60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
adding the tz mailing in the discussion

Yours,=C2=A0
Daniel

On Thu, Jul 18, 2019 at 5:41 AM Martin Burnic= ki <martin.burnicki@burn= icki.net> wrote:
Eliot Lear wrote:
>
>> On 18 Jul 2019, at 10:29, Martin Burnicki <martin.burnicki@burnicki.net<= /a>> wrote:
>>
>> Hi all,
>>
>> Eliot Lear wrote:
>>> Hi everyone,
>>>
>>> While the IANA does a great job at servicing our assigned numb= er needs
>>> and delivering the TZ database to developers, they is not set = up, nor do
>>> they have *any* experience, to handle the load that end client= s could
>>> place on them.=C2=A0 Moreover, they are in no position to supp= ort millions of
>>> people if something goes wrong.=C2=A0 And make no mistake: som= ething will go
>>> wrong.=C2=A0 I would be okay with a limited tzdist service for= those who are
>>> going to be distributing the data themselves, but the order of= receivers
>>> should be on 100s not millions.
>>
>> Wouldn't it be nice to have an infrastructure similar to what = the NTP
>> pool provides for time synchronization?
>
>
> I guess I would want to see commitment from those who provide TZ servi= ce to their customers today to go to such a new service before investing a = lot of money.=C2=A0 Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any= of the others want to use it?=C2=A0 I also realize that ICANN is well posi= tioned to fund this sort of thing, but it is not clear to me that it is rig= ht for them to do so.=C2=A0 There has to be a real need, and those who real= ly need it perhaps should foot the bill.
>

I'm working at Meinberg
https://www.meinbergglobal.com/

and we are manufacturing NTP/PTP servers, beside related time
synchronization stuff.

In the past, whenever governments as of Egypt, Morocco, etc. decided to
start or end DST just a couple of days before this really happens we get support requests from industries, telecommunication companies, etc.,
asking if our time servers could fix the problem to update the TZ data
quickly enough.

We always have to tell them they need to wait until a new TZ DB has been released, and then hope that their OS maintainers (Microsoft, Apple,
Linux distros, etc.) pick up the new TZ DB version and provide a
software/firmware update just to provide the latest changes quickly.

Providing these updates also requires quite some effort for the
maintainers, and it would be much easier for them if this kind of
information could be updated automatically, which should also be faster
than with manual intervention required.

TZ data must not be requested from a server as often as the current
time, so I think that even if the data size is larger than an NTP packet the overall load compared to NTP will not be much higher than for a
server that provides NTP services, and if I remember correctly then data only needs to be transferred if changes have become available.

So I think this type of service and its advantages just need to be made
more public, to let the OS maintainers learn that they have less work
with rolling out and deploying software updates if they just use TZDIST.
I'd expect that a TZDIST pool could be operated by volunteers, just lik= e
the NTP pool.

Martin

_______________________________________________
Tzdist-bis mailing list
Tzdist-bis@ietf.or= g
https://www.ietf.org/mailman/listinfo/tzdist-bis=
--00000000000016f296058df44d60-- From nobody Thu Jul 18 06:51: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 71A6012027C for ; Thu, 18 Jul 2019 06:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 pEHa-Yhs-Mo2 for ; Thu, 18 Jul 2019 06:50:50 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 2715012028B for ; Thu, 18 Jul 2019 06:50:50 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id c202so9868203ybf.0 for ; Thu, 18 Jul 2019 06:50:50 -0700 (PDT) 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 :cc; bh=8A9s+coos82FpUUZ2Pkk8w9dqcSUA8Kz+XAdw3wcYPg=; b=YA3LoiOuPGlChc5aZAa45U/oRnzGsJZhfZGITv4DIZHMjBiPQ6hbxMCinzBbJ0b+wn LUyR66uDAkycWk/jZQlYqUBPPbYRjsY4OgeWYNHMQ8DdTH5Ue4OjvquQ0SpltSlvRbKM Ql/osi/EHvz+E8yWLE8djhWJDOnI3OIlItgGoWEQ7/nsSFrjW6gaCgOJ2KkGXaLLHkme mpbOQFimAtl8zg5wN13TnauE8DZtMgQo7s5XeaxHk09LxHOxCyvHCNTDujVgSu5EBGAN DYKgCspRn4zss3TjqUXXEL0Aj4cBty+ARRmyrRpUNGPsQaAd9etKTSPT+KWKQnTuL1k2 3pPw== 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=8A9s+coos82FpUUZ2Pkk8w9dqcSUA8Kz+XAdw3wcYPg=; b=jC/L0fiLxWBrbQ3w+tM379Ct1s/xsm7zhCJwpG/0btGUSVS3eKxyxPRRXdBDIzJKpy jV71WtJcKsWrwv01dL4O0DsB3ZmkSoGYIfOFS1o+6VtqErcZOO+pV7IoJbBgCMtbL8ov l/OTEYmIbf9idoQrWpGN8Konuws6lBJ8/e6WvpM6aYRjjPndgOpTYWAhl4kRCdTdIWfL g8n63aptaGoIO+1nw5XU7zkE1dAjWGAc0W7Goyxjqd2o8zVjUQ0lXUuyiQ5k1+BUWefB XlBCgDJ90GLG9qK4Cmc/4i1ZZIaDRlh2iF6y2QgnOySPCAtWGWlSdSKaWxK37Li45uH8 kdkg== X-Gm-Message-State: APjAAAXS4hnxPWI8t8CfsNXC9Cclw26hjPp3gn63/NQVU5HbLNPPXKGB rnUwQ1CVLPCvtguPgEj7dysKjpfSkZrnlqFEo/Y= X-Google-Smtp-Source: APXvYqy+vnCtP/UUXdiP+DE5Z5cnQ4GOFTI1g+ULCDioiRH10jxSza+uO/IE/YMzMfUPRque2nOam4m0ZpTNQKW9uzM= X-Received: by 2002:a25:ab12:: with SMTP id u18mr26894508ybi.357.1563457849013; Thu, 18 Jul 2019 06:50:49 -0700 (PDT) MIME-Version: 1.0 References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> In-Reply-To: From: Steve Crocker Date: Thu, 18 Jul 2019 09:50:38 -0400 Message-ID: To: "tz@iana.org mailing list" , IETF-Calsify Cc: Martin Burnicki , tzdist-bis@ietf.org, Paul Eggert , Daniel Migault Content-Type: multipart/mixed; boundary="000000000000b688cd058df4e599" Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA -- estimating the operational parameters 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, 18 Jul 2019 13:50:54 -0000 --000000000000b688cd058df4e599 Content-Type: multipart/alternative; boundary="000000000000b688ca058df4e597" --000000000000b688ca058df4e597 Content-Type: text/plain; charset="UTF-8" Early in this thread it was mentioned the the time zone database should be served in a fashion similar to DNS. My first thought was the numbers are wildly different. I jotted down a first cut at identifying the relevant operational parameters. Perhaps the people proposing this service can flesh out the quantitative aspects. Thanks, Steve --000000000000b688ca058df4e597 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Early in this thread it was mentioned the the time zo= ne database should be served in a fashion similar to DNS.=C2=A0 My first th= ought was the numbers are wildly different.=C2=A0 I jotted down a first cut= at identifying the relevant operational parameters.=C2=A0 Perhaps the peop= le proposing this service can flesh out the quantitative aspects.

Thanks,

Steve

=
--000000000000b688ca058df4e597-- --000000000000b688cd058df4e599 Content-Type: application/pdf; name="TZDIST Quantitative Parameters.pdf" Content-Disposition: attachment; filename="TZDIST Quantitative Parameters.pdf" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jy8qax6j0 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1nW2P5MaNx9/3p2ifz8nM7k67pX527OQSx7G9l9vzHha4 F7d5ZcQHHJAAib8/cL8/i6wqlaQZdc84AayRimKRLPJP1oN6/7F+v/7H+vOvf+7WP/683tr/f/6R R9tNv0/3+qPrNpfL9rg+XLab7njZr3/82/oPH9YP2812e1p/+HF9SK9yuWz36/35svrwt/XnHz70 62794af1/6zvPvmXe/6++/R+/dD167t/1fWwvvuM65nWX+l+ffdrXfbru493/AHZx/v7ldpfpdvX aubxG115HPeQGZu4j/aH+zV9bGi8rO9+BSu6+Fzvbo21vbO9X6eO7K5LjPyV4Oe3ibS/X/9l9eHt +psPZrxFlir26Q4HM9DaDbQyAyHc+sP/3ciyF8f+PDR5zVFjfNqtj7vtuj+tj9v1P/+6/u/1368f 91Ua96LNruvWu+MhlEmj3XbdbbfWd7ffl85Xtzpd1fn5os4f17tXpyiO1s9XfMrfkxBDC+DvO7mw fBWn6Y75srlf4ZG4s5pwr7+sb/ekbn94Wv8d8Sj9z8cX0h9/reO963fnsQtggD1KordCiIC2iCTq Dver6u5oJB/vnUhhRoSerjHLyCW7Pa7+qE8+hW7OUoM9qSwWbdHt4/251tYV2d6vhDTE9gmIu1+D WKAgUCQUxAwCQVo+S02QLfeGJ2Ts97uRjJ9lqdaSCmxU5zikbC4vzaLGYIF0At9bBJtKDeYq3bkf SXbBD4T2A5gN6A8MDky/eC4IzP/iBrMVDDFvGcnUItiOILcgegkAM9Ocmyg6kFRHWEYU/UZj0DFO ZoadBxIupETFxazANZptjBnIE8MK9VVDV2d13GcQ5Sbfdj/EWuT70gTAlyUAvqL+ATj6pffL/ZoW IoOxvUqSyrub8qKTIFPevfsqYarkAXYcYX+LGZJjLQ8tN0PlI6f9UX0OlW995PNvKaL+9+dxUj31 m8uB4ul4vmz6M+JvN/uz/WdFHv5pPd+uPE37brPf1e/3x40zsfbLZXMetDf8Sb+bXVcz6Pa7zaFP chgLlJvjkWQgizY8DpcNOKiukha77W6zm1YzsRDBUM7zYVMLQZBtto8pIoLDQJFzvzkcKz322HJ7 qlXNtkhCPELQDMZuuzn1MViHs/oZWnuOoNhyTNGaakzhtsqmmKMoiowpUi9R9G17FX39RZxfpujr L2dmBJchjN/9bnkFO8rZu343wRHIiJpYylgZiTYqI7M6N5eRE9ldKI9ewzAH4z6LfPhvgBuABsYt R5ORrvvjlPUaXa1qRVdK1krVBmE6yu1uzXSt31889rrjZiev3R03l+O6220uffIo5m07+x/R4n+t 8l/iAXz1gq+niiNHR5mPMqjOEReZr9+6+Zg0auZ39wnFTYziQt4V8m4pccc8KaKuZDkhbrc9TMn7 KUXZlcwreTvmtGN5n8eSUm7MknlzSBmJZ8Idtv3muFfCNPzCHfC9f/519ZNNXKd8rGSv8JLiL9Vf C5YIRn4v9zhG7efeQXDh+IqpX1czfntAAvcgW71fIO7SlYuRWF23PRe5fL2ize02iSIcmURV4Xjj qknlLpo7jRBn1LkMp84r2CvjdLviqqTGMN4AUThXNVtfbYUXuWoh/4A/VVWTACdXLdE+V7VEe87U KX2VqiUIHqlagiTzSDKUqiUI5quWoGhYlKolCGarliDIHDzb56olCOarlqDILNyWUUFGPFt7f9oc Uxe5Ahy1hx2i9JohKMXbiKAokWqzEUHqotQjMwRk8BUT88OZWuSkFZFby5GUgFYlilSOBK5E/P6+ wONTSWeECCpGWn5NVKgUkSYqRYaqrG5YRp0pRfpRIfIHn6XbJG9997XNdBCN6SFTLWZfTLVs+TQ9 2x9s/qX/rmxixjzfp/Raw7x95el4piwZSteClpKLLEQBMzTQVevMo7FREnlibITV6hmsHvZ8y9AU L7PFi9z1eNVWFaoKSOu69YrnKZ3mvE253XjkBE6vt6sap4lLW7pvsSVml9E+h9PRnt9vcToIHsHp IMk8Ap9idhkE8zgdFA2LgtNBMIvTQZA5FIhLs8sgmMfpoMgskh6RE/EB5teRE7s9RdgQqCcIwhKO 1LMUGaonKIoihtUTFKmXDNazFO9XtmNwONnkkaL2GWi9YqeoxJHQ+iHXgYHXf3wmXo85NvFhiI02 htihzktPHpFiiIrUt9dg9nJIdmC0pURAqZ6GHUDekTkQ5BsWWVmTY3Gd/9qqHdfXrI/ZIvCz0sHl oB6Hqk8mBAZACSHs/wJVrBLCSNu2b0sJ9K2UEH3fPPbFlS0lPKm4JQV1TlKIzl9AcUsKT2o+kRaG 5bsQYPtI+Z7bZ9JCbs9Q2KSFTDCfFjJJ5hFg6GkhE8ymhUzRsMhpIRPMpYVMkDkUNLW0kAlm00Km yCySHjkt8EdJwaSFs6+dRv0O3LYEYYlIC3MUJS2MKYoiKS2MKVIvJS3MUURaYDH02UX8RFro+nYn +U/PzQtjllOJAX2qUn51w874aNNAYc9ZhXZ3+svlCo1Y7qlnJ1gyG4iloKfmOs7S0gam/rGaRe33 nTEflpnkja8/ps3btIedlj+VM04YskpYrCYuPTHS7C0dQEapFT2n2pqev/TNJNsCYxeHBMZ/06YS y0P8HS1OiETkNBYckdLWbJn3aJ/s2jXbkeXPLKNOWL5xJZvz4Eq/wJynts/0IQvLcXReT3teLMeN /bhR3ZKcev8FZj5P6/50ljt1LH1GQW7wbJs5sUh1iPa5LBftGdnbLBcEj2S5IMk8AtsjywXBfJYL ioZFyXJBMJvlgiBzKMkhZbkgmM9yQZFZNFnuUFcUU5OfMUFYIrLcHEXJcmOKokjKcmOKNsvNUUSW AxF/kSx3ZvO/Ph139+1yBB+tiGi1irNwLcsmPm36gz4vk+UsfzQonvIdFc1AtQrFWa0CsbXMzyWh sx07Ia84fDM1oSmB+DdayVo55PvZgnjpFkgf2e20UzJ9ym4G6dithvQXQFWbtdD50FiT0xY6ryH9 JWYO2nV4WnWDdPWeIf1F6qI0b3lS9wlIZ6ejWs86HI7sydeQngAgQ3q0z0F6tDcwlvcdcgcVpKcu 8g5/Jml45H2HTFAgPYFQBWTTahRIDzlnIT0IGiEYv3RaIgtRID3pUer9GRZMA+zkymHP+d/helaD +RDsB7NIH4yKwbDd3/fFR3Vg7XODNRYgdZBnTsGgMUIZzSCoRjPJUEZzrpMBxZQaZbyjl/nxnuuk eETwaFQpHhEEsx4x20ccK8n2bvvIPpP7mDthM+ETrVcFj6aT4nYzBMR+v1p+FKEsyOgg9EN/4OBB lV5XNaxeM0FqTp4Z813XLHOR4D7h5Fl1epH8pQOVtsLGlsx3qfGi45as/1iu47yeUa3SsT2lRT/A 7tScabTz7UqMQexJE5Y26yFtek+WFs+r9oy8v+unJcmtlYx+5wzs7CBCXPy+15FQ+Mfz1EE6ckj3 sVMfQobsQT4UmgO/mn/Fqc3GDPlEvXUoTn4umqK/KBwv+wn+6DBMGwKFAI1ak8PztQ4GyvDUIzJM 8HRzBatQPe6DLO7D9o1aLkHSzu1B/WMdeYfBeUDTIRUWHg5d9NUMu/b6NGiJAT1Wk3GOajw2Gfdi aGLfMTk5+7R1BOnzjY/39MCsP53Ypk+dFr7IUZAhPUxbkJLSVUhHuZOj8irzcqOeOQK94q3Ux5CF 95WPK1t0+cMB/ffwpzN5L6xkNV+sQA5KxuXmGU3/Lz214u70yAHQa3ClWXi57E7GfGTyMwbFuKiK HmiKGkeLOZQ0P+T66tUbjYH++q3MmynNaRiir+RLGJ/3Hziyl19MXNkalg99Zc4IE20HaGD9JW8O Xh9dlsIycE79az3IukhiH3WwnI5TRyFvsIoOE+2raA71krbpVettpc3uhx7RZlajNCdAChftVfRj MYNR3ubx5zTRwsGq8gof7YzH6JbEUvFUrtrv8qcE4x3lhWISxXyEM9gCsijeX2LtkcXN6iMsnOBT nImh4VgagcJJsuQ1/M3nV8vDZDSlkjYPdOue7N0axMYCZZT1UVnuj5yJ3lLFcwBZZ4FPfSoiVAJc cRqxMSsVLzKsyvdncv8QYaFZbY47VQIcu9Nw2jZZAjzDjLv9Fl9mgAYYfPfvy1Wo8L3RYHdklXfE Gw3qz5WEm8SeUOUFP1c6oJG6Hhrv7s/L1Rrh8kET2THLGwdbCxrVgvhhr53Fdhgw1QHQwkKGVVx9 ReOqDOMDlNfhq/3x44kgmur2VQLFQM5ANmoiUDjwLuFporQiz7K00ohj+UdbEJ9ASt65+qtGFRDK ZpX43ZYls/GYYLbX+kAj5RYW6elOlS1SATsyoZpwOoG4fA/DguUQvkrfUL32F1DQK47Cy+mVRHjt tSwEF6ekoBOlNa5s0GiTgZROq7bcrbNhPLMMr5Mo3o8sz8YCKcW/sBEr5wikLo/85M+Vy3UnOxzR +tzdfyyPkSr020+Mzsg56VkPqOdGQWXqyg67q67ggpcjjtmNu0SIY4lCKkMvc3MnO5eH+CM3GnEu gEhif61pSAjbLd8Z1A7Wc2B32sF6SYKnc0qf4leyprpnea+PhKWl1OOpWWbFrc94Bb2lwPMqZBiT VQmGoyCWyiKnjMInonpYAKWoXt19lfrwV+OdUylqFn+IXDnbidnow0gjjerSTOnmapLvadd+GXI9 y9nke+bg5SAtMgLj+bdGfHXb59mWfNteVtckX89SE5MrS77wHmZANJj7VFaOZZ4BgKU51vhT2dVy 9x7nT74ReaiU9Rr0z8tdYMRSmUsshzpe41XOMu8xVC577Mn3lby5rp1NySplQCZQASfcrfK+g2XP 9PRq+9nIrgagdN6xCTMl2Md7ek/gR9ArgIEAdV5mqDaBY4C7dmyR+FrZVlOBwwcORPqUdBdfQ6An yWVwg1FswSSdGC6LT/ifLV/4QhWItFy4Kik1M5WuP89arnNzSayE59oRUhLGWm7DG2xkSaWZg3d7 TiROmujdoGpRkqNzelXOLxXNyjOfD26SlmcSlhutXVgeVFL0Z87Dion1ndYusLzWLqD3eiOVIE4I DoiV0/vDROEVi9IywmE1k+Z6YJhyHst752M3jGcwa+6b7ezaUwt4lrpYqrQ0RwiQwWxRFHXkgH75 T91hjUSdjCPdfb1PbhF+WVZQzWlTiEWjhb45ra+5KenS65AP4+GW14THRXjnIhj68koIHFcnG3Ly h7aIEmHUSqTxUz+hm4tU61QaYyE2M052mVRV9T02ivXMpFX6r5j3l9ECsXMdB3ZlesS7KcybM6nd CZ0fcKNR8t4ouhUbCgsPH5DyBwIBsyNiGi8eSTMuTp9akN1hVUtDzgLziByggp8oVhY1PEsvaUxx ERgtV22U5/qOD8Gk0TAwrinVnedkjbsXHI2Y9yiwtDir02iDdhbTF1a/20rqO3kKdjInFQ5xG3hX 7lj1xUMQBfOaG+PO8UZc22lmog5+URF/zygr0FOrxRzDyPjQd1TCcU0075FI0RP18xEE8VG8ZWHv zEr3w8gSyLO60sxNDXwhq7lxb17Xm0Xjbrsf/w7DuAgWoP7GBikwx8yPuQPUDHtWGYqi2bFouEfE uUWDF0//DS2Do9zc1BM7PWUoHa8C8kiiAmVbr2YsvTtjkZYpmFxfAmgDzxwn7d3kMdIvNAkNYbI8 ph+pSrZnHYbEzjGKudKcKejqLQeEWi5EFab6or6e6Xa9QHNytKkVZUSCRQPhs92HHov8oPtIgOCq 0F1jICurnZ+ksZDWmOh5ZhSEMiVltmLyQZN3pbgBYRBofV8c5SciiBeYCVtQa6jiOeWxbU/qPtpD ciS5ZeGJZDG0li1vTFrrDaIo5+JxDjZgHA4laNMqEdoqUXKHlZLttOZheRyBETAytt5wZqgrItnP IXL5oFee1yyfGTSzwsHjagtbG3Dv5OsoocDg4sWeVhoYA8WSBpMUKWFQg1NhUSsyYJJfnpF+mUVv SG7e0GBykTLE72tZw00EjRR3E/HwnRFhFn9MJ/ThD/EekZo3dUer0pebo0qEzaCe+fb9QeZosuzH e4bvSohWnlVZUs0nL/x4nbEfWXumLEFbnOUdRkN1TdzwFgbkalVLumByJqgZqwjbKxWsmV6m7Yb8 VzKdmoYjLWvUk156wDnwFfMD/IpY4c6QnisekzzwZaYmXa/NjLHpNDlp9uMV3o5QXsdwG8nDU4uk o0h++7zhZENrSibFyZWWL8PpoHA8NlFwPc+p0Uzce5btE+SU3cKP92zVa8TSMD5vc3B3VDIbdWOY FZZpdwf7i36niN1BjoVxUvOltgdZdNASpfYHp/Yon7FByG+voCQ/g9SM1O/wqlByIfsy/LujUKow 5Tym/bJK9RMgC3lOrEnuLZQLc/8gkxia+NUbn6MvhztPdOZ2TXWjfWLTaoS9b5SUlJTxb+Gs1ZrU hECLcpXiVBnMWxW9JfWQg0Cb2wRsUvEpLDMSkDMX9ElKNcmU9u5OftoBoRCNNAq+nNNNEMWkJz09 GUTWPFTRcf8dDSv9YVZI+i7Xx1NpcZ6uOwqrRwN8AyDhPaOiqzv5KA4dHveJokvqUidRRspi398w OPLaZmy6XhM3aTUaHF87qwsbDchKdQ1pwCtSOdB/YXAVfcPCyksgyUsb8mquIqa5onp2jjho2f1F hiTPEauiJmHQXkNVl5B3v78CgzxuixslDCpMb8CgquhtqryEQYV5waDq4+kqBq741Kzxm5Sdq57S 7Bx35Ss3AQue+sp3yjX0UQxbSBsmeVDvacSdndQuacEcBhG4XCuhyV6PHckrNbCMUw3nmbBhHtUO JyL/oNBCCEOjNC/x+p6HHJfSaVNmBCs/dZpmOToD5i+gL8+QMoGpWKmM563Uomjx2RBN4OyLTNO6 E9u30mcWMWwWQ48AJ/9FljIli9mag4qUhMSUTKSWGVTtKa7TqyhIBPsbUjAzdTpvSnTgON0xoD5V VR6i/NFLmnJx+YFL5ueEmhLRlKY/dO2cBeVCEaeqFQoZ2azO8gwkTcTOWJrYcTNB6RduBfUm7i4X aix3tzoxN0eEPBr5Yn2AHzhcOYbLCHr261NexsLImJflPQiSZnoqddM+iPtXeYjWlkzf3l8/LSgA pR99xK2K1C+67pYw9bBrT4D+8QpMHaXmhKmF6Q2YWlCj/aXiNIqF+SSmahSJIXkuKwc+WjzD4bnB ayk/BIPc4F2so+N5honsG/ozflfC1gFi+QhnpKXeyrzaKVVnDNd2zjtN9FBm6JKGgEvL6vn0c9bh zjF3HJ5lNlefcgC15OIW+9d7qmXqJhvxcYpqs6lB+k5dVbkkikhhlWGxxsRpDHW4tUCiTm6O6epc Lu9EzerHyD7ayqBgsq5EbxkrW1SpT4Dt+V5t2p4biYhWSASs4jL8zcaPLWGlZ2QZZMXNwAy8kHZp ziQAILxFuMaRKFfnZItsKqxO/Vn+BMGX9+vhODXd6c784O70WG9z2qBvjasNdjXT2WrsNFT6/VHl JfND7GT7g1gS25WJUlpvr6hoXa5CCZO21ndEYTbe5oXZhLRSuvJs5UkUYfRwlN2yEpH9PVN7cotM mt5D/1ITpKz5xgkHTd61Tjlgj9y1TqNViTW3JE5EPMTp77o7uSZjAOJX1lxWipY01XX2Ywf66cWB FRHu2i2nXPtXsZfy1PHQrpf+CamXAuVMnipMb89TJnJzzDa5FdyHBgF94+cfyFDUDvILLgZjjA8F hSHgSutTjD1NjC+BG28JalS+40f8F0/gJXyQv6NFUZQKZltksC2cYK9VBV5wkh/EC6IXiqSLfbI9 pXIzaXaXe/MFO6643hdIp2vyzeTpXloOg8xjIdEhPFBRRF++Tzo58ean0CnXbLiqA/YMlzYoBE6+ QeGX0u+CM4oFfEYT/p2Ofnm/w39YZrQfofC86vSf3JIhGW4n7W1voHh9KaAOhtfadLOiB/zNDwTg GiG5ER9DGJJrM01VxG5rFbz9mD/DZTWvkClWuhwWbfMNdMrf//HDKBo9e0+uu8OFbe+N50SBJQQ7 YMQoy19FH8+DPt7PghIJ1gGectOsrjEWXwnDb8pYkVYF5wiGgJgD8TSzFAbzTEJxB0UFrE9MlytP adYVOR885yk9oTBewlwG4ROxkJBLJ1scyvNiwtAl5QxglZTGJRgKLT7JHgrp1CYT0Ib7YB1sxElF Yp8n+jtNQCHWGXi969TOUKGPS1jehIiR9UmhLYv6BuFQIufDYXWVDf6GL5w5V3+Y+n/9No3NVVFV Jz1962RngHLSW+m3wZHjyqw0n/ROp/bLkm+R+kr2ReY0OStMf4mkB/dwHSA6/TNZkb4WJb3l8TJK 6gf2UxiSkdFuHJJmY/Vw0T7IlH7+K4QqcSkDFRpKrEq3XPC2VKjp3wh6NyRRpIg0rggKERBS3osm YouHiYASGWzx7vBtOlWk0K7MmVv8WSLIYqgHf1UdpRU+niXWAnvBGAEIihEwMLV9R6LQWSR+QuGI 21Sn25eRoXz9fuJsMA03Zp38N7W7hC5OorMbW4CBrEhtqSXJ4w/9AtoXwnSTGCXLZf0qLa52Mc3e WdsbHGS5pPifcPcvUo2CFNVUgayo1TQe3pTK2y9GEk6fd82vrVCybGUXjQy2kOPJxrpiO13iKeBM 9s6PNe4ccVBOl5igzNVGKjhzPCgOR8LdAI2FZ9rRPV+af8niBXhejrGzGRun1//rDsqkpMzaQXo7 AzFizgjZx1wMEB6pMGa8ltvaa4Ril53tu9CNo27ooGGPRNFuQXcdv7KuD1R3+w3/UMBLbUH3W45O /SJb0Db4/fb8sr9TYVhFbWJQlmJTldR7YoCnFjcxs6JVuORbJ6IyOIOMgNYpQRW9EAdLMHL+VTs6 AsfoQQGLIyQx0rleh4q6o6b/uFVVTVfOw6SxssyexVmeXHfTjeGgV6jSU7gAcfBzDqRqPQ0R0dam kg1xqBsvh1G4h3O0Ro9ZRk7rpXmGehAQQZwsFnfKnTz0N4K932bjXo2kCtP2C8KjvpKY9K232CKq W5CT7TESLfipjO0Xp1C5ikkRTIiv8hR6dOCGJp/N6zWZhIuSARfQFkM4D6kOvXlBzhP845nLp7ZW RzbLsSly+H0gD8wy43sla9KhX9jst9vrPsAbwdGemSInKNt/qa+G6ff/Dy4F9boKZW5kc3RyZWFt CmVuZG9iago1IDAgb2JqCjY4NjYKZW5kb2JqCjIgMCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVu dCAzIDAgUiAvUmVzb3VyY2VzIDYgMCBSIC9Db250ZW50cyA0IDAgUiAvTWVkaWFCb3ggWzAgMCA2 MTIgNzkyXQo+PgplbmRvYmoKNiAwIG9iago8PCAvUHJvY1NldCBbIC9QREYgL1RleHQgXSAvQ29s b3JTcGFjZSA8PCAvQ3MxIDcgMCBSID4+IC9FeHRHU3RhdGUgPDwgL0dzMQoxNCAwIFIgL0dzMiAx NSAwIFIgPj4gL0ZvbnQgPDwgL1RUMiA5IDAgUiAvVFQ0IDExIDAgUiAvVFQ2IDEzIDAgUiA+PiA+ PgplbmRvYmoKMTQgMCBvYmoKPDwgL1R5cGUgL0V4dEdTdGF0ZSAvQUFQTDpBQSBmYWxzZSA+Pgpl bmRvYmoKMTUgMCBvYmoKPDwgL1R5cGUgL0V4dEdTdGF0ZSAvQUFQTDpBQSB0cnVlID4+CmVuZG9i agoxNiAwIG9iago8PCAvTGVuZ3RoIDE3IDAgUiAvTiAzIC9BbHRlcm5hdGUgL0RldmljZVJHQiAv RmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAGdlndUU9kWh8+9N73QEiIgJfQaegkg0jtI FQRRiUmAUAKGhCZ2RAVGFBEpVmRUwAFHhyJjRRQLg4Ji1wnyEFDGwVFEReXdjGsJ7601896a/cdZ 39nnt9fZZ+9917oAUPyCBMJ0WAGANKFYFO7rwVwSE8vE9wIYEAEOWAHA4WZmBEf4RALU/L09mZmo SMaz9u4ugGS72yy/UCZz1v9/kSI3QyQGAApF1TY8fiYX5QKUU7PFGTL/BMr0lSkyhjEyFqEJoqwi 48SvbPan5iu7yZiXJuShGlnOGbw0noy7UN6aJeGjjAShXJgl4GejfAdlvVRJmgDl9yjT0/icTAAw FJlfzOcmoWyJMkUUGe6J8gIACJTEObxyDov5OWieAHimZ+SKBIlJYqYR15hp5ejIZvrxs1P5YjEr lMNN4Yh4TM/0tAyOMBeAr2+WRQElWW2ZaJHtrRzt7VnW5mj5v9nfHn5T/T3IevtV8Sbsz55BjJ5Z 32zsrC+9FgD2JFqbHbO+lVUAtG0GQOXhrE/vIADyBQC03pzzHoZsXpLE4gwnC4vs7GxzAZ9rLivo N/ufgm/Kv4Y595nL7vtWO6YXP4EjSRUzZUXlpqemS0TMzAwOl89k/fcQ/+PAOWnNycMsnJ/AF/GF 6FVR6JQJhIlou4U8gViQLmQKhH/V4X8YNicHGX6daxRodV8AfYU5ULhJB8hvPQBDIwMkbj96An3r WxAxCsi+vGitka9zjzJ6/uf6Hwtcim7hTEEiU+b2DI9kciWiLBmj34RswQISkAd0oAo0gS4wAixg DRyAM3AD3iAAhIBIEAOWAy5IAmlABLJBPtgACkEx2AF2g2pwANSBetAEToI2cAZcBFfADXALDIBH QAqGwUswAd6BaQiC8BAVokGqkBakD5lC1hAbWgh5Q0FQOBQDxUOJkBCSQPnQJqgYKoOqoUNQPfQj dBq6CF2D+qAH0CA0Bv0BfYQRmALTYQ3YALaA2bA7HAhHwsvgRHgVnAcXwNvhSrgWPg63whfhG/AA LIVfwpMIQMgIA9FGWAgb8URCkFgkAREha5EipAKpRZqQDqQbuY1IkXHkAwaHoWGYGBbGGeOHWYzh YlZh1mJKMNWYY5hWTBfmNmYQM4H5gqVi1bGmWCesP3YJNhGbjS3EVmCPYFuwl7ED2GHsOxwOx8AZ 4hxwfrgYXDJuNa4Etw/XjLuA68MN4SbxeLwq3hTvgg/Bc/BifCG+Cn8cfx7fjx/GvyeQCVoEa4IP IZYgJGwkVBAaCOcI/YQRwjRRgahPdCKGEHnEXGIpsY7YQbxJHCZOkxRJhiQXUiQpmbSBVElqIl0m PSa9IZPJOmRHchhZQF5PriSfIF8lD5I/UJQoJhRPShxFQtlOOUq5QHlAeUOlUg2obtRYqpi6nVpP vUR9Sn0vR5Mzl/OX48mtk6uRa5Xrl3slT5TXl3eXXy6fJ18hf0r+pvy4AlHBQMFTgaOwVqFG4bTC PYVJRZqilWKIYppiiWKD4jXFUSW8koGStxJPqUDpsNIlpSEaQtOledK4tE20Otpl2jAdRzek+9OT 6cX0H+i99AllJWVb5SjlHOUa5bPKUgbCMGD4M1IZpYyTjLuMj/M05rnP48/bNq9pXv+8KZX5Km4q fJUilWaVAZWPqkxVb9UU1Z2qbapP1DBqJmphatlq+9Uuq43Pp893ns+dXzT/5PyH6rC6iXq4+mr1 w+o96pMamhq+GhkaVRqXNMY1GZpumsma5ZrnNMe0aFoLtQRa5VrntV4wlZnuzFRmJbOLOaGtru2n LdE+pN2rPa1jqLNYZ6NOs84TXZIuWzdBt1y3U3dCT0svWC9fr1HvoT5Rn62fpL9Hv1t/ysDQINpg i0GbwaihiqG/YZ5ho+FjI6qRq9Eqo1qjO8Y4Y7ZxivE+41smsImdSZJJjclNU9jU3lRgus+0zwxr 5mgmNKs1u8eisNxZWaxG1qA5wzzIfKN5m/krCz2LWIudFt0WXyztLFMt6ywfWSlZBVhttOqw+sPa xJprXWN9x4Zq42Ozzqbd5rWtqS3fdr/tfTuaXbDdFrtOu8/2DvYi+yb7MQc9h3iHvQ732HR2KLuE fdUR6+jhuM7xjOMHJ3snsdNJp9+dWc4pzg3OowsMF/AX1C0YctFx4bgccpEuZC6MX3hwodRV25Xj Wuv6zE3Xjed2xG3E3dg92f24+ysPSw+RR4vHlKeT5xrPC16Il69XkVevt5L3Yu9q76c+Oj6JPo0+ E752vqt9L/hh/QL9dvrd89fw5/rX+08EOASsCegKpARGBFYHPgsyCRIFdQTDwQHBu4IfL9JfJFzU FgJC/EN2hTwJNQxdFfpzGC4sNKwm7Hm4VXh+eHcELWJFREPEu0iPyNLIR4uNFksWd0bJR8VF1UdN RXtFl0VLl1gsWbPkRoxajCCmPRYfGxV7JHZyqffS3UuH4+ziCuPuLjNclrPs2nK15anLz66QX8FZ cSoeGx8d3xD/iRPCqeVMrvRfuXflBNeTu4f7kufGK+eN8V34ZfyRBJeEsoTRRJfEXYljSa5JFUnj Ak9BteB1sl/ygeSplJCUoykzqdGpzWmEtPi000IlYYqwK10zPSe9L8M0ozBDuspp1e5VE6JA0ZFM KHNZZruYjv5M9UiMJJslg1kLs2qy3mdHZZ/KUcwR5vTkmuRuyx3J88n7fjVmNXd1Z752/ob8wTXu aw6thdauXNu5Tnddwbrh9b7rj20gbUjZ8MtGy41lG99uit7UUaBRsL5gaLPv5sZCuUJR4b0tzlsO bMVsFWzt3WazrWrblyJe0fViy+KK4k8l3JLr31l9V/ndzPaE7b2l9qX7d+B2CHfc3em681iZYlle 2dCu4F2t5czyovK3u1fsvlZhW3FgD2mPZI+0MqiyvUqvakfVp+qk6oEaj5rmvep7t+2d2sfb17/f bX/TAY0DxQc+HhQcvH/I91BrrUFtxWHc4azDz+ui6rq/Z39ff0TtSPGRz0eFR6XHwo911TvU1zeo N5Q2wo2SxrHjccdv/eD1Q3sTq+lQM6O5+AQ4ITnx4sf4H++eDDzZeYp9qukn/Z/2ttBailqh1tzW ibakNml7THvf6YDTnR3OHS0/m/989Iz2mZqzymdLz5HOFZybOZ93fvJCxoXxi4kXhzpXdD66tOTS na6wrt7LgZevXvG5cqnbvfv8VZerZ645XTt9nX297Yb9jdYeu56WX+x+aem172296XCz/ZbjrY6+ BX3n+l37L972un3ljv+dGwOLBvruLr57/17cPel93v3RB6kPXj/Mejj9aP1j7OOiJwpPKp6qP639 1fjXZqm99Oyg12DPs4hnj4a4Qy//lfmvT8MFz6nPK0a0RupHrUfPjPmM3Xqx9MXwy4yX0+OFvyn+ tveV0auffnf7vWdiycTwa9HrmT9K3qi+OfrW9m3nZOjk03dp76anit6rvj/2gf2h+2P0x5Hp7E/4 T5WfjT93fAn88ngmbWbm3/eE8/sKZW5kc3RyZWFtCmVuZG9iagoxNyAwIG9iagoyNjEyCmVuZG9i ago3IDAgb2JqClsgL0lDQ0Jhc2VkIDE2IDAgUiBdCmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9Q YWdlcyAvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXSAvQ291bnQgMSAvS2lkcyBbIDIgMCBSIF0gPj4K ZW5kb2JqCjE4IDAgb2JqCjw8IC9UeXBlIC9DYXRhbG9nIC9QYWdlcyAzIDAgUiA+PgplbmRvYmoK MTMgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvQ1RX R0hCK0NhbGlicmktQm9sZCAvRm9udERlc2NyaXB0b3IKMTkgMCBSIC9Ub1VuaWNvZGUgMjAgMCBS IC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDQ2IC9XaWR0aHMgWyA1MjkgNTM4IDI0Ngo1MzcgODEz IDUzNyAzOTkgMjI2IDU2MyA3NDUgNDk0IDQ3MyA1MDMgMzQ3IF0gPj4KZW5kb2JqCjIwIDAgb2Jq Cjw8IC9MZW5ndGggMjEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AV2Ry2rD MBBF9/4KLdtF8Nh5tWAMJSXgRR/U7QfY0jgIalnIysJ/3ztKmkIXZ3F0NZJmlB+a58bZqPL3MOmW oxqsM4Hn6Rw0q55P1mVFqYzV8WppTY+dz3IUt8sceWzcMKmqypTKP1Ayx7Couycz9Xwva2/BcLDu pO6+Dm1aac/ef/PILirK6loZHnDcS+dfu5FVnkpXjUFu47JC1d+Oz8WzwotQUVyepCfDs+80h86d OKuI6up4rDN25l9UrC8V/XDdWhZ1JRBt1nVWlSUUEO0G0TUUQLXoBgqI9lvRLXSXUiO6hwKk6agH KCAqSdJHKCDalqIdFGDzXrSHAlxUiGooQLoTNVCANN3LUIB0k5r87Ub6lX+5zVGfQ8AI0+el6crU rOPb//rJy5QSPyeZl2sKZW5kc3RyZWFtCmVuZG9iagoyMSAwIG9iagozMDYKZW5kb2JqCjE5IDAg b2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL0NUV0dIQitDYWxpYnJpLUJv bGQgL0ZsYWdzIDQgL0ZvbnRCQm94ClstNTE5IC0zNDkgMTI2MiAxMDM5XSAvSXRhbGljQW5nbGUg MCAvQXNjZW50IDk1MiAvRGVzY2VudCAtMjY5IC9DYXBIZWlnaHQKNjMyIC9TdGVtViAwIC9YSGVp Z2h0IDQ2OSAvQXZnV2lkdGggNTM2IC9NYXhXaWR0aCAxMzI4IC9Gb250RmlsZTIgMjIgMCBSID4+ CmVuZG9iagoyMiAwIG9iago8PCAvTGVuZ3RoIDIzIDAgUiAvTGVuZ3RoMSAxNDc3NiAvRmlsdGVy IC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHlm3l8VEW2+Kvuvb3v2TpJZ+nOTXcSOunOvkBILtnI QkgCaUmAQEIAg4LBQNgUwXEBo4iOiqOOwriOotJpUBtFQcVtcBvFfUMHRxmJouKGJv1O3dMJi+Pv 92be5/fmj1/T537rnDpVt+45VXVvd5rlff0LiI6sJzzJ7l7StZTIr/QoQH73iuV21GNLCVFuXLj0 7CWoJ+0nRBN59uLVC1FP7yHE4upZ0DUfdfILsLAHDKjTfGBqz5Llq1BPextYuri3O1yfXgu6fUnX qvD5yftMP69ryQL0L7kGmL60b0G4nrYREvOxGSt/42gkhEKVSaggVmomasIRM/GSTkL0P9JyIkAt q1fm5V1zjWnvXFPpdyROLff12BcXvsgKb2wZ6P753eECbby6GXw10AO+oJ3qtuF3CdFu+/ndE5dr 4+WewpUyTAEN/8WkRL4Saibwk+B4JZ9NbgHhiMB7yXyQ5SAHQQQ+ix9Hikkynxmmmx8XKE5O3Qvq nSC7QPjQPjCKaTW75UKCvWZSN19KivkJxMePB5YAi4FFwEJgATAfmAcUgSlAB9BOfMTNSzCic9mR n4h1oE0AWyqfQ1pBOLmUH9aOAwUSxaeRKpDDIDyMOg180LIceCnI9SAHQY6DqGHoKdBjPpyRQls7 eNuhvR36t8O126GFnSi5nwJJiclB7sdAkhvwQyApE/A94jvEcaz7FrVvEF8jjiG+QnyJnkOIo2j8 AvEPxBHE54jPEH9HfIo4HEjSwCD+htoniI8DiRFgPBRIjAN8FEj0Aj5EfIB4H/EeuryL2juItxFv Id5EvIE4iHgd8Rrir4hXEa8gXsZBvIR4EXEA8Rc87Qvo+TziOcSziGcQ+xFPI55CPInYh9iLfT6B eByNexCPIR5F7EYEEY8gHkY8hNiF2IkIIAYDCbkQQT9iRyAhD7QHEQ8g7kdsR9wXSMgBl3sRf8Z2 9yDuRtyFuBNxB+J2bP4nxDbEVsRtiFsRf8Sub0HcjM1vQvwBcSNiC+IGbHc94jrE7xHXIq5BbEZc jV1vwuZXIa5EDCCuQGzEBhsQlyMuQ1yKuATxu4AtH+JyMWI9Yh3iIsRaxIWICxBrEKsRqxArESsQ /YjliGWIPsT5iKWI3kB8AQziPMQSxGLEuYhzEIsQPYizEQsRCxDzEd2IeYguRCdiLmIOogMxGzEL MRPRHogrgpG1IWYgzkL4EK2I6YhpiBZEM6IJMRXRiJiCaEDUI+oQtYjJiBpENaIKUYmoQExCSIhy RBliIqIUMQExHlESiC2B6ytGFCEKEQWIfEQeIheRg8iWwdNArAd68aLRg8hCZCLciHGIDEQ6Ig3h QjgD1gnQWSpCDFjZQk8JWMcDHGi0I5IRSYhERALChohHxCFiEVZEDCIazxCFZ4hEYwTCgjAjTAgj woDQI3QILUKDfaoRKjQqEQqEgOARHIIiiAwaQowghhG/IH5GnED8hPgR8YN8Wvq9fEX0OzQeR3yL +AbxNeIY4ivEl4ghxFHEF4h/II4gPkd8huf7eyBGTA7STxGHAzGwcujfEJ8EYopB+xhxKBBTCdpH gZgqwIeIDxDvB2KqwfheIKYG8C7iHcTb2PVbiDexszews4OI1xGvYWd/xXavIl5BvIx4CfEi4gC2 +wt2/QLieRz8c4hn8XzPBGIqYGT7scHTeKKncNRPYmf7EHsRTyAeR+xBPIZ4FLvejV0HsetHsOuH EQ8hduGJdiICiEE8rR+xA/Egdv0A4n7EdsR9iHsD0bDr0z8HoicB7kHcHYhuBO2uQPRUwJ2B6CbA HYHoaYDbA9ES4E/osg1dtqLLbehyK9b9ET1vQe1m9LwJ8QdscCNiSyC6Gfq8AZtfj7gO8Xsc0rXo eQ16bkZcHYhugXab0PMqxJWIgUBUG9RdEYhqB2wMRM0GbAhEdQAuD0TVAy4LRM0CXIp1l6Dn79Dl YmkHuB4zVSd/ZaxNPqSfmvwUyJMg+0D26s5KDoAMgvhBdoA8CPIAyP0g20HuA7kX5M8g94DcDXIX yJ0gd4DcDvInkG0gW0Fu0/Yk3wxyE8gfQG4E2QJyA8j1INeB/B7kWpBrND3Jm0GuBtkEchXIJA33 C3eCnEWSuZ+BPSSZrgtEwpZJLwpEsAW4HLEsYGGztg9xPmIpohdxHmIJYjHiXMQ5iFLEhICZdTYe UYIoRhQhChEFiHxEHiI3AAEO0hxENiICYUGYESaEEWEIQFKCVI/QIbQIDUKNUAUMLNVKaRbwS5Ah kKMgX4D8A+QIpPMjkA9BPgB5H+Q9kHdB3oG0vA3yFsgTII+D7AF5DORRkFshFX8ECdL1GOk1AQtb HKsxOKsQKxErEP2ISkQFxmESQkKUI8oQE/GSoxFRiEiG3TzPcwEp+c4neA4+3HFkPwjPExzLBYjp mPVpOLIWRDOiCTEV0YiYgmhA1CPqELWIyYgaRDWiCpGCcODg7YhkRBIiEZGAsCHiEXGIWLxMKyJG ugUudxjkF5CfQU6A/ARz4EeQH0C+B/kO5DjIt5DVb0C+BvkM5O8gn4IcBvkbyCcgH0N2XwJ5EeQA yF9AXgB5HuQ5kGdBngHZD/I0SBDkEcj4wyAPgewC2QlyC8s+N4wxXou4ELEoYIFHIdqDOBvDshCx ADEf0Y2Yh+hCdCLmIuYgOhCzEbMQMxHtiDbEDMRZCB+iFeFFeDDUWYhMhBsxDpGBSEekIVwIJ+Ym FSEiFAgBwSM4BMUVSaTbIUkhkBGQzyGwb4K8AXIQ5HWQ10D+CvIqyCsgL0Ogd4NcxjuTL+U9yZdQ T/Lvatf7Lt6+3reudq3vou1rfbq1E9Y2rOV1a22AC9ZuX/veWuWFtWt8F2xf4xPWRK3htKtrV/pW bV/p062k+hW1/b7W/sP9x/v5qP7W/vn9y/uv7z8IBtWd/bv69/fzwdA+KaK/eELN+v5r+rkoqOdI PzUxs6NfZ6xZXtvnW7a9zyf05fdxE4730UN9lMvuo819nX0ceO3sS02vYd4FfTHxNea+7D6pjz+/ tte3dHuvr6m3t3dd79bevb2Kdb2be7kdUOKkXo2h5rzaJb6PllCyhwsRM8g+LhTgtb2PcSPw3cdX 3IgUoudCAM6BQCzynO3r2X62b6Fnvm/B9vm+bs88X5en0zfX0+Gbs73DN9sz0zdr+0xfu6fNNwP8 z/K0+nzbW33TPS2+adtbfE2eqb6pYG/0NPimbG/w1XtqfXXba33NtXSyp8ZXzRcmwx2EJMF7adL6 pGNJgq4zcWkitzTxUOKxRH5pwrEEbp2NmuLXxW+O501w4PAQlxy3OW5r3I44hUku8PqlEesjuKWW 9RYu2yJZXrUcsgjEss3CmTabtpp2mPgm01zTV6aQSdhhojuMe42vGPkm41xjr5E3GZnOmyWjJ6fG ZEg2SJO9Br7Uayg3NBn4zQYqGTy5NZIhNa2mXN+kn6vnt+qppHdl1HylDWk5SQsVX2lCGi6koYSn dgrf1ZkBvBpys4tGJ9fwj8tf3ykIpdeQVndDUBWa1uBXN8/y041+53R2lFpm+pUb/cQ3c1bbIKVX tw9SrrLVH9XQMhP1yzZtIokVDf7E6W0Bftu2xIr2Bv96VpYkuRxiZQIu7e45y/qXLVvuXuaGA8ic ZWBZ3g9vGRSOUO6HAysRcHH/xot5QCV4y07L+uf2Qx/gDGbWez8UmMJcfqOL/10zG9t/7EX/Y2f+ //7EBCYym9U45cPhYJMB5umy2Llz5K+5VbcRMnLdKV98X0wuJn8k28lD5FHyJPkLeZ18S7Xwnftl ZC/5G/kH+Yb8DOtWRaNpAs04pd3/sDhyiWIJMfD7iJJYCQmdCB0ZuTd0hBCF8RTLdaBZBddJSygi NHSmbeS6keDIy0odMcttzdwB6O0YHQqd4MqhpTlUyHRuAyvLZzqmum1kx8jW0y5gKekj/WQVWU3W kAvIWnIRWUcuIZeTDWQjuQJisQ7KV5KryCZyNdlMriHXkt+T68j15AayhdxI/kBuIjeTWyCOt5Lb yNZwHdNvg39b5FpWczu5m9xL7gfeQe4kd5F7yJ9Bvw+ifz95EGxoQf0BsGwjfwLr3eDHvO4nD5Ad 8M9PBkmA7CS7IGeoj2pBso88TB4hQbIbsvkY2UMeJ09AHvdBZp+Sbcwyqv+2J/o/TfaTZ8iz5Dny PHkBZsYB8iJ5ibxMXiH/Ts0zY72wHl4lfyWvwVw7SN4gb5K3yDvkPfIh+YgcIp/ArDv6q/q3weNd 8Pkg7PUxeH1KjoDnEPSE/aDP+9DHx+RzuYeD0PchcpiqyXeUIz+TEJRY9rbIGbpJziPL3s2Qtzvl OLN87ACdZQijznLzAMT8Acgvywwr3xzOxoPgOwhxHY00i/KvY/NyOFcY7z3gw2LB4onRfBUijDlj /TwxFvEDcpwCckafGsvFySywGLL4vUVGo/P+KTH8lPxdjgyL7tty7N4/JXosyochgiwLrI/TY/sJ tMXssLYs5iymo21Y3bugH4Hd4ShEmvELORNfkM/Gyp+F64fIl+Qr8p18PEa+hv3kW3Ic9O/Bcgy0 r+B4uvVMyw/kB/Ij+YmcgAz+QoZP0U4ts5phMgI5hgcMylGejJwsnbSyGipQBVXCnqamGqqlemqg RmqCxxXVGTW6sRrLr2pOtjpZp5H7iaCRNAr2SyuNpfHUBvtmIk2iydRBU+jJurixGjvUiDSVOsPt YuSWcWNtk+Exyhruhflm0Gy6Eo5u6qFeKOfQfFpAi2gJWLJAzwV9PNRly6wgzWQeWUxOKD7nXoRx RcGuMnja3vcvKIr7SDTZFvoxVDFy+/Ae/mHaSl+EKBpJCDJ6HpXINsUccq5iaeh7mhL6WjE5dFQ4 ETpKc0LHiZbfxi+EPetjYQq5UKqZO6dj9qyZ7W2+1unTWpqbpjZOaaivq51cU11VWTFJKi+bWDph fElxUWGB15OVme5ypoopybFRFrPJoNNq1CqlQuA5SjKrxZpOu9/V6RdcYm1tFtPFLjB0nWLo9NvB VHO6j9/O2nVB1WmeEnguPMNTQk9pzJOa7aWkNCvTXi3a/S9VifYgndnSBuVNVWK73T8klxvlsuCS FQMoDge0sFfH9lTZ/bTTXu2vWdEzUN1ZlZVJB3XaSrFygTYrkwxqdVDUQcmfLi4dpOllVC5w6dXj BzmiNrDT+nlnddd8f3NLW3WVzeFol22kUu7Lr6z0q+S+7Iv8MGZypX0wc9/AVUEzmdfp1s8X53fN bvPzXdBogK8eGNjgt7j9GWKVP2PN4VgI4AJ/plhV7XeLMLCGaWMnoH6F0yzaB74jMHhx6CiM+hRL V9iidJq/I6ySXeJYmPy0a7RMYGwwQrg+h4ON5cqgROaB4l/f0oa6ncyzBYjkdbf7uU5Ws2+0JtrH ataP1ow17xQhstVidWf4vaIn1r9+nj0rEzIrv51+wQn1dj/v6pzX3cPYtWBArIIrhFiS1ja/VAUF qSsczOrBbC/4d3XCRSxiYWhp83vFpf4osQKjDQboxFm9aHqb3ASt1f6oSj/p7A638nuroS1MkeoB lhg2QNaX2NK2m+SFDg3m220780g+aWfj8MdUQlJc1QNt8xf6kztt82F+LrS32Rx+qR3C1y62LWhn WRLN/oxDcDp4QQLlVnBtZ3iPOsNl+1VOtb2Ns/HtLFtgsNfAQawohQqzX4kqy2hFqb2N2sioG5wl 7MFKp/UDCu+srIXGQGhaWWtzwOSWX/+HIdnwAmAYfvXYmAQYhOLkmPA8vzk09GYDyrBXL6g6ZYCn dQqKPMBwb/98nByLRTgYMAQ1S2ctu4asTA7KdqhW+zm4TtnEshhr95Nme5u4QGwXYQ5JzW0sOSzW cn4bpovsY6qc7fAsaT1Nw/pirPMTR0Nr26gCH3Lb/DVuOa8srbI+WdbH1NozqutGq+0DarFh+gA7 uRjukNhhBUFylK66riuLI/JhsdbARinWdIl2s71moCsYWj9vYFCSBpZWd/aMh2UwINbNHxCnt5VC LuV1v9a2hp06gjTQhtaKrEzYeyoGRbqxZVCiG6fPbNsNz9L2ja1tAQ4+ondWtA+mQl3bbjshkmzl mJUZmYudKaynaaCoZX/bbomQ9XKtIBtkvTtIiWxDJ7BR0h3k0GYe9ePAJqBNkm3t8IIVFtsDKYB9 uNo+n6Xnwvaegc52trhIDKQS3tRPxTLi58Qy+GJBqfdrxQUVfp1YwezlzF6OdiWzq8QKP42hEJwg 7EkDnSLsUzDl2oiNtsPsMLPZzzntwVCotc3xkm2o3QFLYjbIzDa/xg33AYWzHvwmM+kE82T/+u4u Ng7ig6XOVmZddzushdEOwaXOr4EeNOEewKNGbsOmIzTqhtxAAuX260Hxr2/3t7vZSdsWsRHZ7WY/ qRXHQ9qxT4WLncjbPhAh5rKJDa5+rXMDgwbGRqa3ocUGKpwMNlx2RSo9jLxbhKruTjtkQCDd02Gq 416qZXkDywLYEgXXAlm0tnAlYZfFO3UGrV/jgQ7hzco6D3QIb1U7BIVdvKxtCDvAuc1+HYzIdUoo ww0gOlBVx8YC7w0weOb6JOumJUimiatga2SDlk+lgmq/wVnXBZs/tteBRSwebQx9qZ3MxPrYj1YV u3I9xJ13tgZD94ir2Q4w+srKFNnNgU1MYtsNE5u0D5xp8M9yZ2Wqz7QaZPPAgNrwzxtgvNSGMUIv RGA/f3uFEKGUNAkXk038t2SyoCL19AdykfJ35CKhAaSR1MIvu+q4Z+FzcQNZzb9AYhTfExFGCA+7 cISfysHnXBfQQYyEg1/AKcGigt92aaGeB5tADEQBvx9kL/h0Ck+Jh7gD/Bb+beEmRbLiWmW38ifV ctUh9XXgRUaW8e/Bp2oeeighjWQqad1DDPRW+Mg+nh7YVVWlzlI9ASpH7PQAnIPSW6VIgTPYbOVi gfIqvsVSV666imsl5cMffvAsHF6KKPG+RL0fDL05ZB5+1lLiHTo4lJ1DLQ6LLFFGTqVSKsUUD1eQ 5irMy8st4wryXWKKkZNt+YVFZXxebhLHgydayjimU/69X5r46uFUbrVjwvQcBXU7rcmRajWfnGRw 5tlNDY1iYXq8QlAreYValVZYIfpW1qe8rI1NS0hMi9UCExOAw08pjCe+URh/niFU/byH+7ykrSxV udqg4xQa9a3pSdGpOQkTGwwmg8Jos8YnqNQWo3ZcbdfwTfFOq1ZrdcYnOFlfzmH2u7ym0BeCXiFC 3K5g32L62gIJxP0E9xykIJZ2QXpcoc936Ux0iitIOwOR0wV4iHykIDuWmbKDdF5A0pxFYsvjh90H h8rZgUKw9mfn2Pb8m+2zc9qdUUYMbn5EYSHETRkdjiOLcHRUEsQS4ynoeaU2pnxWf9Vlb25pbrvt g8sK5/uqbFolL2iNGpOnbkFN42pfpnfGBY01C+u8Bq1eLeyPE+MirKmOmGl3HL/9LkoenBmR6LJF JLgSksbF60W3WN5/d0/fPYsLHOl2daybwKzZFDohNML8KiRV5BaM0i6zx5KhfQwmOCFF3C2BjHJL kIPfaXnMwXC8zEHq3ClJ1omjholBmvGw5Gix+hQ+iFh5efyQG+bZkLsEQpZ7EKaYJaKkBCI3+G91 gnGTp1sa7+FF0TI6+Sz5hXmO3BhrEs/iqErirdaYGJrvSnO5wIvFUmhUJ43PHZebqBeWR6fnSOOm GZJy01x5SfosB23Kq7BNXTvD45DmlCbmZaVHLjFpRx4YXxGVl7Xi8uLW4oQUnUkrCDqLnjpypuTF j0RqzVqlEg7CjZlpAq8rnLGycdK5rWWRxvSSOk/IJfLzpbYIhXLkWltOFYvv5NARfgX/FskjEk0L z0KNNT/IzdpF0tLI+CBXLZktvJV+a6XWoD6f/pJP89nfUjR6A52Sn++ZNC5IYyXboRTKr03ZlMJJ Kc0pnSm8KSU5hdMLKSlCYjB0SDLqYc4mxpppY+IJTz3Li6QBZeJhSd8okFgvS0j5kJslBT72dXTM 7WAZ8bo7zh/qOB9ytL/Eax7KZRmSTP/Zwci5ZhuQy1VQEN6I8mFJ5BXke2AGjG06Att0olW4bGLy cguL+BVR7nFZGZaiTWdNXjkje+LqXStnWNImZZd3T8kz6yw6pTahZk7vhEU3dGb+0DnxrMK4yeUF 7Z5ko1mlMhsnT6hw1i2unbqsIbVwXPm4qISUBGO8y5qcmigmRWb4Lp/9bkRqnqNYKoQfZXOkHrL6 MGTVTfIpj1ndGRnpyAxylQF3vhDk+iStg8+MzORsmU8LLJ1WA20kglngpjQLnQK3TfALnCAkeCFT O020kVGyg4/3sKs+9ntiNBs5C2/UxOppoyYWHDQ/SQmNuBm5D0IKh8LZ7Dh/Tod7aE4HW2cfDEFK WQo1/6unhozRKKXoOGXzgsUY3uVwM4tOK5RvISr+4YzU4Y9tEzomVcyvyzZp9GqeE9SG8TOXV6zc uWpC2Yp7z1m6dWH2cX7W3OzJ3jiOnvBklnRMSom0RqoiHHExyTEmY6zVUrrm0bUr915WU9G/bY79 nNWpE6d7Yb+/KHSCrlEshe9H2MMl7PeSyRBNdTqq01IDoTqBBLnOhyStuUYxhe1S1BsPtz55PXTY do5aT9lsCixs5rF5RtfoE7OdzuxE/ShTtCatQsEOotasUyp1Zi17AoAxKDUwM5rJvTiGwZrIIDd3 Z1JSrhYYaC5Le4zrJLnwpTjee2AvbQw01KeObqWpoEtGaVJ9WU1WcV3WlLgpONjycthBw8sYkl0C WypssGzF7v4f9XX65bIlplSdsr3+yhAOSLR89+Ks+DAQrdToE7KdruxEnUUscGbNLoQwpbJwWVIK Uz2zC0ajpo3PSLaPs2rrr2suaqvOtaQ3NjSkta9psI+Fk7Nk1Rck1lQO7xgN8K8t/IWjdWc3N1vd pU53WVpk6dkDjeEM8K9BBnLJunAGxkWykCcRHcSfJMFd7NhOHW2U72Zs22QZkHRSVv24uNS6sXBH yMF2U+/BIfNYmP+Fhv+XuJ4exmj+NX1CTqozJ0EfmVriyp7364DdNH3W2saUsTDR4UlnhOm0oEAw umCfqg0dEQSIRSRJI70Yjb0kiuuHO3sSHLUkLjwL44I0XtKY6kX54UcM0oSApJD3G/m+AROOPSXC VPtvNpD3hLG9Wl5DivD+PfqQIwila4IXrPQvL5645pELVvmXFY8MR+dOLy9uLbTF5LSWlbQWxtMj fXs21ldcFFzR9/iG+kkXBS+u6J3myWjqnQzMypjaCyuuLnSE+wausY58hle4m0ziPA+l5qbm6m1B rkpKIXrBQz2Hi2Ab0H5mKZJY8ovsRRxfZCmyxJhKaSlMCcnGHvtKD0+yKTLqY8zs7ktiqFmI+WY0 ELBRuNkiHHJ3WEpKvN65HW7zUAe82RwBu9fLQiTZ/9+e7GRkhYLw7oTP6B5lWD/zkVLJfVPSc/X0 3Fm12TF6Qa3X6NySrzClIC3KObGxpXGiM3fOhtZxTVJmpFrgeZVerXGVNGSn5NrNrrKmlqYyF02a snxqmskaG52VmShGq+KS4o3x6fFJbntCSqY0s1w6d8o4fUS0yRSdbLWlRKmiY6ON8WJU8jh7giNT aoccWUNHuauFQTKeXIs5esRiMUzIIGIW2xOthqzR3S8rSJN3irWJhlGDAQwBa21OkE4OSCqckXDr ewmEevOGc/fnWvCmt5tkhefyv9IHrlJB/iBjgWcOOYTwqDG6POXNH25u8MQJzxho5a7WRYjeooSG 82pTzo2MYveAc3SJuHqfYhtTVOTTnglR9jiLSqlTKtZkeiNNOqWradU0+oK3KDHdqn0O7hgKBdwx ntNa0xOLvCMddXUqjUoVnQqxWg3PFi/yz8L+tSi8f+nglsH+dJzMzZVMkVl1aTpFXF2qvFLZ3WKX ZGzEewR7yGN3CXm5yg9zxv+GN8YAP8yNPnGN3fgs8l29sGjMwL+ojctIdmTEautvmjZ7baNDvnTY 6SOcsHF1Fenk+2SCfmyngi26tOeKhdyYYURdI29dXMvoLg5XHRM6we+Eq84kU/GqA2YH/Njs0l3R DqVDDHIdko5IjvQ6hy6+TiffvWGDpnHe+Fj21GNmB1h8j5zhEF4sKmrkWYrTKHyqDefWGmktigx/ lN1JeYUwclxhSassLKh0WRQjx5UqqkvIcWawzw0HlMrneUOC1+X0xmv5rQqjJcb4yzuWaL2g0Eeb +bQou1EJlyIoNBb98PlxcdxmvUWjELQmuC4xdELxOlxXNdkSnvkJiRGezEzzOHhWlHSJ5mKjWeDH jzeXBjm3ZJB486S6vDpzts5UOz4YenUnMBMoGVlhvJm3OuusUzRyAMojrCXw0wJ4jonzxh6MhwjE eSNKIP+xZrYfxXlLQGE7kol1+U8al5fL8VGq+HB4+LSTRXj8/nWkTgma4nWl+kuF2TExJ6dMNAtb OG5AMKWW5eROBO2oRgHTwpmem6DjBznubt4Q73U6PTYdH+C5+zj2rOD02uDvUTp70slIckkazfAn J+Oa6NBpTRpB0LKw6vUsrCzIJu3wYl1YEzQmWBjwoiQChL2UcLcjla0zJtdWuCu7Fi+a17coq6J3 MftPlv8FRfaTSgplbmRzdHJlYW0KZW5kb2JqCjIzIDAgb2JqCjc5MDkKZW5kb2JqCjExIDAgb2Jq Cjw8IC9UeXBlIC9Gb250IC9TdWJ0eXBlIC9UcnVlVHlwZSAvQmFzZUZvbnQgL0RNSURCTytBcmlh bE1UIC9Gb250RGVzY3JpcHRvcgoyNCAwIFIgL1RvVW5pY29kZSAyNSAwIFIgL0ZpcnN0Q2hhciAz MyAvTGFzdENoYXIgNDIgL1dpZHRocyBbIDU1NiAyNzggNTU2CjU1NiAyNzggNTU2IDUwMCAyNzgg NTU2IDUwMCBdID4+CmVuZG9iagoyNSAwIG9iago8PCAvTGVuZ3RoIDI2IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdkc1qwzAQhO96Ch3TQ/Da+QdjCCkBH/pD3T6ALa2DoJaF rBz89h0paQo9zOHb2VmvV9mpfq6tCTJ796NqOMjeWO15Gq9esez4YqzIC6mNCndKNTW0TmQIN/MU eKhtP8qyFFJmH4hMwc9ycdRjx0+x9uY1e2MvcvF1alKluTr3zQPbIElUldTcY9xL617bgWWWosta wzdhXiL11/E5O5bYCIn8tpIaNU+uVexbe2FRElXl+VwJtvqfldMt0fX31iKvyiiiVVGJsiiAEFGh Iq6AENxVxDUQAu4jboAQminiFggRbdOoHRAi2h2iuwdCwHXEAxBC8yZiC4Tg4kPY+3fB+Avx1I/T qKv3uEp6j3SweAhj+fFkbnRxQNIPpLeMWwplbmRzdHJlYW0KZW5kb2JqCjI2IDAgb2JqCjI4OQpl bmRvYmoKMjQgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvRE1JREJP K0FyaWFsTVQgL0ZsYWdzIDQgL0ZvbnRCQm94IFstNjY1IC0zMjUgMjAwMCAxMDM5XQovSXRhbGlj QW5nbGUgMCAvQXNjZW50IDkwNSAvRGVzY2VudCAtMjEyIC9DYXBIZWlnaHQgNzE2IC9TdGVtViAw IC9MZWFkaW5nCjMzIC9YSGVpZ2h0IDUxOSAvQXZnV2lkdGggNDQxIC9NYXhXaWR0aCAyMDAwIC9G b250RmlsZTIgMjcgMCBSID4+CmVuZG9iagoyNyAwIG9iago8PCAvTGVuZ3RoIDI4IDAgUiAvTGVu Z3RoMSAxNDY4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AXVUfUxTVxQ/9/XjMSDS 2tKiyEcptBU6dRRa2SqKkgwiiIhW58hIKYVCy4YgBEcZApUPxQFhzrHgVNwECQxksEwCoRrDDFvj lk0TjHMxZsj4QxITyIbwuvP43D/e+84975xzzzm/c89972RhsRk84DRwAEz5xgJYGsSBTJ1jO5W9 It8D4PxuMRuzlmVYQK61oGLFHoU81JJ/snRFPoZcbfvItGrvQ9kv31i6Eh8eoxz8oTHfvLyf18bK r7fHNKFdVVBoXsWH8SVPBcvOr1k3ABA0eVGDoIdxoIECAWxf0rEePJRZO/9n19N0uiLDRz/r4e/B WqD9mTKc5a6DDyTzvYs5AvBIRfGNNV/0o2OZA7BPAPO98x8jDjbS/4cXH1VUDLDUxS0CPZIBKQ2p Bmk/F2A32kKRy9CRrETwBj4EoiwDT+wIBVzESVDnidlp7BM7fHGGQzpcgudEQpLIZ2SITAPFQuDh RD8aAwhlwjBcCIZYCOY4F/bw4BUEc51sri7mCakGF0YFTbTGV8ynlVqt7nvXwaORMVqOy3XinCJ5 k/F93KkH4NI8J4spzFem0OE2rTY6SiEPWfLRRErQm0/jw6UXdJQ07NqXM52tZVVt5Jbon19/m0vo uNOeHtjTE6c3OT+5+1e2taXtrOj+xHTPsa7hr+uMb7FoDO5JrgRzRACIdBKJJnI5Aa1be13NxSaj JbiCPERhGAi6YK3obS/XJIk3ehX9UJOX2yAekE1/Wzpuzc6qamKmHt52k2q/1tq+KvtV8VdUabmp yuEIHvwxpz8ro21b4MinTmZ2kj2vNPdz7iZEIAU57EBICkV0lHa5ttV0gBqReB0RR7yOlE/yCmyT o85pa37teWZuYoKZa86ssVrO1Gfn1L2d2JRW2dlTVdHB8d/6Rd6VR39eyb64VX23btgNhDgbb5PD Fkd1hqnWseBObkq5frqqqxOvDdS4p7hBvCG8swHYTblQI0REgZSvAGtXcsTSdSjkzY6BwpuZvSf2 MC9Hhq1U1JHmku5viku6eUOLs40pjeNFzAzz8BL5fPTIOddPv4y5MPp+jB7IjcWbhNGJlM+Xh4BQ AJpIEIpp2VJpRKZQsn3mfDCkfnHrb2aGiB8/IBvIwpRn/xlTw+IjKtV7p6HefoMYpNcGSBDhEG+i Yp4w/wqCe4cs5ELNPst1tr+73VOcm5gLT3atv0qFchuFR4q3Cc9ZIqUVbCpfLAsnVomXClu8u9+n vsxeGh3WMtaaErczvDmtfOS4sM+7KNeeJ5Fs93eMXjTkjpXfnyC7tlgLzfG75H5hkYmVB949pQqK SCjL8TuUfkgn3xIg8gzVxNnTj18+2o14Qt0vqXBeK3YbwqRsGkW0UB6tEeqEGl+5cKmvlGBzkj7T pnY4vhscFEWoAq9eFsSa2ylTA6FtzPmGxZZk9Wa2NhmTynnBVQAKIiXbEh07iUYkkWp1Ig1hPw15 SIX4HbU+QSpU8LyY/Dt/RIQERTwbYGxxoTvshigm54ZAFepv9QngqhZbiyvtJZT11b3eve+l4QdN YCMSO/iAP7T45MT4vSkRcYW5Rlvy4f8ANC9uygplbmRzdHJlYW0KZW5kb2JqCjI4IDAgb2JqCjEx ODQKZW5kb2JqCjkgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNl Rm9udCAvSUNFWkdHK0NhbGlicmkgL0ZvbnREZXNjcmlwdG9yCjI5IDAgUiAvVG9Vbmljb2RlIDMw IDAgUiAvRmlyc3RDaGFyIDMzIC9MYXN0Q2hhciA4MiAvV2lkdGhzIFsgNDg3IDQ2OCA2MTUKMjUy IDQ1OSAyMjYgNjczIDUyNSA0NzkgNTI1IDMzNSAyMjkgNDUyIDQ5OCA1MTcgMzQ5IDc5OSAzOTEg NTMzIDU3OSA0MjMgNTI1CjUyNSAzMDUgNTI3IDIyOSA0ODggNTQzIDUyNSA0NzEgNTA3IDM5NSA1 MDcgNDU5IDUyNSA1MDcgNjQyIDUwNyA1MDcgNTI1IDQ1MwoyNTIgNDE4IDQxOCAyNTAgNzE1IDg1 NSAyNTAgMjM5IDQ1NSBdID4+CmVuZG9iagozMCAwIG9iago8PCAvTGVuZ3RoIDMxIDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdk81um0AURvc8xSzTReSBGZtEQkhRqkhe9Ed1 +wAYBgupBoTxwm/f812nqdTFWXzc+bmHmdm87j/vx2F1m+/L1B7S6vph7JZ0ma5Lm9wxnYYxywvX De36nuxbe27mbMPkw+2ypvN+7CdXVZlzmx9MuazLzT28dNMxfdK3b0uXlmE8uYdfrwf7crjO8+90 TuPqfFbXrks9y31p5q/NObmNTX3cd9SH9fbIrH8jft7m5OiIGfm9pXbq0mVu2rQ04ylllfd19fZW Z2ns/ivF8j7j2L8PLfK6Et5vY51VRUEEYqMYiOB9tGokAvFZ1S0RGBwUd0TwvvCKJRGo5opPRPC+ 3Co+E8H7nVUbIhCTqkciMNj2bYlA1fbtiEB1p8GJCFRt5Z4I7Ks2Av9CMLhQxFUwuFPEVVCVQsBV IGgR13D3VZMBV8Fcq+IazLe0jXAN5rtTzwFXwWA1GXAVxF4RV0FsFXEV7CuFgKtAwXrGNZjv7klV XAVzS0Vchfd4ZVXEVWCkE4y4CqpaKuIq2EhdYWkw2ObiykFrsATpxaANdcWMKpog/4SInKANWxk5 bgWx1BlF5ASXQQcakYs6RZ/LN2IjiDYYm2hGpYwiNoImdUYco8FSmsttqvgt2hdBrvjfu6zbrlf5 8Yra67LwgOzp2tvSmxnG9PG652nWAsYfS7AFlQplbmRzdHJlYW0KZW5kb2JqCjMxIDAgb2JqCjUx NAplbmRvYmoKMjkgMCBvYmoKPDwgL1R5cGUgL0ZvbnREZXNjcmlwdG9yIC9Gb250TmFtZSAvSUNF WkdHK0NhbGlicmkgL0ZsYWdzIDQgL0ZvbnRCQm94IFstNTAzIC0zMTMgMTI0MCAxMDI2XQovSXRh bGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAtMjY5IC9DYXBIZWlnaHQgNjMyIC9TdGVt ViAwIC9YSGVpZ2h0CjQ2NCAvQXZnV2lkdGggNTIxIC9NYXhXaWR0aCAxMzI4IC9Gb250RmlsZTIg MzIgMCBSID4+CmVuZG9iagozMiAwIG9iago8PCAvTGVuZ3RoIDMzIDAgUiAvTGVuZ3RoMSAzMTI3 NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHVvQd4XMXdPTz33u29F62k3dVKq7Lq ktVsS2urS26yLFuyLVuy3JG7jQEbbMA0AYGAA4FAIAVIMIHVysaiBSdxekwIoQRCCOmUOCGdJul/ ZmZHlinv+33P93zPk7+ss+dM3Xt/0+fOlffu3reBGMlhopDSoW2DOwn7qX0XdHDowr0h7o42EaJ+ cuPOTdu4uxBkjm0avngjd9e9SkhD6eYNg+u5m3wIrtoMD+6WKsHZm7ftvYi7a2kGPxneMZQKr9sL 9+Ztgxelvp8gPxLaPrhtA49/iYm6d+7ekAqXepHd2zYe+CmfFkIkBFWo6ohX0hEdkYmNlJBrCHFU ybOICqE0XFNR8SX93RNrrXP+Rfw6ltcTbx/8CRUv3Day8YP3Jw7r/6yrglOPHPgP0mm/OPEKIYZ7 P3j//Xv1f2Y5pQIZVYzqlXnd8g/k75EaEpS/n+JfkRr5FdIjvwx+CfyLFL8IfgHu58E/Bz8H/hn4 afA3wU+BnyQ9RCX/klQCywBlWq2H66vA84CaXICcJGJEeom45G+TJmA9sBc4CqgR95sI+ypylEhI PnJc75M6QuPylUJcIcTlQhwW4pAQlwlxqRAHhTggxCVCXCzERULsF+JCIfYJsVeIPULsEmKnEDuE 2C7ENiGGhbhAiK1CbBFisxCbhNgoxAYh1gsxJMQ6IQaFGBBirRBrhOgXYrUQq4RYKUSfEL1CrBBi uRA9QiwToluIpUJ0CbFEiMVCLBJioRALhOgUokOIdiHahGgVokWIZiGahGgUYr4Q84SIC9EgRL0Q c4WYI8RsIeqEqBWiRohqIaqEmCVEpRAVQpQLUSZEqRAlQhQLUSREoRAxIQqEyBciT4hcIaJC5AiR LUREiCwhwkKEhAgKkSlEhhDpQgSESBPCL4RPCK8QHiHcQriEcArhEMIuhE0IqxAWIcxCmIQwCmEQ Qi+ETgitEBoh1EKohFCEkIWQhCApIU0JMSnEhBAfCvGBEO8L8Z4Q7wrxHyH+LcS/hPinEP8Q4u9C /E2Id4T4qxB/EeKsEH8W4m0h3hLiTSHeEOJPQvxRiD8I8XshfifEb4X4jRCvC/FrIV4T4ldCvCrE L4V4RYiXhfiFEC8J8aIQLwjxvBA/F+I5IX4mxLNC/FSIZ4Q4I8RPhPixED8S4odC/ECI7wvxPSG+ K8RpIb4jxLeF+JYQp4R4WohvCvGUEE8K8YQQjwvxmBDjQpwU4lEhTghxXIgxIZJCjAqREOIRIR4W 4htCPCTEMSEeFOLrQnxNiAeEuF+I+4T4qhBfEeLLQnxJiHuFuEeILwpxtxB3CfEFIe4U4g4hPi/E 7ULcJsTnhDgqxK1C3CLEZ4W4WYibhPiMEDcKcYMQ1wsxIsR1QlwrxDVCXC3EVUIcEeJKIa4Q4nIh DgtxSIjLhLhUiINCHBDiEiEuFuIiIfYLcaEQ+4TYK8QeIXYLsUuInULsEGK7ENuEGBbiAiG2CrFF iM1CbBJioxAbhFgvxJAQ64QYFGJAiLVCrBGiX4jVQqwSYqUQfUL0CrFCiOVC9AixTIhuIZYKsUSI xUIsEmKBEJ1CdAjRLkSbEK1CtAjRLESTEI1jdLY8Lh9JZtYHMWdOZrpBV3DX5cnMOrgOc9chTpcl M03wvJS7DnI6wOkSThcnM+YhykXJjEbQfk4XctrHw/Zy1x5Ou7nnrmTGfCTYyWkHp+08yjZOw5wu SKY3I+ZWTls4bea0idPGZHoTomzgrvWchjit4zTIaYDTWk5reLp+7lrNaRWnlZz6OPVyWsFpOace Tss4dXNayqmL0xJOizkt4rSQ0wJOnZw6koF23EM7p7ZkoAOuVk4tyUAnXM3JwAJQE6dGTvN52Dye Ls6pgaer5zSX0xweczanOp68llMNp2pOVZxm8cwqOVXwXMo5lXEq5ZmVcCrm6Yo4FXKKcSrglM8p j1MuzzrKKYfnmc0pwimLZx3mFOLpgpwyOWVwSucU4JSWTFsEY/k5+ZJpi+HycvJwTzcnF/d0cnJw svMwGycr97RwMnMy8TAjJwMnPQ/TcdJy0iT9S/Dt6qS/C6TipHBPmbskToSRNMVpkkWRJrjrQ04f cHqfh73HXe9y+g+nf3P6V9K3LDgu/TPp6wb9g7v+zulvnN7hYX/lrr9wOsvpzzzsbU5vcc83Ob3B 6U+c/sij/IG7fs9dv+Ou33L6DafXedivOb3GPX/F6VVOv+T0Co/yMnf9gtNLSe8K3MqLSe9y0Auc nueeP+f0HKefcXqWR/kpp2e45xlOP+H0Y04/4lF+yOkH3PP7nL7H6bucTnP6Do/5be76FqdTnJ7m Yd/k9BT3fJLTE5we5/QYp3Ee8yR3PcrpBKfjnMaSngbcdDLpWQUa5ZTg9Ainhzl9g9NDnI5xejDp Qa8vfZ3n8jVOD/Cw+zndx+mrnL7C6cucvsTpXk738My+yHO5m9NdPOwLnO7kdAenz/MEt3PXbZw+ x+koD7uV53ILp8/ysJs53cTpM5xu5HQDj3k9d41wuo7TtZyu4XR10j2Ie78q6V4HOsLpyqR7I1xX cLo86e6B63DSjcFGOpR0V4Eu43QpT36QpzvA6ZKkez2iXMyTX8RpP6cLOe3jtJfTHp71bp58F6ed SfcQctnBM9vOY27jNMzpAk5bOW3h6TZz2sSvbCNPvoHTeh5ziNM6ToOcBjit5bSG33Q/v7LVnFbx m17Js+7jX9TLaQW/3OX8i3p4Lss4dXNayqkr6YrjxpYkXdSsi5Mu2mAXJV1XghYmXUWgBTxKJ6eO pAsTCamdu9o4tXLPlqTrMoQ1J13XgJqSrkOgxqTrMGh+0tECmscpzqmBU33SgXmBNJe75iTtfXDN 5lSXtNN2VMupJmlvhas6ae8FVSXtK0GzeFglp4qkvRCe5TxmWdJOb6w0aacdUgmnYp68iH9DIacY z6yAUz7PLI9TLqcop5yknVopm1OE55nF8wzzzEI8lyCnTJ4ug1M6pwCnNE7+pK0fefqStjUgb9K2 FuTh5Obk4uTk5OAJ7DyBjXtaOVk4mTmZeEwjj2ngnnpOOk5aThoeU81jqrinwknmJHEi8SnruiDF pHUoOGFdH/wQ+gPgfeA9+L0Lv/8A/wb+BfwT/v8A/o6wv8H9DvBX4C/AWfj/GXgbYW/B/SbwBvAn 4I+WTcE/WDYHfw/8Dvgt8Bv4vQ7+NfAa8Cu4XwX/EngFeBn4hfmC4EvmsuCL4BfMw8HnzdHgz4Hn oH9mjgWfBX4KPIPwM/D7iXlb8MfQP4L+IfQPzFuD3zdvCX7PvDn4XfOm4Gmk/Q7y+zbwLSA+dQqf TwPfBJ4y7Qo+adodfMK0J/i4aW/wMWAcOAn/R4ETCDuOsDH4JYFRIAE8Yrw4+LDxkuA3jAeDDxkv DR4zXhZ8EPg68DXgAeB+4D5jUfCr4K8AX0aaL4HvNV4QvAf6i9B3A3dBfwF53Ym87kBen4ff7cBt wOeAo8CtwC1I91nkd7NhUfAmw+LgZwybgjca7gveYHggeJWSEzyi1ASvlGqCV/Qc7rn82OGeQz2X 9lx27NIe46WS8dLApZ2XHrj02KW/vDTu0BgO9lzSc+DYJT0X9+zvuejY/p7H5avJRvmq+JyeC4/t 61Htc+3bu0/55z7p2D6paZ9Uuk+SyT7bvtA+xbS3Z3fPnmO7e8juJbsP707sVs1O7H59t0x2S4bx qVNjuwOZLeD4wd1mW8uunh09O4/t6Nm+cVvPVlzglppNPZuPberZWLO+Z8Ox9T1DNet6BmsGetbW 9PesOdbfs7pmZc+qYyt7+mp6e1Yg/vKaZT09x5b1dNd09Sw91tWzuGZRzyL4L6zp7FlwrLOno6at p/1YW09rTUtPM26epNvSQ+mKjV7AonRcCQlI80sD8cDrgXcCKhJIBE4FFIc1LZgm51v9UuNiv7TD f8h/k1+x+n7qk+O+/MIWq/en3l97/+pVOePe/OIW4rF5Qh7FTe/Ns3AZvbcxT0MT57JZ7F6Dnki0 xeqWrO6gW27+q1u6mihSSMIzJBtI0SHNcckdbFGeYo+V1ESSbibLYp3jOrK0M6FbsiohXZvI6aaf 8a6VCc21CdKzclXvqCR9pm9UkhuXJVydXSu5+6obbyQZ8zsTGd29SeXeezPm93UmDlMdjzM9RTVB lL7Ymj379sR643OJ/XX7O3bF/bTtpzbZapWs1imrHLfi4q2WoEWmH1MWJW4pq26xmoNmmX5MmRVP 3Awfaspc05JlLVZj0Cj3NBgXG+W4saGxJW4sKm352H2O0fvk3xzbu2ZPDHJvjP3C1Sfto078IAS/ e/bCTf+B4CY05NN/eDTEW7sHPywbnv2nJ/m/IET6v+Aa/8svcZSgifTOm5KP4FnmlcAVwOXAYeAQ cBlwKXAQOABcAlwMXATsBy4E9gF7gT3ALmAnsAPYDmwDhoELgK3AFmAzsAnYCGwA1gNDwDpgEBgA 1gJrgH5gNbAKWAn0Ab3ACmA50AMsA7qBpUAXsARYDCwCFgILgE6gA2gH2oBWoAVoBpqARmA+MA+I Aw1APTAXmAPMBuqAWqAGqAaqgFlAJVABlANlQClQAhQDRUAhEAMKgHwgD8gFokAOkA1EgCwgDISA IJAJZADpQABIA/yAD/ACHsANuAAn4ADsgA2wAhbADJgAI2AA9IAO0AIaQA2o5k3hUwFkQAIIWS/B T5oEJoAPgQ+A94H3gHeB/wD/Bv4F/BP4B/B34G/AO8Bfgb8AZ4E/A28DbwFvAm8AfwL+CPwB+D3w O+C3wG+A14FfA68BvwJeBX4JvAK8DPwCeAl4EXgBeB74OfAc8DPgWeCnwDPAGeAnwI+BHwE/BH4A fB/4HvBd4DTwHeDbwLeAU8DTwDeBp4AngSeAx4HHgHHgJPAocAI4DowBSWAUSACPAA8D3wAeAo4B DwJfB74GPADcD9wHfBX4CvBl4EvAvcA9wBeBu4G7gC8AdwJ3AJ8HbgduAz4HHAVuBW4BPgvcDNwE fAa4EbgBuB4YAa4DrgWuAa4GriLr5x2WjkBdCVwBXA4cBg4BlwGXAgeBA8AlwMXARcB+4EJgH7AX 2APsBnYBO4EdwHZgGzAMXABsBbYAm4FNwEZgA7AeGALWAYPAALAWWAP0A6uBVcBKoA/oBVYAy4Ee YBnQDSwFlgCLgUXAAqAT6ADagTagFWgBmoEmoJGs/y/vpv/bL6/vv/0C/8uvj9Bp2fTEjF6sb+0a HHjSfpGQyVtnHoAiS8hWsoccxr+ryY3kVvI0+SVZR66EuoPcS+4nXycJ8i3yQ/LSean+PzomL1Zv IyblJNEQJyFT70+dnbwfGFdbZvjcCpdTFTrnM2Wb+stH/P4yeeuUbXJc4yAGltYsP4fc/iFNTL2P IVdDzFNV1C1fA21l3/Q37RcnH5l84LwbWEK6yEqyiqwm/WSADOL+15PNZAsscwEZJtvIdubajrBN 0BvhWotY6F6YPhdrB9lJdpDdZC/ZRy7Ev53Qe1IuGraLufeR/fh3EbmYXEIOkIPk0tTnfuZzECGX MN+LEHIZOYSSuZxcwZRg7nMlOUKuQqldQ64l16HEPt113XSsEXI9uQHl/BlyE/k0feN5ITeTm8ln yS2oD0fJ58ht5POoF18gd33E93bmfyf5IrkHdYam+Bx87mHqNnI7eZJ8j5wgD5NHyKPMlkOwLbeI sMtGZumdsMFB3POVM66YW3P/tLUugzXofY+k7vsi2O+KGSkuTNmRWu9KxKTWGUmVA83l0pSPsMTN uDOuz90ntRG9h5vOu0+R4n/zpXdM7XQX7CUsQ212G/zu/JjvzBgz9W3kbrTAL+GTWpWqL0NzdQ/T M/2/OB33Xhb2FfJVch/K4gFClWDucz/8HiBfQ9t+kBwjD+HfOT1T8dCHyTdYySXIKEmSMXIcJfko OUnGmf//FPYI+o6PphlL5ZWczuUx8jh5AjXkm+QUeppv45/weQp+T6d8T7NY3P1t8h1ymsWiod9G 3fo+eqgfkR+Tn5Cfku/C9Qz7/AFcz5LnyM/JS5IZ6mfkTXxOkGfVvycWMg9nZR9HadxF1uDf/48/ 6jTiJvdOvTu1f+pdpY1slJZhAvkQSuk4uQE7E9vPfbUUJAbVb4mLHJ/6t7IanDfxinrz5Jen/hpf efVVe/fs3rVzx/Ztwxds3bJ508YN69etXdO/etXKvt6eZd1Lu5YsXrRwQWdHe1trS3NT4/x58Yb6 uXNm19XWVFfNKikuKsyL5mRHsoI+l91mNRsNep1Wo1YpmJ8XNkdaBkKJ6EBCFY20tRVRd2QQHoMz PAYSIXi1nB8nEaLpBhF0Xsw4Ym78SMw4jxmfjinZQnPInKLCUHMklDjTFAmNSyu7eqFvbIr0hRJn mV7ItCrKHGY4wmGkCDX7NjeFEtJAqDnRcuHmkeaBpqJCadRoaIw0bjAUFZJRgxHSCJXIi+wclfLq JSbkvOa6UZnozPRrE0pO8+D6xJKu3uamQDjcx/xII8sroWlMaFleoS0JXDO5PjRaeGrkhnEbWTcQ M62PrB9c3ZtQBpFoRGkeGbkmYY8l8iNNifxLfu+DATckCiNNzYlYBBfWuXT6C6SEOscWCY38i+Di I2f/jKue4TOY8tHk2P5FaCC9xWkzJaRBoQmuDVeI+wuH6bVcPx4n6+BIHO7q5e4QWRdIknhJrC8h D9CQUyLE3UNDDouQ6eQDEVi2OdI8kPq9cLMvcXhdqKgQJct+cxKqHISHEkp0YN3QZsqDG0YiTbhD 2JIs603EmyDigyljNo+WliD+4ABuYgs1Q1dvoiSyM+GKzOfWhgcyyWne0t3LknDf5oSrMUEGhlKp EiXNSIsq0jxCC4ZeIM0r0tX7GKmYen20MhQYqyCVpI9eR8LTiEKJNo/0rt+YCA4E1qN+bgz1BsKJ eB/M1xfp3dBHSyliS+S/jq/DDwqQpcK9fSS2iIzbTmhzdKFeOaD00dKCR6gFH5H5cxBgS2i4k5bo /DmhXilARDR8SyoGVeflA4eS09iGxGAkbWwLhFG52c//cEkBfgO4jIRu+ppUuAj1uWvi3/Opl8Zj 0wvKDzVvaJpxgedlCge7wFRun3ydMrVFyhi4BB0tzjZ6D0WFMnQIwbqEjPtkXrQUfaEEWRLqjWyI 9EVQh+JLemnhUFuz8u3sjtDtVVbaqVqy7DwXD6/hYQkS7lzWKxx05ynREmPlSouVuVuZe9rZ9pHg dhGMfocsGRlZP0qUHFqVA6MSE+rG6/sSi2N9kcS6WCRMr7OocFRHTOFlA41ovS3oOSMtg5GQLdQy Mjg+dXjdyGg8PrKzeWBzHdrFSKR9/Uiku3cOCpd1BJcGLqHX4iCdUuey+chKJvNHI9K1XaNx6dru lb2P4V2J0LXLepMy9poH5veNZiOs97EQIXHmK1Nf6kmjhKiD5rQUDh2LH3gsTshhFqpiHsw9NC4R 5scjwU8iQ+My97OxeKNR9kVxvDsxNK7iIXGRgwp+Ou53mMfOS8XWIcRGQx4nGEiw+Ydr5j98JzBu UMd1cX3cJJtlmJQWSRI+jyOuXiJjJsksBUaRJ+4A3ngkPaqPBx5jOXGvx6XDiEn9DiP3VDSZ0Ggz MsJX8hvvAaXuoGdl75iJIH/2iRjz6Q+6EN9m1DEMNM2h9bT+HezbPDLQR3sP4kFdxa+UkCL1JCFH 6nHFGlPCENkwP2GMzKf+DdS/gftrqL82Mj8heSQU9jg63ZGBCDpitKlePO7oQ/W30eYt54TGp6aW 9YbPBM72hdHmVwMrexP6GAY6dU4H4rVSDMC7NXF4aJBeB+lBX0a7nvahPjR2kSGitCf0yEGfygEx Wlga2t6QaAh1DRWSpT8MR+JwX6IvRr+0dwu9olDIliBtkbqEJsrzVEfpF5X0jTgi5bTlImrCkHMN JT2ujXT3cp8AnPgyjCj0jrQmXPlQBEFDAyFYHXWkG22ZDxYGWg/hswF9viq6gcEQSAUSeltKjtFs SOiLkSF+qTYWI0P8avtgFHrzzHVNKgK+25Yw4oqiM0yZSgDrIKidXgt+r8HF06jfotl0jZOlkYvQ 99OLZl+lRXDCnNM+iNGNpzfCJ1IjEiMvXQ71onmc5r5aeucm2B1dwvjUA5GLaRcnfooKI3T0o/WP BB5DQyV9Ix/1SKyKFRXqPuprZt4jIzrzJyfg9tKZp5nmghsZosMamFY4Vt9CzXSAjXSMyosQAywx HumIYFCTcygw0VHQfMKh9X00Fi55CevLIp8WCVlMR6LDNMt8xDabzkqoC+HMBQd+RxKbzndunna2 ILgFk8GcYoD9RlEwtN/fGkgMo2YimEWhJRIaCdkidRH6gVtV0BqAAZTTdLNA9Ueto43m8FCodx0q O8zTMjDSMoIvCQ0NIhmtg6lvSmyPnZcl2oWEdgiDUCskDi8JDfSFBjA1lbp6w+EAWiM4tHEwEY8M 0qFgCb4fv0swJIEGR2gVJ3340kBCi4Fp4+CGSBgDDvz6mF1Z+eDbebMhgZGRyEiCdQQtiIzso2h2 7ZTwuzMWGdxAp9D4vtDgBpa2BZfLrEOvL9AcQVvegKuldsd94e0vso5+DI1EkFv/QAyWsI84RkK1 I+iC+zF6qKJDywcwVNERKcSKejAAF+zaTl19yIhH1OfQiLwJ0KvZFhvt1+ac86FtMbEjxiPrWK64 sqW9iSUiEWtPNNauWEL21iAQV5qQlqJng/1pPwXjqXPaYd44ql6Apg4lZAyvvHhY+naaFF0DLzCe DD5sEGFNDIOkGG3EOLQ6AJt+qj9R0VcKfwpTfIlEVE1kUPVn8pDyBvAN8pCsIg9pXiIPqbLIQ+p1 ZEjVy/xblT8SqzqLPKg8TWYrL5DVqkpyh7KOrAQPKB+QfnkXyVFOk1nUH48JrpLemnpB+QrTd2jW kzuov6qGxad6QP4R0odJl/wwCcN9VLmbZKnHySzlHpKl5JM+PA4pwMOS2ykrfeRaIIbrfhjYDWwC SoEN6FTYg2qwCXtYdK0YJuXEjN0sFdHCTyIGko03JjNIhPhIDtaMesRIJ1l48VAmDhLEDpubZJIA Xig0Ei/xkGKSh/crNSRESrEKLkNudpJLCkghKSIxEsUbmPnET9LwTQSr76elYVklX674lc8pb6ge VFep39Q8qL1bZ9c9qNfpXzHcYKw2/tF0n7nO0mF53brRJtuO2f5t/5vjqLPC+VvXUXemR+253Vvn 0/i1/oP+s2m5aUvTbkj7S6ArPZD+Ysbbmd8Nfh5XRib3KM9hB0/BPdWShWQRuT1xVaz3SYzfS3HJ ddKJE+6mJl2R9ptSI24rhP15HR7dN8atKtl8Mi2tIXJyluZGxd4+LhUdb9DeiCdPDROvTTxTMvHa WUdtyVmp5Fe/ee03tr89Y68tqfjN878pw0kEV5r55DCSzoqcHJ6laG4cVuwNNH1cP9wQl7U3DiMT X0Ms7ZnYMyWxZ2LIJlZa1ifZw3YGl0XWal2aSFaxPCs3WlVRUV4vz6qMRrIsMvOrrKquVyrKM2UF MblPvUzdkvLchyuVxRMa+bJIw/IKdWaa1WXWqOV0n6NoTo6te1XOnOIMraLVKGqdNq96flbncHPW K1p7htuT4dDpHBked4ZdO/FLteX9v6stHzSqhj84qmhmr27IVj5v0MkqjWY80+cvmB1uX2512lRG p83u0WkddlNe0+qJq93pNI90t5vnNbEQ5oxMva+6TO1CnYmSV6ndHyPZU28cN9mkBZHxlIiOT71z 3AgfoxA4Y/JOPI165djop5l9mthnPE/KocGFRmlhdiSa80+T0eTLyogYzJJHZSImm0l+JPJ05KcR JWKKmBwZSx096h7S0NDgqK0tKenvt3tr7ZD2CtvZcntFWakU6+db7jiYEIhnIktTzj+HZ+Y5Mx+f yGg6mxhyQeHleDwaVmK5SlixKJGsaLSqWuLF5NVGlLBqn06y5QSDOU69asfEH7cqBmckPSPHKumk pMrsz80MFaRZVAekX0vfnusJWFSK1qSXZk/+UG/Wq9SWgEeVNFp0iqKzGm+cOIC2OTj1jsqkzkSd ZvV5LJ3MjsGiYzZpIfidMSvjP4+ZGf8FE2Lq/8YYzBb7plyB9umTStCeo1Jh0tmtekIqILNIqVQ8 ql+OCv78WQqp5DfMNrYXT6Naj4Z9OKI3Nhx2RselwuPDzu5ZqnGpYGx4lr50XCpODiMlavXpGAU1 icvC63Alq50ad6q20nrsdmWixvJaqzLJap0rvvZA+2U/vmlh920/O1SzdWVLQKdWVDqjzlK+eNfi 5Teur541dPOqhXu6Kq1ag0Y5afM5LK783MCyr/7t7i99+Mhqd6ggYHGmOVzpTn1uSW7z1d86eOCp Q/OiJVGNPZOgJj6EXvsm9AO03/o8rYnxjIaw5PTBXk4bjOV0wVJOB8zk9MFGzifkcvRSadyiaSmL MkY88L+pRcHMomlPyHb0jj7JlLR0Bcal6Kh6GWk42zBtwee5IctK+wOjFpjRdHzY0qWmMZPDiAqz NbAugJoonBWdZa+sqgijRWsri+VIxE5Npbpp+X3v3D/5F29+vlfK+dobd3edqNzx4NWPjB58cHet fOfXPrhvaTBXdUVucMVX3rhjy4kjHR/a6w9/CzUFd64cxJ0XkofpfY+m5abqCZjVE8a4KzC7KxYO G+SOy/a4Xu8MOUO4ubRxSRc3H45Kp6LSs1EpGtX4cR9Jc1cuaFTD7xddWf+u3bjtEtbcbPy2y2nt ibIMjMOocR4Fqc00+fFhc5eGZpAcRg7MDMgCm4+pCnS+NVgNCtupYWZI5aDKYNZN3EoNI2/UmXVq NT4mNVJSh7aj0kMvkiWd2aBqdQQcOm4knSPgcgTsusmtelu605Fm006W6ewBOiY+NPW+sgz2yiVX MntpnSl7gZm9GNPakrIXC6d1BvY6Yc4gmRla3NGY0+nXjEt5Y1ldftoBpUaLktP22hlWcdKoJ4YR N4tGPj7MYqObmR4VWJWYec+i0xd1RFmG+9dOomC0uEem4zpXKM2X5dLBIi3M97QzHTfbprUF3M6A XT/xB61Zq1bjQ/VwbhA9P79vqRd9tZsM0vs+2eBd7H3Eq5DU3YPZ3TPG3YNZbWHhuHvyONqAYerU Sbe00GBbyjpdqSR2ruKPMU/cGu8b+Mhl552D7JZ6da6wn16z3h32+sMuXZrORC/RpFO9IhS/Sk0M pTOHvMhasW2gfme9bC4t9ZaUGIp9PtYk0ahZU0W7ZvxJTZZW7szsMpPJQPsAA+0DDDZENBjQsA20 DzDQOyI4Guent5dd1WX0ec0lvrJiTTCvK9gjBpYGB4aUigap5PnUzWJEEBXfXmGvnVtSUUFHmn5M DD4xDzqopDI5zzQRiQ4kxXKuFLHPLHQ61HulCjq6UOnWxHSuoN8bdurkyQrF6M5wuTNdRnmyVUI1 8PtCTm1hYHOoNNunl/arpauNacGof5s14DSds/CmD45qDVpFhb4Vg/4dwt6q+wuyTWl5gQ9XKPdn FviNemeGm/alaCHfRxmkYz53D2sj2ZpULQGzWsIY1gSzWsLCYUYNNbvXnkFtnkFtnmEzmaUFGSGE ZYzL5UlizxmXDGMajSkyLhnH3F2mGY2Hd6PCuLRX0dDYJ4YR3U3jHx9mCT7afs63H/oP1YyOVfl+ fP83LrpV7wz7abUrSJPcBQu3bFuQf2L2iv7Ce76waFNLtnLr4F3b50wWTxvmwbwsrbdh9cUrFm+t tEy8l9c6BLsMTc1TX6MOo+eYTb7JameGIezIo/eaR+81j44xeXSMyaP1Kw/3GzeQUHpp+uF0Jb08 ZUIwMyGYDd9gNnyzcCQrH5crjjvCBnPRuJR/3Nudo6oel2KjZozbZ58/Q/uZWjFwP99/mrc/+MFa x5HIS1NhIop0cZXZTJMmh5EWfa/t+bQztN+pRS1UpypcLp/VzBLNFN7aTLVEh6UZwzju2mDSuPr2 Hqkvu23olheub+o4+trR639+U5szv76gfXtbnks3+VDuqs/v3Pn5tfnRlbfv3nXnmrzd3qBdE25Y OSezcPn9/7n3zvceWbv8vr/f3XX0yM6iOY1ZVmdEfn37k9cv6r7x8c27n75h4bKbnmIjOeaURtS+ KtJEnmJWzrQV26t1ME01tXI1q1HV1OrV1MzVsNfJ/Dic+Q12alsoxojLGIUCZtUUzAZ0O6ppMr3Y hjHv0Z1xKR73zkXtOhHu8qZmk7Q37z87behy0fa5oZPFcZr0xDAShmnKR4dTSWlbZ107NTJmSKwX zFWKFYzyM9t4uNzjzVToKKfNVLxOj0eqjOZGo2IuYNS4sjPTwi6jar+7qH7Z7D2i9mJu4Cybl9a5 Z1FuZP7q2lBlUZ5rr0U3OdG0xN9Q8dmvNQ3ND6LZ6zAu2kxSWeWKhsjEy9O1GmOBWjHXLN/ROG/T 4jqXJTZnUdnk77IzlKsWbPFqNZMLwrOXoA9unTqrDKGet0t51P6PkXmYylsxUZ9HzQtzMoaZGaO6 g5lZ543LhfFYedzpkhaUx+2YwZdnl5sCPpo2QDvfgA2pAriyhQFadIHHcUwRPfBYgI03p8b8KXZx ftRqx7kpU/ETUi6pJgYpGjfaQ9VSddxokhagLE/FDVRV26vtnjl0oJ0XUOd3e9ACRtW0udBFwVk7 XRjEYv22szZMXJ6nM97pRkMDxAgWGK0uHpdyk8N2A+ZtJ4dZrvk025PDLF81zRjzOdaYaNaxVNYo aokXrko0JL6mK9ak3B+dHGuUocb9X+qft2PFbK9RhfKyVCzZ1VHT35hdvnTL9s1LK2Zv+eyy2IqF c5walaxojFpjSVN/XdWSyrTy7q3bt3ZXSBes+sxQuSeU5csJYnGnzcqLZFYvqaheNLuson7ZrsVd h5YXWf1Bp9HuczowZ06PZGSUzs+pWjSnvGJu9y46D7Kil38J7SyLHKalfNIXRwH57BjvTx2HIqxL R3Gxrh5tiTECwOd3+XQYtU+dOoEwu8ZBp0QZqV69HBOEv7ElxndjttMxdFFJTQaNcXyYRaH9eLmw XvhcAwnTpTHtkuhUUHmJzfGOivnD5FExB1SOsBkgm/t88MXpWr5OZ093OvkqFff54NRZ1cWY98TI Cd5nDxRJIdp7hGhvEqLVMkTnBCFaI7FFZovbSRyTHBJ30g/UYuJJdd1g1nUzRjowMwULR2rP4zjy ijnSGJ0j0eqpRxaG6FLbUiwFRJ3ETEJUOloZRfXrD5ygEemi4Vwlo3OpVNWSsWjgCyq3PbW6Ouej urj58Pi+CxKXNfGZoVNX2L2vvXNfF6YOmHWFnXrptQsfOzy//uJH9ysRYakP/77yauyG9V6xQvEK P1ozZmNFcRQ1I580UIuNZtnRIMYCXSbM5HP50qe84Syd9SezAjTsxDAC1TRULHfKecGyHpAueGhp VkszytXjZp2fhI5QOYoC1k+o0kKKwWGWeyaSBgud2FsM8rOBoMpgt0w8LF9kd7Q5Mb0PRXLMHn/Q rdyP6TyWg5jwh3Jt/rRM14drsjBGr0bf1aD8iFRgO/3frLxD1vnB+SXzFaPeW2lCOVfSEq+khV1p ox1T5bj0nziWA7lWIpkIrROkjpYzooLfoP0dYySgzDrCunFZF3fZvd8llbZKefapSolUSpWVxfMK xqVA3PpslpSVpcp4q7hj7qumhSpSQteKbESxsxXUmn6xcjwdW9NfW8JnPOUYw9dgFmk2eqVK73eH aX5ZLEPPMMnC9gfyLM54a7i4wzT31WGar6+ELixTKyqadawfFSbHRQf1KIw+Y3CvmJUa01MbSio2 tdTyUd5TUV5VrTTY0gNpQcvsz3a17ukqqt/7tS0HPWWLaucOtpeZdCa9ShuYv3xj5eC1y6JfvbFp /fxg35J5O+b6TCZMzkwrG1pyWjbOW7CzI6elcsmsQEYkQ2fzW/0ZaZEMZ2HPZctOe4sa8lu65zeh jO5AGb2g3oWdw7nkUVpGJxoaJEO4KtWawGyUAbNRhbqZ1avGpXfjAXeMzrBiIZRLjJZijLblGC23 2LhsiOuJ21A1K6xSY9NC/Wi0I9BiW1ALOapeSEcEulDzYlxPrdjPWb4/cJKni9KEmEHxpGqaFrV6 IVu90sHdS4d20Shz2UKVdlfnWiffFWIzUMyhtHYPzFsvKy9UDN3cH2tvacnF4tSNmqvROkM+f8ih y+tsa8tbd/2KvIfdlcvjofp4c27Twcb63mq/9Kd9TxxpsUfr8rejgapUWC2pa9jwjo+JP+TXRGyL rkzsa75i/VxHwfzyyTu6V8wZOkDb8ErYOKT8EJs+P2BtOJ3263RqBH6d1mm6rjsO8xG2HYAAtk0A K4LZfPTcNsHUWzQBtguMcXOJRbL4/xSMG8xtwexxST7u7FDeLqNjht7cVlY4LmlG9TD0xPMxusUU Qz3v5z3cafR1tMuIm4L+Pw3zDJw0h5PDzo4y5e1hmskJmome5oLtJmZyJKP7TZ+84cT2nyJZGF3P bTcpIVmt9c/p7C0ZvG3DrHm77uiLdTXN8uk1ssNszZ3TU7f/UDjeP6d2eUPMRNdEX7b77WZ/ToYj fmBs31VPXzLblpblszh9jtxgOC988uEVV/bGsmMRnTMDNXcAVr0LJ1Cj2Jd7kvUuwYbZkjFQS/uU WjqK1NIZTi2tjbW0ctY+gdcUCCnhNi+hNRrhYDaOMEYi5o/YJbQCG5zhFmNtbkBlQdtXJ30d6KBU Y5aF6gV0l4FVXwwh3KipWkx7DnQcBpHQR1MeH/Z1WGha7EXRxHSwZdX3vAX6zD4Cc9LpWowtnJkr gGrlLq093UX3gFvvWDV0w4q88nWfXbv4yrjWFaR1WH9/46VNDaixqMHzwnPjLbl+UWH3L1y+8MrR dXufONLa3CgbxcbERDPq6rqD8aYrNqDuNpbBuv2w7h3ou2M4lvMWs25BSVVD1Y4qxUlbuzMEqzqd 4UI6fyyk1i2kZi9kvTjqzHsnmmJfjcl0e/QE7Q0qVamqDmY1mrmRDMy7cRW1dzhc+P3DqptV8imV 9KxKUqnSS16NdvjeGrDstMgW/VvprDr3p3pwtvvFjF/+qxiv2rTfxdwGBZClKvz+8IUsj2jJq+hB LL63honFhvfzFEu6/q1h5EW3UOkGGOu32T6YhGcB4Rk1GF3KzI1V2Z1bxcpCq9yR659IZrbs7Iqv by8xaY0aRVa0xqrlu+I7HthdN2fXvUNbPzdQdL9y8f65q+uzZFnODXdetLzYnebWWvwOs9NqMvp9 zvpLxi/Z+9jlzU17vtDrvOJo8YIN1bTHyMHJ56vVF2Hn5Vpq+6THRrsK1kUEUj0yZdYTQ7CJD5h1 0Zi0vJcsLcDO/bNxhw2T9hzD2arWtOjZ0rbQAlsb3Z8/iykDZj6nK9iE8HSsgu45x+1VhrPDiFka PTucisuWUJg/zOhlWU10sxELtpqxksIwx+aJGN3Y3EglX61S6zRad2Z+IKcyZPmhzqhXO6w/1KGn xUaJ7pDNRmfbhyJt2zoi87NNOkVtdXotar1R76voqluntac5s0Mfvo2NaRXdnVbcoWxnml3bv+aa 5flmq8mJHUSFzJq8VblO+QGpx9OmtZKH1VS3o6iVtvpWHSpna8jmlBa0VjSMT71L5xFg1t7Brz9K gxq0iyHjZqtDWrA4oLKWKhVaLa2t6Bxg01NxM0RRhTYQ0FYUqWg5xCtRcUkv/YrekA3Jegty4kZw jrVUq9R0vGLqfsPtHqhR3pzTVhCa/3JNx6qXQ4vZJrWjtuEsnRycfZEPfbGKMzF0qV4si+j6x44R zXYmht+Y+KAlk8vyNXW8Mmxyu7vfGKaZz1HeHKbZ18x/ebimI7Tq5WF8RWpXtwEZoSHYvjc9QqKk PB4+Pkaxz+B2ebypNa94qFWNSQqedtFPWnweL2aDWAhPT0rqZSeWxbkWLJT5GHqd03p5JL28//Ci 6qGAwzuv6u3GnUuLKy+4f9e2O9YV2sJlobKS8pxgduXqyxfktwYlm90+Obmhv7S1xLthVVlbibd7 bdeboXyf/siFnRvqA8reSDB7Rcmii7oLMzyO4sxIsWyQw3P7Ztfv7CnLifdVhutrKvz+BYVzB6I5 /fMXXrKsSK8LT/5t9aZQTXte38ZgddvEmroGWecvys9zz2vMKK2nLekOrKzuxfymnNxN68bxhkqp 4NwmcqoJzdhdZrMdJ53ceDONdBAx0n7NSHs4I+vcjDTMQOIIItinw96D5mRRR3aLfwEbFOicBlOa 1GYsn9KwEWGswF9EI2M2Mx2dNi/a96B5if0JzF3ofo9Ge24FNr3UqKpizU65V+fgkxVfcXtp/cEm ONnWo5jDtN7cvvLAgrBftBzZunBNU3Zvz8T1wmfmxKWzfe7G6wbpbs9VU+9LXeoS7EqHyQPUWicb IosjOyKKh3YtMAP43BoLyym4WTMBi7UY64I8T+BJezpx87kjXvVmqcAsFMx7LjdM+aghGEc7wp94 qD/ut7UzG754NpYaVFNjKuvRR/000olhHgum+970g4vz5nxO+jiX1mVUYqn+o7ZxFs6ui1FMW0c5 Qve90RVppdK6gvxagMhTL0zeKq2HLbLxfP0RaouxxeX0aSibfoH/TvsSMB+8IN6hj/ty6N8Hi5nQ SbB4YHbnYH7HEMwEBH103OD3k/JievfY66gfywu2uzBDGFWzngI2sFdUpMxwmtuBjmvHkSaPxj8x jARqmgIzYt7yv0eToC6lNhRTGyCstZ6bEp9nnq7M+PrWUJFPr5IUrV6riXjDJZkW0UNTWxXEZs8u sK4/sCymM5jtDjN9fKN2FbW1K8c+brZUezuI9lZJxlhfbGqokvLLpLK4Q1qIWeWzbMiCYPNe8FvU jswN85U9gVdgs4gpZS0TtSqqHZiZEcysZ6JNMM1TVESo8XhT9GQZ1Xnt6S120QyxJySVYLKKFR0b 5cpfZ5sfsCEmB8aZsVkrRPQZrTBX+oTml3rE7HZptJLk8SgHdc6stEDEZ9VMHvloNZOW6Rz+LJ8/ y603Wycfl7abjWwrUNGa9dLfJ80fb4gfPiddaDDrFUwi9CafbfLxyRy7O9WDSfWwqJt08TaJZ0U7 2LMiZpwZdSxVtabrmvTucYOthTWpVEWiNWiMeeGmZ9zvuerx8RYz3VDOdRq8nNXPYn64RMpk5Rxw 2FCA7Hlu1EY3AnN99HPnUqllRu/KrhButjHMGAUIZq2F9bqZmR6UeGZmOX82RDtf/oCIdb4GtJuT S+g+0JJ6rIlYrZixNmLZws06I8ZInvsE3kwuJzasYzo7sMjRxM3zOupbimraixZMd9oofjqfF3P5 2tQeMw6apDaFaB/O/p5CYLSTduPHhzs75rHcLMPnZyeqU+o58//UsX9aT+/mPb2Xr17d6md5h+/U uQqbimv3NNMGimdQWk9hY3Ht3un+X+NI93oybNoFN7XX9DWV2oq6OluzV1zYHpwuQjlS+5GR4OM+ 2Mkzohrqjbr9PYvTSubllTUVODFELBCjKUq9nIyzUrfyUqdFnxpYP1qyqfGUFxVKOlUD6OZBppGu z/j4SudSfLhlIy0a+MnUEMvGTENRR4E/u10UF51FTY+xsdQzqlQJBUb5MGvEMDudhpYJEn1kwPhf zO/+1IF22tC3L/xfBtrzjAkjDtBxlu4HvAYrOvH06ofMjukN+VKeQ8q3S1GzFDVJUZ0U1UoFipQv S5nUaDAUmNVrMOs8wWwlxcJRAJl0AZVZYpAMLroL46ImddG1movu0bioXV2P43V/7PGftJKFO1Gc OBYgJa0deJonp7Zk6B5BqsaLzQLaY6Z+AqNWmuT4sLVDTRNN78XMXCCkpv/8PMWMB1fKa3V7vrF7 x33bq2r3PLQHXP1woH7r4vYtTeFAw9bFbVubQtIftj92def8y47vBneAD7Zfsa62cu0VCzuuGKyt XHMFtd4dk0eVF2A9umM1Sq1Hd6zCVfQgEx0swKxboG422ECwSoe+A5M6N9+sYttW7FkI37f6xN2q dtviT92t+p83q5Dyf9us+vgA4/70zapb1uQ1zYtni1EG9c/lDji0+QsWdhWtG6GbVRVss6olt+mS xvq+6jTpzQufvLLVllUZmawXe1SqN9GmcazJqL+4oD7fveDII/uaL18/x5nfWDZ5J15vWH8Q1h2A de9KWfck79lh3qAxRnviGJ0Qc4Ox7jhGd1QK8AoPq4gVqQoKZv05mFVcxqh9FWxHxZ3TbpwbC6ps mMSok2kdNXRHxbaQzno+eUdFbKiIdGk04fHhtA4bTXp8mKVFAz+3oSI2BGfZ+UN9USO9Qrg/vqOi p1PqoEub39HWnktNWj702bV5Lc2tBfScnSvdrv3YrsrkcWFZ6Ux+bcQqdlbsObPztwlTT/6Lb63w bUFsrfBeVH4ANq4gV1MLH985S4paU9UWzGormFdfKmi9ttLq65jxIIQ2bZKGWp0T18c6olZ3qN1N t6XYUMamPrwhs9XHaIxFNAyfiwmT0agzmy5d7H3CwoNXTI38gKzR63TejGy3v3RWXWRGbWTDTs68 utoMczg7w6RSJGWdJ9Ou1+t1ruIF1RMJMd851x9eWdWUa1V0BoPeEoBNuqbOys/AJu2SjdU6U0ln Q+fizkOdj3SqZzzqZE2budG7gU+NYRnC3OjyGKOizRuXXo0H+fNOWm0DtNqmHnciOEB7xsDj+Dsl 9MCJAQ5iisMf08tT8SjyazA9YpJNxb+qNrxtX2IfsO+0K/yx5i/ps8cOzxt8+xrW4w80U48zcbhx xqPpktS2IN+Nyqku/hUeZr49TOw2e8iOY4upR5q/ZM8zO9SeN8S+NrLlDzPpztSM0vl//DxTfqZi zRWLSlc0l3oMKvq8MtawvKagqTyQG1/S0xXPzV96YGl2W12+W6tgtmnQ6LOq2ksK4vnuvPjSnu54 rmRpHkZ98vpd2UEnpvuBUMARqcqJVuYFs2L1y+fMGmwvNDncNpPVY7P7bVqP3+OMlKbnzsoLZRXM WUZreHjqr/I21TdIHbmO1fB8Yo8UpboHxigVMCtNMOsmGKMYcGji3bjJay46G2nLMJ/1tpXRVZGW PTE4e4YO/BV8w7X8zGm2iY2szw4jrjfuNZ8d9rZpaYLkMFKw7ZA0G05a8Lmuim122D+6UyW7Z+5n sfUSXWjL23S2UH6xt2V9POMyq4OedLtULLH/RB/COKx/qm71Zqe7dGq9WrUqI8tm0WtycB5AtvCt qhdxsBQPz0zaF/lm1qShf63eoFdbfLDRUbp/rTw5PZcKYgZlzKX1NZfW11x6yCKXdbO5dH6FJ3rv PcofgQZTXQKYWRD8LhvqqKDLUBpBeLB1KVbO7+EBaFF7rlHtb8e0VX1uE5t2AmLeO12BWacR16cS WGiKmVvXNM3M5YPYuZ7esuaPRauqpz2wZ+3IcHsz7JqFt7FJk9bFtwG9JW2l9QeasXeNPQyHfnqq ur9n0ZxN162Ts8RsdOKfi9c25vT2yPuED61pWdjfOQArFkpmWtMewzFojPJ06RHU0c+coJTJRabE tilgHroBQc3kSvW1zhQ7UmxHeLwaEaoxH7NLuTYpTy1l5cFjbpaUnSWFqcSJ1uywFGK+ISk7JOVa pQvDUphuu+rt7rZwCD0JXG/E9eiawiF0M9RFl7vgd+Im5BHOaw8b09qNvNtmD6OxSCWxfjbnivX3 01+JTr7Y2hXHpyECJ0hYsqnZFxnxRdN5sA69IYZuA0VDx0Dt9KG21CN8epjN6a128omGckCSFXny jMqclpeZmee3qCafUaklnTPozYjg6PSkSvlAxhOQgDfTrlXuUekNJu2HX6dHo1U6i0FZYXLoFeya yPjQT6SZTPIf9djElXVGWi6zpt5XH0G5NEtlvFxa0bnOhRHwyAyng2qkaso5xVI0LEVDUjQoRTOl aIaUmy7lqaR8RaqbLc2uk2YXSXMKJVsID/HxRwjZZhNlPPKCRwg52DA+Mm/KcZxvW2il3tZ57Swe NXuDbbFth+2QTWWLOzxttor2nPa6mwulQhpWSPt8m9PTtqlwf6HcDF/vAj0tjheozftPNzScgc15 yWB/lj5bILQ8WKFQwYsknjGv3WoL2uhXqUz8e+Lsi5YUSgr7Ege+JFpYVSjLqKoq/jUosRdQXP2x tfSb0s7gATQ/ZYAdhtR5RCVXy86406OJYm/2vFKcUaDqIyr15H8UszcvM1jgNylPyfIjijktPzOY C9fke2oVFo7e9CyHTnlZxn+TpXegzQUdOvklWXpRxrGmNB/eSVDu0bqs58pZvlGvn9hzrtStLq3e iELHRsZEml6PQjdjHMFe0IRPuGSdgbZMzCQPogZkk128BgRQ62fRVhWQ8gOSjy5Ioj4paqmyyLl6 KY0OwXVpkr8GPNsvBdv9Bme7oVO1mHTSZxZ0/YZmgdKgtqcNgz6+nBkJ1mSxUPvDCn/cXu2MRmG3 ytR6Wqpwsr1tj0srV1ykKStPC9llzUG9TZl8WmfLzszMcunVkqS8q7FnhdKz7ZrJEza72uSySLUq h0FZ7fZZ1HgtwDxRLL/oNKrRjztoXe/DsuQl/B2cGBngd2rDnXroWcsoOx9XgjiV+ia9rM/BCQ15 zN9mRW+OJRdujD6KwdGc/jNo82jbyRw/jYJdzjYrPcRBl1iddBz7tEMcfLueHdMWhzgwcr2k0Vl0 Ey+6A7SlSjdOHrI56bkOWWW049E1/Cb3SffjwI6mBSeUtenhLIvH47fJW8M5OKit1Vg89pDF502z TdyGU8y4+oLJ1/CHvF7H+0cZ9A6TRm86sT1/Bs8mxoxxaB89z5gaELRaXnWrnWK6Le3RWLz269Rm p99p9xok1VVGX3aaP9trvClYWVzkf0ZrwLoEVUhyHg6EbBqNLYTvvH3qP/hDYa/jfad8+p2j9BDU qUfRtjV6BS30DB5gfYtegD4Opw+th33/jL3f7SX1c4optrWWFDcDtKwKlH3SHjxZC+CPl/I7aUVe qRtpFfmw3vP/xX2oo8GKkiLfM1oTawt6yXkoLeTQaBwhumK9VtmvFLPvrCYR+q3HNVmecnxvxRk6 gTmhyYpTp6+hIu0MO4I1fZCBntRJvYCklT7u66EV+X6jN+LzZXmMGrPXdo3a5PA7bB6DpJ70fkKA 26hStV6Wura0zApY/4zOoKWvwOgmz35KAL2HmLJf/tl592DM9Vacuwdjbpw6z90DHX+YBaPRynNV gW5Nf7yCyD+j136tyuzwOWxuo3LE4I34vRGPcfLOGQG4KRULoTerzg3i4n1ndEZcPAYgyQ6L2zUa eyjt0wJQ+g/jkeE9ai8plky0HOLZ2ZlSdoaUnS5FAlJ2mpTtl2iX5JXy2WaMI4Shu5QOEWarvHCg VCL07DTJp+M4QsBsR4YxRh4wm4+B2TQsnx7AtmT6aCKfkX4aMbV4nb4vBH5+DHmCT9GsZvifolME uN+J65HiXryn5sQxvYaxyNJ87IVp+esf5Q0TaACpacEZPEHkj3Jj36XLDcwgzo1P2PB1xiM0hxPD yEJD8xBvgKBTmW62kXMHwtADaPhYU52T2oLEazE4/XePBm8/TKzWmowaDd71kCzv0we2OBOplwpU JhQeZnCat3QWvbqJLhy0tjS87mHXK7/4nEFlzvTafTaT5mlFhYfyeF7+wU16exrKZDfK5C6ccK0n P2JlYs6vkmKZUn4GnRHEqfG91PhxyUO3tTysR/VQY3rG5aJHK3Lwj9SmSqT2cfx9UiNMChMa6YTA CFsb7TW1oVAtnosXP1rh0RR327CrkyfsyFdx9B0afhbwDD2iynZ3mCXZSB84ybMopnngAR7PRUOz OWdK5IB1G80o1RFOW5ROuD5y5EvDH6DTxsDOVd6l1lv1E7MsbqtWMVhNH6zYUutIn7Wkkh340qKO 470t3+y+C2avubG/2NN69Y4zcgXeT1N30AOlWlumx5Xp9Zolw+pbLloXiy2sy8rKy9I5Mt1Yolnc 2RHfrNWXNNcfuOmR3S/qHezNm01YfdwCq/dKrdTqj2FT8lQ8nRp6pVSmg6HL6Cq5jFm7jFq7bFye FTcs6o4uWuTDzBYF80Y8iihROo2KwzcaVywBmpKvr1nKAE2Jh+isOQRQXicIXdbQx2DH8V3EkmoO YNaSwKfiThSeZXYc2c6mE7oFJbMl1kzgQTluoJ6z7bPtHhxCM8YN7d2F/wiF1O30sLFx+rBxydla 2/R54xgeKGLyhjOefOmIx+zseTt9Ts538mhhY0JhxQkiheXdzjI3D3eHCv8xzLKnZ46NGI/FmeOS 2LmFOoo8teukYU8e+RkoVujiAXvq3VK66WxhR9ExPJ6rBu5MRbmlfu+DF8zb1Vtn1WkUi1k/q3tH 0/z1TVmx7osXHkBpazVGi37X/C3tuWmVXbPqBheUG1A1FFmjc9b17IivvHZVUah+5ezGHUuKpN19 N22sdmcELRZXhjs7PZQTyqrvKa/ujWehVbqdfqs2K95XnddeFYzkRdTWgMfqtVucqCnFy/a1zt3S VWuUtbOWXICevxQrrJ/jzG4Bes0c1kLr6LS9SMotlLJzpeyolJMuRQNShHWfOT4pxytFPVLULUVd UtSGrS0pWy1lq6RYQGJ9qYPWslKpyOOD8NAulj1HRvFSPonS96QX432AqQ/jGYhho83eRmujjS6O bXRxbKMrYht9EzCXqHhPioNEz9JmTw8WxQ0IVqlKS3ID2CxEFVHFwjabIbzUQF9wwdEIR23F2fJy u0Oix4Viqf0E+nopPXhBj8ahD50xx2cTffoRGMsN0I1LY9w4PCNPtvKimcbK+RHq8w7GiI5VvKPq RmfqkSJSWPm5y3GLeG9o4i2TzayWNQat9JzamVmYGS7LtN1id09+SZ5cJT0g7QxHJ98R22iSTWPL 9Dkz/V6z4sAuJF4yNus//F5EfnOijs5yNqB134ZTw/XkQ96n5lZLuVXssYLC+tRHaRnEpepUvwnG e8FoVtX0AHkeGlkejJ5H22CeZXH5jvJD5Ur5J79I9DhecCUYD5EhmvUpetoLm5RQJ+mBXqfTh3ZU GDcV1v0zlIWTuOrCLryTOaOZ9uNVAPqYTbK9mGqdp/uf5w2VFwMth8BxZFTIcrIPZ9X9k57BNSos NzXNbmarZNtmyPG8JslOJLHXYHlHzKaJ4q0+PNGNhO18jaDc1nJ4dHjO8LIqK97mxma51lDQuqWt cWdXcW7XweVze6PpvmCGPFdnNahdjsmMSHvpjvt31Er3bv7yjjq732cx2dMcdrztiOO2oaZNHfVr G4KmtBzZGg7p0Vdn501+Ti3PGhzBQUSUkwOgPxpiIaS9sXlla2uscXB4y7rdW/4PLYTC5AplbmRz dHJlYW0KZW5kb2JqCjMzIDAgb2JqCjE3NDA0CmVuZG9iagozNCAwIG9iagooVFpESVNUIFF1YW50 aXRhdGl2ZSBQYXJhbWV0ZXJzKQplbmRvYmoKMzUgMCBvYmoKKE1hYyBPUyBYIDEwLjEzLjYgUXVh cnR6IFBERkNvbnRleHQpCmVuZG9iagozNiAwIG9iagooU3RldmUgQ3JvY2tlcikKZW5kb2JqCjM3 IDAgb2JqCigpCmVuZG9iagozOCAwIG9iagooV29yZCkKZW5kb2JqCjM5IDAgb2JqCihEOjIwMTkw NzE4MTM0NjE1WjAwJzAwJykKZW5kb2JqCjQwIDAgb2JqCigpCmVuZG9iago0MSAwIG9iagpbIF0K ZW5kb2JqCjEgMCBvYmoKPDwgL1RpdGxlIDM0IDAgUiAvQXV0aG9yIDM2IDAgUiAvU3ViamVjdCAz NyAwIFIgL1Byb2R1Y2VyIDM1IDAgUiAvQ3JlYXRvcgozOCAwIFIgL0NyZWF0aW9uRGF0ZSAzOSAw IFIgL01vZERhdGUgMzkgMCBSIC9LZXl3b3JkcyA0MCAwIFIgL0FBUEw6S2V5d29yZHMKNDEgMCBS ID4+CmVuZG9iagp4cmVmCjAgNDIKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDQwMjQ5IDAwMDAw IG4gCjAwMDAwMDY5ODIgMDAwMDAgbiAKMDAwMDAxMDEyNyAwMDAwMCBuIAowMDAwMDAwMDIyIDAw MDAwIG4gCjAwMDAwMDY5NjIgMDAwMDAgbiAKMDAwMDAwNzA4NiAwMDAwMCBuIAowMDAwMDEwMDkx IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDAyMTI3MSAwMDAwMCBuIAowMDAwMDAw MDAwIDAwMDAwIG4gCjAwMDAwMTkxNDQgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAw MDEwMjYwIDAwMDAwIG4gCjAwMDAwMDcyNDggMDAwMDAgbiAKMDAwMDAwNzMwMiAwMDAwMCBuIAow MDAwMDA3MzU1IDAwMDAwIG4gCjAwMDAwMTAwNzAgMDAwMDAgbiAKMDAwMDAxMDIxMCAwMDAwMCBu IAowMDAwMDEwODgyIDAwMDAwIG4gCjAwMDAwMTA0ODAgMDAwMDAgbiAKMDAwMDAxMDg2MiAwMDAw MCBuIAowMDAwMDExMTIzIDAwMDAwIG4gCjAwMDAwMTkxMjMgMDAwMDAgbiAKMDAwMDAxOTcyOCAw MDAwMCBuIAowMDAwMDE5MzQzIDAwMDAwIG4gCjAwMDAwMTk3MDggMDAwMDAgbiAKMDAwMDAxOTk3 NiAwMDAwMCBuIAowMDAwMDIxMjUwIDAwMDAwIG4gCjAwMDAwMjIyMzkgMDAwMDAgbiAKMDAwMDAy MTYyOSAwMDAwMCBuIAowMDAwMDIyMjE5IDAwMDAwIG4gCjAwMDAwMjI0NzUgMDAwMDAgbiAKMDAw MDAzOTk3MCAwMDAwMCBuIAowMDAwMDM5OTkyIDAwMDAwIG4gCjAwMDAwNDAwNDEgMDAwMDAgbiAK MDAwMDA0MDA5NCAwMDAwMCBuIAowMDAwMDQwMTI2IDAwMDAwIG4gCjAwMDAwNDAxNDUgMDAwMDAg biAKMDAwMDA0MDE2OCAwMDAwMCBuIAowMDAwMDQwMjEwIDAwMDAwIG4gCjAwMDAwNDAyMjkgMDAw MDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSA0MiAvUm9vdCAxOCAwIFIgL0luZm8gMSAwIFIgL0lEIFsg PGMxNzkwZDhlNzRiZDVkNjczZjY0MGYzYjU1NWU1ZjgxPgo8YzE3OTBkOGU3NGJkNWQ2NzNmNjQw ZjNiNTU1ZTVmODE+IF0gPj4Kc3RhcnR4cmVmCjQwNDI0CiUlRU9GCg== --000000000000b688cd058df4e599-- From nobody Thu Jul 18 06:51: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 B1519120290 for ; Thu, 18 Jul 2019 06:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 vSQrDkCqQgRG for ; Thu, 18 Jul 2019 06:50:54 -0700 (PDT) Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (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 7A0B312027C for ; Thu, 18 Jul 2019 06:50:54 -0700 (PDT) Received: by mail-vs1-f43.google.com with SMTP id u3so19137412vsh.6 for ; Thu, 18 Jul 2019 06:50:54 -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:from:date:message-id:subject:to; bh=zNhAo8R7XATUUVp0/HODQGP7koFxcca+sZs2nwXIiaA=; b=Kau3SFVeuj8bcWzmXTEIGiiL1f8bGS9C0kXg+mqZg0i5ZCIJZv8ZRxc90qSiQC5CtH rkfLMXms03EWusuulxGwmP1/M5iZSOlgoekPqBIEi4sUPzVzhkPTcd0Zg2BD5l8WeqvR bjrnYC9fJqtLbOyYcsIKFNqdtMNZ4J87fR4fGWBWDbBEIkkSVQRTX9/5Ghr3hRwbl5Rh tGlk2kLBno2PGC2O2d4JD6/vXTbGEwdoLTGPc8H9XgOPY363L/DcID6K5sJkGBGpwK3a a6jSqr++o378zmesH/+VAhdBvlt6pi32u4suyn9AXweyb56FP6PxSCtICWmgn7vj0Cr9 R5KQ== X-Gm-Message-State: APjAAAWaLWxPh2w3HlGXBfjiKHuVWP65REnTu9XdMuUycCWu2Z2GmkRK 5wlGt7tAOLgyo6qXOG2CGVrfuP7bmNpVE8fd370XrLZQ X-Google-Smtp-Source: APXvYqzzTwJW6TFwo3Txz401BakNqsj98DqjyWM1F636Y/pn042CuwYRsrETaOcjoIr3cSCCwBhzpmAvsLd7yPW9hY0= X-Received: by 2002:a67:fb0d:: with SMTP id d13mr29501179vsr.69.1563457853396; Thu, 18 Jul 2019 06:50:53 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Thu, 18 Jul 2019 09:50:42 -0400 Message-ID: To: IETF-Calsify Content-Type: multipart/alternative; boundary="000000000000f91ce4058df4e57f" Archived-At: Subject: [calsify] IETF105 agenda 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, 18 Jul 2019 13:50:57 -0000 --000000000000f91ce4058df4e57f Content-Type: text/plain; charset="UTF-8" Hi, Calext will meet in Montreal on Wednesday July 24 15:50 - 16:50. Following up the scheme of our interim meeting collocated with calconnect, it might be good we go through all current draft. If you believe a presentation is worth being made, please indicate the time you need and provide the slides by Monday July 22. If you believe that is not necessary, or you are not able to do it, please provide a note on the mailing list of the advancement of the draft, issues to be solved, date of the expected new version, as well as other information you believe is useful. Please find a draft agenda below. calext agenda * chairs slides (10 minutes) * draft-ietf-calext-eventpub-extensions-13 ( 10 minutes Michael) * draft-ietf-calext-jscalendar-17 and draft-ietf-calext-jscalendar-icalendar-01 (10 minutes) * draft-ietf-calext-subscription-upgrade-00 * draft-ietf-calext-valarm-extensions-00 * draft-ietf-calext-caldav-scheduling-controls-00 * tzdist & IANA (Daniel 10 minutes) Yours, Daniel --000000000000f91ce4058df4e57f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Calext will meet in Montreal = on Wednesday July 24 15:50 - 16:50.=C2=A0

Fol= lowing up the scheme of our interim meeting collocated with calconnect, it = might be good we go through all current draft.=C2=A0

If you believe a presentation is worth being made, please indicate the t= ime you need and provide the slides by Monday July 22.=C2=A0=C2=A0
If you believe that is not necessary, or you are not able to do it, pleas= e provide a note on the mailing list of the advancement of the draft, issue= s to be solved, date of the expected new version,=C2=A0 as well as other in= formation you believe is useful.=C2=A0

Pleas= e find a draft agenda below.=C2=A0
calext agenda

* chairs = slides (10 minutes)
* draft-ietf-calext-eventpub-extensions-13 ( 10 minu= tes Michael)
* draft-ietf-calext-jscalendar-17 and draft-ietf-calext-jsc= alendar-icalendar-01 (10 minutes)
* draft-ietf-calext-subscription-upgra= de-00
* draft-ietf-calext-valarm-extensions-00
* draft-ietf-calext-= caldav-scheduling-controls-00
* tzdist & IANA (Daniel 10 minutes)
Yours,=C2=A0
Daniel
--000000000000f91ce4058df4e57f-- From nobody Thu Jul 18 07:26:38 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 2B28B120374; Thu, 18 Jul 2019 07:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.558 X-Spam-Level: X-Spam-Status: No, score=-1.558 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 5E95a6-oPClt; Thu, 18 Jul 2019 07:26:34 -0700 (PDT) Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) (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 7403412036D; Thu, 18 Jul 2019 07:26:34 -0700 (PDT) Received: by mail-ua1-f53.google.com with SMTP id v18so11199055uad.12; Thu, 18 Jul 2019 07:26:34 -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=vtRLVfG3afFUwpGImiD6FOgV89SY75Re5ZaPbvubZsI=; b=MGtObYuPqY2l2mBCX91nWXvBJapxZxR9calMhq9wxuem6FW2Rw1vrmAldqq9dw2TlT slnWDwtT/5vpj2U/1qYkxAn724TzrrXpoq98GcyZ+S9YTrB30+l/mEZM1ufyJYh+3yHx aZRFzd6hn+beI+nc1zktV6qvjVeY4KjvdfPbVIFToAdwEevyX6beixz+tVOlRpNzXxuJ Yx8U6NxWKydrSS8Zw7J4mEMpzO97mpE7MCzgzzYTC22rfECK9I7/TQ8TYP465t86cR/s IWfSJGAVv/OWImK2SEiKVolm1p1Q2urw92Oe6YKVnVEvOQ7Dfi3iOqCJU8fPzlNWEpJy 80Rw== X-Gm-Message-State: APjAAAWOIra7jvb6XLAlMucBvUng3go2Vv42/Zagz9HF37rUao7Ui5q0 tTOEWMaAAYK8glSRuiGyaNdLts0NENuXhL2+8DQ= X-Google-Smtp-Source: APXvYqxccT3yJc4Ai0/3d0tSwnG/pG1/JQgi3QJt2W5zo2idGh55MMulu0uZznHWPxdUmSSKRPCcnWe0qLOlFCeGTEQ= X-Received: by 2002:ab0:70ab:: with SMTP id q11mr4468306ual.88.1563459993560; Thu, 18 Jul 2019 07:26:33 -0700 (PDT) MIME-Version: 1.0 References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> In-Reply-To: From: Daniel Migault Date: Thu, 18 Jul 2019 10:26:22 -0400 Message-ID: To: Eliot Lear Cc: Martin Burnicki , IETF-Calsify , Paul Eggert , tzdist-bis@ietf.org, Michael Douglass Content-Type: multipart/alternative; boundary="000000000000896c20058df565fe" Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 14:26:36 -0000 --000000000000896c20058df565fe Content-Type: text/plain; charset="UTF-8" On Thu, Jul 18, 2019 at 4:40 AM Eliot Lear wrote: > > > > On 18 Jul 2019, at 10:29, Martin Burnicki > wrote: > > > > Hi all, > > > > Eliot Lear wrote: > >> Hi everyone, > >> > >> While the IANA does a great job at servicing our assigned number needs > >> and delivering the TZ database to developers, they is not set up, nor do > >> they have *any* experience, to handle the load that end clients could > >> place on them. Moreover, they are in no position to support millions of > >> people if something goes wrong. And make no mistake: something will go > >> wrong. I would be okay with a limited tzdist service for those who are > >> going to be distributing the data themselves, but the order of receivers > >> should be on 100s not millions. > > > > Wouldn't it be nice to have an infrastructure similar to what the NTP > > pool provides for time synchronization? > > > I guess I would want to see commitment from those who provide TZ service > to their customers today to go to such a new service before investing a lot > of money. Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any of the > others want to use it? I also realize that ICANN is well positioned to > fund this sort of thing, but it is not clear to me that it is right for > them to do so. There has to be a real need, and those who really need it > perhaps should foot the bill. > If these companies are on the list it would be good they share their thoughts, otherwise it would be good to contact them if any of you have some contacts. Yours, Daniel > > Eliot > > > _______________________________________________ > Tzdist-bis mailing list > Tzdist-bis@ietf.org > https://www.ietf.org/mailman/listinfo/tzdist-bis > --000000000000896c20058df565fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 18, 2019 at 4:40 AM Eliot= Lear <lear@cisco.com> wrote:


> On 18 Jul 2019, at 10:29, Martin Burnicki <martin.burnicki@burnicki.net&= gt; wrote:
>
> Hi all,
>
> Eliot Lear wrote:
>> Hi everyone,
>>
>> While the IANA does a great job at servicing our assigned number n= eeds
>> and delivering the TZ database to developers, they is not set up, = nor do
>> they have *any* experience, to handle the load that end clients co= uld
>> place on them.=C2=A0 Moreover, they are in no position to support = millions of
>> people if something goes wrong.=C2=A0 And make no mistake: somethi= ng will go
>> wrong.=C2=A0 I would be okay with a limited tzdist service for tho= se who are
>> going to be distributing the data themselves, but the order of rec= eivers
>> should be on 100s not millions.
>
> Wouldn't it be nice to have an infrastructure similar to what the = NTP
> pool provides for time synchronization?


I guess I would want to see commitment from those who provide TZ service to= their customers today to go to such a new service before investing a lot o= f money.=C2=A0 Would Red-hot, Apple, Microsoft, Debian, Ubuntu, or any of t= he others want to use it?=C2=A0 I also realize that ICANN is well positione= d to fund this sort of thing, but it is not clear to me that it is right fo= r them to do so.=C2=A0 There has to be a real need, and those who really ne= ed it perhaps should foot the bill.

If = these companies are on the list it would be good they share their thoughts,= otherwise it would be good to contact them if any of you have some contact= s.
Yours,=C2=A0
Daniel=C2=A0

Eliot


_______________________________________________
Tzdist-bis mailing list
Tzdist-bis@ietf.or= g
https://www.ietf.org/mailman/listinfo/tzdist-bis=
--000000000000896c20058df565fe-- From nobody Thu Jul 18 07:32:37 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 B4C2712061F; Thu, 18 Jul 2019 07:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 fqZZvck6MuGz; Thu, 18 Jul 2019 07:32:30 -0700 (PDT) Received: from ppsw-30.csi.cam.ac.uk (ppsw-30.csi.cam.ac.uk [131.111.8.130]) (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 B230D120615; Thu, 18 Jul 2019 07:32:30 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:35080) by ppsw-30.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.136]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1ho7SM-001nvL-dS (Exim 4.92) (return-path ); Thu, 18 Jul 2019 15:32:26 +0100 Date: Thu, 18 Jul 2019 15:32:26 +0100 From: Tony Finch To: Steve Crocker cc: "tz@iana.org mailing list" , IETF-Calsify , tzdist-bis@ietf.org, Paul Eggert , Daniel Migault , Martin Burnicki In-Reply-To: Message-ID: References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA -- estimating the operational parameters 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, 18 Jul 2019 14:32:35 -0000 Steve Crocker wrote: > Early in this thread it was mentioned the the time zone database should be > served in a fashion similar to DNS. We could just use the DNS :-) As Paul pointed out, TZif files are not very big. I have experimentally shoved the zoneinfo files from my workstation into a DNS zone I happen to have lying around. I've deflated (RFC 1950) each file (RFC 8536) and picked an arbitrary RR type 29818 = 0x747A = 'tz'. The result appears below as a hex blob (RFC 3597) which does not quite fit in the Ethernet MTU, but you can get the answer over UDP if you allow EDNS with fragmentation. It's signed with DNSSEC so you can be sure I am to blame. https://pbs.twimg.com/media/DY5rHo_WAAEISGh.jpg ; <<>> DiG 9.15.1 <<>> +dnssec +multiline London.Europe.tz.dotat.at. TYPE29818 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32632 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1420 ; COOKIE: 30e31bd663d426f6eb79a79f5d307ef6114d7eabab9d3c0e (good) ;; QUESTION SECTION: ;London.Europe.tz.dotat.at. IN TYPE29818 ;; ANSWER SECTION: London.Europe.tz.dotat.at. 3412 IN CNAME GB.tz.dotat.at. London.Europe.tz.dotat.at. 3412 IN RRSIG CNAME 5 5 3600 ( 20190728110326 20190718100326 56700 dotat.at. R7ynL3bJ7uScgbF3GNSKzuXZZZKnTF6ZKObqh9y5LIwI voZSo46m1jv6HwkQBUDvmMSYzSfW0TDqzxz6BDrxb+VG aBITB2DyJeI6OXcJYQXbyGpqP9Brc7k5B6js1oyFOMru hLDqOxSlZTIW3pimnV17LQqI7ve/FPygHN26+rE= ) GB.tz.dotat.at. 3412 IN TYPE29818 \# 1751 ( 789CEDD67B74CF751CC7F1DF9A61CBE5438CCCE5A3B9 34CDFC36914B4BEE8D6DB9FCD22FD208439666691969 3995E238CE5B472DA13E2296582E5B2E4BAE0DD19026 26B985CDFD9A319B3ECF2F754EC7395DFFEDF73BDBE3 B7DF3867E7ECECFD7C79FA0E8F8F70DDF1287FFB83C7 A5DBAFABBC663FCD6CB4D8CCDCE3A767ED709BD9F336 9A0F67CD361FA5D532E6CDD57A4EF20DF3F190597AEE B82D665EEC4AF349BB623DBFE100BDA0718E4E6F12AA D34F159985AEDD66615E75FD59E179BD6873825EBCF5 3B9DB120567F6E52CC92B7DC7AE93B3BCDB2C468B33C 6999C9EC1166B2A2FAEA2FDCCAAC8848362B2B5F34AB AA7ACDAA73DF9BD5852E9DBDF782FE72FF937ACDCADD FAABA5A566EDFB597ADDCC20BD7E4C9ADE30B6446FF4 A6E84D3DE799AF5BF5D3396DD6EBCDDE3D6673BEBFF9 26B0917C93F6946CDB5557B6BFDC56BE5DEA92DC015E B5438EC8CE91CFC8AEA440B5AB38427D37BC54EF1E14 62BE8F3AA4F3EAD637791D4A24EFE021B5277691DE53 EA6BF6864DD57BAFBDABF32B25EAFC53A7F5FE6335CC 8FDB72F5814DD7CC4F9927CDC18C407D68FA767338E9 317364C4687DB45713F3B347CCB1880AE678E4627D22 28441754F39882E2BB7561C9287D32FF8C3E75A0B73E BD7A873EB3FCBA39FBC1527D6EC25073FEA3F1FAC2C0 287331354E5FEA16AF2FC7B5D757EA5734BFB40BD657 5DE74C513D3F5D746897B9567A425F5FB7DC1417F89A 1BE33E33259BB3137D1373749910AFF6EB91AECBFAB7 D1E5DC9375B9C2DADA5F2568FF2DA53AE07CACBE7B59 2D5361A75B579C76C3545A5255571EF5935133C24C95 9EEB4CD51465EE09FFD854F35E34D5834F4960AB1CA9 E1FBADD4AC992E358F7E2EF7164D965A1BA749D0E105 AAF6A20C5567FD2455778AA87A7346289D90A4EA4F88 51F7457B54F0C066AA41684BD5B05B776954A1A66ADC A4A934BEF2A08404549690BC40695278411EC82C92D0 ADBBA5E9F47C09FB344B9A8DFE52DC93D2C47DA2812B BCFF3E159194A99A4766AB077BBDA75AD499AD5A468C 512D4B5255ABA0E9D2EAC040D5BA3859DAACE9A8DAEE F7CAC3F3E32432BB8D3C32B1BDB49B595B1E8D0F96F6 6FB4561DBAF849C7C141AA53C313D2B96389EAE2B755 BA061F545DCF1E5751BEEB5554EE16D5EDE85CD53D63 A18ADEBE5662A64E51B18BE6C8E32347AA1E535E979E 4F4E965E0943A4F74309E289EE2A4FD488953EA121D2 E7AA5BBCD5BB28EF0F55E5A92BF7ABBE5F5C967E7901 EA695345F5CF3CAD9E49BDA4E2A6E7AA0171796AE0F8 93F26CBB156A50FFED32B8DE0C35243243E2CB67C9D0 3A22430BD2645849920CDF9222CF1DF0C888F47E9290 334A3DFF76A48C9CDF5BBD30AC9E244E6CA146F57C58 25C5D7502F86D755A33B5F532F5571A9E466D525F9FC 1135A6D25519B373934A39BB4FC62E99AFC6E566CB2B 3336C8F88CD9F26ACA3C499D9A2A77F9FCD3A7EFEFCF 5B5FFDFDFF59A6EC9D6FFA95FDB367B93FFFF6BF7BDE BC79338B7B5649F994F9EDC8D5D63E1578C755E68FEF F3393AC6E3EAD0DBE3EA8A9DEC0B978F8F8FFDB87515 AD9EBFBE9D977FBB9D45B7DFB03FC4CD5AFDFDB721B7 D4D1DE53E4A6227715B9ADC87D456E2C7267915B8BDC 5BE4E6227717B9BDC8FD456EB0A3BDC3C82D76B4F718 B9C9C85D466E33729F911B8DDC69E45623F71AB9D9C8 DD466E3772BF911B8EDC71E4963BDA7B8EDC74E4AE23 B71DB9EFC88D47EE3C72EB917B8FDC7CE4EE23B71FB9 FF4803900E38DA16203D70B44D40BA80B401E903D208 A413482B905E38DA6620DD40DA81F4036988A3ED88A3 6D09D21347DB14A42B8EB62D485F1C6D6390CE20AD41 7A833407E90ED21EA43F4883900E212D427A843409E9 12D22647DB27A45148A7905621BD429A85740B6917D2 2FA46148C79096213D439A86740D691BD23747DB38A4 7348EB90DE21CD43BAC7DF1AED43FA873410E920D242 47DB43A4898EB68B481B913E228D443AE91C12DB4AA4 974833916E22ED44FA893414E928D252A4A748531D6D 5791B6227D451A8B7416692DD25BA4B9487791F622FD 451A8C74186931D263A4C98EB6CB489B1D6D9F914623 9D465A8DF41A6936D26DA4DD8EB6DF3C6838D271A4E5 48CF91A6235D77B46D47FAEE681B8F741E693DD27BA4 F948F791F623FD473600B203902D80EC01641320BB00 D906C83E70B41B01D9098E762B207B01D90CC86E40B6 03B21F900D81EC08644B207B02D914C8AE40B605B22F 1CEDC6407686A3DD1AC8DE403607B23B90ED81EC0F64 83203B04D922C81E413609B24B906D82EC1364A3203B C5B1E0D6EF97BD826C1664B720DB05D92FC88641760C B265903D836C1A64D720DB06D937C8C641768EA3DD3A C8DE71B49B07D93DC8F641F60FB281901D846C21640F B9FE1F44FF7D1005D8EFB8EDBF088D691ED622CCDD2C 3C3426DCCDAB805F0162E35BFB ) GB.tz.dotat.at. 3412 IN RRSIG TYPE29818 5 4 3600 ( 20190728110326 20190718100326 56700 dotat.at. JMbEh9MzMHhSIuLF+capNcNEkoa5Q2McgQSBpjS84w4v ROpglw84OgCYunhmI5xmxVgqCUHd4+romQK86xvfit9j 4Gs2kHTKOEjcxfvVbxLoUGkjZOe6zBeaT2tXRx/gQnUq +md2j8+NKEbcRi8oL4YdDjdMsmFo5SntpbRd19E= ) ;; Query time: 0 msec ;; SERVER: ::1#53(::1) ;; WHEN: Thu Jul 18 15:15:18 BST 2019 ;; MSG SIZE rcvd: 2209 Tony. -- f.anthony.n.finch http://dotat.at/ Fair Isle, East Faeroes: Mainly southerly 4 or 5, increasing 6 at times. Moderate, occasionally slight. Occasional rain or showers. Moderate or good, occasionally poor. From nobody Thu Jul 18 08:52:55 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 BE7691207AB; Thu, 18 Jul 2019 08:52:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 AG22EjsgpMLd; Thu, 18 Jul 2019 08:52:44 -0700 (PDT) Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) (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 547C212078D; Thu, 18 Jul 2019 08:52:37 -0700 (PDT) Received: by mail-qt1-x843.google.com with SMTP id l9so27683459qtu.6; Thu, 18 Jul 2019 08:52:37 -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-transfer-encoding:content-language; bh=0qAq9+FWinxfS/5PG7x2hII2gb0HtVpJydafcWDZ9sY=; b=PamaDIvKd+GunC71uSsZSD5ntBUvlcLRFeRwKReDDVMstHA/MNKSOdCwn6SdKRMA/+ 2tT93ARyJDdgN539ZrQri0R7wE3Nu5fLlw0FmGbKJv7OkhmJZCzY1PmJEterg1WSW1Sh Yg3PL5JZdX9HRfEe7jiYBLN0mvuR5SXNYD01IRWPEX2DRVWW1ZBtsi/44dNP5XVDHaut XzhLIer0hYQKPkHJlPVCh0831kszrF/qnEt/6YtPx5y6iAWOVemASztMgO76g+0buk+c 00GaAQ+x+KEEnmlfPYtiONVBF8gmkua59MsKaeD3HO6DXy2BjfRmZM2zYid72rPzXlen aseA== 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-transfer-encoding :content-language; bh=0qAq9+FWinxfS/5PG7x2hII2gb0HtVpJydafcWDZ9sY=; b=sAckkMXkvGPOlPAX54PXbfCw0IZyOfYo/MZHyQv4vmZE8+r/CkSYlKYt+5WdglY8Ya Eo4I9DGPisBWsUre2U2gXr4/Q6pSEIG/7yO1b/SbCwMeBa7W/LUTrImPXcmhNlq9id0W tt6WBxcTeuJIL6dKOsQ5eFtc5JfCcXWti1GtOyjq5JwR12AstI0CfyjfoS+fmzKrSTEK Wr7ui0uYk8BeQtJaiZHyt6SJ114S309aIQjFlZ6SrUFmGUzddmdSwE7jqlpMqiBpPiin 2INhFj5usHXrj3puTMczy3uFpWKgAf5fleStyDJUKsooCpP2LiS+/xtkqJsFqvYuKk88 n77A== X-Gm-Message-State: APjAAAWR5LKSRb/Vu/wtRIQeb562LPymHZhT4KF8Ynjdgp2OSRfAk7Se RRyOOv0D8x7aWNkFeq6y0Hr086d5j9E= X-Google-Smtp-Source: APXvYqykmJfxyvJIHV4QoYseqpsLnDOt5D0GcPW7XcvpmCX9/TT3VIG8FI34yFEZOUHlR+BJYv0Isg== X-Received: by 2002:ad4:4112:: with SMTP id i18mr33819663qvp.175.1563465156259; Thu, 18 Jul 2019 08:52:36 -0700 (PDT) Received: from a-192-168-129-25.dynapool.vpn.nyu.edu (vpnrasa-wwh-pat-01.natpool.nyu.edu. [216.165.95.84]) by smtp.googlemail.com with ESMTPSA id d31sm15014666qta.39.2019.07.18.08.52.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2019 08:52:35 -0700 (PDT) To: Tony Finch , Steve Crocker Cc: Paul Eggert , "tz@iana.org mailing list" , IETF-Calsify , tzdist-bis@ietf.org References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> From: Michael Douglass Message-ID: <6f0f4df8-d054-48e5-a9c3-5ca9a1d1f917@gmail.com> Date: Thu, 18 Jul 2019 11:52:34 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA -- estimating the operational parameters 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, 18 Jul 2019 15:52:53 -0000 On 7/18/19 10:32, Tony Finch wrote: > Steve Crocker wrote: > >> Early in this thread it was mentioned the the time zone database should be >> served in a fashion similar to DNS. > We could just use the DNS :-) As Paul pointed out, TZif files are not > very big. DNS keeps turning up as a suggestion. However, just because tz distribution has some vague similarity to DNS doesn't make it a good idea. I'm sure it can be done but a simple RESTful interface over https is simpel and easily implemented. > > I have experimentally shoved the zoneinfo files from my workstation into a > DNS zone I happen to have lying around. I've deflated (RFC 1950) each file > (RFC 8536) and picked an arbitrary RR type 29818 = 0x747A = 'tz'. The > result appears below as a hex blob (RFC 3597) which does not quite fit in > the Ethernet MTU, but you can get the answer over UDP if you allow EDNS > with fragmentation. It's signed with DNSSEC so you can be sure I am to > blame. https://pbs.twimg.com/media/DY5rHo_WAAEISGh.jpg > > > ; <<>> DiG 9.15.1 <<>> +dnssec +multiline London.Europe.tz.dotat.at. TYPE29818 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32632 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 1420 > ; COOKIE: 30e31bd663d426f6eb79a79f5d307ef6114d7eabab9d3c0e (good) > ;; QUESTION SECTION: > ;London.Europe.tz.dotat.at. IN TYPE29818 > > ;; ANSWER SECTION: > London.Europe.tz.dotat.at. 3412 IN CNAME GB.tz.dotat.at. > London.Europe.tz.dotat.at. 3412 IN RRSIG CNAME 5 5 3600 ( > 20190728110326 20190718100326 56700 dotat.at. > R7ynL3bJ7uScgbF3GNSKzuXZZZKnTF6ZKObqh9y5LIwI > voZSo46m1jv6HwkQBUDvmMSYzSfW0TDqzxz6BDrxb+VG > aBITB2DyJeI6OXcJYQXbyGpqP9Brc7k5B6js1oyFOMru > hLDqOxSlZTIW3pimnV17LQqI7ve/FPygHN26+rE= ) > GB.tz.dotat.at. 3412 IN TYPE29818 \# 1751 ( > 789CEDD67B74CF751CC7F1DF9A61CBE5438CCCE5A3B9 > 34CDFC36914B4BEE8D6DB9FCD22FD208439666691969 > 3995E238CE5B472DA13E2296582E5B2E4BAE0DD19026 > 26B985CDFD9A319B3ECF2F754EC7395DFFEDF73BDBE3 > B7DF3867E7ECECFD7C79FA0E8F8F70DDF1287FFB83C7 > A5DBAFABBC663FCD6CB4D8CCDCE3A767ED709BD9F336 > 9A0F67CD361FA5D532E6CDD57A4EF20DF3F190597AEE > B82D665EEC4AF349BB623DBFE100BDA0718E4E6F12AA > D34F159985AEDD66615E75FD59E179BD6873825EBCF5 > 3B9DB120567F6E52CC92B7DC7AE93B3BCDB2C468B33C > 6999C9EC1166B2A2FAEA2FDCCAAC8848362B2B5F34AB > AA7ACDAA73DF9BD5852E9DBDF782FE72FF937ACDCADD > FAABA5A566EDFB597ADDCC20BD7E4C9ADE30B6446FF4 > A6E84D3DE799AF5BF5D3396DD6EBCDDE3D6673BEBFF9 > 26B0917C93F6946CDB5557B6BFDC56BE5DEA92DC015E > B5438EC8CE91CFC8AEA440B5AB38427D37BC54EF1E14 > 62BE8F3AA4F3EAD637791D4A24EFE021B5277691DE53 > EA6BF6864DD57BAFBDABF32B25EAFC53A7F5FE6335CC > 8FDB72F5814DD7CC4F9927CDC18C407D68FA767338E9 > 317364C4687DB45713F3B347CCB1880AE678E4627D22 > 28441754F39882E2BB7561C9287D32FF8C3E75A0B73E > BD7A873EB3FCBA39FBC1527D6EC25073FEA3F1FAC2C0 > 287331354E5FEA16AF2FC7B5D757EA5734BFB40BD657 > 5DE74C513D3F5D746897B9567A425F5FB7DC1417F89A > 1BE33E33259BB3137D1373749910AFF6EB91AECBFAB7 > D1E5DC9375B9C2DADA5F2568FF2DA53AE07CACBE7B59 > 2D5361A75B579C76C3545A5255571EF5935133C24C95 > 9EEB4CD51465EE09FFD854F35E34D5834F4960AB1CA9 > E1FBADD4AC992E358F7E2EF7164D965A1BA749D0E105 > AAF6A20C5567FD2455778AA87A7346289D90A4EA4F88 > 51F7457B54F0C066AA41684BD5B05B776954A1A66ADC > A4A934BEF2A08404549690BC40695278411EC82C92D0 > ADBBA5E9F47C09FB344B9A8DFE52DC93D2C47DA2812B > BCFF3E159194A99A4766AB077BBDA75AD499AD5A468C > 512D4B5255ABA0E9D2EAC040D5BA3859DAACE9A8DAEE > F7CAC3F3E32432BB8D3C32B1BDB49B595B1E8D0F96F6 > 6FB4561DBAF849C7C141AA53C313D2B96389EAE2B755 > BA061F545DCF1E5751BEEB5554EE16D5EDE85CD53D63 > A18ADEBE5662A64E51B18BE6C8E32347AA1E535E979E > 4F4E965E0943A4F74309E289EE2A4FD488953EA121D2 > E7AA5BBCD5BB28EF0F55E5A92BF7ABBE5F5C967E7901 > EA695345F5CF3CAD9E49BDA4E2A6E7AA0171796AE0F8 > 93F26CBB156A50FFED32B8DE0C35243243E2CB67C9D0 > 3A22430BD2645849920CDF9222CF1DF0C888F47E9290 > 334A3DFF76A48C9CDF5BBD30AC9E244E6CA146F57C58 > 25C5D7502F86D755A33B5F532F5571A9E466D525F9FC > 1135A6D25519B373934A39BB4FC62E99AFC6E566CB2B > 3336C8F88CD9F26ACA3C499D9A2A77F9FCD3A7EFEFCF > 5B5FFDFDFF59A6EC9D6FFA95FDB367B93FFFF6BF7BDE > BC79338B7B5649F994F9EDC8D5D63E1578C755E68FEF > F3393AC6E3EAD0DBE3EA8A9DEC0B978F8F8FFDB87515 > AD9EBFBE9D977FBB9D45B7DFB03FC4CD5AFDFDB721B7 > D4D1DE53E4A6227715B9ADC87D456E2C7267915B8BDC > 5BE4E6227717B9BDC8FD456EB0A3BDC3C82D76B4F718 > B9C9C85D466E33729F911B8DDC69E45623F71AB9D9C8 > DD466E3772BF911B8EDC71E4963BDA7B8EDC74E4AE23 > B71DB9EFC88D47EE3C72EB917B8FDC7CE4EE23B71FB9 > FF4803900E38DA16203D70B44D40BA80B401E903D208 > A413482B905E38DA6620DD40DA81F4036988A3ED88A3 > 6D09D21347DB14A42B8EB62D485F1C6D6390CE20AD41 > 7A833407E90ED21EA43F4883900E212D427A843409E9 > 12D22647DB27A45148A7905621BD429A85740B6917D2 > 2FA46148C79096213D439A86740D691BD23747DB38A4 > 7348EB90DE21CD43BAC7DF1AED43FA873410E920D242 > 47DB43A4898EB68B481B913E228D443AE91C12DB4AA4 > 974833916E22ED44FA893414E928D252A4A748531D6D > 5791B6227D451A8B7416692DD25BA4B9487791F622FD > 451A8C74186931D263A4C98EB6CB489B1D6D9F914623 > 9D465A8DF41A6936D26DA4DD8EB6DF3C6838D271A4E5 > 48CF91A6235D77B46D47FAEE681B8F741E693DD27BA4 > F948F791F623FD473600B203902D80EC01641320BB00 > D906C83E70B41B01D9098E762B207B01D90CC86E40B6 > 03B21F900D81EC08644B207B02D914C8AE40B605B22F > 1CEDC6407686A3DD1AC8DE403607B23B90ED81EC0F64 > 83203B04D922C81E413609B24B906D82EC1364A3203B > C5B1E0D6EF97BD826C1664B720DB05D92FC88641760C > B265903D836C1A64D720DB06D937C8C641768EA3DD3A > C8DE71B49B07D93DC8F641F60FB281901D846C21640F > B9FE1F44FF7D1005D8EFB8EDBF088D691ED622CCDD2C > 3C3426DCCDAB805F0162E35BFB ) > GB.tz.dotat.at. 3412 IN RRSIG TYPE29818 5 4 3600 ( > 20190728110326 20190718100326 56700 dotat.at. > JMbEh9MzMHhSIuLF+capNcNEkoa5Q2McgQSBpjS84w4v > ROpglw84OgCYunhmI5xmxVgqCUHd4+romQK86xvfit9j > 4Gs2kHTKOEjcxfvVbxLoUGkjZOe6zBeaT2tXRx/gQnUq > +md2j8+NKEbcRi8oL4YdDjdMsmFo5SntpbRd19E= ) > > ;; Query time: 0 msec > ;; SERVER: ::1#53(::1) > ;; WHEN: Thu Jul 18 15:15:18 BST 2019 > ;; MSG SIZE rcvd: 2209 > > Tony. From nobody Thu Jul 18 09:13:08 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 01D3912082B; Thu, 18 Jul 2019 09:12:58 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 UXzYe_oGn2vP; Thu, 18 Jul 2019 09:12:55 -0700 (PDT) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) (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 2B55E120822; Thu, 18 Jul 2019 09:12:55 -0700 (PDT) Received: by mail-wr1-x442.google.com with SMTP id n4so29374875wrs.3; Thu, 18 Jul 2019 09:12:55 -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:content-transfer-encoding; bh=IQnRiaMhqIejr3eYUSfa3LeZQhn7eQC5DyQgtdrckGU=; b=ILv7rHlVNeHxXxqkx/hy9lnkI7zNlgHH/0i0YNLJua+Wpviec3kDoif977M5ECMswA DbCJpDVP18rklXgsd40ifRC2C/2gOIJsHBPe/Mea8IzDLWwi+DG2A4nTcdtuc7t7PELb 3qLksDWyd67Ua1QIgoxj7Fq2ar0Itbo/rMQs5d16QlPqsPhs/JXOXzTZqh7xr1Oij+Jb 4MAl1SdHmDj+uZm7QUt8jads2DqOyYBUpB03m4GxrCbTYmx4gkN66LRLID7MXp5vD4Ne lEMHaHsvNnpFw0P/XzqDBSUA4G+TeEzTMoTPMqHQujq7fLWDWbRDcClhcRvpocvltp+7 +Ifw== 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 :content-transfer-encoding; bh=IQnRiaMhqIejr3eYUSfa3LeZQhn7eQC5DyQgtdrckGU=; b=aabQFmd9K7urO183Jnc1b1GNj1yA5MzDeTqyamjIQl7CmYmcfkN4ruXJTIcQ92c/x4 2dhuKF0diNdu4XSaR/OHTSAeK1077800QWBK6MJEUtaQbwta4ea4tu6/mA3KDEZYdcP4 qcvwzcbYhxgYaXCoNdZYnjAlMtYMPl46dSgxGsJ9nUlCj0RYVHdDmE72rY4p0lJjyLI3 3mnwqPopj3VMDNZ7dxFPuNNWDAedGAVk7SzKnybHAUkAzG17VKO+AGOF2pY8SKbvFw31 4L1HvpY6gekrJgWFpBU9iTiRwyN2+uSZz+UE9WBAEMwkWxTXV0icBuEW0gB5P4XaRHwB qw4w== X-Gm-Message-State: APjAAAUYmEB9tIh2LHyrqQgCuUVWGBAdj5WssNFNSdR1GA7I36A0Zaja m77l7ZUsuQToKvU8huGcRGaJ30nz X-Google-Smtp-Source: APXvYqxgYcngb3sONqNYUEOaDgurmno411j2m17AK7V1X1MjEOWY+ryjCrWGLbPABkKdwr4kJhQtFw== X-Received: by 2002:a05:6000:11c6:: with SMTP id i6mr44867764wrx.193.1563466373320; Thu, 18 Jul 2019 09:12:53 -0700 (PDT) Received: from [192.168.43.33] (55.red-83-41-197.dynamicip.rima-tde.net. [83.41.197.55]) by smtp.gmail.com with ESMTPSA id w25sm26246162wmk.18.2019.07.18.09.12.52 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2019 09:12:52 -0700 (PDT) To: Steve Crocker Cc: tzdist-bis@ietf.org, "tz@iana.org mailing list" , IETF-Calsify References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> <6f0f4df8-d054-48e5-a9c3-5ca9a1d1f917@gmail.com> From: Thomas Peterson Message-ID: <822167d4-860a-d14a-92da-34fbd33e5882@gmail.com> Date: Thu, 18 Jul 2019 17:12:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.0 MIME-Version: 1.0 In-Reply-To: <6f0f4df8-d054-48e5-a9c3-5ca9a1d1f917@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] [tz] [Tzdist-bis] tzdist and IANA -- estimating the operational parameters 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, 18 Jul 2019 16:12:58 -0000 We already have a REST-like standard defined for carrying TZ data - RFC 7808. It also appears based upon previous discussions that very few, if any real world implementations and deployments which exist. Perhaps this is because of the complexity of the standard, and maybe defining a simpler subset might be more appealing for implementations. Regards On 18/07/2019 16:52, Michael Douglass wrote: > > On 7/18/19 10:32, Tony Finch wrote: >> Steve Crocker wrote: >> >>> Early in this thread it was mentioned the the time zone database >>> should be >>> served in a fashion similar to DNS. >> We could just use the DNS :-) As Paul pointed out, TZif files are not >> very big. > > DNS keeps turning up as a suggestion. However, just because tz > distribution has some vague similarity to DNS doesn't make it a good idea. > > I'm sure it can be done but a simple RESTful interface over https is > simpel and easily implemented. > >> >> I have experimentally shoved the zoneinfo files from my workstation >> into a >> DNS zone I happen to have lying around. I've deflated (RFC 1950) each >> file >> (RFC 8536) and picked an arbitrary RR type 29818 = 0x747A = 'tz'. The >> result appears below as a hex blob (RFC 3597) which does not quite fit in >> the Ethernet MTU, but you can get the answer over UDP if you allow EDNS >> with fragmentation. It's signed with DNSSEC so you can be sure I am to >> blame. https://pbs.twimg.com/media/DY5rHo_WAAEISGh.jpg >> >> >> ; <<>> DiG 9.15.1 <<>> +dnssec +multiline London.Europe.tz.dotat.at. >> TYPE29818 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32632 >> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags: do; udp: 1420 >> ; COOKIE: 30e31bd663d426f6eb79a79f5d307ef6114d7eabab9d3c0e (good) >> ;; QUESTION SECTION: >> ;London.Europe.tz.dotat.at. IN TYPE29818 >> >> ;; ANSWER SECTION: >> London.Europe.tz.dotat.at. 3412 IN CNAME GB.tz.dotat.at. >> London.Europe.tz.dotat.at. 3412 IN RRSIG CNAME 5 5 3600 ( >>                                  20190728110326 20190718100326 56700 >> dotat.at. >> >> R7ynL3bJ7uScgbF3GNSKzuXZZZKnTF6ZKObqh9y5LIwI >> >> voZSo46m1jv6HwkQBUDvmMSYzSfW0TDqzxz6BDrxb+VG >> >> aBITB2DyJeI6OXcJYQXbyGpqP9Brc7k5B6js1oyFOMru >> >> hLDqOxSlZTIW3pimnV17LQqI7ve/FPygHN26+rE= ) >> GB.tz.dotat.at.         3412 IN TYPE29818 \# 1751 ( >>                 789CEDD67B74CF751CC7F1DF9A61CBE5438CCCE5A3B9 >> >> 34CDFC36914B4BEE8D6DB9FCD22FD208439666691969 >> >> 3995E238CE5B472DA13E2296582E5B2E4BAE0DD19026 >> >> 26B985CDFD9A319B3ECF2F754EC7395DFFEDF73BDBE3 >> >> B7DF3867E7ECECFD7C79FA0E8F8F70DDF1287FFB83C7 >> >> A5DBAFABBC663FCD6CB4D8CCDCE3A767ED709BD9F336 >> >> 9A0F67CD361FA5D532E6CDD57A4EF20DF3F190597AEE >> >> B82D665EEC4AF349BB623DBFE100BDA0718E4E6F12AA >> >> D34F159985AEDD66615E75FD59E179BD6873825EBCF5 >> >> 3B9DB120567F6E52CC92B7DC7AE93B3BCDB2C468B33C >> >> 6999C9EC1166B2A2FAEA2FDCCAAC8848362B2B5F34AB >> >> AA7ACDAA73DF9BD5852E9DBDF782FE72FF937ACDCADD >> >> FAABA5A566EDFB597ADDCC20BD7E4C9ADE30B6446FF4 >> >> A6E84D3DE799AF5BF5D3396DD6EBCDDE3D6673BEBFF9 >> >> 26B0917C93F6946CDB5557B6BFDC56BE5DEA92DC015E >> >> B5438EC8CE91CFC8AEA440B5AB38427D37BC54EF1E14 >> >> 62BE8F3AA4F3EAD637791D4A24EFE021B5277691DE53 >> >> EA6BF6864DD57BAFBDABF32B25EAFC53A7F5FE6335CC >> >> 8FDB72F5814DD7CC4F9927CDC18C407D68FA767338E9 >> >> 317364C4687DB45713F3B347CCB1880AE678E4627D22 >> >> 28441754F39882E2BB7561C9287D32FF8C3E75A0B73E >> >> BD7A873EB3FCBA39FBC1527D6EC25073FEA3F1FAC2C0 >> >> 287331354E5FEA16AF2FC7B5D757EA5734BFB40BD657 >> >> 5DE74C513D3F5D746897B9567A425F5FB7DC1417F89A >> >> 1BE33E33259BB3137D1373749910AFF6EB91AECBFAB7 >> >> D1E5DC9375B9C2DADA5F2568FF2DA53AE07CACBE7B59 >> >> 2D5361A75B579C76C3545A5255571EF5935133C24C95 >> >> 9EEB4CD51465EE09FFD854F35E34D5834F4960AB1CA9 >> >> E1FBADD4AC992E358F7E2EF7164D965A1BA749D0E105 >> >> AAF6A20C5567FD2455778AA87A7346289D90A4EA4F88 >> >> 51F7457B54F0C066AA41684BD5B05B776954A1A66ADC >> >> A4A934BEF2A08404549690BC40695278411EC82C92D0 >> >> ADBBA5E9F47C09FB344B9A8DFE52DC93D2C47DA2812B >> >> BCFF3E159194A99A4766AB077BBDA75AD499AD5A468C >> >> 512D4B5255ABA0E9D2EAC040D5BA3859DAACE9A8DAEE >> >> F7CAC3F3E32432BB8D3C32B1BDB49B595B1E8D0F96F6 >> >> 6FB4561DBAF849C7C141AA53C313D2B96389EAE2B755 >> >> BA061F545DCF1E5751BEEB5554EE16D5EDE85CD53D63 >> >> A18ADEBE5662A64E51B18BE6C8E32347AA1E535E979E >> >> 4F4E965E0943A4F74309E289EE2A4FD488953EA121D2 >> >> E7AA5BBCD5BB28EF0F55E5A92BF7ABBE5F5C967E7901 >> >> EA695345F5CF3CAD9E49BDA4E2A6E7AA0171796AE0F8 >> >> 93F26CBB156A50FFED32B8DE0C35243243E2CB67C9D0 >> >> 3A22430BD2645849920CDF9222CF1DF0C888F47E9290 >> >> 334A3DFF76A48C9CDF5BBD30AC9E244E6CA146F57C58 >> >> 25C5D7502F86D755A33B5F532F5571A9E466D525F9FC >> >> 1135A6D25519B373934A39BB4FC62E99AFC6E566CB2B >> >> 3336C8F88CD9F26ACA3C499D9A2A77F9FCD3A7EFEFCF >> >> 5B5FFDFDFF59A6EC9D6FFA95FDB367B93FFFF6BF7BDE >> >> BC79338B7B5649F994F9EDC8D5D63E1578C755E68FEF >> >> F3393AC6E3EAD0DBE3EA8A9DEC0B978F8F8FFDB87515 >> >> AD9EBFBE9D977FBB9D45B7DFB03FC4CD5AFDFDB721B7 >> >> D4D1DE53E4A6227715B9ADC87D456E2C7267915B8BDC >> >> 5BE4E6227717B9BDC8FD456EB0A3BDC3C82D76B4F718 >> >> B9C9C85D466E33729F911B8DDC69E45623F71AB9D9C8 >> >> DD466E3772BF911B8EDC71E4963BDA7B8EDC74E4AE23 >> >> B71DB9EFC88D47EE3C72EB917B8FDC7CE4EE23B71FB9 >> >> FF4803900E38DA16203D70B44D40BA80B401E903D208 >> >> A413482B905E38DA6620DD40DA81F4036988A3ED88A3 >> >> 6D09D21347DB14A42B8EB62D485F1C6D6390CE20AD41 >> >> 7A833407E90ED21EA43F4883900E212D427A843409E9 >> >> 12D22647DB27A45148A7905621BD429A85740B6917D2 >> >> 2FA46148C79096213D439A86740D691BD23747DB38A4 >> >> 7348EB90DE21CD43BAC7DF1AED43FA873410E920D242 >> >> 47DB43A4898EB68B481B913E228D443AE91C12DB4AA4 >> >> 974833916E22ED44FA893414E928D252A4A748531D6D >> >> 5791B6227D451A8B7416692DD25BA4B9487791F622FD >> >> 451A8C74186931D263A4C98EB6CB489B1D6D9F914623 >> >> 9D465A8DF41A6936D26DA4DD8EB6DF3C6838D271A4E5 >> >> 48CF91A6235D77B46D47FAEE681B8F741E693DD27BA4 >> >> F948F791F623FD473600B203902D80EC01641320BB00 >> >> D906C83E70B41B01D9098E762B207B01D90CC86E40B6 >> >> 03B21F900D81EC08644B207B02D914C8AE40B605B22F >> >> 1CEDC6407686A3DD1AC8DE403607B23B90ED81EC0F64 >> >> 83203B04D922C81E413609B24B906D82EC1364A3203B >> >> C5B1E0D6EF97BD826C1664B720DB05D92FC88641760C >> >> B265903D836C1A64D720DB06D937C8C641768EA3DD3A >> >> C8DE71B49B07D93DC8F641F60FB281901D846C21640F >> >> B9FE1F44FF7D1005D8EFB8EDBF088D691ED622CCDD2C >>                                  3C3426DCCDAB805F0162E35BFB ) >> GB.tz.dotat.at.         3412 IN RRSIG TYPE29818 5 4 3600 ( >>                                  20190728110326 20190718100326 56700 >> dotat.at. >> >> JMbEh9MzMHhSIuLF+capNcNEkoa5Q2McgQSBpjS84w4v >> >> ROpglw84OgCYunhmI5xmxVgqCUHd4+romQK86xvfit9j >> >> 4Gs2kHTKOEjcxfvVbxLoUGkjZOe6zBeaT2tXRx/gQnUq >> >> +md2j8+NKEbcRi8oL4YdDjdMsmFo5SntpbRd19E= ) >> >> ;; Query time: 0 msec >> ;; SERVER: ::1#53(::1) >> ;; WHEN: Thu Jul 18 15:15:18 BST 2019 >> ;; MSG SIZE  rcvd: 2209 >> >> Tony. From nobody Thu Jul 18 09:20:47 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 CEC1B12084D; Thu, 18 Jul 2019 09:20: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 aqt44Cz1IBkJ; Thu, 18 Jul 2019 09:20:35 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (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 758CE120847; Thu, 18 Jul 2019 09:20:35 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id k10so27864423qtq.1; Thu, 18 Jul 2019 09:20:35 -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-transfer-encoding:content-language; bh=HjLmpiauR3TlOIVU5uH3NnnQo3C27jVwjz5Fh4Iwgso=; b=B5bdIXtUXYvSWN55UV0xayqqlAR/xHf94QekbYn0/e8TQoIUS6a9/QAp0pZqqO8PiS Dpk9JIMw8PrmV6fBNrt94SR41ScDVntpYPYalamGI0IQFD96zMtzbBMkl8lw8vVCyVzw 9e964/mEMTADcRZPvmC4UKdqhmnK30yFr3rl1kc3qN8E33UGJ4ZF4EPIISIpltqCcyW8 y6KwRRevaZeD5cngsTxn3KULyB6FM6n6lWKWDmaS9fMGrqQl0NeCLkn/wLwi3Otn0OIH /GFpyR7VWtOGy1sLkrNoErdfZ9Ic2gkRep8Ri4iqEA2Iviu4jFgboBGlMvnC6eYuZJLR rfjg== 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-transfer-encoding :content-language; bh=HjLmpiauR3TlOIVU5uH3NnnQo3C27jVwjz5Fh4Iwgso=; b=PMisdHa71qECBsQI6hNu5JQGa6KMclYAO9EX63WJ1HiP6HwO+oA+aRsb7rEZfOTjaF r6hWz/cxT3jsdAMIwXWYjqv0ejGFcDX5bRj7PxmzXJVSgly54+9heRyjvS1TxCDKsg5M 4cuG87z4vU+DZd5ul9uXQQe6umZrOBcOXZq6hvPH+tlbo5tfaNbN77Q4BvMjW+wqipaF bT3D+s9UTxPhvJDWQv0pqhZ58oV3qlRccynNx3eTnhidQk6NC2lqb9IfBhIZ8CWvi6lR rhcQQ4shS5M5v/hR0CG53N/Oy0E4vaQlVEjemY7Otxbnaj+3d9YB3Rl4lVZTw+XMGf/v twvQ== X-Gm-Message-State: APjAAAUL9ZrzV9xsMVOBljYxBeW38Rzl6Dirc0K5EJf2VvmE5P8QYzis EPPEm2Gb+sojJ7rOkI9CKQg5iqlQb9g= X-Google-Smtp-Source: APXvYqxYNTv1m2Z9HB2ZVM+AavtCO3iAVwxEfAEqVLNv2hgvXJAvryeNrtvvdUtvBrTvZLPyx/XEXQ== X-Received: by 2002:ac8:22a3:: with SMTP id f32mr33122549qta.152.1563466834422; Thu, 18 Jul 2019 09:20:34 -0700 (PDT) Received: from a-192-168-129-25.dynapool.vpn.nyu.edu (vpnrasa-wwh-pat-01.natpool.nyu.edu. [216.165.95.84]) by smtp.googlemail.com with ESMTPSA id t2sm16291494qth.33.2019.07.18.09.20.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2019 09:20:34 -0700 (PDT) To: Thomas Peterson , Steve Crocker Cc: tzdist-bis@ietf.org, "tz@iana.org mailing list" , IETF-Calsify References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> <6f0f4df8-d054-48e5-a9c3-5ca9a1d1f917@gmail.com> <822167d4-860a-d14a-92da-34fbd33e5882@gmail.com> From: Michael Douglass Message-ID: <3ba7097a-08af-6f8c-db05-a7e3721f5140@gmail.com> Date: Thu, 18 Jul 2019 12:20:33 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <822167d4-860a-d14a-92da-34fbd33e5882@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] [Tzdist-bis] [tz] tzdist and IANA -- estimating the operational parameters 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, 18 Jul 2019 16:20:38 -0000 On 7/18/19 12:12, Thomas Peterson wrote: > We already have a REST-like standard defined for carrying TZ data - > RFC 7808. I know - I'm one of the authors > It also appears based upon previous discussions that very few, if any > real world implementations and deployments which exist. Perhaps this > is because of the complexity of the standard, and maybe defining a > simpler subset might be more appealing for implementations. I can assure you it's very simple to implement. There are at least 3 implementations. The major issue as far as I can tell is getting some organization(s) to agree to host a root service we can build out from. Without that it's going nowhere. > > Regards > > On 18/07/2019 16:52, Michael Douglass wrote: >> >> On 7/18/19 10:32, Tony Finch wrote: >>> Steve Crocker wrote: >>> >>>> Early in this thread it was mentioned the the time zone database >>>> should be >>>> served in a fashion similar to DNS. >>> We could just use the DNS :-) As Paul pointed out, TZif files are not >>> very big. >> >> DNS keeps turning up as a suggestion. However, just because tz >> distribution has some vague similarity to DNS doesn't make it a good >> idea. >> >> I'm sure it can be done but a simple RESTful interface over https is >> simpel and easily implemented. >> >>> >>> I have experimentally shoved the zoneinfo files from my workstation >>> into a >>> DNS zone I happen to have lying around. I've deflated (RFC 1950) >>> each file >>> (RFC 8536) and picked an arbitrary RR type 29818 = 0x747A = 'tz'. The >>> result appears below as a hex blob (RFC 3597) which does not quite >>> fit in >>> the Ethernet MTU, but you can get the answer over UDP if you allow EDNS >>> with fragmentation. It's signed with DNSSEC so you can be sure I am to >>> blame. https://pbs.twimg.com/media/DY5rHo_WAAEISGh.jpg >>> >>> >>> ; <<>> DiG 9.15.1 <<>> +dnssec +multiline London.Europe.tz.dotat.at. >>> TYPE29818 >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32632 >>> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags: do; udp: 1420 >>> ; COOKIE: 30e31bd663d426f6eb79a79f5d307ef6114d7eabab9d3c0e (good) >>> ;; QUESTION SECTION: >>> ;London.Europe.tz.dotat.at. IN TYPE29818 >>> >>> ;; ANSWER SECTION: >>> London.Europe.tz.dotat.at. 3412 IN CNAME GB.tz.dotat.at. >>> London.Europe.tz.dotat.at. 3412 IN RRSIG CNAME 5 5 3600 ( >>>                                  20190728110326 20190718100326 56700 >>> dotat.at. >>> R7ynL3bJ7uScgbF3GNSKzuXZZZKnTF6ZKObqh9y5LIwI >>> voZSo46m1jv6HwkQBUDvmMSYzSfW0TDqzxz6BDrxb+VG >>> aBITB2DyJeI6OXcJYQXbyGpqP9Brc7k5B6js1oyFOMru >>> hLDqOxSlZTIW3pimnV17LQqI7ve/FPygHN26+rE= ) >>> GB.tz.dotat.at.         3412 IN TYPE29818 \# 1751 ( >>>                 789CEDD67B74CF751CC7F1DF9A61CBE5438CCCE5A3B9 >>> 34CDFC36914B4BEE8D6DB9FCD22FD208439666691969 >>> 3995E238CE5B472DA13E2296582E5B2E4BAE0DD19026 >>> 26B985CDFD9A319B3ECF2F754EC7395DFFEDF73BDBE3 >>> B7DF3867E7ECECFD7C79FA0E8F8F70DDF1287FFB83C7 >>> A5DBAFABBC663FCD6CB4D8CCDCE3A767ED709BD9F336 >>> 9A0F67CD361FA5D532E6CDD57A4EF20DF3F190597AEE >>> B82D665EEC4AF349BB623DBFE100BDA0718E4E6F12AA >>> D34F159985AEDD66615E75FD59E179BD6873825EBCF5 >>> 3B9DB120567F6E52CC92B7DC7AE93B3BCDB2C468B33C >>> 6999C9EC1166B2A2FAEA2FDCCAAC8848362B2B5F34AB >>> AA7ACDAA73DF9BD5852E9DBDF782FE72FF937ACDCADD >>> FAABA5A566EDFB597ADDCC20BD7E4C9ADE30B6446FF4 >>> A6E84D3DE799AF5BF5D3396DD6EBCDDE3D6673BEBFF9 >>> 26B0917C93F6946CDB5557B6BFDC56BE5DEA92DC015E >>> B5438EC8CE91CFC8AEA440B5AB38427D37BC54EF1E14 >>> 62BE8F3AA4F3EAD637791D4A24EFE021B5277691DE53 >>> EA6BF6864DD57BAFBDABF32B25EAFC53A7F5FE6335CC >>> 8FDB72F5814DD7CC4F9927CDC18C407D68FA767338E9 >>> 317364C4687DB45713F3B347CCB1880AE678E4627D22 >>> 28441754F39882E2BB7561C9287D32FF8C3E75A0B73E >>> BD7A873EB3FCBA39FBC1527D6EC25073FEA3F1FAC2C0 >>> 287331354E5FEA16AF2FC7B5D757EA5734BFB40BD657 >>> 5DE74C513D3F5D746897B9567A425F5FB7DC1417F89A >>> 1BE33E33259BB3137D1373749910AFF6EB91AECBFAB7 >>> D1E5DC9375B9C2DADA5F2568FF2DA53AE07CACBE7B59 >>> 2D5361A75B579C76C3545A5255571EF5935133C24C95 >>> 9EEB4CD51465EE09FFD854F35E34D5834F4960AB1CA9 >>> E1FBADD4AC992E358F7E2EF7164D965A1BA749D0E105 >>> AAF6A20C5567FD2455778AA87A7346289D90A4EA4F88 >>> 51F7457B54F0C066AA41684BD5B05B776954A1A66ADC >>> A4A934BEF2A08404549690BC40695278411EC82C92D0 >>> ADBBA5E9F47C09FB344B9A8DFE52DC93D2C47DA2812B >>> BCFF3E159194A99A4766AB077BBDA75AD499AD5A468C >>> 512D4B5255ABA0E9D2EAC040D5BA3859DAACE9A8DAEE >>> F7CAC3F3E32432BB8D3C32B1BDB49B595B1E8D0F96F6 >>> 6FB4561DBAF849C7C141AA53C313D2B96389EAE2B755 >>> BA061F545DCF1E5751BEEB5554EE16D5EDE85CD53D63 >>> A18ADEBE5662A64E51B18BE6C8E32347AA1E535E979E >>> 4F4E965E0943A4F74309E289EE2A4FD488953EA121D2 >>> E7AA5BBCD5BB28EF0F55E5A92BF7ABBE5F5C967E7901 >>> EA695345F5CF3CAD9E49BDA4E2A6E7AA0171796AE0F8 >>> 93F26CBB156A50FFED32B8DE0C35243243E2CB67C9D0 >>> 3A22430BD2645849920CDF9222CF1DF0C888F47E9290 >>> 334A3DFF76A48C9CDF5BBD30AC9E244E6CA146F57C58 >>> 25C5D7502F86D755A33B5F532F5571A9E466D525F9FC >>> 1135A6D25519B373934A39BB4FC62E99AFC6E566CB2B >>> 3336C8F88CD9F26ACA3C499D9A2A77F9FCD3A7EFEFCF >>> 5B5FFDFDFF59A6EC9D6FFA95FDB367B93FFFF6BF7BDE >>> BC79338B7B5649F994F9EDC8D5D63E1578C755E68FEF >>> F3393AC6E3EAD0DBE3EA8A9DEC0B978F8F8FFDB87515 >>> AD9EBFBE9D977FBB9D45B7DFB03FC4CD5AFDFDB721B7 >>> D4D1DE53E4A6227715B9ADC87D456E2C7267915B8BDC >>> 5BE4E6227717B9BDC8FD456EB0A3BDC3C82D76B4F718 >>> B9C9C85D466E33729F911B8DDC69E45623F71AB9D9C8 >>> DD466E3772BF911B8EDC71E4963BDA7B8EDC74E4AE23 >>> B71DB9EFC88D47EE3C72EB917B8FDC7CE4EE23B71FB9 >>> FF4803900E38DA16203D70B44D40BA80B401E903D208 >>> A413482B905E38DA6620DD40DA81F4036988A3ED88A3 >>> 6D09D21347DB14A42B8EB62D485F1C6D6390CE20AD41 >>> 7A833407E90ED21EA43F4883900E212D427A843409E9 >>> 12D22647DB27A45148A7905621BD429A85740B6917D2 >>> 2FA46148C79096213D439A86740D691BD23747DB38A4 >>> 7348EB90DE21CD43BAC7DF1AED43FA873410E920D242 >>> 47DB43A4898EB68B481B913E228D443AE91C12DB4AA4 >>> 974833916E22ED44FA893414E928D252A4A748531D6D >>> 5791B6227D451A8B7416692DD25BA4B9487791F622FD >>> 451A8C74186931D263A4C98EB6CB489B1D6D9F914623 >>> 9D465A8DF41A6936D26DA4DD8EB6DF3C6838D271A4E5 >>> 48CF91A6235D77B46D47FAEE681B8F741E693DD27BA4 >>> F948F791F623FD473600B203902D80EC01641320BB00 >>> D906C83E70B41B01D9098E762B207B01D90CC86E40B6 >>> 03B21F900D81EC08644B207B02D914C8AE40B605B22F >>> 1CEDC6407686A3DD1AC8DE403607B23B90ED81EC0F64 >>> 83203B04D922C81E413609B24B906D82EC1364A3203B >>> C5B1E0D6EF97BD826C1664B720DB05D92FC88641760C >>> B265903D836C1A64D720DB06D937C8C641768EA3DD3A >>> C8DE71B49B07D93DC8F641F60FB281901D846C21640F >>> B9FE1F44FF7D1005D8EFB8EDBF088D691ED622CCDD2C >>>                                  3C3426DCCDAB805F0162E35BFB ) >>> GB.tz.dotat.at.         3412 IN RRSIG TYPE29818 5 4 3600 ( >>>                                  20190728110326 20190718100326 56700 >>> dotat.at. >>> JMbEh9MzMHhSIuLF+capNcNEkoa5Q2McgQSBpjS84w4v >>> ROpglw84OgCYunhmI5xmxVgqCUHd4+romQK86xvfit9j >>> 4Gs2kHTKOEjcxfvVbxLoUGkjZOe6zBeaT2tXRx/gQnUq >>> +md2j8+NKEbcRi8oL4YdDjdMsmFo5SntpbRd19E= ) >>> >>> ;; Query time: 0 msec >>> ;; SERVER: ::1#53(::1) >>> ;; WHEN: Thu Jul 18 15:15:18 BST 2019 >>> ;; MSG SIZE  rcvd: 2209 >>> >>> Tony. > > _______________________________________________ > Tzdist-bis mailing list > Tzdist-bis@ietf.org > https://www.ietf.org/mailman/listinfo/tzdist-bis From nobody Thu Jul 18 09:36: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 690E31208E4; Thu, 18 Jul 2019 09:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 nz92uDhfXrU9; Thu, 18 Jul 2019 09:36:20 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A793F120630; Thu, 18 Jul 2019 09:36:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1815; q=dns/txt; s=iport; t=1563467780; x=1564677380; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=o7w7qBRSlgYslatEthFgPRgqWmoX0iivuId4zWU8DgU=; b=YRmR5uJlp0A21r9/ioYhQLFH8YCPmKzVa7HUfYO1C2QjIG4lvsjX45Ub b54tBo8YVS3FQ8ugrLJjhWvjjz2dJaJpRhvjIflnFLLkmBEfxeT13Oh3x OyKQLtwZc5s+cHCqqeW1AAXlpmrPpiruNO9o82Ea1INs2AtyzS1ouJgXD A=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAACwnjBd/xbLJq1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVgEBAQEBAQsBg1QBMiqEHYh7iwElmnkCBwEBAQkDAQE?= =?us-ascii?q?vAQGEQAKCbzcGDgEDAQEEAQECAQVthUiFSgEBAQECASNWBQsLGCoCAlcGE4M?= =?us-ascii?q?iAYF7D6x4gTKFR4RtEIE0AYFQiiWBf4ERJwwTgh4uPodPMoImBI5FhiyVcgm?= =?us-ascii?q?CG4IfgQyQYRuNN4pThBGdaYMLAgQGBQIVgWYiRIEUMxoIGxVlAYJBPoI6jg8?= =?us-ascii?q?9AzCObAEB?= X-IronPort-AV: E=Sophos;i="5.64,278,1559520000"; d="asc'?scan'208";a="14387268" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jul 2019 16:36:17 +0000 Received: from [10.61.168.42] ([10.61.168.42]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x6IGaGrD027455 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Jul 2019 16:36:17 GMT From: Eliot Lear Message-Id: <7629044C-DF3D-4526-B395-320BC6CFD158@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_37705F23-415C-473F-AB70-C2F18C94891E"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 18 Jul 2019 18:36:14 +0200 In-Reply-To: Cc: "tz@iana.org mailing list" , IETF-Calsify , tzdist-bis@ietf.org, Paul Eggert , Daniel Migault , Martin Burnicki To: Steve Crocker References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.168.42, [10.61.168.42] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA -- estimating the operational parameters 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, 18 Jul 2019 16:36:22 -0000 --Apple-Mail=_37705F23-415C-473F-AB70-C2F18C94891E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Steve, > On 18 Jul 2019, at 15:50, Steve Crocker wrote: >=20 > Early in this thread it was mentioned the the time zone database = should be served in a fashion similar to DNS. My first thought was the = numbers are wildly different. I jotted down a first cut at identifying = the relevant operational parameters. Perhaps the people proposing this = service can flesh out the quantitative aspects. My issue isn=E2=80=99t so much the size of entries. Many entries can = fit in a DNS packet *without* EDNS0. It wouldn=E2=80=99t be wildly = crazy to to use 2k as a good size. The problem is 2k*O(10^9) (and soon = O(10^10)) devices X an unknown frequency, because it is in part based on = political considerations of the various jurisdictions. The chaos coming = to Europe soon will demonstrate this. Also, I don=E2=80=99t think we = should swear by the code in devices these days in terms of how they back = off or what epsilons they use in their timers. And then there are all the security aspects of that. Shoving this stuff = into the DNS would pretty much require DOH everywhere. Eliot --Apple-Mail=_37705F23-415C-473F-AB70-C2F18C94891E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXTCf/gAKCRBugA9nE248 uEFoAKDNJuAgU+x61ZH8tocPv630bEQ2lACePncmnpR1nFh8D9OdrZcr6/MfGhs= =67cW -----END PGP SIGNATURE----- --Apple-Mail=_37705F23-415C-473F-AB70-C2F18C94891E-- From nobody Thu Jul 18 13:16: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 F27801200EF; Thu, 18 Jul 2019 13:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 IS8P1NsT0Qid; Thu, 18 Jul 2019 13:15:57 -0700 (PDT) Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28EA1120074; Thu, 18 Jul 2019 13:15:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 7632E1626E8; Thu, 18 Jul 2019 13:15:56 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id axPdfgpBU37K; Thu, 18 Jul 2019 13:15:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 366411626E9; Thu, 18 Jul 2019 13:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id WImwP9RbMV-M; Thu, 18 Jul 2019 13:15:55 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 022BA1626E8; Thu, 18 Jul 2019 13:15:54 -0700 (PDT) To: Steve Crocker , Time zone mailing list , IETF-Calsify Cc: Martin Burnicki , tzdist-bis@ietf.org, Daniel Migault References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <118a452c-25ba-8427-4401-5465270da738@cs.ucla.edu> Date: Thu, 18 Jul 2019 13:15:54 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA -- estimating the operational parameters 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, 18 Jul 2019 20:15:59 -0000 Steve Crocker wrote: > Early in this thread it was mentioned the the time zone database should be > served in a fashion similar to DNS. My first thought was the numbers are > wildly different. I jotted down a first cut at identifying the relevant > operational parameters. Perhaps the people proposing this service can > flesh out the quantitative aspects. Here are some estimates. There is no central TZDIST server now, so all the non-size estimates are for if/when that happens. The estimated rate of change for these numbers is all zero, except for the database size where I'd estimate a growth of 5%/year (this is just off the top of my head). Frequency of database update: 18 times per year has been the worst case since the project started in the 1980s. Recently updates have occurred three to ten times per year. Frequency of access: If we're assuming a pull model like TZDIST with primary and secondary servers, I would expect queries once every hour-or-so from each downstream server that wants to be up-to-date. Usually the response will be "nothing has changed". Required response time: Most clients and servers can be expected to have a (possibly-stale) copy of the data already, which they can fall back on. So I would say "minutes". Required uptime: Again, not crucial. I would say 90% would be enough. For sizes, it depends on data format and whether you want all the data. Size of entire tzdb database (including all time zone history, version info, and legal notices), in minimal source-code (text) form: 111 kB uncompressed, 27 kB compressed via gzip, 22 kB compressed via lzip. Size of entire tzdb database in binary (TZif) form in traditional form: 456 kB uncompressed, 152 kB tar+gzip, 68 kB tar+lzip. This includes all time zone history but omits version info and legal notices. Same size, but with zic's new '-b slim' option that relies on Internet RFC 8536 instead of attempting to work around bugs in older applications: 216 kB uncompressed, 77 kB tar+gzip, 43 kB tar+lzip. I don't know how to compute the size of tzdb converted into iCalendar form, but my guess is that it'd be the same order-of-magnitude as the TZif files. All sizes are for ordinary (POSIX) tzdb, not for the rarely-used leapsecond variant. From nobody Thu Jul 18 13:26:26 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 A7DA8120074; Thu, 18 Jul 2019 13:26:18 -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, 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=rUJOOpov; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BYmeUE8Y 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 owj1CRLW1mCq; Thu, 18 Jul 2019 13:26:16 -0700 (PDT) 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 664D1120033; Thu, 18 Jul 2019 13:26:16 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id F00E12206E; Thu, 18 Jul 2019 16:26:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 18 Jul 2019 16:26:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm3; bh=IiLAc3f44ODT0xVozMAxSeFctfj y0avcDIdOsBP3TGM=; b=rUJOOpovsF1FA6Cc122SKBXm0Z8ZWku3eQxAQls0g3c 2eqF3PNQoCcPdLmiMWEpwkXvNAhBtNqXlKvS4nurybO21Gf9qcYbyCB+ivTH54s4 l4eXUWi2kC3hSdMP2Zm4AzBdFq/3cAmUEfg7BjdsxWMrDP0UkeAtbN9aOZSupR4b N7IslVVxJ9NO9OJjlIGTA+Y1Tib/fDSqfX3EdrVCbBmyozk2JO77GlkltxMJnFXD Gw9bt6tjur8M6P6JdRQyc3Z64LHEJulmGYEmRTz1VkziIHq4VsGDu953OAPS5GbH Yk4poAWLysQ9IX7QvgXoUcefX9yuWiz4+ok+swOCgCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=IiLAc3 f44ODT0xVozMAxSeFctfjy0avcDIdOsBP3TGM=; b=BYmeUE8Yju7szKuOzBSB+U AI0XU7aa7Cq2RN+6heGC8pYCynKDGx2ZRFgqGW8t2gVrOkAnhEZ+SvRSmxYIM0zI 0IjEZA3MKd4/AcCoV+/GK7JkAfO2a/5I/fFcX8OAOqmtjQRa1HoH0QGmq09lDYKE DMmt+tbotMgwW9/hkjPds+HF4IC6ey9UB9NWac2rS0CxSSJHiu6miUu7kqHqP547 hkQWAb7XRzgiihUG7eXqbgEcM51Pi2QtiuY3kfbdX3An/FoxGZf9PuwgILF0Vdk5 YSwjJhvPvJRnLXHUYO1K47ozEW2ccpW/a7Blsrj3MfdChP8PXtZjbMOPTlnmcNow == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrieehgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhohfkffgfgggjtgesmhdtreertdefjeenucfhrhhomhepmfgvnhcu ofhurhgthhhishhonhcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecuffhomh grihhnpehivghtfhdrohhrghenucfkphepjeegrdejjedrkeehrddvhedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtghomhenucevlhhush htvghrufhiiigvpedt 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 C297D380084; Thu, 18 Jul 2019 16:26:13 -0400 (EDT) To: Paul Eggert , Steve Crocker , Time zone mailing list , IETF-Calsify Cc: tzdist-bis@ietf.org, Daniel Migault , Martin Burnicki References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> <118a452c-25ba-8427-4401-5465270da738@cs.ucla.edu> From: Ken Murchison Organization: FastMail US LLC Message-ID: <5a63c02a-5ae1-15c3-fbb5-7baba149dbfa@fastmail.com> Date: Thu, 18 Jul 2019 16:26:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <118a452c-25ba-8427-4401-5465270da738@cs.ucla.edu> Content-Type: multipart/mixed; boundary="------------A833717AE33B1BE238FCDF48" Content-Language: en-US Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA -- estimating the operational parameters 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, 18 Jul 2019 20:26:19 -0000 This is a multi-part message in MIME format. --------------A833717AE33B1BE238FCDF48 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/18/19 4:15 PM, Paul Eggert wrote: > Steve Crocker wrote: >> Early in this thread it was mentioned the the time zone database >> should be >> served in a fashion similar to DNS.  My first thought was the numbers >> are >> wildly different.  I jotted down a first cut at identifying the relevant >> operational parameters.  Perhaps the people proposing this service can >> flesh out the quantitative aspects. > > Here are some estimates. There is no central TZDIST server now, so all > the non-size estimates are for if/when that happens. The estimated > rate of change for these numbers is all zero, except for the database > size where I'd estimate a growth of 5%/year (this is just off the top > of my head). > > > Frequency of database update: 18 times per year has been the worst > case since the project started in the 1980s. Recently updates have > occurred three to ten times per year. > > Frequency of access: If we're assuming a pull model like TZDIST with > primary and secondary servers, I would expect queries once every > hour-or-so from each downstream server that wants to be up-to-date. > Usually the response will be "nothing has changed". > > Required response time: Most clients and servers can be expected to > have a (possibly-stale) copy of the data already, which they can fall > back on. So I would say "minutes". > > Required uptime: Again, not crucial. I would say 90% would be enough. > > > For sizes, it depends on data format and whether you want all the data. > > Size of entire tzdb database (including all time zone history, version > info, and legal notices), in minimal source-code (text) form: 111 kB > uncompressed, 27 kB compressed via gzip, 22 kB compressed via lzip. > > Size of entire tzdb database in binary (TZif) form in traditional > form: 456 kB uncompressed, 152 kB tar+gzip, 68 kB tar+lzip. This > includes all time zone history but omits version info and legal notices. > > Same size, but with zic's new '-b slim' option that relies on Internet > RFC 8536 instead of attempting to work around bugs in older > applications: 216 kB uncompressed, 77 kB tar+gzip, 43 kB tar+lzip. > > I don't know how to compute the size of tzdb converted into iCalendar > form, but my guess is that it'd be the same order-of-magnitude as the > TZif files. My current set of iCalendar VTIMEZONEs (using symlinks for aliases) is also 77kB tar+gz. > > All sizes are for ordinary (POSIX) tzdb, not for the rarely-used > leapsecond variant. > > _______________________________________________ > Tzdist-bis mailing list > Tzdist-bis@ietf.org > https://www.ietf.org/mailman/listinfo/tzdist-bis -- Ken Murchison Cyrus Development Team Fastmail US LLC --------------A833717AE33B1BE238FCDF48 Content-Type: text/x-vcard; name="murch.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="murch.vcf" bnVsbA== --------------A833717AE33B1BE238FCDF48-- From nobody Thu Jul 18 13:30:15 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 45AC41200EF for ; Thu, 18 Jul 2019 13:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 nwBBBwrKHn7s for ; Thu, 18 Jul 2019 13:30:11 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 155B1120033 for ; Thu, 18 Jul 2019 13:30:11 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id s145so21554688qke.7 for ; Thu, 18 Jul 2019 13:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hPcucLzL7jAeZtHF/tWwmZxdoMFBWnbDvvC5FLxAh9A=; b=fXa9lqguTTIURX4Gzf6EMHz/w/zGaibSwk15JRvqX6WOCEflTePgWQOjZph2G2mxQ4 eGnSG9AyqFnnpN3iq/Dh6ia2FvA0BAaykb54Nr2ptQKiOHosc8QTsOQj/elEfB+yVx2Y bujP74t6YKMFG0Cbknl/N1TG3TY/Fh8hg5JuN5SxQfVabmtJ0qt4/Dm4RHZmF76jUM7s QDy00JutsSymbun78rPn+T6ogLh1S1sdbZZz4qyQfs5moPU6aqJEuv+MxIGwMJ+wN7gv ojs3abt6omI6+vL7wRLcnjY50I/2bwlL7lrS6uGZ21m1OCNHLHNLFhXrbolt5cFV6vSK 1qJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hPcucLzL7jAeZtHF/tWwmZxdoMFBWnbDvvC5FLxAh9A=; b=tIQnXxRveKCrmzeTVPl7tyCMmxwb+xPqymls+xPlYFrKgffoAKYU5DM0jFE7F6uyLI a+XhOyBmgV42GapV03aNYPpT6TExKLcnoR/By+N49FUjbw3m3ZC6fjbTeBIhkaII5Xrw DW/yYYZVAXju4QS2UBzULVePXR58juZxVj48YxF0c2mhCgaWN3E+eCwREUXmphYxZOAM 4YK6Th2YNNxTQN73wdj8Ri//feisr1imyNEMgKDLbrBT0a1/LlzWO3u5B+gFQkNdiHEM s7RAnF7pWGD6oB2DN73SD3hP/+K5AkBfEsJu3MiTUBi93JfpjpHplxcVcMe8cAAIBr2p k+iQ== X-Gm-Message-State: APjAAAU2RD1iQqyr9Ff8s9pnz6RYMtg9PSX1hJBwYL57KBFYb8YrjPfP ouaJnaUFd8VQ0WA66REthFw= X-Google-Smtp-Source: APXvYqx5woNmxUfDec7IEV7d0WelltO6+AkB2j5zYzYVaUIP3Dw6pTAugPwTeb1IdLCD0G51aSpMqg== X-Received: by 2002:a05:620a:1447:: with SMTP id i7mr32790725qkl.254.1563481810047; Thu, 18 Jul 2019 13:30:10 -0700 (PDT) Received: from ?IPv6:2600:380:927c:5de8:f58d:ec9c:c9ec:1e2e? ([2600:380:927c:5de8:f58d:ec9c:c9ec:1e2e]) by smtp.gmail.com with ESMTPSA id l63sm12733713qkb.124.2019.07.18.13.30.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2019 13:30:09 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Steve Crocker X-Mailer: iPhone Mail (16F203) In-Reply-To: <5a63c02a-5ae1-15c3-fbb5-7baba149dbfa@fastmail.com> Date: Thu, 18 Jul 2019 16:30:08 -0400 Cc: Paul Eggert , Time zone mailing list , IETF-Calsify , tzdist-bis@ietf.org, Daniel Migault , Martin Burnicki , Steve Crocker Content-Transfer-Encoding: quoted-printable Message-Id: References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> <118a452c-25ba-8427-4401-5465270da738@cs.ucla.edu> <5a63c02a-5ae1-15c3-fbb5-7baba149dbfa@fastmail.com> To: Ken Murchison Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA -- estimating the operational parameters 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, 18 Jul 2019 20:30:14 -0000 Paul and Ken, Thanks for these estimates. It doesn=E2=80=99t seem to me the legal verbiage would be part of the regula= r download, so that would reduce the payload a bit. Steve Sent from my iPhone > On Jul 18, 2019, at 4:26 PM, Ken Murchison wrote: >=20 >=20 >> On 7/18/19 4:15 PM, Paul Eggert wrote: >> Steve Crocker wrote: >>> Early in this thread it was mentioned the the time zone database should b= e >>> served in a fashion similar to DNS. My first thought was the numbers ar= e >>> wildly different. I jotted down a first cut at identifying the relevant= >>> operational parameters. Perhaps the people proposing this service can >>> flesh out the quantitative aspects. >>=20 >> Here are some estimates. There is no central TZDIST server now, so all th= e non-size estimates are for if/when that happens. The estimated rate of cha= nge for these numbers is all zero, except for the database size where I'd es= timate a growth of 5%/year (this is just off the top of my head). >>=20 >>=20 >> Frequency of database update: 18 times per year has been the worst case s= ince the project started in the 1980s. Recently updates have occurred three t= o ten times per year. >>=20 >> Frequency of access: If we're assuming a pull model like TZDIST with prim= ary and secondary servers, I would expect queries once every hour-or-so from= each downstream server that wants to be up-to-date. Usually the response wi= ll be "nothing has changed". >>=20 >> Required response time: Most clients and servers can be expected to have a= (possibly-stale) copy of the data already, which they can fall back on. So I= would say "minutes". >>=20 >> Required uptime: Again, not crucial. I would say 90% would be enough. >>=20 >>=20 >> For sizes, it depends on data format and whether you want all the data. >>=20 >> Size of entire tzdb database (including all time zone history, version in= fo, and legal notices), in minimal source-code (text) form: 111 kB uncompres= sed, 27 kB compressed via gzip, 22 kB compressed via lzip. >>=20 >> Size of entire tzdb database in binary (TZif) form in traditional form: 4= 56 kB uncompressed, 152 kB tar+gzip, 68 kB tar+lzip. This includes all time z= one history but omits version info and legal notices. >>=20 >> Same size, but with zic's new '-b slim' option that relies on Internet RFC= 8536 instead of attempting to work around bugs in older applications: 216 k= B uncompressed, 77 kB tar+gzip, 43 kB tar+lzip. >>=20 >> I don't know how to compute the size of tzdb converted into iCalendar for= m, but my guess is that it'd be the same order-of-magnitude as the TZif file= s. >=20 >=20 > My current set of iCalendar VTIMEZONEs (using symlinks for aliases) is als= o 77kB tar+gz. >=20 >=20 >=20 >>=20 >> All sizes are for ordinary (POSIX) tzdb, not for the rarely-used leapseco= nd variant. >>=20 >> _______________________________________________ >> Tzdist-bis mailing list >> Tzdist-bis@ietf.org >> https://www.ietf.org/mailman/listinfo/tzdist-bis >=20 > --=20 > Ken Murchison > Cyrus Development Team > Fastmail US LLC >=20 > From nobody Thu Jul 18 13:51:25 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 88056120431; Thu, 18 Jul 2019 13:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 tAECmvhs0cFY; Thu, 18 Jul 2019 13:51:13 -0700 (PDT) Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16C621208B7; Thu, 18 Jul 2019 13:51:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DE1CD1626E9; Thu, 18 Jul 2019 13:51:12 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id XucU0vkeM08a; Thu, 18 Jul 2019 13:51:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 389661626EA; Thu, 18 Jul 2019 13:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4qUASmhajxuU; Thu, 18 Jul 2019 13:51:12 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 0446D1626E8; Thu, 18 Jul 2019 13:51:12 -0700 (PDT) To: Steve Crocker , Ken Murchison Cc: Time zone mailing list , IETF-Calsify , tzdist-bis@ietf.org, Daniel Migault , Martin Burnicki References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> <118a452c-25ba-8427-4401-5465270da738@cs.ucla.edu> <5a63c02a-5ae1-15c3-fbb5-7baba149dbfa@fastmail.com> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Thu, 18 Jul 2019 13:51:11 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA -- estimating the operational parameters 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, 18 Jul 2019 20:51:21 -0000 Steve Crocker wrote: > It doesn=E2=80=99t seem to me the legal verbiage would be part of the r= egular download, so that would reduce the payload a bit. Sorry, I shouldn't have distracted the performance discussion by mentioni= ng that=20 verbiage. It's so small that eliminating it isn't worth the effort unless= one is=20 trying to win a compression contest. Here's a complete copy of the verbia= ge: # This zic input file is in the public domain. From nobody Thu Jul 18 13:53:50 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 60783120124 for ; Thu, 18 Jul 2019 13:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 RXCPhmsp8iF7 for ; Thu, 18 Jul 2019 13:53:46 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 A29BC1200E0 for ; Thu, 18 Jul 2019 13:53:46 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id w17so28701087qto.10 for ; Thu, 18 Jul 2019 13:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shinkuro-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HSFSI4YLYXYPF357vfRHRlhCJQuNAyLHWEFEk9CDIAI=; b=CtWZol2toXsD+MoAG3L1venW2DTkJW6FPhl15WtW+NUgfBtZqwRew2/M4ERQmubj7D utiRfPtEg32Ah2nNpmQPz9ddR8nZjBRKwyNPxwaqP3V8JMurSGOGUggUu+LnFH9rQkz5 ZId5+tkBeDk5e2Q9/rEevUbTJGrPFP6URZV6Fnc8QExSrhsfZtciXz25S0kBH8v3DskP a/ax7xWDX6THQLEd6HXKrwGP6IiysB34SOWyInUD6+guAmfj2gQiWbqZukfJf1G5Xrr8 PA0dagLrUuJVQNddoJonZRiSDRTmnTLiNngXQtS+vXTcMhpFTICK3U2ga5dxxZNp4NZ8 L9Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HSFSI4YLYXYPF357vfRHRlhCJQuNAyLHWEFEk9CDIAI=; b=PMZAbgaiLpxI+NWdYQkxc2BP00ZtsGcJxxcw2/L80N1kboM6/m9lop/9ddm38t9o3X OAHDhXDNHw6qgyFXkOkooGGumrkT+nx/Js6dW5/Ucblld0SGxzWhtkk8JdHnewf+859y w9WTDiJ33O5tJDiUN8Fvw6Bi4QWF9TyCVqh+BCrrh480PrWmlFe5iYVCHwwueWfoplRk cxdFy/4mJA+gqa9dfMIDcDYYV6MhPR3wjF+kkpdxSnzaXh4UeYQU+4GTHH+dYurVRxXH 5i0pUbXO8+BRlthhXxU7Yyp4RZYXKWNe6QmtEEzppBfUADi2WngRv3X/GY0MT0eKXcPh 1gaQ== X-Gm-Message-State: APjAAAV9Sqx9gyDefOgahT5xmU5/mc+/p369XP9n8AfU6+Ga889IWTjJ Sib2nhV4zwS8pelBNlMNGh8= X-Google-Smtp-Source: APXvYqzso3ZCgPWBA7cRKcnGOLrZIEBP/TSO5r/eaCfzeYdpBEglQCCTvqAaoOIc4XlBCLjAC513Dg== X-Received: by 2002:ac8:1a3c:: with SMTP id v57mr33564968qtj.339.1563483225727; Thu, 18 Jul 2019 13:53:45 -0700 (PDT) Received: from ?IPv6:2600:380:927c:5de8:f58d:ec9c:c9ec:1e2e? ([2600:380:927c:5de8:f58d:ec9c:c9ec:1e2e]) by smtp.gmail.com with ESMTPSA id y3sm14201428qtj.46.2019.07.18.13.53.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jul 2019 13:53:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Steve Crocker X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Thu, 18 Jul 2019 16:53:44 -0400 Cc: Ken Murchison , Time zone mailing list , IETF-Calsify , tzdist-bis@ietf.org, Daniel Migault , Martin Burnicki Content-Transfer-Encoding: quoted-printable Message-Id: References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> <118a452c-25ba-8427-4401-5465270da738@cs.ucla.edu> <5a63c02a-5ae1-15c3-fbb5-7baba149dbfa@fastmail.com> To: Paul Eggert Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA -- estimating the operational parameters 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, 18 Jul 2019 20:53:49 -0000 :) Sent from my iPhone > On Jul 18, 2019, at 4:51 PM, Paul Eggert wrote: >=20 > Steve Crocker wrote: >> It doesn=E2=80=99t seem to me the legal verbiage would be part of the reg= ular download, so that would reduce the payload a bit. >=20 > Sorry, I shouldn't have distracted the performance discussion by mentionin= g that verbiage. It's so small that eliminating it isn't worth the effort un= less one is trying to win a compression contest. Here's a complete copy of t= he verbiage: >=20 > # This zic input file is in the public domain. From nobody Thu Jul 18 15:54:36 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 226111200E7; Thu, 18 Jul 2019 15:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Pch8lpZ-bE9i; Thu, 18 Jul 2019 15:54:32 -0700 (PDT) Received: from zimbra.cs.ucla.edu (zimbra.cs.ucla.edu [131.179.128.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C4B120041; Thu, 18 Jul 2019 15:54:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 0A76E1626E6; Thu, 18 Jul 2019 15:54:32 -0700 (PDT) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id H8pYHrwAS34o; Thu, 18 Jul 2019 15:54:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 458C31626E8; Thu, 18 Jul 2019 15:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ag9pPa7xcH7y; Thu, 18 Jul 2019 15:54:31 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 158AD1626E6; Thu, 18 Jul 2019 15:54:31 -0700 (PDT) To: Daniel Migault References: From: Paul Eggert Organization: UCLA Computer Science Department Cc: IETF-Calsify , tzdist-bis@ietf.org, Time zone mailing list Message-ID: Date: Thu, 18 Jul 2019 15:54:30 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 18 Jul 2019 22:54:34 -0000 Here are some other thoughts about any potential IANA effort in this area: * As others have mentioned, the effort should address authentication of the timezone data. It would be helpful to have a real authentication expert in on this, since we want something simple and scalable and workable downstream (see below). * Each tzdb release comes with a version number like "2019b", development commits have version numbers like "2019b-11-gd8c6bf2". Downstream publishers often make minor changes to the data, and some append a suffix to the version number to indicate this. The mechanism for publishing this number is specified only loosely in Internet RFC 7808 section 3.10, and presumably the IANA effort would do something more specific. Downstream modifications will complicate data authentication. * Each tzdb release has auxiliary metadata files zone1970.tab and iso3166.tab that contain vague geographical information associated with each tzdb entry. (In some cases this vagueness is intentional, to avoid running into political disputes.) These files are not covered by TZDIST but some POSIX-style clients use them. How should metadata like this be addressed? * Each tzdb release has an auxiliary data file 'leapseconds' that is widely used by clients running NTP and related software. TZDIST has a "leapseconds" action that conveys the information in a different format, and we would need to make sure that this all hooks up correctly. * It'd be helpful to support not only TZDIST, but also a reasonably simple protocol, presumably based on HTTPS transfer of the data since HTTPS is widely supported. This could be used by platforms that don't support TZDIST, or that need auxiliary metadata that is outside the scope of TZDIST. For example, many NTP hosts need a 'leapseconds' file but don't support TZDIST or grok its leap seconds data format. From nobody Thu Jul 18 23:13:19 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 9C6261200DB; Thu, 18 Jul 2019 23:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.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 entKPIT1bCj1; Thu, 18 Jul 2019 23:13:14 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-eopbgr1310090.outbound.protection.outlook.com [40.107.131.90]) (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 7FDE612002F; Thu, 18 Jul 2019 23:13:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AX+L+FMbKpnLcYMNQBPZBhA9GMbaawBEduxQXT0cbDjQF76fTa1Le2CwwtcmorYwoQVPvto5Sf0zIgTscvBQ593X6J2ilMalT7nEEqLlEAbga7cJkhuFbuo5KduoYz3jAjaKU63hFsumNNjL8kKJv/Z0TneMUln3/1hEJ8bnNt3mke/kBb4ZZR86ZTpxD9QnjtVcZUvh5PD10XaLGInp7ZUBbckbp98mnvIicwk8fADqWfbNTf6pFwqIUAHJpMPM6fpvJklYSi5Pln2Oo4RRbMc1bt+AbDUPjUfJ4wsBEtQdWav4LidpRsOAC+QtNqtPjNzayWiOlrs6niu1z1v8iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bZ8U/4PoBdYtHdinlUCJc8x+WLZsrlT2nDylMcmbc+Q=; b=ZZm7epH9O2snw3dTiX3qIVvXg51XvwEqS5QpDgAC8rwTD45ZqIHkBu6+9V5JXn45HDmg/jVXlZBcTlDlzzyEGhYxgpQf/wHHmwTjT2Fghl3ADk5q2WxzKSdLkGsKIDf86O3jjiRqhPG0uU25WO0+YkcTEzu5WQVhMjdlCc+XENR8GgCgbanXXgz5+AER3/aku4b94t45/6SBeYx5sH/GP+Qbpqpn5ZJIeugSr3tlSsohV3FBvM+ofkXKQEElSQxY6t4AvB5IqIcrEE58YPJG4xWg9DmNFz092cvaBzA8qIMTVzkqraLHtSo3YfSmpP5jn8MU6Gq6mFdfT6xEmFr8lw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=it.aoyama.ac.jp;dmarc=pass action=none header.from=it.aoyama.ac.jp;dkim=pass header.d=it.aoyama.ac.jp;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bZ8U/4PoBdYtHdinlUCJc8x+WLZsrlT2nDylMcmbc+Q=; b=s5qwvSPWIC2vHAmtVsU4vccRQBRU4wQ15YqrEn2a+CGliE1s363ByRFvlYpLgctEdJ4oSlOuU7A/fe4Cu47Ty/Ux2nLl7Kf3+TWubYV25mUMGvM0R/ojHQLW64S/G/uq0W/7QsrwHkd/hNC5C9tKc9QB/ywfHt2bwlLMaYyjMl8= Received: from TY2PR01MB3401.jpnprd01.prod.outlook.com (20.178.141.204) by TY2PR01MB4715.jpnprd01.prod.outlook.com (20.179.170.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Fri, 19 Jul 2019 06:13:10 +0000 Received: from TY2PR01MB3401.jpnprd01.prod.outlook.com ([fe80::cda0:9cf9:9530:a96e]) by TY2PR01MB3401.jpnprd01.prod.outlook.com ([fe80::cda0:9cf9:9530:a96e%7]) with mapi id 15.20.2073.012; Fri, 19 Jul 2019 06:13:10 +0000 From: =?utf-8?B?TWFydGluIEouIETDvHJzdA==?= To: Daniel Migault , Eliot Lear CC: "tzdist-bis@ietf.org" , Paul Eggert , IETF-Calsify , Martin Burnicki , Michael Douglass Thread-Topic: [Tzdist-bis] [calsify] tzdist and IANA Thread-Index: AQHVPUL0OWAT5MdY8E6NTE86Awk3gqbQDliAgABgrQCAAQiGAA== Date: Fri, 19 Jul 2019 06:13:10 +0000 Message-ID: References: <47038bd0-210a-4dbc-173c-15bfa89ac54f@cs.ucla.edu> <6a50708d-5fac-1da9-56b3-ed1cea793752@fastmail.com> <6b1616e3-bfc0-a22a-2aa9-11033c525ff3@cs.ucla.edu> <6e243cf0-a3ff-82a1-3cae-70fbf699f1f7@gmail.com> <98A352CD-3386-49FB-B6C1-D4EC61BB79EC@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: TYAPR03CA0013.apcprd03.prod.outlook.com (2603:1096:404:14::25) To TY2PR01MB3401.jpnprd01.prod.outlook.com (2603:1096:404:d1::12) authentication-results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [133.2.210.64] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 79e75232-afca-4432-37c2-08d70c102c94 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7025125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:TY2PR01MB4715; x-ms-traffictypediagnostic: TY2PR01MB4715: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01039C93E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400004)(346002)(376002)(396003)(136003)(366004)(199004)(189003)(26005)(6116002)(3846002)(85182001)(186003)(68736007)(102836004)(66066001)(6486002)(54906003)(386003)(6506007)(786003)(53546011)(14444005)(486006)(6436002)(53936002)(316002)(6246003)(6512007)(110136005)(8676002)(508600001)(45080400002)(25786009)(256004)(4326008)(99286004)(71190400001)(71200400001)(31686004)(52116002)(85202003)(14454004)(229853002)(305945005)(7736002)(76176011)(81166006)(446003)(2906002)(31696002)(5660300002)(86362001)(8936002)(476003)(2616005)(66946007)(81156014)(66556008)(66446008)(64756008)(66476007)(11346002); DIR:OUT; SFP:1102; SCL:1; SRVR:TY2PR01MB4715; H:TY2PR01MB3401.jpnprd01.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ECAV2dtMYT56vKY6WJv0VFjNgyupJO4Zrn8u2Jza5Db9wMg6cGZdsXp/rhnMXTM/CaHSOfUISkA6a3c6wqWSY30YGT7ZQKNs6064XIaNk/LE94RPO/149gmIg732wcuIQvRhNTofwr9DZubb2jQS0fbEhcm7DrdtLNkfb9CBnMi4w/ggj5iCiMV8Ibee6BuvJzTVUaNL6RwsWebqy2HAlSFl+L0pQMJKP1BDrkrQwlnY05k4iuBvZLePSZNjkQshDAMPJEbreMG7cDGlMjHd0yNyMbaQ/P2A+6QEfr1LA4pknxRrxcvNg6dn91mVDss0KmBx1u29q6xI+op3DB2wP2SvzgWYY9s85YeFpy617pKLL2mH/6HOboLJmIsuvn8ksw81EhUypg7gG77IfNIy1NhRZsFiJlsCnRYfcZ50yiU= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 79e75232-afca-4432-37c2-08d70c102c94 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2019 06:13:10.5184 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: duerst@it.aoyama.ac.jp X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB4715 Archived-At: Subject: Re: [calsify] [Tzdist-bis] tzdist and IANA 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, 19 Jul 2019 06:13:17 -0000 T24gMjAxOS8wNy8xOCAyMzoyNiwgRGFuaWVsIE1pZ2F1bHQgd3JvdGU6DQo+IE9uIFRodSwgSnVs IDE4LCAyMDE5IGF0IDQ6NDAgQU0gRWxpb3QgTGVhciA8bGVhckBjaXNjby5jb20+IHdyb3RlOg0K DQo+PiBJIGd1ZXNzIEkgd291bGQgd2FudCB0byBzZWUgY29tbWl0bWVudCBmcm9tIHRob3NlIHdo byBwcm92aWRlIFRaIHNlcnZpY2UNCj4+IHRvIHRoZWlyIGN1c3RvbWVycyB0b2RheSB0byBnbyB0 byBzdWNoIGEgbmV3IHNlcnZpY2UgYmVmb3JlIGludmVzdGluZyBhIGxvdA0KPj4gb2YgbW9uZXku ICBXb3VsZCBSZWQtaG90LCBBcHBsZSwgTWljcm9zb2Z0LCBEZWJpYW4sIFVidW50dSwgb3IgYW55 IG9mIHRoZQ0KPj4gb3RoZXJzIHdhbnQgdG8gdXNlIGl0PyAgSSBhbHNvIHJlYWxpemUgdGhhdCBJ Q0FOTiBpcyB3ZWxsIHBvc2l0aW9uZWQgdG8NCj4+IGZ1bmQgdGhpcyBzb3J0IG9mIHRoaW5nLCBi dXQgaXQgaXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgaXQgaXMgcmlnaHQgZm9yDQo+PiB0aGVtIHRv IGRvIHNvLiAgVGhlcmUgaGFzIHRvIGJlIGEgcmVhbCBuZWVkLCBhbmQgdGhvc2Ugd2hvIHJlYWxs eSBuZWVkIGl0DQo+PiBwZXJoYXBzIHNob3VsZCBmb290IHRoZSBiaWxsLg0KDQo+IElmIHRoZXNl IGNvbXBhbmllcyBhcmUgb24gdGhlIGxpc3QgaXQgd291bGQgYmUgZ29vZCB0aGV5IHNoYXJlIHRo ZWlyDQo+IHRob3VnaHRzLCBvdGhlcndpc2UgaXQgd291bGQgYmUgZ29vZCB0byBjb250YWN0IHRo ZW0gaWYgYW55IG9mIHlvdSBoYXZlDQo+IHNvbWUgY29udGFjdHMuDQoNCkknbSBub3Qgd29ya2lu ZyBhdCBhbnkgb2YgdGhlc2UgY29tcGFuaWVzLCBidXQgbXkgZ3Vlc3MgaXMgdGhhdCB0aGVzZSAN CmNvbXBhbmllcyBhcmUgdXNpbmcgdGhlIGRhdGEgZnJvbSBJQU5BLCBhbmQgaW50ZWdyYXRpbmcg aXQgaW50byB0aGVpciANCmFwcGxpY2F0aW9uIHVwZGF0aW5nIHByb2Nlc3Mgd2hpbGUgdmVyaWZ5 aW5nIGl0IHdpdGggaW5mb3JtYXRpb24gdGhleSANCm9idGFpbiBmcm9tIHRoZWlyIGxvY2FsIHN1 YnNpZGlhcmllcy4gVGhpcyB2ZXJpZmljYXRpb24sIGFuZCBtYXliZSBpbiANCnNvbWUgaW5zdGFu Y2VzIHNvbWUgcG9saXRpY2FsIGNvbnNpZGVyYXRpb25zLCBtYXkgYmUgdGhlIG1haW4gYmxvY2tz IGZvciANCm5vdCBzd2l0Y2hpbmcgdG8gYSB0b3RhbGx5IGF1dG9tYXRlZCB1cGRhdGluZyBzeXN0 ZW0uIEluIGFueSBjYXNlLCB0aGUgDQpudW1iZXIgb2Ygc3VjaCBjb21wYW5pZXMgaXMgc21hbGws IGFuZCBmb3IgdGhlbSwgdGhlIGN1cnJlbnQgDQpkaXN0cmlidXRpb24gc3lzdGVtIChkaXJlY3Rs eSBmcm9tIElBTkEpIGlzIGNvbXBsZXRlbHkgc3VmZmljaWVudC4NCg0KQmVjYXVzZSBvZiB0aGUg bGVhZCB0aW1lcyBpbnZvbHZlZCwgaXQncyBzdWZmaWNpZW50IGluIG1vc3QgY2FzZXMgdG8gDQpk ZXBsb3kgdGhlIGluZm9ybWF0aW9uIHZpYSB0aGUgbm93YWRheXMgd2VsbCBlc3RhYmxpc2hlZCBP UyB1cGRhdGUgDQpjaGFubmVscyAoZS5nLiBQYXRjaCBUdWVzZGF5LC4uLikuIE1vc3QgYXBwbGlj YXRpb25zIHRoZW4gZ2V0IHRoZSANCmluZm9ybWF0aW9uIGZyb20gdGhlIE9TLg0KDQpBcyBmb3Ig J2Zvb3QgdGhlIGJpbGwnLCB0aGUgdmFyaW91cyBPUyBtYWtlcnMgYXJlIGFscmVhZHkgZG9pbmcg c28uIFRoZSANCnF1ZXN0aW9uIGlzIHdoZXRoZXIgdGhleSB3b3VsZCBiZSByZWFkeSB0byBmb290 IGFub3RoZXIsIHNlcGFyYXRlIGJpbGwuDQoNCkluZGVwZW5kZW50IGFwcGxpY2F0aW9ucyAoaW5j bHVkaW5nIG1heWJlIHNvbWUgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2VzKSANCnRoYXQgZG9uJ3QgcmVs eSBvbiBPUyBpbmZvcm1hdGlvbiBtYXkgYmUgdGhlIGJlc3QgY2FuZGlkYXRlcyBmb3IgDQpiZW5l Zml0aW5nIGZyb20gYSBuZXcgZGlzdHJpYnV0aW9uIHNjaGVtZS4NCg0KSW4gYSBzZXBhcmF0ZSBt YWlsLCBhIHJlbGlhYmlsaXR5IHJlcXVpcmVtZW50IG9mIDkwJSB3YXMgbWVudGlvbmVkLiBUaGlz IA0KaXMgb2theSBpZiB0aGlzIHRyYW5zbGF0ZXMgaW50byAyaCBvZmYgcGVyIGRheSwgYnV0IGl0 IHdvdWxkIGJlIA0KaW5zdWZmaWNpZW50IGlmIGl0IHRyYW5zbGF0ZWQgaW50byAxIG1vbnRoIG9m ZiBwZXIgeWVhciwgaW4gYSBzaW5nbGUgDQpibG9jay4gU28gOTAlIGhhcyB0byBiZSBxdWFsaWZp ZWQuDQoNClJlZ2FyZHMsICAgTWFydGluLg0K From nobody Tue Jul 23 08:01: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 ECCB2120309 for ; Tue, 23 Jul 2019 08:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 3PLnvhfCIpyQ for ; Tue, 23 Jul 2019 08:01:30 -0700 (PDT) Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) (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 7524E1202BF for ; Tue, 23 Jul 2019 08:01:23 -0700 (PDT) Received: by mail-ua1-f51.google.com with SMTP id s4so17021158uad.7 for ; Tue, 23 Jul 2019 08:01:23 -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=3Z25DGFH/p1Ghka5iQEqT3vh8sxsL+9uW1Cbbu/RzUk=; b=avNRTP9AZfTBP0sJ8gHxYIjfj1Ndu46hiGCaT+Fypp/yRXx92YNOML769rRgmweKK9 COIm/lg7ZV9GQUDnoDGOgqZFW5SH3zj+m82Ey758jGUcoLv7QNSEybCJ42inCyNfdRX4 R40Roa3ey3hT+NJ2LiCyxWr5pt1AKFKVcy4Xg7poQye+gFJ2lpJx9kOTPROqrFZrWS3N niKH4mrsM2pLSC8BxaD/uvZtHXItjZIIhdsms5ZoXxS5Q1mD3G+VeGzNsrCczdaB/mpI 0o7D5Vdq06/2GGeG9po1HwGsEThQU2Bf1NSze6K2Q24any87Jogs8hHXEic5FM5d0aF9 5sIA== X-Gm-Message-State: APjAAAVWhp8VPaxzV4ttmmbNAfa884pw5tKwZU3wdsbJ5rQKe+xvZ3wI AFXSafM+aQrZH5cjHcjqfhCdKKdeYS+rFuI57IeAuQ== X-Google-Smtp-Source: APXvYqxOl0zliCxTbPcDsKmov523O+oVKvwih4l7biNDq5oYSq4kVM+COmTNm8HRSTL4aN+JeakDhU4Au95DXVR9roo= X-Received: by 2002:ab0:614d:: with SMTP id w13mr28403434uan.66.1563894082233; Tue, 23 Jul 2019 08:01:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Tue, 23 Jul 2019 11:01:10 -0400 Message-ID: To: IETF-Calsify Content-Type: multipart/alternative; boundary="0000000000003ce791058e5a7789" Archived-At: Subject: Re: [calsify] IETF105 agenda 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, 23 Jul 2019 15:01:32 -0000 --0000000000003ce791058e5a7789 Content-Type: text/plain; charset="UTF-8" Hi, Unless I have missed your notification, I have not received confirmation from presenter nor slides. Please provide your slides and confirmation you intend to present to the chairs so we can upload then to the tracker. Yours, Daniel On Thu, Jul 18, 2019 at 9:50 AM Daniel Migault wrote: > Hi, > > Calext will meet in Montreal on Wednesday July 24 15:50 - 16:50. > > Following up the scheme of our interim meeting collocated with calconnect, > it might be good we go through all current draft. > > If you believe a presentation is worth being made, please indicate the > time you need and provide the slides by Monday July 22. > If you believe that is not necessary, or you are not able to do it, please > provide a note on the mailing list of the advancement of the draft, issues > to be solved, date of the expected new version, as well as other > information you believe is useful. > > Please find a draft agenda below. > calext agenda > > * chairs slides (10 minutes) > * draft-ietf-calext-eventpub-extensions-13 ( 10 minutes Michael) > * draft-ietf-calext-jscalendar-17 and > draft-ietf-calext-jscalendar-icalendar-01 (10 minutes) > * draft-ietf-calext-subscription-upgrade-00 > * draft-ietf-calext-valarm-extensions-00 > * draft-ietf-calext-caldav-scheduling-controls-00 > * tzdist & IANA (Daniel 10 minutes) > > Yours, > Daniel > --0000000000003ce791058e5a7789 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Unless I have missed your not= ification, I have not received confirmation from presenter nor slides. Plea= se provide your slides and confirmation you intend to present to the chairs= so we can upload then to the tracker.=C2=A0

Yours= ,=C2=A0
Daniel

On Thu, Jul 18, 2019 at 9:50 AM Daniel Migaul= t <daniel.migault@ericsso= n.com> wrote:
Hi,=C2=A0

Calext will meet in Mont= real on Wednesday July 24 15:50 - 16:50.=C2=A0

Following up the scheme of our interim meeting collocated with calconnect= , it might be good we go through all current draft.=C2=A0

If you believe a presentation is worth being made, please indicate = the time you need and provide the slides by Monday July 22.=C2=A0=C2=A0
If you believe that is not necessary, or you are not able to do it, = please provide a note on the mailing list of the advancement of the draft, = issues to be solved, date of the expected new version,=C2=A0 as well as oth= er information you believe is useful.=C2=A0

= Please find a draft agenda below.=C2=A0
calext agenda

* ch= airs slides (10 minutes)
* draft-ietf-calext-eventpub-extensions-13 ( 10= minutes Michael)
* draft-ietf-calext-jscalendar-17 and draft-ietf-calex= t-jscalendar-icalendar-01 (10 minutes)
* draft-ietf-calext-subscription-= upgrade-00
* draft-ietf-calext-valarm-extensions-00
* draft-ietf-ca= lext-caldav-scheduling-controls-00
* tzdist & IANA (Daniel 10 minut= es)

Yours,=C2=A0
Daniel
--0000000000003ce791058e5a7789-- From nobody Tue Jul 23 08:03:45 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 CF123120302 for ; Tue, 23 Jul 2019 08:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=twitch.tv 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 2EACNlVDTGrs for ; Tue, 23 Jul 2019 08:03:29 -0700 (PDT) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) (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 5980A12036F for ; Tue, 23 Jul 2019 08:03:29 -0700 (PDT) Received: by mail-wr1-x444.google.com with SMTP id r1so43553058wrl.7 for ; Tue, 23 Jul 2019 08:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitch.tv; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ADmB1XfOvBA/6Zhnc8FcBcyaaLI/d2TV6qmaV/27Xg=; b=NfYmxYyRtF7jTtWQE+d9iLNKb3LDwbjwad66qY9TuYWuCYpSq5Gi//MLZWHTGX2JLw g3LWbQ2REF6xsvHy634np1JFYxdX5Uo263s8jvw8uZxP7cqRhQyj/m631B9BrIFN7lZE WcEWkmtHTwgSibAVS2/BqW3SY4Msg+Tuu9Ptw= 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=1ADmB1XfOvBA/6Zhnc8FcBcyaaLI/d2TV6qmaV/27Xg=; b=CZF4zEivY8aZmGNsogSUjiRboLKELFSoaOrWSq7y8ori61bdTm4x6UaT5m7bDE8d3z xi9+V2VzKMYY3pOxXYYcbixOUnNcMTZDm4zvBh0Y8AKCpro/PAxzMEQu97isXlRv6ZLn +mYN6B2wdqOjt58htNoFSej4c7exsqbCnOqe3xiFlzffZjWOAS14InuooOIIlPZukPOo USNucJ10fZhIS3zhQhd2diqyUkoyOGjbEIY5DiYDEF8fYDOVE3L2TefmsigrhOgZJB9v VDgyJKHOjwApbhoerA8aTuCPAfdrnFZY0RgPuD+Hpb8mOImcHZVbJQRPPaq/fuis46oo q97g== X-Gm-Message-State: APjAAAWebDCbCXRUgoVcfpCjjLM/e1IaqD/0poLWJFXEggbi9//pDCBk 8wOfpOri/Vj0BBSjWNXtdvjEKftCnDcGTLtK1A4ee09OWA== X-Google-Smtp-Source: APXvYqyv72VUCr+vDiBRwHRBARxZfMyCSKRrQrZ8ymUJpEm52di9aN0B8Jwu8frudwNQG0F0YqrUcaLbNwNA7heD2Ak= X-Received: by 2002:a5d:54c7:: with SMTP id x7mr52567573wrv.39.1563894207666; Tue, 23 Jul 2019 08:03:27 -0700 (PDT) MIME-Version: 1.0 References: <12d2d82e-121f-3583-592b-fcbd17f2b0d1@gmail.com> <17ad7de3-5957-eb65-a052-d6f9f93f2b23@gmail.com> In-Reply-To: From: Ryan Gunter Date: Tue, 23 Jul 2019 09:02:51 -0600 Message-ID: To: Doug Royer Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary="000000000000b6ee9d058e5a7e3b" Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 23 Jul 2019 15:03:39 -0000 --000000000000b6ee9d058e5a7e3b Content-Type: text/plain; charset="UTF-8" Hello, Appreciate the replies. Sorry for the delay. Is this a workflow process that involves scheduling? Or are you looking for > an XML/HTML (schema.org) web page solution? A massive percentage of the > schema.org schemas are CSS or HTML content. > This involves scheduling. We looked through schema.org quite a bit and noticed the same thing. The idea is the additional fields were to allow for easier machine parsing, while still functioning as a calendaring file. The two are not incompatible, as schema.org ties to MIME-types > (attachments). - See the schema.org contentType as one example. > Structured-Data has no benefit over ATTACH. I think people misunderstand > the ATTACH property. > Is this suggesting to use the ATTACH property with a defined data set from schema.org, or otherwise? If that's the case, we could work with schema.org to define these data sets? The original hope of the draft was to agree upon a way to provide network maintenance information within the file. If we went with the ATTACH or STRUCTURED-DATA route, would there be a way to define this data set or method within the IETF? I just want to make sure I understand the boundaries and drive this effort correctly. Ryan Gunter | *Twitch* | Network Engineering | +1.415.568.7607 On Tue, Jul 16, 2019 at 5:05 PM Doug Royer wrote: > On 7/16/19 4:44 PM, Michael Douglass wrote: > ject. > >> > >> The two are not incompatible, as schema.org ties to MIME-types > (attachments). - See the schema.org contentType as one example. > Structured-Data has no benefit over ATTACH. I think people misunderstand > the ATTACH property. > > > > So how as an attachment would we represent the example: > > > > STRUCTURED-DATA;FMTTYPE=application/ld+json; > > SCHEMA="https://schema.org/SportsEvent"; > > VALUE=TEXT:{\n > > "@context":"http://schema.org"\,\n > > "@type": "SportsEvent"\,\n > > "homeTeam": "Pittsburgh Pirates"\,\n > > "awayTeam": "San Francisco Giants"\n > > }\n > > Versus the current way, for which parsers already can read: > > ATTACH;FMTTYPE=text/SportsEvent;...:CID:sport-attachement1 > ... > ATTACH;FMTTYPE=text/Maintenance;...:CID:maint-attachement1 > > > >> > >> The W3C (schema.org) and the IETF are in agreement on object > identifiers. Schema.org allows for the definition of data sets, and they > are tied to mime types when sent as separate, non-web-page objects. > >> > >> Don't over complicate your data set. Define it, then map it to agreed > on names, value types, and when needed specific acceptable values. Then > decide if its values are primarily web-page-content, or a stand alone > transported objects. And if stand alone objects tied to calendar date/time, > then keep with the same format and do not invent another one, it will just > complicate parsers. > > I don't see how this complicates parsers: the value of structured-data > can be ignored if you're not interested and presumably you havea parser if > you are. > > Because you now have to write new code, to do the same as ATTACH. > > > > -- > > Doug Royer - (http://DougRoyer.US) > Douglas.Royer@gmail.com > 714-989-6135 > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --000000000000b6ee9d058e5a7e3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

Appreciate the replie= s.=C2=A0 Sorry for the delay.

Is this a workflow process that involves = scheduling? Or are you looking for an XML/HTML (schema.org) web page solution? = A massive percentage of the schema.org schemas are CSS or HTML content.

This involves scheduling.=C2=A0We looked thr= ough schema.org quite a= bit and noticed the same thing.=C2=A0 The idea is the additional fields we= re to allow for easier machine parsing, while still functioning as a calend= aring file.

The two are not incompatible, as schema.org ties to MIME-types= (attachments). - See the schema.org contentType as one example. Structured-Dat= a has no benefit over ATTACH. I think people misunderstand the ATTACH prope= rty.

Is this suggesting to use the AT= TACH property with a defined data set from schema.org, or otherwise?=C2=A0 If that's the case,= we could work with schema.= org to define these data sets?=C2=A0 The original hope of the draft was= to agree upon a way to provide network maintenance information within the = file.=C2=A0 If we went with the ATTACH or STRUCTURED-DATA route, would ther= e be a way to define this data set or method within the IETF?=C2=A0 I just = want to make sure I understand the boundaries and drive this effort correct= ly.


Ryan Gunter=C2=A0=C2=A0|=C2= =A0=C2=A0=C2=A0Twitch=C2=A0= =C2=A0=C2=A0|=C2=A0=C2=A0 Network Engineering=C2=A0 =C2=A0<= /font>| =C2=A0=C2=A0+1.415.5= 68.7607


On = Tue, Jul 16, 2019 at 5:05 PM Doug Royer <douglasroyer@gmail.com> wrote:
On 7/16/19 4:44 PM, Mich= ael Douglass wrote:
ject.
>>
>> The two are not incompatible, as schema.org ties to MIME-types (attach= ments). - See the schema.org contentType as one example. Structured-Data has = no benefit over ATTACH. I think people misunderstand the ATTACH property. >
> So how as an attachment would we represent the example:
>
> STRUCTURED-DATA;FMTTYPE=3Dapplication/ld+json;
>=C2=A0 =C2=A0SCHEMA=3D"https://schema.org/SportsEvent&quo= t;;
>=C2=A0 =C2=A0VALUE=3DTEXT:{\n
>=C2=A0 =C2=A0 =C2=A0"@context":"http://schema.org"\,\n<= br> >=C2=A0 =C2=A0 =C2=A0"@type": "SportsEvent"\,\n
>=C2=A0 =C2=A0 =C2=A0"homeTeam": "Pittsburgh Pirates"= ;\,\n
>=C2=A0 =C2=A0 =C2=A0"awayTeam": "San Francisco Giants&qu= ot;\n
>=C2=A0 =C2=A0}\n

Versus the current way, for which parsers already can read:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ATTACH;FMTTYPE=3Dtext/SportsEvent;...:CID:sport= -attachement1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ATTACH;FMTTYPE=3Dtext/Maintenance;...:CID:maint= -attachement1


>>
>> The W3C (schema.org) and the IETF are in agreement on object identif= iers. Schema.org allows for the definition of data sets, and they are tied = to mime types when sent as separate, non-web-page objects.
>>
>> Don't over complicate your data set. Define it, then map it to= agreed on names, value types, and when needed specific acceptable values. = Then decide if its values are primarily web-page-content, or a stand alone = transported objects. And if stand alone objects tied to calendar date/time,= then keep with the same format and do not invent another one, it will just= complicate parsers.
> I don't see how this complicates parsers: the value of structured-= data can be ignored if you're not interested and presumably you havea p= arser if you are.

Because you now have to write new code, to do the same as ATTACH.



--

Doug Royer - (http://DougRoyer.US)
Douglas.Royer@= gmail.com
714-989-6135

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--000000000000b6ee9d058e5a7e3b-- From nobody Tue Jul 23 12:02:52 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 568F112083D; Tue, 23 Jul 2019 12:02:36 -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.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <156390855626.27882.12300760263098236733@ietfa.amsl.com> Date: Tue, 23 Jul 2019 12:02:36 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-18.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, 23 Jul 2019 19:02:45 -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-18.txt Pages : 56 Date : 2019-07-23 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, and over time successor 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-18 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-18 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 Jul 23 12:49:17 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 448A612095E for ; Tue, 23 Jul 2019 12:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 fQ_0hsfMPWTX for ; Tue, 23 Jul 2019 12:49:02 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 DF530120952 for ; Tue, 23 Jul 2019 12:49:01 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id a97so17460471uaa.9 for ; Tue, 23 Jul 2019 12:49:01 -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=zEZ7hkCiEXjNiqE0p2JTi3iScRvQRs5FhIB4w06GxVw=; b=qwv48ntyMlggLtFlr7C0OuO4pBX+gNki7ygRDg8/vYYA8FiqQlRCl0DtAiVB0sOP/9 fTCl8PRgUXx3X8WGeT2ElW1KbozWLeVCgRtLQLqYQijABOWxzDTXH/h0oCkFEI3Cpn3X S+qoZvweNFa/Hp5rDPucr+Ej86HXrPpnsZJi45tCd3wRs5gIHefOHQUrIVBpEVsfDAde OI+LW+15UBYZQGWIHfHWtvSVNKq5yGe+s0rQZjQHKnV8gKQ93VOOxJZ2DZI79qxlzFsr 12ciZ+J3BNXwozyTNtnomeTTCRDFqJbOl/4lfKZHRhOjQZC2wwpBgzZ5a2rYYRtbK8gg awRA== 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=zEZ7hkCiEXjNiqE0p2JTi3iScRvQRs5FhIB4w06GxVw=; b=qJX8mf/Pphq1n4XkcPM1m+oelvXQDFFP2J863v4zvAMRC471urkIP0RuSeLMownNAc YRNjumAiLVU/3RHvCJDiyjdXoHw0R0Blgwk+c80JkNSr00jnscIxK63RbX9WNaK4nHx1 kAyJwPQSopUUUC0yaGb1IVMKS6nOY03RGn8TFankglq+0FVLswvkV25qt1LsJvCq0WKO ShiE/lWYSVIeWNkA9nYEFkNEZAuDI104STaDmMDzpQwQ2Q6NZ6hIQwegyuxojoT1I/x0 OsrUSGE/jo77yvOIecKRo9vfsP2XI+OQS3ltTEVBGdq1PM5AfDKwj/AhB3ps/r79tw7R VaWw== X-Gm-Message-State: APjAAAWjVXRO+5hGoPfxCYXwQKEDLcTe7QXvgKOeCRJbcnRqgUbS8N3z MrL5ejGYCXf9IC4lEHsaBaDaODx3 X-Google-Smtp-Source: APXvYqxs3gpVXJfGYoOZip5XBPHGO2BsDWz2Ca794zgG8oD8Mcz926fHSSKBZdOUQkhm3hqZzLCSqQ== X-Received: by 2002:ab0:7848:: with SMTP id y8mr31567489uaq.58.1563911340866; Tue, 23 Jul 2019 12:49:00 -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 x13sm6615538uaq.19.2019.07.23.12.49.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 12:49:00 -0700 (PDT) To: calsify@ietf.org References: From: Michael Douglass Message-ID: <524f0103-2265-794d-b806-9e283f23b2f4@gmail.com> Date: Tue, 23 Jul 2019 15:48:59 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------47B1B0BB05C75E3F15AF9350" Content-Language: en-US Archived-At: Subject: Re: [calsify] IETF105 agenda 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, 23 Jul 2019 19:49:15 -0000 This is a multi-part message in MIME format. --------------47B1B0BB05C75E3F15AF9350 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I did find the meeting management tool but I get this message when I log in: There is no person record associated with your login.. I was logged in with the only account that works. Maybe the wrong one? I'll pursue this and see what happens... On 7/18/19 09:50, Daniel Migault wrote: > Hi, > > Calext will meet in Montreal on Wednesday July 24 15:50 - 16:50. > > Following up the scheme of our interim meeting collocated with > calconnect, it might be good we go through all current draft. > > If you believe a presentation is worth being made, please indicate the > time you need and provide the slides by Monday July 22. > If you believe that is not necessary, or you are not able to do it, > please provide a note on the mailing list of the advancement of the > draft, issues to be solved, date of the expected new version,  as well > as other information you believe is useful. > > Please find a draft agenda below. > calext agenda > > * chairs slides (10 minutes) > * draft-ietf-calext-eventpub-extensions-13 ( 10 minutes Michael) > * draft-ietf-calext-jscalendar-17 and > draft-ietf-calext-jscalendar-icalendar-01 (10 minutes) > * draft-ietf-calext-subscription-upgrade-00 > * draft-ietf-calext-valarm-extensions-00 > * draft-ietf-calext-caldav-scheduling-controls-00 > * tzdist & IANA (Daniel 10 minutes) > > Yours, > Daniel > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify --------------47B1B0BB05C75E3F15AF9350 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I did find the meeting management tool but I get this message when I log in:

There is no person record associated with your login..

I was logged in with the only account that works. Maybe the wrong one? I'll pursue this and see what happens...

On 7/18/19 09:50, Daniel Migault wrote:
Hi, 

Calext will meet in Montreal on Wednesday July 24 15:50 - 16:50. 

Following up the scheme of our interim meeting collocated with calconnect, it might be good we go through all current draft. 

If you believe a presentation is worth being made, please indicate the time you need and provide the slides by Monday July 22.  
If you believe that is not necessary, or you are not able to do it, please provide a note on the mailing list of the advancement of the draft, issues to be solved, date of the expected new version,  as well as other information you believe is useful. 

Please find a draft agenda below. 
calext agenda

* chairs slides (10 minutes)
* draft-ietf-calext-eventpub-extensions-13 ( 10 minutes Michael)
* draft-ietf-calext-jscalendar-17 and draft-ietf-calext-jscalendar-icalendar-01 (10 minutes)
* draft-ietf-calext-subscription-upgrade-00
* draft-ietf-calext-valarm-extensions-00
* draft-ietf-calext-caldav-scheduling-controls-00
* tzdist & IANA (Daniel 10 minutes)

Yours, 
Daniel

_______________________________________________
calsify mailing list
calsify@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
--------------47B1B0BB05C75E3F15AF9350-- From nobody Tue Jul 23 12:52:45 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 8467E120943 for ; Tue, 23 Jul 2019 12:52:31 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, 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 HrAdR5SpX8_T for ; Tue, 23 Jul 2019 12:52:28 -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 934B9120966 for ; Tue, 23 Jul 2019 12:52:24 -0700 (PDT) Authentication-Results: mail.aegee.org/x6NJqLSC032755; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1563911542; i=dkim+MSA-tls@aegee.org; r=y; bh=twqPGB7N391eMZvLOF9Il5IriJAAKMBiiOHbvyvPxak=; h=Subject:From:To:Date; b=m9PKGd6uhbtOSDQYL/9RD/hG+lwdQKQ3YjPW+MFaDmZUKmYpiWPU+pBZcWkLJHM1J WBuTW3G8J9odpw6B7K9wRX1PhvTLbgCzKWXIszMeAGpetDy9qLXl0NhoEw7+KLYmGk ZlYCxF1gzrNtgB9cbaDNf5FG9HCS+2ee0ZT6rKgNdJ/aElB3nktN/v/wcENOnHKJSf VaQ1OsrfOanB5JjeEQpQVxoWugkgoqbrjvSTxLIRddunOvGSuo2dpsmEx/ORihxGCr w8SiIvg5Rivz5G3aoB5tAOkatuxgkshApB2cVVxvjnfGlC7AFKRxyXTb4ITbesqRC3 sYKMNJQtKWug/7FcKrHqgNHHaeDAOD7vkcJXssHBU5OOFj1t5cmEI6zW1UXx+LHOj5 ivSiVeiEFehu5wVwouu+bkERGuk5iHnz2dAqpdlDhldPx9Zvqsy8SlXKSh1RtzRj6C 5ZM1LCYfHwf5EyMW8DCeIea8cBaJKjtPEIRZjHMwUczH3c0AxdPcv/FROOpIoCwTJJ H3/uNMU7+2Q1Jrn18HLqfbLTm5WveQY8h9O6XrY8anAqOGATNyla0pqjFcJ1ipGNB8 VCVE4s8OcBovdFsYMSY9lj2ED6Ei7uKJvCFhaC0F/AtAGYUMYLBkuC8Uo+I6as6oN+ kvuRNhh37k6QSu+kegZa32uE= Authentication-Results: mail.aegee.org/x6NJqLSC032755; 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 x6NJqLSC032755 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 23 Jul 2019 19:52:22 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: IETF-Calsify Date: Tue, 23 Jul 2019 19:52:21 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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] Removing the Protection from CALDAV:supported-calendar-component-set Property 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, 23 Jul 2019 19:52:43 -0000 Hello, RFC 4791 “Calendaring Extensions to WebDAV (CalDAV)”, Section 5.2.3. “CALDAV:supported-calendar-component-set Property” defines supported-calendar-component-set as protected property: it cannot be changed by clients using a PROPPATCH request. What is the rationale for this? For a calendar created before RFC 7953 “Calendar Availability” was invented, there is no way for the CUA to add support for the VAVAILABILITY component afterwards. I propose erratum to https://tools.ietf.org/html/rfc4791#section-5.2.3 CALDAV:supported-calendar-component-set Property Type Technical Current text: Conformance: This property MAY be defined on any calendar collection. If defined, it MUST be protected and SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 12.14.1 of [RFC2518]). Description: … Any attempt by the client to store calendar object resources with component types not listed in this property, if it exists, MUST result in an error, with the CALDAV:supported-calendar-component precondition (Section 5.3.2.1) being violated. Since this property is protected, it cannot be changed by clients using a PROPPATCH request. However, clients can initialize the value of this property when creating a new calendar collection with MKCALENDAR. … New text: Conformance: This property MAY be defined on any calendar collection. If defined, it MAY be protected and SHOULD NOT be returned by a PROPFIND DAV:allprop request (as defined in Section 12.14.1 of [RFC2518]). Description: … Any attempt by the client to store calendar object resources with component types not listed in this property, if it exists, MUST result in an error, with the CALDAV:supported-calendar-component precondition (Section 5.3.2.1) being violated. Clients can initialize the value of this property when creating a new calendar collection with MKCALENDAR. … Rationale: The protected status of supported-calendar-component-set is removed, so that CUAs can add component types to existing callendars, which component types were not defined, when the calendar was created Plese provide feedback within a month, afterwards I will submit it over https://www.rfc-editor.org/errata_report.php . What will happen then? What are the chances, that nothing happens, and therefore the time for submitting this is practically lost. Regards Дилян From nobody Tue Jul 23 12:55:11 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 28477120970 for ; Tue, 23 Jul 2019 12:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 tUxdFVcFCowt for ; Tue, 23 Jul 2019 12:54:59 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 2CF5D12099C for ; Tue, 23 Jul 2019 12:54:59 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id i10so84408123iol.13 for ; Tue, 23 Jul 2019 12:54:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:organization:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=J1BaO6JuNHqRkfKIkbtR21rPMN8qy3QHH38A+y1C95k=; b=rie5hhTd/u6+ZRguWpjQnfte8f+IwzmGLX4p1QHChFsGtERxIJsc4PEb8hEZLJ9+BV 5BpRNiAep3td3dx3Yf2vpNVU8QCYQbqwCHIBVaj3Ud6jVHCbwU61DivmieY4n/bSoWDJ rw+lacMiXZsixZe3tDx/GGGVgx5rXOSb6yUvAWkKGe7wraXp0XMOO7VT2nsxLavHezoU ifpODw0d+3nm24LCXJsLws6XQqEJ61cXizX7RVVx3SI3ylyAoWC0FSFCB3pweRHgbu9g KJj09IpJ9nT+vGCEcxBHBf7bN44w3ZZBg7mROdDSb2ZMKg2m0YknrwQocy0KW3Tspbwy 6Niw== 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:cc:references:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=J1BaO6JuNHqRkfKIkbtR21rPMN8qy3QHH38A+y1C95k=; b=OmbHRrzJEKdeOECeUo/2XrO6qEBcIvTYvgCmWQF4P/D+tnlX6J8VGWj60/uyPn70WY gtksZvrKIadU44Mr2jgI//EoiaGhF7pzyJerUzbf2uagEEJkOprluhemqi+C58ARo/V5 LoFdUUR1I8nSe8oQTD7KxeGmULtu9JQnyzT5M6i2AHdJtJWNWRN0L0aq+o7vB9X5DQFw 3l7go7zMio7VjsVdyvGef2JXLR8SQlYwAX6zB1ukvsvdbNnnI6pj7/0skk4+Wro5OQEU Eqfp55AAEyzPuv3UIPXLDvt5GLIHJEfgH+IDby3bkAeCIrUWZw1DkOM9pQFQRVolkFd8 ZNpg== X-Gm-Message-State: APjAAAUoDI2htC3k3yifijhiROMuUDx1BM3+9Gc1uTsDK0cNQKDSjHE0 EmWblUgZJpQRdLsIEkAaroT1elFObsDt X-Google-Smtp-Source: APXvYqw+gGBzOLO0C6qkvSAimSxmNlKK4mUpHlej0tI5Q+jEvM+xEeb0WdS2wrpXiXZuWukgDL5+jw== X-Received: by 2002:a5d:9d58:: with SMTP id k24mr71134240iok.116.1563911698218; Tue, 23 Jul 2019 12:54:58 -0700 (PDT) Received: from [192.168.1.7] ([174.27.92.215]) by smtp.googlemail.com with ESMTPSA id m4sm39326186iok.68.2019.07.23.12.54.57 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 12:54:57 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: Ryan Gunter Cc: calsify@ietf.org References: <12d2d82e-121f-3583-592b-fcbd17f2b0d1@gmail.com> <17ad7de3-5957-eb65-a052-d6f9f93f2b23@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: <4a9a9e83-08b0-6d70-10d4-3c82a58ad398@gmail.com> Date: Tue, 23 Jul 2019 13:54:56 -0600 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 23 Jul 2019 19:55:09 -0000 On 7/23/19 9:02 AM, Ryan Gunter wrote: > > Is this suggesting to use the ATTACH property with a defined data set from schema.org , or otherwise?  If that's the case, we could work with schema.org to define these data sets?  The original hope of the draft was to agree upon a way to provide network maintenance information within the file.  If we went with the ATTACH or STRUCTURED-DATA route, would there be a way to define this data set or method within the IETF?  I just want to make sure I understand the boundaries and drive this effort correctly. One option is to create a new iCalendar component 'MAINTNOTE' and include it inline, as in: ... BEGIN:MAINTNOTE MAINTNOTE-PROVIDER:example.com MAINTNOTE-ACCOUNT: Twitch MAINTNOTE-MAINTENANCE-ID: WorkOrder-31415 MAINTNOTE-OBJECT-ID: ABC123 MAINTNOTE-IMPACT: OUTAGE MAINTNOTE-STATUS: CONFIRMED END:MAINTNOTE ... Which would be the 'iCalendar' way of doing it. Another option is if the data structure does not easily translate to iCalendar format, you could attach it with something like this for an included attachment (where text/maintnode would be replaced with whatever mime-type is assigned to identify your data): ... ATTACH;fmttype=text/maintnode;...:CID=maintnote-attach-id ... Or for an external object: ... ATTACH;fmttype=text/maintnode;...:https://example.com/maintnote-attach ... The advantage to ATTACH is that email and calendar tools like outlook, Thunderbird, and others will see the data as an attachment and allow the user to drag/drop it, without new code needing to be written just to pull it out, or to copy/paste it. Outlook, Thunderbird, and many other calendar clients already know how to handle ATTACH, even when they do not know what the mime-type does. Minimal changes to make a maintnode aware calendar client. Zero changes needed when the iCalendar application can already handle ATTACH, and copy/paste is what you need. And for custom iCalendar maintnode programs, MIME libraries already know how to handle mime multipart objects (CID or external). How an attachment is include in a mime object is already a standard. Custom maintnote processing code would just open the text/calendar MIME object and pull out the ATTACH;text/maintnote properties. Then call already implemented MIME libraries to extract the included maintnode attachments (a CID) and/or for fetching the URL provided for external maintnode attachments. Then your custom code does whatever it wants with the attachment and iCalendar data. The structured-data proposal has no advantages, and it would complicate recognizing the data as an attachment or extra data and require outlook, Thunderbird, and all other calendar clients be re-written to extract out the maintnote data from the iCalendar object, or someone would have to write a plug-in for all email clients and calendar clients to extract the data. (vs just using an copy/paste or using existing MIME libraries). As to schema.org. Any MIME object defined by them, can already be the content of an ATTACH iCalendar object. Just name the MIME-TYPE and provide the URL as the property value. It is not a schema.org vs IETF decision. You can (or not) define it with schema.org. You can ATTACH it as a defined schema.org object, or attach it as a non-schema.org object. Both with ATTACH. (Or go the MAINTNOTE component way). If it maps easily into iCalendar, use MAINTNOTE. If your data is part of a larger data set that is complicated, define it with schema.org, and iCalendar ATTACH it. Hope this helps. -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Wed Jul 24 07:33: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 9DDD812006F for ; Wed, 24 Jul 2019 07:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 WAgVhiarmft9 for ; Wed, 24 Jul 2019 07:33:12 -0700 (PDT) Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (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 62C4A120306 for ; Wed, 24 Jul 2019 07:33:10 -0700 (PDT) Received: by mail-ua1-f43.google.com with SMTP id o19so18528316uap.13 for ; Wed, 24 Jul 2019 07:33:10 -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=hS1k4nrvQt5lKNX7I3PI8rkxaS290yBmDeNMCsnd34M=; b=AS4C949RE2OLEbrdPp8TgVzjyWy1+NgPr4MAlBVII4SwFMkYwrIODAo3z20tQ2Ytvw VnpXjnXuPtzszkzvxQseKYMOYlqUE422uGJydu8C4Zz0IF3TPvpb4N0KxCIlVoQ3zK7B R2XJNDkKNBlwDlBNlHr91H5LG1zZPPdkEgVe1q7rcKBkAsTyU7gSN7c4ue0A71StQd44 pyhQla0lbQQS5514FkCb/E7H0UXy7lEquKs12APlVr/2yWwUXju7KZLdmm1i5TyX6C/K Pe8de7RYXI67st5Rc4l7RXTyZC18xMHZui2wLO3P/MK4CZDiRK/zDhfwrbVzuaSGv2Hr Z/XQ== X-Gm-Message-State: APjAAAWw8UL8b9ozeBwVTekGZ+80NlXDAJ6AP9yzXVe/5kEJHPeiFc13 +LjAxbVxoK+4rsdRbqsaptk7Z5xUnSD8njJ5Pi4= X-Google-Smtp-Source: APXvYqy226TjR4a6Zyt20BZuCO91h9pvLLOWj/KAv2Wj+IVbEd35m3Zog+GpFtLsO02ZrZ+FJKYgAdWmaQdKKSbOQrw= X-Received: by 2002:ab0:614d:: with SMTP id w13mr33060604uan.66.1563978789443; Wed, 24 Jul 2019 07:33:09 -0700 (PDT) MIME-Version: 1.0 References: <524f0103-2265-794d-b806-9e283f23b2f4@gmail.com> In-Reply-To: <524f0103-2265-794d-b806-9e283f23b2f4@gmail.com> From: Daniel Migault Date: Wed, 24 Jul 2019 10:32:58 -0400 Message-ID: To: Michael Douglass Cc: IETF-Calsify Content-Type: multipart/alternative; boundary="0000000000002e5e64058e6e30cd" Archived-At: Subject: Re: [calsify] IETF105 agenda 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, 24 Jul 2019 14:33:21 -0000 --0000000000002e5e64058e6e30cd Content-Type: text/plain; charset="UTF-8" Hi, I have uploaded the material, if you do not see it, please let me know. Yours, Daniel https://datatracker.ietf.org/meeting/105/session/calext On Tue, Jul 23, 2019 at 3:49 PM Michael Douglass wrote: > I did find the meeting management tool but I get this message when I log > in: > > There is no person record associated with your login.. > > I was logged in with the only account that works. Maybe the wrong one? > I'll pursue this and see what happens... > On 7/18/19 09:50, Daniel Migault wrote: > > Hi, > > Calext will meet in Montreal on Wednesday July 24 15:50 - 16:50. > > Following up the scheme of our interim meeting collocated with calconnect, > it might be good we go through all current draft. > > If you believe a presentation is worth being made, please indicate the > time you need and provide the slides by Monday July 22. > If you believe that is not necessary, or you are not able to do it, please > provide a note on the mailing list of the advancement of the draft, issues > to be solved, date of the expected new version, as well as other > information you believe is useful. > > Please find a draft agenda below. > calext agenda > > * chairs slides (10 minutes) > * draft-ietf-calext-eventpub-extensions-13 ( 10 minutes Michael) > * draft-ietf-calext-jscalendar-17 and > draft-ietf-calext-jscalendar-icalendar-01 (10 minutes) > * draft-ietf-calext-subscription-upgrade-00 > * draft-ietf-calext-valarm-extensions-00 > * draft-ietf-calext-caldav-scheduling-controls-00 > * tzdist & IANA (Daniel 10 minutes) > > Yours, > Daniel > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --0000000000002e5e64058e6e30cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

I have uploaded the material,= if you do not see it, please let me know.=C2=A0

Y= ours,=C2=A0
Daniel




On T= ue, Jul 23, 2019 at 3:49 PM Michael Douglass <mikeadouglass@gmail.com> wrote:
=20 =20 =20

I did find the meeting management tool but I get this message when I log in:

There is no person record associated with your login..

I was logged in with the only account that works. Maybe the wrong one? I'll pursue this and see what happens...

On 7/18/19 0= 9:50, Daniel Migault wrote:
=20
Hi,=C2=A0

Calext will meet in Montreal on Wednesday July 24 15:50 - 16:50.=C2=A0

Following up the scheme of our interim meeting collocated with calconnect, it might be good we go through all current draft.=C2=A0

If you believe a presentation is worth being made, please indicate the time you need and provide the slides by Monday July 22.=C2=A0=C2=A0
If you believe that is not necessary, or you are not able to do it, please provide a note on the mailing list of the advancement of the draft, issues to be solved, date of the expected new version,=C2=A0 as well as other information you believe is useful.=C2=A0

Please find a draft agenda below.=C2=A0
calext agenda

* chairs slides (10 minutes)
* draft-ietf-calext-eventpub-extensions-13 ( 10 minutes Michael)
* draft-ietf-calext-jscalendar-17 and draft-ietf-calext-jscalendar-icalendar-01 (10 minutes)
* draft-ietf-calext-subscription-upgrade-00
* draft-ietf-calext-valarm-extensions-00
* draft-ietf-calext-caldav-scheduling-controls-00
* tzdist & IANA (Daniel 10 minutes)

Yours,=C2=A0
Daniel

= 
____________=
___________________________________
calsify mailing list
calsify@ietf.org
https://www.ie=
tf.org/mailman/listinfo/calsify
_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--0000000000002e5e64058e6e30cd-- From nobody Wed Jul 24 08:40:04 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 45FD2120473 for ; Wed, 24 Jul 2019 08:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 g-v_rHJl_mJc for ; Wed, 24 Jul 2019 08:39:53 -0700 (PDT) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (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 75FA5120475 for ; Wed, 24 Jul 2019 08:39:53 -0700 (PDT) Received: by mail-vs1-f52.google.com with SMTP id h28so31632765vsl.12 for ; Wed, 24 Jul 2019 08:39:53 -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=5+TSx1OOLD2cBbrUA3zZtpc5p1TIZ419B4FBR7Wv1po=; b=V6LtPGAYHRiFmJ/QAOzlMbBKFt57bdCuah2+tr7HuqMXl+VDJDFWsi8jb2cmpmtXQI kQlsQD2IH3MhLqr4Bl9BP+N7UMcGCMbodn1B/lsJEGj/KEYvyzJBcGXUPSICH3VaSBZD oBBPNzQxsESNRVaY4Z9Gqo2wkcXtuMxXsfynjuLAZbvpyqf+u6KK7LfoP/z+2pBue487 fOqSGs37zaxHT3YR57SNClbLV1/JTD9NbdJf4WbqMXBzSnvPv5MzLrwlw2Qc9pLsC9mQ M15ap3UcEhlQbh1qwfZ/g8wDPZXkuKHqg+LyHaSppj5cbDJ00OOElQUKuksDqXSrNy7A iDKA== X-Gm-Message-State: APjAAAVLmCO6A30cti2ROOrWxsec+ty1TjKGeH/4572NAwnJ6gGziYOF 1K6HQ9iVhuKRbmliPw7Be5SZtPjGT2oQN5PvWv8= X-Google-Smtp-Source: APXvYqxH5FCZvLQGH8qbd6Ir6YL3JrhsOgcnRIM9UY3jC3ZthUqfrLGMIVNbFR7Oz/YXtP/4UTCAyregplb9Jz7Imr4= X-Received: by 2002:a05:6102:458:: with SMTP id e24mr28330267vsq.31.1563982792585; Wed, 24 Jul 2019 08:39:52 -0700 (PDT) MIME-Version: 1.0 References: <524f0103-2265-794d-b806-9e283f23b2f4@gmail.com> In-Reply-To: <524f0103-2265-794d-b806-9e283f23b2f4@gmail.com> From: Daniel Migault Date: Wed, 24 Jul 2019 11:39:41 -0400 Message-ID: To: Michael Douglass Cc: IETF-Calsify Content-Type: multipart/alternative; boundary="000000000000c97778058e6f1ea0" Archived-At: Subject: Re: [calsify] IETF105 agenda 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, 24 Jul 2019 15:40:02 -0000 --000000000000c97778058e6f1ea0 Content-Type: text/plain; charset="UTF-8" I checked with meetingecho team and it is probably because the session had not started. That should be fixed this afternoon. Yours, Daniel On Tue, Jul 23, 2019 at 3:49 PM Michael Douglass wrote: > I did find the meeting management tool but I get this message when I log > in: > > There is no person record associated with your login.. > > I was logged in with the only account that works. Maybe the wrong one? > I'll pursue this and see what happens... > On 7/18/19 09:50, Daniel Migault wrote: > > Hi, > > Calext will meet in Montreal on Wednesday July 24 15:50 - 16:50. > > Following up the scheme of our interim meeting collocated with calconnect, > it might be good we go through all current draft. > > If you believe a presentation is worth being made, please indicate the > time you need and provide the slides by Monday July 22. > If you believe that is not necessary, or you are not able to do it, please > provide a note on the mailing list of the advancement of the draft, issues > to be solved, date of the expected new version, as well as other > information you believe is useful. > > Please find a draft agenda below. > calext agenda > > * chairs slides (10 minutes) > * draft-ietf-calext-eventpub-extensions-13 ( 10 minutes Michael) > * draft-ietf-calext-jscalendar-17 and > draft-ietf-calext-jscalendar-icalendar-01 (10 minutes) > * draft-ietf-calext-subscription-upgrade-00 > * draft-ietf-calext-valarm-extensions-00 > * draft-ietf-calext-caldav-scheduling-controls-00 > * tzdist & IANA (Daniel 10 minutes) > > Yours, > Daniel > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --000000000000c97778058e6f1ea0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I checked with meetingecho team and it is probably because= the session had not started. That should be fixed this afternoon.

=
Yours,=C2=A0
Daniel
=C2=A0

On Tue, Jul = 23, 2019 at 3:49 PM Michael Douglass <mikeadouglass@gmail.com> wrote:
=20 =20 =20

I did find the meeting management tool but I get this message when I log in:

There is no person record associated with your login..

I was logged in with the only account that works. Maybe the wrong one? I'll pursue this and see what happens...

On 7/18/19 0= 9:50, Daniel Migault wrote:
=20
Hi,=C2=A0

Calext will meet in Montreal on Wednesday July 24 15:50 - 16:50.=C2=A0

Following up the scheme of our interim meeting collocated with calconnect, it might be good we go through all current draft.=C2=A0

If you believe a presentation is worth being made, please indicate the time you need and provide the slides by Monday July 22.=C2=A0=C2=A0
If you believe that is not necessary, or you are not able to do it, please provide a note on the mailing list of the advancement of the draft, issues to be solved, date of the expected new version,=C2=A0 as well as other information you believe is useful.=C2=A0

Please find a draft agenda below.=C2=A0
calext agenda

* chairs slides (10 minutes)
* draft-ietf-calext-eventpub-extensions-13 ( 10 minutes Michael)
* draft-ietf-calext-jscalendar-17 and draft-ietf-calext-jscalendar-icalendar-01 (10 minutes)
* draft-ietf-calext-subscription-upgrade-00
* draft-ietf-calext-valarm-extensions-00
* draft-ietf-calext-caldav-scheduling-controls-00
* tzdist & IANA (Daniel 10 minutes)

Yours,=C2=A0
Daniel

= 
____________=
___________________________________
calsify mailing list
calsify@ietf.org
https://www.ie=
tf.org/mailman/listinfo/calsify
_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--000000000000c97778058e6f1ea0-- From nobody Wed Jul 24 10:06:53 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 925131202A5 for ; Wed, 24 Jul 2019 10:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 JBNKOyzcPcOi for ; Wed, 24 Jul 2019 10:06:49 -0700 (PDT) Received: from mail-ua1-f41.google.com (mail-ua1-f41.google.com [209.85.222.41]) (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 7EF15120112 for ; Wed, 24 Jul 2019 10:06:49 -0700 (PDT) Received: by mail-ua1-f41.google.com with SMTP id z13so18729895uaa.4 for ; Wed, 24 Jul 2019 10:06:49 -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=7FLmaQSAEyFNre8JV5yEbagX0/bt8RuunAAainBcozo=; b=rVARr/K9q8HavBAEBlK7FeDxDCT9j63rrNavOjakBBgeZ46BQMV/EZ4CmM0hhz9QGR fwkorildXDbB7xYSKWeercmgEO7Cxe/PvGOWTNi1VSrTP/Rj6STkpzx8WaMoXJntGEfC 6LWO+jlGunYZTxjYpWtKsc0mzT7QWPi7gnbRfC5aoW6/MLDBVFWLCZS4r2PNDecq1Bw7 jQ4DQDo77EyUxV0OuVBj6c/dvAd4AnDEo8uVtgkIdxRS/Me95rKSXEkJxmppkOisFR6p OvXNnaRvDCHJ2Y2c4WvGZGdIY8vDcyF8ma+ONJRzLYTvBxGjMm+kIIXsWfUIiio8fCm+ oveQ== X-Gm-Message-State: APjAAAXqaKyDvrNvLUv1snM+zKctiuTPbPhizQbTAaK2pNCWtizP4362 fm5l1PygeYOELxKzvcrDSO7cOnNxs9xG3pZPY+fNFw== X-Google-Smtp-Source: APXvYqwA4xJsQpOyAicw5jutjEiz1UMV3byUURdfiaqncoW9twzzcut9giqmxiZ72zlRJ2LzsUZQew6P0Qv5tjPjLkE= X-Received: by 2002:ab0:614d:: with SMTP id w13mr33489848uan.66.1563988008600; Wed, 24 Jul 2019 10:06:48 -0700 (PDT) MIME-Version: 1.0 References: <524f0103-2265-794d-b806-9e283f23b2f4@gmail.com> In-Reply-To: From: Daniel Migault Date: Wed, 24 Jul 2019 13:06:37 -0400 Message-ID: To: Michael Douglass Cc: IETF-Calsify Content-Type: multipart/alternative; boundary="000000000000af8950058e7055c3" Archived-At: Subject: Re: [calsify] IETF105 session Minute taker/Jabber 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, 24 Jul 2019 17:06:52 -0000 --000000000000af8950058e7055c3 Content-Type: text/plain; charset="UTF-8" Hi, We are looking at one minute taker and a jabber scribe. Please let me know if you volunteer. This would be appreciated! Yours, Daniel On Wed, Jul 24, 2019 at 11:39 AM Daniel Migault wrote: > I checked with meetingecho team and it is probably because the session had > not started. That should be fixed this afternoon. > > Yours, > Daniel > > > On Tue, Jul 23, 2019 at 3:49 PM Michael Douglass > wrote: > >> I did find the meeting management tool but I get this message when I log >> in: >> >> There is no person record associated with your login.. >> >> I was logged in with the only account that works. Maybe the wrong one? >> I'll pursue this and see what happens... >> On 7/18/19 09:50, Daniel Migault wrote: >> >> Hi, >> >> Calext will meet in Montreal on Wednesday July 24 15:50 - 16:50. >> >> Following up the scheme of our interim meeting collocated with >> calconnect, it might be good we go through all current draft. >> >> If you believe a presentation is worth being made, please indicate the >> time you need and provide the slides by Monday July 22. >> If you believe that is not necessary, or you are not able to do it, >> please provide a note on the mailing list of the advancement of the draft, >> issues to be solved, date of the expected new version, as well as other >> information you believe is useful. >> >> Please find a draft agenda below. >> calext agenda >> >> * chairs slides (10 minutes) >> * draft-ietf-calext-eventpub-extensions-13 ( 10 minutes Michael) >> * draft-ietf-calext-jscalendar-17 and >> draft-ietf-calext-jscalendar-icalendar-01 (10 minutes) >> * draft-ietf-calext-subscription-upgrade-00 >> * draft-ietf-calext-valarm-extensions-00 >> * draft-ietf-calext-caldav-scheduling-controls-00 >> * tzdist & IANA (Daniel 10 minutes) >> >> Yours, >> Daniel >> >> _______________________________________________ >> calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >> > --000000000000af8950058e7055c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

We are looking at = one minute taker and a jabber scribe. Please let me know if you volunteer. = This would be appreciated!

Yours,=C2=A0
= Daniel

On Wed, Jul 24, 2019 at 11:39 AM Daniel Migault <daniel.migault@ericsson.com> wrote:
I= checked with meetingecho team and it is probably because the session had n= ot started. That should be fixed this afternoon.

Yours,= =C2=A0
Daniel
=C2=A0

On Tue, Jul 23, 2019 at 3:49 = PM Michael Douglass <mikeadouglass@gmail.com> wrote:
=20 =20 =20

I did find the meeting management tool but I get this message when I log in:

There is no person record associated with your login..

I was logged in with the only account that works. Maybe the wrong one? I'll pursue this and see what happens...

On 7/18/19 09:50, Daniel Migault wrote:
=20
Hi,=C2=A0

Calext will meet in Montreal on Wednesday July 24 15:50 - 16:50.=C2=A0

Following up the scheme of our interim meeting collocated with calconnect, it might be good we go through all current draft.=C2=A0

If you believe a presentation is worth being made, please indicate the time you need and provide the slides by Monday July 22.=C2=A0=C2=A0
If you believe that is not necessary, or you are not able to do it, please provide a note on the mailing list of the advancement of the draft, issues to be solved, date of the expected new version,=C2=A0 as well as other information you believe is useful.=C2=A0

Please find a draft agenda below.=C2=A0
calext agenda

* chairs slides (10 minutes)
* draft-ietf-calext-eventpub-extensions-13 ( 10 minutes Michael)
* draft-ietf-calext-jscalendar-17 and draft-ietf-calext-jscalendar-icalendar-01 (10 minutes)
* draft-ietf-calext-subscription-upgrade-00
* draft-ietf-calext-valarm-extensions-00
* draft-ietf-calext-caldav-scheduling-controls-00
* tzdist & IANA (Daniel 10 minutes)

Yours,=C2=A0
Daniel

_______________________________________________
calsify mailing list
calsi=
fy@ietf.org
https://www.ietf.org/mailman/listinfo/calsify
_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--000000000000af8950058e7055c3-- From nobody Wed Jul 24 12:02: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 F22A712066E for ; Wed, 24 Jul 2019 12:02:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 S9p3l0ZahLK7 for ; Wed, 24 Jul 2019 12:02:20 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 8D512120674 for ; Wed, 24 Jul 2019 12:02:20 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id a15so46556915qtn.7 for ; Wed, 24 Jul 2019 12:02:20 -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-transfer-encoding:content-language; bh=LdMZDc4zzx8g/3SPZXVr4aSwk07PnzDIxQfA+19C45s=; b=Y/8Zmf6w+lbr1IesITa/6KOF8Xb/gO5RAvHRaGXJr4BxNBmJQcZo+8tLRTbNFHKiCK WGch0mJXy7YwzMQZshNszbh6/AuIOf0CwI0xcd8nZTP3RmFVjjCXlWKChizescvioBx0 EqvIvbJWOVeUSXoRuohDCIgfTfjnDsz94i98lEGxtqveUHd1eQh7kQmsB2td2GKBEjq0 8QAExsU+qBTq+E1mjiq2pldKOWbX3OAnhEYZl94CEBqrnOTYusJFSLjMNrlR32SGKA82 Iop4RqEkHlM7tYnIym90uRHd4fkQkBdxQAMA1EnGOcap5JYoc4lbuoQppDad5o94vSBL 9Pww== 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-transfer-encoding :content-language; bh=LdMZDc4zzx8g/3SPZXVr4aSwk07PnzDIxQfA+19C45s=; b=l3r12IbeiCbUkbcmvds9fMQjAoQV56Nd11PWs+r2o9eM4Wz1pDlYd9CKx4o8c0mQ6J 8ysGbGTvwiBKwKOoJLtrEsdL8vy3bgGo6bEYf3EMTGLfXToInQrPbAqECt0O/Y84tkt/ 5ZuuAJO9Pn0NBwgU//aF/hpHbGtNB/VfXouyDOzA2vBd5etSANaxWlodKtAr59Yw1M4p 9Eg5PRs6qOV6qqWdiw58aVWBfxsADErge+lF50Euc2wTX8Zvc1w2niaaB/Os7d5/dTPc NqP2sYQ35llNQCyWxcHe8aUWxnexMU9lNzI+JJdyRcWVPqnwDmGgyeyiDOnmXsUY9zBZ CoQQ== X-Gm-Message-State: APjAAAVTzx5mEcJWDgGy4vkhvfpcSRufOgeKTqdLObso3CauNrhMkP92 r1duufFdrILENPssVC4myTBjjJnWzp8= X-Google-Smtp-Source: APXvYqz5M700KOmI8J2xY/t2vMxcyNWlS1FK5rw6ayEz8rWwo0RIwJFyv36iI2SIRfeNm3XHku8e7A== X-Received: by 2002:a0c:b5dd:: with SMTP id o29mr61068249qvf.85.1563994939547; Wed, 24 Jul 2019 12:02:19 -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 f20sm19927194qkl.48.2019.07.24.12.02.18 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jul 2019 12:02:18 -0700 (PDT) To: calsify@ietf.org References: From: Michael Douglass Message-ID: Date: Wed, 24 Jul 2019 15:02:18 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [calsify] Removing the Protection from CALDAV:supported-calendar-component-set Property 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, 24 Jul 2019 19:02:29 -0000 On 7/23/19 15:52, Дилян Палаузов wrote: > Hello, > > RFC 4791 “Calendaring Extensions to WebDAV (CalDAV)”, Section 5.2.3. “CALDAV:supported-calendar-component-set Property” > defines supported-calendar-component-set as protected property: it cannot be changed by clients using a PROPPATCH > request. > > What is the rationale for this? I think the rationale is that once a calendar is populated you can't be changing the allowable component types - or at least it gets very complicated. What if you try to change it from tasks + events to events + availability while it contains tasks and events? And what about clients that may have made decisions based on the allowable types? The move was away from mixed types anyway. > > For a calendar created before RFC 7953 “Calendar Availability” was invented, there is no way for the CUA to add support > for the VAVAILABILITY component afterwards. > > I propose erratum to https://tools.ietf.org/html/rfc4791#section-5.2.3 CALDAV:supported-calendar-component-set Property > > Type Technical > > Current text: > > Conformance: This property MAY be defined on any calendar > collection. If defined, it MUST be protected and SHOULD NOT be > returned by a PROPFIND DAV:allprop request (as defined in Section > 12.14.1 of [RFC2518]). > > Description: … Any attempt by the client to store calendar object resources with > component types not listed in this property, if it exists, MUST > result in an error, with the CALDAV:supported-calendar-component > precondition (Section 5.3.2.1) being violated. Since this > property is protected, it cannot be changed by clients using a > PROPPATCH request. However, clients can initialize the value of > this property when creating a new calendar collection with > MKCALENDAR. … > > New text: > > Conformance: This property MAY be defined on any calendar > collection. If defined, it MAY be protected and SHOULD NOT be > returned by a PROPFIND DAV:allprop request (as defined in Section > 12.14.1 of [RFC2518]). > > Description: … Any attempt by the client to store calendar object resources with > component types not listed in this property, if it exists, MUST > result in an error, with the CALDAV:supported-calendar-component > precondition (Section 5.3.2.1) being violated. Clients can initialize > the value of this property when creating a new calendar collection with > MKCALENDAR. … > > > Rationale: The protected status of supported-calendar-component-set is removed, so that CUAs can add component types to > existing callendars, which component types were not defined, when the calendar was created > > Plese provide feedback within a month, afterwards I will submit it over https://www.rfc-editor.org/errata_report.php . > > What will happen then? What are the chances, that nothing happens, and therefore the time for submitting this is > practically lost. > > Regards > Дилян > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Wed Jul 24 23:55:45 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 1B4CB12036D for ; Wed, 24 Jul 2019 23:55: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, 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 K9R6XxaXxS8Y for ; Wed, 24 Jul 2019 23:55:41 -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 BB198120355 for ; Wed, 24 Jul 2019 23:55:40 -0700 (PDT) Authentication-Results: mail.aegee.org/x6P6tZHV001200; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564037737; i=dkim+MSA-tls@aegee.org; r=y; bh=IkQww9Wn/zU4dM2bfzcuZLgOJOPFgiiqUgMzESKQkFg=; h=Subject:From:To:Date:In-Reply-To:References; b=E2lhqzvfURekUN+MtHL22Hw/09TGKWR3uTf6WFlFOpdSzgMCKurFSZWjMcKpiAMuI vivWzbYcIfbq6mgish/ETO/Q/6wax+7ugUnWIRUiLrUE8jjqUSbmXqsqsxJXc8C/NJ Z/ySZc1KKiqHvZKIryy9dl3xsc1W8bs87yuqXWnG7BqQVecEtSDFdtBCOyOzDeE+Iy m6rEnzprisJ7zBHLPuP41b2Vy2aXQKUHIM5lxWs3hu1wxSkk8zxAsxoZ/9WM2y26uP Y36UjtMtecWIC3N6Hnm67dDokJh/bSvfOVYnxzIZSAe5yq6j0RlX6akN0zk60Wv+aV LMctRFnG/lJspwi2O7WZ7a1fJ3CoA0LGu/zVgk4/UvVm+KJYJOslaB6pi+7BDmlwFA bESwUesS4WeEFXmK+qLAvMBu2aCLA0LObjO2dn6y8bAb+78jSm07GitWufGh0XwoTa bbOXoAwdTqKeCOA4LA+VJB1qc666rZ14+hXnxd4hdTdA836E1/E779uaonHCuB8iyo XzFl+K0yNElI5o7zdikiDMCkCy0PXEHlmy0vfXk0ggu70i0ZiP/W9IPTyvlMO337fP sViBvsyZSBZBvcSyFYW8oDBtYYGgaDq47nW1FmC3f0kvrS5e3oKes8+j17qj4dyEJQ Drvx0D8zEglo0CqQCZyXI6Dk= Authentication-Results: mail.aegee.org/x6P6tZHV001200; 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 x6P6tZHV001200 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 25 Jul 2019 06:55:36 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: Michael Douglass , calsify@ietf.org Date: Thu, 25 Jul 2019 06:55:35 +0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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: Re: [calsify] Removing the Protection from CALDAV:supported-calendar-component-set Property 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, 25 Jul 2019 06:55:44 -0000 Hello Michael, when changing from events+todos to events+availability on a collection containging tasks, the server returns error and changes nothing. Clients that made decisions based on allowable types... caldav collection properties like displayname, transparency, description, color can change and clients are supposed to be able to refresh the values from the server. Likewise, when the values in supported-calendar-component-set change, clients adapt. Regards Дилян On Wed, 2019-07-24 at 15:02 -0400, Michael Douglass wrote: > On 7/23/19 15:52, Дилян Палаузов wrote: > > Hello, > > > > RFC 4791 “Calendaring Extensions to WebDAV (CalDAV)”, Section 5.2.3. “CALDAV:supported-calendar-component-set Property” > > defines supported-calendar-component-set as protected property: it cannot be changed by clients using a PROPPATCH > > request. > > > > What is the rationale for this? > > I think the rationale is that once a calendar is populated you can't be > changing the allowable component types - or at least it gets very > complicated. > > What if you try to change it from tasks + events to events + > availability while it contains tasks and events? > > And what about clients that may have made decisions based on the > allowable types? > > The move was away from mixed types anyway. > > > For a calendar created before RFC 7953 “Calendar Availability” was invented, there is no way for the CUA to add support > > for the VAVAILABILITY component afterwards. > > > > I propose erratum to https://tools.ietf.org/html/rfc4791#section-5.2.3 CALDAV:supported-calendar-component-set Property > > > > Type Technical > > > > Current text: > > > > Conformance: This property MAY be defined on any calendar > > collection. If defined, it MUST be protected and SHOULD NOT be > > returned by a PROPFIND DAV:allprop request (as defined in Section > > 12.14.1 of [RFC2518]). > > > > Description: … Any attempt by the client to store calendar object resources with > > component types not listed in this property, if it exists, MUST > > result in an error, with the CALDAV:supported-calendar-component > > precondition (Section 5.3.2.1) being violated. Since this > > property is protected, it cannot be changed by clients using a > > PROPPATCH request. However, clients can initialize the value of > > this property when creating a new calendar collection with > > MKCALENDAR. … > > > > New text: > > > > Conformance: This property MAY be defined on any calendar > > collection. If defined, it MAY be protected and SHOULD NOT be > > returned by a PROPFIND DAV:allprop request (as defined in Section > > 12.14.1 of [RFC2518]). > > > > Description: … Any attempt by the client to store calendar object resources with > > component types not listed in this property, if it exists, MUST > > result in an error, with the CALDAV:supported-calendar-component > > precondition (Section 5.3.2.1) being violated. Clients can initialize > > the value of this property when creating a new calendar collection with > > MKCALENDAR. … > > > > > > Rationale: The protected status of supported-calendar-component-set is removed, so that CUAs can add component types to > > existing callendars, which component types were not defined, when the calendar was created > > > > Plese provide feedback within a month, afterwards I will submit it over https://www.rfc-editor.org/errata_report.php . > > > > What will happen then? What are the chances, that nothing happens, and therefore the time for submitting this is > > practically lost. > > > > Regards > > Дилян > > > > _______________________________________________ > > 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 From nobody Thu Jul 25 06:50: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 E762312001A; Thu, 25 Jul 2019 06:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.091, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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 8Hr2x40y_Wxc; Thu, 25 Jul 2019 06:50:28 -0700 (PDT) Received: from mail-vs1-f44.google.com (mail-vs1-f44.google.com [209.85.217.44]) (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 B76A512006D; Thu, 25 Jul 2019 06:50:28 -0700 (PDT) Received: by mail-vs1-f44.google.com with SMTP id y16so33716959vsc.3; Thu, 25 Jul 2019 06:50:28 -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; bh=h56fnLAACnbAVyR54Zlfq5xbGp70+TLIjRoxGeyeWZE=; b=CK2Q9/QVhDnXKWy03F76zHRA5lMqWPG3WLhKVWLD8jgaiiZ3EKBNQt2W9g3ihzwQJ8 oD51AWvMqV2M5z2AkbYlA6VG7bdDWs8SAYK1fUvfVrPfoQVwFQBVuulUrk3u7socm5Ea AGNpwlz25VMwQMhSN9ndT7XI0Y2KJ5HMyhAMh5mbTPEYLypAKj9gobVcTqTLYy4AEJ9g s9//cJ30jxAh+QK+YrJToCBgbpauCu8pA0/anDS+fBMKnRWlz3fk04WcWfM9eRN0af51 5VD+i571Ld92xiY+LXy+96/5Zqx+jPJqxufjq1oRke9L30EUCJ+nSFrHhQYGI/lF+AXO waiw== X-Gm-Message-State: APjAAAVZF4EhCisuLHi2oxbIuM1B7sf7IYmehcOTwqenJhgGB3W64TOp xedE8Hzj34ZUluLR+RwuI6zMbNGShHSIDz77TU7E1DyH X-Google-Smtp-Source: APXvYqwK2BhPb2Ik1ceGHz7A0AKPOTSBPyfUfuB8XOnYZa2bDkBunpytA07hVKCYFqHkUxdZZHar5+38vTzFmM8lt8g= X-Received: by 2002:a05:6102:458:: with SMTP id e24mr31595444vsq.31.1564062627570; Thu, 25 Jul 2019 06:50:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Thu, 25 Jul 2019 09:50:16 -0400 Message-ID: To: tzdist-bis@ietf.org, Time zone mailing list , IETF-Calsify Content-Type: multipart/alternative; boundary="00000000000052abd1058e81b5c8" Archived-At: Subject: [calsify] TZ distribution system mailing list 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, 25 Jul 2019 13:50:30 -0000 --00000000000052abd1058e81b5c8 Content-Type: text/plain; charset="UTF-8" Hi The calext WG met yesterday. The minutes will be uploaded soon. It has been agreed that the discussion of the tzdist system should not be split over three mailing lists and will be done on the tzdist-bis[1] mailing list. Please continue the discussion on that mailing list. Yours, Daniel [1] https://www.ietf.org/mailman/listinfo/Tzdist-bis --00000000000052abd1058e81b5c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi
<= div>
The calext WG met yesterday. The minutes will be uploade= d soon. It has been agreed that the discussion of the tzdist system should = not be split over three mailing lists and will be done on the=C2=A0 =C2=A0t= zdist-bis[1] mailing list.

Please continue the dis= cussion on that mailing list.

Yours,=C2=A0
Daniel


--00000000000052abd1058e81b5c8-- From nobody Thu Jul 25 08:45: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 6D0C212027E for ; Thu, 25 Jul 2019 08:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=twitch.tv 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 LBBwgrgs4DxJ for ; Thu, 25 Jul 2019 08:45:30 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 AED1412026D for ; Thu, 25 Jul 2019 08:45:29 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id a15so45439659wmj.5 for ; Thu, 25 Jul 2019 08:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitch.tv; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o1PBuhQ/prcHVtLr8NV2RNGT8G05HQrLW/fdpk71CNw=; b=KRuvSXvXSFPkXD9ypMiWcpVwOXNBhapenNJ6vQBderVwlpAOpwHg6ffVe2NzSeX83p PoVjnHvXAisHD9XAEIn9wFq0DMn3Rb78d0vKDcvY/pQ6JX7sBo25lNV7Zxg1V768J02f CLf4FVr0idtlaFCp9/PLJ/LkGjJF1h2WMbsnk= 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=o1PBuhQ/prcHVtLr8NV2RNGT8G05HQrLW/fdpk71CNw=; b=ZRnvRoIpWeqGOCvCMyN1EdrYslJi7CSsXmOniQ0oXS7WJ66g80vFaRIzbKJBQYFpqi frh0aiqaCyIkXpwHEo0y5NBLfeLKgOOzBSxppujytWY3zGkyooH9Tt9U0tYcB4vXtXn0 WDABzQdaDI76Mx7sUUkkTt5ixvV6lTdLfH0EtFTNM1pbCxZm72j2hCmha101soF9zadA qwTwi5Xcl4cLdVHsJynlP1y3VJCi4oy72zTgjj5AyGYNWH5rTRF1IVpNA6UoV6xECQDT z+ti6TahVOkJrnrfKwlRxKTlKrPmv82viC1sPLoB9CorI8vjALH5Fl2iBvN11VrEX7si gTiQ== X-Gm-Message-State: APjAAAWXZ5ZxrXB9Abwa7106EU7OcDi5QwQrJ6Ie35UD5m0gEXtJhIZX dYrNJ94/D2hsOG1mjVoBd4gm+R44YoSR0QCwTNDX X-Google-Smtp-Source: APXvYqwFSnqRDfm2ExgdwThxpLmvDmPVSIfYe1QAFZtbdZK82ptPlZ6cWHw8bgUmVVGIxQjsMALcWDIKT9Mdq8SQQ+M= X-Received: by 2002:a1c:f418:: with SMTP id z24mr31436313wma.80.1564069528030; Thu, 25 Jul 2019 08:45:28 -0700 (PDT) MIME-Version: 1.0 References: <12d2d82e-121f-3583-592b-fcbd17f2b0d1@gmail.com> <17ad7de3-5957-eb65-a052-d6f9f93f2b23@gmail.com> <4a9a9e83-08b0-6d70-10d4-3c82a58ad398@gmail.com> In-Reply-To: <4a9a9e83-08b0-6d70-10d4-3c82a58ad398@gmail.com> From: Ryan Gunter Date: Thu, 25 Jul 2019 09:44:51 -0600 Message-ID: To: Doug Royer Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary="0000000000009f7f58058e835079" Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 25 Jul 2019 15:45:33 -0000 --0000000000009f7f58058e835079 Content-Type: text/plain; charset="UTF-8" Doug, I'm extremely appreciative of your response, it's very helpful. Based on my previous draft, we have a very simple set of fields but enough to provide context for an upcoming maintenance. With this being said, the addition of a new component seems like the better option. For the new draft, would we revise it to 01, or create a new draft to review? Ryan Gunter | *Twitch* | Network Engineering | +1.415.568.7607 On Tue, Jul 23, 2019 at 1:54 PM Doug Royer wrote: > On 7/23/19 9:02 AM, Ryan Gunter wrote: > > > > > Is this suggesting to use the ATTACH property with a defined data set > from schema.org , or otherwise? If that's the case, > we could work with schema.org to define these data > sets? The original hope of the draft was to agree upon a way to provide > network maintenance information within the file. If we went with the > ATTACH or STRUCTURED-DATA route, would there be a way to define this data > set or method within the IETF? I just want to make sure I understand the > boundaries and drive this effort correctly. > > One option is to create a new iCalendar component 'MAINTNOTE' and include > it inline, as in: > > ... > BEGIN:MAINTNOTE > MAINTNOTE-PROVIDER:example.com > MAINTNOTE-ACCOUNT: Twitch > MAINTNOTE-MAINTENANCE-ID: WorkOrder-31415 > MAINTNOTE-OBJECT-ID: ABC123 > MAINTNOTE-IMPACT: OUTAGE > MAINTNOTE-STATUS: CONFIRMED > END:MAINTNOTE > ... > > Which would be the 'iCalendar' way of doing it. > > Another option is if the data structure does not easily translate to > iCalendar format, you could attach it with something like this for an > included attachment (where text/maintnode would be replaced with whatever > mime-type is assigned to identify your data): > > ... > ATTACH;fmttype=text/maintnode;...:CID=maintnote-attach-id > ... > > Or for an external object: > > ... > ATTACH;fmttype=text/maintnode;...: > https://example.com/maintnote-attach > ... > > The advantage to ATTACH is that email and calendar tools like outlook, > Thunderbird, and others will see the data as an attachment and allow the > user to drag/drop it, without new code needing to be written just to pull > it out, or to copy/paste it. Outlook, Thunderbird, and many other calendar > clients already know how to handle ATTACH, even when they do not know what > the mime-type does. Minimal changes to make a maintnode aware calendar > client. Zero changes needed when the iCalendar application can already > handle ATTACH, and copy/paste is what you need. > > And for custom iCalendar maintnode programs, MIME libraries already know > how to handle mime multipart objects (CID or external). How an attachment > is include in a mime object is already a standard. Custom maintnote > processing code would just open the text/calendar MIME object and pull out > the ATTACH;text/maintnote properties. Then call already implemented MIME > libraries to extract the included maintnode attachments (a CID) and/or for > fetching the URL provided for external maintnode attachments. Then your > custom code does whatever it wants with the attachment and iCalendar data. > > The structured-data proposal has no advantages, and it would complicate > recognizing the data as an attachment or extra data and require outlook, > Thunderbird, and all other calendar clients be re-written to extract out > the maintnote data from the iCalendar object, or someone would have to > write a plug-in for all email clients and calendar clients to extract the > data. (vs just using an copy/paste or using existing MIME libraries). > > As to schema.org. Any MIME object defined by them, can already be the > content of an ATTACH iCalendar object. Just name the MIME-TYPE and provide > the URL as the property value. > > It is not a schema.org vs IETF decision. You can (or not) define it with > schema.org. You can ATTACH it as a defined schema.org object, or attach > it as a non-schema.org object. Both with ATTACH. (Or go the MAINTNOTE > component way). > > If it maps easily into iCalendar, use MAINTNOTE. If your data is part of a > larger data set that is complicated, define it with schema.org, and > iCalendar ATTACH it. > > Hope this helps. > > -- > > Doug Royer - (http://DougRoyer.US) > Douglas.Royer@gmail.com > 714-989-6135 > --0000000000009f7f58058e835079 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Doug,

I'm extremely appreciative of your respon= se, it's very helpful.

Based on my previous draft, we have a ver= y simple set of fields but enough to provide context for an upcoming mainte= nance.=C2=A0 With this being said, the addition of a new component seems li= ke the better option.

For the new draft, would we revise it to 01, o= r create a new draft to review?
=C2=A0

Ryan Gunter= =C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0Twitch=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0 Network Engineer= ing=C2=A0 =C2=A0| =C2=A0=C2=A0+1.415.568.7607


On Tue, Jul 23, 2019 at 1:54 PM Doug Royer &l= t;douglasroyer@= gmail.com> wrote:
On 7/23/19 9:02 AM, Ryan Gunter wrote:

>
> Is this suggesting to use the ATTACH property with a defined data set = from sch= ema.org <http://schema.org>, or otherwise?=C2=A0 If that's the ca= se, we could work with schema.org <http://schema.org> to define these data se= ts?=C2=A0 The original hope of the draft was to agree upon a way to provide= network maintenance information within the file.=C2=A0 If we went with the= ATTACH or STRUCTURED-DATA route, would there be a way to define this data = set or method within the IETF?=C2=A0 I just want to make sure I understand = the boundaries and drive this effort correctly.

One option is to create a new iCalendar component 'MAINTNOTE'=C2=A0= and include it inline, as in:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 BEGIN:MAINTNOTE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAINTNOTE-PROVIDER:example.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAINTNOTE-ACCOUNT: Twitch
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAINTNOTE-MAINTENANCE-ID: WorkOrder-31415
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAINTNOTE-OBJECT-ID: ABC123
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAINTNOTE-IMPACT: OUTAGE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAINTNOTE-STATUS: CONFIRMED
=C2=A0 =C2=A0 =C2=A0 =C2=A0 END:MAINTNOTE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

Which would be the 'iCalendar' way of doing it.

Another option is if the data structure does not easily translate to iCalen= dar format, you could attach it with something like this for an included at= tachment (where text/maintnode would be replaced with whatever mime-type is= assigned to identify your data):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ATTACH;fmttype=3Dtext/maintnode;...:CID=3Dmaint= note-attach-id
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

Or for an external object:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ATTACH;fmttype=3Dtext/maintnode;...:= https://example.com/maintnote-attach
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

The advantage to ATTACH is that email and calendar tools like outlook, Thun= derbird, and others will see the data as an attachment and allow the user t= o drag/drop it, without new code needing to be written just to pull it out,= or to copy/paste it.=C2=A0 Outlook, Thunderbird, and many other calendar c= lients already know how to handle ATTACH, even when they do not know what t= he mime-type does.=C2=A0 Minimal changes to make a maintnode aware calendar= client. Zero changes needed when the iCalendar application can already han= dle ATTACH, and copy/paste is what you need.

And for custom iCalendar maintnode programs, MIME libraries already know ho= w to handle mime multipart objects (CID or external). How an attachment is = include in a mime object is already a standard. Custom maintnote processing= code would just open the text/calendar MIME object and pull out the ATTACH= ;text/maintnote properties. Then call already implemented MIME libraries to= extract the included maintnode attachments (a CID) and/or for fetching the= URL provided for external maintnode attachments. Then your custom code doe= s whatever it wants with the attachment and iCalendar data.

The structured-data proposal has no advantages, and it would complicate rec= ognizing the data as an attachment or extra data and require outlook, Thund= erbird, and all other calendar clients be re-written to extract out the mai= ntnote data from the iCalendar object, or someone would have to write a plu= g-in for all email clients and calendar clients to extract the data. (vs ju= st using an copy/paste or using existing MIME libraries).

As to sc= hema.org. Any MIME object defined by them, can already be the content o= f an ATTACH iCalendar object. Just name the MIME-TYPE and provide the URL a= s the property value.

It is not a schema.org vs IETF decision. You can (or not) define it with schema.org= . You can ATTACH it as a defined schema.org object, or attach it as a non-schema.= org object. Both with ATTACH. (Or go the MAINTNOTE component way).

If it maps easily into iCalendar, use MAINTNOTE. If your data is part of a = larger data set that is complicated, define it with schema.org, and iCalendar A= TTACH it.

Hope this helps.

--

Doug Royer - (http://DougRoyer.US)
Douglas.Royer@= gmail.com
714-989-6135
--0000000000009f7f58058e835079-- From nobody Thu Jul 25 09:32:11 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 F17F11200C5 for ; Thu, 25 Jul 2019 09:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 FlQHMS9uDf08 for ; Thu, 25 Jul 2019 09:32:07 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 A90E512004C for ; Thu, 25 Jul 2019 09:32:07 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id z3so98616707iog.0 for ; Thu, 25 Jul 2019 09:32:07 -0700 (PDT) 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:content-transfer-encoding; bh=0PtsbXgakVluuyO9UPuM5xvOQ9+2DhMURAASIxVe8bk=; b=k0EsmhqpPKJtEuKkUtl2yKzxTHQJZlqC4tqu48SmtAurEUDogn8XoQoF3mdYLgaJxI LOi5+yXw0U9BqITmfZR1I+ExhBNVkVOIib9zDjt2XWxgE2gKDoo13wLroLkQNU8BUQPv PV3z2HXnXIEEOjbTZVHjqTWKZ7jVceGTvQSj9/Ito3BaYkvO2KV6ptI2B+Un+iAGb0+z 03GhXqXWiosLdPej8OGHByv+kdbEL2u6wfc8wLe+ALhu8Q+sZtbvaixOGM5IuCVdiKxm N2MWDqJTvloW5XXmxCgBPvKx1dFQbj6eOq+44/XAWlHAv4ABEolBIilW6hVUSo4gnwFg wZJQ== 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:content-transfer-encoding; bh=0PtsbXgakVluuyO9UPuM5xvOQ9+2DhMURAASIxVe8bk=; b=YjOKx8BnCQFPSHiVaPr0nrbHShx6v1p9qCPTGNEQoZ5yLX8f1xhKKSQXE3LHOKWaAW 2+aqhVxbhEDn6E+Fqu+2xcJTxnvt8Otr56rQyTHRn7SuonL+W8ujqjqH5S+QaZNCPRfX VP6CNTSyHa6fIMMrjNNJvngrl0wxUKg+2l1/c5YWtE5V+RV27oxnqa5mEMlu5BNO3T3z 3IXIBk2GCSpHOGpgO4FpfqWB8Fhz6dD4/q5KJZcX6LyXSSpC8dxjIjO5gWHDs2WvAMX2 6TKhqX7qyrPpP32lLoskQCeinIlihk0YrQAJiRCseMrAS05hKWtn6mjt3t6LtbRiBREv +lwA== X-Gm-Message-State: APjAAAWqoVY/KYDBVYYlyjwOldIHt8DL29v2gbuZD7ZmP3t0gFgJU+6K kGp+dPFK2HYPfD7YhTa30fzP16+o9TQZ X-Google-Smtp-Source: APXvYqzgOaLbKQqipM4id0rCW23tv2kZT9Fl/kWCTNdrD8JjdNaiDlme8psoLmKc/XOeboMHInZt+A== X-Received: by 2002:a5e:c241:: with SMTP id w1mr77880968iop.58.1564072326649; Thu, 25 Jul 2019 09:32:06 -0700 (PDT) Received: from [192.168.1.7] ([174.27.92.215]) by smtp.googlemail.com with ESMTPSA id x22sm37369376iob.84.2019.07.25.09.32.04 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jul 2019 09:32:06 -0700 (PDT) From: Doug Royer X-Google-Original-From: Doug Royer To: calsify@ietf.org References: <12d2d82e-121f-3583-592b-fcbd17f2b0d1@gmail.com> <17ad7de3-5957-eb65-a052-d6f9f93f2b23@gmail.com> <4a9a9e83-08b0-6d70-10d4-3c82a58ad398@gmail.com> Organization: http://SoftwareAndServices.NET Message-ID: Date: Thu, 25 Jul 2019 10:32:01 -0600 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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 25 Jul 2019 16:32:09 -0000 On 7/25/19 9:44 AM, Ryan Gunter wrote: > Doug, > > I'm extremely appreciative of your response, it's very helpful. > > Based on my previous draft, we have a very simple set of fields but enough to provide context for an upcoming maintenance.  With this being said, the addition of a new component seems like the better option. > > For the new draft, would we revise it to 01, or create a new draft to review? > The next would be -01 -- Doug Royer - (http://DougRoyer.US) Douglas.Royer@gmail.com 714-989-6135 From nobody Thu Jul 25 12:21:50 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 D5C8A1201C9 for ; Thu, 25 Jul 2019 12:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=twitch.tv 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 F2wyKwXxltZz for ; Thu, 25 Jul 2019 12:21:46 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 03AA61201C5 for ; Thu, 25 Jul 2019 12:21:46 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id s3so45942985wms.2 for ; Thu, 25 Jul 2019 12:21:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitch.tv; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=L4dHNTtIr/4cfb1uP9uhGqX1G5k/TKa8egBPGTMVUzs=; b=aCqCNINz/l22F/lLyXvWpAXmDI0RFk4lOeDFvNQ+ILFjYH+bhnlt/tTGwWU6TRSZpL xne1LdBuFjuSovnTlnNVpON92sCY864Rac4JTUR6YagkcoA6apJGCsf9E+kAS7jgk04t GbDpwx8ekapgckUd0sbYOZidM3+3t7TcuV+pw= 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=L4dHNTtIr/4cfb1uP9uhGqX1G5k/TKa8egBPGTMVUzs=; b=WRQG6oYrNCHnJC1TEM4mGHJStsq00InAEBjcSOxZUvOd1Vnz1N1jHj1Y1q5I18nQum w3N9OlOZjv1LaVY2OIdpl87SqhhB35T/UWmBFsFGJaqFtxSnXL9+AU0pDd0gDBZJbMSB 9UchqqIFloH6aBnAC1MG1nuKQNjtHVGZR+cZ7b77gIIyjsg6i/zipQzqyjAeAY6wBR/1 d8ELCRS8YZRs7dOANuWGe3hM0ZEcS0kVafd2YQOrhlc+mY55G8ZvVu+DA0kDpee72hUf 3nq04lLHoFRHYbUdSc5ClLIcyK5h5GBslXc9jJ7vQVGH3URv83Rs6bCRK9gymFDkZipe j0mA== X-Gm-Message-State: APjAAAUW44KwPmIapOGLZEDIcgwjG+KLfhWc1pHlOn3P5p2qUZ2DWVYa D2kAiT1Y8xpzVbQ0WLpoRSkPfZpwNs1SvxxMzQ+u X-Google-Smtp-Source: APXvYqxU2Z6A7FUEy7krZW4VeOuNnGDoUxH7bXcuL9woaO5WS1gaPdwD/jIlUqlbcy1Z0Q8H0d4FgOUWQoo/y4YKFYA= X-Received: by 2002:a05:600c:254b:: with SMTP id e11mr75542743wma.171.1564082504414; Thu, 25 Jul 2019 12:21:44 -0700 (PDT) MIME-Version: 1.0 References: <12d2d82e-121f-3583-592b-fcbd17f2b0d1@gmail.com> <17ad7de3-5957-eb65-a052-d6f9f93f2b23@gmail.com> <4a9a9e83-08b0-6d70-10d4-3c82a58ad398@gmail.com> In-Reply-To: From: Ryan Gunter Date: Thu, 25 Jul 2019 13:21:07 -0600 Message-ID: To: Doug Royer Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary="00000000000013618b058e865676" Archived-At: Subject: Re: [calsify] New Draft - Maintenance Notifications Using iCalendar 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, 25 Jul 2019 19:21:48 -0000 --00000000000013618b058e865676 Content-Type: text/plain; charset="UTF-8" Thanks. I'll work on that. Ryan Gunter | *Twitch* | Network Engineering | +1.415.568.7607 On Thu, Jul 25, 2019 at 10:32 AM Doug Royer wrote: > On 7/25/19 9:44 AM, Ryan Gunter wrote: > > Doug, > > > > I'm extremely appreciative of your response, it's very helpful. > > > > Based on my previous draft, we have a very simple set of fields but > enough to provide context for an upcoming maintenance. With this being > said, the addition of a new component seems like the better option. > > > > For the new draft, would we revise it to 01, or create a new draft to > review? > > > > The next would be -01 > > > -- > > Doug Royer - (http://DougRoyer.US) > Douglas.Royer@gmail.com > 714-989-6135 > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --00000000000013618b058e865676 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks. I'll work on that.=C2=A0
<= br>
Ryan Gunter= =C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0Twitch=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0 Network Engineer= ing=C2=A0 =C2=A0| =C2=A0=C2=A0+1.415.568.7607


On Thu, Jul 25, 2019 at 10:32 AM Doug Royer &= lt;douglasroyer@gmail.com>= wrote:
On 7/25/= 19 9:44 AM, Ryan Gunter wrote:
> Doug,
>
> I'm extremely appreciative of your response, it's very helpful= .
>
> Based on my previous draft, we have a very simple set of fields but en= ough to provide context for an upcoming maintenance.=C2=A0 With this being = said, the addition of a new component seems like the better option.
>
> For the new draft, would we revise it to 01, or create a new draft to = review?
>

The next would be -01


--

Doug Royer - (http://DougRoyer.US)
Douglas.Royer@= gmail.com
714-989-6135

_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--00000000000013618b058e865676-- From nobody Sun Jul 28 04:45: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 A10DB12013E for ; Sun, 28 Jul 2019 04:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 7cRMNxijUxH0 for ; Sun, 28 Jul 2019 04:45:26 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8874C120077 for ; Sun, 28 Jul 2019 04:45:26 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A93CFB80D0D; Sun, 28 Jul 2019 04:45:11 -0700 (PDT) To: bernard.desruisseaux@oracle.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, lear@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: eugene.adell@gmail.com, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190728114511.A93CFB80D0D@rfc-editor.org> Date: Sun, 28 Jul 2019 04:45:11 -0700 (PDT) Archived-At: Subject: [calsify] [Editorial Errata Reported] RFC5545 (5794) 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, 28 Jul 2019 11:45:32 -0000 The following errata report has been submitted for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5794 -------------------------------------- Type: Editorial Reported by: Eugene Adell Section: ToC Original Text ------------- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 7 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 11 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 11 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 12 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 12 3.2.1. Alternate Text Representation . . . . . . . . . . . . 13 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 15 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 16 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 17 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 17 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 18 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20 3.2.11. Group or List Membership . . . . . . . . . . . . . . 20 3.2.12. Participation Status . . . . . . . . . . . . . . . . 21 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 22 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 23 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 24 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 25 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 26 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 26 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 28 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 29 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 29 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 30 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 31 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 34 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 36 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 37 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 46 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 49 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 50 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 50 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 56 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 58 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 60 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 63 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 72 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 77 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 77 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 78 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 79 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 80 3.8. Component Properties . . . . . . . . . . . . . . . . . . 81 3.8.1. Descriptive Component Properties . . . . . . . . . . 81 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 81 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 82 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 83 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 84 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 85 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 87 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 88 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 89 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 90 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 92 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 93 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 94 3.8.2. Date and Time Component Properties . . . . . . . . . 95 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 95 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 96 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 97 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 99 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 100 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 101 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 102 3.8.3. Time Zone Component Properties . . . . . . . . . . . 103 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 103 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 105 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 106 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 106 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 107 3.8.4. Relationship Component Properties . . . . . . . . . . 108 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 108 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 111 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 113 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 114 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 117 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 118 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 119 3.8.5. Recurrence Component Properties . . . . . . . . . . . 120 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 120 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 122 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 124 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 134 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 134 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 135 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 135 3.8.7. Change Management Component Properties . . . . . . . 138 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 138 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 139 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 140 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 141 3.8.8. Miscellaneous Component Properties . . . . . . . . . 142 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 142 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 142 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 144 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 146 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 150 6. Internationalization Considerations . . . . . . . . . . . . . 151 7. Security Considerations . . . . . . . . . . . . . . . . . . . 151 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 151 8.2. New iCalendar Elements Registration . . . . . . . . . . . 155 8.2.1. iCalendar Elements Registration Procedure . . . . . . 155 8.2.2. Registration Template for Components . . . . . . . . 155 8.2.3. Registration Template for Properties . . . . . . . . 156 8.2.4. Registration Template for Parameters . . . . . . . . 156 8.2.5. Registration Template for Value Data Types . . . . . 157 8.2.6. Registration Template for Values . . . . . . . . . . 157 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 158 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 158 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 158 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 161 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 162 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 162 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 163 8.3.7. Participation Statuses Registry . . . . . . . . . . . 163 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 164 8.3.9. Participation Roles Registry . . . . . . . . . . . . 164 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 165 8.3.11. Classifications Registry . . . . . . . . . . . . . . 165 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 165 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 165 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 10.1. Normative References . . . . . . . . . . . . . . . . . . 166 10.2. Informative References . . . . . . . . . . . . . . . . . 167 Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 169 A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 169 A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 169 A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 169 Corrected Text -------------- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 8 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 12 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 12 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 13 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 13 3.2.1. Alternate Text Representation . . . . . . . . . . . . 14 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 16 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 17 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 17 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 18 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 18 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 19 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 20 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 21 3.2.11. Group or List Membership . . . . . . . . . . . . . . 21 3.2.12. Participation Status . . . . . . . . . . . . . . . . 22 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 23 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 24 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 25 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 26 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 27 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 27 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 29 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 30 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 30 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 31 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 31 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 32 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 32 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 35 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 37 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 37 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 38 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 47 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 50 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 51 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 51 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 55 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 57 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 59 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 62 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 71 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 76 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 76 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 77 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 78 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 79 3.8. Component Properties . . . . . . . . . . . . . . . . . . 80 3.8.1. Descriptive Component Properties . . . . . . . . . . 80 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 80 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 81 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 82 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 83 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 84 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 85 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 87 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 88 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 89 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 91 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 92 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 93 3.8.2. Date and Time Component Properties . . . . . . . . . 94 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 94 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 95 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 96 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 97 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 99 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 100 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 101 3.8.3. Time Zone Component Properties . . . . . . . . . . . 102 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 102 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 103 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 104 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 105 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 106 3.8.4. Relationship Component Properties . . . . . . . . . . 106 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 107 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 109 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 111 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 112 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 115 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 116 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 117 3.8.5. Recurrence Component Properties . . . . . . . . . . . 118 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 118 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 120 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 122 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 132 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 132 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 133 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 133 3.8.7. Change Management Component Properties . . . . . . . 136 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 136 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 137 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 138 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 138 3.8.8. Miscellaneous Component Properties . . . . . . . . . 139 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 140 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 140 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 141 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 144 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 147 6. Internationalization Considerations . . . . . . . . . . . . . 148 7. Security Considerations . . . . . . . . . . . . . . . . . . . 148 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 149 8.2. New iCalendar Elements Registration . . . . . . . . . . . 152 8.2.1. iCalendar Elements Registration Procedure . . . . . . 152 8.2.2. Registration Template for Components . . . . . . . . 152 8.2.3. Registration Template for Properties . . . . . . . . 153 8.2.4. Registration Template for Parameters . . . . . . . . 153 8.2.5. Registration Template for Value Data Types . . . . . 154 8.2.6. Registration Template for Values . . . . . . . . . . 154 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 155 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 155 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 156 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 158 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 159 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 160 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 160 8.3.7. Participation Statuses Registry . . . . . . . . . . . 161 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 161 8.3.9. Participation Roles Registry . . . . . . . . . . . . 162 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 162 8.3.11. Classifications Registry . . . . . . . . . . . . . . 162 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 163 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 163 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 164 10.1. Normative References . . . . . . . . . . . . . . . . . . 164 10.2. Informative References . . . . . . . . . . . . . . . . . 165 Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 167 A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 167 A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 167 A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 167 Notes ----- Most of the Table Of Contents give wrong page numbers Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5545 (draft-ietf-calsify-rfc2445bis-10) -------------------------------------- Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) Publication Date : September 2009 Author(s) : B. Desruisseaux, Ed. Category : PROPOSED STANDARD Source : Calendaring and Scheduling Standards Simplification Area : Applications Stream : IETF Verifying Party : IESG From nobody Sun Jul 28 05:30: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 099281200FB for ; Sun, 28 Jul 2019 05:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 U1yTnzSB7ztI for ; Sun, 28 Jul 2019 05:30:23 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B28C12013B for ; Sun, 28 Jul 2019 05:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25570; q=dns/txt; s=iport; t=1564317023; x=1565526623; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=rH2o9cj2OJXekOUyCRdIMZWGDOMixD7oBFR7zF7pZcs=; b=VYK52wlVF2c7OrgFNjlErxVGt1arZP/tz7KzId8a+gZrltszIan3ByNf Ak+4mZwwIJitXfIYSRui4UpNM5Su4LHXRxATFPPp1iGfsyH9XRXkSQmuQ 0KKqNDEl3Ou9Hi1PqduB4GshHWG7FbjybI0+TzKXf8L5abeq+AuMWscsi g=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DrAQA5lD1d/4MNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4FtKkcmUQEyKoQekRaBaiWJVI9BgWcCBwEBAQkDAQEjDAE?= =?us-ascii?q?BhEACgmIjOBMBAwEBBAEBAgEGbYUeDIVKAQEBAQIBGglPBwULCxgqAgIhNgY?= =?us-ascii?q?TgldLAYFqAw4PD6l5gTKFSIJBDYIXCgaBNIFRig8XgX+BEScME4JMPoEEgRa?= =?us-ascii?q?CEoMjMoImBIwlJodRXIEulBFACYIcgh+BDYxxg3cbgi6HJY47jmyIDosMgws?= =?us-ascii?q?CBAYFAhWBZyGBWDMaCBsVGiEqAYJBPoIciG2FQT0DMI5pAQE?= X-IronPort-AV: E=Sophos;i="5.64,318,1559520000"; d="asc'?scan'208";a="386022666" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jul 2019 12:30:21 +0000 Received: from bxb-vpn3-286.cisco.com (bxb-vpn3-286.cisco.com [10.86.249.30]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x6SCUGPN014988 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 28 Jul 2019 12:30:19 GMT From: Eliot Lear Message-Id: <1EBEA8BC-3A1D-4798-8CAD-0A76DCF850B3@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_BAFB3C49-9CBF-4F09-941E-EF54F357AF13"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Sun, 28 Jul 2019 14:30:14 +0200 In-Reply-To: <20190728114511.A93CFB80D0D@rfc-editor.org> Cc: bernard.desruisseaux@oracle.com, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, eugene.adell@gmail.com, calsify@ietf.org To: RFC Errata System References: <20190728114511.A93CFB80D0D@rfc-editor.org> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.86.249.30, bxb-vpn3-286.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (5794) 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, 28 Jul 2019 12:30:27 -0000 --Apple-Mail=_BAFB3C49-9CBF-4F09-941E-EF54F357AF13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The erratum is correct. Good catch. Under the IESG criteria, as this = is editorial and will not cause any interoperability or other = implementation concerns, it is normally marked =E2=80=9Chold for = update=E2=80=9D. However, because of the particular nature of this = erratum, anyone who clicks on the web searchable index gets sent to the = wrong place. That=E2=80=99s annoying. Suggestions? Eliot > On 28 Jul 2019, at 13:45, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC5545, > "Internet Calendaring and Scheduling Core Object Specification = (iCalendar)". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid5794 >=20 > -------------------------------------- > Type: Editorial > Reported by: Eugene Adell >=20 > Section: ToC >=20 > Original Text > ------------- > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 5 > 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . = 6 > 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . = 6 > 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . = 7 > 3. iCalendar Object Specification . . . . . . . . . . . . . . . = 8 > 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . = 8 > 3.1.1. List and Field Separators . . . . . . . . . . . . . . = 11 > 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . = 11 > 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . = 11 > 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . = 12 > 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . = 12 > 3.2.1. Alternate Text Representation . . . . . . . . . . . . = 13 > 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . = 15 > 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . = 15 > 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . = 16 > 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . = 16 > 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . = 17 > 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . = 17 > 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . = 18 > 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . = 19 > 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . = 20 > 3.2.11. Group or List Membership . . . . . . . . . . . . . . = 20 > 3.2.12. Participation Status . . . . . . . . . . . . . . . . = 21 > 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . = 22 > 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . = 23 > 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . = 24 > 3.2.16. Participation Role . . . . . . . . . . . . . . . . . = 25 > 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . = 25 > 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . = 26 > 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . = 26 > 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . = 28 > 3.3. Property Value Data Types . . . . . . . . . . . . . . . . = 29 > 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . = 29 > 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . = 30 > 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . = 30 > 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . = 31 > 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . = 31 > 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . = 34 > 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . = 35 > 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . = 35 > 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . = 36 > 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . = 37 > 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . = 45 > 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . = 46 > 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . = 48 > 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . = 49 > 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . = 49 > 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . = 50 > 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . = 50 > 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . = 52 > 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . = 56 > 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . = 58 > 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . = 60 > 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . = 63 > 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . = 72 > 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . = 77 > 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . = 77 > 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . = 78 > 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . = 79 > 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . = 80 > 3.8. Component Properties . . . . . . . . . . . . . . . . . . = 81 > 3.8.1. Descriptive Component Properties . . . . . . . . . . = 81 > 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . = 81 > 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . = 82 > 3.8.1.3. Classification . . . . . . . . . . . . . . . . . = 83 > 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . = 84 > 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . = 85 > 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . = 87 > 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . = 88 > 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . = 89 > 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . = 90 > 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . = 92 > 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . = 93 > 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . = 94 > 3.8.2. Date and Time Component Properties . . . . . . . . . = 95 > 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . = 95 > 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . = 96 > 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . = 97 > 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . = 99 > 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . = 100 > 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . = 101 > 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . = 102 > 3.8.3. Time Zone Component Properties . . . . . . . . . . . = 103 > 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . = 103 > 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . = 105 > 3.8.3.3. Time Zone Offset =46rom . . . . . . . . . . . . . . = 106 > 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . = 106 > 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . = 107 > 3.8.4. Relationship Component Properties . . . . . . . . . . = 108 > 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . = 108 > 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . = 111 >=20 > 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . = 113 > 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . = 114 > 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . = 117 > 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . = 118 > 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . = 119 > 3.8.5. Recurrence Component Properties . . . . . . . . . . . = 120 > 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . = 120 > 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . = 122 > 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . = 124 > 3.8.6. Alarm Component Properties . . . . . . . . . . . . . = 134 > 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . = 134 > 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . = 135 > 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . = 135 > 3.8.7. Change Management Component Properties . . . . . . . = 138 > 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . = 138 > 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . = 139 > 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . = 140 > 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . = 141 > 3.8.8. Miscellaneous Component Properties . . . . . . . . . = 142 > 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . = 142 > 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . = 142 > 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . = 144 > 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . = 146 > 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . = 150 > 6. Internationalization Considerations . . . . . . . . . . . . . = 151 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . = 151 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 151 > 8.1. iCalendar Media Type Registration . . . . . . . . . . . . = 151 > 8.2. New iCalendar Elements Registration . . . . . . . . . . . = 155 > 8.2.1. iCalendar Elements Registration Procedure . . . . . . = 155 > 8.2.2. Registration Template for Components . . . . . . . . = 155 > 8.2.3. Registration Template for Properties . . . . . . . . = 156 > 8.2.4. Registration Template for Parameters . . . . . . . . = 156 > 8.2.5. Registration Template for Value Data Types . . . . . = 157 > 8.2.6. Registration Template for Values . . . . . . . . . . = 157 > 8.3. Initial iCalendar Elements Registries . . . . . . . . . . = 158 > 8.3.1. Components Registry . . . . . . . . . . . . . . . . . = 158 > 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . = 158 > 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . = 161 > 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . = 162 > 8.3.5. Calendar User Types Registry . . . . . . . . . . . . = 162 > 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . = 163 > 8.3.7. Participation Statuses Registry . . . . . . . . . . . = 163 > 8.3.8. Relationship Types Registry . . . . . . . . . . . . . = 164 > 8.3.9. Participation Roles Registry . . . . . . . . . . . . = 164 > 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . = 165 > 8.3.11. Classifications Registry . . . . . . . . . . . . . . = 165 > 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . = 165 > 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . = 165 > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = 166 > 10.1. Normative References . . . . . . . . . . . . . . . . . . = 166 > 10.2. Informative References . . . . . . . . . . . . . . . . . = 167 > Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . = 169 > A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . = 169 > A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . = 169 > A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . = 169 >=20 >=20 > Corrected Text > -------------- > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = 5 > 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . = 6 > 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . = 6 > 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . = 8 > 3. iCalendar Object Specification . . . . . . . . . . . . . . . = 8 > 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . = 9 > 3.1.1. List and Field Separators . . . . . . . . . . . . . . = 11 > 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . = 12 > 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . = 12 > 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . = 13 > 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . = 13 > 3.2.1. Alternate Text Representation . . . . . . . . . . . . = 14 > 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . = 15 > 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . = 16 > 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . = 17 > 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . = 17 > 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . = 18 > 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . = 18 > 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . = 19 > 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . = 20 > 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . = 21 > 3.2.11. Group or List Membership . . . . . . . . . . . . . . = 21 > 3.2.12. Participation Status . . . . . . . . . . . . . . . . = 22 > 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . = 23 > 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . = 24 > 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . = 25 > 3.2.16. Participation Role . . . . . . . . . . . . . . . . . = 25 > 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . = 26 > 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . = 27 > 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . = 27 > 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . = 29 > 3.3. Property Value Data Types . . . . . . . . . . . . . . . . = 30 > 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . = 30 > 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . = 31 > 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . = 31 > 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . = 32 > 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . = 32 > 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . = 35 > 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . = 36 > 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . = 37 > 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . = 37 > 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . = 38 > 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . = 45 > 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . = 47 > 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . = 49 > 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . = 49 > 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . = 50 > 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . = 51 > 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . = 51 > 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . = 52 > 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . = 55 > 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . = 57 > 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . = 59 > 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . = 62 > 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . = 71 > 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . = 76 > 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . = 76 > 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . = 77 > 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . = 78 > 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . = 79 > 3.8. Component Properties . . . . . . . . . . . . . . . . . . = 80 > 3.8.1. Descriptive Component Properties . . . . . . . . . . = 80 > 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . = 80 > 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . = 81 > 3.8.1.3. Classification . . . . . . . . . . . . . . . . . = 82 > 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . = 83 > 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . = 84 > 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . = 85 > 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . = 87 > 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . = 88 > 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . = 89 > 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . = 91 > 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . = 92 > 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . = 93 > 3.8.2. Date and Time Component Properties . . . . . . . . . = 94 > 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . = 94 > 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . = 95 > 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . = 96 > 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . = 97 > 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . = 99 > 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . = 100 > 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . = 101 > 3.8.3. Time Zone Component Properties . . . . . . . . . . . = 102 > 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . = 102 > 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . = 103 > 3.8.3.3. Time Zone Offset =46rom . . . . . . . . . . . . . . = 104 > 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . = 105 > 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . = 106 > 3.8.4. Relationship Component Properties . . . . . . . . . . = 106 > 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . = 107 > 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . = 109 > 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . = 111 > 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . = 112 > 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . = 115 > 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . = 116 > 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . = 117 > 3.8.5. Recurrence Component Properties . . . . . . . . . . . = 118 > 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . = 118 > 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . = 120 > 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . = 122 > 3.8.6. Alarm Component Properties . . . . . . . . . . . . . = 132 > 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . = 132 > 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . = 133 > 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . = 133 > 3.8.7. Change Management Component Properties . . . . . . . = 136 > 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . = 136 > 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . = 137 > 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . = 138 > 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . = 138 > 3.8.8. Miscellaneous Component Properties . . . . . . . . . = 139 > 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . = 140 > 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . = 140 > 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . = 141 > 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . = 144 > 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . = 147 > 6. Internationalization Considerations . . . . . . . . . . . . . = 148 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . = 148 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = 149 > 8.1. iCalendar Media Type Registration . . . . . . . . . . . . = 149 > 8.2. New iCalendar Elements Registration . . . . . . . . . . . = 152 > 8.2.1. iCalendar Elements Registration Procedure . . . . . . = 152 > 8.2.2. Registration Template for Components . . . . . . . . = 152 > 8.2.3. Registration Template for Properties . . . . . . . . = 153 > 8.2.4. Registration Template for Parameters . . . . . . . . = 153 > 8.2.5. Registration Template for Value Data Types . . . . . = 154 > 8.2.6. Registration Template for Values . . . . . . . . . . = 154 > 8.3. Initial iCalendar Elements Registries . . . . . . . . . . = 155 > 8.3.1. Components Registry . . . . . . . . . . . . . . . . . = 155 > 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . = 156 > 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . = 158 > 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . = 159 > 8.3.5. Calendar User Types Registry . . . . . . . . . . . . = 160 > 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . = 160 > 8.3.7. Participation Statuses Registry . . . . . . . . . . . = 161 > 8.3.8. Relationship Types Registry . . . . . . . . . . . . . = 161 > 8.3.9. Participation Roles Registry . . . . . . . . . . . . = 162 > 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . = 162 > 8.3.11. Classifications Registry . . . . . . . . . . . . . . = 162 > 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . = 163 > 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . = 163 > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = 164 > 10.1. Normative References . . . . . . . . . . . . . . . . . . = 164 > 10.2. Informative References . . . . . . . . . . . . . . . . . = 165 > Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . = 167 > A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . = 167 > A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . = 167 > A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . = 167 >=20 >=20 > Notes > ----- > Most of the Table Of Contents give wrong page numbers >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC5545 (draft-ietf-calsify-rfc2445bis-10) > -------------------------------------- > Title : Internet Calendaring and Scheduling Core Object = Specification (iCalendar) > Publication Date : September 2009 > Author(s) : B. Desruisseaux, Ed. > Category : PROPOSED STANDARD > Source : Calendaring and Scheduling Standards = Simplification > Area : Applications > Stream : IETF > Verifying Party : IESG --Apple-Mail=_BAFB3C49-9CBF-4F09-941E-EF54F357AF13 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXT2VVgAKCRBugA9nE248 uKLKAJ9iBGuf7GqQjMytVTfWw8ffsVsjbQCfaxxYhDNCUupCkGQCb8YCH7ENg5w= =AHcX -----END PGP SIGNATURE----- --Apple-Mail=_BAFB3C49-9CBF-4F09-941E-EF54F357AF13-- From nobody Sun Jul 28 07:28: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 9EE4F12011B for ; Sun, 28 Jul 2019 07:28: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NONE=0.001, 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 9PPZ_8Ioys0q for ; Sun, 28 Jul 2019 07:28:40 -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 5A89812003F for ; Sun, 28 Jul 2019 07:28:39 -0700 (PDT) Authentication-Results: mail.aegee.org/x6SERnsw016331; auth=pass (LOGIN) smtp.auth=didopalauzov DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1564324102; i=dkim+MSA-tls@aegee.org; r=y; bh=3BSEs2m36mTRfzxL1sDYp1PrFPEJO2Gj7rOGiorkDr8=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=rs7sgQfLPJsS1Vr25ZB99OBKoSLlpVQd4AntOOyuznvcCFQcWzfvjrRr3KM9ktdVx 8kdnqKTTFOuDAiKGd3FrrJ7n7HlX8LhnOa8tH0N7eFx4RgQAhMsC6aUr7sSuPE8dVj Qo2/LbUZVPSiytUAN3lS6JBqdqwvcZupTUEhs3vf+vmue74QZmdrztw0J440AKaBIC GTxZDFnclaQcFpFEJ85LoMC3xgUj6lqkxF6SRM2toTQsppi2GxbXvSoT7yPVF40TEF FLwPbiZ0Ko61POeiRnVOLjDK7WxSk8M9lcd7lm4WtZ4q9T/pNLW5vNo43ES++bUjC5 hSa8ahv3gHhaE2GAr4KHqzx4jDc+4kkWLtVIK52iLNurLzQ6AJM0GPqM6/JbF4D2sy sDJV0Md1jEy5aVz1g6HQG82/B/jkBLNugl1cr7QxS7mNr0cZPAdC1PSg9w96QvIXqH rdjp5E/BV7IoFQ+5G0Or4sEmHOC0f4b7rZd3XZ+jUIkSNkgUXXIe0ocpDVr/dWbv7W yhpvEkF1JxYaft99zD2eSXxn0gIaqoHlfDUbt4iNpY5ZxOpr4+31ztTE5xH2cTZ6vx ixEsPYIGhK2DY2cBwsi8tTs5UWR19z0wEg31pWtBZs0AdfSDNweXWw+n88Hu1OY3pf NWIsMRq59BRelEIfRrfa8tjA= Authentication-Results: mail.aegee.org/x6SERnsw016331; dkim=none Received: from Tylan ([88.203.199.243]) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id x6SERnsw016331 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 28 Jul 2019 14:27:49 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: Eliot Lear , RFC Errata System Cc: ben@nostrum.com, adam@nostrum.com, aamelnikov@fastmail.fm, calsify@ietf.org, eugene.adell@gmail.com Date: Sun, 28 Jul 2019 14:27:48 +0000 In-Reply-To: <1EBEA8BC-3A1D-4798-8CAD-0A76DCF850B3@cisco.com> References: <20190728114511.A93CFB80D0D@rfc-editor.org> <1EBEA8BC-3A1D-4798-8CAD-0A76DCF850B3@cisco.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.33.90 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: Re: [calsify] [Editorial Errata Reported] RFC5545 (5794) 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, 28 Jul 2019 14:28:45 -0000 Hello Eliot, I suggested over rfc-interest@rfc-editor.org on 13 Oct 2018 and 16 Jan 2019 to put under https://tools.ietf.org/html/rfcFFFF documents that incorporate/integrate accepted (validated or hold for update) errata, so that one does not have to print and read the document, and then dig in the errata to get the documents right. On the second email the answer from Heather Flanagan was: > I've asked Adam Roach (IESG) to respond to this suggestion on the list as the > IESG is pushing ahead with an effort to do just this thing. This anwser mean, that IESG is working on this. I have no other information. Regards Дилян On Sun, 2019-07-28 at 14:30 +0200, Eliot Lear wrote: > The erratum is correct. Good catch. Under the IESG criteria, as this is editorial and will not cause any interoperability or other implementation concerns, it is normally marked “hold for update”. However, because of the particular nature of this erratum, anyone who clicks on the web searchable index gets sent to the wrong place. That’s annoying. Suggestions? > > Eliot > > > > > On 28 Jul 2019, at 13:45, RFC Errata System wrote: > > > > The following errata report has been submitted for RFC5545, > > "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid5794 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Eugene Adell > > > > Section: ToC > > > > Original Text > > ------------- > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 > > 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 > > 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 > > 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 7 > > 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 > > 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 8 > > 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 > > 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 11 > > 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 11 > > 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 12 > > 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 12 > > 3.2.1. Alternate Text Representation . . . . . . . . . . . . 13 > > 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 > > 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 15 > > 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16 > > 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 16 > > 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 17 > > 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 17 > > 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 18 > > 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19 > > 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20 > > 3.2.11. Group or List Membership . . . . . . . . . . . . . . 20 > > 3.2.12. Participation Status . . . . . . . . . . . . . . . . 21 > > 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 22 > > 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 23 > > 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 24 > > 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 > > 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 25 > > 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 26 > > 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 26 > > 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 28 > > 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 29 > > 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 29 > > 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 30 > > 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 30 > > 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 31 > > 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 31 > > 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 34 > > 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 35 > > 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 35 > > 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 36 > > 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 37 > > 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 > > 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 46 > > 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 48 > > 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 > > 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 49 > > 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 50 > > 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 50 > > 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 > > 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 56 > > 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 58 > > 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 60 > > 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 63 > > 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 72 > > 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 77 > > 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 77 > > 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 78 > > 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 79 > > 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 80 > > 3.8. Component Properties . . . . . . . . . . . . . . . . . . 81 > > 3.8.1. Descriptive Component Properties . . . . . . . . . . 81 > > 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 81 > > 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 82 > > 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 83 > > 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 84 > > 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 85 > > 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 87 > > 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 88 > > 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 89 > > 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 90 > > 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 92 > > 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 93 > > 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 94 > > 3.8.2. Date and Time Component Properties . . . . . . . . . 95 > > 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 95 > > 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 96 > > 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 97 > > 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 99 > > 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 100 > > 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 101 > > 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 102 > > 3.8.3. Time Zone Component Properties . . . . . . . . . . . 103 > > 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 103 > > 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 105 > > 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 106 > > 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 106 > > 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 107 > > 3.8.4. Relationship Component Properties . . . . . . . . . . 108 > > 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 108 > > 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 111 > > > > 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 113 > > 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 114 > > 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 117 > > 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 118 > > 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 119 > > 3.8.5. Recurrence Component Properties . . . . . . . . . . . 120 > > 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 120 > > 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 122 > > 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 124 > > 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 134 > > 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 134 > > 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 135 > > 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 135 > > 3.8.7. Change Management Component Properties . . . . . . . 138 > > 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 138 > > 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 139 > > 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 140 > > 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 141 > > 3.8.8. Miscellaneous Component Properties . . . . . . . . . 142 > > 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 142 > > 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 142 > > 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 144 > > 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 146 > > 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 150 > > 6. Internationalization Considerations . . . . . . . . . . . . . 151 > > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 151 > > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151 > > 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 151 > > 8.2. New iCalendar Elements Registration . . . . . . . . . . . 155 > > 8.2.1. iCalendar Elements Registration Procedure . . . . . . 155 > > 8.2.2. Registration Template for Components . . . . . . . . 155 > > 8.2.3. Registration Template for Properties . . . . . . . . 156 > > 8.2.4. Registration Template for Parameters . . . . . . . . 156 > > 8.2.5. Registration Template for Value Data Types . . . . . 157 > > 8.2.6. Registration Template for Values . . . . . . . . . . 157 > > 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 158 > > 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 158 > > 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 158 > > 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 161 > > 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 162 > > 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 162 > > 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 163 > > 8.3.7. Participation Statuses Registry . . . . . . . . . . . 163 > > 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 164 > > 8.3.9. Participation Roles Registry . . . . . . . . . . . . 164 > > 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 165 > > 8.3.11. Classifications Registry . . . . . . . . . . . . . . 165 > > 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 165 > > 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 165 > > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 166 > > 10.1. Normative References . . . . . . . . . . . . . . . . . . 166 > > 10.2. Informative References . . . . . . . . . . . . . . . . . 167 > > Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 169 > > A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 169 > > A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 169 > > A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 169 > > > > > > Corrected Text > > -------------- > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 > > 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 > > 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 > > 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 8 > > 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 > > 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 9 > > 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 > > 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 12 > > 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 12 > > 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 13 > > 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 13 > > 3.2.1. Alternate Text Representation . . . . . . . . . . . . 14 > > 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 > > 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 16 > > 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 17 > > 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 17 > > 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 18 > > 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 18 > > 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 19 > > 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 20 > > 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 21 > > 3.2.11. Group or List Membership . . . . . . . . . . . . . . 21 > > 3.2.12. Participation Status . . . . . . . . . . . . . . . . 22 > > 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 23 > > 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 24 > > 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 25 > > 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 > > 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 26 > > 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 27 > > 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 27 > > 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 29 > > 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 30 > > 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 30 > > 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 31 > > 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 31 > > 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 32 > > 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 32 > > 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 35 > > 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 36 > > 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 37 > > 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 37 > > 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 38 > > 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 > > 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 47 > > 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 49 > > 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 > > 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 50 > > 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 51 > > 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 51 > > 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 > > 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 55 > > 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 57 > > 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 59 > > 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 62 > > 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 71 > > 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 76 > > 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 76 > > 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 77 > > 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 78 > > 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 79 > > 3.8. Component Properties . . . . . . . . . . . . . . . . . . 80 > > 3.8.1. Descriptive Component Properties . . . . . . . . . . 80 > > 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 80 > > 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 81 > > 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 82 > > 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 83 > > 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 84 > > 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 85 > > 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 87 > > 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 88 > > 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 89 > > 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 91 > > 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 92 > > 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 93 > > 3.8.2. Date and Time Component Properties . . . . . . . . . 94 > > 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 94 > > 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 95 > > 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 96 > > 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 97 > > 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 99 > > 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 100 > > 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 101 > > 3.8.3. Time Zone Component Properties . . . . . . . . . . . 102 > > 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 102 > > 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 103 > > 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 104 > > 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 105 > > 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 106 > > 3.8.4. Relationship Component Properties . . . . . . . . . . 106 > > 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 107 > > 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 109 > > 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 111 > > 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 112 > > 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 115 > > 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 116 > > 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 117 > > 3.8.5. Recurrence Component Properties . . . . . . . . . . . 118 > > 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 118 > > 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 120 > > 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 122 > > 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 132 > > 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 132 > > 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 133 > > 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 133 > > 3.8.7. Change Management Component Properties . . . . . . . 136 > > 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 136 > > 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 137 > > 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 138 > > 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 138 > > 3.8.8. Miscellaneous Component Properties . . . . . . . . . 139 > > 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 140 > > 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 140 > > 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 141 > > 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 144 > > 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 147 > > 6. Internationalization Considerations . . . . . . . . . . . . . 148 > > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 148 > > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149 > > 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 149 > > 8.2. New iCalendar Elements Registration . . . . . . . . . . . 152 > > 8.2.1. iCalendar Elements Registration Procedure . . . . . . 152 > > 8.2.2. Registration Template for Components . . . . . . . . 152 > > 8.2.3. Registration Template for Properties . . . . . . . . 153 > > 8.2.4. Registration Template for Parameters . . . . . . . . 153 > > 8.2.5. Registration Template for Value Data Types . . . . . 154 > > 8.2.6. Registration Template for Values . . . . . . . . . . 154 > > 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 155 > > 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 155 > > 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 156 > > 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 158 > > 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 159 > > 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 160 > > 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 160 > > 8.3.7. Participation Statuses Registry . . . . . . . . . . . 161 > > 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 161 > > 8.3.9. Participation Roles Registry . . . . . . . . . . . . 162 > > 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 162 > > 8.3.11. Classifications Registry . . . . . . . . . . . . . . 162 > > 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 163 > > 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 163 > > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 164 > > 10.1. Normative References . . . . . . . . . . . . . . . . . . 164 > > 10.2. Informative References . . . . . . . . . . . . . . . . . 165 > > Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 167 > > A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 167 > > A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 167 > > A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 167 > > > > > > Notes > > ----- > > Most of the Table Of Contents give wrong page numbers > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5545 (draft-ietf-calsify-rfc2445bis-10) > > -------------------------------------- > > Title : Internet Calendaring and Scheduling Core Object Specification (iCalendar) > > Publication Date : September 2009 > > Author(s) : B. Desruisseaux, Ed. > > Category : PROPOSED STANDARD > > Source : Calendaring and Scheduling Standards Simplification > > Area : Applications > > Stream : IETF > > Verifying Party : IESG > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Sun Jul 28 19:08: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 B2DFD1200C1 for ; Sun, 28 Jul 2019 19:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=mailforce.net header.b=wCgbUKkO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zARVfQz7 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 LHtCuxe4Zxf2 for ; Sun, 28 Jul 2019 19:08:41 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1E51200B2 for ; Sun, 28 Jul 2019 19:08:41 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 339E822101; Sun, 28 Jul 2019 22:08:40 -0400 (EDT) Received: from imap6 ([10.202.2.56]) by compute7.internal (MEProxy); Sun, 28 Jul 2019 22:08:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=jZfnf+7r2hEnllpAm6PfEryh+j7Z ROF8C0pWXMoJS54=; b=wCgbUKkO3AH6xx9J+nTJgQU3TUkkXQpvC4zv2agO41e0 jU5SyARajSl7IbFmUVzcAhaQAdctVEh7Uqns7fuzU5VpgPxU8y9NRr/dp/y4yrba cunOoGy5XjOs/SXktX3a+gz1vNXm878GH35c2NZYRw0MdPKJXqqcqfRXgnXP0pR8 xD2XqYe77A3WhwHo2yosxpFB6vhRe49kuOZRzmGUIt8SqOyPlkX5NP3TeBFV9yMc 64g5PcO0LICCfTJArF4YSmNy5x6iZm5VrTUj3gjUXLvraps458NCzJlm+CBqBbmP dh9I8pbbilprMHPFeJ9yikBW0KtRZLo6j6S+Psijxg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=jZfnf+ 7r2hEnllpAm6PfEryh+j7ZROF8C0pWXMoJS54=; b=zARVfQz715rHOdSGpOmQQa gG1D/eFdlo7Ry9or3jrJPboqDeP+GYdn/nK8KTegzeGDos8lusv6e91nfiKMgOmW R3+A14CaPMdjxkzGTS74CrEIok45w0Vaxjnbo/7y4Y6mQ7s0/oB7LH+yDN5E4RyE DQuDbSsdvqudV7fBzcdgv8ocp5UEfraCop33asP/NhLREQNphm6Vcm51oc8XwGWX e2JwhLfFqP2CeWnz3sfTf67Xvi4nBI54PBN6YWyfFDwXwQ5B4+708eOy38vB54qK vroXewwIGB/MK2HBRgAz4js+4uxPLiMbrnzJTASjmJLX+Fq1AaHiKzkAkPV6gkPA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrledtgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfufhtrghn ucfmrghlihhstghhfdcuoehsthgrnhesghhlhihphhgvihhnrdhmrghilhhfohhrtggvrd hnvghtqeenucffohhmrghinheprhhftgdqvgguihhtohhrrdhorhhgpdhivghtfhdrohhr ghenucfrrghrrghmpehmrghilhhfrhhomhepshhtrghnsehglhihphhhvghinhdrmhgrih hlfhhorhgtvgdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 27749140169; Sun, 28 Jul 2019 22:08:38 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-736-gdfb8e44-fmstable-20190718v2 Mime-Version: 1.0 Message-Id: <877ba1d2-310f-403a-a6b5-fb7831858b72@www.fastmail.com> In-Reply-To: <1EBEA8BC-3A1D-4798-8CAD-0A76DCF850B3@cisco.com> References: <20190728114511.A93CFB80D0D@rfc-editor.org> <1EBEA8BC-3A1D-4798-8CAD-0A76DCF850B3@cisco.com> Date: Sun, 28 Jul 2019 22:08:37 -0400 From: "Stan Kalisch" To: "Eliot Lear" , "RFC Errata System" Cc: ben@nostrum.com, adam@nostrum.com, aamelnikov@fastmail.fm, calsify@ietf.org, eugene.adell@gmail.com Content-Type: multipart/alternative; boundary=707866e9667e420f8b06273408cfc416 Archived-At: Subject: Re: [calsify] [Editorial Errata Reported] RFC5545 (5794) 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, 29 Jul 2019 02:08:45 -0000 --707866e9667e420f8b06273408cfc416 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, On Sun, Jul 28, 2019, at 8:30 AM, Eliot Lear wrote: > The erratum is correct. Good catch. Under the IESG criteria, as this i= s editorial and will not cause any interoperability or other implementat= ion concerns, it is normally marked =E2=80=9Chold for update=E2=80=9D. H= owever, because of the particular nature of this erratum, anyone who cli= cks on the web searchable index gets sent to the wrong place. That=E2=80= =99s annoying. Suggestions? Per https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/: "Only errors that could cause implementation or deployment problems or s= ignificant confusion should be Verified." So, the way I read it, it comes down to whether the confusion this could= cause is judged to be "significant". My personal opinion is that, given= that the table of contents should go up to page 167, and given that the= re will be more than a few marginally exhausted implementers likely read= ing this at some point, it's "significant enough." Stan > Eliot >=20 >=20 >=20 > > On 28 Jul 2019, at 13:45, RFC Errata System wrote: > >=20 > > The following errata report has been submitted for RFC5545, > > "Internet Calendaring and Scheduling Core Object Specification (iCal= endar)". > >=20 > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid5794 > >=20 > > -------------------------------------- > > Type: Editorial > > Reported by: Eugene Adell > >=20 > > Section: ToC > >=20 > > Original Text > > ------------- > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 > > 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 > > 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 > > 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 7 > > 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 > > 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 8 > > 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 > > 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 11 > > 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 11 > > 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 12 > > 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 12 > > 3.2.1. Alternate Text Representation . . . . . . . . . . . . 13 > > 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 > > 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 15 > > 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 16 > > 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 16 > > 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 17 > > 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 17 > > 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 18 > > 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 19 > > 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 20 > > 3.2.11. Group or List Membership . . . . . . . . . . . . . . 20 > > 3.2.12. Participation Status . . . . . . . . . . . . . . . . 21 > > 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 22 > > 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 23 > > 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 24 > > 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 > > 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 25 > > 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 26 > > 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 26 > > 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 28 > > 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 29 > > 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 29 > > 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 30 > > 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 30 > > 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 31 > > 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 31 > > 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 34 > > 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 35 > > 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 35 > > 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 36 > > 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 37 > > 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 > > 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 46 > > 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 48 > > 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 > > 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 49 > > 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 50 > > 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 50 > > 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 > > 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 56 > > 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 58 > > 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 60 > > 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 63 > > 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 72 > > 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 77 > > 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 77 > > 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 78 > > 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 79 > > 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 80 > > 3.8. Component Properties . . . . . . . . . . . . . . . . . . 81 > > 3.8.1. Descriptive Component Properties . . . . . . . . . . 81 > > 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 81 > > 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 82 > > 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 83 > > 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 84 > > 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 85 > > 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 87 > > 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 88 > > 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 89 > > 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 90 > > 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 92 > > 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 93 > > 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 94 > > 3.8.2. Date and Time Component Properties . . . . . . . . . 95 > > 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 95 > > 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 96 > > 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 97 > > 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 99 > > 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 100 > > 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 101 > > 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 102 > > 3.8.3. Time Zone Component Properties . . . . . . . . . . . 103 > > 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 103 > > 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 105 > > 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 106 > > 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 106 > > 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 107 > > 3.8.4. Relationship Component Properties . . . . . . . . . . 108 > > 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 108 > > 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 111 > >=20 > > 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 113 > > 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 114 > > 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 117 > > 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 118 > > 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 119 > > 3.8.5. Recurrence Component Properties . . . . . . . . . . . 120 > > 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 120 > > 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 122 > > 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 124 > > 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 134 > > 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 134 > > 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 135 > > 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 135 > > 3.8.7. Change Management Component Properties . . . . . . . 138 > > 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 138 > > 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 139 > > 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 140 > > 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 141 > > 3.8.8. Miscellaneous Component Properties . . . . . . . . . 142 > > 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 142 > > 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 142 > > 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 144 > > 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 146= > > 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 150= > > 6. Internationalization Considerations . . . . . . . . . . . . . 151= > > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 151= > > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151= > > 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 151 > > 8.2. New iCalendar Elements Registration . . . . . . . . . . . 155 > > 8.2.1. iCalendar Elements Registration Procedure . . . . . . 155 > > 8.2.2. Registration Template for Components . . . . . . . . 155 > > 8.2.3. Registration Template for Properties . . . . . . . . 156 > > 8.2.4. Registration Template for Parameters . . . . . . . . 156 > > 8.2.5. Registration Template for Value Data Types . . . . . 157 > > 8.2.6. Registration Template for Values . . . . . . . . . . 157 > > 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 158 > > 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 158 > > 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 158 > > 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 161 > > 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 162 > > 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 162 > > 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 163 > > 8.3.7. Participation Statuses Registry . . . . . . . . . . . 163 > > 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 164 > > 8.3.9. Participation Roles Registry . . . . . . . . . . . . 164 > > 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 165 > > 8.3.11. Classifications Registry . . . . . . . . . . . . . . 165 > > 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 165 > > 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 165= > > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 166= > > 10.1. Normative References . . . . . . . . . . . . . . . . . . 166 > > 10.2. Informative References . . . . . . . . . . . . . . . . . 167 > > Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 169 > > A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 169 > > A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 169 > > A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 169 > >=20 > >=20 > > Corrected Text > > -------------- > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 > > 2. Basic Grammar and Conventions . . . . . . . . . . . . . . . . 6 > > 2.1. Formatting Conventions . . . . . . . . . . . . . . . . . 6 > > 2.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 8 > > 3. iCalendar Object Specification . . . . . . . . . . . . . . . 8 > > 3.1. Content Lines . . . . . . . . . . . . . . . . . . . . . . 9 > > 3.1.1. List and Field Separators . . . . . . . . . . . . . . 11 > > 3.1.2. Multiple Values . . . . . . . . . . . . . . . . . . . 12 > > 3.1.3. Binary Content . . . . . . . . . . . . . . . . . . . 12 > > 3.1.4. Character Set . . . . . . . . . . . . . . . . . . . . 13 > > 3.2. Property Parameters . . . . . . . . . . . . . . . . . . . 13 > > 3.2.1. Alternate Text Representation . . . . . . . . . . . . 14 > > 3.2.2. Common Name . . . . . . . . . . . . . . . . . . . . . 15 > > 3.2.3. Calendar User Type . . . . . . . . . . . . . . . . . 16 > > 3.2.4. Delegators . . . . . . . . . . . . . . . . . . . . . 17 > > 3.2.5. Delegatees . . . . . . . . . . . . . . . . . . . . . 17 > > 3.2.6. Directory Entry Reference . . . . . . . . . . . . . . 18 > > 3.2.7. Inline Encoding . . . . . . . . . . . . . . . . . . . 18 > > 3.2.8. Format Type . . . . . . . . . . . . . . . . . . . . . 19 > > 3.2.9. Free/Busy Time Type . . . . . . . . . . . . . . . . . 20 > > 3.2.10. Language . . . . . . . . . . . . . . . . . . . . . . 21 > > 3.2.11. Group or List Membership . . . . . . . . . . . . . . 21 > > 3.2.12. Participation Status . . . . . . . . . . . . . . . . 22 > > 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . 23 > > 3.2.14. Alarm Trigger Relationship . . . . . . . . . . . . . 24 > > 3.2.15. Relationship Type . . . . . . . . . . . . . . . . . . 25 > > 3.2.16. Participation Role . . . . . . . . . . . . . . . . . 25 > > 3.2.17. RSVP Expectation . . . . . . . . . . . . . . . . . . 26 > > 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . . 27 > > 3.2.19. Time Zone Identifier . . . . . . . . . . . . . . . . 27 > > 3.2.20. Value Data Types . . . . . . . . . . . . . . . . . . 29 > > 3.3. Property Value Data Types . . . . . . . . . . . . . . . . 30 > > 3.3.1. Binary . . . . . . . . . . . . . . . . . . . . . . . 30 > > 3.3.2. Boolean . . . . . . . . . . . . . . . . . . . . . . . 31 > > 3.3.3. Calendar User Address . . . . . . . . . . . . . . . . 31 > > 3.3.4. Date . . . . . . . . . . . . . . . . . . . . . . . . 32 > > 3.3.5. Date-Time . . . . . . . . . . . . . . . . . . . . . . 32 > > 3.3.6. Duration . . . . . . . . . . . . . . . . . . . . . . 35 > > 3.3.7. Float . . . . . . . . . . . . . . . . . . . . . . . . 36 > > 3.3.8. Integer . . . . . . . . . . . . . . . . . . . . . . . 37 > > 3.3.9. Period of Time . . . . . . . . . . . . . . . . . . . 37 > > 3.3.10. Recurrence Rule . . . . . . . . . . . . . . . . . . . 38 > > 3.3.11. Text . . . . . . . . . . . . . . . . . . . . . . . . 45 > > 3.3.12. Time . . . . . . . . . . . . . . . . . . . . . . . . 47 > > 3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . . 49 > > 3.3.14. UTC Offset . . . . . . . . . . . . . . . . . . . . . 49 > > 3.4. iCalendar Object . . . . . . . . . . . . . . . . . . . . 50 > > 3.5. Property . . . . . . . . . . . . . . . . . . . . . . . . 51 > > 3.6. Calendar Components . . . . . . . . . . . . . . . . . . . 51 > > 3.6.1. Event Component . . . . . . . . . . . . . . . . . . . 52 > > 3.6.2. To-Do Component . . . . . . . . . . . . . . . . . . . 55 > > 3.6.3. Journal Component . . . . . . . . . . . . . . . . . . 57 > > 3.6.4. Free/Busy Component . . . . . . . . . . . . . . . . . 59 > > 3.6.5. Time Zone Component . . . . . . . . . . . . . . . . . 62 > > 3.6.6. Alarm Component . . . . . . . . . . . . . . . . . . . 71 > > 3.7. Calendar Properties . . . . . . . . . . . . . . . . . . . 76 > > 3.7.1. Calendar Scale . . . . . . . . . . . . . . . . . . . 76 > > 3.7.2. Method . . . . . . . . . . . . . . . . . . . . . . . 77 > > 3.7.3. Product Identifier . . . . . . . . . . . . . . . . . 78 > > 3.7.4. Version . . . . . . . . . . . . . . . . . . . . . . . 79 > > 3.8. Component Properties . . . . . . . . . . . . . . . . . . 80 > > 3.8.1. Descriptive Component Properties . . . . . . . . . . 80 > > 3.8.1.1. Attachment . . . . . . . . . . . . . . . . . . . 80 > > 3.8.1.2. Categories . . . . . . . . . . . . . . . . . . . 81 > > 3.8.1.3. Classification . . . . . . . . . . . . . . . . . 82 > > 3.8.1.4. Comment . . . . . . . . . . . . . . . . . . . . . 83 > > 3.8.1.5. Description . . . . . . . . . . . . . . . . . . . 84 > > 3.8.1.6. Geographic Position . . . . . . . . . . . . . . . 85 > > 3.8.1.7. Location . . . . . . . . . . . . . . . . . . . . 87 > > 3.8.1.8. Percent Complete . . . . . . . . . . . . . . . . 88 > > 3.8.1.9. Priority . . . . . . . . . . . . . . . . . . . . 89 > > 3.8.1.10. Resources . . . . . . . . . . . . . . . . . . . . 91 > > 3.8.1.11. Status . . . . . . . . . . . . . . . . . . . . . 92 > > 3.8.1.12. Summary . . . . . . . . . . . . . . . . . . . . . 93 > > 3.8.2. Date and Time Component Properties . . . . . . . . . 94 > > 3.8.2.1. Date-Time Completed . . . . . . . . . . . . . . . 94 > > 3.8.2.2. Date-Time End . . . . . . . . . . . . . . . . . . 95 > > 3.8.2.3. Date-Time Due . . . . . . . . . . . . . . . . . . 96 > > 3.8.2.4. Date-Time Start . . . . . . . . . . . . . . . . . 97 > > 3.8.2.5. Duration . . . . . . . . . . . . . . . . . . . . 99 > > 3.8.2.6. Free/Busy Time . . . . . . . . . . . . . . . . . 100 > > 3.8.2.7. Time Transparency . . . . . . . . . . . . . . . . 101 > > 3.8.3. Time Zone Component Properties . . . . . . . . . . . 102 > > 3.8.3.1. Time Zone Identifier . . . . . . . . . . . . . . 102 > > 3.8.3.2. Time Zone Name . . . . . . . . . . . . . . . . . 103 > > 3.8.3.3. Time Zone Offset From . . . . . . . . . . . . . . 104 > > 3.8.3.4. Time Zone Offset To . . . . . . . . . . . . . . . 105 > > 3.8.3.5. Time Zone URL . . . . . . . . . . . . . . . . . . 106 > > 3.8.4. Relationship Component Properties . . . . . . . . . . 106 > > 3.8.4.1. Attendee . . . . . . . . . . . . . . . . . . . . 107 > > 3.8.4.2. Contact . . . . . . . . . . . . . . . . . . . . . 109 > > 3.8.4.3. Organizer . . . . . . . . . . . . . . . . . . . . 111 > > 3.8.4.4. Recurrence ID . . . . . . . . . . . . . . . . . . 112 > > 3.8.4.5. Related To . . . . . . . . . . . . . . . . . . . 115 > > 3.8.4.6. Uniform Resource Locator . . . . . . . . . . . . 116 > > 3.8.4.7. Unique Identifier . . . . . . . . . . . . . . . . 117 > > 3.8.5. Recurrence Component Properties . . . . . . . . . . . 118 > > 3.8.5.1. Exception Date-Times . . . . . . . . . . . . . . 118 > > 3.8.5.2. Recurrence Date-Times . . . . . . . . . . . . . . 120 > > 3.8.5.3. Recurrence Rule . . . . . . . . . . . . . . . . . 122 > > 3.8.6. Alarm Component Properties . . . . . . . . . . . . . 132 > > 3.8.6.1. Action . . . . . . . . . . . . . . . . . . . . . 132 > > 3.8.6.2. Repeat Count . . . . . . . . . . . . . . . . . . 133 > > 3.8.6.3. Trigger . . . . . . . . . . . . . . . . . . . . . 133 > > 3.8.7. Change Management Component Properties . . . . . . . 136 > > 3.8.7.1. Date-Time Created . . . . . . . . . . . . . . . . 136 > > 3.8.7.2. Date-Time Stamp . . . . . . . . . . . . . . . . . 137 > > 3.8.7.3. Last Modified . . . . . . . . . . . . . . . . . . 138 > > 3.8.7.4. Sequence Number . . . . . . . . . . . . . . . . . 138 > > 3.8.8. Miscellaneous Component Properties . . . . . . . . . 139 > > 3.8.8.1. IANA Properties . . . . . . . . . . . . . . . . . 140 > > 3.8.8.2. Non-Standard Properties . . . . . . . . . . . . . 140 > > 3.8.8.3. Request Status . . . . . . . . . . . . . . . . . 141 > > 4. iCalendar Object Examples . . . . . . . . . . . . . . . . . . 144= > > 5. Recommended Practices . . . . . . . . . . . . . . . . . . . . 147= > > 6. Internationalization Considerations . . . . . . . . . . . . . 148= > > 7. Security Considerations . . . . . . . . . . . . . . . . . . . 148= > > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149= > > 8.1. iCalendar Media Type Registration . . . . . . . . . . . . 149 > > 8.2. New iCalendar Elements Registration . . . . . . . . . . . 152 > > 8.2.1. iCalendar Elements Registration Procedure . . . . . . 152 > > 8.2.2. Registration Template for Components . . . . . . . . 152 > > 8.2.3. Registration Template for Properties . . . . . . . . 153 > > 8.2.4. Registration Template for Parameters . . . . . . . . 153 > > 8.2.5. Registration Template for Value Data Types . . . . . 154 > > 8.2.6. Registration Template for Values . . . . . . . . . . 154 > > 8.3. Initial iCalendar Elements Registries . . . . . . . . . . 155 > > 8.3.1. Components Registry . . . . . . . . . . . . . . . . . 155 > > 8.3.2. Properties Registry . . . . . . . . . . . . . . . . . 156 > > 8.3.3. Parameters Registry . . . . . . . . . . . . . . . . . 158 > > 8.3.4. Value Data Types Registry . . . . . . . . . . . . . . 159 > > 8.3.5. Calendar User Types Registry . . . . . . . . . . . . 160 > > 8.3.6. Free/Busy Time Types Registry . . . . . . . . . . . . 160 > > 8.3.7. Participation Statuses Registry . . . . . . . . . . . 161 > > 8.3.8. Relationship Types Registry . . . . . . . . . . . . . 161 > > 8.3.9. Participation Roles Registry . . . . . . . . . . . . 162 > > 8.3.10. Actions Registry . . . . . . . . . . . . . . . . . . 162 > > 8.3.11. Classifications Registry . . . . . . . . . . . . . . 162 > > 8.3.12. Methods Registry . . . . . . . . . . . . . . . . . . 163 > > 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 163= > > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 164= > > 10.1. Normative References . . . . . . . . . . . . . . . . . . 164 > > 10.2. Informative References . . . . . . . . . . . . . . . . . 165 > > Appendix A. Differences from RFC 2445 . . . . . . . . . . . . . 167 > > A.1. New Restrictions . . . . . . . . . . . . . . . . . . . . 167 > > A.2. Restrictions Removed . . . . . . . . . . . . . . . . . . 167 > > A.3. Deprecated Features . . . . . . . . . . . . . . . . . . . 167 > >=20 > >=20 > > Notes > > ----- > > Most of the Table Of Contents give wrong page numbers > >=20 > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please= > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > >=20 > > -------------------------------------- > > RFC5545 (draft-ietf-calsify-rfc2445bis-10) > > -------------------------------------- > > Title : Internet Calendaring and Scheduling Core Object Specificatio= n (iCalendar) > > Publication Date : September 2009 > > Author(s) : B. Desruisseaux, Ed. > > Category : PROPOSED STANDARD > > Source : Calendaring and Scheduling Standards Simplification > > Area : Applications > > Stream : IETF > > Verifying Party : IESG >=20 >=20 > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify >=20 >=20 > *Attachments:* > * signature.asc --707866e9667e420f8b06273408cfc416 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Sun, Jul 28, 2019, at 8:30 AM, = Eliot Lear wrote:
The = erratum is correct.  Good catch.  Under the IESG criteria, as = this is editorial and will not cause any interoperability or other imple= mentation concerns, it is normally marked =E2=80=9Chold for update=E2=80= =9D.  However, because of the particular nature of this erratum, an= yone who clicks on the web searchable index gets sent to the wrong place= .  That=E2=80=99s annoying.  Suggestions?


"Only errors that could = cause implementation or deployment problems or significant confusion sho= uld be Verified."

<= div style=3D"font-family:Arial;">So, the way I read it, it comes down to= whether the confusion this could cause is judged to be "significant". &= nbsp;My personal opinion is that, given that the table of contents shoul= d go up to page 167, and given that there will be more than a few margin= ally exhausted implementers likely reading this at some point, it's "sig= nificant enough."

<= div style=3D"font-family:Arial;">
Stan

Eliot


<= /div>

> On 28 Jul 2019, at 13:45, RFC Errata Syste= m <rfc-editor@rfc-editor.org> wrote:
> 
<= /div>
> The following errata report has been submitted for RFC554= 5,
> "Internet Calendaring and Scheduling Core Object S= pecification (iCalendar)".
> 
> -= -------------------------------------
> You may review = the report below and at:
> https://www.rfc-editor.org/e= rrata/eid5794
> 
> --------------= ------------------------
> Type: Editorial
> Reported by: Eugene Adell <eugene.adell@gmail.com>
> 
> Section: ToC
> = ;
> Original Text
> -------------
<= /div>
>   1.  Introduction  . . . . . . . . .= . . . . . . . . . . . . . . .   5
> &nb= sp; 2.  Basic Grammar and Conventions . . . . . . . . . . . . . . .= .   6
>     2.1.  F= ormatting Conventions  . . . . . . . . . . . . . . . . .  = ; 6
>     2.2.  Related Memos = . . . . . . . . . . . . . . . . . . . . . .   7
= >   3.  iCalendar Object Specification  . . . . .= . . . . . . . . . .   8
>   &= nbsp; 3.1.  Content Lines . . . . . . . . . . . . . . . . . . . . .= .   8
>       = 3.1.1.  List and Field Separators . . . . . . . . . . . . . . = 11
>       3.1.2.  = Multiple Values . . . . . . . . . . . . . . . . . . .  11
=
>       3.1.3.  Binary Conten= t  . . . . . . . . . . . . . . . . . . .  11
>= ;       3.1.4.  Character Set . . . .= . . . . . . . . . . . . . . . .  12
>  =    3.2.  Property Parameters . . . . . . . . . . . . . . = . . . . .  12
>      = ; 3.2.1.  Alternate Text Representation . . . . . . . . . . . .&nbs= p; 13
>       3.2.2. = ; Common Name . . . . . . . . . . . . . . . . . . . . .  15
>       3.2.3.  Calendar Us= er Type  . . . . . . . . . . . . . . . . .  15
&= gt;       3.2.4.  Delegators  . = . . . . . . . . . . . . . . . . . . . .  16
> = ;      3.2.5.  Delegatees  . . . . . = . . . . . . . . . . . . . . . .  16
>  &= nbsp;    3.2.6.  Directory Entry Reference . . . . .= . . . . . . . . .  17
>    &n= bsp;  3.2.7.  Inline Encoding . . . . . . . . . . . . . . . . = . . .  17
>       3.= 2.8.  Format Type . . . . . . . . . . . . . . . . . . . . .  1= 8
>       3.2.9.  Fr= ee/Busy Time Type . . . . . . . . . . . . . . . . .  19
>       3.2.10. Language  . . .= . . . . . . . . . . . . . . . . . . .  20
> =       3.2.11. Group or List Membership  . = . . . . . . . . . . . . .  20
>   &= nbsp;   3.2.12. Participation Status  . . . . . . . . . .= . . . . . .  21
>     &n= bsp; 3.2.13. Recurrence Identifier Range . . . . . . . . . . . . . = 22
>       3.2.14. Alarm= Trigger Relationship  . . . . . . . . . . . . .  23
=
>       3.2.15. Relationship Type = . . . . . . . . . . . . . . . . . .  24
> &nb= sp;     3.2.16. Participation Role  . . . . . .= . . . . . . . . . . .  25
>   &nbs= p;   3.2.17. RSVP Expectation  . . . . . . . . . . . . . = . . . . .  25
>      = ; 3.2.18. Sent By . . . . . . . . . . . . . . . . . . . . . . .  26=
>       3.2.19. Time Zon= e Identifier  . . . . . . . . . . . . . . . .  26
>       3.2.20. Value Data Types = ; . . . . . . . . . . . . . . . . . .  28
> &= nbsp;   3.3.  Property Value Data Types . . . . . . . . .= . . . . . . .  29
>     =   3.3.1.  Binary  . . . . . . . . . . . . . . . . . . . .= . . .  29
>       3= .3.2.  Boolean . . . . . . . . . . . . . . . . . . . . . . .  = 30
>       3.3.3.  C= alendar User Address . . . . . . . . . . . . . . . .  30
<= div>>       3.3.4.  Date  . .= . . . . . . . . . . . . . . . . . . . . . .  31
>=        3.3.5.  Date-Time . . . . . . = . . . . . . . . . . . . . . . .  31
>  &= nbsp;    3.3.6.  Duration  . . . . . . . . . . = . . . . . . . . . . . .  34
>   &nb= sp;   3.3.7.  Float . . . . . . . . . . . . . . . . . . .= . . . . .  35
>     &nbs= p; 3.3.8.  Integer . . . . . . . . . . . . . . . . . . . . . . .&nb= sp; 35
>       3.3.9.&nbs= p; Period of Time  . . . . . . . . . . . . . . . . . . .  36
>       3.3.10. Recurrence= Rule . . . . . . . . . . . . . . . . . . .  37
>&= nbsp;      3.3.11. Text  . . . . . . . . .= . . . . . . . . . . . . . . .  45
>  &n= bsp;    3.3.12. Time  . . . . . . . . . . . . . . . = . . . . . . . . .  46
>    &nb= sp;  3.3.13. URI . . . . . . . . . . . . . . . . . . . . . . . . .&= nbsp; 48
>       3.3.14. = UTC Offset  . . . . . . . . . . . . . . . . . . . . .  49
<= /div>
>     3.4.  iCalendar Object = . . . . . . . . . . . . . . . . . . . .  49
>&nbs= p;    3.5.  Property  . . . . . . . . . . . . .= . . . . . . . . . . .  50
>   &nbs= p; 3.6.  Calendar Components . . . . . . . . . . . . . . . . . . .&= nbsp; 50
>       3.6.1.&n= bsp; Event Component . . . . . . . . . . . . . . . . . . .  52
<= /div>
>       3.6.2.  To-Do Co= mponent . . . . . . . . . . . . . . . . . . .  56
>= ;       3.6.3.  Journal Component . .= . . . . . . . . . . . . . . . .  58
>  =      3.6.4.  Free/Busy Component . . . . . . . = . . . . . . . . . .  60
>    &= nbsp;  3.6.5.  Time Zone Component . . . . . . . . . . . . . .= . . .  63
>       3= .6.6.  Alarm Component . . . . . . . . . . . . . . . . . . .  = 72
>     3.7.  Calendar Proper= ties . . . . . . . . . . . . . . . . . . .  77
>&n= bsp;      3.7.1.  Calendar Scale  . .= . . . . . . . . . . . . . . . . .  77
> &nbs= p;     3.7.2.  Method  . . . . . . . . . .= . . . . . . . . . . . . .  78
>   =     3.7.3.  Product Identifier  . . . . . . . .= . . . . . . . . .  79
>    &n= bsp;  3.7.4.  Version . . . . . . . . . . . . . . . . . . . . = . . .  80
>     3.8.  Com= ponent Properties  . . . . . . . . . . . . . . . . . .  81
=
>       3.8.1.  Descrip= tive Component Properties  . . . . . . . . . .  81
>         3.8.1.1.  A= ttachment  . . . . . . . . . . . . . . . . . . .  81
=
>         3.8.1.2. = Categories  . . . . . . . . . . . . . . . . . . .  82
>         3.8.1.3.&nbs= p; Classification  . . . . . . . . . . . . . . . . .  83
>         3.8.1.4.&n= bsp; Comment . . . . . . . . . . . . . . . . . . . . .  84
>         3.8.1.5. = ; Description . . . . . . . . . . . . . . . . . . .  85
>         3.8.1.6.  G= eographic Position . . . . . . . . . . . . . . .  87
= >         3.8.1.7.  Loca= tion  . . . . . . . . . . . . . . . . . . . .  88
>         3.8.1.8.  Pe= rcent Complete  . . . . . . . . . . . . . . . .  89
<= div>>         3.8.1.9.  = Priority  . . . . . . . . . . . . . . . . . . . .  90
>         3.8.1.10. Res= ources . . . . . . . . . . . . . . . . . . . .  92
&g= t;         3.8.1.11. Status = ; . . . . . . . . . . . . . . . . . . . . .  93
>&= nbsp;        3.8.1.12. Summary . . . = . . . . . . . . . . . . . . . . . .  94
> &nb= sp;     3.8.2.  Date and Time Component Propert= ies  . . . . . . . . .  95
>   = ;      3.8.2.1.  Date-Time Completed . . .= . . . . . . . . . . . .  95
>   &n= bsp;     3.8.2.2.  Date-Time End . . . . . . . = . . . . . . . . . . .  96
>    = ;     3.8.2.3.  Date-Time Due . . . . . . . . .= . . . . . . . . .  97
>    &n= bsp;    3.8.2.4.  Date-Time Start . . . . . . . . . = . . . . . . . .  99
>     = ;    3.8.2.5.  Duration  . . . . . . . . . . . = . . . . . . . . . 100
>     &n= bsp;   3.8.2.6.  Free/Busy Time  . . . . . . . . . .= . . . . . . . 101
>      = ;   3.8.2.7.  Time Transparency . . . . . . . . . . . . .= . . . 102
>       3.8.3.=   Time Zone Component Properties  . . . . . . . . . . . 103
>         3.8.3.1= .  Time Zone Identifier  . . . . . . . . . . . . . . 103
>         3.8.3.2.&n= bsp; Time Zone Name  . . . . . . . . . . . . . . . . . 105
>         3.8.3.3. = ; Time Zone Offset From . . . . . . . . . . . . . . 106
&g= t;         3.8.3.4.  Time Z= one Offset To . . . . . . . . . . . . . . . 106
> =         3.8.3.5.  Time Zone URL = . . . . . . . . . . . . . . . . . . 107
>  &n= bsp;    3.8.4.  Relationship Component Properties . = . . . . . . . . . 108
>     &n= bsp;   3.8.4.1.  Attendee  . . . . . . . . . . . . .= . . . . . . . 108
>      = ;   3.8.4.2.  Contact . . . . . . . . . . . . . . . . . .= . . . 111
> 
>   =       3.8.4.3.  Organizer . . . . . . . . = . . . . . . . . . . . . 113
>    &n= bsp;    3.8.4.4.  Recurrence ID . . . . . . . . . . = . . . . . . . . 114
>     &nbs= p;   3.8.4.5.  Related To  . . . . . . . . . . . . .= . . . . . . 117
>      &= nbsp;  3.8.4.6.  Uniform Resource Locator  . . . . . . . = . . . . . 118
>      &nbs= p;  3.8.4.7.  Unique Identifier . . . . . . . . . . . . . . . = . 119
>       3.8.5. = ; Recurrence Component Properties . . . . . . . . . . . 120
>         3.8.5.1.  Ex= ception Date-Times  . . . . . . . . . . . . . . 120
&= gt;         3.8.5.2.  Recur= rence Date-Times . . . . . . . . . . . . . . 122
> = ;        3.8.5.3.  Recurrence Ru= le . . . . . . . . . . . . . . . . . 124
>  &= nbsp;    3.8.6.  Alarm Component Properties  . = . . . . . . . . . . . . 134
>    &n= bsp;    3.8.6.1.  Action  . . . . . . . . . . .= . . . . . . . . . . 134
>     = ;    3.8.6.2.  Repeat Count  . . . . . . . . . = . . . . . . . . . 135
>     &n= bsp;   3.8.6.3.  Trigger . . . . . . . . . . . . . . . . = . . . . . 135
>       3.8= .7.  Change Management Component Properties  . . . . . . . 138=
>         3.8.= 7.1.  Date-Time Created . . . . . . . . . . . . . . . . 138
>         3.8.7.2.&nbs= p; Date-Time Stamp . . . . . . . . . . . . . . . . . 139
&= gt;         3.8.7.3.  Last = Modified . . . . . . . . . . . . . . . . . . 140
> = ;        3.8.7.4.  Sequence Numb= er . . . . . . . . . . . . . . . . . 141
>  &= nbsp;    3.8.8.  Miscellaneous Component Properties&= nbsp; . . . . . . . . . 142
>    &n= bsp;    3.8.8.1.  IANA Properties . . . . . . . . . = . . . . . . . . 142
>     &nbs= p;   3.8.8.2.  Non-Standard Properties . . . . . . . . . = . . . . 142
>       =   3.8.8.3.  Request Status  . . . . . . . . . . . . . . .= . . 144
>   4.  iCalendar Object Exampl= es . . . . . . . . . . . . . . . . . . 146
>  = ; 5.  Recommended Practices . . . . . . . . . . . . . . . . . . . .= 150
>   6.  Internationalization Consid= erations . . . . . . . . . . . . . 151
>   7.=   Security Considerations . . . . . . . . . . . . . . . . . . . 151=
>   8.  IANA Considerations . . . . . .= . . . . . . . . . . . . . . . 151
>   &= nbsp; 8.1.  iCalendar Media Type Registration . . . . . . . . . . .= . 151
>     8.2.  New iCalend= ar Elements Registration . . . . . . . . . . . 155
>&nb= sp;      8.2.1.  iCalendar Elements Regist= ration Procedure . . . . . . 155
>   &nb= sp;   8.2.2.  Registration Template for Components  = . . . . . . . . 155
>     &nbs= p; 8.2.3.  Registration Template for Properties  . . . . . . .= . 156
>       8.2.4.&nbs= p; Registration Template for Parameters  . . . . . . . . 156
>       8.2.5.  Registrati= on Template for Value Data Types  . . . . . 157
>&= nbsp;      8.2.6.  Registration Template f= or Values  . . . . . . . . . . 157
>  &n= bsp;  8.3.  Initial iCalendar Elements Registries . . . . . . = . . . . 158
>       8.3.1= .  Components Registry . . . . . . . . . . . . . . . . . 158
>       8.3.2.  Properties= Registry . . . . . . . . . . . . . . . . . 158
> =       8.3.3.  Parameters Registry . . . . = . . . . . . . . . . . . . 161
>    =    8.3.4.  Value Data Types Registry . . . . . . . . . . = . . . . 162
>       8.3.5= .  Calendar User Types Registry  . . . . . . . . . . . . 162
>       8.3.6.  Free/= Busy Time Types Registry . . . . . . . . . . . . 163
>&= nbsp;      8.3.7.  Participation Statuses = Registry . . . . . . . . . . . 163
>   &= nbsp;   8.3.8.  Relationship Types Registry . . . . . . .= . . . . . . 164
>       = 8.3.9.  Participation Roles Registry  . . . . . . . . . . . . = 164
>       8.3.10. Actio= ns Registry  . . . . . . . . . . . . . . . . . . 165
= >       8.3.11. Classifications Registr= y  . . . . . . . . . . . . . . 165
>  &n= bsp;    8.3.12. Methods Registry  . . . . . . . . . = . . . . . . . . . 165
>   9.  Acknowledg= ments . . . . . . . . . . . . . . . . . . . . . . . 165
&g= t;   10. References  . . . . . . . . . . . . . . . . . . = . . . . . . . 166
>     10.1. Norma= tive References  . . . . . . . . . . . . . . . . . . 166
<= div>>     10.2. Informative References  . . = . . . . . . . . . . . . . . . 167
>   Appendi= x A.  Differences from RFC 2445  . . . . . . . . . . . . . 169=
>     A.1.  New Restrictions&= nbsp; . . . . . . . . . . . . . . . . . . . . 169
>&nbs= p;    A.2.  Restrictions Removed  . . . . . . .= . . . . . . . . . . . 169
>     A.= 3.  Deprecated Features . . . . . . . . . . . . . . . . . . . 169
> 
> 
> Corr= ected Text
> --------------
> &nb= sp; 1.  Introduction  . . . . . . . . . . . . . . . . . . . . = . . . .   5
>   2.  Basic Gram= mar and Conventions . . . . . . . . . . . . . . . .   6
>     2.1.  Formatting Conventions&n= bsp; . . . . . . . . . . . . . . . . .   6
>&= nbsp;    2.2.  Related Memos . . . . . . . . . . . .= . . . . . . . . . .   8
>   3.&nbs= p; iCalendar Object Specification  . . . . . . . . . . . . . . .&nb= sp;  8
>     3.1.  Conten= t Lines . . . . . . . . . . . . . . . . . . . . . .   9
>       3.1.1.  List and F= ield Separators . . . . . . . . . . . . . .  11
>&= nbsp;      3.1.2.  Multiple Values . . . .= . . . . . . . . . . . . . . .  12
>  &n= bsp;    3.1.3.  Binary Content  . . . . . . . .= . . . . . . . . . . .  12
>   &nbs= p;   3.1.4.  Character Set . . . . . . . . . . . . . . . = . . . . .  13
>     3.2. = Property Parameters . . . . . . . . . . . . . . . . . . .  13
<= /div>
>       3.2.1.  Alternat= e Text Representation . . . . . . . . . . . .  14
>= ;       3.2.2.  Common Name . . . . .= . . . . . . . . . . . . . . . .  15
>  =      3.2.3.  Calendar User Type  . . . . .= . . . . . . . . . . . .  16
>   &n= bsp;   3.2.4.  Delegators  . . . . . . . . . . . . .= . . . . . . . .  17
>    &nbs= p;  3.2.5.  Delegatees  . . . . . . . . . . . . . . . . .= . . . .  17
>      = 3.2.6.  Directory Entry Reference . . . . . . . . . . . . . . = ; 18
>       3.2.7. = Inline Encoding . . . . . . . . . . . . . . . . . . .  18
>       3.2.8.  Format Type = . . . . . . . . . . . . . . . . . . . . .  19
>&nb= sp;      3.2.9.  Free/Busy Time Type . . .= . . . . . . . . . . . . . .  20
>  &nbs= p;    3.2.10. Language  . . . . . . . . . . . . . . = . . . . . . . .  21
>     = ;  3.2.11. Group or List Membership  . . . . . . . . . . . . .= .  21
>       3.2.1= 2. Participation Status  . . . . . . . . . . . . . . . .  22
>       3.2.13. Recurrence= Identifier Range . . . . . . . . . . . . .  23
>&= nbsp;      3.2.14. Alarm Trigger Relationship&n= bsp; . . . . . . . . . . . . .  24
>  &n= bsp;    3.2.15. Relationship Type . . . . . . . . . . . .= . . . . . .  25
>     &n= bsp; 3.2.16. Participation Role  . . . . . . . . . . . . . . . . .&= nbsp; 25
>       3.2.17. = RSVP Expectation  . . . . . . . . . . . . . . . . . .  26
<= /div>
>       3.2.18. Sent By . . .= . . . . . . . . . . . . . . . . . . . .  27
>&nbs= p;      3.2.19. Time Zone Identifier  . . = . . . . . . . . . . . . . .  27
>   = ;    3.2.20. Value Data Types  . . . . . . . . . . .= . . . . . . .  29
>     3.3.&= nbsp; Property Value Data Types . . . . . . . . . . . . . . . .  30=
>       3.3.1.  Bin= ary  . . . . . . . . . . . . . . . . . . . . . . .  30
>       3.3.2.  Boolean . .= . . . . . . . . . . . . . . . . . . . . .  31
>&n= bsp;      3.3.3.  Calendar User Address . = . . . . . . . . . . . . . . .  31
>  &nb= sp;    3.3.4.  Date  . . . . . . . . . . . . . = . . . . . . . . . . .  32
>    = ;   3.3.5.  Date-Time . . . . . . . . . . . . . . . . . .= . . . .  32
>      = 3.3.6.  Duration  . . . . . . . . . . . . . . . . . . . . . .=   35
>       3.3.7.&= nbsp; Float . . . . . . . . . . . . . . . . . . . . . . . .  36
=
>       3.3.8.  Integer= . . . . . . . . . . . . . . . . . . . . . . .  37
&g= t;       3.3.9.  Period of Time = . . . . . . . . . . . . . . . . . . .  37
> =       3.3.10. Recurrence Rule . . . . . . . . .= . . . . . . . . . .  38
>    =    3.3.11. Text  . . . . . . . . . . . . . . . . . . . . = . . . .  45
>       = 3.3.12. Time  . . . . . . . . . . . . . . . . . . . . . . . . = 47
>       3.3.13. URI .= . . . . . . . . . . . . . . . . . . . . . . . .  49
= >       3.3.14. UTC Offset  . . . = . . . . . . . . . . . . . . . . . .  49
> &nb= sp;   3.4.  iCalendar Object  . . . . . . . . . . . = . . . . . . . . .  50
>     3.= 5.  Property  . . . . . . . . . . . . . . . . . . . . . . . .&= nbsp; 51
>     3.6.  Calendar = Components . . . . . . . . . . . . . . . . . . .  51
= >       3.6.1.  Event Component . = . . . . . . . . . . . . . . . . . .  52
> &nb= sp;     3.6.2.  To-Do Component . . . . . . . .= . . . . . . . . . . .  55
>   &nbs= p;   3.6.3.  Journal Component . . . . . . . . . . . . . = . . . . .  57
>      = ; 3.6.4.  Free/Busy Component . . . . . . . . . . . . . . . . .&nbs= p; 59
>       3.6.5. = ; Time Zone Component . . . . . . . . . . . . . . . . .  62
>       3.6.6.  Alarm Compo= nent . . . . . . . . . . . . . . . . . . .  71
>&n= bsp;    3.7.  Calendar Properties . . . . . . . . . = . . . . . . . . . .  76
>    &= nbsp;  3.7.1.  Calendar Scale  . . . . . . . . . . . . . = . . . . . .  76
>     &nb= sp; 3.7.2.  Method  . . . . . . . . . . . . . . . . . . . . . = . .  77
>       3.7.= 3.  Product Identifier  . . . . . . . . . . . . . . . . . = ; 78
>       3.7.4. = Version . . . . . . . . . . . . . . . . . . . . . . .  79
>     3.8.  Component Properties = . . . . . . . . . . . . . . . . . .  80
> &n= bsp;     3.8.1.  Descriptive Component Properti= es  . . . . . . . . . .  80
>  &nbs= p;      3.8.1.1.  Attachment  . . . .= . . . . . . . . . . . . . . .  80
>  &n= bsp;      3.8.1.2.  Categories  . . .= . . . . . . . . . . . . . . . .  81
>  =        3.8.1.3.  Classification = . . . . . . . . . . . . . . . . .  82
> &nbs= p;       3.8.1.4.  Comment . . . . . = . . . . . . . . . . . . . . . .  83
>  &= nbsp;      3.8.1.5.  Description . . . . .= . . . . . . . . . . . . . .  84
>  &nbs= p;      3.8.1.6.  Geographic Position . . = . . . . . . . . . . . . .  85
>   &= nbsp;     3.8.1.7.  Location  . . . . . . = . . . . . . . . . . . . . .  87
>   = ;      3.8.1.8.  Percent Complete  . = . . . . . . . . . . . . . . .  88
>  &nb= sp;      3.8.1.9.  Priority  . . . . = . . . . . . . . . . . . . . . .  89
>  &= nbsp;      3.8.1.10. Resources . . . . . . . . = . . . . . . . . . . . .  91
>   &nb= sp;     3.8.1.11. Status  . . . . . . . . . . .= . . . . . . . . . .  92
>    =      3.8.1.12. Summary . . . . . . . . . . . . . . .= . . . . . .  93
>     &n= bsp; 3.8.2.  Date and Time Component Properties  . . . . . . .= . .  94
>      &nbs= p;  3.8.2.1.  Date-Time Completed . . . . . . . . . . . . . . = .  94
>       &= nbsp; 3.8.2.2.  Date-Time End . . . . . . . . . . . . . . . . . .&n= bsp; 95
>       &nbs= p; 3.8.2.3.  Date-Time Due . . . . . . . . . . . . . . . . . . = ; 96
>         = 3.8.2.4.  Date-Time Start . . . . . . . . . . . . . . . . .  9= 7
>         3.8= .2.5.  Duration  . . . . . . . . . . . . . . . . . . . . = 99
>         3= .8.2.6.  Free/Busy Time  . . . . . . . . . . . . . . . . . 100=
>         3.8.= 2.7.  Time Transparency . . . . . . . . . . . . . . . . 101
>       3.8.3.  Time Zone C= omponent Properties  . . . . . . . . . . . 102
>&n= bsp;        3.8.3.1.  Time Zone = Identifier  . . . . . . . . . . . . . . 102
> = ;        3.8.3.2.  Time Zone Nam= e  . . . . . . . . . . . . . . . . . 103
> &n= bsp;       3.8.3.3.  Time Zone Offset= From . . . . . . . . . . . . . . 104
>  &nbs= p;      3.8.3.4.  Time Zone Offset To . . = . . . . . . . . . . . . . 105
>    =      3.8.3.5.  Time Zone URL . . . . . . . . . = . . . . . . . . . 106
>     &n= bsp; 3.8.4.  Relationship Component Properties . . . . . . . . . . = 106
>         3= .8.4.1.  Attendee  . . . . . . . . . . . . . . . . . . . . 107=
>         3.8.= 4.2.  Contact . . . . . . . . . . . . . . . . . . . . . 109
>         3.8.4.3.&nbs= p; Organizer . . . . . . . . . . . . . . . . . . . . 111
&= gt;         3.8.4.4.  Recur= rence ID . . . . . . . . . . . . . . . . . . 112
> = ;        3.8.4.5.  Related To&nb= sp; . . . . . . . . . . . . . . . . . . . 115
> &n= bsp;       3.8.4.6.  Uniform Resource= Locator  . . . . . . . . . . . . 116
>  = ;       3.8.4.7.  Unique Identifier .= . . . . . . . . . . . . . . . 117
>   &= nbsp;   3.8.5.  Recurrence Component Properties . . . . .= . . . . . . 118
>      &= nbsp;  3.8.5.1.  Exception Date-Times  . . . . . . . . . = . . . . . 118
>      &nbs= p;  3.8.5.2.  Recurrence Date-Times . . . . . . . . . . . . . = . 120
>        = 3.8.5.3.  Recurrence Rule . . . . . . . . . . . . . . . . . 122
>       3.8.6.  Alarm = Component Properties  . . . . . . . . . . . . . 132
&= gt;         3.8.6.1.  Actio= n  . . . . . . . . . . . . . . . . . . . . . 132
>=          3.8.6.2.  Repeat C= ount  . . . . . . . . . . . . . . . . . . 133
>&nb= sp;        3.8.6.3.  Trigger . .= . . . . . . . . . . . . . . . . . . . 133
>  = ;     3.8.7.  Change Management Component Prope= rties  . . . . . . . 136
>    =      3.8.7.1.  Date-Time Created . . . . . . . = . . . . . . . . . 136
>     &n= bsp;   3.8.7.2.  Date-Time Stamp . . . . . . . . . . . . = . . . . . 137
>      &nbs= p;  3.8.7.3.  Last Modified . . . . . . . . . . . . . . . . . = . 138
>        = 3.8.7.4.  Sequence Number . . . . . . . . . . . . . . . . . 138
>       3.8.8.  Miscel= laneous Component Properties  . . . . . . . . . 139
&= gt;         3.8.8.1.  IANA = Properties . . . . . . . . . . . . . . . . . 140
> = ;        3.8.8.2.  Non-Standard = Properties . . . . . . . . . . . . . 140
>  &= nbsp;      3.8.8.3.  Request Status  = . . . . . . . . . . . . . . . . . 141
>   4.&= nbsp; iCalendar Object Examples . . . . . . . . . . . . . . . . . . 144<= br>
>   5.  Recommended Practices . . . . . = . . . . . . . . . . . . . . . 147
>   6. = ; Internationalization Considerations . . . . . . . . . . . . . 148
<= /div>
>   7.  Security Considerations . . . . . . = . . . . . . . . . . . . . 148
>   8.  IA= NA Considerations . . . . . . . . . . . . . . . . . . . . . 149
>     8.1.  iCalendar Media Type Regis= tration . . . . . . . . . . . . 149
>   =   8.2.  New iCalendar Elements Registration . . . . . . . . . = . . 152
>       8.2.1.&nb= sp; iCalendar Elements Registration Procedure . . . . . . 152
<= div>>       8.2.2.  Registration T= emplate for Components  . . . . . . . . 152
> = ;      8.2.3.  Registration Template for P= roperties  . . . . . . . . 153
>   =     8.2.4.  Registration Template for Parameters&nbs= p; . . . . . . . . 153
>     &= nbsp; 8.2.5.  Registration Template for Value Data Types  . . = . . . 154
>       8.2.6.&= nbsp; Registration Template for Values  . . . . . . . . . . 154
=
>     8.3.  Initial iCalendar Ele= ments Registries . . . . . . . . . . 155
>  &= nbsp;    8.3.1.  Components Registry . . . . . . . .= . . . . . . . . . 155
>     &= nbsp; 8.3.2.  Properties Registry . . . . . . . . . . . . . . . . .= 156
>       8.3.3. = Parameters Registry . . . . . . . . . . . . . . . . . 158
>       8.3.4.  Value Data Types = Registry . . . . . . . . . . . . . . 159
>  &= nbsp;    8.3.5.  Calendar User Types Registry  = . . . . . . . . . . . . 160
>    &n= bsp;  8.3.6.  Free/Busy Time Types Registry . . . . . . . . . = . . . 160
>       8.3.7.&= nbsp; Participation Statuses Registry . . . . . . . . . . . 161
>       8.3.8.  Relationship= Types Registry . . . . . . . . . . . . . 161
> &n= bsp;     8.3.9.  Participation Roles Registry&n= bsp; . . . . . . . . . . . . 162
>   &nb= sp;   8.3.10. Actions Registry  . . . . . . . . . . . . .= . . . . . 162
>       8.= 3.11. Classifications Registry  . . . . . . . . . . . . . . 162
=
>       8.3.12. Methods Regi= stry  . . . . . . . . . . . . . . . . . . 163
>&nb= sp;  9.  Acknowledgments . . . . . . . . . . . . . . . . . . .= . . . . 163
>   10. References  . . . .= . . . . . . . . . . . . . . . . . . . . . 164
> &= nbsp;   10.1. Normative References  . . . . . . . . . . .= . . . . . . . 164
>     10.2. Info= rmative References  . . . . . . . . . . . . . . . . . 165
=
>   Appendix A.  Differences from RFC 2445  = . . . . . . . . . . . . . 167
>    = A.1.  New Restrictions  . . . . . . . . . . . . . . . . . . .= . 167
>     A.2.  Restriction= s Removed  . . . . . . . . . . . . . . . . . . 167
&g= t;     A.3.  Deprecated Features . . . . . . . = . . . . . . . . . . . . 167
> 
>&= nbsp;
> Notes
> -----
&g= t; Most of the Table Of Contents give wrong page numbers
&= gt; 
> Instructions:
> ----------= ---
> This erratum is currently posted as "Reported". I= f necessary, please
> use "Reply All" to discuss whethe= r it should be verified or
> rejected. When a decision = is reached, the verifying party
> can log in to change = the status and edit the report, if necessary.
> 
> --------------------------------------
&= gt; RFC5545 (draft-ietf-calsify-rfc2445bis-10)
> ------= --------------------------------
> Title  &nb= sp;            : = Internet Calendaring and Scheduling Core Object Specification (iCalendar= )
> Publication Date    : September 2009=
> Author(s)       &= nbsp;   : B. Desruisseaux, Ed.
> Category&nbs= p;           : PROPOSE= D STANDARD
> Source      =         : Calendaring and Scheduling = Standards Simplification
> Area    =             : App= lications
> Stream      &= nbsp;       : IETF
> Veri= fying Party     : IESG

=
_______________________________________________
=
calsify mailing list
calsify@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/calsify


Attachments:
  • signature.asc
    <= /li>

--707866e9667e420f8b06273408cfc416--