XML Protocol Teleconference

 

<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]

agenda bashing

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

AI review

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

Status of SOAP1.2 PER

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

Status and discussion of oneway MEP draft

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