[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Prellim minutes of 6/1 teleconf
Prelim minutes of 6/1 teleconf are attached. Please provide corrections to the list before monday morning. Tom Rutt -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com; trutt@us.fujitsu.com Tel: +1 732 801 5744 Fax: +1 732 774 5133Title: Minutes of OASIS WS-RX Teleconference
Prelim
Minutes of OASIS WS-RX Teleconference Junk
1, 2006 Start Time:4:00 PM Eastern
Daylight Time Paul F acted as chair. Textual Conventions Ø Action Item Motion § Resolution 1 Roll CallFrom Kavi: Over xx of 46 voting members, meeting is quorate Tom Rutt agreed to take minutes. 2 Agenda ApprovalAgenda: 1) Roll Call 2) Review and approval of the
agenda 3) Approval of the May 25, 2006
meeting minutes http://www.oasis-open.org/committees/download.php/18295/MinutesWSRX-051806.html 4) AI Review http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php 5) TC schedule revisited 6) New issues since last conf-call Watch for Marcs email 7) Update from the editor's 8) Issue Discussion: i089 Doug Davis suggest the restricted use of anonymous
URI http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089 i119 Doug
Davis When to piggy-back RM headers http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i119 i115 Gilbert Pilz "must understand" attribute for
extensions to RM components http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i115 i125 Paul Fremantle Protocol precondition requires knowledge of
policies http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i125 No objection to agenda as proposed. 3 Approval of the 5/18 minutes;http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/18444/MinutesWSRX-052506.html Tom R moved, Chris F seconded to approve 5/25 minutes. § No objection minutes for 5/25 meeting approved. 4 AI Reviewhttp://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php #0100: Tom Rutt & Bob
volunteered to work on state table revisions with Jacques Owner: Jacques Durand Status: Still Open Assigned: 2006-05-09 Due: --- -------------------------------------------------------------------------------- #0102: Marc G will prepare to start an issues list for
Public review comments Owner: Marc Goodner Status: Still Open Assigned: 2006-05-22 Due: --- -------------------------------------------------------------------------------- #0103: Paul F will address Marc G concerns and interop concerns in a next version of schedule, including
the member ballot Owner: Paul Fremantle Status: Closed Assigned: 2006-05-22 Due: --- -------------------------------------------------------------------------------- #0104: Gill will clarify his proposal for i121 to clarify
the relationship between requirements and the threats Owner: Gilbert Pilz Status: Still Open Assigned: 2006-05-30 Due: --- 5 TC schedule revisitedPaul F posted http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00008.html
Paul C: the schedule does not say anything about what to do with newest editor’s draft. There is no time frame for this initial review. Paul F: implicit that members should review draft and raise issues by June 8. Paul C: june
29 to July 6 contains Paul F asked the editors about June 29 to July 10 is realistic. Doug D: It is probably ok as . Paul F: we will leave schedule as is. Martin C: we need to preserve time for a second public review, in October timeframe. Paul F: I am assuming that we would not have substantive changes. I could do a second version which has a second public review period. Paul C: There might be only minor changes after the first public review. Only substantive changes require a second public review. Tom R: the TC decides if the changes are substantial. If there are no changes which would break an existing implementation, then the TC may decide they are not substantial. 6
New issues since last conf-call
http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00005.html 6.1 Proposed 01Title: unclear text regarding wsa:Action Description: Line 120 currently reads: If an action IRI is used, and one
is not already defined per the rules of the WS-Addressing specification [WS-Addressing], then the action
IRI MUST consist of the WS-RM namespace URI concatenated with a '/', followed by
the message element name. For example:
http://docs.oasis-open.org/ws-rx/wsrm/200602/SequenceAcknowledgement This text is, IMO, ambiguous, if
not confusing, at best. The intent was to define the pattern of defining a wsa:Action IRI value when the intent of a message is
exclusive to RM, such as in the case of RM lifecycle messages (CreateSequence, TerminateSequence,
etc.) or in the case where either an RM
fault or SequenceAcknowledgement are sent standalone. Even Gil's proposed revisions (for
i093) don't resolve the ambiguity: If an action IRI is used by a
system that uses the elements defined within this specification, and one is not already
defined per the rules of the WS-Addressing specification [WS-Addressing], then
said system MUST use an the action IRI that
MUST consists of the WS-RM namespace URI concatenated with a '/', followed
by the message element name. For example: http://docs.oasis-open.org/ws-rx/wsrm/200604/SequenceAcknowledgement What is needed is simply a clear
prescription for the designation of the wsa:Action IRIs that are
specific to the
specification. Target: core spec Type: editorial Proposal: replace
text at line 120-123 with the following: When the RM protocol, defined in
this specification, is composed with the WS-Addressing specification [WS-Addressing], the following
rules prescribe the constraints on the value of the wsa:Action header: 1. When an endpoint generates a
message that carries an RM protocol element, that is
defined in section 3 below, in the body of a SOAP envelope that
endpoint MUST include in that envelope a wsa:Action
SOAP header block whose value is an IRI that is a concatenation of the WS-RM
namespace URI, followed by a '/', followed by the value of the
local name of the child element of the SOAP body . For
example, for a Sequence creation request message as
described in section 3.1 below, the value of the wsa:Action
IRI would be:
http://docs.oasis-open.org/ws-rx/wsrm/200602/CreateSequence 2. When an endpoint generates a SequenceAcknowledgement message that has no element content
in the SOAP body, then the value
of the wsa:Action IRI MUST be: http://docs.oasis-open.org/ws-rx/wsrm/200602/SequenceAcknowledgement 3. When an endpoint generates an AckRequested message that has no element content in the
SOAP body, then the value of the wsa:Action IRI MUST be:
http://docs.oasis-open.org/ws-rx/wsrm/200602/AckRequested 4. When an endpoint generates an RM
fault as defined in section 4 below, the value of the wsa:Action IRI MUST be as defined in
section 4 below. Cheers, Christopher Ferris Marc G: this text has been around for a long time, and no concerns have been raised. Chris F: because the words do not mean anything. It is not as precise as a spec should be. This does not change the spec other than textually. Gil: I move we accept as new issue and arguer later, seconded by Doug D. § No objection proposed 01 accepted as a new issue.. 7 Update from the editor'sGil: wg Drafts of both specs were posted recenty http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/18455/wsrmp-1.1-spec-wd-09-diff.pdf http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/18452/wsrm-1.1-spec-wd-13-diff.pdf Gil: may need to check the new text: [Detail] The
detail element(s). If absent, no detail element is defined for the fault. If more than one
detail element is defined for a fault, implementations MUST
include the elements in the order that they are specified. There was discussion on the above text. There are no schema statements associated with this text. No concerns were expressed about the text cited by Gil. Paul F: please raise any issue on these wgs before the next week’s call. 8
Issue Discussion:
8.1
i089 Doug Davis suggest the restricted use of anonymous
URI
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089 Doug posted a consolidated proposal as: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200605/msg00310.html Doug: This is a consolidation of the earlier IBM, BEA, and WSO/2 proposals. In this proposal, one can pass in rm sequence id or an address URI for the correlation ID. This is the major difference with this proposal. There is a proposal for construction of the correlation URI. Paul F: I am happy with the fact that sequenceID can be used as the correlation id. Paul F: we should take discussion of this new proposal to the mailing list. Anish: since this is the major issue on our list, is there a timeframe limit for closing this. Paul F: as a member I would hope we can resolve this by next week. 8.2
i119 Doug Davis When to piggy-back RM headers
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i119 Doug D posted a response to Jonathan’s proposal at: http://lists.oasis-open.org/archives/ws-rx/200605/msg00308.html His suggested changes are to change “SHOULD” to MUST” "Some RM header blocks may be
added to messages that happen to be targeted
to the same endpoint to which those headers are to be sent (a concept
often referred to as "piggy-backing"), thus saving the overhead
of an additional message exchange. Reference parameters MUST be considered when determining
whether two EPRs are targeted to the
same endpoint." And remove:
This concept is often referred to as "piggy-backing"
Sequence acknowledgements. from
section 3.6. This moves the definition of
'piggy-backing' to a general spot thus removing the need to repeat it. And I think the "MUST" is important to ensure interop. Jonathan: I used SHOULD due to testability. In general I can accept Doug D changes. Doug D: I think you can test for this in many cases. Anish: MUST be considered allows considerable leeway in the comparison semantics. Doug D moved to accept modified proposal, seconded by Jonathan. § No objection Issue 119 closed with modified proposal from Doug D. 8.3
i115 Gilbert Pilz "must understand" attribute for
extensions to RM components
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i115 Dave O: To summarize:
Chris F: I move we close i115 with no action, seconded by Marc G. Anish: how does a soap must understand way work in cases where a wsrm:ack has an extension in it. This requires failing at soap level rather than at wsrm application level. Doug B: I do not understand the use case for “must understand if” . Anish: you can piggyback things on main message, the receiver that process may fail or ignore the piggyback stuff as long as main body is processed. Doug B: I think the soap header must understand covers the useful cases. Chris F: a wsrm specific must understand is not necessary. I strongly support my motion to close with no change. Dave O: I thought the security profile extension might need this feature. I thought we had agreed to wait until after we discuss that security extension. Paul F: there were email discussion suggesting we could discuss it today. Dave O: I move to table this motion until after security discussion, Gil Seconded. Vote: 14 Yes 16 No § Motion to table defeated. Dave O: It is unfortunate that we cannot wait until after discussion of security extension. The piggyback case makes a good case for need of wsrm must understand for components of a piggybacked wsrm header. Thiis feature allows rm layer to fail on the rm extension, rather than the soap layer. The soap processing model for this piggybacked response is not where they would want it to fail. It does not allow the separation of concerns, and would throw away more application responses than warranted. Paul F: I do not understand you scenario. If the rm layer does not understand extension, and throws a fault, how is that different than soap extension throwing fault. Dave O: that is the core of the issue. In a pipeline implementation the rm extension in a piggybacked header. The rm layer does not understand the extension, and will send back, however it can accept the rm application response included in the message. The piggybacking can break the application level response. Discussion ensued on the differences of each layer sending a fault. Dave O: what if response message is different usage than the piggybacked wsrm header with an extension. Unless all piggybacking extensions must be understood even to accept the rest of the application response. From chat: anish I want to point out that soap:MU fault requires that the receiver *not* process the soap:Body. whereas in the
piggyback case, we do want the soap:Body to be
processed Jacques: I would like more time to discuss this issue. I have concerns about the Gil proposal, since it goes beyond our wsrm scope. I would be more comfortable with an actual use case to support Gil’s proposal. Chris F: I move to call question, Paul Knight seconded. Dave O objects to call question. Vote on call question passes. 20 Yes 9 No 2 abstain Vote on Motion to close I115 with no action. 19 Yes 7 No 4 abstain § Motion to close I115 with no action passes. 8.4
i125 Paul Fremantle Protocol precondition requires knowledge of
policies
http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i125
no time to discuss _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]