16:57:45 RRSAgent has joined #tagmem 16:57:45 logging to http://www.w3.org/2006/10/10-tagmem-irc 16:58:19 Zakim, this conference is Tag 10 Oct 16:58:19 sorry, EdR, I do not see a conference named 'Tag 10 Oct' in progress or scheduled at this time 16:58:34 Meeting: Weekly Tag Telecon 16:58:46 Vincent has joined #tagmem 16:59:08 Chair: Vincent Quint 16:59:16 Scribe: Ed Rice 16:59:51 Agenda: http://www.w3.org/2001/tag/2006/10/10-agenda.html 17:00:34 raman has joined #tagmem 17:01:33 +DanC 17:01:48 +[IBMCambridge] 17:02:10 zakim, [IBMCambridge] is me 17:02:10 +noah; got it 17:02:13 +[INRIA] 17:02:30 Zakim, INRIA is Vincent 17:02:30 +Vincent; got it 17:02:58 Zakim, who is here? 17:02:58 On the phone I see Ed_Rice, Raman, Norm, DanC (muted), noah, Vincent 17:02:59 On IRC I see raman, Vincent, RRSAgent, Zakim, EdR, noah, DanC, timbl, Norm, ht 17:03:08 TOPIC: Administrative 17:04:04 Can we add "minutes of the f2f" as an Administrative agendum? 17:04:27 Next teleconferance next week, Oct 17. 17:04:47 Noah regrets for 24th and 31st of October. 17:04:57 T.V. Regrets for 17th. 17:05:04 Dave Regrets for 17th. 17:06:43 One piece still missing from F2F minutes, could be finished today. Minutes to be reviewed / approved next week. 17:07:56 Agenda at; http://www.w3.org/2001/tag/2006/10/10-agenda.html 17:08:11 q+ to request an agenum on HTML 4 -> XHTML as a possible new issue; perhaps under item 6 17:08:40 ack danc 17:08:41 DanC, you wanted to request an agenum on HTML 4 -> XHTML as a possible new issue; perhaps under item 6 17:09:17 Resolution: Agenda approved. 17:10:21 q+ to advocate 2 best practice notes 17:10:54 q+ to mention editorial issues and at least two that may be substantive 17:10:56 TOPIC: passwordsInTheClear-52 17:11:11 New draft out there, short notice so not much feedback yet. 17:11:28 +TimBL 17:11:28 ER: Norm sent feedback, thanks! 17:11:46 ack danc 17:11:46 DanC, you wanted to advocate 2 best practice notes 17:12:01 Current text says: Therefore its imperative that any organization who wishes to safeguard its customers data start with secure transfers of user login and password information. 17:12:17 raman has left #tagmem 17:12:27 That's a bit too strong, in that it implies that all good security systems are login + password-based. 17:12:41 Dan: We should point out the two items; Sites should not solicite passwords in the clear and browsers should not transmit them. 17:13:04 ack noah 17:13:04 noah, you wanted to mention editorial issues and at least two that may be substantive 17:13:10 Suggest something like: "...imperative that any org that uses password-based security to safeguard its customers data start with secure transfores of.... 17:14:03 Noah: suggest adding this to the bottom of section 2. 17:15:23 Noah: 2.2 on SOAP, 2 issues.. in the 2nd sentance SSL secures point to point, more complex if using intermediaries. (spelling) 17:16:35 Noah: add after intermediaries.. or if data needs to be secured at the end-points. 17:18:04 (I'm interested pointers to what Ed read yesterday about ws-secruity and TLS/SSL) 17:18:48 http://www.ws-i.org/Profiles/BasicSecurity/SecurityChallenges-1.0.pdf 17:18:59 Vincent: More comments? 17:19:25 (ah... that pointer looks familiar; I think I saw it in a msg from Paul C) 17:20:44 ACTION: Ed to publish update in one week for discussion in two weeks 31st. 17:21:14 Topic: submission of WS-Transfer 17:21:57 Dan: I made the request on Tim's behalf.. 17:22:27 Back on the question about security headers in ws-security: 17:22:33 From: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf 17:23:11 Tim: If anyone on the call wants to go back over the issues on this, than do. 17:23:19 Dan: We dont have any recorded issues on this. 17:23:24 As elements are added to a header block, they SHOULD be prepended to the existing elements. As such, the header block represents the signing and encryption steps the message producer took to create the message. 17:23:51 Tim: Its been suggested that this specification provides the same functionality as HTTP but over web services. 17:23:53 I think that makes the case that SOAP headers are used to control encryption (which is, BTW, XML Encryption-based) 17:24:53 Tim: I thought the team may have some thoughts on this and if its architecturally broken 17:25:23 -> http://www.w3.org/Submission/2006/08/ ws-transfer submission request 17:25:38 -> http://www.w3.org/Submission/2006/04/Comment W3C team comment on ws-transfer 17:25:54 Tim: has anyone had time to read this? 17:27:12 Noah: I've skimmed this, but its not quite on the surface a replacment turned upside down. 17:27:27 (ah... re Noah's 3 points, 2 of them are TAG issues: using SOAP rather than GET conflicts with our decision on issue whenToUseGet-7, and using EPRs rather than URIs is endPointRefs-47, still open) 17:28:00 q+ 17:28:26 Noah: I'm uncomfortable with EPR's instead of URI's 17:28:39 ack DanC 17:28:45 Tim: and you have a completely seperate caching system. 17:32:14 Noah: they appear to be trying to move binary through xml. 17:32:17 + +1.604.897.aaaa 17:32:55 What I really said was that there is a positive view, which is in the case that you were for some good reason going to use another protocol, such as durable queuing software (IBM's WebSphere MQ, for example), this does bring it somewhat closer to a Web model. 17:32:57 Zakim, +1.604.897.aaaa is Dave 17:32:57 +Dave; got it 17:33:01 Welcome Dave Orchard 17:33:22 Tim: Maybe you can describe this paper to us Dave. 17:33:36 (er... soap://www.example.org/repository? a soap: URI scheme? is that registered?) 17:34:08 I do have some concern, other than the use of EPRs instead of URIs, that a WS-Transfer GET may well bind to an HTTP POST rather than HTTP GET in the particular case where you are going over HTTP. 17:34:12 Dave: The short answer is.. it comes mostly out of the management space where your managing resoruces and you have a constrained space for managing these resources and we want to be able to this using soap and over multiple protocols and reliable messages and ws policy and etc. 17:34:47 There are webdav-like features, etc but no content negotiation 17:34:48 Dave: I think its very similar to whats in HTTP. There are some web-dav kinds of things in there where you can get specific resources like put and get in http 17:35:37 Dave: you would pick at deployment time which protocols you would actually use. 17:35:47 Tim: so the same URI would point to the same resource? 17:35:57 Surely you meant EPR, Tim? :-) 17:36:25 Dave: the same operation. but when you deploy it you could deploy it using HTTP or not so the end-state referance would be set at deployment time. 17:36:47 Dave: In general, you'd probably pick the address of the URI at deployment time. 17:37:11 Tim: There is an example in there. A simple soap request which has a get request. Whats being requested there. 17:37:14 http://schemas.xmlsoap.org/ws/2004/09/transfer/Get 17:37:21 I think the GET is directed to the wsa:to EPR 17:38:18 Noah: My recollection is that there is this trick thats played with EPR's where an EPR has a bunch of properties but when its mapped to soap each of these properties gets its own header. 17:38:21 """ 732199 17:38:22 EMEA 17:38:22 """ 17:38:30 There are the EPR 17:38:38 Dave: exactly, the expectation is that it will be used with WS-Addressing and will be used to pass around resources. 17:39:02 Those xxx:CustomerID & Region things presumably came from the mapping of the EPR into separate SOAP headers. 17:41:20 Dave: from a web architecture perspective, I admit that I'm torn about this specification. When you take soap and you add in ws-addressing, ws-transfer starts looking like HTTP with angle brackets. 17:41:36 Dave: but if your protocol independant you kind of have to. 17:42:30 (DOI is one of the parties in the un/registries discussion) 17:42:35 Tim: This protocol independance is the reason for DOI etc, but it sounds like your writing your own protocols. Various people say they need to be protocol independance and sometimes it leads to something we consider a bad thing. 17:42:52 Dave: Yes, because it forces you to reinvent the protocols your trying to be independant from. 17:42:59 Tim: Yes, exactly. 17:43:17 (oddly, "doi" doesn't occur in http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.xml v 1.21 2006/08/17 ... er... is that current?) 17:43:51 Dave: Well, if we had come up with a framework so we can be protocol independant and mix and match at differant levels to get that. However, this has frankly not been interesting to the people driving the WS-* specifications. 17:44:03 ("The DOI System is for identifying content objects in the digital environment." http://www.doi.org/ ) 17:44:14 tnx 17:46:18 Noah: Well, for the example of saying I want to do something like an http get but I dont mind if it takes hours to get a response or if the network is down it can wait. In this case, I can see where something like this may make sense. 17:46:40 Tim: Of course, I think Roy if he were here would probably have a lot to say about this. 17:47:10 Tim: HTTP protocol is designed to be a bit of a gateway function and allows you to encompass differant protocols such as FTP. 17:47:37 (in sum, I don't see any new issues here. I think there's a clear clash between WS-Transfer and whenToUseGet-7 in some cases (maybe this is new information that merits reopening that one), and our EPR issue is still open.) 17:47:38 Tim: So essentially as HTTP is a gateway protocol, its a bit of an extraction so it can connect to other protocols. 17:49:04 Noah: if the keep alives dont work on the wire though, they need a way to store that transaction and process it later as opposed to http get which wouldnt allow this. 17:50:32 Dave: Noah, good point. We at BEA tried to some reliable messaging using http post, similar to what IBM did with httpr but nobody uses it. I'm not sure if its because of marketing or nobody knows about it or what. 17:50:55 q+ to ask for help finding the http reliable messaging thingy 17:50:59 Noah: But just to be clear, there is a large amount of business use of these reliable messaging systems. 17:51:23 ack danc 17:51:23 DanC, you wanted to ask for help finding the http reliable messaging thingy 17:51:34 Dave: I'd say of the ws-* things going on, reliable messaging has got the most attention. 17:51:51 (http://www.goland.org/draft-goland-http-reliability-00.text SOA-Reliability (SOA-Rity) for HTTP November 7, 2005 ) 17:52:45 doceng 2006 17:53:17 Dave: if you look at the core part of the REST architecture is this sort of stateless architecture. 17:53:47 (was it Dave or Noah who said that? maybe it doesn't matter.) 17:54:19 Dave: so one of the questions is, from a web architecture perspective what is the view of ws-addressing. From a base blush it appears to be a parallel architecture and I dont know how bad that is. 17:54:28 Tim: Yes, from first blush it appears it is. 17:54:48 I think Dave pointed out that individual HTTP interactions tend to be stateless. 17:55:08 Tim: its bad because it weakens deployement of Http system, it weakens the caching system since everyone has to duplicate everything. 17:55:33 I made the point that at a lower level, reliable queuing systems tend to keep durable state on disk relating to point-to-point connections, and that state is typically retained across multiple messages sent between the same two endpoints. 17:55:56 Tim: and of course that its a new protocol so it has to go from the ground up from what HTTP had to go through. 17:56:10 So, when you tunnel HTTP interactions over MQ, the HTTP interactions work fine and appear stateless, but at the next level down there is a typically a lot of point-to-point statefulness. 17:56:48 Perhaps what's harmful is: WS-Transfer GETs over HTTP don't map to HTTP GETs 17:56:57 Dave: So you mentioned exactly the rub. But if you were going to say anything as the TAG we should have done that at the EPR level. 17:57:08 Tim: We did, didnt we? 17:57:23 I think it's worth going back and finding our response. Will see if I can do it quickly. 17:57:53 Dave: almost everything you see in a referance parameter has an :id at the end of it so it looks like an EPR. But I think the horse is kind of out of the barn. 17:58:15 Dave: I agree it doesnt promote more use of HTTP URI's. 17:58:22 Noah: I found the referance. 17:58:34 http://lists.w3.org/Archives/Public/www-tag/2005Oct/0057.html 17:58:46 Quoting from that: 17:58:47 Taking all these factors together, the TAG today resolved to ask that the Web Services Addressing Working Group include the following note in a suitable section of the Web Services Addressing 1.0 - Core Proposed Recommendation: 17:58:54 Note: Web Architecture dictates that resources should be identified with URIs. Thus, use of the abstract properties of an EPR other than wsa:address to identify resources is contrary to Web Architecture. In certain circumstances, use of such additional properties may be convenient or beneficial, perhaps due to the availability of QName-based tools. 17:58:59 When building systems that violate this principle, care must be taken to weigh the tradeoffs inherent in deploying resources that are not on the Web. 18:03:36 Dave: so what would happen if the TAG says WS-Transfer is really bad for the web architecture. 18:04:15 Noah: Well, lets turn it around and say yeah, this stuff is protocol independant but a get should turn into a get and that would force you to look at http URI's. 18:05:30 Dave: yes, but to get there I'd say there is some technology needed. 18:05:37 Noah: yes. 18:06:10 q+ to recall looking for http://www.w3.org/TR/ws-arch/ in the "architectural specs" section of http://www.w3.org/TR/webarch/ , but it's not there. 18:06:42 q- 18:06:44 oops; there it is. 18:08:05 Specifically, what I'm saying is, that it would be a good goal in principle if in the particular case where this is mapped to SOAP over HTTP, it turns into an ordinary GET that (probably) results in an envlope of media type application/soap+xml 18:08:43 I have some doubts that the communities promoting this will want to go that way, and it obviously is harder to do in the cases where the EPR parameters are used to carry identifying information. 18:08:46 Tim: Well EPR's used to have URI's in them. 18:08:53 Dave: They all do. 18:09:23 soap://www.example.org/repository 18:09:24 Noah: what your reading isnt the EPR but the soap binding the EPR 18:09:46 -Dave 18:09:48 s/binding/binding of/ 18:10:01 q+ to ask about the soap: URI scheme: (a) is that hypothetical or deployed for real, and (b) is it registered? and if not, who owns it, i.e. who should I pester to register it? 18:10:20 Vincent: Tim, this was put on the agenda because you suggested that we could have some comments on it, but do you expect something more of the TAG? 18:10:52 Tim: We've already made a fairly muted statement on this. I do think it would be usefull to have a TAG comment on this and to point these things out. 18:11:29 Tim: As Dave said, if we let this go by without saying something strong then why and we'll think we've let ourselves down and let the community down. 18:11:57 Dave: We should make a decision about when to use HTTP-Get7 and clarify this to the W3C teams. 18:13:00 +DOrchard 18:13:17 welcome back Dave 18:13:35 s/Dave: We should make/DanC: We should make/ 18:15:32 ack danc 18:15:32 DanC, you wanted to ask about the soap: URI scheme: (a) is that hypothetical or deployed for real, and (b) is it registered? and if not, who owns it, i.e. who should I pester to 18:15:35 dorchard has joined #tagmem 18:15:36 ... register it? 18:16:38 SOAP-over-UDP http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/soap-over-udp.asp 18:16:52 Vincent: ok, its time to move on to the rest of the agend, but before that we had a discussion and a few ideas came up during the discussion and these are in the IRC. 18:17:17 Vincent: Dan/Tim, do we need to do more? 18:17:24 Dan: I move to re-open issue 7. 18:17:34 Spec for SOAP over HTTP: http://msdn.microsoft.com/ws/2004/09/soap-over-udp/#search=%22soap%20over%20udp%22 18:17:46 Vincent: which was closed 2 years ago 18:17:53 Dan: Yes, but now we have new information. 18:18:10 Vincent: yes, but does that address the request from the team. 18:18:24 Dan: When we close it again, I would expect to have a response to the teams question. 18:18:41 Noah: So isnt this -47? 18:18:48 Dan: Yes, but we havent closed that one yet. 18:19:29 Vincent: ok, we have a motion to re-open issue 7 because of this new information, what do others think? 18:19:41 Dave: Ok, thats fine. 18:20:19 Dan: We often have owners for action items.. and I suspect Dave we close to volunteering. 18:20:31 zakim, who's making noise? 18:20:42 Norm, listening for 10 seconds I heard sound from the following: noah (61%), Vincent (30%), TimBL (65%) 18:20:47 Vincent: do we have opinions about reopening issue 7? 18:20:52 Norm: I think its a fine idea. 18:20:59 Tim: Ok, I'm happy with that. 18:21:19 http://www.w3.org/2001/tag/issues.html#endPointRefs-47 18:21:23 Noah: Yeah, I think we should open it and know that its that issue together with EPR's as an ubrella for this issue. 18:21:30 Vincent: Ok, so lets re-open this. 18:21:39 RESOLUTION: Re-Open issue 7. 18:21:50 timbl, I nominate you to call for discussion of issues 7 and 47 and ws-transfer on www-tag. 18:23:18 Noah: I think someone should frame it more. Its going to be a political hot potatoe. 18:23:35 Dave: I'm open to having Tim send it to Tag only and have Noah on critical path. 18:23:49 Dave: Yes, this could take a fair amount of tag's time over the next little while. 18:24:47 Noah: We can point to the ERP API discussion and the fact that the soap community agreed to do some things and to point out that a direction has been set there and that the TAG has an interest in seeing things carried forward in that direction. 18:25:59 Noah: so maybe one of things we could do in a note like this is to point out the gap that SOAP agreed to do things like use GET properly but that ws-transfer doesnt appear to support that. 18:26:34 Timbl: what we agreed specifically was that you would take the soap request and encode as a URI. 18:28:40 Vincet: Ok, we're really running out of time. I'm interested in any action that would allow the issue to be better framed and to keep the ball rolling. 18:28:57 Vincent: Dave, would you be interested in sending a message to re-open the issue? 18:29:01 Dave: no. 18:29:16 Tim: Should I draft it and noah should edit it? 18:29:39 Noah: Yes, lets send it to the private tag list first until we edit it. Tim needs to be involved. 18:29:51 NM: Sure, I'll take a look, but I don't see this as specifically mine to take the lead. Everyone on tag@w3.org can review, but I certainly will try. 18:30:18 Vincent: The proposal is; Time to send a message to the private tag list and Noah and maybe Dave will contribute to polishing the message for the public list. 18:30:26 Tim: Ok, I'll try and do it tomarrow. 18:30:33 Actually, what I said above was not "Ws-Transfer doesn't appear to support that", but rather, "it would be nice to find out that they can support it" 18:30:49 I'm not necessarily optimistic that they can, but I think it 18:30:56 it's an appropriate positive goal. 18:31:11 ACTION: Timbl to send draft of issues 7 and 47 and ws-transfer to tag@w3 for revision and discussion internally. 18:31:28 TOPIC: futures 18:31:38 Vincent: this will wait and we can do this via email. 18:31:43 -DOrchard 18:31:44 -DanC 18:31:45 -noah 18:31:47 -Ed_Rice 18:31:49 -Norm 18:31:51 -Vincent 18:31:53 -Raman 18:31:54 -TimBL 18:31:55 TAG_Weekly()12:30PM has ended 18:31:56 Attendees were Ed_Rice, Raman, Norm, DanC, noah, Vincent, TimBL, Dave, DOrchard 18:32:07 Zakim, list participants 18:32:07 sorry, EdR, I don't know what conference this is 18:32:17 RRSAgent, make logs public 18:32:27 RRSAgent, generate minutes 18:32:27 I have made the request to generate http://www.w3.org/2006/10/10-tagmem-minutes.html EdR 19:24:03 Norm has joined #tagmem 19:41:21 rrsagent, bye 19:41:21 I see 2 open action items saved in http://www.w3.org/2006/10/10-tagmem-actions.rdf : 19:41:21 ACTION: Ed to publish update in one week for discussion in two weeks 31st. [1] 19:41:21 recorded in http://www.w3.org/2006/10/10-tagmem-irc#T17-20-44 19:41:21 ACTION: Timbl to send draft of issues 7 and 47 and ws-transfer to tag@w3 for revision and discussion internally. [2] 19:41:21 recorded in http://www.w3.org/2006/10/10-tagmem-irc#T18-31-11