Internet Engineering Task Force 100, 16 Nov 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF100-JMAP-20171116-1330

Description

JMAP meeting session at IETF100
2017/11/16 1330

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

A

B

They need to give us space.

C

All right now we're in a really load of the resolution. Yes, would hate for fun now.

B

D

Gonna set one: yes,.

A

I've already yeah.

A

What could be defining the other.

E

F

So for for y'all on me deco, so you know we are having technical problems with projection and stuff, so we'll be a bit well let you know.

C

F

So you know you, you outnumber you on me. Deco outnumber us in the room. Actually, not if we count Alexei, but let's not count Alexei, because he's.

C

It's very HDMI, cable.

D

D

B

C

All right people are mediocre, we're getting another HDMI, cable and we'll see if that helps.

C

Do you have another.

A

Computer than me, until.

D

We know his work.

F

Yes, we've decided that this is going to be a short session, but it's going to start very, very late.

F

A

F

Av people working on the problem.

F

Yes, that's a good point.

A

It may actually be an option at some point. Quite.

C

F

Three, we now have three AV.

A

People working on.

F

The problem soon they will outnumber the people amendment as well.

G

A

A

Okay, I have a it says.

C

Have a display.

A

It even lets me mouth off into it.

F

A

Look at all of these promise yeah! Well, it it'll head it all along yeah, I, didn't.

H

F

A

It's just not coming out the other end.

A

I think you're left destroyed it scented some HDMI seasonal.

C

All right, while we're waiting for the slides to work, if you want to find the slides that are available on the meeting info page for this, you can get up your own copy of them and worst cases that we follow along.

F

Yep I just I just asked on jabber. If anyone does not have access to them.

A

C

F

It looks like we have ignition.

C

F

Yep, okay, you.

G

F

We have a slide up. That's a big plain white slide with a big J map in the middle of it. Do you on me deco see that liftoff says Ken. Okay, life is good up, but Jeff.

E

F

He does not sorry Jeff PC Jeff is Joseph. Okay,.

F

He's good now so alright.

E

H

E

H

So I'm gonna go up in the front like.

F

A good do be here.

C

Alright, this is cutting in and out so, let's be careful not to touch Neil's laptop, yes, we're back again. Okay, fingers crossed.

C

Don't break anything Barry.

C

All right, everybody welcome to the slightly delayed by about 15 minutes J map session at ITF 100, the blue sheets of I think made their way around the five people in the room, and we have another five on me, echo I'm, Bron Barry is arriving at the table as well. The note well should be appearing on your screen right about now. If you can't see it, there's plenty of places to find it and let's get on with the agenda, so we're going to start with an overview of the changes since the last time.

C

I think this is the lack of people in the room is probably indicative of the fact that there aren't that many outstanding issues that there's going to be a large amount of debate about, but we yep Alexie's about to hop up the microphone.

I

I'm creating you know excuses. There is also door working group running in parallel and SOG, which is like so.

F

The first question is how the hell did that happen. Well, SOG is well SOG and doe should not overlap, because dough is security-related dough. A I'm.

I

All idea nester late, yes,.

F

But it's, but it's HTTP, dough and us shouldn't overlap. I mean this was just a that doesn't matter it. We shouldn't go on about it right, regardless.

C

Let's hand over to Neil to talk about what's changed since I up 99, ok,.

J

um So, first of all, just gonna have a look at what's the major changes in call, so one of them is patch updates, updates have always been a patch and that you didn't have to send all the properties of an object just had to send the ones that changed, but you did have to send the whole value of the top level of property, and this was an issue for things like keywords and mail boxes, because you'd have to send the complete set, which was a bit wasteful in terms of bandwidth and also meant that if another client had changed, one key word in between you would black that change.

J

If you were just naively writing the whole thing out rather than and are not checking, the state hasn't changed under you, so with patch updates. Basically, it looks like this, so you can see. We've got keywords, slash dollar flags being set to true, which is basically JSON, pointer format. I comment the RSC, but it's another standardized format for with going into the property of what you're changing and the patch format is defined.

J

Such that you can also you can include just the whole object and the top-level properties if you want- or you can include, the detailed minimal patches and the server processes at the same way either way and that's pretty much all there is to say about that. But just pause. The moment see if there's any comments.

J

Lexi just asked: what's the big hashed load, looking I think that's the ID of the object, you're updating, that's finally,.

C

The sha-1 of the RFC a to two bytes in.

J

In this example, was copied straight out of the the network panel from the j map proxy, but it could be anything, isn't a paid string in this case. It's a hash of something, but anyway are there any comments or questions on this from the people on meat echo? As someone monitoring java.

C

J

Let's just move on then so the other major.

J

Great +1 for maxi yeah, the other other major change, is introducing this idea of back references for method arguments. So the idea here is there was quite a few methods where we're having two special case: extra proper extra arguments for things like fetching the messages from the message list or fetching the threads from the message list, and all of this was really just to allow you to make implicit method calls and so avoid round trips, because you need some of the results of the previous method in order to make the next call.

J

So, with the back references, we have basically simple syntactic transformation, which is really easy to implement on the server, but it actually gives you just as much power and more from before and means we could remove a whole load of special cases so that actually a lot of the met. The methods become simpler, so here's an example to actually explain more what I'm talking about.

J

So this is split over two pages, because the sides are quite small, but essentially what we're doing here is fetching the third first 30 threads in a particular mailbox and fetching the headers for every message in each of those threads of those first 30.

J

So the first thing we do is a get get message list with the filter just off a particular mailbox that doesn't that's the idea of the mailbox there if you've not familiar with J map, filter format, sorted date, descending collapse by thread, so that we only return each thread once at the first position of its message and we live in that 30. So that gets us the 30 IDs of those first 30 messages in that message list.

J

The next one is slightly odd, but you can see here how our work, so we have a hash before the argument name- and you can do this for any argument name and so that's very easy to scan through the arguments and check. And then it's telling you which of the previous methods to look for the result in and in the path into the response from that to look through. So there's also of zero, so we can look back and see. That was what was tagged.

J

They get message list cool was tagged with zero that that's the ID of that method call and then we would look at the IDS path in the result, and that is an array of IDs and that then becomes the IDS argument for get messages. So it's it looks slightly weird when you're looking it on in the slides I think, but it's actually really easy to implement and gives you a lot of extra power to reduce round round trips and make things more efficient and.

F

So we have yes comment from jabber a possible issue. Aj map call containing both IDs and bound IDs.

J

The this this is the argument name so I. Don't they obviously are no arguments at the moment. Let us start with a pound and I. Don't think anyone is likely to define one and they can certainly. We can certainly make sure you don't that. That's the that's all you're looking for you're iterating through the arguments to a method in.

C

The same ways: it's used by D replacement for back references within objects, the that leading character can easily be defined us not allowed to be used for anything else.

J

Do we have any further comments on the mute echo? Okay, I'll just keep continuing for a short time them, so so what we've done so the second one was fetching basically we're getting. We want to know what the thread ID for each of those messages is, so we do a get messages called just fetching the thread ID property for each of those. For that that's the one slightly weird bit and then after that, we're simply getting the threads so for each of those thread, IDs that we've got a back reference there to the thread.

J

Ids result of the previous thing, we're fetching the threads which is list of messages in each of those threads and then finally, we're doing our get message with the header properties. We want back referencing to those message IDs in the threads to fetch all the messages, so it I said I think it does look a bit weird when you first see it in the slide, but having now tried implanting this and playing around with it, it seems to work quite well and actually simplifies code.

J

We found on both particularly on the back end, because it reduces the special cases that used to have to exist to get the network efficiency so.

F

Continuing from jabber Roberts says, core spec should reject requests as invalid that contained foo and pound-foolish by.

G

F

Chris says question is: would the server have to merge pound IDs and IDs and compute? The result on the merged list know.

J

As Robbo said, it'd be invalid arguments error immediately if you try and include both- and it's very easy to check that you don't have both. You can include this if you want to back reference. Otherwise you just get the explicit one. There's no merging! No, nothing tricky like that.

J

Any other questions on on this.

J

