Preliminary Minutes of WSRM TC Conference Call – Apr 20, 2004

The meeting of the WSRM TC took place by teleconference

Tuesday, April 20, 2004, from 5:30 to 6:45 PM Eastern Standard Time

(UTC - 5)

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 Status of Action Items

4 Discussions of Issues and editorial comments

5 Discussion of FAQ for WS-Reliability

Agenda approved

1 Roll Call

Attendance:

First Name	Last Name	Email	Role	Company	Voting Level
Joseph	Chiusano	chiusano_joseph@bah.com	Member	Booz Allen Hamilton	1
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
Jishnu	Mukerji	jishnu@hp.com	Member	Hewlett-Packard	1
Robert	Freund	bob.freund@hitachisoftware.com	Member	Hitachi	1
Eisaku	Nishiyama	nishiy_e@itg.hitachi.co.jp	Member	Hitachi	1
Nobuyuki	Yamamoto	no_yama@bisd.hitachi.co.jp	Member	Hitachi	1
John	Fuller	jfuller@wernervas.com	Observer	Individual
Junichi	Tatemura	tatemura@sv.nec-labs.com	Member	NEC Corporation	1
Alan	Weissberger	ajwdct@technologist.com	Member	NEC Corporation	1
Mark	Peel	mpeel@novell.com	Member	Novell	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/6453/MinutesWSRMTC041304.htm

Bob Freund moved to approve 4/13 minutes. Alan seconded.

No Opposition, Minutes 4/13 are approved

3 Status of Action Items

3.1 Action 032304-2 – (Sunil & Jacques) Completed – 4/20/04

Sunil and Jacques will provide a proposal on retry parameters to the

group before the end of the public review period. –

· Action 032304-2 proposal
From Jacques Durand <JDurand@us.fujitsu.com> on 20 Apr 2004 18:55:19 -0000

to discuss with issues

3.2 Action 033004-3 – (Jacques) Pending

Jacques took action item to propose new FAQ text for the ws-reliability

features. - open

3.3 Action 033004-4 – (Mark G) closed 4/20

Why does the spec have a different name than the TC?

Marc G agreed to propose a new question with new answer to clarify the

matter. –

Action 033004-4 

From "Goodner, Marc Andrue" <marc.andrue.goodner@sap.com> on 20 Apr 2004 20:59:40 -0000

3.4 Action 033004-5 – (Jacques) closed 4/20

Jacques took action to clearly state what the relation with ebMS is. He

agreed to draft a question with an answer. – completed

Action 041304-1 , Action 033004-5 

From Jacques Durand <JDurand@us.fujitsu.com> on 20 Apr 2004 19:33:28 -0000

To discuss with Faq discussion

3.5 Action 033004-6 – (Tom) Pending

Need a general question on how can ws reliability be used with other ws

reliability protocols. Answer : we design it as orthogonal, to work with any other ws- reliability protocol. An example on why we have a reply to element of our own would help.

Tom Rutt agreed to send a suggested question and proposal out. - open

3.6 Action editors-1 – (Marc and Doug) Pending

Marc G and Doug B to updated issues list to reflect agreements in CD

.992. - open

3.7 Action 041304-1 – (Jacques) Completed 4/14/04

- Jacques will send an email to initiate email discussion on poll

response for fault conditions

· treatment of aborted out-of-order seq
From Jacques Durand <JDurand@us.fujitsu.com> on 14 Apr 2004 00:15:05 -0000

will discuss with issues

3.8 Action 041304-2 – (Iwasa) Needs Discussion – 4/20

- Iwasa to action to consolidate all the agreed comments in text with

change bars against CD .992. A list indicating which meeting minutes’

agreed changes were applied should also be included.

· Groups - UpdatesListFromCD10Mar2004-0.992.pdf uploaded
From kiwasa@jp.fujitsu.com on 20 Apr 2004 14:41:05 -0000

· Groups - WS-Reliability-2004-04-19.pdf uploaded
From kiwasa@jp.fujitsu.com on 20 Apr 2004 14:40:08 -0000

Needs for Discussion from above:

March 3,2004(WD0.99)

This was updated with minutes at: http://www.oasis-open.org/apps/org/workgroup/wsrm/email/archives/200403/msg00035.html

except for Minutes 4.4 Rel119, which requires discussion.

January14,2004(WD0.86):

This was updated for comments at : http://www.oasis-open.org/archives/wsrm/200401/msg00010.html

