OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[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 5133


Title: 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 Call

From Kavi:

 

Over xx of 46 voting members, meeting is quorate

 

Tom Rutt agreed to take minutes.

2         Agenda Approval

Agenda:

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 Review

http://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 revisited

Paul F posted http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200606/msg00008.html

  • June 1st Editors produce a new WD
  • * June 8th TC implements new policy on issue list - highly restrictive acceptance policy         To be clear, Robert's Rules is still in force, but the aim is that the TC focuses on removing bugs from the spec beyond this point.
  • June 22nd Target for all issues closed
  • June 29th Editors produce "release candidate" Working Draft
  • July 6th TC review period done
  • July 10th Editors produce final WD
  • July 13th Open ballot on CD and PR
  • July 20th Ballot closes
  • July 24th Public review begins
  • Sept 14th Interim WD with any PR comments folded in
  • Sept 5-15 Online Interop
  • Sept 22nd Public review ends
  • Sept 28th New WD for review with all PR comments folded in
  • Oct 5th Review ends
  • Oct 9th CS ballot starts
  • Oct 16th CS ballot ends

 

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 Canada day and US independence day.  Is that realistic for the release candidate review?

 

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 01

Title: 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's

Gil: 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:

  • Extensibility and versioning is essential for loose coupling.
  • Soap model has must understand, some say we should use this
  • BEA has problem with soap MU as only mechanism.  Composability concerns with both compatible and incompatible changes. This would require separate new soap header block extensions for each incompatible change.
  • This effectively moves xml from tree language to a graph language, requiring pointing into exact portions of message from a header block.  Using tree structure allows the extension semantics to be co-located with the extension itself in the document.

 

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]