See also: IRC log
<uyalcina> SCRIBE: uyalcina
looking at proposal 6...
Mark: what do you think?
... Are there objections
None noted
<scribe> ACTION: Hugo to communicate our decision back to the tag on CR10 [recorded in http://www.w3.org/2006/01/20-Ws-addr-minutes.html#action01]
RESOLUTION: CR10 closed with accepting Proposal 6
Mark: Are these optional faults?
Jonathan: Can we check with each vendor to add them?
Glen: These kind of things are very handy for debugging.
Scribe missed some of the points because this was her cr issue...
Paul: We need to add test cases
Jonathan: How many people are interested in implementing them?
DaveH: Aren't they related to WSDL only?
Jonathan: They are not really WSDL faults.
Mark: Is there enough info here to proceed.
Jonathan: yes
Mark: Are there any objections to accept this?
None noted.
<umit> SCRIBE: umit
DaveH presents the problem.
Jonathan: This is an expediency,
we should not change anything.
... Are you asking to break the tie between them?
Glen: SOAPAction is not an HTTP
thing
... The idea is to encode the metadata
DaveH: SOAP Action is less important than from and to...
Mark: We discussed the
relationship between the underlying protocol artifacts in the
past and this was the direction we wanted to take.
... Doing thought experiments at this stage is not a useful
thing.
... It questions the fundamental assumptions.
DaveH: You want to totally ignore this?
Paul: Write a test case to illustrate the issue.
Mark: You can not use the test case as a bar to get issues accepted.
Discussion on multi-hop test case ...
DaveH presents a Jabber based test case and says how id will not match (scribe missed some of the details)
scribe: in the multi hop case we
may lose the ids to match...
... I would like a sentence or two (in the proposal 2)...
Mark: Could you do this by lunch and provide concrete text?
DaveH: yes
Mark: Proposal is to reincorporate the text as aggreed on issue i20 subissue d back into the text
http://www.w3.org/2002/ws/addr/wd-issues/#i020
RESOLUTION: Close to issue reincorporating the previous resolution into the text
<mnot> http://www.w3.org/mid/2BA6015847F82645A9BB31C7F9D64165E43F89@uspale20.pal.sap.corp
<pauld> Jabber URI schema, fwiw: http://www.jabber.org/jeps/jep-0032.html
Umit: There are two problems.
Glen/Umit: the concept of "when you need the property" is missing
Jonathan: We should make it required.
Mark: Thisis a serialization problem, it appears in the serialization only. We do not have a problem.
<dhull> Proposed text for CR14: http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2006Jan/0008.html
Mark: Will we have a
serialization that will never have defaults?
... is the absence of optional element equivalent to none?
Glen: no
Mark: there are three options
1. make it required
2. default is none (if not present)
3. define another semantic when missing
Gil: None has a semantic meaning you do not want to default to it.
<akarmark> +1 to paco
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.
... in a request-response pattern, you can default to
anonymous. We should keep this semantic as intended.
... restrict the default to request-response...
<akarmark> option 4: remove the defaulting in the core and include it in the wsdl-binding for the req-res MEP
Jonathan: we have a context in the spec. Lets not default the property.
Paco: There is also a problem with wsa:To
<mnot> Ãœmit's OPTIONAL/REQUIRED issue
<mnot> [ remove defaulting from infoset serialisation ]
<mnot> Select the appropriate EPR:
<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".
<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.
<mnot> •In either of the above cases, if the related message lacks a [message id] property, the processor MUST fault.
<mnot> 2.Send the message according to [section 3.3 Sending a Message to an EPR], but also including:
<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
<mnot> revised:
<mnot> Ãœmit's OPTIONAL/REQUIRED issue
<mnot> [ remove defaulting from infoset serialisation ]
<mnot> Select the appropriate EPR:
<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".
<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.
<mnot> •In either of the above cases, if the related message lacks a [message id] property, the processor MUST fault.
<mnot> 2.Send the message according to [section 3.3 Sending a Message to an EPR], but also including:
<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
Mark: More comments?
... Removing the defaulting to the processing section in
formulating a reply.
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.
Mark is trying to apply the change to accomodate the semantics on board.
it is coming tony
<mnot> final proposal:
<mnot> Ãœmit's OPTIONAL/REQUIRED issue
<mnot> [ remove defaulting from infoset serialisation ]
<mnot> 1. Select the appropriate EPR:
<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".
<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).
<mnot> c)In either of the above cases (a) or (b), if the related message lacks a [message id] property, the processor MUST fault.
<mnot> 2.Send the message according to [section 3.3 Sending a Message to an EPR], but also including:
<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
Mark: Are there any comments to this?
Hugo: Lets define an anonymous EPR and reuse it.
The group seems to nod their heads.
<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.
see above
<TRutt> Yes to tony
<mnot> Ãœmit's OPTIONAL/REQUIRED issue
<mnot> [ remove defaulting from infoset serialisation ]
<mnot> 1. Select the appropriate EPR:
<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.
<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).
<mnot> c) In either of the above cases (a) or (b), if the related message lacks a [message id] property, the processor MUST fault.
<mnot> 2. Send the message according to [section 3.3 Sending a Message to an EPR], but also including:
<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.
RESOLUTION: The last wording as pasted above is accepted as the resolution of the issue.
<bob_> Prince. How long hast thou to serve, Francis?
<bob_> Fran. Forsooth, five years, and as much as to—
<bob_> Poins. [Within. ] Francis!
<bob_> Fran. Anon, anon, sir.
<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.
<uyalcina> Anish agrees.
<uyalcina> Umit: +1
<uyalcina> Anish: We make it hard for one-way message. It is also the Paul's issue. I agree with Paco.
<uyalcina> Tom: My interpretation was that the address in the HTTP header is sufficient to be the destination.
<uyalcina> ... We had a different discussion earlier. Anonymous has morphed into the backchannel now.
<uyalcina> Paco: This is dangerous to default here except the case we understand...
<uyalcina> Tom: Do people have trouble in accessing the HTTP layer and have no access to it?
<uyalcina> Jonathan: yes, that is the problem due to layering.
<uyalcina> Glen: my preference is to make To optional completely.
<uyalcina> Jonathan points to 3.5 in the SOAP binding document for the definition of anonymous.
<uyalcina> Jonathan: Does not say it is the backchannel
<uyalcina> Anish: Lets remove the defaulting (last sentence) from the definition of wsa:To
<uyalcina> Jonathan: but destination is a required property
<uyalcina> Glen: Anology is similar to Action.
<uyalcina> Paco: Lets scope this to request only.
<uyalcina> Tom: If you are using a backchannel for the response, I would like to retain that.
<uyalcina> The only time we do not need to put this when you are formulating a response
<uyalcina> Jonathan: For SOAP/HTTP anonymous is the backchannel, nothing more.
<uyalcina> Glen: Do I need to a wsa:To in the request ?
<uyalcina> Paco: yes
<uyalcina> Umit: +1
<uyalcina> Paco: Defaulting is a bit extreme here.
<uyalcina> Jonathan: It is an error to use the value of anonymous for SOAP/HTTP.
<uyalcina> ... for request
<uyalcina> Paco: When you are holding a connection open, you know what the anonymous corresponds to.
<uyalcina> Scribe could not capture Anish's argument, apologies.
<uyalcina> Jonathan: We still need to define what anonymous here regardless of the default case.
<uyalcina> ACTION: Paco to provide a concrete proposal for this issue. [recorded in http://www.w3.org/2006/01/20-Ws-addr-minutes.html#action02]
<mnot> http://www.w3.org/mid/43D12536.6060103@tibco.com
<uyalcina> Tony: Where should it be in the spec?
<uyalcina> DavidH: Originally SOAP Action.
<uyalcina> Umit: Last sentence in the proposed text is misleading (is likely to differ) is erroneous
<uyalcina> Glen: there is nothing normative here.
<uyalcina> Mark: Are there any objections to accept with advise to editors?
<uyalcina> Umit: Where should it go?
<uyalcina> DaveH: 3.4 in the SOAP binding document
<uyalcina> DaveH: New section 3.5
<uyalcina> ... or in 3.4.
<uyalcina> Mark: Any objection to this resolution?
<uyalcina> None noted.
<uyalcina> RESOLUTION: Closed by adopting the text
<uyalcina> Group reads the proposal from email.
<uyalcina> The first sentence appears to be capture.
<uyalcina> Remove the first sentence of the third par in the core.
<uyalcina> Replace it with: In a one way interaction pattern, a source sends a message ...
<uyalcina> Section 3, third paragraph of MAP
<mnot> In a one-way interaction pattern, the source sends a message...
<uyalcina> Mark: any objections?
<uyalcina> None noted.
<uyalcina> RESOLUTION: Close the issue with adopting the change to Section 3, paragraph 3 as noted above
<mnot> http://www.w3.org/mid/2A7793353757DB4392DF4DFBBC9522550276F23E@I2KM11-UKBR.domain1.systemhost.net
<uyalcina> Paul presents the issue based on the interop testing experience.
<uyalcina> The examples did not have any wsa:To in the test suite originally.
<uyalcina> At least two implementations actually dispatch on wsa:To and Action...
<uyalcina> If you omit it from the spec, what does it mean as it defaults to anonymous?
<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.
<uyalcina> Jonathan: We do not say that anonymous is exactly the HTTP response channel that is the problem.
<uyalcina> Jonathan: Defaulting is a separate problem. The question is what does "anonymous" mean when you are sending the request message?
<uyalcina> Paul: I side with Microsoft's point. We need to identify where we are sending the message.
<uyalcina> Glen: There is a different perpective. Need not to repeat sth that already exists.
<uyalcina> Jonathan: It is an optimization.
<uyalcina> Glen disagrees.
<uyalcina> Umit: Agrees with Jonathan.
<uyalcina> Mark: Remove the defaulting, section 3.3 it defaults a new default value and in 3,4 it is overridden.
<uyalcina> Jonathan: This does not solve the problem. On a request, we can not process anonymous.
<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.
<uyalcina> Paul: We need to consider what it means when Action differs in HTTP/SOAP Action, the issue is similar here.
<uyalcina> Anish: You want the MAP to survive.
<uyalcina> Glen: Some vendors will not be able to process this, it is ok.
<uyalcina> Anish: Make [destination] property optional
<uyalcina> Umit: Big -1
<uyalcina> Paul: The status quo is not sufficient.
<uyalcina> ... The combination of these two specs is not clear from testing perspective.
<uyalcina> Anish: Anonymous means backchannel regardless of the context (we make this assumption)
<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.
<uyalcina> ...we do not say what it means when it is used outside an EPR.
<uyalcina> DaveH: Isnt it a dispatching problem and outside our scope?
<uyalcina> Paul: another use case: I send you a msg with wsa:to anonymous to sth behind a a firewall. At this point, it is not really useful.
<uyalcina> Paul: Least distruptive change is to make wsa:To with anonymous is meaningless.
<uyalcina> Umit: do you require we prohibit it?
<uyalcina> Paul: we just state it is meaningless.
<pauld> want's a straw poll
<uyalcina> Jonathan: (1) we do not say anything, your mileage may vary. (2) We define anonymous for SOAP/HTTP fully.
<uyalcina> ... Option 2: It means only the response channel.
<uyalcina> Anish: We require the sender to make more work while we are helping the responder with defaults. The first option is better.
<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.
<uyalcina> Large majority of yes, no one objected.
<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.
<uyalcina> Glen: Going down that you should get an error is taking it too far.
<uyalcina> Jonathan: I prefer the second option.
<uyalcina> Umit: Where should this advisory text go?
<uyalcina> Group looks at Section 3.5 in SOAP binding document.
<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).
<uyalcina> ... not appropriate here, back to Core document defn of wsa:To
<uyalcina> The above text is as an addendum to wsa:To.
<uyalcina> Mark: Could someone send text for this issue? This issue is still open...
<uyalcina> Mark: No call on Monday. I have commitments for the following week.
<uyalcina> Mark: Dave Orchard to give an update for the note proposed.
<pauld> this document is far too short. Suggest adding the enitre working group as editors :-)
<uyalcina> DaveO: reads the document. http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jan/0055.html
<uyalcina> .. There is discussion already in the list that folks would like an optional SOAP Envelope...
<uyalcina> Umit: This is what wS-RX needs.
<uyalcina> Mark: We are out of time.
<uyalcina> DaveO: We need to call it a SOAP optional response document then.
<uyalcina> Mark: We need the docs to be updated for the following week from the editors.
<uyalcina> ... No open issues on the WSDL document.
<uyalcina> ... If there is none, we will take it to LC.
<uyalcina> ... There are two open issues for which we need proposals for.
<uyalcina> Working group thanks to the Chair.
<uyalcina> Meeting adjurned.