IRC log of tagmem on 2003-01-27

Timestamps are in UTC.

19:44:02 [RRSAgent]
RRSAgent has joined #tagmem
19:53:43 [Ian]
Ian has joined #tagmem
19:56:24 [Ian]
RRSAgent, start
19:57:21 [Chris]
Chris has joined #tagmem
19:57:44 [Chris]
rrsagent, pointer?
19:57:44 [RRSAgent]
19:59:22 [Roy]
Roy has joined #tagmem
20:00:46 [Ian]
zakim, this is TAG
20:00:47 [Zakim]
sorry, Ian, I do not see a conference named 'TAG'
20:00:53 [Ian]
zakim, who is here?
20:00:54 [Zakim]
sorry, Ian, I don't know what conference this is
20:00:55 [Zakim]
On IRC I see Roy, Chris, Ian, RRSAgent, Zakim, DanCon, Stuart
20:01:00 [Ian]
zakim, this is TAG
20:01:01 [Zakim]
sorry, Ian, I do not see a conference named 'TAG'
20:01:10 [Ian]
zakim, this is TAG
20:01:11 [Zakim]
sorry, Ian, I do not see a conference named 'TAG'
20:01:32 [Ian]
zakim, this is TAG_weekly
20:01:33 [Zakim]
sorry, Ian, I do not see a conference named 'TAG_weekly'
20:01:40 [Chris]
zakim, get it together you robot
20:01:41 [Zakim]
I don't understand 'get it together you robot', Chris
20:01:54 [Ian]
zakim, this is TAG
20:01:55 [Zakim]
sorry, Ian, I do not see a conference named 'TAG'
20:02:24 [TBray]
TBray has joined #tagmem
20:02:30 [Roy]
zakim. the meaning of life
20:03:05 [Ian]
Regrets: NW, TBL
20:03:31 [Roy]
zakim, who is here
20:03:32 [Zakim]
Roy, you need to end that query with '?'
20:03:36 [Ian]
Present: PC, RF, DC, CL, IJ, SW, TB
20:03:44 [Ian]
Unknown: DO
20:04:19 [Ian]
Resolved: Accept minutes from 20 Jan (IJ made RF change).
20:04:24 [DanCon] $Date: 2003/01/23 07:11:06 $
20:04:26 [Ian]
Next meeting: 3 Feb, short meeting.
20:04:51 [Ian]
[No regrets]
20:05:10 [Ian]
20:05:12 [Ian]
This agenda.
20:05:18 [Ian]
20:06:03 [Ian]
Present: DO
20:06:35 [Ian]
Bill De Hora's comment
20:06:52 [Ian]
DC: I feel no obligation to discuss this in previous meetings.
20:06:58 [TBray]
what Dan said
20:07:25 [TBray]
20:07:42 [Ian]
CL: BDH's question has not been ignored on the list.
20:07:45 [Ian]
ack DanCon
20:07:50 [Stuart]
ack DanCon
20:08:08 [Stuart]
ack TBray
20:08:25 [Ian]
TB: In light of further traffic on www-tag (and xml-dev in parallel), my opinion has gotten stronger that our chances for consensus on this point are small.
20:08:40 [Ian]
TB: I agree that TBL's world view is consistent; I just don't believe it.
20:09:58 [Ian]
Action SW: Tell www-tag that we have agreed not to discuss this.
20:10:13 [Ian]
IJ: I think this issue may be blocking us in practice, even if we have said in the past it's not critical path.
20:10:36 [Roy]
20:11:11 [Ian]
DO: I don't know what new information there has been to cause us to reopen this.
20:11:35 [Chris]
I agree on the 'what text needs to change' criterion
20:11:48 [Ian]
RF: I've spent a lot of time drafting messages; they had nothing to do with httpRange-14 except in the periphery. The purpose of those messages was to establish what we should put in the arch doc.
20:12:17 [Ian]
RF: If TBL wants to describe the Web as everything the W3C is doing, we have to write another document. We need to write a model that describes it all.
20:12:37 [Ian]
RF: The REST model does not describe the SemWeb architecture.
20:13:19 [TBray]
20:13:20 [Ian]
RF: The reason we have to make a choice: I can describe the system that exists without talking about anything in the future (by looking at implementations).
20:13:28 [Ian]
ack Roy
20:13:48 [Ian]
RF: Whether we want to talk about the future will affect our description.
20:13:57 [Ian]
DO: There is similar discussion going on in Web Services area.
20:13:59 [Ian]
20:14:14 [Chris]
but if there are no implementations in that area, isn't it premature to try and abstract out their properties?
20:14:53 [Ian]
[Agreement to talk about "What should go in the arch doc" at the ftf meeting.]
20:15:33 [Ian]
ack TBray
20:15:52 [Ian]
PC: I think it's important that at our ftf, we talk about www-tag and perhaps a need to organize threads.
20:16:31 [Ian]
SW: We shan't discuss httpRange-14 today; will not be on agenda any time soon.
20:16:34 [Ian]
20:16:51 [DanCon]
ah; ftf agenda linked from today's telcon agenda
20:17:35 [DanCon]
Mon, 27 Jan 2003 18:14:47 -0000
20:17:35 [Stuart]
20:17:45 [Ian]
F2F Planning: Agenda proposal and Issue strawpoll.
20:18:27 [Ian]
SW: I will send the agenda by COB Weds.
20:18:38 [Ian]
20:18:41 [Ian]
TAG at the tech plenary
20:19:01 [Ian]
DO: Tech plenary planning committee has met.
20:19:05 [Ian]
DO: See msg from PC to tag
20:19:10 [Ian]
20:19:25 [DanCon]
"short" and "5 segments" don't both fit in my brain at the same time
20:19:39 [Chris]
20:20:59 [Ian]
ack Chris
20:21:17 [Ian]
CL: Good idea to pick top three issues and get input. XML id, XML subsetting good.
20:22:34 [Ian]
DO: We'll use BOF to talk about linking.
20:22:43 [Chris]
discussion *with knives* - cool!
20:22:53 [Ian]
[Discussion of fact that xml id and xml subsetting orthogonal.]
20:23:02 [Ian]
PC: Looking to have 90 minutes with non-TAG moderator
20:23:47 [Ian]
PC: The message is that people want more technical content.
20:24:22 [Ian]
DO: I was hoping to have no process discussion; we'll have a short discussion.
20:24:29 [DanCon]
I'd be happy letting any process discussion come up as Q&A.
20:24:43 [Stuart]
20:24:51 [Chris]
I think 10 mins is an acceptable compromise but lets hold it to that and not let it spread into the technical part
20:24:58 [Stuart]
ack DanCon
20:24:59 [Zakim]
DanCon, you wanted to ask about discussion mode/logistics (panel? presentations? other?)
20:25:11 [Ian]
PC: I think Steve Zilles should moderate.
20:25:17 [Ian]
DO, CL: Good idea.
20:26:11 [Ian]
Confirmed to attend and participate: CL, DC, PC, DO
20:26:17 [Ian]
LIkely regrets: TB, RF, SW
20:26:41 [Ian]
PC: NW should be there for XSL meetings
20:26:50 [DanCon]
ack danc
20:26:53 [Stuart]
20:29:38 [Ian]
[Defer discussion to ftf meeting]
20:29:54 [Chris]
ACTION ij have firm date suggestions in time for f2f
20:30:05 [Ian]
I've already sent this.
20:30:15 [Chris]
ACTION closed ;-)
20:30:15 [Ian]
Reiterated: AB 16th, TAG 17th, AC 18th-19th
20:30:30 [Ian]
20:30:50 [Ian]
SW: Please read editor's draft of Arch Doc to prepare for FTF meeting
20:30:53 [Ian]
20:31:06 [Ian]
CL: I've started putting together a chapter three. [progress]
20:31:27 [Ian]
CL: I may have something shortly before the ftf meeting. I'll try to have enough in advance to read on plane.
20:31:41 [Chris]
20:32:00 [Ian]
3. Complete review of TBs proposed principles CP9, CP10 and CP11
20:32:00 [Ian]
20:32:15 [Ian]
20:32:32 [Ian]
20:32:33 [Ian]
CP9. Designers of protocols should invest time in understanding the REST
20:32:33 [Ian]
paradigm and consider the role to which its principles should guide
20:32:33 [Ian]
their design:
20:32:33 [Ian]
- statelessness
20:32:33 [Ian]
- clear assignment of roles to parties
20:32:35 [Ian]
- flat addrss space
20:32:39 [Ian]
- limited uniform set of verbs
20:33:20 [Chris]
yes, agreed
20:33:47 [Ian]
ack DanCon
20:33:48 [Zakim]
DanCon, you wanted to ask for 4 corners around REST
20:33:56 [Ian]
DC: Are these the top four things for REST?
20:33:58 [Chris]
20:34:43 [Ian]
RF: "Uniform address space"
20:35:19 [Ian]
DC: I have no objection to this, but would rather explain how to do a Web page / how not to.
20:35:28 [Ian]
DC: I'd be willing to write something up.
20:35:35 [Chris]
ACTION DC write two pages on correct and incorrect application of REST to an actual web page design
20:35:45 [DanCon]
(I was talking about a finding... webarch editor to steal as much/little text as he likes)
20:35:47 [Chris]
or a web service
20:36:12 [TBray]
agree with Roy s/flat/uniform/
20:36:25 [DanCon]
note to self: OpenGIS mapping service is a *great* example of a straightforward "uniform address space" service
20:36:26 [Stuart]
20:37:20 [Ian]
DO: I'm writing something in Web Services area that's related.
20:37:32 [Ian]
DO: I'd have to publish this info....
20:38:34 [Ian]
DO: My goal is different - someone who believes in REST can say "this is how I would build a REST-based Web service" and someone more interested in RPC could do things according to that style.
20:39:21 [Ian]
Action DO: Please send writings to DO grants DC license to cut and paste and put into DC writing.
20:40:34 [Ian]
TB: Per our charter, please send info to www-tag.
20:41:03 [Ian]
RF: One reason is that we are talking about WS Arch....
20:41:17 [Ian]
TB: Ok, but I'll keep pushing for www-tag.
20:41:32 [Ian]
Resolved: Accept CP9 with s/flat/uniform.
20:41:34 [Ian]
20:41:39 [Ian]
CP10. Agents which receive a resource representation accompanied by an
20:41:39 [Ian]
Internet Media Type MUST interpret the representation according to the
20:41:39 [Ian]
semantics of that Media Type and other header information. Servers
20:41:39 [Ian]
which generate representations MUST not generate Media Types and other
20:41:39 [Ian]
header information (for example charsets) unless there is certainty that
20:41:41 [Ian]
the headers are correct.
20:42:14 [Ian]
20:42:16 [Ian]
20:42:19 [Chris]
20:42:35 [Ian]
CL: Yeah to CP10
20:42:50 [Chris]
+1 to add this as is
20:42:50 [Ian]
ack Ian
20:42:54 [Ian]
See finding
20:42:58 [Ian]
20:43:18 [Chris]
ack Chris
20:43:21 [Stuart]
ack Chris
20:43:42 [Ian]
20:43:48 [Ian]
Internet Media Type registration, consistency of use
20:43:51 [Chris]
q+ to ask Paul C if he is really sure
20:43:57 [Ian]
"The architecture of the Web depends on applications making dispatching and security decisions for resources based on their Internet Media Types and other MIME headers. It is a serious error for the response body to be inconsistent with the assertions made about it by the MIME headers. Web software SHOULD NOT attempt to recover from such errors by guessing, but SHOULD report the error to the user to allow intelligent corrective action."
20:44:38 [Ian]
CL: I like the more general second sentence of CP10 (compared to findnig).
20:44:43 [Ian]
CL: I can elaborate this; and give examples.
20:44:49 [Chris]
I can elaborate this no problem
20:45:10 [Ian]
DC: I prefer what we have in the finding. wget and link checkers don't pay attention to the mime type, and they're still correct.
20:45:41 [Ian]
20:45:45 [Chris]
they are not, arguably correct
20:45:48 [Ian]
ack DanCon
20:45:49 [Zakim]
DanCon, you wanted to wonder about clients like WGET that totally ignore MIME types, in a way that's good.
20:45:54 [Stuart]
ack Dan
20:46:04 [Ian]
ack Chris
20:46:05 [Zakim]
Chris, you wanted to ask Paul C if he is really sure
20:46:36 [TBray]
20:46:38 [DanCon]
DanC: ... and so the way it's phrased here in CP10 doesn't appeal to me.
20:47:10 [Stuart]
ack Ian
20:47:25 [Ian]
IJ: I think there is an ok behavior where the tool says "I'm doing something different." This is different than a user agent doing something and hiding it's incorrect behavior.
20:47:36 [Ian]
TB: I support moving finding info into arch doc.
20:47:51 [Stuart]
ack TBray
20:47:53 [Ian]
TB: I think we need to say more about "Servers
20:47:53 [Ian]
which generate representations MUST not generate Media Types and other
20:47:53 [Ian]
header information (for example charsets) unless there is certainty that
20:47:53 [Ian]
the headers are correct." in arch doc.
20:48:36 [Ian]
RF: One slight problem - because of some charset interpreting errors in some browsers, often the charset is explicitly given in the doc itself to prevent a cross-site scripting security problem.
20:48:49 [Ian]
TB: If you are sending well-formed XML, it knows what charset it's in.
20:49:27 [Ian]
TB: It's almost always wrong to say what the charset is (and you could get it wrong)
20:49:33 [Chris]
I understand this and can write it in the arch doc
20:49:41 [Ian]
TB: Don't serve as text/xml; transcoders can possibly get it wrong.
20:49:53 [Ian]
Action CL: Include this in arch doc.
20:50:26 [Ian]
s/Include/Draft language.
20:51:39 [Ian]
Action CL: Take language from internet media type registration, propose for arch doc, include sentiment of TB's second sentence from CP10.
20:51:40 [Ian]
20:51:57 [Ian]
CP11. Designers of protocols should give serious consideration to
20:51:57 [Ian]
avoiding such design activities in favor of existing well-established
20:51:57 [Ian]
protocols such as HTTP that fit well into REST.
20:52:17 [Ian]
TB: Another way to say this is : Avoid designing new protocols if you can accomplish what you want with HTTP
20:52:58 [Ian]
DC: I think that TBL has an old action to build a table saying: what patterns would imply good protocols.
20:53:04 [Ian]
20:53:10 [Ian]
TB, IJ: We withdrew that.
20:53:14 [Ian]
[That action]
20:53:30 [Ian]
TB: This is a statement worth making; people should think about using HTTP before running off to design a new protocol.
20:53:43 [Ian]
DO: What are the criteria for using/not using?
20:53:53 [Ian]
TB: That's a larger question that may be worth working on.
20:53:59 [Ian]
DC: "In the Web context" is vague to me.
20:54:12 [Ian]
DC: The IETF practice on record is "Don't use HTTP except for hypertext."
20:54:18 [Ian]
DC: Handwaving won't help us here.
20:54:28 [Ian]
s/IETF practice/IETF best practice/
20:55:24 [Ian]
TB: I have not understood why WebDev was needed as another protocol.
20:55:33 [Ian]
RF: It's written as an extension to HTTP.
20:55:37 [Ian]
DC: It runs on port 80.
20:55:44 [Ian]
DC: My examples are POP and SMTP.
20:56:22 [Ian]
Action TB: Develop CP11 more.
20:56:32 [Ian]
DC: I suggest describing GET/PUT/POST in different paras.
20:56:55 [Ian]
20:56:58 [Ian]
20:57:23 [DanCon]
... describing GET/PUT/POST in a para each, then say "if your app looks like that, use HTTP".
20:57:42 [Ian]
TB: If your protocol needs a notion of a temporally extended session, then HTTP won't help you.
20:57:49 [Ian]
DO: Why would you need one of those?
20:57:57 [Ian]
20:58:09 [Ian]
DO: You'll need to include some examples.
20:58:47 [Ian]
20:58:55 [Ian]
# IRIEverywhere-27
20:58:58 [Ian]
20:59:06 [Ian]
CL: IJ and I discussed this last week.
20:59:12 [Ian]
CL: We drew up some text.
20:59:18 [Ian]
20:59:21 [Ian]
ack Ian
20:59:29 [Ian]
CL: Text based on input from Martin.
21:01:13 [Ian]
DC: Value of treating e and E as equivalent is a huge cost. What actual value do you get?
21:01:25 [Ian]
CL: Actual value is that both are equivalent to the same character.
21:01:37 [Ian]
TB: Lots of software is already treating %7e and %7E as the same.
21:01:38 [Chris]
that they are equivalent to the *actual character* represented
21:01:47 [Chris]
uri spec is way fuzzy on this
21:01:53 [Chris]
actual practice is that they are the same
21:02:21 [Ian]
TB: Per 2396, I think Web robots are in their rights; lots of Web robots do this.
21:02:24 [Ian]
RF: Yes, that's my understanding.
21:02:32 [Ian]
PC: Chris, could you explain impact?
21:02:35 [Ian]
21:02:46 [DanCon]
I think it's straightforward to read the URI spec as saying that http://a/%7E and http://a/%7e are distinct URIs, and may or may not refer to the same resource.
21:02:58 [DanCon]
roy, you think otherwise?
21:03:10 [Roy]
I think otherwise
21:03:18 [Stuart]
I read it the same as Dan :-(
21:03:27 [Ian]
CL: There is a bigger effect on IRI spec and suggestions for RFC2396.
21:03:57 [DanCon]
sigh; each of those URIs is a sequence of 12 characters. they differ in their 12th character. hence they're different URIs. RFC2396 says otherwise?
21:03:59 [Chris]
this has more effect on IRI comparison (which is done by transformation to URI and then comparing)
21:04:16 [Ian]
Action CL: Please propose text IJ and CL worked on to www-tag (flipping the ACL).
21:04:20 [Roy]
%7e is one character -- three octets
21:04:27 [Chris]
it means that the *actual kanji* and the sequence of hexifyied octets compare to the same
21:04:37 [Chris]
which helps in roundtripping a very great deal
21:04:57 [Roy]
oops one octet -- char[3]
21:05:05 [DanCon]
"%7e" is *one* character???
21:05:17 [Roy]
"character" is defined in spec
21:05:18 [TBray]
was ignoring IRC... yes, lots of software will decide those two URIs are the same in their cache
21:05:26 [Chris]
no, %7e is one octet
21:05:26 [Ian]
21:05:30 [Ian]
ack DanCon
21:05:31 [Zakim]
DanCon, you wanted to suggest the value of having %7E specified to be equivalent to %7e is purely aesthetic, and not *nearly* worth the cost.
21:05:32 [Ian]
ack Ian
21:05:34 [Ian]
21:05:39 [Ian]
# binaryXML-30
21:05:42 [Chris]
hence *sequence of *
21:05:45 [TBray]
21:05:50 [Ian]
21:05:57 [Ian]
21:05:57 [Ian]
1. Action CL 2002/12/02: Write up problem statement about binary XML; send to www-tag. See CL email to tag
21:06:05 [Ian]
21:06:05 [Ian]
1. See CL email to tag
21:06:12 [Ian]
21:06:44 [TBray]
21:07:31 [Ian]
TB: I agree that a general public service announcement along the lines of what CL has done would be beneficial.
21:07:34 [DanCon]
yes, chris's msg is the first 80% of a finding, IMO.
21:08:02 [Ian]
TB: I propose that we close the issue; no substantive proposal at this time.
21:08:48 [Ian]
TB summarizing CL mail: The only out there that seems to be making a serious reach at being a broad-spectrum solution is the MIB thing.
21:08:51 [Stuart]
ack TBray
21:08:58 [Chris]
21:09:00 [Ian]
CL: I'd like to post this so that people can say "You aren't aware of this other thing...."
21:09:16 [Ian]
DC: I'd like a week to think about the proposal.
21:09:26 [Chris]
so, getting public review would flush out some alternative solutions we have missed
21:09:30 [DanCon]
ack danc
21:09:31 [Zakim]
DanCon, you wanted to ask for a week or so to consider Bray's proposal
21:09:40 [Ian]
Action CL: Send email 0067 to www-tag for feedback.
21:10:39 [Ian]
TB: I will be astounded if a proposal comes forward that really does meet a broad spectrum of needs. Some requirements are fairly contradictory with each other.
21:12:22 [Ian]
SW: We'll talk about this again in a week.
21:12:58 [Ian]
SW: Rather, ftf meeting is likely next time.
21:13:01 [Ian]
21:13:05 [Ian]
# xmlProfiles-29
21:13:11 [Ian]
21:13:21 [Ian]
TB: Norm's draft:
21:13:25 [Ian]
21:13:42 [Ian]
TB: Was there much disagreement about this?
21:14:19 [Ian]
DO: My pushback was attribution; I don't think there's consensus in the TAG yet. NW wrote his note as NW's position, not TAG position.
21:14:50 [Ian]
DC: I expect that NW will integrate feedback on his position.
21:15:02 [Ian]
DC: At the last meeting, we agreed to comment on NW's text.
21:15:32 [TBray]
21:16:09 [Ian]
TB: I don't think we have a TAG position without further discussion of NW's draft.
21:16:44 [DanCon]
Orchard hasn't responded in substance, has he? he only objected on process grounds. i.e. he hasn't sent his technical position/argument, did he?
21:17:05 [Ian]
NW: I think that there are at least 3 or 4 people who could live with xml:id.
21:17:07 [Ian]
21:17:09 [Stuart]
21:18:00 [Ian]
TB: I thought we were trying to write a note for the AC on a way to proceed.
21:18:22 [Ian]
TB: My sense is that we pretty much agree with NW's draft except for the xml:id part.
21:18:55 [Ian]
PC: I thought I saw public pushback on having profiles at all.
21:20:07 [TBray]
21:20:31 [Ian]
See also:
21:20:59 [Ian]
TB: Mostly I see questions about SOAP and PIs.
21:22:25 [Ian]
TB: We could change "I
21:22:25 [Ian]
feels strongly that it would be a mistake to introduce a single
21:22:25 [Ian]
new feature, or a single change of any sort that would not be
21:22:25 [Ian]
completely compatible with XML 1.1, in the work that subsets XML."
21:22:25 [Ian]
21:22:30 [Ian]
"The question remains open..."
21:22:35 [Ian]
DC: Seconded.
21:22:50 [Ian]
TB summarizes NW's proposal:
21:22:55 [Ian]
"In short, it appears that a new recommendation-track document that
21:22:56 [Ian]
defines a subset of XML 1.1 should be developed:
21:22:56 [Ian]
* The subset must be backwards compatible with XML 1.1.
21:22:56 [Ian]
* The subset must define a language that excludes DTD declarations
21:22:56 [Ian]
How the new recommendation is constructed we leave to the editorial
21:22:57 [Ian]
discretion of the group that undertakes it.
21:22:58 [Ian]
21:23:08 [Ian]
CL: That would mean that you cannot have xml:id; that's not in xml 1.1.
21:23:19 [Ian]
TB: 1.1 processors would not know what it means, but wouldn't have any problems with it.
21:23:25 [Ian]
SW: I'd like NW to concur with this.
21:23:34 [Ian]
DC: I'm happy for him to do that after the fact.
21:23:47 [Ian]
TB: My proposal is to ack that NW feels this way.
21:24:10 [Chris]
sorry, David
21:24:26 [Ian]
DO: One possibility is to ask the AC what they think; another is to hammer this out further.
21:24:29 [TBray]
21:24:43 [Ian]
ack TBray
21:25:05 [Ian]
TB: I think it's cost effective for us to tell the world that we think that there should be an xml 1.1.
21:26:15 [TBray]
21:26:25 [TBray]
did I say 1.2?
21:26:42 [TBray]
no I don't mean to say 1.2
21:26:51 [Ian]
Is there an xml 1.1?
21:26:59 [Ian]
Because I wrote 1.1 earlier, perhaps instead of 1.0....
21:27:19 [Ian]
DC: WRiting to the AC is logistically awkward. I recommend we write to XML Activity lead and recommend that it go to the Director.
21:27:37 [Ian]
21:27:42 [Ian]
ack DanCon
21:27:43 [Zakim]
DanCon, you wanted to ask that the chair put the question, including who we're writing to. Writing to the XML Activity lead, suggesting he take it to the AC, would be my preference
21:27:51 [Ian]
ack Ian
21:28:22 [Ian]
Action IJ: Change one sentence, sent to XML Activity Lead, cc www-tag.
21:28:49 [Ian]
DO: I have some concerns about this; seems like we're pulling a fast one.
21:29:04 [Ian]
DO: I think we could do with more discussion about this.
21:29:50 [Ian]
DO: Perhaps we could do a straw poll on xml:id.
21:30:14 [Ian]
TB: Why don't we accept a new issue on xml:id and get the ball rolling.
21:30:17 [Ian]
PC/TB/DO agree.
21:30:31 [DanCon]
2nded, to accept an issue on xml:id (in case chair is counting toward majority in favor)
21:30:32 [Ian]
DO: If we treat xml:id as a new issue, then ok to send out.
21:30:36 [Ian]
Action DO: Raise new issue.
21:31:00 [Ian]
DO: I will raise issue by tomorrow.
21:31:20 [Ian]
TB PROPOSED: Close this issue with the sending of this letter.
21:31:25 [Ian]
Resolved: Yes.
21:31:30 [Ian]
21:31:35 [Ian]
RRSAgent, stop