Preliminary Minutes for WSRX TC meeting, Monday Afternoon.

The attendance list , as of the end of Monday, will be sent by Paul Cotton in a separate email.

The final minutes will include only one attendance list, which will reflect all attendees over the two days.

Special Minutes Style Conventions

Motion text

§ Motion Resolution text

Ų Action item text

Ų Potential new issue Text:

Lunch Recess ends:

7 Review of TC Charter (Continued)

The indented text is from the existing charter, while the non indented text (and the indented colored text) is from the TC meeting discussion.

While composition with other specifications is a goal of the TC, it is also a goal to leave the specifics of how that composition is achieved outside the scope of the RM specifications.

Martin suggested that we change “RM” to “WS-RX Specifications”

Doug B suggested “outside the scope of the WS-RX TC”.

Doug B moved, Anish Seconded to change “outside scope of the RM Specifications” to “outside the scope of this TC.”

§ This proposed clarification will be put out for formal Ballot.

Ų Jamie Clark will put out a web ballot on the Doug B motion.

Each of the protocol elements will use implementation and language neutral XML formats defined in XML Schema [14].

Out of Scope: The following is a non-exhaustive list. It is provided only for the sake of clarity. If some function, mechanism or feature is not mentioned here, and it is not mentioned in the Scope of Work section either, then it will be deemed to be out of scope.

The TC will not define a mapping of the functions and elements described in the specifications to any programming language, to any particular messaging middleware, nor to specific network transports.

The elements and/or mechanisms the TC defines must be independent of issues and considerations that do not affect an interoperable reliable messaging protocol.

There was some discussion of the wording “and/or mechanisms the TC defines”. It was clarified that usage of elements defined in another spec is different than defining a new mechanism. No change was suggested.

Specifically: the TC is not concerned with binding the specifications to specific underlying transports.

The TC and the specifications that it producesdo not address considerations, such as durability related to Sources' and/or Destinations' ability to satisfy reliability assurances.

Typographical error noted in above paragraph.

Ų Action OASIS Staff should fix typographical error in charter of missing space between “produces” and “to” the next time the charter is updated.

Except for the elements directly related to the functions in the scope of the specifications, the TC will not prescribe the format of messages that are transferred reliably according to the specifications.

The TC will make no assumptions about the location of Application Sources relative to RM Sources and Application Destinations relative to RM Destinations.

The TC will not attempt to define concepts or renderings for functions that are of wider applicability including but not limited to:

* Security (Encryption, Integrity and Authentication)

* Addressing

* Policy languages and frameworks

* Routing

* Transactions and Compensation

Anish asked if an authenticated session setup for ws-reliable messaging would be out of scope. He can envision an authenticated session in the RM headers themselves, and wants to know if this is out of scope. The current input spec has a security token in the create sequence response body.

Anish: I do not agree that Security is part of Reliability.

Chris F: If I can ack messages from someone else, that is not reliable.

Colleen: this spec must compose with ws-security. Thus we cannot define things that are already in WS-Security.

Gilbert: we might consider adding statements that this spec does not depend on other specs.

Tom R: the input spec uses EPR for Ack To. However there is no requirement for ws-addressing run time. We should not use wsa:messageId however, since this is part of the WS-addressing run time headers.

Chris F: the security context is optional in the Create Sequence response, thus we do not “depend” on ws-security.

Paul C: making the security context optional, allows another group to profile it to change this to not used, or as required.

Doug D : We need revised text to get to conclusion on this discussion

Chris F: we could tweek this to make clear that re-use of an EPR is not out of scope.

Martin C: we are going to have to make some of these decisions on re-use in a case by case basis.

Gilbert: I do not see good definitions of Composability.

Paul F- are there any proposed changes to the charter in this area.

No changes were proposed.

Where required these functions are achieved by composition with other Web services specifications.

The TC will not attempt to define functionality duplicating that of any normatively referenced specification in the input WS-ReliableMessaging or WS-RM Policy specifications. If the referenced specification is outside of a standardization process at the time this TC moves to ratify its deliverables, or is not far along enough in the standardization process, any normative references to it in the TC output will be expressed in an abstract manner, and the incarnation will be left at that time as an exercise in interoperability.

Deliverables

The TC has the following set of deliverables.

