See also: IRC log
<trackbot> Date: 13 October 2009
<Bob> scribe: Wu Chou
Add issue 7553 to discussion today
Agenda agreed
RESOLUTION: F2F minutes accepted and go final
Bob: Please register to W3C meeting in Nov.
<li> i had nightmare with paypal too in the past
Gil: problem with paypal payment for registration
<dug> Gil - can Jeff pay for you?
Yves: please send email to w3c admin for help.
Bob: Meeting is on Thursday/Friday of that week and may run to the end of the day.
RESOLUTION: no objection, issue 7791 is open.
<dug> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7811
Katy: issue is more editorial regarding to use generic SOAP fault
RESOLUTION: no objection, issue 7811 is opened.
Ram: we need more concrete proposal and some study.
Katy: It would be good if someone else can take a closer look.
Ram: Certainly, we should accept this issue and do some work.
RESOLUTION: no objection, issue 7812 is opened and resolved with the proposal.
<asir> sounds reasonable
RESOLUTION: no objection, issue 7827 is opened and resolved with the proposal.
<asir> related to issue 7588 and Action 113
Gil: I owe group a proposal and my proposal will conform to it.
dug: prefer to have this change first.
RESOLUTION: no objection, issue 7828 is open. It will be reviewed later.
dug: issue 6724 propose close without action.
RESOLUTION: no objection, issue 6724 is closed without action.
<Ram> One more comment: I will ask that the specification clearly specify what the fault sub codes are when the generic fault is raised. That way, it is clear to the implementor what the interoperable behavior is.
Katy: mostly resolved at F2F and working on detailed text.
Bob: have you looked at Ram suggestions?
Katy: it looks good.
Ram: Suggest to clear identify the condition of the fault sub-code.
gpilz: it seems issue with the direction with that two sentences.
ram: how about we work with Katy on the proposal and agree with gil's comment.
dug: propose to close issue 6411 with no action.
RESOLUTION: issue 6411 closed with no action.
<dug> proposal at http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Oct/0018.html
dug: all needs are qname and the proposal is quite straightforward.
daveS: not sure if this is policy
concept and looks more of metadata conecpt.
... the issue has some pieces to break down.
dug: not sure if it is policy or not. Open to suggestions if it is better.
asir: need more time to think about it.
bob: one week time and put in next week call.
dug: not aware with the
interoperablity issue of this type problem.
... propose to close issue 7015 without action.
<gpilz> http://www.wstf.org/docs/scenarios/sc003/endpoints
ram: propose to specify the implementation more clearly on relying wsa:action.
gpilz: did not see the sign of problem in this direction of action and body.
daveS: not clear what is special with transfer that needs this information.
yves: needs a good story of the body wrapper.
<DaveS> dave
tom: agree with dug and not seeing problem.
yves: we need to say what should happen if there is a discrepency between action/body.
<gpilz> http://www.w3.org/2002/ws/ra/edcopies/wst.html#Get
gpilz: yves issue may be addressed in another issue.
<dug> and what if they don't do what we tell them to do in this fault case? how recursive do we get?
gpilz: there is a limit to spec what it should do.
asir: we are happy to work with yves to have a proposal.
bob: sounds there is a separate issue and happy yves and ram to work on a separate new issue to addrss it.
<DaveS> I have looked at Transfer and I will not be raising an issue on fault a missmatch.
<Zakim> Tom_Rutt, you wanted to discuss clarification
<li> wu: it's a good idea for yves and ram to work on the issues
asir: suggest to keep both open and discuss together.
<li> ...asir's idea is good to keep both open until a good solution.
<Yves> suggest to open a new issue, and make 7015 depends on the new issue
<Yves> closing the new issue will close 7015
<gpilz> that's backwards
<gpilz> the new issue exists only if there is a unique soap:Body for each operation
<gpilz> if all the soap:Body's are the same, the new issue doesn't exist
<Yves> well if the resolution of the new issue is satifactory to the people who raised 7015... (that I can't say ;) )
bob: the new issue will depend on resolution issue 7015, is it right?
<asir> 7015 depends on the new issue, rather than the other way around
<Zakim> asir, you wanted to ask Dave a clarification question
daveS: it is clear from the spec that this should not cause problem.
bob: this issue is independent of issue 7015.
asir: we don't these issues are independent.
bob: at this point the issue is not raised yet.
<dug> I'd prefer if we talked about the issue in front of us and not some other, yet to be opened, issue. If this issue needs to morph then CWNA and open a new one.
<Yves> the issue about discrepancy between body and action is because of the duplication of action as a body element
<dug> yves- your issue would exist even if the Body were static across all ops - it could still be mismatched.
<gpilz> as Dave said, the wsa:Action could be "Foo"
<Yves> dug, agreed, if you duplicate action functionnality in body, you always have the issue
<dug> no, duping action has nothing to do with this
daveS: if we resolve to clarify the fault behavor, would it resolve the issue?
<Yves> if you just have action, you don't have that kind of issue
<gpilz> it has nothing to do with the value of soap:Body - it's about whether or not it matches what the spec says
<dug> no matter what wrapper you put in the body you could has the wrong wrapper - hence the issue
<Yves> well, the issue is that you need a wrapper ;)
bob: we have the statement of issue
here, where interoperability is the issue.
... first question if the interoperability described is real.
asir: the use of single wrapper should not be a issue, since the wrapper does not carry any information.
daveS: as spec being written, it should not cause interoperability for complaint implementation.
<gpilz> +1 to Dave
<asoldano> +1 from me too
<dug> "The Get request message MUST be of the following form:...."
<Yves> will compliant implementation _detect_ non compliant messages?
<asir> neither detection nor reporting are part of the spec today
<gpilz> and SOAP doesn't say what happens if I send random ASCII to a SOAP endpoint
<Yves> gil, yes: "Any other malformation of the message construct MUST result in the generation of a fault "
asir: both yeves and I propose to coming back with some text on this issue.
yves: closing this one with no action will not make the point.
bob: how many days to come back with a proposal, asir/yves?
asir: we will try to next week.
<DaveS> +1 to diug. The new issue applies to all the specs. They should be separate.
dug: yves is a separate issue and it should open it separately.
<Bob> issue action and wrapper differ
<Bob> proposal: when that occurs throw a sender fault
<Yves> bob, 22 should be fine by me, but if you want to do smething before that :)
bob: will be a new proposal or new issue?
yves: it is about my issue.
asir: yves and I working on the new issue which will lead to a concensus solution to issue 7015.
bob: the action is: yves and asir have a proposal on Oct. 22.