See also: IRC log
Chair: today we will be mostly discussing issues 8 & 16
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
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 ..
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.