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

Neil Jenkins <neilj@fastmailteam.com> Sun, 08 March 2020 02:58 UTC

Return-Path: <neilj@fastmailteam.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@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: <xms:WV9kXuLPQaNYy3smlgfSu5YEOeTTQlfohwi8E88YurCItNrpAI0ynQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudduhedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreertdenucfhrhhomhepfdfpvghi lhculfgvnhhkihhnshdfuceonhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepnhgvihhljhesfhgrshhtmhgrihhlthgvrghmrdgtoh hm
X-ME-Proxy: <xmx:WV9kXid8zQU9wGnwRJayByUw5FiqSyIf_3u1IDGEeOOsJifC-V-_xw> <xmx:WV9kXhfw-2qh2UMElNJQPNWSlX8FbzXIp7RAyxAfjgPrQxTnH7_bTw> <xmx:WV9kXlODwQaXc4fMgtv5e5DBhSo_f1mM7uZ8_9jk57x77eFhAjkevw> <xmx:Wl9kXmKBbA6zS4sGdAXQrfN5y-mx3WlT3y_-wgbCNRcMcpJmT-sC4w>
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" <neilj@fastmailteam.com>
To: "Robert Sparks" <rjsparks@nostrum.com>, 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: <https://mailarchive.ietf.org/arch/msg/gen-art/X4odY7l7Jy-mFdIB-KMS3WBQUC0>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-calext-jscalendar-25
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 08 Mar 2020 02:58:39 -0000

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 <https://tools.ietf.org/html/draft-ietf-calext-jscalendar-26> with all of the above updates.

Cheers,
Neil.