prelim friday minutes

["Tom Rutt" <tom@coastin.com>]

The prelim friday minutes are attached.



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

Title: *Proposed Agenda:*

WSRM Face To Face

Friday Preliminary Minutes

13   Home work review

13.1New editor’s draft

Iwasa walked thru the new editor’s draft.

 

Sections that need updating

Section 1: 1.6 reference to wsi, 1.7,  1.8 poll request –sunil,

Section 2 – Awiating Jacques homework,  Issue on request response nature

 

 

New Issue

should a Reveiver only update its group termination value for messages which are delivered?

 

Minor edits were done in section 2.

 

ACTION: Iwasa to change, in the first sentence of definition of guranteed delivery to:

“A message submitted to the sending rmp with guaranteed delivery requested, will either be delivered by the receiving rmp, or the sending rmp will notify the submitter of failure. “

 

Changed: “made available” to “delivered” in section s.10.

 

Section 4 needs updating –

 

ACTION: Sunil will provide a new section 4,

 

Section 5 needs to be updated to add examples.

 

Discussion of Tony Graham comments;

Tony sent the following email:  Disposition are shown inline.

Line      Comment

 

263-294           These sections should be moved to after Section 4, SOAP Fault,

            because they use many terms that have not been introduced yet.

 

            This section uses the terms "start", "end", "ExpiryTime",

            "max(ExpiryTime)", "GroupId value", "SequenceNumber

            intervals", "groupExpriryTime", "groupMaxIdleDuration",

            "InvalidGroupParameter fault", "status=start", and

            'status="end"'.  (Note also the absence of quotes around

            "start" and their presence around "end".)

to be accommodated by Jacques homework

 

269            Should “Group Termination and State Removal Criteria” be a

            section title?

Already fixed

 

542, 721

        The text does not indicate that PollRequest can appear more

        than once in a SOAP Header.

 

Add NEW ISSUE:  Can header elements be present more than once.

Sunil moves to close issue with answer no.  Iwasa Seconded.

 

No opposition motion passes. 

 

Completed issue,

 

Action: Iwasa to add sentence: This element has cardinality zero or 1 in the rm-request message.

 

Also explain the convention of “+” in the figures in section 3.

 

 

554     The meaning of "Cardinality" isn't obvious (and the word isn't

            in the Concise Oxford Dictionary), especially since elements

            such as MessageOrder that can appear zero or one times are

            shown as having the same cardinality as elements such as

            PollRequest that can appear zero or more times.

 

ACTION: Iwasa to add explanation for the table rows in Section 3: e.g., for cardinality:

cardinality is a constraint on the number of instances of an item type which may be present in an enclosing item.

 

732      The text does not indicate that GroupId (or MessageId) can

            appear more than once in a PollRequest element.

 

Action: Iwasa will finish updating section 3 to fully reflect the syntax changes for message references.

 

Action: Sunil will update the schema.

 

 

 

748      While a PollRequest can request acknowledgment of a messages

            with a range of sequence number values, it is not clear what

            happens when one or more of the messages in that range caused

            faults.

        Consider, for example, a sequence of messages with the same

            GroupId and sequence numbers 0 to 4 sent using the Poll reply

            pattern.  If message 1 fails with an InvalidMessageHeader

            fault and message 3 fails with an InvalidRequest fault, what

            is the expected response for a PollRequest element containing

            <SequenceNumberRange from="0" to="4"/>?

ADD NEW ISSUE: Clarify semantics of polling  In particular there needs to be clarification that the poll reply only includes references to messages which were delivered.

 

ACTION :Sunil will come up with text to resolve this issue on clarification of Poll semantics..

 

 

754      What is the expected correspondence between the value of the

            SequenceNumberRange (or SequenceNumRange) element and the

            value of its 'from' and 'to' attributes?

 

            The schema indicates that this is an empty element.

 

Agreed: changed  value to “none” in 4.4.1.1.

 

762      "Response Element" should have the style of a section title.

Fixed

 

790-795 This paragraph should look like a paragraph.

Will fix.

 

796      Same comment as for line 754.

Fixed

 

807      The Fault element does not have the same sort of table as the

            other element definitions.

 

Agree: ACTION: Iwasa will add sub-section to section 3 for Fault element.

 

 

 

13.2Review of Fault Homework

Sunil sent the following email:

url

 

ACTION: Sunil will update to have the soap 1.2 mapping of ws-reliability will not use the rm:fault element, but instead will use the soap 1.2 Subcode element.

 

ACTION: Iwasa will put this statement in the new section in 3 on rm:fault element.

 

Message processing faults include:

• Nonsupported feature
• Permanent processing failure
• MessageProcessing Fault

 

Agreed to not have the suffix “fault” in names.

 

