IRC log of tagmem on 2002-04-22

Timestamps are in UTC.

12:55:09 [RRSAgent]

RRSAgent has joined #tagmem

12:55:15 [Zakim]

Zakim has joined #tagmem

13:41:47 [DanCon]

DanCon has joined #tagmem

14:17:24 [Norm]

Norm has joined #tagmem

14:22:12 [Stuart]

Stuart has joined #tagmem

14:25:20 [DanCon]

that was *almost* suggested text. But it wasn't actual suggested text.

14:25:57 [DanCon]

folks seem to feel free to spout whatever opinion comes to mind, with no obligation to contribute to an architecture document.

14:26:17 [DanCon]

not your posting, Stuart.

14:26:20 [DanCon]

but most of the others.

14:26:42 [DanCon]

RRSAgent, pointer?

14:26:42 [RRSAgent]

See http://www.w3.org/2002/04/22-tagmem-irc#T14-26-42

14:26:46 [Stuart]

yep... it's a big thread...

14:26:57 [Stuart]

What is RRSAgent?

14:27:08 [DanCon]

a log-to-http-space service

14:27:34 [DanCon]

it does a few other things... tracks action items, I think. try: /msg RRSAgent help

14:30:24 [Norm]

zakim, list conferences

14:30:25 [Zakim]

I see VB_Multi()10:00AM, Team_Comm()9:30AM, T&S_()10:00AM, TAG_Weekly()10:00AM

14:30:35 [DanCon]

Zakim, this will be TAG

14:30:36 [Zakim]

ok, DanCon, I see TAG_Weekly()10:00AM already started

14:30:44 [Norm]

Dan beat me to it

14:32:57 [Zakim]

+DanC

14:33:41 [Zakim]

+Ian

14:34:00 [Ian]

zakim, who's here?

14:34:01 [Zakim]

I see ??P32, ??P34, ??P2, DanC, Ian

14:34:12 [Ian]

zakim, ??P32 might be Paul

14:34:13 [Zakim]

I don't understand '??P32 might be Paul', Ian. Try /msg Zakim help

14:34:19 [Ian]

zakim, ??P32 may be Paul

14:34:20 [Zakim]

+Paul?; got it

14:34:32 [Ian]

zakim, ??P34 may be Stuart

14:34:33 [Zakim]

+Stuart?; got it

14:34:39 [Ian]

zakim, ??P2 may be Norm

14:34:40 [Zakim]

+Norm?; got it

14:34:49 [Zakim]

+TBray

14:35:10 [Ian]

zakim, mute Norm

14:35:11 [Zakim]

Norm? should now be muted

14:35:35 [Ian]

zakim, Norm is Paul

14:35:36 [Zakim]

+Paul; got it

14:35:43 [Ian]

zakim, who's here?

14:35:44 [Zakim]

I see Paul?, Stuart?, Paul (muted), DanC, Ian, TBray

14:35:54 [Ian]

zakim, unmute Paul

14:35:55 [Zakim]

'Paul' is ambiguous, Ian

14:36:05 [Ian]

zakim, mute Paul?

14:36:07 [Zakim]

Paul? should now be muted

14:36:15 [Norm]

zakim, who's here?

14:36:17 [Zakim]

I see Paul? (muted), Stuart?, Paul (muted), DanC, Ian, TBray

14:36:24 [Ian]

zakim, Paul? is Stuart

14:36:25 [Zakim]

+Stuart; got it

14:36:26 [Stuart]

can you hear me

14:36:30 [Norm]

no

14:36:34 [Ian]

zakim, Stuart? is Norm

14:36:35 [Zakim]

+Norm; got it

14:36:40 [Stuart]

then I'm muted

14:36:43 [Ian]

zakim, unmute Paul

14:36:44 [Zakim]

Paul should no longer be muted

14:36:47 [Ian]

zakim, who's here?

14:36:49 [Zakim]

I see Stuart (muted), Norm, Paul, DanC, Ian, TBray

14:36:54 [DanCon]

ack Stuart

14:36:56 [Ian]

zakim, unmute Stuart

14:36:57 [Zakim]

Stuart was not muted, Ian

14:37:07 [Norm]

zakim, who's here

14:37:10 [Zakim]

Norm, you need to end that query with '?'

14:37:15 [Ian]

Regrets: TBL

14:37:18 [DanCon]

Stuart: not here yet: DaveO, RoyF, TimBL

