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

["Durand, Jacques R." <JDurand@us.fujitsu.com>]

----- 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."