On Wed, Dec 14, 2022, at 20:45, Jaime Jimenez via Datatracker wrote:
Reviewer: Jaime JimenezReview result: Ready with Nits
Hi Jaime, thanks for your review and apologies for the delay in replying through this holiday time.
In my opinion this draft is ready to be published. I found some nits and
comments that the authors may take into consideration.
I will reply to each inline.
- Somewhere in the draft I would expect an indication that the request MUST beof type "application/octet-stream". - I am not too familiar with JMAP but to myunderstanding for any HTTP API you would need the URL for the resource path tobe well-defined. I assume that the definition of how the request URL isconstructed is out of the scope of this document and left to APIimplementations or defined in RFC8620. Similarly how responses like"notCreated" are carried over HTTP (e.g., 500 Error or similar) are to bedefined elsewhere, right? If they are defined on that RFC or elsewhere, itmight be good to add a reference in the document. If I am completely off, Iapologize cause I do not know the insides of JMAP well.
Yes, the definition of how all the methods are carried is entirely within RFC8620. You can't really read this document without having understood RFC8620, or implement it without an existing RFC8620 implementation, so re-describing all that would be redundant, You would hook the additional method handlers into your existing Blob/ datatype handler that you had already implemented Blob/copy inside of, but instead of copying from another account you would create a blob the new datasources described by this document.
The newly created blob would go into the same pool of unassigned blob data that the JMAP upload endpoint defined in RFC8620 creates blobs into, with the same expiry semantics.
- Another comment isthat the blob itself seems to carry CRUD operations but I only saw examples ofcreate or "Blob/upload" and read or "Blob/get". The draft indicates that blobs"can't be updated or deleted" so I am wondering then if it is up to the serverto remove them over time and on which basis as the draft does not seem tomention that. For example after a "blob lifetime", based on memory usage orother.
As above, this is covered in RFC8620 section 6: https://www.rfc-editor.org/rfc/rfc8620#section-6
A blob that is not referenced by a JMAP object (e.g., as a message
attachment) MAY be deleted by the server to free up resources.
Uploads (see below) are initially unreferenced blobs. To ensure
interoperability:
o The server SHOULD use a separate quota for unreferenced blobs to
the account's usual quota. In the case of shared accounts, this
quota SHOULD be separate per user.
o This quota SHOULD be at least the maximum total size that a single
object can reference on this server. For example, if supporting
JMAP Mail, this should be at least the maximum total attachments
size for a message.
o When an upload would take the user over quota, the server MUST
delete unreferenced blobs in date order, oldest first, until there
is room for the new blob.
o Except where quota restrictions force early deletion, an
unreferenced blob MUST NOT be deleted for at least 1 hour from the
time of upload; if reuploaded, the same blobId MAY be returned,
but this SHOULD reset the expiry time.
o A blob MUST NOT be deleted during the method call that removed the
last reference, so that a client can issue a create and a destroy
that both reference the blob within the same method call.
I have added some text to say that the created blob has the same lifetime and expiry semantics.
- The Lookup operation might be underspecified IMO, as it is currentlystating: "The definition of reference is somewhat loosely defined, but roughlymeans "you could discover this blobId by looking inside this object"". I thinkthat might not be clear enough for a developer implementing this but I leave itto the group/authors to decide.
It's kind of deliberately underspecified, to allow for future extensions to make sense.
I've clarified the text a bit. If you are asking about threads, a thread returns an emailId - and if the blob is referenced by one of the emails, then the Thread references the Blob.
BUT - if you fetch an email, it can contain a set of mailboxIds, and if you then looked at all the OTHER emails inside each of those mailboxes, and they contained the blob, then it wouldn't mean that this email contained the blob... so you'd need to either have a hierarchy of "contains" vs "references" which JMAP doesn't explicitly define (but mostly I would expect developers to know), or you'd need some kind of non-re-entrant rule, where you can look inside referenced objects but not recuse back to the same object type again - so if it's an email then if you find other emails by recursing then you stop. Tricky. But for a filesystem maybe you would want to recurse into directories.
Hence leaving it a bit loose. But if the group think it needs to be tighter, I could try to come up with a hierarchy for existing object types and require that any future extension also define the blob containing rules for it.
Actually that's a nasty little question - does a Mailbox contain an Email if it has children mailboxes and one of THEM contains the Email. I didn't define that clearly. Damn. I'll write a separate email to the list about this.
Edits-nits:The document contains apostrophes (can't, don't...). My understanding (whichmight be mistaken) is that standards should not be coloquial, so maybe I wouldexpand those.
Fair enough, whether it's a MUSTN'T or a SHOULDN'T, I've fixed all the ones in the standard text itself. I've left contractions in the changelog, which will be removed before publishing.
Cheers,
Bron.
--
Bron Gondwana, CEO, Fastmail Pty Ltd
brong@xxxxxxxxxxxxxxxx
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
