Session Date/Time: 17 Mar 2026 01:00
Bron Gondwana: Welcome everybody to the JMAP/CALEXT, or maybe CALEXT/JMAP session. We're starting with CALEXT and then moving on to JMAP. I am sitting here in this room with millions of people crammed into a huge space. Thank you for joining us at random hours, remote people. My co-chair Jim is joining us remotely and is going to take notes for us, and we are starting right here with the Note Well. As I said to some people during the dispatch session, if you are here all week, if you read one word in each session, by the end of the week, you will know the whole thing. But maybe read the whole thing now and then you don't have to read anything afterwards, including drafts.
All right. Meeting tips are the same as usual. If you are not speaking, please don't hop on. Hopefully, Meetecho is working well now, so you don't have to join your audio just to be able to hear. But when you are speaking, please turn on video if you're comfortable with it, turn on your audio, and we'll all be happy. These sessions tend to run fairly casually, but we do have the queueing system, and it's handy to use that just to keep track of who wants to speak.
All right. We'll skip over the resources. You can find them pretty easily, you probably already have. This is our rough agenda. We've done the introduction and Note Well. If there's anything you want to change on the agenda, now's a good time to do some agenda bashing. Pop your hand up if you want to. We're going to do CALEXT first, then JMAP, any other business, and review our milestones at the end. We have two hours. I don't think we have two hours' worth of material, so it's quite possible we'll finish early, or we will have lots of debates. You never know till you try.
All right. And this is the rough area. In CALEXT, we're going to discuss all the various JScalendar and JSContact bits. JSContact Cryptographic Key, if Philippe is here—I'm not sure if he is, and he hasn't specifically asked to speak, but I've stuck it in the queue just in case he wants to—and Rick has a proposed vCard 4.0-bis. There was also that email that came to the list a little while back about canonical vCard, and I thought if we want to discuss that, we can discuss that, but we might save it till the end, depending how people feel.
And then for JMAP, we have the JMAP Calendars work, which is kind of stalled at the moment, but we thought we should have a bit of discussion about how this all fits together, wherever we do that, whether it's in the JMAP section or in the CALEXT section, I don't really mind. We have a bunch of different drafts from Mario, including a proposal for CBOR in JMAP. And then we have my filenode stuff, and there's a bunch of expired work that I don't know if anyone wants to bring up, but maybe, Alexey, this is finally the time that S/MIME sender gets some love? Who knows. It could happen. You've got about an hour.
All right. I've been told that "logo" is not the word, it's a "protocol badge." Lawyers get very upset when you say "logo," and I said something along the lines of, "We'll call it whatever the hell we like, and they can be mad." But it's a protocol badge. We have designers working on it, and then we'll get to the any other business. Would anybody like to bash any of this agenda before we move on?
Ben: This agenda sucks.
Bron Gondwana: We know that. Bashing done. All right, thank you very much. In that case, Robert, I think you are up first in the CALEXT.
Robert Stepanek: Hello, good morning everyone. Hello, can you hear me?
Bron Gondwana: Yes, yes, we hear you.
Robert Stepanek: Okay, perfect. Good morning. Let me request slides. Slides: calext-jscalendar-jscontact How do I approve that? Pass slides control, yes. All right, cool. Yeah, so I'm just going to give a short overview over the progress with the JScalendar and JSContact drafts I'm involved with.
So for the JScalendar drafts, which are JScalendar-bis and JScalendar-icalendar, and the one you don't see on this slide is a third document that updates iCalendar for JScalendar. They... there were only minor changes. We had started Last Call in between the last session and this session. All that happened for JScalendar was that we aligned it with the definitions of RFC 9553, so the JSContact definitions. And for the other two documents, JScalendar-icalendar and the iCalendar extensions draft, there have been only minor tweaks, mostly about making the IANA sections complete and other similar, more administrative tasks so to say.
For the JSContact side, we have two documents that are basically waiting for approval. The one is JSContact-profiles. This one we... for that one, we had received quite extensive feedback in the IESG Last Call review. And we think the feedback substantially improved the document. We have incorporated all of that feedback. The issue we have with that one is that it seems to be stuck in AD-review after Last Call. It hasn't basically progressed from there since November last year. So it would be great to understand what we can do to push this forward from this stage.
Bron Gondwana: So Robert, we... I had a chat with the Area Directors during the hackathon this weekend, and that document is now unblocked.
Robert Stepanek: Okay, that's great to hear. Thank you very much. And for JSContact UID, this is basically done. I think I'm... let me... I haven't checked yet if we are in Auth48 already. If we are not, I would expect that very soon. And way more early in the publication stage is RFC 9553-bis, that I've just asked for adoption by the working group. This is doing for the JSContact vCard conversion what already is defined for the JScalendar iCalendar conversion document, so to align these documents as well in terms of their definitions, layout, and how they use extension properties to preserve one format in the other. This should make it simpler for implementations who intend to implement both iCalendar and JScalendar conversion, as well as vCard and JSContact conversion.
So the next steps are for the JScalendar-related documents. I expect to submit them to IESG before the next IETF session in July. For JSContact-profiles and UID, as I said, we think these are basically done, and we'd be happy to get them into Auth48 and then published as soon as possible. For RFC 9553-bis, it's... I'm not sure, I think it did not get adopted formally yet, so we are waiting for that.
Bron Gondwana: No, I just emailed Daniel about that right now. The call for adoption expired yesterday/today, so it's basically just ready for adoption and there were no objections. So it should be adopted hopefully tomorrow.
Robert Stepanek: All right, that's great to hear. I expect this document to go rather quickly. As you said, you never know, but if all goes well, we might already start Working Group Last Call before the July session. And that's it from my presentation, unless there are any questions.
Bron Gondwana: All right, thanks Robert. Let's check the queue. I don't see a list of people. That was super fast. It looks like everything's progressing nicely there. All right, back to the chair slides, I guess, and let's see what's next. Slides: chair-slides It's a pity you can't just leave these in the background to switch to. All right. Cryptographic Key, we don't have the author present, so I think nothing's going to happen with that. So let's move on to vCard 4.0-bis, Rick. Slides: vcard-4.0-bis-proposal
Rick: Hello. Hello, good morning I guess. Good, sounds like maybe you can hear me if I'm getting a hello back.
Bron Gondwana: You're very soft.
Rick: Okay, let's see. This is this weird microphone I have which likes me to talk for a while before it starts becoming audible. But if it doesn't get any better, I'll just talk loud. Let's see, a button here, microphone. No, okay, I'll just talk louder. How's that?
Bron Gondwana: Good.
Rick: Okay, slides, there's a button for that. This one. It's going to be quick. So, there is an RFC for vCard 4.0. It's a good 15 years old now. It is the latest and greatest in vCard technology until it has totally been replaced by JSContact. It is also an errata-rich environment. It's got 33 reported errata. 14 of those are verified. There's a bunch still left open, and some of them are marked as held for document update, although I think some of them are a bit more serious than just typographical. There's a bunch of errors, and some of these are pretty complicated problems. The most fiddly ones are probably around commas and semicolons. I feel almost ridiculous talking about the amount of complexity there is in commas, semicolons, their escaping, and their placement in different data types, but it has led to a whole lot of confusion both in what the spec is trying to say and in how to cope with the behaviors of clients of people who didn't come to the same conclusions about what the spec was trying to say as I did.
I think that it's reached a point where we need to take this document and actually apply the errata and issue something that has put them all in place, especially because when you look at these, sometimes the errata seem to be in tension, or at least not extremely clear how they work together. There's also a specific and I would say more difficult problem around the realm of UIDs. UIDs in version 3 are defined as being a text type, and in version 4 as primarily being a URI type. And one of the purposes of UIDs is to become the membership indicator for a group. The member property is defined only as a URI, which means the upgrade story from version 3 to version 4 is really fraught if you want to take a version 3 card, bring it into version 4, and make it part of a group. There's not really a story on how to do that. And so rather than take this back to the drawing board and people said we need to fix this right now and put that fix into practice, over the past 15 years there've been a number of different practices people have put into use. They are often similar but they are not the same, they are not entirely intracommunicable, they often have a big area of overlap and at the edges they get all crazy. And I would really like to clarify this because the people who are working in version 4 space, who are actually trying to use the modern standards, are much, much more confused than people who just decide to work in a proprietary standard.
Version 4 is much less broadly used than version 3, which is a bummer. Google and Apple, when they are offering an external interface to their data, or data they store, present that in vCard 3. People who are working in vCard 4, that means they tend to be working with smaller audiences, less interoperation, and they're not being forced to sort of encounter the problems. And as a provider who's dealing with a lot of different clients, we get to be the people who see this weird interoperation, we want to fix that. The other problem is JSContact is defined with a pretty extensive set of rules and explanations of how it converts to and from vCard. But because vCard 3 is obsolete, that's defined entirely in terms of vCard 4, which means if we're going to make anything clear to try and make moving forward on vCard representation useful, it has to be done on top of version 4, which means version 4 needs to be cleaned up and polished and made coherent as something we can build on.
That's kind of the whole thing. I think that I'd like to get this adopted as something the working group wants to work on. The plan's real simple: we're going to reformat the document to a modern format, apply the errata that are very straightforward, have a little errata queue, work our way through it, get them applied, get consensus on those, put in some language to clarify what can be done with UID and membership, and that's kind of it. Stick to a minimal restatement of terms, clarification, and making the whole thing coherent.
Bron Gondwana: All right, thanks Rick. This is entirely within our charter. The first thing the charter says is it lists the standards we deal with, one of which is vCard, and it says as the very first item: the working group will maintain existing standards and proposed standards, processing errata and refreshing them as required. So, I'd say it's a slam dunk to say this belongs in this group and we don't have that much on the go, so it seems appropriate to adopt. Ken.
Ken: This is Ken. I wholly support this effort, as someone who has had to code the various heuristics with the UID mess. I would like to get vCard 4 straightened out so that the big vendors stop adding more crap to vCard 3 which kind of emulates vCard 4 but somewhat differently. I'd also be willing to help with writing the draft or whatever needs to be done.
Bron Gondwana: All right. Anyone else? I see a thumbs up from Alexey.
Orie: Hey, Orie Steele, as an individual. I just wanted to ask about the convert to XML piece of this. I mean, I probably you guys have more information on or understanding around why the XML piece is there, but just sort of wondering. You said modern formats, so I'm just wondering, you know, what what the XML piece is.
Bron Gondwana: My guess is XML RFC, but Rick can answer that too.
Rick: Correct, yes.
Orie: Ah, okay, yes. Now I understand, thanks. Maybe try Markdown.
Rick: Yeah, I mean, I think that it will almost certainly be in Markdown in the repository, but I want to get it into... I want to be able to submit it to IETF in XML, which means taking the whole thing and formatting it into something else. I sure as hell don't want to work in Markdown in my... in my editor from the start. Or sorry, XML.
Bron Gondwana: That bit confused me when I first read this slide as well, I was like, oh yeah, I know what he means.
Rick: Robert advised me to drop it, and I said I knew better, so now we know who knows better.
Ken: Will the lawyers make us rename the logo property? Because they like badge, not logo, when they're talking about protocol badges.
Bron Gondwana: All right. Cool. Do you have a... I guess we can do a call for adoption for doing the work without a draft, or we could prepare a draft first and then call for adoption on that. I don't particularly care either way. Anyone?
Rick: Can I run through the mic?
Bron Gondwana: Yeah, please.
Rick: I think you convinced me that the work needs to be done by the just number of errata. So, yeah. The document already exists, it's just, you know, a mechanical work of actually doing something with it, so I think that's fine.
Bron Gondwana: Do the right thing. All right. Cool, thank you. Let me pull back up the chair slides and see what's next. I believe we are getting towards the end of the stuff that was on the agenda for CALEXT. Yeah, so the only other thing was the discussion thing of canonical vCard. This is the having a URL that you can say, "Go here to get the latest version of this card." And go. Where's the queue of people with opinions on this? We would all love to have this, right? But I think someone would need to actually do the work of defining the property and and how it... how you can tell it's the legitimate one and all the security considerations around it. All right, I don't see a huge upwelling of people who want to do this right now, so I think this remains in our ideas queue.
And with that, I guess let's move on to JMAP. Now, Mario said he probably wouldn't actually be here until 45 minutes or so into the session, because that's when we were going to get started with JMAP. But so for JMAP Calendars, that one is kind of paused. It got pulled back out of the queue, Neil.
Neil Jenkins: Hi. Uh, yes. I... it's basically done. We're waiting on two things. One is the JScalendar-bis draft to be finished, which Robert gave a brief update on before, and it is that is basically done. So once that's in the queue, it will go out together with JMAP Calendars, they'll be published together. And then just we want to make sure we've got some more implementation experience of the final JMAP Calendars draft before we say yes, this is definitely it. That I think should happen before the next IETF because we're... I'm very much hoping we should have that done at Fastmail, and I think Stalwart have also got an implementation of a pretty recent draft, we'll make sure that's up to date as well, check that that all seems to work as we expect. Probably do a very brief Last Call again in the group just if there'd been any changes from what was proved before. And then I think based on the discussion with editors and stuff in the past, it will... doesn't have to go through the whole approval and review process again because there's minor changes from what was approved by the IESG and stuff before. But we'll sort that out at that point. But yeah, it's very close, mostly just waiting on implementation experience, and I hope that's all finished before the next meeting.
Bron Gondwana: All right, thanks Neil. Well, I guess if we're still waiting for Mario, then maybe I should do my section next. The filenode/blobext? Oh, that JMAP question about what goes with JMAP Calendars, he didn't hear that part. Oh, that JMAP Calendars was getting... was quite a long way through the editor process when we realized that it needed to wait for the new JScalendar format. So it has been kind of dumped back into Purgatory in a weird state in the datatracker until he's not even paying attention... until the format is now... is up to date and we can reference the new format. So it's just on pause basically until the next IETF. All right, filenode. Slides: filenode-blobext
Are my slides not in here? What kind of useless... that's ridiculous. Hang on a second. It's like I don't even know how to do my own job here. I DO have slides. I just need to download them and upload them and refresh. Downloaded. Uploaded. Refreshing. And I believe this refreshes itself automatically now. No. Yes. There it is. I don't want to speak on microphone. All right, here we go. Sorry about that.
So, this is two drafts: draft-ietf-jmap-filenode, one of which is adopted by the working group and has been sitting idle for a long time waiting implementation experience, the other is something that I came up with once I started implementing. Somewhere about a month ago, I got my hands on a Claude subscription and started developing a Windows file client based on the JMAP filenode API. I've now converted that to a Mac file client as well, though I'm stuck in Purgatory with Apple Developer because I have an Australian passport and a US address and so I can't get a developer ID, which means I can't build the Mac client yet. But we'll figure that one out.
Right. Anyway, in implementing I discovered a bunch of stuff that needed to be added to it and some interesting issues where Claude said, "No, you're wrong, the spec says this," and I was like, "Oh yeah, I guess I'd better fix the spec." Anyway, this has been sitting around. It's now usable, hopefully. I discovered that I needed to add a role for top-level nodes so that you could find where your home directory is and find where the trash is reliably, so I added a role property to match other JMAP things. Added viewOnWeb URLs because that's a thing that some of the systems that exist now offer. Added onExists handling so that you can reliably replace a file even when you're fighting against other changes on the server and just say, "Let mine win," rather than having to round-trip an arbitrary number of times.
And there's probably the biggest discussion point that I want to talk to the group about is that the Fastmail Storage Node API that this is based on has an immutable blobId, size, and type for a node. Once you create a file, the content is fixed, and so if you replace it with new content, it gets a new inode-type concept, which worked fine there but it makes it less POSIX-like in some ways. And I mean, it's fine, you just throw away the old one and replace with a new one, but the question is whether we want to allow you to edit those properties on an existing file or not, whether you should be able to change its content.
Mickey: "Round-trip" repeats? It makes it less POSIX-like?
Bron Gondwana: Yes, so more like POSIX. Yeah. For roles, I defined four roles in the draft so far: root, home, temp, and trash. The question: do we need to create a registry of filenode roles? Are there any other roles that people think we should create as kind of bases of trees in a file storage system? This is obviously per account, so if you have somebody else's files shared to you, you will see their home or their root node in their account separately. Ben.
Ben: Pictures comes to mind, because many people upload their pictures to file storage.
Bron Gondwana: Okay, so a pictures role. All right, Jim, have you caught that?
Jim: Got it, yes. Thank you.
Bron Gondwana: Thank you. All right. For onExists, I created the onExists property in FileNode/set, a top-level option which is either reject, which is the default, or you can say replace, which will delete the old node if it already exists with that name, or rename gives this node a new name on creation, so the server will give it a new name. JMAP already supports returning any changed properties in a set response, so you will get the new name back as part of the response if you requested this. And then there's onDestroyRemoveChildren. So if you replace a directory, you need to decide whether you destroy everything underneath it or whether it rejects with a containsChildren error, which you'll get if you don't explicitly say that destroying children's okay. Yeah, I know. [Coughing].
All right. The immutable blobId, size, and type. With emails, you can't change the content of an email without changing its email ID. With calendar and contacts, you can change things, you can update the existing ID and change properties on it. So yes, it's just shoving the lump around under the carpet, but I guess the question here is what do people think, should we relax that restriction? We can change the data model at Fastmail. Mickey.
Mickey: What was the motivation of making it immutable, the size for instance? If you have a document, it makes a lot of sense to be able to go in and change it and...
Bron Gondwana: You can certainly change the item with the name, it's just whether the node ID changes or not.
Mickey: Yeah, I understand. But for a... if you look at it human-centrically, a document is something that evolves over time. And I don't know what the blobId is used for internally.
Bron Gondwana: blobId is always a reference to an exact set of bytes, so that property will change whenever the content changes, but the question is whether the FileNode ID also needs to change. And I could see it either way. When I first designed the Fastmail file system 21 years ago, I'd just come from doing clinical trial data management where exact versions of everything were very much a thing, so it was like if the content changes, the ID changes. But I'm happy with either option, I think.
Mickey: Yeah, I could see a case for having the size being able to change, maybe type, I don't know. And also for the roles, maybe look at what the X Desktop group has, like documents and pictures and all of that. Yeah. Thanks.
Bron Gondwana: Yeah, cool, thanks. The other thing with the our existing data model that's nice about this is that if you replace a file, the old node still exists with an isDeleted flag on it, which allows us to give you an undo history because there's a different node ID history for that name, which is something you would lose if you allowed the same node to be changed. However, if you were mapping this directly over POSIX, then... Neil.
Neil Jenkins: I would say I prefer the POSIX model where I can update it without changing the inode. I think that'd be easier from a client point of view, and also in terms of your undo history, there's other ways obviously of tracking that, and actually linking it all to a single ID would help because then even if you move the file around or, you know, rename it, it's still the same file and you can get the undo history through that too, so I think it's probably even better if you do it that way.
Bron Gondwana: That is a very persuasive argument. Thank you. Ben.
Ben: I agree. I feel quite strongly that files should be writable. To add to this, let's say I'm sharing a file, I have probably like a URL attached to it, I have permissions attached to it, all that would need to move every time I change it. And but the killer for me is like in your examples you had home as a role. Let's say I really want to use, and I think you implemented that even as a file system on Windows if I understood this correctly, let's say I'm really mounting this as my home drive and there is an SQLite database with 500 megabytes, and SQLite is going to do fsync on it all the time. And then every time I have to upload 500 megabytes over my... over my DSL line and I have to make two HTTP calls: one to make to create the blob and then one to change the inode? That's two HTTP calls, two round trips, and not even talking about the amount of bits that I have to move. So I really think it should be a really cheap action to have a random write anywhere in the... within the file. And I would even go as far as that I want to have notifications when the file updates, like you... like it's common like the editor knows when the file has changed underneath and I get a notification and all this kind of stuff, I would like to have.
Bron Gondwana: Well, funny you should mention that. We're moving on to the blob stuff very shortly. All right. So I think I buy the argument that we should allow you to change the blobId, change the size, and obviously change the mime type as well in that case of a file by the same FileNode ID, so I will update the spec and update the Fastmail server to support that somehow, which might be fun. That data model is very ancient and it's too clever for its own good. Anyway, Blobext.
So, Blobext is an extension to the Blob extension which was an extension to the very basic blobs that are in JMAP core. In JMAP core you can only upload the entire blob as a single item and download it as a single item. Blobext adds even more to it. Blob/upload allowed you to create a blob by joining together individual components, so you could define a recipe that said this range of bytes, then this range of bytes, all appended together. And that allows you to do writes to just a small part of a file. If you want to do an arbitrary write, what you say is, "Copy everything up to the start and then add this little component and then copy more," and you can do that with base64 so you don't need to upload if it's just a few bytes in the middle of the file. The other thing that Blobext adds is a chunk size, and that says if you upload something exactly on the boundaries of this, the server will be able to very efficiently make this change in place. So, it's basically the same way that hard disks can say, "This is my underlying geometry. If you write in blocks of this size, it will be very efficient for me to handle." And that's all that chunk size does. It says if you write on these boundaries then I can handle it efficiently. It doesn't force you to do anything. My Windows client does all this stuff already, it works by uploading chunks in the size the server already expects, and the server has already calculated the SHA-1 of those, and so it can give a digest match against what's there and you can download and upload those chunks very efficiently. So that's there. Resumable upload URL, I'm not so sure about, whether we need it or not, but it's just another per-account URL because JMAP only has a central URL, so having one per account means that you're definitely uploading into the correct account in the first place, which I think's pretty valuable.
RDIF is a whole question of whether we're going to support it and how we're going to define it, because there's no RFC already for it, it's a format that's only defined in its implementation. And the final thing I added just recently was a noPersist hint. So it allows you... you can create a .tar.gz file with calls through this, and if you say noPersist, then it means you don't need to keep the tar file, you can do the whole thing just as a pipeline and return the blobId of the result.
All right. Blob/convert lets you resize images, which is very handy for thumbnails. My Windows client now uses that to create the thumbnails even when it hasn't downloaded all the big image files, and you can open a directory and it will just pre-fill the thumbnails very nicely. Recursive flag to archive, I worked on that during the hackathon a little bit, added a... something to FileNode that says... because this is Blobext and Blobext is only in the blob space, it doesn't know about files, but I added a FileNode wrapper that basically says, "Parse this tree, convert it into the Blobext archive recipe, and then have Blobext actually archive it."
All right. RDIF... I'd love to have RDIF, I think it'd be a very useful thing to have. I'm not sure how to go about defining it in the IETF because there's no spec that we can point to already. Whether we can just say it's this format, because RDIF DOES have a media type, and basically say we just handle this media type and the server knows what to do.
There was some debate on the list about the chunk size question, whether that's something that we should be advertising from the server. I think as a hint, that just saying the server likes chunks of this size is reasonable. I don't know whether you want to have multiple of them or not, the server accepts these chunks, or whether one is enough. But certainly one of the other nice things about Blobext—I uploaded the draft just on the weekend because most of the work I did was during the blackout period—but you can specify any field that's calculated by the server, and your request will be accepted only if that field matches what the server calculates. So you can upload a blob and you can say, "I think it will have this digest," and then the server will calculate the digest and check, because that's one of the properties that it would return if you did a get against it. And the spec actually specifically says that: you can say, "Build this file out of this recipe and the digest has to match at the end."
All right. As I said, I don't know if resumable upload is needed, but I think it's a useful thing to have an upload URL in each account rather than just one for the whole server. I did a nice little picture with color-coded items of what the chunks in Blob/get and Blob/upload have. The orange up the top is the source blob that you're copying from, and you have an offset and a length within it which is the bit that you're going to copy, and then you have a position which is where in the output this is supposed to write. You don't need to specify that, but if you do, it has to match where it's going to be placed. And you have the length which is how much is actually getting copied. Oh yeah, and the size is the size of the blob source, which again you do or don't have to specify, and the digest is just this bit that you're copying. I thought it was nice to have a picture to describe it all. The text also describes all this as well. And then noPersist just says, "I'm never going to use this blobId so don't send it back to me," and if you're not sending it back, then you don't need to store it.
There's a question of whether we needed to add quotas to this. When you upload a blob at the moment, RFC 8620 says it may disappear at any point later, and you can't guarantee that it will be around later, but you can use it for a bit. It's very non-specific about it. Certainly on our server, we set an expiry time on nodes and they won't be deleted until that expiry time. You could theoretically tell the client it'll be around until now. Whether that's worth adding to the the blob type or not, I think's something that's worth debating. And whether we want to have some kind of a maximum number of items in your file storage as well as just a disk usage, particularly because directories cost nothing theoretically in the current data model.
So these are these are kind of the open things there. I'm going to do ask for a call for adoption for Blobext because it's not adopted yet, and I think it's an important part of the complete recipe for a file storage system on JMAP. I think that's all I have for slides. Yep. And I'd love to see more implementations of course. The Fastmail server now, you can OAuth against it requesting the scope for files and you can access your Fastmail files with it. All right, that's all the slides I have. Ken.
Ken: This is Ken. This all seems useful stuff to me. The couple things that popped into my head as you were going through the presentation: why would we need a separate URL for resumable upload? Why can't the server just say, "I support resumable uploads," and just use the regular URL?
Bron Gondwana: I think the main thing was that different accounts might have different abilities to handle stuff as they come in, and at the moment the JMAP upload URL is per server not per account.
Ken: Okay, fair enough. The other thing that popped into my head was Blob/convert. I remember IMAP CONVERT from way back, which I don't think anybody ever uses, so I'm curious why would somebody want to use this on the JMAP side if it was never used for the IMAP side?
Bron Gondwana: So for JMAP files specifically, thumbnail is a very common thing that people want to be able to get a thumbnail. The Storage Node API within Fastmail does that, it has a specific thumbnailing capability. This one's a slightly more general one that allows you to say, "I want this blob to get converted to this mime type with these hints for the converter."
Ken: Fair enough. Yeah, I'm... I'm a server guy, so I'll defer to the client people. If they want it, they want it, and we'll take care of it.
Bron Gondwana: Yeah. One of the interesting things about it, and I should add some more text to the draft, is that there's two ways to do this. You could... the server can calculate that new value straight away and give you back a blob that you can keep referring to for a week or however long and then it disappears. The other way is the server can generate a synthetic blobId which is basically this source blobId and these transformations, and then you can generate that cache it, throw it away, regenerate it again from the same. And in theory, you could invent that blobId yourself if you knew exactly what the server's pattern is, but the server can just immediately return with, "If you want this, here's the blob to fetch and I will generate it lazily later." Ben.
Ben: I very much like the thumbnail feature as client. Most people who want to show this in any GUI will want to show thumbnails, and it's something that the client can't do on its own. A question about the resumable uploads URL and so on. Have you considered using more HTTP semantics? I mean that I'm just writing to this URL and I'm in the headers, I'm saying actually what I'm sending you is starting with byte zone so up to byte zone, so the length, which is very similar I think what you mentioned in one of your slides, but you could do that in both directions. I could either upload with these bytes or I can fetch those bytes, and you can define how the headers look like, but basically I would just take a byte range and then I have a normal get and post apart from that.
Bron Gondwana: Yeah, I think probably what this would look like would be a URL that you could do a range write to for the FileNode, and that would make the modifications to the underlying blob structure and then the node would be updated next time you fetched it would have a different blobId and that would be that new content. That... I could see that working, and that that seems like a reasonable thing to do is to create a URL which is a... an "edit this FileNode" URL. There's already a URL that has the node in the URL schema, so you'd just do the same thing. Ken.
Ken: My assumption when I saw resumable upload URL was that you were going to follow the spec that's in the HTTP working group, which I think is close to completion.
Bron Gondwana: Yes, that was... that references that spec.
Ken: Okay, let's... let's not reinvent the wheel here.
Bron Gondwana: Yeah, it's just whether we allow you to patch... have a PATCH URL for a filenode that allows you to patch the binary. Yeah. All right. Anyway, I think Ben's suggestion there might be able to be mapped in a sensible way, and I think it would be... as a client, I can see why that would be useful. All right, anything else from anyone on this? Any feedback, any comments? Sounds like I've got a few things to go with already. Thank you. All right, Mario, you are up.
Mario Loffredo: Hello. Hello. Can you hear me?
Bron Gondwana: Yes.
Mario Loffredo: I do not have any slides prepared because the... currently I'm waiting for feedback from the group. So I'm working on three different drafts: the JMAP Mail Sharing (draft-ietf-jmap-mail-sharing), the JMAP Object Metadata (draft-ietf-jmap-metadata), and also the JMAP Enhanced Result References (draft-ietf-jmap-refplus). So the last documents I uploaded included all the changes that the group suggested, Neil and you Bron, so I was, yeah, basically waiting for... for feedback or and then to know what are the next steps.
Bron Gondwana: All right. I think generally once all the feedback has been included, if people are interested in it, then we go to Working Group Last Call on documents if there's no outstanding feedback or design decisions that people want to discuss. Sorry, I don't remember off the top of my head exactly where we were with each of those. Do other people want to chime in on any of them? Neil.
Neil Jenkins: I'll reread the latest version to see if I've got any more feedback. But I was going to say the next step is probably to make sure we've got an implementation or ideally two, just so that we can check that it works as we hope it will.
Mario Loffredo: Okay. Yeah, the JMAP Mail Sharing draft is implemented in Stalwart. The capability is not announced but it's there. But what I want to know for example before starting to work on the other two, which are bigger, I wanted to make sure that they were not... yeah, that you're okay with... with the...
Neil Jenkins: Yeah, I'll have a look. From memory, the JMAP Mail Sharing one was straightforward, just this is obviously correct, let's just do that. The other two were more different. The Metadata one is still probably the weirdest one to a certain extent in terms of... you could do this lots of different ways. Yeah, okay, I'll have a look at the draft again.
Mario Loffredo: Okay, okay, great.
Bron Gondwana: Thanks Neil. I'm keen to look at how Metadata might interact with filenode as well, because there's certainly some interest from people in being able to have things there.
Mario Loffredo: Yeah, there are even examples for the metadata example... sorry, for the FileNode extension. For example for including photo metadata and so on, so if you look... if the group looks at these documents and they're no more big changes, I can start working on implementing them.
Bron Gondwana: All right. Well, that was nice and quick. Yeah. I think, yeah, hopefully the next... next steps for Mail Sharing seem to be for a couple of people to review it and then we'll do a Working Group Last Call for that fairly soon.
Mario Loffredo: Yeah, Mail Sharing is pretty simple, so I guess that will be the one that should be ready first.
Bron Gondwana: Yeah. And then maybe for Enhanced Result References, we should... we should try and push ahead with that one as well and get people to review it and see if they think it looks reasonable and implementable, and then it's just an extension so you don't have to do it if you don't want to, so we may as well as long as it's safe and doable, we should push that one ahead too.
Mario Loffredo: That's right, yeah. And also we had the... there were other extensions we were discussing like the server settings that we briefly discussed in Madrid. But yeah, that one we'll work on that once these three are, yeah, at Last Call or issued for this.
Bron Gondwana: Yeah. And then you talked about CBOR as well, for JMAP with CBOR on the list.
Mario Loffredo: Yeah, yeah, yes, and also using this shared dictionary for compression of JSON. You know, there is a new RFC, I forgot the number but I posted that on the Matrix, on the Modern Email, there is this RFC that was recently published for pre-sharing the dictionary for compression. So it was a very simple extension to create a dictionary with all the JMAP words and JSON keys used, so to compress the JSON faster. But that was just an idea, but that is something interesting to implement also.
Bron Gondwana: Yeah, that sounds great. I would be keen to have that as an option.
Mario Loffredo: Yeah, and those are the idea. Then I also propose, Neil, because I implemented the masked email. So yeah, those are other... other extensions that... well, I was not thinking about masked email as a separate extension but rather as part of the server setting extension. But once I have that ready and released, I will post it to the list.
Ken: Mario, quick question. I'm wondering can you explain what CBOR would get us over compressed JSON? Especially if you've got a specific dictionary for the compression scheme?
Mario Loffredo: Yeah, well those are like two competing ideas, so basically I would have to benchmark and compare which one is... see which one is faster because obviously if you do compressed JSON, you have the, well, first compressing, decompressing, and parsing, and in CBOR you're just will have to first create... I mean because there are two options to CBOR. First one is just using sending the keys, you know, the JSON dictionary keys as text, and the even faster option is creating a CBOR, yeah, mapping each JMAP word to an integer. That would be even faster for parsing. I know like nowadays JSON parsers with SIMD are really fast, but my guess is that using a binary protocol such as CBOR will be even faster. So for large payload, for example, you're requesting, I don't know, a hundred emails, sorry, yeah, a hundred emails but not obviously not the whole text, not the whole contents, but the headers for a hundred emails, it would be faster to do that over CBOR rather than JSON. Even though JSON is super fast for parsing in with modern parsers, I still think JSON will be... sorry, CBOR will be faster in those cases. But yeah, that is something experimental to try and see if it's really makes sense to implement.
Ken: Right. Yeah, that's my suggestion, if we get some kind of benchmarking to help us make the decision. Thank you.
Mario Loffredo: Yeah, sure, sure. Neil.
Neil Jenkins: Yeah, I was going to say something similar because I did try using CBOR instead of JSON many, many years ago now when we were first developing JMAP, and when I was benchmarking it, it didn't really make any benefit once you accounted for compression. But I was also doing this all in the browser, and I could see there's overheads there from the CBOR because the CBOR's not native whereas there's, you know, browser have built-in JSON parsers that probably add as much why there was so much overhead with the CBOR, so it could be in other environments it is a significant win. So certainly no objection philosophically to it, it maps very easily obviously to JMAP, it's just like JSON. But it is worth making sure it is going to make a real difference before we add yet another option, it's mostly what I wanted to say. Because just every option is the proliferation of extensions like we have with IMAP. The other other question was with this compression dictionary, is that meant for a specific compression algorithm or is that just you can use this with any compression algorithm? It's just specifying the dictionary.
Mario Loffredo: Well, I would have to read the draft in detail, but it's for the compression algorithm that supports pre-sharing a dictionary. I posted the link somewhere on the Matrix room, I will have to look at it again, but it was a very simple extension that we would include in the JMAP session object, the location of this dictionary. And that is something of course each server can build based on the extensions they support, they can pre-share the dictionary with the JSON keys fit for the server, right? Based on the extensions they support.
Neil Jenkins: I mean, again I guess I would just say it'd be nice to have some benchmarks to show the saving is worth having more complexity. I guess we again had a custom dictionary for our compression for many years, and I actually dropped it recently just because we it was you got more compatible tooling just from using, you know, the standard compression algorithm without custom dictionary, and the extra saving was not hugely worth it. But yeah, again it might maybe it is with some algorithms.
Mario Loffredo: Yeah, I believe it's the RFC that Ken posted to the chat, was recently 9842, yeah. Compression Dictionary Transport. I believe that's the one. But yeah, it's just something I was brainstorming, but it's something to investigate.
Neil Jenkins: Okay, cool. Yeah. All right.
Bron Gondwana: Thanks Mario. Anything else? Not from my side. All right, thank you. Let's go back to the chair slides. Slides: chair-slides Hey Bron, have we done anything with Email Delivery Push Notifications (draft-ietf-jmap-emailpush) yet? Did I miss it or did we skip it? I guess we missed adding it entirely, I don't see it on the agenda. How did I miss that? I don't know, I copied the agenda into a hedge doc and it was there. Okay, I must have missed adding it to the slides then.
Neil Jenkins: I can give a two-second update because it's basically exactly the same as last meeting, I'm afraid on this one, that I believe the spec is complete but no one's implemented yet, and so we should make sure that at least one, preferably two implementations, and it does what we think before we push it forward. So that's... I'm not sure from our end whether we will get to it in the next three months. I'm hoping so, we want to do JMAP Calendars first, but then this is high up my list after that. So yeah, that's the status.
Bron Gondwana: Is the document already adopted or is it...?
Neil Jenkins: That's a good question. I thought it was, but I actually don't know.
Bron Gondwana: Let's have a look at that. Email push IS adopted, it's a working group document. There you go. How did I miss that? I'm sorry. When do we think we'll be getting that ready to...?
Neil Jenkins: I mean, I'm hoping it's all done this year, but whether we'll have implementation by the next meeting to have confirmed that it works as we expect, I don't know.
Bron Gondwana: All right, I'm going to give it a milestone of October then. Mario says email push is implemented in Stalwart. Great! So we can test against that too. And Mario, is that matching the current spec? Not that it's changed for a while, but I assume so.
Mario Loffredo: Yeah, I mean it is implemented, but I was... it's not currently sending the payload, which is important stuff, right? The message contents. I was waiting if the if the extension is ready, if you think there are no more changes, I will add that. I was waiting to see if it's ready.
Neil Jenkins: I think so. Yeah, I'm not aware of any issues anyone's raised, and it all makes sense from what I can see, and I think it'll work well for the clients. But yeah, we do need to test round to end. So yeah, if you implement it as well, that'd be great.
Mario Loffredo: Yeah, I was going to because now I'm working on something else, but soon within the next few months I was thinking about creating a public Stalwart instance with Email Push and also PAC, you know, the Mail Main draft, yeah. So and also Object ID Plus (draft-ietf-jmap-refplus), so other client developers can use it as a to implement all these together. So yeah, we really want to see JMAP in popular mail clients, so I will create a public instance so clients can implement Object ID Plus, Email Push, and yeah, all together. So yeah, I was planning to finish the implementation as part of that effort.
Neil Jenkins: Sounds good. Yeah. Cool.
Bron Gondwana: All right. We have in the expired documents tasks, rest, portability, essential, and S/MIME sender. Alexey, what's the status for S/MIME sender?
Alexey: Yes. All right. Yeah, I was a bit snowed down there at various things at work. I added it to my calendar to review in early April, so I'll need to talk to Philippe, because I think that's where we ended up last time.
Bron Gondwana: All right, milestones has it for July this year already, so you still have time. All right, Robert, sorry, go ahead.
Robert Stepanek: I have a question regarding the expired tasks draft. The JScalendar-icalendar conversion doc has a dependency on that draft. The dependency is rather small, it basically requires two elements, and if that tasks keeps... stays expired, then I would prefer to define these properties in our iCalendar extension documents so that we can make use of them for the JScalendar iCalendar conversion. Sorry for the confusion again.
Bron Gondwana: So Tasks (draft-ietf-jmap-filenode) got up to 06 before it expired, and Hans-Joerg is one of the authors on it, so he appears to be in the meeting if you would like to speak to it. Go ahead.
Hans-Joerg: Hello, is my audio working?
Bron Gondwana: Yes, hear you loud and clear.
Hans-Joerg: All right, all right, so hello everybody together. Yeah, I promised to work a little bit on tasks, so this is still on my list, but I couldn't do it since last meeting, so unfortunately no major improvements here so far.
Bron Gondwana: All right. Do you know how much is left to do?
Hans-Joerg: Not even fully, because I think one of the main things I wanted to work on or that were still outstanding were the very specific tasky things like these checklist things and so on, but I to be... from the top of my head, I don't exactly know what how much of that is in the current version of the document. I need to check it out.
Bron Gondwana: All right. When do we think we'll be getting that ready to...
Hans-Joerg: I don't want to overpromise something here. I mean, I really... I mean I did some implementation work on the task side recently, so it's basically also a matter of transferring that back to the spec, but hard to say when I find the time for that. So I might try to get that done for Vienna, but yeah, I'll be careful promising too much here.
Bron Gondwana: All right, it's currently got the milestone set to July, so you still have time according to our tracker. If you could upload a new rev of it, just the same content but give it a new version number so it's not expired, that would be great.
Hans-Joerg: Okay, I can do that, yeah.
Bron Gondwana: Thank you. And the other three documents that belong to you kind of are Portability Guide, Rest, and Minimal Profile. They are all listed as on hold in the milestones.
Hans-Joerg: Right. So I think each of it has its use, so I think it's also... I mean we are using them in, you know, our version as documented there, so... and we decided last time that we address them now one by one and maybe Tasks is the one with a more widely or more obvious audience. But if there is anybody very interested in one of the other three or even implemented them, I'm also happy, you know, putting some work already in that. Otherwise, going onto them one by one probably once we have the Tasks thing getting forward.
Bron Gondwana: All right, thanks. Neil.
Neil Jenkins: Two things. Firstly, I think Robert should take anything he needs for the iCalendar/JScalendar draft and put it in that spec, because that's clearly going to come out first before JMAP Tasks, and let's not hold it up. Also, it seems probably if it's new properties for iCalendar, which I presume that's what it is, then makes more sense for it to be in that draft anyway. That was the main thing. JMAP Tasks, I had a look at that a month or two ago, the last document. From memory, it was looking okay, I was just think wondering if we could simplify some stuff. Like, I think it's aiming to be perhaps too comprehensive in some ways, which makes it more complicated, but I'll have to have another look at it to have specific comments. But I might be able to help with that at some point, not right now though.
Bron Gondwana: All right, thanks. I have to apologize, it's early morning for me. I have mistaken the JMAP Tasks document with the iCalendar Tasks document on which we have a dependency. So I see no issue with the JMAP Tasks document in context of the JScalendar iCalendar work. Sorry for the confusion again.
Robert Stepanek: Right, thank you.
Bron Gondwana: Okay, so it sounds like Tasks is going to get work next, and then we'll work our way through the others as time becomes available. For our area directors who might not have caught what happened here: the lead author on these left the place he was working, leaving the remaining co-author with a whole pile of projects all at once, so that's why it's been slowed down. Yep.
All right. That is I believe everything on our agenda. As I mentioned, the badge is most certainly a badge and definitely not a logo. I have no idea why this typo exists on this slide. It is being developed by this group called Occupop, who many of us will recognize as the designers of the branding here at this IETF, that beautiful T-shirt that Alexey's wearing there, for example, and also the designers of these existing protocol badges that currently exist. Jim and I had a call with the designers at Occupop a couple of weeks ago, and they are currently putting together some ideas. We gave them a brief around kind of what JMAP is and and what its properties are: the modernness, efficiency, energy saving, all those kinds of things. And they are going to come up with an idea which we will then send around to the group to look at and see if everyone thinks, "Yes, that's amazing," or they completely missed the mark, and then we will recycle and tweak until we come up with something nice that you can put on all your lovely products. Robert, are you still in the queue? No.
All right. With that, see you all in Vienna. However, before we do that, let me just go quickly through the milestones. All right, there we go. The infinite thing. These are the CALEXT milestones. So I've got Adopt the vCard-bis Document, which I think we can do next month hopefully. This is just put out a call for adoption, within two weeks that will be next month. We have already the submit document to IESG for a bunch of things, and we had Adopt the bis Document, which is going to happen this month. What? Not in the past. That one'll get clicked to done very soon. And submit these to IESG, I think is actually done. Yes, it is done. So both of these can be marked as done. All right, and that I think is all the work we've got here other than the iCalendar encryption thing, but we don't have Philippe here so I guess we can deal with that later. All right. Go to delete that new one I added because otherwise it will complain. I think that is all the changes we've got here, so I'm going to send these off to our Area Directors for approval. That will happen soon. That will be... that's new. And we submit these in July. Sweet.
Now, over in JMAP land, we have: draft-ietf-jmap-metadata has been adopted, Enhanced Result References (draft-ietf-jmap-refplus) has been adopted, Mailbox Sharing (draft-ietf-jmap-mail-sharing) has been adopted. Submit filenode (draft-ietf-jmap-filenode) is going to need to be bumped forward, I've made that June. I've added a new one for Adopt Blobext and for Submit Blobext. And I've put email push out in the future. Was there anything else in the milestones for JMAP anyone can think of? Do you have your Blobext on there? Yeah, that's the new one here: Adopt and then Submit, which I've put together with filenode in June. All right. I'll send those and I'll harass my Area Directors to approve it because the last ones still weren't.
All right. With that, I believe we are done, nice and early. Thank you everybody. If you've got any other business, now is the time to pop up to the microphone, otherwise I'll give you your 45 minutes back. I'm improving the milestones beforehand. Oh, thank you. You've still got another day. What? JMAP won't reload. What? Orie's opinion only counts for another 36 hours. All right, thank you all. See you in four months. As we soon as we do the vCard work, it then occurs to me: do we want to roll in existing extensions to vCard 4 into that? So everything's under one roof. That will be a question I suspect for Rick, but vendors have at least a look at what, five or six different specs for vCard 4. How much do you guys want to spend on vCard? How much time do you want to spend on vCard? Andy likes to read as many specs as possible. Yeah. How much time do we want to spend? As little as possible but we also want it to be good. The CALEXT working group's entire job is maintaining these specs, so you know, we're a long-lived working group because there's always shit comes up in them and it's not worth spinning things up and down. But it goes through quiet periods. Yeah. But I mean, my comments are really about energy dedicated towards JSContact versus vCard. Oh yeah. Well, in that case it's more that the formats need to be compatible, our charter says that you got to be able to represent in both, so alignment. vCard 3 is not compatible with JSContact. It can be with extensions, but sorry, everybody's doing their own thing, it's the wild west of vCard coming into JSContact. Oh yeah. vCard 4 could be entirely too cool, but nothing's going to change unless it's mature. Yeah. All right. All right, thank you very much, see you later.