Proposals for issues 009,083,092,097 + some edits on WD16

----- 
Core issue 009: Already partially 
addressed. In addition, At the end of 3.1, add:

"A Sending MSH MUST be 
able to determine whether a submitted message should be pulled or 
pushed, and which Message Partition Flow (MPF) it 
must be assigned to. Similarly, the Receiving MSH is aware of which 
MPF(s) should be pulled from, and which ones will 
be used for push. This knowledge is 
based on an agreement shared between 
parties prior to the exchanges, and modeled in this specification as the P-Mode 
set (see Section 4)."

----- 
Core issue 083: in 
D.2.3:  Update: 

"A payload part is a data structure that consists of 
four properties: name (or Content-ID), MIME data type (text/xml, 
application/pdf, etc.), name of the XML 
Schema file if the MIME data type is text/xml, and a Boolean value 
indicating whether the part is expected or 
optional, within the User message."

as:

"A payload part is a data structure that consists of 
five properties: name (or Content-ID), MIME data type (text/xml, 
application/pdf, etc.), name of the XML 
Schema file if the MIME data type is text/xml, maximum size in Kb, and a Boolean 
value indicating whether the part is 
expected or optional, within the User message."

Also add one parameter to BusinessInfo:

PMode[1].BusinessInfo.PayloadProfile.maxSize: This parameter allows for 
specifying a maximum size in Kb for the entire payload, i.e. for the total of all payload 
parts.

----- 
Core issue 092 + 097: B.2 ReliableMessaging binding:

Add intro just under B.2 title:

" Note: This section is based on the Committee Draft 
4 (August 2006) of the WS-ReliableMessaging 
specification [WSRMCD4], and conforming to the more recent revision 
resulting from public review - WD 16, October 31, 2006. It is possible that some update will be 
required in order to conform with the final release of WS-ReliableMessaging as 
OASIS Standard. It is expected that such 
updates - if any - will be minor and can be handled via the errata process." 

Also replace L1956:

" It is not required that WS-ReliableMessaging 
implementations support the wsrm:MakeConnection feature, when used in an MSH. In case MakeConnection is 
not supported, then the two following requirements apply:"

with:

"In case pulled messages must be sent reliably, the 
two following requirements apply:"

Also replace L1959:

"A CloseSequence message or a TerminateSequence 
SHOULD be sent piggybacked over the response to a PullRequest, along with the EmptyMessagePartitionFlow warning 
(EBMS:0006)."

with:

"When the Sending MSH decides to terminate a reliable 
sequence of pulled messages, a CloseSequence message or a 
TerminateSequence SHOULD be sent over a pulled message or a pulled signal - 
e.g. piggybacked over the EmptyMessagePartitionFlow warning 
(EBMS:0006)."

NOTE: About the current ed. note at beginning of B.2.1: because 
message processing failures have virtually no chance to get fixed by resending, 
it seems appropriate to escalate Faults even if resending is not over (also may be hard to figure when 
the resending wil be over).

--------- editorial issues on WD16:

L625: Replace:

" When sending a PullRequest signal, the name of the 
MPF to pull messages from must be specified" 

with:

" When sending a PullRequest signal, the name of the 
MPF to pull messages from must be specified unless it is the default" 

 

In 2.2.3: lack of clear definition of " 
back-channel", need to update w/r to 
current discussion in WS-RX:

Update the definition of 2-way protocol (1st bullet 
of " notes" ):

" An underlying transport protocol is qualified of 
"2-way" if: (a) it guarantees a channel 
for transferring the response of every message (request) initiated by an MSH, 
back to this MSH without need 
for explicit addressing 
information in SOAP headers and 
regardless of connectivity restrictions such as inability to accept incoming new connections, and (b) it 
provides some means to the MSH initiator of the exchange for correlating the 
response with the request, without 
relying on the SOAP header. For example, HTTP qualifies as 2-way, but SMTP and 
FTP do not (although FTP has a notion of 
session, it does not inherently support the coupling of (b)). The channel 
offered in (a) is also called back-channel 
in this specification."