except for:

- More faults for Tables1

(Need to list up all faults)

- Section2.4 Line#259 in Spec20040106(Ver0.85): It should read "after the message has been processed and delivered to the "next processing layer".

(Need to confirm with TC for this change, since the current text was approved one.)

- Figure1,2,and3 “New processor Entity”

(Want to confirm with TC member)

-New terminologies for “Group Termination”, “Removal”, “Complete”, and others.

(Needs definitions)

Discuss these at the face to face meeting.

Iwasa has two or three updates remaining.  Small editorial ones.

It was agreed he should post these as comments to the list, to be discussed at the F2F.  He will not produce another draft before the F2F meeting.

3.9 Action 04304-3 – (Sunil) completed – 4/20

Sunil took action to consolidate all agreed comments on Schema.

· Groups - ws-reliability-soap12-2004-04-20.xsd uploaded
From Sunil.Kunisetty@oracle.com on 20 Apr 2004 16:27:11 -0000

· Groups - ws-reliability-2004-04-20.xsd uploaded
From Sunil.Kunisetty@oracle.com on 20 Apr 2004 16:26:28 -0000

4 Discussion of Issues and editorial Comments

4.1 Retry parameters

· Action 032304-2 proposal
From Jacques Durand <JDurand@us.fujitsu.com> on 20 Apr 2004 18:55:19 -0000

Title: Action 032304-2 proposal

Action 032304-2 proposal (from Sunil / Jacques)

- Issue 1: RetryMaxTimes and RetryTimeInterval are really meaningful only

for Callback reply pattern. The spec is silent on this limitation.

For Poll reply patttern, the resending effort can be associated with the polling:

The spec is silent on the resending policy in that case.

- Issue 2: RetryMaxTimes and RetryTimeInterval have a precise interpretation, that actually

is just one way to do the resending effort. Other ways should not be excluded.

- Issue 3: there is no indication of how often a Poll request will be sent.

Yet this should be controlled by the RMP (and remain transparent to the application).

A parameter to control this (time period, or number of messages, or both) need be defined.

Proposal Outline:

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

1- RM Agreement items can be either Required / optional :

Update section 1 to reflect that:

- some RM Agrement Items are "required" by this specification:

an implementation must be able to represent them and their value.

They are critical to the specified reliability mechanisms:

GuaranteedDelivery, NoDuplicateDelivery, OrderedDelivery, GroupMaxIdleDuration

GroupExpiryTime, ExpiryTime, ReplyPattern

- Some RM Agrement Items are "optional" for this specification:

Two communicating parties do not have to both agree on using them.

An implementation may represent them and use them to locally control the execution of reliability features:

RetryMaxTimes, RetryTimeInterval, PollFrequency

2- Introduce PollFrequency optional agreement item, as a way to control the frequency of polling.

3- update Section 3.1 (guaranteed delivery) to stress the optionality of

agreement items that control resending, and cover all reply patterns.

E.g. For each poll, after looking at the Poll response, the RMP will resend all messages that have not been acknowledged or faulted. Poll frequency is also controlled.

4- Mention that some agreement items are set by business partners, some

are intended to be set more dynamically, depending on network conditions, messaging load.

Jacques summarized that the existing resend policy needs to be relaxed.

The spec is currently unclear on when the polling will occur.

Tom asked why the picked poll frequency rather than PollingTimeInterval.

Tom asked what it means to have three optional parameters in the RM-agreement?

Jacques: It can be taken as a guideline on how to implement reliability procedure. I cannot make a strong case for leaving them in.

Sunil: the question is why to we even need to define the three parameters.

Jacques: we need to say that resending is expected. We cannot be prescriptive here, it must remain optional.

Tom: Another parameter could be time between callbacks, which we do not have in the spec.

Doug: I thought we were leaving it up to the two parties involved to determine such things.

Doug: my opinion is that anything that could be interpreted to imply that other algorithms are not allowed (e.g., backoff) is a negative thing.

Jacques: We could keep what we have as optional, or to remove it. If they are optional, we cannot make a clear case to keep them in.

Anyone feel strongly to keep them in.

Alan, could put them into an annex. Or the implementers guide document.

Jacques moved to remove the mention of retry max times or retry interval parms, doug seconded.

No opposition, motion passes.

These also need to be applied to appendix A.

Ø Action: Jacques will propose the text changes to the document to remove retry parameters

4.2 Comments from XMLP WG thru Pete Wenzel