14:37:22 [Norm]

zakim, who's here?

14:37:23 [Zakim]

I see Stuart, Norm, Paul, DanC, Ian, TBray

14:37:27 [DanCon]

Stuart: not here yet: DaveO, RoyF, TimBL, ChrisL

14:37:59 [Ian]

--------------------

14:38:07 [Ian]

Minutes of previous meeting? No objections.

14:38:17 [Ian]

Comments on this agenda?

14:38:23 [Zakim]

+DOrchard

14:38:32 [Ian]

SW: I've put time allotments on the agenda; I hope it's useful.

14:38:53 [Ian]

Agenda: http://www.w3.org/2002/04/22-tag

14:39:35 [Ian]

SW: Additions? None.

14:39:45 [Ian]

Action item review:

14:39:56 [Ian]

DO: Write text about "Web as information space", to be integrated by IJ. Status - not done.

14:40:07 [Ian]

IJ: Integrate/combine one-page summaries. Status - not done

14:40:48 [Ian]

TBL Actions not done.

14:40:56 [Ian]

RF: Write up discussion of RFC3205 based on www-tag input.

14:41:02 [Ian]

Status Done: http://lists.w3.org/Archives/Public/www-tag/2002Apr/0221.html

14:41:53 [Ian]

DC: I propose to withdraw the action.

14:42:16 [Ian]

DC: Correction - RF's message is a proposal to withdraw the action.

14:42:38 [Ian]

SW: Action hereby withdrawn; we'll pick up when we address HTTPSubstrate-16.

14:42:43 [Ian]

================

14:42:50 [Ian]

Prioritization of issues list.

14:42:55 [Ian]

Strawman from SW:

14:43:45 [Ian]

DC: For me the priority is whatever goes first in the arch doc. I find it hard to address these issues without context.

14:43:53 [Zakim]

+??P0

14:43:55 [TBray]

TBray has joined #tagmem

14:43:57 [Ian]

SW: So, order by doc order, not urgency/sense of importance.

14:44:12 [Ian]

DC: Doc order is not arbitrary; things earlier should depend on fewer other things.

14:44:15 [TBray]

Hah... figured out my IRC client

14:44:17 [Ian]

zakim, ??P0 is Roy

14:44:17 [Zakim]

+Roy; got it

14:44:19 [DanCon]

Zakim, ??P0 is RoyF

14:44:22 [Zakim]

sorry, DanCon, I do not recognize a party named '??P0'

14:45:30 [Ian]

TB: Two thoughts:

14:45:41 [Ian]

a) Agree with DC about starting from points of few dependencies outward.

14:45:58 [Ian]

b) Also order based on urgency relative to work going on in w3c.

14:46:16 [Ian]

(e.g., GET in SOAP)

14:47:33 [Ian]

TB: I like SW's list; it seems to meet both criteria (a) and (b).

14:47:45 [Ian]

(with exception of *-13 first).

14:48:30 [Ian]

TB: I propose 7 first, then the rest of the list as is.

14:48:40 [Ian]

TB: 7, 13, 15, 6, 14, 16, 8

14:48:58 [Ian]

SW records no dissent.

14:49:01 [Ian]

===============

14:49:10 [DanCon]

is 13 really supposed to be in that list?

14:49:26 [Ian]

Correction:

14:49:52 [Ian]

Handle issues in this order: 7, 15, 6, 14, 16, 8, 13

14:49:53 [Dave]

Dave has joined #tagmem

14:49:55 [Ian]

==================

14:50:06 [Ian]

1. Draft Finding on Media-Types how do we progress this finding - is it done?

14:50:12 [Ian]

http://www.w3.org/2001/tag/2002/0129-mime

14:50:24 [Ian]

SW: Where are we on this? Perilously close to done?

14:50:30 [Ian]

TB, DC: I thought we were done.

14:50:54 [Chris]

Chris has joined #tagmem

14:51:29 [Ian]

Resolved: Accept finding on Media-Types.

14:51:32 [Ian]

DC: Was resolved 8 April.

14:51:33 [DanCon]

" Resolved:

14:51:33 [DanCon]

* Accept TAG finding uriMediaType-9 (as amended)." -- http://www.w3.org/2002/04/08-tag-summary

14:51:48 [Ian]

Action IJ: Publish this as accepted finding.

14:51:58 [Ian]

SW: Correction on DC's comment, that was uriMediaType-9 findings.

