Internet Engineering Task Force 105, 26 Jul 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF105-JMAP-20190726-1220

Description

JMAP meeting session at IETF105
2019/07/26 1220

https://datatracker.ietf.org/meeting/105/proceedings/

A

A

B

All we need is I can do actually I can do the Jambo.

C

But but no taker is important.

C

A

Right I know it's: it's.

C

Gonna be rough to do that.

B

It does make it does make me wonder if this working group should ever meet in person again it may be that we don't need to that. The mailing list is sufficient.

B

We can, we could always.

D

B

Could just say we'll meet in the isg room or something like that.

B

Okay, we're now up to five people plus a chair in the room. That's that's really exciting.

C

And it's time start yeah, let's, let's get started because I have a plane to catch so good afternoon to everybody and welcome, welcome to the ultimate session of the IETF 105 and can I figure out how to change the slide even with the keyboard. No.

E

F

C

I made it fullscreen whoops, it just changed a bunch of times. What's going on. This is very strange. That's about five slides back.

C

D

C

D

Got to know well.

C

Okay, well we'll.

G

Do it this way, Wow.

C

More people yay.

F

C

So, presumably, by at this point in IETF, everyone has seemed to note well, and so what we're gonna do is good, heavens, Wow, that's saying things slow kind of go through document status and stuff like that, and then each of the active working group drafts we have a presentation on each of those.

C

So congratulations to everybody that was involved in J map core.

C

So it is now RFC 8620 J map, Noah.

H

Witnessed applause I've ever.

C

I

Let's do it again, congratulations.

I

Arguably I'm fixing stuff in it so yeah, so the another one is imminent. Basically, we are waiting for our scheduler to post new okay, oh okay, fine, okay, I'll I'll! Do that them I.

J

Just wanted to say this is Neil Jenkins. We do have our first day roster for Jame up cause. Well, what's a minor issue in the JSON in one of the examples.

I

Yeah yeah, that's exactly what what I said. You know if there is no writer nobody's bothering curie to implement. So that's not necessarily a bad thing, but, yes, you might be able to start on the base document right away.

C

And we've already got an errata item right.

C

I

I'm District I'm.

C

Distracted by all of it, although the cool cool, new toys and red buttons up here so sorry, okay, so Jim at male real soon now and we're gonna talk about calendars, WebSocket, s/mime and MDM drafts that are that are currently there.

C

So, let's start with WebSocket and let me see if I can figure out how to get this thing out of full screen. So I can check.

C

In WebSocket yeah here we go.

A

Okay, web second I think this is getting pretty close to being fully baked version. Oh three I published early earlier this week. Most people probably saw Oh two was one small change which I'll get into as we move along here.

A

Oh really, it works that way because here's the list of changes since the last IETF real quickly so I renamed one of the capabilities. That's mostly just for cosmetic purposes. The originally I had set up the push capability to be a query parameter on the URL that has been changed to its own separate true/false capability.

A

We added a @ type argument to the request: object, which means that all the objects going to and from the server all have a type so that the client and server knows what it's receiving quite quickly and we I say added a push state argument to the state change object. I will get into that in another slide and finally, we added two new objects: a website could push enable and disable disable is what was added an oh three. The enable was in Oh next slide. Please, okay, so Ford notify take no notifications, discovery.

A

There is the new capability supports. Websocket push put it in bold, so everybody knows what we're talking about very, very simple: true/false property I. Don't think, there's any reason to argue or discuss that next slide.

A

Please so enabling push notifications here is the new object, very simple: it has the type you list, the data types that you want to receive from the server in an array, and the last argument is the last overall state that you received from a push notification from the server, so where this is useful is if you're reconnecting to a server you can give it this state, and presumably this server would then push all updates from this state up to the current states.

A

It's a quick way for the the client to refresh his cache and get up to date. Next slide, please here's the notification format, which is identical to the state change object document in core with the new push state property at the end, if the server can support an overall state, it would include this on all the notifications, so the desert that so the client knows exactly where everything is at the next slide.

A

Please and finally, a very, very simple object to disable notifications if the client, for some reason, don't like what wishes to receive them, that's pretty much it in this draft. Anybody have any questions or comments or outstanding issues with this, as.

J

Neil Jenkins Sara, yes, I've, read this I think is some looks fine and ready to publish just one quick comment on that push date thing: it's basically analogous to the last event. Id thing: that's already built into a server sent events, events halls, which is the way you connect push without WebSockets, so it's just giving you the same functionality over the WebSockets bread's yep yep.

J

A

I personally, I think this is ready for a working group last call I. Don't we put that up to the list Jim? How does that work? I.

A

C

Know I have seen I, don't have a lot of context, so let's ask Ron but I think I think probably just send it out to the list. Okay sounds good.

A

Okay, great just a point of interest. This actually other than the push stuff is, has been implemented in the server side, at fast mail and in the cyrus server, and hopefully we will start to have a client side, at least for testing purposes fairly soon, so hey. Thank you. Thank.

C

You, okay next item is.

C

C

And that will be Neil and I'll train keepers. My decentered.

K

C

J

That's better come on okay, so I published an initial 0-0 draw for this a while back. That was pretty basic, there's still quite a few things to add so I'm going to give a quick overview of what this is trying to achieve. What the general data model is and then talk about something open issues and see if you've got any people in the room or on the meet echo that want to put forward some opinions on those issues. So we can go to the next slide.

J

Please so Jess calendar is giving a way to access calendar data over J map, so it's kind of an equivalent CalDAV much like J map mail is an equivalent to IMAP, but like in that equivalence, more efficient, easier to use more consistent, there's a single setup point and you get access to all of the different bits of data without having setup separately or email your calendar and eventually we'll do chairs no J map contacts as well.

J

This is just calendars not trying to do tasks or journal entries, which you can do with card out, but is rarely actually part of the same system. In practice, so doesn't actually I think main since necessary between the same document, you can always add that, as a separate J map extension with its own capability later and just like with the male spec, we want to be able to provide access to the same date of are both CalDAV and J.

J

Map Kalen doesn't have it be a consistent view so that you can use both clients at the same time and there's not great paths, because nothing can is going to be able to cut over overnight.

J

