sipping@conference.ietf.jabber.com - 2002/11/20
[13:41] %% DigiMojo has arrived.
[13:42] %% andersa has arrived.
[13:43] %% leifj has arrived.
[13:45] <DigiMojo> draft status
[13:46] %% agaton has arrived.
[13:46] %% TonyHansen has arrived.
[13:51] %% TonyHansen has left.
[13:51] %% CTHD has arrived.
[13:51] %% TonyHansen has arrived.
[13:53] %% fluffy has arrived.
[13:53] <fluffy> Eric Burger at MIc
[13:57] <DigiMojo> Robert Sparks @ mic
[13:58] <DigiMojo> discussing who owns rate limiting reqts
[14:04] <DigiMojo> Sean ? at mic
[14:07] %% CTHD has left.
[14:08] %% TonyHansen has left.
[14:08] %% TonyHansen has arrived.
[14:09] <DigiMojo> Jonathan drops laptop!
[14:09] <DigiMojo> rubber necking starts
[14:09] <DigiMojo> laptop reported dead
[14:10] <DigiMojo> Jon puts his laptop way down low
[14:10] <DigiMojo> SIP-T
[14:11] <DigiMojo> CPR effective
[14:11] <DigiMojo> laptop revived
[14:12] %% ietfwatch has arrived.
[14:12] %% CTHD has arrived.
[14:13] %% paf has arrived.
[14:14] <DigiMojo> Adam Roach at mic
[14:15] <fluffy> Rohan Mahy at mic
[14:16] <DigiMojo> Cullen@mic
[14:17] <ietfwatch> one way to cope worst case practce
[14:18] <DigiMojo> Allison - security flaws
[14:19] <DigiMojo> Adam Roach@mic
[14:20] <fluffy> Keith D at mic
[14:23] <fluffy> Can you connecto to room from your own jabber server - that seemed to work yesteryday but Robert seems to be having problems with it today
[14:24] <DigiMojo> Henning Schulzrinne at mic
[14:28] %% RjS has arrived.
[14:28] %% RjS has left.
[14:29] <DigiMojo> Adam Roach - identity mapping discussion for SIP-T
[14:29] %% RjS has arrived.
[14:29] <DigiMojo> Allison@mic
[14:30] <DigiMojo> Jonathan at mic
[14:31] <DigiMojo> Keith D. on sip-q.931 mapping
[14:31] <fluffy> Mary Barns was at the mic
[14:35] <fluffy> Eric B at mic
[14:36] <DigiMojo> Allison at mic on wg charter non-goal of sip-q931 mapping
[14:37] <DigiMojo> Eric B - shamless plug
[14:38] <CTHD> Andrew Bender was at the mic
[14:38] <DigiMojo> Francois at mic now
[14:40] %% EricCheung (Coordinator) has arrived.
[14:40] %% EricCheung (Coordinator) has left.
[14:40] %% EC has arrived.
[14:40] <DigiMojo> that's better
[14:40] <EC> i am NOT coordinating. can't type fast enough
[14:41] <DigiMojo> Jon at mic
[14:43] %% dmarlow has arrived.
[14:44] <DigiMojo> early media hum
[14:47] <DigiMojo> nice screen saver
[14:48] <DigiMojo> not as interesting as Jonathan's laptop
[14:49] <DigiMojo> Rohan on Message Waiting Indication
[14:50] <DigiMojo> Henning at mic
[14:51] <DigiMojo> align mwi with events work?
[14:53] <DigiMojo> Eric B at mic
[14:53] <DigiMojo> EB - turn on the blinky light
[14:54] %% mrose has arrived.
[14:55] <fluffy> Henry S at mic
[14:55] <DigiMojo> Henry Sinnreich at mic
[14:57] <DigiMojo> Alan Johnston - transfer draft
[15:01] <DigiMojo> Jonathan R at mic
[15:02] <DigiMojo> on globally routable URIs
[15:06] %% LisaDusseault has arrived.
[15:06] %% LisaDusseault has left.
[15:07] <DigiMojo> Mary Barnes - call history
[15:13] %% mrose has left.
[15:14] %% DigiMojo has left.
[15:17] %% mrose has arrived.
[15:29] %% CTHD has left.
[15:30] %% EC has left.
[15:32] %% mrose has left.
[15:35] %% leifj has left.
[15:39] %% buffy has arrived.
[15:45] %% buffy has left.
[15:45] %% RjS has left.
[15:45] %% ietfwatch has left.
[15:58] %% andersa has left.
[16:01] %% TonyHansen has left.
[16:01] %% fluffy has left.
[16:04] %% paf has left.
[16:09] %% agaton has left.
[17:24] %% TonyHansen has arrived.
[17:26] %% TonyHansen has left.
[17:37] %% dmarlow has left.
sipping@conference.ietf.jabber.com - 2002/11/21
[07:08] %% arjunrc has arrived.
[07:09] <arjunrc> hmm jabber conference rooms are funny - or maybe my jabber client is messed up
[10:24] %% TonyHansen has arrived.
[11:05] %% SandyTurner has arrived.
[11:06] %% RjS has arrived.
[11:06] %% fluffy has arrived.
[11:06] <fluffy> We are getting going
[11:06] %% muonzoo has arrived.
[11:06] * muonzoo has changed the subject to: Introduction
[11:06] <arjunrc> ah I see life, finally
[11:07] <muonzoo> IEPREP Discussion
[11:08] %% chtd has arrived.
[11:10] <arjunrc> looks like jabber users cannot see any SIMPLE users in contacts
[11:10] %% d has arrived.
[11:11] %% kc has arrived.
[11:13] %% JavierA has arrived.
[11:13] %% JavierA has left.
[11:13] <muonzoo> There doesn't appear to be presence connectivity at the SIMPLE gateway...
[11:14] <TonyHansen> so it's an im: gateway, but not a pres: gateway
[11:14] <arjunrc> yep - I guess so - in the meantime , Im trying to login to this session using iptels SIMPLE gw from Messenger - hopefully I can see who all is here then
[11:15] %% bacampbe has arrived.
[11:15] %% hanzzz has arrived.
[11:16] <fluffy> Is anyone on the list that is not in the room?
[11:16] <d> yep
[11:17] <fluffy> Hi [d] - are you listening to the mbone stream too or just follwing the IM. I'm trying to get a feel for how people use this. Thanks
[11:17] <d> i'm in manet; just watching on jabber
[11:18] <arjunrc> how does one listen to the mbone stream from a jabber client ?
[11:18] <fluffy> I don't think you can - I think you would need to set up a separate mbone client for that
[11:18] <arjunrc> k
[11:19] %% LisaDusseault has arrived.
[11:19] <d> yeah, i don't think jabber is up to an rtp gateway :-)
[11:20] <arjunrc> what client are the SIMPLE folks using ? iptel doesnt seem to be accepting REGISTERs from messenger - although I have an acct. with iptel
[11:21] <fluffy> I'm using MSN Messenger
[11:21] <muonzoo> From the IETF multicast page:
Information on how to receive multicast can be found at: http://www.ietf.org/audio//ietf55.html
[11:22] <arjunrc> Cullen: is your sign-in name in MSN fluffy@iptel.org or just fluffy ?
[11:23] <muonzoo> Fluffy @ mike
[11:23] <muonzoo> (mic)
[11:24] %% rafdalb has arrived.
[11:24] <fluffy> Just a sec - have to follow meeting
[11:25] <fluffy> http://www.iptel.org/ietf55/use_msn.html says how to use MSN with IPTEL to get to jabber
[11:26] %% eburger has arrived.
[11:27] <fluffy> Jonathan @ mic
[11:29] %% SandyTurner has left.
[11:33] <fluffy> Moving on to Conf Design Team
[11:34] %% kc has left.
[11:35] %% bacampbe has left.
[11:37] %% muonzoo has left.
[11:37] %% adamroach has arrived.
[11:38] %% bacampbe has arrived.
[11:40] * TonyHansen has set the topic to: Transcoding for the hard of hearing
[11:41] <adamroach> Gonzalo: making sure transcoding fits in OPES infrustucture
[11:42] <adamroach> Working on B2BUA model for transcoding
[11:42] %% eburger has left.
[11:42] <adamroach> Three options considered: Route header, message encapsulation, and REFER.
[11:42] <adamroach> Current proposal: use REFER.
[11:43] <adamroach> While it uses more signalling, it takes advantage of current REFER security work, and it more in line with OPES goals.
[11:44] <adamroach> Discussion at mic: clarification that common application is human-performed
[11:44] <adamroach> Comment at mike: it would be useful to have language transcoding with multiple streams delivered to endpoints.
[11:44] <adamroach> Call for solution team to work on more general requirements.
[11:45] <adamroach> kdrage: We seem to be jumping from requirements for deaf transcoding to requirements for general transcoding.
[11:46] <adamroach> kdrage: this might be premature. 3GPP R6 has requirements for doing automated transcoding from one codec to another.
[11:46] <adamroach> kdrage: If we're going to make these more general, we should publicise it more widely.
[11:47] <adamroach> Rohan found someone to make an announcement along these lines to the mailing list.
[11:47] <adamroach> Back to the presentation.
[11:47] * TonyHansen has set the topic to: Plumbing draft
[11:47] <adamroach> Talking about "source-sink" draft.
[11:47] <adamroach> Gonzalo: Some question about whether this draft is necessary at all.
[11:48] <adamroach> jdr: this seems to be too complicated
[11:49] <adamroach> Back to presentation of what motivates this draft.
[11:49] <adamroach> Unfortunately, it's mostly visual, so scribing the conversation is nearly impossible.
[11:50] <adamroach> jdr: the conferencing design team has already been working on policies for media policy, which basically what this draft covers.
[11:50] <fluffy> Unless you do typescripts for a living, there is no hope on keeping the conversation up on the IM system
[11:50] <adamroach> jdr: we can add transcoding to the conferencing media policy work.
[11:50] <adamroach> Yeah, but I think I can capture the essence. :)
[11:51] <adamroach> rmahy: The fine line that distinguishes this from the conferencing work is that conferencing involves combining of media, while this work does not.
[11:52] <adamroach> (I'm missing some of the comments here)
[11:52] %% eburger has arrived.
[11:52] <adamroach> jdr: before we do more work, this team and the conferencing team need to coordinate.
[11:53] <adamroach> gonzalo agrees with this proposal.
[11:53] <fluffy> Gee adam - you edited my comments out :-)
[11:53] <adamroach> I was about to yell "mike" before you sat down.
[11:53] <adamroach> I couldn't hear a word you said.
[11:53] <fluffy> Moving on to the App Interaction stuff
[11:54] <adamroach> jdr: Yes, I dropped my laptop *again*, but it still works.
[11:54] * TonyHansen has set the topic to: App Interaction design team
[11:55] <adamroach> App Interaction team: fluffy, eburger, robert farlie-cunningham, jdr
[11:55] <RjS> The name of the design team is "Stimulation with SIP!"
[11:55] <adamroach> Doing stimulus protocol with SIP
[11:55] <adamroach> Covering media, markups, DTMF.
[11:56] <adamroach> This is a unified effort to merge various efforts at stimulus extensions.
[11:56] <adamroach> Done framework doc: app-interaction-00
[11:56] <adamroach> Keypad markup language (burger-sipping-kpml)
[11:57] <adamroach> jennings-sipping-app-info (SIP extensions for the framework)
[11:57] <adamroach> culpepper-sipping-app-interact-reqs (requirements document)
[11:57] <adamroach> jennings document defines "App-Info" header
[11:57] <adamroach> Discussion of open issues.
[11:58] <adamroach> Debate: philosophical issues with sending keypress events and application semantics
[11:58] <adamroach> (Not real-time debate, just assertion that such debate exists)
[12:00] <adamroach> Other debate exists: Should stimulus events be sent via SIP or HTTP?
[12:01] <adamroach> Arguments for each approach are offered.
[12:02] <adamroach> HTTP has consistency with previous approaches (e.g. WML, VXML, HTML), and is inherently synchronous.
[12:02] <adamroach> SIP handles the nature of security necessary better, provides correct routing, and some quarrantine-related issue that isn't exactly clear to me.
[12:03] <adamroach> eburger: interface between API and app is a red herring.
[12:03] <adamroach> (I kind of missed the argument)
[12:04] <fluffy> It is a larger argument - I'm sure it will make it to the list
[12:04] <adamroach> Yes, it was just defered to the list, as far as I can tell.
[12:04] <adamroach> No additional comments on those issues.
[12:04] <adamroach> Next slide: Focus determination for KPML
[12:05] <adamroach> Issue: when a user enters a digit, how can you tell which application receives information?
[12:05] <adamroach> Current proposal is to send it to every application that has expressed interest.
[12:06] <adamroach> Argument is that this is on par with what the PSTN does with DTMF.
[12:07] <adamroach> Demultiplexing between various apps could also be handled by a central coordinating application in the network.
[12:07] <adamroach> No comments.
[12:07] <adamroach> No, actually, a comment.
[12:08] <adamroach> alex chung: if there is a way to do this, e.g., in the simple cases, do you think you would incorporate them?
[12:08] <adamroach> jdr: we will always consider ideas.
[12:08] %% eburger has left.
[12:09] <adamroach> Next topic: error reporting for App-Info
[12:09] <adamroach> What do we do if the App-Info URI is invalid?
[12:09] <adamroach> In a request, of course, the request can be rejected with an error code.
[12:09] <adamroach> In responses, though, this is not possible.
[12:10] <adamroach> Must go to mike.
[12:10] <LisaDusseault> I'll do logging for a while.
[12:10] <fluffy> Rohan @ mic
[12:10] <LisaDusseault> [Jon] Error reporting is tough. Our options are no error reporting, reject the request, or have an error reporting URI. You can have infinite recursion.
[12:11] <LisaDusseault> [Rohan] I want to make clear we think this can be an arbitrary URL, not just a HTTP URL. It's saying, go run the app you find at this URL.
[12:11] <LisaDusseault> [Jonathan] Yes, there's a markup document at this URL you're going to need.
[12:11] <LisaDusseault> [Rohan] HTTP is a baseline minimum to support thing.
[12:11] <LisaDusseault> [Jonathan] This isn't a REFER replacement. Don't anybody get any funny ideas!
[12:12] <LisaDusseault> [Adam] This is a ? more than an invite.
[12:13] <adamroach> Sorry...
[12:13] <adamroach> General nature of my comment is: if you send App-Info in a non-INVITE request, you can't send an error response.
[12:13] <adamroach> Reason being: doing so requires you to fetch URL before responding to request...
[12:14] %% ec has arrived.
[12:14] <adamroach> ...but that requires you to keep transaction open for longer than is safe, leading to bad timeout situations.
[12:14] <adamroach> Sean Olson: Have you considered using URNs instead?
[12:14] <adamroach> (brief discussion follows, taken offline)
[12:14] <adamroach> Next Issue: indicating script termination.
[12:15] %% randy has arrived.
[12:15] <adamroach> How to you communicate to the network application that the client application has been closed?
[12:15] <adamroach> must go to mike again.
[12:15] <LisaDusseault> [Jonathan] In the IVR world, this works with timers on the server side.
[12:16] <LisaDusseault> [At side mic] If there's a way to do this, it would be good. But it may be too hard.
[12:16] <LisaDusseault> [Jonathan] You get the browser start, you get the page there, and you dismiss it. Changing the way the browser works is not an achievable goal.
[12:16] <LisaDusseault> [side mic] In this case the application is actually tied to whatever ui is being displayed. Logically it seems part of the same transaction. We can discuss this on the list.
[12:17] <LisaDusseault> [Cullen] Analogy between whether you're trying to exit the app or terminate it. It's analogous to when you close one window, and another pops up. It's possible to create the voice equivalence of this. Could be bad idea.
[12:18] <LisaDusseault> [Adam] Quick question for stimulus protocl -- wouldn't closing the window be a stimulus and deal with it correctly?
[12:18] <LisaDusseault> [Jonathan] Does HTML have an event on close?
[12:18] <LisaDusseault> [Rohan] JavaScript "onClose" is how those awful popups happen.
[12:19] <LisaDusseault> [Jonathan] If they can do that, we can too, detect the closure via javascript.l How many phones want to support JavaScript. I don't even know what that would mean in KPML.
[12:19] <fluffy> Eric B at mic
[12:19] <LisaDusseault> [Eric] Eitehr you're on a real browser, or you're not, if you're not, it's not useful.
[12:19] <fluffy> Paf at mic
[12:20] <LisaDusseault> [Patrik] I tried to read this at the same time you were talking. If you take a step back, to understand what you have problems with, it matters who is the active party in this connection between client and server. That's mixed up with whether the client supports local or remote, which means different things passing over the keyboard, application, connection.
[12:20] %% DigiMojo has arrived.
[12:20] <LisaDusseault> [Patrik] On top of that, if both app and user can initiate events, and on top of that, you'd like the app to instruct the user what kind of profile of all of those phone functions.. that together is really complcicated to build.
[12:20] <LisaDusseault> [Patrik] My suggestion is you sit down with the guys doing the ??? protocol.
[12:21] <adamroach> IMAP
[12:21] <adamroach> (I think)
[12:21] <LisaDusseault> [Patrik] You can get more input from talking to those kind of people.
[12:21] <LisaDusseault> [Jonathan] We just want to pass it off to HTTP/Script and get back to SIP when that's done.
[12:22] <DigiMojo> Question: Couldn't two applications both simultaneously ask the UA to render a page - with forking?
[12:22] <LisaDusseault> [Patrik] HTTP has a verry specific way of working which might not be able to sovle your problems here. Your requirements built on user scenarios should be passed by people who have done this before.
[12:22] <LisaDusseault> [Eric] A lot of it is problem statement.
[12:23] <adamroach> DigiMojo: I can take your question to the mike, but I don't quite understand it yet.
[12:23] <LisaDusseault> [Eric] We want to get it started somehow, get the client to initiate a HTTP request. Then we want it to just work -- just be HTTP.
[12:23] <DigiMojo> I'm here so could go to mic - I'm not sure enough myself, else I would go to mic
[12:24] %% agaton has arrived.
[12:24] <DigiMojo> Is there "early media" for AppInfo header related interactions?
[12:24] <LisaDusseault> [Patrik] HTTP has much baggage, anyone to actually read and implement -- be a little bit careful. The point is HTTP is created for a very simple app where the client knows what it wants, sends a request, gets it back, full stop.
[12:24] <LisaDusseault> [Patrik] There is no callback, session, notification.
[12:25] <LisaDusseault> [Patrik] Some additions are in HTTP 1.1. If they were to start over again... it might not be so simple, might be a more complicated protocol. People do want server generated events. The app must be able to initiate events like a prepaid calling card running out of money.
[12:25] <LisaDusseault> [Patrik] I'm not saying HTTP is stupid.
[12:25] <LisaDusseault> [Patrik] If you use something for a purpose it's not designed for -- trouble.
[12:25] <d> it's SNAP all over again
[12:25] <LisaDusseault> [Jonathan] Sending the URL to the client in the SIP message, from there on it's HTTP. We have requirements to do these things you describe, but it seems you can fill in the holes in HTTP with SIP.
[12:26] <LisaDusseault> [Patrik] Her'es the 10000$ question. If you have a session setup, is it the case both sides can send events whenever?
[12:26] <LisaDusseault> [Jonathan]Any side can send whatever at any time.
[12:27] <DigiMojo> Could AppInfo URI appear in 18x response? I haven't read the draft.
[12:27] <LisaDusseault> [Rohan] If I have used invite to establish a dialog, each side can send a message to update or terminate it. If I have an existing dialog, and somebody wants to start another dialog, they can. There is some mechanism to prevent race...
[12:27] <LisaDusseault> [] rest of discussion brought offline.
[12:27] <LisaDusseault> or as Harald asked us to say "to the mailing list".
[12:27] <adamroach> DigiMojo: I'm not sure; there was discussion of not including it at all in responses...
[12:27] <fluffy> Switching topic to Barge
[12:28] <LisaDusseault> [Jonathan] In the voice over IP world, we can get zero-latency barge in with this framework.
[12:28] <LisaDusseault> [Jonathan] There are KPML scripts at the end point, with a flag that says stop playing out media.
[12:28] <DigiMojo> Adam, I'm Hal Purdy - I'll find you/Jonathan later and discuss these issues - seems like a PSTN feature interaction problem translated to the new world.
[12:28] <LisaDusseault> [Jonathan] As a result, there's no network communication, and the latency can be better than a packet switched network.
[12:29] <LisaDusseault> [Jonathan] A problem is to figure out how to start playing media again.
[12:29] <LisaDusseault> [Jonathan] It's a media stream synchro'n problem.
[12:29] <LisaDusseault> [Jonathan] We have the same change sychronizing codec changes.
[12:30] <LisaDusseault> [Jonathan]RFC3264 payload changes works there, works here. We don't know if htere are others.
[12:30] <DigiMojo> Eric B at mic
[12:30] <LisaDusseault> [Eric] If markup bits are inserted by the server, every server in the world would have to do that.
[12:30] <LisaDusseault> [Eric] Because, how do you know, it's just a bunch of RTP?
[12:30] <LisaDusseault> [Eric] How do you get the markup bits into the RTP?
[12:31] <LisaDusseault> [left mic] THe problem of when to start and stop new media is the server problem. This 'barge' would indicate the client post the results and that's good enough.
[12:32] <LisaDusseault> [Jonathan] The client has pushed a button that gets sent to the server, and the server stops playing the media. But also the client, without even talking to the server, stops. New media shows up from the server. How does the client know if this is a continuation of the old media?
[12:32] <LisaDusseault> [Bert] Maybe just throw this away [paraphrased] maybe you don't need it.
[12:32] <LisaDusseault> [Jonathan] Here, we have the ability to make a feature that would make ? go to zero. Is it useful? [Eric] Would it be done?
[12:33] <DigiMojo> Eric Cheung at mic
[12:33] %% qzhou has arrived.
[12:33] <LisaDusseault> [Eric C] THe other thing you could do is before the application plays it asks the server if it should play again. This is still a quick-stop solution.
[12:33] <LisaDusseault> [Eric] This assumes the stop is coming from the application.
[12:33] <fluffy> Eric are you in IM
[12:33] <LisaDusseault> [that last was Eric B, not Eric C]
[12:34] <LisaDusseault> [Jonathan] What would be useful for people to do: 1. Read it. 2. Address the scope.
[12:34] <DigiMojo> fluffy: Eric is on IM here - this is Hal
[12:34] <LisaDusseault> [Jonathan] There's a whole lot of things provided by this-- should it do that.
[12:34] <LisaDusseault> [Jonathan] Comment on it.
[12:34] <DigiMojo> nm, i see you're chatting
[12:34] %% chtd has left.
[12:34] <LisaDusseault> [Eric B] How about a humm to get rid of hookflash?
[12:35] %% ironm has arrived.
[12:35] %% qzhou has left.
[12:35] <LisaDusseault> [Bert] I'd like to have an answer. One of your slides said KPML was a black phone. There's network architectures that dn't have a solution. If we handle it or let them do it for themselves, it would be nice to have more thoughts about what are we going to do.
[12:35] <LisaDusseault> [Rohan] Let's make sure we really agree what requirements motivate this.
[12:36] <LisaDusseault> [Rohan] Start discussion on specific paragraphs on the list. Not enough people have read the draft to make a decision here.
[12:36] %% qzhou has arrived.
[12:36] %% muonzoo has arrived.
[12:37] <adamroach> Next presentation; Q.SIG presentation
[12:37] <adamroach> (Q.SIG to SIP mapping)
[12:37] * TonyHansen has set the topic to: Q.SIG
[12:37] <adamroach> Jon Peterson is presenting
[12:38] <adamroach> [Jon] People seem generally supportive of this draft. Yesterday's conversation seemed to point to a desire to do a Q.SIG to Q.931 mappinng.
[12:38] %% TonyHansen has left.
[12:38] <adamroach> [Jon] New version of the draft is available: does some P-Asserted-Identity when maping to CLIP/CLIR.
[12:39] %% fsolensky has arrived.
[12:39] <adamroach> [Jon] Alson strengthened some security text, borrowed from SIP-ISUP mapping draft
[12:39] <adamroach> [Jon] No additional substantive changes.
[12:39] <adamroach> [Jon] Some ongoing discussion for mapping 180 status code to alerting.
[12:39] %% TonyHansen has arrived.
[12:40] <adamroach> [Right Mic] Elwell says consensus has been reached on this topic, and that it will be close to what is currently in SIP-ISUP draft.
[12:40] <adamroach> [Right Mic] These changes should appear in a future version of the draft.
[12:40] <adamroach> [Jon] This is not currently a WG item.
[12:41] <adamroach> [kdrage] Note: it's QSIG, not Q.SIG
[12:41] <adamroach> [Jon] Any more substantal comments?
[12:41] %% eburger has arrived.
[12:41] <adamroach> [Right Mic] What type of document would we be considering? BCP? Informational?
[12:41] <eburger>
[12:41] <adamroach> [Jon, Gonzalo] Informational
[12:42] %% randy has left.
[12:42] <adamroach> [Jon] The ISUP draft was not informational due to the places we expected it ot be referenced.
[12:42] <adamroach> [missed name, affliation] expectation of (other standards group) is that it will be informational.
[12:43] <adamroach> [Rohan] no recollection of what the WG has decided on this work, can't find in minutes.
[12:43] <adamroach> [Rohan] Taking hum: should we make this working group item?
[12:43] <adamroach> strong hum in favor.
[12:44] <adamroach> Next topic: iSIP: iTIP over SIP and using iCalendar with SIP
[12:44] <adamroach> (Pekka Pessi presenting)
[12:44] %% hanzzz has left.
[12:44] * DigiMojo has changed the subject to: iCalendar, iTIP
[12:45] <adamroach> [Pekka] What is iCalendar and iTIP?
[12:45] <adamroach> [Pekka] iCalendar is based on vCalendar; RFC822-like syntax.
[12:45] <fluffy> We skipped the "What is SIP" slide
[12:46] <adamroach> [Pekka] Has primitives for event, free/busy, timezone, todo list, and journal entries.
[12:46] <adamroach> iCalendar usage with SIP: can be used for offline invitations to future conferences
[12:46] <adamroach> Can be used to describe SIP-inititated teleconferences.
[12:46] <adamroach> Can be used to define roles (e.g. chairs, participants, conference server, etc)
[12:47] <adamroach> Can indicate schedule and timezone.
[12:47] <adamroach> Can provide notifications related to a conference.
[12:48] <adamroach> Proposal: cary iTIP methods in SIP IM requests
[12:48] <adamroach> Primarily, will use SIP URIs instead of mailto: URLs.
[12:49] %% arjunrc has left.
[12:49] <adamroach> current draft proposes using XML format for iCalendar.
[12:49] %% davidoran has arrived.
[12:50] <davidoran> just showed up - what is the name of this draft?
[12:50] <adamroach> We want extensibility, but xCal uses DTD instead of schema, which makes it difficult. Would use of RFC2445 format be appropriate?
[12:51] <adamroach> [Pekka] Should this go to SIP/SIPPING, or to CALSCH?
[12:51] <adamroach> [Pekka] Current beleif is CALSCH, since it doesn't change SIP.
[12:52] <adamroach> Dave: draft is http://www.ietf.org/internet-drafts/draft-pessi-calsch-isip-00.txt
[12:52] %% arjunrc has arrived.
[12:53] %% LisaDusseault has left.
[12:53] %% LisaDusseault has arrived.
[12:55] <adamroach> [Rohan] Using e-mail or IMAP to exchange information with others isn't always feasible. In an isolated network that allows ad-hoc connectivity (e.g. IR or bluetooth), this functionality is useful.
[12:55] <adamroach> [Rohan] I want to be able to exchange calendar information in ways other than mail.
[12:56] <adamroach> [Sean] It's pretty clear how this would be used in an IM.
[12:57] <adamroach> [Rigth Mic] (seems to be concerns about backwards compatibility)
[12:57] %% arjun_roychowdhury has arrived.
[12:58] <adamroach> [jdr] This is just a mime type, right? If so, yeah, you can just send it and the recipient can send it to the right application to process it.
[12:58] <adamroach> [jdr] So, the claim that there is a need to provide a mapping concerns me.
[12:58] %% arjun_roychowdhury has left.
[12:58] <adamroach> [Rohan] There's nothing that you need to do in SIP to handle this object; however, many objects are optimised for the underlying transport.
[12:59] <adamroach> [Rohan] but, for example, with SIP, we have no 7-bit limitations.
[13:00] %% d has left.
[13:00] <fluffy> Lisa put in a comment , then Dean W
[13:00] <adamroach> [Lisa] If CAP is involved in telling people interesting events -- like "you have a meeting shortly" - it may not be the right thing to maintain a persistent connection to the client to give those events. It would be good to have an event package showing how to deliver calendaring events via SIP.
[13:01] <adamroach> [Dean] The capability to send this sort of information to a set of SIP phones capable of scheduling themselves to a teleconference could be quite useful.
[13:01] %% davidoran has left.
[13:02] <adamroach> Question: is this something SIPPING should do?
[13:02] <adamroach> [Rohan] It's out of scope. I wanted it presented here to bring attention to it, but it's out of our scope.
[13:02] %% rafdalb has left.
[13:02] <adamroach> [Rohan] Taking this work up would be a CALSCH issue.
[13:03] %% RjS has left.
[13:03] <DigiMojo> thanks, Adam, Lisa
[13:03] <adamroach> [Rohan] That's it! See you in San Francisco.
[13:03] %% ironm has left.
[13:03] %% ec has left.
[13:03] %% fluffy has left.
[13:03] %% LisaDusseault has left.
[13:03] <bacampbe> :leave
[13:03] <bacampbe> :quit
[13:03] <arjunrc> gee how come there were no logs for the conferencing design team drafts ?
[13:04] <adamroach> Ben and I are stuck. How to you unjoin?
[13:04] <bacampbe> To someone using the iptel.org gateway, how do you leave the room?
[13:04] <arjunrc> ":exit"
[13:04] <bacampbe> :bye
[13:04] <adamroach> Thanks.
[13:04] <bacampbe> thanks
[13:04] <qzhou> :exit
[13:04] %% bacampbe has left.
[13:04] %% qzhou has left.
[13:05] <adamroach> Arjun: I thought a scribe was assigned already. When I realized that it wasn't happening, I started.
[13:05] %% DigiMojo has left.
[13:05] <adamroach> The minutes should still reflect that part of the meeting.
[13:05] <arjunrc> adam: darn - I was waiting all this while for the conf-design team discussions:-((
[13:05] %% adamroach has left.
[13:06] %% arjunrc has left.
[13:06] <TonyHansen> :exit
[13:07] <TonyHansen> :bye
[13:07] %% TonyHansen has left.
[13:09] %% arjun_roychowdhury has arrived.
[13:10] %% eburger has left.
[13:11] %% fsolensky has left.
[13:14] %% muonzoo has left.
[13:20] %% agaton has left.
[13:20] %% arjun_roychowdhury has left.
[14:20] %% john loughney has arrived.
[14:21] %% john loughney has left.