Doesn't look like it cool, okay, great cool? Well, let's move on the veining overview. Stuffer! What's changed since prog push support, it's not a lot to say about this. It was just mainly kind of refinements to what was there before referencing in webbing encryption sport, which is going to be needed if you're going to use this in a browser that just references a different RFC or will be an RFC before this is finalized.

J

Martin Thompson's writing and ensures that we are conforming to what's required and I've see a t-34 too to be able to be used as part of that standard push ecosystem. The other form push which is the eventsource, has changed slightly in that there. The client can now pass some query parameters, one of which says this is kind of long polling. So just close the connection every time you actually push something and the other one is to let the client determine how long the service, what interval the server should send things down.

J

Events also, if there's been no events, these are to allow clients to detect that they've got a live connection to the server and their concerns were raised before the the trouble with events or sometimes is that you have proxies in between which mean that if they're buffering proxies, you never get the response until the connection is closed because they're buffering too much in between, and so this sometimes doesn't work in some corporate environments. So, with these options, the client can look out for pings and if it determines it's, not getting.

J

The things through can fall that long calling which normally always works because you're closing the connection and therefore the proxies flush their buffer and you get get the data poof, and so it's all works as a push channel. It's just slightly less efficient on the network and so with those as a set I think pushes pretty much finished. So any comments on push I think coming great and finally authentication. This is a big issue. We've discussed in a few cases.

J

Basically we've taken out the new authentication stuff that was in the J Mack core. It's kind of out of scope and makes it much more difficult to get through the spec. This is a problem. That's not really just tied to J map. So it's basically just now says it's HDPE, so you need HTTP author to authenticate connections.

J

What that is, will actually depend on the service, probably basic in some cases or bearer with OAuth in certain other cases, and that's.

J

Pretty much the same situation as we currently have an IMAP, it's no better, but in their worse as.

F

Well, any interest in this is Barry any interest in implementing any of the HTTP off working group. Experimental authentication mechanisms.

J

I'm not sure which one the experimental ones are I'd have a look.

F

Up the HTTP off working group is now closed, but it produced I think three experimental specs assessing.

J

The manner they I mean I'm certainly interested looking those and doing some experiments with them in terms of the specification I think whatever that is, it would still have to be. Consumer like it is an independent part, is not required and tying the two together would be a mistake. I think that's.

F

Fair, so Ken Ken says scram, you know, which is that's the sort of thing that we're talking about. There's one of the experimental mechanisms is related to scram. So can.

H

You guys both Kiko go. Do because could you consider like not watching like beta code because of all the TV show, vidi god and really like that? That's the use case where you've gone to use some mechanism like oh another,.

G

H

The void the nightmares of Avik, but.

J

So this is what.

H

I was getting out yeah.

J

So the kind of history of this is the we were desperately trying to avoid basic auth, but mandating OAuth doesn't work because there are too many situations, email that that's not necessarily viable. We could prohibit basic, but again that's it's. It's going to be hand. Waving scanned is going to be used in situations to an extent like if you're, so so, obviously, there's there situations in the in the back and like only internal networks, sometimes where it's in Crocs eat through and at that point it's gonna use some some other all system.

J

That's this could just be basic or something, but the other issue main. The main issue is if your random isp set up an email service, mail client has to connect to it so kind of worry options for allowing authentication while there's basic or there's OAuth pretty much, but but all with OAuth is borrowing there's now some new standards to do auto discovery, but just the whole there's no email, clients, I, don't know how likely it is. People are gonna support.

J

All these things in order to be able to auto, discover the oath settings, Auto register the client, and so they can't pre-register with every email service out that they can pre-register with Gmail and Yahoo and stuff so that they don't need the auto discovery system. But they can't can't do that with every ISP yeah.

F

I agree that we can't require a lot, but I think this is a real, a real loss from coming from IMAP, where we had s cram, except.

J

That, in the vast majority of places, no one you today and I'm at so.

F

Anyway, Chris says, while I'm, obviously a fan of s cram plus TLS. The more important problem to solve is client, specific token bootstrap I.

H

Could you go there for bidding baby cot for.

J

Bidding what's a envelop.

H

Mandating must.

J

Not just basic.

J

As a base without Then There is obviously it forbids, not TLS. Everything has to be over yes, but it's I I think it is.

H

Very far like you're gonna prop it all, even our believe that our possible, like impossibility to logout a lot of nightmares with Vedic yeah.

J

Yeah, we prefer.

H

Like holding or together this.

J

Is what we've been trying to do, except that we also don't want to be defining a new authentication specification because that's out of scope- and we can't there doesn't seem to be anything we can just say you must like saying you must use it auth, it's not practical either like you could you we can say you mustn't, use basic. You must use a bearer token and how you get that bearer token. It's not necessarily vile, oh, but that's still these open. If you're writing a client, okay I need a Barrett Oken.

J

How the hell do I get this Barrett oak.

F

And bearer tokens suck as well. So that's.

J

Another I suggest that.

F

You post to the SAG list, si AG mailing list and ask for somebody to look at this document from a security point of view and comment on what you might do, but because of what I'm afraid is that, when this gets to the IAS G, it's gonna get pounced on by the security, a DS. If we're doing basic off I.

I

Think we probably need some security considerations C realistically, so there was the recent document from mile, which is again it's sort of a temp up based HTTP protocol doesn't talk a it, can waved about authentication as well. It sort of said you know. So what also.

F

The alternative, then is: could we just drop HTTP entirely and say that you must use this over HTTPS? Oh so.

J

No, it's already must be over HTTP, okay,.

F

But that's that's.

J

A side issue: it's.

F

It's it's not sufficient to solve everything, but it may be sufficient to get past the initial issue so anyway, let me Chris says basic over TLS is the only thing that's likely to interoperate as long as authentication is out of scope, so it's probably the mandatory to implement for interoperability and I. Guess I agree with Chris on that bearer tokens are better than password over TLS for mobile devices as long as there's a way to expire, the bearer token, if the device is lost.

C

So I would actually answer that this is what's happening in the world. Is that a lot of big providers now are issuing an app specific passwords to each device and saying your bearer token? Is your username Plus this, because HTTP basic authentication in two parts and part of a bearer token is you use an M part of the bearer token? Is this long-lived app password that you can then cancel when your device is lost and because the canceling, a token, is still going to be saying?

C

This is no longer usable and that's that's where the world is going at the moment, because that's what's available well.

J

Yeah I mean it's basically a nicer way of setting up that app password, which so the user doesn't have to manifest around they just log.

H

J

Their normal credentials and that's all handled on the background they yeah the the yeah. This is the thing is this is not an issue that is specific to J map. It is an issue with any HTTP API, and so the solution, I, don't know, is I, think I. Think I. Don't think that we can solve this.

J

Just within this working group, I think.

F

Unless anyone objects I'm going to request an early sector review on it, so that, while we're finishing up the document, we can get any comments from the security area about it sure.

J

That's fine I certainly think there Sophie, the security considerations section will need a strong bit about basic, but I think the trouble is that we, if we forbid it, we are basically removing the only real interoperable okay option for a lot of AI speeds. Take.

F

Please take a stab at writing out the security considerations as a priority yep when you're done with that I'll ask the security Directorate for an earlier with you sure.

J

There's already quite a few in our at.

F

J

Yep, okay, so those are the main changes since last time. So let's look through the remaining issues. There's no actually too many kind of the real substantial issues to go: we're hoping to get most of these resolved by March in the in London and then hopefully we can actually do Interop testing at the hackathon and ITF London as well beforehand, if people have got fairly complete in plantations of a fairly finished spec.

J

So let's have a look what's remaining in core, so one thing we need to do is make sure we have sorted our plan, versioning extensions, which is obviously always going to happen with any API, and my rough plan for this looks a bit like this. So at the moment your method calls are an array which is what you, post to the API, we'll wrap that array in a top-level object which lets us add various kind of metadata properties.

J

If you like to the whole request, Chris Newman I know, has raised ideas of adding extensions on this in the future. For things like, you must commit the whole thing atomically or things like that. But for now the main thing is that we can add it using property which behaves a lot like sieve. It's not in to extend to specifications. You have to opt in as a client to everything you wish to use.

J

