Re: [Gen-art] Genart last call review of draft-ietf-calext-jscalendar-25

Alissa Cooper <> Wed, 23 September 2020 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23E653A121B; Wed, 23 Sep 2020 08:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Status: No, score=-2.119 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=sNnlcX3H; dkim=pass (2048-bit key) header.b=REntKRy2
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Y7LiD6mXa8x; Wed, 23 Sep 2020 08:15:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A51F3A1220; Wed, 23 Sep 2020 08:15:23 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 0431F5C023D; Wed, 23 Sep 2020 11:15:22 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Wed, 23 Sep 2020 11:15:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= from:message-id:content-type:mime-version:subject:date :in-reply-to:cc:to:references; s=fm1; bh=dpvCr9z9QcGnM142UN5TFtX rW/Uqt7gfjmxjklQR6Gk=; b=sNnlcX3Ho0imkB1eqNpTyF4H/ElFV/DrC+hGoDT sXGu+PyHHGt/WS+o2vPV06xlhKeoEATJkae5DL46IwdUhWu+6sE0xs1JaZd57af3 8udDzy9rHlZGLeNRMzZYiGKdnPLdK3bwIHdzmVxvJRk8P4Cau7L1KikTfeN3/CSd OWBcp1vE79Ci05aG9xObNr/bplBrzMyz7XBd+96v5GU9IrO+BMovCsTt8ADsdfs0 iFnx5120kqEABHsmum9JeJIZrwMElnn2A767Pm/xlWj0gjZi2HJ8J75GAALsgwvd D4YZxwfX8Lcq9gZ4lobCumRS6XwrfC2KJ1IUkRCGImKkNbA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=dpvCr9 z9QcGnM142UN5TFtXrW/Uqt7gfjmxjklQR6Gk=; b=REntKRy2jvcD1CpHKVKgnz bDlNkZj3Deq/pJqTJD1Qk/YW1qJfdmQ5osimVFbjC8BTIoZTDVmi6ILVtWRZQDUe HRpMvkgwHuUmTuT6deDUjBmE/k8RmaXZDTEtGoPIDxi29PvIgWV2eKs+3JF5GgVf jKjbunWydqdcFV17fpxvJ/loq6VHk1noYESlc4D8LHun9MIIj6pyB0jBHkZOHLkm uJxA6BwfS9zDzQybHJj92B8mtyYDrevrcqk7oEZNEDU/TfvVrT3Wx1Ao+IqTXuqK 4R5Sg+LthPJ9kQghJLr17XtjldU0k4iNN7ISIA2ukBvwwY+PPpk+3TqMW6WSa6Rw ==
X-ME-Sender: <xms:iGZrXzcwzZBjrWNKBoBid_OE3vxQF5f0UI7LTQ2WttqhwlWVGoJfJw> <xme:iGZrX5MNWW3Ep23ZI17ikWc0pI4hUe8IuE9gwrCFgwjHIoyYCAcX1eE_kCboDKc7X Ch3PU6pcneovIbaPg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeigdekjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhkfgtggfuffgjvfhfofesrgdtmherhhdtvdenucfhrhhomheptehlihhsshgr ucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucggtffrrghtth gvrhhnpeelteekheffkeeuuedutedviedutedvtdffheeigeetjeelhfdtteeiffdvudeu teenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedutdekrdehuddruddtuddrle eknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghl ihhsshgrsegtohhophgvrhifrdhinh
X-ME-Proxy: <xmx:iGZrX8gxAYbaj2TjJF3jZ_h4SdJepCDR2dpf-X9XEJD9g54LROvxVA> <xmx:iGZrX09Of7qaZVbWzIP1au-8aogWIyaqyXmivQSEpK1CTWHZlXowfw> <xmx:iGZrX_sVp7ehY3GGzCQU_j1qJK5yBRZ-zbVb6Zy62NoFsk1Vrh6o8w> <xmx:iWZrX_KUn1803Lz3L9HSjVhAUlua851vvpooJykgyZiTBw4_jnzkeA>
Received: from alcoop-m-c46z.fios-router.home ( []) by (Postfix) with ESMTPA id 27B513064674; Wed, 23 Sep 2020 11:15:20 -0400 (EDT)
From: Alissa Cooper <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FF5090F8-1545-4E2A-AF79-F64AFAB053FA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Wed, 23 Sep 2020 11:15:19 -0400
In-Reply-To: <>
Cc: gen-art <>,,,
To: Neil Jenkins <>, Robert Sparks <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-calext-jscalendar-25
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 Sep 2020 15:15:25 -0000

Robert, thanks for your review. Neil, thanks for the updates. I entered a No Objection ballot.


> On Mar 7, 2020, at 9:58 PM, Neil Jenkins <> wrote:
> 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.
> _______________________________________________
> Gen-art mailing list
> <>
> <>