[03:06:39] --- RandyG has joined
[03:19:39] --- fanf has joined
[03:21:47] --- Ted_Hardie has joined
[03:27:45] --- oern has joined
[03:28:45] --- oern has left
[03:31:08] --- tonyhansen has joined
[03:31:39] --- Hollenbeck has joined
[03:32:44] <tonyhansen> looking for a co-jabberer
[03:33:06] <Ted_Hardie> I'm going to have to duck out to another room mid-flight, but I'll help out when I can
[03:33:18] <Ted_Hardie> currently: delay as chairs work out technical issue with slides
[03:33:23] <tonyhansen> chair: working on making slides accessible -- will start momentarily
[03:34:22] --- ekr has joined
[03:34:58] --- dotis has joined
[03:35:14] <tonyhansen> here we go
[03:35:32] <Ted_Hardie> Note well: check your packets for text
[03:36:11] <tonyhansen> it's the glenn & erik show: lemonade
[03:36:25] --- andrewm has joined
[03:36:28] <Ted_Hardie> Status
[03:36:30] <tonyhansen> today's agenda: status of docs, mms mapping, profile phase 1, OMA liaison
[03:36:44] --- alexeymelnikov has joined
[03:36:47] <tonyhansen> tomorrow's agenda: profile phase 2, OMA based proposals
[03:37:38] <Ted_Hardie> OMA liaison will be discussed by Ileana
[03:37:50] <Ted_Hardie> Liaison from Mobile email as well
[03:38:00] --- corby has joined
[03:38:06] <tonyhansen> OMA put together a requirements doc (80 some odd)
[03:38:25] --- cnewman has joined
[03:38:28] --- gparsons has joined
[03:38:57] <tonyhansen> oma reqts may affect contents of what's in phase 1/2 of profile
[03:39:23] <gparsons> "Hi, I'm Glenn!" says Eric :)
[03:39:35] --- ekr has left: Replaced by new connection
[03:39:58] --- lisa has joined
[03:40:30] <Ted_Hardie> Slide of WG status: goals in rfc editor queue
[03:40:32] <tonyhansen> wglc status:
[03:40:36] --- shmaes has joined
[03:40:50] <Ted_Hardie> Server-to-server notification; last called closed, informational, needs update
[03:41:01] <Ted_Hardie> mms mapping: new draft needed after appeal upheld
[03:41:22] <tonyhansen> goals - rfc editor queue server 2 server notification reqts - ietf last call closed, needs update mms mapping - new draft needed after appeal
[03:41:22] <Ted_Hardie> URLAUTH, Catenate, BURL, (slides say last call, but LC has closed)
[03:43:29] --- Altair71 has joined
[03:43:29] <tonyhansen> ted: weren't there last call comments on this? can they be handled via auth48?
[03:43:59] <tonyhansen> randy: minor comments were sent in on burl
[03:44:30] <tonyhansen> chris: will do a burl rev for the minor comments
[03:44:48] <tonyhansen> randy: catenate had minor comments
[03:44:55] --- pguenther has joined
[03:45:08] --- resnick has joined
[03:45:31] <tonyhansen> randy: also has comments on urlauth
[03:45:55] <tonyhansen> ted: is anyone implementing and having problems because not using 2119 MUST/etc.?
[03:45:55] <Ted_Hardie> Anyone in the jabber listening to the streaming?
[03:46:08] <tonyhansen> ted: room indicated no problems with current text
[03:47:04] <tonyhansen> future delivery: wglc closed, needs new draft before ietf last call
[03:47:31] <tonyhansen> greg v: a new draft is ready, but missed id editor deadline
[03:48:12] <tonyhansen> reconnect -- new draft, ready for wglc
[03:48:24] <Ted_Hardie> reconnect-clarifications
[03:48:50] <tonyhansen> corby: minor changes only
[03:48:55] <Ted_Hardie> updated security section to reflect comments
[03:49:08] <Ted_Hardie> IPR and normative references update request
[03:49:20] --- dcrocker has joined
[03:50:17] --- dcrocker has left
[03:52:04] <tonyhansen> pete: is the reconnect problem one of immediate reconnect, or 2 weeks later? answer: immediate reconnect pete: shouldn't this be done using shim6?
[03:52:39] <Ted_Hardie> Don't we need to work on v4
[03:52:52] <tonyhansen> ted: does shim6 work on v4? pete: talk is going on about making shim6 work on v4
[03:52:57] <Ted_Hardie> so punting it to shim6 has a problem
[03:53:14] <tonyhansen> dave: no, shim6 folks are adamant against making it work on v4
[03:53:40] <tonyhansen> dave: it would be critical path
[03:54:05] <tonyhansen> corby: how about hip? mobite(?)?
[03:54:45] <resnick> mobike
[03:55:03] <tonyhansen> keith: should look at tls, as it provides lots of the needed features of reconnect
[03:55:27] <tonyhansen> ted: --- missed it
[03:55:58] <tonyhansen> dave: this group should generate a service interface reqt formulated as a protocol interface spec
[03:56:08] --- dcrocker has joined
[03:56:09] <Ted_Hardie> the internet area meeting had a preso by Geoff Huston on Internet-level approaches to this--there are 10 or so, not contacting transport layer (e.g.SCTP) approaches
[03:56:21] <Ted_Hardie> That means punting it to that layer has a complex further choice.
[03:56:29] <tonyhansen> ?: there is utility in having conn identity
[03:56:43] <tonyhansen> ?: shim6 would love to have feedback
[03:57:06] <Ted_Hardie> Keith: is there ongoing work on this related to TLS
[03:57:18] <Ted_Hardie> (sorry, that's not a report--I thought he was in the jabber room)
[03:57:21] <resnick> Kurtis Lindqvist
[03:57:22] <tonyhansen> philg: there are 2 proposals at upper layers for different protocols: multiplying and multiplying
[03:57:39] --- Barry Leiba has joined
[03:58:02] <resnick> (Kurtis is the shim6 chair and on the IAB)
[03:58:49] <tonyhansen> glenn: personal perspective is we should continue work on reqts, and explore possibilities at multiple layers
[03:59:06] <tonyhansen> glenn: still in charter
[03:59:12] <Ted_Hardie> Stephane asks when do we want it
[03:59:25] <Ted_Hardie> Okay if there is a better solution lower later, but in the mean time it would be good now
[03:59:37] <Ted_Hardie> Corby: delta set generation critical, as are other things
[04:00:19] <tonyhansen> alexey: make it experimental? glenn: in charter as std track
[04:00:32] --- Altair71 has left
[04:01:28] <tonyhansen> erik: this conversation has been repeated before, and still useful at this layer
[04:02:09] <tonyhansen> erik: more useful than just for oops, connection was lost
[04:02:15] <Ted_Hardie> erik: no harm
[04:02:27] <Ted_Hardie> erik: has useful characteristics
[04:02:31] <tonyhansen> glenn: go forward with it to wglc
[04:02:49] --- [email protected] has joined
[04:02:49] <tonyhansen> intermediaries -- defer to phase2 discussion
[04:03:00] --- andrewm has left: Disconnected
[04:03:43] <tonyhansen> stephane: oma reqts will affect things
[04:04:17] <tonyhansen> pete: are intermediary challenges really security issues? no
[04:04:39] <tonyhansen> on to mms mapping -- randy gellens
[04:06:00] <tonyhansen> was approved by iesg, but appealed consensus reached on issues with x- headers iesg resolution allows group to revise and recycle to LC again
[04:07:23] --- amarine has joined
[04:08:01] <tonyhansen> issues with x-mms-message-id, x-mms-priority/x-priority
[04:08:55] <tonyhansen> issues with group syntax, and ESMTP vs. SMTP usage text on address hiding, media conversion, defn of gateway, the phrase relay/servers
[04:10:08] --- corby has left
[04:11:34] <tonyhansen> issues: wording on null return-path, resent-count header, text on quoting/resent:/received: headers
[04:11:40] --- Barry Leiba has left
[04:12:41] <tonyhansen> issue: sensitivity header, security considerations, mms references not normative, incorrect bcc example
[04:14:31] <tonyhansen> issues: message-id; unqualified addresses; text on anonymous remailers and signed mail; text on smtp auth, s/mime, pgp
[04:15:21] <tonyhansen> issues: disposition-notification-to vs x-mms-read-reply wg needs to pay more attention
[04:16:01] <tonyhansen> resolutions: x-headers issue resolved need resolution of sender address hiding, mdn vs mms read-reply, null return path
[04:16:19] <gparsons> need to discuss disp-notif-to & read-reply on list
[04:18:21] <tonyhansen> does anyone care about sender address hiding? alexey: usefor is also questioning this issue
[04:18:54] <tonyhansen> glenn: vpim had same problem, solved by using "unknown@domain"
[04:19:47] <tonyhansen> ?: is there are reference to rfc 3834?
[04:20:12] <fanf> that comment was from tony finch
[04:21:13] <tonyhansen> randy will send note to list on topics not yet decided, then rev the draft, and do another wglc and ietf lc
[04:21:59] <tonyhansen> on to lemonade profile and alexey
[04:22:07] <Ted_Hardie> I'm stepping out for a moment to be in ECRIT during a preso; will be reachable via
[04:23:54] <tonyhansen> changes since -02: minor editorial, plus updated examples to handle CATENATE etc clarification on using TLS qualified future delivery to MAY from SHOULD
[04:25:03] <tonyhansen> open issues: is quick-reconnect part of version 1 is future delivery part of version 1 TLS section needs more work, relationship with SASL
[04:25:08] <gparsons> text needs to include and correctly reference quick-reconnect, since we decided quick-reconnect is important
[04:25:22] <tonyhansen> gregv: keep future delviery in version 1
[04:25:29] <tonyhansen> and as mandatory
[04:25:45] <tonyhansen> randy: agrees, clarifies why mandatory
[04:26:36] <tonyhansen> gregv: version 1 and version 2 difference is time related, not feature related -- what's ready to go
[04:27:58] <tonyhansen> erik: there is no "are you version 1" negotiation, but individual feature negotiation version X compliance is more a marketing issue
[04:28:38] <tonyhansen> stephane: could do bulk negotiation in the future gregv: not sure what that would save
[04:29:31] <tonyhansen> stephane: can't reconcile mobile with future delivery
[04:30:02] <tonyhansen> ?: is there an expectation of an implementation declaring itself as being profile compliant?
[04:30:43] <gparsons> Dwight?
[04:31:05] <tonyhansen> glenn: no -- the profile doc summarizes a set of standards that is to be used by a particular application, so that implementator can go to one place to see what s/he needs to implement
[04:31:49] <tonyhansen> pete: oma can point to this document and say "this is the doc you need to use to be compliant"
[04:32:19] <tonyhansen> dwight: is profile normative? glenn: yes
[04:33:06] <tonyhansen> randall: we often have normative rfcs that can't be identified via the protocols (dns etc examples)
[04:33:46] <tonyhansen> randall: profile doc must be normative because of requirements, and it's handy to say "yes this server is lemonade compliant" and gives client guidance as well
[04:34:25] <resnick> ekr wants out of here soon. Can we get to his stuff soon?
[04:34:41] <tonyhansen> stephane: dwight is correct that oma needs to specify what mobile implementers need to do
[04:34:53] --- ekr has joined
[04:35:21] <tonyhansen> stephane: back to future delivery, do we really need it in the profile
[04:36:04] --- Ted_Hardie has left: Logged out
[04:36:09] --- bdesruisseaux has joined
[04:36:37] --- ekr has left: Online
[04:37:12] <tonyhansen> gregv: there is no oma reqt for future delivery, options: only do what oma wants, or stick to "what is useful" and oma picks and chooses lemondae should pick decent set of things so that we get interop across more than one area
[04:37:29] <resnick> Glenn - Did you see above note from me?
[04:37:59] <tonyhansen> randall: helps client author eliminate multiple code paths
[04:38:30] <gparsons> yes (eric here). Forward without download is the thing he's interested in. However, I'm not sure we're getting into the level that he would care about.
[04:38:48] <tonyhansen> glenn: yes these are in scope for profile
[04:38:58] <resnick> Well, let's make that call quickly.
[04:40:19] --- mrose has joined
[04:40:32] <resnick> In the interest of moving things in the room along, I won't go to the mic, but I would object to the SHOULD/MUST.
[04:40:49] <resnick> I'll say so on the list as needed.
[04:40:52] <gparsons> Which would you prefer?
[04:41:31] <resnick> I find 2119 language in profile documents silly. But maybe that's just me.
[04:41:35] <tonyhansen> more issues: catenate examples are redundant with catenate draft need to selection *which* extensions are mandatory
[04:42:33] <tonyhansen> imap extensions: starttls: must catenate: must urlauth: must uidplus: must postaddress: unknown reconnect: must if in version 1
[04:43:20] <tonyhansen> ?: need uidplus to implement catenate efficiently
[04:43:39] <gparsons> Spaceman me: we skimmed over TLS/SASL...
[04:43:47] <tonyhansen> philg: objectors to uidplus are gone
[04:43:59] <resnick> Uh......sorta.
[04:44:36] --- ekr has joined
[04:45:05] <tonyhansen> smtp extensions: auth: required by submit burl: must futuredelivery: ???? pipelining: suggest must starttls: MAY 8bitmime: must chunking: suggest should binarmime: suggest may dsn: suggest should size: suggest should
[04:45:17] <tonyhansen> senhancedstatuscode: should
[04:45:47] <tonyhansen> gregv: silly not to make pipelining, chunking, binarymime as must
[04:45:51] <ekr> Sorry to be difficult, but I really need to be in sechmech. Does anyone have an estimate of when the security topic is coming up?
[04:46:33] <tonyhansen> questiong downconverting needs of binarymime
[04:47:03] <RandyG> Pete: it's useful to have MUST in profile so you can say that server X is lemonade-compliant
[04:47:10] <tonyhansen> gregv: why is dsn, size should
[04:47:33] <tonyhansen> chris: need to only have MUSTs or MAYs, no SHOULDs
[04:48:07] <RandyG> (that was to Pete, not from him)
[04:49:03] --- bdesruisseaux has left
[04:49:10] --- bdesruisseaux has joined
[04:49:24] --- corby has joined
[04:49:37] <tonyhansen> gregv: only one to really discuss is future delivery
[04:50:11] <tonyhansen> chris: questions STARTTLS being MAY, cites sasl plain, STARTTLS should be MUST
[04:50:37] <tonyhansen> gregv: tls may not be implemented in mobile world randy: ssl is common
[04:51:02] <resnick> Who is that?
[04:51:20] <tonyhansen> randy: alternate port tls is unfortunately common, making starttls mandatory helps combat that
[04:52:45] <tonyhansen> jon callas: starttls and cram-md5 are orthogonal both starttls and cram-md5 should be MUST
[04:53:04] <ekr> I agree with Jon's point here.
[04:53:26] <tonyhansen> pete: appsarea yesterday had presentation that said cram-md5 is little better than plain
[04:53:51] <tonyhansen> pete: if we can say must on starttls, there's no point in doing other than sasl PLAIN
[04:54:10] <ekr> Well, must support TLS != must USE TLS.
[04:54:28] <tonyhansen> jon: questioning what is stored on server for different algorithms
[04:54:59] <tonyhansen> chris: can store hmac predigest
[04:56:08] <tonyhansen> pete: plain is more secure in terms of server storage issue
[04:56:29] <tonyhansen> keith: predicts that cram-md5 will be deprecated soon
[04:57:02] <tonyhansen> keith: pete is right about plain being safer than cram-md5 as for server storage issue
[04:57:22] <tonyhansen> jon: thinks he disagrees and will discuss offline
[04:58:19] <ekr> So, cram-md5 and digest are different here....
[04:58:28] <ekr> (just FYI).
[04:58:35] <ekr> Digest has better server storage behavior.
[04:58:42] <tonyhansen> randy: need to properly check cert expired certs, self signed certs, affect reliability of security when users become conditioned to accept bogus certs
[04:59:02] <tonyhansen> chris: mandatory to implement doesn't mean mandatory to use
[04:59:18] <RandyG> We need a mechanism that permits mutual authentication
[04:59:39] <RandyG> My concern with bogus certs is that the user ends up sending his username and password to a random server
[04:59:40] <tonyhansen> tony: channeled ekr's comment about "must support TLS"
[04:59:50] --- dcrocker has left
[05:00:06] <tonyhansen> pete: having starttls with a MUST also requires a minimal security suite: STARTTLS with NULL doesn't help
[05:00:56] <resnick> Just clarifying ekr.
[05:01:08] <tonyhansen> pete: questions on starttls's requirements on security suite chris: yes phil: clarifies further
[05:01:48] <tonyhansen> phil: question on TLS/SASL interaction should be postponed until SASL WG stops swinging its bat
[05:02:14] <tonyhansen> chris: can't constrain implementations in the wild
[05:02:32] <tonyhansen> erik: any questions for eric rescola?
[05:03:04] <tonyhansen> pete: questions ekr's comment about digest's server storage issues
[05:03:17] --- xd has joined
[05:04:00] <tonyhansen> ekr: digest and cram md5 are similar (2% diff?) in security for server storage issues
[05:05:06] <tonyhansen> ekr: no way to fix the problem if server is broken into set up system so that if sysa is broken into, it gives no advantage for sysb even if same password is used
[05:05:42] <tonyhansen> ekr: cram md5 doesn't protect against that, but digest md5 does
[05:06:57] <tonyhansen> phil: is conclusion that starttls a MUST glenn: yes
[05:07:28] <tonyhansen> glenn: concensus is there are no SHOULD's
[05:08:03] <tonyhansen> future delivery will be taken back to the list: either include it as MUST or eliminate it from the profile
[05:09:24] <tonyhansen> chris: asks for hum on future delivery
[05:09:32] --- bdesruisseaux has left: Disconnected
[05:09:45] --- ekr has left: Online
[05:10:40] <tonyhansen> pete: if hum says future delivery is not in v1 doesn't prevent it from being in v2
[05:11:05] <tonyhansen> chris: future delivery has security difficulties
[05:11:27] <tonyhansen> chris: and may affect deployment of v1
[05:12:19] <tonyhansen> hum says not in v1, question may be revisited for v2
[05:13:36] <tonyhansen> on to OMA collaboration: Ileana Leuca
[05:14:07] --- [email protected] has left
[05:15:15] <tonyhansen> ileana introduces herself and describes open mobile alliance, and rfc 3975
[05:17:05] --- dcrocker has joined
[05:17:54] <gparsons> IETF / OMA collaboration web page: http://www.openmobilealliance.org/colloaborating/ietf.html
[05:19:31] <tonyhansen> eric: are there no lemonade depencies?
[05:20:34] <tonyhansen> stephane: reqts have been provided; dependencies work has just begun
[05:21:23] <gparsons> The OMA/IETF collaboration link, "IETF Dependencies" is off of the OMA home page, http://www.openmobilealliance.org/
[05:21:34] <gparsons> [typo in collaboration web page]
[05:24:05] <tonyhansen> glenn: the oma mobile e-mail reqts is input to lemonade reqts doc had ~80 reqts needs feedback on relevance to lemonade and view on preferred potential collaboration working arrangements between oma and lemonade we're invited to oma e-mail swg interim meeting here in paris next week
[05:27:22] --- dcrocker has left: Disconnected
[05:27:47] <gparsons> Desire to have joint OMA / IETF meeting.
[05:27:51] <tonyhansen> randy: can dwight address this: can't oma have a joint meeting with non-members? dwight: workshops, but not meetings that make decisions
[05:28:33] <tonyhansen> glenn: glenn and eric will represent lemonade at next week's meeting
[05:29:15] <tonyhansen> ileana: please indicate which docs are underway and how they are applicable to oma reqts
[05:29:33] --- Hollenbeck has left
[05:29:33] <tonyhansen> glenn: lemonade initial reaction to oma reqts
[05:30:01] <tonyhansen> many reqts are met with base imap and smtp submit
[05:30:25] <gparsons> OMA draft responses will be on the supplemental web site sometime this evening.
[05:30:25] --- tonyhansen has left: Disconnected
[05:31:12] --- RandyG has left: Logged out
[05:31:22] --- alexeymelnikov has left
[05:31:24] --- corby has left
[05:32:58] --- resnick has left
[05:33:03] --- tonyhansen has joined
[05:33:13] <tonyhansen> at oma meeting: glenn and eric will cover: what is lemonade what is internet email comments on requirements drafts of presentation will be on supplemental site tonight
[05:33:19] <tonyhansen> we're adjourned
[05:33:24] --- tonyhansen has left
[05:34:05] --- mrose has left
[05:35:27] --- pguenther has left
[05:37:43] --- shmaes has left: Disconnected
[05:39:32] --- lisa has left
[05:39:40] --- amarine has left
[05:44:31] --- fanf has left: Disconnected
[05:47:20] --- xd has left: Disconnected.
[05:49:52] --- cnewman has left: Disconnected
[06:35:45] --- dotis has left: Disconnected
[06:44:13] --- gparsons has left: Disconnected
[06:59:10] --- dcrocker has joined
[07:00:52] --- corby has joined
[07:01:35] --- corby has left
[07:04:35] --- dcrocker has left
[07:26:44] --- corby has joined
[07:27:06] --- corby has left
[08:17:34] --- kmurchison has joined
[08:31:47] --- kmurchison has left
[14:30:26] --- kmurchison has joined
[14:41:58] --- kmurchison has left