If you don't opt in the server behaves as though it doesn't support it, which gives you fairly decent yeah if the server advertisers which specs it supports in the capabilities object which is fetched at the beginning. If, with with your basically information about the session, once you have some kind of authentication token, however, that is, you can fetch this object.

J

That has information about which endpoints to hit for the resources and the capabilities at the server and the capability objects, basically is a key of the spec name or preferably I think a URL to the specification itself, so that, if you're just trying to see what a server supports you see something you don't recognize. You can just follow the link and you know find out about respect which would be quite nice and then the value of that in the capabilities object is an object with various information about that spec.

J

So, for example, for the male spec, the capabilities object includes things like max, mailboxes and stuff like that. So that's the general plan. It's not too complicated, I think it's based on. You know existing solutions that work and it gives you a way to move forward while not breaking old clients, which is the main thing you want any objections or alternative proposals or ideas on that.

C

General shrugging in the room for those in meat, okay, yeah.

J

I mean we've discussed this a few times before and I think this actually doesn't.

F

This assume that URLs are stable forever, since Jeff no.

J

Not at all I mean the the capabilities. If your capability name is a URL yeah, the the thing is that the so the specification will define its capability name, which doesn't have to be a URL I'm, just suggesting it will be nice if they aren't for things like RFC's, you can have a canonical URL, I think, which is a chore forever, is a long time, but can be reasonably stable. I.

F

Think I presume you when you say URL here you mean URI yeah.

J

I being loosen.

F

J

It the gym, might my he's.

F

Not kind of an Emporium okay, yeah.

J

It's not important to this functioning; it can perfectly function without it being a URI. It's just I think that would be nice. If that's a suggested thing for future extensions, because then it helps people developers who are examining new server if they come across something that I recognize to find the documentation on that of what the server can do. My question wasn't: URL versus.

F

Uri, but what my question was at URI versus non URI. Now that we're clear that when you say URL.

E

F

Uri it's so it's okay! For this not to be a locator, it can be something that doesn't resolve to anything so.

I

A you are n, yes, standard ones can be your ants in and can be actually located in ITF namespace, but.

J

I

Common yeah so I think that works. The.

J

Main thing I think design sense will be in in.

F

J

To be in your domain in domain, you own, so that it enforces name spacing yeah.

H

J

Was the other idea of that is yet enforces name spacing through that? Okay, good.

J

Okay- and this is really kind of the only other thing from core I think- was looking very, very good now. This is a bit of bike shedding really, but there's some inconsistencies in the standard method.

J

Name: we've got rules, we get Foose and set throughs, but we have a singular phupho get through updates, get through lists list updates, which is both aesthetically a little bit annoying and also makes it harder to programmatically generate these if you're kind of doing automatically from by just giving it one type name and having it synthesized what the event, what method names are cause? You have to know how to pluralize something in mailboxes has es as opposed to something else, so I think it would just be nice if we made this.

I

Actually, not to add s, just keep it, as is I actually.

J

I'm proposing to keep everything's cool, but then you still only have to specify one. The main thing is the server you would never have to try and everything else. You.

I

J

And then so these are some suggestions, so everything was yeah.

F

So like get mailboxes, yes.

J

F

Everything will be mailboxes rather than I.

J

I

More shrug but yeah.

J

I uh we could try and go all singular. It's arbitrary I just think it makes sense to make it consistent and to have and to not require two forms at the same time. Does anyone object to.

F

Letting you'll figure it out and accept what he comes up with sold great.

J

This is by jenny. In its best, we can wis pass the important bits, there's a very similar, quick naming bike-sharing issue on email. We want to the mail spec now, which is simply that it's been proposed. We renamed the message, object to email, because there's some confusion around the fact that you have an ID on the message, object and that's a J map ID and not the RFC 52 to message ID and terminology.

J

So that's just avoids that confusion, because then it becomes email, ID and stuff yeah, so great move on from the blank cutting stuff. This is the main issue, I think still to resolve, and so this is hopefully what we can hash out to here and on the mailing list between now and March, which is the message format in JSON of the RFC five three to two so I think the headers bit of this is fine and doesn't need have any objections.

J

It's gives you past forms of a lot of the headers, which makes it easier for the client to deal with like getting the from as an array of objects with the name and email property and rather having to pass the string. The main I think thing that we really are not sure about at the moment is converting the body into an and what form does that take?

J

Is it just some kind of JSON representation of a mime tree which is kind of what the Gmail API does, or is it closer to what clients generally use, which is clients generally present a message as some kind of body, which is a text thing or HTML representation, and then some attachments which are files associated with that? Then, of course, even how you convert between them. There's some ambiguity of what is an attachment. We've had some discussion on the list the last few days.

J

This is not quite as simple as it sounds, and so I think this. This is kind of the main thing of what what we want from this. Do we want both options or one of these. What should it look like, I think kind, large, open the floor to opinions here.

H

F

H

F

H

Mouse key Google, so my question: why would be you do something different and provided providing the original mime structure? Because the point is to you want to provide like a mail, the desktop transfer. So you want to actually respect that rather than try to select, say key bees that select the field, but you want to propagate so.

J

There's a couple of reasons: firstly, it just makes it easier for client authors, because I said this is this: does not map to the presentation that is used in in clients generally, it's which is body plus attachments? The second reason is, it also makes easier to optimize fetching. So it's a to optimize. The network usage I want to be able to say return me just the HTML body.

J

Representation of each of these messages, without having to fetch, are some kind of overall structure object, interrogate that work out, which bits and individually fetch each each of those that becomes a lot more Bo overhead and complexity to fetch. What I need to just display this message in a client.

H

Or, if have an option, to get back the original message, so this is.

J

One of the things which organized whether we basically provide both options. So the client can request which it wants, whether it wants kind of the mime structure or whether it wants some interpretation by the server of that, so that it doesn't have to bother passing that that that's what we're discussing the.

C

Fast mail web interface, intermediate code, which I've worked on for this fetches, the body structure for all the messages it's interested in and then it goes through and finds the one where the same part number is going to be of interest to it, and then it does a fetch on that subset of messages for each subset to actually fetch that part of the message so that it can generate the data to display on the web interface and it has to actually be it- has to go through and filter the body structure and say well, it's part number one point one on these ones.

C

That's part number one point three on these: that's quite a complex set of code to find the display text. I.

I

Confirm because well I just throw the same thing in our implementation, which.

E

Is not J map yet.

I

But it's exactly the same problem and once you start dealing with multi-part, alternative multi-part makes multi-part related all arbitrary nesting, yeah yeah, so yeah, if you want just for display, I mean returning a single block. You know whatever text play no HTML depending what the client wants is probably so.

J

That's another question: whether a single blob or one thing we noticed when we went looked annotation for this is actually it's kind of an array of blobs that we get so it's a flat array. But, for example, if you had a message centers with HTML and text alternatives, and then it goes through a mailing list which adds a text only signature as a next apart after it.

J

Then, if you were synthesizing this into a single property, you'd have to convert that to HTML and then append that to HTML to get an HTML version, but then appending that to a HTML is hard because you don't want to stick it just after the end of the line, if you just append them, because that's actually not valid, and you can do this and that what we do and it kind of works every third browser. But it's yeah.

J

It might be nicer just to return the array, because the client is easy to emit, render each HTML text bit and then just pop them all together on the screen. Potentially I. Don't know so I think that's fast discussion. Well, that's not an option. The.

C

Next interesting kind of worm this can of worms. This raises is whether you have a set messages capability to add something more structured than just a single text or single HTML part yeah.

I

Yeah, this actually I'm sort of on the opposite side, because you probably want to have a bit more control on the client who's. A client I mean make the simple case simple, but if the client wants something more elaborate, yeah.

J

I think the same messages would have to mirror whatever we do. Forget messages really like it doesn't make sense to do different, something different there. So if you, if the get message, can either fetch a mime structure or fetch this past version, then I think need to be able to do the same with set if the client wants just do. The past version does that otherwise it so I hit the we.

C

J

Went through at the same time, okay, any comments from the online people on this.

F

I

I have a gut feeling that well might have a a bit more discussion of this in the mailing. Oh yes,.

J

I

Actually get their heads around this, this.

J