Change “invalidRequestHeader” to “invalidRequest”

 

ACTION: Sunil will incorporate amended proposal into the Schema and into the new text for section 4.

 

ACTION: Iwasa will updated section 3 to accommodate the proposal

 

14   Issues on Meeting Requirements

14.1REL-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:  Agreed

14.2REL-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 not violated by WS-Reliability spec

Resolution: Agreed

14.3REL-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:  Agreed

14.4REL-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:  Fault description will be amended to accommodate both. 

Sunil will provide a soap 1.2 version of the schema before we do the next CD vote.

Pending Close as accepted.

 

14.5REL-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: Agreed

14.6REL-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: Need to add some text.  We do not do our own message integrity checking.

“

The WS-reliability protocol relies on the underlying transport layer to not deliver  corrupted messages.  The WS-Reliability protocol does NOT REQUIRE additional mechanisms for message integrity checking.

“

Resolution: close by adding text above to sectin 2.1.

 

ADD NEW ISSUE:

Doug: Any message which results in a fault should have no further processing done to it.  Unexpired message which results in a fault will not result in the delivery of that message.

 

Whenever we have special case for expired message it should be discussing faults, caught before delivery.

 

14.7REL-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: Agreed

14.8REL-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: Agreed

14.9REL-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: Agreed

14.10                        REL-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:  Agreed

14.11                        REL-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:  Agreed

14.12                        REL-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: Agreed

14.13                        REL-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:

Text in 3.4 states that a response element may coexist with a request element.

 

ACTION: Sunil add text that a response to a poll may not coexist with a rm:request header.

 

Will work with callback.

Will only work with response reply pattern.

 

Change text in 3.4  to: When using the callback reply pattern, if the reply and the new request share a common destination URI, a response element may coexist with a request element.

 

Close as accommodated with this change to WS-Reliability spec.

Resolution:  Agreed.

14.14                        REL-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.

 

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:  Agreed

14.15                        REL-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)

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.

 

Add text to poll element in section 3 that states

“

In addition to its use for receiving replies for requests using the poll RM-Reply pattern, a Sending RMP may use it as a general query to determine non-expired messages which have been delivered.

 

If a Receving RMP does not support this general query, it MAY return a notSupportedFeature fault.

“

 

Resolution: Close by adding new text above.

14.16                        REL-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: To eventually close as accommodated by WS-Reliability spec

Resolution: Leave open, and close after we consider adding state charts or state tables for sending and receiving reliable messages.

14.17                        REL-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: Leave open, someone needs to insure our headers work with WS-Security.

14.18                        REL-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  Agree:

 

 

15   Resume discussion of Open Spec Issues

15.1Rel ___Semantics of duplicate acknowledgement

Jacques sent email:

Proposal:

If we do on "Ack of duplicate" then we should tighten the spec to remove

the following ambiguities and unnecessary restrictions:

The spec needs to be more precise on the conditions of persistence of message IDs

when supporting duplicate elimination.

It should be made clear that only persistence of IDs of *delivered* messages is REQUIRED.

That is important to help a fast yet easy implementation

of Acknowledgment of *delivered* duplicates.

(the following changes below are also justified for other editorial reasons)

 

The order of the Message processing flow should then be:

(this is a general sequence of steps, may have more steps in between,

e.g. additional expiry checks, or some steps may be cancelled.

The point is, "persist ID" may occur before (4) but does not have to )

1- M received

2- duplicate check

3- expiry check

4- (M delivery AND persist ID, i.e. both should succeed or fail)

5- Ack sent

 

Tom: there is the special case of a resend of a message which is held waiting for prior delivery.  This is accommodated by holding the resend as well.

 

----- Section 2.4 "Group Persistence":

 

Rename the section more generally "Message ID Persistence", and update as follows:

 

Replace:

"The duplicate elimination feature requires persisting the Message Identifier (GroupId and optionally the Sequence Number), after the message has been processed and delivered "

 

With:

"In case duplicate elimination is required, an RMP MUST persist the ID (GroupId and optionally the Sequence Number) of a delivered message at least until the message expires."

 

Agreed:

(rationale: it is a more precise wording that makes it clear that persistency of ID is NOT required as long as the message is not delivered. Personally, I think that statements on persistence are unnecessary as they are implied by the feature itself - here duplicate elimination - but if we keep this one, propose that one.)

 

------ Section 2.8  Duplicate Elimination

 

Replace:

"A number of conditions may result in transmission of duplicate message(s), e.g.,

temporary downtime of the sender or receiver, a routing problem between the

sender and receiver, etc.  In order to provide at-most-once semantics,

the ultimate receiver MUST eliminate duplicate messages.  Messages with the same

Message Identifier MUST be treated as duplicates.  "

 

With more precise:

"A number of conditions may result in reception of duplicate message(s), e.g.,