So, yes, we don't want to radically change the data model, so that's not possible we're going to use jazz calendar for the event data model. This is in last call over in collects its JSON representation of calendar data. That's much nice to work with it's again, hopefully, an eventual successor to iCalendar. It's if you've not seen that go, have a look at the calyx stuff if you're interested okay, let's move on next slide, so just quick overview of the general data model.

J

So an account here is a J map account which is kind of a consistency model. It's saying within an account: you have properties that must be enforced like unique IDs within that account and be able to do certain things as transactions within an account where there isn't that requirement across accounts.

J

So you have an account that represents calendar users. So in a shared system you might have an awful lot of these. This could be an individual. It could be a resource, it could be a location, a room. Anything scheduled you've build query this with standard J map methods, so that you can, for example, query for search for a room. If you have permission to see that and then from there the calendar user object gives you an account ID where you can fetch the calendar and the events to see all query the availability on that resource.

J

So yes, so if you have a simple server, it can can just support a single user. It doesn't have to worry about the calendar user stuff or anything. You just get the calendaring calendar events data, but for anything, that's doing more sophisticated shared use. The calendar calendaring you'll have this kind of top-level directory of calendar entities, which then reference. The different accounts for the actual calendar data for that entity. That's the demo overview. It's anyone have any comments or stuff. They want to say on that.

J

I think this Maps fairly cleanly to Cal dev. If you have an experience with that, the calendar users are different principles. Is that right, Ken and then yeah. The calendar data would be within that, but.

C

In Calif, I have a question: how are shared calendars handled, how a calendars what's right, I miss? How are they handled these? You know.

J

C

Use disjoint calendars: yes,.

J

So an account is the kind of a data consistency thing like you can only have a calendar event with a particular UID can only exist once within an account, but it may exist in different accounts. So in this example, maybe the accountant left is my calendar data and the one on the right corresponds to Ken's. He could share access to his data to me so I could see both accounts and I can, but I might look at their sharing.

J

Permissions are done on a per calendar basis, so he could share one of those calendars, but not the other one, for example, or you could share one vide only and one just read free/busy so I can see these busy, but I can't see all his information. So my sense yes.

J

Okay, so I'm just going to some of the open issues here, see if there's any news in the room, so we've sanded GMAT methods, you have calendar event- is a datatype which represents an event and you'll be able to get it by ID, and normally you can fetch changes which tells you the IDS of objects that have been created, update or destroyed.

J

Since your current state in the client we're going to want so there's a sophisticated calendar, clients will be able to get an event that has a recurrence, rule and recurrence exceptions and just expand that itself in the client to know when it's actually, the occurrences are but I think that we want a option when you query the events to ask the server to the expansion for you, which will allow very simple kind of probably not hole clients.

J

But people just want to integrate with calendar data to be able to not worry about some of the more complicated bits and still get the data they need. So the question I have is whether we want to also let they have some kind of mode that lets you get the changes whilst having the expanded events. So the trouble is there could be infinite, expanded events, so there could be an infinite number of changes if you change you're going event and you're fetching the expanded ones.

J

So the only way I could think of this working was, if you had some requirement that the IDS of single of occurrences are the prefix of that ID is the same as the ID of the master thing master event, which would then come through in your / changes, but pretty expensive processes. You have to not just do a lookup but scan everything for prefix matches and also breaks the idea that IDs have no semantic meaning to the client.

J

So I think my inclination is just to say: if you're asking the server to expand events, you don't get Delta changes. You still know that something's changed, because, but at that point you just have to evaluate your entire case and ask again. This is probably gonna. Give me simply simple clients anyway, so I don't think we too much data anyone. Someone stepped up yet Mike.

L

E

L

I'd say CalDAV has a form of expanded query, but it's pretty useless. Actually it. It assumes that the client could do almost nothing and, for some reason, turned everything into UTC and things. The the expanded query I would like to have seen is one that treated the instances, essentially as as I as a separate event. You know a fully populated event that looked much like the master event, but with the appropriate time and date in it, but we I my recollections.

L

We put that in assuming that we would have some really simple client at the other end. That could do almost nothing and, in that case I think I. Don't think we need to worry too much about this infinite changes thing. Are you delivering? The events is probably enough. Yeah.

J

Thanks Mike, yeah, I, agree and certainly in terms of the options I plan to add is yes, you can ask the server to expand events, and if you do ask it, you can optionally also ask it to change it to UTC. If you don't want to deal with time zones as well, but that's optional, so you can get them with the time zones but expanded. If, if that's what you want, which I think is what you're asking can can.

A

Register I agree are.

J

You an having expansion.

A

Done in changes it seems like it might be more apropos to the query method. Show me: the expanded results within a certain time period kind of thing seems more useful than having it expand. A recurrence rule just because I changed the title in a never ending event.

J

Yeah sorry, I, I, think yeah I think maybe kind of consensus here that we don't need. If you, if you're doing, expansion on the server, you don't get the exact changes, whereas if you're, not it's it's trivial to do the actual changes like we normally do in J map. The way will work. Yes with expansion. You'll do a calendar event, query and say: expand this, and the IDS will get back will be IDs for the expanded events rather than for the master event. You get multiple ones.

J

You have to time range the query: if you're doing expansion, you can't obviously ask for everything cuz it could be infinite and then you just ask those IDs or the standard get and it will serve return. You like Mike, said the full event as though it were, that instance of it with the right date and everything.

J

Okay, I think happy that let's move on to next one, what was this? Oh yeah, okay, so the calendar event object is representing an event and, as I mentioned at the beginning, this is basically a giant object, which is data format puts in last call and almost finished, but there's a few extra properties that specific J map on it. Its ID, which is its ID within J map, calendar ID the idea the calendar it belongs to and possibly will let you request.

J

Utc start, which is what we mentioned before the server would calculate what the UTC start is giving current times and information. Obviously we don't store it as UTC in the server, because timezones can and do change at any point. But if the client wants to request it, they can ask for what it is given current information, there's, no we're not expecting the server to market has changed if times and information change. So anything like that, though this is, can be clearly marked computed property.

J

So, given that we have these extra properties to add, but J's calendar can be extended with arbitrary action properties, we have a kind of name spacing issue because they're all in the same namespace, so I can't see two options here and I. Think what's been suggested to me is the, but the best thing is guest calendar will have a registry of property names and we'll just reserve any ones that we want to use within J map so that they're not used in Jeff's calendar.

