From orie@transmute.industries Fri Apr 12 08:06:38 2024 Return-Path: X-Original-To: jmap@ietfa.amsl.com Delivered-To: jmap@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152CDC14F68F for ; Fri, 12 Apr 2024 08:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=transmute.industries Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLVH1Rj8N4-U for ; Fri, 12 Apr 2024 08:06:33 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D25C14F6AA for ; Fri, 12 Apr 2024 08:06:33 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id 41be03b00d2f7-5e8470c1cb7so731017a12.2 for ; Fri, 12 Apr 2024 08:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=transmute.industries; s=google; t=1712934393; x=1713539193; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qnpV/Ce4RLhlwWXZ0xOPC/1FWwJcHefgITWzr6g24Uc=; b=Kk3K9ZgDd7s99Lo56SQeysBDf1b9Az3izUzE3ezSscLRZNUpDnMSRW73qCjOZdXXh+ KJRskJWRBT4KMReiHdG6bhd/pzWNiekfkpWIhvmxo3oRcQdSFXjK55fHC0Mm9wDDuKiw a7bBiqZNWGX56vyZ1IPvYJpwn5CAvppDTFDgvOGOlT0ghRrDZddC5pbkg3CvmSTfCZXs qCQTRDfaGZ/a890lkhX1DJzvtIHCV7Swi8+aANMF7xH84Q5iCEQRuxhITb4qnujB7Ntm cAlPaJql7jZcEgm+ug8t6zvjN/3p5pwQVejaSQNES/UJ+zy3fw0X4aDPdvjdwsmxdxsN A0eQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712934393; x=1713539193; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qnpV/Ce4RLhlwWXZ0xOPC/1FWwJcHefgITWzr6g24Uc=; b=UbHkm1mEldlzuGWBkU/P0Dv49pBiTg2vAw48QtRLCYH1Da+GduFbdX7SEK64Ap+FNB 9fHd4sqQQQUeLwrpnTGjNAuyW9g8VaQrLuQlEyOYGfbCD4HtCCq7QJE+K5nn52Q2ko6N mIpDa/8G+KOaWMy3ow1IshAW1GKBuJ5A2mZx3w4aCGbBXtz/60RpXemnBp91nDIqra2u C54uu2D5+NKtfPYnPK43u0eJKGWNS6iRLRHY9EWCaiCnYzrupOQJD1WbVehx+g79X8+U 7gKyX09duaUtV1fpSFYt6XPKBjz7HHquzsrTRDQPs9ecjll/s3Zb8KgDaZmjz5MUdM76 9vmw== X-Forwarded-Encrypted: i=1; AJvYcCV4/pGgpt6fhKG/PqLLu8frIf8YAX+CqcOHG398I5E0tZiJcPDBEow4oVER8ra9JN7MZZkN5iQq+EHilWh+ X-Gm-Message-State: AOJu0YxChk97I6e7VB/b0EMX485W+2/ZsozCjLjNPvSmP6siNQAETw6U zVbeAAt0eBY4Z7Q6BNIPDDegNaz+w5azL6ZBMoVZ1g1NoagxOWlWNLojVNeCT4kh9IP6GDPNTyQ /NOwSBc7RHWvCQXEWOv57hz4fGFhFr47MiwKA3w== X-Google-Smtp-Source: AGHT+IGzaEbNRc9aX6Xxbzdn/pOd7GYTt1fvmUNnVWbN5/Nvk0veJvvApjSP0JJ6IoCx7kZJTwvWAZHwf0WKqRuZTV8= X-Received: by 2002:a17:90b:3b48:b0:2a2:8ed7:da34 with SMTP id ot8-20020a17090b3b4800b002a28ed7da34mr2599375pjb.1.1712934392818; Fri, 12 Apr 2024 08:06:32 -0700 (PDT) MIME-Version: 1.0 References: <171261811964.2420.13803806575481214175@ietfa.amsl.com> <029d16f4-4f5a-49da-ad5f-2a0f538f9d9d@dogfoodapp.fastmail.com> In-Reply-To: <029d16f4-4f5a-49da-ad5f-2a0f538f9d9d@dogfoodapp.fastmail.com> From: Orie Steele Date: Fri, 12 Apr 2024 10:06:21 -0500 Message-ID: To: Neil Jenkins Cc: iesg , draft-ietf-jmap-sharing@ietf.org, jmap-chairs@ietf.org, IETF JMAP Mailing List , Bron Gondwana , arnt.gulbrandsen@icann.org Content-Type: multipart/alternative; boundary="000000000000020d780615e79ee9" Archived-At: Subject: Re: [Jmap] Orie Steele's Discuss on draft-ietf-jmap-sharing-07: (with DISCUSS and COMMENT) X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2024 15:06:38 -0000 --000000000000020d780615e79ee9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Neil, Thanks for your updates, there are is only 1 remaining discussion point, which will repeat here: " The server MAY limit the maximum number of notifications it will ..." - denial of service / resource exhaustion ? See comments inline for the rest: On Thu, Apr 11, 2024 at 10:12=E2=80=AFPM Neil Jenkins wrote: > Hi Orie, > > Thank you for your review. I have published an updated draft > > addressing your comments, as detailed below. > > The repeated '*' make this section difficult to read, I initially assumed > this > syntax indicated the field is not optional. > > After reviewing RFC8620, it seems to simply be a "bolding" / "emphasis" > effect. > > > That's correct. In the HTML version of the document I think this makes it > clearer, but in the plain text version I agree it's more confusing. I wou= ld > probably defer to whatever the RFC Editors think is the best option here. > (Ideally in my mind, it keeps the bold for the HTML version but doesn't > wrap it in the asterisks for the plain text, if that's possible.) > > This section (and similar ones) contain many instances of "String" which = is > defined in https://datatracker.ietf.org/doc/html/rfc8620#section-1.1 > > As has been discussed on the list regarding a related document: > https://mailarchive.ietf.org/arch/msg/jmap/nEumbk7DKcV6AOg6q-7yD_qetU0/ > > Unicode / i18n processing of these fields is possibly non trivial... > The document would be greatly improved by a section commenting on what > kinds of > JSON Strings / UTF-8 strings must remain supported. Examples in an append= ix > demonstrating interesting edge cases / unicode characters might help. > > > I have added an Internationalisation Considerations section, with the > following text: > > Experience has shown that unrestricted use of Unicode can lead to problem= s > such as inconsistent rendering, users reading text and interpreting it > differently than intended, and unexpected results when copying text from > one location to another. Servers MAY choose to mitigate this by restricti= ng > the set of characters allowed in otherwise unconstrained String fields. > The FreeformClass, as documented in [RFC7564 > > ], Section 4.3 may be a > good starting point for this. > > Attempts to set a value containing code points outside of the permissible > set can be handled in a few ways by the server. The first option is to > simply strip the forbidden characters and store the resulting string. Thi= s > is likely to be appropriate for control characters for example, where the= y > can end up in data accidentally due to copy-and-paste issues, and are > probably invisible to the end user. JMAP allows the server to transform > data on create/update, as long as any changed properties are returned to > the client in the /set response, so it knows what has changed, as per [ > RFC8620 > > ], Section 5.3 . > Alternatively, the server MAY just reject the create/update with an > invalidProperties SetError. > "Section 4.3 may be a good starting point for this." -> "Section 4.3 might be a good starting point for this." It's a nit, but "might be..." avoids the lower case "may". Thanks for adding this section, it addresses most of my discuss. > ``` > 310 * *accountIds*: String[] > 311 A list of account ids. The Principal matches if any of the > ids in > 312 this list are keys in the Principal's "accounts" property > (i.e., > 313 if any of the account ids belong to the principal). > ``` > > Should this not be Id[] ? Is full UTF-8 equality check expected here? > > > It should indeed be Id[], thanks for spotting, I've fixed this. > > ``` > 354 The server MAY limit the maximum number of notifications it wi= ll > 355 store for a user. When the limit is reached, any new > notification > 356 will cause the previously oldest notification to be > automatically > 357 deleted. > ``` > > Why not SHOULD or MUST? What happens if there is no limit? > > > You could end up with a lot of notifications. This is not necessarily a > problem as long as your server and client are well architected. The point > of this text was mainly to make it permissible for servers to choose not = to > store all the notifications if it thinks it's not required. > My concern was denial of service / resource exhaustion. I'd prefer a "SHOULD, unless" framing instead of MAY here, but it's up to you. > > ``` > 359 The server MAY coalesce notifications if appropriate, or remov= e > 360 notifications that it deems are no longer relevant or after a > certain > 361 period of time. The server SHOULD automatically destroy a > 362 notification about an object if the user subscribes to that > object. > ``` > Why not MUST? Should 362 say "unsubscribes" ? > > > The original intention here was "subscribe" =E2=80=94 if the notification= was > telling you that you now have access to an object and the user subscribes > to it, they know it exists and so don't need the notification. Upon > reflection though, I think this is more something a user presentation > issue, and something a client should handle (when subscribing, it could > choose to destroy the notification), so I have just removed this sentence= . > Thanks. > > ``` > 439 * *objectAccountId*: String > 440 The objectAccountId value must be identical to the given > value to > 441 match the condition. > ``` > > Should this be `*objectAccountId*: Id` ? > > > Yes, thanks. Fixed. > > ``` > 173 The server MAY reject the user's attempt to subscribe to some > 174 resources even if they have permission to access them, e.g., a > 175 calendar representing a location. > ``` > > Can this be strengthened to a SHOULD with clear conditions for when the > server > MUST allow subscription? > > > Not really, it's dependent on the implementation. For example, with JMAP > calendars, the client MUST be allowed to set their own sort order and a f= ew > other properties on subscribed calendars, so if the server can't support > this for some calendars (e.g. a calendar representing a room that's > actually auto-generated from another backend booking system) it must reje= ct > the subscription attempt. While the calendars spec also notes the server > may reject the subscription, I think it's worth having up front as a > general thing here too so they can't be seen as in conflict. > Ok. > > ``` > 177 A user may query the set of Principals they have access to wit= h > 178 "Principal/query" (see Section 2.4). The Principal object may > then > 179 provide Account objects if the user has permission to access > data for > 180 that principal, even if they are not yet subscribed. > ``` > > Can this be strengthened with normative language? > For example: > The Principle object MUST contain / provide when... > The Principle object MUST NOT contain / provide when... > > > I have rewritten this as: > > *The Principal object will contain an Account object for all accounts > where the user has permission to access data for that principal, even if > they are not yet subscribed.* > > I don't think the normative MUST is appropriate here as this is simply a > statement of the structure of the object. It should avoid any hint that > there is any kind of choice here! > Thanks. > > ``` > 295 However, the server may reject this change, and probably will > reject > 296 any other change, with a forbidden SetError. Managing > principals is > 297 likely tied to a directory service or some other vendor-specif= ic > 298 solution, and may occur out-of-band, or via an additional > capability > 299 defined elsewhere. > ``` > > Can this language be strengthened? > > For example: When the server rejects updates it MUST use a SetError of ty= pe > forbidden as described in Section 5.3 of RFC8620. > > > I have rewritten this as: > > *Managing principals is likely tied to a directory service or some other > vendor-specific solution and may occur out-of-band, or via an additional > capability defined elsewhere. Allowing direct user modification of > properties has security considerations, as noted in **Section 5* > *. > Servers MUST reject any change it doesn=E2=80=99t allow with a **forbidde= n** > SetError.* > Thanks. > > > ``` > 314 * *email*: String > 315 Looks for the text in the email property. > ``` > > I suggest a stronger reference for IDNA compatible email identifiers. > There are many combinations of unicode characters that will not result in= a > valid email address. Consider: > https://datatracker.ietf.org/doc/html/rfc6531 If > this field is not required to be a well formed email (possibly one build > of an > IDNA), perhaps note that directly. > > > I have added to the "email" property definition: > > *If given, the value MUST be conform with the "addr-spec" syntax, as > defined in **[**RFC5322* > *], > **Section 3.4.1* *.* > This reads awkwardly, I suggest: If present, the value MUST conform to the "addr-spec" syntax, as defined in [RFC5322 ], Section 3.4.1 . > > ``` > 318 * *text* String > 319 Looks for the text in the name, email, and description > properties. > ``` > > The use of the word text is slightly misleading here without inclusion of > the > charset, since strictly speaking this is filtering on octets (encoding so= me > UTF-8 string), correct? > > Thanks to Yaron Sheffer for his comments to this effect in the SEC DIR > review. > > > I have updated this wording to address Yaron's comments. > Thanks > > ``` > 347 The server SHOULD create a ShareNotification whenever the user= 's > 348 permissions change on an object. It SHOULD NOT create a > notification > 349 for permission changes to a group principal, even if the user > is in > 350 the group. > ``` > > Why not MUST? The way this is written, an implementation could easily > decide to > reverse these recommendations. > > > The SHOULD is in recognition that this API is often going to be an > interface onto an existing directory management system (unlike most other > JMAP APIs, where we can be more proscriptive). > Ok. > > ``` > 614 5. Security Considerations > ``` > > Please consider adding security considerations regarding deceptive use of > unicode characters, perhaps drawing from previous work, for example from: > https://datatracker.ietf.org/doc/html/rfc5894#section-1.4 > > """ > The introduction of the larger repertoire of characters > potentially makes the set of misspellings larger, especially given > that in some cases the same appearance, for example on a business > card, might visually match several Unicode code points or several > sequences of code points. > """ > > > I have added into the security considerations: > > *Note that simply forbidding the use of a name already in the system is > insufficient protection, as a malicious user could still change their nam= e > to something easily confused with the existing name by using trivial > misspellings or visually similar unicode characters.* > > Thanks > ``` > 639 The set of principals within a shared environment SHOULD be > strictly > 640 controlled. If adding a new principal is open to the public, > risks > 641 include: > ``` > > Why not MUST? > > > This should be a MUST, I've changed it. > > Is consent from existing principles required or recommended when adding > new principles? > > > Not normally, no. Think of a standard office environment, where the > principals correspond to employees. > > ## Nits > > ``` > 536 "u12345678": { > 537 "name": "jane.doe@example.com" > 538 "isPersonal": true > 539 "isReadOnly": false > 540 "accountCapabilities": { > 541 "urn:com.example:jmap:todo": {}, > 542 "urn:ietf:params:jmap:principals:owner": { > 543 accountIdForPrincipal: "u33084183", > 544 principalId: "P105aga511jaa" > 545 } > 546 } > 547 } > ``` > > This example is malformed JSON. accountIdForPrincipal and principalId are > missing quotes, and the there is no indication of elision, consider > starting > with { ... "u12345678": ... } > > > Thanks, I've fixed this. > > Its also strange that "name" is an email in this example > > > I used this because the account name is most commonly the email address o= f > the owner of the account. > Ok > > Cheers, > Neil. > --=20 OS, ART AD --000000000000020d780615e79ee9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neil,

