Web Services Addressing WG F2F

26 oct 2004

See also: IRC log


  • Anish Karmarkar, Oracle
  • Ashok Malhotra, Oracle (observer)
  • Bob Freund, Hitachi
  • Davanum Srinivas, CA (phone)
  • David Orchard, BEA Systems
  • Francisco Curbera, IBM
  • Glen Daniels, Sonic
  • Greg Truty, IBM
  • Harris Reynolds, webMethods
  • Hugo Haas, W3C
  • Jeff Mischkinsky, Oracle
  • Jiri Tejkl, Systinet
  • Jonathan Marsh, Microsoft
  • Marc Goodner, SAP
  • Marc Hadley, Sun Microsystems
  • Mark Nottingham, BEA Systems
  • Martin Gudgin, Microsoft
  • Michael Eder, Nokia
  • Paul Downey, BT
  • Philippe Le Hegaret, W3C
  • Rebecca Bergersen, IONA
  • Steve Winkler, SAP
Mark Nottingham
jeffm, anish, plh-scribe


EPRs and URIs presentation

See slides.

<jeffm> scribe: jeffm

markn: need more discussion on I1

michael: discussions seem to boil down to what is the "resource"?

markn: what can we do move forward on issue?

jmarsh: we could define an ugly mapping
... from rpp
... allows the writing of rdf

ashok: wants to think about for a while, look for other technical solutions before we talk to the TAG

paco: good to define precisely what the use case/reqs are. i.e. precise def of problem

philippe: need to list the reasons why

jeffm: raises issue around def of identity

davido: given that we have eprs, provide scenarios that demonstrate diff uses of eprs
... describes traditional tx service use case
... produce table of differences between using uri's alone, uri's + ref props, uri's + ref parms

greg: uri's are limited in length, -- rpp can be much "bigger"

markn: assumes solution is to serialize eprs, not necessarily the only solution
... suggests spending future time to frame the issue

<scribe> ACTION: davido kick off discussion of I1 -- to frame the issue

paul: perhaps we should accept that just shoving stuff onto the end of uri probably wont be doable

i002 WS-Policy dependece

philippe: while not an absolute w3c policy, we can't have a normative reference to non-stable/moving target

glen: even if it were ok to reference it, is it really the right thing to do architecturally

anish: this should be separate issue

jmarsh: could be an open-content/extenisiblity model

paco: there is a specific use of "packing in metadata" HERE, not just a generic extenisibility point
... we have specific kinds of metadata and notions of how it is to be used

markn: could we abstract some of the "policy" requirements

paul: why do we need this policy stuff at all

glen: if you have mustundertand, why do u need anything more

paco: this is about packaging information needed to use the workship

philippe: during the ccl workshop there were kind of 2 factions: short-term -- solve some specific issues
... long-term -- solve the more general "policy" problem
... inside addressing spec, do we require the "addressing processor" to support/understand a "policy package"

greg: need to ensure that whatever extensibility we define supports the "policy" use cases

anish: we are really discussing a different issue from i002

davido: doesn't think this is a separate issue: they could possibly live with removing explicit ref to ws-policy as long as the specific support for "policy metadata" requirements

markn: anish can raise a new issue later this afternoon if necessary

paco: maybe stick the metadata in the wsdl rather than the policy-element

ashok: could also use rpp for this information

marc h: diff between ref prop and param and policy-element in that rpp are meant to be opaque to the sender, where as policy is someting the sender is supposed to undertand

marc h: dont think we can get rid of the policy notion (as described above) but have to get rid of the ref to WS-Policy

paul: the distinction marc h just made is important
... am i going to chagne the message based upon the EPR?

glen: yes
... multiple buckets -- some need to be understood and processed

gudge: params are part of the addr, policy e.g. is 1st class or 2nd class

paul: how important is this to spec? can i write whatever i want or does the spec speciffy what i can put there

gudge: endpts have policy associated with them, number of ways to express: wsdl, metadata exchg, embed epr. there are some cases where embedding in epr is better/more useful.

anish: spec says embedded policies in epr may be stale, etc.

gudge: these are guidelines, but you may have other knowledge that supercedes

anish: when u use metadataxcgh, e.g. u query endpt and get policy, the policy might chg later -- this we know
... are the words in the spec similar in meaning or is there somehting more special meant?

gudge: same thing -- it takes time for eprs to be transmitted -- but things might have changed

markn: if we are not going to ref ws-policy spec, (direction), then we don't need discuss the policy spec

RESOLUTION: we will not reference the WS-Policy spec -- no objection raised

