TAG telcon -- 28 Mar 2006

[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"

Future telcons

<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]

endpointrefs-47

<DanC> (only a year? that's pretty young, as tag issues go. 1/2 ;-)

MarkB: discussed with Noah, Stuart
... 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 gateways
... 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.

<MarkB> hello

<MarkB> oops

<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

<MarkB> grrrr

<MarkB> '

<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: no.

<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

<Ed> +1

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 better now..
... 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

media types 38

<DanC> (fair point, dorchard )

<MarkB> p.s. norm - don't think "wrong", think "inconsistent with Webarch"

ed: summarizing some of my questions..
... 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 story
... 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]

state finding

<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

<DanC> [Editorial Draft] State in Web application design Draft TAG Finding 15 February 2006

[Noah scribes for DaveO's intro]

DaveO: Goal of document is to give guidance on building stateful application.
... 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 mark
... 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

TAG telcon

28 Mar 2006

Attendees

Contents

Future telcons

endpointrefs-47

media types 38

state finding

Summary of Action Items

Scribe.perl diagnostic output