IRC log of tagmem on 2002-04-29

Timestamps are in UTC.

14:19:36 [RRSAgent]
RRSAgent has joined #tagmem
14:19:40 [Zakim]
Zakim has joined #tagmem
14:20:58 [Ian]
Ian has changed the topic to: TAG teleconf
14:21:30 [Stuart]
Stuart has joined #tagmem
14:24:40 [Stuart]
zakim, who is here
14:24:41 [Zakim]
Stuart, you need to end that query with '?'
14:24:47 [Stuart]
zakim, who is here?
14:24:49 [Zakim]
sorry, Stuart, I don't know what conference this is
14:25:04 [DanCon]
Zakim, this is tag
14:25:05 [Zakim]
ok, DanCon
14:25:09 [DanCon]
Zakim, who's here?
14:25:11 [Zakim]
I see ??P29
14:25:39 [Stuart]
Hiya Dan
14:25:52 [Stuart]
zakim, ??P29 is probably me
14:25:53 [Zakim]
+Stuart?; got it
14:26:47 [Norm]
Norm has joined #tagmem
14:27:13 [DanCon]
Stuart, I did some scribbling in , but didn't make any really interesting progress.
14:28:41 [Chris]
Chris has joined #tagmem
14:29:01 [Zakim]
14:29:32 [Stuart]
Ok... maybe we can get a quick update. Also, do you think it would be useful to discuss Larry's proposal?
14:30:00 [Ian]
/me will be there in 1 minute
14:30:28 [Stuart]
14:31:00 [Zakim]
14:31:07 [TBray]
TBray has joined #tagmem
14:31:18 [Norm]
0824, Dan
14:31:59 [Norm]
zakim, who's here?
14:32:01 [Zakim]
I see Stuart?, N.Walsh, ChrisL
14:32:03 [Zakim]
14:32:04 [Chris]
Zakim, who is here?
14:32:05 [Zakim]
I see Stuart?, N.Walsh, ChrisL, DanC
14:32:14 [Zakim]
14:32:23 [Norm]
zakim, p43 is Roy
14:32:25 [Zakim]
sorry, Norm, I do not recognize a party named 'p43'
14:32:27 [Chris]
Zakim, ??P34 is Roy
14:32:28 [Zakim]
+Roy; got it
14:32:46 [Norm]
Yes, DanCon is right. I let my pilot remember, not Zakim, that's all.
14:33:28 [Zakim]
14:36:31 [Zakim]
14:36:53 [Ian]
Regrets: PC, TBL
14:36:56 [Ian]
zakim, who's here?
14:36:57 [Zakim]
I see Stuart?, N.Walsh, ChrisL, DanC, Roy, TBray, Ian
14:37:28 [Ian]
SW: Minutes accepted for 22 April:
14:38:33 [Ian]
IJ: I propose to drop arch doc progress since I've made none.
14:39:15 [Ian]
SW: General question about TAG agenda; driven from proactive to reactive.
14:39:27 [Ian] others feel they'd like the balance to be more active than reactive?
14:39:32 [Ian]
RF: I'd rather be working on the document.
14:39:46 [Ian]
TB: It's important to not let the arch doc languish.
14:39:49 [Ian]
CL: Agreed.
14:39:50 [Chris]
14:40:08 [Ian]
TB: Let's put that on ftf agenda:
14:41:46 [Ian]
IJ: I ack the problem of my inavailability these days.
14:42:01 [Ian]
[FTF AGENDA: Unplugging IJ the bottleneck. :)]
14:42:22 [Ian]
TB: IJ is not de facto available; what should we do? Should we do some of the editing ourselves?
14:44:28 [Ian]
CL: It would give IJ less work if we polish our own sections.
14:45:26 [Ian]
NW: With respect to:
14:45:38 [Ian]
NW: My efforts petered out since I haven't heard consensus of opinion on some piecs.
14:45:45 [Ian]
14:45:54 [DanCon]
I'm quite happy with folks writing their own opinion and asking if other folks agree, Norm.
14:46:31 [Ian]
CL: Not clear whether this section is addressing just "document-like" resources or all resources.
14:46:47 [Ian]
NW: Trying to address all resources. Not sure that document v. data is useful architecturally.
14:47:36 [Ian]
IJ: XAG 1.0 finds interesting to distinguish data-centric and user-centric content; but no formal distinction.
14:48:02 [Ian]
SW: What about RF's writing on application state?
14:48:07 [Ian]
14:48:20 [Ian]
RF: TBL, IJ, RF talked about this section.
14:48:29 [DanCon]
ACTION Norm: take another pass over "what does a document mean" before the f2f"
14:48:48 [Ian]
RF: Ball is in IJ's court.
14:48:57 [Ian]
14:49:01 [Ian]
Action item review:
14:49:04 [Ian]
14:49:11 [Ian]
IJ: Publish draft finding on Media-Types (after edits)
14:49:26 [Ian]
See comments from SW:
14:49:41 [Ian]
14:49:51 [Ian]
CL: Prioritize comments on Guidelines for the use of XML in IETF protocols
14:50:10 [Ian]
(CL will read these in other agenda items)
14:50:24 [Ian]
Pending - DC: Write more on whenToUseGet
14:50:35 [Ian]
14:50:39 [Ian]
New issues
14:50:50 [Ian]
1) Review charmod lc2
14:50:54 [Ian]
14:51:00 [Ian]
2) Qnames as ids
14:51:06 [Ian]
14:51:15 [Chris]
Get url of document from
14:51:21 [Ian]
* Charmod
14:51:25 [Stuart]
14:51:36 [Zakim]
14:51:37 [Chris]
14:51:38 [Ian]
RF: Covers character requirements for every protocol. It's architectural in that it touches everyone.
14:52:27 [Ian]
CL: Charmod introduces ability to put unicode-encoded URI ref in a document. Makes it a req that protocols say when it happens.
14:52:42 [Ian]
...Stuff you send over the wire is percent-encoded. But you can put company names in URIs.
14:53:03 [Ian]
...(e.g., on the side of a bus). Conversion to percent (hex) encoding doesn't change what goes over the wire.
14:53:06 [DanCon]
I don't agree with the summary that Chris just gave.
14:53:25 [Ian]
RF: I don't think that IRI will exist for long; not integrated in the URI draft.
14:53:53 [Ian]
RF: I was opposed to IRI four years ago because they wanted to integrate it before having implementing it.
14:53:54 [David]
David has joined #tagmem
14:53:55 [Ian]
14:54:25 [Ian]
CL: This doc has several sections. Section 3 is on characters. With the exception of sorting, the entire section is a description of current practice.
14:54:57 [Ian]
...very good that all this is gathered into one place.
14:55:12 [Ian]
CL: Normalization stuff is contentious but has benefits.
14:55:19 [DanCon]
I sure wish they'd split the document. Hmm... I wonder if I asked them for that in so many words.
14:55:45 [Ian]
CL: I with they'd split it up too
14:55:53 [Ian]
CL: I recommend that the TAG review this document.
14:55:58 [DanCon]
I 2nd the request to review
14:57:10 [Ian]
IJ: What makes this document different from xforms? Significant impact on other work?
14:57:11 [Ian]
CL: YEs.
14:57:39 [Ian]
NW: I've committed to review for XML Core. I will send my comments to both core and tag.
14:57:46 [Ian]
DC: Please tune your head differently for two reviews.
14:58:03 [Ian]
CL: I volunteer to review and act as a liaison and coordinate comments.
14:58:23 [Ian]
Action CL: Respond affirmative to Misha Wolf's request to review.
14:58:28 [Ian]
DC: Deadlines?
14:58:39 [Chris]
ACTIOn CL confirm with Misha that TAG will review entire document
14:59:09 [Ian]
14:59:12 [Chris]
Last Call period begins 30 April 2002 and ends 31 May 2002.
14:59:29 [Ian]
Action IJ: Add as issue charmod-17
14:59:32 [Ian]
14:59:36 [Ian]
Qnames as Identifiers
14:59:41 [Ian]
14:59:43 [DanCon]
hmm... TAG to finish its charmod review by 31 May? I doubt it.
14:59:55 [Ian]
CL: I'm seeing increasing use of qnames as ids.
15:00:42 [Ian]
CL gives some scenario that scribe missed: essentially, "Qname is a URI/name pair"
15:00:49 [Ian]
ack Chris
15:00:59 [Ian]
SW: Is there a new issue here?
15:01:16 [TBray]
15:01:22 [Ian]
ack DanCon
15:01:56 [Ian]
DC: I think there is an issue. I think it's a myth that one can rewrite prefixes when one copies part of an xml doc from one section to another.
15:02:01 [Ian]
ack TBray
15:02:40 [Ian]
TB: For the record - I argued intensely when James Clark wrought this on the world that this was the wrong thing to do. I lost that argument. Now that the genie is out of the bottle, I'm not sure what we can say useful about it.
15:02:42 [Norm]
15:03:02 [Ian]
TB: There seems to be consensus that at the end of the day a qname is a URI/local name pair. What else needs to be said?
15:03:20 [DanCon]
I gather Tim Bray's argument can now be summarized as 'I told you so.'
15:03:35 [Ian]
TB: A qname is a prefix plus a string of characters.
15:03:42 [Ian]
CL: What issues bit us?
15:03:48 [Chris]
15:03:50 [Ian]
TB: Bit us in the DOM.
15:04:06 [Ian]
NW: I agree with TB - shouldn't have done this in the first place. But now we need to move on.
15:04:22 [DanCon]
well, as to what we can do about it, I think we can say 'this sucks; sorry; deal; don't expect things to work nicely.
15:04:24 [Ian]
CL: We can say:
15:04:26 [DanCon]
15:04:32 [Ian]
a) Yes it's ok to use them
15:04:39 [Ian]
b) We recommend that you use them.
15:05:02 [Ian]
SW: I'm hearing making this an issue and issuing a finding?
15:05:09 [Ian]
15:05:13 [Ian]
ack Norm
15:05:14 [Norm]
ack norm
15:05:20 [Ian]
DC: There's a lot of experience. We can condense it.
15:05:33 [Ian]
DC: Not everyone knows the plusses and minuses.
15:05:43 [Ian]
CL: Yes, I think a finding would be useful.
15:05:53 [Ian]
SW: Volunteers?
15:06:25 [Ian]
Resolved: Accept qnameAsId-18 as issue.
15:06:42 [Ian]
Action NW: Draft a finding explaining advantages and disadvantages.
15:06:50 [Ian]
CL: Keep it neutral - legal but pros and cons.
15:07:00 [Ian]
DO: So it's not really an arch recommendation...
15:07:06 [DanCon]
order, Stu, we're done accepting this issue
15:07:13 [Ian]
15:07:19 [Ian]
ack Chris
15:07:24 [Ian]
ack Ian
15:07:38 [Ian]
Norm, I recommend including examples (in general in fact) of bad usage (and good).
15:07:56 [Ian]
Action IJ: Add issue to issues list.
15:07:58 [Ian]
15:08:47 [Ian]
15:09:07 [Ian]
RF notes that IE Mac crashes on this document.
15:09:14 [DanCon]
ooh, TimBray, I'm interested in clues on choosing which mozilla to use on a mac
15:09:21 [Ian]
DC: I move we accept this draft.
15:09:26 [Ian]
RF: I agree with SW comments (on
15:09:47 [Ian]
15:10:10 [Ian]
SW summary of comments:
15:10:21 [Ian]
1) s/resource/response. Found this a bit jarring.
15:10:25 [Ian]
CL: I agree with this.
15:10:52 [Ian]
DC: The last meeting said "resolved s/resource/response"
15:11:05 [Ian]
TB: The point was that we were talking about the bits received.
15:11:27 [Ian]
DC: What IJ wrote is what I would have expected based on our meeting of last week.
15:11:43 [DanCon]
15:11:43 [DanCon]
15:11:43 [DanCon]
1. Publish this finding as accepted, without ns dispatch section, and having fixed charset sentence (s/resource/response).
15:11:47 [DanCon]
]] --
15:11:52 [Ian]
RF: This is wrong.
15:12:22 [Ian]
RF: The finding says that representations only exist in responses. We're talking about media types.
15:12:41 [Ian]
CL: Don't imply that some things only are found in responses.
15:13:02 [Ian]
TB: I request that we take more time to review offline.
15:13:35 [Chris]
url to read?
15:13:36 [Ian]
DC: How do we make progress on this?
15:13:50 [Ian]
15:13:56 [Ian]
Wrong uRI
15:14:09 [Ian]
15:14:16 [Ian]
Last modified: $Date: 2002/04/25 17:06:19 $
15:14:19 [Ian]
15:14:22 [Ian]
FTF meeting agenda
15:15:26 [Ian]
DC: TimBL on holiday this week.
15:15:40 [Ian]
SW: Agenda suggestions?
15:15:52 [Ian]
TB: Two things I'd like to accomplislh:
15:16:14 [Ian]
a) Meta-work on arch document. Style, structure. I'm not satisfied with progress thus far.
15:16:35 [Ian]
b) I'd like to drive a stake through whenToUseGet-7.
15:17:16 [Ian]
TB: Soap 1.2 is going to go to last call soon. I suspect that at least TBL, RF, and I will have some issues about what's in there.
15:17:43 [Ian]
TB: I'd like to be proactive, read SOAP 1.2, and identify architectural issues, come up with an action plan (who does what when).
15:18:03 [DanCon]
if there's a suggestion to read "soap 1.2", please include dates and URIs of the specs; I gather the published /TR/ for SOAP isn't the thing to read.
15:18:16 [Ian]
NW: I'd like progress on arch doc. Let's use ftf time to make progress on that and slow issues.
15:18:21 [Ian]
DO: Sounds fine so far.
15:18:30 [Ian]
RF: Already covered.
15:18:34 [Ian]
CL: Already covered.
15:18:53 [David]
Why is Ian crying?
15:18:56 [Ian]
15:19:22 [Ian]
DC: Mixed namespaces, if only to show ourselves that we won't make progress.
15:19:50 [Ian]
Action SW and IJ: Work on ftf agenda.
15:19:55 [Ian]
15:20:03 [DanCon]
Ian's falling on his sword cuz he sees himself as a bottleneck on the arch document, but Tim Bray was careful to say "I think it's important and I'm not satisifeid with the progress *we* are (not) making on it"
15:20:04 [Ian]
1. Guidelines For The Use of XML in IETF Protocols IETF best practices draft requiring URNs for XML namespaces in IETF documents.
15:20:04 [Ian]
Action to take?
15:20:10 [Stuart]
15:20:12 [Stuart]
15:21:00 [Ian]
CL: Some comments on guidelines from editors suggest some fixes will take place (but wouldn't have occurred if charmod already a Rec)
15:21:25 [Ian]
CL: Also, they say "should be well-formed". No. Must be well-formed.
15:21:28 [DanCon]
(alread a REC *and* widely read and understood; unfortunately we can't publish directly into developer's minds)
15:21:38 [Norm]
What Chris said, +100 :-)
15:21:51 [Ian]
CL: I don't want a protocol coming out of IETF saying "Should be well-formed...."
15:21:56 [Ian]
TB: Absolutely.
15:22:20 [Ian]
SW: They expect to "roll a new one" in a week or two.
15:22:36 [Ian]
TB: Larry Masinter has asked us to postpone discussion.
15:22:49 [Ian]
LM: New draft expected "in a couple of weeks"
15:23:21 [Ian]
15:23:49 [Ian]
SW: We will postpone discussion until that draft ready.
15:24:02 [Ian]
15:24:18 [Ian]
whenToUseGet-7 Review revised Finding, TAG consensus? (
15:24:18 [Stuart]
15:24:22 [Stuart]
15:24:31 [Ian]
Draft findings:
15:24:34 [Chris]
15:24:49 [Ian]
DC: See "Fodder" at bottom
15:24:53 [Ian]
(of document)
15:25:43 [Ian]
DC: See email from LM
15:25:55 [Ian]
DC: I like this.
15:26:00 [Ian]
TB: I think close to DC's version.
15:26:30 [Stuart]
15:26:36 [Ian]
TB: Would you redraft your language using LM language?
15:27:00 [Ian]
DC: Original findings didn't make the case for what you lose when you don't use get. I would add examples.
15:27:21 [Ian]
DC: Also, the "browsers v. clients" distinction I don't agree with. I wanted to make this case.
15:29:12 [Ian]
CL: If I bookmark results of submitting a form, I don't want the form posted again. I just want a URL to tracking info. In other cases, I do want form to be resubmitted each time. There are cases for each.
15:29:40 [Ian]
TB: When you buy a book, for the safety criterion, this has to be done with a post anyhow. I think we are mixing the issues here.
15:29:51 [Ian]
DC: LM pointed out that POST response can give a content location.
15:30:01 [Ian]
TB: That's a safe way that's playing by the rules.
15:30:10 [Ian]
RF: It isn't necessary to be limited to content location.
15:30:44 [Ian]
CL: I'd like to have the option of bookmarking a post (when posts are safe).
15:30:50 [Ian]
DC: If safe, shouldn't have been a POST.
15:30:55 [Ian]
CL: Where do you put the message body?
15:31:11 [Ian]
TB: If too complex, existing GET machinery probably not enough. Use Post.
15:31:21 [Ian]
CL: Bad to crunch message bodies into percents.
15:31:25 [Ian]
DC, TB: Why?
15:31:36 [Ian]
CL: No meaning of bytes in URI space.
15:32:35 [Ian]
RF: In practice, the only problem is when the char encoding is transcoded at some point. The body no longer corresponds to the same octets the server had.
15:32:36 [DanCon]
Ian, don't try to minute this line by line.
15:32:40 [Ian]
CL: I disagree with that.
15:33:26 [Ian]
TB summarizing: CL is objecting to the utility in the general case of doing GETs on URIs that have complex args due to I18N issue.
15:33:39 [Ian]
TB: Is that orthogonal to the main arch issue we are discussing?
15:33:56 [Ian]
CL: No, since this is telling people to use something that's broken.
15:34:11 [DanCon]
I don't think anything's broken.
15:34:32 [Ian]
TB: Two sides to this - if you push web to post space, you lose a lot of benefits (e.g., application of crawlers, bookmarks, ...).
15:34:38 [Ian]
TB: Isn't a better solution to fix the I18N solution.
15:34:39 [Ian]
CL: Yes.
15:34:46 [DanCon]
servers define the meaning of all URIs, not just ones with non-ascii form responses.
15:35:06 [Ian]
CL: I still think kind of broken to percent-encode a document and stuff into a URI...
15:35:21 [Ian]
DC: I can make same argument against pointy brackets...
15:35:44 [Ian]
CL: If we recommend something, indicate corresponding drawbacks.
15:36:26 [Ian]
DC: Do you agree with principle to use get for safe operations?
15:36:42 [Ian]
CL: Yes, unless strong reasons to the contrary.
15:36:49 [Ian]
TB: That's why it's "should".
15:36:57 [Chris]
yeah, okay
15:37:04 [Ian]
TB: I think DC's original document was sounds, and that DC should incorporate suggested improvements.
15:37:21 [Ian]
RF: I'd like to refocus on the issue of "All important resources should have URIs."
15:38:13 [Ian]
DO: Before getting closure here, how is this finding to be used?
15:38:21 [TBray]
15:38:34 [Ian]
DO: What is Web services to do with this?
15:39:01 [Ian]
TB: Yes, I agree - some of our findings will be impactful on ongoing work. I think we need to be explicit about intended consequences.
15:39:25 [Chris]
15:39:26 [Ian]
DC: I'd like SOAP primer to say "At this time we don't have GET, so for safe operations don't use SOAP."
15:40:02 [Ian]
TB: At ftf meeting, we can discuss how to build findings and how to work with people to incorporate.
15:40:05 [Ian]
15:40:10 [Ian]
ack TBray
15:40:11 [David]
15:40:37 [Ian]
DC: The example used recently - Google API - you can use with GET or SOAP.
15:41:04 [Ian]
DC: I would like (SOAP) specs to be clear that SOAP is not expected to be used for GET-like operations (e.g., get the weather).
15:41:26 [Ian]
CL: The document primarily talks about HTTP. And talks about GET (but not safe methods).
15:41:55 [Ian]
CL: It seems to me that one thing missing from finding - protocols should indicate their safe methods.
15:42:10 [Stuart]
15:42:26 [Ian]
DC: SOAP is not a w3c-defined vocab of methods. "Make your own"
15:42:33 [Ian]
DC: There are bindings to transport protocols.
15:42:51 [Ian]
CL: If you see a new protocol you haven't met before, you should have a mechanism for querying whether a method is safe.
15:43:01 [Ian]
RF: E.g., include a label in envelope?
15:43:05 [Ian]
CL: Yes, for example.
15:43:24 [Ian]
CL: In short: move away from the word "GET" and use "safe" instead.
15:43:27 [Ian]
15:43:31 [Ian]
ack Chris
15:43:55 [TBray]
15:44:24 [Ian]
DO: I put a proposal out that one of the ways to handle this for the TAG to issue a finding that hiding everything behind POST isn't sufficient, and the TAG would like something more Web-friend (URIs and GET) and we'd like the WSA WG to deal with this issue.
15:44:48 [Ian]
DO: The WSA WG has responsibility for glossary, examples, charters, etc.
15:45:13 [Ian]
DO: This is not part of charter for SOAP 1.2. We could ask WSA to make this a high priority for later versions.
15:45:25 [Stuart]
15:45:28 [DanCon]
sounds mostly good, but the "merry path" should include some "NOTE: this is an issue SOAP 1.2 doesn't address; stay tuned" stuff in the SOAP 1.2 spec
15:45:55 [Stuart]
ack David
15:46:22 [Ian]
TB: I think that this is the best way forward for process. I'm left with a grave concern for timing. What worries me is that huge amounts of info disappear behind POST>
15:47:00 [Ian]
TB: Damage will be done if SOAP 1.2 goes to Rec creating an all-POST environment for Web services.
15:47:07 [Ian]
15:47:11 [Ian]
ack TBary
15:47:25 [TBray]
15:47:33 [Ian]
SW: People asking how to integrate GET. Responses have been "You could do that, but that wouldn't be very useful."
15:47:35 [David]
15:47:57 [Ian]
SW: The WG is working on the document. There is a small window of opportunity.
15:48:49 [Stuart]
15:48:52 [Ian]
CL: Problem is if SOAP 1.3 is produced with safe methods but SOAP 1.2 meets everyone's needs adequately.
15:50:06 [Ian]
DO: Things the WSA WG will be interesting to the Web services community (e.g., reliable methods). Therefore, I think a next version of SOAP with cool features including safe methods will not get lost.
15:50:40 [Ian]
RF: In the IETF, the IESG can add a note at the beginning of the spec to say that additional work is going on to take care of issues a/b/c.
15:51:09 [DanCon]
hmm... I don't think delaying SOAP 1.2 for this is the best idea, but the idea that stuff after SOAP 1.2 will get noticed... I wonder... there's a LOT of stuff being built now that cites SOAP 1.1.
15:51:26 [Ian]
TB: HTTP/1.1 has been slow to catch on.
15:51:30 [Ian]
15:51:43 [Ian]
15:52:17 [DanCon]
RF/CL disagree with TB about speed of HTTP/1.1
15:52:33 [Ian]
DO: What does the TAG think the XMLP WG should do with SOAP 1.2. I'm strongly arguing that the WG should be able to make progress (as is).
15:52:37 [Ian]
ack David
15:54:15 [TBray]
15:54:55 [Ian]
ack Ian
15:55:20 [Ian]
IJ: I think that TAG should provide comprehensive explanation of issue. Let larger community reach consensus as part of regular W3C process.
15:55:22 [Ian]
ack TBary
15:55:24 [Ian]
ack TBray
15:55:39 [Ian]
TB: I think this is a problem that is not hard to solve technologically.
15:55:59 [Ian]
TB: Do some people think it's much harder than what I've described elsewhere?
15:56:33 [Ian]
TB: Wouldn't cover all of SOAP (e.g., not N-space conversations).
15:56:47 [Ian]
DO: How do RF and DC feel about this type of solution.
15:56:49 [Ian]
DC: It's good.
15:56:50 [DanCon]
as to the idea that this issue is coming in late, I notified the XMLP WG of this issue, via Yves, when they were drafting their requirements. R612
15:58:51 [Ian]
TB: Paul Prescod wrote an article about google - they published an API where there used to be a URI. The google result space vanishes from URI space as a result. Paul argues why the URI version was better for a lot of reasons.
15:59:02 [Ian]
DO: I thought the article was well-written.
15:59:31 [Ian]
15:59:37 [TBray]
16:00:08 [Ian]
DC: It would help me if DO said which way Google should have done it - it was done with GET and they switched. If there isn't agreement that it was better done with GET, I don't know how to write the finding.
16:00:53 [Ian]
DO: I think that GET could be used for some of the SOAP calls. I don't like raising the case for using POST in general. But in the case of google, I think it's a fine usage of GET.
16:01:39 [Zakim]
16:02:00 [Ian]
16:02:02 [Zakim]
16:02:04 [Zakim]
16:02:08 [Zakim]
16:02:10 [Zakim]
16:02:10 [Zakim]
16:02:30 [Ian]
RRSAgent, stop