· XMLP WG Comments on WS-Reliability CD-0.992
From Pete Wenzel <pete@seebeyond.com> on 19 Apr 2004 22:46:52 -0000

Subject: XMLP WG Comments on WS-Reliability CD-0.992

I am submitting the following comments regarding WS-Reliability

CD-0.992 on behalf of the W3C XML Protocol Workgroup.

1. Examples throughout the specification are inconsistent with its

normative reference to SOAP 1.2 (Line 1547) and non-normative

reference to SOAP 1.1 (Line 1573). The examples should conform to

a normative syntax.

This was also noted by Tony in an email to the list.

Soap 1.1 is listed as non normative.

We could make soap 1.1 reference normative.

General Agreement: to make both soap 1.1 and soap 1.2 references normative.

Defer final decision:

Sunil decided to make the reference non-normative. Should soap 1.1 be a normative

Doug: I agree that it is normative, however it is a w3C note.

Tom: how about pointing at the WS-I profile for our SOAP requirements.

Jeff: the schema references are to the note. I am unclear on the meaning of normative vs non normative.

Doug: normative means that it required to understand and interpret what is in the rest of the spec. In this case Soap 1.1 is required to interpret WS-Reliability. I agree with the XMLP working group on this.

Jeff M: Why to we have to distinguish the normative from non-normative references.

Pete W: the way the xmlp group distinguishes it is that non-normative reference are not directly relied upon. Perhaps EBMS and soap with attachments could be non-normative.

Jeff M: get rid of the two reference types.

Alan: other groups determine whether each is normative.

Doug: there is no OASIS policy in this area.

Jeff M: if we do not disobey the oasis policy why keep the distinction.

Pete: the non normative references I do not have to look at.

Doug: removing the distinction would satisfy the point of the XMLP comment.

Tom: would collapsing all reference into one section satisfy the XMLP concern.

Jeff Moved to collapse the two references into one, Iwasa seconded. Call it References.

Pete W: I am uncomfortable with this personally, I find having the two categories there, with SOAP 1.1 and SOAP 1.2 as normative.

Jeff: I could live with this but it raises questions where you do not have to raise them.

Jeff: there is an IPR discussion going on the meaning of normative.

Doug: would the alternative proposal to leave the distinction as it is, but move soap 1.1 and wsdl 1.1 and maybe xml schema into normative references. If so, I would also move RFC2822 into non normative.

Pete: that with your text on the meaning of normative would help this.

Doug: I have trouble in trying to define somewhat widely used terms.

No objection to unanimous consent, motion passes.

Doug: the only normative reference that should move down.

Fuller: as an implementer I would like to intuit from the category of the reference. I tend to intuit normative as mandatory for use in the implementation.

Doug: then we need NOTE: we are not using Normative to mean mandatory.

No opposition to the motion. Motion passes.

2. The relationship of Reliable Messaging Processor (Lines 278-281) to

the SOAP processing model requires definition. (Statements that the

RMP is a "module" that exposes "submit", "notify" and "deliver"

operations directly to an application imply a layered processing

approach, which is not explicitly defined.) Also, the SOAP term

"node" is used in several instances where possibly "RMP" is meant,

which contributes to the lack of clarity.

--Pete

What is a reliable messaging processor, with respect to the rest of the soap processor. How is it layered with the soap processor.

There is one picture with a soap node.

Ø Action: Pete will provide an input to the F2F on the RMP / soap processing model to help resolve the XMLP WG’s concern.

4.3 Comments from Pete Wenzel

· RE: [wsrm] Comments on WS-Reliability CD 0.992
From "Furniss, Peter" <Peter.Furniss@choreology.com> on 20 Apr 2004 09:19:32 -

· Re: [wsrm] Comments on WS-Reliability CD 0.992
From Pete Wenzel <pete@seebeyond.com> on 19 Apr 2004 22:59:25 -0000

· Re: [wsrm] Comments on WS-Reliability CD 0.992
From "Alan Weissberger" <ajwdct@technologist.com> on 19 Apr 2004 22:42:34 -0000 · Comments on WS-Reliability CD 0.992
From Pete Wenzel <pete@seebeyond.com> on 19 Apr 2004 19:50:03 -0000

Subject: Comments on WS-Reliability CD 0.992

* From: Pete Wenzel <pete@seebeyond.com>

* To: wsrm@lists.oasis-open.org

