IETF
JMAP
jmap@jabber.ietf.org
Thursday, November 16, 2017< ^ >
Room Configuration
Room Occupants

GMT+0
[05:19:37] meetecho joins the room
[05:25:18] Robert Stepanek joins the room
[05:25:18] Ken Murchison joins the room
[05:25:38] Josef Sipek joins the room
[05:27:52] Chris Newman joins the room
[05:28:32] Neil Jhaveri joins the room
[05:29:30] <Neil Jhaveri> I can hear you
[05:29:35] <Robert Stepanek> yep, can hear you
[05:29:37] <jeffpc> yep
[05:31:51] Neil Jhaveri leaves the room
[05:31:52] Robert Stepanek leaves the room
[05:31:55] Neil Jhaveri joins the room
[05:31:56] Robert Stepanek joins the room
[05:32:57] <Ken Murchison> OK.  Thanks Barry
[05:35:14] <Chris Newman> If the slides available via the agenda are up to date, we can follow along if you say what slide you're on.
[05:36:03] <Ken Murchison> Chris is right.  We can go old school
[05:38:30] <Ken Murchison> Slides are here for those that may need them: https://datatracker.ietf.org/meeting/100/materials/slides-100-jmap-slides/
[05:39:55] Barry Leiba joins the room
[05:40:50] <Barry Leiba> If anyone on jabber wants to chat, feel free…
[05:41:26] <Barry Leiba> Is there anyone on jabber who does NOT have access to the slides from the meeting materials page?
[05:41:49] <jeffpc> (works for me)
[05:41:56] <Neil Jhaveri> (works for me too)
[05:42:20] <Barry Leiba> 2 of 5.  How about Chris, Ken, and Robert?
[05:42:29] <Robert Stepanek> fine with me
[05:43:30] <jeffpc> nothing on the feed (yet?)
[05:43:49] <Ken Murchison> Lift off!
[05:43:55] <jeffpc> I don't
[05:44:04] <Neil Jhaveri> I refreshed the page and now I see it all
[05:44:04] <jeffpc> aha!
[05:44:08] <jeffpc> all good
[05:44:28] <Neil Jhaveri> Slides just went black
[05:44:45] <jeffpc> works again
[05:44:49] <Neil Jhaveri> It's back
[05:45:03] <Ken Murchison> Please announce slide number as you get to it in case we lose video
[05:46:02] <Barry Leiba> A-GEN-da schlide
[05:46:39] <Ken Murchison> I blame Alexey
[05:46:51] <Barry Leiba> I do too.  :-)
[05:47:06] <Barry Leiba> Patch updates
[05:47:59] <Barry Leiba> This looks SO much better than IMAP syntax….
[05:48:16] <jeffpc> is that... sarcasm?
[05:48:26] <Barry Leiba> He-he.  Yes.  Mostly to be silly.
[05:48:49] <jeffpc> :)
[05:48:56] <Ken Murchison> Barry set pretty low bar ;)
[05:49:17] <Barry Leiba> Back references slide
[05:51:30] <jeffpc> possible issue: a jmap call containing both "ids" and "#ids"
[05:52:19] <jeffpc> it's just a thing the server has to check
[05:52:29] <jeffpc> because the key names aren't the same
[05:53:05] <Robert Stepanek> core spec should reject requests as invalid that contain foo and #foo on the same level
[05:53:06] <Chris Newman> Question is would the server have to merge "#ids" and "ids" and compute result on the merged list?
[05:53:08] <Barry Leiba> Slide with no title.
[05:53:23] <Barry Leiba> (Sorry, my evil co-chair didn't number them.  I'll cane him later.)
[05:54:38] <Barry Leiba> Push Support
[05:56:36] <Barry Leiba> Authentication
[05:57:48] <Ken Murchison> SCRAM?
[05:59:10] <Chris Newman> While I'm obviously a fan of SCRAM+TLS, the more important problem to solve is client-specific token bootstrap
[06:01:19] <Chris Newman> 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.
[06:02:08] <Chris Newman> 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.
[06:05:02] <jeffpc> pretty sure that forbidding basic will only result in implementors ignoring that MUST NOT
[06:05:14] <Barry Leiba> Yes, I think so.
[06:05:27] <Barry Leiba> JMAP Core Remaining Issues up…
[06:05:38] <Barry Leiba> Top-level API slide
[06:07:42] <jeffpc> doesn't this assume that URLs are stable forever?
[06:08:44] <jeffpc> that's fine, yep
[06:09:40] <Barry Leiba> Mthod naming
[06:09:45] <Barry Leiba> Method naming
[06:11:11] <Barry Leiba> Renaming "Message"
[06:11:12] <Ken Murchison> Syntactic sugar.  I don't care
[06:11:18] <Barry Leiba> Exactly
[06:11:36] <Barry Leiba> Message Format
[06:14:52] vaibhav singh joins the room
[06:16:26] vaibhav singh leaves the room
[06:16:35] vaibhav singh joins the room
[06:18:29] <Neil Jhaveri> Every client I've worked on want a pair of (html, attachments[]) to actually display the message content at the UI layer, heh. So somebody has to solve the problem at some point in the pipeline.
[06:18:51] <Neil Jhaveri> And it's better IMO if the server can, so things like search and message body display are consistent.
[06:19:19] <Chris Newman> 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?) IMAP-style MIME part number. This allows conversion between flat attachment view and MIME hierarchy.
[06:19:27] <jeffpc> but that makes the server responsible for some of the presentation decisions
[06:19:41] <jeffpc> which is... IMO not a server problem
[06:20:16] <Neil Jhaveri> That's a fair perspective, too. But it does impact consistency with search.
[06:20:38] <jeffpc> (yes, I walk talking about Neil's comment)
[06:21:15] resnick joins the room
[06:22:35] <jeffpc> another option: return IMAP-style structure, but the server tags certain parts as "body" and others as "attachments"
[06:22:53] <jeffpc> and the MUA can assemble all body parts for displaying
[06:23:16] <Neil Jhaveri> Yes we can hear Alexey
[06:23:21] <Ken Murchison> We can hear him fine
[06:23:23] <Robert Stepanek> i can hear alexey
[06:24:10] <resnick> Are we all presuming that multipart/related stuff is *not* an attachement?
[06:24:14] <jeffpc> wouldn't backrefs handle some of this?
[06:24:31] <Barry Leiba> Pete: what means "attachment" is very flakey and a part of the problem
[06:24:47] <Chris Newman> multipart/related is presumed not an attachment unless it has a content-disposition: attachment on the multipart.
[06:25:05] <resnick> I meant the internal parts of the multipart/related.
[06:25:17] <Barry Leiba> Chris: but in my experience, content-disposition isn't used consistently enough
[06:25:24] <Neil Jhaveri> For the raw representation, are we thinking really just pure raw, or some kind of parsed JSON representation ala what the Gmail API does?
[06:30:16] <Neil Jhaveri> I agree, it would be very nice to have both formats for "full MIME" access. Having the raw raw representation is useful for cases where you want to move a message between two accounts, and want to perfectly preserve the original message source.
[06:31:28] <Chris Newman> For security considerations, we'll 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.
[06:34:19] <Barry Leiba> ACLs
[06:34:25] <Chris Newman> What you just explained would be good in security considerations.
[06:34:52] <Barry Leiba> Chris: ack
[06:38:06] <Chris Newman> It was separated in IMAP becuase of idea of reading netnews via IMAP with .newsrc.
[06:38:28] <Barry Leiba> Chris: do we think that's still an important use case?
[06:38:34] <Chris Newman> I concur with Alexey with slight preference for separate ACL. No preference on same or separate property.
[06:42:09] <Barry Leiba> Destroying mailboxes
[06:44:15] <jeffpc> null deleting sounds good
[06:44:17] <Neil Jhaveri> I agree, if anything, I recall getting user bug reports where deleting Gmail labels (as Mailboxes) did NOT remove the messages that only had that label.
[06:44:23] <Chris Newman> Barry: the newsrc use case is no longer important. But semantic alignment between IMAP and JMAP simplifies implementation which is why I have slight preference to keep separate ACL for Seen.
[06:46:58] <Barry Leiba> Chris: Yes, I agree with that.
[06:47:32] <Neil Jhaveri> My 2 cents... delete a mailbox, deletes the messages, unless they are also in another mailbox.
[06:48:57] <Neil Jhaveri> I vote for letting a client do a search if it really cares.
[06:48:59] <Chris Newman> I think a reference to the Trash folder is an interesting value for that parameter.
[06:49:27] <Neil Jhaveri> Hmm that is a good point
[06:49:41] <Robert Stepanek> wouldnt an onLastReferenceMoveTo imply an account-global lock on all messages for this operation?
[06:50:15] <Robert Stepanek> sorry: meant for all message within (at least) this mailbox
[06:51:18] <Neil Jhaveri> Maybe deleting a mailbox should move the whole mailbox to be a sub-mailbox of the Trash mailbox?
[06:53:16] <Neil Jhaveri> Yeah, agreed with Neil Jenkins. Nevermind :D
[06:53:22] <Chris Newman> Robert: could be implemented with a conditional store on the message's list of folders as an alternative to global lock.
[06:54:44] <Robert Stepanek> Chris: have to think this through. let's see how this hashes out on the mailing list
[06:54:55] <Barry Leiba> AOB
[06:57:08] resnick leaves the room
[07:05:12] <Neil Jhaveri> Gmail de-duplicates them, yeah
[07:06:31] <jeffpc> hrm, what about drafts (with missing message-ids)?
[07:06:57] <jeffpc> fair
[07:09:16] <jeffpc> importing a raw email is ok wrt the server changing it up - since the imported email can have a different blob id IIRC
[07:09:43] <jeffpc> (sorry for the terrible grammar... it's after 2am here)
[07:11:18] Neil Jhaveri leaves the room
[07:13:11] <Chris Newman> Actually, for the virus case you want the client to know it should remove a copy of that attachment if it downloaded it.
[07:14:16] <Chris Newman> Can be done as an extension: $ContainsVirus flag, and attempt to fetch part returns a useful error.
[07:15:55] <Ken Murchison> Thanks to Neil J, Barry and Bron
[07:15:59] <jeffpc> thanks & good night
[07:16:12] <Robert Stepanek> thanks and bye
[07:16:14] <Chris Newman> Thanks! Great work all!
[07:16:27] Ken Murchison leaves the room
[07:16:30] Barry Leiba leaves the room
[07:16:49] Josef Sipek leaves the room
[07:17:27] meetecho leaves the room
[07:17:31] Chris Newman leaves the room
[07:17:32] Robert Stepanek leaves the room
[07:17:32] vaibhav singh leaves the room
[11:17:21] jeffpc leaves the room
[11:17:52] jeffpc joins the room
[23:32:45] jeffpc leaves the room