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