J

And so, if you see those that came up, anything else is Jay's calendar and just gets written straight through to the object. The other alternative I see is we define exactly which ones we expect we jairs calendar and you have to prefix custom : or something to access the others, but as soon as I heard of the registry idea, I was like. Oh yes, that's that's, probably much better way of doing it. So that's why I plan to do is anyone got any comments on that I see general nodding in the room for the registry?

J

Yeah, okay, I think that's straightforward them.

J

So from move on to the next shoe okay, so this is just a kind of a query should we allow an event within an account to belong to multiple calendars in that account, so this is kind of treating the calendars more like labels and folders, if you like, so a bit analogous to how you can do that with mail potentially, if you want to with with gamer, which is a bit more flexible and powerful and I was kind of thinking that I liked the idea of the symmetry but I think overall I.

J

Don't think this is a good idea if we scroll down as a few more cons here, one of main troubles is calendar. It belongs to us various properties like what are the default alerts. This calendar, it's quite common, to have different ones for different calendars. What's the time zone for this calendar potentially and ACLs, and so if an event is in multiple, for example, do you get the alerts from all of the different calendars or just one? It gets a bit more complicated, and the kind of the bigger downside to me is just that.

J

No one seems to be doing this even with their own proprietary models, so a it's going to be harder for existing clients to adopt game at calendars. If this is something in there and secondly, actually is there any demand for this, or is it just more complicated and it seems adding complexity when there's no demand is and the biggest con as well? Potentially, it doesn't actually map very easily to CalDAV, because Cal that doesn't support this and explicitly.

J

You cannot have the same scheduled UID in different calendars in the same accounting, car dev, but run your I think more proponent of this yeah.

H

You can have a non-scheduled UID in multiple calendars in Cal dev, but.

E

One of the one.

H

Of the big issues is that this does kind of map Pakal dev or the related issue with cal def, that if you move something in a client, the client then has to calculate a move command on the server rather than being able to upload the new one and then delete the old one or you've got a race condition where you have to delete the old one.

H

There's a bunch of different ways in which you could wind up with the data in two different calendars, so I think it's it's cleaner and clearer, and the server can always just reject an attempt to set multiple calendars if it doesn't support it. I.

J

Didn't quite further, but I I mean I, think I got the UM you are still in favor of having support for multiple calendars for an event. I wasn't quite sure why I mean J map to move it between counters is just an update. The calendar ID property. So it's very simple and it's a single command there's no create and then destroy. Yeah.

H

But a Cal dev client talking to it. Similarly, particularly because something could wind up with the same ID I think you could reject an attempt to set something with the same ID that has different content in a different calendar with this already exists. But if it has exactly the same content, it should just become a second calendar ID, because that way you it's easier to recover from data being restored into another calendar. That's in the same namespace and a bunch of conditions like that.

J

How would you map that to caldo, though, like if it's a scheduled event, you're not allowed to do that in Calif,.

H

Yeah, if assuming the server, actually enforces that restriction right, you would. You would then enforce the same restriction if was a scheduled event, but we certainly we've run into issues with our implementation and clients that don't like the idea of an event not being Eldar exists in multiple calendars.

H

On the Cal dev level will.

C

Keep Bron there but also recognize Ken. How about that yeah.

A

Ken Murchison so Ron, when you say our clients, are you talking about our our UI or actual cab? That Cal deaf clients have the problem not challenged Calvet.

H

Plants having issues talking to our CalDAV server, that it rejected the event being credible hopeful telling us, because they would try and upload it when accounting for deleting the old well other than copy of fun. Things that I remove I mean the fact that the copy command exists. Lf, you can't use it within a one account.

A

Yes and our server disallows it for the the reason Neil mentioned earlier, that with scheduled events, they can only be on one calendar, yeah.

H

That would be k-map compatible, I.

A

Believe, other other vendors do the same thing. One UID per users set of calendars. Now, if you got something shared or whatnot that might change things slightly, but I'm not sure with the use cases and maybe I'm, just a dunce corrected.

H

Discontinuity between, because you can have the same event on account of the shed into your space for another user, but you can't have a the same event on two calendars within your own user. The.

B

Use cases mrs. Barry the use cases I share a calendar with you and I share a different calendar with Ron and I. Want you both to see the same vent so I put it in both calendars. So it's in.

K

B

Of course, that's that's a contrived use case, but if you make it a little more complicated, it's a real use case.

A

It's somewhat contrived, but yes iced. It is based in reality. It's like I can kind of see. Maybe.

J

We'll take this one to the list, then, and see. There's some wider feedback, given that I think I'll be to me, will not currently in the room that have opinions that someone else wants to speak.

J

C

L

Was just trying to history as I recollect? The only reason for the restriction was that at the time, Cyrus and we're afraid didn't want to have to limit your scheduling to a specific calendar. They want to do a search for the UID across all your calendars to find it, but it does it promises. It is inconsistent that all over the place, you can have multiple events of the new ID yeah. We have this one restriction.

J

Yeah I mean J map I, think already is gonna. Have a restriction of a UID can only exist once anywhere in the account, so that kind of avoids.

J

L

J

Has shared is a different account. It's.

L

The client wise it's the same, it's the same deal. It looks the same in the end, yeah.

J

The client may want to merge those in its display. It's true. It's the same day to initiate.

L

The product that they use, what what ended up happening was that we end up with all the same problems because of sharing and instead of solving those issues up front so that you could allow for the possibility of the same event. Turning up in two different places. It was pushed out other way and said: oh won't happen and then sharing came along and it did happen. So.

D

L

Mean there's all sorts of reasons why it might happen you might as well I. Think Bronk mentioned one. What if you import a whole batch of events, so we're gonna filter every one of them to make sure saying the UID doesn't turn up.

K

This is Daniel con Gilmore at the mic here. I just want a second. What Mike is saying: I regularly run into this problem, not via J map, oh just with the calendar files in a calendar client where I import an event and then I move it to a different calendar and then I get an update about that event. With the same UID and I import it, and then it's got a deal with the fact.

K

You've got two things with the same UID but they're in different calendars, and then I try to merge them and they're different, because it was an update. These things happen in the real world. Yes, yes,.

L

And I think the problem will all arose, because, because sorry I wanted to simplify the world right down to something really easy to deal with. Unfortunately, the world was more complicated than that.

