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 minutes of 7/6 teleconf


The prelim minutes are attached.  Please provide corrections before Friday.

We resolved the issues, and Iwasa will post a draft 1.05 for serious 
review with comments
requested before end of business on Next Monday, July 12.

I will schedule a vote for CD at the next meeting on July 13.

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

Preliminary Minutes WSRM TC Conference Call –July 6, 2004

 

The meeting of the WSRM TC  took place by teleconference 

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

 

 

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:

First Name

Last Name

Email

Role

Company

Voting Level

Jeff

Turpin

jturpin@cyclonecommerce.com

Member

Cyclone Commerce

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

Abbie

Barbir

abbieb@nortelnetworks.com

Member

Nortel Networks

1

Mark

Peel

mpeel@novell.com

Member

Novell

1

Pete

Wenzel

pete@seebeyond.com

Member

SeeBeyond

1

Chi-Yuen

Ng

cyng@cs.hku.hk

Member

University of Hong Kong

1

 

 

 Meeting  is  quorate.

 

3         Minutes Discussion

3.1      Appointment of Minute Taker

Tom Rutt will take minutes.

 

Minutes will serve to record issue resolutions.

3.1      Approval of previous meeting minutes

The minutes of the June 29 teleconf are posted at:

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

 

Bob F moved to approve, Jishnu seconded.

 

No opposition minutes approved.

 

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

 

Jacques took into account the remarks from several people.  He edited the previous proposal, with edits to make it clear, and to not include unnecessary terms.

 

In section 2.2, a shorter set of requirements on rmp operations and invocations.  It was clarified that the submit and deliver are mandatory.

 

Tom: we need to clarify in a few places that the respond is invoked when a consumer payload is expected.

 

Use proper subheadings for two subsections in section 2.4.

 

Use proper subheadings for subsection so section 2.5.

 

 

·  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

 

Re: [wsrm] Uploaded contribution (June 30) on messaging model - MEP update
From "iwasa" <kiwasa@jp.fujitsu.com> on
5 Jul 2004 08:14:52 -0000

 

The document FiguresFor1.05.pdf has been submitted by Kazunori Iwasa (kiwasa@jp.fujitsu.com) to the OASIS Web Services Reliable Messaging TC document repository.

 

Document Description:

This PDF file contains proposed updates for figure2, 3, 4, 5, and 8 consistent with Jacques's contribution document at http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7523/COntribution-JD-WS-Reliability-2004-06-30.pdf

 

 

Download Document: 

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7562/FiguresFor1.05.pdf

 

 

On figure 5 change Response/Response to Response/Request

 

Iwasa moved to resolve issue with Jacques proposal as amended above.  Bob Freund seconded.

 

No opposition, motion passes.

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.

“

 

Tom: need to add “and when a consumer response payload is expected,” to the lead in text.

 

Bob moved to resolve issue with amended text above.  Iwasa seconded.

 

No opposition, motion passes.

 

Jishun moves to amend, to clarify that this is either or, but not both.

 

Bob seconded.

 

No opposition.

 

Final text of motion proposal:

“

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, and when a consumer response payload is expected,  the response of the SOAP MEP instance must contain one or the other of the following, but not both:

-          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)., or;

-          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 behaviors satisfy

those expectations.

“

 

 

No opposition  motion passes.

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

>

 

Tom: Doug suggested adding “and when a consumer response payload is expected” to both statements.

 

Bob F moved, Jishnu seconded to resolve this issue with the amended text:

“

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

element, and a consumer response payload is expected, a SOAP

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

problem with processing by the receiving RMP, and a consumer response payload is expected, a SOAP server fault must be returned.

“

No opposition, motion passes.

 

 

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

 

 

> The most recent copy of this schema[1] does not seem to support (allow

> validation of) the WS-Reliability 'bare URI' scheme.  To directly insert

> text into the wsrm:ReplyTo element, the ref:ServiceRefType type must

> support mixed content.  That is,

>

> <xsd:complexType name="ServiceRefType">

>   <xsd:sequence>

>     <xsd:any namespace="##other" processContents="lax"/>

>   </xsd:sequence>

