Session Date/Time: 20 Jul 2026 14:30
[00:00:08] Bron Gondwana: Alright. I think it's time. I think so. The popping just clicked over. So Good
[00:00:20] Ken Murchison: afternoon, everyone. It's time.
[00:00:26] Bron Gondwana: Hey.
[00:00:31] Ken Murchison: Popping corks because of the JMAP session. Great. Welcome to JMAP at IETF 126. And we will note the note well as usual. And, of course, you know, this is hopefully, will be redundant by the end of the week, but not entirely so at this point. Please do learn and abide by the the different aspects of the IETF well, which include guidelines for conduct, anti harassment, intellectual property rights, and your obligation to disclose things that are that you that you're aware of IPR restrictions on. And in in general, the IETF process. And and these are all outlined in various RFCs that are specified on this slide and we expect everyone to be aware of those things. So appreciate that. If you're here in the room, please do log in with do log in to MeetEcho preferably with the on-site tool, but you can also use the the the regular tool with video and so forth as long as you make sure that your speaker is off and your speaker and microphone are and camera are off so that we don't end up with a lot of feedback. If you're remote I don't see anybody that's remote. Oh, there is somebody remote there now. For remote people, please also make sure your audio and video are off until you're maybe either presenting or commenting at the at the in the microphone queue. And we strongly recommend using a headset so that we have your audio in sparkling clarity. And for everyone, please when you're in the queue, please state your name each time you begin speaking so that we have a good record of who said what. The point pointers to the agenda, MeetEcho, and reporting issues page. So the first part of this meeting is Calixt, and the second half will be Jmap. And so here's the here's the Calixt portion of the agenda. And does anyone have things that they would like to bash in this agenda?
[00:03:41] Arnt Gulbrandsen: Okay.
[00:03:44] Ken Murchison: And then
[00:03:45] Bron Gondwana: That's it. But Oh. Spoiler. Spoiler. Wait. So we'll
[00:03:50] Ken Murchison: come back to that. So so the first one is
[00:04:00] Bron Gondwana: Yeah. We don't have slides. We don't have slides for that with IESG section, but there are two drafts in that section. They're both with the RFC editor. I don't believe there's anything, but if anyone has anything anything they want to say about those, then it's probably worth the iCalendar Tasks and JS contact profiles.
[00:04:19] Robert Stepanek: I I assume nobody has anything to say about them, but they are still underway. Hopefully,
[00:04:25] Bron Gondwana: they'll come back to all 48 shortly, and we'll get them published. So, Robert, I think you're up next with a couple of different day. Whichever order you'd prefer to take them in because there's two different sets. Js calendar. Yep.
[00:04:39] Ken Murchison: Calendar first. And, hopefully, that works.
[00:04:45] Robert Stepanek: Okay. Hello, everyone. I'm gonna talk about js calendar and then afterwards, some more about js contact. Js calendar first because the status is very easy. We we are we are done. I the the title says we are ready for last call, but that's not entirely correct because some of them already are in last call. And I think one of them already is with the area director, so I'm not sure about the procedure as how to move them all forward. But in terms of content, this is all done. We have deployed it on our systems. We have we think we have enough experience with interoperability and are confident that this is this is what it's should be do doing. There are three drafts just for your interest. So there's the JSCalendar bis draft, which is about the data format for calendar events. Chase calendar iCalendar is the one that talks about converting between chase calendar and iCalendar. Third one in this bucket are a few iCalendar changes that we have done so that we can map all the off JSCalendar bis to iCalendar. And in the chain of working group, there is the chain of calendars API specification that I think Neil might be talking about later. So I'll only cover the three in the Calnex working group. Just a short short summary of what has changed or some of the notable changes since last ITF are for JSCalendar bis. There has been a clarification in the recurrence rule interpretations. We reintroduced the sent by property, also made some further restrictions so that we are that we are compatible with the iCalendar restrictions with regards to rescheduling. And one of the things we did is removed all null values except the ones that are used in patch objects. This is mostly so that this more nicely incorporates with using JS calendar in chain map for calendars because in chain map for calendars, there is the requirement that top level properties might be null, but should be then ignored by the server. And so since null does not have any semantics or meaning anymore in JSCalendar, it's very easy to just remove them before converting them, for example, to iCalendar. JSCalendar iCalendar basically reflects the changes that we had done to JSCalendar bis. One thing we did is we now also define how to preserve our dates in recurrences of period type. You can look it up. It's an edge case. We we rarely see them or mostly not at all in iCalendar data getting passed around by contemporary iCalendar and and Caldiv clients. But if you encounter it, now there's a way to preserve that in JS calendar. And lastly, we removed the example for preserving non IANA time zones because the example was incomplete. And to make it complete, we would have to define handling of non IANA time zones, and this was deemed to be out of scope of our RFC. So as I said, we are ready for last call. That being said, most of them already are in last call or already exited last call, so I'm not sure what's the bureaucratics and how to get this actually done. That's the end of my presentation.
[00:08:24] Bron Gondwana: Alright. Thank you, Robert. I'll note down that action is anything that's not already been work group last call to last call it now.
[00:08:32] Arnt Gulbrandsen: Cool.
[00:08:34] Robert Stepanek: Anything to talk about with regards to chess calendar? Otherwise, I would start with chess content. Oh, I think Neil is in the queue.
[00:08:49] Bron Gondwana: Yep. Neil, go ahead.
[00:08:54] Neil Jenkins: Hello. Yes. I just thought I'd jump in with the kind of JMap calendars bit associated with that just to say because that was in a weird state. It went all the way through to all 48, and then we realized we had to hold it because of the JS calendar changes. So the plan for that is to also do a very short last call again. There have been very minor changes mostly just to clarify things editorially. So I I think maybe we just make a one week or two week last call for all four documents together and then send them all through.
[00:09:38] Bron Gondwana: Neil, are they all published already, the latest versions that we want to do that with, or is it a need to do one more run?
[00:09:43] Neil Jenkins: No. I will publish the latest streamer calendar one tomorrow.
[00:09:48] Bron Gondwana: Alright. Thank you.
[00:09:56] Robert Stepanek: Alright. Should I continue with JSContact? Or
[00:09:59] Bron Gondwana: Yeah.
[00:09:59] Robert Stepanek: Alright. Good. JSContact, there's a bit more to be said about JSContact and JSCalendar in the current stage. We published recently 09/1982, the draft-ietf-jmap-blobext, which made the UID property optional rather than mandatory, and that required us to bump the major version of JSContact to two point o. We have one that had been mentioned before at the ISG, the JS content profiles draft that's waiting in the or, actually, that's waiting in the editor queue. So whenever the editors get ready, that should get published soon after, hopefully, too. The two documents or actually, one document that is in the works is the this document for RFC nine five five five. Nine five five five is the as the JS calendar, iCalendar document before described how to convert between JS calendar and I calendar. The nine five five five document describes how to convert between vCard and JSContact. Now that we are publishing, hopefully, soon the JSCalendar iCalendar draft, we we we did some changes to nine five five five so that the conversion idioms used are the same for both vCard and iCalendar conversion, which should which should be make it that better developer experience rather than having to implement two different things for the very same things, actually. I'm just mentioning here nine five five four because there are two errata, but now already the errata that had been pending is now held for document update, which updates the ABNF. I think we'll decide if we if we try to update nine five five four in 9555-bis, but regardless, sooner or later, this might get an update then too.
[00:12:00] Arnt Gulbrandsen: So
[00:12:03] Robert Stepanek: for nine five five bis, we we basically achieved almost everything we wanted to achieve, so that was quite fast. The main the main goal was to, as I said, align the idioms that we use for iCalendar and chess calendar conversion also for vCalendar and chessContact. We've basically done all that. In the while doing so, we also fixed fixed examples, expanded the document with more clarifications, reorganized them so that people reading the one document will find the other document very familiar. There is one just one one thing missing, and that's about how to make these new idioms work with localization, which use JSON pointers, and it's not not entirely clear which point they should point to what. But this is this basically requires us a bit to experiment more which approach of the couple of approaches that we are considering we prefer. I expect this to be done in a in a couple of weeks. So, basically, for 9555-bis, we we thought we are ready. Oops. But in the meantime, Rick, my colleague, has started the effort to write a biz to update or actually obsolete the existing vCard 4.0 document that's 6350, published almost fifteen years ago, I think. And it since that time, it has its words, and Rick is now updating it. And the updates that this document will get will also make conversion between JSContact and vCard better.
[00:13:45] Bron Gondwana: So we
[00:13:45] Robert Stepanek: think it's worthwhile waiting for that document. That being said, at the moment, I wouldn't I wouldn't know what's the timeline for document. I guess Rick might talk about that later then. But in in terms of the contents, I think these documents should go together rather than 9555-bis getting published before because otherwise, we might just need to update 9555-bis again soon after. I think that doesn't make sense. While we are we're we're working or still working on 9555-bis, and we we also rolled out JSContact on our services, and I thought it might be interesting that we share a couple of findings from that. Generally, we are we are happy with the with the rollout. We we encountered a few words that I want to talk about now, but overall, this works. So I think it's that's a good sign. The one of the things that we encountered, though, is that while defining JSContact addresses, we decided let's say, probably out of a sense for purity that we split street addresses into street names and street numbers. But we and that's in contrast to weak heart, which is basically one text item for both the street name and the number. But we didn't consider the case where it's unknown to the implementation for for the location if numbers typically go before the street name or after. So that's an issue that we currently see in the data model. We typically do not see this issue in practice because almost all address data that we encounter is created from vCard first. So and that leads us to converting the the single field from vCard into the name street name of the JS contact data. So, basically, we are not using the number field. But, of course, the other way around, it it's not exactly trivial for an implementation to figure out if it wants to create an address label where street name and number are separated in which order to produce that. We had done we had chosen this approach because it's very similar to the person names that we extended for JSContact. And for person names, there is a CLDR technical report that tells you how to render a full name specific to the culture for which the for where the name originates. The issue is this does not exist for addresses in CLDR. I read I read some notes that I think last year, the Unicode consortium was discussing options to to do that, but they haven't started any effort to do so. I know that the ISO what is it? Well, you can read the number. But there is an ISO spec that does the same thing as JS context, so it also separates street name and number. But it's pay void. I haven't looked into it. I don't even know if they then have any guidance on how to render the address such that it makes sense for the location where that address is actually located. Yeah. I think this is this it's it's annoying. It's not a it's not a big annoying issue currently in in practice, but it's certainly it's certainly something we wouldn't do again if we would define JS contact addresses now. And I think the workaround is to use just the name field, but we might also consider to introducing a a field that's actually fine to contain both. Yeah. I'd be happy to hear anyone's thought about what to do about it or what are their experiences with with rendering addresses. Promise in the queue.
[00:17:54] Bron Gondwana: I'm just popping myself in the queue. IATf has a liaison with ISO. Yep. So we could ask them to provide us a review and information on what they're doing with addresses. Okay.
[00:18:05] Mário Blažević: That would be very great.
[00:18:06] Bron Gondwana: Yeah. And yeah. Possibly, an option would be to add a field which says which order they belong in at number first or number last to our object.
[00:18:18] Robert Stepanek: Well so in JSContact in JSContact addresses, we already allow you to state the order of these fields.
[00:18:27] Ken Murchison: Mhmm.
[00:18:27] Robert Stepanek: The issue is, typically we expect implementations to not know. So that's the that's the issue. If if you know the order, you can state it already, and this is a nonproblem. But if you don't know them, and I think most implementations don't know them, yeah, then this feed won't help us. Another finding is related to the social profile or ex social profile, how it's called in vCard, and the online service object type in JSContact. This is a long history. Basically, since a long time, people have to need to put their messenger addresses and, I don't know, social media identities and whatever into their contacts. And there have been multiple proposals how to achieve that. Shortly before vCode four got published, so what, like, I think sixteen years ago now, there was actually a proposal for a social profile property in vCard that, for reasons I don't know, never took off. It was written by Barry Label, I think, and I think you and were somehow involved in that. But, anyway, this never took off. Apple still implemented it then as an x property, but implemented it a bit differently and never documented the differences. So since then, you see x social profiles in in vCards that are generated by Apple products and iCloud. For when we now introduce JSContact, we had the same need again, so we figured we are just formalizing what's already out there as x social profile. But since it's undocumented, we didn't get the semantics exactly right, so there's now a new a new property that's also not totally adequate. And for this, during in our rollout at the moment, we had decided to fall back to our own x property again. So that's that's all to say that the there is apparently the for a long time, the need to store social identities or or a messenger service identities in contact cards. But whatever approach has been chosen so far apparently hasn't been adequate. So at this point, we are a bit lost what to do about it because as long as people who who have issues with it don't speak up what exactly they want, we really have a hard time figuring out what to do all about it. Oh, you're you're still in the q queue?
[00:21:13] Bron Gondwana: Oh, sorry. No. Oh, let me take myself out.
[00:21:16] Robert Stepanek: And the last finding from our deployments is that vCard four basically is almost nonexistent. Like, the lingua franca in for vCard is still vCard version three. That's what's getting sent around by almost all services. Then again, only a subset of what's defined in vCard three actually gets sent around because even for this subset, interoperability is basic enough that you can share the main things like names, phone numbers, email addresses, and and mail addresses. But everything else, as I said, messenger data and and all that stuff, that's really there has to be special handling for basically all the data that at least the big players are producing, and the small players are basically then trying to implement all of these variants to to make sense of the data. What that means for JSContact, when we started JSContact or when we defined JSContact, we took out the Calix charter by heart, and we really tried hard to stay to stay close to the semantics of vCard 4.0. But I think that made us make decisions for the data model, which we might have not made otherwise. And now it turns out that vCard 4.0 isn't that prevalent at all. So I'm not necessarily saying we should recharter, but we might want to reconsider if we ever refresh JSContact if vCard 4.0 capability should be our top priority under these circumstances unless
[00:22:56] Bron Gondwana: v cut
[00:22:57] Robert Stepanek: four b suddenly suddenly makes the word move towards it. But at the moment, I I just don't see it. Last thing, Phillip ah, here he is. So there's one additional document in the works for JSContact to extend and also improve its support for cryptographic keys. Anyone who's reading the mailing list, I guess, knows about that. As I also wrote in the mailing list, I think it would make totally sense to support JSON web keys or an equivalent that the IETf has produced in JSContact for your information. At the moment, a cryptographic key in JSContact is basically a data URI. So it's like one data format stored in another, and that always sucks, in my opinion. So if we can move to real JSON based cryptographic reformat that's actually also more modern than the ones we're supporting,
[00:23:55] Bron Gondwana: that would be really great.
[00:23:59] Robert Stepanek: So the next steps are the JS contact profiles RFC as soon as it's getting into editor queue. We would edit and publish it. The nine five five bis will resolve the few remaining open points and then just align with the b code for bis effort. And we have no further work planned at the moment. That being said, depending on your experiences, for example, about street addresses or what we learned from ISO, we might we might propose an update for that, but I have nothing concrete planned at the moment.
[00:24:34] Bron Gondwana: Alright. That's my presentation. Cool. Thank you. So the only action I have out of here at the moment is for me to speak with ISO about liaison. Yep. Thank you. Yeah. Thanks. Alright.
[00:24:52] Mário Blažević: Thank you.
[00:24:54] Bron Gondwana: Alright. Rick, believe you're up.
[00:25:01] Arnt Gulbrandsen: I
[00:25:04] Rick Signes: think this will be short and sweet. So last time, we talked about starting a vCard for this, which is just vCard four with a bunch of the problem solved because there were a bunch of problems. I had 33 reported errata, which ranged from things that were confirmed fifteen years ago as being problems to things that we thought maybe were problems but crossed over with other working groups and no one was sure what to do. I had fun solving the easy ones, and then I went on to the hard ones. All the easy ones tended to be typos and examples didn't match the grammar and tedious stuff that nobody wants to hear about. That's all been fixed. Feel free to look at the commit history if you want tedium. There are a couple fiddly things that I wanted to make clear here, which I've also talked about on the list, the decisions that got made. One is about commas and URIs. This is one of the bigger errata erratum. Yeah. That was reported. This is not important. It's one of the bigger issues that got reported. It was reported several times with conflicting fixes suggested, sometimes both of them being accepted. So we had to decide what to do. The biggest issue here is nothing showed escaping commas in URIs, but there is a suggestion in the draft that all values must have commas escaped, and there's problems with solving this either way. The solution that I've got in vCard 4.0-bis in the Git repository is that comma escaping will only apply to non URI values or specifically to text values and to components, which are structured text values. That means that your URIs don't need to be escaped. There is no ambiguity that I could find introduced by this, and it means all the examples throughout this and the extended specifications become accurate and work. Also, it seems to match most implementations that I found out there. The alternative solution that was discussed is do require comma escaping. All the examples become wrong, but the rule that all values must be escaped becomes correct. That requires more invasive grammar changes, so I didn't make that choice. But the big question is effect on the ground. I haven't heard from a lot of people. This is gonna be a topic comes up later. But if you have stake in this, you should think about how the change that I have put in the draft would affect you because I only know how it will affect me.
[00:27:31] Bron Gondwana: What does a nonescape comma mean in a URI if you came across one in that second case?
[00:27:36] Rick Signes: Yeah. That's right. I mean, in in the in the grammar, URIs never appear as a URI list where you have multiple URIs separated by commas. They sometimes appear in structured fields separated by commas or semicolons where the URI's position makes it totally unambiguous. So a kind of a key aspect here is if you know the type that of the field that you are processing, you can always parse it unambiguously. If you don't know the type, you probably shouldn't be parsing it. You should be treating it as opaque. That's the view that I've taken here. The biggest issue the the whole issue that led me to want to undertake any work on this was difficulty with text UIDs either in v four cards or v three cards and group cards in v four. To recap this problem that I posted about a bunch, a v four group card has a member property, which refers probably to another card, and it must be a URI, which means that if you have a v three card or a v four card with a text value u UID, you can't refer to it. So there's a number of ways people solve this, one of which is referring to it anyway. Just put the byte value in. And some is transforming the text UID into a URI through a process that may or may not produce a well formed URI and referring to that. None of these fit with the document. They're all bodges to make their software work. So I wanted to have guidance in the document that said, this is how to do it. That would be coherent. That would be simple and straightforward and would work with all the implementations I could find. So what I put into the draft is that member will get a the option to have a text value type, and there's a little rule for how to compare member and UID equivalents across types. It's very simple and straightforward. But, again, if you have software that performs this operation, you should look at this and decide if it's gonna have any impact on you. I've looked at a bunch of software. As Robert said earlier, the adoption of vCard four is pretty low, so finding all the software that does it is tough. There's a couple open questions. One of them is about the deprecation of text directory. I don't know who the authority to talk to is here. Someone reported that sixty three fifty deprecates the text directory media type, which is being used by LDAP, and it was introduced for the use of sixty three fifty. If LDAP wants it, I assume what needs to happen is some LDAP authority needs to go to IANA and say, please undeprecate this according to our use in some other document, but I don't know. So I don't know how to resolve that, erratum. And forty two thirteen, if if you have a property that is in a group with other properties and they have conflicting alt IDs, what do you do? And the answer appears to be give up. I I think the only thing we can do is say, if this happens, no one knows what it means, and you should not do it. But I am not sure I've ever seen this occur in practice. I think that's the answer is don't do it. And finally, the net this is the the next action for me is to go through the existing extensions to vCard four and pick the ones that should be folded into vCard four BIS as now effectively core. This is my proposal, which I'll be sending the list. I think that the things from nine five five four for JSContact compatibility, should bring in. I think that we might wanna bring sixty eight sixty eight, which is for parameter value encoding. I need to determine if it occurs in the wild. I only know about it occurring in the wild in one place that is not parameter value encoding, so probably the not a good use case for this. And then some other standards that I think we can skip. If you have skin in the game here, please be in touch. And then that's the last message again. If vCard, especially vCard four, is part of the software you are working with, part of the technology you're interacting with, please be in touch either on the Calcify list or directly with me. Most of this stuff is driven by me thinking about what is coherent and looking at the data that pass through our systems or software I can download from the Internet, which is great. But if there is software out there beneath the surface of the ocean, I have not seen, what it's doing. That is it. That's my presentation.
[00:32:07] Bron Gondwana: Alright. Andy.
[00:32:13] Andrew Alston: Hi. Friendly neighborhood AD. If you could send me the list of those, errata, that are accepted but conflict, I can change them to hold for document update, which is what they should be. And even the ones that are still open, I can go ahead and
[00:32:27] Robert Stepanek: mark those as hold for document update as
[00:32:29] Bron Gondwana: I can do.
[00:32:30] Andrew Alston: On the LDAP question, there is the LDAP text mailing list, which is, believe it or not, still around.
[00:32:35] Ken Murchison: Great.
[00:32:35] Andrew Alston: So you can send email to them.
[00:32:37] Rick Signes: I'll do that. Thank you.
[00:32:44] Murray Kucherawy: Hey. Can you tell me more about text directory? Not really. Can anybody tell me more about text directory?
[00:32:50] Rick Signes: I can tell you a very small amount unless someone knows more than me.
[00:32:54] Murray Kucherawy: Tell me what you know.
[00:32:55] Rick Signes: My recollection is that in the RFC introducing vCard three, it introduces two or three media types, including text directory, like, x application directory card, right, something like this. And it because vCard three is being introduced in the context of LDAP and directory services. So there's a number it's introduced two other documents that are, like, we're directory service documents. VCard four introduces the media type text vCard, which we all know and love. It says now text directory is deprecated because we don't need it anymore. That's my read of the situation, but I don't know how LDAP is involved.
[00:33:31] Murray Kucherawy: And why do you still need it?
[00:33:32] Ken Murchison: We don't.
[00:33:33] Rick Signes: So what's The the is someone saying, you deprecated text directory in sixty three fifty.
[00:33:39] Alexey Melnikov: Yep.
[00:33:39] Rick Signes: Over here in LDAP land, we're still using it. And they still need it. They still need it. That's why I think that LDAP needs to say, please, we would like to take responsibility for this. If it's still true, that could be twelve years old and everyone's moved on. I just don't have the expertise.
[00:33:54] Murray Kucherawy: So the argument is that we, being this community, should not have deprecated text directory without That seems
[00:34:00] Bron Gondwana: to be the argument.
[00:34:01] Mário Blažević: Okay.
[00:34:03] Hans-Joerg Happel: Okay. Thanks.
[00:34:04] Neil Jenkins: Yeah.
[00:34:07] Arnt Gulbrandsen: I thought that would be Anything
[00:34:12] Ken Murchison: else? That's it. Thank you.
[00:34:14] Rick Signes: No. Alright. Thanks.
[00:34:31] Phil Pennock: Okay. So Phillip Hallam-Baker. Cryptographic extension. So the framing goal here, everything I'm trying to do here is to make it so that when somebody gives you contact, you can run a little Perl script. Or if the application is JSContact aware, it can just suck in the cryptographic credentials for that application and put them in the right spot spot. And, you know, there's pulling things out that are expressed as data URIs is really suboptimal because then the Perl script that's doing this extract has to understand the cryptographic format. And, you know, you don't want the JS contact widget knowing have having to know about new cryptographic formats as they come along. So there's a dependency stuff there. So that's what we're trying to do. Current status is I've now got running code and have exported that code into the draft, and the two are synced now. There is a slight tweak. It's not got the updates to the scheme that we're discussing on the list. That does not have been reflected through, so there's a slight mismatch between the text and the examples right now. But as soon as I'm told which one to do, I can go through and change that. I just want to do one change, not multiple changes. I've been talking to the OpenPGP and SSH communities to find out if I would be treading on toes and you know? We don't we don't want to choose to do something one way and find out that they're all doing it some other way, and it's not quite documented yet. But it turns out that I talked to people doing open PGP and say, oh, yeah. You can put data in the PGP key to say what it's for. Is it and are those described anywhere? No. So so it doesn't look like we're treading on terms. We can just do what we like, which is easier in some way. Okay. So one issue that's come up is crypto key object type has you must have a URI property, which was for the data URI and the blob of, you know, opaque data. But we don't need that if we're putting a key key into the contact as a JSON web key. And so, you know, there's various hacky ways around it, but, basically, it comes down to either we do a breaking we we say, you don't need to have the URI. It is optional, which is a breaking change as far as the spec goes, but probably not gonna break any of these code. Or we bifurcate and have a crypto key object and another one for crypto key with JWK, which is kind of crappy. So yeah. So I think that I prefer the breaking change because, yeah, having online services separate from emails is causing problems. This will be a new type of complexity. We can avoid it. The second issue that came up was I there's a mechanism in the in the system to say, here's where you can get updates from. And I had called the class updates, lowercase. Yes. Sorry. And, yes, change that to update source because updates could be, here are the updates, not here's how to find the the updates. So just a bit of grammar, you know, so we can back back shed that if people really want, but I think update source works fine. And, I'm currently working on code to implement three options, only two of which I think will actually make it into the draft at most. But, yeah, I do want to have at least one mechanism for pulling updates described, and HTTP polling is probably the one to do. If I can persuade people that we should put DNS handles as a way of fetching a JS contact into the draft, well, then we'll put that in as well. Because, actually, it's quite neat because, you know, you can update your whole contacts thing just by doing UDP DNS lookups rather than HP polling, which is cheaper. And that's it. Clients?
[00:39:42] Robert Stepanek: Robert Stepanick. So just to restate what I said before, I I would also be in favor of introducing a breaking change for JSContact crypto keys so that we can store them both kind of keys in the same object type that looks the much cleaner solution to me.
[00:39:59] Phil Pennock: Okay. Yeah. That that that's my preferred approach as well. I mean, if nobody's screaming yeah. I mean, there's breaking the spec, and there is breaking running code. And I think it's pretty clear that we're not
[00:40:13] Bron Gondwana: gonna break any running code.
[00:40:14] Robert Stepanek: I think we should not be afraid of bumping major versions, especially not in this early stage of JS content. And as I said, this this exactly goes in the direction of that we started from what we had in vCard, but we can improve on what we think is makes more sense in reality.
[00:40:31] Bron Gondwana: The the
[00:40:31] Phil Pennock: the the one tweak here is that this set of capabilities are something that you will be able to do with JSContact that you cannot currently do with vCard. And so once we put it out into the wild, then we may the curtain will probably come down, and it will start you know, if it takes off.
[00:40:55] Robert Stepanek: Yeah. Even better. Yeah. One other question with regards to the registry of update source protocols. On the mailing list, you mentioned that you would introduce a registry for that.
[00:41:09] Arnt Gulbrandsen: Yeah.
[00:41:10] Robert Stepanek: In would you would you want to register that as part of the JS contact registry, or would you create another registry at IANA for that?
[00:41:20] Phil Pennock: I think it would be an IANA registry under the JS contacts folder. The only reason you might want to do it differently is if you're gonna be doing JS calendar or whatever. I it is possible that the updates widget is something that would be general purpose and could be reused elsewhere. And my third one, the notification service push, I do have code that does just that. It's just not being used for contacts at the moment in my system. It's Yeah. But that's something that I don't think makes much sense until we've got a million of these.
[00:42:00] Robert Stepanek: Well, let's see if we can we can still decide where to put this then. Yeah. Alright.
[00:42:15] Bron Gondwana: Alright. And is that our complete agenda for Calixt? We had no. The only other thing we had was a piece of new work that got sent to the mailing list a few months ago. I haven't heard anything from the author since. This was a tidy up all the references thing, and it it looked like it may have been someone throwing an agent at it and saying, describe all the things that are not well lined up here. And so if if anything, it might be an input to Rick's work to see if anything could be better documented from it. But, without a speaker or anything, I think we just skip past that, in which case we alright. Any other business for Calixt?
[00:43:06] Ken Murchison: Do You wanna do milestones?
[00:43:09] Bron Gondwana: Yeah. Murray.
[00:43:15] Murray Kucherawy: Andy and I were just talking about how to fix the text directory thing. We I may have a solution.
[00:43:20] Alexey Melnikov: I I
[00:43:21] Murray Kucherawy: don't know how much it really matters to this working group since it's mostly we broke some LDAP stuff, but I I might have something to report soon.
[00:43:35] Bron Gondwana: Cool. Alright. Let's have a look at our milestones then. Do you want to oh, you have unshared. Excellent. There we go. Now we are in the in the depths of craziness. Not this one. The other one. I can't I can't do it from here because it's not doesn't have its own link. There we go. Alright. So we have, adopt RFC five five this that's done. Resolved. Done. Dot vCard BISS is resolved. Done. Submit JS calendar mapping document for publication. Will happen this month, hopefully.
[00:44:36] Alexey Melnikov: Maybe next.
[00:44:37] Bron Gondwana: Maybe next. Yeah. Depends how fast we are. JS calendar bisque, near enough. Just give ourselves a couple more weeks.
[00:44:50] Alexey Melnikov: I think this has already been done.
[00:44:55] Bron Gondwana: This one?
[00:44:56] Mário Blažević: But, yes, put everything on our view.
[00:44:58] Bron Gondwana: Okay. We'll sync with the we'll mark that as done then. Sweet. What new milestones do we have? We have, I guess, submit the vCardBiz. When when do you think you'll be done, Rick?
[00:45:27] Rick Signes: I would
[00:45:28] Phil Pennock: like it to be done before next meeting. So
[00:45:30] Bron Gondwana: Alright. November.
[00:45:32] Rick Signes: Yep. Hopefully, sooner.
[00:45:34] Robert Stepanek: Yep. That would be great, but
[00:45:35] Bron Gondwana: I'm like Tomorrow. No. No. Draft-ietf. IETFietf-, that's what it'll be. Yep. X v card for this. There we go. Alright. Are there any other milestones we have at the moment?
[00:46:06] Robert Stepanek: 955 this Should have same milestone as we got for this.
[00:46:19] Ken Murchison: November.
[00:46:27] Bron Gondwana: Alright. Anything else? Saved. Waiting for our area director to approve. Let's move on to the JMAP part of the agenda. And we're fifteen minutes ahead of time. Fantastic. Lots of time to discuss the JMap things.
[00:46:51] Ken Murchison: You need to unshare first.
[00:46:52] Bron Gondwana: Sorry. Let me go back here and drop that. Yep.
[00:47:03] Ken Murchison: We wanna go back to chair side?
[00:47:05] Bron Gondwana: Yeah. Alright. Yep. Just keep rolling through to number seven. There we go. We have a protocol badge. There are stickers floating around. If you here we go. There are stickers right here. If anybody would
[00:47:32] Ken Murchison: like limited edition a limited number of these. So I just bought the introductory size pack to see what the stickers were like. So they're
[00:47:41] Alexey Melnikov: Do do you get one if you come to the mic or something? You
[00:47:44] Bron Gondwana: get you get one if you ask nicely. Gin and tonic, I believe, works. So these this you can now stick on all your products that support Jammap. You can stick it on your website to say we support JMap. You can have it tattooed on your body, whatever whatever floats your boat. This is available on the IATF website in the protocol badges section, and this this is what JMap now looks like forever and ever.
[00:48:13] Ken Murchison: And I've heard that there are plans to have available in the in the store JMap t shirts. Mhmm.
[00:48:22] Bron Gondwana: Alright. Shall we move on to the the rest of the content?
[00:48:26] Ken Murchison: Is there anything else here?
[00:48:27] Bron Gondwana: You can download high quality copies of this from jmap.io as well. That's in the resources section. Alright. So, again, gemmap calendars, Neil already spoke about. It will be passed through and and dealt with very soon as part of our last calls. And then, Mauro, you are next.
[00:49:03] Robert Stepanek: Object metadata? Yeah.
[00:49:12] Mário Blažević: Okay. Hi, everyone. So Could you move the microphone up a little bit?
[00:49:24] Bron Gondwana: Okay. Thank you.
[00:49:28] Mário Blažević: Okay. So these are the three extensions I'm working on. It's just a brief overview of what of what they are in the current status. Nothing much has changed since the last session. So so they are the draft-ietf-jmap-mail-sharing, object metadata, and enhanced results references. So mail sharing, this one is very simple. It's just adding sharing support to email to jam up for email. Because as you know, the jam up sharing was published after JMap mail. So JMap mail does not have all the the properties we need in in order to make a mailbox shareable. So it's just a, yeah, a small draft, adding a new capability and the and the required properties. So this is, yeah, practically done. It's implementing store, and I believe also there are few clients that support it. I don't know if Cyrus does. Soon. Soon. Okay. Yeah. So I I believe it's ready for last call whenever the the group is ready. Then draft-ietf-jmap-metadata. So, basically, what it does is it is equivalent to the the properties in web app and the iMAP metadata for iMAP. So it adds the capability to add metadata to any JMap object. So, basically, you if the server supports metadata, you will be able to store, like, a public metadata or private metadata on on any object that the server publishes. So then the in the capabilities, server advertises which objects you can add metadata to, basically. There are also name namespaces, so we can register some specific metadata. For example, for photos, we can create a photo metadata and then add it to filenodes to define aperture and any other camera properties. That's an example. So this changed the this the how how this extension works since zero one based on some feedback from Neil. Now it's much simpler. So, basically, you have two properties, metadata and private metadata with, yeah, a JSON object under under them, and you can use a standard JMAP methods to query them. So in the in '0 one, there was a separate metadata object because the goal was to make this compatible with web app, the properties and also with the IMAP metadata so you could access that metadata from JMap. But, yeah, it doesn't I think that is an it's too much. It's too much bloat, so it doesn't make sense, I mean, to to do that, really. So this is much much simpler approach. It's just metadata that you set from JMap and you retrieve from JMap if needed in the future. If we need in the future to access a web lab or IMAP metadata, we can add an extension. So for that reason, before there was a metadata object, but now it's much simpler. There's there's not and, also, there were other methods for metadata, but now everything is under the JMap object that you are adding metadata to. So, yeah, this comes with some advantages so that you don't have to worry about two properties sorry, two different objects. No multiple calls. And in a same query, you can in a same method call, not a same query. As a method call, you can also retrieve the metadata. So on the this object metadata, so you can have the server can tell the client whether you can add vendor namespaces as any properties you you like as a client, whether you can set private metadata. So the different for example, if you're sharing a, I don't know, an email, You can have some metadata that is only for the owner or for each user that has access to that email or global per ops for the entire object, for example, an email. And then also which namespaces it supports. And then it adds some query filters if to check if you can add to a query if a certain object has certain properties inside the metadata. Then it add added new updated properties to the changes methods and, yeah, and and add some clarification about state changes for metadata. So this is how we would an idea of how it works. So you when you create an you can either patch objects sorry. Pat patch keys inside the the metadata property or replace replace it entirely. Here's an example how you could query only the and fetch only the metadata you're interested in without retrieving the entire object because it might contain data from other vendors, for example. So, basically, the properties the properties now should be has to be extended a bit to support JSON pointers for the for the metadata. Also, this extension creates a metadata registry at Ayana. So what that this is what I mentioned before that if you are, for example, for file node, you we could create a a new metadata for photography or any other object in the future. Anything that makes sense to standardize could be added to this metadata registry. Okay. So, basically, this is I'm waiting to implement this in stalwart once the group believes it's it's clean implementation. So I know some people that want to use the this extension for either migrating this, storing temporary data for migrating or adding custom properties to calendar, stuff like that. But, yes, here, we're basically loop waiting for feedback, and if it's ready to be implemented as it is. Sorry. Yeah. Developed and and tested before, yeah, we can continue. So, basically, it's just we're here to review the current draft and suggest any changes. Or if you think it's okay, then create an initial implementation of some and buy some clients also to support it. Okay. The draft-ietf-jmap-refplus. This one is more controversial because it tries to extend the way you query JMAP.
[00:57:21] Ken Murchison: So
[00:57:23] Mário Blažević: it adds a lot by this detail in the in in the draft. As you know, Jmap, you basically, you you query you can patch and using JSON pointers. And, also, you can run queries using JSON pointer. This is this adds support for a JSON path. So you can create more powerful queries, and, also, you can use resolve references in set and filters. And there are other few ideas I have in mind, but that will be too much. But, yeah, basically, it's extending the result references mechanisms on in JMap with JSON path and other extensions. This is an example of of a query. For example, you are here, the idea that you are creating creating an email and an importing the attachments for another from a different email that you queried before without having to fit download it to a client. So yeah. And there are other other examples. You could, for example, combine it in a search, use a filter that is using results from a previous search so you can change searches and and so on. These are some comments from Neil. Neil probably is on the call. He can provide feedback later. So Neil believes that it's too much complexity for what we're gaining here, And then he makes some comments. He suggests adding a type direct resolution. So sorry. He proposed adding a type property to resolve reference object. Then so he was also worried about proxies in the middle. How do they need to learn about the Do
[00:59:29] Arnt Gulbrandsen: a like this. Okay. Yeah.
[00:59:34] Mário Blažević: This is about adding a type property to the to the result references. Yeah. So it's yeah. Then so, yeah, he was also proposing making some changes overall to the to make this work with proxies and also to handle to make this easier to be implemented. But so what I believe in general, the the the the changes are reasonable. And what I was telling Neil is that I find this extension useful when I implemented a client. I thought that, yeah, I could reduce some network round trips by doing this from the adding more work to the server, but letting the client fetch to fewer round trips. And but what I what I like to know if is others will find this useful too or or if you believe this is an overkill and Jaymap should stay as it is simple. And or if if it's something other people is interested in in implementing. If not, should stay as a proprietary extension, I believe. So, yeah, basically, I'm waiting what is the feedback here. So, yeah, this is what I just said how if others are interested in in the enhanced references, think there is interest for metadata that that I I've heard comments that people want to implement it and email sharing also. Yeah. That's that one for sure. Okay. Yeah. That's basically
[01:01:27] Arnt Gulbrandsen: Arndt, question about enhanced enhanced result references. They closed the coffee bar. It drops a few round trips, which may not be serious. Does it does it also drop error handling between the round trips? Can you it make things atomic that needed error handling in the client between the steps? Because that's a big issue to me.
[01:02:00] Mário Blažević: Well, the yeah. Well, if the first, if you're chaining requests and the first one fails, the second one fails through the result references. But if the error is that your your JSON path query yields no results, that, I guess, you will know that because the first query had no results, and, you know, you cannot trust the second one. But, yeah, it does not yeah. That's something could be first of all, let's say you're importing you're writing an email and you want to bring the attachments from or the participants. You create a new calendar event, and you want to import the participants from a a a template you have somewhere. If that template does not exist, yeah, the whole chain will fall. But if your query is wrong and it yields no results, perhaps we should, yeah, add, like, some property or some way to tell the server or this or define that and say, yeah, if if you're running a query that use no results, how to handle that? If that is a failure, because it might generate invalid results. If you're expecting some data that is not there. But, no, currently, I was I did not if your if your query JSON path query yields no results, it will that that is not an error.
[01:03:31] Arnt Gulbrandsen: Not quite sure I understand it.
[01:03:33] Mário Blažević: No. For example, this I think part of it It's what I was For example, this this query
[01:03:39] Arnt Gulbrandsen: You need the same error handling for service that don't support it, and therefore, you lose no complexity or server or error handling.
[01:03:47] Mário Blažević: No. What what I'm saying
[01:03:49] Arnt Gulbrandsen: What kind of error? I
[01:03:52] Alexey Melnikov: think it's in the definition of error. Right? The past
[01:03:54] Mário Blažević: Yeah. Yeah. So if the error is about accessing a a path, for example, accessing a result, a previous JMAP result that does not exist or that fail, fails in cascade. It's like a cascading failure.
[01:04:11] Bron Gondwana: Right.
[01:04:12] Mário Blažević: But if you make a mistake here, for example, like, pdf view PFT. PFT. Yeah. And you get no results, that will be a failure. There's an error in the query that you were expecting to work. So the only kind of error that you can get from JSON path well, be besides not compiling that is a hard error is an empty empty results. So perhaps what we could but but the same also could happen with JSON path. But here is more complex because you're importing data from a previous query. So what we need to decide is what happens in that case. Either we set a property, how to deal with empty results, or we assume we we say empty results is fine as part of it. Because it's something also you can you can detect from the client side because if you are seeing that you're getting the attachments, you see that there are no attachments there, perhaps doesn't make sense to trust the following query. But, yeah, that is something to think about how to handle that how to handle, like, the a query that has not resolved because of a an error in your query.
[01:05:35] Arnt Gulbrandsen: Right. Thanks.
[01:05:36] Mário Blažević: Yeah. Sure. Yeah. But the the big question here is whether this there is interest to continue with this or if it's something that should stay proprietary. Yeah.
[01:05:48] Bron Gondwana: Neil, I saw you popped in earlier. Did you want to speak?
[01:05:58] Neil Jenkins: I was just going to try and help clarify for aunt. Well, basically, what I was gonna say is I don't think it simplifies your error handling at all, really. It saves some round trips, but doesn't affect your error handling. Certainly doesn't make anything atomic that wasn't full.
[01:06:17] Mário Blažević: Also, you were so your question, if it simplifies our handler, my my reply was how to handle errors. No. It does not simplify. Yeah. You just said no. No. It does not. It's it's just about this it's about saving round trip to the server, this extension. Yeah. Alexi.
[01:06:40] Alexey Melnikov: Sorry. Maybe not a super useful observation. I just had a with and forward without download in. So we which we played with it and found it somewhat useful, but not super deployed. I think some of it I find interesting enough. So maybe just leave the draft for now and see, you know, how people feel about it. So I wouldn't actively abandon it, but maybe people need to think about complexity of it. And, also, you have kind of two parts. You have JSON path as a, you know, JSON pointer and separately ability to use it in more places. You know? Maybe ability to use it in more places is actually more useful where the other one gives me a bit of a pause because of complexity, multiple values, and memory usage usage and all that. So
[01:07:37] Mário Blažević: Yeah. And also expensive queries. And Yeah. Exactly. So The the the thing is that sometimes the the JSON pointer is a bit limited for the stuff you could you need to express in these queries to make that Sure. And and also there is the draft is has a way to the server can say what it supports. If it's only a querying for from multiple places, adding JSON pointers, or if it's also support JSON path. So JSON path is an optional. It's not a must implement. Yeah.
[01:08:15] Alexey Melnikov: Then we have too many options, and people need to decide, you know, whether, know, you which one they depend on. So I I yeah. I don't know. I will I will just sit on it and just think about about it. You
[01:08:27] Mário Blažević: know? Okay.
[01:08:31] Bron Gondwana: Alright. Thank you. I think if there are no other questions, I think at least this doesn't it's not dangerous to have this the server can choose to support it or not and and make its decision. So, but the question is whether whether there'll be more than one implementation, I guess.
[01:08:49] Mário Blažević: Yeah. Yeah. That's something we need to say.
[01:08:58] Bron Gondwana: It's not dangerous to people who don't implement it that it that it exists.
[01:09:04] Arnt Gulbrandsen: Alright.
[01:09:08] Bron Gondwana: What's next on our agenda?
[01:09:14] Ken Murchison: I
[01:09:16] Bron Gondwana: think there's one more person before me. Yeah.
[01:09:21] Murray Kucherawy: Had
[01:09:25] Bron Gondwana: a Neil had a short thing email push. Do you wanna speak about email push, Neil?
[01:09:31] Ken Murchison: Okay.
[01:09:40] Ben: There we go.
[01:09:44] Neil Jenkins: Not a lot to say again. I think it's the same as last time when we were waiting for implementation experience. However, I do expect that by the next meeting, we will have implementation experience and hopefully can progress that to last call. So although that's been delayed a bit, I I think we will have progress sooner. Now that's about it. Unless anyone else has implemented it and wants to say anything about it.
[01:10:10] Ken Murchison: Anyone? Has
[01:10:13] Bron Gondwana: anyone implemented email push yet? Yep. Mauro Mauro raises his hand and says yes. Do you wanna speak about it at all?
[01:10:19] Neil Jenkins: Yeah. Do you have any comments, any concerns, or you're you're happy that it's it's good? In which case, great. We'll do a second implementation, then we can take the last call.
[01:10:33] Mário Blažević: The there was I well, I forgot already, but there was a thing about bun I don't know if you remember. We exchanged some emails about that bundling the the payloads. No. Sorry. The push. I forgot already. When bundling the groups of multiple email pushes so the push payload does not get too big, That was the only thing, but I think we found a solution or a common agreement or I don't know what was it was not about
[01:11:04] Neil Jenkins: I'd have to go check the emails. I don't recall any open issue on that, but, yes, I can look what we I vaguely remember the discussion.
[01:11:13] Mário Blažević: Yeah. Because I think it require a separate push per email push. Mhmm. And then we wanted to avoid breaking the previous push definition. I think I proposed creating, like, JSON calendar a type group that you can bundle multiple push types, and then we decided only to bundle the email pushes. That was the only thing we need to review.
[01:11:43] Neil Jenkins: I'll go review that again. I can't remember
[01:11:46] Bron Gondwana: what Yeah.
[01:11:46] Mário Blažević: But I think I don't remember as a pending item. It's the only thing that we discussed, but then there were no other issues. Yeah.
[01:11:54] Neil Jenkins: Okay. Thanks.
[01:11:56] Bron Gondwana: Alright. Thank you. I guess I should hop up and speak about my things. Unless you wanna go first, Alexi? Cool. On my way out of here. Thank you. There we go. It's gonna have to get moved down again. Alright. Thanks. Clicker. Awesome. Alright. I have four documents, that are all somewhat related, and I'm gonna talk about them in reverse order. That's the order that they were first published in. So conditional changes, I'll speak about first. At the moment, the only control we have for deciding whether something's changed or not is if in state, which is a very large everything with that data type has not changed at all, or if there's any change you need to resynchronize and then try again, which is fine if you are the only client talking to the server. It's not so good if you have a high churn dataset with lots of things happening because you will be sending it in state and failing all the time. So this adds disrupt adds a new, if unchanged by, patch object that you apply against the source object and say, if this if this patch would not change the source object, then nothing I care about has changed. And so you can narrow it down to just the specific parts you want to do a diff against and say, this has changed, I don't wanna go ahead. Otherwise, apply my change to whatever the current state of the object is. I've got a couple of examples here. One is for a file node set, and you say, if the old if the file still has the blob ID that it used to have, so it still has the content that it used to have, then I'm fine with replacing it with the new content and updating the modified and whatever else about it, whatever name it has, doesn't matter. So if a renames happen on the file, you don't care just as long as it had the same content. And the other one here is an email set, which is destroy this message, but only if it hasn't been marked seen by somebody else in the mean meantime. And that's the only thing that you cared about there. One thing other thing you can do here is if there's an etag type field did I say that here? Maybe on the previous slide. If you had something like an etag field in there or a modification sequence, you could set that and say, if that field's changed, then it's the object has changed without having to have changes across everything else. I think there's this pretty good mechanism. Have other people read the the draft? Do you think this is a a good way to specify what you care about for changes? Does it work? Have I missed anything? Is there any other I guess the should this be combined with anything else should probably be answered after we've gone through all these drafts, whether it should just be part of one of them. But as I'll have comment, but later, I will do. Yeah. We'll we'll okay. We'll combine it altogether. Let's talk about the next one. Object history. So this is the once you've deleted an object or if you change an object, there's no way to see what previous values it has. Again, we thought about introducing this for individual objects, but maybe this is a useful mechanism across everything. So we thought, again, it's useful to see deleted objects as well. There's a few different ways to do it. You could have patches against previous revisions. You could have full objects, either a sub things. The current state of this draft is that it just appears in the list of objects with the same ID multiple times and with a subcomponent inside each object, the other way around just to do it the other way and have the metadata at the top and then have the object as just a child key in that. So if you do it inside out or outside in. This is what it looks like at the moment. So if you're getting the history on a a contact card, you could have changed from Bob Smith to Robert Smith at some point, and you can see the time stamps, the replacements on each of these. So version one, version two. Robert Smith became Bob Smith in this one based on those dates. And then the current version doesn't have a replace date because it's it's what's currently active. And if there's none of them, then it's been deleted. Alright. Again, do we think this is a good mechanism? Is there a better way of doing this? Should it be combined all the all the regular questions that will go through all of these? Third one is draft-ietf-jmap-blobext. This has had a fair bit more work on it. It replaces RFC ninety four zero four. I originally wrote it as an extension that added additional fields and kinda messed around with it. But the big thing was that there was a blob slash upload, which was a set in everything but name, and it made it a weird wart. And so rather than patching that, I just said, let's replace it with a slash set like everything else. One of these we implemented and said, it's different enough. It shouldn't be a slash set and then looked at it and went, it's absolutely just a slash set and everyone's implementing it as a slash set. So this replaces the JMap blob that's already out there with a blob two, and it has lots of fairly powerful things to, like, IMAP catenate to allow you to slice and dice exactly to specify with any of the supported hash algorithms, what the digest must be of the content that's generated from that so that you can you can grab part of a blob and say it has to have this digest once it's all been calculated to make sure your calculations work. It also has extensions for resizing images. And for lots of other things, you can compress and decompress with whatever algorithms the service says it supports. You can make tarballs or zip files. You can patch and and do a diff operation to get a difference between two blob IDs, which allows for some really nice things. So if you have a file that's got a small change in it and there's already a copy on the server, you can just calculate your diff and then send that and apply it against the existing file. And then say that it must have the correct digest at the end of doing that so that you can compare with what you've got locally and make sure that you it'll work out. Couple of examples here. This is the diffing. So you say, I have this blob ID. I have this new blob ID, and I'd like a text x dash diff output from that place. And that will give you a new blob ID that you can fetch or be the content of the diff. And then you can apply that against the old version and, again, say it's a text diff, so use that algorithm to apply it. What I didn't add here was that you could then add, in the end, digest must be this, but that would be a useful thing to add as well. Again, anything missing from this? Are we ready for working group last call on Blobext yet, or do people want to make more more changes to that one? This one is an adopted document. Those first two are not. So, yeah, this one's already in progress. And then the final document is draft-ietf-jmap-filenode, which has had a lot of revisions. For a lot of the things here, metadata using Marrow's existing metadata spec is definitely the right place to put things there. Though for the the large sub data objects that things like Mac OS file system allows you to stash large amounts of data in its metadata. We might want to be able to support uploading that as a blob and referencing it from the metadata rather than putting the whole thing in there. And then, yeah, thumbnails are already handled by draft-ietf-jmap-blobext. Conditional updates was something I ran into needing for this, and it makes more sense for that to be a general thing. This has been live on Fastmail for a while. Nothing much is using it yet other than my Mac and Windows clients, which work okay. But there's a bunch of things. So, how complete do we want to be as a file system? Do we wanna be able to support everything that NTFS, SMB supports, everything that POSIX file system supports? The extended attributes for macOS that allow us to give a really good experience there require some place this is available on you don't need to take photos of You can download the PDF. Yeah. Anyway, and then the node type registry only currently has files, directories, symlinks, but there are additional things in the archive. So blobext specifies additional types that we don't support in file node. Do we want to support those, or how do we want to handle that? I think it's an an open question. Feel free to pop up now, if you want, or I can do the next slide and then
[01:20:57] Arnt Gulbrandsen: Yeah. Because I need to go. You have an answer there how complete do we want it to be. You want it to be as complete as s three is because all those other things are obsolete.
[01:21:11] Bron Gondwana: Okay.
[01:21:11] Arnt Gulbrandsen: What what attributes does s three have on the files? Not so much.
[01:21:17] Bron Gondwana: That okay. And you think s three is enough?
[01:21:22] Arnt Gulbrandsen: Cool. Well, people don't complain about s three. Uh-huh. They demand s three compatibility from their provider. Yep. I need to go. Sorry.
[01:21:29] Bron Gondwana: Thank you. Alright. I will I will take that note. Is there another person in the queue as well behind Arnd? Can you kick him out now that he's left? Ben. Ben, go ahead.
[01:21:40] Ben: Yes. So to use file node as a basement base for on mounting it on my drive, we have arbitrary applications writing to it. So they expect this random access to the file Yep. To read and also to write. And is that solved by your diffing thing?
[01:22:04] Bron Gondwana: Yes. Diffing or if you're doing range based rights, you can also you can upload use the draft-ietf-jmap-blobext combining. So you say copy this range from the old Blob ID and then put this little bit of data and then copy the rest from the Blob ID. And my server implementation does chunking on that, so a chunk that hasn't been touched just gets maintained, and whichever chunks have been touched get rewritten.
[01:22:28] Ben: Okay. So that does allow me to do random access rights and and reads with the range request,
[01:22:35] Bron Gondwana: you're saying? Yes. You can do range requests via HTTP when you hit the download endpoint, or you can also the blob method allows you to say, I wanted to just get the get a blob that is this this range and then download
[01:22:48] Ben: That was my wish list
[01:22:49] Bron Gondwana: Yep.
[01:22:50] Ben: Solution. Thank you very much. So you added that. That's perfect. Right? Yep. The there's one issue missing for me is if I upload something correct me if I'm misunderstanding this. I need several round trips to do this. So I need to first round trip to do the blob upload, and then I need it comes back, and then I can do the actual upload to the file node, and I need to wait basically for the round trip. Is that correct?
[01:23:14] Bron Gondwana: There's two round trips if you're uploading a large blob because you'll want to push that to the upload endpoint. If you're uploading a small amount of data, you can do it in line with a blob slash set and then back reference that directly. So, generally, for for larger amounts of data, you'll want to do a single blob upload and then get the ID and then use that.
[01:23:34] Ben: But for small rights, I can do that directly in
[01:23:36] Bron Gondwana: line? Yeah. For small rights. So we could do that for our sieve implementation in FastMal already. We use blob slash set with the content of it and then just back reference it directly rather than using the uploaded points.
[01:23:48] Ben: So if I have an SQLite database running on this, it will run efficiently?
[01:23:53] Bron Gondwana: Yes. Well, as as efficiently as
[01:23:55] Ben: As it goes on the network.
[01:23:57] Bron Gondwana: As anything goes across the wire.
[01:23:58] Ben: Yes. Perfect. Yes. We can ask them all. Do you have examples for all of this in this pack?
[01:24:04] Bron Gondwana: There's not heaps of ex there's not many examples in file note at all.
[01:24:09] Ben: If if you don't have examples, can you, like, all these use cases that are specified, can you make examples for this? Because not obvious at all. Yep. So if it is in your head, put it in there so because everybody, I think, will need that.
[01:24:20] Bron Gondwana: Yep. How wonderful is that? That's did I have that in my in my next in my last slide here? No. I did not. There you go. But, yes, more examples definitely needed. So the other thing here is that we don't have locking mechanisms for advisory locks to say, please don't mess with this file. I'm working on it, which a lot of file system layers again have. Do we need that? No. And finally, atomic swap rename from POSIX. Looking at this, there was there's no way to guarantee that the swap rename works other than a full if in state because one of the files could have been renamed and then your other rename would succeed. You can rely on if you if you're swapping them, nothing else has changed. You can rely on either both succeeding or neither succeeding. But if one's been moved, then you could get a rename without the other file being there. So there's a couple of possibilities here. One is if unchanged by only matches on the source, but you could have an if unchanged by on the destination as well. If I change the spec to say you're allowed to list IDs that are not allowed to have changed. And if we had a mechanism to say all or nothing, this has to all be true or we don't do any changes. At the moment, JMap set doesn't have that. But if we added a all or nothing property, then it would be all these conditions must be true or we don't try any of the changes. And I think there might be something that's worth doing and adding back to some of the other specs.
[01:25:58] Ken Murchison: Alright. Laura's in the queue. Let's go.
[01:26:02] Bron Gondwana: This is the end. The the the final item here was was just yeah. Do we want any of these things?
[01:26:14] Mário Blažević: Alright. Yeah. About the final, I think the only change I suggested that you kind of agree with is use the tag type for the at type.
[01:26:24] Bron Gondwana: At type. Yeah. Yep. Absolutely.
[01:26:27] Mário Blažević: The only thing. The rest looks looks okay. Yep. I I have implemented it already, the latest one fourteen. And and about your other two extensions, what I was saying is that what I wanted for JMap is, like, something for collaborative editing.
[01:26:43] Bron Gondwana: Yep.
[01:26:44] Mário Blažević: So, like, something that would allow you to have, like, a Google Sheets, Google Docs, and a lot of people working on arbitrary JMap objects. So what it will be nice is to have an extension that does all that, which I think both of your extensions trying to solve that problem differently. So, yeah, that was my idea. So having multiple extension have a really big one with
[01:27:08] Arnt Gulbrandsen: With
[01:27:09] Mário Blažević: the things we we
[01:27:10] Bron Gondwana: Alright. That that seems reasonable. The downside of that is, obviously, you have to implement the whole thing. You can't implement the the little pieces. But
[01:27:20] Mário Blažević: Yeah. That that's something.
[01:27:22] Bron Gondwana: Alright. I guess we'll keep talking about that during the week.
[01:27:28] Ken Murchison: Then? Just
[01:27:33] Ben: on the earlier renaming thing
[01:27:35] Bron Gondwana: Yep.
[01:27:36] Ben: A lot as if I'm mistake not mistaken, a lot of the Unix applications using that atomic rename as a as a way to protect themselves from changes.
[01:27:47] Rick Signes: Yeah. So they do
[01:27:47] Ben: that a lot. I think that might be important.
[01:27:50] Bron Gondwana: Yeah. But there there is another way to do that here, which is the if unchanged by mechanism questions whether they can use that.
[01:27:58] Ben: Yeah. But if you're mapping from a from a file system to this then
[01:28:01] Bron Gondwana: Yeah. You have to do have to do what they're doing on top of the file system even if it's not the the best way. Yeah. But we can get that with the with the all or nothing flag. So cool. Alright. So I I would like to call for adoption the the first two documents. After chatting with you, Mara, this this week, I guess I'll ask I'll ask him to do a call for adoption on them if if we don't decide to do something different instead.
[01:28:37] Mário Blažević: Oh, you got a link. I like the idea.
[01:28:39] Bron Gondwana: Yeah. Cool. And then for draft-ietf-jmap-blobext, I think there's not anything to add to that. It's already it's already pretty busy. And for file note, obviously, there's plenty of work to do there, including potentially another another document around the changes or some some updates to the state stuff.
[01:29:05] Robert Stepanek: So so which documents do you wanna do call for adoption on?
[01:29:07] Bron Gondwana: The first two. Object history and conditional updates. And I have some changes to make to conditional updates based on the the final things. And I will add the app type to file node, and we'll we'll figure out the rest. Cool. And lots of examples. I'll add lots of examples to file node on how how to use this thing. Cool. Alright. That's all my stuff, unless anyone else has any comments. Alexi, you're up.
[01:29:44] Alexey Melnikov: So it's quite good. Yeah. But kind of I revived my slides from a couple of years ago, so I'm not sure they are five minutes, but I'll do my best.
[01:29:56] Bron Gondwana: We've got eight.
[01:29:57] Robert Stepanek: It's in
[01:29:57] Bron Gondwana: the half an hour.
[01:29:59] Alexey Melnikov: Okay. Well, yeah, don't don't encourage me that much. Otherwise, I'll put you to to sleep. Right. So history of this. I had very simple draft in the working group doing a SMIME signing and encryption with just, like, three options. And then Philip came and ruined everything and said, let's make it more generic. So I wrote a proposal alternative proposal because, I wanted to kind of flesh out how it would look like. And I kept asking people for probably a year. You know? Do they have a preference? Do you have a preference? And then, I was not getting any answers, and then I I let it expire. I was busy, and this is coming back. So, it was somewhat useful to have a fresh look at this. So, you know k. So this is the original, which is very simple. You can sign, encrypt, or both, and you can say if it's signing that it's a back signing, which is a common option in this month. And there there were some extra query parameters for searching all those oh, yeah, all the sign, all encrypted messages texting. So this is what the alternative draft is now doing. It basically now have an array of operations, which each operation is an object, which is either, you know, sign and crypto and extended thing. And it's also have a bunch of options also as objects. The good thing I mean, so, obviously, it's more complicated to implement. The good thing that it's more extensible, more you can add stuff like SMIME compression, which is sometimes used as well. You can do things like sign and crypt sign, which is used in some environments with this. But as of previous version, there was also unspecified. You can easily denounce service because you can say sign sign sign sign, you know, 100 times or encrypt, encrypt, encrypt, and, you know, this is so now there is some text saying that at the moment, I'm limiting chain to three operations. Maybe it needs to be four considering encryption, but compression, again, if people have opinion, but I think having some limit would be useful. It's also incorporate header protection, which is more recent S/MIME RFC. The other thing done is there was a way to decrypt. So there is a new command for decrypting and then doing something with it so that there is also an session on the receiving side. So some of these questions might be obsolete. And considering your blowbacks changes, maybe I I shouldn't go this way. I don't know. Maybe mail is my decrypt is fine. It's kind of make it more regular with other objects because it's a one off operation, but maybe it's just the way it is. Yeah, if people have opinion. But now
[01:33:40] Bron Gondwana: No opinion. Oh, wait till you finish.
[01:33:43] Alexey Melnikov: Do opinion on this now.
[01:33:45] Bron Gondwana: Right. My opinion on this is that this does look remarkably like all the other Blob conversion operations. Yes. And so it makes sense for it to be a blob slash set convert operation built on top of the existing blob mechanism. Once the existing blog mechanism gets published. But I think I think it might be given given the speed at which you've been doing this, I think I'll be I'll be done first. Well,
[01:34:14] Alexey Melnikov: that's the part that actually kind of scares me because of like, if you're doing all of it, then you have to do all image resizing and other bits and then, you know so No.
[01:34:22] Bron Gondwana: You don't. You because you can specify which bits you support. It's it's very, very flexible. You just you just say, I have an array of zero types of image conversion I do, and then it's not supported.
[01:34:36] Alexey Melnikov: Okay. I I think I'm encouraged by your comment to base it on Blobset, but I'm still a bit scared of Alright. draft-ietf-jmap-blobext. It might be just going a little bit too much. Again, I'm up convert. Up up. We did this and I'll buy you
[01:34:56] Bron Gondwana: a drink and persuade you later.
[01:34:58] Alexey Melnikov: Oh, that okay. Well, maybe maybe I just didn't know something. I don't know. Okay. Right. So I was kind of trying to demonstrate coloring is probably all wrong. The bits on the left in yellow is the old way. The on the right is the new way. So you have two operations here, sign and encrypt, and you have one of the options is OPEC. But you can also add, like, suffers use and, you know, various parameters of you know, to control how how you want to do operations if you want to. So I might have said this more than once, the old way. Simple, not super extensible. And the new way is more flexible, but, you know, less simple. So because unless people want to shout one way or the other somebody was encouraging me yesterday saying, because I am editor, I can just just do a change and then see if anybody screams. I said, well, technically, it doesn't quite work like this, but, I mean, I have some sway. So my suggestion is I will just post this more advanced version as a new working group. And if people scream at this point, then we'll can discuss. I think that's it.
[01:36:30] Bron Gondwana: I'm in favor of doing what you say on the slide.
[01:36:34] Alexey Melnikov: Okay. Wow. I got input. Other than Philip, you know, I'm I'm grateful to what Philip already told me. So thank you.
[01:37:01] Bron Gondwana: I think that's all the material we had. The only question is any of the the parked documents from either of the working groups. The Calixt had four parked documents, and Jmap also has a bunch of parked documents. Hansjmap, did you want to speak about the Jmap ones? Because I think they're mostly you adjacent.
[01:37:23] Hans-Joerg Happel: Yes. So this is Hans York. Yeah. So I think the majority of those is a little bit specific to usage we had for, you know, debugging and migration use cases. So I think so far, nobody has expressed usage for it. So I think that makes sense. I think they are not completely useless, so I think there was a reason also for proposing them. I think, also, I have in mind the REST one appeared recently in some context. I didn't expect it, but I don't remember which one. So, yeah, I think these are obviously not in the priority right now. The task thing is still on my agenda. We are currently in the process of reimplementing or updating our tooling for the updates we have seen recently in the other draft. So as soon as this is done, I hope that also we get more to that task spec. And, actually, I have a a question for the room on top of that because I think we have been discussing, I think I think about something like preferences things, which might be some more future stuff. But two further things that are missing on the set yet is something about notes, for instance. So I would be interested to understand if there's any feeling in the room or how people currently deal with, like, you know, personal notes with in JMF implementations, if at all, or what's a feel about it or so on? Because I think that would be one natural thing also for us in order to because we use JMAP as an abstraction layer also for, you know, migrating legacy stuff. We reference that within the mail made PDPA personal data portability archive thingy. So that's certainly something on my mind that might make sense to to think about. So and I would like to share ideas with people interested in that. And, actually, a further thing we are currently working a lot with is chat messages. So, I mean, we are I mean, probably the idea is not probably to make JMap a chat protocol or something like that, but for probably having an import export format, which we could also be using in the PDPA. Maybe it's just okay to use EML mail files for that or so. But if somebody has some opinion on that, I would also be interested.
[01:39:53] Bron Gondwana: Okay. Alexi here.
[01:39:56] Alexey Melnikov: Being somewhat devil's advocate and somewhat serious, you can use metadata to use to store notes.
[01:40:04] Mário Blažević: Yeah. Yeah. I mean, you can
[01:40:05] Alexey Melnikov: So so there are other ways of, you know, what you're asking for to to be done with I mean, obviously, metadata is more complex as a as a as an extension. But
[01:40:22] Rick Signes: Rick sickness, you could use metadata or you could use files. We we implement JMAP. We implement JMAP for notes. It works fine. I think that you don't need a special data type for this. I think that using files in a format that stores the kind of text you want will do better. Like, you you can store HTML. You can store markdown. You can store whatever you want in files, and you can have a separate account or a separate data group for just notes that's restricted that way. I think you'll have a better time in a specialized data product, the specialized data type. That's just that's my opinion.
[01:40:58] Arnt Gulbrandsen: We can
[01:40:58] Rick Signes: talk about it more later.
[01:41:01] Hans-Joerg Happel: So, Hans, you're gonna appreciate the feedback. So that's exactly what I wanted to to hear. I mean, just to give some context, I mean, we are so what I'm observing right now is there's a lot of, you know, notes tools moving towards some sort of a block notes style or what, you know, some tools like Notion and so have. Obviously, you could also do that in a file, but at some point, probably, that might get a little bit tricky to stuff everything. I mean, with that argument, obviously, you you wouldn't even need JMap contacts or stuff like that because you could also do it in a in a file.
[01:41:32] Bron Gondwana: But yeah.
[01:41:38] Ben: I have a book for Parula. This I Ricardo's commenter had the same idea, and this precedent, like, notes app for Nextcloud is just using TXT files on the storage there. And I like that because it doesn't make me dependent on this app. I can just use any other editor for this, or you could use MD files. My main issue would be where do I store that because I don't wanna do a directory, which then is visible to the user when he's browses the files. So that would be something for file note that I can have, like, a private thing that is for my app or for a specific purpose, which is not files to display to the user in the same way that we have with IMAP, like, all kinds of IMAP clients are creating folders, and they show up, and I don't want that. So so there needs to be a way to say this folder is for a specific purpose or something like this. The other note, a task, however, I like, if this this if this this is not solved by today's calendar, then if not, then this definitely needs is needed. Yeah.
[01:42:57] Rick Signes: This is Ricardo again. As for tasks, it is solved in air quotes, solved by JS Calendar, but what JS Calendar solves is the representation document for a v to do, which is the JS task, but we don't have a JMap API for managing them. I think that we can have a pretty minimal one that could be put together and cover everything you can currently do with Caldev. The the draft that I saw earlier from Rodriguez covers quite a few more cases because it's for managing portability of data for more complex task systems. And I think that what we wanna get to is a minimal JMAP for task lists core that can be extended with the other data. And that that will give us compatibility to legacy formats as well as the path forward. That doesn't mean implement the whole kitchen sink.
[01:43:59] Ken Murchison: Any other comments?
[01:44:02] Bron Gondwana: K. You wanna do? Then I think, yeah, we're up to milestones now unless there's anything else anyone wants to talk about. Fantastic. Alright. Milestones for JMap. Let me get the page up first so you don't get to watch me navigating through my browser. Edit milestones. Here we are. Alright. draft-ietf-jmap-blobext was adopted. Done. Submit file note document to ASG. That is gonna be kicked out to November now. Adopt a document for JMap server settings. This Alright. Didn't happen.
[01:44:58] Mário Blažević: No. Because I believe it I don't
[01:45:01] Ken Murchison: know if I should call.
[01:45:02] Bron Gondwana: Yeah. Come on. Come on up.
[01:45:15] Mário Blažević: So jmap for server settings. I don't know. Has your oh, yeah. There. If you remember, there was we were supposed to work on this one together. So it it is something that is installed where it's already present, but if not, it's a proprietary extension. So it's a standard way to store and access and set common properties that you find in most servers. Not only server properties, it's also, like, account settings, like, a time zone for a user or language or encryption settings at rest. And, yeah, that is something that could be useful to, yeah, to some clients wanting to allow because if you if you don't have this extension, each mail server needs to expose web interface so users can configure those common settings. So this allows clients to modify them. Yeah. I guess there is if there is still interest, we can I already have that working? We can propose
[01:46:30] Bron Gondwana: Alright.
[01:46:31] Mário Blažević: Something. Yeah.
[01:46:32] Bron Gondwana: So I put an action for you to publish a draft.
[01:46:43] Robert Stepanek: Cool.
[01:46:44] Bron Gondwana: Alright. Back on the milestones. We I guess So August. I don't think it lets me rename it. So it's gonna be called server settings, but then it'll we'll call it something different when the document's adopted. Alright. Submit draft-ietf-jmap-blobext. Hopefully, that will happen shortly. Submit SMIME extensions. Alexei, when do we wanna say that happens? Christmas? Yeah. Well,
[01:47:28] Alexey Melnikov: now that I revived it, it's kind
[01:47:30] Arnt Gulbrandsen: of easier to do. Cool.
[01:47:33] Bron Gondwana: Alright. Let's say December.
[01:47:37] Mário Blažević: We're planning to work on BGP.
[01:47:45] Bron Gondwana: Jmap tasks.
[01:47:47] Hans-Joerg Happel: So as we've probably said, there's certainly some key required before really and especially for submitting it to the.
[01:47:54] Bron Gondwana: So February next year? Yeah. March next year? I'll say March. Submit it in Mumbai. And then email push documents. I think we should be they said October. That should still be good for that, hopefully, with implementation experience. And then, I guess, we have adopt-jmap object. History doc. And we have dot yeah. What do they call it? For August, and I have submit file note. Let's go. Gonna kick that off towards the end of the year, I think. That's still got a bit of work to do. Anything else we want to have on our milestone list? I think I've got file note there already.
[01:49:32] Mário Blažević: The last call for our for our mail sharing?
[01:49:38] Bron Gondwana: Oh, yeah. That's it.
[01:49:49] Alexey Melnikov: August.
[01:49:58] Ken Murchison: Alright.
[01:49:58] Bron Gondwana: Anything else? Alright. In that case, we're done with ten minutes to spare. Thank you, everybody. See, as the last slut says, in San Francisco.
[01:50:25] Ken Murchison: Stickers available upfront. Just a few, though.
[01:50:37] Bron Gondwana: We share. See you at the dinner. Alright. Cool.