[Last-Call] Secdir last call review of draft-ietf-jmap-contacts-06
Shivan Sahib via Datatracker <noreply@ietf.org> Thu, 04 April 2024 06:19 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED458C14F61E; Wed, 3 Apr 2024 23:19:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Shivan Sahib via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: draft-ietf-jmap-contacts.all@ietf.org, jmap@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.9.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171221155095.47781.827957534903822489@ietfa.amsl.com>
Reply-To: Shivan Sahib <shivankaulsahib@gmail.com>
Date: Wed, 03 Apr 2024 23:19:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/-CapAsIsZKiqbrzaOqyxrutmHvA>
Subject: [Last-Call] Secdir last call review of draft-ietf-jmap-contacts-06
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2024 06:19:11 -0000
Reviewer: Shivan Sahib Review result: Has Issues Section 1.4 This section says "This document defines two additional capability URIs." but AFAICT it's only one i.e. urn:ietf:params:jmap:contacts Section 2 Why does description property not have any restrictions unlike the name property? In general, it's a bit confusing which properties are mandatory and which are optional: sometimes it's pretty obvious (id and name), and sometimes it's not (sortOrder). I would highly recommend explicitly labelling all properties as either mandatory (and then defining what the possible values are), or optional (similar, but also with a sensible default). Looks like Principal is missing a reference to https://datatracker.ietf.org/doc/html/draft-ietf-jmap-sharing-06. mayDelete property in AddressBookRights is confusing, since I first thought it means the ability to delete ContactCards since that's what mayRead and mayWrite mention. Section 5 The Security Considerations section needs to address the fact that a user query which uses filtering/sorting is basically untrusted input and recommend how to sanitize and treat the input. It should at the very least point to RFC 8620 security guidance around parsing JSON input.
- [Last-Call] Secdir last call review of draft-ietf… Shivan Sahib via Datatracker
- Re: [Last-Call] Secdir last call review of draft-… Neil Jenkins