Is definitely more discussion on the mailing list and I?

J

Think oh I, don't know well I wanted to get people to start thinking about it here and we'll maybe send through some ideas of Basil's I, said I think this is the meatiest issue still remaining to be resolved so worth worth a bit of thought. The other thing that's come up kind of related to this, although in some ways differently is wanting to be able to fetch partial body.

J

So suppose you had your HTML body, where we've service magically worked out a single text, HTML thing to represent the body, but that HTML thing could be three measures of text and as a client, you only want to fetch. Maybe 100 kilobytes up front, especially on the constrained environment, so you're not wasting, and then only if the user says yeah I won't see the whole thing. Do you bother fetching the rest?

J

So we don't have a way of representing that at the moment in in J map, and so whether that's part of something custom for message or whether that becomes part of core in some way of some custom thing of determining. For a string I'm not sure about that it seems fairly limited in use case, but yeah. That's.

I

Probably one of the more useful features of IMAP, actually so yeah yeah I, don't know if.

F

I

Hear you I can't hear you I suspect it's one of partial fetch is one of the most more useful features of IMAP so but probably need to do that.

F

So the other Neil says every client I've worked on, wants a pair of HTML attachments to actually display the message content at the UI layer. So somebody has to solve the problem at some point in the pipeline and it's better in my opinion. If the server can so things like search and message body display are consistent.

F

Chris says the structure. I prefer is main inline, blob or array of inline blobs plus array of attachments, but the array of attachments has an optional question: mark IMAP style, mine, part number. This allows conversion between flat attachment view and mime hierarchy, Jeff says, but that makes the server responsible for some of the presentation decisions. Presuming he's going back to Neil's comment, which is, in my opinion, not a server problem.

F

Neil says that's a fair perspective too, but it does impact consistency with search hmm I.

I

Think I don't agree on attachments numbering. If, if you want any structure a publisher to use IMAP, you know number dot number. That would be probably the easiest way of doing it. So does that mean.

F

You agree with Chris I.

I

Agree with Chris, I, think and clients who don't want to use that they will just ignore it.

H

Right right, okay, so in okay and I, think it's actually it's a really hard problem. If you have both the server and the client trying to decide which mime part was to show, on the other hand, in dust cloud you have to do, you have to deal with also in line in line attachments like CID type attachment, whether you want them or not. In the case of partial body, fetch you get something even a bigger problem: you are, you may cut off HTML in the middle and cut off. Html middle can have drastic different behavior.

H

In particular, you may have like several that perform some kind of abuse detection, but if the you are is a chaotic that yet twenty kilobyte Reis actually can be a good vector for abuse to have something different, ending up showing up in the mailbox. So.

K

That's a great point so.

H

If you start to cut things up, try to do your job, you have to think everything again. Yeah.

J

I think this is a good point. There is certainly security issues that can result from chopping, HTML or arbitrary points and I, don't think it's it's not easy for a server to chop it off and manipulate it search to make guarantee it's it's safe. In that respect, I I. On the other hand, I mean the client you're still going to make sure it's not running scripts or anything like that, but yeah. It's a.

H

Step of sanitization.

H

J

Things like you are ELLs, I agree. If he knew where is gonna be chopped, you could change the URL that's coming through. That is yeah. That's a legitimate concern. Yeah.

I

Yeah, it's actually partial might be even more interesting, more interesting for attachments. You know, especially if you progress you well.

J

You attachments at the moment with a quick home format. You are you just get the blob ID reference and then you download the blob using standard HTTP. So you can chop that off wherever you want as a client.

I

J

Or variant, or whatever method you want, is only really for stuff coming over the API, which is many your text body, HTML body that you might want to be able to chop off some other way. Someone.

F

On me, deco tell me on jabber, if you can hear alexei because in the room, it's he's not coming through the speakers very well, but he might be coming to you. Jeff says another option return. I map style structure, but the server tagged certain parts as body and others as attachments and the MUA can assemble all body parts for displaying and jabber says they can hear you fine. So don't worry about it. That's.

J

An interesting idea, it might be one of the options we offer the main tricky bit. I like, I think that makes it very hard to optimize your network uses, which is one of the things that we've been trying to make happen, because you don't want to download all of the alternative parts if you're only going to display one.

J

I think that's quite a lot of waste overhead, especially with large messages right and but if you only get kind of just the outline structure, you didn't have to make successive requests once you decided, which ones you want to fetch that data. So you end up with more round-trip. So it's it's. It's a trade-off. I know idea and.

C

We're back at the imap case of having to I guess at least, would get messages. You can specify a different different. No, you can't specify different fields for each message anyway. No, yes,.

J

If you have to well, oh.

C

Yeah, yes, but.

J

C

You did wind up with that same IMAP, client, problem of having to pre, pass the body structures and work out which parts you want for different subsets of the messages and then make multiple requests. I.

J

Think you'd have to return them as blob ids and then you just download them all as blob ids as if you had HTTP to feel download server. That's not too bad with the overhead, even those lots of requests, but it's yeah. I do.

F

J

They wouldn't ban graphs handles.

F

J

Potentially, it depends on the output format um that we come up with, I think we'd have to we. You can't tell that until we have a bit more idea of what we want the structure to look like and what's returned yeah, it was possible that backrests could help with this. But at the moment it sounds like, what's being proposed, is returned to the client requires more processing than you know which why not to make the back reference stuff some kind of a virtue, scripting language, you can run on the server.

J

It's just very basic syntactical transformation to get results when previous thing- and this at the moment sounds like I'd, be beyond that, because it requires actual some kind of intelligent algorithm to determine which body parts you're interested in.

I

Yeah I'm just I suppose there might be sort of different types of clients. Basic clients might just want to have like single HTML, for you know just extract or an array of HTML. You know pieces, as you say, for inline parts and don't bother with you know, trying to figure out what's needed.

J

Iii think that, but most clients would want that if that's what they can get because I, you know it's Neal said via the Apple clients all end up. Constructing that gonna be internally I know are well it does that internally, as far as I can see from the display model, we've.

I

Done the same yeah.

J

I

It's we basically have a bunch of render classes that generate HTML, so equal they're called recursively, and you only for multi-part alternate. If you wanna face whatever you, you can render yeah.

J

So this is being done everywhere as far as I can see and I'm, not quite sure what this non-simple Klein that's gonna do something different is because I haven't I, guess if you're, using if you're using email, not actually as email, is there some kind of bus system? Instead, then you start to get into a point where you might something different yeah.

I

I guess the question is where the client wants to know you know: is there like two textual parts or a single textual part? Maybe it wants to put separate delimiter between them. I, don't know, I mean that's sort of a bit obscure, but you know that might affect you I potentially so maybe just getting away with the array of things might be good enough. Yeah.

J

You know I do think you. Your client still needs to be able to request like HTML version or text version, if there's alternatives and maybe know that the other versions there, even if it doesn't fetch it, that's the other kind of thing that I don't have a solution for necessary. That's great at the moment, but yeah Neal says.

F

For the raw representation, are we thinking really just pure raw or some kind of parsed JSON representation allow what the Gmail API does. Oh.

J

I think some kind of pastures. Well, my goal was only over the API, it would be. You can fetch the structure and some kind of Jason thing more like the Gmail API or you can fetch this more with processed version, which gives you their bodies and attachments which we seem to think most clients. They're gonna, want you.

C

Can always pitch the Roar or RFC a 2 to s. It's called in the IMAP standard via the blob ID as well. Yeah.

J

But I would have thought if we can, if we make them, if we do the API right. A lot of certainly new clients would never do that, because why write all this complicated, parsing code when they don't have to? And we don't want to require that unless you're doing something really obscure, that's always there's kind of the escape hatch, so we don't have to cover every single option. You know we want to cover all the common things and yeah you really have to. You can fetch that, but you shouldn't have to for most cases, yeah.

I

Roy's, probably for you know, import/export type thing is.

E

I

Something very elaborate: you know some kind of analysis of message for display you you hmm well again, we can actually probably.

F

I

This on the server it.

F

Says signature verification to which Alexei responded? We can do this um so yeah.

J

