Preliminary Minutes WSRM TC Conference Call – Mar 23, 2004

The meeting of the WSRM TC took place by teleconference

Tuesday, March 23 2004, from 5:30 to 6:45 PM Eastern Standard Time

(UTC - 5)

Conference call Dial-in number : Toll number (only): 1-512-225-3050 Participant code: 89772

0 Draft Agenda:

Draft Agenda to WSRM TC Conference Call

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.2 Approval of previous meeting minutes –

3 Discussions of Issues and editorial comments

4 Discussion of FAQ for WS-Reliability

5 Discussion of New Orleans F2F

agenda approved

1 Roll Call

Attendance:

First Name	Last Name	Email	Role	Company	Voting Level
Jacques	Durand	jdurand@us.fujitsu.com	Member	Fujitsu	1
Kazunori	Iwasa	kiwasa@jp.fujitsu.com	Secretary	Fujitsu	1
Tom	Rutt	tom@coastin.com	TC Chair	Fujitsu	1
Robert	Freund	bob.freund@hitachisoftware.com	Member	Hitachi	1
Nobuyuki	Yamamoto	no_yama@bisd.hitachi.co.jp	Member	Hitachi	1
John	Fuller	jfuller@wernervas.com	Observer	Individual
Junichi	Tatemura	tatemura@ccrl.sj.nec.com	Member	NEC Corporation	1
Alan	Weissberger	ajwdct@technologist.com	Member	NEC Corporation	1
Anish	Karmarkar	Anish.Karmarkar@oracle.com	Member	Oracle	1
Sunil	Kunisetty	Sunil.Kunisetty@oracle.com	Secretary	Oracle	1
jeff	mischkinsky	jeff.mischkinsky@oracle.com	Member	Oracle	1
marc	goodner	marc.andrue.goodner@sap.com	Secretary	SAP	1
Pete	Wenzel	pete@seebeyond.com	Member	SeeBeyond	1
Doug	Bunting	doug.bunting@Sun.com	Secretary	Sun Microsystems	1
Tony	Graham	Tony.Graham@Sun.com	Member	Sun Microsystems	1
Chi-Yuen	Ng	cyng@csis.hku.hk	Member	University of Hong Kong	1

Meeting is quorate.

2 Minutes Discussion

2.1 Appointment of Minute Taker

Tom Rutt will take minutes.

Minutes will serve to record issue resolutions.

2.1 Approval of previous meeting minutes

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6002/MinutesWSRMTC031604.htm

Iwasa  moved to accept the Mar 23 minutes. Alan  seconded.

No opposition, 3/23 minutes  are approved.

3 Discussion of Issues and editorial Comments

Doug B: The editor’s are far behind the minutes in their reflection in the issues list. They are also behind in the reflection of completed items in the document. They will have two passes before they are caught up. After that, they will still be strapped for time and will be unable to keep the issues list going forward.

Doug: I feel the issues list will be an integral part for dealing with the public comment phase.

Seek Volunteers: for ongoing issues editor.

3.1 Sunil Homework

· My Action Item ...
From Sunil Kunisetty <Sunil.Kunisetty@oracle.com> on 23 Mar 2004 01:59:54 -0000

from email:

... to suggest replacement text for the following lines/paragraphs:

Replace lines 507 - 513 with the following:

If the RMP sending a Reliable Message does not receive an Acknowledgment or a Fault for a sent message that has not yet expired, then the Sender can either Poll the Receiver for the status of that message or can resend the same message with same Message Id as long as it is not expired (i.e. ExpiryTime is not passed).

Change both “can” to “may”

Record this as agreed.

Replace the lines 760-764 with the following:

For ordered messages, the Sender MUST include this attribute in the first message and its value MUST be "Start". Subsequent messages in the group, except the last, MAY include this attribute and if it is included, MUST have "Continue" as its value. The group may be ended by denoting the last message in the group as the last one by including this attribute with a value "End". A group may also be ended using group termination parameters. When this attribute is omitted, the default value of this attribute is "Continue".

Tom: does everyone agree in principal?

Jacques: related to what Sunil just said, we do have a comment. Why do we make it mandatory to use the start value for the status in the first message, even though sequence number is zero.

Sunil: we do not say that the sequence number must be zero.

