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: Full agenda for 5/18 Teleconf

the full agenda with links, is attached.

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 –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



 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:



These include Jeff M in the roll call.


The minutes of May 11 Teleconf are posted at:




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:




5.1      PC3.14 Not Supported Feature Fault


Alan Weissberger 
Title: Not Supported Feature Fault condition 
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.







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_



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.






Tony Graham


Title: line 336 of .993

Description: A reply may now include multiple Acknowledgment Indications.

Proposal: Needs text, if required.






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.



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





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






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



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






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




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






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




·  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.



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?


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.

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