proposed replacement for 3rd para sect 2.2 oneway mep

Regarding WSDL comment #5: 
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4405

I took an AI to re-write the 3rd paragraph in section 2.2. 

Old:

A receiving node MUST determine whether a given message is successfully 
received, and if so, 
MUST populate http://www.w3.org/2003/05/soap/mep/InboundMessage with the 
received message 
and MUST process the message in 
http://www.w3.org/2003/05/soap/mep/InboundMessage according 
to the SOAP Processing Model (see SOAP 1.2 Part 1 [SOAP Part 1]Processing 
SOAP messages). 
Determination of success by a receiver MAY be conservative, I.e. a 
receiver may in exceptional 
circumstances treat as erroneous or lost a message which is received 
intact (typical reasons for 
making such decisions might include shortage of buffer space, network 
interface overruns, etc.). 
A receiver MAY fault in a binding-specific manner if some particular 
message is declared in error 
(note, however, that in many cases where receipt is unsuccessful, 
information identifying the
message or its sender may be unreliable, in which case there may be little 
if any value in reflecting 
a message-specific fault.) 

New:

When a message is successfully received by a SOAP node, that node MUST 
populate
http://www.w3.org/2003/05/soap/mep/InboundMessage with the received 
message and 
MUST process the message in 
http://www.w3.org/2003/05/soap/mep/InboundMessage 
according to the SOAP Processing Model (see SOAP 1.2 Part 1 [SOAP Part 1]
Processing SOAP messages). 
A receiving node is given certain latitude in  determining success 
criteria for receipt of a message. E.g. a receiver 
might, in exceptional circumstances, treat as erroneous, or lost, a 
message that has been received intact. 
Typical reasons for making such decisions might include shortage of buffer 
space, network interface overruns, etc.. 
A receiver MAY fault in a binding-specific manner if some particular 
message is determined to have been 
unsuccessfully received (note, however, that in many cases where receipt 
is unsuccessful, information 
identifying the message or its sender may be unreliable, in which case 
there may be little if any value 
in reflecting a message-specific fault.) 

Cheers,

Christopher Ferris
STSM, Software Group Standards Strategy
email: chrisfer@us.ibm.com
blog: http://www.ibm.com/developerworks/blogs/page/chrisferris
phone: +1 508 377 9295