IRC log of tagmem on 2006-03-28

Timestamps are in UTC.

18:00:08 [RRSAgent]
RRSAgent has joined #tagmem
18:00:08 [RRSAgent]
logging to http://www.w3.org/2006/03/28-tagmem-irc
18:01:12 [Zakim]
+DOrchard
18:02:02 [Zakim]
+Vincent_Quint
18:03:09 [Vincent]
Zakim, who is here
18:03:09 [Zakim]
Vincent, you need to end that query with '?'
18:03:18 [Vincent]
Zakim, who is here?
18:03:18 [Zakim]
On the phone I see Norm, MarkB, Ed_Rice, DOrchard, Vincent_Quint
18:03:19 [Zakim]
On IRC I see RRSAgent, Ed, Vincent, Zakim, Norm, MarkB, DanC
18:03:35 [noah]
noah has joined #tagmem
18:03:42 [Zakim]
+[IBMCambridge]
18:03:44 [MarkB]
earlier, DanC wrote; DanC is preparing an agenda for a SPARQL thingy; might be late for TAG today"
18:03:54 [noah]
zakim, [IBMCambridge] is me
18:03:54 [Zakim]
+noah; got it
18:04:02 [dorchard]
dorchard has joined #tagmem
18:04:08 [dorchard]
brb
18:06:01 [noah]
zakim, who is here?
18:06:01 [Zakim]
On the phone I see Norm, MarkB, Ed_Rice, DOrchard, Vincent_Quint, noah
18:06:03 [Zakim]
On IRC I see dorchard, noah, RRSAgent, Ed, Vincent, Zakim, Norm, MarkB, DanC
18:06:28 [Zakim]
+??P1
18:07:15 [raman]
raman has joined #tagmem
18:07:27 [raman]
#tagmem
18:07:36 [dorchard]
scribe: dorchard
18:08:12 [noah]
topic: Future telcons
18:08:51 [noah]
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 [Zakim]
+DanC
18:10:13 [dorchard]
regrets from noah, ed
18:10:37 [dorchard]
tv scribe next week
18:11:29 [dorchard]
action: minutes from 03/28 approved
18:12:49 [dorchard]
topic: endpointrefs-47
18:13:18 [DanC]
(only a year? that's pretty young, as tag issues go. 1/2 ;-)
18:14:08 [dorchard]
MarkB: discussed with Noah, Stuart
18:14:30 [dorchard]
MarkB: TAG issue is accurate
18:14:59 [dorchard]
MarkB: WSA:To header/component/property does not make it into the HTTP request URI, and it darn well ought to.
18:17:08 [dorchard]
Vincent: why didn't TAG look directly at this?
18:18:07 [dorchard]
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 [dorchard]
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 [raman]
mmark is impossible to understand.
18:20:38 [noah]
q+ to ask about gateways vs. proxies
18:21:00 [dorchard]
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 [Vincent]
ack noah
18:21:23 [Zakim]
noah, you wanted to ask about gateways vs. proxies
18:21:47 [dorchard]
Noah: HTTP has proxies and gateways
18:23:17 [dorchard]
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 [dorchard]
Noah: this is a gateway scenario. The way the gateway works is by looking at the ws-a header.
18:24:48 [dorchard]
tv: gateway could do rewrite
18:25:32 [dorchard]
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 [dorchard]
markb: you've described proxies and gateways in http correctly
18:27:24 [dorchard]
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 [MarkB]
hello
18:28:26 [Zakim]
-MarkB
18:28:33 [MarkB]
oops
18:28:49 [Zakim]
+[IPcaller]
18:29:31 [Vincent]
zakim, IPcaller is MarkB
18:29:31 [Zakim]
+MarkB; got it
18:30:24 [noah]
DaveO: The wsa:To field should never refer to something beyond the Request-URI in terms of hops.
18:31:14 [dorchard]
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 [dorchard]
MarkB: the http request-uri should be to the ultimate recipient.
18:32:02 [dorchard]
MarkB: can live with ws-a:to and request-uri being the same.
18:32:11 [dorchard]
MarkB: wsa:to does not need to be removed
18:32:39 [dorchard]
vincent: trolls for DanC comments..
18:33:03 [noah]
Is the real issue whether multiple wsa:To URIs are routed to the same Request-URI?
18:33:35 [noah]
q+ to ask about one-to-one vs one-to-many
18:34:13 [dorchard]
DanC: seems like the "if they used URIs they'd be ok, otherwise they'll need more expensive software"
18:35:28 [Vincent]
ack noah
18:35:28 [Zakim]
noah, you wanted to ask about one-to-one vs one-to-many
18:36:08 [Zakim]
-MarkB
18:36:29 [dorchard]
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 [MarkB]
grrrr
18:36:34 [MarkB]
'
18:37:10 [DanC]
DanC: ah. thanks, Dave. I think I see now.
18:38:47 [Zakim]
+[IPcaller]
18:39:21 [dorchard]
Noah: Mark has the concern with what I'm calling the gateway scenario.
18:39:22 [Vincent]
zakim, IPcaller is MarkB
18:39:22 [Zakim]
+MarkB; got it
18:39:24 [MarkB]
sub-addressing; right. aka "source routing"
18:39:57 [dorchard]
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 [dorchard]
markb: no.
18:40:42 [MarkB]
i'm still cutting in and out 8-(
18:41:06 [dorchard]
noah: risk is that ws-a will do wsa:to to 3 resources, and there's only 1 uri for gateway.
18:41:47 [dorchard]
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 [dorchard]
noah: if all request-uris to the gateway are the same, then you can't use GET
18:43:44 [dorchard]
vincent: do you think the TAG understands the issue?
18:44:18 [dorchard]
markb: yes, and encouraged
18:44:33 [dorchard]
Vincent: TAG, do you underand the issue better?
18:44:39 [dorchard]
danc: yes, thanks
18:44:44 [Ed]
+1
18:44:48 [dorchard]
daveo: I'm at the same point I was before
18:45:56 [dorchard]
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 [dorchard]
vincent: now question is what should we do?
18:47:49 [DanC]
q+
18:48:21 [Vincent]
ack danc
18:48:57 [dorchard]
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 [dorchard]
ed: I understand the issue much better now..
18:49:44 [dorchard]
ed: and how does this fit into web architecture, TAG should do something but not sure quite what yet.
18:49:57 [DanC]
(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 [dorchard]
vincent: let's move on for this agenda
18:50:26 [Norm]
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 [dorchard]
(DanC, I disagree that SOA = WS. I think GET/POST is an awesome SOA).
18:51:24 [dorchard]
vincent: thanks MarkB for the time, and we may re-invite
18:51:28 [MarkB]
thanks everybody
18:51:34 [dorchard]
topic: media types 38
18:51:37 [Zakim]
-MarkB
18:51:56 [DanC]
(fair point, dorchard )
18:51:59 [MarkB]
p.s. norm - don't think "wrong", think "inconsistent with Webarch"
18:53:08 [dorchard]
ed: summarizing some of my questions..
18:53:23 [dorchard]
ed: where do we get the authoritative metadata, what about external documents
18:53:25 [noah]
q+
18:54:03 [dorchard]
ed: criticizing a Roy paper is like saying Thor's hammer needs to be bigger.
18:54:19 [noah]
q+ to say that Roy's finding DOES apply to SOAP
18:54:32 [Vincent]
ack noah
18:54:32 [Zakim]
noah, you wanted to say that Roy's finding DOES apply to SOAP
18:54:48 [dorchard]
+1 to noah's upcoming point.
18:55:22 [dorchard]
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 [dorchard]
noah: SOAP works better on the web. Has media type.
18:56:05 [dorchard]
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 [DanC]
(I concur that the metadata finding applies to SOAP more or less as well as to any other format)
18:56:26 [dorchard]
noah: WSDL does not change the story
18:56:56 [dorchard]
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 [dorchard]
daveo: from my perspective, the message metadata always describes the message.
18:58:37 [dorchard]
daveo: and the description is a snapshot of a description
18:59:11 [noah]
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 [noah]
If others want more review time, so be it.
18:59:27 [Norm]
I'd be happy to approve it today, but I don't mind waiting a week.
18:59:43 [noah]
BTW: I think it's an example of a relatively long finding that in fact justifies its length.
18:59:46 [dorchard]
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 [DanC]
q+ to respond to a different aspect of what Ed was saying, connected to RDFUriMeaning-nn
19:02:00 [dorchard]
daveo: brilliant points about senders/receivers/xsd not lining up.
19:03:02 [dorchard]
Noah: Roy's point is about "what the message is". text/xml is a smaller problem than the right xsd
19:05:43 [dorchard]
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 [noah]
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 [dorchard]
Ed: story is about metadata and discovery
19:08:11 [dorchard]
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 [DanC]
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 [dorchard]
ed: I can live with that adding a paragraph saying this isn't about general metadata discovery, etc.
19:10:04 [raman]
need to run ...
19:11:26 [dorchard]
Vincent: we will wait a week
19:11:49 [dorchard]
ACTION: Propose disclaimer and discuss with roy
19:11:56 [dorchard]
ACTION: Ed Propose disclaimer and discuss with roy
19:12:09 [dorchard]
topic: state finding
19:12:49 [noah]
I like what the state finding is trying to do.
19:12:58 [noah]
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 [Zakim]
-??P1
19:13:25 [noah]
DaveO: agrees with Noah ... ooops never mind
19:13:38 [DanC]
-> 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 [noah]
DaveO: Goal of document is to give guidance on building stateful application.
19:13:57 [noah]
DaveO: walking through document
19:14:27 [noah]
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 [noah]
DaveO: there are several examples
19:14:53 [noah]
DaveO: Banking example: they get a session, get some balances.
19:15:08 [DanC]
q+ to ask if the case of bookmarking my bank balance page is covered
19:15:32 [noah]
DaveO: Examples include http authentication, URL rewriting, cookies with client side state, cookies with session ids
19:15:49 [noah]
DaveO: a range of session-related issues are discussed
19:15:57 [noah]
DaveO: How is information relating to sessions exchanged?
19:15:57 [DanC]
(er... POST <Action>GetBalance<Action> ?! )
19:16:35 [noah]
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 [noah]
DaveO: XML-centric examples are offered to contrast with browsing scenarios
19:17:20 [noah]
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 [noah]
DaveO: shows WS-Security name and passord. WS-Security context token.
19:18:05 [noah]
DaveO: So, I've shown session state and application state in both custom built and WS-Security styles.
19:18:29 [noah]
DaveO: lengthy section on decision factors. Ease of app construction, scaleability, security [scribe missed some], etc.
19:18:45 [noah]
DaveO: these are traded off when applications use state.
19:19:25 [dorchard]
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 [noah]
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 [noah]
DaveO: I'm also trying to absorb or build on some of the earlier discussion of EPRs.
19:20:42 [noah]
q?
19:21:45 [noah]
DaveO: I spoke to several people in Mandelieu and am working on integrating their comments.
19:21:47 [Vincent]
ack danc
19:21:47 [Zakim]
DanC, you wanted to ask if the case of bookmarking my bank balance page is covered
19:22:36 [noah]
DaveO: toward the end of the example Dan asked about, there are some TBD notes. Need to flesh it out.
19:22:44 [noah]
(which example are we on?)
19:22:56 [noah]
DanC: so having things you can't bookmark is bad?
19:23:06 [noah]
DaveO: um, ah... (implying it may be a tradeoff)
19:23:26 [noah]
DanC: well, if it's defensible, then you should explain why.
19:24:10 [noah]
DaveO: is this roughly oK with people?
19:24:14 [noah]
q+ on style
19:24:20 [noah]
q- on
19:24:25 [noah]
q- style
19:24:28 [noah]
q+ to talk about style
19:24:34 [Vincent]
ack noah
19:24:34 [Zakim]
noah, you wanted to talk about style
19:24:56 [dorchard]
noah: mental toc is close to the mark
19:25:05 [dorchard]
noah: needs tightening of prose
19:25:06 [DanC]
DanC: I sure like the bank login example
19:25:16 [DanC]
... very engaging
19:26:35 [dorchard]
ed: good paper, like to see finished. Can help if needed..
19:27:45 [DanC]
q+ to note some potential reviewers from the security workshop
19:29:46 [Vincent]
ack danc
19:29:46 [Zakim]
DanC, you wanted to note some potential reviewers from the security workshop
19:30:52 [DanC]
RRSAgent, draft minutes
19:30:52 [RRSAgent]
I have made the request to generate http://www.w3.org/2006/03/28-tagmem-minutes.html DanC
19:31:00 [Ed]
Ed: I did exchange some emails with Lisa this week from the security workshop as well. I'll summarize in email.
19:31:05 [DanC]
RRSAgent, make logs world-access
19:31:29 [Zakim]
-noah
19:31:30 [Zakim]
-Ed_Rice
19:31:31 [Zakim]
-DOrchard
19:31:32 [Zakim]
-DanC
19:31:32 [Zakim]
-Norm
19:35:46 [Zakim]
-Vincent_Quint
19:35:48 [Zakim]
TAG_Weekly()12:30PM has ended
19:35:49 [Zakim]
Attendees were Norm, MarkB, Ed_Rice, DOrchard, Vincent_Quint, noah, DanC
20:08:33 [Norm]
Norm has joined #tagmem
20:19:05 [DanC]
er... is this in response to my mozex weblog item, Norm ?
20:19:09 [Norm]
Yes
20:19:51 [DanC]
http://dig.csail.mit.edu/breadcrumbs/node/102
20:19:54 [DanC]
so... what's the question?
20:20:46 [Norm]
you say, "after a couple of configuration hassles"
20:20:52 [Norm]
With a link to the URI I gave above.
20:21:06 [Norm]
I find no relevant information in that resource
20:23:40 [Norm]
OTOH, I did get it to work after reading the docs.
20:23:46 [Norm]
SAAAAwheeet!
20:36:12 [DanC]
congrats
21:49:19 [Zakim]
Zakim has left #tagmem