Obviously, if you have keys that only on the client, then yes you'll have to download the raw water be able to do any kind of actual verification of signatures or even decrypting encrypted blobs. Potentially, that's.

I

Yeah there are some interesting interaction, whether something I.

J

I mean I think this is where we've well for now. We kind of said that the escape hatch of devolve always kind of handing that but yeah. If, if the client is the one, that's to cookie I, don't see if the server is the one that has the keys, then it can just present all this anyway, doesn't matter if.

I

It's on the signatures or can do all the job yeah.

J

I

If it's epically, encoded single part, application /, whatever server, can actually decode and presented in a mime format, which is much much nicer than having.

J

I

In the client, that's actually would be a very nice feature so.

J

I

Server can't decrypt, but the server.

F

Can verify signatures yeah.

J

Okay, so that does sound like that would be valuable if we can represent that in a more high-level way. Maybe.

I

We can add, you know small issue: / eg request for spam signatures.

J

Yep, would you like to help specify what it is you think, would you look like sure.

I

F

Alexey how's she.

I

Doing I was just fixing this. You know the last week, so yeah I have some idea so.

F

Alexa has an action action item to provide text. Neal says I agree. It would be very nice to have both formats for quote full mime access having the raw raw representation is useful for cases where you want to move a message between two accounts. As was mentioned, import/export.

G

Well, we all there's actually want.

J

F

Perfectly preserve the original message: source yeah.

J

I mean yes: if the two accounts on different servers, yes, then you would need that. I me know if they're two accounts you have access to via the same came up: API, there's a method just to copy them over without having to download and upload it again. But yes, that's true, so yeah we think this is gonna, be yeah. You you're always going to need access to that for those kind of cases, but as far as possible, we would prefer you not to need it.

J

Okay, ah I think that's been a good opening. Discussion of this will definitely continue all this on the list. I think we will be able to agree on something. Is it's not like everyone's got wildly different opinions, but there's certainly different ideas, which we should have a look at. Try out see what they actually looked like with real messages and then decide and stuff said, hopefully get this over the next couple of months, because yeah, ideally we'll have pretty much all the issues closed off by March and start doing some in shop testing them. Okay,.

F

Chris for security considerations will have to say something about HTML security filtering it's safer if the server has a whitelist HTML filter by default, but that increases complexity. A lot, an extension to request HTML whitelist filtering by the server would be very interesting to client authors, yeah.

J

We've kind of got away from this in that we found you can now with with more modern browsers. You can often do better filtering in the in in the browser, because you have the same Dom parser, rather than a different one, which is often where bugs creep in when the dump are slightly different to what actually ends up being passed in the browser.

J

H

Definitely suggest like having both approach in the case, because unless a client knows exactly what's going on, the server like displaying I'd push displaying raw HTML will be like suicide, or you have a lot of side effect possible depending on implementation, depending on which platform you're running on. So you have to be extremely defensive, but.

K

H

Same time, definitely good to also have like a client client signed either in particular, if you have any mutation possible on the client yeah.

J

I know the difficulty would be on the server again. He said you don't know what the target client is and what's dangerous may be slightly different, depending on the user.

J

Agent ends up rendering it so I think, regardless of what happens on the server the clients always going to have to do its own filtering, and so the question is whether there's extra value and having the server do it as well, or whether we found that these days, almost it's the server, doesn't add as much value and 10 and has more likely to mess up the formatting and stuff because it doesn't have as accurate a pass tree now.

J

Admittedly, you there are now full html5 compliant parses that we could go find as well for a server that we've tended to move towards doing this on the client.

J

Okay, but it's a good point: we should probably still maybe discuss bit further whether we want that as an option, but it's it's tricky because again, you certainly couldn't specify a particular algorithm. The server would have to use and the client can't rely on it 100% because of that anyway.

J

So there's a question of how much you'd win if you're writing an object, light knob, tree server, I think, okay, last couple of minor points that mean some discussion of ACLs in the last few months in particular, you know bring back a some kind of mapping for an ACL on mailboxes, for whether you can edit the key words and you need.

J

If the messages in multiple mailboxes you're gonna, you need permission on every mailboxes and I think to be able modify the key words because the site, that's the only eyewitness, but one thing that has been brought up is that the scene keyword is kind of special in IMAP. There's a lot of special casing, certainly in this iris IMAP server for this versus other keywords. It's included in this computed count on the mailboxes object is unread Affairs and unread messages, which is actually kind of flipping the behavior, because everything treat stuff as unread read.

C

J

And there's obviously different ACL for it and IMAP as well. So kind of there are two questions that kind of raised for this. Firstly, do we want to keep a separate ACL for this in geomap or just merge it with single ACL? For all all keywords?

J

The second question comes from that, if it's a separate ACL, does it actually make more sense to take this out of keywords and map it as a separate is unread property on the message object, because that means your ACL affects one particular property rather than kind of various a bit of that, and also just cuz, it seems to be quite special in various other ways.

J

Maybe it's special enough that we take it out of keywords, I think one of the downsides this is, it does mean there will have to be more to plication off things like the message list, filter and search where you have things like is all in thread. The all in fred has keywords. Some in that is keyword. You need to mirror that, with all in thread is unread, some in fetters on red, etc. So that is a little bit of kind of duplicate of stuff that ends up there, but any opinions on on this.

I

Alexi as far as ACL slight preference for having keeping parity with M I'm a pace, yells back okay for people who implemented it just makes it slightly easier. But of course your specific server can always bundles rights. So if you're writing one from scratch, you probably don't want to have them separate anyway. So you just or not, you.

C

J

Okay, so slight preference police having separate Al and.

I

About separating it as a separate property, a bit ambivalent, yeah.

J

I'm a bit as well I think I some ways I like it in some ways, I think it's just a bit annoying having a separate I, don't know well.

F

The only issue is, if you are not allowed to see keywords, you don't want that to prevent you from knowing whether a message is seen or not. That's the concern.

J

But the ACL is about writing it, not about seeing.

F

It so the other way around. Then, if you can't set keywords, does that mean yeah, there's a there's, a reason. It was separated and IMAP so that you can view a message and have seen flag set without being able to. You know, do the other keywords, so it's sure.

J

But you could enforce on the server where you try and set the keywords property. If you try and change anything other than seen it gets rejected. If you don't have that ACL, it doesn't need to be a separate property to have it as a separate ACL. It's just maybe that be nicer. Yes, okay,.

J

Any the people online got opinions on this. Was this a another kind of just ambivalent pick? Something can.

I

You remind me of somewhat related the we have deleted. No.

J

There's no deleted FAQ.

C

I'm in favor of it being a separate properties, Bron here, largely because I think it's simpler harder to get wrong.

I

This will affect search. Yes, is it a problem? It.

J

Will affect search? You know you need.

I

To look well, you will have to special gazing for CMC in a flag, as opposed just I'm I'm asking I'm, not sure it's a big deal which is sort of pointing out that at vote.

J

I mean the main thing is: it makes the mapping from my Maps slightly more complicated, I guess because you're mapping a keyword to a specific property rather than just mapping them straight to the keywords property.

J

But it's not you.

I

Know it's only one special cases they were like you know, even to his already slightly more annoying, but you know of just one: it's yeah just about bearable and.

F

Chris says it was separated in IMAP because of the idea of reading net news via IMAP, with dot news RC, to which I responded. Do we think that's still an important use case to which he didn't respond, but he said: I concur with Alexei, with slight preference for separate ACL, no preference on same or separate property. Okay,.

I

Basically, the same as me, yeah.

J

C

Can tell you that in the Gienapp proxy, which is pretty dumb and does no smart stuff about keywords, I still keep the ease unread as a separate database column field, because I need to be able to count on it to get the counts.

G

C

It's all it's actually duplicated storage at the moment, because I want to be able to generate the keywords properly, just by dumping, a blob, but I still have to keep a separate copy of it for counting on, because it is the one counted flag, counted keyword as well. We.

F

C

F

But going go count, everything says Alexei, but it going back to going back to Chris's point about. The reason that we had it separate was to actually prevent you from setting scene flags in certain cases. If we don't have that need anymore, if we don't have that you case, maybe the whole thing goes away by saying the scene flag is not covered by ACLs.

J

