From nobody Mon Mar 2 08:46:06 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 95F0A3A0A38 for ; Mon, 2 Mar 2020 08:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=twitch.tv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVd011A0lGra for ; Mon, 2 Mar 2020 08:46:01 -0800 (PST) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929933A096E for ; Mon, 2 Mar 2020 08:46:01 -0800 (PST) Received: by mail-wr1-x434.google.com with SMTP id z15so613935wrl.1 for ; Mon, 02 Mar 2020 08:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitch.tv; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DDxUz2tSl8Ak+eF4FMh6Pl23QbqnN5EQ+kHfHeRFZkY=; b=fxPFK2/b5+5J58dngEiV+mPG9aLHa76XlUZOWosd4hMu4V8uMHuArK5fRHC72XJN1l rIw27t+CsX89VowL11aMYAALSPnUKvqLuBJ1f1AMaZ5gN1WPFWiLOCe0z4mPYk6qzU/V AGpAbLjD6bzBlCSyhwyG6RIqcgOcUC+wyi0UY= 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=DDxUz2tSl8Ak+eF4FMh6Pl23QbqnN5EQ+kHfHeRFZkY=; b=sA0/IQMKqOBZ6SHRMOVE6lEXZzq0qKzjnLf6bcqkHHZu4C3Qr4NS0n/R3x7IzZ10pm Q9Qp5TaFFH1snZpJ2lqWnesKdUBP+5cf9RuwVDSaSHyCG1yms/Fo6+PfpocI3IBBsvBz l5Htjg4szQfFvtcAk00dSJbFtm2vsKVrLtS5zt2CGXAv8MpDrMFnKMNqYtKTaj3P3mDS o6E45YcbmqUEMfpgQFL5l2tRKvquZUdwH3ntVNSxBmePNafcmXFYE4Z42PGVt2XGILwk ZzfR42zKNXidvI5uGjisDV9byfSULJM1yqBj0kUTiZeGO5m9tOZa4TTldK8TF5wEWYml 4U1g== X-Gm-Message-State: ANhLgQ1ryexVptBrbATACcGBjlWSoQ1RPsBIyFBoIoxdwtRYskkC5beG sK27HxfsURvF33IHPdacbP2TlN1Yw3oHGdvV+yn1 X-Google-Smtp-Source: ADFU+vsMiaMlexqQwyX4t6TXABp1HT0annKnZznDxjc8tjPYoOeFfvokEbs3HQQtV2u3N63hPAO2Qh6eAiH1eYmu+yo= X-Received: by 2002:a5d:4bc8:: with SMTP id l8mr446042wrt.89.1583167559724; Mon, 02 Mar 2020 08:45:59 -0800 (PST) MIME-Version: 1.0 References: <3e70f4a7-2247-b6c4-fbd7-9e1bc4e1f91d@gmail.com> <6cc0d0c0-9389-9c1e-c263-87f7376fe864@fastmail.com> In-Reply-To: <6cc0d0c0-9389-9c1e-c263-87f7376fe864@fastmail.com> From: Ryan Gunter Date: Mon, 2 Mar 2020 09:45:23 -0700 Message-ID: To: Ken Murchison Cc: calsify@ietf.org Content-Type: multipart/alternative; boundary="000000000000048b0d059fe1ec41" Archived-At: Subject: Re: [calsify] Informational RFC Question - Maintenance Notifications 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, 02 Mar 2020 16:46:05 -0000 --000000000000048b0d059fe1ec41 Content-Type: text/plain; charset="UTF-8" Awesome, thanks so much guys! I'm sure I'll have more questions! Ryan Gunter | *Twitch* | Network Engineering | +1.415.568.7607 On Fri, Feb 28, 2020 at 1:51 PM Ken Murchison wrote: > Agreed. > > > On 2/28/20 3:23 PM, Michael Douglass wrote: > > I believe that to be the best approach. > On 2/28/20 14:43, Ryan Gunter wrote: > > Hello, > > I hope the group is doing well! > > A few months ago I submitted a draft to add x-maint properties to > icalendar attachments to indicate upcoming network maintenances. > > > https://datatracker.ietf.org/doc/html/draft-gunter-calext-maintenance-notifications > > During an IETF meeting (and through some emails as well), it was suggested > to define a schema to use the STRUCTURED-DATA property presented in the > current eventput-extensions draft. Then, an Informational RFC could be > written about this particular use case. Is this still the best approach? > If so, I am going to start working on getting something defined at > schema.org and creating the informational document. > > > > Ryan Gunter | *Twitch* | Network > Engineering | +1.415.568.7607 > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify > > > _______________________________________________ > calsify mailing listcalsify@ietf.orghttps://www.ietf.org/mailman/listinfo/calsify > > -- > Ken Murchison > Cyrus Development Team > Fastmail US LLC > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify > --000000000000048b0d059fe1ec41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Awesome, thanks so much guys!=C2=A0 I'm sure I= 9;ll have more questions!

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


On = Fri, Feb 28, 2020 at 1:51 PM Ken Murchison <murch@fastmail.com> wrote:
=20 =20 =20

Agreed.


On 2/28/20 3:23 PM, Michael Douglass wrote:
=20

I believe that to be the best approach.

On 2/28/20 14:43, Ryan Gunter wrote:
=20
Hello,

I hope the group is doing well!

A few months ago I submitted a draft to add x-maint properties to icalendar attachments to indicate upcoming network maintenances.


During an IETF meeting (and through some emails as well), it was suggested to define a schema to use the STRUCTURED-DATA property presented in the current eventput-extensions draft.=C2=A0 Then, an Informational RFC cou= ld be written about this particular use case.=C2=A0 Is this still the best approach?=C2=A0 If so, I am going to start working on getting something defined at schema.org and creating the informational document.



Ryan Gunter=C2=A0=C2=A0|=C2=A0= =C2=A0=C2=A0Twit= ch=C2=A0=C2=A0=C2=A0<= font style=3D"font-family:Helvetica;font-size:12px" color=3D"#cccccc">|=C2= =A0=C2=A0 Network Engineering=C2=A0 =C2=A0| =C2=A0=C2=A0+1.415.568.7607 

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


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

