Full Agenda of WSRM TC Conference Call –May 25, 2004

The meeting of the WSRM TC  will take place by teleconference

Tuesday, May 25, 2004, from 5:30 to 7:30 PM Eastern Standard Time

(UTC - 5)

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 editorial comments

5 Discussion of Document progression

6 Discussion of FAQ for WS-Reliability

7 Discussion of potential f2f meeting in Brussels in October

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 May 4 teleconf are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6811/MinutesWSRMTC050404b.htm

These include Jeff M in the roll call.

The minutes of May 11 Teleconf are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6782/MinutesWSRMTC051104.htm

The minutes of May 18 Teleconf are posted at:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6882/MinutesWSRMTC051804.htm

4 Status of Action Items

4.1 Action editors-1 (Marc and Doug) Pending

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

- open

4.1 Action 050404-1 (Iwasa)

Action on Iwasa to add new annex pointing at schema with the

disclaimer of precidence.

4.2 Action 050404-4 (Iwasa)

Iwasa has action item to update figures to get rid of application layer.

4.3 Action 051104-10 (Jacques)

The current answer to the FAQ question on wsdl operation types is only about reply patterns.

Ø Jacques; Action: Jacques will write an answer to the FAQ question on how WS-Reliability relates to WSDL operation types.

4.4 Action 051804-1 (Iwasa)

Ø Action: Iwasa will complete the agreed resolutions from public comments Resolution Issue list.

PC6.2 , PC7.12 , PC10.3 , PC11.5 , PC11.6 , PC11.9 , PC11.11 , PC11.13 , PC11.14 , PC11.20 , PC11.25 , PC12 , PC14

4.5 Action 051804-2 ( Bob F )

Action: Give it to the Demo Subcommittee to work on “company Using Spec” letters. Successfully using consistent with OASIS IPR policy

4.6 Action 051804-3 ( Tom )

Action: Tom will try to locate earlier submission to show Bob.

5 Discussion of Issues and editorial Comments

The following issues list includes open items which need further discussion:

http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6924/PublicCommentsIsssues-052504Input.html

5.1 PC 11.15

PC11.15	Spec	Editorial	open	Tony Graham
	Title: line 336 of .993
	Description: A reply may now include multiple Acknowledgment Indications.
	Proposal: Tony provided the following suggestion: From Tony Graham on 18 May 2004 21:22:25 -0000Lines 201-202 of 0.997:"An indication referring to a previous message, that is either anAcknowledgment Indication or a Reliable Messaging Fault Indication."Proposed replacement:"An indication from the Receiving RMP of the success or failure of the deliver operation of one or more previous messages that were sent by the Sending RMP." Discussion at 5/18 meeting Tom: the term reply was intended to be for a single request message. The response could contain the replies for multiple messages. Response could be defined to include for multiple replies. Take this back to the list for further discussion.
	Resolution:

Email from Tom Rutt on 5/25/04 Subject (Proposal to resolve PC11.15):

Lines 204-206 currently state:

Reliable Messaging Reply (RM-Reply):

An indication referring to a previous message, that is either an Acknowledgment Indication or a

Reliable Messaging Fault Indication.

Change the definition to:

An indication refering to a previous reliable message, that is either an Acknowledgement Indication or a Reliable Messaging Fault Indication. For the Callback and Poll reply patterns, RM-Reply indications for multiple reliable messages MAY be included in a single Reliable Messaging Response.

5.2 PC11.24

PC11.24	Spec	Editorial	open	Tony Graham
	Title: Section 3, Reliability Features
	Description: "Business payload" is undefined.
	Proposal: Line 499 Needs definition for Business payload or replacement text
	Resolution:

Email from Tom Rutt on 5/25/04: Subject ( Proposal to resolve PC 11.24)

Proposal to resolve PC11.24

The word payload is used in the following lines of draft .998 without the word “business” preceding :

169, 170, 171, 172, 173, 176, 177, 178, 181, 376, 390, 403, 405, 418, 425

The two words “business payload” are used in the following lines of draft .998:

373, 401, 404, 408, 417, 415, 411

Proposal:

Change “business payload” to “payload” wherever occurring in the spec.

Add the following definition for Payload:

Payload: the contents within the SOAP body of a Reliable Message

5.3 PC13 HTTP POST as Mandatory

PC13	Spec	Editorial	open	Tom Ruttl
	Title: HTTP POST Binding Clarification
	Description: We need to clarifiy that the mandatory binding in the spec is to use htttp post.This is not stated clearly.In fact we need to clarify the exsting lines 1310, 1311, 1312"(3) The Acknowledgment Message is sent with another HTTP connection from the Receiving RMP to the Sending RMP. Example 15 is an example of this message.(4) The HTTP response for (3) has no HTTP message body. Example 14 is an example for this HTTP Response."to require an http post request.This clarification is needed, for interoperability, to avoid the use of http get when http post is expected.
	Proposal: From Tom Rutt on 18 May 2004 21:22:35 -0000Add the following paragraph to the intro to section 6"This section specifies a normative binding of WS-Reliability soap header elements, using the SOAP binding to HTTP, as specified in Section 6 of SOAP 1.1. The WS-Reliability header elements, when mapped to an HTTP request, must be carried in an HTTP POST operation."Add the following sentence to the conformance clause:"The binding of WS-Reliability protocol specified in Section 6 of this specification, using SOAP HTTP binding defined in section 6 of SOAP 1.1, must be used when this specification is bound to SOAP over HTTP."Meeting discussion 5/18:Anish: What do you intend on this wording. Are other protocol transport bindings allowed.Tom: the intent is If you use this spec with SOAP over HTTP you must use the binding in section 6.Take this to the list for wordsmithing.
	Resolution:

· Re: [wsrm] Clarification of HTTP POST Binding for WS_Reliability
From Tom Rutt <tom@coastin.com> on 24 May 2004 16:11:28 -0000

Here is my refined proposal to satisfy the HTTP mapping issue:

Tom Rutt wrote:

> Add the following paragraph to the intro to section 6

> "

> This section specifies a normative binding of WS-Reliability soap

> header elements, using the SOAP binding to HTTP, as specified in

> Section 6 of SOAP 1.1. The WS-Reliability header elements, when

> mapped to an HTTP request, must be carried in an HTTP POST operation.

> "

Change to:

This section specifies a normative binding of WS-Reliability header

elements, as SOAP headers carried using HTTP, as specified in Section 6

of SOAP 1.1. In particular, WS-Reliability header elements, when

mapped to an HTTP request, must be carried in an HTTP POST operation.

> Add the following sentence to the conformance clause:

> "

> The binding of WS-Reliability protocol specified in Section 6 of this

> specification, using SOAP HTTP binding defined in section 6 of SOAP

> 1.1, must be used when this specification is bound to SOAP over HTTP.

> "

Change the new conformance statement to the following:

An implementation which uses SOAP over HTTP transport to carry

WS-Reliability header elements, MUST conform to the normative mapping

defined in Section 6 of this specification, for all RM-reply patterns

supported by the implementation.

5.4 Editorial Comments

5.4.1 ReplyTo Property

· Editorial change to reply to property
From Tom Rutt <tom@coastin.com> on 25 May 2004 16:31:57 -0000

Lines 1741 - 1742 of draft .998

The property for reply to needs to be updated to the new type:

Currently states:

A.V.D. ReplyTo URI

This property is identified by the QName "wsrmf:ReplyTo" and corresponds

to the semantics specified by the WS-Reliability reply-to. The type of this property is wsrm:ReplyTo.

delete the word "URI" from the title of the subsection.

Change the type from "wsrm:ReplyTo" to "ref:ServiceRefType"

need to add the namespace prefix "ref" to the document’s namespace table.

5.4.2 Namespace for Schema, and location

· [Fwd: [Fwd: How do we post schemas at the namespace location forOASIS specs.]]
From Tom Rutt <tom@coastin.com> on 25 May 2004 16:09:29 -0000

Sunil wrote:

This is what WS-Security is also doing. To achieve this, we need to CHANGE the

namespaces of all the 3 schemas to start with the following:

