[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of WSRM TC meeting 7/29
The prelim minutes are attached. Please post any corrections before wed pm, so I can post the final minutes on this thursday. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: firstname.lastname@example.org; email@example.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
Preliminary Minutes to WSRM TC Conference Call –
The meeting of the WSRM TC took place by teleconference this
(UTC - 4)
The call in details are as follows :
Toll Free - : 1-800-605-5167
International - : 1-719-457-0339
The draft agenda was sent on the list
1 Roll Call
Meeting is quorate.
2 Minutes Discussion
2.1 Appointment of Minute Taker
Minutes were agreed be taken by Tom Rutt.
Doug Bunting agreed to document the issues resolutions.
2.2 Approval of previous meeting minutes
Peter Furniss moved, Sunil seconded approval of the minutes.
No opposition, minutes approved.
3 Discussion of Issues:
Issues List: (From Doug Bunting):
3.1 Rel 16 Order and sequencing
Iwasa gave an email:
Here is a proposed resolution for Rel16,
which is my action item at last telecon.
Description: The behavioral semantics of senders and receivers need to be
further defined with regard to the tracking of sequence numbers for the
purpose of detecting duplicate or out of order messages. For example: How
long should a receiver hold on to out-of-sequence messages in anticipation
of a missing message?"
REL-11 proposals address some of the sequencing issue.
REL-6 and REL-17 deal with persistance issues, but not out of sequence
[see original spec]
Include the following description to the spec at section 2.4.
When a sender sends multiple messages with Guranteed message ordering,
the sender is REQUIRED to include MessageOrder element in the message.
And all messages to be delivered in order MUST have same GroupID
and MUST have sequence number as a value of SequenceNumber element
in order of the message to be delivered to receiver's application. (Please
refer to section 3.3.2 for SequenceNumber element.)
When the sender uses Guranteed message ordering,
the sender MUST use Guaranteed message delivery and Guranteed
duplicate elimination together. In detail, the sender MUST include both
AckRequested element and DuplicateElimination element, as well as
the MessageOrder element for Guranteed message ordering.
A receiver that received messages including MessageOrder element
MUST provide its application layer with those messages
in order within the same groupID. In detail, the receiver MUST
follow the following procedure, when it received messages
with MessageOrder element:
1. Confirm the message is including AckRequested element and
DuplicateElimination element as well as MessageOrder element.
If there is missing eaither/both of the above two elements,
the receiver MUST send back [TBD] Fault message to the sender,
waste the message, and terminate this procedure.
2. The receiver MUST check if the message is duplicating
with any message persisted at receiver.
3. The receiver MUST persist the message until PersistentDuration
[TBD:This parameter must be defined as a configuration parameter]
has expired, if the message is not duplicating.
4. The receiver MUST generate and send back an Acknowledgement
message to the sender. Note the Acknowledgement message
MUST be sent back whether it was duplicated or not.
5. The receiver MUST remove the message if it was duplicating
at #3 above, and terminate this procedure.
6. The receiver MUST check the SequenceNumber and GroupId
to see whether the message is arrived in order within the GroupId.
If the message is arrived in order, the receiver MUST provide the
message to the application layer. If the message is not arrived
in order, the receiver MUST wait until all previous messages
is received by receiver and provided to the application layer
In addition to the above procedure, the receiver MUST check
messages persisted and didn't provided to the application layer
until PersistentDuration is expired. If there are those messages,
the receiver MUST send back [TBD] fault to sender to notify
those messages are not delivered to the application, even if
the Acknowledgement messages were returned before. And
then the receiver MAY remove those messages.
Please propose any updates to make the above
sentences more appropriate.
Linkage between ack and ordering is implied by the current text.
Scott questioned why they are not orthogonal.
Sunil does not know why duplicate elimination can not be orthogonal to order and sequence.
Requirements 50 51 52 and 53 are very related.
Iwasa stated this was an attempt to show the new structure for ws-r in picture. The sentences are not changed yet.
Ack requested element.
Sunil wants to have them work in each combination.
Iwasa understands scott and Sunil concern. He does not disagree.
They can be used independently.
Tom Rutt asked why Message order can be put inside of rm-message header.
Doug Bunting asked why they cannot be separate RM headers.
If they are independently specified and defined in similar ways. First decide on orthogonality and then decide on which to use.
General agreement on keeping the three RM-functional Units / features orthogonal is specification.
Doug: Keep orthogonal and do not mix together. Handle them in a similar way in the XML. What choice we want to make for the xml can come later.
Perhaps a separate rm header for each of the three Functional units to have their own headers.
General agreement that we should have a separate header for each of these three functions. The descriptions can be done separately.
Doug stated Tom had skipped over the need for consistency in discussion.
There was general agreement to have the specification of each of these three functions be done in a consistent and orthogonal manner.
The couplings may influence these discussions.
Bob stated the interaction issues must be looked at to define the second step to define the xml schema.
Scott Warden stated he is willing to work on this.
Sunil can work on it.
Action: Iwasa will start the discussion by refining his proposal to separate the semantics of ordering and sequencing. Then the discussion will continue.
Doug suggested that they do a few revisions on their own.
Iwasa, Bob Freund, Tom Rutt, Sunil, Scott Will work on this.
3.2 Rel 21 from to
Iwasa proposed to drop it.
Bob Moved to drop from and to elements from the spec. Doug seconded.
No opposition, they are agreed to be removed. Close Rel 21.
3.3 Rel 54 New issue: need for Service Element
Iwasa stated service element was there to be used for specifying the receiver application.
This is supposed to be used in combination with from/to and service element.
Since we removed To element, the service element can also be removed.
Sunil stated that there is a requirement for extensibility. If people wanted to add that in its own name space.
Sunil stated that this could be useful to classify services.
We had agreed that our xml will be extensible. This cannot be found.
Agreed to add new requirement issue
Sunil moved to remove the service element from the spec. Seconded by Iwasa.
Nobody opposed, close rel 54 by removing service element from spec.
3.4 Rel 55 Extensible XML schemas.
XML schemas for RM should accommodate extensible attributes and elements.
Joe Chiusano asked about requiring separate name spaces for the extensions.
Joe recommended that we require the extensible attributes and elements are in a different namespace.
Tom asked how we could extend the protocol ourself. Joe stated we could have a new version namespace.
Moved by Scott, Joe seconded, to add new issue, with title extensibility.
Our XML Schemas MUST accommodate additional attributes and elements from a different namespace than the target namespace.
No opposition, new requirement accepted, rel 55 closed.
3.5 Rel 39 Reply To
Tom Rutt described the current email discussion:
Here is a new proposal, which incorporates much of the discussion.
Modify the definition for the AckRequested element to change the use of the
terms synchronous and asynchronous to the new terms “reply acknowledgment pattern”
and “callback acknowledgement pattern”.
Note: This proposal does not make reply to an attribute or sub-element of ackRequested, but includes the faults in the definition for the ackPattern attribute.
“*3.2.4. AckRequested Element*
The AckRequested element is an OPTIONAL element. It is REQUIRED for
guaranteeing message delivery. However this element MUST NOT appear in a non-Reliable Message. This element is to be used for a sender to request the receiver to send back an Acknowledgment message for the message sent.
The AckRequested element contains the following attribute:
- an *ackPattern *attribute
*(1) ackPattern attribute*
The ackPattern attribute is an OPTIONAL attribute. This attribute is used to specify whether the Acknowledgment Message (or application fault messages) should be sent back directly in the reply to the reliable message or in a separate callback request. This attribute, when used, MUST have one of the following two values.
The default value of this attribute is “Response”, when omitted.
- *Response *: An Acknowledgment Message (or RM Fault message) MUST be sent back directly in the Reply to the Reliable Message.
- *Callback*: An Acknowledgment Message (or RM Fault message) MUST be sent as a callback request, using the address in the ReplyTo element
- *Poll*: An Acknowledgment Message(or RM Fault message) MUST be sent as a response to a poll request
With this modification the ReplyTo definition can be modified as follows:
*3.2.2. ReplyTo Element*
This is an OPTIONAL element, used to specify the initial sender’s endpoint to receive a callback Acknowledgment message or Fault Message. A value of this element MUST be present in the request message if the AckRequested element indicates that the Callback Acknowledgement pattern is requested.
If present, the ReplyTo element is required to be URL as defined in [RFC 1738].
Doug stated that it is unclear to use an attribute to ack requested which also applies to faults.
Sunil stated that when ack pattern is response we are expecting the RM faults or acks to be sent in same way. He wants them to be tied together.
Sunil stated that at app level one way mep one may not have a fault or ack in the response. We need to state that the reply to has to be there. The ack or fault always have to be sent to the callback or polling for one way mep.
Doug saw the issue of tying ack pattern (which has a bad name if it applies to faults) to ack requested element, we will have problem with faults from duplicate elimination feature.
Doug asked if the ack pattern should also apply to fault handling. If that is the case
This ack pattern must be placed separately from ack requested feature.
Scott tended to agree.
Doug proposed to separate out the guaranteed delivery feature from ack pattern.
General agreement that RMFaults and Rm-acks should be handled the same for each ack pattern.
Do we want reply to element to be applied to binding pattern element.
Agreed to decouple binding pattern from ack requested element.
General agreement that the reply to element should be coupled with the binding pattern element.
Doug asked if it was necessary for a global change to be put in the action item.
Doug stated it would be more efficient for the editor’s to take a cut at it.
Come back to the next meeting on this.
Tom Rutt took action to start new discussion. Tom Will send first pass to sunil and scott.
3.6 Rel 46 faults in header rather than body.
Sunil sent the following mail:
As per my AI from the last con. call, here is the proposal for REL-46.
Issue: As per SOAP 1.1 spec. for Faults (section 4.4), "soap:detail
MUST NOT be used to carry information about error information belonging
to header entries. Detailed error information belonging to header entries
MUST be carried within header entries". Unfortunately, this is not the case
with the initial WS-Reliability spec. as all WS-Reliability specific faults are
sent in /Body/detail. [[Actually, this is more an outstanding issue. It was in
the Issues list at one point, but it was removed when Issues list was converted
to Futures list as this is too low-level (technically) to fit into the former. ]]
When a Fault occurs, we will be still sending the SOAP:Fault, however, without
the /soap/Fault/detail sub-element. Instead, we will be sending the RM specific
fault code as a Header element. So we will be having an additional Header
element called RMFault. The schema for RMFault will be the same as the
New changes in bold:
<faultstring>Error in the Message Header sent from Server</faultstring>
<!-- <detail> ... </detail> element will NOT be there -->
Schema for RMFault Header element:
<xsd:element name="faultcode" type="xsd:QName" />
Note that there is no 'soap:mustUnderstand' attribute unlike some
other RM Headers, as this Header is for informational purposes.
Sunil summarized that the detail sub element of fault should not be used. Instead we will send them as a new header rm-fault.
Sunil stated that this will make us soap 1.1 compliant.
Doug B asked why we need the rm-fault wrapper, Why not define a RM-fault code. Why do we need both fault code and fault in rm namespace.
Sunil agreed it is better for One soap header element rmfault code with xsd:Qname as value.
Sunil moved to close issue 46 with the above resolution, amended to use a single rm-fault code element. Seconded by Doug B.
No opposition, issue 46 is closed with resolution.
3.7 Rel 56 - New Requirements Issue – List configuration parameter, default and nominal values as appendix to spec.
Alan asked about a requirements issue on configuration management parameters in an appendix.
He suggested we define the parameters, default values, and range of acceptability of these parameters.
Doug asked if this is a new requirement issue, or a spec issue
Alan asked if this is a requirement for our spec to have such a list of parameters.
Sunil stated that rel 47 is a related issue.
Alan stated that one table would list all parameters which would have to be known.
Alan stated he would have to go over them one by one.
Alan stated he would send mail out on this issue.
3.8 Rel 47
Doug suggested we leave rel 47 as a spec issue which will fall out from the requirements issue.
Could be generalized to be which config parameters need to be expressed in the protocol.
Bob F: Scope of tc is reliable messaging. Our protocol could have how to send adequate configuration information during negotiation of session for reliable messaging. He would prefer our protocol having all required parameters included.
Tom Rutt stated that we currently only have time-to-live in the protocol.
Alan W suggested leave 47 open, and continue discussion on his new requirements issue.
4 Face to face meeting
ACTION: Dock needs to send out meeting information for the face to face.
Alan moved to adjourn Joe seconded it.