See also: IRC log
<scribe> ACTION: yves to check if the latest editors' drafts link on our homepage to XOP/MTOM/RRSHB is correct [recorded in http://www.w3.org/2006/08/09-xmlprotocol-minutes.html#action01]
<scribe> ACTION: yves to figure out where the latest editors drafts of the schema are [recorded in http://www.w3.org/2006/08/09-xmlprotocol-minutes.html#action02]
chris reviews the agenda
<scribe> ACTION: chris to ping daveh on whether he is on vacation [recorded in http://www.w3.org/2006/08/09-xmlprotocol-minutes.html#action03]
no AOB
chris: we won't meet next week
DaveO to add InboundMessage property to rationalize props for
sender/receiver [recorded in
http://www.w3.org/2006/07/26-xmlprotocol-minutes.html#action02]
<scribe> done
DaveO to remove state property and clarify that inboundMessage
property is only filled in upon the successful receipt of a message
[recorded in
http://www.w3.org/2006/07/26-xmlprotocol-minutes.html#action03]
<scribe> DONE
chris: email in part trios captures all the changes that need to be made
<scribe> ACTION: chris to follow with Noah and get the correct URL for the part2 xml (with Noah's changes) [recorded in http://www.w3.org/2006/08/09-xmlprotocol-minutes.html#action04]
Everybody in agreement with part trios
<scribe> ACTION: anish to apply changes to the xml as outlined in part trios [recorded in http://www.w3.org/2006/08/09-xmlprotocol-minutes.html#action05]
Chris: in part deux email, i have a proposed
amendment
... not normative is misleading
part deux: http://lists.w3.org/Archives/Public/xml-dist-app/2006Aug/0008.html
Chris: Noah's response to this -- not totally supportive.
Noah's response: http://lists.w3.org/Archives/Public/xml-dist-app/2006Aug/0010.html
Yves: noah's distinction is on the sender of 202 not being a soap node
Chris: thinking in terms of reliable messaging. we want the message to be processed per the soap processing model
Yves: if it is a real soap reply, it should not use 202.
Chris: not a response to the soap request, but
related. Can be an ack
... it may or may not be acking the request message but another one in the
sequence
... for the binding to say that you don't have to do that is problematic
Marc: it is a soap message and needs to be processed.
Anish: in case of 202, either there is a soap
message coming back or not. In case there is a soap message coming back then
the receiver is clearly a soap node
... if there isn't a soap message in the http response, then we have no clue
about whether anybody has processed the msg or not
... all we know is that it was received
... so saying anything about what Noah is talking about buys us anything
Pete: no strong opinion. Noah's concern is valid and would like to say as little as possible about normative behavior
DaveO: 2 weeks ago we had 2 changes. One about
the state to be removed from the properties (the 2 AIs). Done.
... there were ed comments from Noah
Dave0: will do the break in the property
description. Minor editorial items to be done.
... daveh had 4 more items which we have to go through
http://lists.w3.org/Archives/Public/xml-dist-app/2006Jul/0006.html
DaveO: of the 7 bullets, we agreed on two and I
have already folded them in
... 1st bullet is done
... 2nd bullet is done
... 3rd bullet is a good point
Chris: need to look at this more closely
daveo: this is a cut-and-paste from part2
... if we have a problem here, it is a problem for part 2 too
More discussion on what is in part 2
daveo: there are transmission and exchange
failure defined
... this is a good catch by daveh
chris: looks like we don't need that property
daveo: the reason for 2 values in req-res is
that one is about transmission failure in the requesting state and the
exchnageFailure occurs in the sending+receiving state
... we don't have those two states
... we might want to have a single value for the failureReason
Chris: without the state tables it is not very relevant
Marc: i think so, trying to go thru the docs. Sounds reasonable
daveo: although it is nice to have common
things (failure reason) across MEPs
... talked myself into it, I agree that we should remove this
<scribe> ACTION: daveo to respond to daveh's 3rd bullet saying that the property will be removed [recorded in http://www.w3.org/2006/08/09-xmlprotocol-minutes.html#action06]
Chris: bullet 4 is the same as bullet 3, so that is resolved
dave0: for bullet 5, i think we already dropped the properties
Chris: not sure if he means all the props or only those props
Daveo: he can come back and tell us if he meant all the props
Chris: ok
... bullet 6, not sure if this needs to be changed
daveo: in the multicast scenario, how may
instances of meps are in play?
... from the sending side there is only one MEP, on each receiving side there
is another instance. So, if there are 2 receivers then there are 2
isntances.
... what he is saying is that, get rid of scope of one-way mep (part3 ed
draft) in 2.2 (3rd sentence)
chris: or could be zero or more receiving soap
nodes
... isn't this a function of the binding?
daveo: lets have a 'a receiving node'
... more cases of 'the receiver' -- 3 cases. Need to change it to 'a'
<cferris> ACTION 6 = daveo to respond to daveh's note with a revised version of the part 3 ed addressing daveh's and noah's comments
chris: no call next week
... will have a call the following week
... everybody should review daveo's draft on the list
... have comments in the next 2 weeks or we go to WD
... adjourned