[11:47:13] --- resnick has joined
[11:47:38] --- Glenn Parsons has joined
[11:48:02] * Glenn Parsons has set the topic to: IETF 68.5 - LEMONADE interim
[11:48:04] --- greg.vaudreuil has joined
[11:48:28] --- arnt has joined
[11:48:36] <arnt> mean?
[11:48:41] <Glenn Parsons> Now serving lunch....
[11:48:52] <Glenn Parsons> for those in the room.
[11:48:55] --- alexeymelnikov has joined
[11:49:04] <arnt> who invited me?
[11:49:06] <Glenn Parsons> I'll start the audio bridge in ~10 minutes
[11:49:28] <arnt> glenn - should I phone in, stay on jabber or both?
[11:49:44] --- dwd has joined
[11:49:54] <Glenn Parsons> I suggest both at least at the outset...
[11:50:02] <alexeymelnikov> Agreed
[11:50:18] <arnt> then so I shall do. just let me get a new bottle of water.
[11:50:26] <resnick> I invited you Arnt.
[11:50:47] <resnick> iChat makes it easy.
[11:50:57] <dwd> If someone could email me some of the food, that'd be great.
[11:51:32] --- DarrylChampagne has joined
[11:51:34] <alexeymelnikov> Yes, food-over-lemonade would be great
[11:51:55] <dwd> I think there's a media type for solid objects.
[11:52:21] <alexeymelnikov> Dave, stop discussing CONVERT now ;-)
[11:52:38] --- cyrus_daboo has joined
[11:52:38] <cyrus_daboo> Just a sec.
[11:52:42] <arnt> CONVERT? CONVERT? wasn't there something... uh...
[11:53:01] <alexeymelnikov> Hi Cyrus
[11:53:10] <arnt> we want profile-bis to reference CONVERT! RFC 1428!
[11:53:24] <cyrus_daboo> Hi - sorry forgot this was happening - still catching up after last week's calconnect.
[11:53:37] <dwd> Ah, here we are. RFC1437. Mandatory for Lemonade, then?
[11:55:32] <alexeymelnikov> On a more serious note: have you read the proposed agenda?
[11:55:36] <arnt> dave: 1437 is the only april rfc that fooled me for longer than the abstract. I did something like 'grep -lw mime rfc14??.txt' and read all the MIME RFCs at a stretch. that one followed just after the last legit one.
[11:57:08] --- eburger has joined
[11:57:21] <eburger> I'm here, too.
[11:57:37] <dwd> I'm here, but not there.
[11:58:36] <resnick> We'll get you sound after Glenn finishes munching.
[12:00:30] --- Glenn Parsons has left: Replaced by new connection
[12:00:30] --- Glenn Parsons has joined
[12:00:38] <resnick> We're on the phone.
[12:01:29] --- pguenther has joined
[12:01:38] <alexeymelnikov> Hi Philip
[12:01:44] * pguenther drags himself in
[12:03:57] <resnick> Everyone got the numbers to dial in?
[12:04:04] <resnick> http://standardstrack.com/ietf/lemonade/
[12:04:35] <arnt> I dialled the number closest to me. I think that's actually more expensive that dialling a number across the pond.
[12:04:54] --- Anil_Srivastava has joined
[12:05:25] <dwd> I'm going to delay dialling in for a bit, due to small children running about the place.
[12:05:42] <resnick> Right.
[12:05:50] <resnick> At the moment, all you will hear is chewing.
[12:05:53] <arnt> dave needs a door which is difficult to open.
[12:06:07] <eburger> New materials posted at http://www.standardstrack.com/ietf/lemonade/
[12:06:16] <eburger> Look for agenda and slides links under meeting materials.
[12:06:36] <eburger> sorry for PDF, but I had a Word "opportunity"
[12:06:41] <eburger> (agenda is simply document list)
[12:06:43] <dwd> Arnt: ACtually, mine have no handles thanks to some building work, but the trouble is they're jumping off the beds in the room above my head... :-)
[12:07:53] <arnt> if we're not doing lemonade work, can we do some help-arnt work?
[12:08:30] <arnt> I need an adapter to plug an old serial mouse into a ps/2 plug. difficult to find in the shops now that even the second most recalcitrant oldtimer has given up his old mouse.
[12:08:37] * pguenther leans his crutches against the wall and settles into a cup of coffee
[12:08:38] <arnt> do any of you have such a thing lying around?
[12:09:25] <arnt> not? no hope?
[12:09:41] <arnt> maybe I have to purchase a new mouse. I don't want to.
[12:10:02] <alexeymelnikov> So conservative :-)
[12:10:33] <arnt> alexey, if you'd recover from severe wrist problems, you'd be conservative too ;)
[12:10:39] <pguenther> your old serial mouse probably has an actual rolling thing inside it
[12:10:50] <arnt> yes it does
[12:11:09] <pguenther> keep it so you can convince your kids that they actually did that
[12:11:09] <arnt> and it had a serial number, but that has faded away.
[12:11:40] <resnick> Pasting Alexey's suggested agenda:
[12:11:42] <resnick> My take on the agenda for the Interim meeting:Wednesday 16:Quick status of several drafts:1) draft-cridland-imap-context-02.txt2) draft-ietf-lemonade-streaming-02.txt - Volunteer for URLAUTH extension?3) draft-ietf-lemonade-search-within-04.txt - confirm WG consensus on Dave's text.4) draft-ietf-lemonade-rfc2192bis-06.txt - Do we need a syntactic extension for "must use STARTTLS" (in this document or in a separate one)? - two minor open issues (a separate email was just sent)5) draft-ietf-lemonade-msgevent-02.txt - Make MailboxSubscribe and MailboxUnSubscribe a single event with boolean parameter? - Should the document describe how ACLs are to be returned - Naming of events (e.g. MessageExpunge instead of ExpungeMessage)ENABLE - is it part of Lemonade Profile Bis?draft-melnikov-imapext-filters-01.txt - is it part of Lemonade Profile Bis?IMAP NOTIFY (currently draft-gulbrandsen-imap-notify-06.txt)- Arnt and/or myself will send a list of open issues separately. -06 is getting close to be done, but we need to wait for at least -07 before starting WGLC. There would be some syntactic changes between -06 and -07.Thursday 17th: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 parametersdraft-ietf-lemonade-notifications-04.txtAny other businessDoes this seem reasonable?Alexey
[12:12:08] <alexeymelnikov> This doesn't format very well in Exodus
[12:13:33] <resnick> I will try to be jabberish.
[12:13:41] <arnt> jabberish?
[12:13:49] <resnick> Peter will try to take minutes (as against seconds).
[12:14:13] <resnick> (As in I'll be Jabber scribe, Peter will be minutes taker.)
[12:14:21] <pguenther> mmmmm, seconds...
[12:14:24] <alexeymelnikov> Peter Coates?
[12:14:35] <eburger> correct
[12:14:36] <Anil_Srivastava> I think that is Peter Coates..
[12:14:40] --- DarrylChampagne has left
[12:14:55] <resnick> Present in the room:
[12:15:04] <resnick> Eric Burger
[12:15:09] <resnick> Glenn Parsons
[12:15:19] <resnick> Peter Coates
[12:15:23] <pguenther> alexey's agenda doesn't include reconnect-client
[12:15:28] <resnick> Pete Resnick
[12:15:38] <pguenther> should we discuss chris's comments at some point?
[12:15:42] <alexeymelnikov> Philip: it doesn't because I am not sure what to discuss yet
[12:15:50] <alexeymelnikov> Tomorrow?
[12:15:57] <pguenther> probably wise
[12:16:00] <resnick> Darryl Champagne
[12:16:26] <resnick> Brooke Hayes
[12:16:41] <resnick> (Randy Gellens in town but not yet in the room)
[12:16:56] <resnick> In the jabber room:
[12:17:07] <resnick> Dave Cridland
[12:17:12] <resnick> Cyrus Daboo
[12:17:17] <resnick> Phil Guenther
[12:17:24] <resnick> Arnt Gulbrandsen
[12:17:35] <resnick> Alexey Melnikov
[12:17:44] <resnick> Greg Vaudreuil
[12:17:46] <alexeymelnikov> I am impressed with the number of usual suspects participating
[12:18:15] <resnick> Anil Srivastava
[12:18:30] <resnick> Alexey, are you on the phone?
[12:18:36] <alexeymelnikov> Not yet
[12:18:49] <alexeymelnikov> Should I phone in?
[12:19:03] <resnick> Please do. We are starting.
[12:19:13] <arnt> only 25 minutes late?
[12:19:20] <alexeymelnikov> I need to move my computer, but then I will lose all my terminal sessions, etc.
[12:19:21] <arnt> that's disastrous. close the group at once!
[12:20:20] <arnt> philip wants his name written in Fraktur.
[12:20:38] <resnick> On the phone:
[12:20:57] <resnick> Alexey, Arnt, Anil, Phil
[12:21:04] <resnick> http://standardstrack.com/ietf/lemonade/
[12:25:56] <resnick> Starting with search-within
[12:26:29] <resnick> Alexey: Dave suggested text
[12:26:43] <resnick> Eric: How do you know it's dynamic?
[12:26:56] <resnick> Alexey: Use vfolder or context and use search-within there.
[12:27:31] <resnick> Eric: Dave's right; if you're doing a static search, there's no reason not to be exact.
[12:28:03] <resnick> Eric: In the dynamic search, the server should tell you "I support within, and if you're using dynamic, I'll tell you the accuracy"
[12:28:48] <resnick> Arnt: If you have older-yougers, it's going to be really icky.
[12:29:12] <resnick> Eric: Even if you do specify the behavior, it's going to be weird to the user.
[12:30:02] * resnick tries to figure out what exactly of this I'm going to type
[12:30:22] <resnick> Randy Gellens has arrived.
[12:31:51] <resnick> Eric: Plea to client writers or customer people: If the server doesn't tell the user when they can expect their updates to happen, would they care?
[12:32:21] <resnick> Eric: If I say, "Give me everything less than an hour old", do I have expectations about when new messages show up or old messages disappear.
[12:32:41] <resnick> Arnt: I can put a refresh interval into the server config file.
[12:33:56] <resnick> Alexey: This is really a QoS issue.
[12:34:56] --- DarrylChampagne has joined
[12:35:10] --- randy has joined
[12:35:20] --- DarrylChampagne has left
[12:35:50] <resnick> Eric: Need to take out all of the language on the accuracy of the search. (i.e., Dave's text)
[12:36:13] <resnick> Eric: Take to the list: a) Would a client ever request a refresh interval?
[12:36:35] <resnick> Peter: I don't think you want to do that. Frequent update might be expensive.
[12:36:54] <resnick> Eric: And then what do we do if the client asks for something too frequent?
[12:37:34] <arnt> being able to ask for frequent update is essentially "give me priority over everyone else". fine for the client, not so great for everyone else.
[12:38:57] <resnick> Eric: Take to the list: Can we drop the idea of the client specifying the refresh interval.
[12:40:30] <resnick> Eric/Phil: Punt this to context.
[12:40:55] <resnick> Alexey: This effects context and vfolder.
[12:41:17] <resnick> Eric/Phil: Which says be silent in here.
[12:41:35] <pguenther> faster than light updates! the imap ANSIBLE extension...
[12:43:46] <resnick> Arnt: Delete older than one week has the same problem. It should be specified in within.
[12:46:42] * resnick waits for something to be decided....
[12:48:05] --- DarrylChampagne has joined
[12:48:10] <resnick> Arnt: within is different than things based on flags.
[12:50:37] <resnick> Randy: What's the use case here? We don't want the set to be dynamically changing.
[12:51:02] <randy> at least not dynamically shrinking
[12:58:09] <resnick> Eric is typing....
[12:58:26] --- DarrylChampagne has left: Replaced by new connection
[12:59:09] --- DarrylChampagne has joined
[12:59:42] <eburger> OLDER/YOUNGER always result in exact matching, to the resolution of a second. However, if one is doing a dynamic evaluation, for example, in a context, one should be aware the server may perform the evaluation periodically and the updates may be delayed.
[13:00:11] <eburger> Principal question: Is there any reason to mandate a minimum server evaluation?
[13:00:54] <eburger> Pete is pointing out that if we make it possibly difficult for the server to implement, i.e., by mandating some minimum server evaluation time.
[13:01:26] <eburger> Peter is pointing out that while we know that servers should try at least every hour, someone looking at it in two years won't know that.
[13:01:57] <eburger> Pete: if the server doesn't give any indication of what it will do, client writers will make (incorrect) assumptions.
[13:02:45] <resnick> Eric: So why doesn't the server simply *tell* the client what it's going to do.
[13:02:59] <resnick> Alexey: There's nothing useful for the client to do with that info.
[13:06:04] <resnick> Eric: So say, "MUST update at least every hour"
[13:06:11] <resnick> Pete: What does that buy us?
[13:08:22] <eburger> OLDER/YOUNGER always result in exact matching, to the resolution of a second. However, if one is doing a dynamic evaluation, for example, in a context, one needs to be aware the server may perform the evaluation periodically and the updates may be delayed.
[13:10:00] <arnt> eric - that text is fine with me.
[13:11:34] <eburger> te: What does that buy us?OLDER/YOUNGER always result in exact matching, to the resolution of a second. However, if one is doing a dynamic evaluation, for example, in a context, one needs to be aware the server might perform the evaluation periodically and the updates may be delayed.
[13:12:06] <eburger> (This replaces the "unable / unwilling" text in SEARCH WITHIN)
[13:14:03] <resnick> Next topic: 2192bis
[13:14:23] <resnick> Alexey: Please comment on mailing list
[13:14:44] <resnick> Alexey: Suggestion to require STARTTLS
[13:15:19] <resnick> (That is, syntax in the URL to require STARTTLS)
[13:19:10] <resnick> This is a request by the URL creator.
[13:19:19] <resnick> Many people: Why would we want this?
[13:21:28] --- cnewman has joined
[13:21:30] <resnick> Alexey: Future, but not now.
[13:25:19] <resnick> CONVERT phrase in URL: Not now.
[13:28:17] <resnick> A short WGLC will be done at some point soon.
[13:29:22] <resnick> Maybe....
[13:29:42] <resnick> We'll decide tomorrow.
[13:30:11] <resnick> Chairs will look at the doc and decide if it's worth another WGLC
[13:33:57] <resnick> Moving on to msgevent. Randy.
[13:35:16] <resnick> Randy: Take out "MAY return ACLs" and put ACLs in the possible future section.
[13:35:57] <resnick> MailboxSubscribe/Unsubscribe, one event or two?
[13:36:01] <resnick> Randy: I don't care.
[13:36:33] <resnick> Does Chris care (since he suggested it)?
[13:36:36] <resnick> Chris: I don't care.
[13:37:33] <Anil_Srivastava> keep it as separate events... simpler IMHO
[13:37:53] <resnick> Sold: Keep it as separate event.
[13:37:57] <resnick> events.
[13:38:07] <resnick> Event naming issue:
[13:38:51] <resnick> Should the names have a pattern?
[13:39:14] <resnick> Arnt: Pattern is good.
[13:39:26] <resnick> Randy: Type of thing first, specific latter.
[13:39:49] <resnick> (e.g., AppendMessage becomes MessageAppend)
[13:43:12] <resnick> Randy will rename to make a pattern.
[13:43:43] <arnt> email me the draft once changed, and I'll check name correspondence line by line
[13:45:35] <resnick> WGLC for msgevent needed.
[13:46:10] <resnick> Dave: Are your children asleep yet?
[13:46:58] <resnick> Next document: NOTIFY.
[13:47:22] <arnt> 1. Suggestion to add "STATUS" option to the NOTIFY command: notify = "NOTIFY" [SP "STATUS] SP event-groups If status is specified, then the event "a mailbox becomes monitored" triggers a STATUS response. This replaces the evil STATUS responses before the tagged OK. 2. Ability to bundle connections. 3. Well-defined ACL requirements for each event type etc. + When to return NO to a NOTIFY command + How to notify about a mailbox no longer being monitorable (due to deletion, ACL change) 4. Section on ExpungeMessage doesn't explain that the lack of ExpungeMessage means the default "don't send unsolicited EXPUNGEs" behavior. 5. Get rid of mailbox patterns, replace them with "subtree <mailbox>"? 6. Peter Coates: allow for NOTIFY SET, NOTIFY ADD subcommands [accepted, but allow for multiple events in a single command] 7. Peter Coates: allow to specify a single search criteria for multiple events
[13:53:26] <resnick> Peter: Meta-point: Not happy with complexity of Mailbox manipulation, and the whole mechanism in general.
[13:54:37] --- cyrus_daboo has left
[13:55:04] <resnick> Peter: If you're only permitted to specify specific mailboxes for message events, you won't get effected by mailbox events.
[14:00:51] <resnick> Arnt: Punt on wildcards
[14:01:14] <resnick> Peter: No wildcards, no subtree, for message events.
[14:01:22] <resnick> Peter: For mailbox events, you can do subtree.
[14:02:28] <arnt> my phone hung up
[14:02:32] <arnt> unilaterally
[14:02:37] <resnick> We'll wait.
[14:05:17] <resnick> Arnt: So, for mailbox events you only have to walk up the tree for other mailbox notifications.
[14:11:01] * dwd gets children to bed finally.
[14:19:13] <pguenther> "dwd hopes they can't reach their lockpicks"
[14:20:19] <resnick> Jabber scribe wakes up and starts typing again in the discussion of whether subtrees are needed for message events.
[14:22:21] * dwd dials in, having, hopefully, figured out Mute on the phone.
[14:28:51] <resnick> A 10 minute break....
[14:29:24] <arnt> I hung up. ten minutes without the damned phone will do me good.
[14:30:00] <dwd> Yeah, I have mine on speaker/mute, so I get to avoid earache. :-)
[14:30:13] <arnt> I do too, but when I speak I need to hold it.
[14:40:39] <Anil_Srivastava> are we back now? I hung up too so I could make another call ;)
[14:40:59] <resnick> People are still milling about.
[14:41:11] <resnick> Heading back in this direction.
[14:41:24] <Anil_Srivastava> thanks...
[14:46:42] <arnt> arnt is back
[14:46:48] <resnick> OK, silliness of dinner arranging is completing.
[14:46:52] <resnick> Then we will restart.
[14:47:52] <resnick> We are back.
[14:49:13] <resnick> So, folks (Arnt, Peter, Alexey) seem convinced that you have notify add and notify reset (syntax TBD)
[14:49:47] <resnick> Arnt still cogitating on the issue of subtrees with message events.
[14:50:06] <resnick> Peter seems *very* enthusiastic to get rid of them.
[14:50:54] <dwd> Careful that you're not confusing cogitating with ruminating, there...
[14:52:30] <resnick> Dave: Yes, we were discussing that cogitating has the same feel as ruminating, only more cognitive. :-)
[14:53:08] <resnick> Peter will write up suggestions for Arnt re: bundling connections.
[14:55:45] <dwd> I'm on the phone. Not talking...
[15:01:23] <resnick> Discussing ENABLE (sorry, I was paying attention)
[15:06:16] <randy> Discussing oddity of issuing ENABLE before authentication
[15:06:35] <resnick> It would be useful for EAI, but I'm not saying that outloud.
[15:09:00] <resnick> Arnt: QRSYNC should *definitely* use ENABLE.
[15:09:07] <resnick> Dave is here, is he not?
[15:12:30] <resnick> (Discussion going on about extending the capability banner. Silliness ensues.)
[15:13:01] --- eburger has left
[15:13:11] <resnick> Peter asks whether it should be part of AUTHENTICATE or should be separate.
[15:13:25] <resnick> (wants a separate ENABLE command)
[15:13:41] <resnick> ENABLE is for current limitations of QRSYNC and CONDSTORE.
[15:18:41] <resnick> Question of whether 4550 requires advertising CONDSTORE.
[15:21:49] <randy> 4550 requires "support" but not "advertise"
[15:22:08] <resnick> Fractional hairs notwithstanding
[15:22:17] <randy> 4550 does require advertising some things, by the way
[15:28:25] <resnick> Peter: Having quick resync support enable is the important thing.
[15:28:50] --- pvanhoof has joined
[15:28:54] <pvanhoof> hi there
[15:29:05] <resnick> Who are you?
[15:29:11] <pvanhoof> Tinymail author
[15:29:14] <dwd> (That's Philip van Hoof, Tinymail developer)
[15:29:20] <pvanhoof> And you? ;)
[15:29:20] <resnick> ack
[15:29:32] <resnick> Pete Resnick, random passenger on the bus.
[15:29:35] <resnick> :)
[15:29:36] <dwd> (And that's Pete Resnick, RFC2822 author)
[15:29:36] <pvanhoof> ok
[15:29:50] <pvanhoof> Ok I see :)
[15:32:27] --- arnt has left
[15:32:46] --- eburger has joined
[15:33:07] --- arnt has joined
[15:34:23] <pvanhoof> listening
[15:35:12] <randy> Philip -- are you on the voice call as well as Jabber?
[15:35:17] <pvanhoof> yes
[15:35:24] <pguenther> yes
[15:35:28] <pvanhoof> I 'm using that Holland-number
[15:35:50] <pvanhoof> that sounds like Dave's voice
[15:36:00] <pguenther> we have two Philips present now
[15:36:08] <pvanhoof> oh sorry :)
[15:36:18] <pguenther> oooh, and you spell your name with one ell too
[15:36:28] <pguenther> I'm not the only one
[15:36:43] <pvanhoof> My dad worked at Philips in Eindhoven, should explain all :)
[15:36:56] <pguenther> heh
[15:40:16] <resnick> (Sorry that I lost the thread on ENABLE. I think the minutes will be reasonable.)
[15:41:05] <resnick> imapext-filters
[15:41:21] <pguenther> I was just rattling on the idea that a profile bis server might fail to support a 4550 client by only support condstore-via-enable
[15:41:39] <resnick> Storing search criteria in annotations (by name).
[15:41:59] <resnick> This with context will get you virtual folders.
[15:44:07] <pguenther> they would be stored in server metadata, not annotations, right?
[15:44:36] <resnick> Dave: Issue: What if you create a dynamic search based on the named filter and rename the filter?
[15:44:48] <resnick> Alexey: Expansion done at instantiation time.
[15:45:31] <Anil_Srivastava> how does on avoid loops?
[15:45:33] <resnick> Server must do at least 3 levels of substitution at execution time.
[15:46:24] <resnick> (I'm waiting for Dave to ask what happens if God creates an annotation so large that he himself can't parse it.)
[15:47:22] <Anil_Srivastava> never mind.. I just read that loop detection is the implementation resposibility
[15:48:10] <resnick> Alexey asks for direction.
[15:50:30] <resnick> Q: So, is anyone going to use this?
[15:51:19] <Anil_Srivastava> I believe there is a use for it.. just look at the number of clients that support virtual folders and store the def in the client..
[15:52:06] <resnick> Philip?
[15:52:12] <pvanhoof> Which one?
[15:52:14] <resnick> You
[15:52:17] <pvanhoof> Yes?
[15:52:18] <dwd> You...
[15:52:22] <pvanhoof> Listening :)
[15:52:25] <resnick> Do you think this would be useful?
[15:52:44] <pvanhoof> I was asking dave for the agenda of this conference :), and not really listening to the current subject
[15:52:57] <pvanhoof> Sorry, I kinda got thrown in :)
[15:53:03] <dwd> Philip: Named filters stored on the IMAP server. :-)
[15:53:34] <resnick> Next topic: Context
[15:53:36] <pvanhoof> searches?
[15:53:47] <resnick> (Philip: Right)
[15:53:48] <pvanhoof> or, vfolders
[15:54:04] <pvanhoof> yes, for mobiles it's really difficult to keep the memory consumption low if you want to do vfolders at the client
[15:54:22] <pvanhoof> so letting the server do some bits of it, yes is very useful
[15:54:30] <resnick> Sorry, missed those differences Dave.
[15:54:43] <resnick> Someone else care to type them in here.
[15:54:54] <resnick> Since Prague, we're punting on SORT.
[15:55:35] <resnick> Any other open issues on CONTEXT?
[15:56:02] <pvanhoof> I read the proposal, looked good to me
[15:59:03] <resnick> Peter: This doesn't add much for a webmail client. What is this thing to be used for.
[15:59:03] <pvanhoof> mobile
[15:59:12] <pvanhoof> For mobiles it's useful
[15:59:45] <pvanhoof> Because I don't have all the data in memory (of the entire folder), so IDLE updates for things that don't belong to a search (a vfolder), are not interesting (bandwidht)
[15:59:57] <resnick> Dave: Lowers bandwidth for clients for large mailboxes.
[16:01:14] <cnewman> I'm dropping off the voice call for a while, but will continue on jabber...
[16:01:23] <resnick> I'll try to keep up.
[16:02:35] <randy> Dave -- think of the data corruption opportunities with CONVERT and RFC1437!
[16:03:05] <dwd> Randy: Hey! A use-case for STRICT!
[16:03:32] <resnick> Peter: Concern that we don't have SORT. Is this still useful for the client if we don't have SORT?
[16:05:39] <resnick> Dave: Original design was with SEARCH and SORT. But we punted SORT in Prague.
[16:06:54] <pguenther> randy: converting from non-sentient to sentient would be interesting...
[16:07:53] <resnick> Dave: There's scant little in the document that is specific to SEARCH.
[16:08:21] <cnewman> Hmm, would we need RFC 1437 to support sentient?
[16:10:13] <pguenther> maybe we should extend sort to permit an empty sort criterium, thereby giving the baseline msgno/uid order
[16:10:21] <resnick> Peter: Could repeatedly do SORT.
[16:10:50] <resnick> PvH: Better than doing it on the client.
[16:11:14] <resnick> Peter: It's not that big a deal to ask for partial results from a SORT.
[16:11:17] <pvanhoof> if client = mobile
[16:12:15] <resnick> Dave: Need to have some sort of extended SORT like ESEARCH response.
[16:16:32] <resnick> Dave will re-introduce sort into the document.
[16:23:39] <cnewman> It's been quite for a while...
[16:23:50] <cnewman> ^quite^quiet
[16:23:51] <resnick> Sorry.
[16:24:08] <resnick> Simply discussing adding binary to URLFETCH.
[16:24:27] <resnick> Useful for streaming.
[16:24:37] <resnick> Dave seems to have volunteered to write it up.
[16:25:01] <resnick> Lots of head nodding and mmhmming.
[16:25:11] <resnick> Dave currently explaining how this might be done.
[16:25:47] <resnick> Streaming servers don't know from base64.
[16:26:18] <randy> Would this be related to the other recent proposals to allow access to the MIME information?
[16:28:25] <resnick> This makes it possible for the streaming server to simply get the Content-Type and the data.
[16:29:14] <resnick> PG: Can you also get the Content-Base?
[16:29:20] <resnick> Dave: No.
[16:30:40] <pvanhoof> silent question: Will this allow to get a message without having to select to a folder
[16:30:59] <resnick> PvH: URLFETCH does so in general.
[16:31:08] <pvanhoof> ok
[16:31:46] <pvanhoof> then for me it's useful to have this to get messages from a folder without having to leave my selected folder (one connection, turning on/off IDLE on each command, trying to keep one folder selected)
[16:32:08] <pvanhoof> No other comments from me , though (get it like BINARY :-) )
[16:33:46] <randy> It's worth noting that, while URLFETCH can be used to get a message without SELECTing the folder, it requires an extra round-trip to generate the URL before it can be used in URLFETCH.
[16:34:03] <pvanhoof> Right
[16:37:05] <dwd> And you get no metadata, parsing, etc.
[16:38:19] <dwd> My proposal at Thu, 10 May 2007 09:51:56 +0100
[16:38:30] <dwd> (On lemonade list)
[16:38:38] <pguenther> url into archive?
[16:39:22] <pguenther> btw, I was confused: content-base was removed from the MHTML spec (RFC 2557)
[16:39:30] <resnick> I (having just returned from the men's room) have missed a full discussion about whether something needs to be coordinated with mediactrl.
[16:39:57] <resnick> PG: Right. Content-Location.
[16:40:01] <pguenther> returning the content-location information of surrounding multiparts may be necessary
[16:40:20] <pguenther> ...in general, for resolving links in an html part
[16:41:03] <dwd> http://www1.ietf.org/mail-archive/web/lemonade/current/msg03698.html
[16:45:03] <resnick> So, Dave is going to work on this and then streaming will be updated to reflect.
[16:45:56] <pguenther> dwd: I would suggest using the same extension syntax in the URLFETCH request and response
[16:46:12] <pguenther> i.e., put the parens in the same place in the two
[16:46:50] <resnick> Closing down for today.
[16:47:04] --- randy has left
[16:47:16] <resnick> See you all tomorrow at 09:00 -0400.
[16:48:00] --- DarrylChampagne has left
[16:49:13] --- alexeymelnikov has left
[16:50:58] --- resnick has left
[16:52:10] --- pguenther has left
[16:53:32] --- cnewman has left
[16:55:02] --- pvanhoof has left
[16:55:50] --- Anil_Srivastava has left
[16:56:46] --- Glenn Parsons has left
[17:18:52] --- eburger has left