--=20
Ken Murchison
Cyrus Development Team
Fastmail US LLC
_______________________________________________
calsify mailing list
calsify@ietf.org<= br> https://www.ietf.org/mailman/listinfo/calsify
--000000000000048b0d059fe1ec41-- From nobody Tue Mar 3 13:10:16 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 4CFAC3A09F2; Tue, 3 Mar 2020 13:10:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-calext-jscalendar.all@ietf.org, calsify@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158326980124.7765.4116913884578487301@ietfa.amsl.com> Reply-To: Robert Sparks Date: Tue, 03 Mar 2020 13:10:01 -0800 Archived-At: Subject: [calsify] Genart last call review of draft-ietf-calext-jscalendar-25 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2020 21:10:08 -0000 Reviewer: Robert Sparks Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-calext-jscalendar-25 Reviewer: Robert Sparks Review Date: 2020-03-03 IETF LC End Date: 2020-03-09 IESG Telechat date: Not scheduled for a telechat Summary: This document has minor issues to address before being published as a Proposed Standard RFC. Caveats: I did not carefully verify that the initial registry values (of which there are many) matched the document text. Minor issues: ABNF is used, but there is no reference to RFC 5234. The document shepherd report implies that the ABNF has not been verified (see item 19 in that report). The first registry in section 8.4.3 should be explicit that it is a registry for values of the "@type" property. Right now the reader has to infer that. It's not stated clearly whether a patch should succeed or fail if the resulting object doesn't meet this specification's requirements. Side question: if a patch changes 'updated' (4.1.6) in an object that didn't already have a 'created' (4.1.5), should it fail if it doesn't also result in an object that has a 'created'? Or is it ok to lose the original creation time information? The security consideration section only points to section 7 of RFC 3986 for potential issues related to the URIs that can be carried in this representation. I don't think that's sufficient. There should be some discussion (or a pointer to discussions) about the potential for malicious construction of jscalendar objects containing potentially very large numbers of URIs in, say, as Link objects (4.2.7). Is there an opportunity for amplified attacks here? (Especially if these URLs might be automatically referenced by any client, and even more so if the object is sent from a calendar with a large number of subscribers.) Have you considered any tighter integrity checking for (4.2.7) links? Maybe a checksum property? It doesn't look like application/jscalendar+json has had a media type review. Nits: Introduction, second sentence: "It" is ambiguous. As written, it could point to "This document" or "a data model". You sort of mean the later, but I think you really mean the JSON representation (especially when you say "process"), but you don't talk about that here. Introduction, design considerations list, last bullet: This bullet is currently written as description of the end result, not as a design consideration. Please restate it to match the rest of the elements in the list. Last full paragraph on page 2: "unlike most common JSON data representations" is asserted without data. The document doesn't really need it. I suggest simply deleting the phrase from the sentence. I don't expect anything to change at this point, but I do have to point to the dissonance in the conventions A[] and A[B]. It would have been far less confusing for A have the same semantic in both cases (preferably value), than the current situation where it means value for A[], but key for A[B]. 1.4.3 last paragraph: You don't need to use MUST in this example - it's not a requirement on the protocol. I suggest replacing "MUST be" with "is correctly". In 4.2.5 at 'locationTypes', it would be better to point to the actual registry (https://www.iana.org/assignments/location-type-registry/location-type-registry.xhtml) than only to RFC4589. Do you want to say anything about what should happen if the size of a resource (as represented by 'size' in 4.2.7) doesn't match the actual fully decoded size? I think you mean for this property to be an informational estimate, and you should explicitly say the actual size could be quite different. In 4.2.10, 'american-football""' should be 'american-football"' (one fewer ") In 4.3.2 at 'byDay', why do you have * symbols around 'An *NDay* object'? In 4.4.5 at 'scheduleUpdated', do you really want to couple this so tightly to iTIP? Perhaps you should say "the last time this participant provided an update" and point to iTIP as how these are typically provided? Major issues: Minor issues: Nits/editorial comments: From nobody Tue Mar 3 14:31:14 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 217A43A0B81; Tue, 3 Mar 2020 14:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zBc-5BeY1y5; Tue, 3 Mar 2020 14:31:03 -0800 (PST) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795923A0B79; Tue, 3 Mar 2020 14:31:03 -0800 (PST) Received: by mail-il1-f177.google.com with SMTP id p8so73080iln.12; Tue, 03 Mar 2020 14:31:03 -0800 (PST) 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=QM6uMif/P1xyQujHNMyfk6lGomMoCtGq29/iuYv9BA0=; b=nnpI1T6TiDLDlpJ+peqBb1w7dnFyg/JYIuIQ0LCdr+cNNlv8VXKuAHQLPZW7ESoMs1 PXH/79gdL7SI3hOTTQQNEzrQZ0jkwbZ3r9zl6KB0SvHVjOVq/WuMLELE8AfLQZqY+yha sxWPQIkuX6husvrXsclSIkI3Hi1uZ9EQ1fTT6+sdwiqA9l3fja632VEmzIq+yM5pEDs8 Yh7AEXO+oMXrwG2dCipbDjmQlr/tIfNtQVEEM9w72U+kI97sglQkvHDZzCB0yifNPAy4 3X7E/mN3V2q50s+DCbzfkQr49TbLZCSd5YegTWD27iFV48oiHOUkrpu6xtVs9ucsmsT2 1dOw== X-Gm-Message-State: ANhLgQ2Q+G7e2CBngrUpqBE4Di0Igz+ncTN11jW84ZkRK1iD67cXhxYy biuvIM1CeqfOvMxFxwM5yozzJ0x6z/13zmxJySQKzlU3 X-Google-Smtp-Source: ADFU+vsp1QtE37zOpejZ0ifWKY/V4yB2iZ1K1gSfhfx54S8NTcvVJheSieSqi74+NL6rAMl3zOoxnP7DJ7gbR4FOdcI= X-Received: by 2002:a92:8f4b:: with SMTP id j72mr6693811ild.17.1583274662454; Tue, 03 Mar 2020 14:31:02 -0800 (PST) MIME-Version: 1.0 References: <158326980124.7765.4116913884578487301@ietfa.amsl.com> In-Reply-To: <158326980124.7765.4116913884578487301@ietfa.amsl.com> From: Barry Leiba Date: Tue, 3 Mar 2020 17:30:50 -0500 Message-ID: To: Robert Sparks Cc: General Area Review Team , draft-ietf-calext-jscalendar.all@ietf.org, calsify@ietf.org, last-call@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [calsify] Genart last call review of draft-ietf-calext-jscalendar-25 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, 03 Mar 2020 22:31:09 -0000 Robert, thanks for the careful (as always) review. Just on one point -- the authors can reply to the others: > It doesn't look like application/jscalendar+json has had a media type review. There aren't formal media-type reviews for types registered in IETF-consensus documents: see Section 3.1 of RFC 6838. That said, Section 5.1 of 6838 says this: Notice of a potential media type registration in the standards tree SHOULD be sent to the media-types@iana.org mailing list for review. This mailing list has been established for the purpose of reviewing proposed media and access types. I strongly encourage the authors to follow the advice in that section now: it's not too late. And I'm sorry that I didn't catch that myself; thanks for picking it up. Barry From nobody Wed Mar 4 13:37:26 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 008AB3A0986; Wed, 4 Mar 2020 13:37:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZKigeKszxhF; Wed, 4 Mar 2020 13:37:22 -0800 (PST) Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com [209.85.167.181]) (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 8A1253A0984; Wed, 4 Mar 2020 13:37:22 -0800 (PST) Received: by mail-oi1-f181.google.com with SMTP id q81so3741057oig.0; Wed, 04 Mar 2020 13:37:22 -0800 (PST) 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:content-transfer-encoding; bh=o/SjS0P5wooleOXiDO/mXgZDHwNHQQgAVKVwOyBcYkM=; b=WYx4csGWJSlf6WPbAyEYuDJEjzFDzD4MdtPzbyGrXaBzm5iwc0nbpDJgucDYZAjXz6 ewFGp22BLEo0t0S8fcTOpb+x4COeSOu6FNACmW/Fvvwe+eh6gnQS9W/wcx0gnYHkfrmw 32D1zgGOPV5UyI0KRGux2n7OJ1tvxHG3sqzH2Q1ZBa3t9acMKmfSwK6FrPDUWwzoBg91 AMQxkfmpvLvRB0f7FszVaz78Ir0Bup9wpW+tERNsmX9uzVrjie38LjOoFmS4x77tJ2D9 Yx3WKvASIvd2zz9oic8/ygA1+ZlaEKP3/YzPjQSQPi7oPfNK7Rm84uB7yW4hZdmXxbPA 7noA== X-Gm-Message-State: ANhLgQ2nLxh3C0oNnDP9Hwv/px/1A0onV4UbbaGvSt0ScuL11RzRto05 8CVmEHJKhKiWlGWgJMyxuLngh377Z7CntmY5SYR+Hw== X-Google-Smtp-Source: ADFU+vuE2Hq2xoyfpZR7FSMA6vVqyFEMWGJ1aE9umxu0zuUCwC1JZHoVqyQ7PksekH2LEGt/usCrq0YA2jiMrzG5drA= X-Received: by 2002:aca:2b0f:: with SMTP id i15mr3144355oik.29.1583357841670; Wed, 04 Mar 2020 13:37:21 -0800 (PST) MIME-Version: 1.0 References: <0accc1d2-3f8e-4b52-b454-f944f836eeea@beta.fastmail.com> <1fa00973-195a-489f-a4f9-d919ab80b7f5@beta.fastmail.com> In-Reply-To: From: Barry Leiba Date: Wed, 4 Mar 2020 16:37:10 -0500 Message-ID: To: Neil Jenkins Cc: draft-ietf-calext-jscalendar.all@ietf.org, Calsify Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 04 Mar 2020 21:37:24 -0000 Neil (and the working group), I need a response to this, so I can get back to Michelle. Is this acceptable to you? Barry On Tue, Feb 25, 2020 at 9:04 PM Barry Leiba wrote= : > > I chatted with Michelle Cotton (IANA), and she suggested that it would wo= rk better for them if we called the policy Expert Review instead of Specifi= cation Required, but still said that we expect a document, etc, as we now s= ay, and the Expert will judge the suitability of that. > > No need to make any change now, but please queue it up for when you next = make a change. It=E2=80=99s just a minimal thing at this point. > > Barry > > On Sun, Feb 23, 2020 at 9:29 PM Barry Leiba wro= te: >> >> All good... onward and forward. >> >> b >> >> On Sun, Feb 23, 2020 at 6:46 PM Neil Jenkins wr= ote: >>> >>> Hi Barry, >>> >>> OK, that makes sense. Maybe it's worth a minor wording change. Does >>> something like this work for you >>> >>> NEW >>> A value of 0 specifies an undefined priority, for which the treatment >>> will vary by situation. >>> END >>> >>> >>> Yes, I'm happy with that; I've added it in. >>> >>> Do you really anticipate extensions that are sufficiently simple, of th= at sort of nature, that a one-sentence explanation could be sufficient for = interoperable implementations? >>> >>> >>> I do, yes. Many properties are that simple. >>> >>> Maybe this will work?: >>> >>> NEW >>> That documentation will usually be in an RFC, but simple >>> definitions are likely to use a web/wiki page, and if a sentence >>> or two is deemed sufficient it could be described in the registry >>> itself. >>> END >>> >>> >>> That looks good to me, I've adopted that too. >>> >>> > =E2=80=94 Section 8.4.1 =E2=80=94 >>> > >>> > o Experts: The initial list of experts for Expert Review of updat= es >>> > to the subregistry. >>> > >>> > Hm, are you actually proposing that registrations provide their own >>> > lists of experts, rather than having them appointed by the IESG? I >>> > don=E2=80=99t think that=E2=80=99s going to work. We probably need t= o have a >>> > discussion about the intent here, so please initiate that by >>> > explaining to me what you=E2=80=99re looking for. >>> > >>> > >>> > Suppose a new enum-type property is registered that is not IETF contr= olled, >>> > then a new enum subregistry will be created and the designated expert= s need >>> > to be given for that subregistry, hence its inclusion in the template= . Does that >>> > make sense? >>> >>> Well, Expert Review (or Specification Required) uses experts >>> designated by (appointed by) the IESG. Here, it sounds like you're >>> talking about creating registries that use some other sort of peer >>> review, using experts not appointed by the IESG -- appointed by, it >>> seems, whoever creates the registry. I'm quite sure that IANA will be >>> unhappy with that, as they aren't set up to consult arbitrary experts >>> and to track their responses, without having the IESG to act as >>> managers and do problem resolution. What happens when the specified >>> experts disappear -- their email addresses no longer work, or the >>> experts are unresponsive? Who deals with that? We have a whole >>> process for how expert review works within the IETF, but we don't have >>> any process for dealing with outside experts. >>> >>> So, the *concept* makes sense, but, as the saying goes, the devil is >>> in the details. >>> >>> >>> OK, understood. I've now made it so the registry is just IETF designate= d experts (like the others); see the diff in v25. I hope this resolves the = issue. >>> >>> Cheers, >>> Neil. > > _______________________________________________ > calsify mailing list > calsify@ietf.org > https://www.ietf.org/mailman/listinfo/calsify From nobody Wed Mar 4 16:30:04 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 AB3D73A0CEE; Wed, 4 Mar 2020 16:30:00 -0800 (PST) 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, 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=dPKGFr4i; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lby4WMB8 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 wfgHiuU6V17A; Wed, 4 Mar 2020 16:29:59 -0800 (PST) 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 6958C3A0CEC; Wed, 4 Mar 2020 16:29:59 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 861CE21DFB; Wed, 4 Mar 2020 19:29:58 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Wed, 04 Mar 2020 19:29:58 -0500 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=fm2; bh=F1V9 zCWvi67gFaJ8DFj1lqMHx0B044ITr+BZKhTzGF0=; b=dPKGFr4idqUn8DW8y5wM hDK7hGPPiK3v8OTOTxu39TVAv/ouYeg4xGquVm6tGlP13H3iAp3fRYlziHPdgutc uEnLxPajEQOg67ZnXMdDQo2d9BSz0vqY0c9JJgju+KFkawETo6LTE4+Y4ywuGWN0 w8FVd31pxxWO5J21dYNvFGQxzRJccz8iekRMJBuUyGx1UFpHvhN3OT3HIcM7UGwh Txh5dQifK6xeRh0fJ8A4OM6R1zezQRkJw3KOiOD7fBTLrvVt4OvJtiY5CQsy4T/O +GzU4Kh9rycWddGeyr5O9WdpMQ3i1pNcgNC+vsvC6dbEP0AUe9HwWKpm8XlkDO7g 3Q== 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=fm2; bh=F1V9zC Wvi67gFaJ8DFj1lqMHx0B044ITr+BZKhTzGF0=; b=lby4WMB8B5rsocbk6ka5Km HZGE6FqMSaIyVdx/ohu629J6nliHHh9tp77WiMUOjO85i/zpDLVSyFM71ljD2Ad4 Btm1wX8wjrh8/suouK/j7HbxBA4n11e5klp5r/KjWS9l438qAbGjLPfc4gU3F//2 tAq01ZnTugteDxuE3ZBo9LYSWZEfXVwWJ8i74+TDp63Pe8+lHssv2ps9SIVN3JL7 kKJ0PBl+VftvZfhOcWNxydi7h1R+WDQ054UCCtByGgjnQHDQZLffnxqkACbBSKxH g20OAsIQq1nEuZIH5e0iY6ATM3pAK9YZgZ8Pd/2to6AwTmG4YGIWIwiDW8o2/+mA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddtledgvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghi lhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 36697180091; Wed, 4 Mar 2020 19:29:58 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-988-g326a76f-fmstable-20200305v1 Mime-Version: 1.0 Message-Id: <5aff6055-1771-4598-b72e-2b6652c70a55@beta.fastmail.com> In-Reply-To: References: <0accc1d2-3f8e-4b52-b454-f944f836eeea@beta.fastmail.com> <1fa00973-195a-489f-a4f9-d919ab80b7f5@beta.fastmail.com> Date: Thu, 05 Mar 2020 11:29:37 +1100 From: "Neil Jenkins" To: "Barry Leiba" Cc: draft-ietf-calext-jscalendar.all@ietf.org, Calsify Content-Type: multipart/alternative; boundary=81b12927832d4a738965e123061775af Archived-At: Subject: Re: [calsify] AD review of draft-ietf-calext-jscalendar-23 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, 05 Mar 2020 00:30:01 -0000 --81b12927832d4a738965e123061775af Content-Type: text/plain On Thu, 5 Mar 2020, at 08:37, Barry Leiba wrote: > Neil (and the working group), I need a response to this, so I can get > back to Michelle. Is this acceptable to you? Yes, this is fine. I have updated the source; it will be in the next published revision. Apologies for the late reply. Cheers, Neil. --81b12927832d4a738965e123061775af Content-Type: text/html
On Thu, 5 Mar 2020, at 08:37, Barry Leiba wrote:
Neil (and the working group), I need a response to this, so I can get
back to Michelle.  Is this acceptable to you?

Yes, this is fine. I have updated the source; it will be in the next published revision. Apologies for the late reply.

Cheers,
Neil.
--81b12927832d4a738965e123061775af-- From nobody Sat Mar 7 18:56:43 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 A198C3A044D; Sat, 7 Mar 2020 18:56:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: calsify@ietf.org Message-ID: <158363619759.25642.15164071767646081255@ietfa.amsl.com> Date: Sat, 07 Mar 2020 18:56:37 -0800 Archived-At: Subject: [calsify] I-D Action: draft-ietf-calext-jscalendar-26.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: Sun, 08 Mar 2020 02:56:38 -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-26.txt Pages : 77 Date : 2020-03-07 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-26 https://datatracker.ietf.org/doc/html/draft-ietf-calext-jscalendar-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-calext-jscalendar-26 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 Sat Mar 7 18: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 5A53B3A044F; Sat, 7 Mar 2020 18:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 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_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=C03jTkwn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hDPBYvhT 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 umVL4YCe9RE8; Sat, 7 Mar 2020 18:58:36 -0800 (PST) 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 3529C3A044E; Sat, 7 Mar 2020 18:58:36 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1F6C9220B5; Sat, 7 Mar 2020 21:58:34 -0500 (EST) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Sat, 07 Mar 2020 21:58:34 -0500 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=fm2; bh=Y0HC zp5UnCXrqFtWOgmp3UMeYco1Tbm75W5K/H4+Ilc=; b=C03jTkwn8ozQ4dueKweA U2HznBMU8CFOpjRp+UYwTUKmwaDhhDp2xAAbVrhjmhOi6YDwAZKfxaI48VP1W76x P3e5C8CuP9n8gGjVYcKj3XQjwLXEiPkRZNOT7YnmEXBF/FEhk+LkcSZsRq+1SsSV C7Y1udVwS/vSfh+ekr1UXslbKhVEZI6OGzi9a2hohpILpw+Q3fMs/vvM939mKw7K T0QylU0UQ5lXKVdGVpgmfO5RcMD6KoWfGXZ6Dq6u0/rvc7fE+ZkIPZxstG9FiWjv EShlxiIV+j1DWe1NIa7z7h4A4v4xUWWytWdAp1OcMmlWLQFQYMvwO680furvCIwG zA== 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=fm2; bh=Y0HCzp 5UnCXrqFtWOgmp3UMeYco1Tbm75W5K/H4+Ilc=; b=hDPBYvhTpSTIHltJR+s1bj Z8WdA6I/UVBuYdermPZnqwBQ1bWw6OHqDwRMqhVj8tUuByqobnDcYpuIsRzGNEIu 5RFFb35MS4L3gFJMKrdm1keEeTV+CjBVVICtOfcct3zg4/1UmLcclYo/Siu/wPoF EAVqfyhMYylrJ9qDLzIJaYPFkptBjtoX3qTpjHS980lqB0J6pqlFKnGtFt00u6xK S4WOI5cwjvyQ344fWjixZ20q9t3uGfv1M2gTXjp/yn8sZlGa27iMGDZYVNVRn6JW RS50cyOsmETuXfCHynePNdeq5DXXeisescGl79lPDL08a5xd2mVvuHfjviG4P3XQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudduhedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtoh hm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8F139180091; Sat, 7 Mar 2020 21:58:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: <2cfb69c3-2828-4b10-9419-87eed026169f@beta.fastmail.com> In-Reply-To: <158326980124.7765.4116913884578487301@ietfa.amsl.com> References: <158326980124.7765.4116913884578487301@ietfa.amsl.com> Date: Sun, 08 Mar 2020 13:58:13 +1100 From: "Neil Jenkins" To: "Robert Sparks" , gen-art@ietf.org Cc: draft-ietf-calext-jscalendar.all@ietf.org, calsify@ietf.org, last-call@ietf.org Content-Type: multipart/alternative; boundary=80900e8cf2c844b0beae3a54b057ca38 Archived-At: Subject: Re: [calsify] Genart last call review of draft-ietf-calext-jscalendar-25 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, 08 Mar 2020 02:58:39 -0000 --80900e8cf2c844b0beae3a54b057ca38 Content-Type: text/plain Thanks for the review Robert. > ABNF is used, but there is no reference to RFC 5234. I have added a normative reference to this RFC. > The first registry in section 8.4.3 should be explicit that it is a registry for values of the "@type" property. That's not quite correct; the registry is for the names of types. Not all types have an "@type" property (for example, primitive types like `UnsignedInt`). The "@type" property is primarily to help where the context allows multiple types (e.g. the "entries" property in a JSGroup object is a list of JSEvent and/or JSTask objects, so you need the @type property on these to know which one you are getting). > It's not stated clearly whether a patch should succeed or fail if the resulting > object doesn't meet this specification's requirements. Good spot. I have added a requirement for the PatchObject to be valid that: The value for the patch MUST be valid for the property being set (of the correct type and obeying any other applicable restrictions), or if null the property MUST be optional. (Thus if this is not true the whole PatchObject should be ignored, as per any other patch failure.) > Side question: if a patch changes 'updated' (4.1.6) in an object that didn't already have a 'created' (4.1.5), should it fail if it doesn't also result in an object that has a 'created'? Or is it ok to lose the original creation time information? No, this doesn't fail. The "created" property is optional, so you can have an object that doesn't record its creation date. > The security consideration section only points to section 7 of RFC 3986 for > potential issues related to the URIs that can be carried in this > representation. I don't think that's sufficient. There should be some > discussion (or a pointer to discussions) about the potential for malicious > construction of jscalendar objects containing potentially very large numbers of > URIs in, say, as Link objects (4.2.7). Is there an opportunity for amplified > attacks here? (Especially if these URLs might be automatically referenced by > any client, and even more so if the object is sent from a calendar with a large > number of subscribers.) I have added: *A maliciously constructed JSCalendar object may contain a very large number of URIs. In the case of published calendars with a large number of subscribers, such objects could be widely distributed. Implementations should be careful to limit the automatic fetching of linked resources to reduce the risk of this being an amplification vector for a denial-of-service attack.* > Have you considered any tighter integrity checking for (4.2.7) links? Maybe a > checksum property? No. The integrity of data is left to the transmission protocol and not part of the data format being described in this document. I don't see any good reason why this property should be subject to extra integrity checks beyond the whole object. > It doesn't look like application/jscalendar+json has had a media type review. Thanks, I have now sent this for review. > Nits: I have addressed these, thanks for noting them. One comment: > I don't expect anything to change at this point, but I do have to point to the > dissonance in the conventions A[] and A[B]. It would have been far less > confusing for A have the same semantic in both cases (preferably value), than > the current situation where it means value for A[], but key for A[B]. I see your point, but we have already used the same syntax in JMAP (RFC8620/8621) and I think it is better to stay consistent. I have published v26 with all of the above updates. Cheers, Neil. --80900e8cf2c844b0beae3a54b057ca38 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
Thanks for= the review Robert.

ABNF is used, but there is no reference to RFC 5234.

I have added a normative reference t= o this RFC.

The first registry in section 8.4.3 should be explicit that it is = a registry for values of the "@type" property.

That's not quite correct; the registry is for the names= of types. Not all types have an "@type" property (for example, primitiv= e types like UnsignedInt). The "@type" property is primarily to = help where the context allows multiple types (e.g. the "entries" propert= y in a JSGroup object is a list of JSEvent and/or JSTask objects, so you= need the @type property on these to know which one you are getting).

It's not = stated clearly whether a patch should succeed or fail if the resulting
object doesn't meet this specification's requirements.
=

Good spot. I have added a require= ment for the PatchObject to be valid that:

= The value for the patch MUST be valid for the property being set (of the= correct type and obeying any other applicable restrictions), or if null= the property MUST be optional.

(Thus if th= is is not true the whole PatchObject should be ignored, as per any other= patch failure.)

Side question: if a patch changes 'updated' (4.1.6) in an obje= ct that didn't already have a 'created' (4.1.5), should it fail if it do= esn't also result in an object that has a 'created'? Or is it ok to lose= the original creation time information?

=
No, this doesn't fail. The "created" property is optional, so= you can have an object that doesn't record its creation date.
=

The security con= sideration section only points to section 7 of RFC 3986 for
potential issues related to the URIs that can be carried in this
representation. I don't think that's sufficient. There should b= e some
discussion (or a pointer to discussions) about the = potential for malicious
construction of jscalendar objects= containing potentially very large numbers of
URIs in, say= , as Link objects (4.2.7). Is there an opportunity for amplified
attacks here? (Especially if these URLs might be automatically re= ferenced by
any client, and even more so if the object is = sent from a calendar with a large
number of subscribers.)<= br>

I have added:
A maliciously constructed JSCalendar object may contain = a very large number of URIs. In the case of published calendars with a l= arge number of subscribers, such objects could be widely distributed. Im= plementations should be careful to limit the automatic fetching of linke= d resources to reduce the risk of this being an amplification vector for= a denial-of-service attack.

Have you considered any tighter integrity chec= king for (4.2.7) links? Maybe a
checksum property?

No. The integrity of data is left to = the transmission protocol and not part of the data format being describe= d in this document. I don't see any good reason why this property s= hould be subject to extra integrity checks beyond the whole object.
<= /div>

It doesn't = look like application/jscalendar+json has had a media type review.

Thanks, I have now sent this for re= view.

N= its:

I have addressed these, t= hanks for noting them. One comment:

I don't expect anything to change at this p= oint, but I do have to point to the
dissonance in the conv= entions A[] and A[B]. It would have been far less
confusin= g for A have the same semantic in both cases (preferably value), than
the current situation where it means value for A[], but key = for A[B].

I see your point, bu= t we have already used the same syntax in JMAP (RFC8620/8621) and I thin= k it is better to stay consistent.

I have <= a href=3D"https://tools.ietf.org/html/draft-ietf-calext-jscalendar-26">p= ublished v26 with all of the above updates.

=
Cheers,
Neil.
--80900e8cf2c844b0beae3a54b057ca38-- From nobody Tue Mar 10 07:28:42 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 43D7F3A13D3; Tue, 10 Mar 2020 07:28:40 -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: last-call@ietf.org, calsify@ietf.org, draft-ietf-calext-jscalendar.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.120.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158385051998.15836.4770030164750320016@ietfa.amsl.com> Reply-To: Phillip Hallam-Baker Date: Tue, 10 Mar 2020 07:28:40 -0700 Archived-At: Subject: [calsify] Secdir last call review of draft-ietf-calext-jscalendar-26 X-BeenThere: calsify@ietf.org X-Mailman-Version: 2.1.29 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 14:28:41 -0000 Reviewer: Phillip Hallam-Baker Review result: Has Issues The Security Considerations need to be substantially expanded to address: 1) Spam 2) Duplication 3) Time Zones 4) Authentication The first issue is a major problem with ical attachments, applications assume that these are authentic and create entries. It is stupid but it is ubiquitous. There should be note of this as it is a very common channel exploited by spamers. Duplication is a related problem. Calendar entries should have a unique persistent ID and clients should check these so that updates on multiple devices don't end up resulting in a dozen calendar entries which happens to me repeatedly. Time Zones are a related problem it is important to make sure that the time zone of recurring entries is correctly set. Why is this a security issue? Because I have been in a situation where a meeting secretary deliberately sent out a maliciously crafted meeting announcement to make sure the 'wrong people' didn't attend. Authentication is my main concern though as my entire home automation system runs off a a task database that is based on a JSON calendar format which is not this format _yet_. My plan being to let you folk do the work and then wrap authentication round it. So when I am done, the calendar will drive the selection of what happens in the house. The school calendars will be loaded and these will cause the alarms for myself and the kids to come on when it is a school day and not otherwise. Same for heating etc. If one of us is traveling, there will be adjustments etc. This is obviously a stretch goal but it is clearly something that will be commonplace at some point. Calendaring systems are going to be about more than just work appointments. And that means we need authentication. The draft does not need to say HOW this is done but it does need to say you need to do it. A related concern is that many companies set up accounts for each meeting room and you reserve the room for your meeting by 'inviting' it to the meeting. Now consider doing the same in a serviced office scenario, you want the convenience but there is also going to be a payments interface because you pay for the meeting room by the hour. In the general body of the text, the treatment of recurring events MUST address time zones and daylight savings. This is the stuff iCal didn't get right at first and that lead to pain. From nobody Mon Mar 16 03:07:59 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 57F9A3A2226; Mon, 16 Mar 2020 03:07:58 -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, 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=Tfs4cJIT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3ehIi5QN 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 EHZYJZ9kmh4q; Mon, 16 Mar 2020 03:07:56 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB563A2210; Mon, 16 Mar 2020 03:07:56 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DAD6E79E; Mon, 16 Mar 2020 06:07:54 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute4.internal (MEProxy); Mon, 16 Mar 2020 06:07:55 -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=fm2; bh=j4n8 GfMgWen2loVFeNGeqfmOdHo3ESxYXNCJHmxYw1o=; b=Tfs4cJIT48tBXNU83JKV 37prICyyDrKl+a9TTYJ+1vzEMtvyooOzIkknt4PXPn8CQ5FVIxZnLk/K9mN9t1hn 2FMID7Jr1wjaYPMpYZ+j4trOXECozuD7Ja0w095ytNGLsEudC3ozPQtMjQguGsGW MvOC+eqlneBi2pVBPbbGRU1gvv4Z+H4Rl6omgK/lRWphgZdX4QXXxCt2J1Lr6kP/ UFDgwvu96YHHs7M1TgUuMWov6zEXbAUYuzA2LnDh+ZmkJCmAruHNIOGoe3DDNR9H sj6AQXLKk4+4kYAkZO/Ixu571FWST3Zp0u5QvOvuAJRWl0usx30b1+8Z7S2gyl0D RQ== 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=fm2; bh=j4n8Gf MgWen2loVFeNGeqfmOdHo3ESxYXNCJHmxYw1o=; b=3ehIi5QNIS6xWQ8zGZrlMR iiLWm+0uteafk6SHIrxRxIlgfJUN70R+tkQ07rRrArX5dOd4rqi9pZNqyN8mv2ce EbjR8GSMf3q+df9+EntvuOHcnehfZbsA6+pKmKo/GuRhJdIJN70/Xch7Y39CiDk8 p674YCKMNZevDbMCnYK3077g/3shXw7cFXuTPFOsEj97cDhov70Tb1xBQhroXr1b 5zljPYUtSpuXNQ/ql3/W0gQRXHq3sQDcYQhgknPwugq747dEc9fh1VSDkdiguCA/ CSge6S4aa7AvXMd2bLMs0pzxdFcpucVakSs1CRRmIdqLkVopx0i2RNcIrpIp9lGQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudeffedguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehnvghi lhhjsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 18394180090; Mon, 16 Mar 2020 06:07:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-991-g5a577d3-fmstable-20200305v3 Mime-Version: 1.0 Message-Id: <857a3426-bda6-47cb-9b73-b9db8e596a2d@beta.fastmail.com> In-Reply-To: <158385051998.15836.4770030164750320016@ietfa.amsl.com> References: <158385051998.15836.4770030164750320016@ietfa.amsl.com> Date: Mon, 16 Mar 2020 21:07:32 +1100 From: "Neil Jenkins" To: "Phillip Hallam-Baker" , secdir@ietf.org Cc: last-call@ietf.org, draft-ietf-calext-jscalendar.all@ietf.org, calsify@ietf.org Content-Type: multipart/alternative; boundary=c9116e7e33f04a42b5c5d8c86be3520b Archived-At: Subject: Re: [calsify] =?utf-8?q?Secdir_last_call_review_of_draft-ietf-calext?= =?utf-8?q?-jscalendar-26?= 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, 16 Mar 2020 10:07:59 -0000 --c9116e7e33f04a42b5c5d8c86be3520b Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Phillip, Thank you for the review and apologies for the late reply; I have been o= n leave. > 1) Spam > 2) Duplication > 3) Time Zones > 4) Authentication I have expanded the introduction to the security considerations to menti= on (4) and added sections for (1)-(3); I include the additions and alter= ations below. Please let me know if you believe this is insufficient: *7. Security Considerations* Calendaring and scheduling information is very privacy-sensitive. Its transmission must be done carefully to protect it from possible threats, such as eavesdropping, replay, message insertion, deletion, modification, and man-in-the-middle attacks. The data being stored and transmitted may be used in systems with real world consequences. For example, a home automation system may turn an alarm on and off. Or a coworking space may charge money to the organiser of an event that books one of their meeting rooms. Such systems must be careful to authenticate all data they receive to prevent them from being subverted. This document just defines the data format; such considerations are primarily the concern of the API or method of storage and transmission of such files. =E2=80=A6 7.1-7.3 as before =E2=80=A6 *7.4. Spam* Calendar systems may receive JSCalendar files from untrusted sources, in particular as attachments to emails. This can be a vector for an attacker to inject spam into a user's calendar. This may confuse, annoy, and mislead users, or overwhelm their calendar with bogus events, preventing them from seeing legitimate ones. Heuristic, statistical or machine-learning-based filters can be effective in filtering out spam. Authentication mechanisms such as DKIM [RFC6376] can help establish the source of messages and associate the data with existing relationships (such as an address book contact). Misclassifications are always possible however, and providing a feedback mechanism for users to quickly correct this is advised. *7.5. Duplication* It is important for calendar systems to maintain the UID of an event 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 confusing situation for the user, with many variations of the event and no indication of which one is correct. Care must be taken by consumers of the data to remove old events where possible to avoid an accidental denial-of-service attack due to the volume of data. *7.6. Time Zones* Events recur in a particular time zone. When this differs from the user's current time zone, it may unexpectedly cause an occurrence to shift in time for that user due to a daylight savings change in the event's time zone. A maliciously crafted event could attempt to confuse users with such an event to ensure a meeting is missed. > In the general body of the text, the treatment of recurring events MUS= T address > time zones and daylight savings. This is the stuff iCal didn't get rig= ht at > first and that lead to pain. Can you clarify a bit what change you are looking for here, if any? Do y= ou believe the current text in JSCalendar is ambiguous? A recurrence app= lies to the "start" property of the event, which is a local date-time. A= ll other properties (including "timeZone") are inherited unless overridd= en for a specific instance. So an event will essentially recur in its ti= me zone; if you need to translate this into UTC you'll of course need ti= me zone information and to account for daylight savings etc. Cheers, Neil. --c9116e7e33f04a42b5c5d8c86be3520b Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Phillip,
=