<scribe> ACTION: paco - start discussion of "policy"(lower case) requirements/use cases

<anish> ACTION: davido kick off discussion of I1 -- to frame the issue

i003 WSDL MEPs

glen: what does it meant to support a MEP

gudge: if your using this MEP, use the addr constructs like "this"
... in/out we could say: in case over http req/rsp use the anonymous uri
... is this the kind of thing we are talking about specifying?

a puzzled silence descends

marc h: gets more complicated when u get down to the protocol bindings

marc h: if i dont have any rpp and i know the response is going to come back over the same http connection: i don't need to specificy a replyto

greg: issue seems pretty grandiose, how are we going to close out? there will be lots of smaller issues for diff MEPs?

jeffm: we should decide whether we are agoing to do all the wsdl 1.1 and/or all wsdl 2.0 meps

gudge: are the 2.0 ones a superset

jmarsh: want this to work in 1.1 and 2.0, so we should do both

philippe: that was the intent

jeffm: what are we going to do with 1.1 meps which don't have bindings

<scribe> ACTION: assign i003 to gudge

<scribe> ACTION: assign i001 to davido

<scribe> ACTION: assign i002 to markn

i004 Security Model

mark n: seems to apply to MIH

anish: is this a requirement to only describe security threats

marc h: more than that, e.g. replyto SHOULD the sender, so that i can legimately refuse to replyto to an address that i know is bogus

gudge: how do u describe such a model --

markn: can see people raising specific issues for setting rpp's and other info in EPR
... this req simply means that we have to have a discussion in the spec about security related issues

jmarsh: we should be more proactive about identifying specific security issues

philippe: leave issue open until LC, and go back and see if we've statisfied it

<scribe> ACTION: assign ioo4 to gudge

<scribe> ACTION: gudge to kickoff discussion of i004

anish: did we decide if we need a security model?

gudge: no decision -- see what issues evolve

marc h: thinks we need more

bob: we need to define the security reqs before we can decide the "model" issue

i005 SOAP1.1 and WSDL 1.1 references

markn: could say non-normative, optional

jmarsh: almost a pub rule

philippe: obviously optional

jmarsh: the test suites should/must? test wsdl 1.1/soap 1.1

markn: RESOLUTION: optional, but normative. test suites will test

<anish> scribe: anish

anish: soap 1.1 is in a much better shape then wsdl 1.1, we may have to refer to BP or do something similar to BP

markn: RESOLUTION: our references to SOAP 1.1 and WSDL 1.1 will be normative and optional for implementation. Our intent is to include in the test suite.

issue 5 closed.

marc is the owner of issue 5

<scribe> ACTION: editors to include language that says that soap 1.1 wsdl 1.1 are included for backward compatibility only


<plh-scribe> Scribe: plh-scribe

location of next meeting

proposal: December 7-9, Vancouver, BC, hosted by BEA?

Mark: it will be on the west coast
... possible places: Silicon Valley, or Vancouver
... I expect to have the delay for that very soon
... we do have an australian participant in the group (from HP), and also possibility to colocate with WSDL f2f
... it will be in late January

Issues list

Mark: at this point, I'd like to gather new issues
... we will continue to gather issues tomorrow as well

Glen: two issues from yesterday minutes:

<GlenD> ISSUE: Marc: It's an issue that wsa:To must be there if it might be duplicate information....

<GlenD> ISSUE: Glen: RefP's explicitly use the SOAP processing model, and force senders to send 1st class SOAP headers they don't understand. This could cause problems - why not solve this by just having <To> be an EPR which reflects the RefPs, instead of sending RefPs as headers?

Marc: right, talking about address and transport

Mark: duplicate information the serialization in the SOAP headers and the underlying transport

Glen reads yesterday's minutes

Marc: re issues. wsa:To should be optional if the information is evident somewhere else

Paco: if it was proven to be useless, then we could make it optional

Jonathan: under what circumstances is it clearly redundant, and can we phrase that in the spec?

Marc: sending to the anonymous address for example. we could say, no address means anonymous
... could be a soap binding issue

[Mark shows a description of the issue on the screen]

Jonathan: one issue is whether is syntactic convenience for anonymous URI and this is different from duplicate information

[clarification wsa:to and wsa:action are mandatory]

Gudge: Marc is worried about mandatory elements, not headers.

Jonathan: should address be optional, and should wsa:To be required?

<scribe> ACTION: Marc to start the issue i006

<scribe> ACTION: Marc owns issue 006

Marc: did we capture the processing model issue for headers?
... the soap spec says you should do so

