[03:02:03] --- Ted Hardie has joined
[03:07:50] --- eburger has joined
[03:08:31] <Ted Hardie> Shouting?
[03:08:52] <eburger> I wanted a place holder - looks like the logs will roll over in U.S., not London time.
[03:13:00] <Ted Hardie> It sounds like you are now trying a modem?
[03:13:15] <Ted Hardie> Has the group there actually gathered for the meeting?
[03:19:28] <eburger> Yes - the gang is all here. Also: thanks for being up so early!
[03:19:48] --- eburger has left
[03:20:20] --- eburger has joined
[03:20:24] --- eburger has left
[03:21:33] --- eburger has joined
[03:22:06] <eburger> slide 3
[03:23:11] <eburger> slide 4
[03:25:06] <eburger> Emphasizing geting documents to IESG by December 15
[03:25:38] <eburger> slide 5
[03:27:08] <eburger> Working on bridge.
[03:27:14] <eburger> We're dropping you, but we'll be right back.
[03:27:31] <eburger> We're all on hold :)
[03:28:17] <eburger> Ted, you back?
[03:28:17] <eburger> Excellent!
[03:28:27] <Ted Hardie> What changed?
[03:29:20] <eburger> He got Canada to dial out to us. Is the audio quality better?
[03:29:44] <Ted Hardie> No change from my perspective.
[03:29:52] <eburger> :(
[03:29:56] <Ted Hardie> I can hear him well enough.
[03:30:04] <Ted Hardie> The rest of the room will be hard, likely.
[03:30:07] <eburger> OK. I'll make sure that everyone speaks up.
[03:30:11] <Ted Hardie> Thanks.
[03:30:47] <eburger> Can you hear Stephane OK?
[03:31:21] <Ted Hardie> Basically, no.
[03:31:37] <Ted Hardie> I heard him speak, but repeating the question may be important.
[03:34:13] <eburger> slide 6
[03:34:26] <eburger> slide 8, 9
[03:34:34] <eburger> (Now discussing slide 9)
[03:34:48] <eburger> goals been in RFC Editor Queue for over 18 months (!)
[03:34:58] <eburger> Question: does anyone care?
[03:35:40] <Ted Hardie> It is only indicative of how long other Informationals will take. Standards going higher in the queue.
[03:35:40] <eburger> Answer: we might be concerned about how long it takes to get stuff published, if this is indicitave of publication time.
[03:35:54] <eburger> Question: Isn't it because it's Informational?
[03:35:59] <eburger> Answer: probably
[03:36:31] <eburger> Alexey: RFC Editor tends to do work in bunches (IMAP, SMTP, SIP, etc.)
[03:37:20] <eburger> Ted: Dependencies also get bumped up over other stuff. If Profile reuqires dependencies, make sure they get done.
[03:37:28] <eburger> Getting OMA to "pressure" would not be a bad thing, as well.
[03:38:33] <eburger> Closing discussion of Goals: we don't really care, either, so we won't be pushing hard.
[03:38:42] <eburger> Discussing s2s Notifications requirements
[03:39:27] <eburger> Also "Informational", so no pressure to push through RFC Editor
[03:39:35] <Ted Hardie> Basically, we need to make sure that the document has nothing holding it up (no normative dependencies on documents which are not avaialble). If it is required for OMA, OMA's liaison can request expedited processing. But note that's sort of queue-jumping is partly responsible for the time things like goals document are spending in the queue. :(
[03:41:18] <eburger> MMS: Do we need another IETF LC?
[03:42:43] <eburger> Randy is still addressing issues raised by Chris Newman.
[03:44:15] <Ted Hardie> Yes, we do need another IETF LC.
[03:44:23] <Ted Hardie> For reconnect, is the proposed standard?
[03:45:06] <eburger> Comments from John should have been addressed
[03:45:50] <eburger> Alexey: issue - Rob S. raised issue on resuming session
[03:45:56] <eburger> Currently extension to LOGIN.
[03:46:07] <eburger> Plan to use separate command for continuing session
[03:46:14] <eburger> Makes document easier to understand and implement
[03:46:21] <eburger> Will add 1 more r.t.
[03:46:27] <eburger> Alexey will post description to list
[03:46:51] <eburger> Discussion was done off-line.
[03:48:41] <eburger> Timeframe?
[03:49:04] <eburger> Corby was going to do it this week, but he is moving house.
[03:49:17] <eburger> Alexey thinks new revision by end of October
[03:50:02] <eburger> Pointing out that deadline is 10/17.
[03:50:11] <eburger> (I-D deadline)
[03:51:04] <eburger> Alexey asks for implementation experience before we do WGLC
[03:51:44] <eburger> Glenn: we need to make appeal to Server Vendors :)
[03:52:43] <eburger> Alexey: Quick reconnect can be complex, so really wants to see if it works.
[03:53:23] <eburger> Glenn: Should we personally pressure server vendors to do something?
[03:53:28] <eburger> Alexey: that would help
[03:53:44] <eburger> Need to have new document first.
[03:55:49] <eburger> Stephane: is just the document changing, or the protocol?
[03:55:50] <eburger> Answer: yes
[03:56:03] <eburger> Yes, being the protocol (slightly), with new message
[03:56:09] <eburger> (message being RECONNECT)
[03:56:19] <eburger> Discussion turns to MMS mapping
[03:56:37] <eburger> Are there open issues?
[03:56:51] <eburger> Yes: Chris found some text errors and John K. found some nits.
[03:57:48] <eburger> Randy hoped to get draft done before Interim, didn't happen, but will try to get out -06 shortly
[03:57:58] <eburger> Issue: Message-ID and Info-ID; that is changing
[03:58:06] <eburger> Do we need to do WGLC?
[04:00:44] <eburger> Now it is critical to do Review or to do WGLC?
[04:01:26] <eburger> (oops, I meand Envelope-ID, not Info-ID)
[04:02:38] --- resnick has joined
[04:03:09] <eburger> Pete - can you review MMS mapping?
[04:03:27] <resnick> Yessir.
[04:03:42] <eburger> Great - we have our two reviewers: Greg V and Pete R.
[04:03:56] <Ted Hardie> Can you assign them dates?
[04:04:43] <eburger> -06 will be done on 10/6; review due 10/10.
[04:06:50] <resnick> I'm in.
[04:07:55] <Ted Hardie> If the -05 has not been seen by the drafts directory, you can't push an -06.
[04:08:11] <Ted Hardie> They will re-number it to -05.
[04:11:09] <eburger> Eric teaches Glenn how to turn of Windoze Screen Saver
[04:11:40] <eburger> Pete - you buy in to reviewing in 4 days and delivering on 10th?
[04:12:19] <eburger> If necessary, -07 by 10/17.
[04:12:28] <resnick> beep beep
[04:12:33] <Ted Hardie> One of the marx brothers there in the room with you?
[04:12:55] <resnick> I can hear you fine.
[04:13:01] <eburger> That was a lorry going by
[04:13:05] --- Dave Cridland has joined
[04:13:15] <eburger> beep beep
[04:13:30] <Ted Hardie> I can hear glenn, but the general room discussion is harder.
[04:13:47] <resnick> "That's the most ridiculous thing I ever hoid!"
[04:14:15] <resnick> I'll review MMS mapping today.
[04:14:29] <resnick> (When I'm more awake than I am now.)
[04:14:56] <eburger> Thanks Pete. Note that Randy is changing Message-ID and Envelope-ID.
[04:15:23] <eburger> Discussion now is that if Reconnect won't be done by December, should we move Reconnect to Profile phase 2
[04:15:40] <eburger> Reconnect depends on Expunge and Condstore
[04:15:54] <eburger> Expunge has been expunged :) [Expired]
[04:16:16] <eburger> Condstore is in IMAP-EXT
[04:16:44] <eburger> The "Sad Story" of Condstore
[04:16:56] <eburger> Condstore has been in RFC Editor Queue for 24 months.
[04:17:03] <eburger> However, it is dependent on ANNOTATE
[04:18:23] <eburger> ANNOTATE is just beginning to be implemented by 1 server vendor.
[04:18:48] <eburger> Implementation experience is discovering that the protocol is WAY too complicated than it needs to be.
[04:19:46] <eburger> Stuff like ASCII pattern matching, etc.
[04:19:54] <eburger> [reported by Dave Cridland]
[04:20:11] <eburger> ANNOTATE depends on I18N draft, which isn't done.
[04:20:24] <eburger> I18N depends on COMPARITORs draft, whcih isn't done.
[04:20:37] <resnick> Cyrus is ANNOTATE
[04:20:45] <resnick> Chris Newman is i18n
[04:20:50] <eburger> ANNOTATE editors are Cyrus and Randy
[04:21:31] <eburger> SIEVE also depends on COMPARITORS
[04:22:03] <resnick> Yes, i18n is in IMAPEXT.
[04:23:32] <eburger> Dave C. thinks there is a possibility to reformulate CONDSTORE to remove dependency on ANNOTATE, as the dependency is purely syntactic. Move syntax from ANNOTATE to CONDSTORE. Both drafts are being edited by Alexey.
[04:23:35] <resnick> Alexey needs to yell louder or get closer to the phone.
[04:23:37] <Dave Cridland> Comparators/Collations was adopted by IMAPEXT, I think.
[04:23:44] <resnick> :)
[04:23:54] <eburger> mumble
[04:24:11] <Dave Cridland> CONDSTORE would then depend on Alexey's IMAP ABNF extension.
[04:24:45] <eburger> Alexey asks Pete's thought on the idea (as IMAP-EXT WG chair)
[04:25:04] <Dave Cridland> SELECT (CONDSTORE), too.
[04:25:35] <eburger> Pete: can Alexey do write-up and post to list?
[04:25:45] <eburger> Yes.
[04:27:41] * resnick mutes his phone and runs to the fridge to get some juice
[04:27:46] <eburger> draft-melnikov-imap-ext-abnf-04.txt
[04:27:50] <eburger> slurrp
[04:28:50] <Ted Hardie> Can't hear greg
[04:30:34] <eburger> Ted: we can ask IESG to approve change to document (and it is not appealed), we can get RFC Editor to accept the change, without dropping document from its slot in the queue.
[04:31:40] <eburger> IMAP ABNF is pretty much done.
[04:32:00] <eburger> EXPUNGE - Alexey needs to review comments.
[04:32:17] <eburger> EXPUNGE is not an IMAP-EXT WG document, but an Individual (Alexey)
[04:32:29] <resnick> Is IMAPABNF an IMAPEXT document?
[04:32:36] <eburger> Question: EXPUNGE versus ESEARCH?
[04:32:54] <eburger> Answer: need to think about it.
[04:33:15] <eburger> Answer to Pete's Q: from the title, I think individual (draft-melnikov-imap-ext-abnf-04.txt)
[04:33:27] <resnick> Well, the title is why I asked.....
[04:33:40] <resnick> I can't remember.
[04:33:46] <resnick> It is individual.....
[04:33:53] <resnick> YELL KIDS!
[04:34:02] <Dave Cridland> Individual but discussed on IMAPEXT.
[04:34:03] <resnick> Right!
[04:34:09] <eburger> It was discussed in Paris - "Great Individual contribution, keep it that way"
[04:34:43] <eburger> Can Alexey get EXPUNGE and IMAP-ABNF done soon?
[04:35:05] <Dave Cridland> I think it's "EXPUNGED".
[04:35:19] <eburger> Possibly by 10/17, or remove reference to EXPUNGE
[04:35:21] <eburger> D
[04:36:01] <resnick> That person needs to speak louder
[04:36:03] <eburger> Last calling ESEARCH now
[04:38:39] <eburger> Moving conversation to Future Delivery
[04:38:49] <eburger> Only issue: Date/Time in addition to Interval
[04:38:51] <resnick> The bloody date-time!
[04:39:15] <eburger> Idea is when client doesn't have enough information, you can fail in more ways.
[04:39:20] <eburger> :)
[04:39:31] <eburger> Proposal is to add Date-Time.
[04:39:51] <eburger> Greg doesn't like idea of adding yet more ways of failing, as well as having two ways of doing same thing.
[04:40:01] <eburger> Randy: given list discussion, do both.
[04:40:32] <Ted Hardie> I think convergence seems unlikely; so it sounds to me like two or none.
[04:40:32] <eburger> If we're lucky, only one really gets implmeneted, in which case the loser gets dropped off.
[04:40:42] <eburger> Incremental cost of doing both is tiny.
[04:40:43] <Ted Hardie> from the spec side.
[04:41:01] <eburger> Consensus is to do both.
[04:41:53] <eburger> Greg will write up proposed syntax for doing both.
[04:42:17] <eburger> Steve K asks "Do we really want to do both?"
[04:42:28] <eburger> Answer is "that was the list discussion"
[04:43:47] --- corby has joined
[04:43:59] <eburger> Hi Corby! Can you dial-in?
[04:44:08] <eburger> Of course, we are about to go to a coffee break.
[04:44:12] <eburger> :)
[04:44:16] <corby> already dialed in
[04:44:30] <eburger> Cool.
[04:44:38] <corby> goog, I can get my eve so needed Starbucks
[04:45:05] <eburger> [oops - Future Delivery was on slide 10]
[04:45:23] <eburger> Break - getting back at 11am London Time
[04:58:25] --- Randy has joined
[05:00:45] --- eburger has left: Disconnected
[05:02:21] --- Glenn Parsons has joined
[05:03:12] --- Glenn Parsons has left: Disconnected
[05:05:00] --- eburger has joined
[05:05:17] <eburger> Returned.
[05:05:33] <eburger> Corby - you up?>
[05:05:41] <corby> I'm here
[05:05:46] <eburger> Slide 11: Trio
[05:06:45] <eburger> Pete: thnks he has addressed DISCUSSes; should be able to address with IESG note
[05:07:42] <eburger> Don't necessarily have to accept DISCUSS, just need to discuss it with them and to address them.
[05:07:51] <eburger> Ted can send note to RFC Editor if DISCUSS cleared.
[05:10:08] <eburger> Consensus is OK
[05:10:11] <eburger> Bigger issue: URLAUTH
[05:10:24] <eburger> Issue #1: need to "fix" access identifiers
[05:10:50] <eburger> BURL: Sam's DISCUSS was missing mandatory-to-implement auth mechanism
[05:10:50] <eburger> SASL issues
[05:11:20] <eburger> Since SUBMIT has mandatory-to-implement authentication, and since BURL is part of SUBMIT, what is problem?
[05:11:56] <eburger> Sounds like we disagree with Sam's DISCUSS.
[05:12:13] <eburger> Question to Ted: can we disagree with Sam's DISCUSS?
[05:12:39] <eburger> Ted: not a show-stopper, but painful.
[05:12:45] --- Randy has left: Lost connection
[05:12:45] --- eburger has left: Lost connection
[05:12:45] --- Dave Cridland has left: Lost connection
[05:12:45] --- corby has left: Lost connection
[05:14:02] --- eburger has joined
[05:14:18] <Ted Hardie> Basically, if the group continues to disagree with Sam, we need to take it back to the IESG with an explanation of why the mandatory-to-implement auth mechanism isn't required for interoperability here. The IESG can then ask Sam to change his discuss or send it forward over his objections. Not common; it's better to persuade Sam if we can.
[05:18:09] <eburger> eric is back
[05:19:25] <eburger> Pete will post changes to CATENATE to the list.
[05:19:41] --- corby has joined
[05:21:33] <eburger> So, we think CATENATE is done.
[05:22:08] <eburger> We need to close BURL and URLAUTH discusses.
[05:22:12] <eburger> We might be able to address with IESG notes
[05:22:25] <eburger> We have to talk with Sam
[05:22:29] <eburger> Glenn and Eric will follow-up
[05:22:57] <Ted Hardie> Russ's discuss, I believe, could be resolved with an RFC Editor note. It's sam's, I believe, that may need more effort.
[05:26:42] <eburger> Marc thinks the access identifiers DISCUSS is editorial and can be addressed.
[05:26:44] <eburger> Randy: thinks that they are Roles, not Prefixes
[05:27:46] <eburger> Randy suggests calling them Role Identifiers. He will post to list.
[05:30:29] <Ted Hardie> Can't hear the conversation at the moment
[05:30:42] <resnick> Yeah, neither can I.
[05:31:33] <eburger> It was about whether I could afford a PowerBook with my "winnings" from the Brooktrout-Excel merger. Answer: not really :(
[05:31:48] --- Dave Cridland has joined
[05:31:51] <Ted Hardie> Brian Carpenter: Comment: [2005-09-01] Some curious text in the "status of this memo" section of -urlauth-07: A revised version of this document will be submitted to the RFC editor as an Informational Document for the Internet Community. A revised version of this draft document will be submitted to the RFC editor as a Proposed Standard for the Internet Community. Gen-ART review comments from Lakshimnath Dondeti, for consideration if there are new versions: BURL ------- No additional issues other than those on the tracker already. What does BURL stand for? There are some typos toward the end of the security considerations section. Please run a spell check. Also, the RFC ed process will take care of it too. Lemonda-Catenate: ------------------------ Note: The author of this draft, Pete Resnick and I are colleagues, however I was not aware of this work until I read the draft for the first time to review it for Gen-ART. *) I would like to see more in the security considerations section. I understand that the draft says the proposal does not introduce any threats. However, this is in contradiction to the BURL draft's sec considerations section. I think that the first part of that section might be appropriate in this draft as well. *) The draft says "Responses behave just as the original APPEND command described in IMAP [1]." But the examples are somewhat inconsistent (may be I am being too picky): In Example 1: S: A003 OK catenate append completed In Example 3: A003 OK append Completed In Example 4: ... CATENATE append has failed, one message expunged Should they all use the keyword APPEND? Is the keyword CATENATE allowed in responses? I realize it is allowed in capabilities as specified in Section 5. URLauth ----------- * I am uncomfortable with the word Authorization and the mechanisms for it in this draft. However, it is late in the process to have a philosophical discussion. Since this is a WG consensus, I can live with it. To explain: The first sentence notes that RFC 2192 requires authorization My reading of that RFC is that it is talking about authenticating a user and then verifying whether the user is authorized to read/read-write. Authorization comes from local policy and enforced after authenticating the user. Section 1.4 concerns me. First, I am not sure I understand the use of HMAC-SHA-1 as an authorization mechanism. More importantly, the draft only recommends something such as that algorithm and notes that there is no way to change the algorithm without severe consequences. While HMAC is holding up, there are concerns about SHA-1 already; I am not sure about advancing protocol specs in which algorithms cannot be updated. Bill Fenner: Comment: [2005-09-01] draft-ietf-lemonade-burl should use the ABNF from 3986, in which 'absoluteURI' is spelled 'absolute-URI'. Sam Hartman: Discuss: [2005-08-31] The burl draft does not provide enough information and does not require a mandatory to implement mechanism such that a submit server from one vendor is guaranteed to be able to interoperate with an imap server from another vendor. Here are examples of missing information: 1) Mandatory to implement authentication mechanism for submit servers to support when contacting imap servers. 2) How does the submit server log in? Obvious answers include using the submit credential with no authorization id or the submit credential with the authorization ID of the user after submit+/user+. I think the first option is probably preferable, although it may involve some imap ickyness. Scott Hollenbeck: Discuss: [2005-08-30] draft-ietf-lemonade-catenate: The ABNF in section 5 contains two instances of an illegal character. The "_" characters in "toobig_response_code / badurl_response_code" should probably be changed to "-" characters. Comment: [2005-08-30] The documents contain normative references to RFC 2234, which has been obsoleted. It's replacement (draft-crocker-abnf-rfc2234bis) is in the RFC Editor queue. References to 2234 should probably be replaced with references to 2234bis. Russ Housley: Discuss: [2005-09-26] In draft-ietf-lemonade-urlauth-07, Status of this Memo, the document says: > > A revised version of this document will be submitted to the RFC > editor as an Informational Document for the Internet Community. > This document is being recommended for standards-track. Do the authors have other expectations? In draft-ietf-lemonade-urlauth-07, section 2, the definition of "access identifiers" is unclear. In my COMMENT, I have suggested a clarification based on my reading of the document. I could easily have gotten something wrong, and I will accept any rewording that makes the meaning clear. In draft-ietf-lemonade-urlauth-07, section 2, the document says: > > The "submit+" access identifier, followed by a userid, indicates ... > and > > The "user+" access identifier, followed by a userid, indicates ... > Neither "submit+" and "user+" are authorized access identifiers, as they are not a complete <access> portion of the URLAUTH. Perhaps these should be called authorized access identifiers prefixes. Comment: [2005-09-01] In draft-ietf-lemonade-urlauth-07, the [RANDOM] reference should point to RFC 4086. In draft-ietf-lemonade-urlauth-07, section 2 says: > > ";URLAUTH=<access>:<mech>:<token>" (the URLAUTH) MUST be at the end > of the URL. > This seems awkward to me. I suggest: > > The URLAUTH is comprised of ";URLAUTH=<access>:<mech>:<token>". > The URLAUTH MUST be at the end of the URL. In draft-ietf-lemonade-urlauth-07, section 2 says: > > ";URLAUTH=<access>:<mech>:<token>" indicates the access identifiers > which are permitted to use this URL, the authorization mechanism, and > the authorization token. > This also seems awkward to me. Building on the previous suggestion, I propose: > > The URLAUTH is composed of three parts. The <access> portion > provides the authorized access identifiers which may constrain the > operations and users that are permitted to use this URL. The <mech> > portion provides the authorization mechanism used by the IMAP server > to generate the authorization token that follows. The <token> > portion provides authorization token. In draft-ietf-lemonade-urlauth-07, section 6 says: > > (see below for more details about the URLMECH status response code). > Please provide a forward pointer to the section where this can be found.
[05:34:11] --- Randy has joined
[05:40:19] <eburger> Eric: Point is that only the IMAP server needs to know the algorithm for generating the hash for URLAUTH. It is opaque to the client and submit server. Moreover, the URLAUTH is short-lived, *and* the URLAUTH mechanism explicitly discusses server revocation of URLAUTH tokens. Thus the server can upgrade the hash at will.
[05:44:05] --- Glenn Parsons has joined
[05:44:57] <Randy> (test)
[05:45:13] <resnick> Yes?
[05:45:35] <Glenn Parsons> OK
[05:46:05] <Randy> Regarding the comment on the examples inconsistently including "CATENATE", this is a feature of the draft (since this is free-form text it is good for the draft examples to show differences). Perhaps one example should say "A003 OK all your CATENATEs are belong to us"
[05:46:31] <Ted Hardie> That would go over the head of quite a few people, I suspect.
[05:46:49] <eburger> Which "that"?
[05:46:49] <Dave Cridland> Hey, it made me laugh. :-)
[05:47:06] <eburger> Never mind - I just got it!
[05:47:06] <Randy> True, but what's wrong with an occasional obscure joke embedded in an RFC?
[05:48:31] <eburger> Ted - question is, do we talk about upgradeable has in URLAUTH as a Note or revised I-D?
[05:48:37] <eburger> Ted: Revised I-D.
[05:48:47] <eburger> Also should do revised I-D for BURL
[05:48:59] <Ted Hardie> Note: just advice; up to the authors and shepherds
[05:50:04] <eburger> Goal: new drafts by 10/17.
[05:51:19] <eburger> Randy: realizes that since user ID is in the token, it isn't just role.
[05:51:37] <eburger> "submit+" is a prefix or identifier.
[05:54:01] <eburger> Side note: Dinner will be at Satsuma, 56 WARDOUR STREET, LONDON W1 T 020 7437 8338; we'll have some sushi for our radio audience
[05:54:08] <eburger> slide 13
[05:54:16] <eburger> I meant slide 12
[05:54:22] <Ted Hardie> Is this "dinner" as in "lunch" or "dinner" as in "supper"
[05:54:27] <eburger> supper
[05:54:52] <Ted Hardie> When are you breaking for lunch--1:00 your time?
[05:55:21] <eburger> yes (1pm)
[05:55:30] <Dave Cridland> It was yesterday, yes. 1300 UCT+0100.
[05:58:33] <eburger> Discussion as to whether we respond to OMA liaison inviting us to yesterday's meeting.
[05:58:34] <eburger> No.
[05:59:10] <eburger> So now we will just wait for RD from OMA when it is ready.
[05:59:21] <eburger> I meant AD (not RD) - Architecture Document.
[05:59:36] <eburger> Expected after Sydney OMA meeting 10/17-19.
[05:59:52] <eburger> We will review in Vancouver.
[06:01:28] <eburger> Glenn: how should we respond? Note, I-D, Liaison?
[06:01:46] <eburger> Stephane: What about Profile Phase 2?
[06:02:48] <Randy> Are we saying the OMA AD will be posted as an I-D?
[06:02:58] <eburger> Eric: timing is that it would be after Vancouver.
[06:03:17] <eburger> To Randy's Q: no. We're talking about the lemonade response to the architecture document.
[06:05:04] <eburger> Important to have response as an I-D.
[06:05:18] <eburger> As it is the architecture document for us, too.
[06:06:21] <eburger> Will be useful text in any event.
[06:06:57] <Randy> We could eventually publish as Informational which lays out Architecture and how it fits with OMA MEM.
[06:07:01] <eburger> [Steve K leaves (our esteemed host)]
[06:07:14] <Randy> Some of that text could then be copied into Profile Phase 2
[06:09:53] <eburger> Summary: response will be a WG draft; won't release to OMA until agreed to (possibly -01, e.g.); will most likely use text from this draft for Profile Phase 2; we will decide if we need to publish as an RFC later.
[06:10:25] <eburger> We will send liaison to OMA after agreeing to response draft.
[06:10:35] <eburger> Goal: get to OMA before 12/14 meeting in Athens.
[06:11:24] --- Dave Cridland has left
[06:12:05] <eburger> Real goal is to get response done by 12/9.
[06:12:33] <eburger> [don't forget to send directly to Jerry in case of IETF-OMA interface bottlenecks]
[06:13:12] <eburger> slide 13 - profile discussion
[06:16:07] <eburger> Discussion of changes to Profile listed on Page 15 of draft (draft-ietf-lemonade-profile-04.txt)
[06:16:41] <resnick> Get Alexey closer to the phone please.
[06:17:20] <eburger> Do we push RECONNECT to phase 2?
[06:17:49] <eburger> If our definition of Phase 1 is "What is ready", then push out RECONNECt.
[06:18:07] <eburger> If our definition of Phase 1 is "What is useful", then do we need RECONNECT (maybe?)
[06:18:29] <eburger> Stephane: Forward-without-download is worth it.
[06:18:34] <eburger> Anil: without RECONNECT, not really useful
[06:18:43] <eburger> David: RECONNECT is not a barrier to the market
[06:19:00] <eburger> Alexey: RECONNECT is an optimization, but not having it is not a show-stopper
[06:20:33] <eburger> Eric: show progress - waiting for RECONNECT will impact Phase 2
[06:20:47] <eburger> Consensus: drop RECONNECT
[06:21:02] <eburger> from Phase 1
[06:21:27] <eburger> Gustaf: It's so expensive to create a session at the phone side, handset manufacturers would rather see long sessions, anyway.
[06:21:46] <eburger> Randy: faster publication of phase 1 gets implementations out there which gets some operational experience
[06:21:48] <Ted Hardie> Can you repeate Stephane's comment?
[06:22:37] <eburger> Stephane: lag time for server vendors, too, so faster publication means earlier implementations.
[06:23:04] <eburger> Alexey: second open issue: POSTADDRESS
[06:23:29] <eburger> Dave: POSTADDRESS is very useful - eliminates fcc problem
[06:23:38] <eburger> What is status of POSTADDRESS
[06:24:25] <eburger> Individual draft (Alexey); in last call; depending LIST-EXT
[06:24:44] <eburger> Dependency kind of kills idea of waiting.
[06:25:35] <eburger> Eric says something stupid
[06:25:39] <Glenn Parsons> he he
[06:25:49] <eburger> POSTADRESS is out
[06:26:42] <eburger> Note: page 12: "DNS" should be "DSN"
[06:29:40] <eburger> TLS is required
[06:31:02] <eburger> but no mandatory-to-implement compression
[06:31:13] <eburger> Thus compression goes into Phase 2
[06:31:23] <eburger> Moreover, we don't mention compression at all in Phase 1
[06:33:56] <eburger> Have note that CHUNKING is separate from 8BITMIME and BINARYMIME, as it is useful for interspersing BURL and BDAT.
[06:34:05] <eburger> "Suggested by BURL"
[06:34:09] <eburger> (in the table)
[06:34:35] <Randy> Rather than "Suggested by BURL" we should say "Section x.x" and then in that section say that it makes BURL better.
[06:36:58] <eburger> Remove Editor's Note in section 2.7, as it references POSTADDRESS, and move it to Phase 2.
[06:37:07] <eburger> Add section 2.8 to discuss CHUNKING/BURL
[06:37:54] <eburger> Do we need a section explaining why need BINARYMIME?
[06:38:04] <eburger> Editors will decide.
[06:38:17] <eburger> Randy will do text for CHUNKING.
[06:38:53] <eburger> RECONNECT, CONDSTORE is all gone from table/spec.
[06:40:13] --- sunny has joined
[06:41:16] --- sunny has left
[06:43:06] --- corby has left: Disconnected
[06:43:25] --- Fan Xiaohui has joined
[06:43:37] --- eburger has left: Disconnected
[06:44:49] <Glenn Parsons> Agreed to elave in CONDSTORE
[06:45:26] <Glenn Parsons> section 4 will be focused just on CONDSTORE
[06:45:43] <Glenn Parsons> Alexey will work on text
[06:47:48] --- eburger has joined
[06:48:12] <Ted Hardie> people need to speak up again, please
[06:48:16] --- eburger has left
[06:51:16] <Glenn Parsons> Discussion on section 8.1
[06:51:31] <Glenn Parsons> TLS MUSTs embedded in Security considerations
[06:51:59] <Glenn Parsons> these should be moved to its own section furhter up in the doc
[06:52:11] <Glenn Parsons> but leave TLS security considerations here
[06:52:52] <Glenn Parsons> Randy will write some clarifying text for TLS
[06:55:05] <Glenn Parsons> Do we need authentication text for security considerations?
[06:55:14] <Glenn Parsons> Not sure what we would put there?
[06:57:33] <Glenn Parsons> Agree to put it in
[06:57:53] <Glenn Parsons> Simply say that there is no issues beyond thaose in base IMAP
[06:58:11] --- eburger has joined
[06:58:31] <Randy> Something such as "the security considerations for clients and servers that are compliant with this document are identical to that of those that support IMAP and Submit"
[07:00:34] <Glenn Parsons> Now are we ready for WG last call?
[07:01:46] --- zordogh has joined
[07:02:29] <eburger> Do we WGLC -05 directly?
[07:02:43] <eburger> Needs close read of Examples.
[07:02:54] <Glenn Parsons> Dave volunteers to review examples
[07:03:23] --- zordogh has left
[07:03:44] <resnick> Am I being volunteered for something?
[07:03:56] <eburger> To review CATENATE examples in Profile phase 1
[07:04:01] <eburger> Can you?
[07:04:05] <resnick> Sure.
[07:04:06] <Randy> Alexey is especially concerned about examples in Profile not matching Examples (or syntax) of Catenate, URLAUTH, and BURL
[07:04:24] --- zordogh has joined
[07:06:40] <eburger> Draft will be out by 10/10, pending text from Randy on TLS and CHUNKING. Imediate WGLC.
[07:07:13] <eburger> Breaking for lunch, resuming at 2pm London time.
[07:07:16] <Ted Hardie> 53 minutes from now, eh?
[07:07:20] <eburger> Correct.
[07:07:48] --- eburger has left
[07:07:57] <Ted Hardie> okay; talk to you then. Note that the IESG telechat starts 2.5 hours after that, so I will be signing off then to go there.
[07:12:44] --- corby has joined
[07:12:44] --- corby has left
[07:12:57] --- corby has joined
[07:15:13] --- Glenn Parsons has left: Replaced by new connection
[07:15:45] --- zordogh has left: Disconnected
[07:27:19] <Randy> (Instead of a video game reference, maybe CATENATE should have examples that refer to Hitchhikers' Guide to the Galaxy, and say "A003 OK your literal has been CATENATEdly APPENDed. Thank you for using the Sirius Cybernetics Corporation IMAP server. It is my pleasure to CATENATE your data.
[07:27:22] <Randy> )
[07:30:39] --- corby has left
[07:46:37] --- eburger has joined
[07:50:37] --- corby has joined
[07:50:38] --- corby has left
[07:51:19] --- corby has joined
[07:56:17] <eburger> 5 minutes to start...
[07:58:12] * resnick is back on the conference call
[07:59:46] --- Glenn Parsons has joined
[07:59:58] --- Glenn Parsons has left
[08:00:35] --- Dave Cridland has joined
[08:00:38] <Ted Hardie> //me too
[08:00:40] <eburger> yes
[08:01:28] <corby> 412=Corby
[08:03:20] <eburger> back on the air!
[08:03:28] <eburger> reviewing slide 5 (agenda)
[08:04:02] <eburger> Where to inlcude Sieve presentation?
[08:04:29] <eburger> Notifications, then Sieve, then more notifications discussions under Drafts Review
[08:04:49] <eburger> First "Notifications" discussion is about IAB and philosophy.
[08:05:25] <eburger> slide 15
[08:06:03] <eburger> Charter: only server-to-server in charter.
[08:06:12] <eburger> (notifications)
[08:06:24] --- zordogh has joined
[08:06:27] <eburger> Glenn tells story of IAB memo on notifications
[08:06:46] <eburger> and shows memo
[08:06:49] <Ted Hardie> I can hear you trying to talk Pete
[08:07:08] <resnick> Can the room hear us?
[08:07:14] <resnick> Hellooooooo
[08:07:14] <Ted Hardie> Pete's trying to talk.
[08:07:15] <eburger> NO.
[08:07:16] <Dave Cridland> No.
[08:07:21] <eburger> Ted, can you talk?
[08:07:37] <eburger> I still don't hear anything. Wait 1.
[08:07:45] <Ted Hardie> Are you in lecture mode?
[08:07:49] <resnick> Guys: Pause.
[08:08:08] <resnick> We can hear eachother
[08:08:11] <Ted Hardie> We can hear you.
[08:08:30] <resnick> Mute yourselves momentarily
[08:08:44] <resnick> No
[08:08:45] <Ted Hardie> does it have a volume control
[08:08:51] <resnick> See if you can hear us with mute on
[08:09:21] <resnick> Can the room hear us?
[08:09:32] <Dave Cridland> No.
[08:09:51] <resnick> Shall we all have a go at hanging up and dialing back in?
[08:10:02] <Ted Hardie> Is there a lecture mode?
[08:10:05] <resnick> I can hear you
[08:10:06] <Ted Hardie> He can hear you.
[08:10:15] <corby> We can hear you glen.
[08:10:18] <Ted Hardie> Are you in that mode, rather than "all may talk mode?"
[08:10:35] <resnick> And we can all hear ourselves
[08:10:49] <Ted Hardie> No volume control obvious, eh?
[08:10:56] <resnick> Is the volume on your speaker phone too low?
[08:11:15] <resnick> Can you hang up and dial back in?
[08:11:24] <Ted Hardie> They
[08:11:29] <Ted Hardie> were dialed out to.
[08:11:39] <eburger> It was painful - the phone doesn't do DTMF.
[08:11:45] <resnick> Oy.
[08:14:24] <Ted Hardie> I thought the IAB was later re-asked the question (by me) and decided that James' was the current answer.
[08:16:37] <Ted Hardie> http://www.iab.org/documents/docs/2003-07-10-iab-notification.html
[08:16:43] <Ted Hardie> Is the answer James formulated
[08:19:08] <eburger> Ted re-asked, and on 8/8/05, Leslie said that the answer is OK, unless we want the IAB to think more on it.
[08:19:58] <Ted Hardie> Her'e her note (excerpted a bit)
[08:20:00] <Ted Hardie> Let me rephrase: > > The IAB (at the time) decided James' note was the > best we were going to be able to produce. There is no > current effort to produce something else. If the APPS > area was not satisfied with James' response, we can > review whether we think we have more things to say > now. But, you have to weigh whether the delay between > that response & a decision now that it is insufficient > fits with LEMONADE's needs. Let us know. > > Leslie.
[08:20:23] <Ted Hardie> I think the word ruling is wonky here.
[08:20:35] <resnick> Yes, indeed!
[08:21:10] <Ted Hardie> The charter allows you to work on a specific class of notification; it notes that you can use IAB input for this.
[08:21:19] <Ted Hardie> You have IAB input; you can tick that box.
[08:21:22] <resnick> The IAB does not "issue rulings". We give architectural advice. Occasionally the IESG decides whether documents are sufficiently complete based on that advice.
[08:21:48] <Ted Hardie> If you wish to solicit further discussion or advice, you can do it from anyone you chose, including current or former members of the IAB, or the IAB as a obdy again.
[08:22:02] <Ted Hardie> But as your AD, I don't think you are constrained to wait for further input.
[08:22:03] --- zordogh has left: Replaced by new connection
[08:22:22] <Ted Hardie> er, obdy-->body
[08:22:51] --- zordogh has joined
[08:24:17] <eburger> Eric: Mobile Notifier -> Handset clearly out of scope. IMAP -> Mobile Notifier should be in scope.
[08:24:44] <eburger> Probably OK to do s2s notification protocol, but SNAP isn't it.
[08:25:33] <eburger> 4. Define a format for message notifications for servers reporting message status information to other servers. Specify the method for delivery of those notifications.
[08:27:55] <eburger> We think Frank's response is sufficient. We do not want to solicit further IAB or IESG comments, because we believe we are within charter, and address the issues that Frank raised.
[08:28:11] <Ted Hardie> Do you mean James' response?
[08:28:55] <resnick> !
[08:29:09] <eburger> Yes, James, not Frank.
[08:29:14] <resnick> Stop calling it a ruling? ;)
[08:29:19] <eburger> NOT A RULING.
[08:29:32] <resnick> :)
[08:29:48] <resnick> The IAB likes sending notes.
[08:31:17] <eburger> It's on supplemental web site.
[08:31:53] <zordogh> http://flyingfox.snowshore.com/i-d/lemonade/slides63-5/Lemonade-Sieve.overview.ppt
[08:32:04] <eburger> http://flyingfox.snowshore.com/i-d/lemonade/slides63-5/Lemonade-Sieve.overview.pdf and http://flyingfox.snowshore.com/i-d/lemonade/slides63-5/lemonade_mobile_newdrafts_London_sm_9_29_05.ppt
[08:32:08] <eburger> slide 2
[08:33:20] * resnick will be gone for a bit (downstairs for food) since he knows what sieve is
[08:33:28] <eburger> slide 3
[08:36:37] <eburger> We're up to "What can SIEVE do right now"
[08:39:38] --- zordogh has left: Disconnected
[08:40:16] * resnick is back
[08:44:21] <eburger> "Application to Lemonade: Customizable notifications"
[08:45:03] <eburger> SIEVE has extensions that make sense only in certain contexts, for example, notifications, header manipulation, etc. don't span message transport, message delivery, and message receipt.
[08:45:36] <resnick> I'm having a hard time hearing the current discussion
[08:45:39] <eburger> That's OK
[08:45:52] <resnick> :)
[08:48:17] <eburger> What's ":low"?
[08:48:20] <eburger> Answer: priority
[08:48:26] <eburger> (low, medium, high)
[08:49:01] <eburger> Question: client sends e-mail; what if rule says "if I see subject x, change it to subject y". What happens to return message.
[08:49:27] <eburger> Answer: yes, sieve can change message headers
[08:50:02] <eburger> So, if I change the subject, will that change, for example, the MDN?
[08:50:39] <eburger> Answer: yes
[08:50:54] <resnick> "One ought not do that"
[08:51:02] <eburger> Exactly.
[08:51:24] <eburger> Question: can an inbound message generate a new message?
[08:51:37] <eburger> Answer: yes, just fileinto mailto: URL
[08:52:10] <eburger> Question: could I build Future Delivery using SIEVE?
[08:52:33] <eburger> Answer: uhhh. Yes [Eric: if you create a Future Delivery extension]
[08:52:46] <eburger> Ray: Answer is also yes, because SIEVE lets you fork a process...
[08:53:11] <eburger> Question: how do you specify triggers?
[08:53:26] <eburger> Answer: that is currently being worked on, but is right now undefined.
[08:53:46] <eburger> Question: Does SIEVE support URI's today?
[08:53:50] <eburger> Answer: yes, next slide
[08:54:11] <eburger> "application to Lemonade: Mailbox annotations"
[08:54:49] <eburger> :method lets us use mailto:, sms:, xmpp:, etc. targets
[08:56:23] <eburger> Comment: if you need persistence, you can use ANNOTATEMORE or insert new headers
[08:56:42] <eburger> "SIEVE script management/generation"
[08:57:44] <eburger> Thinking of trigger / execution methods
[08:58:12] <eburger> Ray: Would be nice to have multiple scripts instead of a single, monolithic script.
[08:58:31] <eburger> Greg: Don't want multiple scripts out everywhere
[08:58:35] <resnick> (Whenever you get a chance: Who's in the room?)
[08:59:34] <eburger> Question: can one reverse-engineer script into UI?
[08:59:57] <eburger> Answer: kind-of; switches & nested tests don't get presented easily
[09:00:18] <eburger> Lemonade Interim Attendees Day 1: 29 September 2005 Alexey Melnikov Eric Burger Randall Gellens Stephane Maes Ray Cromwell Steve Killi Todd Choi Anil Srivastava Zoltan Ösdögh Andy Pearlson Dwight Smith Jerry Shih Greg Vaudreuil Glenn Parsons Dave Cridland Gustaf Rosell By phone/jabber: Ted Hardie Peter Resnick Corby Wilson Fan Xiaohui
[09:01:22] <eburger> Greg: so is there a market for the situation where someone builds a script on a PC but tries to edit it on a handset?
[09:01:30] <eburger> Grimaces all around
[09:01:56] <resnick> vi on the handset! Weeeee......
[09:02:15] <eburger> Question: must one have script editor on phone?
[09:02:16] <eburger> Answer: no.
[09:02:39] <corby> There is definitely the case where you get a mail message on the terminal and create a quick script to block future delivery of messages from this user/domain to the terminal.
[09:02:43] <resnick> Well, you could, but "one ought not do that".
[09:03:26] <corby> I can see 'on the fly enhancements' of existing scripts to fine tune terminal scripts.
[09:03:52] <eburger> There are currently multiple methods of administering SIEVE scripts, including ACAP and LDAP
[09:03:52] <resnick> Yeah, but you probably wouldn't want to build a script with one UI and edit it with another UI.
[09:04:05] <eburger> Working on a single protocol
[09:04:14] <resnick> (Depending of course on how simple or complicated it is.
[09:04:15] <resnick> )
[09:04:24] --- Glenn Parsons has joined
[09:04:26] --- Glenn Parsons has left
[09:05:30] --- Glenn Parsons has joined
[09:05:33] <resnick> What is our schedule for today and tomorrow? 9-5 for both?
[09:05:50] <eburger> 9-5 today, 9-12 tomorrow.
[09:05:55] <resnick> Oh, good.
[09:06:03] <resnick> That works well for me.
[09:06:05] <Randy> Years ago, Qpopper implemented a subset of ACAP for Sieve scripts, called SieveAD. It's just enough ACAP to manage Sieve scripts.
[09:06:07] <eburger> :)
[09:06:12] <Randy> There's an I-D on it.
[09:07:18] <eburger> Can one specify rules that trigger other rules?
[09:07:53] <eburger> You can have meta-rules.
[09:08:00] <eburger> Can run included scripts.
[09:08:12] <eburger> Nice to be able to have scripts that have different privileges
[09:08:30] <eburger> Answer: implementations today do that, but not standardized yet.
[09:08:39] <eburger> Question: any concept of work-flow?
[09:08:55] <eburger> Answer: no. Just get a set of scripts, and one becomes active.
[09:09:08] <eburger> Question: any thought of building-in work-flow?
[09:09:13] <eburger> Answer: not at this time
[09:09:33] --- Dave Cridland has left: Replaced by new connection
[09:09:49] --- Dave Cridland has joined
[09:09:51] <eburger> Can create one meta-script that INCLUDES others.
[09:10:20] <eburger> Nice to have scripting libraries
[09:10:52] <eburger> Mail list discussion (SIEVE) is to allow variables being shared across scripts. Possibly letting meta-script define global variables.
[09:12:17] <eburger> Question: can I redirect mail to anywhere?
[09:12:19] <eburger> Answer: yes
[09:12:37] <Randy> Comment that redirecting introduces loop and exploit risks
[09:12:53] <eburger> Back to Main Presentation: Slide 16 of Chairs' Slides
[09:15:25] <eburger> Consensus: Phase 2 Obsoletes Phase 1
[09:18:28] <eburger> Randy: can't we just call phase 2 "recycling"?
[09:19:00] <eburger> [recycling of "THE Lemonade Spec"]
[09:19:55] <Randy> I'm saying we should not use "Phase 1" or "Phase 2", but instead we publish the Lemonade spec (what we call phase 1) and then publish a new document that recycles at Proposed Standard.
[09:23:56] <Randy> If we wish to call the newer document "Lemonade Version 2" that's fine, but we do that then
[09:24:32] <eburger> Consensus: Call it simply "The Lemonade Profile"
[09:25:25] <eburger> Stephane: issue is OMA will look at Lemonade Profile and say, "it doesn't meet our needs"
[09:25:46] <eburger> Answer: same problem anyway with "phase 1".
[09:26:12] <eburger> Action: change title of Profile, make sure it doesn't talk about "Phase 1", but rather say, "future work"
[09:26:39] <eburger> We will decide title of Phase 2 later.
[09:26:49] <eburger> Phase 2 will include Phase 1 text, as Phase 2 will obsolete it.
[09:28:35] <Randy> In the current Profile, section 7 is called "Future Work" and says "Future phases of the Lemonade profile are expected to address".
[09:28:46] <eburger> "this was the full list" refers to slide 18
[09:29:08] <Randy> I'd suggest changing this to "Ongoing work is investigating" or something like that
[09:35:29] <eburger> [Ray leaves]
[09:37:13] <eburger> [Whoops, Ray is still here. It was Dwight who left.]
[09:38:48] <Ted Hardie> see you in 15
[09:38:52] <eburger> Coffee is here - brew your own at home!
[09:38:52] <Ted Hardie> or hear you, anyway.
[09:38:54] <eburger> +15 minutes.
[09:55:42] <Ted Hardie> Is this side conversation or are we back?
[09:56:19] <Glenn Parsons> side coversation...
[10:01:53] <Ted Hardie> I'm going to have to step off in 20 minutes, so if there is a conversation you need me for before tomorrow, now would be the time.
[10:04:49] <Ted Hardie> Guys, I think you need to focus.
[10:06:19] <Ted Hardie> cool. I'll be on tomorrow as well, so you can send anything in email.
[10:07:36] <eburger> Is tomorrow OK for you?
[10:08:43] <eburger> test
[10:09:19] <Ted Hardie> I saw the test
[10:09:55] <eburger> Agenda coming;;;
[10:10:18] <Glenn Parsons> Order of phase 2 discussion
[10:10:21] --- eburger has left
[10:10:41] <Glenn Parsons> ...
[10:10:43] --- eburger has joined
[10:10:44] <Glenn Parsons> Filter / NotificationsSIEVE WG draft-maes-lemonade-notifications-server-to-clientdraft-wener-lemonade-clearidledraft-newman-lemonade-msgevent Content Transformation draft-maes-lemonade-lconvertdraft-ietf-lemonade-channel derivatives for streaming & static content Submission & remote compose draft-maes-lemonade-deliver Application Compression draft-maes-lemonade-lzip Firewallsdraft-maes-lemonade-http-binding Draft profile
[10:11:05] --- eburger has left
[10:11:38] <Randy> (test)
[10:12:04] <Randy> (test)
[10:12:07] <Glenn Parsons> Agenda
[10:14:29] <Glenn Parsons> Stephane now presenting his slides -- starting on slide 24
[10:14:33] <Glenn Parsons> Eric are these on the supplemental site?
[10:17:55] --- eburger has joined
[10:18:20] <eburger> .
[10:18:24] <eburger> .
[10:20:18] <Ted Hardie> I'm stepping off the call now. Talk to you guys tomorrow.
[10:20:31] --- Ted Hardie has left
[10:46:41] <resnick> Are we looking at a whiteboard or a slide?
[10:57:55] --- ebjurger has joined
[10:57:55] --- Fan Xiaohui has left: Lost connection
[10:58:15] <ebjurger> xyzzy
[10:58:15] --- eburger has left: Lost connection
[10:58:15] --- Glenn Parsons has left: Lost connection
[10:58:15] --- Randy has left: Lost connection
[10:58:15] --- corby has left: Lost connection
[10:58:24] <ebjurger> Break in for Eric getting back on line
[10:59:16] <ebjurger> Summary: need to create text around notifications
[10:59:26] <ebjurger> we will look at notion of View
[10:59:32] <ebjurger> Eric: MUST reference Chris Date
[10:59:44] <resnick> "Chris Date"?
[10:59:52] --- Randy has joined
[10:59:56] <ebjurger> need notion of annotation of stuff for specifying SIEVE rules
[11:00:05] <Dave Cridland> resnick:Yeah, should be RFC3339, really.
[11:00:14] <resnick> Ah.
[11:00:21] <ebjurger> sieve rules, which run in different places
[11:00:37] <ebjurger> switching, handling, etc. out of scope
[11:00:42] <Dave Cridland> resnick: Chris Date is someone who wrote a book on views, or something.
[11:00:54] <ebjurger> Greg: separate notion of views from notification
[11:01:39] <ebjurger> [Chris Date: protogee of Codd; best explanation of relational data base theory]
[11:02:08] <ebjurger> [Sorry, my Professor of Computer Science, teaching Data Base Theory, comes through]
[11:02:14] <resnick> The whole discussion of "view" gives me flashbacks to IMAPEXT WINDOW/VIEW discussions.
[11:02:47] --- Glenn Parsons has joined
[11:02:50] <Randy> And ACAP virtual scrollbars before that
[11:03:07] <ebjurger> My point is that there have been MANY examples in IETF of people that have no clue of data base theory try to do data base type stuff, but don't realize it. They then tend to make mistakes that have been made *and solved* 25 years ago. Think XCAP...
[11:04:39] <resnick> Are we wrapping up soon?
[11:04:53] <ebjurger> Have to be. I was waiting for a lull to point that out...
[11:04:58] <resnick> :)
[11:05:21] <Randy> ::))
[11:05:47] <Dave Cridland> randy: I got full ACAP virtual scrollbars working in this client a little while ago.
[11:06:01] <Dave Cridland> Scrolling through my addressbook is pretty fast now.
[11:07:06] <ebjurger> View & annotate issues
[11:07:21] <Dave Cridland> That's annotatemore.
[11:07:25] <ebjurger> Greg and Stephane will collaborate on document to explain issues and help us chose
[11:07:41] <Dave Cridland> per-mailbox, not per-message.
[11:07:41] <ebjurger> (right - ANNOTAQTEMORE)
[11:07:52] <ebjurger> Q=O
[11:08:28] <ebjurger> Q=O=""
[11:09:29] <ebjurger> Resuming tomorrow morning 9am London time, ending at noon.
[11:10:10] --- ebjurger has left
[11:10:12] --- resnick has left
[11:11:56] --- Dave Cridland has left
[11:16:30] --- Randy has left: Logged out
[11:41:58] --- Glenn Parsons has left: Disconnected