Subject: [MORG] notes from morg @ IETF75

From: Randall Gellens <[email-masked]>
Date: Wed, 29 Jul 2009 06:13:33 -0700

Here are the notes from the MORG meeting at IETF75.  Please review. 
Thanks to Cyrus and Pete for scribing.

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

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
To die for an idea is unquestionably noble. But how much nobler it
would be if men died for ideas that were true!
    --H.L. Mencken