http://docs.oasis-open.org/wsrm/2004/05/<filename>

Could you add this as an issue for tomorrow's con. call?

-Sunil

Need to change namespaces of our schemata to be the same as URL for final location on OASIS server. Also, may need to revisit the use of version 1.1 in our namespace as a “direictory”.

5.4.3 Editorial Comments from Sunil on draft .998

· Re: [wsrm] Groups - WS-Reliability-2004-05-24.pdf uploaded
From Sunil Kunisetty <sunil.kunisetty@oracle.com> on 25 May 2004 05:05:00 -0000

Iwasa,

Some comments on the latest version:

Table 2(line 138) should also include the namespace for ServiceReferenceType

schema..

Prefix: ref

Namespace: http://www.oasis-open.org/committees/wsrm/schema/1.1/reference

Line 176/Definition of ‘Deliver’.

I’m uncomfortable with the usage of the word ‘transfer’ in the definition of the ‘payload’.

I prefer the words ‘makes available’. Proposed new definition:

Deliver:

An abstract operation supported by the RMP. When invoked, the operation makes available the payload data of the reliable message to the Consumer.

Line 274 should be reworded to also cover the async. case. I believe I’ve mentioned this couple of times before. The RM-Reply can either be sent in underlying response of the request or sent as a different request.

Table 3/Line 309:

Is ReplyTo to an agreement item? The schema on page 59 (line 1743) seem to

include this, where as the table doesn’t reflect it. I believe it shouldn’t be there, and table content is correct. If so, we need to update the schema.

Example 1 (pg. 17/line 510) still uses the old version of ReplyPattern type.

Same thing with Example 3/Pg 23/Line 683. Should use the new ReplyPattern with

Value sub-element.

Same thing with Example 10.

Appendix A:

Please include links to the 2 new schemas (fnp.xsd for the F,P, & C constructs and wsrmf.xsd for WSRM properties).

Remove the schema A.VI. from the document. If it has to be included, it needs to be correct with the correct namespaces.

Examples A.VII.A, A.VII.C, and A.VII.D use “wsrmf:DuplicateElimination” which should be replaced with “wsrmf:NoDuplicateDelivery”.

-Sunil

5.4.4 Pete Wenzel comments on draft .997

· Re: [wsrm] Groups - WS-Reliability-2004-05-18.pdf uploaded
From Pete Wenzel <pete@seebeyond.com> on 18 May 2004 21:49:36 -0000

There are a few problems with the section numbering in this draft:

Section numbers are missing from level-3 and level-4 headers in

Sections 3 and 5.1.3.

Some sections are numbered (1) instead of X.Y.1; prefer the latter,

so they can be referred to completely and will appear in TOC

sensibly.

Appendix A numbering format should be A.2.2 instead of A.II.B, for

example.

Table of Contents needs to be refreshed.

--Pete

6 Discussion of Document Progression.

Tentative Schedule:

June 1 – all changes agreed at TC Teleconf.

June 2 – Frozen document available for informal 6 day review.

June 67 – editorial changes required to be posted to list.

June 8 – TC votes to approve CD at Teleconf, and also votes to submit to OASIS member vote.

June 15 – submission sent to OASIS Staff

7 Frequently Asked Questions

· Updated WSRM FAQ
From Tom Rutt <tom@coastin.com> on 11 May 2004 01:11:54 -0000

The question:

Q: How does the WS-Reliability protocol relate to WSDL operation types?

Answer:

The current answer is only about reply patterns.

Ø Jacques; Action: Jacques will write an answer to this question.

After that we can decide if we need another question about reply pattern specifically.

8 Discussion of Potential Face to Face meeting in Brussels in October

WSRM TC members, all OASIS chairs received an e-mail from the OASIS staff and they need a quick reply.

All TC chairs are being asked if their TCs would be interested in holding a F2F meeting in Europe, probably the week of October 4-8 at an event hosted by OASIS in Brussels . I think the plan is that this will be similar to the recent New Orleans event..

For right now, OASIS are just looking for an informal "yes we might be interested" or "no we probably won't be interested".

wsrm message