* A revised Web Services Reliable Messaging Protocol specification. Committee Specifications are scheduled for completion within one year of the first TC meeting.

* A revised Web Services Reliable Messaging Policy Assertion specification. Committee Specifications are scheduled for completion within one year of the first TC meeting.

Anish: I assume the first bullet would include Schemas. However could the TC also have output white papers on subjects, such as composability with WS-Security.

Paul F: there is no wording in the charter precluding additional documents to be published.

These specifications will reflect refinements, corrections or material technological improvements with respect to the input documents and in accordance with this charter.

Ratification of the above specifications as OASIS Standards, including a brief period to address any errata, will mark the end of the TC's lifecycle.

The TC may choose to vary the number of the specification documents and their titles.

IPR Mode

This TC will operate under the "RF (Royalty Free) on RAND Terms" IPR mode as defined in the OASIS Intellectual Property Rights (IPR) Policy, effective 15 April 2005.

Audience

The anticipated audience for this work includes:

* Vendors offering Web services products;

* Other specification authors that need reliable message delivery for Web services

* Software architects and programmers, who design, write or integrate applications for Web services

* End users implementing Web services-based solutions that require an interoperable, composable reliable messaging solution.

Language

TC business will be conducted in English.

References

[1] WS-ReliableMessaging

http://schemas.xmlsoap.org/ws/2005/02/rm

[2] WS-RM Policy

http://schemas.xmlsoap.org/ws/2005/02/rm/policy

[3] WS-Security

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

[4] WS-Trust

http://schemas.xmlsoap.org/ws/2005/02/trust

[5] WS-SecureConversation

http://schemas.xmlsoap.org.ws/2005/02/sc

[6] WS-Addressing

http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/

[7] SOAP 1.1

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

[8] SOAP 1.2

http://www.w3.org/TR/soap12-part1/

http://www.w3.org/TR/soap12-part2/

[9] WS-Policy

http://schemas.xmlsoap.org/ws/2004/09/policy

[10] WSDL 1.1

http://www.w3.org/TR/2001/NOTE-wsdl-20010315

[11] WSDL 2.0

http://www.w3.org/TR/wsdl20-extensions

http://www.w3.org/TR/2004/WD-wsdl20-bindings-20040803

[12] WS-I Basic Profile

http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

[13] Secure, Reliable, Transacted Web Services: Architecture & Composition

http://msdn.microsoft.com/webservices/understanding/advancedwebservices/default.aspx?pull=/library/en-us/dnwebsrv/html/wsoverview.asp

http://www-128.ibm.com/developerworks/webservices/library/ws-securtrans/index.html

[14] XML Schema

http://www.w3.org/TR/xmlschema-1/

http://www.w3.org/TR/xmlschema-2/

Bob F: I have a question about the intent of the Chairs and the group in pursuing the work to arrive at the output specifications. How do we deal with things such as requirement definition document, or issues lists, which are not official deliverables,

Paul C: I have a concern that we would not be finished within a year if we take on too many new output documents. Of course an Issues list would be useful.

Steve C: I would think that such documents as a use case document would be helpful.

Tom R: another example might be some state chart diagrams or sequence charts to aid in the validation of the specification. However these might not be appropriate to include as formal output specifications.

Paul F: I would think that non-output documents which help the work of the group are a useful thing. However we should avoid formal outputs which will prolong the work of the TC.

Bob F: A running working document on requirements, for the internal use of the TC, could help record fundamental reasons some decisions are made. I have seen some other groups spend more time because they are missing such a standing requirements document.

Bob: I move that the TC operations include the existence of a working document on requirements to aid its work. Seconded by Jacques.

Paul C: I believe that there is already a formal set of requirements in the charter. We have an input spec that members have already implemented Trying to write a requirements document or a used case will slow the TC work down.

Jorgen: I would like to clarify whether this motion is to have the charter change.

Bob F: my intent was to have the motion pertain to the workings of the TC, rather than an explicit charter change.

Anish: I believe taking the charter and the input spec and writing a requirements document will aid the TC

Gilbert: It would help to know which use cases or requirements are in or out of scope of the TC.

Paul F: Are requirements and use cases meant to be separted.

Bob F: I move to amend my motion for TC operation to change “requirements” to “requirements and/or use cases”. Steve C seconded.