J

Okay, I think we'll take this one to the list afterwards then, and write up a bit more and because I think this. Yes, definitely people not in the room on right now that will have some opinions so I. Consider this one unresolved and move on is that there's.

C

Enough discussion that it could be have it on the list.

J

Yeah: okay: let's go.

J

Okay, so this is so the moment you get main you just get push. Events for state changes on the server, but obviously current events can have alerts and clients can calculate when those fire themselves, but again for things like web hooks or various other integrations will just less sophisticated clients might want the server to be able to calculate.

J

When should this alert fire and just push an event to say, hey this alerts just gone off so firstly, so if you did that it's not a state change event will have to define a different type of push event. That's okay! It's already got a type on it, so we can extend that to push different types down.

J

Is this something that we think should be added to the spec, the ability for the server to push when alerts fires to clients? And if so, is this something that's just a mandatory part of the spec? Or is it a separate capability, I? Think of my two main questions and then there's kind, some kind of syntax Oh question over how we set it up, but that's not actually that important. We can work that out.

J

So my question is: yes: do we think that's a capability that we need in servers and is it a mandatory capability or optional one? Anyone got I need someone's.

C

From the floor with a virtual floor.

C

It still slow, okay,.

H

Sorry, my button with yes I can just turn myself on, but I thought I'd be polite. I think this is the kind of thing that it's it's actually perfectly fine to be in a separate capability, because it requires the server to have to keep track of alarms, yeah.

J

It's quite a long time to do this. Yeah.

H

I I, don't think it's a bad thing to put that kind of thing. In a separate capability we built a nice powerful capability system and I saw the discussion about extension mechanisms. Rusting shut, says as I. Don't think, we've got into any risk of our extension mechanism, rusting shut, but this it's perfectly fine for this to be a separate capability and then it's not mandatory and everyone's happy.

J

A

It is a lot of work for the server I. Guess my question will be: will the clients even use it are? Those gonna do deal alerts on their own anyway, it's kind of like the whole time zone thing. We push time zones the clients to throw it away immediately and do their own thing. With this, be it's in the same realm I don't have the.

J

Answer I'm just asking.

A

J

It's good question: I, don't know I I, see in the generic case, having probably more people interested in using it for I, said kind of like web hooks. So if you do it create a push subscription on the server and it does a call back rather than pushing that directly to a client. It does some other action, and so you can. You could use this system to like if this, then that kind of thing trigger when an event alert fires, it does some other arbitrary thing off somewhere else, potentially but yeah.

J

It's a bit hazy as a use case. I give you.

C

Okay, Mike go ahead.

L

Sounds like my argument against doing too much with with all arms and things, because the actual thing that's raising the alert probably needs to know much more about where you are, what you're doing and all the rest of it. Then the server is going to know it just doesn't seem a very useful well.

J

The thing that receives it wouldn't have to actually do anything or show the user anything.

L

No, but if it's not going to do anything, I mean, for example, if you're, if you're 20, minutes away for an event and you've got an alert set for five minutes ahead of the event beto. That is absolutely no use to you. You want do you want the alert, 20 minutes in advance, and so you better get moving to get to the event.

L

So it just seems a not an enormous ly useful. hmm Yes,.

J

L

Least, felt for for regular alerts for users, I mean I can see, maybe in process control or something like that kind of thing, which is not too far-fetched, but so.

J

Maybe we don't want this in the spec at all, then I don't know if it seems.

L

Much yeah I've been client put it off. Yes, I think it's probably going to end up not being used much.

J

A

And this is kind of say we leave it out of the core Jayma accountant, respect and if somebody comes up with a valid use case or strong need, we'll use it as an extension yeah.

J

I mean giving it clearly would be a separate capability. Anyway, almost doesn't matter if it's in its own document or a separate document. It's much remoteness and the.

L

Other way of looking at it, of course, is even if you're doing a server-side, it's essentially having a client on the server just handling alerts.

J

Okay, I guess I'll leave it up for now, then, which makes life easier and if yeah, someone really wants, it will. Okay, it's at the document for it. Okay,.

J

So we need to be able to send high-tech messages for scheduling when you do certain things like you create an event that has invitees. This is how interval scheduling works so I think the main question is whether these are just sent implicitly, because you create an event with them or explicitly I. Think J map style definitely tends to be a bit more explicit. But if it's explicit, how explicit is it just an argument to a calendar event set to say, send I tip and anything that any change you make? That should send 90 thing.

J

The server works out, the appropriate thing send and sends it, or is it actually more explicit than that where the client says do this? Do that in some more precise way,.

J

If that makes sense, that's my me.

L

Yeah, it's me again, yeah my whole problem with with the I tip thing about, when how you send messages is that it it? It says it has sort of wording like send a message when something important changes well. Well, who makes that decision? You know if you change, if you change in a location universe to another room in a building that may be extremely important to one of the attendees, it's not up to the to the organizer, whatever to decide.

L

What's important and- and so my feeling has always been, that any change or to be transmitted to the client see a the question is: does the client bother telling the user that something's changed and that's much easier to determine at the client end that the at the server side or the originating side? Yes,.

J

Except for I'm, it messages often will end up in the users mailbox, which is why, on this miss Trixie, wait.

L

Isn't that isn't that just a sort of an implementation issue, it.

J

Is I think the main question here, though, is probably exactly what misses to send. We can't define exactly because it's going to depend a bit on what the server wants to do or what it thinks client wants to do. So perhaps we document those as a best common practice, separate document well, yeah.

L

I would agree with that. One of the problems with I tip has been that it didn't make it absolutely clear it sort of said you don't you don't have to send this. You don't have to send that so everybody starts sending everything and in reality you you could send much more compact messages than people are sending and, and we should probably encourage that.

C

Can to give another coming yeah.

A

I like what Mike said, but I also would say: let's not make the same mistake we made with kal dev with implicit scheduling, and you have a situation where you're just trying to move stuff onto a calendar from an external source and we start firing off a bunch of events. I think yeah this this should always the client should always tell us. Yes, do my scheduling requests or no, let's get that in there from from day one absolutely.

J

A

J

Think just the question really is more about: is it just a simple yes/no send scheduling stuff for these changes, or is it more? You send the changes and you send a separate method, call to say now: send these I tip messages.

