IRC log of Ws-addr on 2006-01-20

Timestamps are in UTC.

17:01:55 [RRSAgent]
RRSAgent has joined #Ws-addr
17:01:55 [RRSAgent]
logging to http://www.w3.org/2006/01/20-Ws-addr-irc
17:01:59 [mnot]
zakim, this is ws_addr
17:01:59 [Zakim]
ok, mnot; that matches WS_AddrWG(F2F)12:00PM
17:02:08 [David_Illsley]
David_Illsley has joined #ws-addr
17:02:09 [mnot]
Meeting: Web Services Addressing F2F
17:02:14 [mnot]
Chair: Mark Nottingham
17:02:19 [mnot]
zakim, who is here?
17:02:19 [Zakim]
On the phone I see +1.604.642.aaaa
17:02:20 [Zakim]
On IRC I see David_Illsley, RRSAgent, Zakim, mnot, anish, yinleng
17:02:38 [TonyR]
TonyR has joined #ws-addr
17:03:17 [Zakim]
+Prasad_Yendluri
17:06:57 [hugo]
hugo has joined #ws-addr
17:07:12 [Zakim]
+??P5
17:07:20 [Jonathan]
Jonathan has joined #ws-addr
17:07:29 [TonyR]
zakim, ??p5 is me
17:07:29 [Zakim]
+TonyR; got it
17:07:56 [bob]
bob has joined #ws-addr
17:09:10 [uyalcina]
uyalcina has joined #ws-addr
17:10:00 [pauld]
pauld has joined #ws-addr
17:10:26 [uyalcina]
SCRIBE: uyalcina
17:10:46 [uyalcina]
TOPIC: CR10
17:10:59 [uyalcina]
looking at proposal 6...
17:11:04 [Nilo]
Nilo has joined #ws-addr
17:11:59 [uyalcina]
Mark: what do you think?
17:12:17 [uyalcina]
... Are there objections
17:12:21 [uyalcina]
None noted
17:12:38 [Zakim]
+Paco:Francisco_Curbera
17:12:49 [uyalcina]
ACTION: Hugo to communicate our decision back to the tag on CR10
17:13:12 [uyalcina]
RESOLUTION: CR10 closed with accepting Proposal 6
17:13:17 [Paco]
Paco has joined #ws-addr
17:13:18 [uyalcina]
TOPIC: CR13
17:13:43 [Paco]
Paco has joined #ws-addr
17:14:21 [Zakim]
-Prasad_Yendluri
17:15:38 [uyalcina]
Mark: Are these optional faults?
17:18:01 [TRutt]
TRutt has joined #ws-addr
17:20:38 [Zakim]
+Prasad_Yendluri
17:21:29 [PaulKnight]
PaulKnight has joined #ws-addr
17:21:45 [uyalcina]
Jonathan: Can we check with each vendor to add them?
17:22:04 [uyalcina]
Glen: These kind of things are very handy for debugging.
17:22:22 [uyalcina]
Scribe missed some of the points because this was her cr issue...
17:22:41 [uyalcina]
Paul: We need to add test cases
17:22:45 [Paco]
Paco has joined #ws-addr
17:24:12 [uyalcina]
Jonathan: How many people are interested in implementing them?
17:25:09 [uyalcina]
DaveH: Aren't they related to WSDL only?
17:25:40 [uyalcina]
Jonathan: They are not really WSDL faults.
17:26:20 [uyalcina]
Mark: Is there enought info here to proceed.
17:26:24 [uyalcina]
Jonathan: yes
17:26:36 [uyalcina]
s/enought/enough/
17:27:06 [uyalcina]
Mark: Are there any objections to accept this?
17:27:14 [uyalcina]
None noted.
17:29:02 [bob_]
bob_ has joined #ws-addr
17:30:33 [mnot]
mnot has joined #ws-addr
17:31:30 [umit]
umit has joined #ws-addr
17:31:45 [umit]
SCRIBE: umit
17:31:58 [umit]
TOPIC: CR14
17:32:19 [umit]
DaveH presents the problem.
17:33:08 [umit]
Jonathan: This is an expediency, we should not change anything.
17:34:03 [umit]
... Are you asking to break the tie between them?
17:34:20 [umit]
Glen: SOAPAction is not an HTTP thing
17:34:53 [umit]
... The idea is to encode the metadata
17:35:48 [umit]
DaveH: SOAP Action is less important than from and to...
17:36:54 [umit]
Mark: We discussed the relationship between the underlying protocol artifacts in the past and this was the direction we wanted to take.
17:38:34 [TRutt]
TRutt has joined #ws-addr
17:38:48 [umit]
... Doing thought experiments at this stage is not a useful thing.
17:38:59 [prasad]
prasad has joined #ws-Addr
17:39:05 [Zakim]
-Prasad_Yendluri
17:39:06 [umit]
... It questions the fundamental assumptions.
17:39:09 [gpilz]
gpilz has joined #ws-addr
17:39:20 [Zakim]
+Prasad_Yendluri
17:39:26 [umit]
DaveH: You want to totally ignore this?
17:39:40 [umit]
Paul: Write a test case to illustrate the issue.
17:40:09 [umit]
Mark: You can not use the test case as a bar to get issues accepted.
17:40:28 [akarmark]
akarmark has joined #ws-addr
17:40:49 [umit]
Discussion on multi-hop test case ...
17:41:41 [umit]
DaveH presents a Jabber based test case and says how id will not match (scribe missed some of the details)
17:43:02 [PaulKnight]
PaulKnight has joined #ws-addr
17:43:45 [umit]
... in the multi hop case we may lose the ids to match...
17:45:55 [umit]
... I would like a sentence or two (in the proposal 2)...
17:46:06 [umit]
Mark: Could you do this by lunch and provide concrete text?
17:46:18 [umit]
DaveH: yes
17:48:20 [chad]
chad has joined #Ws-addr
17:49:10 [umit]
TOPIC: Umit's new issue regarding inconsistency...
17:50:21 [umit]
Mark: Proposal is to reincorporate the text as aggreed on issue i20 subissue d back into the text
17:51:04 [umit]
http://www.w3.org/2002/ws/addr/wd-issues/#i020
17:51:37 [umit]
RESOLUTION: Close to issue reincorporating the previous resolution into the text
17:51:42 [mnot]
mnot has joined #ws-addr
17:51:44 [mnot]
http://www.w3.org/mid/2BA6015847F82645A9BB31C7F9D64165E43F89@uspale20.pal.sap.corp
17:53:16 [pauld]
Jabber URI schema, fwiw: http://www.jabber.org/jeps/jep-0032.html
17:55:07 [umit]
TOPIC: New issue optional/required
17:57:00 [umit]
Umit: There are two problems.
17:58:37 [umit]
Glen/Umit: the concept of "when you need the property" is missing
17:59:23 [umit]
Jonathan: We should make it required.
18:00:50 [Nilo]
Nilo has joined #ws-addr
18:00:57 [umit]
Mark: Thisis a serialization problem, it appears in the serialization only. We do not have a problem.
18:02:53 [dhull]
dhull has joined #ws-addr
18:03:30 [akarmark]
akarmark has joined #ws-addr
18:03:53 [dhull]
Proposed text for CR14: http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2006Jan/0008.html
18:04:25 [umit]
Mark: Will we have a serialization that will never have defaults?
18:04:59 [umit]
... is the absence of optional element equivalent to none?
18:05:04 [umit]
Glen: no
18:06:10 [umit]
Mark: there are three options
18:06:18 [umit]
1. make it required
18:06:31 [umit]
2. default is none (if not present)
18:06:52 [umit]
3. define another semantic when missing
18:07:24 [umit]
Gil: None has a semantic meaning you do not want to default to it.
18:08:17 [akarmark]
+1 to paco
18:08:20 [umit]
Paco: I recally that reply to is always optional. People wanted to optimize for request-reply pattern and we had the defaulting as a result.
18:08:47 [umit]
... in a request-response pattern, you can default to anonymous. We should keep this semantic as intended.
18:08:54 [Jonathan]
Jonathan has joined #ws-addr
18:09:23 [umit]
... restrict the default to request-response...
18:10:49 [akarmark]
option 4: remove the defaulting in the core and include it in the wsdl-binding for the req-res MEP
18:12:06 [umit]
Jonathan: we have a context in the spec. Lets not default the property.
18:15:15 [dorchard]
dorchard has joined #ws-addr
18:18:34 [umit]
Paco: There is also a problem with wsa:To
18:23:09 [yinleng]
yinleng has joined #Ws-addr
18:32:39 [mnot]
Ãœmit's OPTIONAL/REQUIRED issue
18:32:39 [mnot]
[ remove defaulting from infoset serialisation ]
18:32:39 [mnot]
Select the appropriate EPR:
18:32:39 [mnot]
•If the reply is a normal message, select the EPR from the related message's [reply endpoint] message addressing property. If the MAP is not present, assume its value is "http://www.w3.org/@@@@/@@/addressing/anonymous".
18:32:39 [mnot]
• Otherwise, if the reply is a fault message and the related message's [fault endpoint] message addressing property is not empty, select the EPR from that property. If the [fault endpoint] property is empty, select the EPR from the related message's [reply endpoint] message addressing property.
18:32:43 [mnot]
•In either of the above cases, if the related message lacks a [message id] property, the processor MUST fault.
18:32:46 [mnot]
2.Send the message according to [section 3.3 Sending a Message to an EPR], but also including:
18:32:48 [mnot]
•[relationship]: this property MUST include a pair of IRIs as follows; the relationship type is the predefined reply URI "http://www.w3.org/@@@@/@@/addressing/reply" and the related message's identifier is the [message id] property value from the message being replied to; other relationships MAY be expressed in this property
18:34:03 [mnot]
revised:
18:34:03 [mnot]
Ãœmit's OPTIONAL/REQUIRED issue
18:34:03 [mnot]
[ remove defaulting from infoset serialisation ]
18:34:03 [mnot]
Select the appropriate EPR:
18:34:03 [mnot]
•If the reply is a normal message, select the EPR from the related message's [reply endpoint] message addressing property. If the MAP is not present, its value defaults to an EPR with the [address] "http://www.w3.org/@@@@/@@/addressing/anonymous".
18:34:06 [mnot]
• Otherwise, if the reply is a fault message and the related message's [fault endpoint] message addressing property is not empty, select the EPR from that property. If the [fault endpoint] property is empty, select the EPR from the related message's [reply endpoint] message addressing property.
18:34:10 [mnot]
•In either of the above cases, if the related message lacks a [message id] property, the processor MUST fault.
18:34:13 [mnot]
2.Send the message according to [section 3.3 Sending a Message to an EPR], but also including:
18:34:15 [mnot]
•[relationship]: this property MUST include a pair of IRIs as follows; the relationship type is the predefined reply URI "http://www.w3.org/@@@@/@@/addressing/reply" and the related message's identifier is the [message id] property value from the message being replied to; other relationships MAY be expressed in this property
18:34:29 [umit]
Mark: More comments?
18:34:54 [umit]
... Removing the defaulting to the processing section in formulating a reply.
18:36:21 [umit]
Anish: is it obvious when reply to and fault to are not present, where do we send the fault to? We need to clarify this.
18:37:21 [umit]
Mark is trying to apply the change to accomodate the semantics on board.
18:38:19 [umit]
it is coming tony
18:38:58 [mnot]
final proposal:
18:38:59 [mnot]
Ãœmit's OPTIONAL/REQUIRED issue
18:38:59 [mnot]
[ remove defaulting from infoset serialisation ]
18:38:59 [mnot]
1. Select the appropriate EPR:
18:38:59 [mnot]
a)If the reply is a normal message, select the EPR from the related message's [reply endpoint] message addressing property. If the MAP is not present, use an EPR with the [address] "http://www.w3.org/@@@@/@@/addressing/anonymous".
18:39:01 [mnot]
b) Otherwise, if the reply is a fault message and the related message's [fault endpoint] message addressing property is not empty, select the EPR from that property. If the [fault endpoint] property is not present, select the EPR that would have been selected in step (a).
18:39:05 [mnot]
c)In either of the above cases (a) or (b), if the related message lacks a [message id] property, the processor MUST fault.
18:39:08 [mnot]
2.Send the message according to [section 3.3 Sending a Message to an EPR], but also including:
18:39:10 [mnot]
a) [relationship]: this property MUST include a pair of IRIs as follows; the relationship type is the predefined reply URI "http://www.w3.org/@@@@/@@/addressing/reply" and the related message's identifier is the [message id] property value from the message being replied to; other relationships MAY be expressed in this property
18:39:57 [plh]
plh has joined #ws-addr
18:40:03 [umit]
Mark: Are there any comments to this?
18:41:03 [umit]
Hugo: Lets define an anonymous EPR and reuse it.
18:41:29 [umit]
The group seems to nod their heads.
18:41:38 [mnot]
a) If the reply is a normal message, select the EPR from the related message's [reply endpoint] message addressing property. If the MAP is not present, use an EPR with the [address] "http://www.w3.org/@@@@/@@/addressing/anonymous" and no other properties.
18:42:06 [umit]
see above
18:42:09 [TRutt]
Yes to tony
18:42:33 [mnot]
Ãœmit's OPTIONAL/REQUIRED issue
18:42:33 [mnot]
[ remove defaulting from infoset serialisation ]
18:42:33 [mnot]
1. Select the appropriate EPR:
18:42:33 [mnot]
a) If the reply is a normal message, select the EPR from the related message's [reply endpoint] message addressing property. If the MAP is not present, use an EPR with the [address] "http://www.w3.org/@@@@/@@/addressing/anonymous" and no other properties.
18:42:34 [mnot]
b) Otherwise, if the reply is a fault message and the related message's [fault endpoint] message addressing property is not empty, select the EPR from that property. If the [fault endpoint] property is not present, select the EPR that would have been selected in step (a).
18:42:38 [mnot]
c) In either of the above cases (a) or (b), if the related message lacks a [message id] property, the processor MUST fault.
18:42:42 [mnot]
2. Send the message according to [section 3.3 Sending a Message to an EPR], but also including:
18:42:43 [mnot]
a) [relationship]: this property MUST include a pair of IRIs as follows; the relationship type is the predefined reply URI "http://www.w3.org/@@@@/@@/addressing/reply" and the related message's identifier is the [message id] property value from the message being replied to; other relationships MAY be expressed in this property.
18:43:04 [umit]
RESOLUTION: The last wording as pasted above is accepted as the resolution of the issue.
18:43:36 [bob_]
Prince. How long hast thou to serve, Francis?
18:43:37 [bob_]
Fran. Forsooth, five years, and as much as to—
18:43:37 [bob_]
Poins. [Within. ] Francis!
18:43:37 [bob_]
Fran. Anon, anon, sir.
18:44:05 [Zakim]
-TonyR
18:44:56 [Zakim]
-Paco:Francisco_Curbera
18:59:50 [Zakim]
+Paco:Francisco_Curbera
19:01:52 [Zakim]
+??P7
19:02:00 [TonyR]
zakim, ??p7 is me
19:02:00 [Zakim]
+TonyR; got it
19:06:23 [uyalcina]
uyalcina has joined #ws-addr
19:07:36 [uyalcina]
TOPIC: Paco's issue with respect to defaulting the wsa:To
19:08:16 [uyalcina]
Paco: This is again related to the last issue we solved. This only applies to request-response. The defaulting makes sense only for the response.
19:08:21 [uyalcina]
Anish agrees.
19:08:24 [uyalcina]
Umit: +1
19:08:28 [Jonathan]
Jonathan has joined #ws-addr
19:09:07 [uyalcina]
Anish: We make it hard for one-way message. It is also the Paul's issue. I agree with Paco.
19:09:45 [uyalcina]
Tom: My interpretation was that the address in the HTTP header is sufficient to be the destination.
19:10:09 [uyalcina]
... We had a different discussion earlier. Anonymous has morphed into the backchannel now.
19:10:32 [uyalcina]
Paco: This is dangerous to default here except the case we understand...
19:11:35 [uyalcina]
Tom: Do people have trouble in accessing the HTTP layer and have no access to it?
19:11:46 [uyalcina]
Jonathan: yes, that is the problem due to layering.
19:13:58 [uyalcina]
Glen: my preference is to make To optional completely.
19:14:57 [uyalcina]
Jonathan points to 3.5 in the SOAP binding document for the definition of anonymous.
19:15:14 [uyalcina]
Jonathan: Does not say it is the backchannel
19:16:26 [uyalcina]
Anish: Lets remove the defaulting (last sentence) from the definition of wsa:To
19:16:41 [uyalcina]
Jonathan: but destination is a required property
19:17:21 [uyalcina]
Glen: Anology is similar to Action.
19:18:53 [uyalcina]
Paco: Lets scope this to request only.
19:19:15 [uyalcina]
Tom: If you are using a backchannel for the response, I would like to retain that.
19:19:43 [uyalcina]
The only time we do not need to put this when you are formulating a response
19:20:14 [uyalcina]
Jonathan: For SOAP/HTTP anonymous is the backchannel, nothing more.
19:21:13 [uyalcina]
Glen: Do I need to a wsa:To in the request ?
19:21:16 [uyalcina]
Paco: yes
19:21:25 [uyalcina]
Umit: +1
19:21:46 [uyalcina]
Paco: Defaulting is a bit extreme here.
19:23:04 [uyalcina]
Jonathan: It is an error to use the value of anonymous for SOAP/HTTP.
19:23:31 [uyalcina]
... for request
19:25:00 [uyalcina]
Paco: When you are holding a connection open, you know what the anonymous corresponds to.
19:27:29 [uyalcina]
Scribe could not capture Anish's argument, apologies.
19:28:39 [uyalcina]
Jonathan: We still need to define what anonymous here regardless of the default case.
19:29:49 [uyalcina]
ACTION: Paco to provide a concrete proposal for this issue.
19:30:16 [uyalcina]
TOPIC: DavidH issue
19:30:42 [uyalcina]
TOPIC: CR14
19:30:57 [mnot]
http://www.w3.org/mid/43D12536.6060103@tibco.com
19:33:03 [uyalcina]
Tony: Where should it be in the spec?
19:33:25 [uyalcina]
DavidH: Originally SOAP Action.
19:33:47 [uyalcina]
Umit: Last sentence in the proposed text is misleading (is likely to differ) is erroneous
19:33:54 [uyalcina]
Glen: there is nothing normative here.
19:35:17 [uyalcina]
Mark: Are there any objections to accept with advise to editors?
19:35:36 [uyalcina]
Umit: Where should it go?
19:36:58 [uyalcina]
DaveH: 3.4 in the SOAP binding document
19:37:29 [Zakim]
-Paco:Francisco_Curbera
19:38:00 [uyalcina]
DaveH: New section 3.5
19:38:16 [uyalcina]
... or in 3.4.
19:38:30 [uyalcina]
Mark: Any objection to this resolution?
19:38:35 [uyalcina]
None noted.
19:39:01 [uyalcina]
RESOLUTION: Closed by adopting the text
19:39:30 [uyalcina]
TOPIC: David Hull's issue Jan 20th
19:40:07 [uyalcina]
Group reads the proposal from email.
19:41:34 [uyalcina]
The first sentence appears to be capture.
19:41:53 [uyalcina]
Remove the first sentence of the third par in the core.
19:42:22 [uyalcina]
Replace it with: In a one way interaction pattern, a source sends a message ...
19:43:11 [uyalcina]
Section 3, third paragraph of MAP
19:43:26 [mnot]
In a one-way interaction pattern, the source sends a message...
19:43:30 [uyalcina]
http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html?content-type=text/html;%20charset=utf-8
19:44:19 [uyalcina]
Mark: any objections?
19:44:21 [uyalcina]
None noted.
19:44:42 [uyalcina]
RESOLUTION: Close the issue with adopting the change to Section 3, paragraph 3 as noted above
19:44:50 [mnot]
http://www.w3.org/mid/2A7793353757DB4392DF4DFBBC9522550276F23E@I2KM11-UKBR.domain1.systemhost.net
19:45:01 [mnot]
Topic: Paul's new CR issue
19:46:07 [uyalcina]
Paul presents the issue based on the interop testing experience.
19:48:22 [uyalcina]
The examples did not have any wsa:To in the test suite originally.
19:48:43 [uyalcina]
At least two implementations actually dispatch on wsa:To and Action...
19:49:11 [uyalcina]
If you omit it from the spec, what does it mean as it defaults to anonymous?
19:49:53 [dhull]
Want to explicitly record that the group agreed with Umit's point that "Last sentence in the proposed text [for CR14] is misleading (is likely to differ) is erroneous". "may differ" or "is liable to differ" would be fine.
19:49:55 [uyalcina]
Jonathan: We do not say that anonymous is exactly the HTTP response channel that is the problem.
19:51:05 [uyalcina]
Jonathan: Defaulting is a separate problem. The question is what does "anonymous" mean when you are sending the request message?
19:51:50 [uyalcina]
Paul: I side with Microsoft's point. We need to identify where we are sending the message.
19:52:26 [uyalcina]
Glen: There is a different perpective. Need not to repeat sth that already exists.
19:52:39 [uyalcina]
Jonathan: It is an optimization.
19:53:14 [uyalcina]
Glen disagrees.
19:53:36 [uyalcina]
Umit: Agrees with Jonathan.
19:54:43 [uyalcina]
Mark: Remove the defaulting, section 3.3 it defaults a new default value and in 3,4 it is overridden.
19:55:18 [uyalcina]
Jonathan: This does not solve the problem. On a request, we can not process anonymous.
19:57:08 [uyalcina]
Tom: Originally I was pushing for this, but Action was not required at that time. I was worried about redundant stuff from HTTP. But, this is different as we made Action required. Things have changed.
19:57:46 [uyalcina]
Paul: We need to consider what it means when Action differs in HTTP/SOAP Action, the issue is similar here.
19:58:09 [uyalcina]
Anish: You want the MAP to survive.
20:00:03 [uyalcina]
Glen: Some vendors will not be able to process this, it is ok.
20:00:42 [uyalcina]
Anish: Make [destination] property optional
20:00:50 [uyalcina]
Umit: Big -1
20:01:40 [uyalcina]
Paul: The status quo is not sufficient.
20:02:18 [uyalcina]
... The combination of these two specs is not clear from testing perspective.
20:02:51 [uyalcina]
Anish: Anonymous means backchannel regardless of the context (we make this assumption)
20:03:55 [uyalcina]
... My interpretation is if you are doing req-response, when we say anonymous it is HTTP backchannel when it is a value in an EPR.
20:04:17 [uyalcina]
...we do not say what it means when it is used outside an EPR.
20:05:25 [uyalcina]
DaveH: Isnt it a dispatching problem and outside our scope?
20:06:16 [uyalcina]
Paul: another use case: I send you a msg with wsa:to anonymous with a firewall. At this point, it is not really useful.
20:07:36 [uyalcina]
s/with/to sth behind a/
20:09:14 [uyalcina]
Paul: Least distruptive change is to make wsa:To with anonymous is meaningless.
20:09:36 [uyalcina]
Umit: do you require we prohibit it?
20:09:46 [uyalcina]
Paul: we just state it is meaningless.
20:10:23 [pauld]
want's a straw poll
20:10:57 [uyalcina]
Jonathan: (1) we do not say anything, your mileage may vary. (2) We define anonymous for SOAP/HTTP fully.
20:12:32 [uyalcina]
... Option 2: It means only the response channel.
20:13:18 [uyalcina]
Anish: We require the sender to make more work while we are helping the responder with defaults. The first option is better.
20:15:51 [uyalcina]
Straw pall: Leave it as it is but put advisory text to discourage the use of anonymous as value of wsa:To in a request.
20:16:11 [uyalcina]
Large majority of yes, no one objected.
20:17:53 [uyalcina]
Discussion about what happens when we use WSDL and formulate messages and whether it is possible to change the destination address to an anonymous with overrides, etc.
20:18:37 [uyalcina]
Glen: Going down that you should get an error is taking it too far.
20:18:56 [uyalcina]
Jonathan: I prefer the second option.
20:19:46 [uyalcina]
Umit: Where should this advisory text go?
20:20:25 [uyalcina]
Group looks at Section 3.5 in SOAP binding document.
20:23:00 [mnot]
Note that in some situations, the semantics assigned to anonymous may not be appropriate to the message being sent (e.g., in request messages).
20:23:16 [uyalcina]
... not appropriate here, back to Core document defn of wsa:To
20:24:31 [uyalcina]
The above text is as an addendum to wsa:To.
20:25:03 [uyalcina]
Mark: Could someone send text for this issue? This issue is still open...
20:25:42 [uyalcina]
Mark: No call on Monday. I have commitments for the following week.
20:26:14 [uyalcina]
Mark: Dave Orchard to give an update for the note proposed.
20:27:33 [pauld]
this document is far too short. Suggest adding the enitre working group as editors :-)
20:27:36 [uyalcina]
DaveO: reads the document. http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0055.html
20:28:52 [TRutt]
TRutt has left #ws-addr
20:29:15 [uyalcina]
.. There is discussion already in the list that folks would like an optional SOAP Envelope...
20:29:26 [uyalcina]
Umit: This is what wS-RX needs.
20:30:28 [uyalcina]
Mark: We are out of time.
20:30:51 [uyalcina]
DaveO: We need to call it a SOAP optional response document then.
20:31:21 [uyalcina]
Mark: We need the docs to be updated for the following week from the editors.
20:31:55 [uyalcina]
... No open issues on the WSDL document.
20:32:12 [uyalcina]
... If there is none, we will take it to LC.
20:32:36 [uyalcina]
... There are two open issues for which we need proposals for.
20:33:33 [yinleng]
yinleng has left #Ws-addr
20:33:48 [uyalcina]
Working group thanks to the Chair.
20:33:55 [uyalcina]
Meeting adjurned.
20:34:37 [Zakim]
-TonyR
20:34:56 [Zakim]
-Prasad_Yendluri
20:35:00 [TonyR]
TonyR has left #ws-addr
20:35:07 [mnot]
rrsagent, make logs public
20:35:13 [mnot]
rrsagent, generate minutes
20:35:13 [RRSAgent]
I have made the request to generate http://www.w3.org/2006/01/20-Ws-addr-minutes.html mnot
20:36:02 [bob_]
bob_ has left #ws-addr
21:36:37 [Zakim]
- +1.604.642.aaaa
21:36:39 [Zakim]
WS_AddrWG(F2F)12:00PM has ended
21:36:40 [Zakim]
Attendees were +1.604.642.aaaa, Prasad_Yendluri, TonyR, Paco:Francisco_Curbera