Comments sent on behalf of Sunil

["Bob Freund" <Bob.Freund@hitachisoftware.com>]

More editorial comments:

 

1.  Example Changes:

-         -         XML payload uses namespace prefixes such as xlink, xsi, schemaLocation which are never used.

-         -         HTTP Headers for RM Requests mention a POST with a ‘/abc/servlet/wsrListner’. It will be good to make it more meaningful such as ‘/abc/servlet/wsrEndpoint’ or ‘/abc/servlet/wsrExampleEndpoint’.

-         -         For Callbacks, response POST context URI doesn’t match the replyTo URI in the request

-         -         Why did we have 2 separate examples (Example 3 for Ack and Example 4 for Fault) for the same Poll Request (Example 3). It will be good if we can collapse Example 4 into Example 3 by adding the ReplyRange sub-element (for msg. 15) into Example 3’s <SequenceReplies> element.

-         -         It will be good to add the attribute last=’true’ to the 3^rd Message in Example 6 (SequenceNum Element). This way we will have illustrative example to show the usage of this (‘last’) attribute.

 

2. Figure Updates:

Most of the figures use the word ‘Application Layer’, we need to better quantify what we mean by ‘Application Layer’ or say something like ‘Application Layer/SOAP Processor’.

 

3. Chapter 1/Section 1.6/Polling RM-Reply pattern/Line 352

Just add the word “poll” to better qualify it, i.e., make it “contained in the underlying protocol response to this poll request or in a separate …”

 

4. Chapter 2/Section 2.3/Lines 483.

Line 483 states “This Message Identifier relies on the notion of group. A message always belongs to a group”.

 

The above is incorrect. A message can be independent/singleton or in a group.

We need to reword it.

 

5. mustUnderstand attribute used in tables 1, 9,12 must use lower case ‘m’ for mustUnderstand. It will be much better if we can qualify it as soap:mustUnderstand so as to distinguish this attribute with other RM specific attributes.

 

6. Chapter 4/Section 4.2.1.1/’number’ attribute.

Reference to number attribute on lines (734,735) should start with a lower case ‘n’.

 

Lines 732-733 should be changed as follows:

The value of this attribute MUST be unique within the same group, and the combination of MessageId’s groupId attribute value and SequenceNum’s number attribute  MUST be globally unique to be used as a Message Identifier.

 

7. Chapter 4/Section 4.2.1.1/’last’ attribute/Lines 751-758

-         -         ‘False’/’True’ should be ‘false’ & ‘true’

-         -         We also need to mention that this attribute doesn’t exist, then it defaults to false, i.e., it is not the last message in the group.

 

We also need to mention that the first message in the group can also have this attribute with a value ‘true’, i.e., to indicate the first message in the group is also the last message, something similar to a singleton message.

 

8.      8.      Section 4.4/Response Element.

Comments on replyPattern

1)      1)      replyPattern on line 908 must start with a lower case ‘r’

2)      2)      Did we decide that this is optional? I remember being it  mandatory to avoid potential errors. Schema says it mandatory.

 

Mention the cardinality of attribute clearly when describing the attribute itself. We do mention sometimes at the element (that has this attribute) level. Examples:

1)      1)      Mention that replyPattern attribute (line 937) is a MUST (see above comments).

2)      2)      Mention that groupId attribute of NonSequenceReply (line 961) is a MUST.

3)      3)      Mention that groupId attribute of SequenceReplies (line 972) is a MUST.

4)      4)      Mention that the fault attribute of ReplyRange element is optional (Line 992)

 

9.      9.      Section 4.4.1 (NonSequenceReply)

While the ‘fault’ attribute is listed in Table 13, it is not described below. We need to describe this something similar to ‘fault’ (lines 992-995) attribute for ReplyRange. We need to mention that this is optional too.

 

10.  10.  Section 4.5/Fault Codes/Lines 1008-1012.

I think this paragraph needs to be reworded. A suggested one would be:

 

The SOAP Fault model was not used to report RM Faults is because:

-         -         SOAP Fault model doesn’t support batching of Faults which this protocol requires.

-         -         While it is not illegal to send a Fault in a Request,  it is unconventional to send a Fault in a request message.

 

Because we didn’t want to use SOAP Fault model for few allowed cases and use RM Fault model for other cases, we consolidated into just one model.

 

11.  11.  Section 4.5.1/Line 1037 should be: “Invalid Message Format Faults”. (plural Faults).

 

12. Will the final version have Appendix C(Revision History)? If not, could we remove it from the specification move it to a different document.