A

J

Say? Yes, yes, no send scheduling messages, that's probably the simplest option, we'll start with that men and then see. If we come up with use cases, that's not.

A

J

That's kind of where we're getting to with card up at the moment with the extra stuff. That's in calyx right now basically gives you that okay on/off capability, so it would match that. Okay, what.

H

One obnoxious thing that showed up for fast mail users just recently with this, was that if you're missing the correct ackles on the calendar, scheduling outbox, then the CalDAV set works, the PO the footworks, but it just sets a scheduled status 3.8, which means permission denied, which at the moment, it's not even mapped through to jer map. So the user can't see that their scheduling message wasn't sent it just silently, didn't happen for them. Yeah.

J

That's nasty. We can give proper error messages with J map. If you try I, say: I want to send I'm a poor, whatever I tip, and we can't we can just reject the whole change and say sorry. We can't because this yeah.

H

Yeah, the difficult part there is is the whole when a server rejects anything, that's not entirely correct, then the client could lose significant changes. If someone's done a lot of editing on the event, do they want it to fail to save I.

J

Mean that's just an extent up to a client handle, though the client knows what it's sent. It can not just throw it away if if the server gives a mess error, that's just I. This is the message, though, that the data was fine, but I couldn't send I tip because of reason. The client can then prompt the user as well. Do you want to save this anyway without sending the messages or what.

H

They the difficult case always to see you walk away or you you close your client after hitting save, there's nowhere else like you have to correct the issue before you can save your data or you have to copy paste it out into a.

E

H

Document, it's not a good user experience to not be able to save the intermediate state. Somehow somehow.

J

Is yeah bit very going if I don't see any obvious way of doing that? But if you have a suggestion, no.

H

Not not at 3:00 a.m. but.

H

A

So that the issue Braun's describing has to do with scheduling on shared calendars, which we all know, is a mess and I, think it's incumbent upon us just kind of straighten that out as part of it.

J

I think that will be much clearer in this. Yes and.

A

If we can get it right with Jane of calendars, perhaps we can filter some of that back down to kill that for legacy systems. Yeah.

C

L

Oh I was just I was just gonna, say that Bron Bron raised the the old issue of draft events really, which was was shouted down years ago, but keeps popping up again so I mean that would sort of solve it. If you're implicitly creating a draft event as your as you're working, it will not disappear. It'll just be still draft. That's.

J

Fairly straightforward for creating if you're updating an existing one I think gets a bit trickier because you still need the one. That's the current status, plus, possibly a draft to change to it. That's a bit well,.

L

I guess you can copy it into a draft yeah.

J

L

Copy it back again: okay,.

J

Well, we should maybe have a look at this on the list of whether there's something we can do a drafts. She that reminds me to my completely forgotten mental now maybe want to do something about having a trash place to put calendar.

L

J

L

Implemented it, it cost me so many problems, but maybe maybe gone. Maybe okay.

J

L

Got something to say about the next slide: if we all.

J

C

I'll just leave you there then yeah.

J

Thank you, okay. This is just about adding support for the capabilities of MV availability, which is artsy, seven, nine five, three I think this is definitely accept the capability and I'm inclined to punt it to an extension, but.

L

The work I do, though Asus, which is when I you know we did the soap stuff. This is also P and I finished that, and they said, that's all, that's all great if we do so, but what we really want to do is something is Jason, and that was a long time ago and and I think they will be very interested in this whole train map thing, but they are, they really love the availability.

L

J

The there's gonna be a method I'm currently calling calendar user slash, get availability which looks at your free busy time. Is your free busy report essentially I'm, going to make sure that the way that response would also work once you have support for Via Rail ability, even if you already have it just you can't set afire J map and I think and then we we can add this on extra I think we definitely want to add it. It's just whether we tried.

L

Twister as well is that he's already implemented in a very simple form, Apple I, think uses it for their office hours. Yes,.

J

We were experiment here that spasming tarts, the only thing you can set there.

L

Yeah, it creates of the availability object. It's it's very simple.

A

So I'm curious: are we thinking about leaving it out of the the base spec? Because we think nobody's going to use it or because we think it's too difficult? Or some? Because.

J

I think it's quite a bit of extra complexity to add into the spec and so I yeah.

L

We think about doing the equivalent I mean if we, if we assume that we can store and one thing is company or the the my mind's gone blank, the entity types being you know, can us just our events, cows, just for tasks counters just availability? Are we gonna specify that from the outset, so I think we should and then it becomes real, very easy because you say: oh, this collection holds availability, I mean.

J

That's kind of implicitly the case at the moment, because there's only events in the system, so a calendar can only contain events as soon as we add other types. Yes, we would want to say whether you're allowed multiple in one calendar or whether availability has to be in a separate one. You recommend availability should be complete in a separate calendar.

J

L

I we've gone with, CalDAV keeps causing problems and the reason they went they did that in CalDAV is because there was the danger of people.

L

Simply deleting a calendar because they thought it contained only events when it contain events and tests and- and that was the reason they moved away from mixed entity types in collections, yeah.

J

I certainly I think Tarson events. That was a terrible idea that those were mixed together into calendars. I, don't think we would do the same with Gerry Matt, but, as I said at the beginning, this there's no tasks in this moment. We're just looking events. Availability is a bit less clear in my mind whether that should always be in a separate calendar or should be combined with a single. What well.

L

I think you run the same problem if it's a real thing that people who do queries on a collection that are filtered to a certain type, think that's all there is in there and and then they simply delete it. Thinking they're not, and so they throw away a whole load of other stuff. Well,.

J

The other like in in J map is the V availability. Things wouldn't have to be tied to a calendar at all. They belong just to the calendar user overall, so they've just is this an account? The only reason they'd need to be tied to a calendars. If you wanted to manage permissions separately for different people on the availability, which you probably want, yeah.

L

You would actually yes and the real power of availability comes. Will you present different availability to different people, so I I would I would argue for from the outset indicating what type of thing is inside a calendar collection and looking making that part of the space expect. So we start off in that that state, okay,.

J

That's easy: s'matter yep.

A

