Web Services Addressing WG F2F (Melbourne, Australia)

18 Jan 2005


See also: IRC log


Francisco Curbera (IBM Corporation)
Glen Daniels (Sonic Software)
Paul Downey (BT)
Michael Eder (Nokia)
Robert Freund (Hitachi, Ltd.)
Martin Gudgin (Microsoft Corporation)
Hugo Haas (W3C)
Marc Hadley (Sun Microsystems, Inc.)
Yin-Leng Husband (HP)
Anish Karmarkar (Oracle Corporation)
Jonathan Marsh (Microsoft Corporation)
Jeff Mischkinsky (Oracle Corporation)
David Orchard (BEA Systems, Inc.)
Mark Peel (Novell, Inc.)
Tom Rutt (Fujitsu Limited)
Davanum Srinivas (Computer Associates) (substitute: Tony Rogers)
Greg Truty (IBM Corporation)
Pete Wenzel (SeeBeyond Technology Corporation)
Steve Winkler (SAP AG)
Ümit Yalçınalp(SAP AG)
Rebecca Bergersen (IONA Technologies, Inc.)
Ugo Corda (SeeBeyond Technology Corporation)
Jacques Durand (Fujitsu Limited)
Arun Gupta (Sun Microsystems, Inc.)
Philippe Le Hégaret (W3C)
Mark Little (Arjuna Technologies Ltd.)
Eisaku Nishiyama (Hitachi, Ltd.)
Ales Novy (Systinet Inc.)
Harris Reynolds (webMethods, Inc.)
Rich Salz (DataPower Technology, Inc.)
Jiri Tejkl (Systinet Inc.)
Steve Vinoski (IONA Technologies, Inc.)
Mark Nottingham
Paul Downey, Steve Winkler

Agenda Bashing

Chair: today we will be mostly discussing issues 8 & 16

Issue 008, Issue 016

glen: bunch of issues on 'refps' bunch of stuff which must be echoed back as 1st class soap headers. discussion on architectural goodness of various proposals.
... 1) surrounds wrapper header
... 2) distinguish refps from other headers
... option 2) reveals the crux of the discussion. important for security to distinguish between headers put in as an echo and those put in on purpose
... discussion has been long and winding. i brought up four buckets simplicity, security, composability and clarity
... are things opaque? i think your require to given there may be a clash with other intended, understood headers. esp for ws-security.
... refps may include headers from other specs (ws-RM, etc) already in use which will cause problems and introduces security concerns.
... opposing argument is all you need to do is know where your EPRs come from and trust them implicitly.

Chair: and your AI to push this discussion on?

glen: would like more time

Chair: given our timeline i'm going to strike it from the record
... what about the two proposals: wrapped and attribute tagging?

glen: with the status quo i'll have to write code that checks and scans refps and checks consitancy and side effects of headers put in by refps. a bag will simplify this.

tom: +1 to glen. i see getting rid of side effects as a virtue, whilst others want the side-effects. that's the problem.

glen: an observer won't know which headers were echoed and which were put in intentionally as a part of another contract

steve: wants to understand the problems with the annotation marker

<GregT> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0028.html

glen: not everyone will understand the tag, e.g. existing software
... doesn't solve the problem given not everyone will understand the attribute

marc: the fundemental problem is that it's still a RM header even though it's flagged

marsh: 90% case is for the side-effect and that's growing

glen: wants to understand this processing model

gudge: it's start with the soap message and figure what the EPR looks like

anish: +1 to to glen. i want to look at this with issue 18.
... refps are meant to be abstract right?

glen: they're targeted at a particular role/node at a particular time

anish: cookie model. wrapper - a well defined soap header with a well defined processing model would answer this requirement.

tom: going back to mustUnderstand. marking an attribute - isn't the scope for the whole header? what's the problem with wrapping - is it directing individual props to different roles?

marsh: yes. we'd have to reinvent soap processing model within a wrapper element

glen: a lot of this be done by prior agreement

gudge: has to be done dynamically as there may be more than one of you

greg: gudge brought out my point. if you're worried about confliction - don't put stuff in your EPR that's likely to conflict.

