Re: [Jmap] Secdir last call review of draft-ietf-jmap-contacts-06

["Murray S. Kucherawy" <[e-mail]>]

On Thu, Apr 4, 2024 at 12:21 PM Murray S. Kucherawy <[e-mail]>
wrote:

> On Wed, Apr 3, 2024 at 11:19 PM Shivan Sahib via Datatracker <
> [e-mail]> wrote:
>
>> 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.
>>
>
> Any revision needed, or some other response to this?
>

This document completed IETF Last Call, but I don't know if the feedback it
received warrants a new version before scheduling it for an IESG telechat.

I'm going to be on vacation until the 15th, so I'll check in on this when I
get back, but for now it stays where it is.

-MSK