Thanks for your updates, there are is= only 1 remaining discussion point, which will repeat here:

" T= he server MAY limit the maximum number of notifications it will ..." -= denial=C2=A0of service / resource exhaustion ?

See comments inline = for the rest:

On Thu, Apr 11, 2024 at 10:12=E2=80=AFPM Neil Jenkins <neilj@fastmailteam.com> wrote:=
Hi Orie,

Thank you for your review.=C2=A0I have published an u= pdated draft addressing your comments, as detailed below.

Th= e repeated '*' make this section difficult to read, I initially ass= umed this
syntax indicated the field is not optional.

After reviewing RFC8620, it seems to simply be a &quo= t;bolding" / "emphasis" effect.
<= br>
That's correct. In the HTML version of the document I thi= nk this makes it clearer, but in the plain text version I agree it's mo= re confusing. I would probably defer to whatever the RFC Editors think is t= he best option here. (Ideally in my mind, it keeps the bold for the HTML ve= rsion but doesn't wrap it in the asterisks for the plain text, if that&= #39;s possible.)

This section (and similar ones) contain many in= stances of "String" which is
defined in=C2=A0https://datatracker.ietf.org/doc/html/rfc8620#section-1.1

As has been discussed on the list regarding a relate= d document:

Unicode / i18n processing of these fields is possibly non trivial..= .
The document would be greatly improved by a section comment= ing on what kinds of
JSON Strings / UTF-8 strings must remain= supported. Examples in an appendix
demonstrating interesting= edge cases / unicode characters might help.
I have added an Internationalisation Considerations section, wi= th the following text:

Experience has shown th= at unrestricted use of Unicode can lead to problems such as inconsistent re= ndering, users reading text and interpreting it differently than intended, = and unexpected results when copying text from one location to another. Serv= ers MAY choose to mitigate this by restricting the set of characters allowe= d in otherwise unconstrained=C2=A0String=C2=A0fiel= ds. The FreeformClass, as documented in=C2=A0[RFC7564],=C2=A0Section 4.3=C2=A0may be a good starting point fo= r this.

Attempts to set a value containing cod= e points outside of the permissible set can be handled in a few ways by the= server. The first option is to simply strip the forbidden characters and s= tore the resulting string. This is likely to be appropriate for control cha= racters for example, where they can end up in data accidentally due to copy= -and-paste issues, and are probably invisible to the end user. JMAP allows = the server to transform data on create/update, as long as any changed prope= rties are returned to the client in the=C2=A0/set=C2=A0response, so it knows what has chang= ed, as per=C2=A0[RFC8620],=C2=A0Section 5.3. Al= ternatively, the server MAY just reject the create/update with an=C2= =A0invalidProperties=C2=A0SetError.

"S= ection 4.3 may be a good starting point for this." -> "Section= 4.3 might be a good starting point for this."

It's a nit, = but "might be..." avoids the lower case "may".

T= hanks for adding this section, it addresses most of my discuss.


```
310=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 *accountIds*: String[]
311= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A list of acco= unt ids.=C2=A0 The Principal matches if any of the ids in
312= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 this list are = keys in the Principal's "accounts" property (i.e.,
<= div>313=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if any = of the account ids belong to the principal).
```

Should this not be Id[] ? Is full UTF-8 equality check exp= ected here?

It should indeed be <= code style=3D"border-width:1px;border-style:solid;border-color:rgb(204,204,= 204);border-radius:3px;background-color:rgb(246,246,246);background-repeat:= repeat;background-image:none;background-size:auto;background-origin:padding= -box;background-clip:border-box;font-family:menlo,consolas,monospace;font-s= ize:90%;padding:1px 3px">Id[], thanks for spotting, I've fixed t= his.

```
354=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 The server MAY limit the maximum number of notifications it will
=
355=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 store for a user.= =C2=A0 When the limit is reached, any new notification
356=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 will cause the previously oldest no= tification to be automatically
357=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 deleted.
```

Why= not SHOULD or MUST? What happens if there is no limit?

You could end up with a lot of notifications. This i= s not necessarily a problem as long as your server and client are well arch= itected. The point of this text was mainly to make it permissible for serve= rs to choose not to store all the notifications if it thinks it's not r= equired.

My concern was denial o= f service / resource exhaustion.
I'd prefer a "SHOULD, unless&q= uot; framing instead of MAY here, but it's up to you.
=C2=A0

```
359=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 The server MAY coalesce notifications if appropriate, or= remove
360=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 notific= ations that it deems are no longer relevant or after a certain
361=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 period of time.=C2=A0 The s= erver SHOULD automatically destroy a
362=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 notification about an object if the user subscribes t= o that object.
```
Why not MUST? Should 362 say= "unsubscribes" ?

The o= riginal intention here was "subscribe" =E2=80=94 if the notificat= ion was telling you that you now have access to an object and the user subs= cribes to it, they know it exists and so don't need the notification. U= pon reflection though, I think this is more something a user presentation i= ssue, and something a client should handle (when subscribing, it could choo= se to destroy the notification), so I have just removed this sentence.
<= /div>

Thanks.
=C2=A0
=

```
439=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 *=C2=A0 *objectAccountId*: String
440=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The objectAccountId value mus= t be identical to the given value to
441=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 match the condition.
= ```

Should this be `*objectAccountId*: Id` ?

Yes, thanks. Fixed.
=
```=
173=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The server MAY= reject the user's attempt to subscribe to some
174=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 resources even if they have permission= to access them, e.g., a
175=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 calendar representing a location.
```

Can this be strengthened to a SHOULD with clear conditions = for when the server
MUST allow subscription?

Not really, it's dependent on the implementat= ion. For example, with JMAP calendars, the client MUST be allowed to set th= eir own sort order and a few other properties on subscribed calendars, so i= f the server can't support this for some calendars (e.g. a calendar rep= resenting a room that's actually auto-generated from another backend bo= oking system) it must reject the subscription attempt. While the calendars = spec also notes the server may reject the subscription, I think it's wo= rth having up front as a general thing here too so they can't be seen a= s in conflict.

Ok.
=C2=A0

```
177=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A user may query the set of Princip= als they have access to with
178=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 "Principal/query" (see Section 2.4).=C2=A0 The Pr= incipal object may then
179=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 provide Account objects if the user has permission to access data= for
180=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that princ= ipal, even if they are not yet subscribed.
```
=
Can this be strengthened with normative language?
<= div>For example:
The Principle object MUST contain / provide = when...
The Principle object MUST NOT contain / provide when.= ..

I have rewritten this as:
<= /div>

The Principal object will contain an Account ob= ject for all accounts where the user has permission to access data for that= principal, even if they are not yet subscribed.

I don't think the normative MUST is appropriate here as this is = simply a statement of the structure of the object. It should avoid any hint= that there is any kind of choice here!
<= div>
Thanks.
=C2=A0

=
```
295=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Howeve= r, the server may reject this change, and probably will reject
296=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 any other change, with a fo= rbidden SetError.=C2=A0 Managing principals is
297=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 likely tied to a directory service or som= e other vendor-specific
298=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 solution, and may occur out-of-band, or via an additional capabil= ity
299=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 defined els= ewhere.
```

Can this language be= strengthened?

For example: When the server re= jects updates it MUST use a SetError of type
forbidden as des= cribed in Section 5.3 of RFC8620.

I have rewritten this as:

Managing princip= als is likely tied to a directory service or some other=20 vendor-specific solution and may occur out-of-band, or via an additional capability defined elsewhere. Allowing direct user modification of=20 properties has security considerations, as noted in Section 5.= Servers MUST reject any change it doesn=E2=80=99t allow with a <= i>forbidden SetError.
=
Thanks.
=C2=A0


=
```
=
314=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 *email*: String<= br>
315=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Looks for the text in the email property.
```

I suggest a stronger reference for IDNA compatible email = identifiers.
There are many combinations of unicode character= s that will not result in a
valid email address. Consider:=C2= =A0https://datatracker.ietf.org/doc/html/rfc6531 If
this= field is not required to be a well formed email (possibly one build of an<= br>
IDNA), perhaps note that directly.

I have added to the "email" property definition:<= br>

If given, the value MUST be conform with th= e "addr-spec" syntax, as defined in [RFC5322], = Section 3.4.1.
=
This reads awkwardly, I suggest:

If present, the value MUST conf= orm to the "addr-spec" syntax, as defined in=C2=A0[RFC5322],=C2=A0Section 3.4.= 1.



```
31= 8=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 *=C2=A0 *text* String
=
319=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Looks = for the text in the name, email, and description properties.
= ```

The use of the word text is slightly misle= ading here without inclusion of the
charset, since strictly s= peaking this is filtering on octets (encoding some
UTF-8 stri= ng), correct?

Thanks to Yaron Sheffer for his = comments to this effect in the SEC DIR review.
<= br>
I have updated this wording to address Yaron's comments.<= br>

Thanks
=C2=A0

```
347=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 The server SHOULD create a ShareNotification whenever the user= 9;s
348=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 permissions= change on an object.=C2=A0 It SHOULD NOT create a notification
349=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for permission changes to = a group principal, even if the user is in
350=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 the group.
```

=
Why not MUST? The way this is written, an implementation could e= asily decide to
reverse these recommendations.

The SHOULD is in recognition that this API is o= ften going to be an interface onto an existing directory management system = (unlike most other JMAP APIs, where we can be more proscriptive).
=

Ok.
=C2=A0

```
614=C2=A0=C2=A0=C2=A0=C2=A0 5.=C2=A0 Security Co= nsiderations
```

Please consider= adding security considerations regarding deceptive use of
un= icode characters, perhaps drawing from previous work, for example from:
=

"""
= =C2=A0=C2=A0 The introduction of the larger repertoire of characters
=C2=A0=C2=A0 potentially makes the set of misspellings larger, espe= cially given
=C2=A0=C2=A0 that in some cases the same appeara= nce, for example on a business
=C2=A0=C2=A0 card, might visua= lly match several Unicode code points or several
=C2=A0=C2=A0= sequences of code points.
"""

I have added into the security considerations:

Note that simply forbidding the use of a nam= e already in the system is insufficient protection, as a malicious user cou= ld still change their name to something easily confused with the existing n= ame by using trivial misspellings or visually similar unicode characters.


<= div>Thanks=C2=A0
```
639=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 The set of principals within a shared environme= nt SHOULD be strictly
640=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 controlled.=C2=A0 If adding a new principal is open to the public, r= isks
641=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 include:
```

Why not MUST?

This should be a MUST, I've changed it.
<= /div>

Is consent from existing principles required or recommended when add= ing new principles?

Not normally,= no. Think of a standard office environment, where the principals correspon= d to employees.

## Nits

```
536=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "u12345678":= {
537=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 "name": "jane.doe@example.com"
538=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "isPerson= al": true
539=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 "isReadOnly": false
540=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "accou= ntCapabilities": {
541=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "urn:com.exa= mple:jmap:todo": {},
542=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "urn:ietf= :params:jmap:principals:owner": {
543=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 accountIdForPrincipal: "u33084183",
544=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 principalId: "P105= aga511jaa"
545=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
546=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
547=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 }
```

This example is malformed JSON. accountIdForPrincipal= and principalId are
missing quotes, and the there is no indi= cation of elision, consider starting
with { ... "u123456= 78": ... }

Thanks, I've = fixed this.

Its also strange that "name" is an email i= n this example

I used this becaus= e the account name is most commonly the email address of the owner of the a= ccount.

Ok
= =C2=A0

Cheers,
Neil.
<= /div>


--


OS, ART AD

= --000000000000020d780615e79ee9--