See also: IRC log
[Mark Baker joins the call by invitation for the endpointrefs-47 discussion]
<MarkB> earlier, DanC wrote; DanC is preparing an agenda for a SPARQL thingy; might be late for TAG today"
<noah> Regrets from Noah for April 4 (schema WG), at risk for April 18th. I expect to be on the call April 11th.
regrets from noah, ed
tv scribe next week
<scribe> ACTION: minutes from 03/28 approved [recorded in http://www.w3.org/2006/03/28-tagmem-minutes.html#action01]
<DanC> (only a year? that's pretty young, as tag issues go. 1/2 ;-)
MarkB: discussed with Noah,
... TAG issue is accurate
... WSA:To header/component/property does not make it into the HTTP request URI, and it darn well ought to.
Vincent: why didn't TAG look directly at this?
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.
Noah: said another way, the issue is that when WS-A is stacked up, it may be that 2616 isn't followed.
<raman> mmark is impossible to understand.
MarkB: firewalls look at request URI. With WS-A and Ultimate receiver inside the message, then the target is not visible to HTTP firewall.
<Zakim> noah, you wanted to ask about gateways vs. proxies
Noah: HTTP has proxies and
... 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..
... this is a gateway scenario. The way the gateway works is by looking at the ws-a header.
tv: gateway could do rewrite
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.
markb: you've described proxies
and gateways in http correctly
... (as said by Noah) What WS-A is doing is that client is seeing the structure behind the gateway, rather than hiding it.
<noah> DaveO: The wsa:To field should never refer to something beyond the Request-URI in terms of hops.
DaveO: trying to summarize, WS-A would be doing the right thing if the wsa:To was not "past" the http request-uri
MarkB: the http request-uri
should be to the ultimate recipient.
... can live with ws-a:to and request-uri being the same.
... wsa:to does not need to be removed
vincent: trolls for DanC comments..
<noah> Is the real issue whether multiple wsa:To URIs are routed to the same Request-URI?
DanC: seems like the "if they used URIs they'd be ok, otherwise they'll need more expensive software"
<Zakim> noah, you wanted to ask about one-to-one vs one-to-many
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
<DanC> DanC: ah. thanks, Dave. I think I see now.
Noah: Mark has the concern with what I'm calling the gateway scenario.
<MarkB> sub-addressing; right. aka "source routing"
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
<MarkB> i'm still cutting in and out 8-(
noah: risk is that ws-a will do wsa:to to 3 resources, and there's only 1 uri for gateway.
markb: in order to use http in the web architecture, only 1 resource should be used at a time in a given request
noah: if all request-uris to the gateway are the same, then you can't use GET
vincent: do you think the TAG understands the issue?
markb: yes, and encouraged
Vincent: TAG, do you underand the issue better?
danc: yes, thanks
daveo: I'm at the same point I was before
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.
vincent: now question is what should we do?
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.
ed: I understand the issue much
... and how does this fit into web architecture, TAG should do something but not sure quite what yet.
<DanC> (I think the industry is having a discussion about when SOA is called for and when GET/POST is more cost-effective)
vincent: let's move on for this agenda
<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.
(DanC, I disagree that SOA = WS. I think GET/POST is an awesome SOA).
vincent: thanks MarkB for the time, and we may re-invite
<MarkB> thanks everybody
<DanC> (fair point, dorchard )
<MarkB> p.s. norm - don't think "wrong", think "inconsistent with Webarch"
ed: summarizing some of my
... where do we get the authoritative metadata, what about external documents
... criticizing a Roy paper is like saying Thor's hammer needs to be bigger.
<Zakim> noah, you wanted to say that Roy's finding DOES apply to SOAP
+1 to noah's upcoming point.
Noah: Roy's finding does apply to
SOAP. A bit of lingering "if you are sloppy with SOAP you can
misuse the web".
... SOAP works better on the web. Has media type.
... 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
<DanC> (I concur that the metadata finding applies to SOAP more or less as well as to any other format)
noah: WSDL does not change the
... 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
daveo: from my perspective, the
message metadata always describes the message.
... and the description is a snapshot of a description
<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.
<noah> If others want more review time, so be it.
<Norm> I'd be happy to approve it today, but I don't mind waiting a week.
<noah> BTW: I think it's an example of a relatively long finding that in fact justifies its length.
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
... brilliant points about senders/receivers/xsd not lining up.
Noah: Roy's point is about "what the message is". text/xml is a smaller problem than the right xsd
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>
<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.)
Ed: story is about metadata and discovery
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.
<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"
ed: I can live with that adding a paragraph saying this isn't about general metadata discovery, etc.
<raman> need to run ...
Vincent: we will wait a week
<scribe> ACTION: Ed Propose disclaimer and discuss with roy [recorded in http://www.w3.org/2006/03/28-tagmem-minutes.html#action03]
<noah> I like what the state finding is trying to do.
<noah> I have a bit of trouble with statements like: "The state in an application may exist across a large variety of applications."
<noah> DaveO: agrees with Noah ... ooops never mind
[Noah scribes for DaveO's intro]
DaveO: Goal of
document is to give guidance on building stateful
... walking through document
... talks about different kinds of state, where is it stored? session state? do clients store the state itself or an identifier?
... there are several examples
... Banking example: they get a session, get some balances.
... Examples include http authentication, URL rewriting, cookies with client side state, cookies with session ids
... a range of session-related issues are discussed
... How is information relating to sessions exchanged?
<DanC> (er... POST <Action>GetBalance<Action> ?! )
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
... XML-centric examples are offered to contrast with browsing scenarios
... Web service example, WS-Addressing. Login. EPR to the bank account. Get balance SOAP request using reference parms. Brief discussion of EPRs.
... shows WS-Security name and passord. WS-Security context token.
... So, I've shown session state and application state in both custom built and WS-Security styles.
... lengthy section on decision factors. Ease of app construction, scaleability, security [scribe missed some], etc.
... these are traded off when applications use state.
<DaveO> 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.
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.
... I'm also trying to absorb or build on some of the earlier discussion of EPRs.
... I spoke to several people in Mandelieu and am working on integrating their comments.
<Zakim> DanC, you wanted to ask if the case of bookmarking my bank balance page is covered
DaveO: toward the end of the example Dan asked about, there are some TBD notes. Need to flesh it out.
<noah> (which example are we on?)
DanC so having things you can't bookmark is bad?
DaveO: um, ah... (implying it may be a tradeoff)
DanC well, if it's defensible, then you should explain why.
DaveO: is this roughly oK with people?
<Zakim> noah, you wanted to talk about style
noah: mental toc is close to the
... needs tightening of prose
<DanC> DanC: I sure like the bank login example
<DanC> ... very engaging
ed: good paper, like to see finished. Can help if needed..
<Zakim> DanC, you wanted to note some potential reviewers from the security workshop
This is scribe.perl Revision: 1.127 of Date: 2005/08/16 15:12:03 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Found Scribe: dorchard Inferring ScribeNick: dorchard WARNING: No "Present: ... " found! Possibly Present: BTW DanC Dave DaveO Ed Ed_Rice IBMCambridge IPcaller MarkB Norm P1 Vincent Vincent_Quint dorchard noah raman tv You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 28 Mar 2006 Guessing minutes URL: http://www.w3.org/2006/03/28-tagmem-minutes.html People with action items: ed minutes propose WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]