Glen: we should define the semantics and behaviors associated with those headers, but soap itself has a processing model.

Marc: I don't think the semantics and behaviors are clear enough

Jonathan: seems too general. How do we solve that?

<scribe> ACTION: Marc to start (and owns) issue 007

ISSUE: Glen: RefP's explicitly use the SOAP processing model, and force senders to send 1st class SOAP headers they don't understand. This could cause problems - why not solve this by just having <To> be an EPR which reflects the RefPs, instead of sending RefPs as headers?

<scribe> ACTION: Glen to start and (owns) issue 008

ACTION 12= Glen to start (and owns) issue 008

Paul: how many EPR can you put inside an addressing structure. example: multiple recipient.
... I'd like to rule that out of scope.

Mark: you want to make sure that the constraints on the numbers of EPR stays. for example, the To header only allows one EPR.

Gudge: today, you can stick multiple Reply-To headers... nothing in the spec says the contrary.

Mark: cardinality of headers?

Paul: yes

only one EPR in Reply-To, and only one Reply-To header

Paul: the charter isn't clear on how many EPRs

<scribe> ACTION: Paul to start (and to own) issue 009

Jeff: if there is an MEP that has multiple recipients, wouldn't we have to support it?

Paco: solving that issue doesn't require to have multiple EPRs

Jeff: also there is also the notion of "alternative EPRs"
... (multiple recipients vs alternative recipients)

Marc: the spec talks about point-to-point communication. we need to provide for extensibility to have multiple recipients.

Gudge: we do that already with WS-Addressing. You can only addressing to one.

Marc: in the abstract we can allow it to be open and restrict it in the binding.
... I specified several To: in my email clients everyday...

David: In general, I agree that we should not preclude use cases, but how do we know if we preclude them? this could be part of the feedback we would gather during last call. If other folks come up with scenarios, then they should say so. But I don't think we could do more than that, unless we want to resolve all problems.

Marc: doesn't take much to imagine a binding to email.

Mark: happy with having it soap specific?

Paul: I'd like to make it core

Glen: s/headers/properties/ ?


Anish: my issue is related to the structure of EPR and what's required and what's not.
... in the current spec, it allows you to construct an EPR with only a URI. To me, that's not a reference to a Web Services, it's just a URI.
... is it supposed to point to an endpoint or a service? With endpoint, you need bindings, interface, ...

Paco: mix of runtime vs metadata concept?
... I think you meant a lax of WSDL connection

Anish: didn't say that.
... if you're going to pass this EPR around, I don't know what to do with a URI.

Gudge: that's not necessarily true. if we share the context, you just need the URI.
... an example: the eventing spec. you send a message to the manager, you know exactly what you're getting back.

Anish: so there are scenarios where we don't need to have all info. what would we structure EPR around that.

Paco: to resolve the simple case with a simple way.

Glen: you want something simple for the simple case, while enabling more complex exchanges.

Anish: for the simple case, just send a URI, don't call it an EPR

Glen: in my context, it is

Anish: then would you send relative uris?

Gudge: that's a separate issue that needs to be addressed.

Anish: how robust are EPRs?

Gudge: as robust as the sender wants it to be. Do you want to require more things?

Anish: yes

Jeff: following up on Gudge. If I pass "<wsa:Address>1</wsa:Address>", would it be ok?

Gudge: I'm prefectly happy to disallow that

<scribe> ACTION: Anish to start (and to own) issue 10

Harris: re serialization of from and reply-to, are they separated messages?

Gudge: yes. so the reference properties would be inside the from?
... yes

Harris: so the reference properties would be inside the from?

Gudge: yes
... we don't use an EPR construct to serialize wsa:To

Harris: this might be an issue

Mark: this issue will relate to issue 008

<scribe> ACTION: Harris to start (and to own) issue 011

Marc: EPR lifecycle. should we provide a standard way to timeout EPRs?

David: what happen if the receiver is ahead and the reply-to behind, etc....

<scribe> ACTION: Bob to start (and to own) issue 012

Anish: related to issue 011. if the answer is no for issue 011, I'd like to raise an issue with the serialization of To. the binding and interface info are lost.
... it might be possible that the receiver would need this info to route the message.

Gudge: it's just metadata hint for the consumer of the endpoint.

Anish: it seems strange that we map Address but not the service qname and port.
... if someone hosts multiple services at the same address.

Glen: you would have this problem at the WSDL level anyway.
... you have to solve that problem, even if you don't use ws-addressing

Jonathan: you can put a reference property/parameter

Gudge: an EPR contains two types of things, things that are necessary (address, properties), things that are not (service, port).