Thank you for the review and apologies for the= late reply; I have been on leave.

1) Spam
2) Duplication
3) Time Zones
4) Authentication

I have expanded the introduction to the security = considerations to mention (4) and added sections for (1)-(3); I include = the additions and alterations below. Please let me know if you believe t= his is insufficient:

7.  Security C= onsiderations

   Calendaring = and scheduling information is very privacy-sensitive.
&nbs= p;  Its transmission must be done carefully to protect it from poss= ible
   threats, such as eavesdropping, replay, = message insertion, deletion,
   modification, an= d man-in-the-middle attacks.

   T= he data being stored and transmitted may be used in systems with
   real world consequences.  For example, a home a= utomation system may
   turn an alarm on and off= .  Or a coworking space may charge money to
 &nb= sp; the organiser of an event that books one of their meeting rooms.
=
   Such systems must be careful to authenticate all= data they receive to
   prevent them from being= subverted.

   This document just= defines the data format; such considerations are
 &n= bsp; primarily the concern of the API or method of storage and
=
   transmission of such files.

=E2=80=A6 7.1-7.3 as before =E2=80=A6

7.4.  Spam

   Calendar = systems may receive JSCalendar files from untrusted sources,
   in particular as attachments to emails.  This can b= e a vector for an
   attacker to inject spam int= o a user's calendar.  This may confuse,
   = annoy, and mislead users, or overwhelm their calendar with bogus
   events, preventing them from seeing legitimate ones.=

   Heuristic, statistical or mac= hine-learning-based filters can be
   effective = in filtering out spam.  Authentication mechanisms such as
