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

[Neil Jenkins <[e-mail]>]

Hi Orie,

Thanks for the further feedback.

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

Sure, I've changed this.

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

After further consideration, I have left this as a MAY, but I have added a "Denial of service" security consideration <https://www.ietf.org/archive/id/draft-ietf-jmap-sharing-09.html#name-denial-of-service> with the following text:

By creating many changes to the sharing status of objects, a user can cause many ShareNotifications to be generated, which could lead to resource exhaustion. Servers can mitigate this by coalescing multiple changes to the same object into a single notification, limiting the maximum number of notifications it stores per user, and/or rate limiting the changes to sharing permissions in the first place. Automatically deleting older notifications after reaching a limit can mean the user is not made aware of a sharing change, which can itself be a security issue. For this reason, it is better to coalesce changes and use other mitigation strategies.

>> I have added to the "email" property definition:
>> *If given, the value MUST be conform with the "addr-spec" syntax, as defined in **[**RFC5322* <https://author-tools.ietf.org/api/export/4a43b11b-ad50-4bc3-90cd-0c00e02ce767/sharing.html#RFC5322>*], **Section 3.4.1* <https://rfc-editor.org/rfc/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 <https://author-tools.ietf.org/api/export/4a43b11b-ad50-4bc3-90cd-0c00e02ce767/sharing.html#RFC5322>], Section 3.4.1 <https://rfc-editor.org/rfc/rfc5322#section-3.4.1>.

Thanks, the "be" was a typo in my original; I have updated as suggested.

Cheers,
Neil.