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

[Lisa Dusseault <[e-mail]>]

Thanks for your responses.

I've been thinking over the architecture for the past few days, and wanted
to question whether profiling JMAP existing methods is actually the
easiest/best approach to import/export. Focusing purely on export, and
keeping the conversation very high level, I note that with this proposal,
each client has to figure out what combination of queries to make and data
to ask for, and each server needs to figure out how to support any query
the client might make within the profile limits.  ISTM that queries that
miss some resources or cover some resources more than once are all too easy
to build.  I wonder if we can't build something more robust - more direct
guidance to the purpose, less possibilities to do unexpected creative
things.

For example, how about a method for /export directly?  Although this would
be a new method, it can be much more limited than /get and /query combined
are, and it lets the server know what the intent is.  It can have some
flexibility to operate on subsets of a full mailbox, but also doesn't have
to have the full flexibility of /query.  Thinking as an implementor, a
single mechanism that's new is a lot easier to figure out how to implement
from the spec, than correlating a profile spec and a core spec and also
trying to predict or learn what clients are likely to ask.

I don't know that this would necessarily be better - that depends on the
goals of profiling JMAP for import/export. Not just the main stated goal,
but I think there are some unstated goals like having a path for going from
partial-JMAP to full-JMAP (which I think a separate method does anyway as
it still builds on the basic connection and basic data model work).

WDYT?
Lisa

On Tue, Nov 12, 2024 at 3:19 AM Joris Baum <[e-mail]> wrote:

> Hi Lisa,
>
> Replied inline
>
> On 07.11.24 23:34, Lisa Dusseault wrote:
> >
> > I did a partial review of draft-ietf-jmap-essential-01.
>