[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prelim minutes of New Orleans F2F
The prelim minutes of f2f minutes are attached. Please provide corrections by the end of next week. Tom Rutt WSRM TC Chair -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133
|
1 Agenda Review and RefinementDraft Agenda: 1 Agenda Review and Refinement 2 Roll Call 3 Minutes Discussion 3.1 Appointment of Minute Taker 3.2 Approval of previous meeting minutes 4 Action Item Status Review 4.1 Action 121404-2 (Anish) Open 4.2 Action 012505-1 (Tom Rutt) Pending 4.3 Action 020805-2 (Tom Rutt) open 5 Status of WS-Reliability Specification 6 PAS Progression Discussion 7 Charter discussion 8 Next Step Documentation 8.1 Finalization of Errata 8.2 Future Enhancement Requests 8.3 Implementation Guidelines 9 Scheduled Vote to post Errata as CD 10 Composability with other WS-Specs 10.1 Composability Analysis 10.2 WS-Reliability and WS-Security Composition 10.3 Discussion of Liaison with WS-RX TC 11 Future Meeting Discussion 2 Roll Call
Meeting is Quorate. 3 Minutes Discussion3.1 Appointment of Minute TakerTom Rutt agreed to take the minutes 3.2 Approval of previous meeting minutes
http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/12300/Minutes%20WSRMTC040505.htm Bob F moved to accept minutes. Anish Seconded. No opposition , minutes approved. 4 Action Item Status Review4.1 Action 121404-2 (Anish) OpenAction: Oracle will provide examples of soap header dumps with both ws-reliability and ws-Security headers in use, as in the interop demo. Anish posted email: WSS and WS-Reliability header dumps Anish Karmarkar 24 Feb 2005 23:22:27 Anish may post some additional examples of other combinations. Leave open 4.2 Action 012505-1 (Tom Rutt) PendingAction: Tom will investigate how to change the status of printed document. The posted standard still states CD. Continuing action, need standard number from OASIS staff 4.3 Action 020805-2 (Tom Rutt) openAction: Tom will investigate how to post the three OASIS pas documents on our server. Jamie Clark is investigating how to get the documents on the OASIS Site. 5 Status of WS-Reliability SpecificationChair’s Goal: finalize Cover Page and footers for official posting of standard. Above URL for proposed document for posting. Jamie will give final cover page by end of f2f Meeting. 6 PAS Progression DiscussionChair’s Goal: determine whether TC wants to continue to push OASIS staff to progress WS-Reliability 1.1 as ISO/IEC JTC1 standard through OASIS PAS process. Jamie Clark has confirmed that we can post the PAS documents associated with OASIS. PAS status is a class that JTC1 grants in 6 month increments. OASIS will continue to have PAS status until at least the end of 2005. After that OASIS will revisit the issue as to whether we will keep the status. Jamie stated that the OASIS Liaison policy states that OASIS can decide to send specs to outside bodies. There are several ways, to send OASIS docs to orgs: - OASIS keeps control of evolution, - OASIS will transfer Control of evolution The WSRM TC has asked that OASIS staff consider submitting ws-reliability as the first type of PAS doc (OASIS keeps maintenance responsibility). Two EBxml standards have been progressed as ISO standard (15000 parts 1 thru 5) Jamie asks that we read the Liaison rules. http://www.oasis-open.org/committees/liaison_policy.php Tom asked whether we should continue to pursue the PAS progression of WS-Reliability. Anish stated there is no need to change our course as of this time. Tom: If we do nothing, OASIS will continue to pursue progression thru PAS process as full ISO standard. Consensus of meeting is to let OASIS staff continue work to progress WS-Reliability 1.1 as an ISO standard, with OASIS controlling the maintenance. 7 Charter discussionChair’s goal: discuss the future activities of the WS-RM TC, and possible charter Amendments to enable these activities. Jacques: we might consider charter changes to allow the TC to provide requirements and other contributions, from our perspective, for other related Web Service standards groups. Defer until after discussion of the Future enhancements list. Agreed that the TC should wait for further discussion of the proposed enhancement list, before reconsidering the charter for this TC. We also have to consider that a charter change may impact the IPR transition status of the TC. We also need to consider when we make a transition (if ever) of the group to the new IPR rules. Jeff: after more than 50% of the members have signed the new membership agreement with OASIS, any one of them could propose that the TC transition to the new IPR status. Tom: I will send a mail out to the list that observers can no longer post to the list. 8 . Next Step Documentation8.1 Finalization of Erratahttp://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/11868/ws-Reliability-Errata-ED0.1.htm Chair’s goal: finalize errata, in preparation for Vote to post as CD in afternoon session. Section1 was agreed to be included in the errata. Section 2.1.1: Jacques: clarification is that the tables should be read line by line. Jacques and Pete agreed to recast the tables in a more clear format and distribute as a new errata for vote. Section 2.1.2: Agreed to change offending sentence to: Errata Change offending sentence
to: “ In case GuaranteedDelivery
is not required, remove the group immediately. Otherwise, remove it if every message
has either been acknowledged or faulted “ Section 2.1.3: Agreed to change offending sentence to: “ Remove the group after every message has either been acknowledged
or faulted.” 8.2 Future Enhancement RequestsChair’s Goal: review the futures list above, to prioritize potential enhancements required by industry. The meeting went through the document, and produced a shorter list of future enhancement request, posted as: http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/12436/wsReliabityFutureFeatures.htm Comments on this new Future enhancements document are requested. 8.3 Implementation GuidelinesChair’s Goal: determine progression plan for above document Agreed that 1.1 and 1.4 are not of concern, and should be removed from the next version of this implementers guide. Agreed to discuss 1.2 and 1.3 at the meeting. 1.2 Error
Handling Edge Cases The implementation Guidelines could
give advice on elements to include in error responses for some of the corner
cases described in the following list. Error Status codes are described on
page 39. There are some implementation concerns
related to RM faults: • According to the first row, the fault code “InvalidRequest” MAY be generated if MessageId is missing. This seems to be not possible if the RMP fault message needs to have a reference to the groupId, when it does not exist in the request message. Suggest using "" as anyURI value for this case in Fault message • If the RMP replyPattern is missing, what is to be done with the RM fault (how to send it and to where?) It is permissible for the Receiving RMP to not return the fault (.e.g, log it). It may also be permissible in some cases (eg, if the wsdl operation is not ONEWAY) to return the wsrm:response header on the underlying HTTP response. • If the replyPattern is callback and replyTo is missing, where is the fault sent? It is permissible for the Receiving RMP to not return the fault (.e.g, log it). It may also be permissible in some cases (eg, if the wsdl operation is not ONEWAY) to return the wsrm:response header on the underlying HTTP response. • The case of “InvalidMessageId” fault code due to a missing groupId needs special handling, if the RM fault message needs a reference to the groupId. It is permissable to respond with "" for the groupID anyURI value in such a case. • When many error combinations occur (for example both attributes “number” and “groupExpiryTime” are invalid), what should be used for the RM fault code (InvalidMessageId or InvalidMessageParameters)? There should be implementation freedom in this case. The standard does not need to set up a precedence
order for reporting faults. 1.3 Message
Combination Concerns. The WS-Reliability 1.1
specification does not mention the possibilities of combining RMP signals with
business request/business response messages. By default, silence is always
interpreted as not prohibited. So, since the specification does not mention
message combinations, this means that one can mix RMP signals with business
messages. This however introduces implementation concerns because the
WS-Reliability headers were not designed to handle some circumstances. To explore the possibilities,
consider two mathematical sets: set A, and set B. Set A contains three
elements, while set B contains four elements: A = {B1, B2, B3} (3.1) B = {R1, R2, R3, R4} (3.2) The product set A x B = {(a, b) : a in A and b in B} would contain 3 × 4 = 12 elements.
The interpretation of the symbols used in these sets is as follows: • B1:
this means a message has request business payload data • B2:
this means a message has response business payload data • B3:
this means a message has no payload data (i.e., no payload data in its SOAP
Body, and no attachments either) • R1:
this means a message contains RM Ack headers • R2:
this means a message contains RM Fault headers • R3:
this means a message contains an RM PollRequest
header • R4:
this means a message contains an RM Request header Therefore there seems to be 12
possible message combinations. The last combination which is (B3,
R4) is not possible because there would not be a message having an RM Request
header without any payload. Removing this case, there are 11 combinations. Some
of these combinations have concerns. The following combinations have concerns: (B1, R1), (B1, R2), (B1, R3). When receiving these three messages, the receiver RMP has no way of determining whether the message has a request business payload or not. One answer for (B1, R1), and B1, R2) is the sending RMP has
to look into the body, in some cases, to determine if there is a payoad in the rm-response, to
deliver back to the sender using the "notify" primitive. One answer for (B1, R3) is that this combination is outside the scope of the specification. The response in such a case is not specified by the standard. 1 Scheduled Vote to post Errata as CDChair’s Goal: vote errata (as edited in morning session) to CD status, and post on OASIS web site as referenced from posted ws-reliability standard. http://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/12432/ws-Reliability-Errata-WD1.0.htm Pete moved to progress the above errata as CD1.0, and to post on the OASIS site as referenced from the posted WS-Reliability Standard. Seconded by Bob F. No opposition, motion passes. 8 voting members present at time of vote (>50% voting members). 2 Composability with other WS-Specs2.1 Composability AnalysisChair’s goal: release an edited version of the above document for widespread review inviting comments from other OASIS TCs and W3C WGs. Jacques provided an overview of the analysis document. There were several comments raised on the draft. Jacques will provide a new document for review at the next TC teleconference. Jacques pointed out that this paper my lead to better characterization of how to compose ws-reliability with other specs. Tom: I would like to have this paper be put out for a wider review by other web service standards people. Bob: I have some concerns that this work could be pushing outside our charter. Relatively little of the general case is chartered here. Jeff: there are not groups working on this level of composition analysis. However, we need to discuss how to compose with ws-security, and in the future ws-addressing etc. Doug: I cannot see how releasing this document would affect any of the deliverables of this TC. Jacques: It would just clarify the meaning of composability, so we would know more precisely what we mean by it. It might only affect the definitions we would use in any of our work on composability. I have not seen any satisfying definition of composability in the industry. Jacques: I can do another iteration to take into affect the comments we took. Bob: would not your membership in the OASIS TAB be a venue for further discussion. Tom: I wanted to have this be a TC document with some status before sending it out for review. Jeff: nothing stops you from sending it as a company paper. Bob: I believe that the right thing to do is put it in the contributions folder, and those authors should start distributing emails pointing to it. Bob: I move to encourage the authors of this paper make it available to a wider audience, at a time and a manner at their choosing. Jeff Seconded. No opposition, motion passed. 2.2 WS-Reliability and WS-Security Compositionhttp://www.oasis-open.org/apps/org/workgroup/wsrm/download.php/10944/WS-R%20WS-Security-Draft.pdf Chair’s goal: Given no comments have been posted, discuss progression plans for the above document. There is an open call for new use cases to include in this spec. Agreed to wait for further contributions on this topic (e.g, Anish action item response). 2.3 Liaison with WS-RX TCBob: our TC requirements could serve as a basis for an analysis of how the following two xmlsoap.org ws-reliable messaging specs (2/5) relates to these requirements. Web Services Reliable Messaging Protocol (WS-ReliableMessaging). February 2005. Web Services Reliable Messaging Policy Assertion (WS-RM Policy). February 2005 Tom: TC members should provide contributions a gap analysis between our TC requirements and the above reference specs. Contributions are solicited from TC members for discussion at the May 17 Teleconf on how the specs reference above meet (or do not meet) our requirements. Contributions should focus on uses cases that one can or can not accomplish with each specification. Tom: I will be put this gap analysis on the agenda for the May 17 teleconference meeting. 3 Future Meeting DiscussionAgreed to the following: Resume bi-weekly Tuesday 5:30 PM 60 Minute meetings starting May 17. Leave Next F2F timing and location TBD. Put on agenda for May 17 telecom. At 5:00 PM, Central Time, the meeting adjourned. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]