>   <xsd:attribute name="reference-scheme" type="xsd:anyURI" use="optional"/>

> </xsd:complexType>

>

> should instead be

>

> <xsd:complexType name="ServiceRefType" mixed="true">

>   ...

> </xsd:complexType>

>

> An alternative would be to leave ServiceRefType as is and define a

> particular BareURI (simple) type or element in either reference.xsd or

> ws-reliability-1.1.xsd.  Lots of options but the element would be simple

> in every case:

>

 

Good catch. I too prefer specifying a separate element/type to making it

mixed. Making it mixed will require us to specify what happens if the

content is indeed mixed -- i.e. has both CII and EII.

Defining the new element/type for bare URI just seems simpler.

 

> <xsd:element name="BareURI" type="xsd:anyURI">

>

> or

>

> <xsd:simpleType name="BareURIType">

>   <xsd:restriction base="xsd:anyURI" />

> </xsd:simpleType>

>

> <!--

>    BareURIType would be ref:BareURIType if the element were in the

>    WS-Reliability schema while the type is in the reference schema.

> -->

> <xsd:element name="BareURI" type="BareURIType">

>

> I lean slightly toward this second approach because it is more

> consistent with the other expected (WS-Addressing or WS-MessageDelivery,

> for example) cases.  That is, the element of ref:ServiceRefType would

> have the consistent semantics of identifying the set of messages in

> which the contained address is relevant.  The namespace of the contained

> element and the @reference-scheme value would identify the semantics of

> that address.

>

> Which raises another niggle I had not considered earlier: I believe the

> namespace of the contained element or the direct inclusion of text in

> the wsrm:ReplyTo element (if we leave that option) provides the same

> information as the @reference-scheme value.  Do we need both?

>

 

The reference-scheme attribute is optional. Therefore if it is

considered to be redundant for a particular addressing scheme then it

could certainly not be used (as is the case for bare uri).

 

Having the optional reference-scheme attribute covers the case where the

QName of the child EII does not specify the semantics of the addressing

scheme. For example, WS-MD uses the WSDL 1.1 service element as a

reference (with some restrictions on the contents of the service

element). In this case the child EII will be wsdl11:service. It is

possible that some other spec or some eventual addressing WG/TC may

decide to use wsdl:service QName but with perhaps slightly different

semantics/restrictions than WS-MD. In such a case the optional

reference-scheme attribute comes handy. So I have a slight preference

for keeping it.

 

Thoughts?

 

> thanx,

>     doug

>

> [1]

> http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/7108/reference-1.1.xsd

>

 

Action on Doug and Anish to come up with a proposal before the end of the week to resolve them.

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

 

Bob F moved to add new issue and resolve with new text, Alan weisberger seconded.

"

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.

"

 

No opposition motion passes.

 

 

Iwasa will publish a new edigtors draft 1.05 with the agreed changes above.

 

 

6         Discussion of Document Progression.

 

For discussion

 

July 6: Have agreed on resolutions to all open issues.

July 7: 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 over .992

               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)

 

Bob: how did the state diagrams change.  How substantive changes regard what fundamental changes are made to the state diagram.

 

Tom: I can state we just allowed faults to be sent without ack requested.

 

 

7         Frequently Asked Questions

 

Oasis staff posted the faq at:

 

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

 

 

 OASIS Web Services Reliable Messaging TC

FAQ

3. How does the WS-Reliability protocol relate to WSDL operation types?

WS-Reliability has been designed to support One-Way and Request-Response operations. The two following requirements are observed by WS-Reliability:

•              An implementation of WS-Reliability is not supposed to be aware of the type of WSDL operation associated with the messages it is processing.

 

Tom: This is old wording and needs to be fixed.  Agree that we should update this text after the next CD is approved.

 

•              The RM protocol specified is compatible with current WS-I profiles.

One-Way operations: All specified RM features apply to these operations, with the following restriction: in order to comply with current WS-I profiles, the "Response" reply pattern must not be used with these operations.

 

 

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

 

Agreed to update the timing question when we have more information after next week.

 

Bob moved to adjourn, Alan seconded.

 

No opposition, meeting adjourned so Bob can complete his honeymoon.

 

 



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