=
   DKIM [RFC6376] can help establish the source of messag= es and
   associate the data with existing relat= ionships (such as an address
   book contact).&n= bsp; Misclassifications are always possible however, and
&= nbsp;  providing a feedback mechanism for users to quickly correct = this is
   advised.

7.5.  Duplication

  = It is important for calendar systems to maintain the UID of an event
   when updating it to avoid unexpected duplicatio= n of events.  When the
   UID changes, cons= umers of the data may not remove the previous
  = version of the event if it has a different UID.  This can lead to = a
   confusing situation for the user, with many= variations of the event
   and no indication of= which one is correct.  Care must be taken by
 &= nbsp; consumers of the data to remove old events where possible to avoid= an
   accidental denial-of-service attack due t= o the volume of data.

7.6.  Time Zo= nes

   Events recur in a part= icular time zone.  When this differs from the
 &= nbsp; user's current time zone, it may unexpectedly cause an occurrence = to
   shift in time for that user due to a dayli= ght savings change in the
   event's time zone.&= nbsp; A maliciously crafted event could attempt to
 &= nbsp; confuse users with such an event to ensure a meeting is missed.

In the ge= neral body of the text, the treatment of recurring events MUST address
time zones and daylight savings. This is the stuff iCal did= n't get right at
first and that lead to pain.

