Re: [Jmap] JMAP for Migration and Data Portability

[nelkins alan <[e-mail]>]

Got it.


Sent from Yahoo Mail for iPhone


On Tuesday, March 21, 2023, 10:44, Joris Baum <[e-mail]> wrote:

 
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:
  
 


#yiv3048488330 p.yiv3048488330MsoNormal, #yiv3048488330 p.yiv3048488330MsoNoSpacing{margin:0;}
  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
-------------------------------------------------------------------------- _______________________________________________
Jmap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jmap