* Date: Mon, 19 Apr 2004 13:07:07 -0700

Here is my laundry list of things to fix in CD-0.992; most are

editorial in nature.

Line 98: Says "This specification addresses end-to-end reliability,

and is not concerned with intermediaries." However, there is nothing to

prevent someone targeting Reliability headers to "next" role/actor.

This case should be explicitly forbidden, rather than left undefined.

Defer this to the Face to face.

Lines 129, 1620: Reuse of "wsrm" prefix for different namespaces

is confusing. Choose a different one for the feature namespace in

the appendix.

Different one for feature in the appendix.

Pete W: they do not collide, but they are reused in the spec. It could be confusing.

Appendix A: section 1a, wsrm refers to feature namespace.

Pete: I suggest wsrmf.

Doug: the only real question is whether there is a problem in having both of these the same namespace. We could fix it that way, by merging the namespaces.

Pete moved to change the namespace qualifier in appendix to wsrmf, Doug B seconded.

No opposition, motion passes.

Line 134: Change

"This specification defines reliable messaging protocol embedded in

the SOAP Header."

"This specification defines reliable messaging protocol features,

expressed as extension header blocks embedded in the SOAP Header."

Agreed editorial.

140 Use official name of the standard. Its title must be "WS-Security

2004", not just "WS-Security", to avoid confusion with prior incarnations.

Remove the last sentence of this paragraph, which is already obsolete.

Agreed to use the official reference.

Also Line 1581, reference should be:

[WSS] "OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)".

Available at

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Agreed

Section 1.5: Examples are placed in an awkward location. Should appear

after the protocol & features are described. Suggest moving them to a

non-normative appendix.

Defer to after discussion the Martin C.

Iwasa: I would like to have the examples in the first section, but I could have them moved to the appendix.

Jacques: Martin C made the same observation. I agree it would be easier to move these examples to the Annex. It is tricky to give examples before the terms are identified.

Pete W Moved to have entire section 1.5 to be moved to a new annex. Not seconded.

Doug: we should have an agenda item at the f2f next week on an overall refactoring of the document order

Ø Action: Tom should put general document restructure on the agenda.

Defered:

Line 279: Change

"A module capable of processing and enforcing Reliable Messaging as

described in this specification."

"A SOAP Processor capable of processing Reliable Messaging SOAP

header blocks."

Ø Action: on Pete W. Bundle his definition of RMP with action to describe processing model with the xml p comment.

Line 281, 317 (and throughout document): Prefer the more grammatical forms

"Sending RMP"/"Receiving RMP" rather than "Sender RMP" and "Receiver RMP".

Also replace instances where just "sender"/"receiver" are used, to be

more specific that we are referring to a sending or receiving RMP.

Jacques: We discussed this before, we define the parties as sender rmp and receiver rmp.

Pete: is there any problem with using sending and receiving.

Jacques: I would agree with sending and receiving.

Pete moves to change “sender rmp” with “sending rmp” and “receiver rmp” with receiving rmp” Jacques seconded.

No opposition motion passes.

569: Sequence Number is not a Feature; it is simply a mechanism used to

Implement Guaranteed Message Ordering. Should not be given equal status

to the other 3 features.

Defer to the general document restructuring exercise.

1025-1030: Example in which SOAP Fault may also convey an RM

Acknowledgment requires a confusing or impossible processing order.

