[07:57:34] --- amelnikov has joined
[08:24:40] --- cyrus_daboo has joined
[08:25:04] <cyrus_daboo> Hi Alexey - I just sent some 2086upd comments to the list.
[08:45:33] --- lisaDusseault has joined
[08:45:42] <lisaDusseault> Hi guys
[08:46:03] <lisaDusseault> how are you two this snowy morning :)
[08:46:03] <cyrus_daboo> Hi Lisa, I hear you on the audio stream.
[08:46:25] <lisaDusseault> That audio stream stuff is cool.
[08:46:26] <amelnikov> No snow for me :-)
[08:46:31] <cyrus_daboo> We had snow overnight - not much and its above freezing here right now.
[08:48:41] <cyrus_daboo> Of course we need notifications for caldav too....
[08:49:10] <lisaDusseault> It's true
[08:49:35] <cyrus_daboo> I only hear one side of the conversation...
[08:49:50] <lisaDusseault> I figured.
[08:49:58] <lisaDusseault> I'm sitting right next to the lavalier
[08:50:20] <cyrus_daboo> An xmpp notification scheme is something we could also use in the notify extension in SIEVE.
[08:50:40] <lisaDusseault> Well, push Joe to go the next step :)
[08:51:00] <lisaDusseault> People are stumbling in looking tired
[08:51:29] <cyrus_daboo> Hi Barry - sorry no two-way audio - maybe next IETF???
[08:51:34] <lisaDusseault> cool
[08:52:03] <lisaDusseault> did you see in Korea where Ekr couldn't be there and Pete video-conferenced him onto the big big screen in the plenary?
[08:52:13] <lisaDusseault> big scary Ekr head!
[08:52:33] <cyrus_daboo> Did not see that. I do have my iSight here, but I'm not sure people would want to see me on screen this early in the moring!
[08:53:20] <lisaDusseault> I don't have mine here, though.
[08:53:51] --- robsiemb has joined
[08:54:00] <cyrus_daboo> Right - plus it would be hard to hook up the iChat audio to the mike to make sure iChat is echoed to the mp3 stream.
[08:55:47] --- Hollenbeck has joined
[08:56:37] --- pguenther has joined
[08:56:37] <lisaDusseault> True
[08:56:45] --- tonyhansen has joined
[08:57:13] --- Glenn Parsons has joined
[08:57:42] <amelnikov> Cyrus just clarified that his I18N comment is about moving some text into a separate section. No need to reference I18N draft, hopefully.
[08:58:44] * robsiemb has set the topic to: imapext variety show
[08:58:45] --- randy has joined
[08:59:27] <robsiemb> 2086upd - things are looking quite good and we're almost done, we know we're getting enough review
[09:00:04] <robsiemb> lisa: any other comments? (cyrus sent lots this morning, but its still pretty early)
[09:00:42] <amelnikov> Some minor editorial changes might be required based on Cyrus' comments
[09:01:17] <cyrus_daboo> Actually its not just 'user' id, it could be 'group' or generic 'anyone'. I do prefer WebDAV's 'principal' terminologu these days.
[09:01:27] <robsiemb> alexey are you getting sound?
[09:01:57] <cyrus_daboo> All my comments are minor - I don't belive any invalidate the last call.
[09:02:18] <robsiemb> annotate
[09:02:23] --- resnick has joined
[09:02:39] <randy> Did we decide to go with ASCII + displayname after all?
[09:03:07] <robsiemb> lisa: what is the procedure for referencing the replaced document?
[09:03:26] <cyrus_daboo> Does Lisa have the list of annotate issues I sent out yesterday?
[09:03:27] <robsiemb> the chatter in the room is that it should go in informative or not go in at all. you MUST say it obsoletes 2086
[09:04:21] <randy> I don't have it
[09:04:30] <cyrus_daboo> Bummer - sorry Randy....
[09:05:15] <robsiemb> FWIW 3501 has informative references to 2062 and 1732
[09:07:01] <robsiemb> lisa is reading all of the the changes\
[09:07:37] <robsiemb> pete is working on making the changes projected
[09:08:29] <cyrus_daboo> Use of UTF-8 is probably SHOULD not MUST
[09:08:31] <robsiemb> cyrus: is the use of utf-8 change a recommend or a must?
[09:08:34] <robsiemb> ah,.
[09:08:48] --- hildjj has joined
[09:08:54] --- dbrashear has joined
[09:09:00] <robsiemb> phillip: should sounds correct, someone will surely find something non-unicode
[09:09:08] --- Barry Leiba has joined
[09:09:12] <robsiemb> lisa: what about xmpp?
[09:09:28] <robsiemb> joe hilderan: says xmpp transcoding was bad if you didn't use unicode
[09:09:50] <cyrus_daboo> I'm not adverse to saying MUST use ascii, utf-8, utf-16...
[09:09:56] <robsiemb> phillip: do they allow arbitrary mime types
[09:10:02] <robsiemb> lisa: yes for webdav, no for xmpp
[09:10:02] --- resnick has left: Disconnected
[09:10:25] --- resnick has joined
[09:10:45] <robsiemb> lisa: specifically, for protocol marshalling, not for the content
[09:11:15] <robsiemb> joe: is there something that says what the content type is?
[09:11:22] <robsiemb> phillip: yes
[09:11:48] <robsiemb> (rather, joe asked if something specified the encoding, and phillip mentioned the content-type field)
[09:11:52] <robsiemb> open issues
[09:12:05] <robsiemb> Should servers validate the content type value?
[09:12:12] <robsiemb> phillip: the syntax?
[09:12:12] <lisaDusseault> We don't get this issue
[09:12:17] <cyrus_daboo> Validate the synatax of the content-type value.
[09:12:29] <robsiemb> phillip: validating that is is correct is hard
[09:12:39] <robsiemb> phillip: (that is is correct for the data)
[09:13:13] <cyrus_daboo> Can we say that content-type value is what is defined by MIME Content-Type header and reuse their syntax?
[09:13:14] <robsiemb> pete: consensus seems to be yes, validate it
[09:13:33] <lisaDusseault> That sounds like a good idea to me, Cyrus
[09:13:46] <cyrus_daboo> Yes - referernce 2046.
[09:14:01] <robsiemb> no one can think of a reason not to
[09:14:12] <cyrus_daboo> OK, I will make that change then.
[09:14:28] <robsiemb> next issue: should entry registration include a default content-type value
[09:15:13] <robsiemb> phillip: it would be hard for a client that didn't know the attribute registration to know what the content-type was
[09:15:19] <cyrus_daboo> Do we want to hard-code content-types? i.e. can the /comment entry contain an image/jpeg - does it make sense to allow that?
[09:15:26] <lisaDusseault> Cyrus, can you make your recommendation clear in these issues?
[09:15:39] <lisaDusseault> Might as well have a strawman rather than a completely open issue
[09:16:01] <robsiemb> phillip: why hard-code content type if we're transmitting it
[09:16:32] <robsiemb> phillip: either transmit a content-type or don't, and rely on the registration, don't do both
[09:17:09] <robsiemb> randy: 2 issues here, should we restrict what content types go in what entries, and should there be defaults
[09:17:17] <cyrus_daboo> The registration could include a 'recommended' content-type, but that can be override in the actual entry.
[09:17:31] <robsiemb> randy: I think the first issue is a bad idea, the second is "expected, not default" and it is always sent regardless
[09:17:40] --- cnewman has joined
[09:17:42] <lisaDusseault> BTW, thanks for jumping in and doing the transcription, Rob. I was going to ask for a scribe earlier when I noticed you were already doing so :)
[09:18:29] <cyrus_daboo> OK, so I will extend IANA registration form to include recommended c-t value.
[09:18:36] <robsiemb> pete: it seems like we have a consensus that the registration should recommend something
[09:18:55] <robsiemb> lisa, we'll see if the network holds out, I've had bad luck earlier in the week :)
[09:19:31] <robsiemb> next issue: can values contain binary data? no content-encoding, but we'd need literal8 syntax from BINARY
[09:19:34] <cyrus_daboo> Ok, now I wish I had video to see Ned's face :-)
[09:19:47] <randy> The client still needs to set the content type, even if it is setting it to the recommended type, unless it is text/plain; charset=utf8
[09:20:24] <robsiemb> ned: requiring binary seems scary
[09:20:33] <robsiemb> chris: we should look at binary support in LDAP
[09:20:56] <robsiemb> kurt: do you want to get the problems that came with that too?
[09:20:58] <randy> Chris: name must end in ";binary" to permit binary values
[09:22:02] <robsiemb> kurt: need to be very careful if you do this
[09:22:09] <lisaDusseault> He mentioned "the abyss"
[09:22:13] <amelnikov> Can we just mandate binary?
[09:22:43] <robsiemb> barry: people will want to attach things to messages, like executables....
[09:22:51] <robsiemb> (side discussion about executables)
[09:22:55] <cyrus_daboo> I don't have much to add. I do think people will want to add images etc - so we either allow binary or we have to define a content-transfer-encoding attribute and say its base64
[09:23:10] <robsiemb> barry: people will want to attach binary data, and they will encode it in arbitrary ways
[09:23:56] <robsiemb> pete: are we moving towards CTEs on annotations?
[09:24:06] <robsiemb> chris: we can say the payload of an annotation is ALWAYS literal8
[09:24:29] <robsiemb> chris: (hard dependency on BINARY then)
[09:25:11] <amelnikov> I don't have problems with literal8, but I don't want to implement BINARY decoding of message parts. I wish they are separate.
[09:26:07] <robsiemb> (dependency is just for the syntax, servers would not have to implement BINARY)
[09:27:07] <robsiemb> chris: summizes: copy/reuse literal8 syntax, and the value of an annotation, if it is a literal, must be a literal8
[09:27:13] <amelnikov> We can copy literal8 syntax to a different draft, not necessarily ANNOTATE
[09:27:45] --- lisaDusseault has left
[09:27:55] <cyrus_daboo> I think we could put literal8 syntax into Alexey's extended syntax document and reference it from there.
[09:28:28] <amelnikov> To Philip: exactly my point
[09:28:37] <cyrus_daboo> I agree with Pihilip
[09:28:37] --- lisaDusseault has joined
[09:28:50] <amelnikov> Ok
[09:28:57] <robsiemb> pete: seems to be agreement to move literal8 syntax into the extensible syntax document, and reference that
[09:29:23] <robsiemb> chris: binary is likely to move faster than extended syntax
[09:29:42] <robsiemb> scott says the document for syntax could be informational
[09:29:43] <amelnikov> Chris: why do you think that BINARY will progress faster?
[09:29:45] <robsiemb> barry: [redacted]
[09:29:49] <cyrus_daboo> Come on, lets face it. nothing is going to move until IMAP base moves anyway - what is the likelyhood of that...
[09:30:51] <robsiemb> chris: we already have binary interoperable implementations
[09:31:09] <amelnikov> I was just wondering if Chris knows of any problems with syntax extensiond ;-)
[09:31:22] <robsiemb> next issue: should we restrict attribute names to exclude priv and shared in the text?
[09:31:47] <robsiemb> lisa: can attribute names contain periods?
[09:32:21] <robsiemb> phillip: currently names are utf-8, and excluding dots....
[09:32:27] <robsiemb> phillip: if we made it us-ascii, it would be simpler
[09:32:33] <cyrus_daboo> Attribute names for vendor defined items are defined with a '.' in them.
[09:33:01] <robsiemb> phillip: we have to exclude the names explicitly priv and shared
[09:33:11] <cyrus_daboo> So 'priv' and 'shraed' cannot be used as a hierarchy element?
[09:33:12] <robsiemb> randy: the names are hierarchial separated by .
[09:33:32] <amelnikov> Cyrus: do you mean "foo.shared.priv"?
[09:33:43] <cyrus_daboo> Yes, Alexey.
[09:34:08] <robsiemb> yes, so shared in that case would be banned
[09:34:24] <cyrus_daboo> Sounds good to me.
[09:34:53] <robsiemb> next-issue: utf-8 entry/attribute names: lunch bof proposal to restrict to ascii is fine by cyrus, can we get WG consensus?
[09:35:25] --- dcrocker has joined
[09:35:28] <robsiemb> summary of proposal: limit to ascii, then have an attribute for display name
[09:35:52] <randy> display name is used only for display, not for searching
[09:35:57] <robsiemb> clients would also not have to display the display name that is provided
[09:36:01] <cyrus_daboo> Note we cannot restrict the syntax of entries beyond what is defined for flags and keywords, since we map those into entry names.
[09:36:14] <randy> display name is optional -- it does not need to be present and if it is present the client can use something else
[09:37:02] <robsiemb> chris: subsenquent hallway discussion: mailbox names include non-ascii characters
[09:37:33] <robsiemb> kurt: if these names are at all leaked to users they should be internationalized
[09:37:43] <robsiemb> phillip: thats the point of the display name, so that we can have internationalization
[09:37:45] <cyrus_daboo> Hang on - mailbox name stringprep may be different than a regular text stringprep - ther are case mapping issues with mailboxes that may not be needed to random text.
[09:37:51] <randy> chris: if we have to add stringprep to get imap to DS, we can use the same for annotations
[09:38:01] <cyrus_daboo> i.e. we may need more than one strinprep profile.
[09:38:25] <cyrus_daboo> The fact is we DO need a mailbox name stringprep even now with mUTF7 encoding we currently have.
[09:38:48] <randy> but do we need it for annotate?
[09:39:41] <cyrus_daboo> ANNOTATE (and ANNOTATEMORE) do not use mailbox names in a way that is any different than other IMAP item, so its not required for those. It is neede for IMAP as a whole.
[09:39:45] <robsiemb> lisa: clarification that the annotation needs to have a unique identifier. the display name is really only needed for custom annotations
[09:40:34] <robsiemb> ned: you can register these things right? If we allow internationalization, it'll be the first IANA registery with utf-8 names (with actual entries in it)
[09:42:03] <robsiemb> randy: based on cyrus's coments it sounds like we can go with the lunch bof proposal.
[09:42:04] <robsiemb> chris nodded
[09:42:37] <cyrus_daboo> Is there any 'structure' to the displayname? Remember that entries are hierarchical.
[09:43:38] <robsiemb> chris: I have a slight preference towards using one stringprep for both annotations and mailbox names, if we go with a display name we'll need stringprep for mailboxes, and we'll have a different solution for annotations, and that is probably more code in the long run
[09:43:57] <cyrus_daboo> Remember we need stringperp for SEARCH as well, so there has to be a 'generic text' stringprep for that.
[09:44:16] <robsiemb> the room seems to feel that the display name doesn't need structure
[09:44:24] <cnewman> For SEARCH we just use comparators. It's fetching by identifier when we need stringprep
[09:46:02] <robsiemb> chris: we should really use the same solution for both identifier cases (mailboxes and annotation names)
[09:46:43] <robsiemb> joe: when you can avoid doing it, you're better off performance wise due to the tables
[09:47:26] --- leg has joined
[09:47:29] <robsiemb> chris: lunch bof proposal is simpler by itself, but overall it is more complex
[09:48:04] <robsiemb> lisa: I can see the temptation to tie them together, but we don't actually have to, they can be 2 different stringprep profiles
[09:49:05] <robsiemb> lisa: localized standarized identifers does have problems - can someone register color [french color] [spanish color] and so on
[09:49:27] <robsiemb> pete [no hat]: I think we should avoid the path of localized identifiers
[09:49:43] <robsiemb> randy: right, mailbox names are not registered, but annotations are
[09:49:48] <robsiemb> chris: lisa convinced me
[09:49:53] <robsiemb> chris: I'm on board the lunch bof
[09:49:57] <robsiemb> ned: agree
[09:50:04] <robsiemb> rough consensus!
[09:50:07] <randy> lunch bof it is
[09:50:10] <amelnikov> I agree with Lisa
[09:50:14] <cyrus_daboo> I agree with lunch BOF too
[09:50:21] <lisaDusseault> That was one of the most intelligent and careful conversations I've ever been involved in, within a WG meeting, and I'm not saying that just because I'm right :)
[09:50:50] <randy> I'm glad you thought of the reg issue now rather than after we had an updated draft
[09:51:02] <robsiemb> next issue: CATENATE has changed substantially since current ANNOTATE draft reference. now CATENATE is an extension of APPEND so ANNOTATE needs to only extend APPEND in a compatible way with CATENATE. I want to reference alexey's syntax draft for that, catenate should do same
[09:51:02] <cyrus_daboo> Do we make alexey's draft an official WG item
[09:51:07] <robsiemb> no one seems to be complaining
[09:51:33] <robsiemb> pete: it'll make a shorter last call, how fast can you have it done?
[09:51:42] <amelnikov> I can be auick
[09:51:49] <amelnikov> I meant "quaick"
[09:51:53] <amelnikov> I can't type
[09:52:02] <tonyhansen> are we ducks here?
[09:52:14] <robsiemb> pete: alexey will be high speed
[09:52:29] <lisaDusseault> A high speed duck?
[09:52:36] <cyrus_daboo> FYI ANNOTATEMORE will do the same for entry/attribute names as ANNOTATE...
[09:52:56] <robsiemb> lisa: lets see the draft before committing to making it a WG item.
[09:52:59] <amelnikov> I've submitted this monday
[09:53:43] <robsiemb> phillip: there is some other common text, we should pick one
[09:53:50] <robsiemb> (or did it get fixed already)?
[09:54:07] <cyrus_daboo> I can't remember that comment - I will go back and check the logs and ask Philip again if I can't find it.
[09:55:01] <robsiemb> lisa: looks like we want to WG last call it again.
[09:55:05] <cyrus_daboo> I can do a quick draft, but it needs to reference the new literal8 syntax in Alexey new version of extended ABNF.
[09:55:39] <amelnikov> Cyrus: wait for next revision of extended ABNF, that shouldn't take very long.
[09:55:58] <cyrus_daboo> I can post the current XML file and the new one with changes to the WebDAV space and people can also do a diff on those.
[09:56:45] <robsiemb> seems like there will be plenty of time regardless of the offical WG last call
[09:57:03] <robsiemb> lisa: so thats all for annotate. any comments on annotatemore?
[09:57:04] <amelnikov> I am afraid I need to disappear for some time...
[09:57:53] <robsiemb> kurt: you might want to add language that say you SHOULD implement localization for these
[09:57:59] <robsiemb> LISTEXT next
[09:58:00] <resnick> Can you not stay for listext, alexey?
[09:59:29] <robsiemb> philip: matchparent, placeholder, hassubmailboxes attributes were renamed
[10:00:32] <robsiemb> this all is based on the caveat that we can have LIST responses based on the context of the command that sent them
[10:00:41] <robsiemb> but the list rejected this
[10:00:52] <robsiemb> so instead we moved a lot of this into childinfo
[10:01:17] <robsiemb> barry: so if you request recursivematch, you now get childinfo coming back to identify what matched
[10:01:59] <cyrus_daboo> Hands-up from me!!
[10:02:11] <robsiemb> a few hands are up showing who read it
[10:03:18] <cyrus_daboo> The formal syntax is huge - is there anyway to simplify it a bit? When you compare it with what's in base IMAP for LIST, it really does make me concerned that this has been over-engineered......
[10:03:37] <lisaDusseault> Rob: In the past, with remote mailboxes, it was possible to send the RLIST command and get back a list of remote mailboxes.
[10:03:53] <lisaDusseault> Rob: However, this draft seems to require the server to send back a list saying which are remote.
[10:04:14] <lisaDusseault> Rob: Are there situations where the server would not flag these as remote, e.g. when the server acts as a proxy, therefore will always show the mailbox?
[10:04:38] <lisaDusseault> Barry: It's a server impl'n issue, if the server is going to present it always as a local mailbox, then it shows it as local.
[10:04:56] <lisaDusseault> Rob: As soon as the client does ask for it as a remote mailbox, then the server starts doing referrals
[10:05:28] <lisaDusseault> Philip: The current text wouldn't ban a server from doing that. It's odd, but as long as it permits a SELECT to a mailbox advertised without the remote flag, that's fine.
[10:05:57] <lisaDusseault> Philip: how the client gets the referral out of that, is its own problem.
[10:07:04] <robsiemb> lisa: cyrus, if you have suggestions to simplify the formal syntax, please share :)
[10:07:47] <cyrus_daboo> I will think about it. I am still compiling a list of issues - all pretty minor. I will post those inthe next day or so.
[10:09:14] <robsiemb> philip: some of the syntax is doing exclusion of what is semanticly valid, we may want to revisit that
[10:09:46] <robsiemb> lisa: everything was supposed to be last called in september, and 2 have, but listext hasn't
[10:10:24] <robsiemb> lisa: authors of listext: BE DECISIVE! Propose Resolutions! Open issues in a draft are just going to delay us.
[10:10:41] <robsiemb> lisa: All open issues should get a strawman
[10:11:01] <robsiemb> barry: please also give strawmen when you say "that isn't good"
[10:11:08] <robsiemb> lisa: the end is in sight!
[10:11:34] <robsiemb> Next issue: Comparator
[10:11:40] <robsiemb> lisa: I want to put chris on the spot
[10:12:03] <robsiemb> chris: I wanted to find another author, but I failed, so I will try to comit more cycles to it or find someone else (possibly a coworker)
[10:12:20] <robsiemb> chris: more nagging is helpful on this document. I am interrupt driven.
[10:12:56] <robsiemb> lisa: lets get more eyeballs on this so we can unblock everything
[10:13:58] <robsiemb> pete: There are encrypted message issues in lemonade, imapext needs to be involved in this in a very deep way.
[10:14:04] <robsiemb> scott: actually, up to your necks.
[10:14:21] <robsiemb> scott: we need volunteers to help particfipate in this effort (there will be a small team working on this)
[10:14:34] <hildjj> anyone have a link to the comparator draft?
[10:14:58] <cyrus_daboo> http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-03.txt
[10:15:08] <Barry Leiba> http://www.ietf.org/internet-drafts/draft-newman-i18n-comparator-03.txt
[10:15:14] <hildjj> thx
[10:15:20] <Barry Leiba> Well, there it is twice. :-)
[10:15:27] <robsiemb> lisa: we had a consensus in san diego of killing ACL2 if no progress by today. But we've made LOTS of progress on other areas, so do we want to extend that date?
[10:15:55] <robsiemb> scott: this is fine, but please update charter milestones
[10:16:42] <robsiemb> lisa: we will set milestones for the triplets to be done soon, and for ACL2 to be 6 months from now.
[10:18:33] <robsiemb> chris: i18n document...
[10:18:52] <robsiemb> chris: can we make the comparator for all strings in one search program/command be the same?
[10:19:13] <robsiemb> chris: is there a reasonable use case for searching case sensatively in one search criteria and not in another?
[10:19:24] <robsiemb> barry: yes, I think there is, but if we can search search results, that goes away
[10:19:47] <robsiemb> chris: I will propose a change to make the search key to set the comparator can only be set once (following charset)
[10:20:10] <cyrus_daboo> The only case where you have separate case-sens and case-insens would be with email addresses: the local part and the domain part. Perhaps we can define new SEARCH criteria to separate those and do implicit tests.
[10:20:17] <robsiemb> lisa: with the possibility of a future extension, I don't see much of an issue here, but we'll need to vet it on the list
[10:20:23] <robsiemb> philip: other protocol examples?
[10:20:44] <leg> i don't see how this complicates the implementation at all, personally.
[10:21:31] <robsiemb> pete: I heard chris say something different... [but I am backing out]
[10:21:52] <robsiemb> barry: I can see this example, but if we can search search results, then we can still do this.
[10:23:07] <robsiemb> discussion of complexity
[10:23:10] <cyrus_daboo> Right now I think I agree with Chris. If we want more complex comparator behaviour we would probably be better off redefining the search syntax entirely - perhaps something along the lines of SIEVE.
[10:23:18] <robsiemb> philip: the complexity arises if you use the same comparator on the same criteria
[10:24:30] <robsiemb> kurt: one thing you have to deal with with stringprep based preparation, you can get into undefined matching. in some cases you can't normalize.
[10:25:08] <robsiemb> kurt: you need to think about failure cases
[10:25:23] <robsiemb> chris: one advantage is that the default comparator has everything defined.
[10:26:16] <robsiemb> leg: withdrawn the objection
[10:26:33] <robsiemb> pete: chris, please send a message to arnt and the list
[10:26:36] <robsiemb> any other issues?
[10:26:42] <cyrus_daboo> I'm done...
[10:26:54] <robsiemb> lisa: thanks all!
[10:26:56] --- Barry Leiba has left
[10:26:58] <tonyhansen> so are we!
[10:27:07] --- cnewman has left: Disconnected
[10:27:08] --- Hollenbeck has left
[10:27:10] --- resnick has left
[10:27:18] --- tonyhansen has left
[10:27:24] --- dbrashear has left
[10:27:48] --- cyrus_daboo has left
[10:28:16] --- hildjj has left
[10:30:30] --- robsiemb has left: Logged out
[10:44:01] --- klensin-ietf has joined
[10:44:18] --- klensin-ietf has left
[10:44:36] --- dcrocker has left: Disconnected
[10:44:43] --- Glenn Parsons has left
[10:54:09] --- amelnikov has left
[11:04:24] --- randy has left
[11:06:26] --- leg has left
[11:20:09] --- pguenther has left
[11:27:57] --- lisaDusseault has left
[12:56:44] --- dcrocker has joined
[13:31:59] --- dcrocker has left
[13:35:17] --- lisaDusseault has joined
[14:29:49] --- wej has joined
[14:38:46] --- wej has left
[15:21:01] --- lisaDusseault has left