It becomes merged with the single ACL if I said all key words. No.

F

What I'm saying is separate from that that the scene flag is not that there's no ACL but effects.

J

F

J

Know you always have a seam.

F

Right on the guard, if we have no use case anymore, that wants to prevent you from setting scene flags. When you look at the message.

J

Is there a youths case that wants do that, but not prevent you from I'm, not sure all the keywords I don't know so.

C

In this cyrus, I map implementation scene is per user optionally shared but defaults to per user, whereas all the other keywords are shared, there's, certainly a use case for allowing people to have some own some of their own per user data stored about things without being able to change it for everybody. In any case where you share information.

I

Yeah- and there are some male stores where you're me allowed us had seen and all other flags.

J

Okay, I I think it does sound like we want. Probably one separate sales I seems to be a slight majority opinion on. That seems not huge amounts either way on whether it should be a separate property or not all right, I'll think about a bit right up the list, maybe and we'll see if there's any final comments on the list and then make a decision one way or the other I'm good, okay and then I think this is the final thing again. This has mainly been discussed on the list. What happens when you destroy mailboxes?

J

If you had messages in it? So the original spec basically said this was an errand just rejected, destroying the mailbox, which is the kind of more J map thing, because it requires all of the changes to be explicit. So the client always knows what has changed was this is kind of implicit, but it is pretty useful to be able to destroy a mailbox and just remove it from all the messages. So the suggestion was, we add an extra argument just for set mailboxes, where we can say if this was the last mailbox.

J

This was in you. Can you need to either move it to this mailbox? You can say that, or you can might be able to, or you say, delete the message as well.

J

That's that the main concerns over since many ways it's that if you just omit this argument at the moment, that's the same as null, which is the same as delete the messages and maybe that's a too risky default. Maybe if you omit it, it should be an error to try and destroy the mailbox without messages. If you don't explicitly say, I want to delete them. Oh I.

I

Think I don't know, I find it to be reasonable default.

I

Just delete message, delete mailbox with all messages in it. If, if you want to ask you need to ask that user in the UI before you issue the correct, so that once you decide to do it, you know you want to do it, you don't want to do it like you know, 50 commands to direct shave the same right.

F

Note that was what I was gonna say. The the thing is, it's not like: the user is going to be typing in a command that says, delete the mailbox, the users going to use a UI to do it. Yeah right, well, yeah.

E

F

Who does that deserve what they get? The user is going to use a UI, and the UI can decide whether it wants to prompt the user to. You know worry about the messages or not so I, so I, don't think there needs to be any special incantation. If you delete a mailbox, you delete a mailbox so.

J

Barry you're, just just clarify you, don't think we need any extra argument at all. It's just you want to move them out of the mailbox first. The client needs to do that and then delete the mailbox. Otherwise.

F

The specs the spec says that the spec should say when you delete a mailbox, any messages in it are deleted. If the client needs that behavior to be different, the client needs to deal with that on its side to be.

I

Honest I don't mind the extra parameter, I think I'm more concerned about the default mm-hmm.

J

F

I

Value of the extra Prowler.

F

I

You want to move all.

F

Orphan messages to another mailbox I, don't know whether the point is that the client knows whether there are messages there or so. What is the value of making.

E

F

Client put a parameter on or not when the client can deal with moving the messages or not. If it wants to I.

C

Haven't answers this: you could have a mailbox with a million messages in it and you don't know how many of them are also in other mailboxes, because a message can have multiple mailboxes and then, when you delete their whole million messages, you're not actually deleting a million messages you're taking that mailbox, ID of 900,000 messages and you're deleting a hundred thousands because they didn't haven't, have a reference somewhere else, at least with.

C

If in state, you can make sure that you don't delete a message that you never knew was there, but you, you still wind up deleting messages because they didn't have a reference to another mailbox. Okay,.

F

Maybe I misunderstand what we're talking about here then, so this is if, if, if this, if this flag is not set, then it will still delete the mailbox and get rid of the messages in it as long as none of them are actually being deleted. Okay,.

J

So when you destroy a mailbox, you remove that mailbox from well one option: is you remove that mailbox from every message that it used to be used to be in it right, except that? If yet, if the message was only in that mailbox, that is destroying the message as well, I understand so be. The extra argument was meant to be. If this is the only mailbox, it was in then move it to this mailbox rather than destroying it. Otherwise, it's fine, because it's already in something else.

F

I

F

I

Like you, you moved it from inbox to an ACK another folder, and you want to return everything to inbox on delete. So.

C

I

Live that so I the.

C

I

Don't have to be the default base, there's.

C

A discontinuity here between set messages and delete mailboxes. You can't set a message to have zero mailbox IDs as a way of deleting it, but deleting the mailbox as a side-effect sets the message to have zero mailbox IDs. That.

J

C

Which destroys it, but we don't destroy messages by removing all the mailbox IDs. So it's a different way of destroying a message.

J

C

J

Sure it matters that much terrorists, so okay, I guess yes, what kind of poll of people online and in the room? Would anyone actually use this argument on last reference move to or if just if you, the kind of if the default behavior was it destroy the message if that was any mailbox was in, and that was the only behavior you got that that'd be fine Neal.

F

Says my two cents delete a mailbox, deletes the messages unless they're also in another mailbox, so he doesn't.

J

See the nice doesn't even need for the parameter.

F

Which I, which is how I feel but I, don't object to have I.

I

Can find all the messages that are only in this mailbox and no other with a single search command right.

J

I

So so so that's well, yeah I mean. If you really want the behavior, you want, you can add an extra command, so I'm a bit ambivalent, but I can live with extra flag.

J

Sure aiya well the same time, adding stuff that no one's gonna use is a waste of time right.

F

The other side of it, of course, is the client can decide whether it wants this feature or not so, okay, so servers have to support it. Clients don't yeah.

J

Okay, so it doesn't seem to be anyone that here are those I think there was some of them Lynne Agora, that was concerned for default, deleted messages, business on my own else's concerns, so I'd say: that's probably still rough consensus. That's fine I'll do if I don't call on the list with again summary of that, but I'm leaning towards maybe just a meeting the whole argument as I no one's gonna use it. What's the point Chris.

F

Says I think a reference to the trash folder is an interesting value for that parameter.

J

That is exactly.

F

Why Drew's thinking.

J

F

Comes up to the microphone, he has a voice Pete.

E

Resnick, if I'm implementing trash as a UI element, if I delete a message from a single mailbox, even if it belongs to multiple mailboxes, does that UI wise make a copy in the trash or not I am what am I exposing to the user? Am I exposing multiple mailbox existence, or is it multiple messages that happen to all point through the same message so.

F

I'm I'm app has is a very odd thing with implementing a client-side trash. Folder and J map doesn't change that, but still, if you have not retrieved the message to the client, you can't put it in a in a client-side trash folder, well Lea, so the the any reasonable IMAP implementation is going to have a server-side trash folder right reason. So if I've got a server-side trash, folder.

E

F

E

A message in multiple mailboxes, not the Trash folder yep.

J

E

I go into one mailbox and I delete the message yeah. What is the user experience supposed to be like? What am I exposed.

J

This would depend on your client, but I would expect it if it's actually labeled delete I would expect it basically to remove it from that mailbox and add it to the trash there's also in the other mailboxes, and if you empty your trash, it wouldn't delete it from the other mailboxes. It would just remove the trash so.

E

The user experience is those are copies, even though they.

J

E

J

Facts are the same. They are the same ID. Yes, so.

E

Given that, if I delete the mailbox mm-hmm one choice, well, one choice is that's the problem. One choice is to say to delete. The mailbox is to remove this mailbox from the messages and add trash to them right. That would be one way to implement and and then I don't have to worry about this move it on last, because if the user sees that, as deleting this mailbox deletes all these messages, maybe they all well.

J

I mean the client can honestly do that beforehand. They can make sure one moves everything out to the trash before it's right. Let's say.

E

Yeah this the operation becomes a add trash to all these messages. Remove this mailbox from all these messages, that's what delete the mailbox is and.

F

E

F

Only issue with that is, if you have a limited size, trash folder, then you can wind up flushing your trash with messages that you didn't really need to trash. There's some stuff from jabber Robert says: wouldn't an on last reference move to imply an account global lock on all messages for this operation.

