18:00:08 RRSAgent has joined #tagmem 18:00:08 logging to http://www.w3.org/2006/03/28-tagmem-irc 18:01:12 +DOrchard 18:02:02 +Vincent_Quint 18:03:09 Zakim, who is here 18:03:09 Vincent, you need to end that query with '?' 18:03:18 Zakim, who is here? 18:03:18 On the phone I see Norm, MarkB, Ed_Rice, DOrchard, Vincent_Quint 18:03:19 On IRC I see RRSAgent, Ed, Vincent, Zakim, Norm, MarkB, DanC 18:03:35 noah has joined #tagmem 18:03:42 +[IBMCambridge] 18:03:44 earlier, DanC wrote; DanC is preparing an agenda for a SPARQL thingy; might be late for TAG today" 18:03:54 zakim, [IBMCambridge] is me 18:03:54 +noah; got it 18:04:02 dorchard has joined #tagmem 18:04:08 brb 18:06:01 zakim, who is here? 18:06:01 On the phone I see Norm, MarkB, Ed_Rice, DOrchard, Vincent_Quint, noah 18:06:03 On IRC I see dorchard, noah, RRSAgent, Ed, Vincent, Zakim, Norm, MarkB, DanC 18:06:28 +??P1 18:07:15 raman has joined #tagmem 18:07:27 #tagmem 18:07:36 scribe: dorchard 18:08:12 topic: Future telcons 18:08:51 Regrets from Noah for April 4 (schema WG), at risk for April 18th. I expect to be on the call April 11th. 18:09:34 +DanC 18:10:13 regrets from noah, ed 18:10:37 tv scribe next week 18:11:29 action: minutes from 03/28 approved 18:12:49 topic: endpointrefs-47 18:13:18 (only a year? that's pretty young, as tag issues go. 1/2 ;-) 18:14:08 MarkB: discussed with Noah, Stuart 18:14:30 MarkB: TAG issue is accurate 18:14:59 MarkB: WSA:To header/component/property does not make it into the HTTP request URI, and it darn well ought to. 18:17:08 Vincent: why didn't TAG look directly at this? 18:18:07 DaveO: I think the TAG was focusing on Identifiers, and EPRs introduced a new identifier structure so the TAG decided to look at the potential new identification scheme. 18:19:28 Noah: said another way, the issue is that when WS-A is stacked up, it may be that 2616 isn't followed. 18:20:31 mmark is impossible to understand. 18:20:38 q+ to ask about gateways vs. proxies 18:21:00 MarkB: firewalls look at request URI. With WS-A and Ultimate receiver inside the message, then the target is not visible to HTTP firewall. 18:21:20 ack noah 18:21:23 noah, you wanted to ask about gateways vs. proxies 18:21:47 Noah: HTTP has proxies and gateways 18:23:17 Noah: gateway case different than proxy, it will look like one hop. Send message to example.com:80 and then it will service the request in some other way, like ftp.. 18:24:24 Noah: this is a gateway scenario. The way the gateway works is by looking at the ws-a header. 18:24:48 tv: gateway could do rewrite 18:25:32 Noah: As long as willing to consider the first hop to be an HTTP gateway. Whenever firewall before gateway, this lack of visibility is present. 18:25:55 markb: you've described proxies and gateways in http correctly 18:27:24 markb: (as said by Noah) What WS-A is doing is that client is seeing the structure behind the gateway, rather than hiding it. 18:28:24 hello 18:28:26 -MarkB 18:28:33 oops 18:28:49 +[IPcaller] 18:29:31 zakim, IPcaller is MarkB 18:29:31 +MarkB; got it 18:30:24 DaveO: The wsa:To field should never refer to something beyond the Request-URI in terms of hops. 18:31:14 DaveO: trying to summarize, WS-A would be doing the right thing if the wsa:To was not "past" the http request-uri 18:31:40 MarkB: the http request-uri should be to the ultimate recipient. 18:32:02 MarkB: can live with ws-a:to and request-uri being the same. 18:32:11 MarkB: wsa:to does not need to be removed 18:32:39 vincent: trolls for DanC comments.. 18:33:03 Is the real issue whether multiple wsa:To URIs are routed to the same Request-URI? 18:33:35 q+ to ask about one-to-one vs one-to-many 18:34:13 DanC: seems like the "if they used URIs they'd be ok, otherwise they'll need more expensive software" 18:35:28 ack noah 18:35:28 noah, you wanted to ask about one-to-one vs one-to-many 18:36:08 -MarkB 18:36:29 DaveO: there could be 2 uris, one known by soap layer, one known by http layer. Mark wants to make sure the http layer knows "the furthest" point 18:36:34 grrrr 18:36:34 ' 18:37:10 DanC: ah. thanks, Dave. I think I see now. 18:38:47 +[IPcaller] 18:39:21 Noah: Mark has the concern with what I'm calling the gateway scenario. 18:39:22 zakim, IPcaller is MarkB 18:39:22 +MarkB; got it 18:39:24 sub-addressing; right. aka "source routing" 18:39:57 Noah: my guess is that what he wants is a different gateway uri for each resource behind the gateway, ie 3 resources then 3 uris 18:40:25 markb: no. 18:40:42 i'm still cutting in and out 8-( 18:41:06 noah: risk is that ws-a will do wsa:to to 3 resources, and there's only 1 uri for gateway. 18:41:47 markb: in order to use http in the web architecture, only 1 resource should be used at a time in a given request 18:43:06 noah: if all request-uris to the gateway are the same, then you can't use GET 18:43:44 vincent: do you think the TAG understands the issue? 18:44:18 markb: yes, and encouraged 18:44:33 Vincent: TAG, do you underand the issue better? 18:44:39 danc: yes, thanks 18:44:44 +1 18:44:48 daveo: I'm at the same point I was before 18:45:56 noah: I understand the details a bit better, and ignoring the process state of ws-a, I'm not yet quite clear about what ws-a is doing in intermediaries, etc. as it seems underspecified. 18:46:25 vincent: now question is what should we do? 18:47:49 q+ 18:48:21 ack danc 18:48:57 daveo: my view is that this is about layering, and that ws-addressing + soap layers on http. http doesn't necessarily "know" about the upper layers. 18:49:18 ed: I understand the issue much better now.. 18:49:44 ed: and how does this fit into web architecture, TAG should do something but not sure quite what yet. 18:49:57 (I think the industry is having a discussion about when SOA is called for and when GET/POST is more cost-effective) 18:50:18 vincent: let's move on for this agenda 18:50:26 I wind up simply feeling that I wouldn't do it the WSA way, but I can't see that it's architecturally wrong. 18:50:59 (DanC, I disagree that SOA = WS. I think GET/POST is an awesome SOA). 18:51:24 vincent: thanks MarkB for the time, and we may re-invite 18:51:28 thanks everybody 18:51:34 topic: media types 38 18:51:37 -MarkB 18:51:56 (fair point, dorchard ) 18:51:59 p.s. norm - don't think "wrong", think "inconsistent with Webarch" 18:53:08 ed: summarizing some of my questions.. 18:53:23 ed: where do we get the authoritative metadata, what about external documents 18:53:25 q+ 18:54:03 ed: criticizing a Roy paper is like saying Thor's hammer needs to be bigger. 18:54:19 q+ to say that Roy's finding DOES apply to SOAP 18:54:32 ack noah 18:54:32 noah, you wanted to say that Roy's finding DOES apply to SOAP 18:54:48 +1 to noah's upcoming point. 18:55:22 Noah: Roy's finding does apply to SOAP. A bit of lingering "if you are sloppy with SOAP you can misuse the web". 18:55:43 noah: SOAP works better on the web. Has media type. 18:56:05 noah: when you get a SOAP message, you get a SOAP media type, which is exactly what Roy says is the right way to do things 18:56:09 (I concur that the metadata finding applies to SOAP more or less as well as to any other format) 18:56:26 noah: WSDL does not change the story 18:56:56 noah: if WSDL says I expect a sports score, and there is a purchase order in a message, the message is still about a purchase order 18:58:12 daveo: from my perspective, the message metadata always describes the message. 18:58:37 daveo: and the description is a snapshot of a description 18:59:11 I reviewed it a few weeks ago and liked it a lot. I didn't carefully track changes since then, but I liked it enough a few weeks ago that I'd approve now if the WG wants to. 18:59:17 If others want more review time, so be it. 18:59:27 I'd be happy to approve it today, but I don't mind waiting a week. 18:59:43 BTW: I think it's an example of a relatively long finding that in fact justifies its length. 18:59:46 daveo: to the extent that the message lines up with the description, things are good. When things diverge, say versioning of service or caches or bugs in software, things are bad but the message still wins 19:00:55 q+ to respond to a different aspect of what Ed was saying, connected to RDFUriMeaning-nn 19:02:00 daveo: brilliant points about senders/receivers/xsd not lining up. 19:03:02 Noah: Roy's point is about "what the message is". text/xml is a smaller problem than the right xsd 19:05:43 Dave: trying to characterize this as Ed following metadata one step further than media-type, goes into each instance of the media-type, such as a WSDL/SOAP that says send this XSD> 19:06:43 Roy talks about much more than mediaType. The table in his section 2 talks about quite a variety of metadata (e.g. RDF statements, which by the way feel a lot like WSDL and XSD regarding their role in describing a resource.) 19:07:29 Ed: story is about metadata and discovery 19:08:11 We need messages to be accurate about what they are, and if the service doesn't know about the particular message, then it faults/does whatever. 19:08:13 I hear Ed asking for a para that says, roughly "there are higher level metadata issues, involving multiple messages/resources. If you're looking for that story, you're on the wrong flight" 19:10:04 ed: I can live with that adding a paragraph saying this isn't about general metadata discovery, etc. 19:10:04 need to run ... 19:11:26 Vincent: we will wait a week 19:11:49 ACTION: Propose disclaimer and discuss with roy 19:11:56 ACTION: Ed Propose disclaimer and discuss with roy 19:12:09 topic: state finding 19:12:49 I like what the state finding is trying to do. 19:12:58 I have a bit of trouble with statements like: "The state in an application may exist across a large variety of applications." 19:13:05 -??P1 19:13:25 DaveO: agrees with Noah ... ooops never mind 19:13:38 -> http://lists.w3.org/Archives/Public/www-tag/2006Feb/att-0076/State.html [Editorial Draft] State in Web application design Draft TAG Finding 15 February 2006 19:13:46 DaveO: Goal of document is to give guidance on building stateful application. 19:13:57 DaveO: walking through document 19:14:27 DaveO: talks about different kinds of state, where is it stored? session state? do clients store the state itself or an identifier? 19:14:39 DaveO: there are several examples 19:14:53 DaveO: Banking example: they get a session, get some balances. 19:15:08 q+ to ask if the case of bookmarking my bank balance page is covered 19:15:32 DaveO: Examples include http authentication, URL rewriting, cookies with client side state, cookies with session ids 19:15:49 DaveO: a range of session-related issues are discussed 19:15:57 DaveO: How is information relating to sessions exchanged? 19:15:57 (er... POST GetBalance ?! ) 19:16:35 DaveO: talks about resource identifiers. Two styles: (1) Generic account resource with cookie used to figure out account numbers vs (2) making a URI for each account 19:16:50 DaveO: XML-centric examples are offered to contrast with browsing scenarios 19:17:20 DaveO: Web service example, WS-Addressing. Login. EPR to the bank account. Get balance SOAP request using reference parms. Brief discussion of EPRs. 19:17:46 DaveO: shows WS-Security name and passord. WS-Security context token. 19:18:05 DaveO: So, I've shown session state and application state in both custom built and WS-Security styles. 19:18:29 DaveO: lengthy section on decision factors. Ease of app construction, scaleability, security [scribe missed some], etc. 19:18:45 DaveO: these are traded off when applications use state. 19:19:25 Roy Fielding argues in his REST dissertation [REST] that stateless server has the benefits of increasing reliability, scalability, visibility and while potentially decreasing network performance. However, I believe the trade-offs from an application developers perspective are somewhat different, and need to be examined from a holistic perspective. 19:20:13 DaveO: so, I'm trying to go beyond what Roy says, because we know people who are building stateful implementations with good performance, scalability, security, etc. 19:20:36 DaveO: I'm also trying to absorb or build on some of the earlier discussion of EPRs. 19:20:42 q? 19:21:45 DaveO: I spoke to several people in Mandelieu and am working on integrating their comments. 19:21:47 ack danc 19:21:47 DanC, you wanted to ask if the case of bookmarking my bank balance page is covered 19:22:36 DaveO: toward the end of the example Dan asked about, there are some TBD notes. Need to flesh it out. 19:22:44 (which example are we on?) 19:22:56 DanC: so having things you can't bookmark is bad? 19:23:06 DaveO: um, ah... (implying it may be a tradeoff) 19:23:26 DanC: well, if it's defensible, then you should explain why. 19:24:10 DaveO: is this roughly oK with people? 19:24:14 q+ on style 19:24:20 q- on 19:24:25 q- style 19:24:28 q+ to talk about style 19:24:34 ack noah 19:24:34 noah, you wanted to talk about style 19:24:56 noah: mental toc is close to the mark 19:25:05 noah: needs tightening of prose 19:25:06 DanC: I sure like the bank login example 19:25:16 ... very engaging 19:26:35 ed: good paper, like to see finished. Can help if needed.. 19:27:45 q+ to note some potential reviewers from the security workshop 19:29:46 ack danc 19:29:46 DanC, you wanted to note some potential reviewers from the security workshop 19:30:52 RRSAgent, draft minutes 19:30:52 I have made the request to generate http://www.w3.org/2006/03/28-tagmem-minutes.html DanC 19:31:00 Ed: I did exchange some emails with Lisa this week from the security workshop as well. I'll summarize in email. 19:31:05 RRSAgent, make logs world-access 19:31:29 -noah 19:31:30 -Ed_Rice 19:31:31 -DOrchard 19:31:32 -DanC 19:31:32 -Norm 19:35:46 -Vincent_Quint 19:35:48 TAG_Weekly()12:30PM has ended 19:35:49 Attendees were Norm, MarkB, Ed_Rice, DOrchard, Vincent_Quint, noah, DanC 20:08:33 Norm has joined #tagmem 20:19:05 er... is this in response to my mozex weblog item, Norm ? 20:19:09 Yes 20:19:51 http://dig.csail.mit.edu/breadcrumbs/node/102 20:19:54 so... what's the question? 20:20:46 you say, "after a couple of configuration hassles" 20:20:52 With a link to the URI I gave above. 20:21:06 I find no relevant information in that resource 20:23:40 OTOH, I did get it to work after reading the docs. 20:23:46 SAAAAwheeet! 20:36:12 congrats 21:49:19 Zakim has left #tagmem