glen: WSDLs can be dynamically generated. i could mint one for each use. i could use a policy statement. there's a good set of use-cases to tweak my policy on the fly and continue to describe the contract.

tony: wrapper could be optional to allow refps to be hidden from an intermediatory - give the minter this level of control.

daveo: how does that address the security concern?

marsh: sounds interesting. a conservative consumer could choose to only process headers in the bag.

glen: could just be ignored by some vendors and be useless

marsh: see little difference between the optional bag and the marker

anish: status quo allows you to do this already

marsh: though this is a standardisation of this option

glen: don't like this

marc: me neither

paco: (to glen) difference between describing in WSDL and Policy?

marc: it's the difference between signing a blank piece of paper and signing a letter

glen: are you going to write software that checks and validates an EPR

marsh: outside of the scope of the WG, but it doesn't seem unreasonable

gudge: we might use a blacklist approach..
... we have stuff already which works this way, and IBM has resource framework.

greg: lots of use-cases (tracing/ logging) for the unwrapped approach

daveo: i've yet to hear an acknowledgement from the refps as soap headers is a security problem

marsh: trust is out of scope

paco: our guys have looked into this and we're ok

jeffm: i'm still unclear what the trade-off is here. you're argument seems to be to stick with the status quo

gudge: we don't beleive there is a security issue

<Marsh> actually, gudge says, we don't believe the wrapped approach is any more secure.

bob: other mechanisms exist to secure channels. but you can't secure something that's already been hacked

<jeffm> I also said that saying trust/security is out of scope is what leads to the design of insecure/easily hackable systems - if we believe that one method is more secure we should choose it, especially since the argument against seems to be mostly this is the "status quo" from the draft spec we wrote

discussion of side effects of blindly echoing refps on intermediaries

gudge: this is a legal issue. keep copies of EPRs i've been sent. flip it around, what happens if i mark headers which aren't refps?

bob: only security you've got is to secure the message hasn't been tampered with. you can't protect against an insane minter. trust is out of scope.

daveo: good protocol sepcs will help mitigate against malicious parties in a court of law. i don't think we should say we can't do anything about this.

bob: protection against tampering is sufficient

tony: i'm not concerned about the endpoint. i'm concerend about the impact on intermediatories. these could do "bad things" TM. e.g. denial of service attacks. putting them in a wrapper targets them end to end.

marc: not just intermediaries, you can craft an message to go to other unexpected places.

daveo: it's don box's side-effects that interests me most as a counter argument

Chair: glad that the discussion isn't just black and white, that both sides agree it's a trade-off. have people changed sides?

marsh, gudge: we haven't heard anything new, yet today

Chair: about to go for a 20 minute break. whole schedule is brought forward 30 mins
... what about the 'put a wrapper in To' proposal

proposals: http://www.w3.org/2002/ws/addr/wd-issues/#i008

discussion of the proposals:

0) Status Quo

1) To as EPR

2) Wrapped

3) Attribute

4) Attribute + Required Header

Chair: would the required header always be required to be there?

gudge: sounds like a 2nd order question after we've decided which way we're going.

<mlpeel> +1 to gudge's remark

tony: how does wrapping refps in To imact the optionality of To

<stevewinkler> There are actually 5 options, we're starting at 0 with the status quo

hugo: doesn't like options 0 or 3

<GlenD> hugo: It's important to know the difference between things you are "really" saying and things you are being told to say

<Zakim> hugo, you wanted to talk about options 0) and 3)

straw poll

cannot live with status quo (option 0): 8

cannot live with (option 1): 4

cannot live with (option 2): 5

cannot live with (option 3): 5

cannot live with (option 4): 3 + several undecided

marc: looks like we need another proposal.

paul: or run someone over

Chair: we have to progress.

gudge: we may just need to vote and move on.

discussion between glen and marsh about proposal 4 .. requiredness of attributes

marc: seems non-deterministic, too much optionality.

glen: me too

marc: you have to put in on of these headers for every node a refp is targeted against. sounds gross.

Chair: straw poll again.

cannot live with (option 4): lots and lots

<mlpeel> -1 to option 4

Chair: goodbye to proposal #4