F

Sorry meant for all messages within at least this mailbox.

J

F

Then there's something else but I mean he might sue says depends whether it's a ton.

J

Well, that the a single method call it's their method method calls must be serializable, so potentially yes within the method call, you would need to lock the account while you're processing, those and.

F

Neil says maybe deleting a mailbox should move the whole mailbox to be a sub mailbox of the trash I.

J

You can already do that by just setting the mailbox as as a photo I. Don't think that needs to be that's different, deleting.

G

J

I

Alexi, all of these separations can already be done. You.

J

Know the methods so.

I

Maybe we just need some text around saying that the default behavior you just you know you delete all messages and you delete the mailbox. You know it's all gone. If you want days to day, you know if you want to move mailbox on the trash to this. If you want to move into trash, do that.

F

Yep, that's Chris response to Robert says it could be implemented with a conditional store on the messages list of folders as an alternative to global, lock.

J

Okay, um I'll yeah I'll, send it around this one small time but I Oh, Pete's gonna come yeah.

E

This is definitely by cutting a point. One other solution to this problem is destroying a mailbox is not an operation right. You want to destroy a mailbox. You search for messages that have that mailbox and say remove that mailbox from those messages, but.

J

You need to have.

F

A message right: you want that that mailbox either to be in a list of mailboxes with zero messages, but.

J

Yeah, thank you. People definitely have mailboxes with zero messages in it and well.

E

How do they work flow.

J

E

It will have a do, keep.

I

J

All yeah yeah, okay, okay, is that's probably enough by actually on that, it doesn't seem like it really matters too much either way based on who said so. The solution- hey.

C

Pete, you could have an anti message which, if you moved into a mailbox, made it minus 1 and then it removed from the list.

J

Yeah, okay, I think, there's all the specific issues I thought we should discuss. Does anyone have any other particular ones they want to bring up this session.

I

I can try to go through my notes. You know some of your changes, especially about sorting they hand-wave about how we sort I, think that needs to be specified and we have a collect collation registry for this, or at least you know, prescribed by default sort order, I think using Unicode, and there is also in some places. You say it's case insensitive and for Unicode. Oh, my god, you just made John John Clemson, very.

F

Well, what you need language tagging to do sorts they.

I

J

Is no relation does the case, insensitive is only I believe. The only place has mentioned is in text search and it's not as a must is as a advise for things to try match, because the search is specifically not.

I

Still need to specify no.

J

Because the search is specifically not absolutely defined because the indexing is getting different like Gmail's indexing or fast was indexing, know what they're not gonna.

I

Change- and I think you need to specify we have a not stupid, IMAP implementations as it is and searches. I think it would be nice to recommend that you know sensible thing for people to do and people can improve. We.

F

Should recommend put in their expected search, behavior, realizing that some implementations will do it differently, but we should have a reasonable expected behavior. That's not that's!.

J

Kind of what stuff mean: that's what happens.

F

Without with their, there are IMAP implementations that do fuzzy searches, even if you don't ask for them and stuff like that, but.

I

About that sort of within their expectations, because it's more you know, use a visible thing right, but saying that you know and by the way, if you're doing case insensitive. This is what we meant. I think that that's is useful thing sure.

J

Is uh which I don't think is any way I'll.

I

J

Really send you some yeah.

I

J

J

The header names yes, are lowercase, but they're asking any form of C 5 3 2 anyway, so it doesn't matter so I.

F

Ask you only your you're in good shape by saying yes.

J

F

Or case insensitive, it's only the utf-8 that you have yeah.

J

Iii, actually, don't think, there's any way. I wear it. That's mandated.

I

I'll check again, actually this reminds me there is another issue with you're searching for header fields, especially searching.

E

I

Values that for header fields, you don't know the syntax of the document- says Uther's decode them to utf-8, which, if you know.

E

I

Syntax, you cannot do this you're, probably what you know. Even if it looks like you know, RFC, 22, 31 and coded word. You shouldn't be touching it because if you probably should just search for it as specified, but.

J

If you're searching for lightly.

F

Not expected behavior if I have a subject line no.

I

No I'm not talking now for header fields, you don't understand.

F

I

Is like okay June, my.

J

I

Spam engine added X, you know anti-spam not score, but I, don't know keyword or whatever mmhmm.

H

F

So if you have the the encoding, it's still I think expected. Behavior is still going to be to decode the field. It would be very unexpected. No.

I

F

Can't expand, you know in wait.

I

Like RFC 22 31 is not defined for Hydra feel, for you know it's not generic. It doesn't apply generically it all header fields, understand.

F

I

Only applies to known Heather field.

F

I

F

Like if you want.

I

To search for message ID so.

F

Realistically, if you had a Russian anti-spam engine that put in an anti-spam message that said in Russian, this is a pile of junk and you were searching for that. You would expect to find it not expect to have it fail to find it because you didn't decode the field, even though it's kind of non-standard behavior, it's still common to encode, an an arbitrary field, I, don't.

G

Think you should yeah cheer Pete's.

F

F

Alexis's, don't mess with stuff, you don't understand so.

E

I know there are clients or a fact that do 22:31 processing over anything they're gonna display no.

F

Matter what now.

E

Should that reflect itself in search I, don't know, but clients do that clients just go ahead and eat everything now so I.

F

Just think that if you don't decode the fields you get you get user surprise.

I

No, you typically, if you want to search for specifically, so if there is a fixed small set of fields that we know about like from date subject, you know to GC decoding. There is absolutely fine because they are well specified. They're, structured header fields, everything you don't else you don't know about is unstructured.

I

That's why don't mess with unstructured, but.

F

Which is everything else? It says.

I

F

It happens and it's well-defined enough that if you look at one of these fields, you know it's been encoded and you know how to decode it. So even.

I

Including our Haven, and we have actually an extension where you cannot say I want to search as specified without decoding or I want to search for decoded failure. So may I I'm, saying that we might need a knob for this I'll.

J

I

To control that by.

J

By doing a raisin issue on github with that and you you have other notes as well: I.

F

The other alternative is, we can just say it's a quality of implementation issue. Client I mean a server that doesn't do the decoding when the users of that server expect it might become unpopular. Who knows, but but I I would like I, wouldn't mind having uh you.

J

Know I I think generally, ideally, when you fetch the header it's going to decode it so that it displays, as the user expects it display and if you search it matches what the user saw when if.

I

It has a structure, you don't understand. If it's not for display, you might fetch it for other reasons, because because you want to search, you know.

F

Anything else anybody on Jabbar.

E

F

Want to chat about Oh, Alex, I'm I.

I

Think we decided that all the game app keyboards will be starting with Stoller, but in IMAP it's actually not a requirement. It's.

J

Not all, but the cysts, the we're doing is mapping the four system. Keywords from IMAP, instead of being slash scene, slash, it's a dollar scene dollar, okay,.

I

I think, when you're doing search for various things you you include dollar keyword in there. So maybe you should be a bit more careful saying well.

J

That's the name of the keyword is dollar flag to.

I

Know it was as in as an example of syntax. It says dollar keyword as opposed. It's, not the name of Cuba.

J

Oh yeah editorial.

I

Yes, yeah yeah.

J

That's public infusing, yeah, crying Jason.

F

Alexei continues to look at his notes. I think.

I

You have a minor thing: I can send it an email when deciding for message submission. You know, what's the primary, what you are going to put in mouth from by default, you assume that sender can have multiple values. I, don't think sender can have on the front, can have multiple value. Sanders can't I mean it's sort of the way. It's it's war that you take the first one even from the sender, but in the center you can only have one so I mean it's a Magna thing. The.

J

Past version, the message yeah.

I

There is some text about forbidding messages with the same message: ID in certain cases, I'm slightly uncomfortable with this.

J

J

C

Won't be that email, ID and message, yeah I, think the decision.

J

C

Whole reason we're gonna.

J

Be named message.

C

J

If I just was the case is a good good taste point they're saying we should definitely name.

I

Yeah because I thought you know okay well, some people want to preserve all copies of messages. Some of them go through mailing. They.

E

Definitely have go.

