[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim Minutes of WSRM TC conference Call 5/20/03
Please post desired corrections to the list before Thursday Morning. I will incorporate any desired changes before posting to the server the final minutes. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Draft Agenda to WSRM TC Conference Call
|
Draft Agenda to WSRM TC Conference Call Tuesday 1
Roll
Call
2
Minutes
Discussion
2.1
Appointment
of Minute Taker
Tom Rutt agreed to take the minutes. Mark agreed to take issue resolutions. 2.2
Approval of prior minutes http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/2013/MinutesWSRM-0506.htm Sunil moved to accept the minutes, Jishnu Seconded. No objections minutes approved.
Karl Best accepted the following changes to the “out of
scope” list from the approved
3
Progress
report from Editors of Requirements Document
Mark stated that the work has not yet been done. The only likely task is to use Open Office. Payrits draft is the most recent draft. They need to get a new draft ready for face to face. Action on editors. to have a draft ready by weekend. 4
Discussion
of Requirements Issues:
- Requirements Issues List: (From Mark Goodner, May 16th posting) :
4.1 Rel-8Participating intermediary: Non-participating intermediary: Scott Werden
asked what the definition of Message Exchange Pattern. Payrits stated it is defined in Soap 1.2. Scott stated we were using it for
one way and request response. Perhaps it needs to be clarified
what our formal way is to describe an intermediary. We need to specify where the
definition is coming from. Definitions from 1.2 are the best, according to Payrits. Agreed to discuss at face to face meeting for a definition of Message exchange pattern. Leave open. Magdolna asked if it is our attention to address 1.2. Focused to 1.1, but ability to incorporate standards completed by draft is allowed. 4.1 Rel 9 pull modelIwasa sent presentation material to the list. The point is whether we include requirement for limited devices and firewall, to be a requirement for the pull model solution. These devices have the problem that they have to receive reliable messages even when they can only originate transport connections. Sunil asked for a clarification on the requirement, what to pull, the request and response. This was the first item in the oracle issues. Iwasa agreed to put together a clarification of pulling of what from where. Action on Iwasa. 4.2 Rel10Attachments support Sunil clarified that the current spec is silent on this issue. Sunil stated we could Clarify that messages with RM headers can use attachments. Iwasa state that we could add one requirement sentence to resolve this issue. Tom Rutt proposed “Our RM protocol (our headers and behaviour) shall not preclude the use of attachments.” Joe Chiusano stated WS-attachments is not in a good state, and it is not an official standard. IETF RFC for DIME expired in Dec 2002 Marc G - What does it mean to say attachments, if you do not say what kind of attachments you are talking about. Payrits stated we would need a definition of attachment, before we decide. Jishnu stated we need to distinguish the requirement from meeting the needs of the Requirements. Magdolna stated the previous proposal is good enough for the requirements. Also, the final spec needs to state what specs the protocol is designed to work with. No opposition to accepting requirement as stated by Tom Rutt. 4.3 Rel18Add a requirement for support of
reference to the previous message with the Req/Res
MEP Jishnu Suggested: RM protocol shall allow bundling an
acknowledgment for an earlier message with a request for an acknowledgment for
another message. Sunil stated we change bundling to “bundling or batching” This is for non grouped messages. Jishnu suggested creating a new issue for batching. Magdolna stated there is agreed to have a requirement for batching. Issue rel26 already includes this. These should be kept as two requirements, according to Magdolna. No opposition to Jishnu suggestion. That is the agreed requirements. 4.4 Rel26Description: Requirement is whether a single ack
can ack one or more reliable messages. To avoid
excessive latency in overload or failure recovery conditions, this could be a
requirement. Perhaps the requirement is to minimize acknowledgement overhead,
or to minimize work in doing acknowledgements Paolo clarified that allowing
multiple acks in one message may minimize protocol
overhead. The amount of overhead to experience, depends on the size of the messages. Should not
preclude this feature. May be an optional feature
of protocol. At least a
requirement for an optional feature. Alan Weisberger
supported the idea. Tom Rutt proposed: Requirement for a protocol option
allowing the sending of one message to ack one or
more received reliable messages. Magdolna asked if a receiver has to be able to handle it. Dock stated it is not optional on the receiver. Dock suggested a requirement: Every implementation must be able to receive this multiple ack, and may be able to send it. Dave Ingram suggested Requirement¨: spec will provide support for batched acknowledgements for the purposes of optimization. Agreed to Dave Ingram Suggestion. Optionality left for final spec. 4.5 Rel04Synchronous SOAP HTTP binding: We
say that synchronous SOAP HTTP binding is in use if SOAP messages are sent in
both HTTP request and respond messages. We refer to this binding as
"synchronous" in order to acknowledge HTTP transactions' blocking behaviour as the more common case. Asynchronous SOAP HTTP binding: We
say that asynchronous SOAP HTTP binding is in use if SOAP messages are sent
only in HTTP Requests, no SOAP-level data is conveyed in the HTTP response
messages. We refer to this HTTP binding as "asynchronous" in order to
emphasize that using this HTTP binding, all SOAP-level messages are completely
independent on the transport level. Sunil suggested minor edits. Are we allowing Post and Get. It needs to address the post vs Get. Magdolna stated it cannot be Get with Soap requests. Sunil suggested changing “HTTP request” to “HTTP post request” Scott stated that this is just a definition. It is fine as it stands. Dave Ingram stated that for Get the request does not contain a soap message. Payrits suggested in second definition changing in “HTTP requests”, to “HTTP requests or HTTP responses but not both” Peter Furniss stated that he did not see how it could work with HTTP Get. How would you get them to link together. Paolo stated that a Get might be used in a pull model. Paolo stated it is really an issue for synchronous and asynchronous binding. We have assumptions on transport level. We could think in a more general way, independent on HTTP or smtp etc. Payrits stated he is not sure if you can find a sensible definition in general. Paolo asked for more time to think about it. Perhaps talk about a synchronous soap binding. Payrits asked if we need synchronous and asynchronous in general, or just from the HTTP soap binding. Jishnu stated we are really dealing with a message pair, vs a single message. Synchronous HTTP bindings, vs Synchronous bindings. Sunil pointed out the initial spec already uses these terms. We are only interested in using terms synchronous and asynchronous with respect to HTTP bindings. Latest correction of Payrits is required for asynchronous. With this correction they are both correct. Paolo stated he could live this restriction. Iwasa stated he would like to have a chance to make amendments for proposal. Scott stated he had concerns about the amendment to the second definition. The current initial draft does not require the amendment. Scott suggested using two terms l asynch with call back and asynch with a poll. Peter Furniss stated he did not know how we would do this. Magdolna state the case of poll requires two http transactions. Both asynch cases require two http method invocations. Peter stated three cases 1) Request ,ack on response 2) Request, response empty. Later request has ack as callback 3) third one is A call be with message on request, empty response. Later A polls to be with request for Ack, gets back http response with ack to first message. Callback vs poll for response is the distinguishing factor for 2 and 3. Dave Ingram took action to post definitions for the three. Synchronous with two variants on asynchronous. Dave will work with Sunil on this one. 4.6 Rel05Crash tolerance: Fault tolerance: Scott had an issue with the Crash Tolerance definition. The crash tolerance definition is leading to a requirement for Crash Tolerant. He wants a tighter definition of resume sensibly. He suggested the wording I believe the need for this definition is from requirement 4.5 [1], which talks about what the spec must address. But this definition applies to an implementation of a spec, not just the spec. For instance, I *can* have a crash tolerant implementation of TCP, but that is not guaranteed at all by the TCP spec. I also believe that we need to be succinct in what we mean by "resume sensibly". But that really goes to the core of the requirements. How about: "We say that a specification is crash tolerant, if every conformant implementation of the specification ("node") is able to resume operation in the case of a hardware failure, in such a way that it is largely transparent to other nodes, and to the application, that a crash has occurred." Scott stated he also wanted to add network failure to the definition of Fault tolerance. Payrits had a problem that he wants to have the definition be against an implementation, rather than the specification. Scott stated the specification should guarantee, crash tolerance, for all implementations. Payrits stated that the specification should not demand crash tolerance to all implementations of the specification. He is concerned about lightweight implementations. Scott stated this is an important point, to determine what it the degree of reliability we are trying to create here. Payrits stated they want crash tolerance levels. Scott stated his wording is not requiring absolute crash tolerance. Implementation should not always have to Store every message, vs store only the message ID to avoid replay. Need persistence for Ordered delivery. Can do duplicate elimination with only storing ID at receiver. Payrits stated that Guaranteed delivery at sender requires it so persist, at least until crash. Can it report a fault case for a crash. Paolo stated that the definition proposed for crash tolerance. He suggested it be phrased as ability to meet a Quality of service. It is crash tolerance if it is able to meet the quality of service properties. Scott is willing to lighten up his proposal, but it is important to get agreement in principal on this requirement. Express thoughts on email, to get closure next week. Dave I stated that we are interested in intermittent hardware failure. This is a very broad term. Paolo discussed Fail stop vs Byzantine model. He suggested we might only support fail stop model. Leave open and discuss on email. 4.7 Rel06Persistent data Persistent storage: Static Joe asked if the persistent
definition should use the word persistent in its definition. Peter Furniss
stated this needs to be discussed in terms of levels of failure. Some level of failure you
survive. Persistent is surviving the
first but not the second. Tom Rutt asked if the lifecycle of data at a node is dependent on the level of failure. Dock stated Persistence is related to interruption rather than failure. Some failures (system explodes) may mean one node may never be able to respond. Perhaps additional requirements on announcement of failure are needed to address Peter’s concern. Peter suggested Persistence means surviving the failures we are designing for. V. Danda asked What is lifecycle of a message. This definition does not explain this. Leave open and postpone to meeting 5
Other Points
Requirements completion should be goal for F2F meeting. 5.1 Discussion of Identifiers for Web Service Reliable MessagingTom Rutt stated that we should put this on the agenda for the F2F, along with time to discuss other specification issues. The requirements issues have the highest priority at this time, however we should continue other useful discussions on the spec itself, as time permits at the F2F meeting. 6 Planning for F2F meetingTarget to have a firm draft of the requirements document completed by the end of the meeting. Face to face next week, wed thru Friday, May 28 thru May 30, at Oracle Redwood shores location. Editors should give us something to start with. Dave I stated it would be nice if we allocated times to have Issues to be voted on the phone bridge.. Sometimes this makes the meeting not able to make decisions. Mornings for a couple of hours each day for the bridge is best for the European and Indian members Afternooon for couple of hours is best for the Japanese members.. Suggest Two two hours sessions each day, one on Friday. Five sessions. One will be current time. From Another Tom and Sunil will work out the details and send with the meeting agenda by Friday of this week. - Dates and timing for future conference Calls We will decide at the f2f. Chair will not yet schedule teleconference for the Tuesday after the face to face. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]