Line 741 states this.

Jacques: Given this, what is the purpose of status = start and continue, if we start the sequence at zero, without wraparound.

Sunil: I do not remember agreeing on starting with zero.

So we cannot agree on this change at this time, need to open new issue on this.

Sunil and Jacques will form a small team to come up a proposal.

We are doing the group setup in our protocol in band, but we need to clean up the semantics. This is the issue we need to discuss further.

Sunil has an opportunity to present his slides at the OASIS symposium. Sunil will give the slides and Jacques will be on the panel.

Jacques: Each panel topic we have the opportunity to show some slides.

3.2 Other Issues

· Re: [wsrm] feedback from implementors
From Sunil Kunisetty <Sunil.Kunisetty@oracle.com> on 22 Mar 2004 22:33:32 -0000

· feedback from implementors
From Jacques Durand <JDurand@us.fujitsu.com> on 20 Mar 2004 04:17:19 -0000

From Email:

Hi Jacques,

Comments inlined:

---------------------------------------------------------------------------------
1. RM-Replies, and Messages neither Acked or Faulted :

Issue: For those messages that have neither been delivered (Acked) or been Faulted
at the time a PollRequest is received, the doc is not clear on what should be done in the
response element. The text seems contradictory: implies that a response element
will simply not say anything about such messages (Section 4.4.2.1, and also Example 3 ),
but also that all messages MUST be replied (4.3.1).

<SK-1>
I agree that clarification is needed, but some editorial comments on the proposed
text.
</SK-1>

Proposal: In case of message non-delivered yet, and non-faulted,
it should be clearly stated taht the Response does not have to say anything.
(unless we create a third state for these? That would help distinguish if a
response is mute about a message because it is expired (see #2 below), or because
it is held in out-of-order sequence)
Editorial updates:
- in 4.3.1 (L883) replace:
"...MUST send back all RM-replies for the messages received in the MessageId"
with:
"...MUST interpret such poll requests as concerning the entire set of messages received
so far for this group." (which means returning RM-Replies for those messages
either delivered or faulted.)

<SK-1>
instead, how about just simply saying:

"...MUST send back RM-replies for non-expired messages that were either delivered or faulted in that
message range"

Because, the phrase "as concerning" is ambiguous as the current state.
</SK-1>

- L886: replace:
"...MUST return RM-reply for messages received..."
with :
"... MUST interpret such poll requests as concerning the set of messages..."

<SK-1>
and this one with:

" ... MUST return RM-rplies for non-expired delivered or fault messages for messages received ..."

</SK-1>

- L845 (section 4.3)
replace:
"...to determine non-expired messages which have been delivered."
with:
"...to determine the status of non-expired messages."

Item 1 is editorial in nature, with no issues in the resolution.

---------------------------------------------------------------------------------
2. Time limit for messages referred in the Response element,
in particular for poll requests with broad range:

Issue: It will not be technically possible to provide status for any
past message, especially if they have expired.

Proposal: A Receiver should only be required to send Acks (and Faults) for messages that
have not expired yet. So a Response is exempt from reporting on expired messages.
Make that clear in the spec. (Section 4.4)

<SK-1>
We already agreed upon this. In fact in section 4.1 (line no. 845), we clearly state this.
I'm not sure what additionally needs to be said in section 4.4.
</SK-1>
---------------------------------------------------------------------------------

Jacques stated that the as long spec must makes this explicit, that this behaviour is only for non expired messages, there is not a problem.

3. parameters for "Resending" :

Issue: The RetryTimeInterval RM agreement item, as described in 3.1 (Line512)
is specifying the interval between two retries. A fixed interval may not be appropriate, and
a more dynamic one may be better, and may be dynamically adjusted based on context of operations.
Plus, this resending technique does not really make sense when using PollRequest:
we would expect the Sender to only resend *after* doing the PollRequest (which may be done
for several messages). The spec is mute on what should be the resending policy in that case.

Proposal 1:
(lite) Modify text so that RetryTimeInterval is only an initial value,
that the implementation is free to interpret the way it wants. (e.g. for exponential variation).
Also mention how these parameters should be interpreted in case of PollRequest:
- the RetryTimeInterval should be the elapsed time before doing the (first) polling (followed by
message resending for messages not Acked.)
- the RetryMaxTimes parameter should be for how many times the PollRequest will be tried
for a message that was not Acked.
NOTE: a Receiver should be free to ignore PollRequest messages that are sent too frequently for
a [group of] particular messages.

