[06:42:06] --- tonyhansen has joined
[06:42:47] --- shmaes has joined
[06:49:24] <tonyhansen> the chairs will be there shortly
[06:51:29] --- ekr has joined
[06:58:00] --- Hollenbeck has joined
[06:59:15] --- randy has joined
[07:02:58] --- paulmdx has joined
[07:03:36] --- lisa has joined
[07:05:29] --- Barry Leiba has joined
[07:06:25] <tonyhansen> oh my goodness, here we go
[07:06:58] --- dcrocker has joined
[07:07:15] --- cnewman has joined
[07:07:18] <lisa> I'm transcribing to the jabber room
[07:07:26] <lisa> Anybody here whose not in the physical room?
[07:07:58] <lisa> (I meant "who's" but I'm already into sloppy fast transcription brain)
[07:08:26] <ekr> YEs, I am.
[07:08:57] <lisa> Ok I'll try to do a decent job then
[07:09:38] <lisa> Glenn is bringing up the OMA liaison issues
[07:09:46] <lisa> and punting that discussion to the end of the meeting
[07:09:51] <lisa> any agenda bashing?
[07:09:57] --- resnick has joined
[07:10:38] <lisa> Glenn: Lemonade reaction to OMA liaison shown briefly on slide with much text
[07:11:18] <lisa> Lemonade chairs will present at OMA Mobile Email interim next week on what is LEMONADE and get comments on requirements
[07:12:22] --- DaveCridland has joined
[07:13:10] --- eburger has joined
[07:13:45] <lisa> Stephane: Do we need to say anything about our charter to them?
[07:14:05] <lisa> Or to change the LEMONADE charter for their requirements?
[07:14:17] <lisa> Glenn: WG certainly hasn't decided this eyt
[07:14:23] --- corby has joined
[07:14:46] <lisa> and so that's what we'll have to tell OMA and others until we've decided
[07:15:02] <lisa> but we'd like to say that all enhancements to internet protocols is in the purview of the IETF
[07:15:52] <lisa> Comments?
[07:16:15] --- eburger has left: Disconnected
[07:16:36] <DaveCridland> Liason to ask for a joint open meeting, by the way.
[07:16:42] <tonyhansen> ileana
[07:16:45] <lisa> Illiana said that Lemonade might want to wait until after next week's meeting to recharter
[07:16:56] <lisa> Glenn agreed
[07:17:33] --- pguenther has joined
[07:17:48] <lisa> Andrew Allen: The work on requirements is really just kicking off.
[07:18:12] <lisa> Stephane Maes: disagrees -- The requirements is about to be approved. Architecture activity has started and there's already a baseline so that's in second phase.
[07:18:44] <lisa> New Topic: Liaison
[07:19:09] <lisa> Greg Vaudreuil: There's about 80 requirements in the doc
[07:19:16] <lisa> (the doc from OMA)
[07:19:39] <lisa> some of them quite interesting... they go beyond what you'd think of as IETF requirements, OMA has many more parts to a complete service
[07:19:50] <lisa> implementation and configuration issues as well as protocol issues
[07:20:17] <lisa> Some requirements are failry straightforward and some already in the process of being met with Lemonade work
[07:20:39] <lisa> They include requirements on how to securely traverse firewalls
[07:22:37] <DaveCridland> Randy points out that it doesn't say "securely"...
[07:22:45] <ekr> unsecurely is more fun.
[07:22:57] <lisa> The big gap is that OMA requires uploading new server rule sets
[07:23:06] <lisa> (comparing OMA requirements to SIEVE work)
[07:23:22] <lisa> Some OMA rquirements are user agent programming and config issues which are out of scope for us
[07:25:32] <lisa> Ted and Stephane had a conversation about the kind of security and charging thing that the IETF never has in scope
[07:26:00] <DaveCridland> Because we can't have a network know what's inside, say, a VPN.
[07:26:09] <lisa> Stephane says that he believes those requirements only apply to the portion of the traffic that is in the clear
[07:26:12] <DaveCridland> (As Ted said)
[07:26:25] <lisa> Illiana: maybe we need another spec to say what functions are related to what boxes.
[07:26:31] <lisa> Eric: Who would do that work item?
[07:27:07] <lisa> Stephane and Illiana explain that doc/work is somewhere in the OMA already, public, not yet stable
[07:27:42] <DaveCridland> Stéphane says it's about a stable as an I-D.
[07:28:25] <lisa> Randy read the requirement out loud and points out it needs careful examination...
[07:29:07] <lisa> Stephane: The intent of the charging req't is to know that the particular piece of traffic is email traffic. This can be known when it goes to the email provider in the clear, compared to hard to determine when it goes encrypted to the corporate email.
[07:29:36] <lisa> Stephane: It's even more difficult to know the size of the email and the number of recipients.
[07:30:00] <lisa> Keith Moore: I hope this WG understands it does not need to accept these requirements for Lemonade work, and in fact some of these should not be accepted.
[07:30:10] <lisa> Eric and Greg agreed with Keith.
[07:30:25] <lisa> Stephane: However our goal should be to see if we can satisfy and if we can't then its an OMA problem
[07:31:13] <lisa> Greg: Out of band notification: although there's a need to alert clients of new messages, we can't do a whole lot to specify how that works.
[07:31:17] --- alexeymelnikov has joined
[07:32:22] <lisa> Pete Resnick: I suggested we start looking at SHIM6 but that's not reasonable for this group to do. The diameter folks might have input into what you need.
[07:32:44] <lisa> Maybe the SHIM6 implementations can be made OMA compliant.
[07:33:17] <lisa> Ted: Simpler than that, ask OMA to take on some implementation advice about how to hold a TCP session up if you have not had to change the IP address but don't have a link layer.
[07:34:44] <lisa> Keith: I'd caution against making SHIM6 critical path for anything...
[07:35:19] <lisa> If TCP or other protocols don't handle intermittent hosts well we have to fix that because the Internet isn't wired PCs any more.
[07:35:49] <randy> Discussion that dormant mode allows the link layer (air interface) to drop, but the IP address and other state (PPP) to remain. However, poor TCP stacks end up dropping the TCP session anyway. Discussion of SCTP etc.
[07:36:00] <lisa> Stephane: Most people at OMA aren't aware of these discussions.
[07:36:41] --- corby has left
[07:36:45] <lisa> Mike Smith(?): Not everything in the req'ts doc needs to be satisfied here; OMA already has a PUSH operation. A workshop should drill down on that and familiarize with tech base.
[07:37:14] <DaveCridland> The notification tech is the EMN, basically a very simple "you got mail" chunk of XML, designed to be delivered by WAP-push.
[07:37:39] <lisa> Stephane: In addition to saying whether work is in or out of Lemonade, we would be helpful if we provided pointers to OMA to solutions elsewhere in IETF.
[07:37:45] <lisa> Pete agrees.
[07:38:15] <lisa> Mike: I wanted to encourage or discuss the joint workshop to bridge context by dialog rather than by assumption
[07:38:21] <DaveCridland> Pete wants to encourage the OMA to go talk to other WGs, like SHIM6 et al, to find solutions.
[07:38:45] <lisa> Keith: There may be pieces that OMA doesn't care about and Lemonade doesn't do but IETF does care about
[07:38:55] <lisa> Ted: agrees with Keith
[07:39:36] <lisa> The notification work is very relevant because it seems they (we?) have an application layer notification mechanism for reuse.
[07:39:42] <paulmdx> I think Mike => Dwight ?
[07:39:53] <lisa> Yes Paul I just heard Ted say that too -- thx
[07:41:02] <lisa> Stephane: Agrees, these are action items for liaisons to capture as well as WG to consider communicating with rest of IETF
[07:41:48] <lisa> The most important thing we can say to OMA is (1) We think we can address these req'ts already, (2) We think we are going to address these other req'ts, (3) we're interested in these other req'ts.
[07:43:08] <lisa> Randy: We've seen outside groups come in with requirements we feel are stupid. E.g. charging or going through firewalls. If we tell them these are stupid req'ts they may do even more heinous things.
[07:43:31] <lisa> A dialog can be more helpful to change requirement rather than just dismiss it.
[07:45:35] <lisa> Greg asked people to check his understanding of requirements and comment specifically.
[07:46:34] <lisa> Greg made some assumptions about email architecture to tell whether he thought each requirement was in WG scope or not. Stephane pointed out there might be other architectures who would change the scope decision.
[07:47:46] <lisa> Chris: What about a "managed sieve" draft?
[07:48:07] <lisa> Philip: There are specific requirements for fine-grained control like turning off and turning on vacation notices.
[07:48:56] <lisa> Time-based requirements are easy, there's a draft now...
[07:49:06] <lisa> Greg: There's a draft for lmost eerything OMA has asked for.
[07:49:50] <lisa> Tony suggested a reasonable implementation which is unspecified.
[07:50:14] <lisa> Stephane: Some of the requirements are client and server behavior beyond the protocol but that's teh way the OMA works.
[07:50:41] <alexeymelnikov> regarding notifications: Sieve WG has an item on Sieve notifications
[07:50:47] <resnick> Ooooo....we can't get IETF people to use ACAP. Maybe we can OMA to try it.
[07:51:02] <DaveCridland> Heh. I'd be cool with that. :-)
[07:51:09] <resnick> ;)
[07:51:43] <lisa> Stephane: We should look to see if filtering and changing filtering is something we want to do.
[07:51:59] <lisa> Glenn: So let's talk about whether we recharter, as a separate conversation in a few.
[07:52:21] <DaveCridland> But actually I found Sieve via ACAPimplied a highly coupled ACAP/IMAP service. manageseive is probably a better choice.
[07:52:34] * resnick nods
[07:53:00] <lisa> Greg: Some folks feel that HTTP is a great way to traverse firewalls, and IETF discussion and experience doesn't seem to support that. Note that the requiements don't mention HTTP, just firewalls.
[07:53:26] <lisa> Stephane: We shouldn't bring up HTTP as a firewall traversal mechanism if that's not in the req'ts.
[07:53:43] <lisa> Keith: Whether companies should allow this traffic is out of scope of IETF or OMA -- it's network policy.
[07:54:36] <lisa> Stephane: The bottom line today is there are problems going through firewalls and one solution is to say that people have to deal with it, another way is to figure out something to deploy. [ed: if I understand Stephane correctly, I'm having trouble following clauses]
[07:54:52] <lisa> Keith: There is a doc with considerations for using HTTP as a substrate
[07:55:23] <randy> Dave -- Qpopper implemented a subset of ACAP for managing Sieve called SieveAD. It's obviously not coupled with an IMAP server :-) but it is coupled with a local delivery agent.
[07:55:57] <DaveCridland> RFC3205 covers HTTP as a substrate.
[07:56:00] <lisa> Dave Crocker: Docs that say "here's things to think about" are fine for architects but not so useful for admins. Sometimes we do docs for admins: BCPs. One due soon is SPamOps
[07:56:16] <alexeymelnikov> I think we should discuss manage sieve/ACAP/... on the Sieve mailing list (even though it is out of scope for Sieve WG)
[07:56:28] <DaveCridland> randy: Gah, yes, that's what the coupling is for.
[07:57:14] <resnick> My comment, when we get to the rechartering stuff, will be that it would be best for us *not* to put it into our charter, but to charter a new managesieve WG.
[07:57:38] <lisa> Glenn, Stephane: For the OMA initial response we'll remove discussing HTTP and see more what they're thinking.
[07:58:42] <lisa> Glenn explaiend how the liaison channels work (RFC 3X43?)
[07:58:50] <DaveCridland> 4053, I think.
[07:59:13] <lisa> New Topic: Phase 2: Profile
[07:59:24] <DaveCridland> Yep, RFC4053 is liason statements.
[07:59:39] <lisa> Do we need a phase 2 for profile or are we done? Do the OMA reqts make a difference?
[08:03:00] <lisa> Greg: Havning done the requirements analysis, with the exception of SIP [notify] think which doesn't need to be done here, I don't see anything that wasn't previously anticipated by our requirements thinking.
[08:03:10] --- dcrocker has left: Disconnected
[08:03:19] <lisa> [Me: I don't understand the "phase 2" "goal 1" terminology between the speakers right now]
[08:04:25] <lisa> Stephane: In the interim meeting we discussed goals and this matched with OMA requirements but this didn't get captured.
[08:04:46] <lisa> Glenn: Do we want a doc tha descrbes what phase 2 is? That's what the discussion is -- do we have a goals doc?
[08:05:37] <resnick> Lisa, a "goals" document is a "requirements" document but named something more reasonable.
[08:05:42] <lisa> Greg: I suggest we don't do a goals document but we take the minutes from the interim meeting and fold that into the chartert.
[08:06:03] <resnick> The question is whether we're going to do one of those or just go straight to the "solutions" (i.e., "profile) document.
[08:06:24] <resnick> (We did a goals document when the work in LEMONADE started.)
[08:07:24] --- kmurchison has joined
[08:07:37] <lisa> Glenn: We'll go with option 3, focus on a new profile and discussion of use cases will go directly into that profile phase 2 doc.
[08:07:39] <lisa> New topic: Charter
[08:07:45] <lisa> [hi ken]
[08:07:53] <randy> Our original goals document was quite out of date by the time we stopped working on it
[08:08:50] <lisa> Is it charter expansion to do media conversion and transport optimization?
[08:10:15] <lisa> Greg: I think we previously reached consensus that this was something we needed to work on and perhaps the charter should call that out, but I wouldn't necessarily change the charter just for that.
[08:10:31] <randy> Lisa -- "phase 1" is the current profile document; "phase 2" is the next version, to include items left out of Phase 1 (such as media conversion). "Goals 1" is the original (and now horribly out of date) goal document.
[08:10:38] <lisa> Ted: you don't have to recharter to add a new WG document that's covered by an existing goal.
[08:13:39] --- sunny has joined
[08:14:33] <lisa> Discussion of how to detect a lemonade server... there's not a lemonade tag specifically
[08:15:38] <lisa> Greg: IMAP has many options that we don't consider part of the LEMONADE extensions (see IMAPEXT WG for exaple) and we should review our phase 2 and see if they're MUSTs or not.
[08:16:07] <lisa> We have not previously considered whether something like UIDPLUS was a requirement unless it was a dependency.
[08:16:24] <lisa> Glenn: That sounds useful for Lemonade profile phase 1 or 2 -- in the hands of the editors.
[08:16:30] <DaveCridland> I thought we had...
[08:17:53] <lisa> Corby: If we do not have lemonade-compliant servers, what extensions *do* we need to support for mobile terminals? If we have drastic inconsistencies between mobile terminals we can't leave that choice up to the implementors.
[08:19:44] <lisa> Dwight: We should make that clear and test those who come to our interop. There may be possibilities of conflicting functionality profiles.
[08:20:42] <lisa> Greg: You said you'd leave it to doc authors whether to put in phase 1 but I thought we were closing that up and out the door?
[08:20:48] <lisa> Glenn: Ok, then it's phase 2.
[08:23:06] <lisa> Ileana: As an operator, we need to explain process for OMA to see if we have synchronization needs. People who notice conflicting requirements or architecture can point that out to OMA only if they are a member. We cannot take input from IETF.
[08:23:29] --- corby has joined
[08:24:54] <lisa> New Topic: Server to Client (S2C) notifications
[08:25:02] <lisa> Greg: I didn't see this as part of the OMA requirements.
[08:26:46] <lisa> Ted: If the working group takes this on, they can recharter, I am not implying should or should not.
[08:27:32] <lisa> Chris Newman: If we needed to extend the IDLE command in IMAP to cover more than one mailbox in IMAP then this group should do it, but if we're talking about non-IMAP notifications there's SIEVE, and beyond that in another protocol is not Lemonade appropriate work and further a ratsnest in the IETF.
[08:27:53] <lisa> Barry Leiba: There's nothing in IDLE that would need to be changed. Agree SIEVE notification needs to be the right way to go.
[08:28:32] --- alexeymelnikov has left: Disconnected
[08:29:34] <lisa> Some discusssion on SIEVE vs SIP
[08:30:38] <lisa> Chris: SIEVE doesn't say what protocol is used to notify, which is both a weakness and a strength. It only allows notifications based on mail delivery -- if you needed notifications on operations like APPEND, that wouldn't be covered.
[08:32:37] --- dcrocker has joined
[08:33:09] <lisa> Some discussion about what SIEVE can, cannot or should do...
[08:33:46] <lisa> Barry: A notification specification that both LEMONADE and SIEVE could plug into, would be good
[08:35:38] <tonyhansen> lisa: the idea got dropped to allow both SIP and XMPP to experiment
[08:36:07] <DaveCridland> Lisa is speaking: As far as she knows, the work on notifications in the IAB has dropped, and the IAB has allowed both SIP and XMPP to perform notifications, and there are event packages, subscribe etc stuff for SIP, and XMPP's design basically allows this kind of thing.
[08:36:55] <DaveCridland> Lisa again: XMPP also has lots of the JEPs to describe further, non-IETF XMPP extensions, for this kinda thing.
[08:37:17] <DaveCridland> Lisa again: And finally, if you define the right notification format, both will work.
[08:37:22] <lisa> Stephane points out even more notification transports besides SIP and XMPP, such as SMS
[08:38:09] <lisa> We could minimize saying anything about how it's exchanged.
[08:38:28] <lisa> Glenn: Event descriptions could well be in a profile document.
[08:39:34] <lisa> Ted: The paragraph in the charter about IAB working on notifications -- could indeed be taken out.
[08:40:13] <lisa> One of the problems with notification protocols is that the assumptions about addressing and link layers make huge differences in complicated architectures. You'd have to make sure that SIP NOTIFY handle dormancy correctly.
[08:41:07] <lisa> I wouldn't assume that work going on elsewhere has the same sensibilities.
[08:42:02] <lisa> Scott: If you do take this item out of the charter, think about where that input will come from or whether you still need it.
[08:42:12] <lisa> Ted: Can Pete take this back to the IAB? Make sure the answer is no?
[08:44:54] <lisa> Some discussion about who on IAB might have been thinking about this.
[08:45:12] <lisa> Stephane: Don't forget that our charter item is really server-to-server notifications.
[08:45:20] <lisa> It's not per-user data.
[08:45:33] <lisa> Chris volunteered to write a draft about S2C notification but not about S2S.
[08:46:20] <lisa> Greg: S2C notifications like SIEVE might just be a kick in the pants to the client or may lead to synch problems. Figuring that out is unexciting work.
[08:46:45] <lisa> Corby: Since SIEVE is also doing this can we come up with a common transport mechanism between LEMONADE and SIEVE?
[08:47:14] <lisa> Chris: Since SIEVE is only defining triggers, not format or transport, if we figured out more of that equation then SIEVE would reference our work in this group.
[08:48:02] <lisa> Stephane: Notification work is not independent of filtering.
[08:49:59] <lisa> Discussion of consequences of mixing these features together.
[08:50:15] <lisa> Eric: So, is there interest and expertise to work on S2C notifications?
[08:50:59] <lisa> Stephane: By now we should realize that it's needed.
[08:51:40] <lisa> Chris: This is not an appropriate question because there are two pieces. Triggers and filtering of notifications are problems we have the expertise -- even format. Transport for notifications is way out of scope.
[08:52:17] <lisa> Greg: Even triggers and filters and formats of notifications are large enough work items to justify another WG. I don't think it should be part of Lemonade phase 2.
[08:52:31] <lisa> Eric: The work clearly should be done in the IETF somewhere
[08:54:07] <lisa> Lisa (me): asks about implementation experience and point out that there is serious domain expertise required to define triggers.
[08:54:27] <lisa> Barry, Stephane and Corby all mentioned SMS [and I didn't catch the rest of the answers]
[08:55:29] <lisa> Barry asked about two WG with tied goals but Scott pointed out some one group still needs direct responsibility
[08:55:30] <shmaes> SIP, UDP notification, HTTP Chunck Encoding
[08:55:35] <shmaes> SMS GSM
[08:55:42] <shmaes> WAP Push
[08:55:49] <lisa> Ted suggests that something with 2 interested WGs often results in a 3rd WG with the overlap people.
[08:56:13] --- sunny has left: Replaced by new connection
[08:56:16] --- sunny has joined
[08:57:24] <lisa> Alexey (SIEVE WG chair): We have a milestone, SIEVE notifications, in charter
[08:58:05] <lisa> Philip: That's a milestone for how to tell the SIEVE script runner to send a notification, not for how to send the notification.
[08:58:55] <lisa> Ted: This is a hard problem. Who in this room now would be willing to work on this problem?
[08:59:03] <lisa> (10-15 hands raised)
[08:59:39] <lisa> Ted: So the people who raised their hands should write up what they think the work would entail and circulate it to LEMONADE, SIEVE, etc.
[08:59:49] <lisa> Then we can figure out where this work would happen.
[09:00:25] <lisa> Barry: The notification formats and protocols are separate issues. Lemonade could generate a SIEVE extension that supported other sorts of triggers.
[09:00:52] <lisa> Chris: S2S notification is clearly in scope of *this* charter and we can work on.
[09:03:42] <lisa> Stephane: S2S and S2C notifications are actually a different story.
[09:04:07] --- sunny has left: Replaced by new connection
[09:04:10] --- sunny has joined
[09:06:29] <lisa> Continued low-volume conversation about notification use cases and existing work
[09:06:49] <lisa> Philip: People should read the existing docs to see if they're not enough
[09:07:50] <lisa> Ted: I don't care if the work happens here, SIEVE or elsewhere. Its' not as easy a task as arguing about the charter.
[09:12:02] <lisa> Eric: So, we are not rechartering now for OMA requirements, and for S2S and S2C notifications we're going to discuss further on mailing list and elsewhere.
[09:12:16] --- corby has left
[09:18:09] --- paulmdx has left
[09:18:39] <lisa> New Topic: Maes drafts
[09:21:25] <lisa> Stephane describes what's in each draft...
[09:23:08] --- Barry Leiba has left: Replaced by new connection
[09:23:09] --- Barry Leiba has joined
[09:23:41] --- dcrocker has left: Disconnected
[09:26:48] --- corby has joined
[09:27:13] <lisa> Stephane solicits comments and asks whether/which docs should go to WG drafts
[09:28:32] --- Hollenbeck has left
[09:28:32] <DaveCridland> Greg asks why LDELIVER exists, given that it doesn't exist as a requirement.
[09:28:50] --- Barry Leiba has left
[09:29:01] <lisa> Stephane: I don't read the OMA requirement as asking for this, it's for ease of implementation.
[09:29:22] <lisa> Stephane: It's working very well and we have multiple independent implementations.
[09:29:42] <lisa> We should consider why these things are rejected since they work so well.
[09:30:05] <lisa> Guy: have you considered the overlamp with OCAMP? [?]
[09:30:19] <lisa> Stephane: That's a placeholder, if there's a better mechanism that's fine
[09:30:29] <lisa> asked for a pointer.
[09:30:42] <lisa> Greg: Is TLS with compression still in version 1?
[09:30:51] <lisa> STARTTLS was put into profile 1.
[09:31:42] <lisa> Randy: The most compelling argument I've herad for LDELIVER is that you might want to deploy before servers are ready. I find that an interesting argument but I'd like to hear the others.
[09:31:55] <lisa> Stephane: The most compelling argument is a quick solution that can work with servers that do support that.
[09:32:09] <lisa> Stephane: It's also a good solution when there are gateways in front of the server.
[09:32:19] <lisa> Stephane will send reasons to list.
[09:36:22] <lisa> Discussion of when to hold a joint meeting with OMA/LEMONADE,
[09:36:30] <lisa> at least a month before next IETF, possibly late September.
[09:36:54] --- randy has left: Logged out
[09:37:03] <lisa> Correction: a workshop, not an interim.
[09:37:26] --- resnick has left
[09:37:30] --- cnewman has left
[09:37:45] <corby> EOC
[09:37:53] --- DaveCridland has left: Logged out
[09:37:53] --- pguenther has left
[09:38:35] --- corby has left
[09:44:48] --- lisa has left
[09:45:27] --- sunny has left: Disconnected
[09:49:03] --- shmaes has left: Disconnected
[09:56:00] --- tonyhansen has left: Disconnected
[09:57:41] --- sunny has joined
[10:08:46] --- ekr has left: Online
[10:11:46] --- sunny has left: Replaced by new connection
[10:25:35] --- kmurchison has left
[12:13:44] --- tandre has joined
[12:13:55] --- tandre has left
[13:40:49] --- kmurchison has joined
[13:41:09] --- kmurchison has left