[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 5133Title: Draft Agenda to WSRM TC Conference Call – May 06, 2003
Full Agenda of WSRM TC Conference Call – The meeting of the WSRM TC will take place by teleconference (UTC - 5)
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 TakerTom Rutt will take minutes. Minutes will serve to record issue resolutions. 3.2 Approval of previous meeting minutesThe 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 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 FaultPC3.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) 5.2.1 PC11.112. Line 288, 304: Why must the time be identifiable? I would like this to be explained to me.
Action from last week Tony will take PC 11.11 to email discussion 5.2.2 PC11.154. 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.
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
5.2.2 PC11.5
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
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
· Proposal to resolve the WS-R issue regarding
'replyTo' attribute 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 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]