This is Ken again: I have no strong opinion on single entities and calendars, but I'm fine, either way as far as availability goes personally, I would lean towards putting it in the base spec, because Mike's then keen is saying in the past and bronze current Kalman and I was standing just because free/busy isn't as useful as availability is just not just because my counter says I'm free, 3:00 a.m. doesn't really mean I'm available for a meeting and I. Think availability captures that yes, one. When can you schedule with me? Okay, I.

J

Will look again at keeping in the base back under certainly at least part of it needs to be under a separate capability, I think, but well.

L

I can I can certainly provide some help with that yeah.

J

That's great thanks: Mike, ok, I think that's.

C

I think that's it some time.

J

C

Several several issues here it sounded like you, had a good sense of the room on several of them, but if you could take them all to the list- and you know we want to confirm the consensus there, Joel.

J

Money will do that I. Think oh I bet that's great. There's.

H

One other issue that that's come up with this, that wasn't on those slides that I wanted to just mention to the room, and that is the idea of per user data and what belongs to a user and what? What is shared between users in IMAP. We share the scene. We have peruse the same state and shared everything else in our server and there's no way to tell well.

H

There is because there's an annotation that you can query but general there's no way to tell which parameters are shared where and shared in which one's a individual to user.

J

Yes, they're, quite a few properties will need to be per user I guess the main question is: do we just document which ones those are in the spec or does the server get to decide in a certain manner, in which case it would have to advertise which ones are per user? I was inclined of just document which one should be per user in a spec, but maybe there's other opinions on that.

C

Okay, thanks Neil and just a reminder of several people, who've come in blue sheets are right behind Barry there please make sure that you've signed the blue sheets and Alexi is up.

I

All right, so obviously, if this anything happens to this document, it probably will have to be edgy sponsored by Barry.

I

I

Right so I was lucky enough this week that I have some sleepless hours and I had a chance to think a little bit more about so basically the at the moment. The document only contains the basic as my signature verification.

I

There is one extra thing that might be added which I will talk about on the slides and advanced feature. If there is a desire to talk of cooperating server and store your private key in the server, you can do encryption, decryption and signing top, but that's probably separate capability.

I

Yes right. So in order to report the status as mine status, response property can be requested and it's a string with some simple structure.

I

I

So unknown is when the server cannot figure out. You know it might be multi-part sign message, for example, but of a format that the server doesn't know so, for example, can be like open PGP, but well. This is, as man sign is the status that server knows it's s/mime signed, but didn't try to verification yet and then, once verification is done, it's either yes, mine, verified or assigned verified or sign failed nil. Raise the good question this week about.

I

When does the server turn just signed and when does the server returns and verified sign failed? So.

I

This is very loosely based on my implementation and there, if you just want a list of messages, you just return sign. If, if you want to actually view a specific message, then you will verify it. The reason for this is verification. Operation might be quite expensive, so you want to delay this.

K

Daniel, this is Dan Gilmore I recommend cutting down the number of statuses here. I recommend two statuses only and not for the statuses are signed and verified and nothing. Those are the two statuses. It's not clear to me as a user. What I gained from learning sign failed compared to unknown. We found that we had the same situation. True in D.

A

Kim, where.

K

A DCAM signature that doesn't validate should not be treated any differently than the deccan signature whatsoever. I know many people do, but it's a mistake and and as a as a user of an email client, it is not clear to me that a big red warning sign just because there happens to be something that looked like a mess.

K

Mime signature makes any sense whatsoever because it doesn't defend me against an adversary who's, trying to forge the things that just stripped the signature and remove the big red warning, so so I think I think for a cognitive load for the users, the the only two states you want are. This has been verified and verified needs to cover quite a bit of ground more than what you've described here.

K

I think verified needs to cover that the timestamp of the signature matches to some level the time the date stamp in the message that the sender was the same as the certificate. The certificate itself has been validated and so forth.

I

Yes, yes, most of this is implied slight difficulty is the efficiency thing where you defer the verification ya know. The other part is that in my implementation, if the sender certificate expires, it moved to sign failed right. So, but I mean we can return this information in some other way. If.

K

It, let us see a draft that explains how to how to check signatures in the context of store-and-forward data with expiring certificates, because I don't think anyone's ever actually written that down. I have some strong opinions about what the right thing to do is and that you want to evaluate the signature at the time that the things claimed to be read, and you want it to fail. If the timestamp of the message itself differs from the timestamp of the signature, so you're evaluating stuff at the time.

K

The message claims to have been and your ich and you are required, then to be showing that date stamp and the context of the messaging, the dates tab appropriately, which may mean for a male that. You also want to check to make sure that, if it's in reply to some other messages that it's time stamp is actually after the messages that it replied to for some definition of after no I'm. Just saying that you wish you one is you want the mail user agent to think very clearly about what this signal actually means?

K

And just because I sent a message with the key that I later that later expired and certificate, it's silent.

E

K

Later expired doesn't mean that it should show up as as nothing once the certificate expires. That doesn't make sense. Yes,.

I

It wouldn't show it wouldn't show as nothing and before you asked to go for probe for statuses till two but yeah I understand yeah I understand sounds like you have some ideas, so maybe we can think of some text and.

J

I

Can see if we agree.

J

You say the date of the message, but there are many dates involved inside a message and how many of those can be forged sothey. You need to be more specific about which date so probably the one it was received by your server. No because the date had a field you can write whatever you want into that. No one is.

B

G/Kg is saying is if it's a signed message, maybe you don't want people to be able to put any date they want. It needs to connect to when it was signed in a reasonable way. So.

M

M

B

To fudge this, but what what I wanted to respond to to Daniel know is I, don't want to start getting into all sorts of tying things together and message: threads and validating relative to the reply to to the in reply to and that kind of stuff. That's just getting way out of the scope of a signature.

G

B

Signature is not saying that that this is in reply to that other message, and therefore it has to be later than the other message is, is a semantic content of the message, and that's not what the signature is for.

B

C

Right, let's take a second here from bran.

H

Yeah, what I wanted to comment on was debug ability. One of the things that really frustrates me about DNS SEC, is that you just get back in an X domain when you request something and what's actually happening, is a key signing failure, but the domain totally exists, so the record totally exists. I think it's great to have something that just tells you yes signed, verified or not known, but it needs to be a property that can be fetched for anyone, developing or testing or for a support department to ask the user.

H

