OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Preliminary agenda for WSRM TC meeting 7/6/04


There are proposals to resolve all remaining issues in this proposed agenda.

Please review these proposals, and send your detailed comments with 
proposed changes to the list
before the Tuesday evening teleconfence.

Tom Rutt

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133


Title: Draft Agenda to WSRM TC Conference Call May 06, 2003

Full Agenda of WSRM TC Conference Call July 6, 2004

 

The meeting of the WSRM TC will take place by teleconference 

Tuesday, July 6, 2004, from 5:30 to 7:30 PM Eastern Standard Time

 

 

Conference Bridge number
Toll only : 1-512-225-3050
Participant code: 716071

 

 

1         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 Action Item Status Review

4 Discussions of unresolved comments

5 Discussion of Document progression

6 Discussion of FAQ for WS-Reliability

 

2         Roll Call

Attendance:

 

Meeting ?? quorate.

 

3         Minutes Discussion

3.1      Appointment of Minute Taker

Tom Rutt will take minutes.

 

Minutes will serve to record issue resolutions.

3.2      Approval of previous meeting minutes

The minutes of the June 22 teleconf are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7555/MinutesWSRMTC062904.htm

 

4         Status of Action Items

 

4.1      Action 052503-1 (Tom Rutt) pending

 
Tom took an action item to complete the status column of 
pre public review issues list, with correct URLs.

 

4.2      Action 060104-5 (Jacques) Pending

 

Action: Jacques, will propose further edits, on the FAQ for composability.

 

Still open

 

 

4.3      Action 062904-1 (Jacques) Closed

 

Action: Jacques will propose refined text to resolve Binding model issue.

 

Jacques provided text in contribution draft 1.04 at:

 

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7454/COntribution-JD-WS-Reliability-2004-06-21.pdf

 

 

5         Discussion of Issues and editorial Comments

The following issues list includes items which need further discussion:

 

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7512/PublicCommentsIsssues-062904InputB.html

5.1      PC24

 

PC24

Spec

Technical

Open

Doug Bunting

 

Title: Payload inclusion and MEPs other than request/response

Description: Re: more on payload(s) inclusion and MEPs than our Request-ResponseMEP discussion covers

Proposal: under discussion

Resolution:

 

Uploaded contribution (June 30) on messaging model - MEP update
From Jacques Durand <JDurand@us.fujitsu.com> on
30 Jun 2004 21:10:20 -0000

 

Re: [wsrm] Uploaded contribution (June 30) on messaging model - MEPupdate

Comments on how to amend the figures to go along with Jacques new text:

 

Perhaps Iwasa could post another contribution with the figures fixed,

for us to evaluate along with Jacques new text.:

 

Figure 2: messaging model (include the Respond primitive (perhaps with

dotted line) down arrow from consumer to receiving rmp

 

Figure 3: put solid respond arrow from consumer to receving rmp. Change

"underlying protocol" to "SOAP MEP" on both horizontal arrows

 

Figure 4: Change "underlying protocol" to "SOAP MEP" on both horizontal

arrows

 

Figure 5: Change "underlying protocol" to "SOAP MEP" on all three

horizontal arrows

 

Figure 8: add the down arrow for Respond from consumer to Receiving RMP

 

5.2      PC25

 

PC25

Spec

Technical

Open

Doug Bunting

 

Title: Duplicate message responses

Description: http://www.oasis-open.org/archives/wsrm/200406/msg00078.html

Proposal: under discussion

Resolution:

 

Proposal to resolve PR25 - Duplicate message response
From Tom Rutt <tom@coastin.com> on
2 Jul 2004 19:26:26 -0000

Proposal to resolve Issue PR25 Duplicate message response

 

The public review draft, CD .992, clearly states the following behaviour

in section 4.5:

A message with an RM Fault indication MUST NOT be delivered by the

receiving RMP. If the message cannot be delivered due, say an request fault, then there would

be no meaningful data for the responder to put into the SOAP Body for the WSDL response.

 

When using the Response RM-Reply pattern, a WSDL operation reply will not always be

available for the receiving RMP to return with the RM-Response. This will occur when there is a

Reliable Messaging Fault for the message in the request, or when the message in the request is

a duplicate of a prior delivered message with Duplicate Elimination in use.

 

When a receiving RMP cannot return the WSDL operation response for a request using the

Response Reply Pattern, it MUST return the RM Response in a SOAP Fault message. If the RM

Fault encountered was due to a problem with the request header element, a SOAP client fault

MUST be returned. If the RM Fault encountered was due to a problem with processing by the

receiving RMP (including the inability to return a response due to Duplicate Elimination), a

soap:server fault must be returned.

 

However, the wording above needs to be amended, to use the new terms introduced

by Jacques in contribution draft 1.04. We agreed to put the duplicate

elimination response behaviour in the section pertaining to duplicate elimination.

 

Propose Resolution:

Add the following text at the end of section 3.2.2, Duplicate Elimination protocol requirements:

 

When the Response RM-Reply Pattern is requested with duplicate elimination for a

reliable message, and a resend of that message cannot be delivered to the Consumer by

the Receiving RMP because it is a duplicate of a previously delivered message, the

response of the SOAP MEP instance:

- SHOULD contain a copy of the original response payload returned for

that message ID (in the SOAP Body) in addition to the rm-acknowledgement

indication (in the SOAP Header).

- MAY contain a SOAP server Fault (in the SOAP Body) in addition to the

rm-acknowledgment indication (in the SOAP Header).

 

The Sending RMP and Producer expect either a complete response or a SOAP Fault

when using the Response RM-Reply Pattern and these two allowed behaviours satisfies

those expectations.

 

 

 

5.3      PC26

PC26 Spec Technical Open

Sunil Kunisetty

Title: Soap Fault with RM-Fault

Description: Sunil Mail 1Sunil Mail 2Sunil Mail 3

Proposal: under discussion Resolution:

 

Proposal to resolve PR26 - Soap Fault with rm-fault
From Tom Rutt <tom@coastin.com> on
2 Jul 2004 18:23:02 -0000

 

Re: [wsrm] Proposal to resolve PR26 - Soap Fault with rm-fault
From Doug Bunting <Doug.Bunting@Sun.COM> on
2 Jul 2004 19:35:50 -0000

Tom,

 

I have a slight (very slight) preference toward a SOAP fault in the case

that an RM fault leads to an unexpectedly empty SOAP Body. However, this

text should be focused specifically on that case since the producer may not

be expecting any consumer payloads. SOAP Body content (a SOAP fault) would

be entirely redundant and itself unexpected unless a consumer payload was

expected.

 

To avoid such an over-generalized statement, I would suggest adding "and a

consumer payload was expected" before the comma in both sentences you propose.

 

An editorial nit: Should these two sentences be talking about "soap:client"

and "soap:server" or "SOAP client" and "SOAP server" faults? Consistency

seems necessary here.

 

thanx,

doug

 

[1] ... whom, I assume, is the target of the SOAP fault. This is a bit

counter-intuitive since the sending RMP hides the SOAP messaging layer from

the producer to some extent.

 

 

On 02-Jul-04 11:27, Tom Rutt wrote:

 

> Proposal to Resolve Issue PR26 Soap Fault with RM-Fault

>

> The behaviour that an RM-Fault is returned with a soap fault in the case

> that a response

> payload is not available for response reply pattern was part of the

> public review draft

> cd .992. The changes suggested by Sunil would constitute a substantive

> change to the public review draft.

>

> This behaviour works, and provides fault information separately tarteted

> for the rmp and

> the producer.

>

> However the following sentences were inadvertently removed during

> editing after

> CD .992

>

> If the RM-Fault encountered was due to a problem with the request header

> element, a SOAP

> client fault MUST be returned. If the RM Fault encountered was due to a

> problem with processing

> by the receiving RMP (including the inability to return a response due

> to Duplicate Elimination), a

> soap:server fault must be returned.

>

>

> We agreed to have section 4.5 only talk about rm faults, so the

> parenthetical statement should be removed.

>

> Proposed Resolution:

>

> Add the following paragraph in Line 1070 of 1.04JacquesContrib, after

> the first sentence of the bullet:

>

> If the RM-Fault encountered was due to a problem with the request header

> element, a SOAP

> client fault MUST be returned. If the RM Fault encountered was due to a

> problem with processing

> by the receiving RMP, a soap:server fault must be returned.

>

>

>

> Tom Rutt

>

 

5.4      Comment on the ref Schema

 

Minor technical issue (or two) in the reference.xsd schema
From Doug Bunting <Doug.Bunting@Sun.COM> on
24 Jun 2004 15:43:22 -0000

 

Re: [wsrm] Minor technical issue (or two) in the reference.xsd schema
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on
25 Jun 2004 22:10:52 -0000

 

5.5      Clarification of rm-faults without ack requested

Clarification of RM-faults without ackRequested
From Tom Rutt <tom@coastin.com> on
2 Jul 2004 19:54:58 -0000

At last week's teleconference, it was agreed we have to clarify whether

rm fault indications can be sent if the request

does not include the ackRequested element.

 

The replyPattern element is mandatory, implying that there will be

behaviours which require an rm-reply, even if ackRequested

is not present.

 

The Sending RMP should be made aware when it sends request elements in a

message which are badly formed

 

This I propose we add the following sentence after the first paragraph

of section 4.2.4 AckRequested

 

"

The Receiving RMP MAY publish an rm-fault indication for a reliable

message, even if the AckRequested element is not present in the request

element for that message.

"

 

Tom Rutt

 

 

6         Discussion of Document Progression.

 

For discussion

 

July 6: agree on resolutions to all open issues.

July 8: Iwasa posts draft 1.05 with agreed resolutions

July 12: all editorial comments posted on draft 1.05

July 13: Vote for CD 1.06,

Vote on whether changes are substantive

Potential votes on either (depending of whether changes are voted substantive):

Submit to OASIS for member vote (if not substantive)

Start second 30 day public review ( if substantive)

1         Frequently Asked Questions

 

Oasis staff posted the faq at:

 

http://www.oasis-open.org/committees/wsrm/faq.php

 

Members should propose changes to the list, to update the FAQ after the next CD is approved.

 

 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]