See also: IRC log
RESOLUTION: previous minutes approved
Long running action items around test cases.
No new issues
<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]
<plh> http://www.w3.org/2006/05/ws-addr-errata.html
RESOLUTION: mark as done and close the issue
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]
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
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