<SK-1>
I prefer the above proposal with a minor change. I don't even want to say that it is an
initial value, rather describe them conceptually, and leave it to the implementation for
interpretation.
</SK-1>

Proposal 2:
(radical) Get rid of RetrymaxTimes and RetryTimeInterval alltogether.
After all, the way a Sender is resending (frequency, # of times) does not affect interoperability.
It is not something that Sender and Receiver have to settle on.
GuaranteedDelivery is before all about notifying the Sender in case of delivery failure,
and requesting Acks.
The resending effort is implementation dependent and may vary dynamically with context.
These 2 parameters cannot even be always complied with
(memory issues may prevent to store for too long and resend).
The only requirement we can have, is that no attempt to resend should be made
beyond ExpiryTime (for obvious reasons). Using text like:
"The Sender RMP MUST do its best effort to resend a non-acknowledged message until
the mesage expires or is acknowledged. The resending policy and algorithm
(frequency, dependency on storage and load constraints) is left to the implementation."

Jacques stated that he can agreed to keep the parameters in the spec, with the relaxed behaviour.

Tom: the number of retries may not be required given expiry time per message. Would such an implementation hurt interoperability?

Jacques: Such an implementation does not affect interoperability.

Jacques: We need to describe the semantics, in such a manner that polling fits into the picture. The parameters have different meanings with polling reply pattern.

Jacques we need to talk more about these parameters.

Sunil: the challenge is how to word these parameters.

Sunil and Jacques will add this to the work of their small team. They will provide a proposal to the group before the end of the public review period.

---------------------------------------------------------------------------------
4. Discard or Forward message after consuming the Response header :

Issue: Depending on whether a Response message is (a) alone or (b) piggybacked on a business message,
the processing of the RMP will be different. Let us say the RMP is implemented as a SOAP node:
We must do:
- in (a) discard the message after consuming the Response header block,
- in (b) forward the message after consuming the Response header block, as it is intended to another node.
However, as a SOAP node is not expected / allowed to access the SOAP body to figure whether
this is a stand-alone Response or not, it should only rely on the Header.
But nothing in the header will tell the RMP which case (a) or (b) we are in. As a business message
is not required to have SOAP headers, the SOAP header may look exactly the same for (a) and (b).
Note: In some case where the RMP is implemented as a "handler" (Apache / Java), there is a work-around.
But that is only for very specific cases.

<SK-1>
I don't think we have to say anything here for 2 reasons:
i) We have decided that we are going to support RM for end-to-end entities only {REL-8]. So we don't have to deal with intermediaries in our case
ii) Leave it to the SOAP processing logic (based on soap actor/role/relay stuff) to decide on when to remove the header and when not to remove it.

Also, distinguishing the 'alone' and 'piggyback' is doable even now, i.e., if there is no (RM)Request Header, then it is standalone and if there is (RM)Request and (RM)Response then it is a RM-piggybacking. So I don't see a need for the additional attribute.
</SK-1>

Jacques: this is not just for intermediaries. Some implementations (e.g., using java handler) may benefit from this proposal.

Sunil: The issue is still not clear to me. If this is an implementation issue it does not need to be stated in the document. I still do not understand what the problem is.

Jacques: Hamid is not on the call, we need to follow up with this discussion on the mailing list.

Proposal: Add an attribute to the Response element, like @mode="alone" or "bundled".
The sender RMP always knows how to set this attribute. The Receiever RMP node will forward
after processing only if @mode= "bundled". More details below about the problem:

There two cases to consider about the addressing of an RMP:
Case 1:
------
The address on which the RMP is listening and the address of the web service are the same.

Case 2:
-------
The RMP can receive messages on its own address that is different from the address
of the web service, and yet it can process messages on both addresses.

The only case in which the RMP can distinguish between (a) and (b) above, is the case 2 where
the message is received on the RMP's own address (given in the replyTo element for a response/callback
reply pattern). Note that when receiving poll requests (that could be also be piggybacked), the RMP
is still unable to distinguish between (a) and (b) above.
==============================================================================