<scribe> ACTION: Anish to start (and own) issue 013

RebeccaB: this is also related to the multiple port under a single EPR

Hugo: related to the issue about policy and lifecycle. embedded policy are not authoritative. If I had a policy and I'm being given a different new one for ane endpoint, I cannot use the new one as authoritative?
... we could say, this policy is valid for a certain amount of time

Jonathan: is it: "Is something that you get in an EPR could preempt your own knowledge?"

Jeff: freshness issue of any information you get from an EPR?

Mark: one approach is to push the requirement of defining the precedente on those who defines those information

Hugo: I'd like the issue to mention that the spec says something about policy and it might not be correct.

<scribe> ACTION: Hugo to start (and to own) 014

Paco: not only an issue of wording. should the EPR be considered fresher than your own knowledge?

Hugo: it's a timing issue. depending on when you get those info.

Jeff: if I go and query the endpoint directly, it's better than trusting the EPR

Marc: should we provide a standard redirection mechanism.
... there is no way to say: send future requests to this new EPR.

Gudge: would you "resend the message"?

David: or is it "update your EPR with those data"?

Marc: could be both
... I'd like to build this into my infrastructure instead of relaying on the application to do it

Mark: I don't see this as a priority item. could be addressed at a later stage.

David: can we do it by extending the reply-to construction?

<scribe> ACTION: Marc to start (and to own) issue 015


[break is over]

Marc: what is the relationship between SOAP headers that results from EPR and those that result from the WSDL?
... how do you know which is a ref prop and which one is not?
... this is specific to the SOAP binding

<scribe> ACTION: Glen to start (and own) 016

Anish: action MIH: why?
... as opposed to reusing the operation name.
... Since we already have something that uniquely identifies an operation, why would we need something else?
... why not always use the operation name?
... I can see a value in uniquely identifying with particular operation. I don't see the value beyon that

Mark: action is already in SOAP and WSDL

Anish: it's on the media type in SOAP

Gudge: in the trust spec, we have several bodies with similar bodies but different actions

Anish: is that providing some information beyondd the SOAP body?

Gudge: yes

<scribe> ACTION: Anish to start (and to own) issue 017

Glen: if you woud want to use mustUnderstand, you would need to know which version of SOAP is in use.
... this would make them less abstract

<scribe> ACTION: Glen to start (and to own) issue 018

Hugo: the core spec needs to be independent of the SOAP and WSDL version in use. the submission is written against SOAP 1.1./WSDL 1.1. We should make it version agnostic

<scribe> ACTION: Hugo to start (and to own) issue 019

Anish: rational for including reference properties and parameters in a base service reference.
... with ref props/parameters, you reduce the service. You are requiring to send the ref props/params.
... the EPR subsets what the WSDL allows you to send

Jonathan: that only arises if the WSDL and the EPR don't contain the same info

Anish: so why is it necessary to include ref props/params in a basic ref to a web service
... should we allow ref props in a web services reference?
... (and not outside)

Gudge: the answer would be "use an EPR with just an address field?"

Anish: a web service reference should not subset the set of messages allowed by the WSDL

Jonathan: it also happens if the metadata included in an EPR is not replicated in the WSDL

Anish: why do ref props need a specific place in EPR?

Gudge: I never expect a WSS header used as a ref prop

Anish: nothing prevents it in the spec
... for the service to consume the messages, the messages must contain those headers.
... then that should be included in the WSDL

Gudge: agreed

Anish: there is no such mechanism in WSDL

Gudge: it's missing in WSDL

Mark: mismatch between the granularity of addressing and wsdl?

Gudge: abstract addresses in WS-Addr do not map directly to the WSDL
... what do we do?

<scribe> ACTION: Anish to start (and own) issue 020

Philippe: do we need some extensions in WSDL to use Addressing?

<scribe> ACTION: hugo to start (and own) issue 021

Marc: what the precedent rule to be used with the EPR used in addressing, vs the one used in the SOAP binding?

Paul: would that include SOAP action for the SOAP binding?

Marc: possibly

Jeff: if you specify more information in the EPR, do you need to follow them?

<scribe> ACTION: Greg to start (and to own) issue 022

Rebecca: using service ref instead of EPR, ie the EPR would be defined in WSDL

(and we use the service type reference)

scribe: it still requires the idea of properties, policies, etc.
... a number of the issues that have been brought out would be resolved.

Jonathan: it's nice to have the addressing mechanism separated from wsdl

Paul: we've got a starting point. what would service type reference bring?

Rebecca: if you approach it from the point of view of wsdl syntax, you can address some of the use cases

