[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary minutes of 5/18 Teleconf
The prelim minutes are attached. Please provide any corrections to the list before Friday. -- ---------------------------------------------------- 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
|
Preliminary Minutes of WSRM TC Conference Call –May 18, 2004 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 is 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 Defer approval to next meeting. 4 Status of Action Items · Action Item
list from 5/11 meeting Iwasa to incorporate resolutions from 5/11 meeting on 11.14 4.1 Action editors-1 (Marc and Doug) PendingMarc G and Doug B to updated issues list to reflect agreements in CD .992.- open4.2 Action 042904-3 (Jacques) PendingJacques took an action item to propose this new subsection on special considerations for wsdl request/response operations.closed4.3 Action 042904-4 (Jacques) PendingJacques 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 supportedClosed no text provided. Will discuss.
4.4 Action 050404-1 (Iwasa)Action on Iwasa to add new annex pointing at schema with the disclaimer of precidence.open4.5 Action 050404-2 (Iwasa)Action: Iwasa should check if item 7.13 is done.open4.6 Action 050404-3 (Iwasa)openAction iwasa needs to clarify resolution of item 10.3.Will check the appendix for the updates.4.7 Action 050404-4 (Iwasa)Iwasa has action item to update figures to get rid of application layer.open4.8 Action 050404-5 (Iwasa)When used with soap 1.1, the soap1.1 mustUnderstand attribute MUST be present with value equal to 1 in all RM header blocks.When used with Soap 1.2, the soap1.2 mustUnderstand attribute MUST be present with value equal to 1 in all RM header blocks.Also: Version number should be in the title of the document as version 1.1.Joe Chiusano moved to accept this change, Bob F seconded.No discussion.No opposition, motion passes.Aleady been applied to schema and text.Iwasa: action to ensure the two statements are included. Incorporate version 1.1 in title of spec.open.4.9 Action 050404-7 (Iwasa and Jacques)Jacques, took action, with Iwasa, to produce a new editors draft .997 by Friday. Indicate which public review coments are resolved.closed--
4.10Action 051104-1 (Tom)Action: Tom will reopen issue on not supported feature fault for discussion at next week meeting. closed 4.11Action 051104-2 (Iwasa)Ø Action: Iwasa to apply PC11.6 resolution open 4.12Action 051104-3 (Tony)Ø Action Tony will take PC 11.11 to email discussion open 4.13Action 051104-4 (Iwasa and Jacques)Action: Editors shall incorporate PC11.14 into next draft open 4.14Action 051104-5 (Tony)PC11.15 and 11.19 Tony: Action to send to the list the exact change required on the .996 text. Completed 4.15Action 051104-6 (Iwasa)Ø Iwasa: action to add period if missing for PC11.20 4.16Action 051104-7 (Iwasa)Ø Action: Iwasa will turn smart quotes to normal quotes. Tom will send the required edits to remove smart quotes to Iwasa Still open 4.17Action 051104-8 (Tom)Ø Action: tom will start email discussion on this normative statement of our soap http post binding, and proper conformance text. Closed 4.18Action 051104-9 (Anish)Ø Anish action to provide amended proposal on reply to element, target for approval at next meeting. Closed will discuss at meeting 4.19Action 051104-10 (Jacques)The current answer is only about reply patterns. Ø Jacques; Action: Jacques will write an answer to the FAW question on how WS-Reliability relates to WSDL operation types. open Ø Action: Iwasa will update the issues list on closure. 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.No opposition to closing without change statement.Close Issue 3.14 with no change, moved by Bob, seconded by Iwasa.No opposition will close Issue 3.14 without change.
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.
Agreed to proposed editorial resolution above, which was provided by Iwasa.. 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.
Mail from Tony: · PC11.15 Lines 201-202 of 0.997: An indication referring to a previous message,
that is either an Acknowledgment 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. Regards, Tony Graham 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 a definition for multiple replies. Take this back to the list for further discussion. 5.3 PC11.19
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. Mail from Tony: · PC11.19 My comment on the text: between the application layer, the sender and receiver RMPswas purely about the punctuation.I do not have the same quibble about lines 294-295 of 0.997.Regards,
Closed as accommodated by Jacques editing, will do final punctuation check linter. 5.3.1 PC11.24
Leave this open. Take to the list. 5.3.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. Pending resolution agreed to remove. Ø Iwasa take action to remove the xml declarations from the examples. Agreed to remove. 5.4 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. Mail from Tom Rutt: · Clarification
of HTTP POST Binding for WS_Reliability 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. " 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. " Iwasa: it would be better to make a strong conformance statement. 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. 5.5 PC14 Extensibility of ReplyTo attribute
· · Action
051104-9 (Anish) -- modified proposal for the 'replyTo' attribute New proposal from anish: All, I took an action to provide an amended proposal
on reply to element. This email fulfills that action. Here is the modified proposal for the 'replyTo' attribute (the modifications are: removed the
reference-scheme URI identifier for the case when only URIs
are used, describes default for the ReplyTo element,
makes the reference-schema attribute optional and provides a namespace URI for
the type ServiceRefType): This proposal replaces the 'replyTo'
attribute with a 'ReplyTo' element with an open
content and defines the default referencing scheme (URI) when used with WS-R.
This allows WS-R to be used with URI and makes it extensible to use other
addressing schemes (WSRef, EPR or whatever may emerge
out of other standards TCs/WGs). The crux of the proposal is as follows: 1) The replyTo
attribute is used in two places: a) On the ReplyPattern
element, and b) PollRequest element. This attribute
is replaced with an element called 'ReplyTo'
described below. 2) Define a new global schema type in the
namespace "http://www.oasis-open.org/committees/wsrm/schema/1.1/reference"
as follows: <xsd:complexType
name="ServiceRefType"> <xsd:sequence> <xsd:any
namespace="##other" processContents="lax"
minOccurs="1" maxOccurs="1"/> </xsd:sequence> <xsd:attribute
name="reference-scheme" type="xsd:anyURI"
use="optional"/> </xsd:complexType> 3) Define a new global element decl in the WS-R namespace: <xs:element
name="ReplyTo" type="wsrm:ServiceRefType"/> The value of the attribute reference-scheme
specifies the "type" of the addressing scheme. When used in WS-R, if
the attribute reference-scheme is not present then the reply-to address is a
URI. 4) For the type PollRequestType
convert the attribute 'replyTo' to an element 'ReplyTo' of type 'ServiceRefType'
with minOccurs=0. PollRequestType
schema type will be as follows: <xsd:complexType
name="PollRequestType"> <xsd:complexContent> <xsd:extension base="wsrm:HeaderBaseType"> <xsd:sequence>
<xsd:element
name="RefToMessageIds" type="wsrm:RefToMessageIdsType" maxOccurs="unbounded"/>
<xsd:element
ref="wsrm:ReplyTo" minOccurs="0"/>
</xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> 5) For the type ReplyPatternType
make it a complex content containing sequence of two elements 'Value' and 'ReplyTo as follows: <xsd:complexType
name="ReplyPatternType"> <xsd:sequence> <xsd:element name="Value"
type="wsrm:ReplyPatterTypeValues"/> <xsd:element
ref="wsrm:ReplyTo" minOccurs="0"/> </xsd:complexType> Details of changes required: 1) Modify the schema as stated above and create
a new schema for NS
"http://www.oasis-open.org/committees/wsrm/schema/1.1/reference" as
stated above. 2) Remove line 644 3) Table 5: s/none/Value, ReplyTo remove "replyTo(URI" 4) Section 4.2.3 will have to change to say that
the element 'Value' can have the values 'Response', 'Callback' or 'Poll'. In
addition, a table for element 'Value' and 'ReplyTo'
will have to be added. The description of replyTo
attribute has to change to describe the element wsrm:ReplyTo. The meaning of the attribute
'reference-scheme' will have to be added along with the fact that the default
is a URI. 5) Section 5.3, add a
table for describing the ReplyTo element 6) Table 9 should be modified to remove 'replyTo(URI)' from the attribute
row and 'ReplyTo" element should be added to the
child elements row. 7) Replace lines 742-745 with the description of
the 'ReplyTo' element, similar to (4) above. 8) Table 16, penultimate row, 2nd column: s/replyTo
attribute/ReplyTo element 9) replace 1331-1332 as
follows: <original> <ReplyPattern replyTo="http://wsrsender.org/abc/wsrListnener"> Callback </ReplyPattern> </original> <proposed> <ReplyPattern>
<Value>Callback</Value> <ReplyTo>
http://wsrsender.org/abc/wsrListnener" </ReplyTo> </ReplyPattern> </proposed> 10) Line 639, 723, 986, 1376, 1379, 1390, 1437,
1438, 1448, 1453: s/replyTo attribute/ReplyTo element 11) replace 1466-1473
as follows: <original> <PollRequest
xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1" replyTo=”http://wsr-sender.org/xyz/servlet/wsrmListnener” soap:mustUnderstand="1"> <RefToMessageIds groupId="mid://20040202.103832@wsr-sender.org"> <SequenceNumberRange from="0"
to="20"/> </RefToMessageIds> </PollRequest> </original> <proposed> <PollRequest
xmlns="http://www.oasis-open.org/committees/wsrm/schema/1.1/SOAP1.1""
soap:mustUnderstand="1"> <RefToMessageIds groupId="mid://20040202.103832@wsr-sender.org"> <SequenceNumberRange from="0"
to="20"/> </RefToMessageIds> <ReplyTo>
http://wsr-sender.org/xyz/servlet/wsrmListnener </ReplyTo> </PollRequest> </proposed> 12) Section A.V.F (lines 1775-1777): Replace the section to conform to the new schema
type wsrmr:ServiceRefType <original> A.V.F. 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 xs:anyURI. </original> <proposed> A.V.F ReplyTo 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 wsrmr:ReplyTo. </proposed> 13) In section A.VI, a) add: <xs:import
namespace="http://www.oasis-open.org/committees/wsrm/schema/1.1/reference"/> after line 1784 b) add a namespace
prefix 'wsrmr' corresponding to the NS http://www.oasis-open.org/committees/wsrm/schema/1.1/reference c) and replace 1797
with: <xs:element
name="ReplyTo" type="wsrmr:ServiceRefType"/> Comments? Thanks! -Anish -- Anish summarized: There is a new namespace URI 1.1/reference. Make attribute reference type optional in schema for service ref type. For the Reply to element in WS-Reliability name space, if reference type attribute is not present, the default for the reply to element, used in WS-Reliability is URI . There is a typo on 13 b) need to add /reference Agreed to put this on the agenda for next week. Be prepared to vote on this proposal next week. Doug: in the Reply to element in WSRM namespace is the default in the spec or in the schema. Anish: it is not in the schema it is in the specification. Doug moved to accept the proposal, Anish seconded. State in the text not the schema, can repeat in each header used. No opposition, motion passes. 6 Discussion of Document Progression.Iwasa will repost the open office documents and put diffs of .997 against .996. New editor draft by end of week for .998. Resolve all issue by next week. Documents by wed morning to do final editorial review. Could conceivable issue 7 day cd ballot on June 12, to close June 9. Doug, why not have a cd ballot at June 8 meeting. Very stable document agreed by June 1. We would have to resolve all open issue by next meeting. Meeting CD ballot June 8 Doug asked the group if the feeling of the TC since the previous public review are sufficent to merit another public review. Only two schema changes: Start attribute and Reply to attribute. Considerable editorial clarification throughout the document. Bob: we have not changed the protocol operation much at all. Doug: we do not have to, however is a substantially better written spec something that would promote more public review. Iwasa: most of the comments on public review, were from TC members, so I think the TC final review is enough. Bob: while we have not made big changes, we have an open process which states public review is required. I do think we would get any more comments from additional people. The sessions at OASIS caused some further clarification. Unless we change the operation of the protocol or provide another mode of operation, the changes are not large. Fujitsu is in the final stages of implementing the spec. Oracle has not implemented the reply to, now that it stable we can. Action: Give it to the Demo Subcommittee to work on these letters. Successfully using consistent with OASIS IPR policy Tom will try to locate earlier submission to show Bob. Bob will check with NEC.. 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. Leave it open. Motion to adjourn Bob F, anish seconded. No opposition. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]