See also: IRC log
<scribe> scribe: prasad
2. Agenda review, AOB
Mark review agenda
3. Call for corrections to the minutes
resolution: approved minutes of dec 12 05
4. Review action items
Anish: Issue is still open
... issue to resolve in soap 1.2 erratum or in the new XMLP work
Anish: We initially did not want to fix in errata as it impacts too much in the spec. But Noah may have changed mind
DHull: I was on the XMLP call. Noah thinks can be done in erratum. Does not see a need for one-way MEP
<RalphS_> sorry for the inconvenience, folks
Umit: When is the decision on errata vs new work going to be made?
Anish: I don't think it is either or
prank call ?
<dorchard> please paste # into irc
<marc> did someone get that number ?
<mnot_2> +1 866 214 3176 (US)
<mnot_2> +1 404 827 9098 (non-US)
<mnot_2> Access Code: 2979273
<TRutt> sounds like downs syndrome to me
swithing over to other line
<TRutt> Host not yet arrived
Trutt: Distingushing reliable vs non-reliable transports is important
DHull: Do we really need one-way MEP from XMLP?
Anish: One-Way MEP in Errata or new effort?
DaveO: Real question is req optional response good enough?
<dorchard> Seems to me that wsdl one-way could map to soap request-optional-response mep.
<dorchard> And I'd rather not "hijack" this discussion to meet some other requirement.
<dhull> cheese sandwich with no bread
Umit: Is whats on the table maping WSDL MEP to SOAP optional resp
dhull: believe so, not sure
mnot: No feed back at this pint to XMLP. Moving on
DHull: We can set the expectation as our feedback
Mnot: Where are we on that
Paul: Probably on track
... MS put out two end points. IBM put out a web page
... some test broke; trying to fix
Mnot: Plan to do some tests end-to-end for the vancouver f2f
7. Working Draft Issues
Mnot: We split i59 into three parts last week
<dorchard> For the record, I haven't had a chance to review the umit's proposal because it arrived on Sunday night.
Mnot: i67 and i68 in addtion to i59
Mnot: Umit has a new
... Too many Proposals and status is confusing
Marsh: Proposal does not seem
... If I have a method tht has a reply and fault and one of them is anonymous am i required to generate a fault?
<dorchard> Seems to me that Jonathan's concerns about fault handling might need to be handled by a new issue.
<dhull> fault goes back as transport-level response (if available). After we understand WSA headers and WSA is engaged, anonymous means "response channel"
<dhull> +1 to DaveO
<dhull> prohibited is currently defined in terms of what may appear (not what is used)
<anish> +1 to daveo
<dhull> +1 to anish
<anish> difference between generating a fault and sending a fault
discussion on malformed fault handling
scribe: between umit, Marsh and others
<dhull> Let's not say "anonymous" so much here. Back-channel, response or whatever makes sense outside of WSA. "Anonymous" only means anything in WSA.
Marc: We provide two ways to do using addressing and in SOAP module we don not proide a way to do anonymous equivalent
<anish> you could use a property
Mnot: Can do discuss this in i67?
DaveO: U can set properties but, properties are global and not scoped to an operation
<Zakim> dorchard, you wanted to mention that SOAP already has this problem, and it says that faults may or may not be delivered... c'est la vie.
<uyalcina> it is not as is. You can always raise issues about the wording.
<mnot> ACTION: Umit to incorporate anon element into example 3-3 in conjunction with wsoap:module [recorded in http://www.w3.org/2005/12/19-ws-Addr-minutes.html#action01]
Anish: asks for examples in section 3-3 use of anonymous element in conjunction with SOAP module
Marc: Concerned with including text in section 3.4
MNot: None questioned 3.4 so far
Mnot: Like to close i59 with Umit's proposal with the "anonymous text" in 3.3 deleted and examples added, text in section 3.4 is subject to editorial update.
Marc: 3.4 is not going in the doc?
MNot: It is, but can raise issues againt it.
Umit: Why don't we add an editoril note in section 3.4 that the folllowing text is subject to change?
<dorchard> Why not just accept up to 3.4? 3.4 is easily talked about in email/proposals.
<dhull> 3.4.1 captures one useful scenario. OK with noting that, but there are useful scenarios that conflict with that text. OK with 3.4.1 as long as it's clearly scoped
<bob> +1 Katy
Katy: Likes Umit's proposal
MArc: uncomfortable with putting 3.4 in spec
Mnot: That is a separate issue
<uyalcina> Not accepting 3.4 is mixed with the concept of putting it to a different document. This is not a content issue.
TRutt: I would go with putting in 3.4 with a disclaimer
Anish: Adding a note seems a reasonable way fwd
Marsh: When there is no consensus
what is the status quo? What is in the doc ?
... What we have not agreed to should not be in the doc
<pauld> +1 to Jonathan - the document should reflect the Status Quo, not least for generating test cases
<Zakim> dhull, you wanted to clarify discomfort with 3.4.1
<dorchard> +1 to Jonathan on declaring victory up to 3.4
<Zakim> anish, you wanted to ask about "empty SOAP envelope in section 3.4
Anish: In 3.4.1 2nd sub-bullet 1. What is "empty SOAP Env"? Empty HTTP entity Body, with SOAP hdrs ?
Marc / Umit: we need another issue on this
Umit: Options: Don't say anything
about SOAP 1.1 HTTP binding; put text with disclaimers..
... I am infavor of putting in w/ disclaimer
Marc: Can we find in the minutes what we agreed to?
Paco: What we agreed to at the f2f is status quo
Trutt: Text in 3.4 reflects what we agreed in the meeting
<dhull> In other words, the rule is, if you get a message over HTTP, you *must* send something back (which is what HTTP demands anyway). If you don't know what to say, send an empty 202.
MNot: proposes we accept as resolution for i59 all changes in Umit's proposal upto section 3.2 and editor's recollection of what we agreed to at f2f ...
Anish: what about examples?
Mnot: Those included
<dorchard> Marc, Mark said "upto section 3.4 "
Mnot: Any objections to proposal?
Marsh: I object
Taking a formal vote
<dorchard> why are people abstaining?
<dorchard> Is it because not enough text going in? Or too much?
Yes - 10; No -2; Abs - 3;
Mnot: Motion Carries; i59 is closed
No meeting next 2 weeks. Reconvene Jan 9th