17:06:40 RRSAgent has joined #tagmem 17:06:40 logging to http://www.w3.org/2005/10/18-tagmem-irc 17:06:56 There's a point of view that the questions of whether to respond to WSA and what if anything to do on a stateful apps finding are two related issues, both being carried for the moment under endPointRefs-47 17:06:58 DanC has changed the topic to: http://www.w3.org/2001/tag/2005/10/18-agenda.html scribe: ?? 17:07:03 +Roy 17:07:10 dorchard has joined #tagmem 17:07:17 DanC has changed the topic to: http://www.w3.org/2001/tag/2005/10/18-agenda.html scribe: Noah 17:07:28 Meeting: 18 October 2005 TAG Teleconference 17:07:34 scribe: Noah Mendelsohn 17:07:40 scribenick: noah 17:07:52 timbl has joined #tagmem 17:07:54 regrets: Norm, Ed, Henry (partial...here for now) 17:08:05 Topic: Future telcons 17:08:11 VQ: Any regrets for next week 17:08:11 timbl_ has joined #tagmem 17:08:29 Roy has joined #tagmem 17:08:29 checking calendars for 25 Oct, timbl 17:08:37 k 17:08:40 Roy at risk for next week 17:08:51 +TimBL 17:09:18 agenda: http://www.w3.org/2001/tag/2005/10/18-agenda.html 17:09:29 Next week's scribe: Dave Orchard 17:09:57 Topic: Computer Misuse Act and WebArch 17:10:05 VQ: let's do this topic first, so Henry can participate 17:10:26 I found noah's analogy to signs and doors quite good. 17:10:26 yep, regrets for Oct 25 (SNA to DFW) 17:10:26 Noah thanks Dan for the encouragement 17:11:32 Topic: Logistics 17:11:42 DC: let's add issue 37 at end of today's agenda 17:11:57 VQ: comments on last week's minutes? http://www.w3.org/2005/10/11-tagmem-minutes.html 17:12:05 VQ: Noah said OK, anyone else? 17:12:09 ??: me too 17:12:18 VQ: Propose to approve minutes of last week. 17:12:36 RESOLVED: Minutes of telcon of 11 October 2005 at http://www.w3.org/2005/10/11-tagmem-minutes.html are approved 17:12:48 Topic: Computer Misuse Act and WebArch 17:13:03 [1] http://www.theregister.co.uk/2005/10/11/tsunami_hacker_followup/ 17:13:03 [2] http://www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_2.htm#mdiv1 17:13:23 VQ: This was raised on the public TAG list at http://lists.w3.org/Archives/Public/www-tag/2005Oct/0019.html 17:13:32 http://lists.w3.org/Archives/Public/www-tag/2005Oct/0020.html 17:13:32 VQ: Is this from British Law? 17:13:44 TBL: Well, it came in part from a case decided in a British court. 17:14:10 TBL: If Henry's not available, I can summarize my understanding. Disclaimer: I don't know this first hand, and there seem to be inconsistent rumors going around. 17:14:27 TBL: This is all heresay pending a look at official court records. 17:14:57 TBL: It's alleged that a person used ???.bt.com/??? to donate to the Tsunami. I think he'd used a link. 17:15:07 s/used a link/used lynx/ 17:15:13 donate.bt.com 17:15:22 scribe says: "oops, thanks Dan" 17:15:56 TBL: He got no response and got suspicious that he had been victim of phfishing 17:15:57 The actual law in question is http://www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_2.htm#mdiv1 17:16:18 TBL: He tried appending ../../.. (not sure how many) to see if the site was legitimate. 17:16:42 TBL: He was convicted and fined 1000 pounds including costs, even though the judge acknowledged there was no malice. 17:17:02 TBL: We have to said that doing a GET should always be "safe" 17:17:12 HST has also failed to find a full transcript 17:17:31 TBL: There is some suggestion that the judge thought the accused changed his story, which might or might not cloud the evaluation of this particular case 17:17:44 TBL: There is a strong sense in which being fined is "unsafe" 17:18:09 TBL: Perhaps the question is whether he was doing something intentionally to "hack" the site. 17:18:32 TBL: He got an error, but it was the ISP that had a trigger on URIs of that form and flagged it. 17:19:20 TBL: The URI spec clearly points out the danger of using more levels of ../.. than there were / 17:19:26 TBL: The URI spec clearly points out the danger of using more levels of ../.. than there were /'s in the original 17:19:32 NM: Were there more in this case? 17:19:35 TBL: yes 17:19:40 HT: Really, I'm surprised. 17:19:42 HT: Checking 17:19:42 5.4.2. Abnormal Examples 17:19:42 Although the following abnormal examples are unlikely to occur in 17:19:42 normal practice, all URI parsers should be capable of resolving them 17:19:43 consistently. Each example uses the same base as that above. 17:19:43 Parsers must be careful in handling cases where there are more ".." 17:19:45 segments in a relative-path reference than there are hierarchical 17:19:47 levels in the base URI's path. Note that the ".." syntax cannot be 17:19:50 used to change the authority component of a URI. 17:19:52 "../../../g" = "http://a/g" 17:19:55 "../../../../g" = "http://a/g" 17:19:58 Specifically, he accessed the page 17:20:00 http://donate.bt.com/tsunami/relief/../../../ 17:20:22 TBL: So, he did go one level above. 17:20:30 HT: did you get this from my message. 17:20:48 http://news.zdnet.co.uk/internet/security/0,39020375,39226548,00.htm 17:20:56 ^ zdnet articles by John Airey 17:21:03 TBL: No from John Airey's message, for which I will provide a link here. 17:21:58 SCRIBE NOTE TO SELF: Delete link above referencing John Airey 17:22:04 s/link/line/ 17:22:06 by Colin Barker and Graeme Wearden 17:23:33 (is much more background essential? can we move on to discussion of what the TAG should agree on, if only that previous things we've agreed on apply here?) 17:25:15 http://news.bbc.co.uk/1/hi/england/london/4255591.stm 17:25:26 RF: To the extent this information comes from The Register, we should be careful about drawing conclusions as to what happened and whether we have all the details. 17:25:47 TBL: I've put a link to a short BBC article 17:25:54 http://www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_2.htm#mdiv1 17:26:12 HT: I've posted the link to the law in question. 17:26:16 The actual law in question is http://www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_2.htm#mdiv1 17:26:25 HT: it's at http://www.opsi.gov.uk/acts/acts1990/Ukpga_19900018_en_2.htm#mdiv1 17:27:01 HT: The pertinent portion is: 17:27:22 HT: 1.—(1) A person is guilty of an offence if— 17:27:22 (a) he causes a computer to perform any function with intent to secure access to any program or data held in any computer; 17:27:22 (b) the access he intends to secure is unauthorised; and 17:27:22 (c) he knows at the time when he causes the computer to perform the function that that is the case. 17:27:50 HT: The quotes I've seen so far don't really answer the question. 17:28:14 TBL: I heard that he did not succeed. 17:28:19 HT: Doesn't matter. 17:28:31 TBL: But he didn't actually "cause" the computer to do anything 17:28:53 HT: But even the error code counted as getting it to do something 17:29:20 Do not click here: ______________ 17:29:24 TBL: So if we have a link that says Member Only and a non-member clicks it, they're guilty under this law 17:29:31 HT: Yes, see section 17 which says: 17:29:33 good example, timbl... a link labelled [member only]. if anybody clicks on one of those, they break this law 17:30:06 HT: sorry, I'm not finding the pertinent part of section 17 to quote here. 17:30:19 HT: I think that we should consider doing something, but not quite clear what. 17:30:41 HT: Deep linking is pertinent. But there's no issue here of intentionally passing on the link, so that's different. 17:30:51 q+ re deep linking. Yes, this isvery bad because it would allow people to put arbitrary constraints on what you have to have done befroe following a link eg go trhough a tunnel. 17:31:05 q+ to talk about deep linking. Yes, this isvery bad because it would allow people to put arbitrary constraints on what you have to have done befroe following a link eg go trhough a tunnel. 17:31:11 HT: Note also that this law predates the Web, and seems to me to be contrary to what we'd like for Web architure. 17:31:18 HT: How to do that, I don't know, and I 17:31:21 http://lists.w3.org/Archives/Public/www-tag/2005Oct/0020.html 17:31:24 HT: How to do that, I don't know, and I'm afraid I have to leave. 17:32:07 VQ: This is going to be a legal issue. 17:32:23 -Ht 17:32:36 VQ: As a legal problem, this feels to me more like a W3C issue then a TAG architectural issue. 17:33:07 VQ: There may be a possibility of clarifying Web architecture, but I'd like to keep the legal and architectural issues separate. 17:33:23 VQ: Legal issues should be W3C-level; the architectural part is ours. 17:33:47 ack tim 17:33:47 timbl, you wanted to talk about deep linking. Yes, this isvery bad because it would allow people to put arbitrary constraints on what you have to have done befroe following a 17:33:48 ack timbl 17:33:50 ... link eg go trhough a tunnel. 17:34:09 q+ to say that the architecture question I hear is: true or false: it's always authorized to ask a server the "GET /any_path" question; i.e. it's not unauthorized to cause a 4xx not authorized or 5xx burb response. 17:34:38 TBL: I think this is important and we in the TAG should do something to make the technical part clear. What the W3C does is another question. 17:35:19 TBL: this relates to deep linking insofar as someone saying on there site "here are the rules for using my links" is the deep linking question, and it relates to this. 17:35:33 q+ to add modulo load issues 17:35:37 ack DanC 17:35:37 DanC, you wanted to say that the architecture question I hear is: true or false: it's always authorized to ask a server the "GET /any_path" question; i.e. it's not unauthorized to 17:35:41 ... cause a 4xx not authorized or 5xx burb response. and to add modulo load issues 17:36:27 TBL: regardless of whether anything happens with this case, we should go right up to the line in saying how we think things need to work on the Web. 17:37:02 DC: For the court to key on a code like 400 or 500 seems wrong, because that's what's telling you the status of the resource. 17:37:21 TBL: but the form he used was well known on certain servers was known to give him /etc/passwd 17:37:22 q+ 17:37:36 TBL: there are details of the case where you can argue about motivation 17:37:58 TBL: the law seems not to require him to succeed in unauthorized access, only to try 17:38:02 .../../../etc/passwd 17:38:09 DC: I claim doing a GET doesn't count as trying 17:38:41 TBL: you could argue that he should have known that doing this would read the /etc/passwd file. Rumor has it that some viruses are exploiting this as a hole in some systems. 17:39:03 TBL: so, this is a suspicious thing to do 17:39:26 TBL: he represented himself, supposedly, as someone who knew how to crack sites, or so I've heard. 17:39:54 TBL: By the way, why anyone would think he'd attack a site after carefully id'ing himself with his credit card does seem improbable 17:40:12 TBL: still, we need to look at court records before drawing conclusions 17:40:36 TBL: there may be differences between doing a GET, and doing a GET for something you know is subject to exploitation 17:40:52 (I'm reminded of the Schwartz case. http://www.lightlink.com/spacenka/fors/ ) 17:41:03 TBL: do you want to protect the world from doing something that is reasonable in the architecture, but at another level is known to specifically be a source of system exploitation? 17:41:16 ack noah 17:44:38 (I don't think crawlers try random URIs. they follow links from seeds.) 17:44:50 Noah: In general, it is true that you can make any commitment or be in trouble for anything for doing a GET. One can argue about the intent. 17:45:06 ... If the URIs were more opaque,this would not be possible. 17:45:19 ... We should encourage people to keep them opaque. 17:45:46 .. Maybe this case -- we don't know -- we don't have the records -- is an exception. 17:46:02 Crawlers don't have permission to try things up the hierarchy of a hierachical URI? I find that surprising. 17:46:02 The article claims he entered "../../../" with Safari. The current version of Safari will translate that to "/" before any message is sent to the server. 17:46:07 q+ 17:46:19 ack roy 17:46:25 At one point lynx was mentioned. 17:47:16 RF: We've worked with browser developers for some time to get them to do this stuff on the client. I've just tried Safari and it doesn't actually send the ../'s to the server. 17:47:41 RF: I want to say again that we should get the court records to find out what happened. I suspect he may have used telnet. 17:47:51 TBL: one article suggested lynx. 17:48:16 RF: if lynx did that, it was on old copy. Lynx is the most likely thing that would actually send that to a server. 17:48:23 VQ: let's move on 17:48:33 VQ: let's try to find out more details 17:49:02 VQ: can someone volunteer to find the facts, and if possible the court records? 17:49:29 VQ: Tim, what about folks in the technology and society domain. 17:49:50 TBL: well Henry's not here, but he's in the right time zone. maybe we should ask him. The T&S domain is a possibility. 17:50:41 VQ: well, I'm not in Britain, but I can try and talk to people who may be able to point me in the right direction. 17:51:07 ht has joined #tagmem 17:51:45 ACTION: Vincent to try and get official information about the Computer Misuse Act case referenced in http://lists.w3.org/Archives/Public/www-tag/2005Oct/0020.html 17:52:12 Topic: endPointRefs-47 17:52:27 VQ: Dave, could you summarize discussion of your draft 17:53:01 DO: I published a rough start to a TAG finding on state (http://lists.w3.org/Archives/Public/www-tag/2005Oct/0025.html) 17:53:42 DO: I followed the same banking scenario through several designs including, stateless, cookie-based, web services using WSA EPRs. 17:54:06 DO: I discussed a bit about making such an EPR available as a URI, focussing on the customer key as an example 17:54:26 DO: I showed 4 or 5 examples of different bindings to URIs, and even to HTTP cookies 17:54:43 DO: previous to that I had some definitions of "state", and I got comments on those. 17:55:10 DO: I had a section on architectural properties of stateful vs. stateless wrt/ performance, reliability, ease of use, security, etc. 17:56:12 DO: I want to get 2 things out of the finding: 1) bring in the architectural issue about state and relationship to web services, giving guidance on choices 2) also want to talk about EPR issus 17:56:19 q+ to ask about finding vs. response to WSA 17:56:30 q+ to explain why "Roy Fielding argues in his REST dissertation [1] that stateless server has the benefits of increasing reliability, scalability, visibility and while potentially decreasing network performance." is out of context. 17:56:39 VQ: Dan had an action to review what Dave posted 17:57:05 DC: I got hung up on state definition stuff and didn't go much further 17:57:07 ack noah 17:57:07 noah, you wanted to ask about finding vs. response to WSA 17:58:38 ack roy 17:58:38 Roy, you wanted to explain why "Roy Fielding argues in his REST dissertation [1] that stateless server has the benefits of increasing reliability, scalability, visibility and while 17:58:41 ... potentially decreasing network performance." is out of context. 17:58:44 http://www.ics.uci.edu/~fielding/pubs/dissertation/net_arch_styles.htm#sec_3_4_3 17:59:00 NM: seems to me the time urgency is on deciding whether to respond to the WSA drafts, doing a finding on state will take time and seems lower priority 17:59:38 dorchard has joined #tagmem 17:59:49 RF: See link to my dissertation. Dave references it. Having a discussion of all these things is useful, but I'm not sure Dave's drafts is careful enough about separating, e.g. session state from application state. 18:00:32 q+ 18:00:45 RF: You could my dissertation as arguing that stateless servers has advantages. That's not what I said. I said that having stateless interaction models trades off gains in security, manageability etc. for network performance, since we tend to pass around things like cookies. 18:01:15 RF: working on this seems like a good thing to do. Also suggest putting in some state transition diagrams to illustrate where state is in various scenarios. 18:01:20 q- 18:01:22 ack dorchard 18:01:43 DO: I hear you, but there's no quick answer I can give right now. 18:01:56 VQ: getting back to Noah's question... 18:02:05 q+ 18:02:10 VQ: I'd like feedback on whether we should respond to WSA. 18:02:23 ack dorchard 18:02:26 DO: I think we've agreed that figuring out what to do is high priority. 18:02:43 DO: I put this out as something to support that, and as something that would live longer. 18:03:07 q+ to say that the finding may be useful, but is not a fast way to get to decision on WSA 18:03:24 ack noah 18:03:24 noah, you wanted to say that the finding may be useful, but is not a fast way to get to decision on WSA 18:03:41 Roy, I agree with all you said. 18:04:12 Definitely want to do STDs but I couldn't find my copy of visio... 18:05:14 NM: I think that by looking at this as a finding, we're discussing some things that are not critical do deciding a WSA response, such as the definition of state. 18:05:19 DO: OK, I guess that's so. 18:05:42 VQ: so, what do we want to respond to WSA. 18:06:00 DC: we have a one line version that's too short, and a long version that's too long, though I can live with one line version. 18:06:15 DC: I don't feel urgency of replying to WSA. 18:06:18 (more links for background follow) 18:06:21 http://f-m-c.org/projects/apache/html/2_5Session_Management.html 18:06:23 TBL: to WSA? 18:06:33 s/to WSA/no urgency to WSA/ 18:06:38 DC: I still like short version. 18:07:48 DC: but Dave said we had to do a lot more, and we can't do that in a week. 18:07:50 recalling the proposal: "Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them. 18:09:49 NM: well, I though we were asking them to put a note in their Rec, and it's late in the process. IF we are asking them to change the Rec, then I think we have to fast track that advice, or else make a quick decision not to ask for anything. 18:10:07 NM: giving other advice on how to use the Rec after it's published we can do in a more leisurely way. 18:10:33 DO: I'm not sure that short advice saying "don't do that" isn't useful. 18:10:55 DO: I think there is stuff missing that would help people follow the guidance we'd like to give them. 18:11:18 DO: I don't know how to say don't do bad things if we don't tell them how. 18:11:37 DC: I'm not sympathetic to that. I just want to be sure that whatever we ask for can be understood. 18:11:48 DC: first point, do no harm. 18:12:15 TBL: maybe if we explain the constraint, then the design can get done 18:12:31 TBL: if you can say what needs to be designed, we don't necessarily have to it. 18:12:36 (yes, they can do the design, they being app developers. if patterns emerge, they might be worth standardizing) 18:14:59 NM: this doesn't give advice, it states a (purported) fact: doing X is contrary to Web Arch. 18:15:10 NM: maybe or maybe not the reader feels that matters in his or her case 18:15:25 VQ: I hear less support for the short statement 18:15:29 NM: I think I can support it. 18:15:34 TBL: remind me where it is. 18:15:47 Copying: "Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" 18:16:33 TBL: if we said that, and then said that we realize that current tools may not make it easy to do things that way, e.g. because of dispatch issues... 18:16:49 TBL: ...would it work to do that and not propose a solution? 18:17:15 DO: that makes me a bit more comfortable, in that it acknowledges current reality. 18:17:24 TBL: I want to refer to "current web services implementations" 18:17:32 DO: I'd prefer implementations and technologies 18:17:45 Specifically the way current WS implementations dispatch on URIs 18:18:00 TBL: I have problem with the word technology 18:18:15 "deployed technologies" perhaps? "widely available technologies" 18:18:24 DO: I think you've got it. You could imagine new specifications for QName to URI mapping, etc., that would upon implementation in software enable that. 18:18:30 q+ to talk about SOAP 18:18:35 "Defined, agreed way of doing things?" 18:18:40 (or old specifications, such as RDF ;-) 18:19:21 TBL: if the problem is just the way the server is built, that it doesn't allow the same program to be called with the same URI, then it's going to be difficult. 18:19:38 TBL: that's an example of lack of implementation flexibility. 18:20:02 DO: I think it's both. Standards can help, but you don't always need them. 18:20:04 ack noah 18:20:07 noah, you wanted to talk about SOAP 18:20:17 (this discussion between timbl and daveo is a very rushed version of reviewing a state finding. I'm more inclined to do it slowly. I think the TAG undercuts itself when we make proclamations that don't have well-argued justifications.) 18:20:31 if the problem is just the way the server is built, that it doesn't allow the same program to be called for many many DIFFERENT uris (of differenet objects), then it's going to be difficult to use the URI as an object identifier 18:22:41 NM: well, I think it is technology. The SOAP Rec. is what these folks are implementing, and it says to dispatch on QNames of elements. The issue is that those mechanisms make sense for things like DSIG headers, but people are now trying to stretch that for identification-related dispatching. 18:22:52 NM: I think that's a legitimate concern for them. 18:23:49 DO: my position is unchanged. People are building software to SOAP and related specs that is the natural software for those specs. I think there is in sufficient technology now set out to make it practical to make Web Resources of all the things now identified with EPRs. 18:24:34 DO: I'm willing to make that one sentence "contrary to Web Arch" statement,but only if we acknowledge that the current state of things makes it hard to in fact integrate with Web Arch in some important cases. 18:24:56 DO: I'd like the TAG to spend some time helping to find the technologies that would help make those resources available on the Web. 18:25:11 DO: That's the sort of goal the TAG should undertake. 18:25:46 VQ: I'm getting less optimistic... 18:25:57 would timbl accept an action to write his proposal in email to www-tag? 18:26:25 ... and discuss it for the next week or so 18:26:26 DO: I think we're actually getting close. If you start with TBL's formulation and mix in some of Noah's observations on SOAP headers, that might be OK. Then again, I'm not yet sure exactly what text we'd ask them to change. 18:27:06 DO: I like your suggestion to ask Tim to take an action. 18:27:11 DC: one to two paras? 18:27:42 Noah thinks the measure of success is to know specifically what we're asking WSA to put >into their REC<. 18:28:12 VQ: what about sending a line or two that we'll tune up this week in email discussion. 18:30:01 TBL: worried about the total of my TAG commitments 18:30:08 DC: the WSA stuff seems urgent 18:30:24 NM: my end of the CDF review is coming this afternoon, if that will give Tim a leg up on his? 18:30:52 TBL: where are pieces of text? 18:30:55 let's record the action and adjourn to give tim 2 minutes of quiet 18:31:01 VQ: in the minutes (IRC) 18:31:26 Fodder: """Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them. we said that, and then said that we realize that current tools may not make it easy to do things that way, e.g. because of dispatch issues. 18:31:36 ACTION: Tim to send email starting discussion of text to ask WSA to put into their REC. 18:31:50 TBL: would like to believe text above might be pretty close to fulfilling the action. 18:31:53 DC: mail it. 18:32:21 remind me who's scribing next week? 18:32:28 I'm sribing 18:32:48 DanC has changed the topic to: http://www.w3.org/2001/tag/2005/10/18-agenda.html scribe: Noah. next week: DaveO 18:32:54 -DanC 18:32:59 ACTION: Tim to digest and ermail """odder: """Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them. we said that, and then said that we realize that current tools may not make it easy to do things that 18:33:08 ACTION 1=Tim to send email starting discussion of text to ask WSA to put into their REC. E.g. Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them. we said that, and then said that we realize that cur 18:33:25 Nuts, replaced the wrong one. I'll straighten it out. 18:33:39 -DOrchard 18:33:40 -noah 18:33:41 -Roy 18:33:47 VQ: adjourned. 18:33:47 -Vincent 18:34:11 rrsagent, pointer? 18:34:11 See http://www.w3.org/2005/10/18-tagmem-irc#T18-34-11 18:35:05 ACTION 1= Vincent to try and get official information about the Computer Misuse Act case referenced in http://lists.w3.org/Archives/Public/www-tag/2005Oct/0020.html 18:35:20 ACTION 2=Tim to send email starting discussion of text to ask WSA to put into their REC. E.g. Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them. we said that, and then said that we realize that cur 18:35:29 ACTION 3= 18:38:30 action -3 18:38:47 disconnecting the lone participant, TimBL, in TAG_Weekly()12:30PM 18:38:50 TAG_Weekly()12:30PM has ended 18:38:52 Attendees were noah, Vincent, DanC, Ht, DOrchard, Roy, TimBL 20:27:42 Zakim has left #tagmem 20:51:14 rrsagent, bye 20:51:14 I see 2 open action items saved in http://www.w3.org/2005/10/18-tagmem-actions.rdf : 20:51:14 ACTION: Vincent to try and get official information about the Computer Misuse Act case referenced in http://lists.w3.org/Archives/Public/www-tag/2005Oct/0020.html [1] 20:51:14 recorded in http://www.w3.org/2005/10/18-tagmem-irc#T17-51-45 20:51:14 ACTION: Tim to send email starting discussion of text to ask WSA to put into their REC. E.g. Use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to WebArch" For example, we note that WS-RF specification uses EPRs to identify information resources (such as for example experimental datasets in the Grid) which prevents hypertext links from being made to them. we said that, and then said that we realize that cur [2] 20:51:14 recorded in http://www.w3.org/2005/10/18-tagmem-irc#T18-31-36