Re: [wsrm] Comments on CD 0.992

["Alan Weissberger" <ajwdct@technologist.com>]

All

Sorry these are late, but there were a few internal issues that needed to be settled before I could send them out.

The comments below are my own, and have not been reviewed yet.  Hopefully, we can address them on tomorrow's telecon

1.  Section 1.4 Relation to Other Specs

In my opinion, we should create a TC document on this topic.  The competition calls it "composability" and insists that there WSRM spec is NOT finished until all aspects of composability have been considered.

On line 144 it says that WS Reliability can be used with WS Security-WSS (which I think has now been completed in OASIS and a BSP working draft is available from WS-I).  How?  What reply patterns, configuration parameters, protocol capabilities are needed for each WSS message type?  I think this is one of the most important applications of WS Reliability, but no one is looking at it (vs competition looking at composing WSS with WSRM)

 

2.  Section 1.7.2 RM Agreement Items: Setting, conveying, or changing the Agreement items listed here, is beyound the scope of this specification.

Line 408-406:  If a reply pattern is sent that had not been previously agreed upon, it will be rejected, with a Fault message: Non Supported Feature returned to the sender

3.  Section 1.7.3  Messaging Scope of Agreement items:  For all scopes:  Setting, conveying, or changing the Agreement items listed here, is beyound the scope of this specification.

Need clarification:  Are the values for parameters in message scope (s3) and/or Group scope (s2) related to a particular Reply pattern or are the values the same for ALL Reply patterns over the same binding/ transport connection between sender and receiver????????

4.  Section 3.3. Guaranteed Message Ordering Failure Case

Line 563-565:  Is the decision to abort ordered delivery totally implementation dependent?  Can we specify a Maximum Persistance time parameter for a received out of order message, so that after that time receiver aborts ordered delivery.  Otherwise, a skimpy implementation could give up almost immediately vs a robust implementation trying to recover for a much longer time after receiving multiple out of order messages without receiving any retransmitted sequential messages

What Fault code is sent back to sender after aborting ordered delivery? Is it Permanent Processing Failure?

THIS BRINGS UP ANOTHER HUGE PROBLEM WITH THIS SPEC:  THERE IS LITTLE OR NO MENTION IN THE TEXT OF WHICH FAULT CODES TO SEND FOR A GIVEN PROBLEM.  ALSO, IT WOULD BE NICE TO HAVE A CAUSE CODE/ FIELD TO PROVIDE FURTHER GRANULARITY AS TO THE PRECISE CAUSE OF THE FAULT.

5.  Line 726: groupExpiry Time attribute:

Clarification:  No mention whether this parameter can be changed.  Suggest forward reference to line 1148- 1149. 6. Line 1148- 1149

6.  Line 1148- 1149  d) changing Group Expiry time 

It would be most helpful to provide 2 examples illustrating the change of Group Expiry time when sending sequential messages:

-one correct/ permitted change;  the other incorrect (decremented below Max Value of Expiry time)

Clarification:  What is the relationship between Expity time (section 4.2.2)  and Group Expiry time (line 726), i.e. why are they dependent here?  While Group Expiry time can be modified,  Expiry time (only sent in Request messages) can not be modified.  I always thought that Expiry time was sent in a single Request message while Group Expiry time was sent in each sequential Reply message of a Group.  In other words, they would never be sent in same direction

7.  Suggestion:  WSRM TC should consider producing a new document: An Implementors/ Users Guide to WS Reliability.

This would better explain how to use the protocol features, tips on setting and conveying configuration parameters, and how WS Reliability would communicate with WS Applications via platform neutral APIs (primitives and parameters in OSI sense).  This document could also be referenced by the proposed Relation of WS Reliability to other WS Specifications (e.g. Security, Distributed Management, etc)- see 1.  above

 

alan