14:52:01 [Zakim]

+ChrisL

14:52:03 [TBray]

http://www.w3.org/2001/tag/2002/0129-mime

14:53:08 [Ian]

DC: This thing needs another title.

14:53:36 [Ian]

DC: But I'm not clear we're done with this since I was thinking about something else.

14:53:44 [Ian]

TB: There were grumblings on www-tag, but no loud voices in TAG.

14:53:56 [Ian]

SW: My recollection - three issues tied together. I thought we got closure on 2/3.

14:54:20 [Ian]

NW: I bet grumbling on Namespace-Based Dispatching.

14:55:03 [Chris]

status says "being written" should be "under review" surely

14:55:23 [Ian]

DC: Note that resources don't have mime types, response headers do.

14:55:51 [Norm]

q+

14:56:26 [Ian]

TB: Right, you're not talking about resource here, but message back from server.

14:57:01 [Norm]

q-

14:57:07 [Ian]

NW: I propose removing contentious bit (namespace-based dispatching) and moving to "what does a namespace mean"?

14:57:13 [Ian]

TB, CL: Seconded.

14:57:17 [Chris]

ok, agreed

14:57:19 [Ian]

Resolved:

14:58:04 [Ian]

- Publish as accepted fixing charset sentence, and move to mixedNamespaceMeaning issue.

14:58:08 [Ian]

PC: Agreed.

14:58:09 [DanCon]

PROPOSED: nuke NS section, tweak charset (s/resource/response), accept findings on media types. http://www.w3.org/2001/tag/2002/0129-mime

14:58:24 [Ian]

Action IJ: Publish finding, move dispatching bit to other issue.

14:58:28 [DanCon]

so RESOLVED.

14:58:35 [Ian]

==================

14:58:41 [Ian]

* "Guidelines For The Use of XML in IETF Protocols" IETF best practices draft requiring URNs for XML namespaces in IETF documents

14:58:45 [Ian]

http://www.imc.org/ietf-xml-use/draft-hollenbeck-ietf-xml-guide.html

14:58:55 [Ian]

CL: I sent notes on this:

14:59:22 [Ian]

http://lists.w3.org/Archives/Public/www-tag/2002Apr/0223.html

14:59:33 [Ian]

CL: I said:

15:00:04 [Chris]

"In the case of namespaces in IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used for this purpose. "

15:00:04 [Chris]

Yes, great. Wish we could assign them an action to go do that and say what the base URI is?

15:00:28 [Chris]

for HTTP, that is

15:00:58 [Ian]

TB: Has this draft changed recently?

15:01:03 [DanCon]

"W3C recommended practice" should cite "URIs for W3C namespaces" http://www.w3.org/1999/10/nsuri

15:01:05 [Ian]

SW: I have 15 April on it.

15:01:25 [Ian]

TB: I would bet $100 that when I first read this, pro URN slant was stronger. I may be wrong, though. This version is hard to object to as is.

15:01:48 [Zakim]

-Paul

15:02:04 [Ian]

SW: Is the IETF wrong to mandate URNs for namespace names?

15:02:10 [Ian]

(section 4.5).

15:02:38 [TBray]

q+

15:02:41 [Ian]

DO: I've read through CL's summary. In general, I would say that most of CL's comments are good personal comments but not required to be TAG comments.

15:02:52 [Ian]

DO: I think the TAG should highlight the particular namespace issue.

15:03:14 [Ian]

TB: This has *clearly* been rewritten since I see that some things have been fixed since I first read it.

15:03:16 [Chris]

TB notes this has *clearly* been rewritten yet still says 01.txt

15:03:32 [Ian]

TB: It would be nice if IETF kept around previous versions.

15:03:53 [Ian]

CL: This isn't the primary source.

15:04:02 [Ian]

DC: They start with "00".

15:04:23 [Chris]

dc notes numbering stats at 00.txt

15:04:29 [Chris]

All: Aha!

15:04:39 [Ian]

Resolved: Postponed to allow TAG to reread.

15:04:45 [Ian]

Homework: Read version 01.

15:05:35 [Ian]

CL: I will resort and prioritize my comments for next week.

15:05:37 [Ian]

============================

15:05:42 [Ian]

When to use GET?

15:05:43 [Chris]

ACTION CL to re-sort notes into priority order for next week

15:06:07 [Ian]

whenToUseGet-7: http://lists.w3.org/Archives/Member/tag/2002Apr/0019.html