glen and anish sound out proposal #2. 'To' could contain a copy of the XML, or contain modified values.

anish: don't have to worry about refps being targeted at different nodes

Chair: unless you have multiple Tos .. other issue.

anish: could annotate refps inside the To

<Marsh> Tom: Could keep some in an EPR inside To, and extract others into a refP's wrapper so they could be targetted somewhere else.

daveo: could have multiple Tos, one targeted for each role rather than message

straw poll

cannot live with (option 1): 3

two companies

glen and tom discuss multiple Tos/ bags

Chair: (for myself) don't like 2, brings in other issues regarding processing model and cardinality

marc: making this decision will simplify other issues

gudge: +1 to marc

jeffm: process is make a proposal and then vote on it. finding preferences - make a STV vote!

Chair: math is frightening

staw poll, one vote only, one vote per company.

Options 0, 1, 2 and 3

<hugo> Mark Peel says 3-1-2-0

<mlpeel> hugo had it correct: Novell orders it 3, 1, 2, 0

Chair: ... calculating ... whirl ... click .. click ..

glen: 0 would close i016 with no action

Chair: close i016 as a duplicate and put text under i008

RESOLUTION: close issue 16 with no action and put text under issue 8

markn: option 1 would close issue 8

jeffm: result is a tie between 1 and 3

tom: difficulty is a difference in requirements. i voted for 2 as i'd like to target multiiple intermediaries.

markn: formal vote for option 1 or 3

microsoft 3

<hugo> W3C: 1

<hugo> Mark: 3

<mlpeel> Novell: option 3

<Gudge> mike, we can't hear you

<hugo> Nokia: abstains

HP: abstain

<MSEder> zakim. mute me

IBM: 3

SAP: 3

Hitachi: 3

Fujitsu: 1

Oracle: 1

BEA: 3

Sun: 1

BT: 3

W3C: 1

Novell: 3

Nokia: abstains

option 3 - 7

option 1 - 4

2 abstained

RESOLUTION: close issue 8 with proposal #3

i004 security model

gudge: will send mail about security considerations

marc: i'll help

discussion of what namespaces can be added to a header by refps

schema retricts ##other but there are other namespaces XOP, MTOM, etc ..

Issue 001

markn: time constrained discussion of this issue. 45 mins, lunch then 45 mins afterwards.

daveo: i'm now with paco after discussion of state in an EPR interaction. there are two types of EPR statefull (v) stateless. in all cases they're just an data echoing mechanism.

... we don't need to tell the client about the identity of what is being identified. in all cases we tend to wrap data in an element. in any of the specs where a client needs compare identitiy, there is a wrapper. we don't need to say anything in addressing about EPR identifier.

... state is a separate discussion. EPRs are about echoing data, not identification.

... propose remove text about identification in addressing. EPRs are not always identifiers.

anish: what's the difference between refprops and refparams. why 2 different mechanisms?

<MSEder> 2

paco: you can separate this discussion. there are use-cases without identifiers and use-cases with EPRs as an identitifier and use-cases with state.

marc: was with the argument until he heard paco. unhappy about maintaining distinction between params and props.

paco: address + the state is like URI and a cookie.

paco: how does state effect an interaction: 1000's of ways. policy just raises one area of concern.

marc: more than just state. you're talking about a different thing. it's hiding behind words.

jeffm: we're playing semantic games here. how can you talk about state without identity? state implies an entitiy. it's got to be the state of something.

<marc> marc: discussion is not just about state but also about diff EPRS accepting diff messages and having diff policies

<MSEder> lost audio

daveo: what led me to thinking ERPs are an identifier + state, was the lack of a comparison of EPRs in other specs.

... the specs we have which use EPRs, RM, pub-sub, etc layer comparison on top

tony: you don't cache EPRs!

jeffm: oh yes you do!

markn: warns that a spec you can't abuse is a very high bar

hugo: in the direction we're going, there isn't much difference between props and params. if we need two bags, what is the difference? one of them is still likely to be identifying something

<marc> changing state doesn't mean that a service suddenly accepts a new set of messages. it may affect the result you get for particular messages (e.g. a 'getmybankbalance' message may return a fault unless i previously sent an 'authenticateme' message). its still the same service with the same identity