Can you tell me what what this shows so it actually might need to be visible through the user as well, so that they can report to support here's. Why? My message has an issue rather than being completely undo. Bugga ball.

C

Actually, I think a.

H

C

Feel but same concept. It's.

H

Easy to get caught up with the attacker case and make the regular case very hard to use.

J

Although without the attack case, the regular case doesn't matter anyway, there's Neil Jenkins I just want to make a quick point. We go back to all that other stuff, just about from a J Matt point of view.

J

If this does have a signed state, that's I've not verified it yet, but I want to I think the way to do that would be to say if you request one of these properties, body structure, HTML body, they say neither body properties right, then you can expect if you fetch at the same time the signed state, it will be verified or failed or whatever right.

I

And after that it will be cached basically.

J

About that where's, if you fetch it without fetching all those properties at the same time, you may only get back up signs they if we keep those values. Ok,.

K

Dkg here so Bron I completely agree with you that there may be good cause to have debugging data and I. Don't think this is the place to do that. Maybe there's an additional thing that you can ask for debugging information about how the Signet verification signature verification failed, but given the number of ways that I think signature verifications can fail, I think it's a mistake to try to put that in this status, value which looks very much like something. We are encouraging the user agent to display directly to these ok yeah.

I

If they're going to return information about the failure, it's probably going to be a separate property. But yes.

K

I agree: absolutely it may even be a free-form textual field that says yes.

M

K

Right, yeah I, don't know Brown did you want to go ahead? I, but.

C

I gentleman behind you in line who's next, hey.

E

Steph gentle I just want to say that the like to read or under saying I'm, imagining the ideal UI to be something like what browsers do today, which is you know if there's like a other scenario here, I can see exactly why the certificate failure, why that seems fairly check right like that's what I would I think well, I mean a lot of developers. Use that you know like I know that my mom doesn't click on that button, but I certainly do when I'm building web site from.

K

E

K

Can I just want to do my usual pushback against using my mom as a non.

E

K

We are gendered space, we're heavily male there's a bunch of assumptions there and I know it. I know it's not an intentional thing. I just my mom happens to technical user. Let's not make those assumptions about people who might be in the room or might not be in the room, so yeah I mean I I. Think it's kind of funny to use the browser model as the model that we're working from a because when the browser model fails, you don't see the site at all right and that's not at all the case here. Right.

K

As someone who's debugging a lot of certificate errors I'm not actually convinced that this also thought through you doesn't show you, then there are multiple failures. For example, if you have it, if you have an expired certificate, that also doesn't match, it'll usually tell you one of those two problems, but not the other. So, okay.

C

I think bronze next.

H

All right, if I, can remember what my my other point was here: I in terms of the gem happiness of it as a server implementer I prefer thee. If you requested this property really calculate it for you, if you don't request that we don't I can I can see why you might want to when fetching a listing.

H

I guess have it pre calculate without having to fetch the body structure on it, but it is the question then becomes: do you bump the state when you calculate it, because if you don't bump the state, when you calculate it, then how do you know it's changed.

K

J

Yeah you can define the kind of exception is but yeah the General James mandates would have it don't quite match to. It gets calculated to keep fetch specific other properties. A bit weird, like me, I mean.

H

I know if I implement it in saris IMAP, then what would happen is at the time it got calculated. It would either set a keyword or it would set an annotation and either way that would bump the mod sequence. So it would actually report that message just having changed.

J

Neil Jenkins, just on the browser, I think. Actually the lesson learnt there is moving away from showing Miz's trusted to not showing anything new passes and showing big red warning signs to you know don't go here. If it fails, that's the only state, because users do not notice like this. This is fine.

E

Notice, the absence.

J

Of it, this is fine notice of Keating, they have any so, but I know you have use cases, perhaps that it different I. Don't.

K

Sorry this is dkg, you won't there's one more thing that I wanted to add. I. Think bran is right to think about what it means to do: the verification. How that changes. The state of the message and I want a flag that perhaps what you want in this state is the timestamp that then for for, if it comes back signed as opposed to not signed which of the two states I'm recommending what you may want to have also is signed and verified, and a timestamp when it was verified.

K

Now I am NOT a big fan of moving the cryptographic utility into the server. So the fact that this is situated in the server makes me uneasy, but if you're going to be doing the cryptographic, verification in the server, the thing that I want from my cryptographic verify are is actually a cached time stamp. That says, I saw this thing and I verified it at time. T, it's very different for me to get the message.

K

I'd, look at a message on my on my laptop and I get and I'm looking at it in 2019, and it's from a message that was in 2002 and right as signature verified. Then, if I, what I had that is actually a timestamp from my trusted user agent. That says, I actually did verify this in 2002, that's semantically, different and so I think you might want it to say, signed and verified with the time stamp. Yeah.

H

You have to verify it in 2002 because if you verify in 2019 using the key that was valid in 2002, that key has existed for 17 years and if it's been cracked or leaked in that time, then that message could be faked. That still.

K

Might be relevant right, I might be, have just imported an archive of messages, and they.

E

K

It right so so.

E

There may be a.

K

Circumstance where the, where the user agent will decide what to display based on a timestamp of the verification compared to the timestamp of the of the message but I, but that is one thing that I think should be bundled with a signature. Verification is a timestamp check about a and I. Don't know exactly what that means and I, don't know how we make the user agent use it, but I'm happy to work with folks to think about what what the semantics are there. Okay,.

C

You mean timestamp of when it was initially verified. Well, the first time it was your earliest verification.

K

I, don't think you gain anything by storing additional attempts at there. I.

C

Don't think you do either.

K

H

Need a chain of custody and you need to verify it with a key. That's valid every time that that the previous valid key expires really okay,.

I

Okay, there are some where developers, cases when you don't have you didn't instill trust anchor when you're testing and it failed, and then you know you install it and then later it succeeded, but anyway yeah I'm.

K

Not I don't know no, they only, but that's I'm, not suggesting that you store a timestamp for when the signature verification fails. Agree.

C

Even suggesting.

K

That you store for when it succeeds. Fine.

C

I'd like to move the.

K

C

Along because we're we're taking a lot longer than budgeted here,.

I

Right, so, if we want to do signing sign encryption decryption, then there is identity, object which extended with as my own credentials now at the moment, this key ID, which is like a blob, ID and various other IDs and certificate you can retrieve private key, is not retrievable through this interface.

