Fwd: Proceedings from WebDAV from IETF-61

FYI

Begin forwarded message:

> From: Joe Hildebrand <jhildebrand@jabber.com>
> Date: December 10, 2004 10:26:59 AM PST
> To: proceedings@ietf.org
>
> <agenda>
> WebDAV IETF 61
> Washington, DC
> 2004-11-11
>
> Agenda
> ------
> - Agenda Bash
> - Process
>   - Bugzilla issue tracking:
>     http://ietf.webdav.org:8080/bugzilla/
>   - Closing issues
> - BIND
> - Redirect
> - QUOTA
> - CalDAV
> - WebDAV events
>    
> (http://www.jabber.org/~stpeter/ietf/draft-hildebrand-webdav-notify 
> -00.html)
> - PATCH
> </agenda>
>
> <notes>
> (11:07:59) Julian Reschke: Jim: I agree that RFC2518bis should  
> integrate all clarifications that are needed to explain behaviour in  
> presence of multiple bindings. For simplicity, I'd still prefer to  
> leave authorabilty of new bindings for a separate doc.
> (11:08:02) lisa: It did mention a few possibilities, like the  
> possibility for multiple bindings, but that doesn't mean it really  
> "defined" bindings.
> (11:08:22) ***pguenther is playing the role of note taker
> (11:08:39) pguenther: agenda bashing: add a calDAV report
> (11:08:43) pguenther: (at end)
> (11:08:44) Jim Whitehead: Thanks pguenther
> (11:08:59) hardie: We have agreed that CalDAV is the correct  
> orthography, too, so score!
> (11:09:22) lisa: http://ietf.webdav.org:8080/bugzilla
> (11:09:43) pguenther: bugzilla is set up, report problems to Joe
> (11:10:06) pguenther: is the *canonical* repository for issues
> (11:10:22) pguenther: authors cannot close issues, only chairs
> (11:10:40) Jim Whitehead: how many people in the room in DC?
> (11:10:59) MatthewElvey entered the room.
> (11:11:06) pguenther: 8 + ADs + chairs
> (11:11:11) bdesruisseaux entered the room.
> (11:11:14) Jim Whitehead: thx
> (11:11:20) Julian Reschke: bugzilla: I think this needs to cc the  
> mailing list (I know Lisa and Joe have been working on it; but it  
> doesn't seem to work right now)
> (11:11:41) pguenther: right, Joe is still aiming towards that
> (11:11:43) Jim Whitehead: i received a few emails recently. think this  
> integration is working
> (11:11:49) pguenther: sorry, slipped past my typing
> (11:12:11) pguenther: Julian sent in update on Bind
> (11:12:19) pguenther: WGLC on it soon
> (11:12:41) Julian Reschke: (no mails visibile on  
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2004OctDec/)
> (11:12:55) Jim Whitehead: what is the plan for resolving open BIND  
> issues and getting to WGLC?
> (11:12:55) pguenther: Lisa, as Julian: no open issues
> (11:13:21) pguenther: Lisa, as Lisa: some items found and put in  
> bugzilla
> (11:13:45) codebear entered the room.
> (11:13:46) Julian Reschke: These issues IMHO are the same we already  
> discussed on the mailing list.
> (11:14:00) Jim Whitehead: so do you think they're open or closed?
> (11:14:09) pguenther: moving on to Redirect: Julian: "Redirect to move  
> forwards after BIND"
> (11:14:22) Julian Reschke: Discussion ended with consensus (as far as  
> I can tell), if that's incorrect we'll need to restart it on the ML.
> (11:14:24) pguenther: Joe doesn't think there are any dependencies,  
> just a matter of work
> (11:14:33) hildjj: Is that correct?
> (11:14:40) Julian Reschke: Yes.
> (11:14:59) Julian Reschke: There is one main issue left for which I'd  
> appreciate feedback, which is...
> (11:15:03) Jim Whitehead: so, will there be one more I-D then WGLC, or  
> are we going directly to WGLC?
> (11:15:07) lisa: I think redirect is closer to WGLC, personally
> (11:15:09) Jim Whitehead: on BIND that is
> (11:15:25) Julian Reschke: ...documented here:  
> http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0180.html
> (11:15:26) lisa: redirect closer to WGLC than Bindings, to be clear  
> (and both of those closer than RFC2518bis)
> (11:15:36) hildjj: Jim: WGLC on this issue, as soon as we get Bugzilla  
> 100%
> (11:15:43) hildjj: issue/version
> (11:15:57) Jim Whitehead: bugzilla 100% means all issues reolved?
> (11:16:07) Julian Reschke: IMHO redirect indeed *has* open issues that  
> need to be resolved before we can go to LC.
> (11:17:00) lisa: Yes Julian, that could be, but redirct has fewer  
> issues and easier to resolve -- that's just my guess, based on the  
> issues I'm aware of.
> (11:17:38) Jim Whitehead: wouldn't surprise me if that's the case --  
> redirect has fewer impacts on the rest of the DAV data model
> (11:18:00) lisa: that's right
> (11:18:07) Julian Reschke: I personally think that BIND is a litmus  
> test about whether this WG is still functional or not. It has been in  
> almost-last-call state for over 19 months, and it's on top of our prio  
> list. Let's do not move other things in front of it.
> (11:19:14) pguenther: discussion: delete of redirection is the  
> important case, which makes #1 choice preferable
> (11:19:27) pguenther: (or rather, the _really_ important case)
> (11:20:32) pguenther: Julian: Joe agrees with the sentiment of your  
> concern over BIND and reordering the submission of the drafts
> (11:21:59) Julian Reschke: Meta: BIND is stable and has been  
> implemented in various servers, while REDIRECT currently seems to be  
> implemented by one single server (ours). Thus, the WG should keep BIND  
> as #1 prio.
> (11:22:03) Jim Whitehead: i don't have a strong preference over which  
> one is finished first -- obviously want to see both completed
> (11:22:05) pguenther: Ted (Hardie) to submit to bugzilla an issue over  
> DELETE of a redirection not being explicitly described/warned  
> about/pointed out
> (11:23:00) pguenther: moving on to QUOTA
> (11:23:07) pguenther: new draft submitted
> (11:23:15) lisa: Julian, it would be great to get a snapshot of the  
> implementation status of BIND and REDIRECT, on the WG list.
> (11:23:25) pguenther: big change: removed 'authorable' property that  
> was causing the most grief
> (11:23:44) pguenther: handful of nits (Thanks Julian!)
> (11:24:45) pguenther: suggestions to reorganize seem style issues and  
> will be left to author
> (11:24:55) pguenther: WGLC real soon
> (11:25:02) pguenther: CalDAV notes
> (11:25:15) Jim Whitehead: I asked brian when a new draft would be  
> created, haven't received a response. Would be good for him to receive  
> some WG Chair direction on this
> (11:25:32) lisa: Brian just said, in the next week or so after he gets  
> back from DC.
> (11:25:32) hildjj: brian says soon after he gets back.
> (11:25:35) lisa: heh
> (11:25:40) pguenther: calendaring roundtable was held
> (11:25:54) pguenther: added new resources and properties
> (11:26:21) pguenther: fourth draft adds new method 'add calender'
> (11:26:34) lisa: literally "MKCALENDAR"
> (11:27:09) pguenther: reached concensus over changes and are working  
> on searches and some specific calendaring functions
> (11:27:21) lisa: It would be good to get broader feedback on our  
> CalDAV ideas about property promotion...
> (11:27:59) lisa: it adds complexity (since we know we want to support  
> access via iCalendar formatted bodies, anyway) but we're discussing  
> whether the benefits outweigh that.
> (11:28:07) pguenther: property promotion as means to provide better  
> searching including partial retrieval(?)
> (11:28:55) lisa: Yep -- better searching, partial retrieval, partial  
> write.  To change the DTSTART of an iCalendar body, the client must  
> upload the whole body again.  Unless we reflect the body's DTSTART  
> value as a WebDAV property, in which case you could PROPPATCH only  
> that property.
> (11:28:57) pguenther: discussion on promotion
> (11:29:32) Jim Whitehead: it certainly seems to me that calendar  
> searching will be critical for making CalDAV interesting for  
> Enterprise deployment.
> (11:29:53) lisa: Yes but SEARCH+basicsearch can't even meet the  
> requirements.
> (11:30:19) Jim Whitehead: Doesn't surprise me -- will undoubtedly  
> require a specific CaLDAV search vocabulary
> (11:30:30) pguenther: timezone as example of why a brute force  
> renaming with separator isn't always good
> (11:30:32) lisa: yep -- expanding recurrances, time-range results, etc.
> (11:31:04) pguenther: use reports to do stuff beyond the capabilities  
> of search
> (11:31:16) pguenther: what is being optimized for?
> (11:31:28) pguenther: smarts in server or client?
> (11:31:31) Jim Whitehead: Will also need a richer notion of principal  
> than is provided by ACL spec -- will be tricky to stay away from an  
> entire directory server capability
> (11:31:42) lisa: Why is that, Jim?
> (11:31:44) pguenther: shifted in calsch WG over time
> (11:32:03) pguenther: (where the smarts were expected to be, that is)
> (11:32:04) Jim Whitehead: True, REPORT would be very handy here. Trick  
> is figuring out which REPORTs to support
> (11:32:45) Jim Whitehead: Principals in ACL spec don't have enough  
> metadata (phone number, room number, etc.) -- no problem to add these,  
> just need to have standard property lists
> (11:33:57) pguenther: searching and filtering take place on the server  
> side, with knowledge of recurrence[sic] rules
> (11:34:02) lisa: We may only need one more principal property for  
> CalDAV -- "calendar URL(s)"
> (11:34:13) lisa: the rest of the information can be properties on the  
> calendar resources, I think
> (11:34:14) pguenther: servers _are_ being expected to understand the  
> semantics of the objects
> (11:35:04) Jim Whitehead: For example, Oracle Calendar allows you to  
> associate "organizations" to specific principals, you you can  
> differentiate between the Nguyen in development and the Nguyen in  
> accounting.
> (11:35:14) pguenther: that an assumption of several things, including  
> promotion (but that may be doable with a shim), and recurrence
> (11:35:26) pguenther: the latter being critical to calendaring
> (11:35:49) lisa: Joe just realized he should add the webdav event  
> stuff to the agenda...
> (11:38:08) pguenther: Oracle hoping to have basic IOP by mid January
> (11:38:58) Jim Whitehead: expand "IOP" please?
> (11:39:19) pguenther: sorry, have it in operation
> (11:39:32) pguenther: (short between ears and fingers)
> (11:39:36) Jim Whitehead: OK, what are they hoping to have in  
> operation? CalDAV?
> (11:39:47) Jim Whitehead: Or have we moved on to events?
> (11:39:53) pguenther: yes, with searching
> (11:40:05) pguenther: "what meeting have I not responded to" etc
> (11:40:12) lisa: Joe mentioned the HTTP header registry, which Mark  
> Nottingham is working on
> (11:40:24) lisa: IOP is "interoperability"
> (11:40:57) lisa: Some CalDAV features should interoperate in mid-Jan.
> (11:41:11) Jim Whitehead: Also, shameless plug: there will be an  
> article on WebDAV in the Jan/Feb issue of IEEE Internet Computing.  
> Will focus on the ACL specification
> (11:41:31) Jim Whitehead: How can you have interop when the spec isn't  
> complete yet?
> (11:41:46) bdesruisseaux: The CalDAV protocol adapter of Oracle  
> Calendar should provide support for GET, PUT, DELETE, PROPFIND and  
> REPORTs to allow clients to create, modify, delete events as well as  
> search for them (with reports).
> (11:41:54) Jim Whitehead: Or, put another way, what is the baseline  
> for this?
> (11:42:12) Jim Whitehead: Is the CalDAV adapter going to be publically  
> available?
> (11:42:27) pguenther: taking to list the details of having MKCAL  
> indicate what it is putting up
> (11:42:33) Jim Whitehead: Who is the oracle contact for CalDAV?
> (11:42:56) lisa: Bernard DesRuisseaux
> (11:43:00) lisa: (in this room)
> (11:43:04) bdesruisseaux: We'll make the adapter available outside our  
> firewall for CalDAV cllient initiative to work toward an IOP
> (11:43:08) lisa: (both physical and jabber room)
> (11:43:28) bdesruisseaux: Jim, I am the "dev" contact for CalDAV.
> (11:43:51) Jim Whitehead: Super! Thanks Bernard. We're an oracle  
> calendar shop here at UCSC
> (11:44:16) bdesruisseaux: Good!
> (11:45:32) pguenther: Cyrus: no further immediate needs from CalDAV on  
> WebDAV; if stuff comes up during implementation then it will be taken  
> to the list
> (11:46:21) pguenther: Bernard: in future, stuff like QUOTA may become  
> more important for CalDAV, to prevent DoS attacks in the direct case  
> of QUOTA
> (11:46:30) Julian Reschke: If CalDAV in some way becomes an "official"  
> WebDAV working group item, I'd like to see discussions to actually  
> happen on the mailing list...
> (11:46:48) Jim Whitehead: there are separate mailing lists for caldav
> (11:46:58) Jim Whitehead: seems like it should be a separate WG in any  
> case
> (11:47:07) Julian Reschke: Yes, but there seems to be a lot of  
> out-of-band dicussion :-)
> (11:47:15) Jim Whitehead: :-)
> 11:47:29) Jim Whitehead: not clear caldav folks want to be an IETF WG
> (11:47:43) pguenther: for now, the CalDAV is expecting to stay as an  
> individual submission
> (11:47:59) Julian Reschke: nothing wrong with that
> (11:48:30) lisa: There are certainly a lot of out-of-band discussions.  
>  Co-authors do that.
> (11:48:35) lisa: :-)
> (11:48:35) pguenther: Ted: HTTP SASL had a bunch of review comments
> (11:48:39) Jim Whitehead: agreed
> (11:49:12) lisa: I believe we're doing a good job of bringing the  
> out-of-band discussions on CalDAV into the spec and publishing it  
> frequently.
> (11:49:17) pguenther: comments are currently unreplied to and is stuck  
> there until that happens, perhaps blocked on SASL WG
> (11:49:17) pguenther: ?
> (11:49:55) pguenther: Waiting on revision from Alexey based on review?
> (11:50:06) pguenther: Lisa: blocked on disagreeing on how HTTP is  
> extensible
> (11:51:35) pguenther: Lisa: a use case for HTTP SASL would help it  
> move forwards, perhaps
> (11:51:42) lisa: Also blocked on understanding why it's needed
> (11:52:02) pguenther: Cyrus/Ted: WebDAV pushing for HTTP SASL may serve
> (11:52:29) lisa: (Scott could probably come up with a proposed model,  
> but he needs to be motivated by understanding "why SASL")
> (11:52:34) lisa: (Scott Lawrence, that is)
> (11:52:41) pguenther: Cyrus: webdav security considerations section,  
> etc
> (11:52:55) pguenther: Moving on to events
> (11:53:23) pguenther: Joe: "being that we're XMPP people, this  
> [events] is XMPP based"
> (11:53:40) Jim Whitehead: Seems like HTTP/DAV is doing fine without  
> SASL. Would need to get buy-in from MSFT and Apache up front,  
> otherwise is DOA. Without this buy-in, seems like it's not worth our  
> time.
> (11:53:57) Jim Whitehead: Is there an events specification out?
> (11:54:06) Jim Whitehead: Or is this in the planning stages?
> (11:54:28) pguenther:  
> http://www.jabber.org/~stpeter/ietf/dradft-saintandre-webdav-notify 
> -00.html
> (11:54:35) Jim Whitehead: thx
> (11:55:01) pguenther: JEP #60 (publish/subscribe protocol on top of  
> Jabber)
> (11:55:10) pguenther: JEP == Jabber Enhancement Proposal
> (11:55:20) pguenther: comes from Jabber Software Foundation
> (11:55:49) pguenther: notify spec says how to use that spec to put on  
> top of it "this resouce was modified", perhaps also "here what was  
> changed"
> (11:55:54) lisa: I've proposed we follow up HTTP SASL questions on the  
> HTTP list and see if we can get broader input there... Jim do you  
> still subscribe to that list? Can you point out the buy-in problem?
> (11:56:09) pguenther: optional new property giving place to go for  
> changes
> (11:56:17) Jim Whitehead: url is actually:  
> http://www.jabber.org/~stpeter/ietf/draft-hildebrand-webdav-notify 
> -00.html
> (11:56:38) Jim Whitehead: I've never been on the SASL list, would be  
> willing to point out buy-in problem.
> (11:56:43) lisa: thanks Jim!
> (11:57:13) pguenther: (this was in revenge, stpeter on joe)
> (11:57:17) lisa: There's not a specific SASL list... so I suggested  
> discussing HTTP SASL on ietf-http-wg@w3.org
> (11:57:34) pguenther: Joe: does this ID deserve a home in WG
> (11:57:35) lisa: I mean, there probably is a SASL list, but our  
> problem is not the SASL part of it.
> (11:57:37) Jim Whitehead: ah, ok. yeah, that list is really quiet
> (11:57:45) pguenther: Ted: isn't this also in atompub?
> (11:57:45) Julian Reschke: yes, there is: http://www.imc.org/ietf-sasl/
> (11:57:53) pguenther: Joe: that's a different draft
> (11:57:57) lisa: Our HTTP/SASL problem is how to extend HTTP in a  
> HTTP-like way, that works with intermediaries, to support SASL -- and  
> why to do so.
> (11:58:03) Jim Whitehead: I can also contact authors directly.
> (11:58:25) pguenther: Cyrus: security?  how to do authentication?
> (11:58:27) lisa: I've just asked Alexey Melnikov to try to kick off  
> discussion on mailto:ietf-http-wg@w3.org.
> (11:58:38) pguenther: Joe: if you have SASL it's easy, and XMPP has  
> SASL
> (11:58:38) Jim Whitehead: OK, why do we want SASL? I don't hear lots  
> of calls for replacing current SSL layer, and the CONNECT method isn't  
> getting lots of adoption AFAIK
> (12:00:06) pguenther: Joe: they have a server that has separate "who's  
> allowed to publish" and "who's allowed to subscribe"
> (12:01:38) pguenther: Joe: similarity to XMPP is nice; gives a dual  
> XMPP/WedDAV client ability to use the same creds/stuff to authentice  
> to both
> (12:02:04) pguenther: Cyrus: similar to URLAUTH?
> (12:02:11) pguenther: (from LEMONADE)
> (12:02:34) pguenther: so called "pawn ticket" model: whoever has the  
> token can fetch resource
> (12:02:37) Jim Whitehead: thx -- so the issue gets more important as  
> XMPP gains in adoption, and XMPP/DAV synergies become more useful
> (12:03:08) pguenther: Lisa: old draft of this used by Lycos
> (12:03:15) lisa: Not Lycos, Xythos :-)
> (12:03:41) ***pguenther curses at the phenomes used by English
> (12:03:57) pguenther: Jim: right
> (12:04:51) lisa: Philip are you worried about Phonemes or Pheromones?
> (12:05:30) ***pguenther curses at English in general
> (12:05:36) pguenther: should never made it out of draft
> (12:05:46) pguenther: Moving on to PATCH
> (12:06:17) pguenther: Lisa: unable to register mime-type GDIF due to  
> issues with IPR
> (12:06:35) pguenther: make VCDIF the required form?
> (12:06:56) pguenther:  but it can only be used in HTTP/1.1 according  
> to its IPR statement!
> (12:07:08) Julian Reschke left the room (Replaced by new connection).
> (12:07:08) Julian Reschke entered the room.
> (12:07:09) Julian Reschke left the room.
> (12:07:17) Julian Reschke entered the room.
> (12:07:18) pguenther: there is not another diff format out there to use
> (12:07:22) Jim Whitehead: don't understand IPR issue. MIME type  
> registration doesn't involve any exposure of IPR, as I recall
> (12:07:35) pguenther: don't require diff format to be supported?
> (12:07:48) Jim Whitehead: For example, MSFT still has complete control  
> over .doc format, but still has MIME type for it
> (12:08:00) Julian Reschke: I think we'll need at least one simple diff  
> format that all severs and clients will support.
> (12:08:11) pguenther: IANA won't register an application/* type  
> without resolution of IPR issues
> (12:08:34) Julian Reschke: REQUIRING support for a format with unclear  
> IPR is problematic.
> (12:08:48) Jim Whitehead: Agreed
> (12:08:52) lisa: Yes, agreed.
> (12:08:55) lisa: And then... ?
> (12:09:05) Jim Whitehead: Subversion uses vdelta, but that also has a  
> patent on it
> (12:10:09) pguenther: Ted: talk to Jeff Mogul?
> (12:10:17) pguenther: Lisa: yes, he said use VCDIFF
> (12:10:58) pguenther: suggestion to ask Jeff to lean on people to  
> update/extend IPR grant to apply to more uses including WebDAV
> (12:11:00) Julian Reschke: I looked at VCDIFF a few weeks ago and it  
> seems to be way to complicated as a required base format.
> (12:11:03) Jim Whitehead: Seems like we have three choices: (1)  
> explore where a common delta has RAND licensing (or owner is willing  
> to commit to RAND) (2) develop a new diff format that isn't patented  
> (hard, lots of IP in this space) (3) use a really old delta format  
> (like the Unix diff used in SCCS, or possibly even the diffs used in  
> RCS
> (12:11:46) Jim Whitehead: There is also the XML diff format developed  
> by Vitali and Durand, called VTML
> (12:12:01) Julian Reschke: Need to consider different use cases: text  
> patch (as in diff/patch) and binary patch (like when writing back only  
> parts of a binary resource)
> (12:12:37) Julian Reschke: (the latter likely to be useful for clients  
> that map WebDAV to file I/O)
> (12:12:54) Jim Whitehead: VTML URL is  
> http://www.cs.unibo.it/~fabio/bio/papers/1999/SCM99/SCM9.pdf
> (12:13:02) lisa: There's also the XML diff format developed by Adrian  
> Mouat
> (12:13:07) Jim Whitehead: Agreed VTML would be problematic for binary  
> diffs
> (12:13:12) lisa: yup
> (12:13:48) pguenther: Joe: regarding diff comments: "Can of worms;  
> move on for now"
> (12:14:11) pguenther: Lisa: where to put content-type of patch in HTTP?
> (12:14:32) Jim Whitehead: Seems to me we don't really need a  
> compressed diff format. Something that says insert n octets starting  
> at octet y, using encoding z would do the trick
> (12:14:50) Julian Reschke: ...into the content-type header, as defined  
> in RFC2616...
> (12:14:54) hildjj: Jim: that's gdiff, no?
> (12:14:56) pguenther: long history of HTTP Content-Type and  
> "instance-Manipulation" headers
> (12:15:23) Jim Whitehead: Don't know gdiff
> (12:15:39) Julian Reschke: Yep, that's basically gdiff.
> (12:16:04) pguenther: (i.e., can the content-type header be of the  
> underlying object, even when the actual body of the request is really  
> instruction to modify it)
> (12:16:29) Julian Reschke: (http://www.w3.org/TR/NOTE-gdiff-19970901)
> (12:16:34) pguenther: Joe: stuff is clearly still open; PATCH is not a  
> working group item
> (12:16:42) Julian Reschke left the room (Replaced by new connection).
> (12:16:43) Julian Reschke entered the room.
> (12:16:43) Julian Reschke left the room.
> (12:16:46) Jim Whitehead: Just looked at gdiff spec. Would be easy to  
> design something similar, but still markedly different
> (12:16:47) Julian Reschke entered the room.
> (12:16:52) Jim Whitehead: Does gdiff have IPR issues?
> (12:17:04) lisa: Gdiff is not known not to have IPR issues.
> (12:17:24) lisa: I submitted an IANA registration for  
> application/gdiff and it was rejected because IPR issues were not  
> clear.
> (12:17:25) pguenther: Bernard: calendaring change format could be done  
> using diff format, so would be nice there too
> (12:17:35) lisa: Joe
> (12:17:41) lisa: Joe is declaring we're finished...
> (12:17:47) hildjj: anything else before we're done?
> (12:17:48) lisa: unless there are any last-minute issues
> (12:18:11) pguenther: gavel has fallen
> (12:18:18) hildjj: </gavel>
> (12:18:19) bdesruisseaux left the room.
> (12:18:22) Julian Reschke: I'd like us as WG to agree that we  
> concentrate on the topics that are on top of our charter.
> (12:18:37) hildjj: Julian: yes.  BIND first.
> (12:19:04) Jim Whitehead: OK
> (12:19:16) hildjj left the room.
> (12:19:16) Julian Reschke: People who do have open issues with the  
> latest draft, *please* post them to the ML for dicussion.
> (12:19:50) Jim Whitehead: OK
> (12:25:41) hardie left the room (Disconnected).
> (12:25:57) codebear left the room.
> (12:26:20) Julian Reschke left the room (Disconnected).
> </notes>
>
> -- 
> Joe Hildebrand
> Denver, CO, USA
>