See also: IRC log
Tom agreed to be scribe
agreed to add discussion on "what is the problem
Agenda accepted.
Prasad: was attendance updated?
Bob: yes it was
No objection, minutes are approved with Prasad on roll
<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0040.html
<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0003
<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/att-0003/cr31.html
Tony: Explained the new rules he
proposed in
http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/att-0003/cr31.html
... would it be better to replace grey box text replaced with a
ref to rule 5
all agreed to replace grey text with pointer to rule 5
Bob: can we give Tony action item to do the next bit
<scribe> ACTION: Tony to complete his proposal on cr31 [recorded in http://www.w3.org/2006/10/09-ws-addr-minutes.html#action02]
Bob: due to absence of Anish and Paco, we will defer discussion of proposal 5 framework.
<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0006.html
Bob: Is there agreement on my problem statement.
DaveH: the main issue of cr33 is not with rm,
but it is how to advertise what is understood beyond wsa:anon
or wsa:none.
... asynch task force showed need to
advertise other capabilities beyond anon.
... wsrm has their own uri, and we can
expect others to come up with their own magic uris which they
would want to advertise.
... in strrict sense we are not standing
in way, but could clarify for guidance. Provide a marker that
enables talking about particular kind of endpoint. We do not
have anything that expressive now. Optional does not mean
shutting out some other kind of magic uri. We should at least
clarify what optional means here
<dhull> sounds like a separate issue
Marc G: RM took advantage of advice added by request of RM TC. Some think this was bad advice, independent on how we resolve cr33, I do not think it is a good idea to have other specs define such URIs like wsrm did.
<MrGoodner> thinks RM is the only spec that has walked through the magic door
Bob: Discussion points: How are these two endpoints interacting, what information they are exchaning for these exchanges, is there issue with mechanism within the specification.
<Zakim> dhull, you wanted to talk a bit about layering (then have to leave for a bit)
DaveH: perhaps we should raise it as a
separate issue , outside cr33, if we do not want other special
uris.
... in some layering cases, the reply to
is an application layer thing. Can give this special mechanism
a URI.
... there is a separate issue, however
CR33 is still an issue.
Tony R: Some things annoy me. The layering irritates me the most. If the back channel is used to send information back, it is a request response, it is not one way. If they do not have queued response to come back on back channel, they send a pending. They should be using anonymous in reply to and all this happens at a layer higher than addressing.
<bob> http://lists.w3.org/Archives/Public/public-ws-addressing/2006Oct/0042.html
Tom: Paul Fremantle from wsrm tc has proposed that the wsa:anonymous behaviour for replyTo applies for non failure cases, the makeConnection alternative would come in as a failure recovery mechanism based on wsrm.
Bob: has anyone a coment on the above mail from Marc Hadley
Gil: I have a problem about using generic soap headers. What Doug is trying to do with this special URI is to leverage the behavour of soap stacks to change replyTo to return address. ON server side, request comes in, pass up to applicaiton, then a response goes out, to make sure the correct replyTo is used, the wsrm layer has to know that message b is the response to message a. The RM layer never has enough knowledge to know which message is a respons
Bob: does Marc H provide new kind of relationships.
Gil: on step 4 who puts in that relationship type initial reaues, if it is higher level, then the higher level had to understand it is using RM beneith it. IF not higher level then it is rm layer, it would have to understand that the message going out on step 4 is in response to the request in step 1. How does rm layer have this informaion?
Katy: The client identifying info is passed back on response. Some stated refParms could be used. If we do not need a separate URI for RM it make things easier. If the response does not echo the Client id there could be a problem.
Marc G: why does Gil see ReplyTo not troubling, but using relationship is troubling.
Gil: Somewhere up the stack the
replyTo gets translated into the to for the response. In the to
there is already the correlator parameter. Having another
relationship implies higher layer extra processing.
... Or the rm layer has to correlate outgoing response to which
other message.
... whenever we go away from the responder copying the reply to
to construct the to for the response, we have to ask what
endity will do that extra processing
Gil: at transport layer, when sending message, you look at to address for response, if none, you put it on floor, if anon you send it on the back channel. Additional handlers could be put into place at that point.
Tony R: conjunction between incoming and outgoing message is confused. It is easy to code this. Keeping track that the message that went in, is correlated to response is not difficult. It is back channel of message that is already going in.
Gil: correlation of request and response is not difficult, however it depends on where you are on the protocol stack.
Tom: we could use wsa:anon for reply to with a refParm for a queueID which only is used by rm when it cannot directly send the response on the primary backchannel of the request. This would view the make Connection mechanism as being implemented by the wsrm layer, the queues are managed in that layer.
Bob: does the Mark Hadley email provide a viable alternative for Use by RM
Tom: I need more time to look at
Marc H proposal
... I think we need time to discuss other alternatives, using
refParm for reliability queueID to use with makeConnection.
Doug D: WSRM has some non typical request response cases. These responses are brand new messages being sent out.
... with respect to using refParms, a sending endpoing only has to look at to values, they are not for their use. If you look at refParms, it is a drastic change. Asking it to look at outgoing headers is going beyond the scope. This is changing the processing model
Tom: I am speaking of a third proposal, the reply to has wsa:anon with queueID ref Parms. This is not the same as Marc H proposal. The sender would know it is using wsrm makeconnection as reliability mechanism, and that is why it would put the queueID ref parm in its reply To> It may actually ignore the queue ID ref parms echo, if it is useing the correlation mechanism.
Doug D: Is it the belief that there should be no other special URS defined in other specs.
Bob: that is a strong current wthin this WS addressing WG.
Marc G: ws discovery URIs do not impact the transport layer, They do not impact the ws addressin behaviour in my understanding. I have found no other URIs that trigger the "back channel"
Doug D: I am asking if other specs hava a URI which is not "addressable" and needs extra processing to understand its use.
Bob: no other group has raised an issue to use about this.
<Dug> urn:schemas-xmlsoap-org:ws:2005:04:discovery
Doug D: non addressable uri is one which requires the user to go elsewhere to determine where to send the message to.
... if the uri above was used in a replyTo header, it could cause problems for some systems. That is my concern.
Marc G: scheme handling for urn is different than scheme handline for http. Are you assuming it is unreachable since it has a urn.
Marc G: I would like to understand how that urn is being used in ws discovery.
Tony R: wsaw: anonymous does not represent backchannel.
Tony R they are trying to identify back channel, and also which queue of responses in server should be used to get response back from. That is what the anonymous uri does, it puts two identifiers into one.
Chris F: It does not identify a queue, it defines a backchannel. the backchannel is identified by the wsrm:anonymous URI template.
Tony R: the extra ID is a second thing that is being identified, other than use of the backchannel. You are conbining two identifiers.
Chris F: the extra id info is an identifier for the backchannel itself.
Tom: I do not think that a backchannel id is any different than a queue id. One is from the sender view, the other is from the responser view. The responder has to treat the backchannel identified by the replyTo as a particular queue, waiting for that backichannel ID on the makeConnection poll message.
Doug D: what is problem with our uid.
Tony R: it requires special processing, beyond detecting wsa:anonyous or wsa:none.
<Dug> +1 to chris
Chris F: address could have a base address which is an http address, with the extra backchannel id info as a fragment. This could have been made to work. Using Relative URL. We could use anonmous uri as base, with the backchannel as a fragment.
Discussion on the benefits of alternative
Tom: this new proposal still requires the responder to hold back the reply for the propser message, and cannot just send it using that to address on a response sent at the wrong time (i..e, not to a make connection request).
Doug D: for now only anonymous and none http addresses require extra processing for WSA.
Bob: composing extra information with base http address might work
Doug D: you still need some other flag for the client to state is is going to use the make connection. That is why we used a special uri template. I agree with Tom that the new proposal from Chris F does not signal use of make connection.
Dave H: um um I think we need to careful in packing too much info into a uri. Virtual channels may be ok, but "send to this party using a make connection" type protocol information, this seems dodgy.
Dave Hull: If we can be careful to separate resource represented, as opposed to what mechanis is used to reach that resource, that is good.
Marc G: Doug D example of wsrm:anonURI has behaviour not defined in the wsrm specification
Tom: what about a new uri scheme.
Doug D: the overhead of registering a new uri schem for makeConnection protocl with IETF made that not acceptable. However you would still have problem with wsdL: anon required marker.
Dave Hull: we still could clarify the semantics of the wsdl:anonRequired attribugte to be more flextible.
<dhull> "#
<dhull> "required":This value indicates that all response endpoint EPRs in a request message MUST always use anonymous URI as an address.
<dhull> If a response endpoint EPR does not contain the anonymous URI as an address value, then a predefined InvalidAddressingHeader fault defined in Web Services Addressing 1.0 - SOAP Binding [WS-Addressing SOAP Binding] MUST be generated."
<dhull> Seems clear enough.
Bob: we still have question, does core and soap binding need change? Do we support the use case requested? Is the change required limited to the wsdlBinding doc?
<dhull> (none comes in through the core: "Messages sent to EPRs whose [address] is this value MUST be discarded (i.e. not sent). This URI is typically used in EPRs that designate a reply or fault endpoint (see section 3.1 Abstract Property Definitions) to indicate that no reply or fault message should be sent."
Bob: we have to winnow through these for a small set of final approaches to take. I would like to add the BAseURI approach.
Marc G: does taking wsa:anonymous as base uri require changing the core?
Bob: how much is does depends on
the exact proposal. If anonymous is changed to a base URI, it
allows a definition of wsdl Marker along lines of what wsrm
desires.
... another approach is to use a from field.
... another approach for one way messages is the Marc H
approach of a domain specific relationship type.
... we also have to consider eventual use of a ws:policy
assertion.
... key question is whether it requires changes to core.
... are we within a call, or is there specffic information we
need before we make that call.
... put on agenda for next call , a vote, do we need to change
core arch or not.
Doug D: would you not need the exact proposal for that determiniation.
Tom: What about a w3c hosted call to have a wider discussion with invited guests from WS-RX TC.
<Dug> Do we really think more people will help come to a decision? I have my doubts.
Bob: many will be travelling to WS-I plenary in bay area. Those might not be able to make this call. I propose our next ws-addressin call be schedule for 23 of October.
Tom: can we bring in Observers or invited experts to that call.
Katy: I would prefer we try to work in this group first.
Bob: I will rework the list to
include all the proposals so far, outside of changes to the
wsdl binding. I will get this out tomorrow morning.
... I would like to winnow this down.
Tom: can we send this email to other groups.
Bob: everything on the public list is available to the public.