[09:06:46] --- cyrus_daboo has joined
[09:06:55] --- cyrus_daboo has left
[12:37:22] --- gparsons@jabber.org has joined
[12:37:41] --- gparsons@jabber.org has left: Logged out
[12:41:28] --- lemonade has joined
[12:42:56] * lemonade has set the topic to: IETF 66
[13:20:22] --- cnewman@jabber.org has joined
[13:49:40] --- pguenther has joined
[14:41:20] --- lemonade has left: Computer went to sleep
[14:45:35] --- Dave Cridland has joined
[14:47:50] --- fanf has joined
[14:56:14] <Dave Cridland> 'ello.
[14:58:13] <fanf> hi
[14:59:02] <fanf> are you listening to the audio stream?
[15:00:12] <Dave Cridland> Oh, hadn't noticed the time. Yes, I will be.
[15:03:10] --- lemonade has joined
[15:03:57] <Dave Cridland> Um, I will be when I can get the audio stream to work.
[15:04:14] <lemonade> We will start in ~20 minutes
[15:04:37] <lemonade> Audio stream details are here:
[15:04:40] <lemonade> http://videolab.uoregon.edu/events/ietf/
[15:04:48] <Dave Cridland> Yeah. It's obviously not up yet.
[15:09:28] --- greg.vaudreuil has joined
[15:11:18] <greg.vaudreuil> greg here
[15:18:35] --- alexeymelnikov has joined
[15:19:59] --- Glenn Parsons has joined
[15:20:14] --- eburger has joined
[15:21:02] <fanf> i can *just* hear voices but the background noise is louder...
[15:21:12] --- smaes has joined
[15:21:20] <fanf> i heard that :-)
[15:22:15] <Dave Cridland> I still can't make a connection to the streaming.
[15:23:06] --- Jerry Shih has joined
[15:23:27] --- anabolism@jabber.org has joined
[15:24:51] <Glenn Parsons> We'll start in a couple of minutes -- we are confirming Alexey's agenda in SASL...
[15:25:26] <alexeymelnikov> I will [physically] come later.
[15:27:42] --- resnick has joined
[15:28:41] --- smaes has left
[15:29:41] --- kmurchison has joined
[15:30:53] <eburger> We will start in 2 minutes
[15:31:57] <Dave Cridland> Gah. I see my streaming problem. I can't download the streams fast enough.
[15:32:30] --- smaes has joined
[15:32:51] --- Barry Leiba has joined
[15:32:53] --- arnt has joined
[15:33:42] --- tonyhansen has joined
[15:35:29] --- cromwellian has joined
[15:35:47] --- cyrus_daboo has joined
[15:36:36] * pguenther starts scribing
[15:36:43] <pguenther> NOTE WELL has been read
[15:36:57] <pguenther> agenda bashing:
[15:37:04] <pguenther> - status of docs
[15:37:09] <arnt> is it just me, or is the audio volume very very low?
[15:37:10] <pguenther> - interop event
[15:37:23] <pguenther> - OMA liaison
[15:37:42] <fanf> yes it's only just audible on max
[15:37:44] <cromwellian> i connected to ietf668 live stream but can't hear anything
[15:37:58] <cromwellian> oh ok, i got it now, but it has alot of noise
[15:38:04] <pguenther> - issue discussion -- existing document open issue
[15:38:04] <cromwellian> like there is a fan sitting next to the mic
[15:38:08] <pguenther> milestones
[15:38:13] <pguenther> - charter
[15:38:26] <pguenther> Documents to discuss:
[15:38:32] <pguenther> (groupings)
[15:38:40] <pguenther> streaming media
[15:38:48] <pguenther> other bis components
[15:38:50] <pguenther> notifications
[15:38:52] <pguenther> reconnect
[15:38:56] <pguenther> views
[15:38:56] --- NFreed@jabber.org has joined
[15:38:58] <pguenther> profile-bis
[15:39:19] <pguenther> this is slide 6
[15:39:33] --- frodek has joined
[15:39:43] <pguenther> stuff not the list: convert, deployments
[15:39:55] <pguenther> Glen suggests those two are ready for WGLC
[15:40:13] <eburger> and Search Within (for WGLC)
[15:40:45] <pguenther> no breakdown for what will be discussed today vs tomorrow
[15:42:00] <pguenther> some rejigging of order being discussed so that Randy doesn't miss stuff when he's chairing geopriv tomorrow
[15:43:06] <pguenther> will keep current order until Alexey comes over from SASL, then rejig
[15:43:31] --- Jerry Shih has left
[15:43:59] --- Jerry Shih has joined
[15:44:07] <pguenther> (rejig to be moving streaming and other-bis to end)
[15:44:14] <pguenther> STATUS
[15:44:24] <pguenther> three in IETF last call
[15:44:32] <pguenther> six published
[15:45:06] <pguenther> in WGLC starting after meeting: convert, search within, deployments
[15:45:20] --- xiaodong has joined
[15:45:36] <cromwellian> convert has some nits that have to be fixed, purely formatting oriented stuff
[15:45:39] <cromwellian> some grammar mistakes
[15:46:06] <cromwellian> alexey gave me some feedback on some stuff that needs to be fixed, nothing semantically, just beautification
[15:46:37] <cromwellian> can the scribe relay these comments?
[15:46:56] --- xiaodong has left: Disconnected.
[15:47:04] --- alexeymelnikov has left
[15:47:04] --- ted has joined
[15:47:33] <cromwellian> i can't hear the person speaking
[15:48:06] <NFreed@jabber.org> Sound level is _really_ low overall.
[15:48:06] <pguenther> sorry, have nudged chairs
[15:48:09] --- Glenn Parsons has left
[15:48:18] <cromwellian> search within also has some nits too, but alexey thinks its ready
[15:48:20] --- Glenn Parsons has joined
[15:48:27] <NFreed@jabber.org> Yes.
[15:48:30] <arnt> much better volume
[15:48:31] <fanf> i can hear somewhat better
[15:48:34] <pguenther> that's the tonsil mike
[15:48:50] <resnick> That was mean.
[15:48:57] <arnt> the clicking thing (projector fan?) is weaker compared to the voice.
[15:49:01] <pguenther> "and if we don't speak French?"
[15:49:17] <cromwellian> i fixed my audio by using an equalizer to drop out the fan noise :)
[15:49:31] <pguenther> and there was much rejoicing
[15:49:36] <anabolism@jabber.org> The projector is not near the mike, but there are laptops on the same table as the chair's mikes
[15:49:43] --- xiaodong has joined
[15:49:50] <cnewman@jabber.org> Cool! A reason to deduct the cost of an equalizer as a business expense...
[15:51:05] <pguenther> eric pointed out an unresolved issue (minutes vs hours) that will be addressed in next rev
[15:51:10] <cromwellian> hmm, it appears the draft submitted was a older revision, yes, minutes don't appear in the text :(
[15:51:12] <pguenther> for search within
[15:51:13] <cromwellian> s/hours/minutes/
[15:51:28] <pguenther> alexey has arrived
[15:51:56] <cromwellian> randy, yes, your comments plus alexeys are needed for the next rev
[15:51:58] <pguenther> Randy notes that comments made previous had not been incorporated or answered
[15:52:48] <pguenther> Cyrus will make another rev of annotatemore for a couple things
[15:53:00] --- alexeymelnikov has joined
[15:53:03] <anabolism@jabber.org> I sent comments on convert-03 on May 31
[15:53:30] --- anabolism@jabber.org has left
[15:53:39] --- Randy Gellens has joined
[15:54:01] <pguenther> no comments on deployments...
[15:54:27] <pguenther> Pete, as imapext chair, will trigger the annotatemore ietf last call
[15:54:36] <pguenther> (it's not a WG doc at all, but...)
[15:55:10] <pguenther> Interop
[15:55:48] <pguenther> reasons: marketing, proving viability, moving stuff to draft standard, etc
[15:55:58] <pguenther> thus, a liaison to OMA
[15:56:11] <pguenther> venues listed (see slide 9)
[15:57:12] <pguenther> Randy: request for servers to be available continuously instead of just for the event
[15:57:35] <pguenther> provide something for clients to test against as they get stuff up
[15:58:19] --- Mike Parsel has joined
[15:58:33] <pguenther> summary of OMA liaison:
[15:59:16] <pguenther> interested in interop results that we could come up but they are not at stage to be involved in the testing itself
[15:59:50] <pguenther> will only do so once stuff is an "approved enabler" (procedural level, etc)
[16:01:16] <pguenther> OMA MEM liaison: will study content of notifications, will offer an OMA MEM presentation in October timeframe
[16:01:26] <pguenther> does not appear to be anything in need to response to OMA by WG
[16:02:14] <pguenther> comments on liaison?
[16:02:53] <pguenther> people interested in interop, please talk to chairs
[16:03:11] <pguenther> (that was slide 9 you should be looking at, hint hint)
[16:03:28] <pguenther> Document Issues
[16:03:53] <pguenther> skipping streaming and other-bis groups
[16:04:02] <pguenther> so, start with notifications set of drafts first
[16:04:29] <pguenther> starting with msgevents draft
[16:04:31] <cnewman@jabber.org> I'm here.
[16:04:32] <pguenther> status?
[16:04:39] <pguenther> near completion?
[16:04:48] <pguenther> (alexey gets up)
[16:05:39] <pguenther> alexey: comments from Zolton that he agreeds with re: adding mailbox related events, despite arguments in appendix otherwise
[16:05:47] <cnewman@jabber.org> I would prefer to have a deployed implementation before adding new events.
[16:05:56] --- Lisa has joined
[16:07:19] <pguenther> Randy: mailbox events are fairly rare, while lemonade is concerned with immediate need stuff
[16:07:23] <pguenther> so, don't add, please
[16:07:26] <pguenther> (yet)
[16:08:03] <alexeymelnikov> I had multiple offline conversation with people who want mailbox events to be sent to an IMAP client.
[16:08:04] --- neilcookster has joined
[16:08:36] <alexeymelnikov> I am not entirely sure how useful this is, but I keep hearing requests to add this.
[16:08:49] <pguenther> Randy: was discussed on list how to create notifications, but felt it had poor usability
[16:09:22] <pguenther> need something simpler, perhaps filters on servers that clients can discover and then subscribe to
[16:09:26] <cromwellian> this was one of the issues we had with replacing vfolder with another mechanism used for filtering and attaching notification semantics is that it would be nice if whatever mechanism that exists has a way of naming filters so that the clients can access them by name and that notifications may refer to them by name (event X occured for filter Y)
[16:09:43] <pguenther> or perhaps an IANA registry of notifications that can be subscribed
[16:10:14] <cnewman@jabber.org> Randy, please email me the modseq suggestion so I get it in the draft. That's an important suggestion.
[16:10:48] <cromwellian> for example the CONTEXT discussion
[16:10:51] <Randy Gellens> Chris, will do now (I wasn't sure which draft to comment against :-) )
[16:11:23] <pguenther> (suggestion was to include CONDSTORE modseq value in notifications)
[16:11:27] <cnewman@jabber.org> The msgevent draft lists what messages and what parameters go with them, so modseq goes in that one. The filtering requirements are somebody else's problem :-)
[16:11:43] <cromwellian> by the way, the current notifications draft XEMN extension has a field that can be used for sequence number (modseq)
[16:12:07] <ted> are they going to jello wrestle to work it out?
[16:12:37] <cromwellian> alexey can u speak up a litle
[16:13:24] <pguenther> alexey: would _like_ for list of events in melnikov-lemonade-imap-events to match list in msgevent draft
[16:14:16] <pguenther> Glen: leave events in imap-events draft
[16:14:48] <cnewman@jabber.org> If we're going to put mailbox events on the standards track, I'd prefer we have all the events in my draft.
[16:15:15] <alexeymelnikov> Naming filters should be done in the draft describing filtering. I believe this is already on to do list.
[16:16:00] <pguenther> Chris: you want me to repeat that?
[16:16:53] <cromwellian> the last bullet means that notifications doesn't require VFOLDER, it just says filters needed to be named, etc
[16:17:02] <cnewman@jabber.org> Not sure it needs to be repeated on the list, but it matters to Alexey. Basically if he feels strongly that mailbox events need to be in his IMAP events draft, then I don't have a problem putting them in my draft.
[16:17:19] <cnewman@jabber.org> ^on the list^in the room
[16:17:30] * pguenther nods
[16:17:35] <cromwellian> XEMN has been extended to transmit the filter name in the notification payload
[16:18:36] <cromwellian> I think Chris's document should be the canonical list of events, other drafts should just reference them in terms of how they are used in payloads, etc
[16:19:26] <pguenther> back and forth between Glen and Stephane about in-band vs out-of-band
[16:20:37] <cnewman@jabber.org> Q: does the name of the filter triggering a notification need to be a notification parameter listed in the msgevent document?
[16:20:45] <cromwellian> I changes that so as not to bias towards vfolder. now other proposals like CONTEXT may be able to satify the notifications requirements
[16:21:20] <cnewman@jabber.org> If yes, what is the syntax of the filter name?
[16:21:29] <eburger> Opaque object?
[16:22:57] <cromwellian> good question :)
[16:23:01] <Dave Cridland> I'd prefer a string, UTF-8.
[16:23:09] <Dave Cridland> For no very good reason.
[16:24:41] <pguenther> Randy: what is the use of telling the client the name of the notification that triggered the event
[16:24:43] <pguenther> ?
[16:25:04] <cromwellian> it may be used to determine how to best sync when it reconnects, for example, which CONTEXT to run
[16:25:08] <arnt> utf-8 object sits a little poorly with the current mUTF-7 mailbox names. I think that's a good argument against mUTF-7 mailbox names.
[16:25:27] <Randy Gellens> Ray, how so?
[16:25:29] <pguenther> doesn't that presuppose a model where the user does the subscription elsewise instead of having the client doing its own subscriptions?
[16:26:10] <cromwellian> well, assuming you want to wake up and sync against a large mailbox that may have alots of new messages, but you only want to sync stuff that satisfies a certain search critieria
[16:26:35] <cromwellian> how do you know which search to run
[16:26:51] <cromwellian> you may have 20 different CONTEXT searches defined
[16:26:56] <Dave Cridland> Ray: To be fair, you may want to be notified about different events than you want to resync against.
[16:27:34] <pguenther> Randy: we're into solutions for problems that we haven't clearly described
[16:27:50] <Dave Cridland> Randy: I'm primarily thinking you want to know what notification filter was triggered in order to debug it, etc.
[16:27:54] <pguenther> different people have different opinions on what the problems mean
[16:27:55] <arnt> dave: true, but that's neither here nor there. why would you want notifications unless you're going to act on them? the mere fact that you may also want to read some other mail, about which you weren't notified, is irrelevant.
[16:28:06] <cromwellian> im worried about the situation where you have dozens of filters defined and you don't want your client to sync everything everytime you get woken up
[16:28:57] --- Lisa has left: Logged out
[16:29:41] <pguenther> Stephane: providing multiple notifications channels, not sure they will be subscribeable
[16:29:51] <pguenther> will _all_ be, that is
[16:30:01] <cromwellian> i think the issue isn't just subscribing to which notification channels you want, but after getting such a notification, know which channel it was you subscribed to, and not just the event name.
[16:31:13] <pguenther> randy: diffrerent models for njotification usage
[16:31:52] <cnewman@jabber.org> I'm going to put a parameter in msgevent called a "tag". The meaning of the "tag" parameter will be defined at subscription or filter definition time. This is a similar idea to the context variable passed to a callback function. I'm not sure we know today exactly how such a parameter will be used, but I'm quite sure it will be needed.
[16:32:58] <eburger> Which is my opaque object
[16:33:44] <Randy Gellens> [[ meta-comment: the use of colon (":") as both attribution and comment addressing is very confusing! ]]
[16:33:46] <arnt> if imap gets utf-8 mailboxes (question of time IMO), mUTF-7 and UTF-8 mailbox names will be equivalent.
[16:34:10] <cnewman@jabber.org> I'd prefer the syntax for a "tag" to be a UTF-8 string. The protocol equivalent of an "opaque object" is a counted binary string and those tend to be messy.
[16:34:15] <Randy Gellens> Dave, I can see wanting to know the name for debugging uses
[16:34:46] <cromwellian> particularly if you are getting spammed and want to throttle something, how would you know which filter is the culprit?
[16:34:52] <pguenther> Randy: throttling necessary? or will serves be loaded down or client overrun?
[16:34:56] <fanf> the rate of notifications is limited by how fast the user can mess around with their mailboxes, and how fast email arrives. (the latter is somewhat correlated with how fast you can read...)
[16:35:20] <Randy Gellens> Ray, having filters defined doesn't mean the client will be subscribed to the results of that filter, does it?
[16:35:24] <pguenther> Me: schism in model of notificaiton usage? do client need to filter notifications?
[16:35:47] <pguenther> fanf: you don't have mailboxes to which mailing lists are delivered?
[16:36:18] <alexeymelnikov> I agree with Stephane that we need to define mechanisms for listing and managing filters.
[16:36:21] <cromwellian> no, i don't think so. but for out-of-band, we will need a mechanism for the client to say "I want to subscribe to that" which has not be designed yet
[16:36:34] <fanf> i (eventually) unsubscribe from ones i can't keep up with :-)
[16:37:14] <pguenther> Randy: either you create the filters you want, and thus get what you want, or you subscribe to what you want, and thus get what you want
[16:37:51] <pguenther> Lisa: nice to be able to get notifications without having to do IMAP
[16:38:04] <pguenther> Randy: not our (lemonade) target audience
[16:39:26] <pguenther> Randy: tag on notifications isn't a Bad Thing, but it may show confusion about usage
[16:40:10] <cromwellian> interesting question, perhaps some users would like to get both
[16:40:11] <pguenther> Eric (a non-chair): when I have N filters that all match a new message, do I get N notifications?
[16:40:18] <cnewman@jabber.org> Here's the text I intend for the next version of the msgevent draft: "tag" This is an arbitrary UTF-8 string which is set at the time a filter is created or subscribed which subscribers can used for client-side filtering or dispatch of events.
[16:40:24] <cromwellian> and the stephane notification might trigger a louder alarm ! :)
[16:40:48] <cromwellian> maybe advanced clients will allow ring tones to be associated with certain types of notifications
[16:41:25] <pguenther> stephane: if you only want one, write it as one criteria
[16:41:28] <ted> That is advanced client? This is some value of advanced I don't follow.
[16:41:55] <cromwellian> I think teenagers have a different definition :)
[16:43:15] <pguenther> alexey: multiple tags in a single notification?
[16:43:32] <pguenther> (as a way to merge notifications)
[16:44:51] <pguenther> lisa: if clients are generating sieve scripts, there will interop problems because different clients won't understand each other's scripts
[16:45:13] <pguenther> Cyrus: GUIs already generate canned scripts with magic comments
[16:45:34] <cromwellian> imap search?
[16:45:47] <pguenther> Randy: sieve as lousy way to communicate criteria _to_ clients
[16:46:15] <Randy Gellens> By including the modseq, at least a client will know if it has already processed the underlying event for a notification
[16:46:21] <pguenther> Eric: visions of prolog
[16:46:36] <pguenther> "full employment for server authors RFC of 2006..."
[16:47:21] <pguenther> stephane: expected simple interface for generating sieve filters
[16:47:24] <Randy Gellens> If clients are generating their own filters, they will likely use Sieve as write-only: they will generate a new script (perhaps from checkboxes in UI) each time
[16:47:49] <cromwellian> p-imap took the approach of using vfolder (imap search is filtering language) plus some METADATA preferences to filter the event types
[16:47:51] <Randy Gellens> On the other hand, if clients are discovering filters, they need a way to discover the criteria, and Sieve is a lousy way to do that
[16:48:10] <cromwellian> the benefit was that displaying GUIs for imap search criteria is easier
[16:48:27] <Dave Cridland> Yes, it's difficult to go from Sieve to GUI.
[16:48:27] <pguenther> stephane: does not expect interop of criteria management
[16:49:00] <Dave Cridland> "difficult" meaning that I know of no client which can.
[16:49:08] <pguenther> similarly, no expectation of filter discovery
[16:49:31] <pguenther> Lisa: such expectations would be a simplifying assumption
[16:49:58] <cromwellian> lost audio, anyone else?
[16:50:01] <fanf> yeah
[16:50:05] <arnt> AOL
[16:50:15] <pguenther> Randy: assumption flipped: we're not says "must use IMAP to get noticiations"
[16:50:24] <cnewman@jabber.org> Yup, we lost audio as well.
[16:50:26] <pguenther> we're saying "IMAP clients get notification like this"
[16:50:32] * pguenther types faster
[16:50:43] <Dave Cridland> Maybe everyone's simultaneously lost their voice?
[16:50:53] <pguenther> Randy: having a way for cleints to get notificed of interesting events so that they can synch to them
[16:50:56] <ted> A quick google shows some managesieve code being developed; are there folks who have deployed?
[16:50:56] <eburger> We're still here...
[16:51:03] <pguenther> e.g., fetching a new message in the backgrounmd
[16:51:05] <arnt> meeting ends in how many minutes? 9?
[16:51:11] <ted> 29
[16:51:11] <pguenther> "instant email experience"
[16:51:16] <Dave Cridland> Ted: ManageSIEVE the protocol is well deployed.
[16:51:21] <fanf> our managesieve client does what cyrus described - magic comments
[16:51:22] <cromwellian> i await the day when internet audio streaming is rock solid reliable :) i dont think ive ever been in a meeting where it didn't get dropped at some point
[16:51:22] <cyrus_daboo> CMU has deployed managesieve. There were some clients using it.
[16:51:51] <pguenther> for that, need way for clients to get exactly what they want to provide that experience
[16:51:52] <ted> does it need to move out of draft -06 to ps?
[16:52:03] <Dave Cridland> Ted: I think Alexey's working on that.
[16:52:09] <cyrus_daboo> We will discuss ManageSIEVE tomorrow in SIEVE WG !!
[16:52:47] <arnt> thanks ted
[16:53:06] <pguenther> Stephane: <something I couldn't quite follow>
[16:53:08] <pguenther> (sorry)
[16:53:25] <ted> okay. I just wanted to get a sense of whether discovery in imap + manage in managesieve would be a reasonable approach. Having two ways to manage the script seems less than strongly needed.
[16:53:48] <cromwellian> just a note: I am going to writeup why I think filters need to be named and what clients can use it for in the notifications draft, can someone volunteer to write some text on why modseq is needed and how it will be used, as I anticipate that all of the notification event fields need some justifying text
[16:55:06] <alexeymelnikov> Ted: Ken, Rob, Barry and I talked about IMAP Sieve document in Dallas. The suggestion was to use ManageSieve to upload/download scripts, but use IMAP mailbox annotations to enable/disable them.
[16:55:39] <ted> okay.
[16:55:52] <ted> is there a draft name?
[16:55:57] <cromwellian> alexey, the current notifications draft uses annotations to configure notification stuff, so I would suggest that additional annotations for configuration should be there
[16:56:13] <pguenther> cromwellian: you see Randy's note to the list on modseq?
[16:56:17] <alexeymelnikov> Ted: we first discussed about extending ManageSieve to list mailboxes + sieve filters, but it was overkill.
[16:56:24] * pguenther turns off bold
[16:56:40] <pguenther> moving to notification protocol
[16:56:56] --- Jerry Shih has left: Replaced by new connection
[16:57:19] <alexeymelnikov> draft-martin-managesieve-06.txt and
[16:57:26] <cromwellian> thanks, i just saw it
[16:57:41] <pguenther> abstrace protocol for notifications based on Parlay X (2.0) multimedia messaging
[16:57:46] <pguenther> abstract, that is
[16:58:11] <pguenther> would like review of the choice
[16:58:12] --- Jerry Shih has joined
[16:58:47] <arnt> it's better with sound.
[16:59:01] <arnt> s/'s/ was/
[16:59:15] <alexeymelnikov> and draft-ietf-lemonade-imap-sieve-01.txt
[16:59:15] <resnick> You've lost sound?
[16:59:20] <pguenther> draft is just a reference to Parlay right now, if people don't shake their heads vigorously then he'll flesh things out about the binding
[16:59:26] <cromwellian> we all lost audio about 10 minutes ago
[16:59:35] <pguenther> (this stems from Ottawa interim)
[16:59:36] <cromwellian> the uoregon server is down
[16:59:39] <resnick> Sorry to (not) hear that.
[16:59:46] <pguenther> Glen: what are options?
[17:00:06] <pguenther> Stephane: Parlay is only one on table right now
[17:00:31] <pguenther> designed to drive SMS and web services
[17:01:07] <pguenther> Randy: based on SOAP? sounds like overkill
[17:01:27] * fanf mutters xmpp pubsub
[17:01:33] <pguenther> various parties cringe at profiling of SOAP
[17:02:17] <arnt> various clueful parties? I expect so.
[17:02:46] <pguenther> fanf: suggest to the list
[17:03:01] <pguenther> eric: Parlay would be choice over his rotting corpse
[17:03:12] <pguenther> but maybe for this one space it would be okay....
[17:03:29] <cromwellian> i got audio back
[17:04:15] <fanf> (yay sound)
[17:04:47] <pguenther> (from a bit ago) Randy: if Parlay is simple enough, an example of the bits on the wire should fit in a screenfull
[17:04:52] <pguenther> if not, it's too complicated
[17:05:03] <Randy Gellens> The point of doing this protocol is to have something dirt-simple as mandatory-to-implement. If parlay is that simple, an example of the bits-on-the-wire should easily fit on a CRT screen and can be added to the draft. Otherwise, maybe it is too complex.
[17:05:29] <cromwellian> i thought we wanted both
[17:06:06] <pguenther> Glen: in-band vs out-of-band?
[17:06:21] <pguenther> alexey's is in-band while Stephane's is either?
[17:07:18] <alexeymelnikov> Stephane's draft just references mine for in-band.
[17:07:34] <pguenther> Randy: agrees we need both
[17:09:09] <pguenther> further notification talk will be during charter talk
[17:09:39] <cnewman@jabber.org> yes, we can still hear you.
[17:09:41] <pguenther> now, streaming media
[17:10:34] <pguenther> Eric: in next version: normal SIP negotation handles stuff (was unclear before)
[17:10:48] <pguenther> how to locate media server?
[17:11:02] <pguenther> VCR controls?
[17:11:05] <Randy Gellens> Don't we already have several ways to discover servers?
[17:11:22] <Randy Gellens> Including DNS records?
[17:11:22] <neilcookster> discover media servers?
[17:12:00] <neilcookster> Do they mean SRV records?
[17:12:32] <arnt> we have SRV and SRVLOC; one's fine for discovering domain-bound services, the other for discovering client-local.
[17:12:39] <arnt> SVRLOC, sorry
[17:12:45] <Glenn Parsons> UNAPTR
[17:12:46] <arnt> we may have more.
[17:12:51] <arnt> UNAPTR, of course.
[17:13:25] * pguenther sees the SIP invaders laying siege to the door
[17:13:38] <fanf> do any clients do auto-location of imap and submission servers using SRV based on the email address domain?
[17:14:16] <NFreed@jabber.org> It would sure help if there was an RFC saying how to use SRV records for this ...
[17:14:34] <pguenther> Randy: issue is not where is the media server, but rather one from which the IMAP server will accept the URLAUTH token
[17:14:35] <neilcookster> I think we need both domain and client-based server discovery
[17:14:35] <arnt> fanf, I've seen that, sort of, but only once... it filled in the defaults.
[17:14:40] <ted> I was saying that the group may want to take a look at http://www.ietf.org/internet-drafts/draft-daigle-unaptr-00.txt
[17:14:50] <fanf> there have been drafts...
[17:14:55] <ted> Cyrus mentions rendezvous/bonjour.
[17:15:25] <cyrus_daboo> cf: http://www.dns-sd.org/
[17:15:37] <fanf> problem with bonjour is that it's link-local and your isp's servers are often not on the lcoal link
[17:15:40] <neilcookster> Need server/domain based discovery for the security/access issues
[17:16:02] <Randy Gellens> The problem isn't just a client knowing where its streaming server is, but where is the streaming server that it can pass a URLAUTH to and have the IMAP server accept it
[17:16:25] <neilcookster> Yes
[17:16:35] <cromwellian> can METADATA be used to have the IMAP server report the SIP server?
[17:17:15] <cyrus_daboo> NB dns-sd also has a wide-area discovery process being developed - i.e. not just local link anymore.
[17:17:41] <ted> That's much less baked, though, right cyrus?
[17:17:57] <ted> bonjour has multiple interoperable implementations as a link local
[17:18:02] <cyrus_daboo> Yes - still 'experimental' but there is working code.
[17:18:10] <neilcookster> I think the link to the IMAP server linkage is v important, as I can well imagine IMAP servers that are deployed only to accept URLFETCH from certain media servers
[17:18:24] <neilcookster> So need either explicit or implicit discovery
[17:18:37] <alexeymelnikov> Ray: I would prefer if METADATA is used. If this is the way the WG is going to do discovery.
[17:18:57] <cyrus_daboo> I think I would want a way to tell my IMAP server to accept a local media server at the location I am currently at as being 'OK'.
[17:19:28] --- ted has left
[17:19:40] <cromwellian> i can imagine an entry like /mediaserv, with parameter "servers.shared" that returns a list of SIP servers authorized for URLFETCh
[17:19:49] <fanf> configuring of related servers is a really bad weak point of current MUAs
[17:19:51] <pguenther> suggestions to the list...
[17:20:12] <neilcookster> Yes, all suggestions gratefully received, esp if they use an existing mechanism
[17:20:30] --- pluscom has joined
[17:20:33] <neilcookster> METADATA can give server-wide response?
[17:20:37] <pguenther> Randy: comments for tomorrow:
[17:20:39] <cromwellian> i must say tho I like bonjour for the cool factor
[17:20:42] --- Barry Leiba has left
[17:20:45] <pguenther> - no good reasons to disable compress
[17:20:52] --- pluscom has left
[17:21:02] <pguenther> - no need to negotiate directions separetly
[17:21:02] <cromwellian> yes, there are both mailbox and server-wide annotations
[17:21:07] <neilcookster> cool
[17:21:17] <pguenther> - need to reset dictionary? may depend on algo
[17:21:19] <cromwellian> /motd the message of the day is an example
[17:21:45] <pguenther> - - for virt mailbox: MUST have multiple backing mailboxes to be useful
[17:22:29] --- smaes has left
[17:22:37] --- alexeymelnikov has left
[17:22:40] --- cyrus_daboo has left
[17:22:42] --- xiaodong has left
[17:22:48] --- Jerry Shih has left
[17:23:01] --- cnewman@jabber.org has left: Logged out
[17:23:07] --- NFreed@jabber.org has left: Logged out
[17:23:08] --- eburger has left
[17:23:10] --- arnt has left
[17:23:13] --- cromwellian has left
[17:23:26] --- resnick has left
[17:23:30] --- tonyhansen has left
[17:23:31] <Glenn Parsons> We are adjourned for today
[17:23:41] --- Mike Parsel has left
[17:23:42] <Glenn Parsons> We will resume at 1pm ET tomorrow
[17:28:44] --- neilcookster has left
[17:29:14] --- lemonade has left: Computer went to sleep
[17:29:16] --- Randy Gellens has left: Logged out
[17:39:37] --- frodek has left
[17:54:14] --- Glenn Parsons has left
[17:55:54] --- pguenther has left
[18:15:36] --- Dave Cridland has left
[19:00:30] --- LOGGING STARTED
[19:04:46] --- greg.vaudreuil has joined
[19:06:30] --- fanf has joined
[19:38:05] --- kmurchison has joined