Minutes by Eric Burger Compiled from Jabber Log

Goals in RFC Editor Queue
Server-to-Server Notifications Needs WG Chair Write-Up for IESG
MMS Mapping Needs WG Chair Write-Up for IESG
Future Delivery and BURL needs nits review
Tool to help nits review: http://ietf.levkowetz.com/tools/idnits/idnits.pyht

URLAUTH
-------
- url interpretation: basic concern is "what is the base url for relatively interpretation? does it change in selected state as opposed to authenticated state?"
- if you are going to use an absolute url we have an issue of a server needing to know its own domain name and do you always want to include the username
- an absolute url without a user seems to indicate an anonymous user
- Philip Gunther: favor of changing base url in selected state
- Chris Newman: the complexity is how to deal with ".." in a relative url?
seems to be consensus for selected state changing base URL for relative urls, specifically, to "this mailbox"

Are absolute URLs allowed? is the client required to use relative URLs where possible?
- general agreement that we should force clients to use relative URLs and have a different extension for absolute URLs.
- John Klensin that disallowing absolute URLs is weird. Why have URLs at all if we can only use relative URLs?
- Chris Newman: we should require relative URLs but need to make clear that "/random/mailbox" refers to "random/mailbox"
Consensus that absolute URLs are out for this extension
";AUTH=" is also not allowed
Absolute URLs are syntactically allowed, but not supported by the CATENATE extension.
Absolute URLs get a "NO" from the server.
Same for AUTH.
Needs new draft, new Chairs say enough has changed for new WGLC

Alexey notes there are some ABNF issues with IMAP URL RFC, which he sent to Chris.,


Profile
-------
Greg V: are requirements on server only or client, too?  Consensus is requirements are on server, but document needs to give hints to client for how to use server extension.
Needs lots of work. Right now document is a tutorial. Needs to be a standards document.

Security Issues
---------------
EKR: Comfortable if we use same authentication method for reconnect as for initial IMAP connect. Using *only* a cookie opens up passive attack. Using cookie after authentication is OK.
Alexey & Corby: This is how Quick Reconnect works today (using cookie after full authentication).
Cyrus Daboo points out that this is needed for desktop clients, as well as mobile clients.
Edwin Aoki asks about single use schemes (e.g., SecurId). EKR says that if that is the authentication method, that is the authentication method.

Transcoding & Security
---------------------
Drawing on fact that there is a possibility for the server to hand the encrypted session key to the client, the client can decrypt the session key, and hand back the key to the server, we can (1) ANNOTATE clear key to message, (2) decrypt message using session key and CATENATE message to temporary/permanent storage, (3) hand session key over for each IMAP operation.
One problem is key is part of encrypted blob. [BTW: Ned pointed out need for separate carriage of key back in early 90's.] EKR points out that key almost always lives in first 4KB of blob, so can hack extraction.
Jim Shod states that API's exist for S/MIME to do separate session key extraction, session key decryption, and decryption of the message using the decrypted session key.
Will form design team to address this issue.

On the streaming issue, URLAUTH addresses the Streaming Server-IMAP Server association, so long as the Streaming Server is authenticated to the IMAP Server; can use the same mechanism a SUBMIT server authenticates with the IMAP server for forward-without-download. Normal IMAP authentication addresses the IMAP Server-IMAP Client association. Using a secure channel between the IMAP Client and Streaming Server should be OK (EKR), but Sam Hartman separately expressed concern that the association between the IMAP Client and the Streaming Server has to use the same method as the IMAP Client and IMAP Server. For example, if the IMAP login does not use certificates, then we should not require the use of certificates for the IMAP Client-Streaming Server link.

Stan Turner volunteered to participate on e2e design team.

EKR volunteered to help review specific documents.