Can you clarify a bit what change you are = looking for here, if any? Do you believe the current text in JSCalendar = is ambiguous? A recurrence applies to the "start" property of the event,= which is a local date-time. All other properties (including "timeZone")= are inherited unless overridden for a specific instance. So an event wi= ll essentially recur in its time zone; if you need to translate this int= o UTC you'll of course need time zone information and to account for day= light savings etc.

Cheers,
Ne= il.
--c9116e7e33f04a42b5c5d8c86be3520b-- From nobody Wed Mar 25 10:04:01 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 7DE4F3A0C24; Wed, 25 Mar 2020 10:03:59 -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 RBD_Rt3404sj; Wed, 25 Mar 2020 10:03:57 -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 C4DE03A0BD4; Wed, 25 Mar 2020 10:03:57 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 3BBCFF406D6; Wed, 25 Mar 2020 10:03:47 -0700 (PDT) To: LarsHenriksen@get2net.dk, bernard.desruisseaux@oracle.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: alexey.melnikov@isode.com, iesg@ietf.org, calsify@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200325170347.3BBCFF406D6@rfc-editor.org> Date: Wed, 25 Mar 2020 10:03:47 -0700 (PDT) Archived-At: Subject: [calsify] [Errata Rejected] RFC5545 (5872) 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, 25 Mar 2020 17:04:00 -0000 The following errata report has been rejected for RFC5545, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid5872 -------------------------------------- Status: Rejected Type: Technical Reported by: Lars Henriksen Date Reported: 2019-10-10 Rejected by: Alexey Melnikov (IESG) Section: 3.8.5.3 Original Text ------------- Weekly on Tuesday and Thursday for five weeks: DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH Corrected Text -------------- Weekly on Tuesday and Thursday for five weeks: DTSTART;TZID=America/New_York:19970902T090000 RRULE:FREQ=WEEKLY;UNTIL=19971002T000000Z;WKST=SU;BYDAY=TU,TH Notes ----- The UNTIL rule is inclusive, and October 7, a Tuesday, should not be included. --VERIFIER NOTES-- Neil Jenkins wrote: This erratum is invalid. The original example, while slightly weird, is correct as is. The event's DTSTART time is 09:00 New York TIme, and the UNTIL time is 00:00 UTC, which is before this. Therefore you would not get a recurrence on the 7 Oct with this rule and so it would produce 10 occurrences, as specified. The "corrected text" is in fact invalid, as this would remove the 2nd Oct occurrence. -------------------------------------- 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