[11:08:00] Cyrus (me) will scribe in jabber. status-in-list -------------- [11:11:29] Alexey will talk [11:11:51] More reviews needed. [11:12:02] Some discussion about paged LIST results. [11:12:21] Barry thinks it needs addressing in general - not in this document. [11:12:46] Idea: clients can do FETCH in batches, can't do the same with LIST. [11:13:19] Barry is happy to write the spec but will do a straw proposal to the list first. sort-display ------------ [11:14:07] One open issue: what to do about sorting on group email addresses. [11:14:18] Alexey thinks we should flip a coin on this one. [11:14:23] Otherwise it is done? [11:14:50] Sorry, how do groups impact the DISPLAYFROM? [11:15:21] Can groups occur in From? (I suppose they could, From can technically contain multiple). [11:15:27] From address can be a group address, right? [11:16:11] Oh, but -sortdisplay appears to only contain DISPLAYFROM. [11:17:01] Need an updated draft - it is about to expire. [11:17:27] There maybe support for sorting on TO. [11:17:34] As in, no DISPLAYTO/DISPLAYCC or whatever. So groups and multiple from are a real edge case we'll never really see in practise, so quite honestly, we could collate those "equal and after", like failed comparators. [11:18:07] Chris suggest just use the display name portion of the group. [11:18:26] I can also do a proper review... [11:19:05] Will do. [11:19:07] Dave tasked to do formal review. fuzzy search ------------ [11:20:18] Chris thinks it is reasonable. [11:20:30] Was it just decided to *not* deal with group names? [11:20:51] One issue: range is 1 to 100. Might want to allow more precision with 1 to 1000 or 10,000. [11:20:59] (Sorry, I'm not hearing the conversation, only looking at the jabber.) [11:21:27] Issue from list: should fuzzy be banned for things like UID? [11:21:50] Barry proposed text -- that seems OK. [11:22:12] Other issue: name of capability string. No one cares that much here! [11:22:17] Timo can choose. [11:22:35] After having skimmed this, should the FUZZY and RELEVANCY be split into distinct capabilities? [11:22:39] Next steps: one more revision and then done. [11:22:59] Use case for splitting? [11:23:07] Implement one but not the other. [11:23:18] Well, more likely fuzzy searches without relevancy, but yes. [11:24:09] Is there a real need for that? [11:24:11] Irrelevant fuzziness... I think it might not be easy to determine relevancy. [11:24:46] Server could always return "neutral" relevancy numbers. [11:25:19] So I could just implement such that everything has equal relevancy - yes, that works. [11:25:23] Randy: Having two capabilities introduces more client complexity. Would prefer to stick with one. [11:25:36] Agreeing with Randy as well about not having 2 separate capabilities [11:25:39] Conclusion: keep to one capability. multi-mailbox search -------------------- [11:27:05] Security considerations needs more detail. [11:27:20] Biggest change was to syntax to use extended LIST syntax. [11:28:19] No wildcards any more. Depth parameter changed. No specify on a per mailbox basis whether sub-tree is traversed. [11:29:22] Chris would like to see LDAP nomenclature used. Barry prefers notify syntax. [11:29:47] Reviews of draft are now needed. More suggestions needed for security considerations. [11:30:30] Anyone volunteer for a review? [11:31:07] Chairs will ask individuals, [11:31:12] Dave, can you volunteer to review? :-) message recall -------------- [11:31:43] Two main questions: [11:31:55] 1) Should this be done on top of message tracking? [11:32:25] 2) Whether two-phase system makes sense, or is best effort good enough? [11:32:33] 3) Blow off completely? [11:33:26] Pete: no to (3). On (1): architectural question: can message track pull out of the mail store at the end? [11:33:29] resnick, And also there's the in-brain memory editing, of course. [11:33:49] Does message tracking have enough to deal with the "mail spool"? [11:34:22] Message tracking tags a message with an ID. Same as Barry's current proposal. [11:35:23] Message tracking won't help with POP. [11:35:35] Or with IMAP once message is cached. [11:36:09] MDNs could be used? [11:36:21] Presumably it could at least go through LMTP to the store, as well as just SMTP. [11:37:51] Recall is only about promising not to deliver to final recipient - could still archive the message or do other things to it. [11:39:55] Randy thinks temporary hold is overly complicated and probably not reliable. [11:40:44] Pete does not think hold is worth doing. [11:42:01] An ISP ought not to allow recall without user control. [11:42:29] I suspect a lot of this discussion could be avoided by s/recall/retract/ [11:42:41] (Obviously with a 'g' modifier to that.) [11:43:19] dave... 3 in queue. We'll get you soon. [11:44:14] Chris: on hold/release - IMAP cannot "hide" (hold) messages in its store - that represents a new state for messages which will increase admin complexity too much - would not implement it with hold. [11:44:34] Chris: supportive of the feature as a whole, preference for message tracking. [11:44:44] Dave Cridland hears Dr Seuss in Chris - "Not in the queue, not in the store, not in my view, not any more..." [11:45:00] Barry: enough people have said they are unhappy with hold, so it will go from the next draft. [11:45:31] Chris: per-user option to control probably would not be implemented first, but maybe if request. [11:46:08] Dave: hold/release is a distributed commit - solutions to that do exist elsewhere and we should look at those. [11:47:35] Dave: is this a paradigm shift in email? Does this not imply the need for an email "control plane". [11:48:49] (Isn't it the standard rule that the first person to call a Paradigm Shift gets to buy the beer?) [11:49:38] even for folks on jabber :) [11:49:40] This implies some kind of trust overlay. [11:51:20] Jacob: spec from 10 years ago defined a Replaces header that could be used in a new message to "hide" an existing one. [11:52:28] With Jacob's proposal everyone is always informed of the recall. Would like to see Barry's spec define a notification always sent to recipients so that they know a recall was done. [11:54:16] Barry: "Replaces" header deals OK with the "factual error fix" case, but not so well with the "angry message retract" case. [11:54:57] Chris: does not want to implement a per-user opt in option unless required by the spec. [11:56:29] Chris: message recall is not just an enterprise feature - used on AOL a lot. It saves a lot of time when fixing quickly found errors. [11:57:50] Pete: security considerations section will list a lot of possible abuses, but also needs to describe cases where it would be bad to allow recall (e.g. messages to lawyers etc). So per-mailbox on/off option for this is going to be needed. [11:58:28] Pete: "Replaces" is independently a good idea - could use Supercedes. [11:58:43] Barry Leiba, Incidentally, the reason I say that "retraction" is easier to talk about than "recall" is that "retraction" implies that it's an indication that the message has, at some specific point in time, been stated as withdrawn, rather than a message which is going to be actually deleted out of someone else's mailbox. [11:59:00] Barry Leiba, Not that this needs channelling. [11:59:21] Randy: would opt-in make implementors not do this if required? [11:59:48] Chris: not a huge overhead and would not block implementation. [12:00:39] Jacob: for important non-recallable message just don't include the message id. [12:00:55] Chris: if there is a legal requirement, archiving system can take care of it. [12:01:48] Chris: spec should explicitly say that the new feature does not affect archiving systems. [12:02:09] Jacob: what about mailing lists? [12:03:37] Chris: add an iteration count to message track and use HMAC. [12:05:45] ANNOTATE? [12:05:58] (As in for Cyrus's token storage) [12:10:09] Barry: summary -- change to use message tracking. [12:10:32] Cyrus: want a way for client to easily manage and get status for the recall process. [12:10:53] Should there be a header or annotation on sent-mail message that can be used for this? [12:11:06] Chris: private key in header in sent-mail would be bad. [12:11:23] Pete: MDN can come back with "recall" status. [12:11:59] ? [12:12:20] Pete: Does this require a re-charter? [12:12:27] Alexey: Probably. [12:12:36] Chris: Should probably be done in WG. [12:13:22] Chris: Message tracking architecture: Runs on a different port. The security properties of that are good. (Outbound 25 is blocked, but not the recall; sites can reject packets on the port.) [12:13:43] Chris: Consequence is that you are not piggybacking on SMTP. [12:13:57] Barry: Side effect: Must implement message tracking to get recall. [12:14:30] Chris: Could structure protocol to reduce tracking requirements. But probably not necessary. [12:14:41] Chris: You'll want the tracking data anyway. [12:14:54] Barry: Objections to making this a WG document? [12:14:59] (None in the room) [12:15:35] Randy: You'd want the recall/query to follow the same path as the message. [12:16:11] Barry: For sending the message, you might need to use local infrastrucutre. [12:16:59] Chris: Recall path is a different path from the normal SMTP mechanisms. It must follow the original path, even if that path has changed. [12:17:12] Barry: What if the path has changed and you still want to recall? [12:17:35] Randy: If you don't follow the same path, you might hit a server that hasn't seen the message. [12:17:53] Tony: Tracking uses an SRV record. Well known issues. [12:18:42] Tony: Only the MTA knows how to track down the message. [12:19:27] Klensin: This was experimented with. Should have explicit warning that the recall might arrive before the message. [12:20:07] Klensin: It might want to cache these things. [12:20:29] Chris: With the separate protocol, you can offload the functionality on a different server. [12:20:37] Chris: Lowers impact on mail service. [12:20:51] Barry: I will make it message tracking, and remove hold/release. [12:22:01] Barry: Will confirm on the list. [12:22:59] Alexey: Draft related to messaging: Using SRV records for messaging (draft-daboo....) [12:23:02] Please review. [12:23:15] Randy: Declares done-ness. [12:23:22] Or done-itute. [12:23:23] B'bye, all. [12:25:58] Lemonade clients? [12:26:05] Thunderbird is doing CONDSTORE. [12:26:20] I think that counts to some not insignificant degree.