[Jmap] John Scudder's Discuss on draft-ietf-jmap-sharing-08: (with DISCUSS)

[John Scudder via Datatracker <[e-mail]>]

John Scudder has entered the following ballot position for
draft-ietf-jmap-sharing-08: 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-sharing/



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

Thanks for this document, as a non-expert I found it easy to read. I have one
potential issue, related to subscriptions, I'd like to have a discussion about.

Caveat, as mentioned, I'm not an expert in this technology area, I'm simply
going on what the words in the respective specifications say. If the correct
outcome of the DISCUSSion is for you to apply a clue bat to me, and no changes
to the document, that's fine.

It seems as though there's a conflict between what you write:

   The JMAP Session object (see [RFC8620], Section 2) typically includes
   an object in the accounts property for every account that the user
   has access to.  Collaborative systems may share data between a very
   large number of Principals, most of which the user does not care
   about day-to-day.  The Session object MUST only include Accounts
   where either the user is subscribed to at least one record (see
   [RFC8620], Section 1.6.3) in the account, or the account belongs to
   the user.

And the definition of the session object in RFC 8620:

   A successful authenticated GET request to the JMAP Session resource
   MUST return a JSON-encoded *Session* object, giving details about the
   data and capabilities the server can provide to the client given
   those credentials.  It has the following properties:
...
   o  accounts: "Id[Account]"

      A map of an account id to an Account object for each account (see
      Section 1.6.2) the user has access to.
...

RFC 8620 doesn't say "typically has" it says "has", which to my eyes is a
requirement, not a suggestion, notwithstanding the lack of RFC 2119 keyword.

If (as it appears) you're making a normative change to what RFC 8620 specifies,
that doesn't bother me,  but I think you should call it out more clearly, and I
think you should use the Updates: 8620 header.

Continuing,

            StateChange events for changes to data SHOULD only be sent
   for data the user has subscribed to and MUST NOT be sent for any
   account where the user is not subscribed to any records in the
   account, except where that account belongs to the user.

A close reading of RFC 8620 section 7.1 makes it seem like the above is also a
change, although PushSubscription in 8620 seems like the exception that proves
the rule that 7.1 didn't mean what the plain language of it says.

After reading Section 4 of your document, though, I wonder if you are even
talking about the same thing as what RFC 8620 describes as a subscription. Your
Section 4 defines "isSubscribed" to mean "the user wishes to subscribe to see
this data" and AFAICT doesn't relate to push notifications, except through the
much earlier sentence about StateChange that I quote above.

Can you say a few words about how PushSubscription and isSubscribed relate to
one another, and whether this relationship will be sufficiently clear to the
intended audience of this document? Because it's not at all clear to me.

Depending on what the intended relationship between these two things is, maybe
a few words about it in the document would help, maybe it needs to update RFC
8620, etc.