Proposals to close Issues rel 59-62 and 66-79

[Tom Rutt <tom@coastin.com>]

Attached is an html file which has my proposed resolutions.

Issues 62 and 78 required further discussion.  The rest are not 
controversial, in my opinion.


-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Title: 8

1         Issues on Meeting Requirements

1.1      REL-59  Meet Architectural, R1.1 requirement

Description: The implementation of the specification must fit into a layered architecture where WS-Reliability is a communication layer between the application and the SOAP layer.

Proposal: Close as accommodated by WS-Reliability spec

Resolution: 

1.2      REL-60  Meet Architectural, R1.2 requirement

Description: The Specification must only support end-to-end reliable messaging, where one end is the sender, and the other end is the ultimate destionation. (see also issue REL-8)

Proposal: Close as accommodated by WS-Reliability spec

Resolution:

1.3      REL-61  Meet Usage of XML, R2.1 requirement

Description: XML Schemas delivered by the Specification must accommodate additional attributes and elements from a different namespace than the target namespace. (see also issue REL-55)

Proposal: Close as accommodated by WS-Reliability spec, since the schema is designed for extensibility of attributes and elements.

Resolution:

1.4      REL-62  Meet Usage of SOAP, R3.1 requirement

Description: The Specification must adhere to the SOAP message construction rules. The basic messages generated by any implementation of the Specification must be compliant to the either the SOAP 1.1 or SOAP 1.2 message format.

R3.1.1

The Specification must prescribe the usage of the different SOAP versions in a consistent way. Therefore, it must be forbidden to mix different SOAP versions.

R3.1.1.1

The Specification must define separate XML Schemas for use with SOAP version 1.1 and for use with SOAP version 1.2. (see also issue SOAP-1)

Proposal:  Spec will include both soap 1.1 and Soap 1.2 Schema.  Need discussion of details before closing issue.

Resolution:

1.5      REL-66  Meet Transport bindings, R4.1 requirement

Description: The Specification must be SOAP transport binding neutral.

R4.1.1

The Specifiction must support standard HTTP bindings defined in [SOAP11] and [SOAP12-2].

R4.1.1.1

The Specification must not preclude other SOAP transport bindings. (see also issue REL-3)

Proposal: Close as accommodated by WS-Reliability spec

Resolution:

1.6      REL-67  Meet Transport bindings, R4.2 requirement

Description: All that is expected of the transport layer is that it will not deliver a corrupted message to the reliability layer. (see also issue REL-12)

Proposal: Close as accommodated by WS-Reliability spec

Resolution:

1.7      REL-68  Meet Reliability features, R5.1 requirement

Description: The Specification must address Guaranteed Delivery as a reliability feature. The participating entities must be able to ensure that all application-level information to be sent to the party has actually been received or error reported.

Proposal: Close as accommodated by WS-Reliability spec

Resolution:

1.8      REL-69  Meet Reliability features, R5.2 requirement

Description: The Specification must address Duplicate Elimination as a reliability feature. The participating entities must be able to ensure that all duplicated application-level information is filtered out during the information exchange and is not received as duplicated.

Proposal: Close as accommodated by WS-Reliability spec

Resolution:

1.9      REL-70  Meet Reliability features, R5.3 requirement

Description: The Specification must address Ordering as a reliability feature.

R5.3.1

Ordering feature is associated with a pair of WSRM-capable, communicating nodes. Order of MEPs must be guaranteed to be preserved between these two nodes.

R5.3.2

Multiple concurrent sequences of messages between same two endpoints must be supported by the Specification.

Proposal: Close as accommodated by WS-Reliability spec

Resolution:

1.10REL-71  Meet Reliability features, R5.4 requirement

Description: It must be possible to use different combinations of the functionalities in R5.1, R5.2, R5.3.

R5.4.1

Duplicate Elimination must be possible to be used without Ordering.

R5.4.2

Duplicate Elimination must be possible to be used without Guaranteed delivery.

R5.4.3

Guaranteed delivery must be possible to be used without Duplicate Elimination.

R5.4.4

Guaranteed delivery must be possible to be used without Ordering.

Proposal: Close as accommodated by WS-Reliability spec

Resolution:

1.11REL-72  Meet Backward compatibility, R6.1 requirement

Description: A Web Services stack with an implementation of the Standard must not offer less capabilities than a Web Services stack without the implementation of the standard.

Proposal: Close as accommodated by WS-Reliability spec

Resolution:

1.12REL-73  Meet Backward compatibility, R6.2 requirement

Description: Specification should ensure WS-Reliability sender knows "immediately" that it is interacting with a non-WS-Reliability recipient. (see also issue REL-7)

Proposal:.  Close as accommodated by WS-Reliability spec, since Soap mustUnderstand=1 in the soap header elements in the schema

Resolution:

1.13REL-74  Meet Realization, R7.1 (piggybacking) requirement

Description: The Specification shall allow bundling an acknowledgment for an earlier message with a request for an acknowledgment for another message. (see also issue REL-18)

Proposal: Close as accommodated by WS-Reliability spec.

Resolution:

1.14REL-75  Meet Realization, R7.2 (multiple ack) requirement

Description: The Specification must support the multiple acknowledgement feature, when several SOAP messages are acknowledged in one SOAP message. (see also issue REL-26)

R7.2.1

Every implementation must be able to receive, and every implementation may be able to send multiple acknowledgements.

 

Issue originator (Iwasa) suggested we could have conformance based on feature: eg:

- acknowledgment conformance class

- acnlowledged duplicate conformance class

- acknolwedged duplicatate elimination and ordered delivery conformance class

 

Now the next question is if we need to further parameterize our conformance claims by the RM-Reply patterns supported by an implementation:

- response reply pattern

- callback reply pattern

- poll reply pattern

 

And then again we have the support for request/response WSDL operation type. Is this going to be another conformance point parameter. Thus we have 3 by 3 by 2 conformance matrix. How many of those 3D matrix cells do we want to give separate names to?

Proposed Resolution: use the same syntax for batching acks in all the patterns (mail)

 

Proposal: Close as accommodated by WS-Reliability spec, since the callback and Polling reply patterns support this requirement.  However, it cannot be supported for wsdl request response operations

Resolution:

1.15REL-76  Meet Realization, R7.3 requirement

Description: Spec must support ability of sender to ask the receiver if one or more of its sent messages have been received. (see also issue REL-43)

R7.3.1

The Specification must define a solution for sender to receive delayed Acks, when it is not willing to receive underlying protocol requests, for one-way MEP. (see also issue REL-19)

Proposal:  Close as accommodated by WS-Reliability spec, since Polling reply pattern can be used to meet this requirement.  However, the spec does not yet support a general query for messages not sent using the poll reply pattern.

Resolution:

1.16REL-77  Meet Realization, R7.4 requirement

Description: The Specification must describe the semantics of Reliable Messaging processing parameters that affect both sides of the protocol.

Proposal: Close as accommodated by WS-Reliability spec

Resolution:

1.17REL-78  Meet Compatibility, R8.1 requirement

Description: The Specification should be usable with other open standard technologies, if appropriate.

R8.1.1

The Specification shall not preclude the use of Web Service message attachments. (see also issue REL-10)

R8.1.2

Insure that the Specification is usable in combination with WSS SOAP Message Security to implement secure reliable messaging. (see also issue REL-25)

: Attachments split to new issue REL-100

Proposal: Need to do one last check if our schema are compatible with WS-Security.

Resolution:

1.18REL-79  Meet Fault handling, R9.1 requirement

Description: WSRM spec must identify fault cases and WSRM protocol must support the reporting of these identified faults. (see also issue REL-15)

Proposal: Close as accommodated by WS-Reliability spec

Resolution: