[Jmap] Orie Steele's Discuss on draft-ietf-jmap-contacts-09: (with DISCUSS and COMMENT)

[Orie Steele via Datatracker <[e-mail]>]

Orie Steele has entered the following ballot position for
draft-ietf-jmap-contacts-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-jmap-contacts/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

# Orie Steele, ART AD, comments for draft-ietf-jmap-contacts-09
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-jmap-contacts-09.txt&submitcheck=True

Thanks to Tim Bray for the ARTART review.

## Discuss

### UID vs UUID

I suggest the following clarifications:

Add "UID" to your terminology since it is not defined in RFC8620.

Something like:

```
UID:
: A unique identifier. UUID as defined RFC9562 is RECOMMENDED, but for backward
compatibility it MAY be a free-text value, see RFC9553 Section 2.1.9 for
details. ```

Then instead of:

```
309        *  *id*: Id (immutable; server-set)
310           The id of the ContactCard.  The id uniquely identifies a
311           ContactCard with a particular "uid" within a particular account.
```

Consider this alternative text:

"""
The id of the ContactCard. The id MUST be a UID as defined in Section 1.2 of
this document. """

Later:

```
371        *  *uid*: String
372           A card must have this string exactly as its uid to match.
```

"id" or "uid" ?

### Whats a "data: URI"

```
326        When returning ContactCards, any Media with a data: URI SHOULD return
```

Please add a reference to RFC2397.

### Intended Use: Reserved

```
748     7.5.3.  blobId

750        Property Name: blobId

752        Property Type: Not applicable

754        Property Context: Media

756        Intended Use: Reserved

758        Since Version: 1.0
759        Change Controller: IETF
```

The current registry contains no "Reserved" entries, and RFC8620 does not
define "reserved".

What does "Reserved" mean?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

## Comments

### AddressBook description string length

```
173        *  *description*: String|null (default: null)

175           An optional longer-form description of the AddressBook, to provide
176           context in shared environments where users need more than just the
177           name.
```

Is there an octet limit for this field (and all other string fields), or a
least a max length recommendation?

### Enumerations vs Booleans

```
229        An *AddressBookRights* object has the following properties:

231        *  *mayRead*: Boolean
232           The user may fetch the ContactCards in this AddressBook.
233        *  *mayWrite*: Boolean
234           The user may create, modify or destroy all ContactCards in this
235           AddressBook, or move them to or from this AddressBook.
236        *  *mayAdmin*: Boolean
237           The user may modify the "shareWith" property for this AddressBook.
238        *  *mayDelete*: Boolean
239           The user may delete the AddressBook itself.
```

Later:

```
564                "addressBookIds": {
565                  "062adcfa-105d-455c-bc60-6db68b69c3f3": true
566                },
```

I wonder why these are not modeled as:

```
"<className>Ids": [<id or uid>]
```

Perhaps the object syntax is used to anticipate extension?

### Access Control Policy

```
282        The "shareWith" property may only be set by users that have the
283        mayAdmin right.  When modifying the shareWith property, the user
284        cannot give a right to a principal if the principal did not already
285        have that right and the user making the change also does not have
286        that right.  Any attempt to do so MUST be rejected with a forbidden
287        SetError.
```

This is discretionary access control? Consider a citation and an example that
is not `"shareWith": null,` in Section 4.1.