[JMAP] draft-ietf-jmap-filenode-14: alreadyExists existingId vs. §5 discoverability

[Mehdi Kouhen <[e-mail]>]

Hi,

Implementing draft-ietf-jmap-filenode-14, we ran into two requirements that
cannot both be satisfied for a shared directory.
I could not find this raised before.

Section 3.2.3 (FileNode/set):

   "alreadyExists" [...] The SetError object MUST include an existingId
   property with the id of the existing FileNode.

Section 5 (Access Control):

   Nodes which are not "discoverable" MUST return notFound errors if
   fetched with FileNode/get and MUST NOT be returned in response to
   FileNode/query.

They collide when a user may create a child but not read one.
`mayAddChildren` and `mayRead` are independent in FilesRights, so a drop
box is expressible: Bob creates a name that collides with a sibling he cannot
discover.
Section 3.2.3 says return its id; Section 5 says that node must not appear in
his answers.

The disclosure itself obviously cannot be closed completely, as the
"alreadyExists" itself discloses that a sibling of that name exists.
However, preventing the disclosure of the id and limiting the disclosure to
"existence" seems worth doing.

If the working group agrees the Section 5 intent should win, one way to
resolve it would be to amend the Section 3.2.3 error definition:

   "alreadyExists" -- a create or update would cause a name collision
   with an existing sibling FileNode, and onExists is null.  The
   SetError object MUST include an existingId property with the id of
   the existing FileNode, unless that FileNode is not discoverable by
   the requesting user (see Section 5), in which case the server MUST
   NOT include existingId and SHOULD return "forbidden" instead.

This cuts against Neil's push to make Metadata's existingId a MUST [1], but a
client cannot use the id of a node it may not fetch, so nothing is lost.
Precedent for "forbidden" is already here: Blob/convert picks among
notFound, invalidProperties and forbidden by what the user may do.

Metadata will hit the same collision once it has a visibility model, so the
general shape may be worth settling once. 

Thanks,

[1] https://mailarchive.ietf.org/arch/msg/jmap/jKJw9Zk3-82Sid3Qzld7Jebfd6I/

-- 
Mehdi KOUHEN 
IT Tech Leader 
PU.Seald 

https://www.ovhcloud.com/