[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary minutes of WSRM TC meeting - April 8, 03
Attached are the preliminary minutes. Please suggest any corrections before Thurday PM, I will post the final minutes on Friday Morning. Tom Rutt WSRM Chair. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: The meeting of the WSRM TC will take place by teleconference this Tuesday April 8, 2003, from 5:30 to 7:30 PM Eastern Time
|
Preliminary Minutes of WSRM TC conference Call Meeting The meeting of the WSRM TC took place by teleconference
Tuesday Host:
Fujitsu 1 Roll Call
Doug Bunting SUN Payrits Nokia Mark Goodner SAP
Iwasa
Fujitsu Leave
as Part of spec for now 3 Introduction of Input contributions 3.1 WS-Reliability Specification Fujitsu, Sun, Oracle, 3.2 WS-Reliability Schema 3.3 Royalty Free License Terms for WS-Reliability 3.4 Nokia Requirements input They provided this as a starting point for the
requirements document. 3.5 Nokia WS-Reliability Overview Presentation The slides were introduced by Payrits. They summarize the WS reliability mechanisms
and the basic requirements. They want a general architecture for WS reliability,
including a communication layer in the protocol stack. With a formal definition. They manage it as an extension of the existin soap, on top of the soap exchange pattern. They include summary of the reliable
messaging scope. They would like to support reliability for one-way and
for request response message exchange patterns. Slide 15 requirements; maximum
reuse of existing specs, and use of Soap. This
should be an extension to the existing soap protocols. Another requirement is that persistent
storage should not be mandated. Levels
of reliability should be defined, especially for persistenct. They want to work with soap intermediaries. They would like to be sure that architecturally
that the spec will work with intermediaries. Dave Bunting stated that this is a reasonable request. Faults and acks
going to the original sender is both good and bad. They have an illustration.
the item was opened for
discussion: - Synchronous RPC at the application level Synchronous RPC at application level is included as out of scope. This was done originally to make the spec simpler to understand. It was put here for that reason originally. He now thinks the spec should be allowed to use in a Synchronous way. We need to clarify the requirement. Application level support for RPC we would have to do a lot more. Dock asked if you could build an acceptable RPC on top of this that might be enough. Payrits asked for clarification of terms: - Synchronous is blocking - Message exchange pattern -
RPC is another term, independent
from request response message exchange pattern. Jacques asked if you can have Request response without rpc. There was consensus that we should include Request
response message exchange patterns in the scope of the spec. Sanjay. A question of what the request/response message
exchange pattern would allow a response to be sent correlated with the request,
as well as sending the response reliability. A question was asked on having to also correlate faults
with the message. Magdolna stated that Reliability
already includes correlation, and it could be extended to include request
response. Colleen stated we were. It should be in scope to allow request/response message
exchange pattern. Synchronous means sender blocks while waiting for the acknowledgement. Alex Weinberger made a motion to delete item from
scope. Seconded by
Dave from sonice. No opposition to deleting the item. Paulo Romano stated the sentence is confusing because
it has a different interpretation. One
way to clarify is request response is allowed. RPC is an api
term. Ensuring both exchanges are
delivered by. He would like to discuss
the differences in exchange patterns in requirements. He agrees to remove the out of scope item
from the charter. Request response is a standard use case. Payrits stated if basic correlation of
request response is done by reliable soap layer vs. using HTTP is the major
concern to be discussed. NO opposition to deleting out of scope item. Dock Allen asked about:
Colleen stated we want this to not be specified by this
protocol, but to work with other security protocols. Dock Allen asked about corruption. She asked why we should not deal with
corruption of messages. The point is that the transport takes care of a lot of
corruption avoidance. Alan Weisberger stated that
if we are relying on a Transport protocol for certain features, this has to be
clarified in the requirements. E.g, transport
flow control, etc. Jeff M stated the authors were assuming TCP. Jishu stated the Transport
requirements have to be clarified. Doug Bunting stated if we are starting to discuss the
transport layers. If we want to layer ws-reliability on top of UDP we are starting to hit issues
which are much greater. Jeff M stated the charter writers intended the out of
scope item was meant for security. The
rest of this discussion is that we have to refine the requirements on the
underlying transport. Peter Furniss asked to
clarify whether we are keeping the focus away from security hits, but including
normal corruption hits. Applying security where message is signed and hashed
using normal security mechanisms, would cover all integrity concerns, from any
corruption. You could chose not to use
security mechanism, because it is expensive. TCP failure would leave the user unknown. Jeff M summarized that the item is referring to
security, if the group wants to raise other forms of message integrity, they
should raise these concerns in the Requirements discussion. Jeff M asked if there are any words here which will make
a difference in the final document being produced. Jishnu asked what the problem is to
leave it as is. Peter Furniss asked that we could take message
integrity (including corruption of a single messae) out
of the scope of our protocol, since we are using mechanisms in the lower layers
to do this. Motion to add new bullet to out
of scope.
Seconded by Jeff M. No opposition to adding item.
Alen Weisberger
suggested kicking discussion on the Email. Payrits asked if we have a procedure
for requirements. Weisberger asked that the requirements
doc is supposed to be out in two months. The first requirements document should contain the
functional aspects of what we have, As we go over the future document issues, we could add
to the requirements for a second spec.
This would come much later. Jeff M suggested to Reverse engineer
the spec to produce the current requirements, then enhance the requirements. Doug Bunting states the WS-reliability spec has a set
of requirements already, to use as a starting point. He would not like to prevent resolution of
issues we have time to resolve in the first two months. Magdolna stated we have things done already
for requirements, put these in the first document. Clarify requirement for current doc scope first had
consensus. We could also have a living list of additional
requirements not in the current specification.
We could have general consensus on what items can go into the living
list. Doug stated something can be an issue if one person is
annoyed. Call it a requirements Issue list. Anybody can put something on the Requirements
Issue list. Finish the requirements list before working on
modification of the spec. Payrits stated it is ok for functional
requirements to have the basis for the requirements. We should also proceed
with high level use cases. Nobody is opposed.to use
cases. Dock asked if end to end was intended to mean app to
app. Doug stated end to end was in a space sense, rather
than a time sense. We were not thinking about state management. Doug Bunting suggested the editors have an off cycle
exchange for the format of the original requirements document, extracting those
requirements. Starting point for the issues list will be provided by
the Requirements editors, who will use the Nokia contribution and other items raised on the list. Payrits stated that if there are any
objections to requirements in the list. There was a question as to the final document in 6
months. It does provide constraints on
the extra work to get done. Dock asked about the intent the first of series of
specs vs the final spec at 6 months time frame. Payrits asked whether there would be a
future requirements document after the two month time frame. He asked if we can agree on requirements closed in 2
months. This would be a first pass. How do we get the extended requirements
into place. The requirements for the original spec would not Doug Bunting stated we don not know if there will be
requirements on the requirements issues list after two months. We might meet all the requirements everyone
cares about in the document ready at 6 months, in which case the TC could be
closed down. There could be more requirements in the two month
document. The two months time frame is giving the group a target
to get something produced. We should
continue to put new requirements issue on the issues list. We should not close our eyes. Jishnu stated that we could change
the charter to change the schedule. Doug Bunting clarified that the co-sponsors are now
just regular members. Jishnu clarified that the team will
vote at the end of the two months what the requirements are. The level of “completeness” will
be subject to a vote. Editors will track the issues being raised on the list. Doug suggested that we attempt to use the survey thing. After discussion the group agreed that every
member should send their time zone offset from GMT to the Chair at: We can then use this as a discussion point for other
possible times. It was agreed to have the next two meetings be at the
same time on Tuesday. The time suggested for the first face to face meeting was : Oracle will determine if they can meet this meeting
cycle. Jeff M or Sunil will get back to us on next week call
as to whether they can meet these dates. The meeting was adjourned at |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]