Minutes 2006-08-07 distributed meeting

  <http://www.w3.org/> 


Web Services Addressing


7 Aug 2006


Agenda <http://lists.w3.org/Archives/Public/public-ws-addressing/2006Aug/0019.html> 

See also: IRC log <http://www.w3.org/2006/08/07-ws-addr-irc> 


Attendees


Present 

Paul Downey (BT) 

Arun Gupta (Sun Microsystems, Inc.) 

Marc Hadley (Sun Microsystems, Inc.) 

Yin-Leng Husband (HP) 

David Illsley (IBM Corporation) 

Anish Karmarkar (Oracle Corporation) 

Paul Knight (Nortel Networks) 

Philippe Le Hegaret (W3C) 

Mark Little (JBoss Inc.) 

Jonathan Marsh (Microsoft Corporation) 

Gilbert Pilz (BEA Systems, Inc.) 

Tony Rogers (Computer Associates) 

Pete Wenzel (Sun Microsystems, Inc.) 

Prasad Yendluri (webMethods, Inc.) 

Absent 

Abbie Barbir (Nortel Networks) 

Andreas Bjarlestam (ERICSSON) 

Dave Chappell (Sonic Software) 

Francisco Curbera (IBM Corporation) 

Glen Daniels (Sonic Software) 

Vikas Deolaliker (Sonoa Systems, Inc.) 

Jacques Durand (Fujitsu Limited) 

Robert Freund (Hitachi, Ltd.) 

Marc Goodner (Microsoft Corporation) 

Hugo Haas (W3C) 

David Hull (TIBCO Software, Inc.) 

Amelia Lewis (TIBCO Software, Inc.) 

Bozhong Lin (IONA Technologies, Inc.) 

Jeganathan Markandu (Nortel Networks) 

Jeff Mischkinsky (Oracle Corporation) 

Nilo Mitra (ERICSSON) 

Eisaku Nishiyama (Hitachi, Ltd.) 

David Orchard (BEA Systems, Inc.) 

Alain Regnier (Ricoh Company Ltd.) 

Tom Rutt (Fujitsu Limited) 

Davanum Srinivas (WSO2) 

Katy Warr (IBM Corporation) 

Regrets 

Bob Freund 

Chair 

Philippe Le Hégaret 

Scribe 

Gilbert Pilz 


Contents


*	Topics <file:///C:\Documents%20and%20Settings\freund\My%20Documents\workspace\addr\6\08\07-ws-addr-minutes.html#agenda#agenda>  

	1.	Minutes <file:///C:\Documents%20and%20Settings\freund\My%20Documents\workspace\addr\6\08\07-ws-addr-minutes.html#item02#item02>  
	2.	Action Items <file:///C:\Documents%20and%20Settings\freund\My%20Documents\workspace\addr\6\08\07-ws-addr-minutes.html#item03#item03>  
	3.	CR27 <file:///C:\Documents%20and%20Settings\freund\My%20Documents\workspace\addr\6\08\07-ws-addr-minutes.html#item04#item04>  
	4.	CR29 <file:///C:\Documents%20and%20Settings\freund\My%20Documents\workspace\addr\6\08\07-ws-addr-minutes.html#item05#item05>  
	5.	CR30 <file:///C:\Documents%20and%20Settings\freund\My%20Documents\workspace\addr\6\08\07-ws-addr-minutes.html#item06#item06>  
	6.	CR31 <file:///C:\Documents%20and%20Settings\freund\My%20Documents\workspace\addr\6\08\07-ws-addr-minutes.html#item07#item07>  
	7.	CR32 <file:///C:\Documents%20and%20Settings\freund\My%20Documents\workspace\addr\6\08\07-ws-addr-minutes.html#item08#item08>  

*	Summary of Action Items <file:///C:\Documents%20and%20Settings\freund\My%20Documents\workspace\addr\6\08\07-ws-addr-minutes.html#ActionSummary#ActionSummary>  

________________________________

Minutes

RESOLUTION: previous minutes approved

Action Items

Long running action items around test cases.

No new issues

CR27

<plh> http://www.w3.org/2002/ws/addr/cr-issues/#cr27

Jonathan: Really an erratta issue although it appears on the crR list
... I don't have a detailed proposal but it shouldn't be hard to fix the wording.

<scribe> ACTION: philippe to propose errata to resolve CR27 [recorded in http://www.w3.org/2006/08/07-ws-addr-minutes.html#action01]

CR29

<plh> http://www.w3.org/2006/05/ws-addr-errata.html

RESOLUTION: mark as done and close the issue

CR30

http://www.w3.org/2002/ws/addr/cr-issues/Overview.html#cr30

Anish: (provides overview of the issue)

<David_Illsley> source mail: http://lists.w3.org/Archives/Public/public-ws-addressing/2006Jul/0020

Jonathan: If I had an existing WSDL 1.1 doc with an SOAP Action with a relative URI, I couldn't migrate this to WSDL 2.0?

Anish: You wouldn't be able to use that WSDL document with WS-Addressing.

Jonathan: Is there any evidence that people specify SOAP Actions that are not absolute URIs?

Anish: BP states that a service shouldn't depend on the SOAP Action header.

Jonathan: If I have a WSDL I would just like to use it with addressing. If the SOAP Action is bogus, I'd just like to ignore it.

philippe: We'd have to change the SOAP binding to say we can ignore it?

Gil: What was the reason behind mandating that they be the same?

Jonathan: They seem to be nearly identical concepts. So they should be the same.

Paul Downey: It makes sense to make them the same. Having two different values is just asking for trouble.

Paul Downey: What is the chance of this being a real problem? If you were adding addressing to an existing WSDL you'd probably be editing these values in any case.

philippe: Let's go with Anish's proposal and just declare this case invalid.
... Is there any objection to disallowing the case where (missing detail)

All: (clarify exact case that should be disallowed)

Anish: Only a problem when addressing is engaged.

philippe: So when addressing is engaged and you have a SOAP Action which has a non-empty, non-absolute URI . . . that is an invalid WSDL.

Jonathan: (works through the logic and agrees its ok)

Anish: If there are WSDLs which are being used that don't explicitly engage addressing but addressing is enabled at run-time, this would result in invalid SOAP messages.
... There is nothing we can say in the WSDL binding about this.

<pauld> notes that currently many tools are deaf to SOAPAction in WSDL,, especially if the value is empty '' they tend to assert their own values. I'd also note that most SOAPActions used by tools are currently urn/uris anyway

Gil: That's still a poroblem. We don't want to lose sight of this problem.

Anish: We point this out in various specs; SOAP HTTP binding; WS-Addr SOAP Binding

philippe: If your implemention is well done it should catch this error at run time.

Anish: Not sure if its obvious to everybody.

Gil: Isn't BP going to be taking into account WS-Addr?

philippe: BP 1.2 and BP 2.0

<scribe> ACTION: Anish to raise an issue with WS-I BP 1.2 to make sure this error condition is caught. [recorded in http://www.w3.org/2006/08/07-ws-addr-minutes.html#action02]

<scribe> ACTION: Tony draft the necessary changes for a resolution to CR30 [recorded in http://www.w3.org/2006/08/07-ws-addr-minutes.html#action03]

CR31

http://www.w3.org/2002/ws/addr/cr-issues/Overview.html#cr31

<plh> http://www.w3.org/2002/ws/addr/6/08/cr31.html

Arun: (reviews table)

philippe: How many people did not review the table?
... Let's review the grey one's for now . . . .

Arun: (reviews grey cells)

<anish> can we combine row 1 and 2; they are the same

Tony: I recall a lengthy discussion of this issue. We decided that it would be acceptable to return the fault along the backchannel before the connection closes.
... Up until you closed the connection its fair to use the backchannel since its better for the requester to know something bad has happened.

Anish: MAY or MUST?

<pauld> Tony's timeline from SAP: http://www.flickr.com/photos/psd/9877189/

Tony: MAY

philippe: This logic can be applied to many of the grey boxes.

Anish: Rows 1 and 2 look the same.

Arun: Agreed.

philippe: Where do we document this.

David Illsley: I thought we agreed that it would be good to get this entire table into the spec.

(all): Back and forth on where the table should go.

Jonathan: We are talking about changes to the text of the table.

RESOLUTION: 1E and 2E should be ammended to include optional use of back-channel.

Arun: I'm tracking the changes as well.
... (reviews cell 3D)

philippe: It seems that its better to deliver something on the back-channel rather than just dropping it.

Tony: I like A.

Jonathan: I thought A was wierd.
... Can we delay a decision on this until my people get back to me on how we work?

Anish: Why shouldn't we allow the reciever to decide whether it wants to send it back on the back-channel or not?

Jonathan: That would work. Its consistent with 1E and 2E.

Tony: The reason I like 3D.a is that its more useful than a situation where the requester never gets a response.

(all): Back and forth on various aspects of this issue.

philippe: What we are proposing is a MAY.

Jonathan: It sounds like what we're talking about is a proposal where we leave it up to the implementation to figure out if wants to send the fault on the back-channel.

philippe: We are saying you may use the back-channel.

Tony: That's all you can reasonably say.

philippe: This is not the same a 3D.a. Its more in line with our resolution to 1E and 2E.

Jonathan: I'd prefer if we have a proposed resolution on the table next week.

Anish: I like the resolution (MAY use back-channel). Its important to note that, if the reciever decides to use the back-channel, the sender may not be able to grok this.

philippe: Is our goal to put this table into the spec?

Tony: Yes.

Arun: Are we going to define any meta-rules to apply to the whole table?
... I'm hearing a general rule that if the back-channel is still open a reciever MAY use it to send back a fault.

Marc: What is the scope of this rule? Does it cross transport boundaries (HTTP, FTP)?

Tony: If you can scream for help, scream.
... I'd like to use any available means to tell the sender that they messed up and there is a problem.

Marc: Arun's table says if FaultTo can't be used then fall back to ReplyTo.

Tony: If you can't use the FaultTo or the ReplyTo then try to use the back-channel.

(all): back and forth around meta-rules

David: If there is a header you don't like, ignore it.

philippe: Move on to 5D.

Arun: (reviews 5D)

Tony: 5D has a non-anonymous ReplyTo. Subtly different but the effects are the same.

philippe: Follow our principal and specify "MAY use the back-channel".

Jonathan: It seems like a lot of the rest of the cases are going to break down the same way. What are implementers actually going to do?

Arun: Haven't got there yet.

Jonathan: Everyone is free to implement it either way. This is an interop problem.

Tony: The one thing you can test (like in 5D) is that you don't get the fault on the non-anonymous channel.

Arun: We will have to correlate test cases to these grey cells. We may be able to catogorize these as either optional or required tests.

philippe: These would be optional tests.
... Is is still worth going through the rest of the grey cells?

Arun: Yes

CR32

David: My proposal is that the None URI should be treated as a special case and allowed where anonymous=required.
... This relates to the recent issue about "alternate" anonymous URIs

Arun: Does this need a special case?

David: I'm not sure if this needs a special case or not.

Jonathan: I always thought if it more as a special case.

Tony: I thought of it as a special case, but None is still meets the requirements.

Arun: In terms of the table, 10E goes to option 'a' and 11D goes to option a

(all): discussion on nature of "None" vs. "Anonymous"

Arun: I want to understand the impacts on 10E and 11D

philippe: Option 'a' in both cases

Jonathan: What David was suggesting is neither 'a' nor 'b'.

David: This table is predicated on my proposal; see 4D

(all): Clarifying David's proposal for CR32.

David: If my proposal for CR32 did not go forward the current 10D would be incorrect.

Jonathan: 10D and 10E don't seem consistent then.
... In 10E I would expect that a normal response would also be discarded.

David: Because anonymous is prohibited causes a fault to be generated.

Jonathan: The effects of A and B are the same in that nothing comes back.

Anish: In this case, why wouldn't we give the option to the reciever to send the fault back.

David: This is for 10E; None is a valid address to have in your ReplyTo

Anish: Anon is prohibited, FaultTo is anon, generate a fault, default to ReplyTo and drop the fault?
... This seems out of line with our previous decisions.

David: This is in line with other SOAP bindings.

Anish & David: (back and forth on 10E)

Anish: In this case we are talking about how the fault it routed. To be consistent and allow for interop we should allow the reciever to attempt to get the fault back to the sender.

David: I take your point. I think Anish's idea is more in line with the other grey boxes.
... That still provides a reasonably clear statement that we can make 'at the top of the box'.

Marc: If we allow the responder to ignore None then we don't need to keep it.
... The reason for None was for the sender to say 'I don't want any response back'
... If we allow the reciever to ignore this and send back a fault, why specify 'None'?

philippe: A mistake has been made. We need a way to tell the sender that something is wrong rather than being silent.

Marc: We need to be consitent about our defaulting rules.
... If we default to ReplyTo and ReplyTo is 'None' we should honoer th 'None' semantics and not send anything.

Anish: In this case the sender has indicated that they want to see faults (FaultTo=anon).
... The defaults are meaningful if the sender doesn't have a preference about where the want faults sent.
... But in this case they were explicit (but wrong) about where they wanted faults sent.

Marc: I agree (for this case) but we need to be consistent.
... Going back to previous question: We are doing somehting that is specific to anonymouse, correct?
... Are we doing something that is specific to 'anonymous' or are we saying that, in general, if the reciever doesn't like FaulTo it should default to ReplyTo?

Anish: The former:

Marc: That's ok, but we need to be consistent.

David: The later (FaultTo defaults to ReplyTo) was the original proposal in the table.

Anish: I was saying something different: if FaultTo is specified we never default to ReplyTo . . .

David: That's untestable.

Arun: You may not be capable of sending a fault to a non-anon FaultTo

Anish: The initial sender created a message which was incorrect. If you strictly followed the rules the fault would never get to the sender.
... If these things make it harder for the test suite, that's ok, as long as we promote interop.

philippe: If would be nicer to the users if they can find out when things go wrong.
... General rule is try to use back-channel to send any faults.

David: This is directly opposite to what 6E says.

Anish: If the sender explicitly separates faults and replies this indicates that the sender . . . .

philippe: Don't drop faults on the floor. Try to send them through the back-channel if you can. Try to respect the FaultTo, but if that resulsts in doing nothing try to send the fault through the back-channel.

Arun: It would help me if someone could summarize the rules that should apply to the whole table.

philippe: We still have the rule "try to use FaultTo and if you can't fall back to ReplyTo". We are adding a rule that says "Rather than drop a fault on the floor, try to use the back-channel if it is still open".

Arun: By the second rule - we are overriding the semantics of 'None' URI.

Anish: I am pushing back on the idea of using ReplyTo when you can't use FaultTo

philippe: Your addition is that if you can't use FaulTo try to use the back-channel.
... We have the rule that if you can't use FaulTo fall back to ReplyTo?

Anish: We have that rule, and we need to be consistent.
... If ReplyTo is None and FaultTo is invalid, our current rules say drop the fault on the floor.

philippe: The new rule is don't drop faults on the floor if the back-channel is open.

Gil: But we have to reconcile this with 'None'.
... Need to call out that we are overrding the behavior of 'None' in some cases.

philippe: I suppose so.
... Can we adopt Anish's rule?

Gil: Can we get a clear statement of it?

Anish: If the FaultTo value is incorrect the reciever is going to generate a fault. At its choosing it may send this fault over the back-channel with the understading that the sender may not reciever or process this fault.

David: I'd like to get some mention of the ReplyTo in there, if possible.
... Such as the sender may use the ReplyTo

Anish: You want the ability for the reciever to use either the back channel or the valid, non-anon ReplyTo?

David: Yes.

Gil: This sounds like an interop nightmare.

Arun: If the ReplyTo is None we ignore it?

Anish: Which case is this?

Arun: The case you just mentioned. Invalid FaultTo; try to send via back-channel or, if there is a non-anon ReplyTO, use that?
... Unless ReplyTo is None?
... David's proposal does the right thing for ReplyTo equal anon, non-anon but doesn't do the right thing for None. This means treating None like anon.

David: I wanted an additional step where you can use ReplyTo if it is useful.

Anish: In your change, None is irrelevant?

David: FaultTo is invalid (1) try to use ReplyTo if it gets you somewhere useful (2) if not try to use the back channel

philippe: There are two proposals
... In both cases FaulTo is invalid
... According to Anish you try to send the fault on the back channel
... According to David you look at ReplyTo
... If it is non-anon or anon you try to use it, but if it is 'None' you then use the back-channel

Jonathan: But all of this is optional

David: Yes.
... (more complex than philippe said - ReplyTo should be ignored in cases where it is anon and the WSDL says anon is not supported)

Gil: Anish, why don't you like using ReplyTo?

Anish: The sender explicity set a value for FaultTo. This indicates that they really don't want faults going to ReplyTo.

Gil: (question for David - when doesn't ReplyTo 'get you anywhere useful')?

David: When is either 'None' or just plain invalid

philippe: Seems we are on the same page. Who likes what?

Anish: Results are the same except for 2 cases.

philippe: Non-anon ReplyTo is one, what's the other?

Anish: The only case is when ReplyTo is non-None, non-Anonymous and valid according to WSDL.

philippe: David, you want a MUST for using non-None, non-Anon ReplyTo

David: Yes.

philippe: But Jonathan seemed to want this optionality.

David: (ref 6E)
... I think Microsoft can handle this.

Jonathan: I don't know. It seems like we're going to a lot of trouble to get a fault back by any means possible even though they probably can't handle it.
... My preference would be to say "well there's no way of getting this fault back - so drop it".
... Would like to leave open the option of taking a strict interpretation of what the sender told you they wanted.

Anish: That optionality is there.

Jonathan: I think I'm ok, but I need to see the final proposal.

philippe: Sense of group?
... Jonathan are you ok with both?

Jonathan: Not thrilled with either, but prefer Anish's.

Marc: I prefer Anish's. It will be a lot easier to write down.

Gil: I could live with either, but prefer Anish's.

philippe: David can you live with Anish's approach.

David: Probably, but I don't want to commit to anything today.

philippe: Can you regenerate the table based on Anish's prinicipal?

Arun: Yes.

philippe: We'll come back to the table next week and look at the results.

Arun: I can pick the words from the chat session.

<agupta> (2:32:48 PM) gpilz: Anish: If the FaultTo value is incorrect the reciever is going to generate a fault. At its choosing it may send this fault over the back-channel with the understading that the sender may not reciever or process this fault.

philippe: Going back to CR32, where do we stand?

David: It sounds to me like no one disagrees with the principal behind the proposal.

Anish: The proposal is to treat None as allowed by wsaw:Anonymous?

David: Yes.

Anish: Why do you think this is right?
... When you say anon=required it means you want a back-channel.
... If you have None, you can't send a response anywhere.

<plh> ACTION: Arun to regenerate his table based on Anish's principle [recorded in http://www.w3.org/2006/08/07-ws-addr-minutes.html#action04]

David: My interpretation was that anon=required meant that the reciever was not being called upon to open a new HTTP connection.
... None satisfies this requirement.
... 'None' is a special case to begin with, why would it be limited by anon=required?

Anish: We have slightly different interpetations of anon=required.
... You think it means 'I won't open a separate HTTP connection' I think it means 'I will use the same back-channel'

David: I agree that your understanding is in line with what the spec says today. It is not in line with my understanding up until we began interop testing . . .

Anish: It seems like you want finer granularity on wsaw:Anonymous that we currently have.
... It seems like you want WSDL markers that allow you to talk aout ReplyTo and FaultTo independently of one another.
... For example, you would like to specify in WSDL that the ReplyTo should be anon and not choke on the case where FaulTo=None

David: I'm not asking for finer granularity (missed the rest)

philippe: WSDL says anonymous required but still you set the FaulTo to None. "I know I'm supposed to use anonymous but I really don't want to see any faults".

Jonathan: My conception of wsaw:Anonymous was about whether the service would be required to open a separate connection for response messages. None means no message so its ok.
... (agrees with David)

philippe: We'll resume this discussion next week.

Anish: Can we consider CR33 ASAP?

philippe: Is CR33 related to CR32?

David: It seems like. I related them in a follow-up email.

philippe: Next week, let's tackle CR32, CR33, then go back to CR31


Summary of Action Items


[NEW] ACTION: Anish to raise an issue with WS-I BP 1.2 to make sure this error condition is caught. [recorded in http://www.w3.org/2006/08/07-ws-addr-minutes.html#action02]
[NEW] ACTION: Arun to regenerate his table based on Anish's principle [recorded in http://www.w3.org/2006/08/07-ws-addr-minutes.html#action04]
[NEW] ACTION: philippe to propose errata to resolve CR27 [recorded in http://www.w3.org/2006/08/07-ws-addr-minutes.html#action01]
[NEW] ACTION: Tony draft the necessary changes for a resolution to CR30 [recorded in http://www.w3.org/2006/08/07-ws-addr-minutes.html#action03]
 
[End of minutes]

________________________________

Minutes formatted by David Booth's scribe.perl <http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm>  version 1.127 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/> )
$Date: 2006/08/12 08:46:31 $ 
________________________________