(Process RM headers, remember that an Ack needs to be sent, continue

with header processing and SOAP Body validation and finally "application

processing space outside the realm of the receiving RMP".) How does

the RMP know when all processing has been completed, then intercept a

possible SOAP Fault in order to attach its Ack?

Ø Tom took an action a proposal to clarify when the Receiving RMP may need to send a SOAP fault to close the WSDL level response.

1990: Remove appendix if there is nothing to say here; the sole item

listed is already done (Appendix A).

defer to general document restructure.

The specification contains no reference to the schemas. They should

be listed in the normative appendix, and introduced at an appropriate

location in the text, perhaps at the beginning of Section 4.

Need to reference schemas in the document.

Agreed to add this somewhere, will determine where to put it with document restructuring.

269: Remove line break in the middle of "response".

501: "the Sender RMP notifies a delivery failure"

should be

"the Sending RMP is notified of a delivery failure".

522: "an" should be "a".

526: "nor to notify failure on the sender side" should be "nor to notify

the RMP Sender of the failure".

527: "it's" should be "its".

Schemas: "it's" (in comment blocks) should be "its".

1036: Grammar.

Ø Add this to Tom Rutt action item on the RMP sending Soap Faults.

(The above list is not comprehensive; we could use a thorough proofreading

pass to catch errors in grammar and punctuation.)

Iwasa will post his remaining edits as comments to the existing .993, rather than producing a new version before the meeting.

Everyone should send comments on this .993 editor’s draft document before the F2F meeting.

Tom: we could initiate another 7day, CD ballot the Tuesday after the meeting.

Pete: If we agree the changes are not substantive we do not need another public review.

4.4 Comments from Martin Chapman

· RE: [wsrm] [Fwd: Comments on WS-Reliabilty CD 0.992]
From Jacques Durand <JDurand@us.fujitsu.com> on 16 Apr 2004 21:19:22 -0000

· RE: [wsrm] [Fwd: Comments on WS-Reliabilty CD 0.992]
From Jacques Durand <JDurand@us.fujitsu.com> on 14 Apr 2004 23:43:15 -0000

· [Fwd: Comments on WS-Reliabilty CD 0.992]
From Sunil Kunisetty <Sunil.Kunisetty@oracle.com> on 14 Apr 2004 21:18:30 -0000

Ø Jacques will take an action to write a proposal to try to resolve Martin C’s comments.

4.5 Aborted Out of Order sequence

Ran out of time, agreed to Put this topic on the agenda for the meeting.

· Re: [wsrm] treatment of aborted out-of-order seq
From "Alan Weissberger" <ajwdct@technologist.com> on 14 Apr 2004 01:37:59 -0000

· treatment of aborted out-of-order seq
From Jacques Durand <JDurand@us.fujitsu.com> on 14 Apr 2004 00:15:05 -0000

We talked about two Issues that are not unrelated,

yet after review, I believe only one remains:

----- Issue 1:

Should the Receiver warn the Sender that an out-of-order sequence has been

aborted on the Receiver side, due to a reason other than message expiration?

(in case of message expiration, the Sender can - generally - deduce the failure).

Position 1: This can't be more than just an optimization, as the reliability

contract would not be broken anyway (would not cause delivery of un-ordered messages !)

And also we never rely on error messages for critical RM logic.

Note also that any further "quantitative" aspect of RM (e.g. about max length of

out-of-order sequence) is out of scope for V1 (line 103, sec 1.2)

Position 2: This is more than just an optimization, as it is a special failure case

with potential high cost if not dealt with as efficiently as possible:

without knowledge that a sequence has been given-up, cumulative and useless

resending (and new sending) may overwhelm the Receiver.

We fault individual messages for various reasons, including lack of storage resource,

so why not fault such a multi-message failure?

Opinion: In case a Poll request is used by the sender, it does not cost much to give

notice of the failure (see example in Issue #2 below) in the poll response.

So even if we see this notification as no more than an "improvement" (Position #1)

we can fault the dropped messages in the response.

But when callback is possible - and requested - should the Receiver send:

(a)- nothing at all

(b)- a special PermanentProcessingFailure for the entire group (so will that look like responses we do

for "singleton" groups?)

(c)- a PermanentProcessingFailure for each dropped message.

I personally favor (b) as a consistent complement to my opinion in poll request

case. A MAY or a MUST? I think again its just an optimization, so a MAY is OK.

----- Issue 2:

When we talk of generating Faults, and how to get them to Sender in case neither

callback or response pattern is possible. In that case, Polling is the only way a

Sender can get faults generated on Receiver.

Well, it appears that the Poll response can actually give the fault code,

so the issue is moot(so much for me).

A response to a poll about an aborted sequence, (assuming Position 2)

would look like:

<Response

xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1"

xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

soap:mustUnderstand="1">

</SequenceReplies>

</Response>

NOTE: should we have a new fault code: "InvalidGroupId" for requests

concerning groups that are non-existent (possibly because already terminated?)

5 Frequently Asked Questions:

Ran out of time, agreed to put this topic on the agenda for the F2F meeting.

· Comment on FAQ
From "Bob Freund" <Bob.Freund@hitachisoftware.com> on 13 Apr 2004 22:08:45 -0000

Agreed to this at last week’s meeting.

The following is left over from Last Week’s agenda.

· Initial list of WSRM FAQs
From Tom Rutt <tom@coastin.com> on 24 Mar 2004 00:18:43 -0000

· RE: [wsrm] Input for FAQ question
From Jacques Durand <JDurand@us.fujitsu.com> on 6 Apr 2004 17:27:19 -0000

Title: RE: [wsrm] Input for FAQ question

A way to approach the composability with other WS-* specs is that they

are likely to fall under these (fuzzy) categories :

(a)- "Under WS-R": Add-ons to SOAP transport like routing, addressing,

that WS-R may need to accommodate or profile.

Status: nothing in the open space yet...

(b)- "Supporting WS-R" specifications (policies, WSDL annotation), that support some function

assumed by WS-R but not central to its deployment:

Status: not finalized or not open.

(c)- "Complementary to WS-R" specifications (Security, transactions, Context...)

that support other business requirements requirements likely to be used in conjunction with reliability, and share message footprint.

Soap headers composability and processing model make this possible. Apparent redundancy (message ID, reply address..) should not be an issue.

Appropriate profiling and guidelines may apply.

(d)- "Over WS-R", Higher level specifications (BPEL, Choreography, CAF, ASAP...)

would use/profile reliability, not the reverse.

That may help a bit I hope. Our focus would be on (c) this time.

Jacques

-----Original Message-----

From: Tom Rutt [mailto:tom@coastin.com]

Sent: Tuesday, April 06, 2004 9:39 AM

To: Tom Rutt

Cc: wsrm

Subject: Re: [wsrm] Input for FAQ question

Tom Rutt wrote:

> How can ws reliability be used with other ws reliability protocols.

This is a mistake it should read "How can ws-reliability be used with

other web service protocols.? "

> Answer :

> An important consideration in design of the WS-Reliability protocol

> was to have it be orthogonal to any other web services protocols which

> define the use of soap header elements.

> WS-Reliability defines elements to be sent in Soap headers . Our

> header elements only contain parameters essential for the operation

> of the WS-reliability protocol. For example, WS-reliability defines

> a reply to element for the sending Reliable Message Processor to

> convey a call back address for the Reliable messaging reply. This

> address is independent of any other reply mechanisms used for other

> protocols (e.g., WSDL response is not influenced by the WS-Reliability

> reply To parameter).

> .

New from Jacques on ebms differences

Action 041304-1 , Action 033004-5
From Jacques Durand <JDurand@us.fujitsu.com> on 20 Apr 2004 19:33:28 -0000

Action 033004-5:

Q: What is the relationship between WS-R and ebXML V2.0?

A: Overall, they both have same messaging reliability contracts as objectives:

guaranteed delivery, no duplicate delivery, ordered delivery, and combinations

of these.

However, WS-R has improved on scalability and performance by generalizing the

use of sequence numbers, and can accommodate different security and

access conditions on each party, as this is more frequently the case

with a Web service and its clients, compared to more symmetrical

access conditions in messaging. The reliability contract is more

"application-oriented" in WS-R, where acknowledgment is on final delivery,

in contrast to "on receipt" by the message handler in ebMS.

Jacques

Action 033004-4
From "Goodner, Marc Andrue" <marc.andrue.goodner@sap.com> on 20 Apr 2004 20:59:40 -0000

Action 033004-4

Why does the spec have a different name than the TC?

The difference in naming of the TC (WS Reliable Messaging) and the specification (WS Reliability) is a result of how materials were originally submitted to OASIS to initiate this activity. The TC chose not to rename the specification to avoid confusion with a similarly named, though unrelated, specification (WS-ReliableMessaging) that has not been submitted to a standard body. This permits one to unambiguously refer to the exact specification you are discussing.

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 Status of Action Items

3.1 Action 032304-2 – (Sunil & Jacques) Completed – 4/20/04

3.2 Action 033004-3 – (Jacques) Pending

3.3 Action 033004-4 – (Mark G) closed 4/20

3.4 Action 033004-5 – (Jacques) closed 4/20

3.5 Action 033004-6 – (Tom) Pending

3.6 Action editors-1 – (Marc and Doug) Pending

3.7 Action 041304-1 – (Jacques) Completed 4/14/04

3.8 Action 041304-2 – (Iwasa) Needs Discussion – 4/20

3.9 Action 04304-3 – (Sunil) completed – 4/20

4 Discussion of Issues and editorial Comments

4.1 Retry parameters

4.2 Comments from XMLP WG thru Pete Wenzel

4.3 Comments from Pete Wenzel

4.4 Comments from Martin Chapman

4.5 Aborted Out of Order sequence

5 Frequently Asked Questions: