[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] comments on ws-r 1.05
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]