temporary downtime of the sender or receiver, a routing problem between the

sender and receiver, etc.  In order to provide at-most-once semantics,

the receiver RMP MUST NOT deliver a message that is a duplicate of a previously delivered message."

Agreed

 

(Again, a subtle difference, very significant for implementing duplicate check:

 the initial wording is ambiguous and may be interpreted as " duplicate elimination of any received messages is required",

while only the elimination of those duplicates of previous *delivered* messages is needed: it should NOT be required to do more than that. Remove "elimination" which is imprecise.)

 

----- Section 3.2.1: AckRequested Element

 

Replace:

"... If a receiver receives a message with AckRequested element, the receiver MUST send an

Acknowledgment message even when the message is a duplicate. "

With:

"... When receiving a message with AckRequested element, the receiver MUST send an

Acknowledgment message if and only if either:

(1)   the message has been delivered; or

(2)   the message is a duplicate of a previously delivered message that has not expired."

 

Agreed.

 

Close as completed.

 

15.2Potential New message model issue

Jacques suggested some edits to clarify that the model in section 2 is written with the assumption that the underlying protocol is request/response based.  However the Callback reply pattern can be mapped to underlying transports protocols which are one way.

 

Text changes agreed to be added to section 2.

 

Agreed to include this an editorial correction.

 

ACTION: Iwasa make the changes requested by Jacques.

 

15.3Potential New issue on termination conditions

Bob: In section 2.5, sub-cases t3.2 and t4.2 have common problem

 

There is an explicit assumption that the sender has a synchronized knowledge of the group termination state.  Need to specify the event to cause the sender RMP to determine termination.

 

The text implies that the termination criteria fire at the same time for sending and receiving RMP.

 

Jacques: Agree there can be out of synch knowledge of termination criteria firing.  However, this is not critical for the protocol.

 

Agreed that this can be considered as part of the resolution to the group termination issue which Jacques is working on.

 

ACTION: Jacques will add clarification of this in his homework on clarifying group termination.

 

15.4Schema placement of expiry time parameters

Schema has group expiry time and maxIdleTime as attributes of the GroupId.

 

Sunil asked if they could be moved as attribute of sequence number.

 

This will allow enforcement of the constraint that that they cannot be used for singleton groups.

 

Agreed he should do that in the next view of the schema.

 

16   Additional discussions on Future meetings

Jeff stated OASIS is having a two day symposium “Reliable Infrastructure for XML”.

 

This will be in April.

 

Will people here do papers about this WS-Reliability spec.

 

Sunil: I have submitted an abstract for a paper.

 

Jeff: we should try for a panel.

 

Sunil: I have submitted an abstract for a Tutorial.

 

Bob: The Interop group is waiting for a stable spec before their next go around on the demo.

 

Bob: this may be feasible to have a demo of the near-final spec by the April timeframe.

 

Jeff: how about a talk on the nature and status of the demo sub-group.

 

Jeff: how about a panel on Implementation experience with WS-Reliability.

 

Proposals are due Feb 9.  Materials on April 12,  Symposium, April 26, 27.

 

TC meetings are invited to occur either wed-thur  April 28 and 29.

 

Agreed that WSRM TC should have its next face to face meeting co-located with the Symposium.

 

 

 

 

Question on cancel the teleconference This coming Tuesday, Jan 20.

 

Earliest possible Time line

 

Jan 27 – CD 1 7 day Ballot issued

Feb 3 – CD 1 ballot closes

Feb 4 – 30 day Review initiated

March 5 – 30 Day public Review ends

March 15, submit to oasis staff for member vote

April 1 – Membership two week review

April 15 – start member two week vote

April 30 – member vote concludes.  Earliest Oasis Standard.

 

Try a One month shift:

 

 

Feb 10 –  Tuesday call, final editing instructions agreed.

Feg 12 – Document posted for TC internal review.

Feb 24 – TC review comments resolved, editing instructions produced.

Feb 25  Frozen document completed, TC review begins.

March 2 – CD 1 ballot closes

March 5 – 30 day Review initiated

April 5 – 30 Day public Review ends

April 15, submit to oasis staff for member vote

April 1 – Membership two week review

April 15 – start member two week vote

April 30 – member vote concludes.  Earliest Oasis Standard.

 

Agreed to not have meeting next Tuesday.

 

Agreed to 90 minutes meetings each week starting Jan 27.

 

ACTION: Iwasa will start working on new examples.

 

Action: Editors will produce up to date issues list by the next meeting.

 

Last Business:  Sunil change name of MessageProcessing  fault to MessageProcessingFailure.

 

Agreed to have Sunil modify the schema to make this change.

 

Bob moved to adjourn meeting.

 

Meeting adjourned at 3:30 PM.