calsch@conference.ietf.jabber.com - 2002/11/20
[07:17] %% mrose has arrived.
[07:19] %% tbamonti has arrived.
[07:19] %% tbamonti has left.
[07:20] %% leg has arrived.
[07:20] <leg> aha, "calsch", not "calsched"
[07:20] <leg> not that anyone is here
[07:21] <leg> next up: draft-pessi-calsch-isip-00
[07:25] %% gbabics has arrived.
[07:27] <leg> not sure who is presenting
[07:27] %% gbabics has left.
[07:27] <leg> currently a "introduction to SIP"
[07:27] %% gbabics has arrived.
[07:27] %% leg has left.
[07:28] %% jaym has arrived.
[07:28] %% leg has arrived.
[07:28] %% leg has left.
[07:28] %% leg has arrived.
[07:29] <leg> now "iCalendar usage with SIP"
[07:29] <leg> off-line invitations, describing the SIP conference, etc.
[07:29] <jaym> story so far as I have in my very raw and rough notes:
Wanting to get the WG wrapped up. Final proofread of CAP needed. That is the most important focus as it is the on-the-wire protocol. xCal draft is the other draft. xCal draft is a hot topic. Hopefully it will be nothing more than a representation of the iCal grammer. Two other drafts: Skee-Cal draft as an individual submission, also draft-pessi-calsch-isip-00.txt. CAP draft is the focus of the WG. http://www.ietf.org/internet-drafts/draft-ietf-calsch-cap-09.txt
Had intended to have a physical interop testing, did not come together, did come out as a virtual test though and worked out fairly well. IBM/Lotus, Oracle/Steltor, Novell, and KOrganizer. Most folks were able to exchange large number of objects. Two vendors were able to exchange ALL objects. Need better matrix volunteers for 2445, 2446, 2447 to identify all of the MUST, SHOULDS, etc. **Looking for volunteers to get the matrix put together.** A second interop in spring is planned. Novell has volunteered to host in Utah.
New Java based iCalendar parser: http://www.sourceforge.net/projects/jical which it extends Evolution & Mozilla by enabling server-based group scheduling between evo & Outlook.
Drop chairs a note if interested in working on drafts or helping out. They are looking for assistance
[07:31] <leg> now "iSIP: mapping iTIP to SIP"
[07:31] <leg> modelling the mapping to e-mail (iMIP)
[07:31] %% tbamonti has arrived.
[07:39] %% jaym has left.
[07:39] %% jaym has arrived.
[07:41] %% leg has left.
[07:41] %% leg has arrived.
[07:42] <jaym> please pardon my VERY raw notes... but here are my notes on the iSIP:
SIP needed a way to schedule conferences, off-line invitations to ugture events, iSIP is very similar to iMIP. Crry iTIP methods in SIP instant messages (SIP MESSAGE requests) AllowiTIP PUBLISH methods in any SIP message. Use MIME but no Content-Transfer-Encoding. Use SIP URLS instead of MAILTO: URLs. Other URL schemes could be used as we ll. Tel: or im: . Draft proposes using XML iCalendar format with SIP. XML is already widely used with SIP applications. xCal could be included in other XML documents. . But now we are wiser. Extensible XML format require XML schema but xCAL DTD. iSIP and Current CALSCH work. No changes to 2445/6. No conflict with CAP. In the future iSIP apps may add parameters. Open Issues and Future Work: Working group or individual work in CALSCH? Submit new draft using standard iCalendar format? Specify iSIP applications separately. iCalendar for on-line conferences and iCalendar notifications. Comments to taking work to CALSCH group: BH: ADs want product from CALSCH, so probably not able to take it on in CALSCH. SIPPING has requirements gathering for conferencing, but expertise is here in CALSCH.
[07:42] <jaym> BTW: I am NOT the official scribe, so I'm sure their notes will be better.
[07:45] <mrose> jaym: thanks! keep up the good work.
[07:50] %% swb has arrived.
[07:50] <swb> Wow, excellent reporting (compared to other rooms)
[07:52] %% leg has left.
[07:56] %% leg has arrived.
[07:56] <leg> wireless seems to suck here
[07:57] %% jaym has left.
[07:57] <leg> current discussion: should servers be required to support parallel operation on different BEEP channels?
[07:58] <leg> chris newman is favor of requiring parallel operations
[07:58] <leg> larry greenfield thinks it would be a barrier to implementation
[07:58] <leg> patrik f things that this is a good thing to think about
[07:59] <leg> barry leiba: clients will do what they have to do regardless of whether servers want them to
[07:59] <mrose> could someone in the room summarize the beep issue, if there is a beep issue?
[08:00] %% leg has left.
[08:00] %% leg has arrived.
[08:01] <leg> i will if my network stays up long enough...
[08:02] <leg> should servers be required to treat different beep channels fairly or can an expensive operation on one block operations on others
[08:03] <mrose> leg: answer, beep says its an implementation issue. to conform to the standard, each channel must appear to be handled in parallel. in practice, a single-threaded server running on a uniprocessor can meet this requirement.
[08:03] <leg> newman issue #3: round trips are very expensive, pipelining should be mandatory, specifying what commands can be pipelined, etc.
[08:04] <leg> (will respond in a sec)
[08:05] <leg> newman issue #4: how to support different deletion models. "mark as deleted" versus "trashcan" model.
[08:06] <leg> IMAP has mark as deleted, but it doesn't interoperate well with the popular trashcan model. i wish we had done it differently in IMAP.
[08:06] <leg> pbh: good feedback on IMAP/CAP similiarities
[08:08] <leg> chair: little things in the draft will kill us; recently got some good feedback on the list on little inconsistencies and it's been helpful.
[08:09] %% jaym has arrived.
[08:09] <jaym> meeting over... course I had NO connectivity for the last bit there.
[08:11] %% jaym has left.
[08:11] <leg> marshall: it seems that BEEP servers may choose to answer requests in any order they want, which means that there isn't a requirement for useful parallism.
[08:12] <mrose> leg: we need to make sure we're using the same terms. if you're sending traffic over the same channel, then you're supposed to process them in serial order; if you're sending traffic over different channels, you're allowed to process them in parallel.
[08:13] <leg> you're _allowed_ to process them in parallel. the question is whether you should be required to do so.
[08:15] <leg> 2.6.2 in RFC 3080 seems to indicate to me that a server doesn't have to make progress on all channels.
[08:15] %% swb has left.
[08:16] <mrose> leg: no, you are not required to...otherwise you would be required to implement on multiprocessor or multithreaded servers
[08:18] <leg> but if a server just processes messages in order, clients may end up opening multiple TCP connections to get perceived parallelism.
[08:19] <mrose> leg: anyone who writes a client that opens up multiple beep sessions to the same service should be taken out and shot. one of the things beep gives you is that it allows the server the opportunity to do things in parallel.
[08:20] <mrose> leg: you are correct that 2.6.2 allows the responder to determine order (if any) to process requests from different channels.
[08:22] <leg> but if a server answers queries in the order they receive, clients will open multiple TCP connections to minimize perceived user latency. (long running searches versus a fast query.)
[08:24] <mrose> i doubt this will happen in practice. there is more overhead to starting up a beep session than an http connection. one reason this is okay, is you get to amortize the cost over the multiple transactions you're going to be doing over that one session.
[08:25] <leg> do you believe a POP client is allowed only one connection to a POP server?
[08:26] <mrose> i'm not sure what "allowed" means. i know that with many POP server implementations, the second server instance won't be able to lock the maildrop until after the first server instance receives a QUIT
[08:28] <leg> well, POP clients will do it (one to do the every n second mailcheck) and the other to download mail. so you can't underestimate the amount clients will do to get whatever they want.
[08:30] <mrose> sure, and eventually the unintended consequences become noticeable, but by then its too late to back out the problem. hence, better to try to get it right the first time
[08:30] <leg> so can we require servers to do the harder thing with parallel beep channels? that seems hard to require.
[08:33] <mrose> my point is that you should use just one beep session and let the server try to do things in parallel. no, the server doesn't have to do it in parallel, but good server implementations will.
[08:35] <leg> if any even remotely widespread server doesn't do it in parallel, clients will open multiple TCP sessions to get what they want. i agree with you a high quality server will do better---but can we prevent the low quality implementation?
[08:36] <mrose> can you prevent low-quality implementations, no? in fact, even if you mandated true parallelism, i'm sure that someone would ship a uni-threaded implementation and claim that it conformed.
[08:38] %% jaltman has arrived.
[08:56] %% LisaDusseault has arrived.
[08:56] %% LisaDusseault has left.
[08:57] %% leg has left.
[09:00] %% gbabics has left.
[09:05] %% jis has arrived.
[09:16] %% jis has left.
[09:20] %% tbamonti has left.
[09:40] %% mrose has left.
[09:49] %% jaltman has left.
[10:58] %% leg has arrived.
[10:58] %% leg has left.
[15:23] %% ietfwatch has arrived.
[15:23] <ietfwatch>
[15:23] %% ietfwatch has left.