15:06:15 [Ian]

See SW proposal on when to use Post:

15:06:42 [Ian]

DC: Demoralizing to get hundreds of comments without a proposal for alternative.

15:06:55 [Ian]

SW comments: http://lists.w3.org/Archives/Public/www-tag/2002Apr/0222.html

15:07:16 [Ian]

DC: I didn't hear disagreement about bad idea to subscribe someone to mailing list as result of GET.

15:07:22 [Stuart]

q?

15:07:35 [Ian]

DO: I proposed s/should/may, or to use GET for browser-centric applications.

15:07:59 [Ian]

NW: I am disappointed if we get down to application level in an arch document.

15:08:40 [Ian]

CL: I agree that in general, we should go for generality. But if we can't get agreement on general points, let's consider important specifics (e.g., browsers).

15:08:45 [Ian]

TB: I proposed a solution:

15:08:52 [Ian]

http://lists.w3.org/Archives/Public/www-tag/2002Apr/0211.html

15:09:13 [Dave]

q+

15:09:23 [Ian]

TB: "

15:09:25 [Ian]

"I propose that for those proportion of SOAP requests that consist of a

15:09:25 [Ian]

service name plus a sequence of name-value-pair arguments, we devise a

15:09:25 [Ian]

simple url encoding.

15:09:25 [Ian]

"

15:09:52 [Ian]

TB: I made this proposal in good faith, even if it had been suggested before.

15:09:58 [Stuart]

ack TBray

15:10:03 [Ian]

DO: I find the suggestion interesting, but I don't think it addresses most peoples' issues.

15:10:26 [Ian]

DO: I think that people who want to use GET for safe methods won't be satisfied. People who are adamantly for POST won't be happy either.

15:10:34 [Zakim]

+??P18

15:10:46 [DanCon]

hmm... as to whether the case when SOAP stuff can be url-encoded being a small number of cases... seems to me it's the big part of the 80/20 bucket. e.g. the hello-world SOAP app, getStockQuote, fits quite neatly

15:10:46 [Ian]

zakim, ??P18 is Paul

15:10:47 [Zakim]

+Paul; got it

15:10:51 [Ian]

zakim, who's here?

15:10:52 [Zakim]

I see Stuart, Norm, DanC, Ian, TBray, DOrchard, Roy, ChrisL, Paul

15:10:59 [Stuart]

q?

15:11:07 [Ian]

ack dave

15:11:09 [Chris]

ack Dave

15:11:10 [TBray]

q+

15:11:22 [Ian]

DC: URL-encoding hasn't picked up any steam.

15:11:38 [Ian]

DC: See comments from Mark Nottingham - http://lists.w3.org/Archives/Public/www-tag/2002Apr/0213.html

15:11:47 [Ian]

...WG not excited by this before.

15:11:55 [Ian]

TB: But if the TAG is expressing interest in this, that might help.

15:12:52 [Ian]

DO: There are a couple of people in XMLP WG who are interested in this topic. Why is there such a clean disconnect between these two polar views?

15:13:08 [Ian]

DO: I don't think that just saying "you're doing it wrong" addresses the gap in understanding.

15:13:39 [Ian]

DC: I've talked to 5 people XMLP WG and all of them said "Yes, GET would be the more straightforward method for simple applications like stock quotes."

15:13:56 [Ian]

DC: And I hear XMLP WG participants saying "We're not interested in the simple applications."

15:14:06 [Ian]

DO: But we hate the stock quote example.

15:14:19 [Ian]

DO: I'd like to hear how use of POST is actively harmful and how GET would be better.

15:14:27 [Ian]

DC: Paul Prescod, TB gave reasons.

15:14:51 [Ian]

PP's email: http://lists.w3.org/Archives/Public/www-tag/2002Apr/0210.html

15:14:52 [Chris]

q+

15:15:08 [Stuart]

ack DanCon

15:15:10 [Ian]

DO: Reasons for certain styles of applications have been given. But there are other classes of applications where it's not clear.

15:15:19 [Ian]

DO: I don't think it comes up in practice.

15:15:33 [Ian]

RF: Paul is describing Web applications. The Web Services community is not dealing with Web applications.

15:15:37 [Ian]

DO: I liked RF's posting:

15:16:00 [DanCon]

"urls for everything"??? execpt information available via SOAP services.

15:16:32 [Ian]