I

Direct you, you will have duplication.

J

So you have, you know.

I

J

I, don't believe, there's any where it says you can't have two messages with the same RC: a to change.

C

J

C

That's probably okay, it may be worth having an editorial thing to say that messages with the same RFC message: ID can have different email ids if they have different colors. Although.

J

C

Even if they're.

J

Yes, I mean Gmail I think does not allow multiple messages with the same message: ID that correct they're a to two message: ID, but.

F

I

J

Other difference.

I

Is met its message, suppression right now. These.

F

I

J

If you try it actually, what happens? We try not load like bar I'm Apple, something is it only on delivery. It stops that or was it at any point, Neal says: Gmail D duplicates them yeah.

J

I

It lets you upload and then.

J

It one of them just.

I

J

Well, anyway, the J Matt wants early, not forbid that we may want to mention that it may forbid that just so, Gmail can have a chance of meeting at all. We could just probably not bother.

F

Email specs already strongly recommend that you don't have duplicate message. Items I, think that's good!.

J

Well, yes, but as.

E

I said reality and receive.

J

Stuff by message list and various other formats, which are slightly different and also say my study, I, don't.

C

Think there's anything in J map that forbids the server from doing whatever it feels like at anytime to you.

J

That's true, so if.

C

You don't nice to delete the other one. Then it can still do that. Yeah.

J

That's true, but.

F

We don't need your.

J

I

Yeah as long as you don't prohibit what people are already doing in a right. Yes,.

J

Absolutely yep I.

I

Think that's it.

F

hmm Says: Jeff? What about drafts with missing message? Ideas.

J

The believe it's already in the spec, the sir, is meant to generate a message ID if you try and create one without explicit one set in the headers. So the stored version on the server must always have an eight to two message: ID.

J

Hopefully, most.

I

Of it, I don't have control absolute.

I

J

Can set your own as well so that you can preserve it after a draft has been created. If you can you copy the dog, what.

C

Happens if you upload a message that doesn't have an RFC message, ID and then import messages on it.

J

C

Up to up upload a blob and then call import messages too well,.

J

I would say it's up to the server, so one option is the server can reject. You is an invalid message because they can always reject whatever you blob. You upload is not being a valid I, see HTT message or the other option is. The champ doesn't actually lie on the eighty-two message. Id at all, so there's no reason why couldn't exist in the game. App Store. Now. To be honest, you really wants to the.

C

Interesting question whether the blob gets changed in that case that.

J

Is an interesting case: I'd, yes,.

C

J

C

J

Whether it's allowed to modify it yeah.

C

Because there'll be other cases, whereas invalid characters and stuff or infamous moment coding of headers, it.

J

Probably should be allowed.

C

To do that yeah definitely or do you want to change it.

H

Be valid Nicholas I'm Nicola, so it is like fairly common behavior that once you upload a draft to a server which, when you feature fit, you fetch it back in the AP afterwards and you may have seen like several sites and addition of the compounds. Yes,.

J

The server can add extra heaviness to it and.

H

Headers as well the HTML, if money.

J

H

Already being cleaned up, you need the you need things like that to actually avoid some kind of reflective of RBG, where you upload, mostly HTML HTML with one row client, but will end up on all the other clients mm-hmm. So.

J

H

Trust draft either, so you need to sanitize it. We.

J

So yeah so I mean Jamie already has a in just the cool syntax. The server is allowed to return any properties that it changed. When you create something. So we can, we can just specify that it's allowed to change any of those properties and there's already a method for it to tell the squire what it changed. If you change anything, so you can see so when they upload it immediately.

H

J

H

These these, these.

J

Properties are now this because I did this okay, so we just need to make clear that it's.

F

Allowed to make those changes, jeff says importing a raw email is okay, with respect to the server changing it up, since the important email can have a different blob ID. If I remember correctly. Yes,.

J

I think that is correct yeah, so that.

F

K

Be fine I think we.

J

Just need to specify that that is permissible in the spec.

J

Cool any other business. Finally,.

F

Okay call for other comments going once all right that didn't take long.

H

You have any bathtub provision in case. One of the attachments should not no longer being downloadable. One of the attachment of some far they've won a one common example that would be like server-side, antivirus I would say you should not download the file. I am.

J

There's no specific provision for the moment, but there's two options: one option is obviously the server can always delete the message and recreate a new one with a different message: ID, which is the same, but without the attachment so different, email, ID, not RFC, 882 message ID, so they.

H

Say you receive an you, you have an email in your inbox, yep.

J

H

That message have an attachment and the server after this I determine that attachment have the virus and she it will fail, like you, cannot fetch it anymore, and you should actually provide the information. Why why you are not able to so.

J

It could the cervix certainly refuse to return the data when you try to fetch the blob ID. So the blob ID represents the actual binary data of the attachment. We don't have a specific error response for the server has decided. This is dangerous, but we could certainly add that as a response.

C

Code, it's a standard.

J

Http fetch so I, don't know if there's a standard, HTTP response for the services. I did not return this data because of security policy, but the the other uh I guess the other options yeah. If we could, if you want a way of returning this kind of in the past message, format to say this attachment I, so you want the attachment to be there. So then users know that wasn't attachment, but just the same.

H

Meaningfully Rama error explain to the user. Why? Why that fine? Not while you have an arrow explaining the arrow to user, so.

J

That sounds like it should just be an error. If you try and download the binary data, then throw an error return from the the blob downloader, essentially.

H

Ever is feeling servers, yeah.

J

Yeah I understand yeah.

H

J

So we can definitely add that I think as a yes policy refused error or something if you try and actually download the binary data. Obviously, if the client downloaded it before with a server decided is bad and it's cached it there's not much. You can do unless the client checks again later. That's where, if you'd have to actually modify the message in some way, so it got the update.

H

Another point is from earlier description. You, you suggested like a possibility for the server to decide what the client would see like a design like how you had to radically decide which body part to show that's.

J

Something we discussed in the moment, yes, is being.

H

One question: what does he believe some? Why what provision you have for for seeing a client to redownload in case it doesn't have an up-to-date Sarah decided version, then I say the server decide like I took for the time after you don't know date, the body the modified body decide to change the content. They say there was a Bergamo server-side hard to get the client to research. The updated drops you'd.

J

Have to change the ID of the message, because the meta mess, a message like an IMAP is immutable.

E

J

It's the J map message ID, which at the email ID. So this is why we're going to rename it from message to email. So to avoid this confusion. So yes, the the J map, email ID, which is just an arbitrator assigned ID, and it's it's not from the message content itself. It's I mean it could mean.

H

It's everything from the method, everything from the old message and get the new one in yes,.

J

It have to basically replace that message with a new one which had the different.

H

J

Necessarily because it depends on how the server does it, the attachment has a blob ID, which represents the binary data, which is the bulk of the attachment, and if your server does that by like char 256 of the data which is kind of what we do, then you would see. I already have that if you download the new message, but the message reference is the same blob ID for the date with the attachment so go so I already have that case, so it wouldn't necessarily have to download the whole attachment again.

H

J

Not tied to the message-id no independent, so yes, you could get a new message but still keep the case. Data for the attachment Chris.

F

Says actually for the virus case, you want the client to know it should remove a copy of that attachment if it downloaded it can be done. As an extension dollar contains virus flag, an attempt to fetch part returns, a useful error.

J

Yeah yeah no ways you could you can signal that as I? The other option would just be to replace that message with one that didn't have the right.

F

Chris's point is that the you would have to make sure that the client knew that it needed to actively get rid of this. Well.

J

If you replace the message, then you'll get push, updates and I'll see. If that's the only message that refers, that attachment, it will fuch everything for the case yeah, but yeah.

J

Ok yeah once it goes outside. If you'll see you mean, there's nothing, you can do about what.

F

John levine stumbled in is now signing the blue sheet and has doubled our attendance in the room. That's.

J

F

I

F

Other comments.

F

Ok back to other comments going once.

F

Other comments going twice and thrice and we're done so. This is the end of the J map session. Thank you all for coming and we'll see you in London and.

J

C

F

Thank you very much folks from meet echo and jabber I know it was it's an odd time for some of you. So thank you for attending.

K