W3C

- DRAFT -

Web Services Addressing F2F

20 Jan 2006

See also: IRC log

Attendees

Present
Regrets
Chair
Mark Nottingham
Scribe
uyalcina, umit

Contents


 

 

<uyalcina> SCRIBE: uyalcina

CR10

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

CR13

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

CR14

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

Umit's new issue regarding inconsistency...

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

New issue optional/required

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.

Paco's issue with respect to defaulting the wsa:To

<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]

DavidH issue

CR14

<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

David Hull's issue Jan 20th

<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> http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html?content-type=text/html;%20charset=utf-8

<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

Paul's new CR issue

<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.

Summary of Action Items

[NEW] 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]
[NEW] ACTION: Paco to provide a concrete proposal for this issue. [recorded in http://www.w3.org/2006/01/20-Ws-addr-minutes.html#action02]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.127 (CVS log)
$Date: 2006/01/20 20:35:24 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.127  of Date: 2005/08/16 15:12:03  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/enought/enough/
Succeeded: s/with/to sth behind a/
Found Scribe: uyalcina
Inferring ScribeNick: uyalcina
Found Scribe: umit
Inferring ScribeNick: umit
Scribes: uyalcina, umit
ScribeNicks: uyalcina, umit

WARNING: No "Present: ... " found!
Possibly Present: Anish DaveH DaveO DavidH David_Illsley Francisco_Curbera Gil Glen Jonathan Mark Nilo P5 P7 Paco Paul PaulKnight Prasad_Yendluri TRutt Tom Tony TonyR aaaa akarmark bob bob_ chad dhull dorchard gpilz hugo mnot pauld plh prasad revised umit uyalcina yinleng
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy

Got date from IRC log name: 20 Jan 2006
Guessing minutes URL: http://www.w3.org/2006/01/20-Ws-addr-minutes.html
People with action items: hugo paco

[End of scribe.perl diagnostic output]