Colleen: I feel that adding another deliverable adds to the scope of the TC.

Paul C: Adding another deliverable will increase the time for the TC to finish.

Gilbert: Deriving requirements from existing charter and specs is much simpler than starting from a blank slate to arrive at requirements.

Anish: I do not see how the charter as it stands disallows a working internal requirements/use Case document.

Paul F: I feel that changing the charter to add a Requrements/UseCase document is increasing the scope of the TC. I would like to close off the charter discussion.

Jeff: if there is a general agreement that we could have such a working document for requirements/useCases then we would not need to change the charter. As long as people cannot say such a document is out of scope of the Charter.

Chris F: if the charter does not preclude such a document, someone could produce such a document as a contribution for use in the TC work.

Gilbert

§ No objection to Amendment, resulting motion Text “The TC operations include the existence of a working document on requirements and/or Uses cases to aid the operations of the group.

Doug D: I would prefer that the word “include” be changed to “allow”.

Jeff: since this is a sense of the meeting motion, it does not matter whether the word include or allow is used.

Chris K: This discussion is a discussion about creating a new deliverable, and is adding new work to the TC. This I believe we should not talk about this outside the charter. If this was included in the charter it would be an increase in the scope of the TC.

Paul F: The motion positions this as a working document, not a deliverable.

Chris K: I believe that such a new document will add to the work to be done by the TC.

Chris F: I feel that anyone could produce such a document to help the TC do its work, and the TC could decide to use that document to aid its work.

Paul F: I would like to propose that we amend to motion to determine if TC members feel that such a document would be useful and feasible within the time frame.. Seconded by Bob F.

§ No opposition to amendment. Amended sense of committee motion: “This TC believes that a working document on requirements and/or use cases will be valuable to the operations of the TC and feasible within the time frame of the TC.”

Vote 25 yes in room , 16 against.

§ Amended Motion on Sense of committee for Requirments/UseCase document Passed.

Steve C:: I would like to amend the motion from Jeff:

Paul F: this is out of order, the motion from Jeff has been queued for formal ballot.

8 Contributed works

a) WS-ReliableMessaging and WS-RM Policy, Chris Ferris

http://schemas.xmlsoap.org/ws/2005/02/rm

http://schemas.xmlsoap.org/ws/2005/02/rm/policy

Chris Ferris presented an overview of the input document to the TC posted as:

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200506/msg00014.html

There was a question on why a message with sequence number 1 cannot serve as the start of sequence indication.

Chris F stated that the first message could be lost or received twice.

Tom Rutt stated that the explicit sequence creation exchange establishes the AckTo epr.

Anish asked why the last message indication in a sequence cannot automatically terminate the sequence.

Chris F stated that the explicit sequence destroy is a signal that the sender has received acks for every message it cares about in that sequence.

Question: Is bilateral sequence merely an optimization or is it a mandatory feature.

Chris F: Different people think differently. I believe this is an optimization

Ų Potential New ISSUE: Is Bilateral Sequence Negotiation an optimization or a mandatory feature? RM policy assertion seems to force it to occur, in the case of a wsdl request response reliable in both directions.

Hamid asked if the purpose of this presentation is to just give an overview, or is it to allow TC members to raise potential Issues.

Chris F: If people want to raise potential issues now, they can do it as I speak.

Anish asked if the ackTo can change during the lifetime of a sequence.

Chris F: the input spec does not allow the ackTo to change during a sequence.

Ų Potential New ISSUE: Should the AckTo EPR be allowed to change during the lifetime of a sequence.

Chris F stated that the WS-RM protocol is only concerned with where the ack goes to. It does not deal with application responses to that message. WS-addressing ReplyTo deals with a possible application response to the message.

Anish: WS-RM is a protocol which can guarantee the delivery of a single message. Request response semantics at the application level is not part of RM.

Chris F: there is a way to use WS-RM for assuring both a request message and the later response message. But the wsrm:acks pertain only to a single direction of message.

Chris F: What is identifier of endpoint which establishes the binary relationship between two endpoints which are engaged in a sequence.

Anish: it is possible that the wsa:reply to for the request message may have the same address as the wsrm:ackTo for the sequence the message is sent on. In such a case both the application reply and the wsrm:ack could be piggybacked.