I

If somebody really wants this, we can discuss, but that's probably safer default, and also, additionally, you can mark the private key, whether it's only for signing for encryption or both. You can also mark a special case if it's expired, but you still want to be able to decrypt all mail. You can mark both of them as false. Then it might be able to decrypt it, but it's not usable for sending stuff out next slide.

I

So yeah I was trying to figure out how to exactly.

I

Create a constructor message which is decrypted or with if it's a Buckley signed how to extract them. Payload so I think, with with some help from Neal, you suggested I had attribute to email, parsed, oh well. Basically, it's mime decode default is false, so nothing is done. If it's true, then the blob is first attempted to be decrypted, and/or, stripped from signature unpack from CMS, basically, and then it will be parsed and then, at the end of this there will be a new message with new blog new message, which you can act on next slide.

I

On the sending side, email submission object needs to be extended with at the moment, I made these two objects.

I

Maybe it's efficient to make them just boolean's, but if we need any more information- oh yeah, actually so yeah. In this case, you can actually say.

I

You can possibly have multiple keys and you want to specify which one you want to use, although if you specify identity, it might not be needed. So when you think a bit about this.

J

This seems for defined in the model, which is the service basically doing the encryption kind of on the edge going out right so yeah. So just to be clear, if you do this, it's just the version that sent. That is s my encrypted and will sign to the version you store locally in your send copy is not because this is just my it to the actual submission yep. That's what you're intending.

I

You probably will store the encrypted message in your sent folder, but right it basically allows you to do transformations before you send.

J

Mission then out I said because that implies to me something that just happens to the submitted message that sent out. Not your copy I think you probably want to do as part of email. Slash, says potentially then to say, create this, and also when you create it encrypt it and will sign it. That's the five four three two two message: I'm not created also.

I

Move it to a different object where they must have just created. Yes,.

J

Opposed awesome, Michelle P as well. Yes,.

I

That's a good point all right.

J

The copy will sending out.

I

Yes, good point.

K

Daniel Kanagawa I'm, really sad about this work. The idea of moving the secret key material, that is, the users cryptographic, identity and capability for seeing intended data into the server I, think it causes problems for other people in the ecosystem, who are trying to understand what end-to-end encrypted email actually means. The fact that you've moved it there I understand that anyone can leak clear text, any critics.

K

They have access to you, but I just want to point out that I think this work is radically different than the signature, verification, work and I think it's wrong in a in an entirely separate document and I. Don't think it would be right to try to conflate the two because I well!

K

Well, it Tribble vaguely with the signature, verification work because you're relying on this other party to do the checks for you in this case you're, actually relying on the other party not to compromise the security, the confidentiality of correct the messages and not to forge messages as you which, otherwise they wouldn't be capable doing so. I strongly recommend, if you're gonna work on this, that you work on it in some separate draft, not in the same draft yeah.

J

Once they come new drinkin's I mean I actually think there is a use case here, which is generally, you have a kind of Yemeni corporate like company, which is a trusted boundary. If you like the outside and the stuff and there's other boundary, things are encrypt or decrypt it for Jones, it's not about end-to-end encryption. That is a different use case, but that's I think that's where this is kind of a where s/mime in general is kind of more useful I.

K

Hear you say it's not about end-to-end encryption, but when the user who's outside of that system is sending mail to them, do they think it's about end end encryption, yeah, I, don't either and that causes that paints a very confusing picture for people who are trying to say you're trying to use email who are not the operators of this system who are trying to understand what it means when they send now I.

H

Was just going to say with that, it is not necessarily always the case that the client and the server are operated by two different parties. Your server might be your home box, that is sitting underneath your TV, and it is fully controlled and owned by you that your client is talking to securely, and that is then holding your keys. The the Apple model, where the server, where everything's pushed to Apple devices, to the point that I can't get a one time password without owning an Apple device in order to to talk to their server.

H

Even in that case the server might be the more powerful device that your watch is talking to that's sitting in your pocket. I.

K

Understand that Braun and I think I mean certainly, there are use cases where it would have the same fundamental confidentiality and integrity, properties and authenticity properties as it would if it was asserted on the local device that you hold. But when we define this, we have to be aware of the context that we're defining it in and the context that we're defining it in is that many people will be using this with servers that they don't have the same level of reliability. Oh yeah.

H

I agree with either a separate documents, a good idea.

C

Okay is that it yeah I, think that's it all right! Thank you, relaxing and so the next we have.

G

G

So about the Indian art I put Sebastian the Russian zero two at the beginning of the week. The idea is that it make it simpler, using more concepts from Drake that Chrome. So next slide, please. So a man changes the men change is the following: is defining super MD and object with a very basic set method using only create and the past method. So we replace the previous session who was extended? The material object, Neff slide. Please.

G

So no vengeance set response is similar to standard set metered. So as against Ypres. Thank you latest comments.

G

The only caveat is that is returning no more miss Effie mission, but just use the passive response from the endian. So in this case we are sending an email, because an Indian is is somewhat an email without adding an miss efficient to to follow it. But given that its servers, often a sudden forget message, I think it's very talky.

G

G

The erection has some save a little fix. He is a dating game, ocurro of attrition and remove a registration of the Nvidia registered keyword and some typos and next slide. That's it any question.

J

No questions very I think the general model is expecting now it's much more j-mac evil, one for a better word. Yeah I need to actually read through the latest version again properly, but this thing's pretty reasonable. Thank you.

H

It's Bronwyn I have one more comment on it: I wonder whether MTN is clear enough as a name whether we want a longer name for the object, just that this is a global namespace for all things that will be jam up later.

J

Yeah, it might be good idea to actually expand.

B

That out of it, this is very I. Don't want to belabor this, or you know, make a bike shed out of it. Mdn is certainly a well enough known term that I wouldn't worry about it, but I don't feel strong.

H

E

I don't need it.

H

Just jumped up a bit.

C

All right looks like the queue is empty now, so Thank You Raphael there any other. Yes,.

C

People are shaking their heads, please sign the blue sheets. If you haven't already, and thank you for coming to this session and.

B

Thank you to the remote participants and particularly to the remote chair. I was up at some crazy-ass yeah.

H

B

H

Just just about to thank you thanks for running at Jim, and see you next, one All.

C

Right see you then.