See also: IRC log
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
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
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
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
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
LUNCH BREAK
<plh-scribe> Scribe: plh-scribe
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
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/ ?
[yes]
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]
[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]