[Jmap] Review of draft-ietf-jmap-essential-01

[Lisa Dusseault <[e-mail]>]

I did a partial review of draft-ietf-jmap-essential-01.  I will later
continue taking notes and drawing connections and going back to reread with
new understanding, but I thought it would be more useful for me and for the
authors to send what I've got so far (so I don't rathole about something I
misunderstand, or about something that is going to change).


Section 2.2 “Shared data shall not be exposed over the API”.  Does "the
API" mean this protocol? Is "shall" descriptive? If this is meant to be an
explanation of a necessary fact, I would need more explanation to
understand because I don't see why shared data would necessarily not be
exposed. If it’s meant to be requirements language, that’s not clear.

Section 2.2, “Each user has the same set of capabilities” — what set of
users are we talking about ?  How does this relate to a session?  If it’s
THE user of the session, I wouldn’t think it matters. Does a session
resource have multiple users in some way?

Section 2.2 is referenced via footnote [1]  anywhere footnote [1] is
referenced in the table, e..g.  for /query method Request (accountId) and
/query method Response (accountId) .  That footnote says “Can be modeled as
a JSON file with only constant values."  How would an accountId be modeled
as a JSON file?  Or does this mean that the query method Response (all of
it) can be modeled as a JSON file with constant values?  I’m sure you know
what you mean here, I’m just not getting it, nor do I understand how that
relates to session resources which are the subject of section 2.2.

Section 3.2.2 The accountId in the /query method “Can therefore be ignored
on the server side”.  I don’t like the idea of ignoring the accountId.  If
it’s a wrong accountID or access is forbidden, that should be a bad
request.  Why is it different from regular JMAP use anyway?  Don't regular
JMAP use cases (not just those profiled for export/import) specify the
accountId?

Section 3: I fail to understand the organization of the nested sections in
section 3.  Is section 3.2.2 about Listing resources only required for
Exporting Data (but Exporting data is a subsection of 3.1.2 but not 3.2.2 ?
?? )


I’m trying to understand the various items with footnote [2].  Footnote [2]
comes on text with several variants
* “required for listing/paging[2]” e.g. /query method Request
* “error response for listing/paging[2]”
* “error response, required for listing/paging [2]” e.g. /get method
Request (ids)
* “constant value for listing/paging[2]”
* “error response for listing, required for paging[2]”
Then footnote 2 says “maxObjectsInGet might not be sufficiently high in
some products. In this case, /query is required. Similarly, paging might be
required in case a query might exceed the limit for the maximum amount of
results for /query”
I don’t understand how to put all this together.  The “in some products”
here leads me to believe the requirements are in fact not nailed down as
much as they appear.  Who gets to decide whether /query support is required
or not for a given server trying to support the export profile?

Also I have trouble understanding what the “error response, required for
listing/paging” and other variations mean.  I think this table format isn’t
clear enough to be normative, and I’m really twisted up by having several
parts of the requirements for supporting “/get method Request … “ split
into several rows.  It feels like combining “what is required’ along with
information that means something other than “what is required” in the same
table. I’d really love if there were one table with “Things that can be
replied to with only an error response  (but should not make the server
blow up)” and another with “Things that actually need to be implemented”.

Part of my problem with understanding section 3 is the sections called
“Listing” and “Paging”.  How do we know if Listing is required?  How do we
know if paging is required?

ISTM that to really apply draft-ietf-jmap-essential-01.html to define how
to do export for a given application, we would need to say more about that
given application. For example, if we want to use one of these profiles for
better interoperability of exporting one’s Contact data, I think there’s
hints in this document that it might be fine for the server with Contacts
data not to support paging functionality because all of my Contacts can be
downloaded at once.  But for better interoperability of exporting a user’s
email data, we’d better have quite solid reliable support for paging
through vast numbers of results.

I’m also putting together my mental model which involves RFC8620, RFC8621,
draft-ietf-jmap-contacts-10 and this draft.  Client access to server-held
email/contacts may have different pressures on ID immutability than
export/synch use cases. How does a client tell if a particular draft
message with id “Md45b47b4877521042cec0938” is a more recent version of
“Mf40b5f831efa7233b9eb1c7f” if the replacement of one by another was
originally not requested by this client?  How does a client tell if “Joe
Bloggs” is the same contact card that was previously “Joseph Bloggs” ? I
assume RFC8620 has been used for synch use cases because many full clients
are effectively synch engines, but I’d love to fill in my understanding
here. I looked in RFC8620 and draft-ietf-jmap-contacts-10 and may have
missed explanations there, but adding export/import use cases sharpens the
need to understand how a client can replace one contact or draft with a new
contact or draft, since these use cases lead to potentially more clients
than just the user's primary software application for a given domain.

Thanks
Lisa