Re: [wsrm] comments on ws-r 1.05

[Christopher B Ferris <chrisfer@us.ibm.com>]

Tom,

More comments on v1.05.

36) line 1081 (table) specifies that an InvalidRequest fault is returned 
for a wsrm:Request element that did not have soap:mustUnderstand=true 
specified. Please explain to me how a conformant SOAP node is required to 
catch this? SOAP says that header blocks that are not mandatory can be 
ignored. Why isn't the ws-r spec simply leveraging the SOAP protocol as 
intended?

37) line 1081 (table) specifies an InvalidMessageId fault and says: "This 
fault is sent in any of the following cases:
        1. If @groupId (for MessageId or
        RefToMessageIds ) doesn’t exist, or if exists, and
        the value is wrong or invalid.
        2. If number attribute in SequenceNum element
        doesn’t exist, or if exist, the value is invalid or
        wrong.
        3. Attributes (from and to) of SequenceNumRange
        doesn’t exist, or if exists, the values are invalid or
        wrong."
Unless I am missing something fundamental, a sending RMP can assign new 
@group for any message. Thus, it seems to me that the protocol as 
specified here requires that the receiving RMP fault for every new value 
of @group received. This seems rather odd. Further more, it seems to 
suggest that every message in a sequence should be faulted because from 
the receiving RMP's perspective, the sequence number doesn't exist. 
Finally, when requesting a PollRequest, it seems to suggest that if the 
request covered messages that the receiving RMP had never received that it 
is supposed to respond with an InvalidMessageId fault rather than simply 
not acknowledging the messages.

38) line 1086 (table) defines the "NonSupportedFeature" fault. How is the 
sending RMP supposed to interpret the fault? (e.g. how does it know which 
feature it requested is unsupported?

39) line 1086 (table) defines both "PermanentProcessingFailure" and 
"GroupAborted". When would a "PermanentProcessingFailure" not result in 
the group being aborted?

40) line 1188 reads: 
        "a) the First message in a group (the one with 
Request/MessageId/SequenceNum/@number=0)
        MUST be used by the Sending RMP to indicate that timeout 
parameters are in use for the group."
What happens when the first message sent is not the first message 
received? Why isn't this constraint stipulated in section 4.2? You cannot 
make an assumption that the first message transmitted will be the first 
message received.

41) line 1195 reads:
        "A fault MUST be returned if both group persistence parameters are 
present in any
        request message. An InvalidMessageParameters fault shall be sent 
in this case."
which is redundant to a certain degree with 4.5.1 but this constraint 
should probably have been made back in section 4.2.1.2 where these 
attributes are defined. 

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295