Re: [Jmap] JMAP for Migration and Data Portability

[Joris Baum <[e-mail]>]

Oops. There I clicked the wrong button. Everything I wrote after "TODO" 
was thought as an internal note for myself.

Let me try to explain:

/query and /set are quite powerful methods each with a few features that 
not every vendor would like to implement. The list below is a first try 
at how to signal support for parts of their features via the errors / 
capability flags defined in JMAP Core.


/set

* "maxObjectsInSet" - no support for /set

* stateMismatch - no support for ifInState (dirty, because it signals an 
issue on the client side)

* SetError - no support for create, update, destory (via description. 
Not machine readable)

/query

* anchorNotFound - no support for anchor (dirty, because it signals an 
issue on the client side)

* unsupportedSort - no support for sort

* unsupportedFilter - no support for filter


This could work, but I am not sure if JMAP Core defines enough ways to 
signal lack of support for certain features. Let me think a bit more.


Regards,


Joris


On 21.03.23 15:38, Joris Baum wrote:
>
> Hi Neil,
>
>
>
> On 14.03.23 05:37, Neil Jenkins wrote:
>>
>> Looking at this, I think you could probably make this an 
>> informational document with how to implement Minimum JMAP, such that 
>> it's actually still compliant with RFC8620, rather than being 
>> incompatible — just quite inefficient.
>
> yes. Thanks for your input!
>
> That is exactly what we want to achieve with the document. Our main 
> use case of this document is to give vendors that already have an 
> existing application clear guidance on how to implement a minimal JMAP 
> implementation for data portability. Vendors might be interested in 
> that, because they need to comply with new EU regulation such as the 
> Digital Markets Act. Article 6 of the DMA states that some vendors are 
> required to provide "/continuous and real-time access to"/ user data.
>
> Once vendors have decided to implement such a minimal version of JMAP 
> they could then choose to support more features that are defined in 
> JMAP Core standard.
>
>> For example, if you set your |maxCallsInRequest| capability to |1| 
>> (and implement the correct error response if the client tries to send 
>> more), you have trivially turned off batching, but are still 
>> technically compliant with the original RFC. I think you can do 
>> something like this for just about all of the features (e.g. 
>> |/changes| always just returns a |cannotCalculateChanges| error; it's 
>> compliant with the spec, and now you don't have to implement it).
>>
>> I think this would be simpler and cleaner than essentially forking 
>> JMAP to create something almost-but-not-quite the same, which is 
>> likely to cause confusion and incompatibility issues.
>
> That sounds like a good idea. The important thing here is that the 
> document will show that it is relatively straight forward to implement 
> such a minimal version of JMAP. I will need to look in further detail 
> how this could be achieved. My gut feeling is that we might need more 
> than what is already defined in JMAP Core to reduce implementation 
> effort.
>
> TODO
>
> /set
>
> * "maxObjectsInSet" - no support for /set
>
> * stateMismatch - no support for ifInState (dirty, because it signals 
> an issue on the client side)
>
> * SetError - no support for create, update, destory (via description. 
> Not machine readable)
>
> /query
>
> * anchorNotFound - no support for anchor (dirty, because it signals an 
> issue on the client side)
>
> * unsupportedSort - no support for sort
>
> * unsupportedFilter - no support for filter
>
>
>>
>> Cheers,
>> Neil.
>>
>> _______________________________________________
>> Jmap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jmap
> -- 
> Joris Baum
> Tel: [phone]
> Fax: [phone]
>
> http://www.audriga.com  |http://www.twitter.com/audriga
>
> --------------------------------------------------------------------------
> audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe
> Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
> Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
> --------------------------------------------------------------------------

-- 
Joris Baum
Tel: [phone]
Fax: [phone]

http://www.audriga.com  |http://www.twitter.com/audriga

--------------------------------------------------------------------------
audriga GmbH | Alter Schlachthof 57 | 76137 Karlsruhe
Sitz der Gesellschaft: Karlsruhe - Amtsgericht Mannheim - HRB 713034
Geschäftsführer: Dr. Frank Dengler, Dr.-Ing. Hans-Jörg Happel
--------------------------------------------------------------------------