RF: Web Services doesn't use URLs for everything. That's the problem. If something uses a URL to identify something makes it a Web application.

15:16:42 [TBray]

q?

15:16:57 [Ian]

RF: Here's the exact principle involved: "URIs should be used to identify all important resources." Web services doesn't do this.

15:17:17 [Ian]

RF: The reason you want to use GET is that it requires URI for identification; that makes it available to other applications on the Web.

15:17:37 [Ian]

DO: I lobbied that part of definition of a Web Service was that it be addressable by URI. That's been accepted as a draft definition.

15:17:44 [Ian]

DC: The price of the stock is not addressable.

15:17:46 [Ian]

q?

15:17:52 [Ian]

ack TBray

15:18:02 [Ian]

TB: DO and I drawing 2 conclusions from same facts.

15:18:24 [DanCon]

hmm... reviewing http://www.w3.org/TR/2001/WD-soap12-part0-20011217/ looking for what's now considered the meat-and-potatoes applications of SOAP.

15:18:45 [Ian]

TB: I disagree that stock quotes as hello world is a small subset of Web Services; I think it's a more important class; I think should be addressable by URL; I proposed a simple approach for doing this; I'd like to hear a cogent reason why not a good idea.

15:19:12 [Ian]

RF: If the same naming authority, that server can define any URI for that service; better than a service with no URIs into it.

15:19:57 [Ian]

TB: I agree that a large proportion of Web Services transactions may be densely structured, unsafe, etc. I don't see the benefit of going after those. But for the subset of request/response that are safe, let's use URL-encoding.

15:20:21 [Ian]

DO: Did you see MN's response on URL length?

15:20:35 [Ian]

TB: I've been doing this for years; never seen an application break due to URL length.

15:21:13 [Ian]

RF: The overall issue - if URLs tend to be long in a service, then all of the technology between them and the client improves over time. I think it's been at least six years since 256 char limits on URLs.

15:21:31 [Dave]

q+

15:21:34 [Chris]

There is a class of application where POST is superior to GET when sending a message body such as a form result - unambiguous charset encoding for the body. Known problem with interoperability of forms in multilingual sites that depend on "charset of origin page" when url is bookmarked and there is no origin page

15:21:39 [Ian]

TB: Any anything you can't pack into a reasonable URL length is probably not good candidate for GET anyway.

15:22:11 [DanCon]

I considered writing up this "if it's long, it's not addressable" and Larry has already given counter-examples: "validation result for this (appended) document?" or... "images like this one?"

15:22:42 [Ian]

q?

15:22:48 [Ian]

ack Chris

15:22:53 [DanCon]

(not counter-examples, exactly, but... er... nevermind)

15:22:55 [Stuart]

Q+

15:23:30 [Ian]

RF: There's no basis for "everything must use GET" in Web architecture. There is for "use an URI for everything that's important".

15:23:42 [Stuart]

ack Dave

15:24:30 [Ian]

DO: I personally have gone to significant effort to harmonize Web services with the Web (use of URIs, use of XML, right use of HTTP). But to find out my efforts have been in vain (still doing the wrong thing) is disappointing.

15:24:51 [Ian]

DO: If we are using URIs wrong, a more problematic area of misunderstanding.

15:25:22 [Ian]

TB: I assert that there are classes of Web Services that are addressable by URI and accessible by GET. Web services (SOAP) today does not enable that. There is a low cost solution to address this.

15:25:58 [DanCon]

hmm... after scanning the SOAP primer, I don't see any discussion of mapping Java/Perl/python method calls to SOAP calls. did 'object access' go away somewhere?

15:25:59 [Ian]

DO: TB has said that to hit the 80/20 point, it would be useful to have this particular feature. I am not saying this is uninteresting. I just don't think it's a principle of the Web.

15:26:14 [Ian]

TB: I would argue that first principle of Web is that things have URIs and bet GETable.

15:27:05 [Ian]

Refer to finding -9: http://www.w3.org/2001/tag/2002/01-uriMediaType-9

15:27:11 [Ian]

" * All important resources should be identifiable by URI.

15:27:11 [Ian]

"

15:27:27 [Stuart]

ack Stuart

15:27:42 [Ian]

DO: I think we are allowing Web Services to be addressable by URI.

15:27:56 [Ian]

DC: The results are addressable in the case of GET but not of POST.

15:29:14 [Ian]

[DC talking about SOAP features]

15:29:22 [TBray]

Ian: DO: TB has said that to hit the 80/20 point, it would be useful to have this particular feature. I am not saying this is uninteresting. I just don't think it's a principle of the Web.

15:29:22 [TBray]

Ian: TB: I would argue that first principle of Web is that things have URIs and bet GETable.

15:29:22 [TBray]

Ian: Refer to finding -9: http://www.w3.org/2001/tag/2002/01-uriMediaType-9

15:29:22 [TBray]

Ian: " * All important resources should be identifiable by URI.

15:29:25 [TBray]

Ian: "

15:29:26 [TBray]

DanCon q+

15:29:29 [TBray]

Zakim sees Stuart, DanCon on the speaker queue

15:29:56 [TBray]

Oops... had a little IRC error there

15:29:56 [Ian]

[DC comments on Primer]

15:30:13 [Ian]

PC: I don't think that the primer has ever used the term "java" or described the scenario DC described.

15:30:46 [Ian]

DC: The scenario is there in the larger community [Scribe didn't get scenario, but about querying to find out about safe methods]

15:31:05 [TBray]

q+

15:31:44 [Ian]

PC: DC, you must distinguish the evolution of the use of SOAP. In scenario where URI points to an encapsulation of our favorite logic (and service described in WSDL, which can be consumed by SOAP-enabled software); this kickstarted SOAP from existing services, but lots of people today are writing their WSDL directly.

15:31:57 [Stuart]

ack DanCon

15:32:30 [Ian]

DO: I hear people saying coarse-grain interactions more useful; avoid a multitude of back-and-forth interactions.

15:32:57 [Ian]

PC: Most of these document-centered objects are synchronous. Typically you want your web service to be asynch.

15:32:59 [TBray]

q?

15:33:14 [Ian]

DC: Summarizing - taking your API and hitting the button to create a Web Service is apparently no longer the right thing to do.

15:34:04 [Ian]

TB: As an XML editor, I am profoundly uninterested in Web Service community's predictions about how the tools they are producing will be used.

15:34:17 [Norm]

"No one expects the Spanish Inquisition"

15:34:28 [Ian]

TB: My personal opinion is that a low-rent RPC request/response based on SOAP wrappers will be widely used.

15:34:35 [Dave]

norm, lol

15:34:45 [Ian]

TB: ...but whether widely used or not widely used, why isn't a good thing to expose as a URI.

15:35:20 [Ian]

SW: Are we going to say anything about the use of POST to do safe things?

15:35:24 [Ian]

DC: That seems in order.

15:35:58 [Ian]

Action DC: Write more on whenToUseGet.

15:36:12 [Ian]

DC: Look at it more as "make things addressable"

15:36:18 [Ian]

============================

15:36:21 [Chris]

to concentrate on "make things addressable"

15:36:36 [Ian]

------------------

15:37:00 [Ian]

Architecture Document, Status, Discussion

15:37:10 [Ian]

IJ: Not much progress due to ongoing work on Process Doc and UAAG 1.0.

15:37:54 [Ian]

PC: What about status of this doc at AC meeting?

15:38:06 [Ian]

IJ: TBL's slides point more to categorization than arch document.

15:38:21 [Ian]

PC: Should we get AC to read this before the meeting?

15:38:25 [Ian]

RF: Seems unlikely.

15:38:54 [Stuart]

q?

15:39:10 [Stuart]

ack TBray

15:40:01 [Ian]

IJ: AC agenda will be sent out soon.

15:40:23 [Ian]

PC: I think the agenda is too late.

15:41:34 [Ian]

SW: What about feedback on other pieces to go in arch document?

15:43:16 [Ian]

Looking at: Current State slide

15:44:04 [Ian]

PC: Point to arch doc IJ has been working on?

15:44:09 [Ian]

IJ: I don't think it's mature enough yet.

15:44:38 [Ian]

IJ: I intend to make progress on this this week.

15:44:55 [Ian]

[PC may not be at next week's meeting.]

15:45:10 [Ian]

PC: Will there be a monthly summary end of April?

15:45:13 [Ian]

IJ: Yes, I intend to.

15:46:08 [Ian]

Next meeting: 29 April.

15:46:42 [Ian]

Adjourned.

15:46:46 [Zakim]

-ChrisL

15:46:51 [Zakim]

-DanC

15:46:54 [Zakim]

-Paul

15:46:55 [Zakim]

-Ian

15:47:00 [Ian]

RRSAgent, stop