[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Preliminary minutes of wsrm tc teleconf 5/4/04
The prelim minutes are attached. Please post any corrections before Thursday pm to the entire list. Tom Rutt WSRM Chair -- ---------------------------------------------------- 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 04, 2004 The meeting of the WSRM TC took 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 / Presentation 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 minuteshttp://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/6614/MinutesNewOrleansF2F.htm
Leave open, for Sunil to post a correction. To approve at the next meeting 4 Status of Action Items4.1 Action editors-1 – (Marc and Doug) PendingMarc G and Doug B to updated issues list to reflect agreements in CD .992. - open 4.2 Action 042004-1 – (Jacques) closeAction: Jacques will propose the text changes to the document to remove retry parameters Changes for the agreements section text in .996, still listed in table Iwasa added to section 3 and in the annexØ New action for Iwasa needed to remove retry parameters from table in section 3 and from annex A. 4.3 Action 042904-1 – (Tom and Iwasa) needs discussionAction: Iwasa and Tom will provide text for the new fault code and the reference to it in the section of text Alan cites. Added GroupAborted error code to draft .996, however the paragraph which was cited to add the MUST return sentence was deleted. Did not add a sentence. Could add the following sentence somewhere: ““When group
processing is aborted, the Receving RMP MUST return GroupAborted fault for all non-delivered messages which
have not had an RM reply sent.” 4.4 Action 042904-2 – (Sunil) completedAction: Sunil will update schema for new fault code in the message processing failures sector. Done 4.5 Action 042904-3 – (Jacques) PendingJacques took an action item to propose this new subsection on special considerations for wsdl request/response operations. 4.6 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 supported 4.7 Action 042904-5 – (Jacques) completedJacques took an action on where to move the current section 3.4, with perhaps a re-title of section 3. Jacques will also propose a new document structure to accommodate this and other problems he encounters Completed 4.8 Action 042904-6 – (Jacques) completedJacques took action item to propose appropriate change to using word application (perhaps producer/consumer). Completed in .996, however figures need to be updated to change “application layer” to “producer” or “consumer”. The new figure 1 still has application party. Needs to be removed. Ø New action to Iwasa required to make figure changes. 4.9 Action 042904-7 – (Iwasa) needs discussionAction: Iwasa to apply all editorial changes from Tony’s mail, except for those he considers in need of discussion. Completed on 4/30, there are a few comments that require further discussion at May 4 TC teleconf. 4.10Action 042904-8 – (Tom) completedAction: Tom should put out a call for IPR claims. Done 4.11Action 042904-9 – (Jacques) completedAction on Jacques: incorporate his new Agreement section while doing the document restructure. Done 4.12Action 042904-10 – (Bob F) closedBob F took action to lead a team to provide an initial draft of the comparison paper of WS-Reliability/WS-ReliableMessaging, for review by the TC. Sunil and Jacques joined the team. Add to agenda 4.13Action 042904-11 – (Jacques) closedAction: Jacques will lead a team to ensure the terminology used in the spec is consistent with normative terms in the soap spec. Pete W will work with Jacques to provide a proposal to resolve this. 5
Discussion
of Issues and editorial Comments
The following table includes items which need further discussion: 5.1 Resolution of W3c Protocol group alignment comment
Email from pete: Jacques and others, I believe that recently
adopted text goes a long way toward resolving
the terminology discussion ("what is an RMP?"). I propose the following additional changes
(based on WD 0.996) to close this issue, and
welcome any comments and corrections. 1.1 WS-Reliability is a SOAP Module (as defined by
[SOAP 1.2]), which fulfills reliable messaging requirements that are critical
in some applications of Web Services. SOAP ([SOAP 1.1] and [SOAP 1.2]) over
HTTP [RFC2616] is not sufficient when an application-level messaging protocol
must also guarantee some level of reliability
and security.... [Continue with
remaining text as-is.] 1.2 [Change first paragraph to:] Reliable Messaging (RM) is the execution of a
transport-agnostic protocol based on SOAP for
providing quality of service in the reliable delivery of messages. [Continue with remaining paragraphs.] [Replace these two definitions:] 1.6 Reliable Messaging (RM): The act of processing the set of
transport-agnostic SOAP Features defined by WS-Reliability,
resulting in a protocol which guarantees certain qualities of
service. This includes the processing of
Acknowledgment messages, re-sending of
messages, duplicate message elimination, and message ordering. Change to acknowledgement indications. Reliable Messaging Processor (RMP): A SOAP Node (as defined by [SOAP 1.2]), or a
subset or superset thereof, capable of
performing Reliable Messaging as described by this specification. With
regard to the transmission of a Reliable Message from one RMP to another, the
former will be referred to as the Sending RMP, and the latter as the
Receiving RMP. --Pete Pete moved to close the issue with accepting the proposed text with amendments above. Jacques seconded. No opposition, motion passes. 5.2
Pete stated this may be a valid concern. Leave open and put discussion to the list. Will be put on the agenda for the next meeting. Jacques will initiate discussion of this concern. 5.3
Closed. 5.4
Ø Action on Iwasa to add new annex pointing at schema with the disclaimer of precidens. 5.5
Ø Action: Iwasa should check if item 7.13 is done. 5.6
Bob F: is there any reason we have to send more than 1. Bob F: suggested: “ Any additional messages that are received for an aborted group, until the group expiry time, MUST have the GroupAborted fault sent. “ Jacques, requiring that every message received has to have this fault returned. The Receiver may decide to only send once every 10 messages received in that group. Jacques: we should not mandate one fault notice for each received message. Alan: a responsible sending RMP will cease sending on the group once it receives this fault for this group. This would be a small number of messages in transit which would require sending this fault. Bob F: if you have high bandwidth, low latency channel , they could wait a few seconds to wait and send the fault replies. Jacques: in ebMS people had considered a sender with bad intentions, to overload the receiver. This concern is addressed in the design of the ebMS protocol. In the same way we deferred the resend policy, we could say that the receiver must publish a group abort fault when the group is aborted. This publishing could be open for config parameters to decide the frequency. We need further discussions. Take to the email list. 5.7
Ø Action iwasa needs to clarify. 5.8
Iwasa has action item to update figures to get rid of application layer. 5.9 Superfluous use of two schemataTwo schemas and namespaces are unnecessary for two soap versions. Proposed change: remove the soap 1.2 schema, and change the following lines on the soap 1.1 schema: soap 1.1 schema has: to the folloing: " 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. 5.10Syntax of replyTo attributeNew email from Anish: 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: 1)
A URI does not represent a Web service -- a WS is much more than a URI and a
reference to a WS has to be more than a URI. A URI is certainly part of the WS
reference. URI is necessary but not complete. For example, the URI does not say
what the operation/interfaces/binding/policy/f&P/capability/etc
are. One cannot even specify the value for the "SOAPAction"
HTTP header (which is part of the binding). Although WS-R is not WSDL-centric
(and the callback location and poll location does not necessarily have an
associated WSDL), the replyTo attribute makes the
scope of WS-R very limited. 2)
As corollary to (1) above, the binding/interface of the URI has to be known
before hand and cannot be changed. I.e., the SOAP node which is being polled or
called-back on has to be assumed to use SOAP HTTP binding. One of the big
reasons for using callback/poll is the underlying protocol itself is
asynchronous (HTTP is synchronous) -- other reason is that the operation takes
a long time. Effectively, WS-R cannot be used with non-HTTP/non-SOAP-binding.
For example, one cannot use SMTP/MOM-proprietary asynch
protocols. 3)
Another corollary to (1) is that one cannot send a message using protocol A and
poll/callback using protocol B. E.g., a node which is behind a firewall sends a
message using HTTP (so that it knows that the message has been received but not
necessarily delivered) and have the receiving node send an ack
using SMTP. 4)
An attribute of type URI is not enuf to represent all
kinds of protocol bindings (such as queuing systems). This means that newer
versions of WS-R spec (which hopefully will support various protocols) cannot
use an attribute of type URI -- for two reasons -- the type is restricted to
URI and it is an attribute (which means it can only be simple type). I.e., the
current schema for WS-R lacks extensibility for the addressing feature of
callback/poll. Not very friendly for future versioning. I
do realize that this issue is being brought up at the 11th hour, but did not
realize that there was an issue till now. Thanks. -Anish -- Tom: what if we make it a sub element with any syntax any. We could state that with the HTTP POST normative binding the sub element reply to would be a URI. Anish: the current syntax disallows some other bindings. A URI is not enough as an addressing mechanism, especially in a wsdl centric world. There are at least two addressing mechanisms allowing pointing to a web services. By having a structure, the next version of ws-reliability will have to change the structure to allow other addressing mechanism. Anish: Given it is a uri, it is transport agnostic, but it is not transport binding independent. IT is possible to have more than one binding for a given transport protocol... Jacques; is this for the longer term. What we send back to the reply to address is not intended to be bound to wsdl, it is intended to be received by the soap node sending the message. This is not critical for this release, however the reply to might be a third party address. Is this a serious limitation for this version? Anish: It is problematic for future versions. The next version would not be backward compatible with the current spec if the change is not made now. Until a new version is out I cannot use the spec with other bindings. There are two major use cases for asynch callback: 1) the infrastructure is one way, 2) the reply may not come for a long time. The first case is not covered by the spec, since the schema prevents other bindings. Jeff: if we make it an open content model, with this version restricted if using the HTTP post binding, we enable backwards compatibility. Jeff: make it an element, with an any attribute syntax. Leave it open, take to the list, incorporate discussion of the following point on http binding clarification as well.. 5.11Clarification of http binding· · Re: [wsrm]
Clarification needed on our http binding Tom Rutt wrote: > We need to clarifiy
that the mandatory binding in the spec is to use > htttp
post. > I think the spec needs to be clearer than that.
It should probably say SOAP HTTP binding defined by WSDL 1.1 section 3
(OR SOAP 1.1 section 6 binding, minus the HTTP
Extension framework) > 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. > > Tom Rutt > > Can an implementation claim conformance if it does not do HTTP post binding. Alan: I thought we agreed on this that it is so. Discussion should include both of these items together. Take this to the list. 5.12Tony Graham edits needing discussion:Defer discussion to next week. Ø Action: Iwasa and Tony should work to resolve Tony’s non resolved
comments
Mail from Tony Graham: >Some of Tony Graham's editorial comments are
in this category. >> Please look this over to see if any of
your items need further discussion. 1. Line 178: example.org
example.org (and example.net and example.com)
are reserved for examples and documentation.
See http://www.rfc-editor.org/rfc/rfc2606.txt for the explanation. Using
example.org makes it obvious that it is an example and avoids any conflict with a domain name that is in use or will one
day be in use. 2. Line 288, 304: Why must the time be
identifiable? I would
like this to be explained to me. 3. Line 329: Reliable Messaging Fault Indication
for failure to receive a message Another
thing that I would like explained to me. 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. 5. Line 388, 390, 392 My braino. It should be "Change 'details' to
'details.'." but I was thinking too much about periods so the wrong word came
out. Regards, Tony Graham 6 Discussion of Document Progression.Ø Jacques, took action, with Iwasa, to produce a new editor’s draft .997 by Friday. Indicate which public review coments are resolved. Agreed to postpone discussion of progression to next meeting. 7 Frequently Asked Questions / Presentation rebuttalKarl F. Best wrote: Tom: Bob F sent an email with a draft power point presentation. · · First cut at response presentation, please feel
free to comment and discuss Concern was expressed on the statement from carl: “ The
content of the slides should be strictly limited to correction of any errors in
the comparative analysis done by Chris “ The group decided we have leaway to say what we want. Several comments on the presentation were collected by Bob F. Jeff suggested we recast it as a critical comparison. We need to ensure that the criticisms from Chris are dealt with by this paper. Doug: perhaps we should quote from the slides. Jeff: we do not have to do that. We can talk about it at a higher level. Doug: I agree that talking about it at a higher level will make us look less like a detailed thing Bob: I asked Tom if comments made by an editor of a competing spec might not be considered as public review comments. Tom: we can discuss whether we want them to be public review comments next week. Say: revised spec has one schema. Jeff sugested a team to refine the slides. Bob can do revision before Who in team: Bob F, Alan, Jacques, Jeff, Pete, Jacques moved that the tc delegates to the subteam the job to deliver the talk to the Oasis staff., Alan seconded. No opposition. Motion passes. Tom will tell Karl that we will have it by Thursday or Friday. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]