tom: raises formal identifiers (v) URIs .. specs like WS-RF and RM want to use refps to distinguish what you're talking about

<marc> paco seems to suggest that refps chnage the service

paco: i can't prevent you using refps as identifiers.you can always hang yourself

daveo: i'm ok with collapsing refprops and params. under what situation would you get state in a refprop as opposed to a refparam and do something differently? we need to understand this to go forward.

<hugo> +1 to why we need both

<marc> +1 to not needing both

greg: benefits in optimisation when policy can be attached.

greg: (answering markn) 20,000 blade servers could have their own EPR.

marc: then they're an identifier

anish: if you're talking about two different 'things' then they're identifiers

paco: if everything the same apart from the policy, then are we really talking about a different thing?

anish: if two EPRs can point to the same thing, then we're not talking about identifiers

markn: what's the use-case for refprops?

glen: difference of opinion as to "what is a Web service?" is the problem here

... what we need to do is pick the 80/20 cases. EPR should point you at the same thing a WSDL points you at.

paco: world doesn't turn around WSDL

which chicken and egg. came first, the WSDL or the Web service?

paco: don't use WSDL as a straight jacket.

glen: it's dangerous to change services mid-stream

paco: in very long running services, things such as policy may change.

tom: it's good that EPRs aren't identifiers - they're references. i think we should collapse refps. we don't want them to be identifiers

markn: lunch is looming .. distinction between refprops and params

markn: our charter only requires us to consider (not resolve) this issue.

markn: lunch!

<stevewinkler> Taking over as scribe.

Constrained discussion until 2 about issue i001

Gudge: describes management system as impetus for ref props.

Mark: what is the value of refProps?

Gudge: single entry point into a system, and then use the refprops to go from there.

this stems from two different architectural views of the world: message (v) resource oriented. one isn't better than the other for all cases.

Gudge describes chart from his previous action item

Paco: params and properties are used for state.

marc: that's not what the spec says.

paco: but that's how it's used.

daveo: that was then, this is now. we'll remove identifier terms and add in the part about state.

gudge: The question is, why are there two buckets?

gudge: it seems that we'll use this answer to inform the decision of i001, what is an identifier.

glen: my preference is to simplfy addressing, allow the other use to be layered on top.

marc: so you would say that the management app would define a param.

glen: I would define an EPR extension.

gudge's diagram from Redmond: http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0084.html

paco: so waht you're saying is that an EPR applies to a specific service, if the service changes you need a new EPR. Is the reverse true?
... if an EPR changes, do you have to assume that the metadata has changed.
... there's a difference between the description of the interaction and the interaction itself.
... you're assuming the client is aware of how the policy changes.

back and forth between paco and glen...

paco: we're trying to get away from defining this. We're never going to do it, so let's get away from this.

glen: yes, so what's the point of having refps indicate different metadata?
... the interesting thing about an epr is that some piece of code doesn't need to change to talk to it.

paco: yes, but if you see that they're different, then it MAY have changed.
... refparams are data, not metadata.

glen: why are we talking about the connection between an EPR and metadata at all?

paco: the rationale for having 2 buckets, is that the relationship to the metadata is different.
... a client gets an EPR that is differrent in params, you don't have to refresh your (policy?) side, but if props are different you do have to do the refresh (not cache).

mark: why are we using props to do this, instead of just params with a string that defines the metadata context?

glen: there is an unbounded way to figure out that information, why are we talking about it. It shouldn't be in the spec...

Mark: 3 options: 0 status quo, 1 remove refprops (i.e. collapse), 2 reword

reword means clarify

<Zakim> hugo, you wanted to give his view about i001 closure

daveo: the web is not aligned with the web architecture.

<hugo> Hugo: I think that option 1 would close i001, and that options 0 and 2 would required us to justify our choice with something like the comparison that we started with, and consider a QName to URI mapping

marc: the fact that webarch was written retrospectively, gives it weight, and indicates that they know how to build the types of systems we want to build.

jeff: there's a big difference between observing how others have done their implementations and codifying it in a foundational spec.

<Zakim> hugo, you wanted to disagree