Alan: who knows about the public review.

Doug: everyone in the committee needs to do their own publicity to get the proper review done.

Tom: can any W3C member send out a notice to the members of W3C.

Anish: most of the groups do the work in public.

Anish: I can do this xml-p group.

Anish: xml-P did a review of wss and sent official comments to them.

Tom: we do not have official liaison.

Anish: does the TC want to get comments from XML-P group.

Sunil: one issue is whether we have the Chair send the email to other groups.

Alan: Last week at the WS-I requirements meeting they will be profiling various use cases involving Web Services Protocols. There will be difficulty in picking which Ws- reliability spec to use. Oasis has started WS notification and WS-RF, and these specs have references to proprietary specs. If we can get more people to review this spec, we can state it has had broad public review.

WS-RF and WS-Notification are meeting in April.

Doug: the references to WS-RM are non normative. This issue should be discussed within those TCs.

Members should get involved if they are interested.

Bob F: can we get Carol to do this.

Anybody wanting a notice to be sent to a group should send the email address to Tom, who will send it as chair.

Bob F volunteered to work with Iwasa on a short press release describing the availability of spec for public review, and put on wire.

Bob will investigate how to circulate the press release. The TC will get a 5 day period to send comments to the list. No comments will be seen as concurrence..

4 Frequently Asked Questions:

Re: [wsrm] Candidate Frequently Asked Questions for the OASIS website
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on 23 Mar 2004 20:35:47 -0000

From Anish Email above:

The first question that is asked by people looking at ws-reliability is --

what is the difference between this spec and ws-reliablemessaging?

Are we going to put that in the FAQ?

-Anish

