[03:20:26] --- arnt has left
[06:31:22] --- alexeymelnikov has joined
[07:52:45] <greg.vaudreuil> h
[08:45:36] <alexeymelnikov> Hello
[08:57:46] --- Glenn Parsons has joined
[08:58:16] <Glenn Parsons> Good day. I'll start the bridge in a couple of minutes...
[08:59:20] <alexeymelnikov> I will disconnect and reconnect in a bit
[08:59:25] --- alexeymelnikov has left
[09:00:54] --- resnick has joined
[09:01:29] <resnick> Morning
[09:02:14] --- alexeymelnikov has joined
[09:02:38] <alexeymelnikov> I can't make wireless working, so I will be jaberless
[09:02:57] <resnick> How sad.
[09:03:04] <resnick> You will phone?
[09:03:12] <alexeymelnikov> Yes
[09:03:34] --- alexeymelnikov has left
[09:04:59] <resnick> People just dribbling in.
[09:05:03] --- ams has joined
[09:06:00] --- alexeymelnikov has joined
[09:06:22] <alexeymelnikov> I moved to a different room with ethernet
[09:06:37] --- cnewman@jabber.org has joined
[09:07:30] <alexeymelnikov> Should I dial in now?
[09:08:03] <cnewman@jabber.org> Hasn't quite started yet -- they're discussing how to join the jabber room...
[09:08:37] <resnick> Eric is out in the hall figuring out his airline reservations.
[09:08:44] <resnick> We'll get started in just a few.
[09:10:15] --- pvanhoof has joined
[09:12:21] <resnick> OK, Eric is here.
[09:12:48] <resnick> In the room: Glenn, Eric, Brooke, Peter, Pete.
[09:13:06] <resnick> Still not here: Randy, Daryl
[09:13:25] <resnick> On the phone: Chris, us.
[09:13:38] <dwd> Is the phone thingy up?
[09:13:43] <resnick> Yes.
[09:13:55] <resnick> Dial in when ready.
[09:14:33] --- eburger has joined
[09:15:03] <ams> resnick: i know glenn, eric, pete (wait, not you?), randy, and chris. who are brooke, peter, and daryl?
[09:15:28] <ams> peter coates?
[09:15:32] <eburger> Sun
[09:15:36] <dwd> ams: Peter is Peter Coates, yes.
[09:16:30] <resnick> Brooke is from RIM.
[09:17:29] <resnick> Daryl is a solo human from somewhere.
[09:18:12] <dwd> Ah, a solo human. I was one of those once.
[09:19:08] --- peter has joined
[09:20:09] <resnick> Who is ams?
[09:20:23] <ams> ams = Abhijit Menon-Sen <ams@oryx.com>
[09:21:39] <resnick> And Randy has now arrived.
[09:21:55] <cnewman@jabber.org> #include <http://www.ietf.org/maillist.html> (note well)
[09:22:20] --- peter has left
[09:22:46] <cnewman@jabber.org> How is beautiful Mississauga this morning?
[09:22:50] <eburger> Sunny
[09:22:53] --- peter has joined
[09:24:37] --- brooke has joined
[09:24:59] <eburger> Anyone lifting a pint for Norwegian Constitution Day?
[09:25:02] --- randy has joined
[09:25:08] <dwd> eburger: Arnt is, presumably.
[09:25:11] --- ams has left
[09:25:11] --- ams has joined
[09:25:19] --- peter has left
[09:25:28] <dwd> eburger: Although he's presumably lifting bottles of Linnie instead.
[09:25:34] <eburger> :-)
[09:25:48] <ams> (those things are tiny.)
[09:25:51] <eburger> PROPOSED AGENDA:
[09:25:57] <eburger> IMAP CONVER
[09:25:57] --- peter has joined
[09:26:03] <eburger> (IMAP CONVERT)
[09:26:06] <eburger> NOTIFICATIONS
[09:26:10] <eburger> PROFILE BIS
[09:26:27] <eburger> RUN-THROUGH OF LIST AT http://www.standardstrack.com/ietf/lemonade
[09:26:33] <eburger> Sound bashed?
[09:26:37] <eburger> Anything else?
[09:27:30] <alexeymelnikov> Seems fine to me
[09:29:04] <resnick> I guess I am attempting to jabber again today.
[09:29:12] <resnick> CONVERT:
[09:29:14] <pvanhoof> joined
[09:29:29] <resnick> Alexey: Zoltan suggested remove strict
[09:29:41] <eburger> IMAP CONVERT - Removal of .STRICT specifier - IANA registry for transcoding parameters - Use of METADATA extension or defining ad-hoc commands for requesting possible conversions and associated parameters
[09:29:50] <resnick> (thank you)
[09:31:56] <eburger> Pete: obvious to take multipart/mumble to a single thing. However, he thinks it is also interesting to consider taking something *to* multipart/mumble
[09:32:02] <cnewman@jabber.org> An interesting data point on multiparts -- some SIP documents didn't allow multiparts and apparently now people are trying to stuff additional parts in headers using the data URL.
[09:32:17] <eburger> Once it gets converted, can you get BODYSTRUCTURE?
[09:32:22] <eburger> Alexey: "no."
[09:33:57] <randy> Pete wants to be able to convert to a multipart
[09:34:14] <randy> and then be able to refer to subparts of the converted multipart
[09:34:20] <eburger> Wants ability to refer to a converted body part in an IMAP URL, so he can CATENATE it and refer to it.
[09:34:30] <eburger> CONVERT.mumble (...)
[09:35:14] <randy> Pete proposes two ways: add syntax to CONVERT to access converted multipart parts, or add to URLFETCH so that a converted multipart can be stored using CATENATE
[09:35:34] <cnewman@jabber.org> What about type parameters like text/plain;format="flowed" or multipart/related;type="text/html"?
[09:35:43] <eburger> Why? for security multiparts
[09:35:58] <eburger> Use it to CONVERT in order to decrypt something
[09:37:48] <cnewman@jabber.org> Convert PDF to multipart/related;type="text/html"?
[09:37:49] <eburger> Is there a use for converting something to a MIME multipart, and then treating that as a message (part) itself?
[09:38:05] <eburger> Or, use it to explicitly decrypt a multipart?
[09:39:13] <eburger> If all you wanted was to decrypt, why not just decrypt part directly?
[09:39:45] <eburger> E.g. leaf node is Word or PDF; convert to multipart/related and add text/ part?
[09:40:25] <eburger> Alexey: can get there using CONVERT with conversion parameters
[09:40:49] <eburger> Proposal: don't do it now; plan on extension in future, if need is real
[09:41:02] <eburger> Need separate extension (possibly) for passing keys, etc.
[09:42:22] <eburger> Pete: wants to at least make sure the current syntax will be amenable for such a future extension
[09:43:22] <eburger> Pete will send message to mail list.
[09:43:42] <eburger> Glenn: Is the premise the body part will have been converted already into a multipart, and thus how to deal with it?
[09:43:54] <eburger> Pete: result of the convert is a multipart/mumble
[09:44:20] <eburger> Once result is a multipart, how does one address the parts?
[09:46:37] <eburger> Wants to be able to refer to result as an IMAP URL. Traversing object would be "nice," but that can happen in the future.
[09:49:30] <eburger> IMAP URL: fragments (foo#frag) is server local and not part of IMAP URL.
[09:50:16] <eburger> Use cases for accessing leaves is a bit "out there," with the exception for decryption.
[09:50:50] <eburger> Pete will check to make sure ABNF in IMAP URL and CONVERT will allow for the possibility for an IMAP URL to refer to a converted object.
[09:52:41] <eburger> Reality is server will have to cache it; however, will that be client-visible?
[09:53:20] <eburger> Back to whether we will depend on METADATA or something ad hoc.
[09:53:35] <eburger> Argument against METADATA: way easier for client writers to implement.
[09:54:18] <resnick> Peter: Concern that METADATA is becoming a hammer to everything as nail.
[09:55:17] <resnick> Eric: We want it to be easy to implement, but we want to do the right thing. If METADATA is right, let's do it.
[09:55:40] <resnick> Alexey: In all cases, ad hoc comes out better than METADATA.
[09:56:37] <resnick> Alexey: E.g., for stored searches, could store it, or refer to it in CONVERT.
[09:56:43] <resnick> (Did I get that right?)
[09:56:46] --- Darryl Champagne has joined
[09:57:37] <resnick> Peter: We don't need to standardize the client METADATA stuff now.
[09:57:46] <resnick> Not tied to this document.
[09:58:21] <resnick> Alexey: It would be great to do a profile-ter. Does this mean punt for now?
[09:59:07] <resnick> Peter: Sure, but using the output of a METADATA item put back into a command has come up multiple times. Perhaps we want a general solution.
[09:59:51] <resnick> Randy: Could use an extension to literal that refers to a METADATA item.
[10:01:23] <resnick> Peter/Randy: What you really want is a general macro facility.
[10:01:44] * resnick prepares to cut his wrists
[10:02:51] --- cyrus_daboo has joined
[10:05:22] <resnick> Pete: Ad hoc seems fine.
[10:05:45] <resnick> Alexey: Notification preference is another possible use of METADATA. Search criteria.
[10:07:21] <resnick> Some months ago, Cyrus and Ken were in favor of using METADATA for all of this kind of thing. Alexey and Dave weren't.
[10:07:35] <resnick> (on IMAPEXT)
[10:08:35] <resnick> Randy/Peter: Could be an extension to CAPABILITIES (or CONVERT for that matter)
[10:09:35] <resnick> Dave: Do what HTTP does.
[10:09:47] <peter> peter might cut his wrists too
[10:11:09] <resnick> Alexey/Peter: You wouldn't want to put this all in the CAPABILITIES return string.
[10:12:11] <resnick> Randy: Extend CAPABILITY CONVERT blah blah blah
[10:12:43] <resnick> Chris: Any use for entry match in this thing?
[10:12:43] <randy> or more generally CAPABILITY <extension-name> <extension-parameters>
[10:12:59] <Darryl Champagne> [As an aside, I see a question about me - RE: Darryl Champagne - I am with Funambol, http://www.funambol.com/ , which focuses on mobile email, PIM Sync, and device management software, primarily open source.  I am active in OMA, primarily a lurker here.]
[10:13:55] <randy> Welcome Darryl
[10:14:17] <randy> Are you doing a lemonade client to go along with the Synch client?
[10:14:17] <resnick> Chris: If you need wildcards, adding a new wildcard mechanism is additional complexity. METADATA already has a wildcard mechanism.
[10:15:54] <resnick> Randy: Which command is irrelevant to the client.
[10:16:44] <resnick> Alexey: If you're going to have to search these things, METADATA would be more useful.
[10:16:47] <Darryl Champagne> <reply to randy> Umm, an official "no comment" at this time.  Interested in suggestions on testing both client and server, primarily an off-line conversation, no current actual IOP plans.
[10:18:27] --- arnt has joined
[10:18:56] <resnick> Pete (channeling server people): Requiring METADATA implies implementing all of METADATA, which might be bad.
[10:19:09] <resnick> Peter: This also means a special case of METADATA.
[10:19:33] <randy> Darryl: lemonade has conducted interop events in the past, and intends to do so again. You might want to contact vendors and see if you can bilaterally cooperate on testing against each other's products
[10:19:41] <ams> (oh no. not *more* wildcards.)
[10:20:20] <resnick> Randy: It's also a precedent issue.
[10:23:15] <resnick> Alexey: Leave it as METADATA and call it out at last call.
[10:23:25] <resnick> Next topic: Removal of .STRICT.
[10:24:09] <eburger> Do we allow for optional parameters?
[10:24:25] <eburger> Zoltan (through Alexey): he always knows what parameters there are and how they affect the output.
[10:25:16] <eburger> Question is: client can request knowledge of its screen size; that might allow server to crop, scale, scale assymettrically to fit screen, etc.
[10:25:42] <eburger> This is a conversion parameter, as it specifies how conversion will go
[10:25:48] <Darryl Champagne> Not ready to test anything.  I would say my focus is more on exploring the technology at this point, understanding flows, scalability issues, etc..
[10:26:54] <eburger> separate discussion on client just leaving parameters blank, allowing server to fill it in
[10:27:19] <Darryl Champagne> Thx
[10:27:28] <eburger> Peter: what happens if client over-specifies?
[10:27:33] <eburger> conversion request will fail.
[10:27:56] <randy> or under-specifies (leaves off some parameters)
[10:29:26] <randy> Peter: how is server supposed to know what is best for client?
[10:29:45] <randy> Eric: server knows because it has a database of client device and firmware specific capabilities
[10:31:19] --- ams has left
[10:31:19] <cyrus_daboo> What if my device has the ability to use other hardware for display, sound etc? i.e. an hookup for external monitor?
[10:31:38] <cyrus_daboo> The hard-coded device capabilities mean nothing in that case.
[10:36:06] <Darryl Champagne> Except a hard coded device capabilities store would include if the external display capability was supported, and it would know that some dynamic information is required.
[10:38:54] <randy> I think Cyrus' example shows why server-based databases are fundamentally limited
[10:39:03] <randy> in an era of dynamic device capabilities
[10:42:48] <Darryl Champagne> It depends upon the target audience.  E.g. its a US Carrier, that only allows these 15 phones... Not saying that's what should be done, just saying that in some environments, if some parameters are unspecified, server may want to provide defaults.
[10:44:25] <cyrus_daboo> Defaults is fine, but there must be a way for clients to override, and clients SHOULD do that for most/many parameters.
[10:44:48] <cyrus_daboo> Plus the server's defaults ought to be advertised somewhere.
[10:44:57] <pvanhoof> I agree, I first want to tell the server to do this
[10:50:20] <resnick> Randy/Darryl: The server should be able to guess if the client doesn't specify, but the server should never override.
[10:50:30] <pvanhoof> Very interesting for HTML e-mails would be, for a mobile, to get a mime-part uudecoded/base64 decoded and converted from JPEG (whatever) to PNG
[10:50:55] <pvanhoof> Right now a image components can't (yet) display a base64 image without first in-memory fully converting it
[10:51:00] <pvanhoof> so that's two copies in memory
[10:51:17] <pvanhoof> But a converted mime part as base64, that's as-useless
[10:51:30] <alexeymelnikov> Philip: you want CONVERT+BINARY, which is described in the CONVERT document
[10:51:35] <pvanhoof> yep
[10:51:51] <pvanhoof> I'll read that one :)
[10:51:59] <alexeymelnikov> It works something like BINARY[<section>.CONVERT]
[10:52:08] <alexeymelnikov> Please :-)
[10:52:24] <pvanhoof> Anyway, this is a lot of specification (which types to convert, etc etc)
[10:52:32] <pvanhoof> Though very useful for mobiles
[10:53:30] <alexeymelnikov> Pete: I think we need a conversion parameter "strip unknown characters" for text/* conversions
[10:53:52] <pvanhoof> What about a convertion from text/html to text/plain (links like)
[10:54:00] <pvanhoof> A lot mobiles don't have a html component
[10:54:12] <pvanhoof> Anyway, I should first read that rfc
[10:54:15] <pvanhoof> or drat
[10:54:18] <pvanhoof> draft
[10:54:34] <pvanhoof> -- though, it's screen-size specific how to convert
[10:54:43] <randy> Really? I thought it's pretty common for mobiles to have some sort of html rendered these days?
[10:55:02] <pvanhoof> randy, depends on the device
[10:55:08] <eburger> (html rendering): only on very high-end phones, and usually in a separate application
[10:55:29] <pvanhoof> HTML also consumes a lot ram (yes, still)
[10:55:40] <randy> so there might be phone with a lemonade client but no html renderer?
[10:55:45] <pvanhoof> Gecko: 5 mb static (that you can't get rid of)
[10:55:54] <pvanhoof> randy, yes
[10:56:56] <cyrus_daboo> If it has image capabilities then you can draw the html to and image and send that to it. You won't get clickable links but will get a faithful rendition (at least what can be squeezed on a small screen).
[11:00:30] <pvanhoof> ...
[11:00:37] <pvanhoof> I wouldn't like that solution
[11:00:58] <pvanhoof> More memory, more bandwidth (if the server converts it), less functionality
[11:01:21] <pvanhoof> and a lot people are blind or handicaped and make their phone read the text and things like that
[11:01:43] <pvanhoof> But, anyway. offtopic :)
[11:01:59] <cyrus_daboo> Actually an image of an html page maybe smaller than the actual HTML itself. If you consider all the CSS and markup adds a lot of overhead.
[11:02:08] <pvanhoof> True
[11:02:28] <dwd> Pete: Actually, JPEG doesn't have to be lossy, if we're going to nitpick - setting the quality value to maximum shouldn't drop anything.
[11:03:09] <pvanhoof> Letting a service convert, note that the X11 Clipboard works like this too. We might want to take a look at the problems that this introduces and has
[11:07:26] <Darryl Champagne> Also note that no matter how much the state of the art progresses, there are new low end things created as the costs go down and more things become possible - e.g. next my watch will support a scrolling one line display of incoming SMS, and then email subjects or icon size images (even if I have to go read it somewhere else).
[11:07:46] <pvanhoof> indeed
[11:08:29] <pvanhoof> Look at ePaper, converting movie-attachments wouldn't make sense for such devices (3 seconds refresh time per screen redraw) (again, offt)
[11:08:45] <pvanhoof> listening ... :)
[11:09:42] <alexeymelnikov> Chris suggested a new parameter for "use my device ID to optimize conversion"
[11:09:57] <alexeymelnikov> This was already on my todo list
[11:10:18] <pvanhoof> Register devices on the service?
[11:10:41] <alexeymelnikov> Yes
[11:11:18] <pvanhoof> I don't know why, sounds like a bad idea to m.. (I'm going to read the draft now)
[11:11:50] <alexeymelnikov> There is no explicit registration
[11:11:59] <alexeymelnikov> And this parameter is not in the draft at the moment
[11:12:04] <pvanhoof> ok
[11:12:51] <pvanhoof> "I am any device, I want you to convert these a's to these b's" right after the capability
[11:15:23] <pvanhoof> ok, scanned the draft
[11:15:26] <randy> Randy and Pete agree on adding USEDEVICEINFO
[11:15:54] <randy> as explicit permission to the server to perform any additional conversions and parameters that it feels may be helpful
[11:16:05] --- ams has joined
[11:17:07] <randy> In the absence of this flag, the server may still do a conversion even if the conversion is lossy and even if some information is necessarily thrown away because of the conversion
[11:17:23] <resnick> IANA registry
[11:17:40] <randy> but in the absence of this flag, the server should not take it on itself to do extra conversions to try and be "helpful"
[11:18:51] --- eburger has left: Replaced by new connection
[11:18:56] <resnick> Conneg registry is not 100% fit, but it's probably close enough.
[11:19:12] <resnick> Might need to add some extra stuff, or create a subtree.
[11:19:16] <resnick> Preferences?
[11:19:24] <resnick> Glenn: Where would STI params go?
[11:19:34] <resnick> Alexey: We'd have to add them to the conneg registry.
[11:19:52] <resnick> Chris (as AD): If you choose not to use conneg, you better give a good justification.
[11:20:16] --- eburger has joined
[11:21:41] <resnick> Glenn: What specifically needs to go in conneg registry?
[11:22:05] <resnick> Alexey: STI, DEVICEID, USEDEVICEINFO.
[11:22:26] <resnick> Alexey: Prefer not to put them in the document. Should be a separate effort.
[11:26:52] <resnick> Need a mapping of STI parameters into conneg.
[11:29:30] <resnick> Chris: May want to use RFC 2913 syntax for media types rather than IMAP syntax in CONVERT.
[11:32:10] <alexeymelnikov> Chris wants things line format=flowed on text/plain conversion
[11:33:22] <resnick> C: b001 FETCH 2 BODY[3.CONVERT ("text/plain" ("format" "flowed"))] S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("text/plain" ("format" "flowed"))] ("TEXT" "PLAIN" ("format" "flowed") NIL NIL "Base64" 2135 181 NIL NIL NIL) BODY [3.CONVERT ("text/plain" ("format" "flowed"))] {2135} <the document in text/plain format with format flowed> ) S: b001 OK FETCH COMPLETED
[11:35:34] <resnick> Chris/Alexey: The above is fine, but you'd need to register "format".
[11:36:18] <resnick> Pete: Then leave the syntax and do the registrations.
[11:36:23] <resnick> Chris: That's an OK answer.
[11:36:35] <resnick> Alexey: 2913 does allow logical expressions.
[11:37:19] <resnick> Chris: If you want all of the media features algebra, then you get more power (and would want to use 2913).
[11:37:58] <resnick> Alexey: Let's not do the entire algebra unless there's a good reason to do so.
[11:38:47] <resnick> Peter: If I've got 3rd party converters, and they know algebra, I might want to pass them along.
[11:39:15] <resnick> Alexey: We could add algebra as a separate parameter. (1/2 :-) )
[11:39:55] <resnick> Peter: Is anyone implementing this stuff?
[11:40:34] <resnick> Many: Was designed for FAX. Don't know of any generic converters that implement 2913.
[11:41:20] <resnick> Alexey: Ted mentioned that SIP folks might be doing something similar.
[11:48:28] <resnick> 15 minute break.....
[11:51:54] --- brooke has left: Replaced by new connection
[11:52:10] --- brooke has joined
[12:05:40] --- brooke has left: Replaced by new connection
[12:05:40] --- brooke has joined
[12:08:15] <cnewman@jabber.org> Just rejoined the call after break. I gather there's discussion of quoted pairs?
[12:09:35] <randy> It was a side-discussion of message-id
[12:09:35] <dwd> Ah, we're back on?
[12:09:41] <randy> in 2822 bis and usefor
[12:10:27] <pvanhoof> listening
[12:14:16] <resnick> Back on agenda
[12:15:05] <randy> Drafts is
[12:15:06] <pvanhoof> ok
[12:15:17] <resnick> Trying again.....
[12:15:23] <Glenn Parsons> http://www.ietf.org/internet-drafts/draft-ietf-lemonade-notifications-04.txt
[12:15:35] <randy> Draft is draft-ietf-lemonade-notifications-04.txt
[12:15:56] --- brooke has left: Replaced by new connection
[12:15:56] --- brooke has joined
[12:17:58] <resnick> Randy: The draft would benefit from more than a simple rewrite.
[12:18:06] <resnick> Randy: I haven't had time to do that.
[12:18:24] <alexeymelnikov> The document needs *lots* of work
[12:18:43] <dwd> I've got to go for a bit - if I'm wanted, remind Alexey to drop me a text message and I should be able to reappear.
[12:20:30] <resnick> Glenn: We did this round-about Vancouver to straighten out our confusion of notifications vs. filters.
[12:20:37] <resnick> Glenn: That's still useful.
[12:21:27] <resnick> Randy: All of those conceptual differences are useful to point out, perhaps earlier in the document.
[12:22:01] <resnick> Glenn: The meat of the document hasn't moved with the rest of the wg work.
[12:22:50] <resnick> Peter: What's this stuff for?
[12:22:58] <resnick> Randy: Client notifications.
[12:23:32] <resnick> Randy: Internal server notifications are out of scope.
[12:26:15] * resnick munches .. typing in a moment
[12:27:21] <resnick> Randy: This should be a lightweight mechanism to give the client hints to retrieve data. Not enough in the notifications to keep the entire client in sync.
[12:29:02] <resnick> Peter: The client can't use the notifications to keep a state. The notification must carry the state.
[12:29:29] <randy> Lightweight meaning doesn't need reliability nor encryption
[12:31:14] <resnick> Chris (qua AD): Client notifications are out-of-charter.
[12:33:02] --- brooke has left: Replaced by new connection
[12:33:02] --- brooke has joined
[12:34:13] <resnick> Possible e-mail notifications BOF in Chicago.
[12:34:38] <resnick> Eric (qua Chair): We don't have energy for client notifications, even if it were in charter.
[12:35:10] <resnick> Can say in profile "There are mechanisms for client notifications".
[12:39:57] <resnick> Randy: Not working on this document would leave a big hole in the architecture.
[12:44:18] <resnick> Pete: Item 0 in the charter allows us to discuss architecture in an informational document.
[12:44:48] <resnick> Eric: Architecture could have (non-normative) pointers to examples (e.g., MWI)
[12:45:45] <alexeymelnikov> What is the status of this document as far as Lemonade Profile Bis is concerned?
[12:48:15] <resnick> Peter: Could have an informational document specifying what gets passed around between servers.
[12:48:26] <resnick> Chris: Isn't that the message events document?
[12:48:47] <resnick> Peter: Yeah, but might need to be expanded.
[12:49:54] <alexeymelnikov> I think IMAP NOTIFY is more or less in sync with MsgEvents now
[12:50:15] <resnick> Randy: But we can publish now and extend later.
[12:50:17] <alexeymelnikov> I know there are some minor bugs in IMAP NOTIFY, but the intention is to fix them
[12:51:39] <resnick> Peter: IMAP NOTIFY is not the only consumer of msgevents, and we should put the info for server notification into msgevents.
[12:52:29] <resnick> Peter thereby volunteers to provide text for an update to msgevents.
[12:53:16] <resnick> Glenn will help Randy work on notifications document.
[12:53:35] <resnick> Chris: Randy should go talk to Lisa about the document.
[12:54:05] <randy> Glenn will help Randy with the existing notifications document, to mold it into the architecture document we need
[12:54:07] <resnick> Last topic for the day: Status review.
[12:54:17] <alexeymelnikov> Should I SMS Dave C. to come back now?
[12:54:44] <randy> Glenn and Randy will talk to Lisa about the notifications architecture
[12:55:07] <resnick> Alexey, please ping Dave.
[12:56:33] <resnick> Randy on Deployments draft.
[13:01:15] --- brooke has left
[13:01:17] <alexeymelnikov> I think we getting into Nomcom-type feedback on Cullen
[13:04:06] * resnick whines about Cullen's discuss on Deployments and the general ills of the world
[13:04:26] <resnick> Chairs and Randy will talk with Chris about how to move through the discuss.
[13:04:57] <resnick> reconnect-client
[13:05:15] <resnick> Alexey: New revision coming to deal with comments.
[13:06:11] --- ams has left
[13:06:17] <resnick> search-within - Need e-mail to confirm changes without having to do another WGLC.
[13:08:03] <resnick> reconnect-client - confirmed that this replaces reconnect.
[13:09:04] <resnick> firewall-binding and tcp-challenged-environments: Do these need to be progressed?
[13:09:08] <alexeymelnikov> I personally don't want to progress it
[13:09:27] <alexeymelnikov> But I am fine with deferring doing it later, if we have to
[13:09:53] <resnick> Silence pervades the room.
[13:10:33] <resnick> Deployments says, "http ain't lemonade", so that's enough.
[13:11:17] <cnewman@jabber.org> http://www.ietf.org/u/ietfchair/discuss-criteria.html
[13:12:46] <resnick> xencrypted - Much nausea in the room.
[13:15:54] <resnick> Alexey, are you still on the line?
[13:18:06] <resnick> Possibility that we could use CONVERT to do this sort of thing.
[13:21:28] <randy> Chairs suggest new document to extend CONVERT to pass a public key and have the server encrypt the body part
[13:21:45] <randy> Question as to if this is needed now, or if it can wait
[13:21:48] <alexeymelnikov> Pete: I like what you said
[13:22:03] <randy> Pete suggests waiting and do a more general encrypt/decrypt document
[13:22:10] <alexeymelnikov> I.e. delay dealing with encryption till later, but it will be done in Lemonade WG
[13:23:40] <cyrus_daboo> Its more complex than CONVERT. What I would like is to ask the server to decrypt and send me the ENVELOPE/BODYSTRUCTURE of the decrypted message, then do FETCH's on he decrypted structure!
[13:24:03] <resnick> Yes, that's what we were discussing earlier.
[13:24:24] <cyrus_daboo> OK sorry missed that.
[13:25:01] <resnick> No problem. That was just my earlier discussion on the CONVERT document.
[13:25:21] <resnick> But that's what I'm hoping we can combine with the encrypting thing.
[13:25:42] <resnick> - Now going through the active documents
[13:25:50] <resnick> convert - wait for next draft.
[13:28:23] <resnick> imap-sieve - Perhaps a co-editor is needed.
[13:29:49] <resnick> notifications - new draft (work with Lisa, etc.)
[13:30:27] <resnick> 2192bis - revision by monday
[13:32:06] <resnick> streaming - needs a SIP reviewer
[13:32:15] <resnick> Eric will do so.
[13:32:52] <resnick> context - Dave will do one more revision; possible comments from Zoltan and one other person.
[13:33:56] <resnick> notify - reivew -07 and do a WGLC on -08. rename to wg.
[13:37:28] <resnick> enable - dealt with yesterday
[13:38:09] <resnick> imapext-filters - will try to get feedback from client writers and decide later whether to put it in profile-bis
[13:38:36] <resnick> profile-bis:
[13:38:59] <resnick> Randy: Still issue on whether to include quickstart
[13:39:38] <resnick> Alexey: Agreement to add SORT and ENABLE
[13:40:33] <resnick> Alexey: Also imap-filters, and there is some missing features/text (e.g., new CAPABILITY for partial URLs)
[13:42:00] <resnick> Dave will do an update of profile-bis.
[13:43:00] <resnick> Two slots requested for Chicago.
[13:44:23] <resnick> People should start thinking about an interop between Chicago and Vancouver.
[13:44:43] <randy> That is, in the August-November time period
[13:47:16] <resnick> Concluded.
[13:47:26] --- randy has left
[13:47:34] <alexeymelnikov> See you in Chicago
[13:47:39] <resnick> Thanks.
[13:47:49] <alexeymelnikov> I wouldn't thank you for the dinner ;-)
[13:49:40] --- resnick has left: Replaced by new connection
[13:50:58] --- peter has left: Computer went to sleep
[13:54:47] --- Glenn Parsons has left
[13:56:13] --- alexeymelnikov has left
[14:03:02] --- eburger has left
[14:08:13] --- Darryl Champagne has left
[15:15:01] --- cyrus_daboo has left
[17:10:31] --- cnewman@jabber.org has left
[17:55:06] --- pvanhoof has left