marc: I see the removal of refprops as a necessary precursor to rewording the spec wrt to identification.

straw poll:

option 0 gets 0 votes and has been erased.

option 1 gets 10 votes

option 2 gets 6 votes

1 abstention

vote for adoption of proposal 1:

2 abstentions

yes: 7

No: 4

Issue 1 closed with the removal of refprops, and removal of all references to the use of EPRs as identifiers.

RESOLUTION: Issue 1 closed with the removal of refprops and removal of all references ot the use of EPRs as identifiers.

For the record, issue 1 votes: HP=Y, MSFT=N, IBM=N, SAP=ABS, HIT=Y, FUJ=Y, ORCL=Y, BEA=Y, SUN=Y, BT=Y, W3C=ABS, NOK=N, NOV=N


Anish describes the motivation for the issue.

RESOLUTION: change 'will be used instead of' to 'can be used' in section 2 of the WSDL binding. Editors to make the change now.

<marc> section: http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html#_Toc77464317

<Chair> WRT WSDL binding, section 2 2nd paragraph.

<Gudge> Here is what the amended text from Section 2 of the WSDL binding now says:

<Gudge> To support these scenarios, we define a lightweight and extensible mechanism to

<Gudge> dynamically identify and describe service endpoints and instances. Endpoint references

<Gudge> logically extend the WSDL description model (e.g., portTypes, bindings, etc.), but

<Gudge> do not replace it. Endpoint references can be used in the following cases:

<anish> the issue is at this email: http://lists.w3.org/Archives/Public/public-ws-addressing/2004Dec/0168.html

1st subissue resolved.

anish is willing to drop the 2nd subissue.

anish describes subissues 3 and 4.

<scribe> ACTION: Anish to propose text for resolving i020 subissue 4.

<scribe> ACTION: Anish to start discussion on i020 subissue 4, what are we talking about when we say endpoint reference.

<scribe> ACTION: Anish to restate description of issue i020.

<anish> ACTION 1=Anish to propose text for resolving i020 subissue 3 (what is the relationshiop between wsdl endpoint and wsa:address if a service Qname/port is present in an EPR)


pauld describes the motivation for the issue.

jonathon: we already have all the mechanisms in place to do this now, we don't need to provide extensibility for extensibility.

glen: +1
... if you want to do other things you introduce new headers.

dorchard: if we allow multiple To's a subsequent version of the spec could provide some meaning, but if we don't provide it now, then we don't enable future versions to be compatible using those QNames.

jonathon: dave wants to evolve the namespace and paul wants to evolve the functionality.

glen: I don't see a compatible change worth defining.

<pauld> going from request-response to request-respond-to-one-of-a-list

marc: an example - v1 says pick one, v2 says pick one but do so in this ordering.

<Gudge> I guess I don't understand why we wouldn't just leverage the way SOAP works to do v2

<Gudge> We define new QNames for new headers in v2

<Gudge> if the sender doesn't mark them mu='true', then v1 receivers can ignore them

<Gudge> why does our spec need to say anything?

Marsh: can we just say 'ignore stuff not in our namespace'?

pauld: discussion has been hijacked, issue is about cardinality, not versioning.

Chair: straw poll on where everyone sits.

option 1: status quo

<Gudge> 1. Status Quo

option 2: constrain in the soap binding, open in core and wsdl

<Gudge> 2. Constrain in SOAP binding, open in core/wsdl

option 3: open everywhere

<Gudge> 4. constrain in WSDL, open in core/soap

option 4: constrain in wsdl binding, open in core and soap.

option 1: 13 votes

option 2: 0 votes

option 3: skipped

option 4: 5

Chair: would anyone object to closing issue with no action (accept the status quo)?

marc: it seems like we're limiting ourselves.

glen: I'd rather have a clear first spec, and then later on we can amend it for new scenarios in version 2, or allow other specs to add new headers.

marc: I'm surprised that people are comfortable with the wsdl binding that allows extensions (e.g. wsa:from optional) and doesn't say how it works, but they're not comfortable with this.

RESOLUTION: issue i009 closed with the status quo.

meeting adjourned.

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.107 (CVS log)
$Date: 2005/07/21 18:30:04 $