[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of 4/4 teleconf
Prelim minutes are attached. Please post corrections to list before next monday. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Full Agenda for WSRM TC Conference Call –June 14, 2005
|
Prelim Minutes WSRM TC Conference Call –April
4, 2006 The meeting of the WSRM TC took place by teleconference Time Tuesday, 24 Jan 2006, 05:30pm to 06:30pm ET 1
Draft Agenda:
|
|
First
Name |
Last Name |
Role |
Company |
|
Jacques |
Durand |
Secretary |
Fujitsu
Limited* |
|
Kazunori |
Iwasa |
Secretary |
Fujitsu
Limited* |
|
Tom |
Rutt |
Chair |
Fujitsu
Limited* |
|
Robert |
Freund |
Voting
Member |
Hitachi,
Ltd.* |
|
Eisaku |
Nishiyama |
Voting
Member |
Hitachi,
Ltd.* |
|
Nobuyuki |
Yamamoto |
Voting
Member |
Hitachi,
Ltd.* |
|
Paul |
Knight |
Voting
Member |
Nortel
Networks Limited* |
|
Anish |
Karmarkar |
Voting
Member |
Oracle
Corporation* |
|
Pete |
Wenzel |
Voting
Member |
Sun
Microsystems* |
Meeting is quorate
Tom Rutt
Volunteered to take minutes.
The minutes of the 2/21 teleconference meeting are posted at:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/17451/Minutes-wsrmTC-022106.htm
Bob F moved to approve the 2/21
minutes, Paul Knight seconded.
No opposition minutes 2/21 minutes are approved
2006-02-21-1 - Closed
Action: Tom will post a contribution on interworking ws-reliablity with ws rm.
2006-02-21-3 - Open
Action: Jacques will clarify what he thinks we should do on reliability of req-resp.
2006-02-21-3 - Closed
Action: Iwasa will try to find out what da levels are being used for ws reliability.
The working list of potential enhancements to WS-Reliability was posted after the last f2f as:
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/12436/wsReliabityFutureFeatures.htm
TC needs to decide among the following possibilities
Jacques posted the following contribution before the last meeting: Reliability of Request-Responses
Jacques gave an overview of the “reliable synchronous response” with respect to what it would mean for an upgrade to ws-reliability.
The minimal updated would be for guaranteed delivery of synchronous response. The QOS def for reliabile response is different than the one for request, since failure notification does not have to happen on the side of the sender. The proposal is that to support guranteed deliver of response, the request must be send under guaranteed delivery, and in case of failure to receive response, the request is resent. Not receiving the response means not receivint ack of the request, since ack is piggybacked with response. The change is that the sending or response be done with original ressponse, (buffered). We want to avoid duplicate invocation of resend of request. The response must be cached.
In summary: the proposal is to redefine guaranteed delivery of response so the delivery notifications are received on side that receives the response. The other difference is behaviour of caching response on the back channel has to be tightened in the spec.. Ack of the response is an optional. It serves two purposes, when the ack is not received it concludes that a failure has occurred. ; also you have to take measure to make effort in resending.
Tom: but the ack of response can be used to empty the response cache.
Jacques: message expiry time can be used for this. It might be useful to have the ack as an additional mechanism. The ack can be lost itsef.
Jacques: duplicate delivery is covered. However I would leave out the case for response ordering. The QOS for ordering of response would have to be changed.
Tom: is there a need for a new signal header that reliability of response is requested.
Jacques: the signal would be in the response message, including a request header, with a piggybacked ack.
Tom: Jacques will complete action item to give a short contribution on changes needed to ws reliability to make this happen.
Fujitsu posted a contribution in January:
http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200601/msg00014.html
Which included the following sub- proposal:
Develop a high level specification for delivery assurance/QoS of a
reliable message. We need to define the notion of reliable message
delivery assurance in the context of QoS by describing the precise
semantics (but not the syntax or protocol). The standardization of the
expression of delivery assurance could be used to support either WS-R or
WS-RMg (WS-RX).*
We believe that a "mark-up" of the standard representation of delivery
assurance would be very valuable for the WS industry and would be more
expediently developed, generated and approved in the WSRM TC (vs WSRX
TC) due to its proposed sharper focus.
For example, we recommend distinguishing between an acknowledgement from
the receiving RMg entity (e.g. in WS-RX spec) vs an acknowledgement that
confirms that the layer above the receiving RMg entity (perhaps a WS
control protocol or application layer) has correctly received the
message from the RMg entity.
Also, there may be different notions of the various forms of reliable
message delivery: at least once, atmost once (AKA duplicate
elimination), guaranteed delivery, sequential delivery, etc. What do
these notions really mean to the layer above? They need to be precisely
defined and illustrated.
Tom: does anyone support this. Ws-reliability has definition for qos with is precise, and ws-rm does not need the definition for the protocol, they leave qos on the endpoint to be outside of protocol.
Tom does anyone want to keep this on the agends for future work.
Jacques: it is not a simple thing to do, I think we should take it off the agenda. There are differences, and a markup for this might lead to a more broad qos beyone these two specs. Perhaps it would be covered by a generic policy specification scope.
Agreed to take this off future agendas.
Iwasa posted the following Email::
http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200604/msg00000.html
Here is my action item in the last telecon.
Action: Iwasa will try to find out what da levels are being use for ws reliability.
As far as I know, there are two
industry groups that are implementing WS-Reliability in
Both industry groups are implementing Delivery Assurance, but neither Duplicate Elimination
nor Ordered Delivery at this point.
Thanks,
Iwasa
Tom: It seems there is no features of ws reliability being used that are not covered by WS-RM.
Jacques: is duplicate elimination being done.
Iwasa: some might not even do resending, they only notifiy of failure.
Tom R posted the following Email, outlining an Interworking unit for WS-Reliability and WS-Reliable messaging.:
http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200603/msg00007.html
Tom: I think this demonstrates how one could interwork implementations with a simple IU.
Bob: could this work for reliability of the synchronous response.
Tom: I did not put this in the first cut, but I think It could be covered once ws-reliablity and ws-rm have specified reliability of response.
I also assumed only the callback scenario in the example.
Tom: is this something for standardization, or could it be only dealt with with product space..
Jacques: perhaps some app notes could be done.
Tom: perhaps we could do an apps note on this.
Tom: can people give comments on this before the next meeting.
Tom: my opinion is that we should focus on moving to the new platform with wider acceptance. Interworking units could help to facilitate migration from ws-reliability to ws reliable messaging.
Bob F: we should make it simple to facilitate migration, namely do not add new features which make migration more difficult.
Paul K: ws-reliability does its job and is useful. But if we add features, we will not have something which is implementable and stable.
Tom Rutt forwarded the following email, from Jamie Clark, as:
http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200603/msg00001.html
* From: James Bryce Clark <jamie.clarkAToasis-open.org>
* To: tomATcoastin.com
* Date: Tue, 21 Feb 2006 16:04:03 -0800
As you know, our current OASIS IPR Policy was adopted in April 2005
with a 2-year transition period, during which the OASIS TCs then existing
could choose when to convert from the old IPR Policy to the new one under
the OASIS IPR Transition Policy [1]. As we announced back in 2005 [2],
each TC has until April 2007 to select one of the new policy's three
licensing IPR Modes, and conduct the transition vote; or cease operations
if no transition vote is successfully completed by April 2007.
Tom, it would be helpful to know whether your TC has discussed plans to
convert. Could you please advise back to me whether your TC has begun
considering this, and if so, roughly on what schedule? This is an informal
inquiry: we are asking only for current thinking, not a binding
determination or TC member poll. The level of answer we hope for is:
__ We haven't considered our timing yet.
__ We are considering starting a transition roughly in ___ [calendar quarter] 2006/07
__ We probably will close before April 2007 and not convert.
If planning has not started, OASIS standards development staff will be in
touch to discuss your TC's plans, needs and timing between now and the
OASIS Symposium in
Thanks for your attention and assistance.
Best regards Jamie Clark
~ James Bryce Clark
~ Director, Standards Development, OASIS
~ jamie.clark@oasis-open.org
[1] http://www.oasis-open.org/who/ipr/ipr_transition_policy.php
[2] http://lists.oasis-open.org/archives/members/200502/msg00006.html
Tom: I propose we answer we have not considered our timing yet.
At last meeting, TC agreed to decide on the next meeting at this meeting.
May 8 and 9, OASIS Symposium TC meetings 10 and 11.
Paul K, Jacques, will be there.
Paul K : I do not see value for a f2f at this time.
Agreed to have One hour call on 16th of May was chosen.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]