JMAP for Contacts
draft-ietf-jmap-contacts-10

# Éric Vyncke, INT AD, comments for draft-ietf-jmap-contacts-09

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Jim Fenton for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

I hope that this review helps to improve the document,

Regards,

-éric



# COMMENTS (non-blocking)


## Section 1.4.1

In `This MUST be an integer >= 1, or null for no limit` does null represent the integer 0 or NULL (lile in SQL) ? Suggest adding text to clarify, perhaps only double quotes around null.

In `If true, the user may create an AddressBook in this account` suggest to use 'if and only if' construct.

## Section 2

Which type is 'id' ? Integer ? String ? Also applies to sections 3. If well-known by the JMAP community, suggest a reminder in the terminology.


'isDefault' text could be clearer when no AddressBook has isdefault=true.

In the `mayRead`and others, should the following text be a normative MAY ?

## Section 3.3.1

Use of `UTCDate` seems to refer to UTC date and time. It is perhaps well-know in the JMAP community but could benefit from some explanations.

Can all `String` be UTF-8 encoded ?

# Gunter Van de Velde, RTG AD, comments for draft-ietf-jmap-contacts-09

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.


#GENERIC COMMENTS
#================

191	   *  *isDefault*: Boolean (server-set)
192	      This SHOULD be true for exactly one AddressBook in any account,
193	      and MUST NOT be true for more than one AddressBook within an
194	      account.  The default AddressBook should be used by clients
195	      whenever they need to choose an AddressBook for the user within
196	      this account, and they do not have any other information on which
197	      to make a choice.  For example, if the user creates a new contact
198	      card, the client may automatically set the card as belonging to
199	      the default AddressBook from the user's primary account.

What if none is set true? will there then be a random selected at default? 
is there a mechanism or desire to make such selection deterministic?

201	   *  *isSubscribed*: Boolean

203	      True if the user has indicated they wish to see this AddressBook
204	      in their client.  This should default to false for AddressBooks in
205	      shared accounts the user has access to and true for any new
206	      AddressBooks created by the user themself.

208	      If false, the AddressBook and its contents should only be
209	      displayed when the user explicitly requests it or to offer it for
210	      the user to subscribe to.

is there a reason why this section does not use [RFC2119] [RFC8174] language?

Thanks for addressing my comments.

Thanks for addressing my comments.

I'm a bit confused why mayAdmin is not called mayShare, since that is what it is. To me, mayAdmin would include mayDelete, but here that is not the case.

Thank you to Meral Shirazipour for the GENART review.

** Section 7.  Section 7.1, 7.2 and 7.3 don’t explicitly name the registry.  However, Section 7.4, does.  For clarity, I would recommend:

OLD #1
   IANA will register the "contacts" JMAP Capability as follows:
NEW
IANA will register "contacts" in the “JMAP Capabilities” registry as follows:

OLD #2
   IANA will register the "AddressBook" JMAP Data Type as follows:
NEW
IANA will register "AddressBook" in the “JMAP Data Types” registry as follows:


OLD #3
   IANA will register the "ContactCard" JMAP Data Type as follows:
NEW
IANA will register “ContactCard" in the “JMAP Data Types” registry as follows:

Thanks for working on this specification. I have no issues here from transport protocol point of view.

I have one observation, why does the mayAdmin has one modify right for "shareWith" property?