From nobody Sat Oct 3 06:58:44 2020 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 2606A3A0AB1 for ; Sat, 3 Oct 2020 06:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.213, 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=googlemail.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 G8MHIzOoErJ5 for ; Sat, 3 Oct 2020 06:58:42 -0700 (PDT) Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) (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 B4AC03A0A8D for ; Sat, 3 Oct 2020 06:58:41 -0700 (PDT) Received: by mail-ej1-x636.google.com with SMTP id lw21so1562768ejb.6 for ; Sat, 03 Oct 2020 06:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=OTWmD2iMEc3bG9bCzY96yUtFudTWdKRite6UBJYbDnE=; b=neXqCjGp7/iwJAPjDnOGMGoJYAEH3RNOrUTVNGggavG4hAOp+KaQestR2ZTc73HXnD OIj2kKfSEhpsCYZeoSgFskoOE6Jbi5N/TDyb11Bt4NG3X/aPcxw0LFxDPot5bCXu/JaH sR1aMYjWmAonmXG0sEvNhOxMFodHIRTq4doOK6FaoIjcFxRq+IenY4A7y8rHd94PpP4K mPCILXHlv85A81/D+BHmSQZZyQwC6D8u8+3K3iZHmZRVgmCGIxYUTIHGOg0hlRXr+pTy rBOD1QiAoScsqQoIDeDOcdcJzzBjWiWtyMvZfoE0covGyWvCV9WvbsVcnoKl2VlDDiMS RqaQ== 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:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=OTWmD2iMEc3bG9bCzY96yUtFudTWdKRite6UBJYbDnE=; b=bVIG5bk+HRr5oxRGpCdZ18qW2w0ouCIU2opIpgzgnEv4PN5DKl4LwUsrYdJEmQu1l+ zTFX8x+GAS3qco3+czCUpdXF7JeBkoHm5yl0GAdL1NxXfH6DWwrLca2ZnezNzi84uT+E SV8t5HRwKGJxFBwMqhuA7FIhr3W3YaC5zmMsIR8yzSIW35apL5GeC7dKf6UEqMBy0T+D cNPZPdHq2SPUh+XemFyeJdxsMkkQ4JtkuqFNR1gOUStnWBZkaHxFuLuwV0cm6JlHXMkm +LcjdWPPV0F81k+fQm0PSk6xuYdEmFLv/2e9CDk0auO3V72TSpxcVmyrq41m4Q99UPSy 0AxQ== X-Gm-Message-State: AOAM532AKgk18zJiZhZKes4wBqQ9wtigQ2WXPEUqyDj05XNSyhUb+Kef qZ520j06vxPC/UGWsGCBzdfQMZ+WyOq4Aw== X-Google-Smtp-Source: ABdhPJwU/brXDyEmpP8y3+zm1H/JIdHS4MtYGaWFb28K0JEdI8BtUKnfe2pFtKinojTWU1s371uCig== X-Received: by 2002:a17:906:a282:: with SMTP id i2mr6628114ejz.39.1601733519842; Sat, 03 Oct 2020 06:58:39 -0700 (PDT) Received: from [192.168.178.24] (ppp-46-244-251-80.dynamic.mnet-online.de. [46.244.251.80]) by smtp.gmail.com with ESMTPSA id b6sm4259227edu.21.2020.10.03.06.58.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Oct 2020 06:58:39 -0700 (PDT) From: Michael H Deckers X-Google-Original-From: Michael H Deckers To: Justin Grant , calsify@ietf.org References: Message-ID: <26802c87-aa05-ca16-8ead-6e19c2006909@googlemail.com> Date: Sat, 3 Oct 2020 13:57:56 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.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] Subtraction vs. DST disambiguation X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2020 13:58:43 -0000    On 2020-09-30 21:50, Justin Grant wrote: > We previously > agreed that, in order to make subtraction reversible with subsequent > addition of the same value, we'd reverse the order of operations so with > subtraction of a positive duration (or adding a negative duration) the time > portion would be subtracted first, and then the date portion.     If I understand you correctly, you want to ensure that          ( Δ - 1 month) + 1 month = Δ     for any date Δ.     This is impossible to achieve with the "usual" expectations,     for instance, that ( Δ - 1 month) is a date in February     when Δ is a date in March (because you have only 28 or 29     different dates in February, but 31 dates in March, so that     such a subtraction of 1 month from dates in March can never     be injective).     Of course, there are group operations on the set of dates,     such as adding and subtracting integral multiples of days     or weeks.     And on the set of datetimes (= date plus time of day), there     are group operations with multiples of formal time units such as     months so that the subtraction of 1 month maps the set of     datetimes in the interval         [2020-03-01T00:00:00..2020-04-01T00:00:00]     bijectively onto the interval         [2020-02-01T00:00:00..2020-03-01T00:00:00]     (eg, as in the subtraction of fractions of months in Oracle SQL);     but the result of such a subtraction from a date (with time of day     00:00:00) is in general no longer a date. Do you intend to     specify such an operation?     HTH.     Michael Deckers. From nobody Sun Oct 4 15:31:10 2020 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 BB24F3A0A63; Sun, 4 Oct 2020 15:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=jBoFhUZ+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jPARHUsL 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 blwNUIs-bXpV; Sun, 4 Oct 2020 15:31:04 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C9E3A0A5F; Sun, 4 Oct 2020 15:31:04 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 483D05C0049; Sun, 4 Oct 2020 18:31:03 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Sun, 04 Oct 2020 18:31:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=KgpP b9cltWrc2rhs5M2JzNl3Cpo7SbsbuktgCeFx1d8=; b=jBoFhUZ+uv4wzOWYnw7h Dsxm3cSZnvEAb5uA76tyM/rliylBAcRTMQ6/iCfagSpz5QJrggfSlqWdGM2kLhYN pYLVg67ItXpEFytlKhomC4u4dtuS8ooqEKrxGVw62exanrs6LAZ2fkTg/HHZRhqK 12NnB/Ey7yFh6M0V12/U2lIIssvCRI7CpOtS6C0gmN2QcBROZFhGfLDUoKVDWtZf OvYGfPKvMUgH8xOSAN5F9r00ylhX0cBZUMesud9NQcZaGB3SkhryN9qE9xpSIxOe ybgqHAQbji/+u7fXRBuc+7ChFVO0m/2F2H9re2QR3dneCtvp0ppFa4G6f8Ry19jT OQ== 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=fm1; bh=KgpPb9 cltWrc2rhs5M2JzNl3Cpo7SbsbuktgCeFx1d8=; b=jPARHUsLQm02pvXjPUrQqp 0Kg3Jmmb6JL3A2RQ7UrxsAkGYGK7Ts+QSfSwVQsYW2MRy1Fl1wN6AnE+Coyr/+mk sUcB2llWMgQqZd8Y/1j0PAl5CnpKdDTKyInZzHwtBWFTaKreBD4brF0jupUACWFF EKUgAkDARNtQUjMVKqJM6J3O7/0ZXTwcd3Ye39OnboLZO8YxbjjKGrC1sF4TrvZo BnyJec2VX6F96cA46gl9YLaqqBrZrFy8TmXef1odeYnGOmLQEh1Jbsoz0a6UE+ci R6mA5dt8SPn7Dg+PZX2wqmopbppdDA1SHgc0Lc1Za7ClMlfNIav3cYLD7HU4qKIw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgedugdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepheeuhfdujedtieevkedvhfffgfelfeelhfefkeehhfekleek hfefueefveffjeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 11FFE1800F9; Sun, 4 Oct 2020 18:31:02 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-382-ge235179-fm-20200928.002-ge2351794 Mime-Version: 1.0 Message-Id: <5d175fbc-1f00-4512-be45-133cfbfc782f@dogfood.fastmail.com> In-Reply-To: References: <160080310052.2067.3909191521071518854@ietfa.amsl.com> Date: Mon, 05 Oct 2020 09:30:47 +1100 From: "Neil Jenkins" To: "Barry Leiba" Cc: "Benjamin Kaduk" , iesg , "Daniel Migault" , daniel.migaultf@ericsson.com, draft-ietf-calext-jscalendar@ietf.org, calext-chairs@ietf.org, calsify@ietf.org Content-Type: multipart/alternative; boundary=ea91a45dc89a42e8b586fa2f0f4e8a9d Archived-At: Subject: Re: [calsify] =?utf-8?q?Benjamin_Kaduk=27s_Discuss_on_draft-ietf-cal?= =?utf-8?q?ext-jscalendar-30=3A_=28with_DISCUSS_and_COMMENT=29?= 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, 04 Oct 2020 22:31:09 -0000 --ea91a45dc89a42e8b586fa2f0f4e8a9d Content-Type: text/plain On Thu, 1 Oct 2020, at 00:20, Barry Leiba wrote: > I'm not sure which of Ben's suggestions (or both) you're saying "probably" to. Sorry, poor editing on my part. That was meant to be just for "Should jCal be moved to Historic?" > At this point, the *idea* is that JSCalendar would eventually supplant iCalendar, but we'll have to see how the > deployment goes before we formally say that iCalendar is no longer considered a current standard. Absolutely. Neil. --ea91a45dc89a42e8b586fa2f0f4e8a9d Content-Type: text/html
On Thu, 1 Oct 2020, at 00:20, Barry Leiba wrote:
I'm not sure which of Ben's suggestions (or both) you're saying "probably" to.

Sorry, poor editing on my part. That was meant to be just for "Should jCal be moved to Historic?"

At this point, the *idea* is that JSCalendar would eventually supplant iCalendar, but we'll have to see how the
deployment goes before we formally say that iCalendar is no longer considered a current standard.

Absolutely.

Neil.
--ea91a45dc89a42e8b586fa2f0f4e8a9d-- From nobody Sun Oct 4 15:44:54 2020 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 B1AD13A0A68 for ; Sun, 4 Oct 2020 15:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=Erfphc1V; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RgXijb90 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 s4Ae6KPnR2T0 for ; Sun, 4 Oct 2020 15:44:50 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36703A0A65 for ; Sun, 4 Oct 2020 15:44:50 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 123645C00A0; Sun, 4 Oct 2020 18:44:50 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Sun, 04 Oct 2020 18:44:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=YK/A fPrnnR3DZ1jpZo/B9tPQSrNpsWZQn8O4U1/Er10=; b=Erfphc1VECsJd7u2SOg4 d56Iug9HUVhx6Lf1ReedpzZqpLESDpAKZI7sdeAofHaam4ZIWZLEEloEwCJiOE8z u09E1w/Z4NJDvyES/FJ9G40H9c4ZtX980eD8lhmqSb+26lNx1G/cEStHCnMQeh2Q kzWSb4CzaCVWrsjg8SD6R7x5wgi9UngmuBMkjJP4MU7Pu/rfnYLPLzw2sx0zmmtN LrbwgTEOo+7RnTr/eU21oAtmiS/E5ieMELJ2pxubd76MCRqn9iW7fg5foxXNgUjK AeNhdiSevKWfZm0kHNaqyyYyEKa8a43PNV6wN1IP+sHmnU2NOI/WKqVyI7D3n88j Lw== 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=fm1; bh=YK/AfP rnnR3DZ1jpZo/B9tPQSrNpsWZQn8O4U1/Er10=; b=RgXijb90qhjDG2ORXP+TLC pchIdHQlb4vo1B0LiMNy6TH7lma1sxSA2amq7ERHjh4tJdQ3TItdIyp14jc8QOUy odF8eGhw8xth+lfbClU7W0k6Qp9ArF1Q9d25/2NWqec9CbQPSolVV5DDD4a65tOX AU5m44oYsD3wEMvAeFmLbMAXnd7Mx9zC+aDlyE/1+btVENnt9mRWcwoPQxG0ipom vHu9lsH5hxB774jqXAFgIb78ErXZGzd/MRlYCVb4dAcKfclGfDk8b/cUHAEpqBM8 EMFFWX+e2+EMQENDYFvjTjr03MFcXVgJmrR+CN7ReqQ/tmzDYObrul0iFJ5qj63A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgedugddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehuefhudejtdeive ekvdfhfffgleeflefhfeekhefhkeelkefhfeeufeevffejieenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 761101801A7; Sun, 4 Oct 2020 18:44:48 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-382-ge235179-fm-20200928.002-ge2351794 Mime-Version: 1.0 Message-Id: <6dd83e7f-bdd2-4aed-846d-566910fda683@dogfood.fastmail.com> In-Reply-To: References: <5bfd4453-e9a9-4bf4-b403-1b2f19cc790a@dogfood.fastmail.com> <6d357b96-9899-4bd3-93e0-97e147a86a4d@dogfood.fastmail.com> Date: Mon, 05 Oct 2020 09:44:13 +1100 From: "Neil Jenkins" To: "Justin Grant" Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary=f4cb4b2eeecf4d1d9f62514c84a0aeed Archived-At: Subject: Re: [calsify] =?utf-8?q?RFC_5545/JSCalendar_questions_from_ECMAScrip?= =?utf-8?q?t_TC39_=22Temporal=22_working_group?= 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, 04 Oct 2020 22:44:53 -0000 --f4cb4b2eeecf4d1d9f62514c84a0aeed Content-Type: text/plain On Wed, 30 Sep 2020, at 09:44, Justin Grant wrote: > I think this result is probably OK (because DST is weird) but I'm wondering if the difference calculation in this case should return P1D (which makes `end - start == P1D`) or P1DT1H (which would make `undo == start`). Or is there some possible algorithm which could make both comparisons true? With this example, there are two different values of D that can be added to START that both result in the same END: P1D or P1DT1H. Therefore END - START could return either of those two values. You cannot guarantee that DIFF is the same as D, because from just END and START there is insufficient information to tell you which duration value was used. > If not, then would it be better for the first comparison to work and the second to fail, or is it better for the second to work and the first to fail? I would say the second one is the important one (as we already know the first one is impossible!): > * let DIFF = END - START > * let UNDO = END - DIFF > * assert DIFF == D > ** assert UNDO == START* Neil. --f4cb4b2eeecf4d1d9f62514c84a0aeed Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, 30 Sep = 2020, at 09:44, Justin Grant wrote:
= I think this result is probably OK (because DST is weird) but I'm wonder= ing if the difference calculation in this case should return P1D (which = makes `end - start =3D=3D P1D`) or P1DT1H (which would make `undo =3D=3D= start`). Or is there some possible algorithm which could make both comp= arisons true?

Wit= h this example, there are two different values of D that can be added to= START that both result in the same END: P1D or P1DT1H. Therefore END - = START could return either of those two values. You cannot guarantee that= DIFF is the same as D, because from just END and START there is insuffi= cient information to tell you which duration value was used.

If not, then would it b= e better for the first comparison to work and the second to fail, or is = it better for the second to work and the first to fail?

I would say the second one is the important on= e (as we already know the first one is impossible!):

<= /div>
* let DIFF =3D END - START
* let UNDO =3D END -= DIFF
* assert DIFF =3D=3D D
* ass= ert UNDO =3D=3D START

Neil.
--f4cb4b2eeecf4d1d9f62514c84a0aeed-- From nobody Sun Oct 4 15:59:16 2020 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 7DDA93A0A6A for ; Sun, 4 Oct 2020 15:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=gMWacYd7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CleFvv+4 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 kIkAv0lavpYg for ; Sun, 4 Oct 2020 15:59:12 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6FFC3A0A65 for ; Sun, 4 Oct 2020 15:59:12 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1E5A25C008D for ; Sun, 4 Oct 2020 18:59:12 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Sun, 04 Oct 2020 18:59:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm3; bh=jkl3IZT OsQSqWu2x3ViiPfw+kjNAaOD51JEFlkj9F+s=; b=gMWacYd796k2JDiVo/0hNjq PbaHXN5slaMFN2ogM9Xr2jSXWZOZTMhoJ1uRxrAXdEMAU6X73Vg/bxcnlzIwvVDo OP5PeN3KdSZT9hysDCXowMEwdpi5B2uQz38fyn3gzmzOfJHk5MjVfKU8AVfq1IuZ +aCVgpbCVsRSUe0SAlh2MIQEXGOzo+Ydi3X/RYijyO/UCkMfUB4j7/qiKTF1M72Q 3TJQGpaLPWr94lSX2h1JBMBYyTex19MR/4ZeWgC4Fb3A4BD/Gmc9/G7kjn0tm9Nj 9A6jjU2yFM5zSCqq2DjeZbqw/DaGFacd48oP2Ybxdf38vEJQ7orn2mRTmQ8lNMg= = 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=fm1; bh=jkl3IZ TOsQSqWu2x3ViiPfw+kjNAaOD51JEFlkj9F+s=; b=CleFvv+4mybb6/dKFEwqCw iqVjWT8jlgcCXSFCsgP15hWP9zrrxqBuup1/P15IHJZCRZpK86lUs0/qjfgwVmw8 6cFxe2aRQFmRZFKOlSVMiH0VgwPtIecwHBO5zgT+oF22EkE9WoDtTuyp900SKyX8 S757j12XthSpswSKWWs6PTuxEL71TIr4AdTOPfKY6FZnC9IoopHr0uHowXFvjG0g LvY2CQOiuxxtdyQVhMCrcQH/fHb9YXviLbbzAcPVhZccmS9oUlxeHTlD6lLxeNj6 kfTBEpsN5APIzhyp4cywvS04/WfmDQTpljkrUI+sa+ZwitABJ23PurO35rtCEDxQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgedugddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreerjeenucfhrhhomhepfdfpvghilhculfgvnhhkihhnshdfuceonhgvihhljhesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeehuefhudejtdeive ekvdfhfffgleeflefhfeekhefhkeelkefhfeeufeevffejieenucevlhhushhtvghrufhi iigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghilhhjsehfrghsthhmrghilh htvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8743818010E; Sun, 4 Oct 2020 18:59:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-382-ge235179-fm-20200928.002-ge2351794 Mime-Version: 1.0 Message-Id: <67c65e0c-a328-4157-904b-8f3376210638@dogfood.fastmail.com> In-Reply-To: References: Date: Mon, 05 Oct 2020 09:59:11 +1100 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=e43d5ed5b1674926b40791b5f0911917 Archived-At: Subject: Re: [calsify] Subtraction vs. DST disambiguation 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, 04 Oct 2020 22:59:15 -0000 --e43d5ed5b1674926b40791b5f0911917 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Thu, 1 Oct 2020, at 07:50, Justin Grant wrote: > For example: `2020-03-09T02:30-07:00[America/Los_Angeles]` -` P1D` > The result is `2020-03-08T03:30-07:00[America/Los_Angeles]` > And if I add `P1D` to that result, I get `2020-03-09T03:30-07:00[Ameri= ca/Los_Angeles]`, which is one hour later than my original time. It's n= ot reversible. >=20 > I'm not sure there's any way to avoid this problem. We could choose to= reverse the disambiguation behavior and pick the later offset, but that= doesn't solve the reversibility problem, because we'd just get a one-ho= ur-earlier result instead of a one-hour-later one. Yes, thinking about this it seems obvious that you cannot make it fully = reversible, because around DST changes you can have: X + D =3D Z and Y + D =3D Z Therefore Z - D could be either X or Y depending on your choice of algor= ithm. For ease of implementation therefore, I'd recommend keeping the no= rmal disambiguation behaviour so at least this is consistent! > It'd also introduce interesting behavior where the same result in nomi= nal time is resolved to a different result in exact time depending on wh= ether a subtraction or an addition was being performed.=20 True. > There's also another, more obscure problem: in rare cases time zone di= scontinuities can be a full day long, e.g. Samoa's 2011 switch to opposi= te sides of the International Date Line where `2011-12-30` was skipped. = In that case, I could get into an infinite loop while subtracting `P1D` = from `2011-12-31T12:00+14:00[Pacific/Apia]` because after subtracting on= e day in nominal time, we'd add that one day right back to end up with t= he same result: noon on Dec 31. >=20 > Note that this is only an issue when subtracting full days, because su= btracting times will always use exact time.=20 >=20 > Anyone have any ideas for how we should handle this case? This is such an edge case, I'd be mainly concerned about making sure the= algorithm was well specified enough to not enter an infinite loop, with= a note to the effect it may not produce what is considered a "correct" = answer=E2=80=A6 Neil. --e43d5ed5b1674926b40791b5f0911917 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Thu, 1 Oct 2= 020, at 07:50, Justin Grant wrote:
For example: `2020-03-09T0= 2:30-07:00[America/Los_Angeles]` -` P1D`
The result is `20= 20-03-08T03:30-07:00[America/Los_Angeles]`
And if I add `P= 1D` to that result, I get `2020-03-09T03:30-07:00[America/Los_Angeles]`,= which is one hour later than my original time.  It's not reversibl= e.

I'm not sure there's any way to avoid th= is problem. We could choose to reverse the disambiguation behavior and p= ick the later offset, but that doesn't solve the reversibility problem, = because we'd just get a one-hour-earlier result instead of a one-hour-la= ter one.

Yes, thin= king about this it seems obvious that you cannot make it fully reversibl= e, because around DST changes you can have:

X + D =3D Z and
Y + D =3D Z

= Therefore Z - D could be either X or Y depending on your choice of algor= ithm. For ease of implementation therefore, I'd recommend keeping the no= rmal disambiguation behaviour so at least this is consistent!
<= div>
It'd also introduce interesting behavior where the same= result in nominal time is resolved to a different result in exact time = depending on whether a subtraction or an addition was being performed.&n= bsp;

True.

There's also another, more obscure problem: in rare c= ases time zone discontinuities can be a full day long, e.g. Samoa's 2011= switch to opposite sides of the International Date Line where `2011-12-= 30` was skipped. In that case, I could get into an infinite loop while s= ubtracting `P1D` from `2011-12-31T12:00+14:00[Pacific/Apia]` because aft= er subtracting one day in nominal time, we'd add that one day right back= to end up with the same result:  noon on Dec 31.

Note that this is only an issue when subtracting full = days, because subtracting times will always use exact time. 

Anyone have any ideas for how we should handle th= is case?

This is such an= edge case, I'd be mainly concerned about making sure the algorithm was = well specified enough to not enter an infinite loop, with a note to the = effect it may not produce what is considered a "correct" answer=E2=80=A6=

Neil.
--e43d5ed5b1674926b40791b5f0911917-- From nobody Mon Oct 5 21:53:58 2020 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 DF2903A1114 for ; Mon, 5 Oct 2020 21:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 lPZzJS8JX_E9 for ; Mon, 5 Oct 2020 21:53:56 -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 B84103A1113 for ; Mon, 5 Oct 2020 21:53:54 -0700 (PDT) Authentication-Results: mail.aegee.org/0964rIbn3391815; auth=pass (LOGIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1601960030; i=dkim+MSA-tls@aegee.org; bh=+g1TaH4RgXJZszIDmDWJ3pW+itH6oxAW9e4dV9bR4V4=; h=Subject:From:To:Date:In-Reply-To:References; b=FeoKjv63X0BfpK89HWtHWZehxkasGAC2VvUiEXSVIV8Ow0EzL8I8/ypgyiCbJy4c+ IrWZkAWwJbKc+Z36seZqdFZPJt5C8RnmBTkp6KVa9oN/RtLt5mq6Y5w7d7cIdFuZsH /DuMUWx30Lf1xVfdP1ih2G7/R9erhH2HcVVYtA66m5y0bkbswTOi/zPjFVejAq5IG8 Zooyu4WVYdY6HNOg2IKydyamq0ZcifoVHh7mWREV+GgqUUZ9PA2j0Kj9L+sJVfTli4 vWXFj2UaBswrjkeldPovKO8ecDcnLcjAXkjMIKtsu6uSRm/yy0uTRQxd88Sjl2KB24 Ce4X7LtbD9wHLTIEavsuWxTJinq4yi0prQHGCDkJ8FOlepmywPzUZlgJ80tHYTSYMk cdnb0yKHAjIZDcQQwnd1e2EGVPtzDy4SfQrEjFixStESLDhRv4U5SCv+oC5Wo+N5f2 uYORgku6PlTm6xCpTZAzogZYcuUUV3lERpIQZ9mHJ7CE8Syp6ke3HuG8wFQcUz4uoX VatKnJWwI9nYdbpA9i9CBMrxtAWjqY7+3ihCLs7PnGpnDsoMobh+od/DXD/DLooFlW R+vLqNTmOqZCu8idBO6dRbX+TQzFlIYOzTdo1Ul15CgYx640LmgglJvJqURs0kzd8T tNkFMkcH6wu0POs8MMQaZP0Q= Authentication-Results: mail.aegee.org/0964rIbn3391815; dkim=none Received: from d (87.118.146.153.topnet.bg [87.118.146.153] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id 0964rIbn3391815 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 6 Oct 2020 04:53:38 GMT Message-ID: From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: calsify@ietf.org Date: Tue, 06 Oct 2020 07:53:13 +0300 In-Reply-To: <159608014306.19132.12080107760086956798@ietfa.amsl.com> References: <159608014306.19132.12080107760086956798@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [calsify] draft-ietf-calext-subscription-upgrade-02 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, 06 Oct 2020 04:53:58 -0000 Hello, 2 Introduction > Currently clients subscribe to calendar feeds as an iCalendar file > which is often published as a resource accessible using the > unofficial 'webcal' scheme. can this be extended with: … or by opening an iCalendar file, containing the SOURCE property. Retionale: for a user to subscribe to a feed by clicking somewhere I know by now two methods: when the user clicks a webcal URL, or when the user opens iCalendar file (irrespective of the schema) that has SOURCE property. For the latter the software can do one-time import of the data, or subscribe to the feed. There is nowhere a description that webcal: and SOURCE: are supposed to do the same. 8. Link relations * subscribe-webdav-sync this is RFC 6578 * subscribe-caldav - unless this is IP based authentication, what is the difference between subscribe-caldav and subscribe-webdav-sync? I mean, unauthenticated server can be used for retrieving data from, but not for uploading, or doing scheduling. Why is it distinguished between authenticated and unauthenticated CalDAV (that use WebDAV sync), but not between authenticated and unauthenticated subscribe-webdav-sycn? Greetings Дилян В 20:35 -0700 на 29.07.2020 (ср), internet-drafts@ietf.org написа: > 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 : Calendar subscription upgrades > Author : Michael Douglass > Filename : draft-ietf-calext-subscription-upgrade-02.txt > Pages : 15 > Date : 2020-07-29 > > Abstract: > This specification updates [RFC5545] to add the value DELETED to > the > STATUS property. > > This specification also updates [RFC7240] to add the subscribe- > enhanced-get and limit preferences. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-calext-subscription-upgrade-02 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-subscription-upgrade-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-subscription-upgrade-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Mon Oct 5 23:11:57 2020 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 1BA433A119F for ; Mon, 5 Oct 2020 23:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 svFtez8T-bC4 for ; Mon, 5 Oct 2020 23:11:54 -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 B837F3A11AA for ; Mon, 5 Oct 2020 23:11:52 -0700 (PDT) Authentication-Results: mail.aegee.org/0966AtFD3408091; auth=pass (LOGIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1601964710; i=dkim+MSA-tls@aegee.org; bh=QpkwhW8AOZZkD8P2fFiGJP+urKFYmszjrKJfv/S9f0I=; h=Subject:From:To:Date:In-Reply-To:References; b=G00t2Y9CmF2ZJaGFQ/5aZssNHhV2rbXNU8wzYFwphg/FLPv2FnkAwSFtjufWgq2sO JDqbdU05AugS0KGVF9ja3V2qAprHslQa9JRMR2dqALVeT/mYRxdv16zSr87jVxUHFn dmCx8wBY8UPA5KH7qthBz0XEwCR1AkEiVXC0XDiLvZw0lLofFU6gK7Z2HL5Va56opy kOceEfK54TWNsJEwSI+vcr6IyYH744JpNEDiUR8FD26JBFqR95HtU/Mx0xonV+OvqC 9j00VzmsK80vKJ+3xgqpaTyJ4C49nK2WrYL8rS7Rvyc3sDOIiio1YXGsM7DvFn6P45 5Z0GImJgIykGeWfwsC4hGIRT/RJI+E/w4Ol1MvfTHI3wrl+DkkTECxHs8l1FJWQ+UG 1slI/8iwp3OZnp0/jtMCf9dykclsyHzS8ezPNBKLNLxIJFN3ETSpWaSdoSE7iOhMD2 Bzyu/A2IZZjQm7NL/HN12irEE5KCTXSPO44NZkEbRBVkp747+CorxzTewS4IRjGAnc e2TbVLyHz86+uq2VM1YK/OV+KRJxie7P0w7qxMgfYmXebgfDyCJLUFSj+X4eu4Z9yE uufzO8U1dyyJpKeS5MScppYO8lywH5JMiQ0cLpPlqD0zqOUXPbrkYwYYvPL0kbDygz HnrM3qockYu4o4lKVoSljkyM= Authentication-Results: mail.aegee.org/0966AtFD3408091; dkim=none Received: from d (87.118.146.153.topnet.bg [87.118.146.153] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id 0966AtFD3408091 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 6 Oct 2020 06:11:50 GMT Message-ID: <0a66c3aed23b8b1e5b2d5f11d6d37bb814f7f15e.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: calsify@ietf.org Date: Tue, 06 Oct 2020 09:10:48 +0300 In-Reply-To: <159608014306.19132.12080107760086956798@ietfa.amsl.com> References: <159608014306.19132.12080107760086956798@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5 (3.36.5-1.fc32) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [calsify] draft-ietf-calext-subscription-upgrade / STATUS: DELETED 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, 06 Oct 2020 06:11:56 -0000 Hello, it has been a while, since I have not posted here. When an announced event will eventually not happen, the publisher of the event information has two options: delete the event entirely from the calendar, or keep it with STATUS:CANCELLED. The difference between the options is nuance and there is no ultimatively right way to map the fact the event will not happen. Moreover, how to map the fact of event, which will not happen, to iCalendar, is a decision that has to taken by the publisher of the calendar and the feed-subscribers are bound to the decision, if it is HTTP DELETE. The case that an event is moved to another time, can also be mapped in two ways: • keep the old event with STATUS:CANCELLED and description pointing to the new time, creating a new iCalendar object for the new time • keep the same iCalendar object but with new DTSTART/DTEND/DURATION, making the old event disappear from its original place in the schedule. In case of a public calendars, if a person sees an event, and later does not see the event any more in the calendar, that person can question her memory. Keeping the event in the calendar with STATUS:CANCELLED will not lead in the subscribers to the feeling that the calendar server randomly deleted data due to errors. “5.1. Redefined Status property” adds as a third options: * set status to CANCELLED • set status to DELETED • remove the event from the calendar entirely. The redefined STATUS property updates the iCalendar Core Object (RFC 5545) specification irrespective of the other sections in draft-ietf- calext-subscription-upgrade, yet it does not update the iTIP (RFC 5546) constraints to say with which METHOD STATUS:DELETED can be used. draft-ietf-calext-subscription-upgrade lacks means to communicate over Enhanced GET, that the event is still in the calendar but has STATUS:DELETED. I do not see a difference between STATUS:CANCELLED and STATUS:DELETED. Or rather, I do not see when the STATUS shall be set to DELETED and when to CANCELLED on HTTP PUT (in CalDAV terms). I propose removing sections “5. Changes to the iCalendar specifications / 5.1. Redefined Status property” from draft-ietf- calext-subscription-upgrade and communicating the fact, that an announced event will not happen, using only STATUS:CANCEL. It is like publishing something in the newspaper. Once it is published, it cannot be de-published, it can only be rectified. This has the advantage, that it is not up to the publisher of a calendar to decide, whether volatile events shall be HTTP DELETEd, or get STATUS:CANCEL, but the decision is up to the subscriber of the feed (show or hide cancelled events). Greetings Дилян В 20:35 -0700 на 29.07.2020 (ср), internet-drafts@ietf.org написа: > 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 : Calendar subscription upgrades > Author : Michael Douglass > Filename : draft-ietf-calext-subscription-upgrade-02.txt > Pages : 15 > Date : 2020-07-29 > > Abstract: > This specification updates [RFC5545] to add the value DELETED to > the > STATUS property. > > This specification also updates [RFC7240] to add the subscribe- > enhanced-get and limit preferences. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-calext-subscription-upgrade/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-calext-subscription-upgrade-02 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-subscription-upgrade-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-subscription-upgrade-02 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Tue Oct 6 17:14:02 2020 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 AE5363A1576 for ; Tue, 6 Oct 2020 17:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=fastmailteam.com header.b=kenTcmvW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QVugQ9Vd 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 iBYOSj-Z5G57 for ; Tue, 6 Oct 2020 17:13:59 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8313A1575 for ; Tue, 6 Oct 2020 17:13:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id C9832A8F for ; Tue, 6 Oct 2020 20:13:57 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Tue, 06 Oct 2020 20:13:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=sDGYyF3aSuEqkJ2Jfgl8U+fqZT6HqEs8eN4hNTN OlRY=; b=kenTcmvWNCwJEC4GEM/VYyaL6B0RpMn3cN+MpNNf+avpdV4BgH8me2K wZybpxG/bOfQxSVnlH6YzFkJdwDGhI0tNl/YTG1iBNq4MvRikN1qTlnGjwozTLfb GNPY9AuFIDklJx9alV4ri4mcDkXlxrwvAqqcxnEqmbPRBJXcPtJ0a/+t4sirhXs0 zwi+pbXV4Xg/qsv9XJoc97XoPPo9hDe18CzJs2+TSgBP3Ykh1srYDOUJ9wU7LSlB SaqQsFaMYo5yYH2eWsrGmDvPRoNPmK9ie/2xpeHvHttIhASsvkFziw9ijRWoEFjA IN81Y0IWbLoo4ol0UhOjtXCpS8WsbaA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=sDGYyF3aSuEqkJ2Jfgl8U+fqZT6Hq Es8eN4hNTNOlRY=; b=QVugQ9VdI1vJivPrxQ+ShIvyPPMiMmVT44DFjbM5mEOwp CNXGD8eoUKjyPMv4S7KmzldRXSFUIiW0RMtH/8m4CRdnL5Tzv46WZh2E7k29mwGU owJgELJ1cL/ENnHFF9cjmvH39mdfYiKrFPoivzLkQ5H/T9Y9vlw//BcTDC5L8e5M NFmdmiwLVv5lDc8wSYbiB4wyn54lkmAqhTDwmFTqlLkrmuOmvV7MrWqCkpH2oNDq ABioMCA/rnO78U9JaSko3pqW3p8LKQAQmYF6p1zFaX6tc3VLbQEIg1WtVdMG6lPq WI5XieZLvlE2GyKy+tcLd/ZxwqsZIP58KN3Swg92Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgeehgdefudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesrgdtreerre erjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnheptdeujeeivdetgeevgf dtudfgueehueelfeeujeffkeeghffhhfffgfdvveehhedtnecuffhomhgrihhnpehtihhm vggrnhguuggrthgvrdgtohhmpdiiohhomhdruhhsnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghm rdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 93BFF180106; Tue, 6 Oct 2020 20:13:56 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-407-g461656c-fm-20201004.001-g461656c6 Mime-Version: 1.0 Message-Id: <192f774a-e06a-4760-b9e8-29f8f77dc0f5@dogfood.fastmail.com> Date: Wed, 07 Oct 2020 11:13:36 +1100 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=cab8d7c8fab7475a82c479a4d5bd92d4 Archived-At: Subject: [calsify] =?utf-8?q?Interim_draft_review_during_CalConnect_next_?= =?utf-8?q?week_=282020-10-15T05=3A00=3A00Z=29?= 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, 07 Oct 2020 00:14:01 -0000 --cab8d7c8fab7475a82c479a4d5bd92d4 Content-Type: text/plain Apologies for the late notice on this! I've asked for the first hour of the final day of CalConnect for a review of our drafts. It's next week: https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=10&day=15&hour=5&min=0&sec=0&p1=152&p2=179 So that's 1am US Eastern, 6am UK, 7am Europe, 4pm Melbourne. All on Thursday 15th. It will be hosted on zoom with this link: https://us02web.zoom.us/j/4574164360 I have requested a session in datatracker, but I'm aware that I've given less notice that I'm supposed to for that. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --cab8d7c8fab7475a82c479a4d5bd92d4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Apologies for the late notice on this!  I've asked fo= r the first hour of the final day of CalConnect for a review of our draf= ts.  It's next week:

So that's 1am US Eastern, 6am UK, 7a= m Europe, 4pm Melbourne.  All on Thursday 15th.

It w= ill be hosted on zoom with this link:  https://us02web.zoom.us/j/4574164360

I have requested a session in datatracker, but I'm aware that = I've given less notice that I'm supposed to for that.

Bro= n.

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

=

--cab8d7c8fab7475a82c479a4d5bd92d4-- From nobody Tue Oct 6 17:17:33 2020 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 643E73A1576; Tue, 6 Oct 2020 17:17:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160202984729.7961.10392022279756067915@ietfa.amsl.com> Date: Tue, 06 Oct 2020 17:17:27 -0700 Archived-At: Subject: [calsify] Calendaring Extensions (calext) WG Virtual Meeting: 2020-10-15 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: Wed, 07 Oct 2020 00:17:27 -0000 The Calendaring Extensions (calext) WG will hold a virtual interim meeting on 2020-10-15 from 16:00 to 17:00 Australia/Melbourne (05:00 to 06:00 UTC). Agenda: As part of the virtual CalConnect meeting, an open session to discuss the status of CALEXT drafts in advance of IETF109. Information about remote participation: https://us02web.zoom.us/j/4574164360 From nobody Tue Oct 13 19:50:03 2020 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 A0B073A1333; Tue, 13 Oct 2020 19:50:01 -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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 7VqkYaGFLidA; Tue, 13 Oct 2020 19:49:58 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 A4CF73A0D95; Tue, 13 Oct 2020 19:49:57 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09E2njTF023081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Oct 2020 22:49:49 -0400 Date: Tue, 13 Oct 2020 19:49:44 -0700 From: Benjamin Kaduk To: Neil Jenkins Cc: iesg , draft-ietf-calext-jscalendar@ietf.org, calext-chairs@ietf.org, calsify@ietf.org, Daniel Migault , daniel.migaultf@ericsson.com Message-ID: <20201014024944.GB50845@kduck.mit.edu> References: <160080310052.2067.3909191521071518854@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-jscalendar-30: (with DISCUSS and COMMENT) 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, 14 Oct 2020 02:50:02 -0000 Hi Neil, On Wed, Sep 30, 2020 at 01:36:19PM +1000, Neil Jenkins wrote: > Hi Benjamin, > > Many thanks for your detailed review. And thank you for going through the comments carefully. > > (1) I'm a bit confused by the indication that we can use linkIds to link to > > a vCard representation of a participant or location -- if I understand > > correctly that representation would occupy the "description" property of > > the linked object, > > I think I can see the cause of the confusion here. The issue is referencing links by id from a Location/Participant. It's confusing then what the "rel" property of the Link is relative to. I think this is a significant enough issue to change to embedding the Link objects in the Participant/Location rather than doing a reference to the id in the event's links property This simplifies it, and makes the "rel" clear. (So for a participant/location, you would probably use a rel="alternative" to link to a vCard, as this is an alternative representation of that object). The "rel=describedby" would be used from the top-level event's links to link to an alternative to the "description" property of the event. Looking at this text again I agree that that is the cause of my confusion. Your proposal is a fine resolution of the issue, too. Initially when I saw the changes I was concerned that it would lead to unnecessary duplication of the Link objects/content, but on further reflection it is less clear how often a given Link object would have been referenced from more than one place anyway. > > (2) Given the language in Section 1.4.7 about needing to denote on a > > per-object basis when Ids have semantic meaning outside of the object in > > which they are defined, I think we need a stronger/clearer statement in > > Section 4.2.5 that the location Ids have global semantics within a > > calendar, Section 4.4.5 that participant Ids have global semantics, > > within a calendar, etc. > > Sorry, I don't follow. They don't have global semantics; where did you get that from? Only the UID property must be globally unique, which is not of type Id anyway; for iCalendar compatibility it's just a String. To clarify this, I have rewritten this section to read: I think it is my turn to apologize -- I started writing this comment early on in my way through the document, where I was fresh from the mindset of "JMAP for calendaring". The Id type is heavily used in JMAP and I expected it to behave similarly for JSCalendar, which is not the case. That said, I think there was still some truth in my statement about (some) Ids having global (or at least broad) semantics, the way the text in the -30 was written. It had to do with the Location Ids, that you changed already while handling point (1) -- for example, the old text in §4.2.5 for location objects had a "linkIds" property with type signature "Id[Boolean]" where the Ids are link ids from the "links" property of the containing calendar object. Anyway, let's please not spend much time on this aspect, since AFAICT it is no longer relevant in the -31. > *In many places in JSCalendar a JSON map is used where the map keys are of type Id and the map values are all the same type of object. This construction represents an unordered set of objects, with the added advantage that each entry has a name (the corresponding map key). This allows for more concise patching of objects, and, when applicable, for the objects in question to be referenced from other objects within the JSCalendar object. * > > *Unless otherwise specified for a particular property, there are no uniqueness constraints on an Id value (other than, of course, the requirement that you cannot have two values with the same key within a single JSON map). For example, two JSEvent objects might use the same Ids in their respective "links" properties. Or within the same JSEvent object the same Id could appear in the "participants" and "alerts" properties. These situations do not imply any semantic connections among the objects.* > > *Nevertheless, a UUID is typically a good choice.* > > > (3) We may want to discuss the scheduleSequence semantics/usability in the > > face of a user/"participant" that has multiple clients. It seems to me > > that there is not much preventing the different clients from sending > > (different) responses that use the same sequence number > > Correct, this is how iTIP works. These properties are for storing the data needed for the existing iTIP protocol; nothing new. The sequence number is incremented when the organizer makes changes to an event. The changes are sent out to participants. Participants send responses. When a response is received, it is ignored if the sequence number is less than the sequence number of the response currently stored for that participant (as scheduleSequence) or if it's the same but the "updated" date is older than the last response stored for that participant (as scheduleUpdated). Essentially, if the user has multiple clients that aren't in sync then the most recent response will "win" unless it's responding to an older version of the event than a previously received response. Ah, I see. My bad for not digging more closely into iTIP; since this is just mapping existing semantics I will just have to be sad about its poor consistency story but not try to change it. Thanks for the explanation. > > and I'm also not sure whether the client is supposed to keep local state on what > > sequence number to use next or just to increment any value received from > > the server. > > The value is only ever incremented by the organizer. Participants respond with the sequence number of the last update from the organiser (i.e. the sequence property of the JSEvent they are responding to). > > This is all stuff specified in iTIP and I do not think needs to be, or indeed should be, explained in the JSCalendar document. Specifically, this is a description of how a scheduling protocol works, whereas JSCalendar is a data type to store information. Okay. > > (4) I strongly recommend that all the examples not reuse UUIDs for different > > things (e.g., I see "2a358cee-6489-4f14-a57f-c104db4dc2f1" as all of: > > simple event, location (FRA Airport), location (Math lab room 1), > > location (Big Auditorium), and virtualLocation (ChatMe). The Section > > 6.9 example at least rises to Discuss-level (IIUC) as inconsistent with > > the protocol requirements, since the location id is used for two > > different locations in sibling events. > > Thanks, I have updated the examples. It looks like there was probably a stray change in §6.8, since now we have a patchObject in the localizations that refers to a nonexistent virtualLocation, but other than that this looks good -- thank you! > > (6) Can we briefly discuss the use of the "/" character in time zone > > identifiers in §4.7.2? Specifically, this text: > > > > o It MUST start with the "/" character (ASCII decimal 47; also see > > Sections 3.2.19 of [RFC5545] and 3.6. of [RFC7808] for discussion > > of the forward slash character in time zone identifiers). > > > > (a) I see no discussion of the forward slash character in section 3.6 of RFC 7808. > > Indeed. The custom time zones stuff was all written by Robert and he's on holiday at the moment, but I *think* this is just referring to these RFCs for a general discussion on time zone identifiers. Reading through, I don't think either reference is necessary. I have replaced it with the following text, which is the real reason for the requirement: > > *To avoid conflict with names in the IANA Time Zone Database it MUST start with the "/" character.* That makes sense to me! > > (b) Also, Section 3.2.19 of RFC 5545 seems to basically be saying "there > > might one day be one (or more!) global registry for time zones, but we > > don't know of one and can't point you to it" ... is this really the > > semantics we want to continue to enshrine? > > Personally I pushed strongly for not allowing custom time zones and only allowing references to the IANA registry. However, Microsoft are the sole holdouts (that I am aware of) who use their own time zone database rather than the IANA one, and it was considered likely to hinder its eventual adoption everywhere if we did this. (Of course, the flip side is that now everyone has to at least countenance the possibility of custom time zones in code handling JSCalendar, even if it's just to ignore them and treat anything with one as floating time). Indeed. > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > If this is "successor to iCalendar", is an Obsoletes: relationship > > appropriate? > > > > What is the status of jCal (RFC 7265) now that this work is published? > > Should jCal be moved to Historic? > > Probably. How is this done? (I think Barry covered this. I agree with him that obsoleting iCalendar is probably premature at this point.) > > Section 1 > > > > o The data model should be compatible with the iCalendar data format > > [RFC5545] [RFC7986] and extensions, but the specification should > > add new attributes where the iCalendar format currently lacks > > expressivity, and drop seldom-used, obsolete, or redundant > > > > Should this perhaps be downgraded to "generally compatible", since we go > > on to discuss specific areas of incompatibility? > > Sure, done. > > > Section 1.3 > > > > If we're going to use JMAP as justification for (e.g.) the "A[B]" > > notation, should we mention our underlying inspiration as stemming from > > JMAP, somewhere? (I have similar sentiments to the gen-art reviewer, > > and apparently did not pay close enough attention to the change when it > > happened in JMAP, which was possibly introduced as a result of my > > comments on draft-ietf-jmap-core-14...) > > We can, but I don't really see how it aids the reader's comprehension to refer them to another document with the same definition? I wasn't thinking we needed to cite JMAP for specifically the "A[B]" notation, but rather a brief note early in the introduction that many of the concepts used in JSCalendar are inspired by JMAP. (Assuming that's actually true, of course...) > > Section 1.4.3 > > > > This is a string in [RFC3339] "date-time" format, with the further > > restrictions that any letters MUST be in uppercase, the time > > > > Just to check: this means that in general we expect implementations to > > reject as malformed strings that use lowercase 't' or 'z'? > > This would be malformed, yes. Forcing a single representation for any particular date-time (the same reason you can't have trailing zeros) makes equality testing much easier and we've found generally helps reduce bugs. Yes! We are quite familiar with this situation in the security community :) > > component MUST be included and the time offset MUST be the character > > "Z". [...] > > > > (nit) AFAICT including the time component is already required just by > > using the "date-time" construction, since the "full-time" part is not > > optional. > > True, I will drop this superfluous statement. > > > Section 1.4.4 > > > > A time zone may have a period of discontinuity, for example a change > > from standard time to daylight-savings time. When converting local > > date-times that fall in the discontinuity to UTC, the offset before > > the transition is used. > > > > Does this mean that there are certain instants in time that are > > un-representable in this format in that timezone? (Presumably UTC could > > still be used to represent that absolute time if needed, though that > > seems slightly at odds with the general goal of being able to use local > > time for local events.) > > Correct (and yes, you can use UTC to specify something in those times). The alternative would be to store an offset with the date time. At that point you are effectively encoding an absolute time, so might as well use UTC. This also means the dates remain easily compatible with iCalendar, which also does not offer a way to specify the other offset within an overlapping time zone discontinuity. Sure. I think this is a good tradeoff to make; I just wanted to check that I was understanding properly! > > Section 1.4.5 > > > > If we are not going to require that (e.g.) the specified seconds value > > is not more than 60, we may want to put in some security considerations > > about handling such nominally out-of-range values. > > > > duration = "P" (dur-cal [dur-time] / dur-cal / dur-time) > > > > The middle "dur-cal" seems redundant to me. > > Indeed it is, I've removed it. > > > 1. Add any week or day components of the duration to the date. > > > > A week is always 7 days, even if a day is not always 24 hours, right? > > Yes, I've added an explicit statement to this effect to clarify. > > > Section 1.4.7 > > > > Unless otherwise specified, Ids are arbitrary and only have meaning > > within the object where they are being used. Ids need not be unique > > > > Letting the Id be non-unique across objects seems to be a substantial > > divergence from JMAP > > I don't agree with this statement. JMAP ids must be unique within a very specific context: the `(accountId,Type)` tuple. You may have the same id for another object with a different type within the same account, or of the same type within a different account. (For example, you might just have per account auto increment ids, so id "1" will come up a lot! But it's unique within an account for a particular type.) Ah, thanks for pointing out clearly that the JSCalendar Ids are inherently given out to multiple accounts; I had missed that. > > and the discussion in the document doesn't help me > > understand the motivation for that divergence. (If we said something > > along the lines of "JSCalendar's uid is more analogous to the JMAP Id > > than the JSCalendar Id is", that would have helped.) > > It's still different; UIDs need to be globally unique (so if you see the same UID in two different accounts it MUST refer to the same event). > > > What goes wrong if we try to use the RFC 8620 semantics ("[t]he id of a record is immutable > > and assigned by the server. > > There is no server here. This is a data format. JMAP calendars (currently being drafted ) will provide a JMAP interface to calendar data using the JSCalendar format. This will assign JMAP ids, but this will be a separate property and may be different to the UID (which may not even be a valid JMAP id). > > > I would also appreciate some indication of whether the Id is always > > server-assigned, in this section. > > As mentioned in response to your second DISCUSS point, I have now rewritten this, and I hope this is now clearer. I remain puzzled as to what server you are referring to. > ** And rightly so. I must have still been in JMAP mindset while reading/writing this and didn't catch it in my review pass. Sorry for the noise and confusion. > > Section 1.4.8 > > > > The first three items in this list seem semantically equivalent to those > > in RFC 8620 for the JMAP PatchObject; would it make sense to reuse the > > text verbatim? (Similarly for the "value associated with each pointer" > > text.) > > Yes, might as well; I have updated this. > > > A PatchObject does not define its own "@type" property. A "@type" > > property in a patch MUST be handled as any other patched property > > value. > > > > A forward reference for "@type" might be in order (at least, in the > > absence of a reference to JMAP as inspiration in the introductory > > material). > > Added. > > > Section 1.4.9 > > > > By default, time zones in JSCalendar are identified by their names in > > the IANA Time Zone Database [TZDB], and the zone rules of the > > respective zone records apply. > > > > Implementations MAY embed the definitions of custom time zones in the > > "timeZones" property (see Section 4.7.2). > > > > The wording about "by default" leaves me wondering if the custom time > > zones are allowed to override IANA TZDB time zones. > > This has been rewritten in response to other feedback. > > > Section 1.4.10 > > > > Keys in the set MUST be one of the following values, or specified > > in the property definition where the Relation object is used, or a > > value registered in the IANA JSCalendar Enum Registry, or a > > vendor-specific value: > > > > (side note) I'd consider reiterating that "vendor-specific values" > > require the domain-name-plus-colon prefix, > > I have added a reference to the vendor-specific values section to each of these places. > > > The value for each key in the set MUST be true. > > > > We have similar language in §4.2.5 describing locationTypes, where we > > refer to it as a "map" rather than a "set"; it might be good to use > > consistent terminology. > > I've changed these all to "map". Thanks! > > Section 3.2 > > > > Considering this, the definition of equivalence and normalization is > > left to client and server implementations and to be negotiated by a > > calendar exchange protocol or defined elsewhere. > > > > Did we consider providing well-written specifications for a few "common > > options" that a consuming protocol could select from by reference, > > saving applications from needing to duplicate work in each application? > > Not yet. If we did, I think this should be a separate document. Yeah, if we don't already have a starting point, separate document sounds like the way to go. (I do think this would be worthwhile effort.) > > Section 4.1.4 > > > > The vendor of the implementation SHOULD ensure that this is a > > globally unique identifier, using some technique such as an FPI > > value, as defined in [ISO.9070.1991]. It MUST only use characters of > > an iCalendar TEXT data value (see Section 3.3.11 of [RFC5545]). > > > > [Hmm, normatively referencing iCalendar for allowed characters makes it > > hard to obsolete iCalendar as well...inlining the definition in this > > document would make it more of a "standalone" document, if that's > > desired.] > > I've dropped the character restriction here; this was for iCalendar compatibility, but we can define how to escape characters as necessary in the iCalendar-JSCalendar translation document and that simplifies this, which is worth doing. Okay. (And it sounds like we're not very close to obsoleting iCalendar anyway, so the question was perhaps moot (in the US-English sense).) > > Section 4.1.5 > > > > I think someone else asked about whether a patch that only updates > > "updated" without setting "created" is to be considered invalid; it > > might be worth reiterating that here. > > It's technically valid, if pointless. I'm unconvinced that spelling this out specifically is required (a literal reading of the spec does not forbid it, and there are other pointless patches you could make, like overriding a property to the same value). Fair enough. > > Section 4.2.10 > > > > I don't think I understand why the "http" scheme is used in the example > > categories; these feel in some sense more like URI than URL specifically. > > While, as per the spec, a URI is all that's required, a URL that links to documentation would be very useful for people encountering categories. > > > Section 4.3.2 > > > > A JSTask recurs by applying the recurrence rules to the "start" date- > > time, if defined, otherwise it recurs by the "due" date-time, if > > defined. If the task defines neither a "start" nor "due" date-time, > > it MUST NOT define a "recurrenceRules" property. > > > > I think that Phill's secdir review comment about addressing time zones > > and daylight savings could be addressed by calling out more explicitly > > here that the "start"/"due" times here have an associated time zone, and > > that when converting the recurring events into other time zones the time > > zone transitions in both the "to" and "from" time zones (if any) need to > > be taken into account. > > I think this is better in the security considerations; I've added there: > > *Events recur in the event's time zone. If the user is in a different time zone, daylight saving transitions may cause an event that normally occurs at, for example, 9am to suddenly shift an hour earlier. This may be used in an attempt to cause a participant to miss an important meeting. User agents must be careful to translate date-times correctly between time zones and may wish to call out unexpected changes in the time of a recurring event.* Thanks! > > Section 4.3.2.1 > > > > 2. Each date-time candidate is compared against all of the byX > > properties of the rule except bySetPosition. If any property in > > the rule does not match the date-time, it is eliminated. Each > > > > nit: I'd suggest clarifyint that the "it" that is eliminated is the > > date-time, not the property in the rule. > > Done. > > > Section 4.3.4 > > > > If the patch object defines the "excluded" property value to be true, > > then the recurring calendar object does not occur at the recurrence > > id date-time (like an EXDATE from iCalendar). Such a patch object > > MUST NOT patch any other property. > > > > I'd consider specifying which object the "excluded" property value would > > be defined in, as opposed to the current state which is a little vague > > (it could be anywhere). > > I've rewritten this to: > > *If the patch object defines the "excluded" property of an occurrence to be true, this occurrence is omitted from the final set of recurrences for the calendar object (like an EXDATE from iCalendar).* > > > A pointer in the PatchObject MUST be ignored if it starts with one of > > the following prefixes: > > [...] > > > > I'm not sure I understand why prodId is included in this list. It seems > > to preclude indicating that a different product was used to put in an > > override than was used to create the initial recurrence. > > The intention is that you would update the prodId of the master event while adding the recurrence override. This is because generally a client will have deserialised the whole object into an internal data structure and then reserialised it again; even if it thinks it only changed an override, there's the possibility it actually mangled something else. The prodId is primarily useful for debugging later (if you keep a log of previous versions of an event object for a while) and so you want to know which app wrote a particular version. Ah, I see. Thanks for the extra explanation. > > Also, just to check: it's intentional to allow for > > "excludedRecurrenceRules" and "excluded" to be patch-able? > > "excluded" certainly needs to be patchable (that's how you exclude an occurrence, as noted above), however "excludedRecurrenceRules" should have been on the list of disallowed prefixes; I've now added it, thanks. > > > If there is a vendor-specific or future-defined property that should get > > similar treatment, how would that fact be communicated to implementors? > > New properties are added to the property registry, which links to a definition. That description may include guidance that this property may not be overridden. > > > Section 4.3.5 > > > > Defines if this object is an overridden, excluded instance of a > > recurring JSCalendar object (see Section 4.3.4). If this property > > value is true, this calendar object instance MUST be removed from the > > occurrence expansion. The absence of this property or its default > > value false indicates that this instance MUST be included in the > > occurrence expansion. > > > > nit: I think commas around and an added word for "or the presence of its > > default value false" are in order, as the current text seems to parse to > > "the absence of its default value false". > > Done. > > > Section 4.4.3 > > > > This property MUST NOT affect the information sent to scheduled > > participants; it is only interpreted when the object is shared as > > part of a shared calendar. > > > > (Where is "shared calendar" defined?) > > So, this is where we get into the thing of this being a data format, which may be used stand-alone, but may also be used as part of a protocol (e.g. CalDAV or soon JMAP Calendars) which interpret certain properties that have little meaning in isolation. I have rewritten this to try to clarify: > > *This property MUST NOT affect the information sent to scheduled participants; it is only interpreted by protocols that share the calendar objects belonging to one user with other users.* Thanks! > > o "private": The details of the object are hidden; only the basic > > time and metadata is shared. The following properties MAY be > > shared, any other properties MUST NOT be shared: > > > > I guess the idea is that if we want to add/remove things from this list > > we'll just register a new enum value? > > Yes. > > > Section 4.4.4 > > > > Represents methods by which participants may submit their RSVP > > response to the organizer of the calendar object. The keys in the > > > > Given that we don't seem to define a direct analogue for the iCalendar > > RSVP parameter (at least, not that mentions that name), it seems that we > > are falling back on the "native english" (er, French?) meaning of the > > term, in which case it's perhaps debatable about whether "RSVP response" > > adds anything over just "response". > > Agreed, I've cut RSVP. > > > o "web": Opening this URI in a web browser will provide the user > > with a page where they can submit a reply to the organizer. > > > > Are we in a position where we could mandate the "https" scheme here? > > I think we can actually, given this is not a property that needs to be backwards compatible (it doesn't have a representation in iCalendar); I've done this. Exciting! I am so used to asking and being told that we can't... > > Section 4.4.5 > > > > What kind of internal consistency checks do we expect implementations to > > do with respect to (e.g.) delegatedTo/delegatedFrom, > > memberOf/kind(group), etc.? What should one do if an inconsistency is > > found? > > I would expect checks here to be defined in a protocol using JSCalendar rather than in the format itself, because it also relates to permissions and groups. > > > Why do we need both scheduleSequence and scheduleUpdated? > > With iTIP, the sequence number is incremented by the organizer each time they modify the event. When a participant sends a response to the organizer, the response includes the sequence number of the iTIP message they are replying to, and the current time stamp on their device. The organizer will store both the sequence number and time stamp of the last response they received from a participant. This allows them to choose whether to accept or reject a response in the event that responses arrive out of order: to be accepted, the sequence number of the new response must be higher than the old response (but not higher than the organizer's sequence number!) — this is a response to an update from the organizer — or the same as the old response but with a newer updated time stamp — this is a change of response to an existing invitation. Ah, yes, I think you had explained this earlier in the response as well; I am now un-confused. > > o language: "String" (optional) > > > > The language tag as defined in [RFC5646] that best describes the > > participant's preferred language, if known. > > > > nit: RFC 5646 is BCP 47, and referencing the BCP form is probably > > preferred for future compatibility. > > I'm happy to change this reference, but am not sure how to reference the BCP. Do you have a pointer for the correct XML for this? Not particularly handy. The RFC Editor staff will know what to do, though. > > This can be used to determine whether the participant has sent a > > new RSVP following significant changes to the calendar object, and > > to determine if future responses are responding to a current or > > older view of the data. > > > > [Another case where "RSVP" might be out of place.] > > Changed to response again. > > > Servers MUST only add or change this property when they send a > > scheduling message to the participant. Clients SHOULD NOT change > > > > Send, but not receive? > > I believe that's correct; this is the status of the messages the server has sent. > > > Thank you for specifying this explicitly! > > > > An "AbsoluteTrigger" object has the following properties: > > [...] > > * when: "UTCDateTime" (mandatory). > > > > Why can absolute triggers not be in local time even when event start/end > > times can be in local time? > > Firstly for compatibility with iCalendar (which only allows UTC), but mainly because no one has expressed a need. Almost all alerts will be relative triggers, which already relative to a local time. AbsoluteTrigger events are (currently, and I expect going forward) almost solely used for snoozing alerts: you dismiss the relative one and create an absolute one for the point in the future it has been snoozed to. This does not require local time support, UTC only is fine. This is extendable should someone come forward with a use case later. Makes sense. > > (Can alerts be part of recurrence rules?) > > You can override the alerts for a specific occurrence with the standard recurrenceOverrides mechanism. > > > For a recurring calendar object, the "acknowledged" property of > > the parent object MUST be updated, unless the alert is already > > overridden in the "recurrenceOverrides" property. > > > > I'm not 100% sure I understand what the parent/child relationship being > > referred to is, here. My current guess is that there's a main > > "recurrence rule" object that's treated as the parent for a given object > > (in this case, alert) instance, but that may change as I keep reading... > > I've attempted to clarify: > > *For a recurring calendar object, setting the "acknowledged" property MUST NOT add a new override to the "recurrenceOverrides" property. If the alert is not already overridden, the acknowledged property MUST be set on the alert in the master event/task.* Thanks, I think that helps. (And my apologies for not updating this comment in my editing pass over my notes; I'm pretty sure that I had a better idea by the end than what this comment implies.) > > Section 4.6.1 > > > > Are there ever cases where the burden of carrying around a lot of > > localizations in-band with the calendar/objects becomes burdonsome, and > > it would be convenient to make localizations remote resources thare are > > only retrieved on clients that need them? (E.g., if a given object is > > localized into many different locales.) > > This property is really there for when you explicitly want it in-band. If wanted out of band, you could link to an alternate representation with the links property, but generally the user will have sourced the file from a locale-specific feed in the first place. > > > object is set to the language tag. All pointers for patches MUST end > > with one of the following suffixes; any patch that does not follow > > this MUST be ignored unless otherwise specified in a future RFC: > > > > Any RFC at all (including Independent Stream), or specifically an RFC > > that updates this one? > > Independent stream RFCs may document new properties (added to the registry) and may want to allow them to be localized without using one of these suffixes. > > > o At least one other property in the same JSCalendar object MUST > > reference a time zone using this identifier (i.e., orphaned time > > zones are not allowed). > > > > Will maintaining this invariant become burdensome if a calendar needs to > > be "subsetted" (e.g., when redistributing "private" events)? > > If removing private events from a collection, failing to remove a custom time zone that is only used by the private events may leak private information. I agree. If it's a lot of work to do the removal, then somebody might get lazy and skip it, incurring the potential privacy leak. So knowing how much work it is to uphold the invariant could inform some of the design choices here. (Not that I am proposing to revisit those choices, mind you! I was just hoping to get a sense for how sensitive the trade-off of implementation complexity/privacy benefits is.) > > o offsetTo: "String" (mandatory) > > [...] > > o offsetFrom: "String" (mandatory) > > > > nit: these are not sorted alphabetically (and are in the opposite order > > as RFC 5545); is there a reason not to swap them? > > No, I've swapped them. > > > o recurrenceOverrides: "LocalDateTime[PatchObject]" (optional) > > > > Maps the RDATE properties from iCalendar. The set is represented > > as an object, with the keys being the recurrence dates. The patch > > object MUST be empty. > > > > I suggest "MUST be the empty JSON object ({})" to distinguish from JSON > > null (my initial interpretation), which would not have the desired > > semantics. > > Done. > > > o names: "String[Boolean]" (optional) > > > > Maps the TZNAME properties from iCalendar to a JSON set. The set > > is represented as an object, with the keys being the names. The > > value for each key in the set MUST be true. > > > > I wish there was a more precise definition of "TZNAME properties" > > available. Are these supposed to be the "tznparam" or "text" (or both!) > > portions of the RFC 5545 "tzname" construction? > > I believe this is just meant to be the text; params are ignored. I have added a clarification. > > > Section 5.1.2 > > > > Should we say something about the conceptual "end" of the JSEvent being > > at "start" + "duration", or is that too banal? (We do reference the > > "end" in a couple other places.) > > No harm in making it explicit, done. > > > Section 5.3 > > > > JSGroup supports the following common JSCalendar properties > > (Section 4): > > > > nit: any chance we could get this list sorted in the order the > > properties appear in Section 4? > > Sure. > > > Section 6.10 > > > > "uri": "https://chatme.example.com?id=1234567 " > > > > (My sense is that best practices for meeting URLs like this is to > > include some amount of randomness in the URL to make it unpredictable. > > See also https://www.w3.org/2001/tag/doc/capability-urls/ and > > draft-gont-numeric-ids-sec-considerations.) > > I mean it's not meant to be a real URL, but sure, done. > > > "replyTo": { > > "imip": "mailto:6489-4f14-a57f-c1@schedule.example.com" > > }, > > > > The local component of the email address is a substring of the UUID that > > is this meeting's location id (which itself is reused in several other > > places in this document, as previously noted), which is not necessarily > > problematic but is perhaps unusual. I'm more concerned that this is > > also the imip "sendTo" for Tom Tool, who is not an owner/chair/etc. of > > the meeting, just a regular attendee. While not forbidden by the spec, > > this seems like a highly non-representative example. I'd suggest making > > Tom's "sendTo" be just "tom@foobar.example.com" to match Zoe's. > > Sure. > > > "...": "" > > > > Is this empty string actually valid as a participant object? > > No, this is just the saying other entries have been omitted for brevity, as noted at the beginning of the Examples section. It's not necessary here though, so I've just removed it. > > > Section 7 > > > > I note that there is not much discussion of internationalization > > considerations, and arguably there should be. This is specifically > > relevant for security when it comes to "confusables" in Unicode, though > > perhaps the scope for attacks is limited in terms of which JSCalendar > > elements are presented to the user. > > I'm not sure there's much JSCalendar specific that needs to be documented here, but I've added a short comment to the Spam section: > > *Confusable unicode characters may be used to trick a user into trusting a JSCalendar file that appears to come from a known contact but is actually from a similar-looking source controlled by an attacker.* Thanks. I wouldn't be terribly surprised if there was some other minor concern outside of "known contact" but do not feel a need for either of us to spend more time thinking about it. > > Such systems must be careful to authenticate all data they receive to > > prevent them from being subverted. > > > > Authorization checks may also be appropriate in these scenarios, > > separately from authentication. > > I've added an extra note here. > > > Section 7.3 > > > > Several JSCalendar properties contain URIs as values, and processing > > these properties requires extra care. Section 7 of [RFC3986] > > discusses security risks related to URIs. > > > > It's generally my preference to specifically call out that there are > > inherent considerations with fetching remote resources referenced by > > URIs, in addition to referencing RFC 3986's security considerations as > > you already do. > > I have added another paragraph to this section: > > *Fetching remote resources carries inherent risks. Connections must only be allowed on well known ports, using allowed protocols (generally just HTTP/HTTPS on their default ports). The URL must be resolved externally and not allowed to access internal resources. Connecting to an external source reveals IP (and therefore generally location) information.* Thanks! > > Section 7.4 > > > > book contact). Misclassifications are always possible however, and > > providing a feedback mechanism for users to quickly correct this is > > advised. > > > > Based on real-world experience, I think it's important for the feedback > > mechanism to not require sending any traffic to the originator of the > > (spam) calendar event/object). > > I've just cut the word "feedback". The intention of this statement is for the user to correct local classification, certainly not to send remote feedback, which perhaps this implied. Works for me. > > Section 7.5 > > > > when updating it to avoid unexpected duplication of events. When the > > UID changes, consumers of the data may not remove the previous > > version of the event if it has a different UID. This can lead to a > > > > nit: "when the UID changes" seems redundant with "if it has a different > > UID". > > Fixed. > > > Section 8.1 > > > > Interoperability considerations: This media type provides an > > alternative to iCalendar, jCal and proprietary JSON-based > > calendaring data formats. > > > > This feels like a general statement about the calendaring ecosystem and > > not considerations for interoperability specifically within JSCalendar. > > I would have expected things more along the lines of "different > > applications may use different criteria for determining equivalence of > > objects" or "while JSCalendar is designed to avoid ambiguities as much > > as possible, when converting objects from other calendar formats to/from > > JSCalendar it is possible that differing representations for the same > > logical data might arise, or ambiguities in interpretation". > > I have updated this to: > > *While JSCalendar is designed to avoid ambiguities as much as possible, when converting objects from other calendar formats to/from JSCalendar it is possible that differing representations for the same logical data might arise, or ambiguities in interpretation. The semantic equivalence of two JSCalendar objects may be determined differently by different applications, for example where URL values differ in case between the two objects.* > > > Fragment identifier considerations: N/A > > > > I trust it is an explicit decision by the WG to not specify a fragment > > identifier structure (e.g., JSON pointer). > > No, I don't believe anyone had considered this. I think a JSON pointer fragment here makes a lot of sense; I can't see any good reason not to allow it, so I've added this. Thanks for both of these; please try to ensure that the WG has seen them as well (more than just buried in this long review thread) since at least the fragment identifier syntax potentially has long-lasting implications. > > Section 8.2 > > > > delay. It is designed to encourage vendors to document and register > > new properties they add for use cases not covered by the original > > standard, leading to increased interoperability. > > > > nit: maybe s/standard/specification/? > > Done. > > > Section 8.2.5 > > > > o Property Name: The name of the property. The property name MUST > > NOT already be registered for any of the object types listed in > > the "Property Context" field of this registration. Other object > > types MAY already have registered a different property with the > > same name. > > > > Is this MAY too strong? It seems like it would invite confusion if the > > same name was used with different semantics in different contexts (so > > guidance that this is only expected when the semantics are anlogous > > might be appropriate). > > I've expanded this to: > > *Other object types MAY already have registered a different property with the same name, however the same name SHOULD only be used when the semantics are analogous.* Thanks! > > Perhaps "[MIME]" is no longer the best reference tag for the media-types > > registry (which is now uncoupled from MIME)? > > I've changed this to [MEDIATYPES]. > > > Since the RFC 4122 UUID construction is RECOMMENDED, that probably makes > > it normative. > > RFC 5546 needs to be normative since we defer to it for iTIP METHODs. > > Likewise RFC 6047 for iMIP, RFC 7529 for several things, and RFC 7808 > > for several things. > > Done. > > I have published a revised draft incorporating the IESG feedback. Thanks! I have only one page of largely minor (just the virtualLocation Id thing isn't) comments on the -31, and will go clear my discuss now. -Ben From nobody Tue Oct 13 19:55:55 2020 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 69ABC3A1328; Tue, 13 Oct 2020 19:55:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-calext-jscalendar@ietf.org, calext-chairs@ietf.org, calsify@ietf.org, Daniel Migault , daniel.migaultf@ericsson.com X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160264415431.16518.1057616138324026764@ietfa.amsl.com> Date: Tue, 13 Oct 2020 19:55:54 -0700 Archived-At: Subject: [calsify] Benjamin Kaduk's No Objection on draft-ietf-calext-jscalendar-31: (with COMMENT) 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: Wed, 14 Oct 2020 02:55:55 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-calext-jscalendar-31: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-calext-jscalendar/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1.4.8 Where "TimeZoneId" is given as a data type, it means a "String" that is either a time zone name in the IANA Time Zone Database [TZDB] or a custom time zone identifier in the "timeZones" property (see Section 4.7.2). (nit?) I'd suggest 'custom time zone identifier defined in the "timeZones" property'. Section 4.7.1 floating time. This is either a name from the IANA Time Zone Database [TZDB] or the id of a custom time zone from the "timeZones" property (Section 4.7.2). If omitted, this MUST be presumed to be I think we probably want to say "the TimeZoneID of a custom time zone" here since there seems to only be a colloquial tie between "id" and that type. Section 4.7.2 Maps the TZNAME properties from iCalendar to a JSON set. The set is represented as an object, with the keys being the names (excluding any "tznparam" component from iCalendar). The value for each key in the map MUST be true. I suggest moving the parenthetical to being offset by a comma -- it's a normative requirement, not an aside. Section 6.8 It looks like the change in location Id for the virtualLocation entry was unintentional, since the localizations property contains a patch object that still references the old Id. (This would qualify as a Discuss-level internal inconsistency but I am confident that the right thing will happen.) Section 7 behavior within a known time window. It's transmission and storage nit: s/It's/Its/ From nobody Wed Oct 14 17:58:27 2020 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 0442C3A119E for ; Wed, 14 Oct 2020 17:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 RjgJGTNmRjcR for ; Wed, 14 Oct 2020 17:58:24 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 3BC9B3A119C for ; Wed, 14 Oct 2020 17:58:24 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id k12so193055uad.11 for ; Wed, 14 Oct 2020 17:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8NhWSEg7Pg0MQEk6s6gPlPG0wgj3Yg0Bt+oME7FghBg=; b=muRVOtoItLIMTydhWR5Z5jh8faiuxi6MxghpK2Ruib2Ef4mehi8xE0bF17Sa37QVag M7MhtaUsdO33eWPcoCSqGmtE3KqaMLJBosgBTjNFikfqlzNaE0NT3HemGNmHyeXEUsKs cd1gjfYDId566P4SCXn+3RGTgvXZrvqmAMM1y6vs6ZgzjXkJbzGmms1JYT5ftZXGtX8Y RRjhcT8oyfZN0ovi2xyz7re2DhY6ES8jm75zgXrSp61mtn+EBvcRhOzxE24ETG4wV44y ydfBByhQ2O8dXNNRTL1Qxz5CDZ+eBq2BlaKCVbuvYDfK0A60Aks5a4VO1yGrtevYni/i +SCg== 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=8NhWSEg7Pg0MQEk6s6gPlPG0wgj3Yg0Bt+oME7FghBg=; b=XBVlw1gafFNuQAJPafg/754HoO4d/lWURQzd5MvBGXlA0+edUdUeBLXEp1V6JdBETq B/HFuTTiUgS+KyrUCmNu9g51rch2+KlUP73RpSf/H5X8kKOk8K9iYG52vsCHMgzLQXz2 kZHjJK/7Zjk3mIXNQDzGgJ4Z8mpLZTMe2HwBdG6U5xmBzNkniXr5tqPWvAI7WwA544Xe RuQw841q8QvkJJUrg9nFWPrKkrzjtJTD51RfNsWYdPJuH5aGqwXXaZbl+LKs4MGnDArZ ecRcq63Nxn2yrVXpDbxxxJfpra9D0jCzubP2xyldbIvlt/h5iuDAzGdckmKrHgs6++vn Oubg== X-Gm-Message-State: AOAM531J4+///0nBSwY5WEosVGTlcDDNfGZsR+L86u5iymcWC2T2prcm sLlYbbT9AaZmutBneY/p6t1EVBVrxsJ/NRGql2YY8pZAl38= X-Google-Smtp-Source: ABdhPJzMx7pLFyslcetnF5xlmpAZjhDw5wT1kZ4wi6kVkCCQX83EfGfOZ7x4hmuWkWMIulBIBHVKc/RlyTSNGhxjfJ4= X-Received: by 2002:ab0:3a92:: with SMTP id r18mr886058uaw.42.1602723502925; Wed, 14 Oct 2020 17:58:22 -0700 (PDT) MIME-Version: 1.0 References: <160202984729.7961.10392022279756067915@ietfa.amsl.com> In-Reply-To: <160202984729.7961.10392022279756067915@ietfa.amsl.com> From: Daniel Migault Date: Wed, 14 Oct 2020 20:58:12 -0400 Message-ID: To: IETF-Calsify Content-Type: multipart/alternative; boundary="00000000000010aa8b05b1ab2570" Archived-At: Subject: Re: [calsify] Calendaring Extensions (calext) WG Virtual Meeting: 2020-10-15 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 00:58:26 -0000 --00000000000010aa8b05b1ab2570 Content-Type: text/plain; charset="UTF-8" Hi, Just as a reminder. Yours, Daniel On Tue, Oct 6, 2020 at 8:18 PM IESG Secretary wrote: > The Calendaring Extensions (calext) WG will hold > a virtual interim meeting on 2020-10-15 from 16:00 to 17:00 > Australia/Melbourne (05:00 to 06:00 UTC). > > Agenda: > As part of the virtual CalConnect meeting, an open session to discuss the > status of CALEXT drafts in advance of IETF109. > > > Information about remote participation: > https://us02web.zoom.us/j/4574164360 > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > -- Daniel Migault Ericsson --00000000000010aa8b05b1ab2570 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Just as a reminder.

Yours,=C2=A0
Daniel

On Tue, Oct 6, 2020 at 8= :18 PM IESG Secretary <iesg-s= ecretary@ietf.org> wrote:
The Calendaring Extensions (calext) WG will hold
a virtual interim meeting on 2020-10-15 from 16:00 to 17:00 Australia/Melbo= urne (05:00 to 06:00 UTC).

Agenda:
As part of the virtual CalConnect meeting, an open session to discuss the s= tatus of CALEXT drafts in advance of IETF109.


Information about remote participation:
https://us02web.zoom.us/j/4574164360

_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce


--
Daniel Migault
Ericsson
--00000000000010aa8b05b1ab2570-- From nobody Wed Oct 14 18:01:22 2020 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 528823A11A0 for ; Wed, 14 Oct 2020 18:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 H4V7cxj-Lxz1 for ; Wed, 14 Oct 2020 18:01:18 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 B24E03A119E for ; Wed, 14 Oct 2020 18:01:18 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id w25so507884vsk.9 for ; Wed, 14 Oct 2020 18:01:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=T901nV5l+PelKIiTZqrW9B+FzdDjydJ8xMXcR1M+kr8=; b=pnbxdalDz6buUsyPB7b7656xVli1KAdEP+RRBEiE5wPRUgs4o5mmzRa4aE9V3bGj4Z 5Oflb45Xu7nI1zQr4TYlvfhUBN8h+eFlWzQuNASjLn9+C9xaD7cHlhtDdjcHlRC2l9dI LwZDKrbqZ/vytWf/OefoqFYlcO5fYYv0Yszg7E0khy3EDzWXLSdubk+MchBjVveBl6xG EVgEtV0ILlk2qXicl6c8auQkIYnJaBe4PDLai7Mt1QSlTxmied51CyaBG7RICP9FG6Jr ELB3Kk1lK+SL/XbycvAC5CuowefdL381YZa678YUVZ+LOpjtV6ocwjgjS93T2dBM51MJ w69A== 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=T901nV5l+PelKIiTZqrW9B+FzdDjydJ8xMXcR1M+kr8=; b=Fb1FaaORiWl6qS3sf07GEvYx6vBMhiT/sv5rPn4L5nH2srEjuVyIwRhdvrUxI/6Mmu 9gIU2bWaRCXmJiVUC1bMIrWAEldevZs2RHl4WPHa034j0tLJCcRWQq4CawcpvWrG6m4q tcKjn2YUpeqTNz0/9sekjI7ri1WdO6SEUckx42YhwRVYLOGLpakmoKummVkc/Thr/Vvb wrXgFMJDwO9Vm+MNlt5x5TVvuLGyzcZeO8J6rGz+K9b8cSr4EbSlJwMaquUU386+ClUR LmDruclPEE2F47ORkdtbL/ZyWyGuhLKxITwloBBntRH16ZxEHVgaebGaNdgtHQy4Sy89 OtGQ== X-Gm-Message-State: AOAM5320SP/UBD9Pz9Q0hu5vlozF3T6Gp7/l2/eo9Hf610GRX3wQcTqV /Q9mTT2loMjKRngV50KQ97c9mVfvVkvy7PlZe2kboLGt0MI= X-Google-Smtp-Source: ABdhPJwl3bvuSPuxxyz4DZmTzmeuNXkHU3KYivLBo8CY7i4hZvRowv81HfwByYl5N2wzeJTz0usFheSBlj6kg8k6bng= X-Received: by 2002:a67:1e02:: with SMTP id e2mr1244584vse.40.1602723677741; Wed, 14 Oct 2020 18:01:17 -0700 (PDT) MIME-Version: 1.0 References: <192f774a-e06a-4760-b9e8-29f8f77dc0f5@dogfood.fastmail.com> In-Reply-To: <192f774a-e06a-4760-b9e8-29f8f77dc0f5@dogfood.fastmail.com> From: Daniel Migault Date: Wed, 14 Oct 2020 21:01:07 -0400 Message-ID: To: Bron Gondwana Cc: IETF-Calsify Content-Type: multipart/alternative; boundary="0000000000007c279d05b1ab2f9c" Archived-At: Subject: Re: [calsify] Interim draft review during CalConnect next week (2020-10-15T05:00:00Z) 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, 15 Oct 2020 01:01:20 -0000 --0000000000007c279d05b1ab2f9c Content-Type: text/plain; charset="UTF-8" This email may contain more information. Yours, Daniel On Tue, Oct 6, 2020 at 8:14 PM Bron Gondwana wrote: > Apologies for the late notice on this! I've asked for the first hour of > the final day of CalConnect for a review of our drafts. It's next week: > > > https://www.timeanddate.com/worldclock/meetingdetails.html?year=2020&month=10&day=15&hour=5&min=0&sec=0&p1=152&p2=179 > > So that's 1am US Eastern, 6am UK, 7am Europe, 4pm Melbourne. All on > Thursday 15th. > > It will be hosted on zoom with this link: > https://us02web.zoom.us/j/4574164360 > > I have requested a session in datatracker, but I'm aware that I've given > less notice that I'm supposed to for that. > > Bron. > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam.com > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > -- Daniel Migault Ericsson --0000000000007c279d05b1ab2f9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This email may contain more information.

Yours,
Daniel

On Tue, Oct 6, 2020 at 8:14 PM Bron Gondwana= <brong@fastmailteam.com&g= t; wrote:
Apologies for the late notice on thi= s!=C2=A0 I've asked for the first hour of the final day of CalConnect f= or a review of our drafts.=C2=A0 It's next week:


So that's 1am = US Eastern, 6am UK, 7am Europe, 4pm Melbourne.=C2=A0 All on Thursday 15th.<= br>

It will be hosted on zoom with this link:=C2=A0=C2=A0https://us02web.zoom= .us/j/4574164360

I have requested a session in datatracker, b= ut I'm aware that I've given less notice that I'm supposed to f= or that.

Bron.

--
=C2= =A0 Bron Gondwana, CEO, Fastmail Pty Ltd


_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify


--
Daniel Migault
Ericsson
--0000000000007c279d05b1ab2f9c-- From nobody Wed Oct 14 18:22:33 2020 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 17F753A11A4; Wed, 14 Oct 2020 18:22:32 -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: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <160272495197.30243.11611393517485364446@ietfa.amsl.com> Date: Wed, 14 Oct 2020 18:22:32 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-vpoll-01.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 01:22:32 -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 : VPOLL: Consensus Scheduling Component for iCalendar Authors : Eric York Cyrus Daboo Michael Douglass Filename : draft-ietf-calext-vpoll-01.txt Pages : 62 Date : 2020-10-14 Abstract: This specification introduces a new iCalendar component which allows for consensus scheduling, that is, voting on a number of alternative meeting or task alternatives. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-vpoll/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-calext-vpoll-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-vpoll-01 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 Wed Oct 14 19:14:25 2020 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 C758E3A1204; Wed, 14 Oct 2020 19:14:21 -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: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <160272806176.5813.7257323613302599199@ietfa.amsl.com> Date: Wed, 14 Oct 2020 19:14:21 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-icalendar-series-02.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 02:14:24 -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 : Support for Series in iCalendar Author : Michael Douglass Filename : draft-ietf-calext-icalendar-series-02.txt Pages : 26 Date : 2020-10-14 Abstract: This document updates [RFC5545] by defining a new repeating set of events known as a series. This differs from recurrences in that each instance is a separate entity with a parent relationship to a specified template entity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-icalendar-series/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-calext-icalendar-series-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-icalendar-series-02 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 ryzokuken@igalia.com Wed Oct 14 10:51:10 2020 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 5BE553A0F9C; Wed, 14 Oct 2020 10:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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=igalia.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 xGmz43ZksJl3; Wed, 14 Oct 2020 10:51:06 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 90A553A0F97; Wed, 14 Oct 2020 10:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=vA9T1Y7f95dcAOXQdWBZsnoBDKSwrACjXoXJGM0ztgM=; b=hdPzono4QIhgkNZ6lKRH6IRYh64rdmYqvgmvoYiyY34HrCxfglQfa/4FkpgRtWSlD8op5HtCEGe5WYNSQJlPsFfv/hQCe1E5p0JAEUlu2vCi7mRRVKUDlITr/sECG3uhiIrlHKjwEe9WmVZx0dI0pSgsGjti0Vy+Oax33IQIS0FOU4c4whPGlJzriaMAtIYxCVn0vjFjVnA2qXiuKSO5m1zrp6AHD9uEnPQEFnh7fb2ki1qvv/eEFPCRCcddzk0gG2u/QXrkYYz0fH6Qiq5r1tTSc7L+OrPA3gJKEZiuELId1AJe+2cfCJEJfhLmQNkwRi/O0Xcx3GYkt9jVeu8B9A==; Received: from [183.83.215.161] (helo=[192.168.0.110]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1kSkvO-0006k5-EE; Wed, 14 Oct 2020 19:50:54 +0200 To: Shane Carr , Ronald Tse Cc: Ken Murchison , Temporal Champions , Richard Gibson , "calsify@ietf.org" References: <1587565C-7AEC-4CA8-9EF6-B926B962D96A@ribose.com> From: Ujjwal Sharma Autocrypt: addr=ryzokuken@igalia.com; keydata= mQINBFpsLAwBEADb/gc4ouvNQQc3ZmwVAOewWuWve9xA3B/ok+DhzSx2wJ82FR5s+198Y++s oMb4VyiU0FOk6FUUBSn1OTTEB5TVW904hqczD3qLDIbZD6bL9sor1W/8ok0q3q8hr/ICyiSC 6FuTROjXOL31Hs8pob/YsNX6e5g+o7/tSb0gXH6r1Dw7DL7gRqMrMFJRoBZZOwvu75PxFRCr bJ/GfkMv5ovLO2/Oj4P3/VbM4FzHSbn4r/CD/RrL3Qwhn94CoDv0fSzsGKqESbeVYjiqREWU 4oL5PR6PbPD9RXXw/wBUqIvGuEN8lKCpxsLHhPfYA4i7+en3JRot8O+Lk3nu1qEL7ED75Zot MbHGyZ6NxRv12mtX9aVWQAy7g3xNoEh3baqEpYcAXtgbX24aTX5etL1y3Z6cUBHSUTKHlHix egmjSUEkaY/qmTTCvJUGhTU+tYGHBnh6Eibg1NVKeIXdCZBhLqp4NqrivXBQxWAnN4Y7jtCQ O+uQIptIiL1YVcQrU8D/0Y6Pl3kWo8AUd3Nu+Dd+qEJqSimrcNzIjZqoun+ADrVoufzkMT5C ELT1YsS5TH3vGn4qtvGQU+/MQDMMm4vlVlaIHtAExiNHwLQ9NsFDWN6B4vvAvGv5PBanbMJJ b9iA1mCuVZnP+q/dxGQubRY3i+RqA8pyfx03G5yFr0CMjwqbEQARAQABtCRVamp3YWwgU2hh cm1hIDxyeXpva3VrZW5AaWdhbGlhLmNvbT6JAk4EEwEIADgWIQSsOTVT+mJCZQ85wB4f07R7 g/RmIQUCXgnwfgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAf07R7g/RmITovD/0Q T+kIEIBrVppJ7dNp4Pyg1hF7O4pVlu9MI6fu95bGwmXSU5BpohYSCn33d8YwPnHZH698UC0Y Zd2FU2foynYn5XUJRaiDEynK9rmZxIB33IANLfEbxC1u1sby7n154wvk7r5kBJLesR2a/Wlb Qr6q8LMCGvWQf/IAQzOdsylwnuDeKDSLrlOI0XoGizRg9ojExOGiR8cPNnhYNM35UmXEwYXN mDkoUV3unT2dXgW2HQfhc83SlfSqB8+2bLi94LTgZm5eBQxEzbj5wFyGElIURksA8SPvXY2R 0xx24odyGQi1CO16RXcBCOtqHUaH8UnyPeHg4lRBiIarZtzbPMh4h+YBoiuD6iczfLc/II5E 8852XD9PFX8y69y98bLfSBlMz/RIjZ1An9oIgIqFMtPnt1FB5LCNoe2iOXmzA8tuSHDXzYzw GvXix5cgOma4oAqzLphG9GwxhJiOL6eOjf2VzjfZYOrduuJBsJ+60rCvURiAeHbt8ogQVHNb DKImEseQY0h0pyM7r0FRRynyEya5GUF6vdaVL4DkwHJ6OphSlF4TW12XKdBMG8APNF5tx3f+ K732lrAVnqQfTm12hQp/9mpkTQ0edpgoEW+ZWvWOGotyzyWF1uzvVHa9zwwJWvjU2tKINaKL E8x8728etREcX39GKqZWNFqJZN1L3KivQbkCDQReCgRfARAAooqzPt/mQ6vO2zn3JqA4cjVu +VuxmGuBL7VclmzYG1veTrkqOgBW1lxLSLEJLrDyfvC40RDS+QgBqmtbQ8x3ccOkcCNTMoj8 8lx5BiGUInjT6wkmRYejGsw8DuKkIWnWrrv628xZiB+fhwWxc5lu3kb5LEh9eUEDrHUhMzSy svKJlpuLd93zGGtC5KAeqZhUH1pCc0FBxbBBqy0bcfYKuRcNSO7YFHIAGRbYeQMOivhMXC2z Zq6YEdLxnAl21OQlRkv77XinSD4e2Yb7WFK0MgvQsdwLOhM5pHBcuc6MkGLm/lMM8VO8N9o6 n4QyZA5LsfhTd0kGleoII0YO9RQOLHRdiPKlvDbD1B9Mg58hQakBbJF07eAwEJq/a+LhzhW+ VHlZWNV0h9tSugSgq3nOt6wG/ftVMRILREMFUDI63+UR4PXJ++l3TNBd/5RZCmuWFoavc/Tl AcQG/aQt5Ezh9AdD0Ao+5VL2ATjNSHMxH+AnEagnx2vmJC5I+LqATfgn6CX4DzatFSA9LxZX LPiXlMGWH6JogJpIQqaHulqjfko2Mb4eHuYvdl1Wova03w1BUA/EHUnJIaGVXlV5E69ubJTm SXqEAixL6vYsljJ0fO4IxBlT71aRyrvaKW37fWG2c/csjgB25U2Y7tdWY4xA96LynAurJSRJ Jj+Urmz+Bm0AEQEAAYkEcgQYAQgAJgIbAhYhBKw5NVP6YkJlDznAHh/TtHuD9GYhBQJe6vw+ BQkBzkXfAkDBdCAEGQEIAB0WIQRMXCPh15S+uPoc6Av/592ik3N4ZAUCXgoEXwAKCRD/592i k3N4ZKvZEACQNX7g5NPdRNwl0+UXy/NK2nQVOu/0Vel9giRzHfhgjetWBTzsl2DvnMoi8VG3 sY4ztOkpERm33HHOcFKXlJ3qCZ0mjAa9+pH6IpJEvpqc4TJ6o92dB4lqJNuJQBDVsYcuM4+C hPM0LnrJgJ9/SMeuWgVrT9sXC3nuJlx0ZcKo4eW/K7t3IVc3IcXV3V0ORm5hf+W30A+SUY1F xteU+7/wccI1WfjGNC9q2e3ywVsWAVfQu5kS94QhY3S1vJJ6bfZ9zpql8IuP6MczlTkFzvo6 j7CJ5ymF+A952AoU5Mj8Z+qwAt2OCpEbMufMMdexczTbg9edzhtHWAHnX/uE4d/d9HF4VryU xpg3ZZ4mse3UJTQ8AF2vQhOXT7B5d8QI0QKeH4qmhDCrgXDoXyV107TJ6ScZkFI1MmEoyZEf cv6tTiIfn70gfNXntKdqkt7E7lqybofkDEj91qelPlnE0nRH0tDMq5xJSe1DLPPlSYdnk5Z6 2g/rXAGmzvjVlj5Uw6nw/SfTgE275tVWFA1fkMjjVJFItmmwxDu6dez7QZKYlIC2mvk7ZvUW mlUVmyauJFKVMFlrH0AxWFRwMlmyiSrcy4lN93SjlQHAx9Nt23C7OnKUC83sA+jlaHsdQb7k hqAGpgzW78ijWe45CYrmXNzRsgf59nuTWIxcZrU7ck5CugkQH9O0e4P0ZiFfghAAn/dUwP2T OIGAPsvFLEvPKecBGwJITFvm9cbPqUE26D2gOC4EyJuCJlvXfn97sYcv2/c6g5CGgkJxcjnH 3Z8z1Yzkg3JCDi78lmFsw/N3VQdSJAqLJRUeVfcsudZh+LNMPW7FRRXqUb8ZrtCrMtsrWTL7 iVy0qKmWIOBHyhJZCUIVo3GZHZFePsqMRObZlSDUekGkhJ5MNRLcZaLLBVUIMgfNIVMww11M Yk0rmk6i74EYre2+jVc8HQMjkvRb/zqZzWNsqqR+PB4f+lLMAi4E9+8AKCyN1RQa525dnhYs XxiyvPwWpddfKHbDzUSi6z70x5ry3mFx1i+OixKhv2jpqNUXG3B73xsId67gTs6eRy42/JJJ rJ2NC1y0uflJmLamPVxHPZi6h1jqcRFmq5/vvuSWvWPQbTGQeReflRbLTzfSUlOaMll3YedV 07dGKYjmLNy+1vrM/Mwa0So6kAmeYQSk5FbFcrqDHDWcv98E7pP8Kozah/ryWUtVfdGTSCXW dMecSCyuMzAteW6JRlOOOMmN92YBaULxq7ERa4cOL0Vkz5vlzGbkg2wAobgRmXP4LaBJ6kVU Qp9SUTwjwKAVF+i1Tpw38BXLtJphdIOPV1QZmK+5CPMDjGifPlyDUSdA4T6h/Nr8bTjuQUkY HEUDJZMWsP+L5v1mK7gP9mdJiJa5Ag0EXgoFEgEQALOhu272DYYvbhw6kOirE1AR6ncs0i0T wDB/YnEMkBi/J7coe51I171TLaqTb5cwhs2chRUMiIvGft96/efypDnGZnvVZh80tiBUlcI9 tckQj4A7DYlAFNfdZAVKUP+G49P9N1EB8wFnc8X/YPjFP/iB169d8YyHgfibcvZbeOkMWq70 bt4maZVWCYI6r/RkFYrlgVlO28GrURELPW/B5cf+NXg8tFvxv9MR7QEWh/VHZ3CsYq1+4p0A ZEixg0D1ynvV2LS7sqca2eHxXhzX0VXdvjCKWY468E5eYlHkyOFdsbdiGgyZB5L25y/CIeyZ sQz3unYWYZ3E4UcJFm8hgsl8YWMSYl98IORpZVQ7YII2dnwPB5aRIfJgoKl5rP/AsKLV2dzj p+6yljrA2czat1c8MWko2IO/QMpzMFmWkuZiSBwNXQuByYUF0SM10pY6faApo/wWnLyEcwPF 0hmmlj0gLkkT46zdLFxRI0kzUPX7tPKqNc2hPzyHSrKXPuqJyWnq2lvS3LxNRngiRb28mKbg GQpE/iX3whzcVs1kAAL8DaiLIKWmJ5bbYEy3DzTuysMgK2lCeqGGj3p6xczPwrJQkDQKwnwf 6KLMEA6RlbWThmC2eWxPi+TLV4/HTbvabYuOBhVd4xwZZ+WfhgYCR5XmaKknKs3D8YOv3qdv EZj/ABEBAAGJAjwEGAEIACYCGwwWIQSsOTVT+mJCZQ85wB4f07R7g/RmIQUCXur8SgUJAc5F LAAKCRAf07R7g/RmIYbHD/4rekfbk8ZY2q4/wdiH9NpfYLzFQhsylQ1Knqau4oPTFXUPY2bz 9X/LMTwj7fVGa5rtC9uuoDKnmdxq7qzItf2oO+jE6RM2nDXZWeXDubQZlFgNQOde3PvTjJxF CgMwTgFl5Ydh6HQZlgcf13BbXwdF2b1d8kI1SFMkk6dgCWQJfmcRUYrTNfv4CB5dyZvnDLBF N1tmePnUpsn6gDxigr3sXJ3TE4R+mZrYNddW/0Km3X4bMi1lD7n/tmWyLJfQpsOXxInWPT0K 5eFQ/kGWeheAoiYFTGzCnbLLYWzaMRqxfBzze+eP0Jt8tQVcm7Xr7k8GE0811JHhKtTduoX6 /UF0U2+VNdQsYLWVMag/Eb/KeHBCNruEVEcOhGl1eamDIO33fnP/7bs2M7NP+p1rE4tGxLrr oxK5HC7ZDSye7nHfROK1CUzT3ALVupyVQrC6sa4vbUhtpnB3Q2K7fH660YbG6bLaDjHRNfRJ ER5JsjGz7YJi6Snig1eyAkFMEfZym2vxUSagFbi5u5KHteWy1GuaEkPowB4/4/PKmoh7+ec7 pqSM0a9F1fsScQa5SpzGaG5BeTOBz5PPb+528NFZKtt67nHKxJKbVxortLiRjxp6FoXY2x69 8q+jogfmP5bMqkUzHcdOXLzApLyoxOgEGqS3Bn7mBR0C8aUPeowlESZUtw== Message-ID: <79a1e194-4c49-9540-9b97-21e61766347e@igalia.com> Date: Wed, 14 Oct 2020 23:20:37 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5rmTWe5BjdFxr7rtGF4piGi1VzeJ8NdIc" Archived-At: X-Mailman-Approved-At: Wed, 14 Oct 2020 20:47:46 -0700 Subject: Re: [calsify] ECMAScript Extensions to RFC 3339 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, 14 Oct 2020 17:52:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5rmTWe5BjdFxr7rtGF4piGi1VzeJ8NdIc Content-Type: multipart/mixed; boundary="jWh2tjgwrCZXXDmIMmldSTEzHfSIH5vXi" --jWh2tjgwrCZXXDmIMmldSTEzHfSIH5vXi Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Ronald, everyone! I'm trying to get this task done on the Temporal side of things. Is there any draft specification of the date format including timezones and calendars you could point us to? Also, could you give a little more context on the rationale behind not using the [Asia/Hong_Kong] timezone syntax? We've preferred the Java format so far for a lot of reasons including interoperability, but at the same time, would like to align with standards like ISO 8601-3. Ujjwal On 9/6/20 2:51 AM, 'Shane Carr' via Temporal Champions wrote: > Thanks for the info, Ronald! >=20 > Could you loop in the editors of these new draft specs (e.g. ISO 34300)= > and/or ISO/TC 154?=C2=A0 We've done a great deal of work arriving at ou= r > current state of calendar representation, including a relationship with= > the Unicode Consortium, and it would be very good to sync on the syntax= > and data model in this area. >=20 > Shane >=20 >=20 > On Sat, Sep 5, 2020 at 3:12 AM Ronald Tse > = > > wrote: >=20 > Hi Shane, >=20 > There is a new project in ISO/TC 154 called ISO 8601-3 proposed by > CalConnect last year as the third part of ISO 8601. >=20 > The syntax is as follows: >=20 > Date: {gre}2019=C2=AD-10=C2=AD-11; {jul}2019=C2=AD-10=C2=AD-11 >=20 > Time: {utc}09:30:20; {gps}09:30:20 >=20 > Datetime (Timezone): {us=C2=ADet}2019=C2=AD10=C2=AD11T09:30:20; {is= o.34200.us > =C2=ADet}2019=C2=AD-10=C2=AD-11T09:30:20 >=20 > This syntax is based on the three ISO standards under process, ISO > 34100 (reference time scales), ISO 34200 (timezones) and ISO 34300 > (calendars). >=20 > In this syntax, values can be namespaced, so for example, the ISO > 34100 value of {gps} can also be expressed as {iso.34100.gps}, whic= h > allows us to handle codes from other authorities e.g. IANA TZs. >=20 > Do would want to align syntax used? >=20 > Kind regards, > Ron >=20 > _____________________________________ >=20 > Ronald Tse > Ribose Inc. >=20 > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > This message may contain confidential and/or privileged > information.=C2=A0 If you are not the addressee or authorized to > receive this for the addressee, you must not use, copy, > disclose or take any action based on this message or any > information herein.=C2=A0 If you have received this message in > error, please advise the sender immediately by reply e-mail > and delete this message.=C2=A0 Thank you for your cooperation. > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >=20 >> On Sep 3, 2020, at 4:43 AM, Shane Carr >> > > wrote: >> >> Thank you for the responses! >> >> The "[Europe/Berlin]" suffix is already in common use, e.g. in >> Java, and numerous platforms support that syntax.=C2=A0 I feel it = would >> be smart to retain that form as-is for better interop. >> >> For additional key-value pairs, my latest thought is to have them >> use the ';' separator Ken suggested.=C2=A0 It would look like this= : >> >> 2020-05-22T07:19:35.356-04:00[Europe/Berlin];ca=3Dislamic-umalqura= ;foo=3Dbar >> >> An additional iteration would be to adopt the extensions pattern, >> similar to BCP 47, where different prefixes in the key-value >> syntax are managed by different standards bodies, and "x" >> signifies private use.=C2=A0 Since Unicode manages the calendar sy= stem >> identifiers, this form could look like: >> >> 2020-05-22T07:19:35.356-04:00[Europe/Berlin];u-ca=3Dislamic-umalqu= ra;x-foo=3Dbar >> >> Thoughts on the proposed syntax? >> >> What would you recommend as next steps? >> >> Would there be harm if TC39 moved syntax such as that shown above >> into Stage 3 (roughly equivalent to=C2=A0Draft Standard in RFC 202= 6 >> terminology)? >> >> Thanks, >> Shane >> >> P.S. We are having additional discussion on this subject in this >> GitHub issue: >> https://github.com/tc39/proposal-temporal/issues/293#issuecomment-= 685960090 >> >> On Wed, Sep 2, 2020 at 6:30 AM Ken Murchison > > wrote: >> >> >> On 9/1/20 10:55 PM, Shane Carr wrote: >> > Dear CalExt experts, >> > >> > My name is Shane and I am helping push the ECMAScript Tempor= al >> > proposal, bringing new date/time types to JavaScript.=C2=A0 = It's our >> > version of Joda Time. >> > >> > I would like your feedback on the following extensions that >> we are >> > proposing to the ISO-8601 / RFC 3339 strings outputted by >> Temporal. >> > >> > >> https://github.com/tc39/proposal-temporal/blob/main/docs/iso-s= tring-ext.md >> > >> > Of particular interest is our proposed representation of >> dates in >> > non-Gregorian calendar systems. >> >> >> If we're going to parameterize the date/time, why not use >> something more >> generic, familiar, and extensible, e.g.: >> >> 2020-05-22T07:19:35.356-04:00;tzid=3DAmerica/Indiana/Indianapo= lis;cs=3Dislamic-umalqura;foo=3Dbar >> >> or >> >> 2020-05-22T07:19:35.356-04:00[tzid=3DAmerica/Indiana/Indianapo= lis;cs=3Dislamic-umalqura;foo=3Dbar] >> >> --=20 >> Kenneth Murchison >> Senior Software Developer >> Fastmail US LLC >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify >=20 > --=20 > You received this message because you are subscribed to the Google > Groups "Temporal Champions" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to temporal-champions+unsubscribe@chromium.org > . > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/temporal-champions/CAB= xsp%3D%3D8gtf8_9R0LOwKUOsw52w5sW4Tmy4UOMYzM71dvo22WA%40mail.gmail.com > . --=20 Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, Node.js Core Collaborator and Speaker --jWh2tjgwrCZXXDmIMmldSTEzHfSIH5vXi-- --5rmTWe5BjdFxr7rtGF4piGi1VzeJ8NdIc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEETFwj4deUvrj6HOgL/+fdopNzeGQFAl+HOm0ACgkQ/+fdopNz eGTdHQ//WPBHV0jhJFKswsAnsSofseCPb+mb02OzPSLROSqLlbr3qDTJbv5u7xDX GsWGqw+BVfSLNHhlF+PUiU7gfk5wcSzV4Rj1pTtgDg/z5q2cSel/BpNQCqNBJm7B 6NUdVP04gxVgLLFrGJCdKEqjyf21/hdkbdAYAhMTp+VXyKS9e+zw6cMFjtcgpdZF WMfoYchcYjt3OfxzegTUXWOYEdNPVlGMWaS/7ZD0Fyx2lVmqDyD8Jzit3IIY0Era cLph/Kyg3VsMbY9S3JLorr8tDDKyyNqUCnGEOyWb3HtsagQwELlmJkzC4S8aImuu RT7Jsrgw057hFwIkZE40+Uk/6rS/2QA65g286ECg3XHYpQ6EucQFG03f1IKzpnIm FRHew2PIZoLsDlEbfUv+NQ23zR3sXgpEsBs9ivx5NKZ3rVliHW9i5nBDEayuuzaN YygdUHwKPfjaZSMvN8YM4WDsjHlnew/s7Vt1UfQCWXyPNgdnRmzBPBane4QIfT1b UViZgwTuoBA/WMgNFnpoA6VlVdtfaNoInr2KkxGsloSw7hNp6FPh/gaPQ4ECLHfS kRDfGfMaZVxToRjl6vVbWrK0Y38RYPvU5I8XHjjC/2RE3ubMwTMtkLeZ6tMAoatf VUWmyTGG0gVAHZcgV0Z2CJb8/bhiLCybxkZz7CNitLdXtQqySi8= =VaE0 -----END PGP SIGNATURE----- --5rmTWe5BjdFxr7rtGF4piGi1VzeJ8NdIc-- From nobody Wed Oct 14 20:47:52 2020 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 B53A93A0C45 for ; Wed, 14 Oct 2020 11:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.213, 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=igalia.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 eXKrXWkwKTmc for ; Wed, 14 Oct 2020 11:22:32 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 39FC43A09A3 for ; Wed, 14 Oct 2020 11:22:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:From:Subject; bh=a+J7Xb11jLa6ENURZ4HtYfEEApfTuM1sfE88fGeBhGQ=; b=oaVUtIJ3ts5DjJvqGuLqNsar1sjMzk2Jsam/g8QaSjJ5oi5FW9iFAstefgJNWcrI7fGpecaKf3iH8tDWJv59JwMjycUu8JEkTcXYgMcY2oSBEsarAtbiyoeLyh+iWbbRzgyX7lQPsE7ujahQuJyEA4F1Io+2QNNsYjg8Do6dLp9HkBtIXR5zRT++8aEv35ZeNCRbNp66IyAl6yt5GM7nK8AP9bj3VLfdQLcZb4l0OUXe0tmsBjZgAEDamXUDOuBAij68h6F01FmVQbEX/f1JiE0VP2H1i6xMFszviv9P8Ks7aF91wvEe3V6GDWEyvVEffSG+ZgNbbqPVgXfEL6qJDg==; Received: from [183.83.215.161] (helo=[192.168.0.110]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1kSlPv-0002Hs-Vo; Wed, 14 Oct 2020 20:22:28 +0200 From: Ujjwal Sharma To: Shane Carr , Ronald Tse Cc: Ken Murchison , Temporal Champions , Richard Gibson , "calsify@ietf.org" References: <1587565C-7AEC-4CA8-9EF6-B926B962D96A@ribose.com> <79a1e194-4c49-9540-9b97-21e61766347e@igalia.com> Autocrypt: addr=ryzokuken@igalia.com; keydata= mQINBFpsLAwBEADb/gc4ouvNQQc3ZmwVAOewWuWve9xA3B/ok+DhzSx2wJ82FR5s+198Y++s oMb4VyiU0FOk6FUUBSn1OTTEB5TVW904hqczD3qLDIbZD6bL9sor1W/8ok0q3q8hr/ICyiSC 6FuTROjXOL31Hs8pob/YsNX6e5g+o7/tSb0gXH6r1Dw7DL7gRqMrMFJRoBZZOwvu75PxFRCr bJ/GfkMv5ovLO2/Oj4P3/VbM4FzHSbn4r/CD/RrL3Qwhn94CoDv0fSzsGKqESbeVYjiqREWU 4oL5PR6PbPD9RXXw/wBUqIvGuEN8lKCpxsLHhPfYA4i7+en3JRot8O+Lk3nu1qEL7ED75Zot MbHGyZ6NxRv12mtX9aVWQAy7g3xNoEh3baqEpYcAXtgbX24aTX5etL1y3Z6cUBHSUTKHlHix egmjSUEkaY/qmTTCvJUGhTU+tYGHBnh6Eibg1NVKeIXdCZBhLqp4NqrivXBQxWAnN4Y7jtCQ O+uQIptIiL1YVcQrU8D/0Y6Pl3kWo8AUd3Nu+Dd+qEJqSimrcNzIjZqoun+ADrVoufzkMT5C ELT1YsS5TH3vGn4qtvGQU+/MQDMMm4vlVlaIHtAExiNHwLQ9NsFDWN6B4vvAvGv5PBanbMJJ b9iA1mCuVZnP+q/dxGQubRY3i+RqA8pyfx03G5yFr0CMjwqbEQARAQABtCRVamp3YWwgU2hh cm1hIDxyeXpva3VrZW5AaWdhbGlhLmNvbT6JAk4EEwEIADgWIQSsOTVT+mJCZQ85wB4f07R7 g/RmIQUCXgnwfgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAf07R7g/RmITovD/0Q T+kIEIBrVppJ7dNp4Pyg1hF7O4pVlu9MI6fu95bGwmXSU5BpohYSCn33d8YwPnHZH698UC0Y Zd2FU2foynYn5XUJRaiDEynK9rmZxIB33IANLfEbxC1u1sby7n154wvk7r5kBJLesR2a/Wlb Qr6q8LMCGvWQf/IAQzOdsylwnuDeKDSLrlOI0XoGizRg9ojExOGiR8cPNnhYNM35UmXEwYXN mDkoUV3unT2dXgW2HQfhc83SlfSqB8+2bLi94LTgZm5eBQxEzbj5wFyGElIURksA8SPvXY2R 0xx24odyGQi1CO16RXcBCOtqHUaH8UnyPeHg4lRBiIarZtzbPMh4h+YBoiuD6iczfLc/II5E 8852XD9PFX8y69y98bLfSBlMz/RIjZ1An9oIgIqFMtPnt1FB5LCNoe2iOXmzA8tuSHDXzYzw GvXix5cgOma4oAqzLphG9GwxhJiOL6eOjf2VzjfZYOrduuJBsJ+60rCvURiAeHbt8ogQVHNb DKImEseQY0h0pyM7r0FRRynyEya5GUF6vdaVL4DkwHJ6OphSlF4TW12XKdBMG8APNF5tx3f+ K732lrAVnqQfTm12hQp/9mpkTQ0edpgoEW+ZWvWOGotyzyWF1uzvVHa9zwwJWvjU2tKINaKL E8x8728etREcX39GKqZWNFqJZN1L3KivQbkCDQReCgRfARAAooqzPt/mQ6vO2zn3JqA4cjVu +VuxmGuBL7VclmzYG1veTrkqOgBW1lxLSLEJLrDyfvC40RDS+QgBqmtbQ8x3ccOkcCNTMoj8 8lx5BiGUInjT6wkmRYejGsw8DuKkIWnWrrv628xZiB+fhwWxc5lu3kb5LEh9eUEDrHUhMzSy svKJlpuLd93zGGtC5KAeqZhUH1pCc0FBxbBBqy0bcfYKuRcNSO7YFHIAGRbYeQMOivhMXC2z Zq6YEdLxnAl21OQlRkv77XinSD4e2Yb7WFK0MgvQsdwLOhM5pHBcuc6MkGLm/lMM8VO8N9o6 n4QyZA5LsfhTd0kGleoII0YO9RQOLHRdiPKlvDbD1B9Mg58hQakBbJF07eAwEJq/a+LhzhW+ VHlZWNV0h9tSugSgq3nOt6wG/ftVMRILREMFUDI63+UR4PXJ++l3TNBd/5RZCmuWFoavc/Tl AcQG/aQt5Ezh9AdD0Ao+5VL2ATjNSHMxH+AnEagnx2vmJC5I+LqATfgn6CX4DzatFSA9LxZX LPiXlMGWH6JogJpIQqaHulqjfko2Mb4eHuYvdl1Wova03w1BUA/EHUnJIaGVXlV5E69ubJTm SXqEAixL6vYsljJ0fO4IxBlT71aRyrvaKW37fWG2c/csjgB25U2Y7tdWY4xA96LynAurJSRJ Jj+Urmz+Bm0AEQEAAYkEcgQYAQgAJgIbAhYhBKw5NVP6YkJlDznAHh/TtHuD9GYhBQJe6vw+ BQkBzkXfAkDBdCAEGQEIAB0WIQRMXCPh15S+uPoc6Av/592ik3N4ZAUCXgoEXwAKCRD/592i k3N4ZKvZEACQNX7g5NPdRNwl0+UXy/NK2nQVOu/0Vel9giRzHfhgjetWBTzsl2DvnMoi8VG3 sY4ztOkpERm33HHOcFKXlJ3qCZ0mjAa9+pH6IpJEvpqc4TJ6o92dB4lqJNuJQBDVsYcuM4+C hPM0LnrJgJ9/SMeuWgVrT9sXC3nuJlx0ZcKo4eW/K7t3IVc3IcXV3V0ORm5hf+W30A+SUY1F xteU+7/wccI1WfjGNC9q2e3ywVsWAVfQu5kS94QhY3S1vJJ6bfZ9zpql8IuP6MczlTkFzvo6 j7CJ5ymF+A952AoU5Mj8Z+qwAt2OCpEbMufMMdexczTbg9edzhtHWAHnX/uE4d/d9HF4VryU xpg3ZZ4mse3UJTQ8AF2vQhOXT7B5d8QI0QKeH4qmhDCrgXDoXyV107TJ6ScZkFI1MmEoyZEf cv6tTiIfn70gfNXntKdqkt7E7lqybofkDEj91qelPlnE0nRH0tDMq5xJSe1DLPPlSYdnk5Z6 2g/rXAGmzvjVlj5Uw6nw/SfTgE275tVWFA1fkMjjVJFItmmwxDu6dez7QZKYlIC2mvk7ZvUW mlUVmyauJFKVMFlrH0AxWFRwMlmyiSrcy4lN93SjlQHAx9Nt23C7OnKUC83sA+jlaHsdQb7k hqAGpgzW78ijWe45CYrmXNzRsgf59nuTWIxcZrU7ck5CugkQH9O0e4P0ZiFfghAAn/dUwP2T OIGAPsvFLEvPKecBGwJITFvm9cbPqUE26D2gOC4EyJuCJlvXfn97sYcv2/c6g5CGgkJxcjnH 3Z8z1Yzkg3JCDi78lmFsw/N3VQdSJAqLJRUeVfcsudZh+LNMPW7FRRXqUb8ZrtCrMtsrWTL7 iVy0qKmWIOBHyhJZCUIVo3GZHZFePsqMRObZlSDUekGkhJ5MNRLcZaLLBVUIMgfNIVMww11M Yk0rmk6i74EYre2+jVc8HQMjkvRb/zqZzWNsqqR+PB4f+lLMAi4E9+8AKCyN1RQa525dnhYs XxiyvPwWpddfKHbDzUSi6z70x5ry3mFx1i+OixKhv2jpqNUXG3B73xsId67gTs6eRy42/JJJ rJ2NC1y0uflJmLamPVxHPZi6h1jqcRFmq5/vvuSWvWPQbTGQeReflRbLTzfSUlOaMll3YedV 07dGKYjmLNy+1vrM/Mwa0So6kAmeYQSk5FbFcrqDHDWcv98E7pP8Kozah/ryWUtVfdGTSCXW dMecSCyuMzAteW6JRlOOOMmN92YBaULxq7ERa4cOL0Vkz5vlzGbkg2wAobgRmXP4LaBJ6kVU Qp9SUTwjwKAVF+i1Tpw38BXLtJphdIOPV1QZmK+5CPMDjGifPlyDUSdA4T6h/Nr8bTjuQUkY HEUDJZMWsP+L5v1mK7gP9mdJiJa5Ag0EXgoFEgEQALOhu272DYYvbhw6kOirE1AR6ncs0i0T wDB/YnEMkBi/J7coe51I171TLaqTb5cwhs2chRUMiIvGft96/efypDnGZnvVZh80tiBUlcI9 tckQj4A7DYlAFNfdZAVKUP+G49P9N1EB8wFnc8X/YPjFP/iB169d8YyHgfibcvZbeOkMWq70 bt4maZVWCYI6r/RkFYrlgVlO28GrURELPW/B5cf+NXg8tFvxv9MR7QEWh/VHZ3CsYq1+4p0A ZEixg0D1ynvV2LS7sqca2eHxXhzX0VXdvjCKWY468E5eYlHkyOFdsbdiGgyZB5L25y/CIeyZ sQz3unYWYZ3E4UcJFm8hgsl8YWMSYl98IORpZVQ7YII2dnwPB5aRIfJgoKl5rP/AsKLV2dzj p+6yljrA2czat1c8MWko2IO/QMpzMFmWkuZiSBwNXQuByYUF0SM10pY6faApo/wWnLyEcwPF 0hmmlj0gLkkT46zdLFxRI0kzUPX7tPKqNc2hPzyHSrKXPuqJyWnq2lvS3LxNRngiRb28mKbg GQpE/iX3whzcVs1kAAL8DaiLIKWmJ5bbYEy3DzTuysMgK2lCeqGGj3p6xczPwrJQkDQKwnwf 6KLMEA6RlbWThmC2eWxPi+TLV4/HTbvabYuOBhVd4xwZZ+WfhgYCR5XmaKknKs3D8YOv3qdv EZj/ABEBAAGJAjwEGAEIACYCGwwWIQSsOTVT+mJCZQ85wB4f07R7g/RmIQUCXur8SgUJAc5F LAAKCRAf07R7g/RmIYbHD/4rekfbk8ZY2q4/wdiH9NpfYLzFQhsylQ1Knqau4oPTFXUPY2bz 9X/LMTwj7fVGa5rtC9uuoDKnmdxq7qzItf2oO+jE6RM2nDXZWeXDubQZlFgNQOde3PvTjJxF CgMwTgFl5Ydh6HQZlgcf13BbXwdF2b1d8kI1SFMkk6dgCWQJfmcRUYrTNfv4CB5dyZvnDLBF N1tmePnUpsn6gDxigr3sXJ3TE4R+mZrYNddW/0Km3X4bMi1lD7n/tmWyLJfQpsOXxInWPT0K 5eFQ/kGWeheAoiYFTGzCnbLLYWzaMRqxfBzze+eP0Jt8tQVcm7Xr7k8GE0811JHhKtTduoX6 /UF0U2+VNdQsYLWVMag/Eb/KeHBCNruEVEcOhGl1eamDIO33fnP/7bs2M7NP+p1rE4tGxLrr oxK5HC7ZDSye7nHfROK1CUzT3ALVupyVQrC6sa4vbUhtpnB3Q2K7fH660YbG6bLaDjHRNfRJ ER5JsjGz7YJi6Snig1eyAkFMEfZym2vxUSagFbi5u5KHteWy1GuaEkPowB4/4/PKmoh7+ec7 pqSM0a9F1fsScQa5SpzGaG5BeTOBz5PPb+528NFZKtt67nHKxJKbVxortLiRjxp6FoXY2x69 8q+jogfmP5bMqkUzHcdOXLzApLyoxOgEGqS3Bn7mBR0C8aUPeowlESZUtw== Message-ID: Date: Wed, 14 Oct 2020 23:52:10 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <79a1e194-4c49-9540-9b97-21e61766347e@igalia.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="m0vrj44WFIQ9ObOjSl043rbNPrhEXd1ri" Archived-At: X-Mailman-Approved-At: Wed, 14 Oct 2020 20:47:46 -0700 Subject: Re: [calsify] ECMAScript Extensions to RFC 3339 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, 14 Oct 2020 18:22:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --m0vrj44WFIQ9ObOjSl043rbNPrhEXd1ri Content-Type: multipart/mixed; boundary="wmn3mX0mhu7B2BRHVfnMqr6EekIkBgPSJ" --wmn3mX0mhu7B2BRHVfnMqr6EekIkBgPSJ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Updating Ronald's email, it seems it got borked at some point. On 10/14/20 11:20 PM, Ujjwal Sharma wrote: > Hi Ronald, everyone! >=20 > I'm trying to get this task done on the Temporal side of things. Is > there any draft specification of the date format including timezones an= d > calendars you could point us to? Also, could you give a little more > context on the rationale behind not using the [Asia/Hong_Kong] timezone= > syntax? We've preferred the Java format so far for a lot of reasons > including interoperability, but at the same time, would like to align > with standards like ISO 8601-3. >=20 > Ujjwal >=20 > On 9/6/20 2:51 AM, 'Shane Carr' via Temporal Champions wrote: >> Thanks for the info, Ronald! >> >> Could you loop in the editors of these new draft specs (e.g. ISO 34300= ) >> and/or ISO/TC 154?=C2=A0 We've done a great deal of work arriving at o= ur >> current state of calendar representation, including a relationship wit= h >> the Unicode Consortium, and it would be very good to sync on the synta= x >> and data model in this area. >> >> Shane >> >> >> On Sat, Sep 5, 2020 at 3:12 AM Ronald Tse >> > >> wrote: >> >> Hi Shane, >> >> There is a new project in ISO/TC 154 called ISO 8601-3 proposed by= >> CalConnect last year as the third part of ISO 8601. >> >> The syntax is as follows: >> >> Date: {gre}2019=C2=AD-10=C2=AD-11; {jul}2019=C2=AD-10=C2=AD-11 >> >> Time: {utc}09:30:20; {gps}09:30:20 >> >> Datetime (Timezone): {us=C2=ADet}2019=C2=AD10=C2=AD11T09:30:20; {i= so.34200.us >> =C2=ADet}2019=C2=AD-10=C2=AD-11T09:30:20 >> >> This syntax is based on the three ISO standards under process, ISO= >> 34100 (reference time scales), ISO 34200 (timezones) and ISO 34300= >> (calendars). >> >> In this syntax, values can be namespaced, so for example, the ISO >> 34100 value of {gps} can also be expressed as {iso.34100.gps}, whi= ch >> allows us to handle codes from other authorities e.g. IANA TZs. >> >> Do would want to align syntax used? >> >> Kind regards, >> Ron >> >> _____________________________________ >> >> Ronald Tse >> Ribose Inc. >> >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> This message may contain confidential and/or privileged >> information.=C2=A0 If you are not the addressee or authorized to >> receive this for the addressee, you must not use, copy, >> disclose or take any action based on this message or any >> information herein.=C2=A0 If you have received this message in >> error, please advise the sender immediately by reply e-mail >> and delete this message.=C2=A0 Thank you for your cooperation. >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >> >>> On Sep 3, 2020, at 4:43 AM, Shane Carr >>> >> > wrote: >>> >>> Thank you for the responses! >>> >>> The "[Europe/Berlin]" suffix is already in common use, e.g. in >>> Java, and numerous platforms support that syntax.=C2=A0 I feel it= would >>> be smart to retain that form as-is for better interop. >>> >>> For additional key-value pairs, my latest thought is to have them= >>> use the ';' separator Ken suggested.=C2=A0 It would look like thi= s: >>> >>> 2020-05-22T07:19:35.356-04:00[Europe/Berlin];ca=3Dislamic-umalqur= a;foo=3Dbar >>> >>> An additional iteration would be to adopt the extensions pattern,= >>> similar to BCP 47, where different prefixes in the key-value >>> syntax are managed by different standards bodies, and "x" >>> signifies private use.=C2=A0 Since Unicode manages the calendar s= ystem >>> identifiers, this form could look like: >>> >>> 2020-05-22T07:19:35.356-04:00[Europe/Berlin];u-ca=3Dislamic-umalq= ura;x-foo=3Dbar >>> >>> Thoughts on the proposed syntax? >>> >>> What would you recommend as next steps? >>> >>> Would there be harm if TC39 moved syntax such as that shown above= >>> into Stage 3 (roughly equivalent to=C2=A0Draft Standard in RFC 20= 26 >>> terminology)? >>> >>> Thanks, >>> Shane >>> >>> P.S. We are having additional discussion on this subject in this >>> GitHub issue: >>> https://github.com/tc39/proposal-temporal/issues/293#issuecomment= -685960090 >>> >>> On Wed, Sep 2, 2020 at 6:30 AM Ken Murchison >> > wrote: >>> >>> >>> On 9/1/20 10:55 PM, Shane Carr wrote: >>> > Dear CalExt experts, >>> > >>> > My name is Shane and I am helping push the ECMAScript Tempo= ral >>> > proposal, bringing new date/time types to JavaScript.=C2=A0= It's our >>> > version of Joda Time. >>> > >>> > I would like your feedback on the following extensions that= >>> we are >>> > proposing to the ISO-8601 / RFC 3339 strings outputted by >>> Temporal. >>> > >>> > >>> https://github.com/tc39/proposal-temporal/blob/main/docs/iso-= string-ext.md >>> > >>> > Of particular interest is our proposed representation of >>> dates in >>> > non-Gregorian calendar systems. >>> >>> >>> If we're going to parameterize the date/time, why not use >>> something more >>> generic, familiar, and extensible, e.g.: >>> >>> 2020-05-22T07:19:35.356-04:00;tzid=3DAmerica/Indiana/Indianap= olis;cs=3Dislamic-umalqura;foo=3Dbar >>> >>> or >>> >>> 2020-05-22T07:19:35.356-04:00[tzid=3DAmerica/Indiana/Indianap= olis;cs=3Dislamic-umalqura;foo=3Dbar] >>> >>> --=20 >>> Kenneth Murchison >>> Senior Software Developer >>> Fastmail US LLC >>> >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >> >> --=20 >> You received this message because you are subscribed to the Google >> Groups "Temporal Champions" group. >> To unsubscribe from this group and stop receiving emails from it, send= >> an email to temporal-champions+unsubscribe@chromium.org >> . >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/temporal-champions/CA= Bxsp%3D%3D8gtf8_9R0LOwKUOsw52w5sW4Tmy4UOMYzM71dvo22WA%40mail.gmail.com >> . >=20 --=20 Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, Node.js Core Collaborator and Speaker --wmn3mX0mhu7B2BRHVfnMqr6EekIkBgPSJ-- --m0vrj44WFIQ9ObOjSl043rbNPrhEXd1ri Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEETFwj4deUvrj6HOgL/+fdopNzeGQFAl+HQdIACgkQ/+fdopNz eGQyYQ/+J3QUT3nOlpwAHdnnnXAP8Az9EZgFi6YG518WLWpfMtJeP/VjnAFJcOs7 YWe6JWKHIyuIpAsA3s5jWV+SY4fkd5Nzq4JXt0W7zGmDZjSXLxlZfBpcseJsJ09l axZxFnDv8dkw7UIkL1V5QLnKEE34TsvqFSvk/zmEj72VQF23Qj1yu+lfziBbuHhP AM8LB1luBdBMweCH4Ne7YABlmTLysabW0L3DEBR+BFjX8rUlhq7tfngo4Uru5klF cR3WbCpe1L67JBEgPg1JeMAcpaDnjM9lJ6OXTw+YsRhjcMKi7J/iN7qaUTWPUN6p R6y2y81ZO5d9QGOvlvwTKNtT3EoX9l+FpAlWk9qSQVTBU9hdSvNMdrr925IMOBNm G6O71rVKbo4Ga+HGHGKhnblf3qLQO21lpn3oPv7a9e4LMgvXtgem5mAO6+qZ7uCa uf8xougybKWHoUlXC1oGBgjSkvZ6DR3co+GCNLSarht1gK82O6XuUFW5TxNT57uT qVfGfdfhKRfmf6ZkaoIFQfBBjg9CgrvRTeKsC6LfJvJzIJKEx3i02QRQRcvxQECX AiUO+ju5tbUpl9WU6Cpe0geVQSFJiJt3w96Ai3mAJHk5tvqAIAengtFgOQWHyJOQ ITShABI/mIBAJW9tZE8ezyjTgwzZIVKgW3HYjiPCvWMfHbb7ifI= =ZWfg -----END PGP SIGNATURE----- --m0vrj44WFIQ9ObOjSl043rbNPrhEXd1ri-- From nobody Wed Oct 14 21:01:07 2020 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 37FDA3A0858; Wed, 14 Oct 2020 21:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=WyRFfuBQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KsI/NUJG 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 go1VxjZ-1BJT; Wed, 14 Oct 2020 21:01:01 -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 62C483A0869; Wed, 14 Oct 2020 21:01:01 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8D51A5C0191; Thu, 15 Oct 2020 00:01:00 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Thu, 15 Oct 2020 00:01:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=Jc8P yhFCXmRbtal/FE3pSxEuhT1BmrpUKbAnGzvfdgU=; b=WyRFfuBQ3KE9E8Smc4z/ umyz1O94rdQDfdPZswk3XlO7eGMwUOo7BQbFKZaSQFkdLuVwN3B72xwL9yK/O+Yt q89GIzyeA4rrbsoHG28Uz/kFCl8XoffVIVIe1kzAi67FfX42XGj3vNp2PhbO62pW rSnI6MfiQ6aOaVre1U4JISgSVCANrlPwnYzKZnp4OHzCR61Lj3RCrRp8QwSAwwho ASamwnYp9HpmtlpBDi9YnJLSrhsuIW7gqhMmX47rN1t+zYu/fXmbG46WooC0ISR1 gHlBS3LChws2YGmdz87QidsAxd65xQLb5RXk4A6bi+nRwyuIAPz69b2BWN0fqLs/ vw== 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=fm1; bh=Jc8Pyh FCXmRbtal/FE3pSxEuhT1BmrpUKbAnGzvfdgU=; b=KsI/NUJGA9z/qW5a0eypfw p3b7sN2lhc5TiUc/niHMjQ0Qn6o2gUF0EiQgAPxu/+NXOcnzBbKJw2RzIjWahz2s VDjIUGTzQg2uh0kKTsg1qMqr4W7GaWWpfAUbjubBaWJ54IM8rUnVf4ZVkYwraG37 Ys+JhInRsbVy6bv7wHiLELi8yPYHjKO7R26qnWgu1uY3shxWvX10iLTrpLt821XV J+eAFGZhzjij6lItQFPNySaqPNhpLrUfkQnSbExUShf+khEbBMqlT7c0sZVJZZI7 FPCRDdBiScNCXSN4Fi5QX6EdMFT+PjIp1pM4dELTPiTPQaHrrQaPWR0pOrQNfQbw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedriedvgdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepheeuhfdujedtieevkedvhfffgfelfeelhfefkeehhfekleek hfefueefveffjeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id ADCFA18009D; Thu, 15 Oct 2020 00:00:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: In-Reply-To: <160264415431.16518.1057616138324026764@ietfa.amsl.com> References: <160264415431.16518.1057616138324026764@ietfa.amsl.com> Date: Thu, 15 Oct 2020 15:00:59 +1100 From: "Neil Jenkins" To: "Benjamin Kaduk" , iesg Cc: draft-ietf-calext-jscalendar@ietf.org, calext-chairs@ietf.org, calsify@ietf.org, "Daniel Migault" , daniel.migaultf@ericsson.com Content-Type: multipart/alternative; boundary=2cb8d200652a4448842b87351cf7b65b Archived-At: Subject: Re: [calsify] =?utf-8?q?Benjamin_Kaduk=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-calext-jscalendar-31=3A_=28with_COMMENT=29?= 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, 15 Oct 2020 04:01:06 -0000 --2cb8d200652a4448842b87351cf7b65b Content-Type: text/plain Thanks for the further review, I've adopted all these suggestions. > It looks like the change in location Id for the virtualLocation entry > was unintentional, since the localizations property contains a patch > object that still references the old Id. The change was intentional (because I wanted an example that wasn't a UUID to help reinforce that this is permitted), however the patch path in the localizations property should have been updated to match. I have now done this (which conveniently makes it fit on one line too). Good spot! Cheers, Neil. --2cb8d200652a4448842b87351cf7b65b Content-Type: text/html
Thanks for the further review, I've adopted all these suggestions.

It looks like the change in location Id for the virtualLocation entry
was unintentional, since the localizations property contains a patch
object that still references the old Id. 

The change was intentional (because I wanted an example that wasn't a UUID to help reinforce that this is permitted), however the patch path in the localizations property should have been updated to match. I have now done this (which conveniently makes it fit on one line too). Good spot!

Cheers,
Neil.
--2cb8d200652a4448842b87351cf7b65b-- From nobody Wed Oct 14 21:11:49 2020 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 C0EEC3A1260; Wed, 14 Oct 2020 21:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 6jGBfBT60NVQ; Wed, 14 Oct 2020 21:11:46 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 9B9DF3A125F; Wed, 14 Oct 2020 21:11:46 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 09F4BYCd015946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Oct 2020 00:11:38 -0400 Date: Wed, 14 Oct 2020 21:11:34 -0700 From: Benjamin Kaduk To: Neil Jenkins Cc: draft-ietf-calext-jscalendar@ietf.org, calext-chairs@ietf.org, calsify@ietf.org, Daniel Migault Message-ID: <20201015041134.GF50845@kduck.mit.edu> References: <160264415431.16518.1057616138324026764@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [calsify] Benjamin Kaduk's No Objection on draft-ietf-calext-jscalendar-31: (with COMMENT) 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, 15 Oct 2020 04:11:48 -0000 On Thu, Oct 15, 2020 at 03:00:59PM +1100, Neil Jenkins wrote: > Thanks for the further review, I've adopted all these suggestions. > > > It looks like the change in location Id for the virtualLocation entry > > was unintentional, since the localizations property contains a patch > > object that still references the old Id. > > The change was intentional (because I wanted an example that wasn't a UUID to help reinforce that this is permitted), however the patch path in the localizations property should have been updated to match. I have now done this (which conveniently makes it fit on one line too). Good spot! Ah, that's a good idea to show "not a UUID", and thanks for the consistency fix! -Ben From nobody Wed Oct 14 21:57:20 2020 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 B57003A1286; Wed, 14 Oct 2020 21:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=WWxZkAgn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GjT7tVa+ 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 KMq5Bq9Q87Lh; Wed, 14 Oct 2020 21:57:12 -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 67A043A1285; Wed, 14 Oct 2020 21:57:12 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 03246F9B; Thu, 15 Oct 2020 00:57:10 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Thu, 15 Oct 2020 00:57:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm3; bh=TeO2 OzqL5XOjo0n3KdiwnNOiFqP9+yZnlzISOOevXNA=; b=WWxZkAgnRjpQlxghL3M3 ssTkRZCYUfLI5i/X1eazdFDAPJHlIYfnvmpTvoaZhhBPUBfZvypNjTbp1kOE6JMP tngGMugq0Tv6245e0KWfJCb2+uO91QGFCBa+gbaApaOL92uZNvngBGGRMN3KZEAv eS8f0WN8jHUHAH8PCNPbl4iMXz5FQprHYDE+BGgh3Yq8UGBBdG0LC/us5r/TbdNp AUmRStuhYTABM+w+nUU3TUnrXTHxl9myb6wgcgCXPTZocJvA+Ym+knuaZfirc0bj LfUF9gq8sbkDLjpIbOlJ8emMuezTs9UcZBUrFIWUfSpsXHvBTNlgR3JDItE1G/bM VA== 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=fm1; bh=TeO2Oz qL5XOjo0n3KdiwnNOiFqP9+yZnlzISOOevXNA=; b=GjT7tVa+SpdakwoDklkwNA Asb0iCifjhZDkt3jqdwwiMDpfPuG+u9PZIiRWwRD3sA0fYIlgm5JoKquxd4r5fgd rmImX19B46VAOpmSd1R7hLxqQ3pj1GbfkJU0/J4zBmVUNumGzaKDTC/HV+66QrNT DdcLyvvqJz1kN3Ma457Y45aqjGpDiFfEGiXTxSwnO5FkvbLufI8NB/0YWALtODjV 3RyJ+u3AVRI6yRvtKtU9quuvNTssaAZ3G/QZ9oJ6QsSuLgN5y0EzuSlg6AQ5w1oo TETBNC4YdUo1MD5ESZN0HdFllHdSXFZ8jDnpFxY/r2o+QNBDiHB2I6J06Y9HJ23g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedriedvgdeklecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfpfgvihhl ucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomheqne cuggftrfgrthhtvghrnhepheeuhfdujedtieevkedvhfffgfelfeelhfefkeehhfekleek hfefueefveffjeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2247D18009D; Thu, 15 Oct 2020 00:57:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: <127eed97-9569-4288-9d94-84516827e363@dogfood.fastmail.com> In-Reply-To: References: <160086776435.888.17000256917777703435@ietfa.amsl.com> Date: Thu, 15 Oct 2020 15:57:09 +1100 From: "Neil Jenkins" To: "Barry Leiba" Cc: "Warren Kumari" , iesg , draft-ietf-calext-jscalendar@ietf.org, calext-chairs@ietf.org, calsify@ietf.org Content-Type: multipart/alternative; boundary=ac4b39b7d79d420d92b0cdc6a4e06ac9 Archived-At: Subject: Re: [calsify] =?utf-8?q?Warren_Kumari=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-calext-jscalendar-30=3A_=28with_COMMENT=29?= 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, 15 Oct 2020 04:57:14 -0000 --ac4b39b7d79d420d92b0cdc6a4e06ac9 Content-Type: text/plain I have added the following paragraph to the end of the PatchObject description: *The PatchObject format is used to significantly reduce file size and duplicated content when specifying variations to a common object, such as with recurring events or when translating the data into multiple languages. It can also better preserve semantic intent if only the properties that should differ between the two objects are patched. For example, if one person is not going to a particular instance of a regularly scheduled event, in iCalendar you would have to duplicate the entire event in the override. In JSCalendar this is a small patch to show the difference. As only this property is patched, if the location of the event is changed, the occurrence will automatically still inherit this.* Regards, Neil. --ac4b39b7d79d420d92b0cdc6a4e06ac9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I have added th= e following paragraph to the end of the PatchObject description:

The PatchObject format is used to significantly= reduce file size and duplicated content when specifying variations to a= common object, such as with recurring events or when translating the da= ta into multiple languages. It can also better preserve semantic intent = if only the properties that should differ between the two objects are pa= tched. For example, if one person is not going to a particular instance = of a regularly scheduled event, in iCalendar you would have to duplicate= the entire event in the override. In JSCalendar this is a small patch t= o show the difference. As only this property is patched, if the location= of the event is changed, the occurrence will automatically still inheri= t this.

Regards,
Neil.
--ac4b39b7d79d420d92b0cdc6a4e06ac9-- From nobody Thu Oct 15 05:05:52 2020 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 635103A13DD for ; Thu, 15 Oct 2020 05:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=kumari-net.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 yNa6BmxiB153 for ; Thu, 15 Oct 2020 05:05:49 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 C58173A13D1 for ; Thu, 15 Oct 2020 05:05:48 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id c21so2828655ljn.13 for ; Thu, 15 Oct 2020 05:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=arkPWUSwwLzaxmp2Km4gDdCkB5TQkxN7gIwmVPLQRpc=; b=yMwo7F+3MOx6oKI9cCWSVjt9HDGXDWf6i+FAm4XhZR2bATNT+TNI2Gp908/jlfExAO Z5ZGGhblc6K6aEekkumSVVKOG8Ny51GupAF9oqdq1I5jeXE/7CAOMsI2Hh9Kn8eJUsfc QZDCQlzygX0qMT0KXMfp2Dg1xl/WdZ7W0SQhpXMAJcME5XY4Hjz88EPmCsYg1J+4Ng2r VT59wEAjXz+9UTYDLyBvuG4fqQuDFl/RK7g9XPK3YwhjmQyGrf8czeLrBtZHsGk/uVjw u7eiBfnxtbHtMIIdqnsH3yCEkUGgZeYRKzQlC9PEoZl0uipzsFvSho9YJQ2pMedy0A5g Uu1g== 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=arkPWUSwwLzaxmp2Km4gDdCkB5TQkxN7gIwmVPLQRpc=; b=tXoAgEu2MbD1S/Rgte5j4Tq1I2FWGquVAO6VK1n1EsgdvN6Q8nSnjUowDDfvZTYhe+ NDsG62cQn+6IS4vhnCB7j4ciFhJvobjw3xBjBolkHWW1AEqueh9uZkwVuxGWrLYnvvOi hjWuT5fyy8febZxgvCkfvw5uIzy2BLKNBe/rar7j3+0lMXZYQYcNF1lH5F8NGsOgX+Ev 4DACbDeVTx5hqFf2rtr7UOhnGrk35HjVMJkQklUXZ1cSU05sC0p38pmoops3ryTSMX+b RcxcRTpP0LQEkxTJV9t3P89y3w5IGfXLHBBLauNqAhmY160nJQRW1RNbcHiXRCbRPogD gz9g== X-Gm-Message-State: AOAM5309cwaIQQqZEjfCvTA0kgEsJ8Sfm8uTmPaw8PIzSxQAY0VlJW05 zfyhW0onQScUjpeE/EUUA2q9BjcP9wfnI+fo4EyR9Q== X-Google-Smtp-Source: ABdhPJxy4nCJKoBMssWmKVA6Poy4ThKKE4ItHnDrGJD2h5j3zryv5bozZNVtF8HzP4I5jVUgwz1+29/IjrtwEvh3w6I= X-Received: by 2002:a2e:8295:: with SMTP id y21mr1064740ljg.153.1602763546451; Thu, 15 Oct 2020 05:05:46 -0700 (PDT) MIME-Version: 1.0 References: <160086776435.888.17000256917777703435@ietfa.amsl.com> <127eed97-9569-4288-9d94-84516827e363@dogfood.fastmail.com> In-Reply-To: <127eed97-9569-4288-9d94-84516827e363@dogfood.fastmail.com> From: Warren Kumari Date: Thu, 15 Oct 2020 08:05:35 -0400 Message-ID: To: Neil Jenkins Cc: Barry Leiba , calext-chairs@ietf.org, calsify@ietf.org, draft-ietf-calext-jscalendar@ietf.org, iesg Content-Type: multipart/alternative; boundary="000000000000d8796b05b1b477d7" Archived-At: Subject: Re: [calsify] Warren Kumari's No Objection on draft-ietf-calext-jscalendar-30: (with COMMENT) 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, 15 Oct 2020 12:05:50 -0000 --000000000000d8796b05b1b477d7 Content-Type: text/plain; charset="UTF-8" Excellent, thank you very much. This makes it much clearer why this exists / is useful. Thanks, W On Thu, Oct 15, 2020 at 12:57 AM Neil Jenkins wrote: > I have added the following paragraph to the end of the PatchObject > description: > > *The PatchObject format is used to significantly reduce file size and > duplicated content when specifying variations to a common object, such as > with recurring events or when translating the data into multiple languages. > It can also better preserve semantic intent if only the properties that > should differ between the two objects are patched. For example, if one > person is not going to a particular instance of a regularly scheduled > event, in iCalendar you would have to duplicate the entire event in the > override. In JSCalendar this is a small patch to show the difference. As > only this property is patched, if the location of the event is changed, the > occurrence will automatically still inherit this.* > > Regards, > Neil. > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf --000000000000d8796b05b1b477d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Excellent, thank you very much.
Th= is makes it much clearer why this exists / is useful.

Thanks,
W
On Thu, = Oct 15, 2020 at 12:57 AM Neil Jenkins <neilj@fastmailteam.com> wrote:
I have added the following paragraph to the = end of the PatchObject description:

The Pat= chObject format is used to significantly reduce file size and duplicated co= ntent when specifying variations to a common object, such as with recurring= events or when translating the data into multiple languages. It can also b= etter preserve semantic intent if only the properties that should differ be= tween the two objects are patched. For example, if one person is not going = to a particular instance of a regularly scheduled event, in iCalendar you w= ould have to duplicate the entire event in the override. In JSCalendar this= is a small patch to show the difference. As only this property is patched,= if the location of the event is changed, the occurrence will automatically= still inherit this.

Regards,
Neil.
--
I don't think= the execution is relevant when it was obviously a bad idea in the first pl= ace.
This is like putting rabid weasels in your pants, and later express= ing regret at having chosen those particular rabid weasels and that pair of= pants.
=C2=A0 =C2=A0---maf
--000000000000d8796b05b1b477d7-- From nobody Thu Oct 15 15:22:31 2020 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 C77063A0A06 for ; Thu, 15 Oct 2020 15:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=igalia.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 HZSzzM9jnWPX for ; Thu, 15 Oct 2020 15:22:26 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 C4DED3A0A00 for ; Thu, 15 Oct 2020 15:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=sgNtkx7767OHaA+jUM8oETCw/GQh7ge/4kXbGYYzvVo=; b=R8kDqxVc6cPsyJzm7eEb0c6A9Bx1EFBH7hwNYFbfPnhtPsun85C0OyEt55Kqn8vfSm8uy3rH+zkq6TM5LDXoXtvyNbzYZ8AUctbHBNlGLtXQhYULZ17Mli/24T6LFMMe6uDVmGdutUB9h4n7co9VBLyTSxLD+60en0COQE3u/WfobcYHaUp5kpJDHmSIT6XzhB5Wh1zEWkT+cXT+BCH14Xwtlbh4VFejziw8ANo8NmWIwErksMZsep8716Dm8lFYLhgGgIBgUvdA2j8E08DDgHLKx25mPGX2Z/DrqBp751JXf1MzPgGwj38fqfp+fpvUosE4q2w//W3D0nBMz77irg==; Received: from [183.83.215.161] (helo=[192.168.0.110]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1kTBdb-0003Uc-Qa; Fri, 16 Oct 2020 00:22:20 +0200 To: "calsify@ietf.org" Cc: Ronald Tse , Shane Carr , Daniel Ehrenberg From: Ujjwal Sharma Autocrypt: addr=ryzokuken@igalia.com; keydata= mQINBFpsLAwBEADb/gc4ouvNQQc3ZmwVAOewWuWve9xA3B/ok+DhzSx2wJ82FR5s+198Y++s oMb4VyiU0FOk6FUUBSn1OTTEB5TVW904hqczD3qLDIbZD6bL9sor1W/8ok0q3q8hr/ICyiSC 6FuTROjXOL31Hs8pob/YsNX6e5g+o7/tSb0gXH6r1Dw7DL7gRqMrMFJRoBZZOwvu75PxFRCr bJ/GfkMv5ovLO2/Oj4P3/VbM4FzHSbn4r/CD/RrL3Qwhn94CoDv0fSzsGKqESbeVYjiqREWU 4oL5PR6PbPD9RXXw/wBUqIvGuEN8lKCpxsLHhPfYA4i7+en3JRot8O+Lk3nu1qEL7ED75Zot MbHGyZ6NxRv12mtX9aVWQAy7g3xNoEh3baqEpYcAXtgbX24aTX5etL1y3Z6cUBHSUTKHlHix egmjSUEkaY/qmTTCvJUGhTU+tYGHBnh6Eibg1NVKeIXdCZBhLqp4NqrivXBQxWAnN4Y7jtCQ O+uQIptIiL1YVcQrU8D/0Y6Pl3kWo8AUd3Nu+Dd+qEJqSimrcNzIjZqoun+ADrVoufzkMT5C ELT1YsS5TH3vGn4qtvGQU+/MQDMMm4vlVlaIHtAExiNHwLQ9NsFDWN6B4vvAvGv5PBanbMJJ b9iA1mCuVZnP+q/dxGQubRY3i+RqA8pyfx03G5yFr0CMjwqbEQARAQABtCRVamp3YWwgU2hh cm1hIDxyeXpva3VrZW5AaWdhbGlhLmNvbT6JAk4EEwEIADgWIQSsOTVT+mJCZQ85wB4f07R7 g/RmIQUCXgnwfgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAf07R7g/RmITovD/0Q T+kIEIBrVppJ7dNp4Pyg1hF7O4pVlu9MI6fu95bGwmXSU5BpohYSCn33d8YwPnHZH698UC0Y Zd2FU2foynYn5XUJRaiDEynK9rmZxIB33IANLfEbxC1u1sby7n154wvk7r5kBJLesR2a/Wlb Qr6q8LMCGvWQf/IAQzOdsylwnuDeKDSLrlOI0XoGizRg9ojExOGiR8cPNnhYNM35UmXEwYXN mDkoUV3unT2dXgW2HQfhc83SlfSqB8+2bLi94LTgZm5eBQxEzbj5wFyGElIURksA8SPvXY2R 0xx24odyGQi1CO16RXcBCOtqHUaH8UnyPeHg4lRBiIarZtzbPMh4h+YBoiuD6iczfLc/II5E 8852XD9PFX8y69y98bLfSBlMz/RIjZ1An9oIgIqFMtPnt1FB5LCNoe2iOXmzA8tuSHDXzYzw GvXix5cgOma4oAqzLphG9GwxhJiOL6eOjf2VzjfZYOrduuJBsJ+60rCvURiAeHbt8ogQVHNb DKImEseQY0h0pyM7r0FRRynyEya5GUF6vdaVL4DkwHJ6OphSlF4TW12XKdBMG8APNF5tx3f+ K732lrAVnqQfTm12hQp/9mpkTQ0edpgoEW+ZWvWOGotyzyWF1uzvVHa9zwwJWvjU2tKINaKL E8x8728etREcX39GKqZWNFqJZN1L3KivQbkCDQReCgRfARAAooqzPt/mQ6vO2zn3JqA4cjVu +VuxmGuBL7VclmzYG1veTrkqOgBW1lxLSLEJLrDyfvC40RDS+QgBqmtbQ8x3ccOkcCNTMoj8 8lx5BiGUInjT6wkmRYejGsw8DuKkIWnWrrv628xZiB+fhwWxc5lu3kb5LEh9eUEDrHUhMzSy svKJlpuLd93zGGtC5KAeqZhUH1pCc0FBxbBBqy0bcfYKuRcNSO7YFHIAGRbYeQMOivhMXC2z Zq6YEdLxnAl21OQlRkv77XinSD4e2Yb7WFK0MgvQsdwLOhM5pHBcuc6MkGLm/lMM8VO8N9o6 n4QyZA5LsfhTd0kGleoII0YO9RQOLHRdiPKlvDbD1B9Mg58hQakBbJF07eAwEJq/a+LhzhW+ VHlZWNV0h9tSugSgq3nOt6wG/ftVMRILREMFUDI63+UR4PXJ++l3TNBd/5RZCmuWFoavc/Tl AcQG/aQt5Ezh9AdD0Ao+5VL2ATjNSHMxH+AnEagnx2vmJC5I+LqATfgn6CX4DzatFSA9LxZX LPiXlMGWH6JogJpIQqaHulqjfko2Mb4eHuYvdl1Wova03w1BUA/EHUnJIaGVXlV5E69ubJTm SXqEAixL6vYsljJ0fO4IxBlT71aRyrvaKW37fWG2c/csjgB25U2Y7tdWY4xA96LynAurJSRJ Jj+Urmz+Bm0AEQEAAYkEcgQYAQgAJgIbAhYhBKw5NVP6YkJlDznAHh/TtHuD9GYhBQJe6vw+ BQkBzkXfAkDBdCAEGQEIAB0WIQRMXCPh15S+uPoc6Av/592ik3N4ZAUCXgoEXwAKCRD/592i k3N4ZKvZEACQNX7g5NPdRNwl0+UXy/NK2nQVOu/0Vel9giRzHfhgjetWBTzsl2DvnMoi8VG3 sY4ztOkpERm33HHOcFKXlJ3qCZ0mjAa9+pH6IpJEvpqc4TJ6o92dB4lqJNuJQBDVsYcuM4+C hPM0LnrJgJ9/SMeuWgVrT9sXC3nuJlx0ZcKo4eW/K7t3IVc3IcXV3V0ORm5hf+W30A+SUY1F xteU+7/wccI1WfjGNC9q2e3ywVsWAVfQu5kS94QhY3S1vJJ6bfZ9zpql8IuP6MczlTkFzvo6 j7CJ5ymF+A952AoU5Mj8Z+qwAt2OCpEbMufMMdexczTbg9edzhtHWAHnX/uE4d/d9HF4VryU xpg3ZZ4mse3UJTQ8AF2vQhOXT7B5d8QI0QKeH4qmhDCrgXDoXyV107TJ6ScZkFI1MmEoyZEf cv6tTiIfn70gfNXntKdqkt7E7lqybofkDEj91qelPlnE0nRH0tDMq5xJSe1DLPPlSYdnk5Z6 2g/rXAGmzvjVlj5Uw6nw/SfTgE275tVWFA1fkMjjVJFItmmwxDu6dez7QZKYlIC2mvk7ZvUW mlUVmyauJFKVMFlrH0AxWFRwMlmyiSrcy4lN93SjlQHAx9Nt23C7OnKUC83sA+jlaHsdQb7k hqAGpgzW78ijWe45CYrmXNzRsgf59nuTWIxcZrU7ck5CugkQH9O0e4P0ZiFfghAAn/dUwP2T OIGAPsvFLEvPKecBGwJITFvm9cbPqUE26D2gOC4EyJuCJlvXfn97sYcv2/c6g5CGgkJxcjnH 3Z8z1Yzkg3JCDi78lmFsw/N3VQdSJAqLJRUeVfcsudZh+LNMPW7FRRXqUb8ZrtCrMtsrWTL7 iVy0qKmWIOBHyhJZCUIVo3GZHZFePsqMRObZlSDUekGkhJ5MNRLcZaLLBVUIMgfNIVMww11M Yk0rmk6i74EYre2+jVc8HQMjkvRb/zqZzWNsqqR+PB4f+lLMAi4E9+8AKCyN1RQa525dnhYs XxiyvPwWpddfKHbDzUSi6z70x5ry3mFx1i+OixKhv2jpqNUXG3B73xsId67gTs6eRy42/JJJ rJ2NC1y0uflJmLamPVxHPZi6h1jqcRFmq5/vvuSWvWPQbTGQeReflRbLTzfSUlOaMll3YedV 07dGKYjmLNy+1vrM/Mwa0So6kAmeYQSk5FbFcrqDHDWcv98E7pP8Kozah/ryWUtVfdGTSCXW dMecSCyuMzAteW6JRlOOOMmN92YBaULxq7ERa4cOL0Vkz5vlzGbkg2wAobgRmXP4LaBJ6kVU Qp9SUTwjwKAVF+i1Tpw38BXLtJphdIOPV1QZmK+5CPMDjGifPlyDUSdA4T6h/Nr8bTjuQUkY HEUDJZMWsP+L5v1mK7gP9mdJiJa5Ag0EXgoFEgEQALOhu272DYYvbhw6kOirE1AR6ncs0i0T wDB/YnEMkBi/J7coe51I171TLaqTb5cwhs2chRUMiIvGft96/efypDnGZnvVZh80tiBUlcI9 tckQj4A7DYlAFNfdZAVKUP+G49P9N1EB8wFnc8X/YPjFP/iB169d8YyHgfibcvZbeOkMWq70 bt4maZVWCYI6r/RkFYrlgVlO28GrURELPW/B5cf+NXg8tFvxv9MR7QEWh/VHZ3CsYq1+4p0A ZEixg0D1ynvV2LS7sqca2eHxXhzX0VXdvjCKWY468E5eYlHkyOFdsbdiGgyZB5L25y/CIeyZ sQz3unYWYZ3E4UcJFm8hgsl8YWMSYl98IORpZVQ7YII2dnwPB5aRIfJgoKl5rP/AsKLV2dzj p+6yljrA2czat1c8MWko2IO/QMpzMFmWkuZiSBwNXQuByYUF0SM10pY6faApo/wWnLyEcwPF 0hmmlj0gLkkT46zdLFxRI0kzUPX7tPKqNc2hPzyHSrKXPuqJyWnq2lvS3LxNRngiRb28mKbg GQpE/iX3whzcVs1kAAL8DaiLIKWmJ5bbYEy3DzTuysMgK2lCeqGGj3p6xczPwrJQkDQKwnwf 6KLMEA6RlbWThmC2eWxPi+TLV4/HTbvabYuOBhVd4xwZZ+WfhgYCR5XmaKknKs3D8YOv3qdv EZj/ABEBAAGJAjwEGAEIACYCGwwWIQSsOTVT+mJCZQ85wB4f07R7g/RmIQUCXur8SgUJAc5F LAAKCRAf07R7g/RmIYbHD/4rekfbk8ZY2q4/wdiH9NpfYLzFQhsylQ1Knqau4oPTFXUPY2bz 9X/LMTwj7fVGa5rtC9uuoDKnmdxq7qzItf2oO+jE6RM2nDXZWeXDubQZlFgNQOde3PvTjJxF CgMwTgFl5Ydh6HQZlgcf13BbXwdF2b1d8kI1SFMkk6dgCWQJfmcRUYrTNfv4CB5dyZvnDLBF N1tmePnUpsn6gDxigr3sXJ3TE4R+mZrYNddW/0Km3X4bMi1lD7n/tmWyLJfQpsOXxInWPT0K 5eFQ/kGWeheAoiYFTGzCnbLLYWzaMRqxfBzze+eP0Jt8tQVcm7Xr7k8GE0811JHhKtTduoX6 /UF0U2+VNdQsYLWVMag/Eb/KeHBCNruEVEcOhGl1eamDIO33fnP/7bs2M7NP+p1rE4tGxLrr oxK5HC7ZDSye7nHfROK1CUzT3ALVupyVQrC6sa4vbUhtpnB3Q2K7fH660YbG6bLaDjHRNfRJ ER5JsjGz7YJi6Snig1eyAkFMEfZym2vxUSagFbi5u5KHteWy1GuaEkPowB4/4/PKmoh7+ec7 pqSM0a9F1fsScQa5SpzGaG5BeTOBz5PPb+528NFZKtt67nHKxJKbVxortLiRjxp6FoXY2x69 8q+jogfmP5bMqkUzHcdOXLzApLyoxOgEGqS3Bn7mBR0C8aUPeowlESZUtw== Message-ID: <4d4efa02-bc9a-843e-32e5-a491f8f33378@igalia.com> Date: Fri, 16 Oct 2020 03:51:29 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YF08fT1lulmrHgl2NrUO2Bfksy7513nzh" Archived-At: Subject: [calsify] Getting started with the calendar persistence format 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, 15 Oct 2020 22:22:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --YF08fT1lulmrHgl2NrUO2Bfksy7513nzh Content-Type: multipart/mixed; boundary="H92oI22fpkNfl5XLFo5zYIPQj1OKvPnIH" --H92oI22fpkNfl5XLFo5zYIPQj1OKvPnIH Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello everyone! Thanks for the amazing discussions and help yesterday. Given our constrained timeline, I suppose I should start working on the drafts immediately. On the IETF side of things, I suppose I'd need to start by creating an I-D? Is there a set of resources you could point me to in order to get up and running quickly? Also, what should I do to get the ball rolling on the CalConnect/ISO side of things? Best, Ujjwal --=20 Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, Node.js Core Collaborator and Speaker --H92oI22fpkNfl5XLFo5zYIPQj1OKvPnIH-- --YF08fT1lulmrHgl2NrUO2Bfksy7513nzh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEETFwj4deUvrj6HOgL/+fdopNzeGQFAl+Iy4sACgkQ/+fdopNz eGTouA//V3Sp0sen2Yv1+HlNEw/QQC8lLSwwyc8NXboqU/Yoi1AbbToURyN+97fz Rn5yyVk08mm2mMyfZ7yidOO/6KcXBLonEFZ8rWz5Z2VWcoWVpq3CxjhPtO8ql1/0 mStDbFY7pdBEbImTA2J1oQIsO1Lp6I4lvs44SJl7RmsBF7mdARt3/vh+J0vJy2Ne ojjF3od5OW9GDWu8eCWjEIPP89vEl+ECyreW7aQIE48vtt/XR2TkkeTL3EV67n06 EOKk61+FEWlHsUiQX/L7k5kXOULrfg8CSA2LvwldYHS+OEWBmEQjwD3ptadT2Xcq pjGXsAmv2997H0OyuUNCyjYWLiCNBjQVH15ALXn5Pe43Kv1OY9UgicFZnuzsR7hJ SRxpj36CNGf544uQixIS+qy2hMDE38Msbfy1zG8RfawpEe9rUVWfq7wpbWp2ZNqc hIeNPStA+aj22PczsxOCCwtwRf+EzS7jMopN22yTr181yyhEmoBz/4xiwSzRaq/l eWj7/I5J8pucXBAUEpGdPblZtK4es3qY0lxYauYbpwkcWRX3lhDBhovc73C1MAYd QmqwMIlrHgp0auQAr5Zi8UQhmicOnsnEPtNaUiUYHaeofXuRE+D8hF8lBmQEzkM3 gQtNG7u4Jssy7SCCGiSMBTNJCpoZ0JCrNKimzhXW1d3lACmbQ24= =fZlD -----END PGP SIGNATURE----- --YF08fT1lulmrHgl2NrUO2Bfksy7513nzh-- From nobody Thu Oct 15 17:27:20 2020 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 7C6583A0D31 for ; Thu, 15 Oct 2020 17:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=f9cbn2HS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=U+K3NL9c 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 nYcFvQK0E_Ni for ; Thu, 15 Oct 2020 17:27:16 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17593A0CF4 for ; Thu, 15 Oct 2020 17:27:16 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1DD995C00F3 for ; Thu, 15 Oct 2020 20:27:15 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 15 Oct 2020 20:27:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=YjH7stX sN0wXOJJ5PtJoYAP97lKM6eb+SdNxPkj6tss=; b=f9cbn2HSjNJXkl66A94+nNJ +Z3wsQkHn/F6MLNKB4/BhottAvtByyat2oA8aG3sZFufZ+jP8L8yiZ49NUuOPH1H UnnNpqnz+RjiWEjmf547PKJOnqeeCMB40Za+wdyQwK9IwaVdJEcf8IW0izBb/HS3 IFxm6nan6cins3TBbkl3HjeFWGR1Rotdh/p4Z5TxhDRjaqD/1wLbkhRphPtSh86f FSoW2cyqlox6a8SQHGGjazrtql1eHXBZ4XB7MhRdRT8RIk39BCPoybk4a+KcKi9Q Z5htvZktJEEWtOXgXZSdtAtaSPmopff3tbPwtf6IIHZ2+MaKNEVT81beVfeWg5A= = 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=fm1; bh=YjH7st XsN0wXOJJ5PtJoYAP97lKM6eb+SdNxPkj6tss=; b=U+K3NL9crngu4tHPycGI+g FGGu4QJlTG80PTYPt/ylyJizwABkXSu8fQCO5Q8zjLo3wIl7NTxSDnQic9zwp7zc 7y9UbYmlNZ5U9MvSo/G/kzOHbafTs55ZbfQ+woh9Dvv02THHRm/wQIi99MS6v4Wm v3Y+a9sXVMyLOBl677NUGpVDC+nM+PWiPn7PXywCSZVBADYoEDT88R77KGmgLmPN tTDZW3yQXVZ+JPaxedZaM55xIwOBw1gQElYi08wtpwr5IyELEyHUrLazn8SKjsh6 jqiOZ6HOF9wXr4kaRVm2nnlsRNi9t2ju/LeRTJTLy/Z2dWYUR/JAIDE7oH2Kf0JQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieeggdefiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrgdtre erreertdenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehf rghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepgfffuedvgeeuie ehgfduieehieejueeigffhgfdvjeelkeegveelveeutdfgteegnecuffhomhgrihhnpehg ihhthhhusgdrtghomhdpmhgvthgrnhhorhhmrgdrtghomhdpihgvthhfrdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AABB318012C; Thu, 15 Oct 2020 20:27:14 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: <668b5100-aab0-4353-bc11-132ed1f3785a@dogfood.fastmail.com> In-Reply-To: <4d4efa02-bc9a-843e-32e5-a491f8f33378@igalia.com> References: <4d4efa02-bc9a-843e-32e5-a491f8f33378@igalia.com> Date: Fri, 16 Oct 2020 11:26:54 +1100 From: "Bron Gondwana" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=5a646933a043422da16e1d5b69968af0 Archived-At: Subject: Re: [calsify] Getting started with the calendar persistence format 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, 16 Oct 2020 00:27:19 -0000 --5a646933a043422da16e1d5b69968af0 Content-Type: text/plain Hi Ujjwal, There's a variety of options for writing drafts. I personally use a workflow based on mmark, for example: https://github.com/brong/draft-gondwana-effective-terminology There's also metanorma, which allows you to create a variety of outputs. There's documentation here: https://www.metanorma.com/author/ietf/ Or you can use tools like: https://github.com/cabo/kramdown-rfc2629 Basically, they're all toolchains that generate RFC XML format documents. In order to publish to the IETF, you need a datatracker account, and you'll need to upload there: https://datatracker.ietf.org/submit/tool-instructions/ Cheers, Bron. On Fri, Oct 16, 2020, at 09:21, Ujjwal Sharma wrote: > Hello everyone! > > Thanks for the amazing discussions and help yesterday. Given our > constrained timeline, I suppose I should start working on the drafts > immediately. > > On the IETF side of things, I suppose I'd need to start by creating an > I-D? Is there a set of resources you could point me to in order to get > up and running quickly? > > Also, what should I do to get the ball rolling on the CalConnect/ISO > side of things? > > Best, > Ujjwal > > -- > Ujjwal "Ryzokuken" Sharma (he/him) > > Compilers Hacker, Node.js Core Collaborator and Speaker > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > > > *Attachments:* > * signature.asc -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --5a646933a043422da16e1d5b69968af0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Hi Ujjwal,

=
There's a variety of options for= writing drafts.  I personally use a workflow based on mmark, for e= xample:


There's also metanorma, which allows you= to create a variety of outputs.  There's documentation here:


Or you can use tools like= :


Basically, the= y're all toolchains that generate RFC XML format documents.

In order to publish to the IETF, you need a datatracker account, and = you'll need to upload there:
=
Cheers,

Bron.

On Fri, Oct 16, 2020= , at 09:21, Ujjwal Sharma wrote:
Hello everyone!

Thanks= for the amazing discussions and help yesterday. Given our
constrained timeline, I suppose I should start working on the drafts
immediately.

On the IETF side o= f things, I suppose I'd need to start by creating an
I-D? = Is there a set of resources you could point me to in order to get
up and running quickly?

Also, what = should I do to get the ball rolling on the CalConnect/ISO
= side of things?

Best,
Ujjwal<= br>

-- 
Ujjwal "Ryzokuken" S= harma (he/him)

Compilers Hacker, Node.js Co= re Collaborator and Speaker


= _______________________________________________
calsify ma= iling list


Attachments:
  • sig= nature.asc
<= br>
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com

<= br>
--5a646933a043422da16e1d5b69968af0-- From nobody Thu Oct 15 18:25:47 2020 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 E67A43A0DD6 for ; Thu, 15 Oct 2020 18:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=igalia.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 74NkCMlS8Un1 for ; Thu, 15 Oct 2020 18:25:42 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 DB2623A0DD4 for ; Thu, 15 Oct 2020 18:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Message-ID:From:To:Subject:Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Date; bh=Q5Pf5seqd9REBiYY3TeU8Sfel89g4iCA0y8ldintjuE=; b=FG9U+GpITPTwCdDn6zHN8fbah5FinD2cEY5TN45idlJkb8FCbtk9aPgzl2B7uPT8zkVmbaJTFmLDtjmGQStEyZmNdQpT7HKFSoRnp+/y2aRZYB/TpHgQzxzi5+7/hWg8UsDZlGi7T1kyYZorUCkBj5y3BNm6h4T4O9XYQK4BnjKZE6+N1kgB3os75oUWlGjzQSS3Diq5oksUrz3r2IKPPN2yokJsQcji2iPnzbrUJpThJ8UDMc5cliWuH7pNimzMih7ezOZkMBKuzmuvp4ZeZR7zj68Kth//tCia5rn9qYW1rJSPy343j2CbZEyn6I/aQ9PkmXi7Gs17GjX+UJX8bw==; Received: from [183.83.215.161] (helo=[192.168.0.106]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1kTEV0-0008Iu-R1 for ; Fri, 16 Oct 2020 03:25:39 +0200 Date: Fri, 16 Oct 2020 06:55:22 +0530 User-Agent: K-9 Mail for Android In-Reply-To: <668b5100-aab0-4353-bc11-132ed1f3785a@dogfood.fastmail.com> References: <4d4efa02-bc9a-843e-32e5-a491f8f33378@igalia.com> <668b5100-aab0-4353-bc11-132ed1f3785a@dogfood.fastmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----WVHZDBDKCPUJOCPK49W8Y1KKR68QK8" Content-Transfer-Encoding: 7bit To: calsify@ietf.org From: Ujjwal Sharma Message-ID: <34FE1372-DDC0-46A1-AE71-FF0BB06BAAC5@igalia.com> Archived-At: Subject: Re: [calsify] Getting started with the calendar persistence format 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, 16 Oct 2020 01:25:46 -0000 ------WVHZDBDKCPUJOCPK49W8Y1KKR68QK8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the quick response, Bron! Looks like I'd need to request a datatracker account=2E Is it open to all = potential contributors or are there any special requirements? Ujjwal On October 16, 2020 5:56:54 AM GMT+05:30, Bron Gondwana wrote: >Hi Ujjwal, > >There's a variety of options for writing drafts=2E I personally use a >workflow based on mmark, for example: > >https://github=2Ecom/brong/draft-gondwana-effective-terminology > >There's also metanorma, which allows you to create a variety of >outputs=2E There's documentation here: > >https://www=2Emetanorma=2Ecom/author/ietf/ > >Or you can use tools like: > >https://github=2Ecom/cabo/kramdown-rfc2629 > >Basically, they're all toolchains that generate RFC XML format >documents=2E > >In order to publish to the IETF, you need a datatracker account, and >you'll need to upload there: > >https://datatracker=2Eietf=2Eorg/submit/tool-instructions/ > >Cheers, > >Bron=2E > >On Fri, Oct 16, 2020, at 09:21, Ujjwal Sharma wrote: >> Hello everyone! >>=20 >> Thanks for the amazing discussions and help yesterday=2E Given our >> constrained timeline, I suppose I should start working on the drafts >> immediately=2E >>=20 >> On the IETF side of things, I suppose I'd need to start by creating >an >> I-D? Is there a set of resources you could point me to in order to >get >> up and running quickly? >>=20 >> Also, what should I do to get the ball rolling on the CalConnect/ISO >> side of things? >>=20 >> Best, >> Ujjwal >>=20 >> --=20 >> Ujjwal "Ryzokuken" Sharma (he/him) >>=20 >> Compilers Hacker, Node=2Ejs Core Collaborator and Speaker >>=20 >>=20 >> _______________________________________________ >> calsify mailing list >> calsify@ietf=2Eorg >> https://www=2Eietf=2Eorg/mailman/listinfo/calsify >>=20 >>=20 >> *Attachments:* >> * signature=2Easc > >-- > Bron Gondwana, CEO, Fastmail Pty Ltd > brong@fastmailteam=2Ecom --=20 Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker at Igalia, Node=2Ejs Core Collaborator, International Spe= aker ------WVHZDBDKCPUJOCPK49W8Y1KKR68QK8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks for the quick r= esponse, Bron!

Looks like I'd need to request a datatracker account= =2E Is it open to all potential contributors or are there any special requi= rements?

Ujjwal

On October 16, 202= 0 5:56:54 AM GMT+05:30, Bron Gondwana <brong@fastmailteam=2Ecom> wrot= e:
Hi Ujjwal,

There's a variety= of options for writing drafts=2E  I personally use a workflow based o= n mmark, for example:

=

=
There's also metanorma, which allow= s you to create a variety of outputs=2E  There's documentation here:


Or you can use tools like= :


Basically, they're all= toolchains that generate RFC XML format documents=2E

In orde= r to publish to the IETF, you need a datatracker account, and you'll need t= o upload there:


Cheers,
=
Bron=2E

On Fri, Oct 16, 2020, at 09:21, Ujjwal Sharm= a wrote:
Hello= everyone!

Thanks for the amazing discussions = and help yesterday=2E Given our
constrained timeline, I suppo= se I should start working on the drafts
immediately=2E

On the IETF side of things, I suppose I'd need to st= art by creating an
I-D? Is there a set of resources you could= point me to in order to get
up and running quickly?

Also, what should I do to get the ball rolling on the = CalConnect/ISO
side of things?

B= est,
Ujjwal

-- 
Ujjwal "Ryzokuken" Sharma (he/him)

Compiler= s Hacker, Node=2Ejs Core Collaborator and Speaker

<= div>
_______________________________________________
calsify mailing list


Attachments:
<= /div>
  • signature=2Easc

--=
  Bron Gondwana, CEO, Fastmail Pty = Ltd
  brong@fastmailteam=2Ecom



--
Ujjwal "Ryzokuken" Sharma (he/h= im)

Compilers Hacker at Igalia, Node=2Ejs Core Collaborator, Interna= tional Speaker ------WVHZDBDKCPUJOCPK49W8Y1KKR68QK8-- From nobody Thu Oct 15 19:00:33 2020 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 195CB3A0E7C for ; Thu, 15 Oct 2020 19:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=D4iilLR9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qanc1NiO 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 Bb2aYmr-ix2l for ; Thu, 15 Oct 2020 19:00:29 -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 5CDC53A0D46 for ; Thu, 15 Oct 2020 19:00:29 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B04CC5C01A2; Thu, 15 Oct 2020 22:00:28 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 15 Oct 2020 22:00:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=WLwCVGB t/OjIZdVOkPOgQyVaZnRPGhnjXLnRRMkXgh8=; b=D4iilLR9NVF1oiZnzMCK46i 23lV8hJ16HZuz3d4hiqQ3IqMA/BEnhTl1+nnJD0e5H5Cw4+WreFEXt5THUw/ipO3 v5R95vkF22fQOKISEBJFuxb7+8zIMb8k4lu10kGsq5tQAVHtF6bUYpSQ1HvjAPUW 8IRX2zXovCmZKbj/fI9ipePaMPVSIoEos9JDG7nUE200rgCMAbI+QU7kSpST2I2S 2CLb3lYEaTfHPblq8ENmq0VZv9EJAhWIByTFoNbIeAD2sXK7j0u/0W8f8XW67AGE jedwM6inlSjdZ0aqEXYnBRptWIsK7oaO8dkSy8L1cPjdKi5cKxDHg74d2hBG27Q= = 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=fm1; bh=WLwCVG Bt/OjIZdVOkPOgQyVaZnRPGhnjXLnRRMkXgh8=; b=qanc1NiO6pl/2+ckhU47u5 CBHLKLBz+Trtb3w2EGh6AsmnqXVRYfmJpPvBbS7qqkRZyeGH2G9TMw7qh9AzeDPs CuAzeRYlBRRoKnmmhKC/7lvw59TjdUAU96PJvKnYa4m575QJU3ZhEQl9E2sQsoBG 8cSeVIC0f/W4F32G1X8uttW8lcQAf3VdFAWI7/PmRAwLDA0JZglNY2oMuMhKvByT rQCklPFtx6ERpecOquRKvIfFaEWMeDb01jrX+zj6ich/ncmyDQgg4pil6urVual5 a2AWxWIzgceerQMYIf132R5YQYuBf9BwzArpniqs+LDUGXeWY7W+GmgYbyipAswg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieeggdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerredtnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpefgffeuvdegueeihefgudeiheeijeeuiefghffgvdejleek geevleevuedtgfetgeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhmvghtrghnoh hrmhgrrdgtohhmpdhivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 29D891800F1; Thu, 15 Oct 2020 22:00:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: In-Reply-To: <0ECBA659-55BC-4CE5-8D4B-8C48D0B32007@igalia.com> References: <4d4efa02-bc9a-843e-32e5-a491f8f33378@igalia.com> <668b5100-aab0-4353-bc11-132ed1f3785a@dogfood.fastmail.com> <0ECBA659-55BC-4CE5-8D4B-8C48D0B32007@igalia.com> Date: Fri, 16 Oct 2020 13:00:07 +1100 From: "Bron Gondwana" To: "Ujjwal Sharma" , calsify@ietf.org Content-Type: multipart/alternative; boundary=259af5ec743848c5a5d2d891472d76b2 Archived-At: Subject: Re: [calsify] Getting started with the calendar persistence format 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, 16 Oct 2020 02:00:31 -0000 --259af5ec743848c5a5d2d891472d76b2 Content-Type: text/plain No special requirements! It's open to everyone. Cheers, Bron. On Fri, Oct 16, 2020, at 12:20, Ujjwal Sharma wrote: > Thanks for the quick response, Bron! > > Looks like I'd need to request a datatracker account. Is it open to all potential contributors or are there any special requirements? > > Ujjwal > > On October 16, 2020 5:56:54 AM GMT+05:30, Bron Gondwana wrote: >> Hi Ujjwal, >> >> There's a variety of options for writing drafts. I personally use a workflow based on mmark, for example: >> >> https://github.com/brong/draft-gondwana-effective-terminology >> >> There's also metanorma, which allows you to create a variety of outputs. There's documentation here: >> >> https://www.metanorma.com/author/ietf/ >> >> Or you can use tools like: >> >> https://github.com/cabo/kramdown-rfc2629 >> >> Basically, they're all toolchains that generate RFC XML format documents. >> >> In order to publish to the IETF, you need a datatracker account, and you'll need to upload there: >> >> https://datatracker.ietf.org/submit/tool-instructions/ >> >> Cheers, >> >> Bron. >> >> On Fri, Oct 16, 2020, at 09:21, Ujjwal Sharma wrote: >>> Hello everyone! >>> >>> Thanks for the amazing discussions and help yesterday. Given our >>> constrained timeline, I suppose I should start working on the drafts >>> immediately. >>> >>> On the IETF side of things, I suppose I'd need to start by creating an >>> I-D? Is there a set of resources you could point me to in order to get >>> up and running quickly? >>> >>> Also, what should I do to get the ball rolling on the CalConnect/ISO >>> side of things? >>> >>> Best, >>> Ujjwal >>> >>> -- >>> Ujjwal "Ryzokuken" Sharma (he/him) >>> >>> Compilers Hacker, Node.js Core Collaborator and Speaker >>> >>> >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >>> >>> >>> *Attachments:* >>> * signature.asc >> >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd >> brong@fastmailteam.com >> >> > > -- > Ujjwal "Ryzokuken" Sharma (he/him) > > Compilers Hacker at Igalia, Node.js Core Collaborator, International Speaker -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --259af5ec743848c5a5d2d891472d76b2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
No special requirements!  It's open to everyone.=

Cheers,

<= /div>
Bron.

On Fri, Oct 16, 2020, at 12:20, Ujjwal Sharma= wrote:
Tha= nks for the quick response, Bron!

Looks lik= e I'd need to request a datatracker account. Is it open to all potential= contributors or are there any special requirements?

<= /div>
Ujjwal

<= div>On October 16, 2020 5:56:54 AM GMT+05:30, Bron Gondwana <brong@fa= stmailteam.com> wrote:
Hi = Ujjwal,

There's a variety of options for writing drafts.&nb= sp; I personally use a workflow based on mmark, for example:


There's also metanorma, which allows you to create a vari= ety of outputs.  There's documentation here:


Or you can use tools like:

Basically, they're all toolchai= ns that generate RFC XML format documents.

In order to pu= blish to the IETF, you need a datatracker account, and you'll need to up= load there:


Cheers,

Bron.

On Fri, Oct 16, 2020, at 09:21, U= jjwal Sharma wrote:
Hello everyone!

Thanks for the = amazing discussions and help yesterday. Given our
constrai= ned timeline, I suppose I should start working on the drafts
immediately.

On the IETF side of things,= I suppose I'd need to start by creating an
I-D? Is there = a set of resources you could point me to in order to get
u= p and running quickly?

Also, what should I = do to get the ball rolling on the CalConnect/ISO
side of t= hings?

Best,
Ujjwal
=

-- 
Ujjwal "Ryzokuken" Sharma (he= /him)

Compilers Hacker, Node.js Core Collab= orator and Speaker


_________= ______________________________________
calsify mailing lis= t


Attachments:
  • signature.as= c

=
--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com
<= div class=3D"qt-signature">


--
= Ujjwal "Ryzokuken" Sharma (he/him)

Compiler= s Hacker at Igalia, Node.js Core Collaborator, International Speaker
=

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


--259af5ec743848c5a5d2d891472d76b2-- From nobody Thu Oct 15 21:15:48 2020 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 74FF23A0962 for ; Thu, 15 Oct 2020 21:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=ribose.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 S_DNj10MKhji for ; Thu, 15 Oct 2020 21:15:43 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-eopbgr1310084.outbound.protection.outlook.com [40.107.131.84]) (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 8E6F33A0957 for ; Thu, 15 Oct 2020 21:15:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KcLrTeo98aTyCytNmlHv63QqLgyI9Ge2EyUgCWi+8F0pghIPcPmoSLniqfaPUD0uYWOkmsQJp9B7rioZwWZPecwaSK2a+MDtvQ4zlGj6HD89zRusyQ9O/O6m3lOlHKTGnAFV3ODR6/hvXkjYco5bXxkqIFtJKgl1GrRuCg6OCg8WEkkTqUoTViDDX1pI7bCHKDi3IjH1dsODatbMshI088mIV/JAuTA5k6TKhpM1CYbgViqy+nYf22Kme/hCAAiUWGBMB34z0Kcd2RFb+qQe1KOrBMcNsJrPAGTkgPlWHZqe8FFVnQasgzMt8sgsiN/KL0uz06dhH/Uiomr6lYjlww== 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=FO1kfhTaM1todax5POX7aSVcwUsiSdcV61tO5CXN5H0=; b=VOFkHhpnsGUwGtoiRRmMSQ+Yo3O24jQ/aMU9K9S/SoLbLzA6bKT/nlZ+tUJ2EDSVi1RCkh/+8GjjeuJ2nl9Tb6MQoWkWdGhSDEH7J+oj5QGlkAXsMgjXaqqFdtCXrRQxanDXy2yTr9HxwrrDd/eEEk34FqD6c6w1DWiC1K6FOs4I7S039xeVLzBpP1BT3gGTuWBUKHlIdkvmqSKF90QR/RYu3QnCb9MDZZZGAYViMxyBBtiGwgpsrWyIAl68kC1FuQN8clvd9lmugfwRCGBesIirr2UbH7vDVWMFzgY7NcOJ24yCZHDCEQyz2ySahewAN+sYWPuPYKdkeJ4yHaZB3A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ribose.com; dmarc=pass action=none header.from=ribose.com; dkim=pass header.d=ribose.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FO1kfhTaM1todax5POX7aSVcwUsiSdcV61tO5CXN5H0=; b=T71Ze+BYIHMF1yQKxcURGYxqMB4uuT4sAGIr3o0wQj33BYhZYr9xp12Fltdbo2bjZh0wXsXXLLU8UWjAiN0ozdg51EnG0DsAVn1FPcJFcjUpeqkkdjesVxS/taOQaiyC6iVusCok3Q4LQfEdDQdRETjHO8wApwHKm9uu1T93ECs= Received: from HK0PR01MB2900.apcprd01.prod.exchangelabs.com (2603:1096:203:98::14) by HK0PR01MB2946.apcprd01.prod.exchangelabs.com (2603:1096:203:86::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Fri, 16 Oct 2020 04:15:34 +0000 Received: from HK0PR01MB2900.apcprd01.prod.exchangelabs.com ([fe80::950d:3e33:78e0:8c4c]) by HK0PR01MB2900.apcprd01.prod.exchangelabs.com ([fe80::950d:3e33:78e0:8c4c%4]) with mapi id 15.20.3455.035; Fri, 16 Oct 2020 04:15:33 +0000 From: Ronald Tse To: Ujjwal Sharma CC: Bron Gondwana , "calsify@ietf.org" Thread-Topic: [calsify] Getting started with the calendar persistence format Thread-Index: AQHWo0GwGjTIredru0qplU+nj0MZpqmZX5UAgAA/4QA= Date: Fri, 16 Oct 2020 04:15:33 +0000 Message-ID: References: <668b5100-aab0-4353-bc11-132ed1f3785a@dogfood.fastmail.com> In-Reply-To: <668b5100-aab0-4353-bc11-132ed1f3785a@dogfood.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.1) authentication-results: igalia.com; dkim=none (message not signed) header.d=none;igalia.com; dmarc=none action=none header.from=ribose.com; x-originating-ip: [118.140.121.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6669b92f-da78-4bf7-340e-08d8718a2093 x-ms-traffictypediagnostic: HK0PR01MB2946: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: niX+ND4mccGGLH6i/3bEjeksI0xJ83j9lwItju3GP59+qPBHaPgTcM8W27S4er9+qx9hoZ4BNcCUh5gyhIpp+HW3r7eHkUFISb7k8buv8UjvcnNTALw+BeSh/DTY+FigpIiZ/ILAyI9JaYuT5THMSBIQM+eaVa40Jw5/YI/rlqQIQeqIYNxvmoh+8+gZk0lf4Ew2myPl0yk8vkLEglZ1JsxDT/UW8rBgikseDfGZHE7I5TdyKXmySQQGyH4UfbZ+nYVqXRRQwfjuzgPvHsqTj1Tj4IicLn9ChNBF70t4p88X8+RTJfJKvkWcaRjgVZ/j3P+DmiZJr9zAJlxoKLJIPaUrMUKBikLy6Z7o0DwaNXvcsmq2sZGhzjNPwWG/0fct5BvgiyXVXQrrgkRyNNmGsQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HK0PR01MB2900.apcprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(136003)(366004)(39830400003)(346002)(376002)(396003)(66556008)(8676002)(66446008)(478600001)(64756008)(66476007)(83380400001)(53546011)(6506007)(6486002)(54906003)(26005)(2906002)(71200400001)(6512007)(4326008)(166002)(86362001)(36756003)(76116006)(966005)(6916009)(91956017)(2616005)(316002)(66946007)(8936002)(5660300002)(186003)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: W/IhXD5IHHfgeRrVhn5d37rRaEXA+IfvbBRLKOVc3IXvdZaq714j/ggZFcVn1RWPbipCBwi07VAYh7xn+KA4IsIMhI2WHB2CpxqlbJrWwJu6u9wqGelWFRAq7P3ru4rv/CCHio5BE2+OlsEQQmE0EfwC9XxtxhJ8Wbcdanku/kaHa0mQvucA/ofnLB5b09gE4X9zzNeBWLv9Ys97RSB6ex1olBLrVa76Q1sXkLXcHgskCcrMejDlirNFIovhRzlcbThNMWTA56zyiTlezRqHFYob+PvEZgCPYf6gIQOTvYAjx35PJMn+maYCfisjn3jsQRjJEYX3W381NomyQUHCyUVLs+bhHY2XOn4L9dIvECsa/mPLQoDnSeMYq+7eSQ1BZuw3O80aQ8nVaGE924E5uaRHSu/afQcT5y/CvPPlicBTTKPy6XS7NGMW3QnqTJgHcv6radOFGK0/ZvOlNQ2xCKrrxmkVmzkX6kcLGcHv9afrYD/2SiXu5CS2uujmChe1oENI4517TGYJsI6k0CywMgjIfGjTqPXDy3tuV51J+uUa8hJUiNYCe7W6yWdr0yMmlEI53bwiaqLxspKWYM10WdPofaPbkNIBVhfgf9+qjl3EIxYfQ/yFWauAub6fzHlm8h+ApLKWLy2GnVDVoyM/Rg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F5EE66577355417E9BE7E082138C6275RIBOSECOM_" MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HK0PR01MB2900.apcprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6669b92f-da78-4bf7-340e-08d8718a2093 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2020 04:15:33.5850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 8cIkEZqvzaxQrwtvxNLvNoWCM/MQvJhhlBGLnYemmFYXhDUnW+kpdBX0YCJvTvfP X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK0PR01MB2946 Archived-At: Subject: Re: [calsify] Getting started with the calendar persistence format 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, 16 Oct 2020 04:15:46 -0000 --_000_F5EE66577355417E9BE7E082138C6275RIBOSECOM_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVWpqd2FsLA0KDQooVGhhbmtzIEJyb24gZm9yIHRoZSBwbHVnISkNCg0KTWV0YW5vcm1hIGlz IG9uZSBvZiB0aGUgb2ZmaWNpYWxseSBsaXN0ZWQgcHJvY2Vzc29ycyBmb3IgSUVURiBkb2N1bWVu dHMgKGFsb25nc2lkZSBtbWFyayBhbmQga3JhbWRvd24tcmZjMjYyOSkuDQoNCkNhbENvbm5lY3Qg dXNlcyBNZXRhbm9ybWEgdG8gcHVibGlzaCBzdGFuZGFyZHMsIGFuZCBhIG51bWJlciBvZiBTRE9z IGRvIHNvIGFzIHdlbGwgKElUVSwgT0dDLCBCSVBNLCB3aG8gYWxzbyB3b3JrIHdpdGggZGF0ZS90 aW1lKS4NCg0KSWYgdGhlcmUgaXMgYW55IGludGVudGlvbiB0byBjcm9zcy1wdWJsaXNoIGludG8g Q2FsQ29ubmVjdCBvciBJU08sIHRoZSBhYmlsaXR5IHRvICJ3cml0ZSBvbmNlLCBwdWJsaXNoIGFu eXdoZXJl4oCdIGJlY29tZXMgaW1wb3J0YW50Lg0KDQpHaXZlbiB0aGF0IHdl4oCZcmUgdGhlIGZv bGtzIGJlaGluZCBpdCwgSeKAmW0gaGFwcHkgdG8gc2VydmUgYXMgeW91ciBwZXJzb25hbCBzdXBw b3J0IGlmIHlvdSBydW4gaW50byBhbnkgTWV0YW5vcm1hIHByb2JsZW1zIDotKQ0KDQpLaW5kIHJl Z2FyZHMsDQpSb24NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KUm9u YWxkIFRzZQ0KUmlib3NlIEluYy4NCg0KT24gT2N0IDE2LCAyMDIwLCBhdCA4OjI3IEFNLCBCcm9u IEdvbmR3YW5hIDxicm9uZ0BmYXN0bWFpbHRlYW0uY29tPG1haWx0bzpicm9uZ0BmYXN0bWFpbHRl YW0uY29tPj4gd3JvdGU6DQoNCu+7vw0KSGkgVWpqd2FsLA0KDQpUaGVyZSdzIGEgdmFyaWV0eSBv ZiBvcHRpb25zIGZvciB3cml0aW5nIGRyYWZ0cy4gIEkgcGVyc29uYWxseSB1c2UgYSB3b3JrZmxv dyBiYXNlZCBvbiBtbWFyaywgZm9yIGV4YW1wbGU6DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9icm9u Zy9kcmFmdC1nb25kd2FuYS1lZmZlY3RpdmUtdGVybWlub2xvZ3kNCg0KVGhlcmUncyBhbHNvIG1l dGFub3JtYSwgd2hpY2ggYWxsb3dzIHlvdSB0byBjcmVhdGUgYSB2YXJpZXR5IG9mIG91dHB1dHMu ICBUaGVyZSdzIGRvY3VtZW50YXRpb24gaGVyZToNCg0KaHR0cHM6Ly93d3cubWV0YW5vcm1hLmNv bS9hdXRob3IvaWV0Zi8NCg0KT3IgeW91IGNhbiB1c2UgdG9vbHMgbGlrZToNCg0KaHR0cHM6Ly9n aXRodWIuY29tL2NhYm8va3JhbWRvd24tcmZjMjYyOQ0KDQpCYXNpY2FsbHksIHRoZXkncmUgYWxs IHRvb2xjaGFpbnMgdGhhdCBnZW5lcmF0ZSBSRkMgWE1MIGZvcm1hdCBkb2N1bWVudHMuDQoNCklu IG9yZGVyIHRvIHB1Ymxpc2ggdG8gdGhlIElFVEYsIHlvdSBuZWVkIGEgZGF0YXRyYWNrZXIgYWNj b3VudCwgYW5kIHlvdSdsbCBuZWVkIHRvIHVwbG9hZCB0aGVyZToNCg0KaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9zdWJtaXQvdG9vbC1pbnN0cnVjdGlvbnMvDQoNCkNoZWVycywNCg0KQnJv bi4NCg0KT24gRnJpLCBPY3QgMTYsIDIwMjAsIGF0IDA5OjIxLCBVamp3YWwgU2hhcm1hIHdyb3Rl Og0KSGVsbG8gZXZlcnlvbmUhDQoNClRoYW5rcyBmb3IgdGhlIGFtYXppbmcgZGlzY3Vzc2lvbnMg YW5kIGhlbHAgeWVzdGVyZGF5LiBHaXZlbiBvdXINCmNvbnN0cmFpbmVkIHRpbWVsaW5lLCBJIHN1 cHBvc2UgSSBzaG91bGQgc3RhcnQgd29ya2luZyBvbiB0aGUgZHJhZnRzDQppbW1lZGlhdGVseS4N Cg0KT24gdGhlIElFVEYgc2lkZSBvZiB0aGluZ3MsIEkgc3VwcG9zZSBJJ2QgbmVlZCB0byBzdGFy dCBieSBjcmVhdGluZyBhbg0KSS1EPyBJcyB0aGVyZSBhIHNldCBvZiByZXNvdXJjZXMgeW91IGNv dWxkIHBvaW50IG1lIHRvIGluIG9yZGVyIHRvIGdldA0KdXAgYW5kIHJ1bm5pbmcgcXVpY2tseT8N Cg0KQWxzbywgd2hhdCBzaG91bGQgSSBkbyB0byBnZXQgdGhlIGJhbGwgcm9sbGluZyBvbiB0aGUg Q2FsQ29ubmVjdC9JU08NCnNpZGUgb2YgdGhpbmdzPw0KDQpCZXN0LA0KVWpqd2FsDQoNCi0tDQpV amp3YWwgIlJ5em9rdWtlbiIgU2hhcm1hIChoZS9oaW0pDQoNCkNvbXBpbGVycyBIYWNrZXIsIE5v ZGUuanMgQ29yZSBDb2xsYWJvcmF0b3IgYW5kIFNwZWFrZXINCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY2Fsc2lmeSBtYWlsaW5nIGxpc3QNCmNh bHNpZnlAaWV0Zi5vcmc8bWFpbHRvOmNhbHNpZnlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NhbHNpZnkNCg0KDQpBdHRhY2htZW50czoNCg0KICAqICAg c2lnbmF0dXJlLmFzYw0KDQotLQ0KICBCcm9uIEdvbmR3YW5hLCBDRU8sIEZhc3RtYWlsIFB0eSBM dGQNCiAgYnJvbmdAZmFzdG1haWx0ZWFtLmNvbTxtYWlsdG86YnJvbmdAZmFzdG1haWx0ZWFtLmNv bT4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Y2Fsc2lmeSBtYWlsaW5nIGxpc3QNCmNhbHNpZnlAaWV0Zi5vcmc8bWFpbHRvOmNhbHNpZnlAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NhbHNpZnkNCg== --_000_F5EE66577355417E9BE7E082138C6275RIBOSECOM_ Content-Type: text/html; charset="utf-8" Content-ID: <2CB43F5E3D4C804E87A1A37CA0D542D5@apcprd01.prod.exchangelabs.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBjbGFzcz0iIj4NCjxk aXYgZGlyPSJsdHIiIGNsYXNzPSIiPkhpIFVqandhbCw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQooVGhhbmtzIEJyb24gZm9yIHRoZSBwbHVnISkNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk1ldGFub3JtYSBpcyBvbmUgb2YgdGhlIG9mZmlj aWFsbHkgbGlzdGVkIHByb2Nlc3NvcnMgZm9yIElFVEYgZG9jdW1lbnRzIChhbG9uZ3NpZGUgbW1h cmsgYW5kIGtyYW1kb3duLXJmYzI2MjkpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Q2FsQ29ubmVjdCB1c2VzIE1ldGFub3JtYSB0byBw dWJsaXNoIHN0YW5kYXJkcywgYW5kIGEgbnVtYmVyIG9mIFNET3MgZG8gc28gYXMgd2VsbCAoSVRV LCBPR0MsIEJJUE0sIHdobyBhbHNvIHdvcmsgd2l0aCBkYXRlL3RpbWUpLjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SWYgdGhlcmUgaXMg YW55IGludGVudGlvbiB0byBjcm9zcy1wdWJsaXNoIGludG8gQ2FsQ29ubmVjdCBvciBJU08sIHRo ZSBhYmlsaXR5IHRvICZxdW90O3dyaXRlIG9uY2UsIHB1Ymxpc2ggYW55d2hlcmXigJ0gYmVjb21l cyBpbXBvcnRhbnQuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj5HaXZlbiB0aGF0IHdl4oCZcmUgdGhlIGZvbGtzIGJlaGluZCBpdCwgSeKA mW0gaGFwcHkgdG8gc2VydmUgYXMgeW91ciBwZXJzb25hbCBzdXBwb3J0IGlmIHlvdSBydW4gaW50 byBhbnkgTWV0YW5vcm1hIHByb2JsZW1zIDotKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+S2luZCByZWdhcmRzLDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5Sb248L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0i Ij48IS0tIHNpZ25hdHVyZSBvcGVuIC0tPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiBy Z2JhKDI1NSwgMjU1LCAyNTUsIDApOyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClJvbmFsZCBUc2U8YnIg Y2xhc3M9IiI+DQpSaWJvc2UgSW5jLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvc3Bh bj48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+T24gT2N0IDE2LCAyMDIwLCBhdCA4OjI3IEFNLCBCcm9uIEdvbmR3YW5hICZs dDs8YSBocmVmPSJtYWlsdG86YnJvbmdAZmFzdG1haWx0ZWFtLmNvbSIgY2xhc3M9IiI+YnJvbmdA ZmFzdG1haWx0ZWFtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj7vu78NCjx0aXRsZSBjbGFzcz0iIj48L3RpdGxl Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7IiBjbGFzcz0iIj5IaSBVamp3YWwsPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsiIGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7 IiBjbGFzcz0iIj5UaGVyZSdzIGEgdmFyaWV0eSBvZiBvcHRpb25zIGZvciB3cml0aW5nIGRyYWZ0 cy4mbmJzcDsgSSBwZXJzb25hbGx5IHVzZSBhIHdvcmtmbG93IGJhc2VkIG9uIG1tYXJrLCBmb3Ig ZXhhbXBsZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFy aWFsOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpBcmlhbDsiIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9icm9uZy9k cmFmdC1nb25kd2FuYS1lZmZlY3RpdmUtdGVybWlub2xvZ3kiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0 aHViLmNvbS9icm9uZy9kcmFmdC1nb25kd2FuYS1lZmZlY3RpdmUtdGVybWlub2xvZ3k8L2E+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsiIGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7 IiBjbGFzcz0iIj5UaGVyZSdzIGFsc28gbWV0YW5vcm1hLCB3aGljaCBhbGxvd3MgeW91IHRvIGNy ZWF0ZSBhIHZhcmlldHkgb2Ygb3V0cHV0cy4mbmJzcDsgVGhlcmUncyBkb2N1bWVudGF0aW9uIGhl cmU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsi IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 QXJpYWw7IiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3d3dy5tZXRhbm9ybWEuY29tL2F1dGhv ci9pZXRmLyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cubWV0YW5vcm1hLmNvbS9hdXRob3IvaWV0Zi88 L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsi IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6 QXJpYWw7IiBjbGFzcz0iIj5PciB5b3UgY2FuIHVzZSB0b29scyBsaWtlOjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7IiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsOyIgY2xhc3M9IiI+ PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NhYm8va3JhbWRvd24tcmZjMjYyOSIgY2xhc3M9 IiI+aHR0cHM6Ly9naXRodWIuY29tL2NhYm8va3JhbWRvd24tcmZjMjYyOTwvYT48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsOyIgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDsiIGNsYXNz PSIiPkJhc2ljYWxseSwgdGhleSdyZSBhbGwgdG9vbGNoYWlucyB0aGF0IGdlbmVyYXRlIFJGQyBY TUwgZm9ybWF0IGRvY3VtZW50cy48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkFyaWFsOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTpBcmlhbDsiIGNsYXNzPSIiPkluIG9yZGVyIHRvIHB1Ymxpc2ggdG8g dGhlIElFVEYsIHlvdSBuZWVkIGEgZGF0YXRyYWNrZXIgYWNjb3VudCwgYW5kIHlvdSdsbCBuZWVk IHRvIHVwbG9hZCB0aGVyZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OkFyaWFsOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpBcmlhbDsiIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvc3VibWl0L3Rvb2wtaW5zdHJ1Y3Rpb25zLyIgY2xhc3M9IiI+aHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9zdWJtaXQvdG9vbC1pbnN0cnVjdGlvbnMvPC9hPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7IiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsOyIgY2xh c3M9IiI+Q2hlZXJzLDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1p bHk6QXJpYWw7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkFyaWFsOyIgY2xhc3M9IiI+QnJvbi48L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OkFyaWFsOyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPk9uIEZyaSwgT2N0IDE2LCAyMDIwLCBhdCAwOToyMSwgVWpqd2FsIFNoYXJtYSB3cm90ZTo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGlkPSJxdCIgc3R5 bGU9IiIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkhlbGxvIGV2ZXJ5b25lITxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+VGhhbmtzIGZvciB0aGUgYW1hemluZyBkaXNjdXNzaW9ucyBhbmQgaGVscCB5ZXN0ZXJk YXkuIEdpdmVuIG91cjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5jb25zdHJh aW5lZCB0aW1lbGluZSwgSSBzdXBwb3NlIEkgc2hvdWxkIHN0YXJ0IHdvcmtpbmcgb24gdGhlIGRy YWZ0czxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5pbW1lZGlhdGVseS48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPk9uIHRoZSBJRVRGIHNpZGUgb2YgdGhpbmdzLCBJIHN1cHBvc2UgSSdkIG5l ZWQgdG8gc3RhcnQgYnkgY3JlYXRpbmcgYW48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+SS1EPyBJcyB0aGVyZSBhIHNldCBvZiByZXNvdXJjZXMgeW91IGNvdWxkIHBvaW50IG1l IHRvIGluIG9yZGVyIHRvIGdldDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj51 cCBhbmQgcnVubmluZyBxdWlja2x5PzxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QWxzbywgd2hhdCBzaG91bGQg SSBkbyB0byBnZXQgdGhlIGJhbGwgcm9sbGluZyBvbiB0aGUgQ2FsQ29ubmVjdC9JU088YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+c2lkZSBvZiB0aGluZ3M/PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5CZXN0LDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Vamp3YWw8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPi0tJm5ic3A7PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlVqandhbCAmcXVvdDtSeXpva3VrZW4mcXVvdDsgU2hhcm1hIChoZS9oaW0pPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5Db21waWxlcnMgSGFja2VyLCBOb2RlLmpzIENvcmUgQ29sbGFib3JhdG9yIGFuZCBTcGVh a2VyPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Y2Fsc2lmeSBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOmNhbHNpZnlAaWV0Zi5v cmciIGNsYXNzPSIiPmNhbHNpZnlAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2Fsc2lmeSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jYWxzaWZ5PC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiIGNsYXNzPSIiPkF0dGFjaG1lbnRzOjwvYj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjx1bCBjbGFzcz0iIj4NCjxsaSBjbGFzcz0iIj5zaWduYXR1cmUuYXNjPGJyIGNsYXNzPSIi Pg0KPC9saT48L3VsPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6QXJp YWw7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgaWQ9InNpZzU2NjI5NDE3 IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9InNpZ25hdHVyZSI+LS08YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9InNpZ25hdHVyZSI+Jm5ic3A7IEJyb24gR29uZHdhbmEsIENFTywgRmFz dG1haWwgUHR5IEx0ZDxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ic2lnbmF0dXJl Ij4mbmJzcDsgPGEgaHJlZj0ibWFpbHRvOmJyb25nQGZhc3RtYWlsdGVhbS5jb20iIGNsYXNzPSIi PmJyb25nQGZhc3RtYWlsdGVhbS5jb208L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSJzaWduYXR1cmUiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpBcmlhbDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPHNw YW4gY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+Y2Fsc2lmeSBtYWlsaW5nIGxp c3Q8L3NwYW4+PGJyIGNsYXNzPSIiPg0KPHNwYW4gY2xhc3M9IiI+PGEgaHJlZj0ibWFpbHRvOmNh bHNpZnlAaWV0Zi5vcmciIGNsYXNzPSIiPmNhbHNpZnlAaWV0Zi5vcmc8L2E+PC9zcGFuPjxiciBj bGFzcz0iIj4NCjxzcGFuIGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2Fsc2lmeSIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jYWxzaWZ5PC9hPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F5EE66577355417E9BE7E082138C6275RIBOSECOM_-- From nobody Thu Oct 15 22:50:38 2020 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 49BCA3A0C96 for ; Thu, 15 Oct 2020 22:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=WvsvPpHJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=L6zvU/7T 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 nNc_odeoGgyr for ; Thu, 15 Oct 2020 22:50:34 -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 5AD033A0C8F for ; Thu, 15 Oct 2020 22:50:34 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 734B55C017E; Fri, 16 Oct 2020 01:50:33 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Fri, 16 Oct 2020 01:50:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm1; bh=n1lZzFV FjCE45G9XlRMz0QoSc2ZNTp8TvwABMDzRWGk=; b=WvsvPpHJVCH6LABf6pmLH6E SDGUXxmB4xzBr0bQiRVCyx7x7/OXAG43gG4EjL0JxrFNOGz4In89kfIi+h82XRnN pthdoD9bwpXZc0hla/2/d8LmycaEBE7Ko1LDptPlKaUKMcTNJbLQ+WmUWARhoY1Y v4q5VoP6tIfWOffXt4BsSbITIC+HTZuSBgPeektH97QzgK7D1w1pdkQQZATzr69f yF1T4HrG3Cj8TdJbyWL9hG6w+tCvmG0HSayYpK1cn1lkDQH1XH27PhQ5qlDNQgt6 NdSuVM849z8/sek3+aLYeyro9qgBr1iSqL+/ugv8Spzwm5j9cEd0qsCgnixYDXQ= = 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=fm1; bh=n1lZzF VFjCE45G9XlRMz0QoSc2ZNTp8TvwABMDzRWGk=; b=L6zvU/7TH/MV1mOhGqcyz0 7Z8nlJ8iOFfO+2uQ2MNX5zWdmznuZJQH2ktrnGGtXentMa4zCZ5uPjhikH+eBo40 lWqmqhEiKbk8bwErhLE9ermwQCdEyQn5TxbudAgxOT5as+MgifHhWObm7NZjGCjV rZcScTJo+2L//MoTdtxZkFAWZb7t0X2Zg6bDgA3dwJk0o5vbIUoUMb8Jk1w4rt72 Rzt6x681XzVVaB9ZkmrmY50+XtDqMHWrGPpKUM9P7RiW/eBttkLHlQCccrP4i5c0 gDMYTmawB0/exMKe5BZCSmLwtKCD8W18Sj2SThBVld97UC/iYDLi41P694l4S3wg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieeggddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeevvdetvdduleekhfeghfetfeettdelhfehfeevffevleek uddtudffieevjeevhfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0D9751800F1; Fri, 16 Oct 2020 01:50:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: <9a2c28d5-8221-49f3-a2a2-60a6e8a8e58d@dogfood.fastmail.com> In-Reply-To: References: <7867c58d-22f6-393f-1ff1-ec822c5bf4af@gmail.com> <5efa5cfb-624c-4e96-a7d5-7d23beeff47b@dogfood.fastmail.com> Date: Fri, 16 Oct 2020 16:50:25 +1100 From: "Neil Jenkins" To: "Michael Douglass" , calsify@ietf.org Content-Type: multipart/alternative; boundary=a26a296721044047aade39607d7c7637 Archived-At: Subject: Re: [calsify] Issues with overrides. 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, 16 Oct 2020 05:50:36 -0000 --a26a296721044047aade39607d7c7637 Content-Type: text/plain We discussed this at the interim calext meeting and I have proposed the following: * In the iCalendar <-> JSCalendar translation document, we will register a `recurrenceIdTimeZone` property. This is an optional property that can be used store the time zone identifier of the iCalendar recurrence id if different to the event's time zone. * This is only needed for iCalendar compatibility so does not belong in the core JSCalendar specification. * If a server issues an iTIP message in JSCalendar it can include this property in the JSCalendar version so that even if it is translated into iCalendar somewhere along the way and comes back to the server as iCalendar, it will include the correct time zone identifier. (Alternatively, the server may just ignore the time zone on the recurrence id in the iCalendar response and handle it as though it had received JSCalendar back, but either way it's in control.) Neil. --a26a296721044047aade39607d7c7637 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
We discuss= ed this at the interim calext meeting and I have proposed the following:=
  • In the iCalendar <-> JSCalendar translation docu= ment, we will register a recurrenceIdTimeZone p= roperty. This is an optional property that can be used store the time zo= ne identifier of the iCalendar recurrence id if different to the event's= time zone.
  • This is only needed for iCalendar compatibility = so does not belong in the core JSCalendar specification.
  • If = a server issues an iTIP message in JSCalendar it can include this proper= ty in the JSCalendar version so that even if it is translated into iCale= ndar somewhere along the way and comes back to the server as iCalendar, = it will include the correct time zone identifier. (Alternatively, the se= rver may just ignore the time zone on the recurrence id in the iCalendar= response and handle it as though it had received JSCalendar back, but e= ither way it's in control.)
Neil.
--a26a296721044047aade39607d7c7637-- From nobody Thu Oct 15 22:58:08 2020 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 9F94D3A0CC1 for ; Thu, 15 Oct 2020 22:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmailteam.com header.b=K+bmJ1Dh; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FWTGV7xH 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 ZjERWDJvsC0N for ; Thu, 15 Oct 2020 22:58:05 -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 ACF583A0CBD for ; Thu, 15 Oct 2020 22:58:05 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B32FF5C0172 for ; Fri, 16 Oct 2020 01:58:04 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute3.internal (MEProxy); Fri, 16 Oct 2020 01:58:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm1; bh=DKLFLmHg+m0+vd27VxAZuNkxY2GeXpMnY7xKIDH WHNY=; b=K+bmJ1DhAZ1/HgT3GyMD5CpT3WldJfZ6y49A0pR/qA8GgbJLrc7n1z4 Aa8pUx92GU/CkGV1Cj6hou2eN04jz5SNjT3rkRm4dGoSPclruyCABIzmBY4OkgOc R+QwGV8AsjcoUYHtd6wjcIT92LptC/F8pahKAcOh0/ZNMbjOKgQDJi54xphte4PT a5+mJ4dl5Swlhqp6EG8h1tHCgMTCJowjHCWtSVCgjBopPo0Wg9vmW5hgM774UrxZ uOmSusoIbrL0jagtaWy4z+LAk+tByo2Pv2K9iRuFiIgn+fJZ10M3du5rkgiWGUe0 IgrPX83/TB+xrRanLzllXOYBoKnxYig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=DKLFLmHg+m0+vd27VxAZuNkxY2GeX pMnY7xKIDHWHNY=; b=FWTGV7xHv1yeVo6q5VwZJarqp9m++ZyPOtH03EWHPIEeU X5w/6uvzKnk92ebfJTI+LsvULYGKpg8T8axy5FmEEOMUi/aFQtJgXHxq53pj1UAx 6Tnjfliry0C53kZJF2OfzBP81xmlSxqZ21tTWnFl7jsd7Zw8CljUnNYsMB3o6Kap haDtnt30hm3AeZtGT2qH96OSa00QkZhMvR1s46N+rnW6kO2O7CR7st5+6ucb/xDt Y3NSFeO70b8F2Ph/Luuw3FK98c9TMXkRSINpqD1KQrUY4HSSvtE2Y0aDrXOQBStp Wd0EGkBheBD0Os6csjjH+TLoSStloDrzHndjvv1ZQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieeggddutddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erredtnecuhfhrohhmpedfpfgvihhlucflvghnkhhinhhsfdcuoehnvghilhhjsehfrghs thhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepiedtjeejleeijeefud eugfeihfeuveeggfefjeegleefffetudevgfelvdejieegnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehnvghilhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 680C91800F1; Fri, 16 Oct 2020 01:58:04 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-489-gf39678d-fm-20201011.001-gf39678d0 Mime-Version: 1.0 Message-Id: <33fa80c9-cd84-4dc0-a8c2-882dd8e24258@dogfood.fastmail.com> Date: Fri, 16 Oct 2020 16:58:04 +1100 From: "Neil Jenkins" To: calsify@ietf.org Content-Type: multipart/alternative; boundary=21398a3c102c4037839a6694427ce2b4 Archived-At: Subject: [calsify] JSON pointer fragment for JSCalendar 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, 16 Oct 2020 05:58:08 -0000 --21398a3c102c4037839a6694427ce2b4 Content-Type: text/plain This email is just to notify the group of a change I made to the JSCalendar media type registration in the latest draft in response to Benjamin Kaduk's feedback. The change is to allow a JSON pointer fragment identifier to be used when referring to a JSCalendar document via a URI. This means that you could construct a URI with a reference to a specific sub-object inside the JSCalendar file (particularly useful when there's a JSGroup top-level object so you can reference a specific event/task inside it). This seemed very useful to me and I couldn't see any downsides to allowing it, but if anyone has an objection please speak up now! Cheers, Neil. --21398a3c102c4037839a6694427ce2b4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
This email is j= ust to notify the group of a change I made to the JSCalendar= media type registration in the latest draft in response to Benjamin= Kaduk's feedback. The change is to allow a JSON pointer fragment identifier to be= used when referring to a JSCalendar document via a URI.
<= br>
This means that you could construct a URI with a reference= to a specific sub-object inside the JSCalendar file (particularly usefu= l when there's a JSGroup top-level object so you can reference a specifi= c event/task inside it). This seemed very useful to me and I couldn't se= e any downsides to allowing it, but if anyone has an objection please sp= eak up now!

Cheers,
Neil.
=
--21398a3c102c4037839a6694427ce2b4-- From nobody Thu Oct 15 23:08:21 2020 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 AEBC93A0CD8; Thu, 15 Oct 2020 23:08:19 -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: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <160282849957.27999.1556379036823281494@ietfa.amsl.com> Date: Thu, 15 Oct 2020 23:08:19 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-32.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: Fri, 16 Oct 2020 06:08:20 -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-32.txt Pages : 85 Date : 2020-10-15 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 jCal format, which is also JSON-based, JSCalendar is not a direct mapping from iCalendar, but defines the data model independently 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-32 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-32 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-32 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 Fri Oct 16 11:35:04 2020 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 154EB3A03F2; Fri, 16 Oct 2020 11:34:58 -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: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <160287329801.13575.6476139980278266084@ietfa.amsl.com> Date: Fri, 16 Oct 2020 11:34:58 -0700 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-16.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: Fri, 16 Oct 2020 18:34:58 -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 : Event Publishing Extensions to iCalendar Author : Michael Douglass Filename : draft-ietf-calext-eventpub-extensions-16.txt Pages : 36 Date : 2020-10-16 Abstract: This specification updates RFC5545 by introducing a number of new iCalendar properties and components which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar RFC5545 to allow for data that is directly pertinent to an event or task to be included with the calendar data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-16 https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-16 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 Fri Oct 16 11:35:28 2020 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 955673A0924; Fri, 16 Oct 2020 11:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.213, 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 zsyV_B12JgNm; Fri, 16 Oct 2020 11:35:14 -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 3532C3A0855; Fri, 16 Oct 2020 11:35:13 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id c5so2202813qtw.3; Fri, 16 Oct 2020 11:35:13 -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=btP81BcJmk+uU1nVlPqAcG20bJOLXTwvgIe+zwM3eOE=; b=U8LOjpizvNcVpfMZYyfzLHMhzC5BF+/GAqiO4qVDt+NlKQ7mZUnmQEXtuSsntkJfms MmN960KepKMjSteGDkxCTozE6UcxJ88VbvChfUIYaPtj69tWUN8naLCMb6MBkU5Pnp2Q s9I2keGNekQVBbL5F6x1BwlUeaWk6BMuRraFK+x8oSYVRkgL73FN87Gp3G6yi2lMz2q9 8fVSY0lUBcAyOREKN8tAx7rQl+38miV8cG218nVBKyZBPV+6WF2Dt2oqzV+edDFlrDqy K1jZBhQRB5HrLH+gg7fBRcbMpbs7JLgOUAGY7mlkmxlqQdgFs0yVjE9kNisDByF0VAGX r+yg== 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=btP81BcJmk+uU1nVlPqAcG20bJOLXTwvgIe+zwM3eOE=; b=HM4p7FRzLSu5xIO6sexmOUcf8qlec39oOM57UCcekgIlGH+urhrnePX/EWlHRxfGi5 MAFy7UcoIIYfQLX3zdeKwkERq5G1jFY5jeLW88RB5tV9vRbtUTyuoizTZhR8eJRfyCw9 pa4rJRqeL8TkM808DFNd7xNMYOFGTpxfSSH+sDKLwIPa/wDPQCu24n5JkZLnReV00VM4 IZIVrLIMWxteG1sDy1fGdtXndRbTG55HDSDekjfIWKcfkJ6UR2/fmvLhLG9vzmNrCVxE DvLuJfKCAt/WAA9CtKk0cXiV23u8sa3JnoTN9R9sSNExB+p6vPJyz2DTTCz46njK9xdc wAyg== X-Gm-Message-State: AOAM532VwWWLU/EKuobHAKftSpTdjzrQkWJrxO7UiJKUjrxFtNJMbrpd hkXxuz7IGLfXqmpe2Nn3l8bPpNJ0P24= X-Google-Smtp-Source: ABdhPJzVzmhFkYNFSFDZd2hHLWsb6X546RO8uJviD2Km97VaMj570iR1YMGEqHHg6bRFyM9Zsp7Sfw== X-Received: by 2002:aed:2ba6:: with SMTP id e35mr4724895qtd.251.1602873311790; Fri, 16 Oct 2020 11:35:11 -0700 (PDT) Received: from MBP-2019.nycap.rr.com (cpe-74-70-80-66.nycap.res.rr.com. [74.70.80.66]) by smtp.googlemail.com with ESMTPSA id t12sm1164613qkg.132.2020.10.16.11.35.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 16 Oct 2020 11:35:11 -0700 (PDT) To: Benjamin Kaduk , The IESG Cc: draft-ietf-calext-eventpub-extensions@ietf.org, calext-chairs@ietf.org, calsify@ietf.org References: <155908852723.25806.3708247030243239163.idtracker@ietfa.amsl.com> From: Michael Douglass Message-ID: Date: Fri, 16 Oct 2020 14:35:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <155908852723.25806.3708247030243239163.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-eventpub-extensions-13: (with DISCUSS and COMMENT) 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, 16 Oct 2020 18:35:23 -0000 A rather delayed reply to your original message: Thank you for the suggestions. I'll submit a version 16 to refresh the draft and, I hope, fix the remaining issues Note that I'd like in particular some feedback on the security/privacy section. On 5/28/19 20:08, Benjamin Kaduk via Datatracker wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-calext-eventpub-extensions-13: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I want to talk some about the redefinition of SOURCE. While I agree > that the original definition's applicability is more narrow than it > needs to be, that doesn't seem to be enough to convince me that there's > enough justification to make it so broad as to provide vcard information > about a participant or an event link-back, as opposed to just the > canonical source of updates for a given object/component. I must > apologize for having essentially not done a search of the WG discussion > archives for this topic, and pointers into the archive could help to > convince me that this redefinition is a stable, interoperable, and > backwards-compatible choice. This one I fixed with version 14. My comment and your reply at the time was: > On this particular issue I've come round to agreeing with the points > made here and in other messages. As an alternative i was considering > suggesting dropping the VALUE=TEXT. Having a vcard inline can always be > handled with a data uri. > > However, it seems to me that I can come closer to the intent by using > the STRUCTURED-DATA property - it is intended to provide supporting data > and of course there's no backwards compatibility issues. > > Does this seem an appropriate way forward? Your reply... > It seems appropriate to me (with the caveat that I am not a domain expert > here). > > The example in Section 5.4: > > STRUCTURED-DATA;FMTTYPE=application/ld+json; > SCHEMA="https://schema.org/FlightReservation"; > ENCODING=BASE64;VALUE=BINARY:Zm9vYmFy > > contains an inline value that doesn't seem to decode to a valid > FlightReservation JSON object. You were correct - fixed the example in version 14 > > Perhaps I'm misreading, but the ABNF in Section 7.6 does not seem to > allow for an explicit VALUE=TEXT parameter to be given, and the > description does not list TEXT as the default value type. (I note that > the listed example does include VALUE=TEXT, causing this to rise to a > Discuss-level internal inconsistency.) This I missed - updated ABNF to make VALUE=TEXT required > > Similarly, the examples in Section 8.1 seem incomplete, since they omit > the REQUIRED dtstamp and uid properties. In v16 I made dtstamp optional. It is only needed for scheduling. Added UID to the examples. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 3 > > The properties defined here can all reference external meta-data > which may be used by applications to provide enhanced value to users. > > This sentence seems to raise my hackles for two reasons: (1) it reads > like marketing copy and not a technical specification, and (2) it calls > to mind analogies to all the privacy-harming technologies that have > become pervasive in HTML mail and the web ecosystem: tracking pixels, > call-home URLs, etc.. While I agree that loading remote content can be > helpful, it is definitely a dual-use technology; I appreciate that the > privacy considerations attempt to cover the risks of remote content. > Perhaps there is additional room to nod to those risks at this point in > the document. OK - toned it down a bit and added a caution. > > Using STRUCTURED-LOCATION, information about a number of interesting > locations can be communicated, for example, address, region, country, > postal code as well as other informations such as the parking, > restaurants and the venue. [...] > > nit: "the parking" is incomplete; perhaps "parking availability"? > nit: "restaurants" is also incomplete; perhaps "nearby restaurants"? > > In social calendaring it is often important > to identify the active participants in the event, for example a > school sports team, and the inactive participants, for example the > parents. > > I share the directorate reviewer's confusion as to what "social > calendaring" is. Added a section to describe what was meant > > Section 3.1.1 > > In addition, there will be sponsorship information for > sponsors of the event and perhaps paid sponsorship properties > essentially advertising local establishments. > > I'm not sure how much precedent the IETF has for facilitating > advertising as a specific goal. The IETF - like many organizations - welcomes sponsorship and provides advertising: https://ietf.org/about/support/meeting-sponsorship/ Having the opportunity to highlight that information is useful to event organizers. > > Section 3.1.2.1 > > A meeting may have 10 attendees non of which are co-located. The > > nit: s/non/none/ > > current ATTENDEE property does not allow for the addition of such > meta-data. The PARTICIPANT property allows attendees to specify > their location. > > nit: PARTICIPANT is a component, not a property. Fixed: > > Section 4 > > Please be more concrete about what actually is changing, e.g., the > addition of participantc to eventc/todoc/journalc, as well as the more > obvious incremental addition to the properties' ABNF. > Making the reader cross-reference to RFC 5545 for each ABNF production is > rather unfriendly. Added comments to the ABNF > > Section 5.2 > > Is a video remote conferencing facility assumed to also provide audio > functionality? > > Section 5.3 > > nit: "lowest level of ordering" is perhaps ambiguous (though the > subsequent clarification is not); I'd suggest just "as being ordered > last". > > Example uses: The ORDER may be applied to the PARTICIPANT-TYPE > property to indicate the relative importance of the participant, > for example as a sponsor or a performer. For example, ORDER=1 > could define the principal performer or soloist. > > side note: It's not very clear to me that it's going to be possible to > assign a complete ordering to all participants once events start getting > complicated. There is the option of just leaving a single low-priority > "everybody else" bucket and not worrying too hard, but this feels like > something easy that gets a quick win but will not be a full solution. > (Which, to be clear, is not necessarily bad.) > > Section 5.5 > > While I'm sympathetic to not actually putting a full HTML styled > description in the example, I'd suggest at least putting in the closing > tag. Done. > > Section 7.1 > > nit: is there a reason for active participants to be taking a "role" but > inactive ones taking a "part"? no -p changed > > Section 7.3 > > It's not clear to me when one would attach an alternative representation > to a STYLED-DESCRIPTION rather than just adding the other representation > as another STYLED-DESCRIPTION in its own right. Presumably this just > means I'm not an iCalendar expert, but maybe there is something more > subtle going on here. > > Section 7.4 > > Do we want a reference to RFC 7986 again for the LABEL parameter? Added a bunch > > When used in a component the value of this property provides > information about the event venue or of related services such as > parking, dining, stations etc.. > > Does this hold universally for all components (e.g., even PARTICIPANT) or > only some of them? > > I don't understand all the discussion about the "Use of the related > parameter", which is presumably just my lack of familiarity with > iCalendar in general. But it's surprising that we'd have to worry about > timezones and such for events/todos related to a structured *location*. This is to align with jscalendar > > Section 7.5 > > strucewaval = ( uri / text ) > > "strucewaval" seems like a typo and does not appear elsewhere in the > document. It was - corrected > > Section 8.1 > > Conformance: This component can be specified multiple times in a > "VEVENT", "VTODO", "VJOURNAL", or "VFREEBUSY" calendar component. > > Description: This component provides information about a participant > in an event, task or poll. [...] > > Why do these two lists have different cardinality? Changed wording > > Privacy Issues: When a LOCATION is supplied it provides information > about the location of a participant at a given time or times. > This may represent an unacceptable privacy risk for some > participants. User agents MUST NOT include this information > without informing the participant. > > How is this "informing" supposed to work when the participant is not a > human (e.g., an organizational SPONSOR or a sports team)? > > Also, it seems likely that there may be attributes (parameters) other > than location that a given individual may not wish to be disclosed, or > at least disclosed globally. I've added a comment in the privacy section and referred to that. Could you take a look at that please? > In the last example: > > BEGIN: PARTICIPANT > SOURCE;FMTTYPE=text/vcard; > > this last semicolon should be a colon? Gone as a result of other changes > > http://dir.example.com/vcard/contacts/contact1.vcf > PARTICIPANT-TYPE:CONTACT > DESCRIPTION:A contact: > > The last colon here is superflous? > > END:PARTICIPANT Yes > > Section 8.2 > > It's not entirely clear to me that we need this much discussion about > schedulable PARTICPANTs -- can't we get most of the way with the > status quo of ATTENDEE properties being schedulable, and just noting > that for such ATTENDEEs, the matching PARTICIPANT may have additional > (e.g., location) information? We lack a place in the 5545 spec for the SEQUENCE and DTSTAMP for the attendee. I wanted to point out this particular use. > > Section 9.1 > > This example seems to illustrate a weakness of STRUCTURED-LOCATION, > namely that it relies upon the human readaing the LABEL parameter to > understand what type of relationship the location has to the event. It > seems that calendaring software would be able to present a better > interface if there was some structured information available about the > type of location, as well as the freeform string of the label. That's the point of the LOCTYPE parameter > > Section 9.2 > > The time gap between DTSTAMP and CREATED is rather large; is that > intended? No - all the dates are getting old - refreshed them > > It might also be helpful to give some indication of the meeting room > where the event is nominally occurring, so as to make the "At home" > location more clearly a remote location. > > Section 10 > > Potential additional security considerations: the target of the > CALENDAR-ADDRESS URLs may have access control on them, and not all > recipients of the property may be authorized to access the referenced > calendar. Such access control is properly a matter for the owner of the > calendar in question, but it may still be appropriate to mention it > here. > > Security considerations relating to the "ATTACH" property, as > described in [RFC5545], are applicable to the "STRUCTURED-DATA" > property. > > I had a quick look in RFC 5545, and neither the labelled Security > Considerations section nor any mention of "ATTACH" (with quotes) seemed > to cover such security considerations. What am I missing? You are correct. I used a variant of the wording for managed attachments. > When processing HTML content applications need to be aware of the > many security and privacy issues as described in the IANA > considerations section of [W3C.REC-html51-20171003] > > nits: this needs at least a comma after "content", and possibly another > comma before "as described". > > Section 11 > > There may be some privacy considerations relating to the ORDER > parameter, as it provides an indication of some entity (the > organizer's?) perception of the relative importance of other > participants. > > The addition of location information to the new participant component > provides information about the location of participants at a given > time. > > We probably should go a little further and note that this may facilitate > tracking of individuals or malicious actions targeted against them at > the known location/time pair. I've added more text and aligned this to some extent with jscalendar. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Fri Oct 16 18:21:41 2020 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 B40343A0A96; Fri, 16 Oct 2020 18:21:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Phillip Hallam-Baker via Datatracker To: Cc: calsify@ietf.org, draft-ietf-calext-jscalendar.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160289769957.27431.527588870284609048@ietfa.amsl.com> Reply-To: Phillip Hallam-Baker Date: Fri, 16 Oct 2020 18:21:39 -0700 Archived-At: Subject: [calsify] Secdir telechat review of draft-ietf-calext-jscalendar-32 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: Sat, 17 Oct 2020 01:21:40 -0000 Reviewer: Phillip Hallam-Baker Review result: Ready The draft describes a calendar/task format that addresses identified issues in iCalendar. These appear to be handled satisfactorily. The Security Considerations section identifies the principle sources of concern. From nobody Sat Oct 17 13:43:10 2020 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 2A3E73A0ECC for ; Sat, 17 Oct 2020 13:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 WrXlt53IGC81 for ; Sat, 17 Oct 2020 13:43:06 -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 4613B3A0ABC for ; Sat, 17 Oct 2020 13:43:05 -0700 (PDT) Authentication-Results: mail.aegee.org/09HKggHw244907; auth=pass (LOGIN) smtp.auth=didopalauzov@aegee.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aegee.org; s=k4096; t=1602967381; i=dkim+MSA-tls@aegee.org; bh=SpiHdqJn61VtC7QzXbYEFWs8dvaBDRU3Ggzy253eVSk=; h=Subject:From:To:Date:In-Reply-To:References; b=BCGoTwk1/vtXL0A58cPIVc+R1k5VcG2+vaAkTHw9EnVOYOxEDRkbYHQlCWk5pone7 DceEek4H/lFwed4lnxN2FJLi11dwQw2NdHZ2gCAzOJkhOGLVEmgbvDms0GBArqvFKm b5sftOeYPG2yoyRS3sEE3js9kSulzuPWJwOOUxHS0Mvp0eFJJCzbcz59GWcmyhZl0m PaS+fuIdZ/cL1ZKw3NIpi894nYbqWrRwZ54kQUciKrH4HoiJBeYCuRm2MLeG37dzR1 MmI/ixeWlEKgF+stCJZdxXnHP/pXM/z+dNI1ZFC6FcTAmSKOEKa9eOZ/jsMohMmU/R INKuGvWGmKICgTn68kwau4oGZxxjJsvm8XCeK1oDJYmFkKC4qKxbCkZQ1pUp6Rlr6r 6KRtwWYikXvveVg8G+vtG5FkuIun1WB3ijUbhmi0Y9otj9jgS4ncAIEkAOYGHFWW68 ZTJvpBXh+UjmIHdladUv98QLU/TE6eAccEj4AZOb/+iVtudviK4Wo9KvbpaVNoz6lo jhggOky8l3zNleZnqz/UXDGYw5TR5g14sAH+b/PHmjfp2H+1qmNfCDa3dBznfHe1GI 2brz5HRgYi4+mgzsowY7jTNzR3D/i5f6c7M4otWkryzD0prga5sqLelQeZZ3EKGCHq Cglw0bMo32E6AtsRFNzVEFjU= Authentication-Results: mail.aegee.org/09HKggHw244907; dkim=none Received: from [192.168.1.99] (87.118.146.153.topnet.bg [87.118.146.153] (may be forged)) (authenticated bits=0) by mail.aegee.org (8.15.2/8.15.2) with ESMTPSA id 09HKggHw244907 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 17 Oct 2020 20:42:54 GMT Message-ID: <79daa7a2a7518f9ab26060be943538f266ec92ea.camel@aegee.org> From: =?UTF-8?Q?=D0=94=D0=B8=D0=BB=D1=8F=D0=BD_?= =?UTF-8?Q?=D0=9F=D0=B0=D0=BB=D0=B0=D1=83=D0=B7=D0=BE=D0=B2?= To: calsify@ietf.org Date: Sat, 17 Oct 2020 23:42:40 +0300 In-Reply-To: <160287329801.13575.6476139980278266084@ietfa.amsl.com> References: <160287329801.13575.6476139980278266084@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.39.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [calsify] I-D Action: draft-ietf-calext-eventpub-extensions-16.txt X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2020 20:43:09 -0000 Hello, 10. Privacy Considerations 10.1. Tracking Properties with a "URI" value type can expose their users to privacy leaks as any network access of the URI data can be tracked. Clients SHOULD NOT automatically download data referenced by the URI without explicit instruction from users. How about using data: uris, and fmttype parameter for the content-type, that contain vCard, instead of having STRUCTURED- LOCATION;VALUE=URI:https://example.example/abc.vcf? What is the way to download the referenced vCard simultaneously with the iCalendar, apart from the data: uri? I have now a bright idea: the STRUCTURED-DATA is changed from PROPERTY to COMPONENT with UID and is unencoded (as far as possible) blob. Then instead of VALUE=URI:https:// one can write VALUE=URI:attachment: or VALUE=URI:cid: (which is supposed to mean the URI within STRUCTURED- DATA). This basically unifies (base64 decoded) attachments and structured-data. 1.2. Terms Used in This Document Event: When the word 'event' is used (perhaps with a capitalised 'E' we are referring to gatherings, formal or informal. For example a sports event, a party or a concert. The square braket is not closed. What is the puropose of a PARTICIPANT in a VFREEBUSY component? Can you give a use-case? 6.2. Calendar Address The CALENDAR-ADDRESS property if present will provide a cal- address. If an ATTENDEE property has the same value the participant is considered schedulable. The PARTICIPANT component can be used to contain additional meta-data related to the attendee. If there is a related ATTENDEE proeprty then all parameters must be applied in that property. This property is defined by the following notation: caladdressparam = *( (";" schedulestatusparam) ) proeprty ⇒ property schedulestatusparam exists only for scheduled ATTENDEEs, probably only for CalDAV-scheduled (as opposed to iMIP scheduled by the CUA) attendees. A PARTICIPANT/CALENDAR-ADDRESS is only scheduled, if there is a corresponding ATTENDEE with the same value, in which case the ATTENDEE gets the schedulestatusparam. What does PARTICIPANT/CALENDAR- ADDRESS do with schedulestatusparam? 3. Typed References Using STRUCTURED-LOCATION, rich information about multiple locations can be communicated, for example, address, region, country, postal code as well as other information such as parking availability. Can you provide an example, that communicates postal code, address and region for a STRUCTURED-LOCATION? 5.3. Order orderparam = "ORDER" "=" integer ;Must be greater than or equal to 1 space after semi-colon. 6.3. Styled-Description Property Parameters: IANA, non-standard, id, alternate text representation, format type, derived and language property parameters can be specified on this property. https://www.iana.org/assignments/icalendar/icalendar.xhtml does not contain id property, neither does ABNF for styleddescparam. It would be good if the above Property Parameters are enumerated in the same order, that is used in the subsequent Formal Definition for styleddescparam. When RFC 5545 defines Property Parameters for a Property it puts AND before the last value. draft-ietf-calext-eventpub-extensions uses three times OR, twice AND before the last Property Parameter in the enumeration. The usage of the Oxford comma is inconsistent. 6.4. Structured-Location Value type: There is no default value type for this property. The value type can be set to URI or TEXT. Please provide an example for VALUE=TEXT, that uses all parameters. I want to see how LABEL and the TEXT value differ. Description: When a LABEL parameter is supplied the language of the label SHOULD match that of the content and of the LANGUAGE parameter if present. My understanding is that, apart from NAME at VCALENDAR-level and DESCRIPTION, but e.g. not for SUMMARY, any property/parameter can have up to one LANGUAGE and there is no way to specify the same information alternating in different languages in the same iCalendar object. This forces the user to read the information in whatever language it is provided, or skip it based on visual scan, as there is no alternative. LANGUAGE cannot be presented to the user. Does anybody have use cases for LANGUAGE in iCalendar? If elaborating on LANGUAGE is done here, it shall specify that multiple LABELs can be set, each for a different language. Use of the related parameter: This allows a location to define the start and/or end timezone of the associated component. If a location is specified with a RELATED parameter then the affected DTSTART or DTEND properties MUST be specified as floating DATE- TIME value. STRUCTURED-LOCATION has no TZID property and can, but does not have to, point to vCard URI that may, but has not to, contain TZ. The draft does not spell that the URI behing structloc can be a vCard. How does STRUCTURED-LOCATION substitute the time zone information, if DTSTART is floating DATE-TIME? The current way to specify different timezones for a trip is to use different TZID parameters for DTSTART and DTEND. Why does the current way need to be changed? Lets say a CUA(server) implements eventspub and it uses floating times in DTSTART/DTEND with STRUCTURED-LOCATION to signal that the timezones of the start/end are different. The CUA creates an iCalendar objects and sends it to a different CUA. The recipient implements RFC 5545 correctly. It would understand, that the start/end timezones are different, if TZID in DTSTART/DTEND said so. But the received DTSTART/DTEND are floating time and the recipient does not understand STRUCTURED-LOCATION, or for privacy reasons the recipient does not want to download the data pointed by STRUCTURED-DATA;VALUE=URI: . Shall users disclose their IP address to get the timezone of DTSTART from now on? 6.6. Structured-Data Value Type: TEXT, BINARY or URI For the other properties is spelled explicitly, that there is no default value type, but for this one and the other properties the same is implied by https://tools.ietf.org/html/rfc7986#section-3 . 5.4. Schema Example: STRUCTURED-DATA;FMTTYPE=application/ld+json; SCHEMA="https://schema.org/FlightReservation"; ENCODING=BASE64;VALUE=BINARY:ICAgIDxzY3JpcHQgdHlwZT0iYXBwb This is a very good idea. ld+json provides means to communicate from the CUA, over a publisher to search engines information about an event, that is not mapped in iCalendar. E.g. if there are fees. Is it possible to not-base64 encode json, and use something like STRUCTURED-DATA;FMTTYPE=application/ld+json;VALUE=TEXT; SCHEMA="https://schema.org/FlightReservation":{"brum":" wups","zz":true} ? schema.org can define e.g name (corresponding to SUMMARY). SUMMARY can be present only once (in one language). STRUCTURED-DATA can be specified many times, but has no LANGUAGE property. What is the way to write SUMMARY⇔NAME for an event in three languages and put this in a single iCalendar object? What does it mean to have many STRUCTURED-DATA? Greetings Дилян В 11:34 -0700 на 16.10.2020 (пт), internet-drafts@ietf.org написа: > > 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           : Event Publishing Extensions to iCalendar >         Author          : Michael Douglass >         Filename        : draft-ietf-calext-eventpub-extensions- > 16.txt >         Pages           : 36 >         Date            : 2020-10-16 > > Abstract: >    This specification updates RFC5545 by introducing a number of new >    iCalendar properties and components which are of particular use > for >    event publishers and in social networking. > >    This specification also defines a new STRUCTURED-DATA property for >    iCalendar RFC5545 to allow for data that is directly pertinent to > an >    event or task to be included with the calendar data. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-calext-eventpub-extensions/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-calext-eventpub-extensions-16 > https://datatracker.ietf.org/doc/html/draft-ietf-calext-eventpub-extensions-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-eventpub-extensions-16 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Mon Oct 19 15:09:48 2020 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 02F5E3A0C43 for ; Mon, 19 Oct 2020 15:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.446 X-Spam-Level: X-Spam-Status: No, score=-0.446 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, 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=igalia.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 21l04RzZ1x_k for ; Mon, 19 Oct 2020 15:09:43 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 755E43A0C3F for ; Mon, 19 Oct 2020 15:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=MuX2yUerdYZ9ixebMMy3Yw3/rfP4zTMOPrgCnw467Pg=; b=olXljRvEpm1cZLMolTVzWo5rnzzTVHZUlhTATg8W2l/Aw/ITgerXnbc3bnlqV4J1NPUm7PXFk1tLQqWfHBFuZJEOg8XX87TcwJyzSjpn+J3GTnt8CcYssWJ72xcgS87HH19othZT1XGHfFDmvwksAZ4R/2xAQX3PEZPeFv9H1nzLcKrvi3NFdj1bbjYztExr/vCyXKkrwVyn3XayKGmZrxqZehsCOAU6m7bRBc80B5hYXHA9aPyHof13XarbD2Sspv0rrvo0WHBJ2uRDkNtzX9nMo7WbtA62+a3QZTmUEwfDQ1T6g/oQ4cYfVhD9BMZslxPJ8VqdpOepMls1ASYXiw==; Received: from [183.83.215.161] (helo=[192.168.0.110]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1kUdLU-0001pS-Js; Tue, 20 Oct 2020 00:09:40 +0200 To: Ronald Tse Cc: "calsify@ietf.org" References: <668b5100-aab0-4353-bc11-132ed1f3785a@dogfood.fastmail.com> From: Ujjwal Sharma Autocrypt: addr=ryzokuken@igalia.com; keydata= mQINBFpsLAwBEADb/gc4ouvNQQc3ZmwVAOewWuWve9xA3B/ok+DhzSx2wJ82FR5s+198Y++s oMb4VyiU0FOk6FUUBSn1OTTEB5TVW904hqczD3qLDIbZD6bL9sor1W/8ok0q3q8hr/ICyiSC 6FuTROjXOL31Hs8pob/YsNX6e5g+o7/tSb0gXH6r1Dw7DL7gRqMrMFJRoBZZOwvu75PxFRCr bJ/GfkMv5ovLO2/Oj4P3/VbM4FzHSbn4r/CD/RrL3Qwhn94CoDv0fSzsGKqESbeVYjiqREWU 4oL5PR6PbPD9RXXw/wBUqIvGuEN8lKCpxsLHhPfYA4i7+en3JRot8O+Lk3nu1qEL7ED75Zot MbHGyZ6NxRv12mtX9aVWQAy7g3xNoEh3baqEpYcAXtgbX24aTX5etL1y3Z6cUBHSUTKHlHix egmjSUEkaY/qmTTCvJUGhTU+tYGHBnh6Eibg1NVKeIXdCZBhLqp4NqrivXBQxWAnN4Y7jtCQ O+uQIptIiL1YVcQrU8D/0Y6Pl3kWo8AUd3Nu+Dd+qEJqSimrcNzIjZqoun+ADrVoufzkMT5C ELT1YsS5TH3vGn4qtvGQU+/MQDMMm4vlVlaIHtAExiNHwLQ9NsFDWN6B4vvAvGv5PBanbMJJ b9iA1mCuVZnP+q/dxGQubRY3i+RqA8pyfx03G5yFr0CMjwqbEQARAQABtCRVamp3YWwgU2hh cm1hIDxyeXpva3VrZW5AaWdhbGlhLmNvbT6JAk4EEwEIADgWIQSsOTVT+mJCZQ85wB4f07R7 g/RmIQUCXgnwfgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAf07R7g/RmITovD/0Q T+kIEIBrVppJ7dNp4Pyg1hF7O4pVlu9MI6fu95bGwmXSU5BpohYSCn33d8YwPnHZH698UC0Y Zd2FU2foynYn5XUJRaiDEynK9rmZxIB33IANLfEbxC1u1sby7n154wvk7r5kBJLesR2a/Wlb Qr6q8LMCGvWQf/IAQzOdsylwnuDeKDSLrlOI0XoGizRg9ojExOGiR8cPNnhYNM35UmXEwYXN mDkoUV3unT2dXgW2HQfhc83SlfSqB8+2bLi94LTgZm5eBQxEzbj5wFyGElIURksA8SPvXY2R 0xx24odyGQi1CO16RXcBCOtqHUaH8UnyPeHg4lRBiIarZtzbPMh4h+YBoiuD6iczfLc/II5E 8852XD9PFX8y69y98bLfSBlMz/RIjZ1An9oIgIqFMtPnt1FB5LCNoe2iOXmzA8tuSHDXzYzw GvXix5cgOma4oAqzLphG9GwxhJiOL6eOjf2VzjfZYOrduuJBsJ+60rCvURiAeHbt8ogQVHNb DKImEseQY0h0pyM7r0FRRynyEya5GUF6vdaVL4DkwHJ6OphSlF4TW12XKdBMG8APNF5tx3f+ K732lrAVnqQfTm12hQp/9mpkTQ0edpgoEW+ZWvWOGotyzyWF1uzvVHa9zwwJWvjU2tKINaKL E8x8728etREcX39GKqZWNFqJZN1L3KivQbkCDQReCgRfARAAooqzPt/mQ6vO2zn3JqA4cjVu +VuxmGuBL7VclmzYG1veTrkqOgBW1lxLSLEJLrDyfvC40RDS+QgBqmtbQ8x3ccOkcCNTMoj8 8lx5BiGUInjT6wkmRYejGsw8DuKkIWnWrrv628xZiB+fhwWxc5lu3kb5LEh9eUEDrHUhMzSy svKJlpuLd93zGGtC5KAeqZhUH1pCc0FBxbBBqy0bcfYKuRcNSO7YFHIAGRbYeQMOivhMXC2z Zq6YEdLxnAl21OQlRkv77XinSD4e2Yb7WFK0MgvQsdwLOhM5pHBcuc6MkGLm/lMM8VO8N9o6 n4QyZA5LsfhTd0kGleoII0YO9RQOLHRdiPKlvDbD1B9Mg58hQakBbJF07eAwEJq/a+LhzhW+ VHlZWNV0h9tSugSgq3nOt6wG/ftVMRILREMFUDI63+UR4PXJ++l3TNBd/5RZCmuWFoavc/Tl AcQG/aQt5Ezh9AdD0Ao+5VL2ATjNSHMxH+AnEagnx2vmJC5I+LqATfgn6CX4DzatFSA9LxZX LPiXlMGWH6JogJpIQqaHulqjfko2Mb4eHuYvdl1Wova03w1BUA/EHUnJIaGVXlV5E69ubJTm SXqEAixL6vYsljJ0fO4IxBlT71aRyrvaKW37fWG2c/csjgB25U2Y7tdWY4xA96LynAurJSRJ Jj+Urmz+Bm0AEQEAAYkEcgQYAQgAJgIbAhYhBKw5NVP6YkJlDznAHh/TtHuD9GYhBQJe6vw+ BQkBzkXfAkDBdCAEGQEIAB0WIQRMXCPh15S+uPoc6Av/592ik3N4ZAUCXgoEXwAKCRD/592i k3N4ZKvZEACQNX7g5NPdRNwl0+UXy/NK2nQVOu/0Vel9giRzHfhgjetWBTzsl2DvnMoi8VG3 sY4ztOkpERm33HHOcFKXlJ3qCZ0mjAa9+pH6IpJEvpqc4TJ6o92dB4lqJNuJQBDVsYcuM4+C hPM0LnrJgJ9/SMeuWgVrT9sXC3nuJlx0ZcKo4eW/K7t3IVc3IcXV3V0ORm5hf+W30A+SUY1F xteU+7/wccI1WfjGNC9q2e3ywVsWAVfQu5kS94QhY3S1vJJ6bfZ9zpql8IuP6MczlTkFzvo6 j7CJ5ymF+A952AoU5Mj8Z+qwAt2OCpEbMufMMdexczTbg9edzhtHWAHnX/uE4d/d9HF4VryU xpg3ZZ4mse3UJTQ8AF2vQhOXT7B5d8QI0QKeH4qmhDCrgXDoXyV107TJ6ScZkFI1MmEoyZEf cv6tTiIfn70gfNXntKdqkt7E7lqybofkDEj91qelPlnE0nRH0tDMq5xJSe1DLPPlSYdnk5Z6 2g/rXAGmzvjVlj5Uw6nw/SfTgE275tVWFA1fkMjjVJFItmmwxDu6dez7QZKYlIC2mvk7ZvUW mlUVmyauJFKVMFlrH0AxWFRwMlmyiSrcy4lN93SjlQHAx9Nt23C7OnKUC83sA+jlaHsdQb7k hqAGpgzW78ijWe45CYrmXNzRsgf59nuTWIxcZrU7ck5CugkQH9O0e4P0ZiFfghAAn/dUwP2T OIGAPsvFLEvPKecBGwJITFvm9cbPqUE26D2gOC4EyJuCJlvXfn97sYcv2/c6g5CGgkJxcjnH 3Z8z1Yzkg3JCDi78lmFsw/N3VQdSJAqLJRUeVfcsudZh+LNMPW7FRRXqUb8ZrtCrMtsrWTL7 iVy0qKmWIOBHyhJZCUIVo3GZHZFePsqMRObZlSDUekGkhJ5MNRLcZaLLBVUIMgfNIVMww11M Yk0rmk6i74EYre2+jVc8HQMjkvRb/zqZzWNsqqR+PB4f+lLMAi4E9+8AKCyN1RQa525dnhYs XxiyvPwWpddfKHbDzUSi6z70x5ry3mFx1i+OixKhv2jpqNUXG3B73xsId67gTs6eRy42/JJJ rJ2NC1y0uflJmLamPVxHPZi6h1jqcRFmq5/vvuSWvWPQbTGQeReflRbLTzfSUlOaMll3YedV 07dGKYjmLNy+1vrM/Mwa0So6kAmeYQSk5FbFcrqDHDWcv98E7pP8Kozah/ryWUtVfdGTSCXW dMecSCyuMzAteW6JRlOOOMmN92YBaULxq7ERa4cOL0Vkz5vlzGbkg2wAobgRmXP4LaBJ6kVU Qp9SUTwjwKAVF+i1Tpw38BXLtJphdIOPV1QZmK+5CPMDjGifPlyDUSdA4T6h/Nr8bTjuQUkY HEUDJZMWsP+L5v1mK7gP9mdJiJa5Ag0EXgoFEgEQALOhu272DYYvbhw6kOirE1AR6ncs0i0T wDB/YnEMkBi/J7coe51I171TLaqTb5cwhs2chRUMiIvGft96/efypDnGZnvVZh80tiBUlcI9 tckQj4A7DYlAFNfdZAVKUP+G49P9N1EB8wFnc8X/YPjFP/iB169d8YyHgfibcvZbeOkMWq70 bt4maZVWCYI6r/RkFYrlgVlO28GrURELPW/B5cf+NXg8tFvxv9MR7QEWh/VHZ3CsYq1+4p0A ZEixg0D1ynvV2LS7sqca2eHxXhzX0VXdvjCKWY468E5eYlHkyOFdsbdiGgyZB5L25y/CIeyZ sQz3unYWYZ3E4UcJFm8hgsl8YWMSYl98IORpZVQ7YII2dnwPB5aRIfJgoKl5rP/AsKLV2dzj p+6yljrA2czat1c8MWko2IO/QMpzMFmWkuZiSBwNXQuByYUF0SM10pY6faApo/wWnLyEcwPF 0hmmlj0gLkkT46zdLFxRI0kzUPX7tPKqNc2hPzyHSrKXPuqJyWnq2lvS3LxNRngiRb28mKbg GQpE/iX3whzcVs1kAAL8DaiLIKWmJ5bbYEy3DzTuysMgK2lCeqGGj3p6xczPwrJQkDQKwnwf 6KLMEA6RlbWThmC2eWxPi+TLV4/HTbvabYuOBhVd4xwZZ+WfhgYCR5XmaKknKs3D8YOv3qdv EZj/ABEBAAGJAjwEGAEIACYCGwwWIQSsOTVT+mJCZQ85wB4f07R7g/RmIQUCXur8SgUJAc5F LAAKCRAf07R7g/RmIYbHD/4rekfbk8ZY2q4/wdiH9NpfYLzFQhsylQ1Knqau4oPTFXUPY2bz 9X/LMTwj7fVGa5rtC9uuoDKnmdxq7qzItf2oO+jE6RM2nDXZWeXDubQZlFgNQOde3PvTjJxF CgMwTgFl5Ydh6HQZlgcf13BbXwdF2b1d8kI1SFMkk6dgCWQJfmcRUYrTNfv4CB5dyZvnDLBF N1tmePnUpsn6gDxigr3sXJ3TE4R+mZrYNddW/0Km3X4bMi1lD7n/tmWyLJfQpsOXxInWPT0K 5eFQ/kGWeheAoiYFTGzCnbLLYWzaMRqxfBzze+eP0Jt8tQVcm7Xr7k8GE0811JHhKtTduoX6 /UF0U2+VNdQsYLWVMag/Eb/KeHBCNruEVEcOhGl1eamDIO33fnP/7bs2M7NP+p1rE4tGxLrr oxK5HC7ZDSye7nHfROK1CUzT3ALVupyVQrC6sa4vbUhtpnB3Q2K7fH660YbG6bLaDjHRNfRJ ER5JsjGz7YJi6Snig1eyAkFMEfZym2vxUSagFbi5u5KHteWy1GuaEkPowB4/4/PKmoh7+ec7 pqSM0a9F1fsScQa5SpzGaG5BeTOBz5PPb+528NFZKtt67nHKxJKbVxortLiRjxp6FoXY2x69 8q+jogfmP5bMqkUzHcdOXLzApLyoxOgEGqS3Bn7mBR0C8aUPeowlESZUtw== Message-ID: Date: Tue, 20 Oct 2020 03:39:03 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="a8unMihWysTVBca1iuurHHZ20nQ5kEOmn" Archived-At: Subject: Re: [calsify] Getting started with the calendar persistence format 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, 19 Oct 2020 22:09:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a8unMihWysTVBca1iuurHHZ20nQ5kEOmn Content-Type: multipart/mixed; boundary="vaAWcJuwqcrbAZRJARjTwusQPvQwwAGLb" --vaAWcJuwqcrbAZRJARjTwusQPvQwwAGLb Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Ronald! Thanks for the suggestion. Write once, publish anywhere (although perhaps with minimal changes) is indeed a priority, especially given our time constraints. I tried setting up metanorma today, but for some reason, it fails for me locally. My input: metanorma --type rfc3 draft-ryzokuken-timestamp-information.adoc Error: Error: loading gem `metanorma-rfc3` failed. Exiting. This works with or without `-x xmlrfc`. What seems to be wrong here? Am I missing a gem? A simple web search doesn't return anything useful, and no gem named `metanorma-rfc3` can be found. I thought there was something wrong with my setup, but I tried multiple times, ran `metanorma setup` properly, tried the docker version, but no luck. The same error each time. Could you help me figure out what I misse= d? Best, Ujjwal On 10/16/20 9:45 AM, Ronald Tse wrote: > Hi Ujjwal, >=20 > (Thanks Bron for the plug!) >=20 > Metanorma is one of the officially listed processors for IETF documents= > (alongside mmark and kramdown-rfc2629). >=20 > CalConnect uses Metanorma to publish standards, and a number of SDOs do= > so as well (ITU, OGC, BIPM, who also work with date/time). >=20 > If there is any intention to cross-publish into CalConnect or ISO, the > ability to "write once, publish anywhere=E2=80=9D becomes important. >=20 > Given that we=E2=80=99re the folks behind it, I=E2=80=99m happy to serv= e as your > personal support if you run into any Metanorma problems :-) >=20 > Kind regards, > Ron > _____________________________________ >=20 > Ronald Tse > Ribose Inc. >=20 >> On Oct 16, 2020, at 8:27 AM, Bron Gondwana > > wrote: >> >> =EF=BB=BF >> Hi Ujjwal, >> >> There's a variety of options for writing drafts.=C2=A0 I personally us= e a >> workflow based on mmark, for example: >> >> https://github.com/brong/draft-gondwana-effective-terminology >> >> There's also metanorma, which allows you to create a variety of >> outputs.=C2=A0 There's documentation here: >> >> https://www.metanorma.com/author/ietf/ >> >> Or you can use tools like: >> >> https://github.com/cabo/kramdown-rfc2629 >> >> Basically, they're all toolchains that generate RFC XML format documen= ts. >> >> In order to publish to the IETF, you need a datatracker account, and >> you'll need to upload there: >> >> https://datatracker.ietf.org/submit/tool-instructions/ >> >> Cheers, >> >> Bron. >> >> On Fri, Oct 16, 2020, at 09:21, Ujjwal Sharma wrote: >>> Hello everyone! >>> >>> Thanks for the amazing discussions and help yesterday. Given our >>> constrained timeline, I suppose I should start working on the drafts >>> immediately. >>> >>> On the IETF side of things, I suppose I'd need to start by creating a= n >>> I-D? Is there a set of resources you could point me to in order to ge= t >>> up and running quickly? >>> >>> Also, what should I do to get the ball rolling on the CalConnect/ISO >>> side of things? >>> >>> Best, >>> Ujjwal >>> >>> --=C2=A0 >>> Ujjwal "Ryzokuken" Sharma (he/him) >>> >>> Compilers Hacker, Node.js Core Collaborator and Speaker >>> >>> >>> _______________________________________________ >>> calsify mailing list >>> calsify@ietf.org >>> https://www.ietf.org/mailman/listinfo/calsify >>> >>> >>> *Attachments:* >>> >>> * signature.asc >>> >> >> -- >> =C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd >> =C2=A0 brong@fastmailteam.com >> >> >> _______________________________________________ >> calsify mailing list >> calsify@ietf.org >> https://www.ietf.org/mailman/listinfo/calsify --=20 Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, Node.js Core Collaborator and Speaker --vaAWcJuwqcrbAZRJARjTwusQPvQwwAGLb-- --a8unMihWysTVBca1iuurHHZ20nQ5kEOmn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEETFwj4deUvrj6HOgL/+fdopNzeGQFAl+ODo0ACgkQ/+fdopNz eGSH6xAAlZTL2iRQo2IN6y/iyVE8IUBIX1Dszps0ZFOUfaMjHsfaEhLnD5U3ZEi/ +N8SbfYwVc4vAyRteyyr6YBYD6q2yrUFRNZm6Hnv+TnQ22ylVVFiKH22dMvhge2w d26b0Lft7WsSfc2gGx9yNCsggx+E2RFYuzzPIK6+DuAz40Xb6ssmWtfbtieyvATx CL/10AhHRegpCAm/8frTFj2JaM3Y4Lc/PaXtm1GVUEhJw4a2Il+Hoh3MFEmbVvCQ lu7eTugjmowcBI/xKU1xD6S3qgvHXLWa7ay1CpcFfrNGa1eHzAHNDeULTzcvpyQb 0juq4v4FQqrsGevyqBAlfgUOxOzs42imZtRZDspIs6owpYBn0dNQk44Cxw9wLPgz Ew8ZmILgoyj57441dSdmNzJZXe/RjvCAAHAN1XaZSm6qIJo7npSAA08/cigOJCgS 0bV1SYAZxEDbTf6e4nGZlKbpBAKUk9lUCgWXM9LjD+N81+pnR6TIOkL1KFhyCjbQ 0dF9IUEuKf8NeLkbV/d1iJC/LflNIH6/iSfX6It2bxpP3j+g5FCrysLco0GyZqPg 7XWtJhNUtRrT1PpkxWeSmG7hvaQBX25t/rkjjX2R/SwWdJsVxSfCpOP8krqFOxk4 GEWDzujli9KxuSQNHyV24PiAFBHal2y7Jno9jtEaEta0SV+mT4o= =kOCZ -----END PGP SIGNATURE----- --a8unMihWysTVBca1iuurHHZ20nQ5kEOmn-- From nobody Mon Oct 19 16:30:44 2020 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 59A7E3A100E for ; Mon, 19 Oct 2020 16:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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=ribose.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 gCFe8dGWmY3i for ; Mon, 19 Oct 2020 16:30:39 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-eopbgr1300051.outbound.protection.outlook.com [40.107.130.51]) (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 C1B133A100D for ; Mon, 19 Oct 2020 16:30:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kUDs65g/OwbFgkJIfUZLIwt5VSgEyprjH0TL2cuCG4ZB5Nyntvnp/NaiIDvNFSS/j2B/5GCVBw6fWkm8sUhzHAGhebZL/eM6WSBUhbs1X5xxIddC+EU8CNyEUCqDKCac39l6l2AhcNsz/cXaPEMzLyV2hg3G87UvtXvokjF561XT723B/M1EwCiabu8R+OaU2VMabRAQmx4qRmYQ9Ti5VbNq0GyohciIBK7MeacRFU11WrGD9+4pJbSM1Vn/oowotgcV3X0fSvuoXPUOqqhJE1wknZ8wvbc3+Y7c8FjhxuEFA0A1ahJbhXM6F7NHsi2YC6yPFu31bsDF8ICPmZ225Q== 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=x+8/KQRP91a581DydGzdqNzlKJGNkpaHXQk95uLearE=; b=FYTrKxuy4LHgI+qsliL4YqQSdvnH1twV6gUH5pGyrJC/qaKD5fWkUKa6SiZQzRGhOM8SwVzUw1DKpoKMROQK6n4Msj92X2oi2rHU/es4KJCtsPhV9g88rkWClISkLsYy6iBDCxBW7lJAFpSy3ejHGl2ahGM8pveHXaDtbv3iFaJiUNqYvrC/oJhmk+qWLu1VCqXXzro0PSLxAdjGjTlSNwpzG+bMSaNPT0ssHkUVu2V0LXZutKd8XWueE0/wdDO56HjXmuazxj1K073dT83JnsnBZJxCIkRylVG+I2GG6PlV5tHkYXir8zow2/IuE0PwBSuNZ1+N3eCrTYwDlUgp6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ribose.com; dmarc=pass action=none header.from=ribose.com; dkim=pass header.d=ribose.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x+8/KQRP91a581DydGzdqNzlKJGNkpaHXQk95uLearE=; b=DZaRYyOXWfO4aN218ZRCIMUxCGSEDKMChdSNbjcHmFeiFF2zSSEknngHocKMhRZb6Z3ouLkxgidCBWY8iPdaj3fepXLNLwrXwaSeFsmdMOhtew7+OZw3d+SQSh1rEt3Lj5G8IaV3rq84jguYQkZ6WYsueMWku7Z3FyqKCJLAmNk= Received: from HK0PR01MB2900.apcprd01.prod.exchangelabs.com (2603:1096:203:98::14) by HK0PR01MB2897.apcprd01.prod.exchangelabs.com (2603:1096:203:97::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.24; Mon, 19 Oct 2020 23:30:33 +0000 Received: from HK0PR01MB2900.apcprd01.prod.exchangelabs.com ([fe80::b8:4b19:ebf4:7724]) by HK0PR01MB2900.apcprd01.prod.exchangelabs.com ([fe80::b8:4b19:ebf4:7724%5]) with mapi id 15.20.3477.028; Mon, 19 Oct 2020 23:30:33 +0000 From: Ronald Tse To: Ujjwal Sharma CC: "calsify@ietf.org" Thread-Topic: [calsify] Getting started with the calendar persistence format Thread-Index: AQHWo0GwGjTIredru0qplU+nj0MZpqmZX5UAgAA/4QCABeLugIAAFsUA Date: Mon, 19 Oct 2020 23:30:33 +0000 Message-ID: <55B0F7E9-114C-4830-87E5-523CC56D3528@ribose.com> References: <668b5100-aab0-4353-bc11-132ed1f3785a@dogfood.fastmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.1) authentication-results: igalia.com; dkim=none (message not signed) header.d=none;igalia.com; dmarc=none action=none header.from=ribose.com; x-originating-ip: [58.153.245.161] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ebbc4ab4-9e84-4dd7-23fa-08d87486f98f x-ms-traffictypediagnostic: HK0PR01MB2897: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7SqE2WchkSG8ACYAzY39ji0yCvgDSlYxShF6aiPTXdxLVFxlaftOebp44U0cLC17LFA4lO3jvISjFZHpWIvf9SeVAKVeDXi2jzdtv5enLME5/nU7F4+d2DLODPHlPyjl9bDHy+mP58tDJGk1pgpg8VbFWNzn6IzlqgtUEBnHKHii4sQJoLoe2Xue8mXbNipQE4M0Z4tc026QNSZx5sBIJjhWSAOco+wLgUdstACyv4pmHN0PS9jZEVRajOkQmKK1kgm/mLBTJpOpfYlCJ9nPcrePyjD9bEF+AnQCbIfJ0FxyVjvsyGYlT5ztvt7i0FRFv+HsGz1HajMeijxoGQkBam7mEWoSe4cb8xflEZa7Pq+4h3aqJ3zvjacrKrQfX1a21S+JeTdhYyJMx8/thXSxkQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HK0PR01MB2900.apcprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(136003)(396003)(39830400003)(53546011)(5660300002)(6506007)(36756003)(6916009)(8676002)(4326008)(2906002)(71200400001)(316002)(166002)(966005)(186003)(6512007)(478600001)(8936002)(33656002)(66556008)(83380400001)(86362001)(64756008)(2616005)(66446008)(66476007)(26005)(76116006)(91956017)(66946007)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6OMRt7n+xuPu/mTFFGllCBjzJOK0Xxz/BH1nI3Iafhv3Bihv4N89hNsAUUTdYf/84e+OgLL7BFEVlxqHOzvubTobzfIF+cv/8dIy/1qgMEAdhrQbOylbFjZjiqBXzsxi6v1CP2ilsQpOINKF5SOzv44WAc9dw3ssQlECen01M/GFCU957W4julPffaCFauXBoJKg3eXD5ZMD62TloG7vuKvtUNcInEsLHIaPZZyLuDcqPYs/tYSDKXfYgTCpZfm88qx0TzvZv0ZtToHOPKdRAantyCcFsJuI0+PNrBy3gN7k0MXvGA2yGQTpYK3iz51mUMMSeTZA46YbtMi8fJINAuPymWRJDKeiLw/xEAaL/GUFsE4fpjCb7O2/S1Z8B13MYdFt27H/Oay7cYiZ37b4LIYysQi2Cw2P/YOUU6Gu1FaKzKN975bz5hgE24CTwtswHkqW793O1pb8h3HzKkXGPdG3gLnZ1OIDdmGwJk5Bj4RFXW7Px6yPdI2iCc5mZ6k+El0xzba2xMXFBLgYrg7lxlFTE8lU4KbI+R8t6AlobXRkEyOjk1iLQyJO0ntQkBn5htB92N6RPIOcwod9OR1V+CK/Hv55zVGjRAAM7SugATdIlq4fsQDIwFWaOyTLr7I4rzBlyFazL47aK4tfwxGFXA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_55B0F7E9114C483087E5523CC56D3528ribosecom_" MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HK0PR01MB2900.apcprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebbc4ab4-9e84-4dd7-23fa-08d87486f98f X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2020 23:30:33.2533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: C5+xmgYc9BuI+uAw4/7lxtluUBQJlCFrVcwq/sWRE4wL+VZyTwGE6Y/1+xudLGLJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK0PR01MB2897 Archived-At: Subject: Re: [calsify] Getting started with the calendar persistence format 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, 19 Oct 2020 23:30:42 -0000 --_000_55B0F7E9114C483087E5523CC56D3528ribosecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVWpqd2FsLA0KDQpXb3VsZCB5b3UgYmUgYWJsZSB0byBwb2ludCBtZSB0byB0aGUgZHJhZnQg dG8gc2VlIHdoYXQgdGhlIHByb2JsZW0gaXM/DQoNCkhlcmXigJlzIGEgc2FtcGxlIGRvY3VtZW50 IHRoYXQgd29ya3M6DQpodHRwczovL3Jhdy5naXRodWJ1c2VyY29udGVudC5jb20vbWV0YW5vcm1h L21uLXNhbXBsZXMtaWV0Zi9tYXN0ZXIvc291cmNlcy9hbnRpb2NoL2RvY3VtZW50LmFkb2MNCg0K KGh0dHBzOi8vZ2l0aHViLmNvbS9tZXRhbm9ybWEvbW4tc2FtcGxlcy1pZXRmIHByb3ZpZGVzIHdv cmtpbmcgZXhhbXBsZXMpDQoNCklmIHlvdSBoYXZlIHRoZXNlIHR3byBsaW5lcyBpbiB5b3VyIGFk b2MgZmlsZSBoZWFkZXIgKHVuZGVyIHRoZSB0aXRsZSBidXQgYmVmb3JlIHRoZSBjb250ZW50LCB3 aGljaCBpcyBzZXBhcmF0ZWQgd2l0aCBhIGJsYW5rIGxpbmUpOg0KDQoiDQo6bW4tZG9jdW1lbnQt Y2xhc3M6IGlldGYNCjptbi1vdXRwdXQtZXh0ZW5zaW9uczogcmZjLHhtbCx0eHQsaHRtbCxyeGwN CuKAnA0KDQpUaGVuIHlvdSBzaG91bGQgYmUgYWJsZSB0byBqdXN0IHJ1biB0aGlzOg0KbWV0YW5v cm1hIGRyYWZ0LXJ5em9rdWtlbi10aW1lc3RhbXAtaW5mb3JtYXRpb24uYWRvYw0KDQpSb24NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpSb25hbGQgVHNlDQpSaWJv c2UgSW5jLg0KDQpPbiBPY3QgMjAsIDIwMjAsIGF0IDY6MDkgQU0sIFVqandhbCBTaGFybWEgPHJ5 em9rdWtlbkBpZ2FsaWEuY29tPG1haWx0bzpyeXpva3VrZW5AaWdhbGlhLmNvbT4+IHdyb3RlOg0K DQpIaSBSb25hbGQhDQoNClRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24uIFdyaXRlIG9uY2UsIHB1 Ymxpc2ggYW55d2hlcmUgKGFsdGhvdWdoDQpwZXJoYXBzIHdpdGggbWluaW1hbCBjaGFuZ2VzKSBp cyBpbmRlZWQgYSBwcmlvcml0eSwgZXNwZWNpYWxseSBnaXZlbiBvdXINCnRpbWUgY29uc3RyYWlu dHMuIEkgdHJpZWQgc2V0dGluZyB1cCBtZXRhbm9ybWEgdG9kYXksIGJ1dCBmb3Igc29tZQ0KcmVh c29uLCBpdCBmYWlscyBmb3IgbWUgbG9jYWxseS4NCg0KTXkgaW5wdXQ6DQoNCm1ldGFub3JtYSAt LXR5cGUgcmZjMyBkcmFmdC1yeXpva3VrZW4tdGltZXN0YW1wLWluZm9ybWF0aW9uLmFkb2MNCg0K RXJyb3I6DQoNCkVycm9yOiBsb2FkaW5nIGdlbSBgbWV0YW5vcm1hLXJmYzNgIGZhaWxlZC4gRXhp dGluZy4NCg0KVGhpcyB3b3JrcyB3aXRoIG9yIHdpdGhvdXQgYC14IHhtbHJmY2AuIFdoYXQgc2Vl bXMgdG8gYmUgd3JvbmcgaGVyZT8gQW0NCkkgbWlzc2luZyBhIGdlbT8gQSBzaW1wbGUgd2ViIHNl YXJjaCBkb2Vzbid0IHJldHVybiBhbnl0aGluZyB1c2VmdWwsIGFuZA0Kbm8gZ2VtIG5hbWVkIGBt ZXRhbm9ybWEtcmZjM2AgY2FuIGJlIGZvdW5kLg0KDQpJIHRob3VnaHQgdGhlcmUgd2FzIHNvbWV0 aGluZyB3cm9uZyB3aXRoIG15IHNldHVwLCBidXQgSSB0cmllZCBtdWx0aXBsZQ0KdGltZXMsIHJh biBgbWV0YW5vcm1hIHNldHVwYCBwcm9wZXJseSwgdHJpZWQgdGhlIGRvY2tlciB2ZXJzaW9uLCBi dXQgbm8NCmx1Y2suIFRoZSBzYW1lIGVycm9yIGVhY2ggdGltZS4gQ291bGQgeW91IGhlbHAgbWUg ZmlndXJlIG91dCB3aGF0IEkgbWlzc2VkPw0KDQpCZXN0LA0KVWpqd2FsDQoNCk9uIDEwLzE2LzIw IDk6NDUgQU0sIFJvbmFsZCBUc2Ugd3JvdGU6DQpIaSBVamp3YWwsDQoNCihUaGFua3MgQnJvbiBm b3IgdGhlIHBsdWchKQ0KDQpNZXRhbm9ybWEgaXMgb25lIG9mIHRoZSBvZmZpY2lhbGx5IGxpc3Rl ZCBwcm9jZXNzb3JzIGZvciBJRVRGIGRvY3VtZW50cw0KKGFsb25nc2lkZSBtbWFyayBhbmQga3Jh bWRvd24tcmZjMjYyOSkuDQoNCkNhbENvbm5lY3QgdXNlcyBNZXRhbm9ybWEgdG8gcHVibGlzaCBz dGFuZGFyZHMsIGFuZCBhIG51bWJlciBvZiBTRE9zIGRvDQpzbyBhcyB3ZWxsIChJVFUsIE9HQywg QklQTSwgd2hvIGFsc28gd29yayB3aXRoIGRhdGUvdGltZSkuDQoNCklmIHRoZXJlIGlzIGFueSBp bnRlbnRpb24gdG8gY3Jvc3MtcHVibGlzaCBpbnRvIENhbENvbm5lY3Qgb3IgSVNPLCB0aGUNCmFi aWxpdHkgdG8gIndyaXRlIG9uY2UsIHB1Ymxpc2ggYW55d2hlcmXigJ0gYmVjb21lcyBpbXBvcnRh bnQuDQoNCkdpdmVuIHRoYXQgd2XigJlyZSB0aGUgZm9sa3MgYmVoaW5kIGl0LCBJ4oCZbSBoYXBw eSB0byBzZXJ2ZSBhcyB5b3VyDQpwZXJzb25hbCBzdXBwb3J0IGlmIHlvdSBydW4gaW50byBhbnkg TWV0YW5vcm1hIHByb2JsZW1zIDotKQ0KDQpLaW5kIHJlZ2FyZHMsDQpSb24NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KUm9uYWxkIFRzZQ0KUmlib3NlIEluYy4NCg0K T24gT2N0IDE2LCAyMDIwLCBhdCA4OjI3IEFNLCBCcm9uIEdvbmR3YW5hIDxicm9uZ0BmYXN0bWFp bHRlYW0uY29tPG1haWx0bzpicm9uZ0BmYXN0bWFpbHRlYW0uY29tPg0KPG1haWx0bzpicm9uZ0Bm YXN0bWFpbHRlYW0uY29tPj4gd3JvdGU6DQoNCu+7vw0KSGkgVWpqd2FsLA0KDQpUaGVyZSdzIGEg dmFyaWV0eSBvZiBvcHRpb25zIGZvciB3cml0aW5nIGRyYWZ0cy4gIEkgcGVyc29uYWxseSB1c2Ug YQ0Kd29ya2Zsb3cgYmFzZWQgb24gbW1hcmssIGZvciBleGFtcGxlOg0KDQpodHRwczovL2dpdGh1 Yi5jb20vYnJvbmcvZHJhZnQtZ29uZHdhbmEtZWZmZWN0aXZlLXRlcm1pbm9sb2d5DQoNClRoZXJl J3MgYWxzbyBtZXRhbm9ybWEsIHdoaWNoIGFsbG93cyB5b3UgdG8gY3JlYXRlIGEgdmFyaWV0eSBv Zg0Kb3V0cHV0cy4gIFRoZXJlJ3MgZG9jdW1lbnRhdGlvbiBoZXJlOg0KDQpodHRwczovL3d3dy5t ZXRhbm9ybWEuY29tL2F1dGhvci9pZXRmLw0KDQpPciB5b3UgY2FuIHVzZSB0b29scyBsaWtlOg0K DQpodHRwczovL2dpdGh1Yi5jb20vY2Fiby9rcmFtZG93bi1yZmMyNjI5DQoNCkJhc2ljYWxseSwg dGhleSdyZSBhbGwgdG9vbGNoYWlucyB0aGF0IGdlbmVyYXRlIFJGQyBYTUwgZm9ybWF0IGRvY3Vt ZW50cy4NCg0KSW4gb3JkZXIgdG8gcHVibGlzaCB0byB0aGUgSUVURiwgeW91IG5lZWQgYSBkYXRh dHJhY2tlciBhY2NvdW50LCBhbmQNCnlvdSdsbCBuZWVkIHRvIHVwbG9hZCB0aGVyZToNCg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9zdWJtaXQvdG9vbC1pbnN0cnVjdGlvbnMvDQoNCkNo ZWVycywNCg0KQnJvbi4NCg0KT24gRnJpLCBPY3QgMTYsIDIwMjAsIGF0IDA5OjIxLCBVamp3YWwg U2hhcm1hIHdyb3RlOg0KSGVsbG8gZXZlcnlvbmUhDQoNClRoYW5rcyBmb3IgdGhlIGFtYXppbmcg ZGlzY3Vzc2lvbnMgYW5kIGhlbHAgeWVzdGVyZGF5LiBHaXZlbiBvdXINCmNvbnN0cmFpbmVkIHRp bWVsaW5lLCBJIHN1cHBvc2UgSSBzaG91bGQgc3RhcnQgd29ya2luZyBvbiB0aGUgZHJhZnRzDQpp bW1lZGlhdGVseS4NCg0KT24gdGhlIElFVEYgc2lkZSBvZiB0aGluZ3MsIEkgc3VwcG9zZSBJJ2Qg bmVlZCB0byBzdGFydCBieSBjcmVhdGluZyBhbg0KSS1EPyBJcyB0aGVyZSBhIHNldCBvZiByZXNv dXJjZXMgeW91IGNvdWxkIHBvaW50IG1lIHRvIGluIG9yZGVyIHRvIGdldA0KdXAgYW5kIHJ1bm5p bmcgcXVpY2tseT8NCg0KQWxzbywgd2hhdCBzaG91bGQgSSBkbyB0byBnZXQgdGhlIGJhbGwgcm9s bGluZyBvbiB0aGUgQ2FsQ29ubmVjdC9JU08NCnNpZGUgb2YgdGhpbmdzPw0KDQpCZXN0LA0KVWpq d2FsDQoNCi0tDQpVamp3YWwgIlJ5em9rdWtlbiIgU2hhcm1hIChoZS9oaW0pDQoNCkNvbXBpbGVy cyBIYWNrZXIsIE5vZGUuanMgQ29yZSBDb2xsYWJvcmF0b3IgYW5kIFNwZWFrZXINCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY2Fsc2lmeSBtYWls aW5nIGxpc3QNCmNhbHNpZnlAaWV0Zi5vcmc8bWFpbHRvOmNhbHNpZnlAaWV0Zi5vcmc+IDxtYWls dG86Y2Fsc2lmeUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2Fsc2lmeQ0KDQoNCipBdHRhY2htZW50czoqDQoNCiAqIHNpZ25hdHVyZS5hc2MNCg0KDQot LQ0KICBCcm9uIEdvbmR3YW5hLCBDRU8sIEZhc3RtYWlsIFB0eSBMdGQNCiAgYnJvbmdAZmFzdG1h aWx0ZWFtLmNvbTxtYWlsdG86YnJvbmdAZmFzdG1haWx0ZWFtLmNvbT4gPG1haWx0bzpicm9uZ0Bm YXN0bWFpbHRlYW0uY29tPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpjYWxzaWZ5IG1haWxpbmcgbGlzdA0KY2Fsc2lmeUBpZXRmLm9yZzxtYWls dG86Y2Fsc2lmeUBpZXRmLm9yZz4gPG1haWx0bzpjYWxzaWZ5QGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jYWxzaWZ5DQoNCi0tDQpVamp3YWwgIlJ5em9r dWtlbiIgU2hhcm1hIChoZS9oaW0pDQoNCkNvbXBpbGVycyBIYWNrZXIsIE5vZGUuanMgQ29yZSBD b2xsYWJvcmF0b3IgYW5kIFNwZWFrZXINCg0K --_000_55B0F7E9114C483087E5523CC56D3528ribosecom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIFVqandhbCwNCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPldvdWxkIHlvdSBiZSBhYmxlIHRvIHBv aW50IG1lIHRvIHRoZSBkcmFmdCB0byBzZWUgd2hhdCB0aGUgcHJvYmxlbSBpcz88L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkhlcmXigJlz IGEgc2FtcGxlIGRvY3VtZW50IHRoYXQgd29ya3M6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhy ZWY9Imh0dHBzOi8vcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbS9tZXRhbm9ybWEvbW4tc2FtcGxl cy1pZXRmL21hc3Rlci9zb3VyY2VzL2FudGlvY2gvZG9jdW1lbnQuYWRvYyIgY2xhc3M9IiI+aHR0 cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL21ldGFub3JtYS9tbi1zYW1wbGVzLWlldGYv bWFzdGVyL3NvdXJjZXMvYW50aW9jaC9kb2N1bWVudC5hZG9jPC9hPjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+KDxhIGhyZWY9Imh0dHBz Oi8vZ2l0aHViLmNvbS9tZXRhbm9ybWEvbW4tc2FtcGxlcy1pZXRmIiBjbGFzcz0iIj5odHRwczov L2dpdGh1Yi5jb20vbWV0YW5vcm1hL21uLXNhbXBsZXMtaWV0ZjwvYT4gcHJvdmlkZXMgd29ya2lu ZyBleGFtcGxlcyk8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPklmIHlvdSBoYXZlIHRoZXNlIHR3byBsaW5lcyBpbiB5b3VyIGFkb2MgZmls ZSBoZWFkZXIgKHVuZGVyIHRoZSB0aXRsZSBidXQgYmVmb3JlIHRoZSBjb250ZW50LCB3aGljaCBp cyBzZXBhcmF0ZWQgd2l0aCBhIGJsYW5rIGxpbmUpOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZxdW90Ozwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj46bW4tZG9jdW1lbnQtY2xhc3M6IGlldGY8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+Om1uLW91dHB1dC1leHRlbnNpb25zOiByZmMseG1sLHR4dCxodG1sLHJ4bDwvZGl2 Pg0K4oCcPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGVuIHlvdSBzaG91bGQgYmUgYWJsZSB0byBqdXN0IHJ1biB0aGlzOjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQptZXRhbm9ybWEgZHJhZnQtcnl6b2t1a2Vu LXRpbWVzdGFtcC1pbmZvcm1hdGlvbi5hZG9jPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Sb248L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFw OiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVh azogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSb25hbGQgVHNlPGJy IGNsYXNzPSIiPg0KUmlib3NlIEluYy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj5PbiBPY3QgMjAsIDIwMjAsIGF0IDY6MDkgQU0sIFVqandhbCBTaGFybWEgJmx0 OzxhIGhyZWY9Im1haWx0bzpyeXpva3VrZW5AaWdhbGlhLmNvbSIgY2xhc3M9IiI+cnl6b2t1a2Vu QGlnYWxpYS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJj aGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsi IGNsYXNzPSIiPkhpDQogUm9uYWxkITwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAw cHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246 IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPlRo YW5rcw0KIGZvciB0aGUgc3VnZ2VzdGlvbi4gV3JpdGUgb25jZSwgcHVibGlzaCBhbnl3aGVyZSAo YWx0aG91Z2g8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnBlcmhhcHMNCiB3 aXRoIG1pbmltYWwgY2hhbmdlcykgaXMgaW5kZWVkIGEgcHJpb3JpdHksIGVzcGVjaWFsbHkgZ2l2 ZW4gb3VyPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDog bm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj50aW1lDQogY29uc3Ry YWludHMuIEkgdHJpZWQgc2V0dGluZyB1cCBtZXRhbm9ybWEgdG9kYXksIGJ1dCBmb3Igc29tZTwv c3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+cmVhc29uLA0KIGl0IGZhaWxzIGZv ciBtZSBsb2NhbGx5Ljwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPk15DQogaW5wdXQ6 PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+ DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3Bs YXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+bWV0YW5vcm1hDQogLS10eXBlIHJmYzMg ZHJhZnQtcnl6b2t1a2VuLXRpbWVzdGFtcC1pbmZvcm1hdGlvbi5hZG9jPC9zcGFuPjxiciBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+RXJyb3I6PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+ RXJyb3I6DQogbG9hZGluZyBnZW0gYG1ldGFub3JtYS1yZmMzYCBmYWlsZWQuIEV4aXRpbmcuPC9z cGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8 YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+VGhpcw0KIHdvcmtzIHdpdGggb3Igd2l0aG91 dCBgLXggeG1scmZjYC4gV2hhdCBzZWVtcyB0byBiZSB3cm9uZyBoZXJlPyBBbTwvc3Bhbj48YnIg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SQ0KIG1pc3NpbmcgYSBnZW0/IEEgc2ltcGxlIHdl YiBzZWFyY2ggZG9lc24ndCByZXR1cm4gYW55dGhpbmcgdXNlZnVsLCBhbmQ8L3NwYW4+PGJyIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPm5vDQogZ2VtIG5hbWVkIGBtZXRhbm9ybWEtcmZjM2Ag Y2FuIGJlIGZvdW5kLjwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0 OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPkkNCiB0aG91Z2h0 IHRoZXJlIHdhcyBzb21ldGhpbmcgd3Jvbmcgd2l0aCBteSBzZXR1cCwgYnV0IEkgdHJpZWQgbXVs dGlwbGU8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBu b25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnRpbWVzLA0KIHJhbiBg bWV0YW5vcm1hIHNldHVwYCBwcm9wZXJseSwgdHJpZWQgdGhlIGRvY2tlciB2ZXJzaW9uLCBidXQg bm88L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmx1Y2suDQogVGhlIHNhbWUg ZXJyb3IgZWFjaCB0aW1lLiBDb3VsZCB5b3UgaGVscCBtZSBmaWd1cmUgb3V0IHdoYXQgSSBtaXNz ZWQ/PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9 IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+QmVzdCw8L3NwYW4+PGJyIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPlVqandhbDwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPk9uDQogMTAvMTYvMjAgOTo0NSBBTSwgUm9uYWxkIFRzZSB3cm90ZTo8L3NwYW4+PGJyIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQpIaSBVamp3YWwsPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KKFRoYW5rcyBCcm9uIGZvciB0aGUgcGx1ZyEpPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KTWV0YW5vcm1hIGlzIG9uZSBvZiB0aGUgb2ZmaWNpYWxseSBs aXN0ZWQgcHJvY2Vzc29ycyBmb3IgSUVURiBkb2N1bWVudHM8YnIgY2xhc3M9IiI+DQooYWxvbmdz aWRlIG1tYXJrIGFuZCBrcmFtZG93bi1yZmMyNjI5KS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpDYWxDb25uZWN0IHVzZXMgTWV0YW5vcm1hIHRvIHB1Ymxpc2ggc3RhbmRhcmRzLCBhbmQg YSBudW1iZXIgb2YgU0RPcyBkbzxiciBjbGFzcz0iIj4NCnNvIGFzIHdlbGwgKElUVSwgT0dDLCBC SVBNLCB3aG8gYWxzbyB3b3JrIHdpdGggZGF0ZS90aW1lKS48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpJZiB0aGVyZSBpcyBhbnkgaW50ZW50aW9uIHRvIGNyb3NzLXB1Ymxpc2ggaW50byBD YWxDb25uZWN0IG9yIElTTywgdGhlPGJyIGNsYXNzPSIiPg0KYWJpbGl0eSB0byAmcXVvdDt3cml0 ZSBvbmNlLCBwdWJsaXNoIGFueXdoZXJl4oCdIGJlY29tZXMgaW1wb3J0YW50LjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCkdpdmVuIHRoYXQgd2XigJlyZSB0aGUgZm9sa3MgYmVoaW5kIGl0 LCBJ4oCZbSBoYXBweSB0byBzZXJ2ZSBhcyB5b3VyPGJyIGNsYXNzPSIiPg0KcGVyc29uYWwgc3Vw cG9ydCBpZiB5b3UgcnVuIGludG8gYW55IE1ldGFub3JtYSBwcm9ibGVtcyA6LSk8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpLaW5kIHJlZ2FyZHMsPGJyIGNsYXNzPSIiPg0KUm9uPGJyIGNs YXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClJvbmFsZCBUc2U8YnIgY2xhc3M9IiI+DQpSaWJvc2UgSW5jLjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPk9uIE9jdCAxNiwgMjAyMCwgYXQgODoyNyBBTSwgQnJvbiBHb25kd2FuYSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmJyb25nQGZhc3RtYWlsdGVhbS5jb20iIGNsYXNzPSIiPmJyb25nQGZhc3RtYWls dGVhbS5jb208L2E+PGJyIGNsYXNzPSIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpicm9uZ0BmYXN0 bWFpbHRlYW0uY29tIiBjbGFzcz0iIj5tYWlsdG86YnJvbmdAZmFzdG1haWx0ZWFtLmNvbTwvYT4m Z3Q7Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQrvu788YnIgY2xhc3M9 IiI+DQpIaSBVamp3YWwsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlcmUncyBhIHZh cmlldHkgb2Ygb3B0aW9ucyBmb3Igd3JpdGluZyBkcmFmdHMuJm5ic3A7IEkgcGVyc29uYWxseSB1 c2UgYTxiciBjbGFzcz0iIj4NCndvcmtmbG93IGJhc2VkIG9uIG1tYXJrLCBmb3IgZXhhbXBsZTo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v YnJvbmcvZHJhZnQtZ29uZHdhbmEtZWZmZWN0aXZlLXRlcm1pbm9sb2d5IiBjbGFzcz0iIj5odHRw czovL2dpdGh1Yi5jb20vYnJvbmcvZHJhZnQtZ29uZHdhbmEtZWZmZWN0aXZlLXRlcm1pbm9sb2d5 PC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZXJlJ3MgYWxzbyBtZXRhbm9ybWEs IHdoaWNoIGFsbG93cyB5b3UgdG8gY3JlYXRlIGEgdmFyaWV0eSBvZjxiciBjbGFzcz0iIj4NCm91 dHB1dHMuJm5ic3A7IFRoZXJlJ3MgZG9jdW1lbnRhdGlvbiBoZXJlOjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lm1ldGFub3JtYS5jb20vYXV0aG9yL2ll dGYvIiBjbGFzcz0iIj5odHRwczovL3d3dy5tZXRhbm9ybWEuY29tL2F1dGhvci9pZXRmLzwvYT48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPciB5b3UgY2FuIHVzZSB0b29scyBsaWtlOjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9j YWJvL2tyYW1kb3duLXJmYzI2MjkiIGNsYXNzPSIiPmh0dHBzOi8vZ2l0aHViLmNvbS9jYWJvL2ty YW1kb3duLXJmYzI2Mjk8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQmFzaWNhbGx5 LCB0aGV5J3JlIGFsbCB0b29sY2hhaW5zIHRoYXQgZ2VuZXJhdGUgUkZDIFhNTCBmb3JtYXQgZG9j dW1lbnRzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkluIG9yZGVyIHRvIHB1Ymxpc2gg dG8gdGhlIElFVEYsIHlvdSBuZWVkIGEgZGF0YXRyYWNrZXIgYWNjb3VudCwgYW5kPGJyIGNsYXNz PSIiPg0KeW91J2xsIG5lZWQgdG8gdXBsb2FkIHRoZXJlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvc3VibWl0L3Rvb2wt aW5zdHJ1Y3Rpb25zLyIgY2xhc3M9IiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9zdWJt aXQvdG9vbC1pbnN0cnVjdGlvbnMvPC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNo ZWVycyw8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCcm9uLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCk9uIEZyaSwgT2N0IDE2LCAyMDIwLCBhdCAwOToyMSwgVWpqd2FsIFNoYXJt YSB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5I ZWxsbyBldmVyeW9uZSE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MgZm9yIHRo ZSBhbWF6aW5nIGRpc2N1c3Npb25zIGFuZCBoZWxwIHllc3RlcmRheS4gR2l2ZW4gb3VyPGJyIGNs YXNzPSIiPg0KY29uc3RyYWluZWQgdGltZWxpbmUsIEkgc3VwcG9zZSBJIHNob3VsZCBzdGFydCB3 b3JraW5nIG9uIHRoZSBkcmFmdHM8YnIgY2xhc3M9IiI+DQppbW1lZGlhdGVseS48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiB0aGUgSUVURiBzaWRlIG9mIHRoaW5ncywgSSBzdXBwb3Nl IEknZCBuZWVkIHRvIHN0YXJ0IGJ5IGNyZWF0aW5nIGFuPGJyIGNsYXNzPSIiPg0KSS1EPyBJcyB0 aGVyZSBhIHNldCBvZiByZXNvdXJjZXMgeW91IGNvdWxkIHBvaW50IG1lIHRvIGluIG9yZGVyIHRv IGdldDxiciBjbGFzcz0iIj4NCnVwIGFuZCBydW5uaW5nIHF1aWNrbHk/PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KQWxzbywgd2hhdCBzaG91bGQgSSBkbyB0byBnZXQgdGhlIGJhbGwgcm9s bGluZyBvbiB0aGUgQ2FsQ29ubmVjdC9JU088YnIgY2xhc3M9IiI+DQpzaWRlIG9mIHRoaW5ncz88 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCZXN0LDxiciBjbGFzcz0iIj4NClVqandhbDxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0tJm5ic3A7PGJyIGNsYXNzPSIiPg0KVWpqd2Fs ICZxdW90O1J5em9rdWtlbiZxdW90OyBTaGFybWEgKGhlL2hpbSk8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpDb21waWxlcnMgSGFja2VyLCBOb2RlLmpzIENvcmUgQ29sbGFib3JhdG9yIGFu ZCBTcGVha2VyPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+ DQpjYWxzaWZ5IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpjYWxz aWZ5QGlldGYub3JnIiBjbGFzcz0iIj5jYWxzaWZ5QGlldGYub3JnPC9hPjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmNh bHNpZnlAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpjYWxzaWZ5QGlldGYub3JnPC9hPiZndDs8 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NhbHNpZnkiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2Fsc2lmeTwvYT48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQoqQXR0YWNobWVudHM6KjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyogc2ln bmF0dXJlLmFzYzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxi ciBjbGFzcz0iIj4NCi0tPGJyIGNsYXNzPSIiPg0KJm5ic3A7IEJyb24gR29uZHdhbmEsIENFTywg RmFzdG1haWwgUHR5IEx0ZDxiciBjbGFzcz0iIj4NCiZuYnNwOzxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86YnJvbmdAZmFzdG1h aWx0ZWFtLmNvbSIgY2xhc3M9IiI+YnJvbmdAZmFzdG1haWx0ZWFtLmNvbTwvYT48c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0OzxhIGhyZWY9Im1haWx0 bzpicm9uZ0BmYXN0bWFpbHRlYW0uY29tIiBjbGFzcz0iIj5tYWlsdG86YnJvbmdAZmFzdG1haWx0 ZWFtLmNvbTwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xh c3M9IiI+DQpjYWxzaWZ5IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0 bzpjYWxzaWZ5QGlldGYub3JnIiBjbGFzcz0iIj5jYWxzaWZ5QGlldGYub3JnPC9hPjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFp bHRvOmNhbHNpZnlAaWV0Zi5vcmciIGNsYXNzPSIiPm1haWx0bzpjYWxzaWZ5QGlldGYub3JnPC9h PiZndDs8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NhbHNpZnkiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2Fsc2lmeTwvYT48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7 IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+LS08c3BhbiBjbGFzcz0iQXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAx MnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4 dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRh bnQ7IiBjbGFzcz0iIj5Vamp3YWwNCiAmcXVvdDtSeXpva3VrZW4mcXVvdDsgU2hhcm1hIChoZS9o aW0pPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9 IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Q29tcGlsZXJzDQogSGFja2VyLCBO b2RlLmpzIENvcmUgQ29sbGFib3JhdG9yIGFuZCBTcGVha2VyPC9zcGFuPjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_55B0F7E9114C483087E5523CC56D3528ribosecom_-- From nobody Mon Oct 19 18:26:47 2020 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 0784A3A0B5D for ; Mon, 19 Oct 2020 18:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.247, 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=igalia.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 pxpDlx6A059w for ; Mon, 19 Oct 2020 18:26:43 -0700 (PDT) Received: from fanzine.igalia.com (fanzine.igalia.com [178.60.130.6]) (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 C9B123A0A9D for ; Mon, 19 Oct 2020 18:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=igalia.com; s=20170329; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=MdUjQhxFlaRCcTHCr0vnHlrU5kkPBE8cK8gtiDV7CB0=; b=Oplv8OxT0cSA2uinyx7IKpZtMGLZC1iUM8ULiEcJFpgKkMEx1uZ5m1QWuxtskswAoNXOBsrZt3igli5VCAWvl2NPuKVCnlutJLYIJBAn3TEjJIE+V8a2294tFj9lzb21IyVvOeVT9OFE7NcNaGF4LmaaGmZYsuDojMXYduMIBp3miqzdKHWWfmR0QZPmp0f/4jdE/jEKnneRTUqoHNY4iLp2WHKzJ6V9GPxCqGKXRiOpLZWGiLU43vE49J2Bpl2FUGdCx/Wd4o/dpe0Wz21YSIGl39CDRMuFM1rTbC4aI9SEp9v8JzLOiolmQ5xzRgmjvwjweMuLOD6flnL0G5hRSQ==; Received: from [183.83.215.161] (helo=[192.168.0.110]) by fanzine.igalia.com with esmtpsa (Cipher TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim) id 1kUgQA-0008Aj-Dk; Tue, 20 Oct 2020 03:26:38 +0200 To: Ronald Tse Cc: "calsify@ietf.org" References: <668b5100-aab0-4353-bc11-132ed1f3785a@dogfood.fastmail.com> <55B0F7E9-114C-4830-87E5-523CC56D3528@ribose.com> From: Ujjwal Sharma Autocrypt: addr=ryzokuken@igalia.com; keydata= mQINBFpsLAwBEADb/gc4ouvNQQc3ZmwVAOewWuWve9xA3B/ok+DhzSx2wJ82FR5s+198Y++s oMb4VyiU0FOk6FUUBSn1OTTEB5TVW904hqczD3qLDIbZD6bL9sor1W/8ok0q3q8hr/ICyiSC 6FuTROjXOL31Hs8pob/YsNX6e5g+o7/tSb0gXH6r1Dw7DL7gRqMrMFJRoBZZOwvu75PxFRCr bJ/GfkMv5ovLO2/Oj4P3/VbM4FzHSbn4r/CD/RrL3Qwhn94CoDv0fSzsGKqESbeVYjiqREWU 4oL5PR6PbPD9RXXw/wBUqIvGuEN8lKCpxsLHhPfYA4i7+en3JRot8O+Lk3nu1qEL7ED75Zot MbHGyZ6NxRv12mtX9aVWQAy7g3xNoEh3baqEpYcAXtgbX24aTX5etL1y3Z6cUBHSUTKHlHix egmjSUEkaY/qmTTCvJUGhTU+tYGHBnh6Eibg1NVKeIXdCZBhLqp4NqrivXBQxWAnN4Y7jtCQ O+uQIptIiL1YVcQrU8D/0Y6Pl3kWo8AUd3Nu+Dd+qEJqSimrcNzIjZqoun+ADrVoufzkMT5C ELT1YsS5TH3vGn4qtvGQU+/MQDMMm4vlVlaIHtAExiNHwLQ9NsFDWN6B4vvAvGv5PBanbMJJ b9iA1mCuVZnP+q/dxGQubRY3i+RqA8pyfx03G5yFr0CMjwqbEQARAQABtCRVamp3YWwgU2hh cm1hIDxyeXpva3VrZW5AaWdhbGlhLmNvbT6JAk4EEwEIADgWIQSsOTVT+mJCZQ85wB4f07R7 g/RmIQUCXgnwfgIbAwULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAKCRAf07R7g/RmITovD/0Q T+kIEIBrVppJ7dNp4Pyg1hF7O4pVlu9MI6fu95bGwmXSU5BpohYSCn33d8YwPnHZH698UC0Y Zd2FU2foynYn5XUJRaiDEynK9rmZxIB33IANLfEbxC1u1sby7n154wvk7r5kBJLesR2a/Wlb Qr6q8LMCGvWQf/IAQzOdsylwnuDeKDSLrlOI0XoGizRg9ojExOGiR8cPNnhYNM35UmXEwYXN mDkoUV3unT2dXgW2HQfhc83SlfSqB8+2bLi94LTgZm5eBQxEzbj5wFyGElIURksA8SPvXY2R 0xx24odyGQi1CO16RXcBCOtqHUaH8UnyPeHg4lRBiIarZtzbPMh4h+YBoiuD6iczfLc/II5E 8852XD9PFX8y69y98bLfSBlMz/RIjZ1An9oIgIqFMtPnt1FB5LCNoe2iOXmzA8tuSHDXzYzw GvXix5cgOma4oAqzLphG9GwxhJiOL6eOjf2VzjfZYOrduuJBsJ+60rCvURiAeHbt8ogQVHNb DKImEseQY0h0pyM7r0FRRynyEya5GUF6vdaVL4DkwHJ6OphSlF4TW12XKdBMG8APNF5tx3f+ K732lrAVnqQfTm12hQp/9mpkTQ0edpgoEW+ZWvWOGotyzyWF1uzvVHa9zwwJWvjU2tKINaKL E8x8728etREcX39GKqZWNFqJZN1L3KivQbkCDQReCgRfARAAooqzPt/mQ6vO2zn3JqA4cjVu +VuxmGuBL7VclmzYG1veTrkqOgBW1lxLSLEJLrDyfvC40RDS+QgBqmtbQ8x3ccOkcCNTMoj8 8lx5BiGUInjT6wkmRYejGsw8DuKkIWnWrrv628xZiB+fhwWxc5lu3kb5LEh9eUEDrHUhMzSy svKJlpuLd93zGGtC5KAeqZhUH1pCc0FBxbBBqy0bcfYKuRcNSO7YFHIAGRbYeQMOivhMXC2z Zq6YEdLxnAl21OQlRkv77XinSD4e2Yb7WFK0MgvQsdwLOhM5pHBcuc6MkGLm/lMM8VO8N9o6 n4QyZA5LsfhTd0kGleoII0YO9RQOLHRdiPKlvDbD1B9Mg58hQakBbJF07eAwEJq/a+LhzhW+ VHlZWNV0h9tSugSgq3nOt6wG/ftVMRILREMFUDI63+UR4PXJ++l3TNBd/5RZCmuWFoavc/Tl AcQG/aQt5Ezh9AdD0Ao+5VL2ATjNSHMxH+AnEagnx2vmJC5I+LqATfgn6CX4DzatFSA9LxZX LPiXlMGWH6JogJpIQqaHulqjfko2Mb4eHuYvdl1Wova03w1BUA/EHUnJIaGVXlV5E69ubJTm SXqEAixL6vYsljJ0fO4IxBlT71aRyrvaKW37fWG2c/csjgB25U2Y7tdWY4xA96LynAurJSRJ Jj+Urmz+Bm0AEQEAAYkEcgQYAQgAJgIbAhYhBKw5NVP6YkJlDznAHh/TtHuD9GYhBQJe6vw+ BQkBzkXfAkDBdCAEGQEIAB0WIQRMXCPh15S+uPoc6Av/592ik3N4ZAUCXgoEXwAKCRD/592i k3N4ZKvZEACQNX7g5NPdRNwl0+UXy/NK2nQVOu/0Vel9giRzHfhgjetWBTzsl2DvnMoi8VG3 sY4ztOkpERm33HHOcFKXlJ3qCZ0mjAa9+pH6IpJEvpqc4TJ6o92dB4lqJNuJQBDVsYcuM4+C hPM0LnrJgJ9/SMeuWgVrT9sXC3nuJlx0ZcKo4eW/K7t3IVc3IcXV3V0ORm5hf+W30A+SUY1F xteU+7/wccI1WfjGNC9q2e3ywVsWAVfQu5kS94QhY3S1vJJ6bfZ9zpql8IuP6MczlTkFzvo6 j7CJ5ymF+A952AoU5Mj8Z+qwAt2OCpEbMufMMdexczTbg9edzhtHWAHnX/uE4d/d9HF4VryU xpg3ZZ4mse3UJTQ8AF2vQhOXT7B5d8QI0QKeH4qmhDCrgXDoXyV107TJ6ScZkFI1MmEoyZEf cv6tTiIfn70gfNXntKdqkt7E7lqybofkDEj91qelPlnE0nRH0tDMq5xJSe1DLPPlSYdnk5Z6 2g/rXAGmzvjVlj5Uw6nw/SfTgE275tVWFA1fkMjjVJFItmmwxDu6dez7QZKYlIC2mvk7ZvUW mlUVmyauJFKVMFlrH0AxWFRwMlmyiSrcy4lN93SjlQHAx9Nt23C7OnKUC83sA+jlaHsdQb7k hqAGpgzW78ijWe45CYrmXNzRsgf59nuTWIxcZrU7ck5CugkQH9O0e4P0ZiFfghAAn/dUwP2T OIGAPsvFLEvPKecBGwJITFvm9cbPqUE26D2gOC4EyJuCJlvXfn97sYcv2/c6g5CGgkJxcjnH 3Z8z1Yzkg3JCDi78lmFsw/N3VQdSJAqLJRUeVfcsudZh+LNMPW7FRRXqUb8ZrtCrMtsrWTL7 iVy0qKmWIOBHyhJZCUIVo3GZHZFePsqMRObZlSDUekGkhJ5MNRLcZaLLBVUIMgfNIVMww11M Yk0rmk6i74EYre2+jVc8HQMjkvRb/zqZzWNsqqR+PB4f+lLMAi4E9+8AKCyN1RQa525dnhYs XxiyvPwWpddfKHbDzUSi6z70x5ry3mFx1i+OixKhv2jpqNUXG3B73xsId67gTs6eRy42/JJJ rJ2NC1y0uflJmLamPVxHPZi6h1jqcRFmq5/vvuSWvWPQbTGQeReflRbLTzfSUlOaMll3YedV 07dGKYjmLNy+1vrM/Mwa0So6kAmeYQSk5FbFcrqDHDWcv98E7pP8Kozah/ryWUtVfdGTSCXW dMecSCyuMzAteW6JRlOOOMmN92YBaULxq7ERa4cOL0Vkz5vlzGbkg2wAobgRmXP4LaBJ6kVU Qp9SUTwjwKAVF+i1Tpw38BXLtJphdIOPV1QZmK+5CPMDjGifPlyDUSdA4T6h/Nr8bTjuQUkY HEUDJZMWsP+L5v1mK7gP9mdJiJa5Ag0EXgoFEgEQALOhu272DYYvbhw6kOirE1AR6ncs0i0T wDB/YnEMkBi/J7coe51I171TLaqTb5cwhs2chRUMiIvGft96/efypDnGZnvVZh80tiBUlcI9 tckQj4A7DYlAFNfdZAVKUP+G49P9N1EB8wFnc8X/YPjFP/iB169d8YyHgfibcvZbeOkMWq70 bt4maZVWCYI6r/RkFYrlgVlO28GrURELPW/B5cf+NXg8tFvxv9MR7QEWh/VHZ3CsYq1+4p0A ZEixg0D1ynvV2LS7sqca2eHxXhzX0VXdvjCKWY468E5eYlHkyOFdsbdiGgyZB5L25y/CIeyZ sQz3unYWYZ3E4UcJFm8hgsl8YWMSYl98IORpZVQ7YII2dnwPB5aRIfJgoKl5rP/AsKLV2dzj p+6yljrA2czat1c8MWko2IO/QMpzMFmWkuZiSBwNXQuByYUF0SM10pY6faApo/wWnLyEcwPF 0hmmlj0gLkkT46zdLFxRI0kzUPX7tPKqNc2hPzyHSrKXPuqJyWnq2lvS3LxNRngiRb28mKbg GQpE/iX3whzcVs1kAAL8DaiLIKWmJ5bbYEy3DzTuysMgK2lCeqGGj3p6xczPwrJQkDQKwnwf 6KLMEA6RlbWThmC2eWxPi+TLV4/HTbvabYuOBhVd4xwZZ+WfhgYCR5XmaKknKs3D8YOv3qdv EZj/ABEBAAGJAjwEGAEIACYCGwwWIQSsOTVT+mJCZQ85wB4f07R7g/RmIQUCXur8SgUJAc5F LAAKCRAf07R7g/RmIYbHD/4rekfbk8ZY2q4/wdiH9NpfYLzFQhsylQ1Knqau4oPTFXUPY2bz 9X/LMTwj7fVGa5rtC9uuoDKnmdxq7qzItf2oO+jE6RM2nDXZWeXDubQZlFgNQOde3PvTjJxF CgMwTgFl5Ydh6HQZlgcf13BbXwdF2b1d8kI1SFMkk6dgCWQJfmcRUYrTNfv4CB5dyZvnDLBF N1tmePnUpsn6gDxigr3sXJ3TE4R+mZrYNddW/0Km3X4bMi1lD7n/tmWyLJfQpsOXxInWPT0K 5eFQ/kGWeheAoiYFTGzCnbLLYWzaMRqxfBzze+eP0Jt8tQVcm7Xr7k8GE0811JHhKtTduoX6 /UF0U2+VNdQsYLWVMag/Eb/KeHBCNruEVEcOhGl1eamDIO33fnP/7bs2M7NP+p1rE4tGxLrr oxK5HC7ZDSye7nHfROK1CUzT3ALVupyVQrC6sa4vbUhtpnB3Q2K7fH660YbG6bLaDjHRNfRJ ER5JsjGz7YJi6Snig1eyAkFMEfZym2vxUSagFbi5u5KHteWy1GuaEkPowB4/4/PKmoh7+ec7 pqSM0a9F1fsScQa5SpzGaG5BeTOBz5PPb+528NFZKtt67nHKxJKbVxortLiRjxp6FoXY2x69 8q+jogfmP5bMqkUzHcdOXLzApLyoxOgEGqS3Bn7mBR0C8aUPeowlESZUtw== Message-ID: <8150222c-8e80-58fa-3b77-e5b9faba572a@igalia.com> Date: Tue, 20 Oct 2020 06:56:00 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <55B0F7E9-114C-4830-87E5-523CC56D3528@ribose.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="iITccVrbHdmlUDOkY5kll93xNkj1kDB3x" Archived-At: Subject: Re: [calsify] Getting started with the calendar persistence format 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, 20 Oct 2020 01:26:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iITccVrbHdmlUDOkY5kll93xNkj1kDB3x Content-Type: multipart/mixed; boundary="EujNrsgFjWcQ16FhhQCinahYkIj1I6kOr" --EujNrsgFjWcQ16FhhQCinahYkIj1I6kOr Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hey Ronald! I managed to get it running. The document I was using was the same that you linked to, and it seems that while the file works quite well with just `metanorma`, the command on the docs website (`metanorma --type {rfc2 or rfc3} -x xmlrfc {my-document-filename.adoc}`) needs to be fixed. `--type` is `ietf` and `--extensions` is... well, not `xmlrfc`. I would try to make a PR to the website later if this all sounds good. One last thing I need to get started for real: where can I find the source for RFC 3339 (since I was supposed to use that as a starting point)? Is there a source at all? If that source is not in asciidoc format (I'd imagine not), is copying manually from the text file the best I can do? Cheers, Ujjwal On 10/20/20 5:00 AM, Ronald Tse wrote: > Hi Ujjwal, >=20 > Would you be able to point me to the draft to see what the problem is? >=20 > Here=E2=80=99s a sample document that works: > https://raw.githubusercontent.com/metanorma/mn-samples-ietf/master/sour= ces/antioch/document.adoc >=20 > (https://github.com/metanorma/mn-samples-ietf provides working examples= ) >=20 > If you have these two lines in your adoc file header (under the title > but before the content, which is separated with a blank line): >=20 > " > :mn-document-class: ietf > :mn-output-extensions: rfc,xml,txt,html,rxl > =E2=80=9C >=20 > Then you should be able to just run this: > metanorma draft-ryzokuken-timestamp-information.adoc >=20 > Ron >=20 > _____________________________________ >=20 > Ronald Tse > Ribose Inc. >=20 >> On Oct 20, 2020, at 6:09 AM, Ujjwal Sharma > > wrote: >> >> Hi Ronald! >> >> Thanks for the suggestion. Write once, publish anywhere (although >> perhaps with minimal changes) is indeed a priority, especially given o= ur >> time constraints. I tried setting up metanorma today, but for some >> reason, it fails for me locally. >> >> My input: >> >> metanorma --type rfc3 draft-ryzokuken-timestamp-information.adoc >> >> Error: >> >> Error: loading gem `metanorma-rfc3` failed. Exiting. >> >> This works with or without `-x xmlrfc`. What seems to be wrong here? A= m >> I missing a gem? A simple web search doesn't return anything useful, a= nd >> no gem named `metanorma-rfc3` can be found. >> >> I thought there was something wrong with my setup, but I tried multipl= e >> times, ran `metanorma setup` properly, tried the docker version, but n= o >> luck. The same error each time. Could you help me figure out what I >> missed? >> >> Best, >> Ujjwal >> >> On 10/16/20 9:45 AM, Ronald Tse wrote: >>> Hi Ujjwal, >>> >>> (Thanks Bron for the plug!) >>> >>> Metanorma is one of the officially listed processors for IETF documen= ts >>> (alongside mmark and kramdown-rfc2629). >>> >>> CalConnect uses Metanorma to publish standards, and a number of SDOs = do >>> so as well (ITU, OGC, BIPM, who also work with date/time). >>> >>> If there is any intention to cross-publish into CalConnect or ISO, th= e >>> ability to "write once, publish anywhere=E2=80=9D becomes important. >>> >>> Given that we=E2=80=99re the folks behind it, I=E2=80=99m happy to se= rve as your >>> personal support if you run into any Metanorma problems :-) >>> >>> Kind regards, >>> Ron >>> _____________________________________ >>> >>> Ronald Tse >>> Ribose Inc. >>> >>>> On Oct 16, 2020, at 8:27 AM, Bron Gondwana >>> >>>> > wrote: >>>> >>>> =EF=BB=BF >>>> Hi Ujjwal, >>>> >>>> There's a variety of options for writing drafts.=C2=A0 I personally = use a >>>> workflow based on mmark, for example: >>>> >>>> https://github.com/brong/draft-gondwana-effective-terminology >>>> >>>> There's also metanorma, which allows you to create a variety of >>>> outputs.=C2=A0 There's documentation here: >>>> >>>> https://www.metanorma.com/author/ietf/ >>>> >>>> Or you can use tools like: >>>> >>>> https://github.com/cabo/kramdown-rfc2629 >>>> >>>> Basically, they're all toolchains that generate RFC XML format >>>> documents. >>>> >>>> In order to publish to the IETF, you need a datatracker account, and= >>>> you'll need to upload there: >>>> >>>> https://datatracker.ietf.org/submit/tool-instructions/ >>>> >>>> Cheers, >>>> >>>> Bron. >>>> >>>> On Fri, Oct 16, 2020, at 09:21, Ujjwal Sharma wrote: >>>>> Hello everyone! >>>>> >>>>> Thanks for the amazing discussions and help yesterday. Given our >>>>> constrained timeline, I suppose I should start working on the draft= s >>>>> immediately. >>>>> >>>>> On the IETF side of things, I suppose I'd need to start by creating= an >>>>> I-D? Is there a set of resources you could point me to in order to = get >>>>> up and running quickly? >>>>> >>>>> Also, what should I do to get the ball rolling on the CalConnect/IS= O >>>>> side of things? >>>>> >>>>> Best, >>>>> Ujjwal >>>>> >>>>> --=C2=A0 >>>>> Ujjwal "Ryzokuken" Sharma (he/him) >>>>> >>>>> Compilers Hacker, Node.js Core Collaborator and Speaker >>>>> >>>>> >>>>> _______________________________________________ >>>>> calsify mailing list >>>>> calsify@ietf.org =C2=A0 >>>>> https://www.ietf.org/mailman/listinfo/calsify >>>>> >>>>> >>>>> *Attachments:* >>>>> >>>>> =C2=A0* signature.asc >>>>> >>>> >>>> -- >>>> =C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd >>>> =C2=A0=C2=A0brong@fastmailteam.com >>>> =C2=A0= >>>> >>>> >>>> _______________________________________________ >>>> calsify mailing list >>>> calsify@ietf.org =C2=A0 >>>> https://www.ietf.org/mailman/listinfo/calsify >> >> --=C2=A0 >> Ujjwal "Ryzokuken" Sharma (he/him) >> >> Compilers Hacker, Node.js Core Collaborator and Speaker >=20 --=20 Ujjwal "Ryzokuken" Sharma (he/him) Compilers Hacker, Node.js Core Collaborator and Speaker --EujNrsgFjWcQ16FhhQCinahYkIj1I6kOr-- --iITccVrbHdmlUDOkY5kll93xNkj1kDB3x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEETFwj4deUvrj6HOgL/+fdopNzeGQFAl+OPKgACgkQ/+fdopNz eGTtQg//SWJI7Ln2xO0nm18iEW2yp0crJ17kGmb4zGPeWlHN6Ve8EbsdYXeNUXIm EWca3BU7BXmwF0IEPjpPlbJrxWLLGDcKfkzaC/6cy8zRFdO/nrFidTnjXZ0jtZ6O UlYBdNDzc7DKjwPyBBDmbeytXtO/3UXFVIiUHoTKw6b6VIpJWYEsCn3YQogF1P9s mqEFBHWa6W86NN023VHZ+Dzy/n5Lyt2DgRIyk5blPMVFBdYQjMJXQScr27ueLzF2 T5COnNDsGTc4ozN09aXqCFiHHmwBlAmtr7lEi+Uh9yWNmjE5UxteE4PuKxEpjfi8 O6gtf8+qCuvRFUbMu+AwmeA3s7Xm5bGom9EYNZGPtFHYciLA83IJzTsagKv3Vsak VbJLs1VO6qlgCMZDqu7/UUGXzg24z3HH9qpNhLW43MjSS/UsuBeR8Z1ZA1V9qzw2 x0RvCBPrbYtxmMmJYyC263xoEnbhmTJlvZZwwDJSrpbsY6oZv4pdQ/7Zb1meOe8+ nkJ9tImVG0cJ+UeZlCfuts9aPa4xParx8puP3n9UHhAIBC8N1XkMtgWMDoUHd/eY OY/0MIVQKfCJXzQMifD2hki+kbCNvapQ1xHsh53G/JxJGO0N8yJjEuBOz0qt+q+f 5BW+4ttE5LxZl+7T0dKeABYg7g891IMxG+wsKw34rs19hMk2iOs= =tG9j -----END PGP SIGNATURE----- --iITccVrbHdmlUDOkY5kll93xNkj1kDB3x-- From nobody Mon Oct 19 19:19:56 2020 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 B31153A0EA7 for ; Mon, 19 Oct 2020 19:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=ribose.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 N-j5BQT02qOu for ; Mon, 19 Oct 2020 19:19:50 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320051.outbound.protection.outlook.com [40.107.132.51]) (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 A4E183A0EDF for ; Mon, 19 Oct 2020 19:19:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dRtHew8xUf2vlX1jGLYCHaVbTOjKvrtdgdc0nc4UMuGGDwdcFUAsicxZCVR1tV+LK4rh5Ds/oJ7Y4tyWOzF5ziLH15pBDkwudusKmlwr++L4uLLwkGfGnbjFT6yFtBaafN7cuDrS1MVpIgKmrb2rNBcY8Doop0HQrsJpfNM34AB8geMVMiS+NjKnDb7TK3oNGBKMKpsaRMVDFVcrnltGxgSQJ/7Ka40HzxKPIlPDvW3y+iiMNmt71js+Io1El9EVUaBQjpGnYh0y5U331L+x9z/FwShwU0zXCR4yXVEi2edWCNjqQJ2jLU4TZedC4PhQ2BH39/0iJH5yvoAxZCUfNQ== 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=tS/WR6uN5ltv7pfpJf4zE+Yw/mhqs5oR70/0OUjcnYM=; b=JhAjMG/3K+oCc5bnMXkDVT9oMmn10xrfVNB1AyCjmGaclF/N93GDOEtHw88umYBLzkyfFT9tM4srvQP2R+bnqcqm8F5rdnKfQVkV64X67zB57d00r7O9aoDI5+yk3PngBLccPVA7w28QWbA9EFFqJdR1JZCOozFQN0HzB0asmACd4MxNkhTyiHl9h8XfGNV6tDhuUMolzTmri1VpszsYyM0068+SE4o1PUq3AGTMQVP+19zSopnPNkOMM++h4RBhEznprMwHAa2+VOoh7FhEASsk+v2qaYGQDe8xkpZh65mir29vVwoyHOGQfEHFRMwyVySl6sju3IpFBwo8ziIudA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ribose.com; dmarc=pass action=none header.from=ribose.com; dkim=pass header.d=ribose.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tS/WR6uN5ltv7pfpJf4zE+Yw/mhqs5oR70/0OUjcnYM=; b=PrTMF9lBIs3ZPJOx22IutriP9m1x6CyfIiYsQ7PzLgMK3xxoc9f2qE5mIQrGz/A6nyC8OzlPvkoX03oFFI6/lJbAj26BEvCKaWrZZn4h6nF4PnRGCWD2oPcTHEbapH9HfYf5bqNg9uhckCke0kFOz/s6KP9oEKJCkzPnGA8QF68= Received: from HK0PR01MB2900.apcprd01.prod.exchangelabs.com (2603:1096:203:98::14) by HKAPR01MB3731.apcprd01.prod.exchangelabs.com (2603:1096:203:db::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Tue, 20 Oct 2020 02:19:44 +0000 Received: from HK0PR01MB2900.apcprd01.prod.exchangelabs.com ([fe80::b8:4b19:ebf4:7724]) by HK0PR01MB2900.apcprd01.prod.exchangelabs.com ([fe80::b8:4b19:ebf4:7724%5]) with mapi id 15.20.3477.028; Tue, 20 Oct 2020 02:19:44 +0000 From: Ronald Tse To: Ujjwal Sharma CC: "calsify@ietf.org" Thread-Topic: [calsify] Getting started with the calendar persistence format Thread-Index: AQHWo0GwGjTIredru0qplU+nj0MZpqmZX5UAgAA/4QCABeLugIAAFsUAgAAgQgCAAA8DgA== Date: Tue, 20 Oct 2020 02:19:43 +0000 Message-ID: <2D392BD8-0D78-414F-A1FF-33F27E03E6B6@ribose.com> References: <668b5100-aab0-4353-bc11-132ed1f3785a@dogfood.fastmail.com> <55B0F7E9-114C-4830-87E5-523CC56D3528@ribose.com> <8150222c-8e80-58fa-3b77-e5b9faba572a@igalia.com> In-Reply-To: <8150222c-8e80-58fa-3b77-e5b9faba572a@igalia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.120.23.2.1) authentication-results: igalia.com; dkim=none (message not signed) header.d=none;igalia.com; dmarc=none action=none header.from=ribose.com; x-originating-ip: [118.140.121.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e0eb6d71-9214-411b-8c14-08d8749e9bd1 x-ms-traffictypediagnostic: HKAPR01MB3731: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5DSBEzi3B+mZ8i/jtOS51zaF643g9Qa2FZuM24ZINDX9mWFY5OdQAzmiOAmZbMqZgiMjvhMCI2t4a2xo9TM9X5PUfn0VBlViClmRZ7JQhZUg8uzT1RyH6Wwz7DGwU4rV9oizfQnsL9XiKhX38YO8OFOU/m5Pq4EZiWH11rk79EbngVnsowlYIFd8RlUmlyMYiYQYSZw6wW+TgOPqc67MQE88Y0zxmzPWBPETCdXNCuIbIfNmidHzDR1WeiTXJ0LYgDCNwEoHB47eojtP9yqsTPdHviYwpW9lzCIYkkO08vCaiSOlmoDVuqGk6yhNm5cMj+Zb8Xr9iZW4FHIfzIJRb0VvhGL/8N25vBNgDT8aMRIwcmFmu1qNTQZSQ/ev2OcEciS5dxM585tLf1zn5CHpDg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HK0PR01MB2900.apcprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(39830400003)(376002)(396003)(366004)(346002)(136003)(166002)(2906002)(8676002)(8936002)(33656002)(36756003)(6512007)(83380400001)(26005)(6486002)(71200400001)(2616005)(4326008)(316002)(76116006)(6506007)(53546011)(66946007)(5660300002)(66476007)(91956017)(966005)(478600001)(6916009)(86362001)(186003)(64756008)(66556008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: FBweKUjuvYPGuAWgJCkzJRhMOpLtP9RiiNA9iivv9t120euOxX+DPvqYGb7wDgOnTevg7/7AAp4yxkdEmjWpy5UlDm2p+bSsrPXHcBdEysWI5QKYUXwviZMx3YEnnf75XLI+UfSuZEyyY3NGyZQ3TW96sch5D7SNKqBDRZt0TuqFfnhbWDXTlJ9Y4bkKx/smBVA8D7rerI4jNWHyLq37k3Xw5L9wBT/D0eeOGPtcSfAcfBvjQlOBwFwcumV5leCtaOwJHfb+2+zqZtDLaIdf4G17xmIFi8v18mKzSi1WgsvePU8TUrdWSx+65y9HBj6jn5u+RTbq3Hvn1LZOYK5G8icKNdXBLLN9wO4P8y2FgIExLoaTQK2wuHEbSSRPuQ3W/jV2c76MzSCTjegQmWwPOwpxmDj5cLHbsY+dcdPjGa/PDXXDSjIOB75VnnNOHnFUJeY1qS2EIWRuH0TtJWIwir7hiCWe7doOkyEf0zyy1yekqAr6H6UK5Zu1qVzcGOpwkKMRDSPAbqJBeXb2sswJcDScqpX8fJjYA3N+todHZDEcfoXxwJSd1TGDdvLUi4SRz5en0CVb4BNJEre1ctuItPPnVk3uFHgdtDfiYMuHj+wsEQnz2mlmvuRIdhDpvOswsHiKEhwfSZnhqwYLKAfPrQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_2D392BD80D78414FA1FF33F27E03E6B6ribosecom_" MIME-Version: 1.0 X-OriginatorOrg: ribose.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HK0PR01MB2900.apcprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: e0eb6d71-9214-411b-8c14-08d8749e9bd1 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2020 02:19:43.9002 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xSGj1KLFgqlxp5tUAMbG/HE3X7cy8iJjuO5znmNBXTqwK+Ayr/B3NhIvIxAS7+eU X-MS-Exchange-Transport-CrossTenantHeadersStamped: HKAPR01MB3731 Archived-At: Subject: Re: [calsify] Getting started with the calendar persistence format 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, 20 Oct 2020 02:19:55 -0000 --_000_2D392BD80D78414FA1FF33F27E03E6B6ribosecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVWpqd2FsLA0KDQpTbyBzb3JyeSBhYm91dCB0aGUgZG9jcyEgQXBwYXJlbnRseSB0aGV5IGhh dmVu4oCZdCBiZWVuIHVwZGF0ZWQgdG8gdGhlIG5ldyB2ZXJzaW9uIOKAlCBJRVRGIGEgZmV3IG1v bnRocyBhZ28gc3dpdGNoZWQgdG8gWE1MIFJGQyB2MyBhbmQgdGhlIGNvbW1hbmQgbGluZSBvcHRp b25zIGZvciBJRVRGIGhhdmUgYmVlbiB1cGRhdGVkLiBXZSBoYXZlIGEgYmxvZyBwb3N0IGFib3V0 IHRoZSBjaGFuZ2VzIGJ1dCB3ZSBkaWRu4oCZdCBhY3R1YWxseSB1cGRhdGUgdGhlIGRvY3MuDQoN CkEgUFIgd291bGQgYmUgbXVjaCBhcHByZWNpYXRlZCENCg0KUmU6IFJGQyAzMzM5LCB3aWxsIHNl bmQgeW91IHRoZSBhc2NpaWRvYyB2ZXJzaW9uIGluIDIwIG1pbnMuLi4NCg0KUm9uDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KUm9uYWxkIFRzZQ0KUmlib3NlIElu Yy4NCg0KT24gT2N0IDIwLCAyMDIwLCBhdCA5OjI2IEFNLCBVamp3YWwgU2hhcm1hIDxyeXpva3Vr ZW5AaWdhbGlhLmNvbTxtYWlsdG86cnl6b2t1a2VuQGlnYWxpYS5jb20+PiB3cm90ZToNCg0KSGV5 IFJvbmFsZCENCg0KSSBtYW5hZ2VkIHRvIGdldCBpdCBydW5uaW5nLiBUaGUgZG9jdW1lbnQgSSB3 YXMgdXNpbmcgd2FzIHRoZSBzYW1lIHRoYXQNCnlvdSBsaW5rZWQgdG8sIGFuZCBpdCBzZWVtcyB0 aGF0IHdoaWxlIHRoZSBmaWxlIHdvcmtzIHF1aXRlIHdlbGwgd2l0aA0KanVzdCBgbWV0YW5vcm1h YCwgdGhlIGNvbW1hbmQgb24gdGhlIGRvY3Mgd2Vic2l0ZSAoYG1ldGFub3JtYSAtLXR5cGUNCnty ZmMyIG9yIHJmYzN9IC14IHhtbHJmYyB7bXktZG9jdW1lbnQtZmlsZW5hbWUuYWRvY31gKSBuZWVk cyB0byBiZQ0KZml4ZWQuIGAtLXR5cGVgIGlzIGBpZXRmYCBhbmQgYC0tZXh0ZW5zaW9uc2AgaXMu Li4gd2VsbCwgbm90IGB4bWxyZmNgLiBJDQp3b3VsZCB0cnkgdG8gbWFrZSBhIFBSIHRvIHRoZSB3 ZWJzaXRlIGxhdGVyIGlmIHRoaXMgYWxsIHNvdW5kcyBnb29kLg0KDQpPbmUgbGFzdCB0aGluZyBJ IG5lZWQgdG8gZ2V0IHN0YXJ0ZWQgZm9yIHJlYWw6IHdoZXJlIGNhbiBJIGZpbmQgdGhlDQpzb3Vy Y2UgZm9yIFJGQyAzMzM5IChzaW5jZSBJIHdhcyBzdXBwb3NlZCB0byB1c2UgdGhhdCBhcyBhIHN0 YXJ0aW5nDQpwb2ludCk/IElzIHRoZXJlIGEgc291cmNlIGF0IGFsbD8gSWYgdGhhdCBzb3VyY2Ug aXMgbm90IGluIGFzY2lpZG9jDQpmb3JtYXQgKEknZCBpbWFnaW5lIG5vdCksIGlzIGNvcHlpbmcg bWFudWFsbHkgZnJvbSB0aGUgdGV4dCBmaWxlIHRoZQ0KYmVzdCBJIGNhbiBkbz8NCg0KQ2hlZXJz LA0KVWpqd2FsDQoNCk9uIDEwLzIwLzIwIDU6MDAgQU0sIFJvbmFsZCBUc2Ugd3JvdGU6DQpIaSBV amp3YWwsDQoNCldvdWxkIHlvdSBiZSBhYmxlIHRvIHBvaW50IG1lIHRvIHRoZSBkcmFmdCB0byBz ZWUgd2hhdCB0aGUgcHJvYmxlbSBpcz8NCg0KSGVyZeKAmXMgYSBzYW1wbGUgZG9jdW1lbnQgdGhh dCB3b3JrczoNCmh0dHBzOi8vcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbS9tZXRhbm9ybWEvbW4t c2FtcGxlcy1pZXRmL21hc3Rlci9zb3VyY2VzL2FudGlvY2gvZG9jdW1lbnQuYWRvYw0KDQooaHR0 cHM6Ly9naXRodWIuY29tL21ldGFub3JtYS9tbi1zYW1wbGVzLWlldGYgcHJvdmlkZXMgd29ya2lu ZyBleGFtcGxlcykNCg0KSWYgeW91IGhhdmUgdGhlc2UgdHdvIGxpbmVzIGluIHlvdXIgYWRvYyBm aWxlIGhlYWRlciAodW5kZXIgdGhlIHRpdGxlDQpidXQgYmVmb3JlIHRoZSBjb250ZW50LCB3aGlj aCBpcyBzZXBhcmF0ZWQgd2l0aCBhIGJsYW5rIGxpbmUpOg0KDQoiDQo6bW4tZG9jdW1lbnQtY2xh c3M6IGlldGYNCjptbi1vdXRwdXQtZXh0ZW5zaW9uczogcmZjLHhtbCx0eHQsaHRtbCxyeGwNCuKA nA0KDQpUaGVuIHlvdSBzaG91bGQgYmUgYWJsZSB0byBqdXN0IHJ1biB0aGlzOg0KbWV0YW5vcm1h IGRyYWZ0LXJ5em9rdWtlbi10aW1lc3RhbXAtaW5mb3JtYXRpb24uYWRvYw0KDQpSb24NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpSb25hbGQgVHNlDQpSaWJvc2Ug SW5jLg0KDQpPbiBPY3QgMjAsIDIwMjAsIGF0IDY6MDkgQU0sIFVqandhbCBTaGFybWEgPHJ5em9r dWtlbkBpZ2FsaWEuY29tDQo8bWFpbHRvOnJ5em9rdWtlbkBpZ2FsaWEuY29tPj4gd3JvdGU6DQoN CkhpIFJvbmFsZCENCg0KVGhhbmtzIGZvciB0aGUgc3VnZ2VzdGlvbi4gV3JpdGUgb25jZSwgcHVi bGlzaCBhbnl3aGVyZSAoYWx0aG91Z2gNCnBlcmhhcHMgd2l0aCBtaW5pbWFsIGNoYW5nZXMpIGlz IGluZGVlZCBhIHByaW9yaXR5LCBlc3BlY2lhbGx5IGdpdmVuIG91cg0KdGltZSBjb25zdHJhaW50 cy4gSSB0cmllZCBzZXR0aW5nIHVwIG1ldGFub3JtYSB0b2RheSwgYnV0IGZvciBzb21lDQpyZWFz b24sIGl0IGZhaWxzIGZvciBtZSBsb2NhbGx5Lg0KDQpNeSBpbnB1dDoNCg0KbWV0YW5vcm1hIC0t dHlwZSByZmMzIGRyYWZ0LXJ5em9rdWtlbi10aW1lc3RhbXAtaW5mb3JtYXRpb24uYWRvYw0KDQpF cnJvcjoNCg0KRXJyb3I6IGxvYWRpbmcgZ2VtIGBtZXRhbm9ybWEtcmZjM2AgZmFpbGVkLiBFeGl0 aW5nLg0KDQpUaGlzIHdvcmtzIHdpdGggb3Igd2l0aG91dCBgLXggeG1scmZjYC4gV2hhdCBzZWVt cyB0byBiZSB3cm9uZyBoZXJlPyBBbQ0KSSBtaXNzaW5nIGEgZ2VtPyBBIHNpbXBsZSB3ZWIgc2Vh cmNoIGRvZXNuJ3QgcmV0dXJuIGFueXRoaW5nIHVzZWZ1bCwgYW5kDQpubyBnZW0gbmFtZWQgYG1l dGFub3JtYS1yZmMzYCBjYW4gYmUgZm91bmQuDQoNCkkgdGhvdWdodCB0aGVyZSB3YXMgc29tZXRo aW5nIHdyb25nIHdpdGggbXkgc2V0dXAsIGJ1dCBJIHRyaWVkIG11bHRpcGxlDQp0aW1lcywgcmFu IGBtZXRhbm9ybWEgc2V0dXBgIHByb3Blcmx5LCB0cmllZCB0aGUgZG9ja2VyIHZlcnNpb24sIGJ1 dCBubw0KbHVjay4gVGhlIHNhbWUgZXJyb3IgZWFjaCB0aW1lLiBDb3VsZCB5b3UgaGVscCBtZSBm aWd1cmUgb3V0IHdoYXQgSQ0KbWlzc2VkPw0KDQpCZXN0LA0KVWpqd2FsDQoNCk9uIDEwLzE2LzIw IDk6NDUgQU0sIFJvbmFsZCBUc2Ugd3JvdGU6DQpIaSBVamp3YWwsDQoNCihUaGFua3MgQnJvbiBm b3IgdGhlIHBsdWchKQ0KDQpNZXRhbm9ybWEgaXMgb25lIG9mIHRoZSBvZmZpY2lhbGx5IGxpc3Rl ZCBwcm9jZXNzb3JzIGZvciBJRVRGIGRvY3VtZW50cw0KKGFsb25nc2lkZSBtbWFyayBhbmQga3Jh bWRvd24tcmZjMjYyOSkuDQoNCkNhbENvbm5lY3QgdXNlcyBNZXRhbm9ybWEgdG8gcHVibGlzaCBz dGFuZGFyZHMsIGFuZCBhIG51bWJlciBvZiBTRE9zIGRvDQpzbyBhcyB3ZWxsIChJVFUsIE9HQywg QklQTSwgd2hvIGFsc28gd29yayB3aXRoIGRhdGUvdGltZSkuDQoNCklmIHRoZXJlIGlzIGFueSBp bnRlbnRpb24gdG8gY3Jvc3MtcHVibGlzaCBpbnRvIENhbENvbm5lY3Qgb3IgSVNPLCB0aGUNCmFi aWxpdHkgdG8gIndyaXRlIG9uY2UsIHB1Ymxpc2ggYW55d2hlcmXigJ0gYmVjb21lcyBpbXBvcnRh bnQuDQoNCkdpdmVuIHRoYXQgd2XigJlyZSB0aGUgZm9sa3MgYmVoaW5kIGl0LCBJ4oCZbSBoYXBw eSB0byBzZXJ2ZSBhcyB5b3VyDQpwZXJzb25hbCBzdXBwb3J0IGlmIHlvdSBydW4gaW50byBhbnkg TWV0YW5vcm1hIHByb2JsZW1zIDotKQ0KDQpLaW5kIHJlZ2FyZHMsDQpSb24NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KUm9uYWxkIFRzZQ0KUmlib3NlIEluYy4NCg0K T24gT2N0IDE2LCAyMDIwLCBhdCA4OjI3IEFNLCBCcm9uIEdvbmR3YW5hIDxicm9uZ0BmYXN0bWFp bHRlYW0uY29tDQo8bWFpbHRvOmJyb25nQGZhc3RtYWlsdGVhbS5jb20+DQo8bWFpbHRvOmJyb25n QGZhc3RtYWlsdGVhbS5jb20+PiB3cm90ZToNCg0K77u/DQpIaSBVamp3YWwsDQoNClRoZXJlJ3Mg YSB2YXJpZXR5IG9mIG9wdGlvbnMgZm9yIHdyaXRpbmcgZHJhZnRzLiAgSSBwZXJzb25hbGx5IHVz ZSBhDQp3b3JrZmxvdyBiYXNlZCBvbiBtbWFyaywgZm9yIGV4YW1wbGU6DQoNCmh0dHBzOi8vZ2l0 aHViLmNvbS9icm9uZy9kcmFmdC1nb25kd2FuYS1lZmZlY3RpdmUtdGVybWlub2xvZ3kNCg0KVGhl cmUncyBhbHNvIG1ldGFub3JtYSwgd2hpY2ggYWxsb3dzIHlvdSB0byBjcmVhdGUgYSB2YXJpZXR5 IG9mDQpvdXRwdXRzLiAgVGhlcmUncyBkb2N1bWVudGF0aW9uIGhlcmU6DQoNCmh0dHBzOi8vd3d3 Lm1ldGFub3JtYS5jb20vYXV0aG9yL2lldGYvDQoNCk9yIHlvdSBjYW4gdXNlIHRvb2xzIGxpa2U6 DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9jYWJvL2tyYW1kb3duLXJmYzI2MjkNCg0KQmFzaWNhbGx5 LCB0aGV5J3JlIGFsbCB0b29sY2hhaW5zIHRoYXQgZ2VuZXJhdGUgUkZDIFhNTCBmb3JtYXQNCmRv Y3VtZW50cy4NCg0KSW4gb3JkZXIgdG8gcHVibGlzaCB0byB0aGUgSUVURiwgeW91IG5lZWQgYSBk YXRhdHJhY2tlciBhY2NvdW50LCBhbmQNCnlvdSdsbCBuZWVkIHRvIHVwbG9hZCB0aGVyZToNCg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9zdWJtaXQvdG9vbC1pbnN0cnVjdGlvbnMvDQoN CkNoZWVycywNCg0KQnJvbi4NCg0KT24gRnJpLCBPY3QgMTYsIDIwMjAsIGF0IDA5OjIxLCBVamp3 YWwgU2hhcm1hIHdyb3RlOg0KSGVsbG8gZXZlcnlvbmUhDQoNClRoYW5rcyBmb3IgdGhlIGFtYXpp bmcgZGlzY3Vzc2lvbnMgYW5kIGhlbHAgeWVzdGVyZGF5LiBHaXZlbiBvdXINCmNvbnN0cmFpbmVk IHRpbWVsaW5lLCBJIHN1cHBvc2UgSSBzaG91bGQgc3RhcnQgd29ya2luZyBvbiB0aGUgZHJhZnRz DQppbW1lZGlhdGVseS4NCg0KT24gdGhlIElFVEYgc2lkZSBvZiB0aGluZ3MsIEkgc3VwcG9zZSBJ J2QgbmVlZCB0byBzdGFydCBieSBjcmVhdGluZyBhbg0KSS1EPyBJcyB0aGVyZSBhIHNldCBvZiBy ZXNvdXJjZXMgeW91IGNvdWxkIHBvaW50IG1lIHRvIGluIG9yZGVyIHRvIGdldA0KdXAgYW5kIHJ1 bm5pbmcgcXVpY2tseT8NCg0KQWxzbywgd2hhdCBzaG91bGQgSSBkbyB0byBnZXQgdGhlIGJhbGwg cm9sbGluZyBvbiB0aGUgQ2FsQ29ubmVjdC9JU08NCnNpZGUgb2YgdGhpbmdzPw0KDQpCZXN0LA0K VWpqd2FsDQoNCi0tDQpVamp3YWwgIlJ5em9rdWtlbiIgU2hhcm1hIChoZS9oaW0pDQoNCkNvbXBp bGVycyBIYWNrZXIsIE5vZGUuanMgQ29yZSBDb2xsYWJvcmF0b3IgYW5kIFNwZWFrZXINCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY2Fsc2lmeSBt YWlsaW5nIGxpc3QNCmNhbHNpZnlAaWV0Zi5vcmcgPG1haWx0bzpjYWxzaWZ5QGlldGYub3JnPiA8 bWFpbHRvOmNhbHNpZnlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NhbHNpZnkNCg0KDQoqQXR0YWNobWVudHM6Kg0KDQogKiBzaWduYXR1cmUuYXNjDQoN Cg0KLS0NCiAgQnJvbiBHb25kd2FuYSwgQ0VPLCBGYXN0bWFpbCBQdHkgTHRkDQogIGJyb25nQGZh c3RtYWlsdGVhbS5jb20NCjxtYWlsdG86YnJvbmdAZmFzdG1haWx0ZWFtLmNvbT4gPG1haWx0bzpi cm9uZ0BmYXN0bWFpbHRlYW0uY29tPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpjYWxzaWZ5IG1haWxpbmcgbGlzdA0KY2Fsc2lmeUBpZXRmLm9y ZyA8bWFpbHRvOmNhbHNpZnlAaWV0Zi5vcmc+IDxtYWlsdG86Y2Fsc2lmeUBpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Fsc2lmeQ0KDQotLQ0KVWpqd2Fs ICJSeXpva3VrZW4iIFNoYXJtYSAoaGUvaGltKQ0KDQpDb21waWxlcnMgSGFja2VyLCBOb2RlLmpz IENvcmUgQ29sbGFib3JhdG9yIGFuZCBTcGVha2VyDQoNCg0KLS0NClVqandhbCAiUnl6b2t1a2Vu IiBTaGFybWEgKGhlL2hpbSkNCg0KQ29tcGlsZXJzIEhhY2tlciwgTm9kZS5qcyBDb3JlIENvbGxh Ym9yYXRvciBhbmQgU3BlYWtlcg0KDQoNCg== --_000_2D392BD80D78414FA1FF33F27E03E6B6ribosecom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIFVqandhbCwNCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNvIHNvcnJ5IGFib3V0IHRoZSBkb2Nz ISBBcHBhcmVudGx5IHRoZXkgaGF2ZW7igJl0IGJlZW4gdXBkYXRlZCB0byB0aGUgbmV3IHZlcnNp b24g4oCUIElFVEYgYSBmZXcgbW9udGhzIGFnbyBzd2l0Y2hlZCB0byBYTUwgUkZDIHYzIGFuZCB0 aGUgY29tbWFuZCBsaW5lIG9wdGlvbnMgZm9yIElFVEYgaGF2ZSBiZWVuIHVwZGF0ZWQuIFdlIGhh dmUgYSBibG9nIHBvc3QgYWJvdXQgdGhlIGNoYW5nZXMgYnV0IHdlIGRpZG7igJl0IGFjdHVhbGx5 DQogdXBkYXRlIHRoZSBkb2NzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QSBQUiB3b3VsZCBiZSBtdWNoIGFwcHJlY2lhdGVkITwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UmU6 IFJGQyAzMzM5LCB3aWxsIHNlbmQgeW91IHRoZSBhc2NpaWRvYyB2ZXJzaW9uIGluIDIwIG1pbnMu Li48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlJvbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3Jh cDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUm9uYWxkIFRzZTxi ciBjbGFzcz0iIj4NClJpYm9zZSBJbmMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+T24gT2N0IDIwLCAyMDIwLCBhdCA5OjI2IEFNLCBVamp3YWwgU2hhcm1hICZs dDs8YSBocmVmPSJtYWlsdG86cnl6b2t1a2VuQGlnYWxpYS5jb20iIGNsYXNzPSIiPnJ5em9rdWtl bkBpZ2FsaWEuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVy Y2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SGV5IFJvbmFs ZCE8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIG1hbmFnZWQgdG8gZ2V0IGl0IHJ1bm5p bmcuIFRoZSBkb2N1bWVudCBJIHdhcyB1c2luZyB3YXMgdGhlIHNhbWUgdGhhdDxiciBjbGFzcz0i Ij4NCnlvdSBsaW5rZWQgdG8sIGFuZCBpdCBzZWVtcyB0aGF0IHdoaWxlIHRoZSBmaWxlIHdvcmtz IHF1aXRlIHdlbGwgd2l0aDxiciBjbGFzcz0iIj4NCmp1c3QgYG1ldGFub3JtYWAsIHRoZSBjb21t YW5kIG9uIHRoZSBkb2NzIHdlYnNpdGUgKGBtZXRhbm9ybWEgLS10eXBlPGJyIGNsYXNzPSIiPg0K e3JmYzIgb3IgcmZjM30gLXggeG1scmZjIHtteS1kb2N1bWVudC1maWxlbmFtZS5hZG9jfWApIG5l ZWRzIHRvIGJlPGJyIGNsYXNzPSIiPg0KZml4ZWQuIGAtLXR5cGVgIGlzIGBpZXRmYCBhbmQgYC0t ZXh0ZW5zaW9uc2AgaXMuLi4gd2VsbCwgbm90IGB4bWxyZmNgLiBJPGJyIGNsYXNzPSIiPg0Kd291 bGQgdHJ5IHRvIG1ha2UgYSBQUiB0byB0aGUgd2Vic2l0ZSBsYXRlciBpZiB0aGlzIGFsbCBzb3Vu ZHMgZ29vZC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpPbmUgbGFzdCB0aGluZyBJIG5l ZWQgdG8gZ2V0IHN0YXJ0ZWQgZm9yIHJlYWw6IHdoZXJlIGNhbiBJIGZpbmQgdGhlPGJyIGNsYXNz PSIiPg0Kc291cmNlIGZvciBSRkMgMzMzOSAoc2luY2UgSSB3YXMgc3VwcG9zZWQgdG8gdXNlIHRo YXQgYXMgYSBzdGFydGluZzxiciBjbGFzcz0iIj4NCnBvaW50KT8gSXMgdGhlcmUgYSBzb3VyY2Ug YXQgYWxsPyBJZiB0aGF0IHNvdXJjZSBpcyBub3QgaW4gYXNjaWlkb2M8YnIgY2xhc3M9IiI+DQpm b3JtYXQgKEknZCBpbWFnaW5lIG5vdCksIGlzIGNvcHlpbmcgbWFudWFsbHkgZnJvbSB0aGUgdGV4 dCBmaWxlIHRoZTxiciBjbGFzcz0iIj4NCmJlc3QgSSBjYW4gZG8/PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KQ2hlZXJzLDxiciBjbGFzcz0iIj4NClVqandhbDxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCk9uIDEwLzIwLzIwIDU6MDAgQU0sIFJvbmFsZCBUc2Ugd3JvdGU6PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SGkgVWpqd2FsLDxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldvdWxkIHlvdSBiZSBhYmxlIHRvIHBvaW50IG1lIHRv IHRoZSBkcmFmdCB0byBzZWUgd2hhdCB0aGUgcHJvYmxlbSBpcz88YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpIZXJl4oCZcyBhIHNhbXBsZSBkb2N1bWVudCB0aGF0IHdvcmtzOjxiciBjbGFz cz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbS9tZXRhbm9y bWEvbW4tc2FtcGxlcy1pZXRmL21hc3Rlci9zb3VyY2VzL2FudGlvY2gvZG9jdW1lbnQuYWRvYyIg Y2xhc3M9IiI+aHR0cHM6Ly9yYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tL21ldGFub3JtYS9tbi1z YW1wbGVzLWlldGYvbWFzdGVyL3NvdXJjZXMvYW50aW9jaC9kb2N1bWVudC5hZG9jPC9hPjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCihodHRwczovL2dpdGh1Yi5jb20vbWV0YW5vcm1hL21u LXNhbXBsZXMtaWV0ZiBwcm92aWRlcyB3b3JraW5nIGV4YW1wbGVzKTxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCklmIHlvdSBoYXZlIHRoZXNlIHR3byBsaW5lcyBpbiB5b3VyIGFkb2MgZmls ZSBoZWFkZXIgKHVuZGVyIHRoZSB0aXRsZTxiciBjbGFzcz0iIj4NCmJ1dCBiZWZvcmUgdGhlIGNv bnRlbnQsIHdoaWNoIGlzIHNlcGFyYXRlZCB3aXRoIGEgYmxhbmsgbGluZSk6PGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KJnF1b3Q7PGJyIGNsYXNzPSIiPg0KOm1uLWRvY3VtZW50LWNsYXNz OiBpZXRmPGJyIGNsYXNzPSIiPg0KOm1uLW91dHB1dC1leHRlbnNpb25zOiByZmMseG1sLHR4dCxo dG1sLHJ4bDxiciBjbGFzcz0iIj4NCuKAnDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRo ZW4geW91IHNob3VsZCBiZSBhYmxlIHRvIGp1c3QgcnVuIHRoaXM6PGJyIGNsYXNzPSIiPg0KbWV0 YW5vcm1hIGRyYWZ0LXJ5em9rdWtlbi10aW1lc3RhbXAtaW5mb3JtYXRpb24uYWRvYzxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NClJvbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpSb25hbGQgVHNlPGJyIGNsYXNzPSIiPg0KUmlib3NlIEluYy48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiBPY3Qg MjAsIDIwMjAsIGF0IDY6MDkgQU0sIFVqandhbCBTaGFybWEgJmx0O3J5em9rdWtlbkBpZ2FsaWEu Y29tPGJyIGNsYXNzPSIiPg0KJmx0O21haWx0bzpyeXpva3VrZW5AaWdhbGlhLmNvbSZndDsmZ3Q7 IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkhpIFJvbmFsZCE8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MgZm9yIHRoZSBzdWdnZXN0aW9uLiBXcml0ZSBvbmNl LCBwdWJsaXNoIGFueXdoZXJlIChhbHRob3VnaDxiciBjbGFzcz0iIj4NCnBlcmhhcHMgd2l0aCBt aW5pbWFsIGNoYW5nZXMpIGlzIGluZGVlZCBhIHByaW9yaXR5LCBlc3BlY2lhbGx5IGdpdmVuIG91 cjxiciBjbGFzcz0iIj4NCnRpbWUgY29uc3RyYWludHMuIEkgdHJpZWQgc2V0dGluZyB1cCBtZXRh bm9ybWEgdG9kYXksIGJ1dCBmb3Igc29tZTxiciBjbGFzcz0iIj4NCnJlYXNvbiwgaXQgZmFpbHMg Zm9yIG1lIGxvY2FsbHkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTXkgaW5wdXQ6PGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KbWV0YW5vcm1hIC0tdHlwZSByZmMzIGRyYWZ0LXJ5 em9rdWtlbi10aW1lc3RhbXAtaW5mb3JtYXRpb24uYWRvYzxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCkVycm9yOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkVycm9yOiBsb2FkaW5n IGdlbSBgbWV0YW5vcm1hLXJmYzNgIGZhaWxlZC4gRXhpdGluZy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpUaGlzIHdvcmtzIHdpdGggb3Igd2l0aG91dCBgLXggeG1scmZjYC4gV2hhdCBz ZWVtcyB0byBiZSB3cm9uZyBoZXJlPyBBbTxiciBjbGFzcz0iIj4NCkkgbWlzc2luZyBhIGdlbT8g QSBzaW1wbGUgd2ViIHNlYXJjaCBkb2Vzbid0IHJldHVybiBhbnl0aGluZyB1c2VmdWwsIGFuZDxi ciBjbGFzcz0iIj4NCm5vIGdlbSBuYW1lZCBgbWV0YW5vcm1hLXJmYzNgIGNhbiBiZSBmb3VuZC48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIHRob3VnaHQgdGhlcmUgd2FzIHNvbWV0aGlu ZyB3cm9uZyB3aXRoIG15IHNldHVwLCBidXQgSSB0cmllZCBtdWx0aXBsZTxiciBjbGFzcz0iIj4N CnRpbWVzLCByYW4gYG1ldGFub3JtYSBzZXR1cGAgcHJvcGVybHksIHRyaWVkIHRoZSBkb2NrZXIg dmVyc2lvbiwgYnV0IG5vPGJyIGNsYXNzPSIiPg0KbHVjay4gVGhlIHNhbWUgZXJyb3IgZWFjaCB0 aW1lLiBDb3VsZCB5b3UgaGVscCBtZSBmaWd1cmUgb3V0IHdoYXQgSTxiciBjbGFzcz0iIj4NCm1p c3NlZD88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCZXN0LDxiciBjbGFzcz0iIj4NClVq andhbDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk9uIDEwLzE2LzIwIDk6NDUgQU0sIFJv bmFsZCBUc2Ugd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh c3M9IiI+SGkgVWpqd2FsLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCihUaGFua3MgQnJv biBmb3IgdGhlIHBsdWchKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCk1ldGFub3JtYSBp cyBvbmUgb2YgdGhlIG9mZmljaWFsbHkgbGlzdGVkIHByb2Nlc3NvcnMgZm9yIElFVEYgZG9jdW1l bnRzPGJyIGNsYXNzPSIiPg0KKGFsb25nc2lkZSBtbWFyayBhbmQga3JhbWRvd24tcmZjMjYyOSku PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2FsQ29ubmVjdCB1c2VzIE1ldGFub3JtYSB0 byBwdWJsaXNoIHN0YW5kYXJkcywgYW5kIGEgbnVtYmVyIG9mIFNET3MgZG88YnIgY2xhc3M9IiI+ DQpzbyBhcyB3ZWxsIChJVFUsIE9HQywgQklQTSwgd2hvIGFsc28gd29yayB3aXRoIGRhdGUvdGlt ZSkuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSWYgdGhlcmUgaXMgYW55IGludGVudGlv biB0byBjcm9zcy1wdWJsaXNoIGludG8gQ2FsQ29ubmVjdCBvciBJU08sIHRoZTxiciBjbGFzcz0i Ij4NCmFiaWxpdHkgdG8gJnF1b3Q7d3JpdGUgb25jZSwgcHVibGlzaCBhbnl3aGVyZeKAnSBiZWNv bWVzIGltcG9ydGFudC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpHaXZlbiB0aGF0IHdl 4oCZcmUgdGhlIGZvbGtzIGJlaGluZCBpdCwgSeKAmW0gaGFwcHkgdG8gc2VydmUgYXMgeW91cjxi ciBjbGFzcz0iIj4NCnBlcnNvbmFsIHN1cHBvcnQgaWYgeW91IHJ1biBpbnRvIGFueSBNZXRhbm9y bWEgcHJvYmxlbXMgOi0pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KS2luZCByZWdhcmRz LDxiciBjbGFzcz0iIj4NClJvbjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpSb25hbGQgVHNlPGJy IGNsYXNzPSIiPg0KUmlib3NlIEluYy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiBPY3QgMTYsIDIwMjAsIGF0IDg6MjcgQU0s IEJyb24gR29uZHdhbmEgJmx0O2Jyb25nQGZhc3RtYWlsdGVhbS5jb208YnIgY2xhc3M9IiI+DQom bHQ7bWFpbHRvOmJyb25nQGZhc3RtYWlsdGVhbS5jb20mZ3Q7PGJyIGNsYXNzPSIiPg0KJmx0O21h aWx0bzpicm9uZ0BmYXN0bWFpbHRlYW0uY29tJmd0OyZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0K77u/PGJyIGNsYXNzPSIiPg0KSGkgVWpqd2FsLDxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NClRoZXJlJ3MgYSB2YXJpZXR5IG9mIG9wdGlvbnMgZm9yIHdyaXRpbmcg ZHJhZnRzLiZuYnNwOyBJIHBlcnNvbmFsbHkgdXNlIGE8YnIgY2xhc3M9IiI+DQp3b3JrZmxvdyBi YXNlZCBvbiBtbWFyaywgZm9yIGV4YW1wbGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K aHR0cHM6Ly9naXRodWIuY29tL2Jyb25nL2RyYWZ0LWdvbmR3YW5hLWVmZmVjdGl2ZS10ZXJtaW5v bG9neTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZXJlJ3MgYWxzbyBtZXRhbm9ybWEs IHdoaWNoIGFsbG93cyB5b3UgdG8gY3JlYXRlIGEgdmFyaWV0eSBvZjxiciBjbGFzcz0iIj4NCm91 dHB1dHMuJm5ic3A7IFRoZXJlJ3MgZG9jdW1lbnRhdGlvbiBoZXJlOjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3Lm1ldGFub3JtYS5jb20vYXV0aG9yL2lldGYvPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT3IgeW91IGNhbiB1c2UgdG9vbHMgbGlrZTo8YnIgY2xh c3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpodHRwczovL2dpdGh1Yi5jb20vY2Fiby9rcmFtZG93bi1y ZmMyNjI5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQmFzaWNhbGx5LCB0aGV5J3JlIGFs bCB0b29sY2hhaW5zIHRoYXQgZ2VuZXJhdGUgUkZDIFhNTCBmb3JtYXQ8YnIgY2xhc3M9IiI+DQpk b2N1bWVudHMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW4gb3JkZXIgdG8gcHVibGlz aCB0byB0aGUgSUVURiwgeW91IG5lZWQgYSBkYXRhdHJhY2tlciBhY2NvdW50LCBhbmQ8YnIgY2xh c3M9IiI+DQp5b3UnbGwgbmVlZCB0byB1cGxvYWQgdGhlcmU6PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9zdWJtaXQvdG9vbC1pbnN0cnVj dGlvbnMvPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2hlZXJzLDxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCkJyb24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gRnJp LCBPY3QgMTYsIDIwMjAsIGF0IDA5OjIxLCBVamp3YWwgU2hhcm1hIHdyb3RlOjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPkhlbGxvIGV2ZXJ5b25lITxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoYW5rcyBmb3IgdGhlIGFtYXppbmcgZGlzY3Vzc2lv bnMgYW5kIGhlbHAgeWVzdGVyZGF5LiBHaXZlbiBvdXI8YnIgY2xhc3M9IiI+DQpjb25zdHJhaW5l ZCB0aW1lbGluZSwgSSBzdXBwb3NlIEkgc2hvdWxkIHN0YXJ0IHdvcmtpbmcgb24gdGhlIGRyYWZ0 czxiciBjbGFzcz0iIj4NCmltbWVkaWF0ZWx5LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N Ck9uIHRoZSBJRVRGIHNpZGUgb2YgdGhpbmdzLCBJIHN1cHBvc2UgSSdkIG5lZWQgdG8gc3RhcnQg YnkgY3JlYXRpbmcgYW48YnIgY2xhc3M9IiI+DQpJLUQ/IElzIHRoZXJlIGEgc2V0IG9mIHJlc291 cmNlcyB5b3UgY291bGQgcG9pbnQgbWUgdG8gaW4gb3JkZXIgdG8gZ2V0PGJyIGNsYXNzPSIiPg0K dXAgYW5kIHJ1bm5pbmcgcXVpY2tseT88YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpBbHNv LCB3aGF0IHNob3VsZCBJIGRvIHRvIGdldCB0aGUgYmFsbCByb2xsaW5nIG9uIHRoZSBDYWxDb25u ZWN0L0lTTzxiciBjbGFzcz0iIj4NCnNpZGUgb2YgdGhpbmdzPzxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkJlc3QsPGJyIGNsYXNzPSIiPg0KVWpqd2FsPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KLS0mbmJzcDs8YnIgY2xhc3M9IiI+DQpVamp3YWwgJnF1b3Q7Unl6b2t1a2VuJnF1 b3Q7IFNoYXJtYSAoaGUvaGltKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkNvbXBpbGVy cyBIYWNrZXIsIE5vZGUuanMgQ29yZSBDb2xsYWJvcmF0b3IgYW5kIFNwZWFrZXI8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCmNhbHNpZnkgbWFpbGluZyBs aXN0PGJyIGNsYXNzPSIiPg0KY2Fsc2lmeUBpZXRmLm9yZyAmbHQ7bWFpbHRvOmNhbHNpZnlAaWV0 Zi5vcmcmZ3Q7Jm5ic3A7Jmx0O21haWx0bzpjYWxzaWZ5QGlldGYub3JnJmd0OzxiciBjbGFzcz0i Ij4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Fsc2lmeTxiciBjbGFz cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCipBdHRhY2htZW50czoqPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7KiBzaWduYXR1cmUuYXNjPGJyIGNsYXNzPSIi Pg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KLS08YnIgY2xh c3M9IiI+DQombmJzcDsgQnJvbiBHb25kd2FuYSwgQ0VPLCBGYXN0bWFpbCBQdHkgTHRkPGJyIGNs YXNzPSIiPg0KJm5ic3A7Jm5ic3A7YnJvbmdAZmFzdG1haWx0ZWFtLmNvbTxiciBjbGFzcz0iIj4N CiZsdDttYWlsdG86YnJvbmdAZmFzdG1haWx0ZWFtLmNvbSZndDsmbmJzcDsmbHQ7bWFpbHRvOmJy b25nQGZhc3RtYWlsdGVhbS5jb20mZ3Q7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnIgY2xhc3M9IiI+DQpjYWxzaWZ5IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCmNhbHNp ZnlAaWV0Zi5vcmcgJmx0O21haWx0bzpjYWxzaWZ5QGlldGYub3JnJmd0OyZuYnNwOyZsdDttYWls dG86Y2Fsc2lmeUBpZXRmLm9yZyZndDs8YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NhbHNpZnk8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQotLSZuYnNwOzxiciBjbGFzcz0iIj4NClVqandh bCAmcXVvdDtSeXpva3VrZW4mcXVvdDsgU2hhcm1hIChoZS9oaW0pPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KQ29tcGlsZXJzIEhhY2tlciwgTm9kZS5qcyBDb3JlIENvbGxhYm9yYXRvciBh bmQgU3BlYWtlcjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCi0tIDxiciBjbGFzcz0iIj4NClVqandhbCAmcXVv dDtSeXpva3VrZW4mcXVvdDsgU2hhcm1hIChoZS9oaW0pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KQ29tcGlsZXJzIEhhY2tlciwgTm9kZS5qcyBDb3JlIENvbGxhYm9yYXRvciBhbmQgU3Bl YWtlcjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2D392BD80D78414FA1FF33F27E03E6B6ribosecom_-- From nobody Thu Oct 22 11:28:54 2020 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 49B133A0A6E for ; Thu, 22 Oct 2020 11:28:53 -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, 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 GrvkMazzDfJL for ; Thu, 22 Oct 2020 11:28:51 -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 A6F4D3A0A62 for ; Thu, 22 Oct 2020 11:28:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 41906F406F6; Thu, 22 Oct 2020 11:28:44 -0700 (PDT) To: bernard.desruisseaux@oracle.com, superuser@gmail.com, barryleiba@computer.org, lear@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: murch@fastmail.com, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20201022182844.41906F406F6@rfc-editor.org> Date: Thu, 22 Oct 2020 11:28:44 -0700 (PDT) Archived-At: Subject: [calsify] [Technical Errata Reported] RFC5545 (6316) 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, 22 Oct 2020 18:28:53 -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/eid6316 -------------------------------------- Type: Technical Reported by: Ken Murchison Section: 3.8.5.1 Original Text ------------- Value Type: The default value type for this property is DATE-TIME. The value type can be set to DATE. Corrected Text -------------- Value Type: The default value type for this property is DATE-TIME. The value type can be set to DATE. This property MUST have the same value type as the "DTSTART" property contained within the recurring component. Furthermore, this property MUST be specified as a date with local time if and only if the "DTSTART" property contained within the recurring component is specified as a date with local time. Notes ----- EXDATE excludes a specific instance of a recurring event and therefore should have the same value type as DTSTART. This is analogous to RECURRENCE-ID which overrides a specific instance and has the same value type as DTSTART. I will note however that there is iCalendar data in the wild with DTSTART;VALUE=DATE-TIME and EXDATE;VALUE=DATE. If this errata is rejected as incorrect, then a new errata should be opened with additional text describing how EXDATE;VALUE=DATE is supposed to be handled when DTSTART;VALUE=DATE-TIME. For instance, does EXDATE;VALUE=DATE exclude ALL instances of a FREQ=HOURLY recurrence on the given day? 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 Thu Oct 22 12:18:07 2020 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 A24FA3A0B50 for ; Thu, 22 Oct 2020 12:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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 0VQcUUqzOxUW for ; Thu, 22 Oct 2020 12:18:05 -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 AD9F63A0B4E for ; Thu, 22 Oct 2020 12:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8340; q=dns/txt; s=iport; t=1603394284; x=1604603884; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=jl+EUAnJY00XTjX9/FVh6ZXOlgpa6I0OQDjLnnhr5+A=; b=HjrARw6+hi7kAo9Gjcqpoa3rrN3cWtcESg4MN6iUmtT1DxUKSxUgZ1aH 6E0tCX/taeDnKF5e+Oo5ut1kuEUWf/4N1tl1d8w6it/KGjxLUHAej6TeN Rn5sLTS/tZ1axhumc1sA0UQ/CmzgtHSThdo5ee5r9e4tvdXXvSlszZXLf g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6BADt2ZFf/xbLJq1gHQEBAQEJARI?= =?us-ascii?q?BBQUBgg+Be4EfVQEyLIQ8iQWHbyaUC4gaCwEBAQ0BASMMBAEBhEoCggomOBM?= =?us-ascii?q?CAwEBCwEBBQEBAQIBBgRthWEMhXIBAQEBAgEjVgULCxgnAwICRhEZgltLAYJ?= =?us-ascii?q?cIA+yFnaBMoVXhGAGgTiNVIIAgREnDBCCTT6BBIZQM4IsBJAqAykJgjSKeIh?= =?us-ascii?q?hkRmCdIMWl2MDH4MXjy2PGpU5mlyDXgIEBgUCFYFrI4FXMxoIGxVlAYI+PhI?= =?us-ascii?q?ZDY43iG2FRD8DMDgCBgEJAQEDCY5IAQE?= X-IronPort-AV: E=Sophos; i="5.77,404,1596499200"; d="scan'208,217"; a="30504369" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Oct 2020 19:18:00 +0000 Received: from [10.61.241.147] ([10.61.241.147]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 09MJHxbr014729 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Oct 2020 19:18:00 GMT From: Eliot Lear Message-Id: <33BAE7DF-322C-41D1-8703-6ACB2834BA8D@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_937606BD-4008-46F1-BF27-EF73D9D47D70" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 22 Oct 2020 21:17:59 +0200 In-Reply-To: <20201022182844.41906F406F6@rfc-editor.org> Cc: bernard.desruisseaux@oracle.com, superuser@gmail.com, Barry Leiba , calsify@ietf.org To: murch@fastmail.com References: <20201022182844.41906F406F6@rfc-editor.org> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.241.147, [10.61.241.147] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6316) 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, 22 Oct 2020 19:18:07 -0000 --Apple-Mail=_937606BD-4008-46F1-BF27-EF73D9D47D70 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Ken, Thanks for your erratum. > On 22 Oct 2020, at 20:28, 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/eid6316 = >=20 > -------------------------------------- > Type: Technical > Reported by: Ken Murchison >=20 > Section: 3.8.5.1 >=20 > Original Text > ------------- > Value Type: The default value type for this property is DATE-TIME. > The value type can be set to DATE. >=20 >=20 > Corrected Text > -------------- > Value Type: The default value type for this property is DATE-TIME. > The value type can be set to DATE. This property MUST have the = same > value type as the "DTSTART" property contained within the > recurring component. Furthermore, this property MUST be = specified > as a date with local time if and only if the "DTSTART" property > contained within the recurring component is specified as a date > with local time. >=20 >=20 > Notes > ----- > EXDATE excludes a specific instance of a recurring event and therefore = should have the same value type as DTSTART. This is analogous to = RECURRENCE-ID which overrides a specific instance and has the same value = type as DTSTART. >=20 > I will note however that there is iCalendar data in the wild with = DTSTART;VALUE=3DDATE-TIME and EXDATE;VALUE=3DDATE. If this errata is = rejected as incorrect, then a new errata should be opened with = additional text describing how EXDATE;VALUE=3DDATE is supposed to be = handled when DTSTART;VALUE=3DDATE-TIME. For instance, does = EXDATE;VALUE=3DDATE exclude ALL instances of a FREQ=3DHOURLY recurrence = on the given day? First, let=E2=80=99s agree that the text is underspecified. There are = three potential situations: EXDATE matches DTSTART. No problem. Move along. EXDATE is a DATE-TIME and DTSTART is a DATE. I can=E2=80=99t imagine = anyone having coded this, but perhaps my imagination isn=E2=80=99t good. EXDATE is a DATE and DTSTART is a DATE-TIME. This is only a problem if = the RRULE has a FREQ < DAILY (MINUTELY, HOURLY, SECONDLY). Several questions: What happens with implementations today? Do we know? If everyone does = one thing, then we should probably note that in the errata, and perhaps = think of holding for update. Your interpretation seems to make sense, = but I don=E2=80=99t know what=E2=80=99s in the code. If there are different behaviors, then we have to decide which one is = correct. Does CalConnect have a view on this? Eliot= --Apple-Mail=_937606BD-4008-46F1-BF27-EF73D9D47D70 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = Ken,

Thanks = for your erratum.

On 22 = Oct 2020, at 20:28, RFC Errata System <rfc-editor@rfc-editor.org> 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/eid6316
--------------------------------------
Type: = Technical
Reported by: Ken Murchison <murch@fastmail.com>

Section: 3.8.5.1

Original = Text
-------------
   Value = Type:  The default value type for this property is DATE-TIME.
      The value type can be = set to DATE.


Corrected = Text
--------------
   Value = Type:  The default value type for this property is DATE-TIME.
      The value type can be = set to DATE.  This property MUST have the same
=       value type as the "DTSTART" property = contained within the
=       recurring component. =  Furthermore, this property MUST be specified
=       as a date with local time if and = only if the "DTSTART" property
=       contained within the recurring = component is specified as a date
=       with local time.


Notes
-----
EXDATE = excludes a specific instance of a recurring event and therefore should = have the same value type as DTSTART.  This is analogous to = RECURRENCE-ID which overrides a specific instance and has the same value = type as DTSTART.

I will note however that = there is iCalendar data in the wild with DTSTART;VALUE=3DDATE-TIME and = EXDATE;VALUE=3DDATE.  If this errata is rejected as incorrect, then = a new errata should be opened with additional text describing how = EXDATE;VALUE=3DDATE is supposed to be handled when = DTSTART;VALUE=3DDATE-TIME.  For instance, does EXDATE;VALUE=3DDATE = exclude ALL instances of a FREQ=3DHOURLY recurrence on the given day?


First, let=E2=80=99s agree that the text is underspecified. =  There are three potential situations:

  • EXDATE matches DTSTART.  No problem.  Move = along.
  • EXDATE is a DATE-TIME and DTSTART is a DATE. =  I can=E2=80=99t imagine anyone having coded this, but perhaps my = imagination isn=E2=80=99t good.
  • EXDATE is a DATE and = DTSTART is a DATE-TIME.  This is only a problem if the RRULE has a = FREQ < DAILY (MINUTELY, HOURLY, SECONDLY).
Several questions:

  • What happens with implementations = today?  Do we know?  If everyone does one thing, then we = should probably note that in the errata, and perhaps think of holding = for update.  Your interpretation seems to make sense, but I don=E2=80= =99t know what=E2=80=99s in the code.
  • If there are = different behaviors, then we have to decide which one is = correct.

Does CalConnect have a view on this?

Eliot
= --Apple-Mail=_937606BD-4008-46F1-BF27-EF73D9D47D70-- From nobody Thu Oct 22 12:40:34 2020 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 2ACEA3A0B80 for ; Thu, 22 Oct 2020 12:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=fastmail.com header.b=WA5n+kHH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=G/xIebs6 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 kwNsZEqQ1-lc for ; Thu, 22 Oct 2020 12:40:31 -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 422ED3A0B7E for ; Thu, 22 Oct 2020 12:40:31 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8465E5C017C; Thu, 22 Oct 2020 15:40:30 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Thu, 22 Oct 2020 15:40:30 -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=fm1; bh=aO+W24PbYf/JdXJ0aBVauPIvgP3 cNKI+k4bySbN44Fw=; b=WA5n+kHHmupTPSUnhfm2fEdv0gihEBHQrrE31QuNKPD vMWB7QE+yXikYRigkFFbbeO9+sbni+6uVr5TttvGrmPNJBdIztYGGrK4vAF6+x8f 3FIsQ1z4UFnd5Hil3tNtbN0jGQpYI6FuTBchhr/HCq14VxjaZbCgTn4B6U/UZRnt N4pJBgyjEdZfcaJ80t8TTBdwrATWcxR22HHlz3bStl+a28NGGtsQuhYj8whx4TqT 9QQVs1ibGfHyA90V27BMjAmbdVVUSuGh4cDgjIql7irITKbJWruTiFbdv/SKmn06 Cz3A5xe8vnqO5wCXY7eakZRWV93hDXL+45UQ0Zx4e4g== 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=fm1; bh=aO+W24 PbYf/JdXJ0aBVauPIvgP3cNKI+k4bySbN44Fw=; b=G/xIebs6NGqya7nbkcg6Me SSu2unv4yYmWAkKl8JT1tIU4vDcw+S0yuZyuFwAKcTswjktW/k3DzhuqfwJwIieH DbF7Cy1/wccXvpATAKao3RuZ0lXic/F/NqlAuJHW9gD7u4ppB98eOOqVdBznLAr5 s/K9Yxkt9ae6LK8c78c2bLTxgPmX7RSwjODe8fVkk2IYIWZIWNKglOFXOlFWbS6U tDCKLGvZqUy2GdjDIEImmSNAKaCj2lCfkFUfnIVWcyHtbsnf8BHPbC2EPdF1O4iM ryLpg9sW2KBtmuH+WtpO0BovKCje7BUsnlifyE61lE5skg4Ne3a2dXRAdnA4e5mw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrjeekgdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomhepmfgvnhcuofhu rhgthhhishhonhcuoehmuhhrtghhsehfrghsthhmrghilhdrtghomheqnecuggftrfgrth htvghrnhephfffgefhgfetvedttdffheethedukefgveetvddugfejfeegvefhfeehjefg vdfhnecuffhomhgrihhnpehrfhgtqdgvughithhorhdrohhrghdptggrlhgtohhnnhgvtg htrdhorhhgnecukfhppeejgedrjeejrdekhedrvdehtdenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmuhhrtghhsehfrghsthhmrghilhdrtg homh X-ME-Proxy: Received: from [192.168.1.22] (cpe-74-77-85-250.buffalo.res.rr.com [74.77.85.250]) by mail.messagingengine.com (Postfix) with ESMTPA id D7B0D328005A; Thu, 22 Oct 2020 15:40:29 -0400 (EDT) To: Eliot Lear Cc: bernard.desruisseaux@oracle.com, superuser@gmail.com, Barry Leiba , calsify@ietf.org References: <20201022182844.41906F406F6@rfc-editor.org> <33BAE7DF-322C-41D1-8703-6ACB2834BA8D@cisco.com> From: Ken Murchison Message-ID: Date: Thu, 22 Oct 2020 15:40:29 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <33BAE7DF-322C-41D1-8703-6ACB2834BA8D@cisco.com> Content-Type: multipart/alternative; boundary="------------579107E55D941E97E05CA4C0" Content-Language: en-US Archived-At: Subject: Re: [calsify] [Technical Errata Reported] RFC5545 (6316) 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, 22 Oct 2020 19:40:33 -0000 This is a multi-part message in MIME format. --------------579107E55D941E97E05CA4C0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Eliot, On 10/22/20 3:17 PM, Eliot Lear wrote: > Hi Ken, > > Thanks for your erratum. > >> On 22 Oct 2020, at 20:28, 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/eid6316 >> >> >> -------------------------------------- >> Type: Technical >> Reported by: Ken Murchison > > >> >> Section: 3.8.5.1 >> >> Original Text >> ------------- >>    Value Type:  The default value type for this property is DATE-TIME. >>       The value type can be set to DATE. >> >> >> Corrected Text >> -------------- >>    Value Type:  The default value type for this property is DATE-TIME. >>       The value type can be set to DATE.  This property MUST have the >> same >>       value type as the "DTSTART" property contained within the >>       recurring component.  Furthermore, this property MUST be specified >>       as a date with local time if and only if the "DTSTART" property >>       contained within the recurring component is specified as a date >>       with local time. >> >> >> Notes >> ----- >> EXDATE excludes a specific instance of a recurring event and >> therefore should have the same value type as DTSTART.  This is >> analogous to RECURRENCE-ID which overrides a specific instance and >> has the same value type as DTSTART. >> >> I will note however that there is iCalendar data in the wild with >> DTSTART;VALUE=DATE-TIME and EXDATE;VALUE=DATE.  If this errata is >> rejected as incorrect, then a new errata should be opened with >> additional text describing how EXDATE;VALUE=DATE is supposed to be >> handled when DTSTART;VALUE=DATE-TIME.  For instance, does >> EXDATE;VALUE=DATE exclude ALL instances of a FREQ=HOURLY recurrence >> on the given day? > > > First, let’s agree that the text is underspecified.  There are three > potential situations: > > * EXDATE matches DTSTART.  No problem.  Move along. > Agreed. > * EXDATE is a DATE-TIME and DTSTART is a DATE.  I can’t imagine > anyone having coded this, but perhaps my imagination isn’t good. > Agree, this would be weird. > * EXDATE is a DATE and DTSTART is a DATE-TIME.  This is only a > problem if the RRULE has a FREQ < DAILY (MINUTELY, HOURLY, SECONDLY). > No, its also an issue with other frequencies as well.  iCalendar data in the wild are using EXDATE as DATE to exclude DAILY and WEEKLY DATE-TIME occurrences, as we had a user trying to import such data.  I presume the same might be true for YEARLY and MONTHLY as well. > > Several questions: > > * What happens with implementations today?  Do we know?  If everyone > does one thing, then we should probably note that in the errata, > and perhaps think of holding for update.  Your interpretation > seems to make sense, but I don’t know what’s in the code. > I know for a fact that the code that I work on (libical and Cyrus) basically ignores the EXDATE if they don't match DTSTART (I haven't looked into which bit of software is responsible yet). > * If there are different behaviors, then we have to decide which one > is correct. > > > Does CalConnect have a view on this? I'll let folks reply themselves, but I posed this question to the caldeveloper list and two non-Fastmail CalConnect members stated that they also felt that EXDATE should match DTSTART. My guess is that there is enough of this going on that we need to see what the big boys are doing, conform and document accordingly. Either way, I'm curious what the intent of the original text was.  I wasn't involved with calendaring during the initial spec and the update. -- Kenneth Murchison Senior Software Developer Fastmail US LLC --------------579107E55D941E97E05CA4C0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Eliot,


On 10/22/20 3:17 PM, Eliot Lear wrote:
Hi Ken,

Thanks for your erratum.

On 22 Oct 2020, at 20:28, RFC Errata System <rfc-editor@rfc-editor.org> 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/eid6316

--------------------------------------
Type: Technical
Reported by: Ken Murchison <murch@fastmail.com>

Section: 3.8.5.1

Original Text
-------------
   Value Type:  The default value type for this property is DATE-TIME.
      The value type can be set to DATE.


Corrected Text
--------------
   Value Type:  The default value type for this property is DATE-TIME.
      The value type can be set to DATE.  This property MUST have the same
      value type as the "DTSTART" property contained within the
      recurring component.  Furthermore, this property MUST be specified
      as a date with local time if and only if the "DTSTART" property
      contained within the recurring component is specified as a date
      with local time.


Notes
-----
EXDATE excludes a specific instance of a recurring event and therefore should have the same value type as DTSTART.  This is analogous to RECURRENCE-ID which overrides a specific instance and has the same value type as DTSTART.

I will note however that there is iCalendar data in the wild with DTSTART;VALUE=DATE-TIME and EXDATE;VALUE=DATE.  If this errata is rejected as incorrect, then a new errata should be opened with additional text describing how EXDATE;VALUE=DATE is supposed to be handled when DTSTART;VALUE=DATE-TIME.  For instance, does EXDATE;VALUE=DATE exclude ALL instances of a FREQ=HOURLY recurrence on the given day?


First, let’s agree that the text is underspecified.  There are three potential situations:

  • EXDATE matches DTSTART.  No problem.  Move along.


Agreed.


  • EXDATE is a DATE-TIME and DTSTART is a DATE.  I can’t imagine anyone having coded this, but perhaps my imagination isn’t good.


Agree, this would be weird.


  • EXDATE is a DATE and DTSTART is a DATE-TIME.  This is only a problem if the RRULE has a FREQ < DAILY (MINUTELY, HOURLY, SECONDLY).


No, its also an issue with other frequencies as well.  iCalendar data in the wild are using EXDATE as DATE to exclude DAILY and WEEKLY DATE-TIME occurrences, as we had a user trying to import such data.  I presume the same might be true for YEARLY and MONTHLY as well.



Several questions:

  • What happens with implementations today?  Do we know?  If everyone does one thing, then we should probably note that in the errata, and perhaps think of holding for update.  Your interpretation seems to make sense, but I don’t know what’s in the code.


I know for a fact that the code that I work on (libical and Cyrus) basically ignores the EXDATE if they don't match DTSTART (I haven't looked into which bit of software is responsible yet).


  • If there are different behaviors, then we have to decide which one is correct.

Does CalConnect have a view on this?


I'll let folks reply themselves, but I posed this question to the caldeveloper list and two non-Fastmail CalConnect members stated that they also felt that EXDATE should match DTSTART.


My guess is that there is enough of this going on that we need to see what the big boys are doing, conform and document accordingly. 

Either way, I'm curious what the intent of the original text was.  I wasn't involved with calendaring during the initial spec and the update.

-- 

Kenneth Murchison
Senior Software Developer
Fastmail US LLC
--------------579107E55D941E97E05CA4C0-- From nobody Fri Oct 23 14:20:48 2020 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 6AB463A1417; Fri, 23 Oct 2020 14:16:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: calsify@ietf.org, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160348778142.5087.2143388934594368311@ietfa.amsl.com> Date: Fri, 23 Oct 2020 14:16:21 -0700 Archived-At: Subject: [calsify] calext - Requested session has been scheduled for IETF 109 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 21:16:26 -0000 Dear Daniel Migault, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. calext Session 1 (1:00 requested) Thursday, 19 November 2020, Session III 1600-1800 Room Name: Room 1 size: 501 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/109/sessions/calext.ics Request Information: --------------------------------------------------------- Working Group Name: Calendaring Extensions Area Name: Applications and Real-Time Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 15 Conflicts to Avoid: Chair Conflict: tls add drip saag ace dnsop homenet ipsecme dprive People who must be present: Barry Leiba Daniel Migault Bron Gondwana Resources Requested: Special Requests: ---------------------------------------------------------