[Fwd: Re: [Fwd: Please review this FAQ text]
From Tom Rutt <tom@coastin.com> on 23 Mar 2004 20:27:29 -0000

From Email above:

I forward an old email from Carol Geyer, of OASIS, which has some points to put in the FAQ, and also has a proposed answer to the "what is the difference" question.

We can discuss this at Today's teleconf.

Tom Rutt

WSRM Chair

--

----------------------------------------------------

Tom Rutt           email: tom@coastin.com; trutt@fsw.fujitsu.com

Tel: +1 732 801 5744          Fax: +1 732 774 5133

--- Begin Message ---

· From: "Carol Geyer" <carol.geyer@oasis-open.org>

· To: <karl.best@oasis-open.org>, <tom@coastin.com>

· Date: Fri, 14 Nov 2003 09:52:49 -0500

Yes, it should be included with some more generic questions, such as:

  What is the need for this specification?

  Who should be involved in this development?

  Who will benefit from this work and how?

  When will this specification be completed?

--Carol

Tom Rutt wrote:

> Carol Geyer wrote:

> I like this statement.  It is correct, and makes the major Point.

>> I would hope we could provide some information that isn't contentious

>> but is accurate. It's an obvious and fair question that deserves some

>> kind of response on our part (even a lame one). I hate to take the

>> ostrich approach, if there's anything we can say. How about something

>> like:

>>

>> WS-Reliability is being developed within the OASIS open process, and our working draft, related documents and TC archives are all accessible

to the public. We invite public review and comment on this work.

>> WS-Reliable Messaging is a proprietary specification being developed  privately at this time by a group of vendors. As the status of the current version

of WS-Reliable Messaging is not publicly known, we advise those

with specific questions on WS-Reliable Messaging to contact its developers.

>>

>>

>> carol

>>

>>

>>

Candidate Frequently Asked Questions for the OASIS web site
From Tom Rutt <tom@coastin.com> on 23 Mar 2004 18:18:13 -0000

From Email above:

The following FAQ's were provided by Alan Weissberger in his White paper.

We should discuss these on email and on the call. OASIS Staff want us to

give them

a set of FAQs to put on the web site.

--------------------

. Frequently Asked Questions

1. Who is participating in the OASIS WSRM TC and how often do they meet?

A variety of companies are active in the WSRM TC. The members include:

Booz Allen Hamilton, BT, Cyclone Commerce, Fujitsu (3), Hewlett-Packard,

Hitachi(3), NEC Corporation(2), Novell, Oracle (3), SAP, See Beyond, SUN

Micro (2), University of Hong Kong. There are also many observers.

Membership in OASIS is required to participate in the WSRM TC. Telecon

meetings are held weekly and face-to-face meetings are held about every

two or three months.

2. When will the WS Reliability spec be completed and what is it based on?

Agreement was reached in Nov 2003 on a committee draft spec (v0.52),

which was implemented in a demo at the Philadelphia XML Conference, in

Deceber 2003. The TC has recently voted on a committee draft spec

(v.0.992) which is out for public review, to complete on April 19, 2004.

Note that the spec is based on Requirements issues that have been

compiled for the committee’s internal use (over 100 requirements have

been identified).

- An OASIS standard could be approved in the 2nd Quarter of 2004, after

the public review.

3. Who participated in the demo of WS Reliability?

Fujitsu, Hitachi, NEC, Oracle, and SUN Micro. The demo was based on

v0.52 of the spec.

4. Who will benefit from the completed WS Reliability spec?

• WS middleware companies that implement the spec will benefit because

it will be universally interoperable. Initial testing can be done with

any company that implements it. The license to implement the spec is

royalty free.

• Application program developers will also benefit, as their web based

applications will be reliable and robust, operating over WS Reliability

middleware. Using the implemented middleware will also be royalty free.

• WS End users will benefit in accordance with their application

requirements. For example, “at most once delivery” implies duplicate

elimination. This is important for placing orders, banking transactions,

and insurance claims processing. If an end user is sending a Purchase

Order, for example, he wants to know it actually arrived at the

destination and it arrived exactly once (not multiple times). This is

particularly vital for financial applications.

5. Who will generate application specific profiles for the WS

Reliability spec?

WS-I will most likely develop such profiles. The WS-I Requirements

Working Group has already discussed doing this upon completion of the spec.

Agreed to add another FAQ about quality of services of standard.

Tom asked question about item 5 above:

Alan: I am convinced that there will be a new WG on reliability.

Bob F: It is a matter of timing. It could be much longer than 90 days. It could be up to a year.

Bob F : there is no way for our TC to determine what WS-I Requirements group will do.

Doug: no matter how large the overlap is, we as an OASIS TC cannot make any normative statements about another organization.

Tom: I will not included question 5 in the FAQ.

Tom agreed to send out a new starter FAQ email to allow people to add questions and answers.

Everyone should add questions after tom sends out the seed email.

5 New Orleans Face To Face preparation

Email from OASIS Staff:

Hello Tom,

I am writing this email to confirm the WSRM TCs participation at the upcoming New Orleans OASIS Symposium. Please take a moment to review the information below. Since space is very limited at the hotel - it is critical that we confirm the specifics as soon as possible. If any of the information below is incorrect, please respond to this email with the appropriate change. I thank you in advance for the help and look forward to working with you on this upcoming event.

Regards,

Jane Harnad

Manager of Events

OASIS

Phone: 978-667-5115 ext. 214

jane.harnad@oasis-open.org

Meeting Name: WSRM TC

Day: Wednesday, 28 April and Thursday, 29 April

Time: 8:00 am - 5:00 pm (Wed) and 8:00 am - 12:00 pm (Thurs)

Number of Participants: 15 people

Audio Visual Request: None

Phone/Internet Request: None

Room Set: Boardroom for 20 people

Bob: If someone brought a projector, we could get a screen.

Internet access Is a question.

Tom will ask oasis staff about hotel.

Should we find out about a phone for a ½ day.

Tony can live without phone access.

Skip the phone.

Bob will bring a projector, and we can use a wall, or get a screen from

The hotel if we need it.

Jacques and Sunil will work as individuals to determine how to present things.

We can have questions from the audience prepared.

Give questions for the panel to Jacques. Jacques can prep people as to questions he might like members to ask as individuals at the panel discussion.

Bob F made Motion to adjourn, Alan seconded.

Meeting Adjourned at 6:55 PM EST.

wsrm message

0 Draft Agenda:

1 Roll Call

2 Minutes Discussion

2.1 Appointment of Minute Taker

2.1 Approval of previous meeting minutes

3 Discussion of Issues and editorial Comments

3.1 Sunil Homework

3.2 Other Issues

4 Frequently Asked Questions:

5 New Orleans Face To Face preparation