Proposed resolutions for ChrisF issues 3,4,6,8,10

[Doug Bunting <Doug.Bunting@Sun.COM>]

3) lines 151/5 and 250/1 should have a normative reference to the OASIS
SOAP Message Security 1.0 spec not "WS-Security"

==> As agreed (I believe) during the teleconference, make the change Chris 
suggested and reference the specification in both places using the correct 
term.

4) line 489/90 reads: ... Why is this only a RECOMMENDATION?
"It is RECOMMENDED to NOTresend a message for which an RM-Reply with one of 
the following Fault types has been received:".

==> change to

"A Sending RMP MUST NOT resend a message for which it has received an 
RM-Reply with one of the following Fault types:"

I am not sure where group termination due to an error should be covered 
though expect that would be somewhere in chapter 5.  I do agree both the 
sending and receiving RMP should terminate a group as soon as such a fault 
is identified (for the receiving RMP) or received (for the sending RMP). 
This is complicated because the sending RMP may have to retry or poll 
before it shares this understanding, meaning the receiving RMP cannot 
"forget" the group immediately.

6) line 171/2 defines the term "reliable message". This seems unnecessary.

==> change
"Reliable Message:
A message for which some level of reliable delivery is required."

to

"Reliable Message:
A SOAP message containing a <wsr:Request> header block."

Note: I am comfortable with mixing such concrete definitions with the 
various abstract terms we use to illustrate our model.  If others would 
prefer our definitions have a consistent abstraction level, what do they 
suggest for this definition?

8) line 217 [actually 221-225] defines the term "PollRequest Message" ... 
leave out the embellishments.

==> change
"PollRequest Message:
A polling message for Acknowledgment Indication(s). A Sending RMP may send 
a PollRequest Message for polling of Acknowledgment Indication(s) 
regardless of RM-Reply Pattern of the original Reliable Message. For 
example, the Sending RMP may send PollRequest Message to retrieve 
Acknowledgment Indication for a message originally sent using Callback 
RM-Reply Pattern."

to

"PollRequest Message:
A message the Sending RMP sends to the Receiving RMP, requesting RM-Replies 
for identified earlier Reliable Messages.  Support for this message is 
REQUIRED as part of the Poll RM-Reply pattern (see section 2.5.3).  This 
message MAY also be used to augment other RM-Reply patterns."

10) line 265/8 reads: ... getting perilously close to implementation detail
"An RMP which supports both Submit and Notify MUST be able to associate a 
failure notification (Notify) with the related submitted payload(Submit). 
In case the notification of payload is supported, the RMP MUST be able to 
associate a received payload(Notify) with a previously submitted 
payload(Submit)."

==> This text or something similar was the subject of an earlier discussion 
in the TC which may not have completed to everyone's satisfaction.  I would 
prefer deleting this paragraph.  It is only an indication to the developer 
how to design their API were they to choose a direct rendering of the RMP 
component.

thanx,
	doug