Paul: one concern: wsdl is very extensible and could open a world of possibilities.

Anish: EPR is extensible as well

Paul: we might want to constrain it

Mark: we need to have this discussion but also we need to be careful with it and what complexity it would add
... I'd like to see a description and a comparison with the current approach

<scribe> ACTION: Rebecca to start (and to own) issue 023

Rebecca: we had some discussion of the processing model. can you use metadata by value or reference in an EPR?

Mark: we could provide a generic referencing mechanism, or some best practices

<scribe> ACTION: Rebecca to start (and to own) issue 024

Philippe: should we reuse the URI mapping of WSDL 2.0 in the action parameter?

Hugo: that's issue 19

Greg: from yesterday, what to do when action collides?

Gudge: what are the semantics of action if case of multiple?
... (currently the spec says there is only one action)

<scribe> ACTION: Gudge to start (and to own) issue 025

Mark: tomorrow, we'll have an other call for issues, then prioritarization, then we attack them


Marc: if someone is not around the table and want to contest a decision?

Mark: if new information is brought yes

Jeff: would be nice to make sure we get the agenda in time

Mark: yes, I do intend to provide it on time

Paul: regarding the end result of the spec, will it look like the current submission, or more like WSDL?

Jonathan: WSDL is dealing with description, pretty similar to xml schema
... not sure if it's worth the cost for addressing

Gudge: addressing is already written the same way as WSDL. WSDL has a lot more components

Rebecca: a lot of the issues that came up today had to deal with the binding to SOAP/WSDL. Are we going to specifically address other protocols?

Mark: we should accomodate, but we don't have a mandate to produce them
... I still don't have lots of volunteers for scribing during teleconferences
... so I might go to the usual system, ie going through the list of participants
... also still looking for test lead

Room tomorrow is 1215

[meetiong adjourned]

Summary of Action Items

[NEW] ACTION: Anish to start (and own) issue 013 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T18-31-52]
[NEW] ACTION: Anish to start (and own) issue 020 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T20-01-29]
[NEW] ACTION: Anish to start (and to own) issue 017 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T19-41-17]
[NEW] ACTION: Anish to start (and to own) issue 10 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T18-15-17]
[NEW] ACTION: assign i001 to davido [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T15-57-41]
[NEW] ACTION: assign i002 to markn [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T15-57-57]
[NEW] ACTION: assign i003 to gudge [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T15-57-25]
[NEW] ACTION: assign ioo4 to gudge [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T16-04-04]
[NEW] ACTION: Bob to start (and to own) issue 012 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T18-24-17]
[NEW] ACTION: davido kick off discussion of I1 -- to frame the issue [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T15-47-25]
[NEW] ACTION: editors to include language that says that soap 1.1 wsdl 1.1 are included for backward compatibility only [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T16-15-47]
[NEW] ACTION: Glen to start (and own) 016 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T19-33-23]
[NEW] ACTION: Glen to start (and owns) issue 008 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T17-49-07]
[NEW] ACTION: Glen to start (and to own) issue 018 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T19-44-12]
[NEW] ACTION: Greg to start (and to own) issue 022 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T20-10-29]
[NEW] ACTION: gudge to kickoff discussion of i004 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T16-04-19]
[NEW] ACTION: Gudge to start (and to own) issue 025 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T20-33-28]
[NEW] ACTION: Harris to start (and to own) issue 011 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T18-21-54]
[NEW] ACTION: hugo to start (and own) issue 021 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T20-06-20]
[NEW] ACTION: Hugo to start (and to own) 014 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T18-42-50]
[NEW] ACTION: Hugo to start (and to own) issue 019 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T19-48-06]
[NEW] ACTION: Marc owns issue 006 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T17-43-57]
[NEW] ACTION: Marc to start (and owns) issue 007 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T17-46-25]
[NEW] ACTION: Marc to start (and to own) issue 015 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T18-52-46]
[NEW] ACTION: Marc to start the issue i006 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T17-43-40]
[NEW] ACTION: paco - start discussion of "policy"(lower case) requirements/use cases [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T15-46-44]
[NEW] ACTION: Paul to start (and to own) issue 009 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T17-56-37]
[NEW] ACTION: Rebecca to start (and to own) issue 023 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T20-20-58]
[NEW] ACTION: Rebecca to start (and to own) issue 024 [recorded in http://www.w3.org/2004/10/26-ws-addr-irc#T20-25-24]

Minutes formatted by David Booth's scribe.perl 1.94 (CVS log)
$Date: 2004/11/03 08:21:44 $