Web Services Addressing WG F2F -- 17 Jan 2005

Minutes Approval

No objection to accepting the minutes of the 2005-01-10 meeting

RESOLUTION: minutes of the 2005-01-10 distributed meeting are approved

Schedule, Deliverables Review

Draft spec review:

1. Introduction

Core

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

SOAP Binding

Section 2: Binding EPRs

Section 3 - Faults

WSDL Binding

1. Introduction

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

Review of WS-Choreography specification

http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0059.html

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.

Issue 41 - Use cases for testing

Harris' e-mail is at

http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0039.html

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

<hugo> http://131.107.153.195/wsa/doc/WSE_Addressing_Scenarios.doc

Issue 040

Issue 035

we previously decided to extend the solution for issue 34 to cover faults aswell

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.

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

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

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

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

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

Issue: Default Actions and URNs

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

<scribe> ACTION: Editors to add IRI boilerplate a la SOAP/MTOM to relevant specs

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.

Issue 025

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

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.

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

i038 Message addressing properties

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?

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.

Paco: Concluded in Redmond that it's clear what the scope when you're using WSDL, but there might be other cases.

i006: Message property optionality.

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.

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.

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.

Glen: Responsability of the gateway to make sure the continued message has what it needs.

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.

Tony: Easy to misspell the URI too, defaulting removes potential errors.
... Why not allow omission, or an empty element (both types of optimization)

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.

Glen: Many cases where you don't need to say where the response is going - it's implied by the transport.

Glen: For those constrained scenarios it's nice not to have to process something that might not vary.

Chair: We'll try to close this next week unless somebody finds a need to lie in the road.

i017: Purpose of the action property.

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:

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.

Anish: WSDL 2.0 is per operation-direction (e.g. only ins for in-out operations)

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

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.

i021: WSDL extension for addressing.

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.

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.

Marc: You could specify the source, or reply endpoint, for an output message. The service can fix those since it creates them.

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?

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

Hugo: Relationship between <wsa:engaged/> and the unique action marker? Thinks they are the same.

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.

i022: relationship to the SOAP binding framework

Mark: Had a discussion before holidays. We need to think more about the use cases & requirements. i041 spun off.
... Any new info?

Anish: How does this work in WSDL 2.0 today? How do people map a WSDL in-only MEP to SOAP?

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

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

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

<scribe> ACTION: DaveO to develop his proposal with example messages for HTTP binding and one-way SOAP MEP.

Issue 007

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

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.

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

Tony: Most likely processor is something like a load-balancer. Target to load-balancer, and rewrite.

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.

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.

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.

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?

Glen: Perhaps an EPR should have a property that targets the headers at a particular role.

Web Services Addressing WG F2F (Melbourne, Australia)

17 Jan 2005

Attendees