Hi Bron,
thanks for the thorough replies! I think the clarifications cover
all of my comments.
I find the lookup part very interesting as it is also a common
pattern in other areas like IoT resource discovery in CoAP. While
I am not an expert in JMAP and am unsure about the specifics of
the metadata or structure, my understanding is that linking (not
nesting) would be used when an email contains a reference to
another email, mailboxID being in URI format. It will be
interesting to see how links and their metadata are discovered and
navigated.
As for the ARTART review last call, I believe it is ready from my
pov. I have not been following the JMAP mailing list, but if there
is another review in a future draft version, I would be willing to
do it.
Ciao!
Jaime
On 4.1.2023 8.22, Bron Gondwana wrote:
On Wed, Dec 14, 2022, at 20:45, Jaime Jimenez via Datatracker wrote:
Reviewer: Jaime Jimenez
Review 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 be
of type "application/octet-stream". - I am not too familiar with JMAP but to my
understanding for any HTTP API you would need the URL for the resource path to
be well-defined. I assume that the definition of how the request URL is
constructed is out of the scope of this document and left to API
implementations or defined in RFC8620. Similarly how responses like
"notCreated" are carried over HTTP (e.g., 500 Error or similar) are to be
defined elsewhere, right? If they are defined on that RFC or elsewhere, it
might be good to add a reference in the document. If I am completely off, I
apologize 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 is
that the blob itself seems to carry CRUD operations but I only saw examples of
create 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 server
to remove them over time and on which basis as the draft does not seem to
mention that. For example after a "blob lifetime", based on memory usage or
other.
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 currently
stating: "The definition of reference is somewhat loosely defined, but roughly
means "you could discover this blobId by looking inside this object"". I think
that might not be clear enough for a developer implementing this but I leave it
to 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 (which
might be mistaken) is that standards should not be coloquial, so maybe I would
expand 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.
-- Jaime Jiménez
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
