Full Agenda of WSRM TC Conference Call �May 18, 2004

The meeting of the WSRM TC� will take place by teleconference

Tuesday, May 18, 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

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

4 Status of Action Items

�� Action Item list from 5/11 meeting
From Tom Rutt <tom@coastin.com> on 18 May 2004 16:00:29 -0000

Iwasa to incorporate resolutions from 5/11 meeting on 11.14

5 Discussion of Issues and editorial Comments

The following issues list not updated from last weeks minutes yet) includes open items which need further discussion:

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

5.1 PC3.14 Not Supported Feature Fault

PC3.14

Alan Weissberger

Title: Not Supported Feature Fault condition

Description:

Line 408-406: If a reply pattern is sent that had not been previously agreed upon, it will be rejected, with a Fault message: Non Supported Feature returned to the sender Alan suggested: MUST BE

Proposal: the text regarding MUST send for faults should be stated in a general manner to accommodate polling or delayed callback. A single section to explain what _sending a fault_ means. _Sending an RMfault must be interpreted differently depending on the reply pattern in use._ Jacques took action item to add appropriate text to also clarify that an RM-Fault must be returned if the message cannot be delivered because the requested reply pattern is not supported Resolution: agreed not yet fully applied

From Last week�s minutes;

Tom: Issue on not supported feature: this is application specific, leave to profiles.�

Bob F: I agree this detail can be left to profiles.

Jacques: this is not critical to the reliablility protocol.� An implementation would still work if it sends no faults at all.� Faults could be viewed as convenience feature.� We need to be consistent across the spec.

5.2 Editorial comments from Tony Graham (items PC11.x)

Mail from Tony Graham:

�� Re: [wsrm] New Editor's draft .996 posted (with Jacques Refactoringchanges)
From Tony Graham <Tony.Graham@Sun.COM> on 3 May 2004 22:30:18 -0000

5.2.1 PC11.11

2. Line 288, 304: Why must the time be identifiable?

�� I would like this to be explained to me.

PC11.11	Spec	Editorial	open	Tony Graham
	Title: Section 1.6 line 288, 304
	Description: Why must the time be identifiable? Why is it not sufficient to just preserve the order of submissions, e.g., in a queue?
	Proposal: Need resolution. (Not applied)Proposal: replacing _The time_ with _The order_
	Resolution:

Action from last week Tony will take PC 11.11 to email discussion

5.2.2 PC11.15

4. Line 366

�� My comment had to do with the sentence construction.� Looking at

�� the comment in the preliminary minutes, it seems likely that the

�� sentence will change anyway.

PC11.15	Spec	Editorial	open	Tony Graham
	Title: line 336 of .993
	Description: A reply may now include multiple Acknowledgment Indications.
	Proposal: Needs text, if required.
	Resolution:
PC11.19	Spec	Editorial	open	Tony Graham
	Title: line 366 of .993
	Description: "between the application layer, the sender and receiver RMPs" does notscan.
	Proposal: Needs discussion. I believe we shouldn_t mention RM is a contract between application and RMP. Reliable Messaging is for between Sending RMP and Receiving RMP only, but not application and RMP. We can_t guarantee the delivery to the application and should not do that when we don_t define neither protocol between RMP and application, nor RMP API. Even in the ordering case, we don_t guarantee the delivery of a message to the application, and it is completely appropriate. In conclusion, we should not say the RM agreement is an agreement between application and RMP. Sending RMP can_t and shouldn_t guarantee the delivery of a message to the application.
	Resolution:

The line 336. has nothing to do with multiple acks

Tony: Action to send to the list the exact change required on the .996 text.

5.2.1 PC11.24

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

5.2.2 PC11.5

PC11.5	Spec	Editorial	open	Tony Graham
	Title: section 1.3 notiation conventions
	Description: section 1.5 - xml declarations in example
	Proposal: Remove the XML Declarations since they are unnecessary. This was kept in the example, since it is necessary when example includes HTTP header, according to Sunil_s comments
	Resolution:

Discussion from Last week

Tony: we could leave to the Editors.�

Doug: the xml declaration is an optional part of an xml instance.� Soap does not require the xml declaration.� As long as it is in utf-8 any parser should work.

Suggested� to remove to xml declarations in the examples.

Leave open have discussion on email.

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: Needs discussion
	Resolution:

Discussion from 5/11:

What is the conformance requirement of this spec with respect to soap over HTTP.

The soap binding we have could be normative but optional complienace point.

Define a compliance point in the conformance section. For this compliance point.

Sunil The protocol is supposed to be transport agnostic.� There has to be a soap binding to transport.

Anish: you can use a binding which supports soap.� Is it enough to say HTTP post binding.� We could say HTTP post method.� It would be more appropriate to state WSDL 1.1 soap binding. Can used the binding which is defined in soap 1.1

Tom:� Agreed in principal,� we will define a normative soap binding, but not require that binding for conformance.

We talk about WSI compliant in another section.� This is only meaningful with http binding.

5.4 PC14 Extensibility of ReplyTo attribute

PC14	Spec	Technical	open	Anish Karmarkar
	Title: replyTo attribute extensibility
	Description: For the poll and callback pattern WS-R has an attribute 'replyTo' of type xs:anyURI. The value of this attribute in the request message specifies the poll/callback location. This is problematic for the following reasons: AnishEmailMay04
	Proposal: Meeting discussion: perhaps making ReplyTo an element with open content (any) for extensibility) with default restriction (in absence of other agreements) for HTTP POST Binding to be a URL for HTTP requestNeeds discusion
	Resolution:

�� Proposal to resolve the WS-R issue regarding 'replyTo' attribute
From Anish Karmarkar <Anish.Karmarkar@oracle.com> on 11 May 2004 17:55:37 -0000

Discussion from last week:

General agreed that this be in a separate namespace.

Anish:

Remove point 3,

Describe semantics of not present.

In schema make attribute optional.

Suggest a namespace for service ref type.

Anish too action to provide amended proposal on reply to element, target for approval at next meeting.

Initiate discussion,.

6 Discussion of Document Progression.

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.

wsrm message