Doug D: The wsa:replyTo for a create sequence message does not have any specified relationship specified in the input RM spec to wsa:ReplyTo values for individual messages sent using the resulting sequenceId.

Ų Potential New ISSUE: Which pair of EPRs define the scope of a sequence.

Tom R: can the sequenceAck to an AckRequested be carried on the http response to that ack requested request.

Chris F: if both wsa:replyTo and the wsrm:AckTo eprs both use the anonymous address this could occur.

Steve W: WS addressing is discussion the a uniqueness requirements for messages using the same wsa:messageID. In the case of retransmission for reliability reasons, is there a relationship between the uniqueness of the wsa MessageID for a retransmitted message, and the wsrm:SequenceID,sequenceNo used for that message.

Ų Potential New ISSUE: What are the uniqueness requirements for the wsa:messageID values used for messages retransmitted with the same wsrm:{sequenceID, MessageNumber} pair as a prior transmission of the same reliable message.

Martin: The last message indication is not that it is the last message, since it may be retransmitted.

Tom: The answer to this question depends on whether a retransmitted message at the soap layer is considered to be the same message as the prior transmission with that same sequenceID and messageNumber. This is closely related to the potential new issue above from Steve W.

Chris F clarified that the wsrm:nack , when sent from receiver to sender, only states that the sender needs to retransmit a particular message number in a sequence.

Lloyd: is id valid to send a nack for the same message number for a message that has been successfully acked already.

Chris F: the order that the ack or nack messages are received by the original message source is not necessarily the same as the order they were send by the original message receiver.

Steve W: is the sender required to resend a message if it has already received an ack for that messageNumber.

Chris F: while the sender is allowed to resend in such a case, it is not required to resend if it has received an ack. However, the spec does not say this now.

Paul C: we could add a clarification such as “sender MAY resend the message in such a case.

Chris F: there might be some cases where the receiver really does require a resend.

Ų Potential New ISSUE: Is the sender required to resend a message identified in a Nack, if it has already received an ack for that same messageNumber.

The following slide triggered a discussion:

Effecting Reliability assurance

§ WS-RM protocol is an AtLeastOnce protocol as manifested on the wire

§ Responsibility of the RM Source to ensure successful transmission of each message AtLeastOnce or else fail the Sequence

§ Responsibility of the RM Destination to effect the appropriate reliability assurance as a contract with the Application Destination

§ Enables asymmetric implementation capabilities without changing the protocol

4 Provides for broader reach (e.g. pervasive device -> high-end server)

4 Simplifies the protocol

Martin C: reliability assurance, in some cases, may need to be asserted separately by the sender for each sequence.

Paul C: this additional functionality could be is built on the protocol that exists.

Tom R: I have an example case where there is a wsdl port type with two operation types, one which the sender requires duplicate elimination, while the other the sender does not require duplicate elimination. This could be handled by having two different sequences established between the same two sender and receiver endpoints, one for each required assurance level.

Chris F: The current spec puts the determination of reliability assurance beyond at least once as an aspect of the receiving implementation. The protocol assures at least once. Any additional assurance negotiation between sender and receiver is outside the scope of the RM spec.

Ų Potential new ISSUE: Is there a requirement that the sender can assert that the receiver must deliver a particular reliability assurance on a given sequence.

Chris presented the following slide,:

Efficient preservation of the integrity of reliable contexts by composition with WS-Security or other SOAP security mechanisms.

4 CreateSequence can carry SecurityTokenReference to secure the Sequence

4 When used, messages belonging to a Sequence MUST provide proof of possession of the Security Token referenced in the CreateSequence

Chris stated that several people have asked him why this security token is in the WSRM create sequence message of the current spec. He presented a rationale stating that it is to disallow hijacking a sequence number.

Claus: how do you indicate that a particular security context is supported.

Chris F: that is out of scope of this spec.

Paul C: we need to add an issue that the spec needs to Support tokens by both ws security 1.0 and ws security 1.1.

Ų Potential new ISSUE: Must the ws-reliable messaging spec support tokens produced for both ws-security 1.0 and ws-security 1.1.

Meeting recessed at 5:40 PM.

Will continue on Policy assertion overview Friday Morning.

ws-rx message

7 Review of TC Charter (Continued)

8 Contributed works