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

[Neil Jenkins <[e-mail]>]

Hi Shivan,

Thank you for your review. I have published an updated draft <https://www.ietf.org/archive/id/draft-ietf-jmap-contacts-07.html> addressing your comments, details below.

> 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

Fixed.

> Section 2
> Why does description property not have any restrictions unlike the name
> property?

The name property has a length restriction, as it's intended as a short-ish name for display. The description property does not have a length restriction (servers may enforce sanity limits, as for any property of course).

> 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).

The current presentation follows the conventions of existing JMAP documents. As per RFC8620, Section 5.3 <https://datatracker.ietf.org/doc/html/rfc8620#section-5.3>, the "object type definition may define default values for properties.  Any such property may be omitted by the client."

As per RFC8620, Section 1.1 <https://datatracker.ietf.org/doc/html/rfc8620#section-1.1>, the "the client MUST NOT send [a server-set] property when creating a new object of this type."

> Looks like Principal is missing a reference to
> https://datatracker.ietf.org/doc/html/draft-ietf-jmap-sharing-06.

Thanks, I've added a reference.

> 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.

I see how you interpreted it like this, but I'm going to stick with "mayDelete" as it's consistent with what we did in RFC8621 <https://datatracker.ietf.org/doc/html/rfc8621#section-2> for mailboxes, and if you read the description it's clear (as you found).

> 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.

As this document is just defining a few data types within the JMAP protocol, *all* of RFC8620's security considerations apply, as already noted in the document. I'm not sure what you consider a new security consideration around filtering/sorting with this document?

Cheers,
Neil.