See also: IRC log, IRC log
No objection to accepting the minutes of the 2005-01-10 meeting
RESOLUTION: minutes of the 2005-01-10 distributed meeting are approved
Draft spec review:
Glen: Generally pretty good but given the level of discussion we've had, it probably needs amending to include some of that discussion
2. Endpoint References
2.1 - Abstract properties
2.2 Serialization into Infoset
Chair: Has this changed much?
Editors: Only to reflect closed issues
Yin-Leng: Could do with a succint definition of EPR
Glen: Could do with a definition of how extensibility works. We allow extra elements at the Infoset level but there is no definition of extensibility at the abstract property level
Yin-Leng: All the examples have a mismatched end-tag
2.3 EPR Comparison
<Marsh> Marc: Do we need to specify how to compare properties?
<Marsh> ... Esp. Ref props and params? C14N?
Marc: Do we need to be more specific about how to compare EPRs (e.g. C14N )
<scribe> ACTION: MarcH to raise an issue re: C14N of EPRs
2.4 EPR Lifecycle
3. Message addressing properties
3.1 Infoset Rep of Message Addressing Properties
3.2 Formulating a Reply Messages
Hugo: Text says it defines rules but there are no rules, just an example.
Editors: We should define the rules
<scribe> ACTION: Hugo to raise an issue about lack of rules in section 3.2
Section 2: Binding EPRs
Section 3 - Faults
2. Endpoint References
3. Associating Action with WSDL operations
Yin-Leng: Need to change from port type to a generic term or point out that where we say port type we mean WSDL 1.1
Marc: We should define the wsa:Action attribute (just an example right now)
<scribe> ACTION: Editors to add a definition of wsa:Action to Section 3.1
<scribe> ACTION: Editors to amend reference to WSDL 2.4.5 to read WSDL 1.1 Section 2.4.5 in Section 3.
Paco: Might want to be more explicit about where we talk about WSDL 1.1 and where we talk about WSDL 2.0
Section 4.1: WSDL 1.1 MEPs
Some discussion of whether this stuff really relates to WSDL or whether it's part of the core.
Editors: Really just used WSDL MEPs as the basis for building the property tables. WSDL not actually required.
Anish: Do these tables correlate the destination of the response with the source in the request
Gudge: No because the WSDL 2.0 spec doesn't define what 'same node' means
Section 4.2: WSDL 2.0 MEPs
Anish: Doesn't robust in-only use the message triggers fault model in WSDL 2.0
Gudge: We had language that constrained source/fault/replyto values based on 'fault must go back to requestor' in WSDL 2.0.
Jonathan: Should we put this on the agenda for the joint meeting?
Chair: I think this is issue 21
<scribe> Chair: Postpone schedule review until after we've discussed other issues
<scribe> Chair: Logistics. We'll go to lunch at noon.
<scribe> Chair: Go to break now
<scribe> Chair: Review of Choreography last call after the break (20 minutes)
Restarting after break
Yin-Leng: Overall no real direct impact between WS-CDL and WS-Addressing because WS-CDL defines very abstract choreography across businesses
... The two main concepts that might impact WS-Addressing are channels and interactions
... But because the spec defines a contract there is no direct impact on WS-Addressing
... Channel is a point of collaboration between parties. Interaction talks about information that is exchange between parties
... Second comment; they use abstractions to avoid specifics
... Insulates them from datatypes (e.g. in XML Schema )
... Also abstracts them from WSDL messages
Yin-Leng; There may need to be some mapping between the abstract concepts in WS-CDL to the constructs in WS-Addressing
Yin-Leng: Should the mapping be standardized? If yes, which WG should do the work?
Jeff: This seems fairly simple. WS-CDL can use WS-Addressing.
... Other specs that want to use WS-Addressing should just be able to use it however they like.
... Within the constraints of the WS-Addressing spec
Marc: Do the WS-CDL WG know they are a user of WS-Addressing?
Jeff/Yin-Leng: Yes they do.
Yin-Leng: Our comments back to them may be that they should do a binding
Gudge: Agree with Jeff, specs that use WS-Addressing should define the binding ( rather than our WG doing it )
Yin-Leng: Main impact for us is whether we want to provide guidance on how to write a binding to WS-Addressing
... They need to update their reference to our spec ( currently references an old version )
... They will review and comment on our spec.
<scribe> ACTION: Yin-Leng to draft an e-mail response to WS-CDL WG. To be reviewed 2005-01-24 latest.
Harris' e-mail is at
Chair: This is fairly general. Need to specify all sorts of things (WSDL MEP is use, relationship to other specs etc )
Anish: Might be better to have a structure that test submitters can easily fill in.
... Do we expect people outside this group to submit test cases? If so, I think Hugo has a template for submission that deals with copyright issues
Hugo: I did investigate copyright for test cases for the WS-Desc WG. I can't remember exact conclusion but I do remember sending e-mail about IP and test cases
<Zakim> hugo, you wanted to mention copyright
<scribe> ACTION: Hugo to find his e-mail to WS-Desc on IP and test cases and forward to WS-Addr
Chair: Does anyone want to send out e-mail detailing what a test-case would cover
<scribe> ACTION: Anish to help Harris on issue 41 by preparing a more specific template that people can use to submit test cases.
Chair: Once that's done I'd like some people to generate an initial set of (probably simple) test cases.
Greg: Do all implementations have to pass all test cases?
Chair: Test cases will be used to help us drive the design of the spec.
... The test cases will then be used in CR to determine exit criteria
ACTION 7 = Anish to help Harris on issue 41 by preparing a more specific template that people can use to submit test cases. Due 2005-01-21.
<Zakim> hugo, you wanted to ask about the link to interop tests
Hugo: Dims has sent a URL pointing to a document that has interop scenarios we might be able to harvest
Arun is working on this. Postponed to later con-call.
Hugo will forward Arun's e-mail to the list
Fixed action URI for faults
we previously decided to extend the solution for issue 34 to cover faults aswell
Jonathn walks through his proposal
Jonathan: For WSDL 1.1 I tried to extend what we have for 'normal' messages to cover faults
... It's fairly straightforward. Faults have a name attribute. Might be some edge cases if 'Fault' appears in the operation name itself.
... For WSDL 2.0 it's a little harder. Faults have changed between WSDL 1.1 and 2.0
... We need to decide which level we want to indicate the faults at.
... Can point to types of fault and/or specific faults.
... Both seem useful.
Marc: How does it relate to input/output messages
Glen: It's a type/instance relationship
Jonathan: For faults maybe the default action should use the fault type ( rather than the fault instance )
... Proposal describes actions for both kinds of fault reference
... But it gets very nasty syntactically when refering to specific faults ( rather than fault types ) because fault names are QNames
... The heart of the issue is not what the exact syntax is but whether we want the *default* value to vary per fault.
... Not clear where to draw the 80/20 line
Marc: So don't define any defaults?
Jonathan: NO, we should define a default that meets the 80/20 case. But if non of the solutions meet 80/20 then we should shy away from last solution due to ugly syntax
Greg: Do you need to include the namespace in the last case?
Marc: Could define multiple faults with the same local name but different namespaces
Greg: Seems like a pretty rare case.
... Could omit the escaped namespace if it's the same as the targetnamespace
Paco: Solution doesn't follow the same pattern as WSDL 1.1
... Highlights that faults are handled differently in WSDL 2.0
Chair: Where are we leaning?
Marc: Seems like the type based one is cleanest for WSDL 2.0
Jonathan: Should we accept the [target namespace]/[interface name]/[fault name]Fault proposal for WSDL 2.0
Chair: Proposal on the table is to accept WSDL 1.1 proposal as is and accept the [target namespace]/[interface name]/[fault name]Fault proposal for WSDL 2.0
Scribe; We seem to now be arguing about where the 80/20 cut is
Gudge: My 80 is to have a fixed default for faults.
Chair: Two options are a) leave as-is with fixed *default* action for faults
b) use the proposal from jonathan and accept WSDL 1.1 proposal as is and accept the [target namespace]/[interface name]/[fault name]Fault proposal for WSDL 2.0
<hugo> +1 for b
<mlpeel> +1 for b
majority prefer b
<Marsh> (8 for b, 3 for a)
No objection to accepting b) as resolution for issue 35
RESOLUTION: Issue 35 is so closed
<mlpeel> How closed is it?
It's so closed, you won't believe how closed it is ;-)
Chair: Jonathan raised another issue which is that you can't use / as a delimiter in urns
Jonathan: Some people use URNs for targetNamespace. Default algorithm would result in an illegal URN.
Jonathan: We could just note it in the spec and tell people they have to provide explicit action values if they have URN based targetNamespace
... Or we could re-do the algorithm using a delimiter other than / that works in both URLs and URNs
... Or we could define two algorithms, one for URL based targetNamespace and one for URN based targetNamespace
Chair: How far do we go? mailto has similar problems...
Jonathan: But hopefully we wouldn't get mailto in a targetNamespace
Chair: Do we want to include URNs in our default action algorithm.
Yin-Leng: Do we need to consider IRIs
<scribe> ACTION: Editors to add IRI boilerplate a la SOAP/MTOM to relevant specs
Not much interest in option a) (Just say it doesn't work for URNs)
People generally in favour of Jonathan's proposal c) (Adjust default algorithm to work differently for URLs/URNs)
Still need to add a note that if you have a URI outside of heirarchical/URNs then you must specify explicit action values
<scribe> ACTION: Jonathan to make a proposal based around option c). Due 2005-01-23.
Greg: What is the action for the faults defined in Section 3?
Jonathan: I'll include that in my proposal.
When actions collide
Gudge: I've not started discussion of this but in the research I have done I've not noticed any cases where two (or more ) actions are needed
Some discussion of protocols/actions/specs
Chair: Two directions. Clarify that there is exactly one action and that protocol designers need to take this into account. Or allow multiple actions and deal with complexity thereof.
General feeling seems to lean towards former
<scribe> ACTION: Gudge to make a concrete proposal around clarifying there is exactly one action and protocol designers need to deal with that.
ACTION 11 = Gudge to make a concrete proposal around clarifying there is exactly one action and protocol designers need to deal with that. Due 2005-01-18, noon.
We are in recess for lunch. Resume at 12:50 sharp.
<Marsh> Scribe: Marsh
Marc: State of affairs: two parts, Marc to incorporate changes into the doc (done)
... Paco to come up with some language to indicate the scope isn't constrained.
... we've been reviewing the text. Any comments?
[uri to Paco's part of the proposal]
Paco: Purpose is to state that the contract under which the exchange happens defines the scope.
... Might be WSDL, might be something else.
... I added some sentences to the core doc (see proposal).
... These should capture what we talked about last time.
Chair: So WS-A has a different concept of request-response than SOAP, WSDL, whatever.
Paco: Not really, the spec is trying to recognize all the situations where a request might be returned.
Anish: How does this relate to i038? WS-A doesn't define the scope?
Paco: Concluded in Redmond that it's clear what the scope when you're using WSDL, but there might be other cases.
Gudge: WSDL might define a scope, but it's not necessaritly the limiting scope.
Mark: People seem comfortable.
Marc: My part is already in the draft.
Chair: Anyone object to closing the issues by accepting the proposals?
RESOLUTION: i038 closed with accepting the proposals.
Editors still need to incorporate Paco's words.
Chair: State of affairs: parts ii and iii have been withdrawn.
... Part i remains: omission of <wsa:To> is semantically equivalent to inclusion with the anonymous value.
Anish: What does it mean if the intermediary removes <wsa:To>. Default to anonymous?
Marc: Yes, but there's another issue on the processing model which might cover that.
Mark: It's hard to infer mustUnderstand="true" by default in the SOAP processing model.
Glen: Better way to formulate the desire. Instead of saying it's as if the fictitious header exists, say that the property gets the value.
Gudge: Is there an issue with signing something that isn't there>?
Glen: Message integrity is a separate set of issues.
Straw poll on accepting the proposal:
Good idea: 5
Bad idea: 4
Chair: 3 way split, where do we go?
Glen: WSDL says here's the endpoint, it's my business to know who I am. Not really much need for a separate To address.
... would mostly be anonymous.
Paco: Like having a deterministic shape of the message.
Steve: It is nice to see the presence of this kind of information in the message so you can infer the MEP.
... You can draw some conclusions by the presence of anonymous.
Paul: Message might go through HTTP, and then continue beyond that realm.
Glen: Responsability of the gateway to make sure the continued message has what it needs.
Paul: No, you don't want to present the back end to the client.
Glen: When is it OK for the front end to close the socket?
Paul: I'm trying to see the problem we're trying to solve here.
Glen: Some stuff involves the context around the transport. Can't just take the XML and drop it in a pipe.
Gudge: Optimization is so tiny. Minimal soap message is 25% savings. Any real case will be less.
... significantly less, I'd guess single digits or a fraction.
Glen: What's the harm?
Paul: Processing gets more complicated, to infer the default.
Glen: Minimal devices might be looking at ways to save any single thing.
Marc: Optimizing an incredibly common case, SOAP over HTTP.
Tony: Easy to misspell the URI too, defaulting removes potential errors.
... Why not allow omission, or an empty element (both types of optimization)
Gudge: Empty string allowed?
Marc: By anyUri at least.
Glen: What are the benefits of being explicit?
Steve: If people are trying to draw conclusions from the presence of <wsa:To>, we need to describe that.
Glen: We are in the defaulting proposal by defining what omission is equivalent.
Chair: Can I tell ws-a is in use by looking for <wsa:To>?
Gudge: Can't write a nice filter (e.g. XPath) if it's missing.
Jon: Action is always present.
Paul: Wondering about anonymous semantics on the back channel.
Gudge: Defined by the binding (SOAP -> use response channel)
Glen: Many cases where you don't need to say where the response is going - it's implied by the transport.
Mark: Anybody changing their position?
Greg goes from undecided to against.
Tony: Blank might mean something different than anonymous.
Gudge: Then we'd define a new URI.
Mark: Let's do the straw poll again.
Good idea: 8
<Gudge> hugo, use IRC
Good idea: 10
Bad idea: 5
Undecided/don't care: 1
Chair: Omission vs. allowing an empty value?
Glen: Could do both value and omitting.
Gudge: Empty value is gross when defaulting values from a schema.
Marc: What about xml:base and an empty URI?
Chair: People are shying away from omission of the value.
Glen: For those constrained scenarios it's nice not to have to process something that might not vary.
Chair: Anyone going to lie down in the road?
<scribe> ACTION: Marc to revise proposal. by end of week.
Chair: We'll try to close this next week unless somebody finds a need to lie in the road.
Anish: Two subissues.
... First is whether we need wsa:Action. That's been resolved.
... Second is what is the relation to the Operation Name requirement.
... If the Action is required to be distinct, WS-A will satisfy Operation Name requirement.
... I sent two options:
a) make it required to be distinct.
b) add an extension to indicate when it's satisfied.
Anish: I asked for examples of when @wsa:action would not be distinct within a WSDL.
... Chris Ferris gave WS-RM as an example, where the actions are specified as non-distinct.
... Not clear how that relates to WSDL.
Paco: Operation Name Mapping requirement allows you to identify at the operation level.
Glen: We've been talking about making it a Message Mapping requirement.
Anish: WSDL 2.0 is per operation-direction (e.g. only ins for in-out operations)
Mark: Does anybody think it should be required to be distinct?
Marsh: By inspection you can see that action values are distinct.
Anish: Advantage of the marker is a clear assertion that this is the way operations are distinguished.
Marsh: Minimal thing we'd need to do is say, when <wsa:marker wsdl:required="true"/>, and actions are unique (and they are by default), the Operation Name Mapping requirement is satisfied.
Anish: We should define a marker saying this is the case. (walks though his proposal)
Glen: Probably want to put it in your service, not the interface.
... ref Tim E's mail.
[Discussion about whether WSDL requires a marker of possible ways to dispatch, or t
scribe: "the" way to dispatch.
Chair: Summary: Action is not required to be distinct. Rest of the issue pushed on the stack until WSDL worries the bone a bit more.
Hugo walks us through his proposal.
Hugo: Talked a lot about syntax at last FTF. We need to talk more about what features we need to describe.
... Anish and I took the message properties and tried to decide which should be described, and at what level.
... [destination] is identical to the address of the endpoint.
... [action] same @wsoap:action property, which is going on interface/operation. There's an issue with the granularity.
... [relationship] would be nice to annotate in the WSDL.
... [refProps] is a property of an endpoint, but there is a relationship to issue 20 here.
... [refParams] appear to be message specific.
... Scoping rules would need to be defined.
Anish: We might want to indicate that a WS-A-supporting service might not use the WSDL MEP mapping. Indicate separately that WS-A support and WS-A support of the WSDL MEP mappings.
Paco: our current mappings derive directly into the core.
Anish: Is that true of WSDL 2.0?
Marc: If I have an out-in MEP, doesn't that allow me to know what the source, reply, or fault endpoint is?
... You can potentially infer the source from the WSDL.
Anish: Are you assuming soap:address is the same as [destination]?
Marc: You could specify the source, or reply endpoint, for an output message. The service can fix those since it creates them.
Anish: So [messageID] is the only one that's truly runtime only?
Chair: What about inheritance mechanism?
Anish: Not really closed on that. I was thinking refP's could be specified at the interface level, plus more at the service level.
... Hugo thought somewhat differently.
Hugo: Was thinking it more like features and properties. A property may be changed by a more specific declarations.
... Is the nature of properties a bag we throw things in? Or do we want to override or replace them?
Paco: What's the use case for putting a refP in WSDL?
... These are like an EPR that everyone can start with, which may evolve.
... These are mostly dynamic, why would we do this? Just for the initial interaction?
<Zakim> hugo, you wanted to talk about why to put RefP's in WSDL
Hugo: The use case is when you require your client to send a set of headers, you need to put it in the WSDL.
... The underlying question is what is the difference between a refParam and a refProp.
... What's the difference between this and the AD feature?
Glen: AD allows you to put in headers. They are annotated with an attribute. Discourage people from using this for infrastructure-level stuff.
... Both of these are ways to put in headers.
Marsh: Other difference is that an app must understand the namespace of the AD header. WS-A is opaque.
Hugo: If they are needed to interact with an endpoint, they should be in the WSDL. It would be nice to be able to say that the WSDL AD headers are really WS-A refp's.
<Gudge> I could imagine putting an EPR inside a wsdl:port
Paco: Slightly difference to put in fixed headers than AD provides.
<Gudge> either instead of or in additon to a soap:address element ( probably instead of )
Paco: Two parts to refP's: they cause headers to be put in. You can infer and EPR from the WSDL.
... You could make the port and an EPR much closer.
Glen: Some interesting stuff there.
... One tricky issue: why do we need two syntaxes? If refP's are easily used as WSDL extensions, how does that relate to the meaning of refP's in WS-A?
Anish: [relationship]: You may want to relationship QName, but not the message id.
... Schema doesn't solve all your problems for headers, it's hard to fix complex types.
Paco: In the simplest case, we need to say WS-A is in use, static properties map to dynamic. Next level is some fine-grained control.
Mark: What are the semantics of the <wsa:engaged/> extension? Where can it go.
Paco: We already know some things will map.
Chair: Like to get some volunteers for fleshing out the <wsa:engaged/> part.
Hugo: Relationship between <wsa:engaged/> and the unique action marker? Thinks they are the same.
Marsh: Me too, but we need to thrash that issue more in WSDL.
Mark: Wants a volunteer to write the <wsa:engaged/> proposal more thoroughly.
... including where it can appear, what it means at different places.
... then we can see how complex it will be to add more knobs.
<scribe> ACTION: Paco to create concrete proposal for a <wsa:engaged/> marker.
--- break ---
Mark: Had a discussion before holidays. We need to think more about the use cases & requirements. i041 spun off.
... Any new info?
Greg's mail is at http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0072.html
DaveO goes through his presentation
relationship between MEPs, bindings and addresses
Anish: How does this work in WSDL 2.0 today? How do people map a WSDL in-only MEP to SOAP?
DaveO: I think they hack it.
<hugo> +1 for Gudge's comment
Some discussion of the various ways of doing 'async request-response'
DaveO: I prefer the v3 version
Gudge: Me too
Anish: We could use a WSDL in-out, a SOAP 1.2 Request/Response MEP and a new binding
... We don't need a new SOAP 1.2 MEP
Some discussion of whether it's runtime or design time ( without or with WSDL)
Marc: But WSDL describes B's POV
... So what has the address of A got to do with it?
Jeff: Is this like saying we'll bind WSDL in-out into several different interaction patterns
Tony: WSDL in-out is defined as the case where the 'out' message goes back to the whoever sent the 'in' message
Anish: Seems like whatever we decide, we need to define a new SOAP HTTP binding
... Next step is to decide how we describe it
Paul: What's the difference between a MEP and a binding
Paul: We are chartered with not producing any MEPs
Chair: We can't define new WSDL MEPs
... But can define new SOAP MEPs
Paul: We want to address a common use-case. It should jus drop out of WSDL easily, and it doesn't which points out a problem in WSDL
Tony: Depends on whether you're making the async visible at the WSDL level. If you make WSDL sync but the underlying protocol(s) is/are async
Chair: We will talk about the interaction between WSDL/SOAP bindings in our joint meeting
Tony: WSDL should provide machinery for doing async processing
Jeff: Some people only care about SOAP. Other people care about WSDL too.
... Charter language is arbitrary. Can't close our eyes and say that WSDL is not important
Chair: Discussion is currently about how to use WS-Addressing with SOAP bindings.
Anish: Without creating new WSDL MEPs we can still describe these interaction patterns
... And we can represent them in WSDL
Jeff: I think the mistake is allowing you to do WSDL in-out in a whole load of different ways
Anish: It's not just WSDL 2.0 we need to care about. We also need to deal with SOAP 1.1 and WSDL 1.1
Paco: Not sure I agree with Jeff about the async binding of in-out. But I do agree that the WSDL part is a crucial part of the discussion
... The notion that we can figure out the SOAP MEPs and not worry about the WSDL isjust wrong
Greg: Figure out the HTTP messages. Then do the SOAP binding, then the MEP, then the WSDL
Marc: What are the WS-Desc WG going to do WRT exiting CR and testing the one-way MEPs
DaveO: I could write up some sample messages...
Greg: Yes please!
Glen: Can we have the joint meeting from noon to 5pm
<scribe> ACTION: DaveO to develop his proposal with example messages for HTTP binding and one-way SOAP MEP.
Glen: I'd be happy to help
Processing model for headers
Marc's proposal is at http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0047.html
Marc: I've laid out the 7 SOAP headers
... We don't define a processing model for those headers
... We should define the processing model for each header
Glen: Not sure I agree about reinsertion
... I can see a use case where I target the wsa: headers to an intermediary...
Gudge: The proposal says that wsa headers should be targeted at next? Not particularly happy with that.
... If they're targetted at next they should be reinserted.
... Not always true they're targeted at next.
Marc: If it's about addressing, it's about routing a message from here to there.
Gudge: We through out ws-routing - impossible to secure.
Marc: Just say where it's going, not how to get there.
Gudge: 95% case is ultimate receiver. Sometimes though I might want to target it to an intermediary, which changes it and then sends to ultimate dest.
Marc: Changing wsa:To is a desirable/allowable thing?
Glen: Gateway to my company...
Marc: not an intermediary...
TomRutt: If wsa:To is targetted to role="foo"?
Gudge: We could define a rule that says you must reinsert. Don't think that
... 's workable.
Paco: Per the spec, these are targetted to ultimate destination. I interpreted Marc's mail as agreeing with that but didn't want to disallow intermediary processing anyway.
... I'm Ok with that, within the bounds of the current spec.
Glen: Not sure it does allow that - more flexible to remain silent.
... We can say in the general case they go to ultimate destination. Can imagine doing something like WS-Routing with WS-A headers.
... When the notary intermediary processes this message to the "gold" level and then send it on to the ultimate destination with additional headers.
... Aside from having multiple WSA headers...
Marc: Dave was saying that - a message would be targeted to an intermediary to do some routing.
... Don't see how you get multiple wsa:To's in there.
Glen: Notary Intermediary is a client choice.
Marc: So I bind two EPRs?
Mark: Allow multiple EPRs in the properties in the abstract level.
Marc: We define the binding in terms of generating headers from an EPR.
Gudge: Just a way to describe it.
Marc: We don't talk about generating the headers any other way. Hence we need a processing model.
Anish: Because the client doesn't know which intermediaries are in between, unless we say how to target to them, the intermediaries must be non-active.
... Non-active intermediaries can't look at them.
Marc: My motivation is to use the SOAP processing model. If we say all intermediaries are active, we're done.
Anish: Active intermediaries mean we don't have to say anything.
Gudge: We need to say whether it's OK to target wsa:* headers to another role.
Marc: If WS-A intermediaries are active, we don't need to say anything.
Gudge: It's a case of who can remove it.
Anish: We can't define rules for active intermediareis. They can do whatever they want.
Gudge: One should be allowed to target at an intermediary.
... If you don't understand it, you should keep it in place. If you do, do whatever you do.
Paco: Without adding target="next' you change the semantics.
Glen: What is the semantics when somebody processes the header?
Marc: Soap says remove it.
Gudge: Cases where reinsert makes sense, cases where remove makes sense.
Tony: Most likely processor is something like a load-balancer. Target to load-balancer, and rewrite.
Marc: I have a security gateway, I want some processing to happen.
Tony: The "to" is these intermediate machines.
Marc: No, the ultimate destination.
Paco: Tony's example: target the load balancer, behind the scenes is opaque.
Chair: The options seem to be: a) minimally, b) complete, c)
... minimal: informational on processing model, leave to generic SOAP semantics.
... complete: This is how you target, this is what you do...
Gudge: Not sure anyone is saying we shouldn't say anything. We need at least to populate the properties once you recieve it. It's the forwarding etc. I'd say leave it to SOAP.
<hugo> +1 to Gudge who just said what I wanted to say
Marc: If you process the message (therefore it's targeted at me), you take it out.
Paco: Leave it to the client to insert actors and so forth as it wishes. Looks like the client can change it's contract.
... Eventually the server doesn't get what it expects.
Glen: Oh, yes, the properties you get from an EPR might not reach the server.
Tom: The concern is that everything in an EPR needs to get to the server. However, the EPR designer could put in a property that was targeted.
Bob: Minimalist approach: define what this is, not what architectures it can be used for. Let folks surprise us with their creativity.
Chair: option b: define a more constrained approach.
Glen: Not the right options.
Gudge: Minimalist option (might not be desirable) say "ultimate reciever" and be done.
Glen: When you have an EPR, you must make sure the properties in the EPR are delivered to the node that the EPR represents.
Mark: But that's separate from the SOAP processing model.
... like you to see whether that's met by the current spec.
Glen: Beyond that we need to decide whether role works. Can the client change the role, minter set the role?
Marc: Spec doesn't say what the role should be at all.
Glen: Perhaps an EPR should have a property that targets the headers at a particular role.
<Gudge> ACTION: Glen to develop the discussion of issue 7
Tomorrow 8:30 to 4:30.
Recess for the day...