IRC log of ws-addr on 2006-10-09

Timestamps are in UTC.

19:53:10 [RRSAgent]
RRSAgent has joined #ws-addr
19:53:10 [RRSAgent]
logging to
19:53:33 [bob]
zakim, this will be ws_addrwg
19:53:33 [Zakim]
ok, bob; I see WS_AddrWG()4:00PM scheduled to start in 7 minutes
19:53:53 [bob]
meeting: WS-Addressing WG Teleconference
19:53:59 [bob]
chair: Bob Freund
19:54:15 [TRutt_]
TRutt_ has joined #ws-addr
19:56:36 [bob]
19:57:06 [bob]
regrets+ paco
19:57:39 [bob]
regrets+ pauld
19:58:00 [Zakim]
WS_AddrWG()4:00PM has now started
19:58:06 [bob]
regrets+ anish
19:58:08 [Zakim]
19:58:45 [Zakim]
19:59:11 [Zakim]
19:59:21 [prasad]
prasad has joined #ws-Addr
19:59:26 [MrGoodner]
MrGoodner has joined #ws-addr
19:59:40 [gpilz]
gpilz has joined #ws-addr
19:59:42 [Zakim]
19:59:53 [TonyR]
zakim, ??p3 is me
19:59:53 [Zakim]
+TonyR; got it
20:00:35 [Zakim]
20:01:12 [Zakim]
20:01:42 [bob]
scribe: Tom Rutt
20:01:52 [MrGoodner]
zakim, ??P5 is me
20:01:52 [Zakim]
+MrGoodner; got it
20:02:05 [bob]
scribenick: TRutt_
20:02:26 [Zakim]
20:02:50 [Zakim]
20:03:00 [Zakim]
20:03:09 [yinleng]
yinleng has joined #ws-addr
20:03:24 [Katy]
Katy has joined #ws-addr
20:03:25 [dhull]
dhull has joined #ws-addr
20:03:25 [bob]
zakim IPcaller is katy
20:03:46 [bob]
zakim, IPcaller is katy
20:03:46 [Zakim]
+katy; got it
20:05:06 [Zakim]
20:05:20 [PaulKnight]
PaulKnight has joined #ws-addr
20:05:29 [yinleng]
zakim, ??p9 is me
20:05:29 [Zakim]
+yinleng; got it
20:05:56 [Zakim]
20:06:28 [TRutt_]
Topic: Roll Call
20:06:35 [TRutt_]
Tom agreed to be scribe
20:06:42 [TRutt_]
Topic Agenda Review
20:06:56 [TRutt_]
20:08:44 [TRutt_]
agreed to add discussion on "what is the problem
20:08:50 [TRutt_]
Agenda accepted.
20:09:07 [TRutt_]
Topic: minutes 10/02/06
20:09:26 [TRutt_]
Prasad: was attendance updated
20:09:35 [TRutt_]
Bob: yes it was
20:09:59 [TRutt_]
No objection, minutes are approved with Prasad on roll
20:10:05 [TRutt_]
Topic: Action Items
20:10:23 [bob]
20:11:29 [bob]
20:11:47 [bob]
20:12:52 [TRutt_]
Tony: Explained the new rules he proposed in
20:13:06 [dhull]
q+ to ask about none and "required"
20:14:10 [TRutt_]
Tony: would it be better to replace grey box text replaced with a ref to rule 5
20:14:14 [bob]
ack dhull
20:14:14 [Zakim]
dhull, you wanted to ask about none and "required"
20:14:29 [TRutt_]
all agreed to replace grey text with pointer to rule 5
20:15:33 [TRutt_]
Bob: can we give tony action item to do the next bit
20:15:42 [bob]
action: Tony do the next bit
20:15:52 [TRutt_]
ACTION: Tony to complete his proposal on cr31
20:16:48 [TRutt_]
Topic: CR33 proposal
20:17:11 [TRutt_]
Bob: due to absence of Anish and Paco, we will defer discussion of proposal 5 framework.
20:17:24 [bob]
20:17:28 [TRutt_]
Topic: What Problem we are trying to solve
20:18:00 [TRutt_]
s/Topic: Action Items/Topic: CR31/
20:18:26 [TonyR]
20:18:34 [dhull]
20:19:06 [bob]
ack dhull
20:19:08 [TRutt_]
Bob: Is there agreement on my problem statement.
20:19:42 [TRutt_]
Dave H: the main issue of cr33 is not with rm, but it is how to advertise what is understood beyond wsa:anon or wsa:none.
20:20:34 [TRutt_]
Dave H: asynch task force showed need to advertise other capabilities beyond anon.
20:20:53 [Zakim]
20:21:04 [TRutt_]
Dave H: wsrm has their own uri, and we can expect others to come up with their own magic uris which they would want to advertise.
20:23:24 [TRutt_]
Dave H: 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
20:23:41 [MrGoodner]
20:23:59 [bob]
ack mrg
20:24:52 [dhull]
sounds like a separate issue
20:25:07 [TRutt_]
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.
20:25:40 [dhull]
q+ to talk a bit about layering (then have to leave for a bit)
20:26:05 [MrGoodner]
thinks RM is the only spec that has walked through the magic door
20:26:18 [TRutt_]
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.
20:26:36 [bob]
ack dhull
20:26:36 [Zakim]
dhull, you wanted to talk a bit about layering (then have to leave for a bit)
20:27:29 [TonyR]
20:27:32 [TRutt_]
Dave H: perhaps we should raise it as a separate issue , outside cr33, if we do not want other special uris.
20:28:23 [TRutt_]
Dave H: in some layering cases, the reply to is an application layer thing. Can give this special mechanism a URI.
20:28:29 [TRutt_]
20:29:11 [bob]
ack tonyr
20:29:13 [TRutt_]
Dave H: there is a separate issue, however CR33 is still an issue.
20:29:39 [Zakim]
20:30:46 [TRutt_]
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.
20:31:04 [bob]
ack trutt
20:32:28 [bob]
20:33:07 [TRutt_]
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.
20:33:28 [gpilz]
20:33:47 [bob]
ack gpil
20:33:54 [TRutt_]
Bob: has anyone a coment on the above mail from Marc Hadley
20:36:09 [TRutt_]
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
20:36:39 [TRutt_]
Bob: does Marc H provide new kind of relationships.
20:37:02 [Katy]
20:37:16 [MrGoodner]
20:37:58 [bob]
ack katy
20:38:01 [TRutt_]
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?
20:38:39 [gpilz]
20:39:29 [TRutt_]
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 echo the Client id there could be a problem.
20:39:32 [bob]
ack mrg
20:40:46 [TRutt_]
Marc G: why does Gil see ReplyTo not troubling, but using relationship is troubling.
20:41:55 [bob]
ack gpil
20:42:03 [TRutt_]
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.
20:42:49 [TRutt_]
Gil: Or the rm layer has to correlate outgoing response to which other message.
20:43:13 [MrGoodner]
20:43:45 [TRutt_]
20:44:19 [TRutt_]
20:44:33 [TonyR]
20:44:51 [bob]
ack mrg
20:45:08 [TRutt_]
Gil: 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
20:45:39 [Katy]
Above, I meant "If the response does NOT echo the Client id there could be a problem." an important 'not' was missed :o)
20:45:57 [gpilz]
20:47:30 [TRutt_]
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.
20:47:42 [TRutt_]
20:47:59 [bob]
ack tonyr
20:48:11 [gpilz]
20:49:28 [TRutt_]
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.
20:50:14 [bob]
ack gpilz
20:51:02 [TRutt_]
Gil: correlation of request and response is not difficult, however it depends on where you are on the protocol stack.
20:51:10 [bob]
ack trutt
20:52:01 [Dug]
Dug has joined #ws-addr
20:53:51 [TRutt_]
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.
20:54:52 [TRutt_]
Bob : does the Mark Hadley email provide a viable alternative for Use by RM
20:55:26 [Zakim]
20:55:55 [bob]
zakim, ibm is dug
20:55:55 [Zakim]
+dug; got it
20:55:57 [Zakim]
20:55:58 [TRutt_]
20:56:28 [cferris]
cferris has joined #ws-addr
20:56:56 [Dug]
20:56:59 [TRutt_]
Tom: I need more time to look at Marc H proposal
20:57:10 [bob]
ack trutt
20:58:08 [cferris]
20:58:28 [bob]
ack dug
20:58:37 [cferris]
20:58:45 [TRutt_]
Tom: I think we need time to discuss other alternatives, using refParm for reliability queueID to use with makeConnection.
20:59:36 [TRutt_]
Doug D: WSRM has some non typical request response cases. These responses are brand new messages being sent out.
21:01:04 [TRutt_]
Doug D: 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
21:01:08 [TRutt_]
21:02:22 [bob]
ack trutt
21:04:41 [Dug]
21:04:51 [bob]
ack dug
21:05:04 [TRutt_]
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.
21:05:38 [TRutt_]
Doug D: Is it the belief that there should be no other special URS defined in other specs.
21:06:08 [TRutt_]
Bob F: that is a strong current wthin this WS addressing WG.
21:06:16 [MrGoodner]
21:06:25 [bob]
ack mrg
21:07:14 [TRutt_]
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"
21:07:18 [MrGoodner]
21:07:46 [TRutt_]
Doug D: I am asking if other specs hava a URI which is not "addressable" and needs extra processing to understand its use.
21:08:03 [TRutt_]
Bob: no other group has raised an issue to use about this.
21:08:27 [bob]
ack mrg
21:09:21 [Dug]
21:09:28 [TRutt_]
Doug D: non addressable uri is one which requires the user to go elsewhere to determine where to send the message to.
21:10:33 [TRutt_]
Doug D: if the uri above was used in a replyTo header, it could cause problems for some systems. That is my concern.
21:11:16 [TRutt_]
Marc G: scheme handling for urn is different than scheme handline for http. Are you assuming it is unreachable since it has a urn.
21:11:22 [bob]
21:11:39 [TRutt_]
Marc G: I would like to understand how that urn is being used in ws discovery.
21:12:30 [TRutt_]
Tony R: wsaw: anonymous does not represent backchannel.
21:13:41 [cferris]
21:14:06 [Dug]
21:14:09 [TRutt_]
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.
21:14:23 [bob]
ack cferris
21:15:23 [Dug]
21:15:54 [TRutt_]
Chris F: It does not identify a queue, it defines a backchannel. the backchannel is identified by the wsrm:anonymous URI template.
21:15:57 [TRutt_]
21:16:42 [Dug]
21:17:00 [TRutt_]
Tony R: the extra ID is a second thing that is being identified, other than use of the backchannel. You are conbining two identifiers.
21:17:35 [TRutt_]
Chris F: the extra id info is an identifier for the backchannel itself.
21:18:10 [bob]
ack trutt
21:18:27 [bob]
ack dug
21:19:24 [TRutt_]
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.
21:20:24 [TRutt_]
Doug D: what is problem with our uid.
21:20:57 [TRutt_]
Tony R: it requires special processing, beyond detecting wsa:anonyous or wsa:none.
21:21:24 [Dug]
+1 to chris
21:21:29 [Zakim]
21:21:47 [dorchard]
dorchard has joined #ws-addr
21:22:08 [TRutt_]
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.
21:23:07 [TRutt_]
Discussion on the benefits of alternative
21:23:49 [TRutt_]
21:24:53 [bob]
ack tru
21:26:21 [TRutt_]
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).
21:26:23 [bob]
21:27:05 [cferris]
21:27:13 [Dug]
21:27:23 [TRutt_]
Doug D: for now only anonymous and none http addresses require extra processing for WSA.
21:27:56 [bob]
ack bob
21:28:20 [Zakim]
21:28:23 [bob]
ack cferr
21:28:37 [cferris]
cferris has left #ws-addr
21:28:47 [TRutt_]
Bob F: composing extra information with base http address might work
21:29:28 [MrGoodner]
21:29:43 [bob]
ack dug
21:29:52 [TRutt_]
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.
21:29:57 [dhull]
21:30:03 [bob]
ack mrg
21:30:18 [bob]
ack dhull
21:31:12 [TRutt_]
Dave Hull: 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.
21:32:29 [MrGoodner]
21:32:39 [bob]
ack mrg
21:32:45 [TRutt_]
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.
21:33:59 [TRutt_]
Marc G: Doug D example of wsrm:anonURI has behaviour not defined in the wsrm specification
21:34:02 [TRutt_]
21:34:10 [bob]
ack tru
21:34:42 [TRutt_]
Tom: what about a new uri scheme.
21:35:47 [TRutt_]
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.
21:36:56 [TRutt_]
Dave Hull: we still could clarify the semantics of the wsdl:anonRequired attribugte to be more flextible.
21:37:27 [dhull]
21:37:29 [dhull]
"required":This value indicates that all response endpoint EPRs in a request message MUST always use anonymous URI as an address.
21:37:31 [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."
21:37:32 [dhull]
Seems clear enough.
21:38:00 [TRutt_]
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?
21:38:32 [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."
21:38:34 [MrGoodner]
21:38:52 [TRutt_]
Bob: we have to winnow through these for a small set of final approaches to take. I would like to add the BAseURI approach.
21:38:55 [bob]
ack mrg
21:39:15 [TRutt_]
Marc G: does taking wsa:anonymous as base uri require changing the core?
21:40:01 [TRutt_]
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.
21:40:36 [TRutt_]
Bob: another approach is to use a from field.
21:40:54 [TRutt_]
Bob: another approach for one way messages is the Marc H approach of a domain specific relationship type.
21:41:27 [TRutt_]
Bob: we also have to consider eventual use of a ws:policy assertion.
21:41:38 [Dug]
21:41:51 [TRutt_]
Bob: key question is whether it requires changes to core.
21:41:51 [Dug]
21:42:42 [TRutt_]
Bob: are we within a call, or is there specffic information we need before we make that call.
21:43:14 [TRutt_]
Bob: put on agenda for next call , a vote, do we need to change core arch or not.
21:43:44 [TRutt_]
Doug D: would you not need the exact proposal for that determiniation.
21:44:13 [TRutt_]
21:44:34 [bob]
ack tru
21:45:36 [Katy]
21:45:59 [TRutt_]
Tom: What about a w3c hosted call to have a wider discussion with invited guests from WS-RX TC.
21:46:14 [TRutt_]
Topic: Next call
21:46:30 [Dug]
Do we really think more people will help come to a decision? I have my doubts.
21:47:38 [TRutt_]
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.
21:48:09 [TRutt_]
Tom: can we bring in Observers or invited experts to that call.
21:48:57 [TRutt_]
Katy: I would prefer we try to work in this group first.
21:49:10 [bob]
ack katy
21:50:41 [TRutt_]
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.
21:51:20 [TRutt_]
Bob : I would like to winnow this down.
21:51:27 [TRutt_]
Tom: can we send this email to other groups.
21:51:42 [TRutt_]
Bob: everything on the public list is available to the public.
21:52:04 [Zakim]
21:52:08 [TRutt_]
Topic: adjourn
21:52:10 [Zakim]
21:52:11 [Zakim]
21:52:13 [Zakim]
21:52:14 [Zakim]
21:52:16 [Zakim]
21:52:16 [Zakim]
21:52:17 [Zakim]
21:52:17 [Zakim]
21:52:24 [yinleng]
yinleng has left #ws-addr
21:52:27 [bob]
rrsagent, make logs public
21:52:31 [TonyR]
TonyR has left #ws-addr
21:52:33 [TRutt_]
TRutt_ has left #ws-addr
21:52:38 [bob]
rrsagent, generate minutes
21:52:38 [RRSAgent]
I have made the request to generate bob
21:52:45 [Zakim]
22:05:00 [Zakim]
disconnecting the lone participant, Tom_Rutt, in WS_AddrWG()4:00PM
22:05:02 [Zakim]
WS_AddrWG()4:00PM has ended
22:05:05 [Zakim]
Attendees were Mark_Little, Bob_Freund, Gilbert_Pilz, TonyR, Tom_Rutt, MrGoodner, Dave_Hull, Prasad_Yendluri, katy, yinleng, Paul_Knight, dug, Chris_Ferris
22:47:18 [bob]
rrsagent, generate minutes
22:47:18 [RRSAgent]
I have made the request to generate bob
22:53:21 [bob]
bob has left #ws-addr