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