Prelim Minutes OASIS TC Teleconf

Thursday February 23, 2006

4:00 to 5:30 EST

Textual Conventions

Ų Action Item

Motion

§ Resolution

1 Roll Call

From Kavi.

Meeting was quorate.

2 Review and approval of the agenda

1) Roll Call

2) Review and approval of the agenda

3) Approval of the Feb 09 and 16, 2006 meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16663/MinutesWSRX-020906.htm

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16877/minutes%20wsrx%2016%20feb.doc

4) Administrative Issues

Editors review, WD / CD status

Availability of the submission spec on the public page

5) AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

6) New issues since last conf-call

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00234.html

7) Issue Discussion:

a> i021 An RM Policy applies two-way

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i021

b> i008 Policy assertions granularity

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i008

c> i090 Use of offered sequences unclear in current spec

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i090

d> i089 suggest the restricted use of anonymous URI

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i089

e> i061 Anonymous AcksTo

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i061

to moving issue 61 to the top of the list.

8) Any other business

Marc G asked that issue 61 be moved up to the top of the list.

No objections

Chris F asked that the Namespace be posted .

3 Approval of the Feb 09 and 16, 2006 meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16663/MinutesWSRX-020906.htm

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/16877/minutes%20wsrx%2016%20feb.doc

Tom Rutt moved to accept both minutes Paul K seconded.

No objections, both minutes approved.

4 Administrative Issues

4.1 Editors review, WD / CD status

Gil stated that document are not posted by OASIS staff.

The RIDL document is getting closer to being posted properly.

Gil stated this would be fixed before the next meeting.

Paul F: The aim is to have a vote on the call next week. The editors should post a candidate CD.

Sanjay: perhaps a ballot could save time, if we opened a ballot today, to close before next weeks call.

Martin: how long has this doc been available.

Doug D: Monday or Tuesday of this week.

Paul C: they were not accessible to all on wed.

Anish: Did you mean a newer draft, I already sent it out as candidate CD.

Martin: I think it is ok to ballot.

Paul F: I suggest we have a 6 day ballot for approval of the Candididate drafts for CD 03. It will be issued to have it close before the next teleconference meeting.

Anish: what about editorial comments on the candidtate?

Paul C: I will continue my review, and identify anything that should go into CD, and especially if it impacts the interop. I think only deal-breakers be included.

Doug D: I t is easier to have the ballot be up/down.

Paul F: agree to have up/down ballot.

Anish: The editor’s points should be considered during review for the Kavi ballot. http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00163.html

4.2 Availability of the submission spec on the public page

Editors shall organize this.

Action: Doug will make the submissions available from public links.

4.3 Metadata from OASIS

Chris F stated that he is reviewing the ASIS document from OASIS. The one thing that is relevant to this TC, is that the specific URI space …./ws-rx violates ASIS because token for tc short name do not allow hyphens. Since we are already using the space with hyphen, someone in this group should petition to allow continued use of the namespace with a hyphen.

Jeff M moved, Marc G seconded that the committee ask Paul F to petition OASIS staff on the continued use of hypen in namespace.

§ No objections, motion passed unanamously.

Ų Action: Paul F will petition OASIS staff to allow our continued use of hyphens in namespaces and file names.

Note from WS-TX group http://www.oasis-open.org/apps/org/workgroup/oasis-member-discuss/email/archives/200602/msg00003.html

Rant from Chris F: http://www.oasis-open.org/apps/org/workgroup/oasis-member-discuss/email/archives/200602/msg00001.html

Paul F Members should vote on attendance to face to face.

5 AI Review

http://www.oasis-open.org/apps/org/workgroup/ws-rx/members/action_items.php

#0056: Ensure that the final WSA specifications include text for handling of anonymous IRI values for non-WSA EPRs

Owner: Robert Freund

Status: Open

Assigned: 2005-12-13

Due: ---

#0080: Gill will work with OASIS staff to get the CD 2 artifacts posted properly

Owner: Gilbert Pilz

Status: Close

Assigned: 2006-02-14

Due: ---

1 New issues since last conf-call

http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00234.html

1.1 Proposed-01

Title: wsrm:acksTo should not use wsa:AnonymousURK

Description:

The wsa:anonymousURI is defiined in WS addressing for use in a single MEP exchange.

What we really need in wsrm:acksTo is a uri which has the intended semantics:

"return the wsrm:acknolwedgment soap header in the underlying response to any soap request which contains a wsrm defined soap header with this sequenceID."

This is really quite specialized semantics, and should be defined with a wsrm: specific URI.

Proposal:

Define a wsrm specific URI which has the desired semantics for use in the wsrm:acksTo URI.

Tom gave an overview of this new issue.

Chris F: I have been talking to WS-addressing members will make this not be a problem. I would not like this to be raised as a new issue.

Umit: I agree with Chris that this should be resolved in WS-addressing First.

Tom: what is so important about using anonymous here.

Doug D: why is this not part of Issue 61.

Sanjay: I believe our spec depends on ws-addressing and we are trying to deal within WSA. We should try to work with wsa first.

Anish: I was influenced by Glen D who pointed out that if wsa resolves anonymous to mean any back channel, causes problems. We have semantics of matching sequenceIDs before using the back channel.

Gil: I remark that there is really an issue here, and we should accept the issue.

Paul F: I think we need to ignore the proposal, there is an open issue that wsa meaning of anonymous uri and the meaning of anonymous.we want will be aligned.

Doug D: I want to request the chairs that we raised the bar quite high last week.

Paul F: the Bar is decided by the TC and not the chairs. I think the bar should be low.

Bob F: speaking as ws addressing chair, we are working to get back to where we were when the clarification was originally requested. We are accepting proposals thru next Thursday morning. Hopefully we can accommodated the needs of this TC

Tom R: I am just suggesting we can decouple our TC from the WSA discussions by having our own URI with its own special semantics. This is not much different than specifying special semantics to the use of anonymous in Ack To..

Chris F objected to raise as new issue.

Put to a Vote:

7 Yes

10 no

Many abstain

Proposed 01 not accepted as New Issue.

2 Issue Discussion:

2.1 e> i061 Anonymous AcksTo

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i061

New proposal from Chris F: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00245.html

Doug D reviewed proposal:

Doug D moved to accept email proposal to close I061 , seconded by Chris F:

Gil wordsmithing is needed for one of the sentences.

Doug D: the editors can break up the sentence.

Marc G: have the editors propose a better solution and if there is no objection, we can accept the editor’s wording.

Sanjay: I am not comfortable with a motion pass without agreement on the text. I am willing to let the editors have leeway to fix the cumbersome sentence, by breaking it into several sentences.

Marc G: we should accept that the editors might not be able to break the sentence apart.

Paul F: we are voting to accept the text in the proposal as is.

Chris F moved to amend, Anish Seconded.

A wsrm:AcksTo EPR MAY specify the WS-Addressing anonymous URI as its address. When the wsrm:AcksTo EPR specifies the WS-Addressing anonymous URI as its address, the RMD MUST transmit any wsrm:SequenceAcknowledgement headers for the created Sequence in a SOAP envelope to be transmitted on the protocol binding-specific channel provided by the context of a received message containing a SOAP envelope that contains a wsrm:Sequence header block and/or a wsrm:AckRequested header block for that same Sequence identifier.

: A wsrm:AcksTo EPR MAY specify the WS-Addressing anonymous URI as its address. When the wsrm:AcksTo EPR specifies the WS-Addressing anonymous URI as its address, the RMD MUST transmit any wsrm:SequenceAcknowledgement headers for the created Sequence in a SOAP envelope to be transmitted on the protocol binding-specific channel. Such a channel is provided by the context of a received message containing a SOAP envelope that contains a wsrm:Sequence header block and/or a wsrm:AckRequested header block for that same Sequence identifier.

§ No objection of motion to amend.

§ Amended motion had no objections. Issue 61 closed with amended proposal.

2.2 a> i021 An RM Policy applies two-way

http://docs.oasis-open.org/ws-rx/issues/ReliableMessagingIssues.xml#i021

Sanjay posted latest proposal as: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00222.html

Title: i021 Proposal

Here is an updated proposal for resolving the long pending issue i021. The key difference in comparison to what exists in the WS-RM Policy specification today is that -- the proposal allows Message Policy Subject (in addition to the Endpoint Policy Subject) for the RM Policy assertion.

I would also like to bring to your notice that this proposal:

-- Avoids text that would repeat the semantics already addressed in WS-PolicyAttachment, for example, an Endpoint Policy Subject applies to behaviors associated with all the message exchanges of the endpoint, and applies to aspects of both communicating with as well as instantiating the endpoint. So the proposal would seem a bit short and dry to some people!

-- Does not include any recommendations for which wsdl elements (among those that are allowed by the proposal - wsdl:port Vs. wsdl:binding Vs.binding level messages) are more appropriate for policy attachment, since this may simply be a matter of best practices and there are no strong technical reasons for the specification to promote one approach over another, IMO.

-- Does not include any text related to whether and how EPR contained policies may interact with the WSDL attached policies, since I couldn't arrive at any precise and useful (normative) text in this regard.

Please try to send in your comments before the conf-call tomorrow (2/23)!

-- Sanjay

------------------------------------------------------------------------

Replace the entire content of section 2.3 (Assertion Attachment) in the WS-RM Policy specification with the following:

The RM policy assertion is allowed to have the following Policy Subjects [WS-PolicyAttachment]:

Endpoint Policy Subject

Message Policy Subject

WS-PolicyAttachment defines a set of WSDL/1.1 [WSDL 1.1] policy attachment points for each of the above Policy Subjects. Since an RM policy assertion specifies a concrete behavior, it MUST NOT be attached to the abstract WSDL policy attachment points.

The following is the list of WSDL/1.1 elements whose scope contains the Policy Subjects allowed for an RM policy assertion but which MUST NOT have RM policy assertions attached:

wsdl:message

wsdl:portType/wsdl:operation/wsdl:input

wsdl:portType/wsdl:operation/wsdl:output

wsdl:portType/wsdl:operation/wsdl:fault

wsdl:portType

The following is the list of WSDL/1.1 elements whose scope contains the Policy Subjects allowed for an RM policy assertion and which MAY have RM policy assertions attached:

wsdl:port

wsdl:binding

wsdl:binding/wsdl:operation/wsdl:input

wsdl:binding/wsdl:operation/wsdl:output

wsdl:binding/wsdl:operation/wsdl:fault

If the RM policy assertion appears in a policy expression attached to a wsdl:binding as well as to the individual wsdl:binding level message definitions(wsdl:binding/wsdl:operation/wsdl:input, wsdl:binding/wsdl:operation/wsdl:output, wsdl:binding/wsdl:operation/wsdl:fault), the parameters in the former MUST be used and the latter ignored.

If the RM policy assertion appears in a policy expression attached to a wsdl:port as well as to the other allowed WSDL/1.1 elements, the parameters in the former MUST be used and the latter ignored.

Sanjay gave an overview of his proposal above. The proposal does not talk about EPRs, and it makes no suggestions as to preferred levels of policy attachment.

Anish: I like this proposal, but posted a few comments. We no longer have parameters which can conflict, we just have a binary switch.

Sanjay: I included this for extensibility, but perhaps the extensions can provide their own overrides.

Chris F posted counterproposal as: http://lists.oasis-open.org/archives/ws-rx/200602/msg00225.html

Thinking about this proposal, I am concerned that what is not clear is what is the expected behavior

should the policy be expressed as Message Policy Subject (MPS) for selected input and/or output|fault messages

and then either side goes a step further and sends messages that have NOT been designated as reliable.

Specifically, I am concerned that there might be two flavors of RM implementation: one that only supports

EPS and one that supports MPS granularity. It would be a problem IMO if these two flavors of RM implementation

did not interoperate.

I am thinking that what may be needed is two assertions: one for the endpoint (EPS) that effectively proclaims

that "this endpoint supports WS-RM", period. A second assertion with MPS could then be used to decorate

the WSDL to indicate which messages SHOULD be sent reliably, but would NOT preclude that other messages

be sent reliably.

Alternately, there would likely need to be some statement made to the effect that if ONLY MPS is specified, then

there is an implicit claim that the assertion ALSO applies to EPS to indicate "RM supported". However, I am not clear as to whether

Policy effectively supports this notion of transitive policy subject UP the food-chain.

I think that unless we have such a notion of two-levels of policy subject as applied to RM

assertions, that there will be potential interoperability issues. For instance, what if a message that was

NOT designated as being reliable were sent reliably? If the RMD implementation were to reject this message, then the

Sequence is effectively broken because the MessageNumber has been used but will never be acknowledged.

I'm not suggesting that this is the behavior that one would expect, just that given what it states in the proposal

below, it isn't clear what responsibility the RMS and RMD have.

Thus, I am thinking that we really need two assertions, one with EPS and the other with MPS to get this

right, and to ensure interoperability.

The semantic of the one with EPS is "WS-RM Supported|Required" and MAY be attached to either

a wsdl:binding or wsdl:port and MUST NOT be attached to any other WSDL component.

The semantic of the one with MPS is "SHOULD be sent reliably". It MAY be attached to any of:

wsdl:binding/wsdl:operation/wsdl:input

wsdl:binding/wsdl:operation/wsdl:output

wsdl:binding/wsdl:operation/wsdl:fault

It MUST NOT be attached to any other WSDL component. When used in the context of an

endpoint that proclaims "WS-RM Required" (e.g. <wsrmp:RMAssertion wsp:Optional="false"/>) then

the designated message(s) MUST be sent as part of an RM Sequence, otherwise, the receiving

endpoint SHOULD generate a fault (TBD with semantics of "RM REQUIRED"). When used

in the context of an endpoint that proclaims "WS-RM Supported" (e.g. <wsrmp:RMAssertion wsp:Optional="true"/>)

then the sending endpoint MAY send the designated messages as part of an RM Sequence.

The receiving endpoint MUST NOT generate a "RM REQUIRED" fault. The receiving endpoint

SHOULD (MUST?) permit messages that have not been designated "SHOULD be sent reliably" to be

included in an RM Sequence.

Finally, there is the issue of the scope of the EPS assertion. Does it apply only to messages sent to

the service provider endpoint, or does it apply to messages sent in either direction?

One use case that needs to be covered is that for pub/sub, where the subscriber endpoint is the one

that would want to assert that the messages be delivered reliably (or not as the case may be),

but where the service provider (the publisher) could go either way (RM supported).

Doug had a proposal that provided for the wsa:ReplyTo EPR to carry in its metadata, a policy

assertion that indicated whether RM was supported/required, much as the service provider can

do by decorating its WSDL description.

The question then becomes, how does one express this if it is to deal with MPS as opposed to

simply EPS? WS-PolicyAttachments has defined a domain expression for EPR which we could

use, but that would only give us EPS.

We could invent some domain expression for WSDL and use that for an external policy attachment

using PolicyAttachment. I am not comfortable having the WS-RX TC do a domain expression for

WSDL though, and we'd have to do more than one flavor anyway (sigh).

Quite frankly, I am not at all confident that the proposal below really addresses all of the issues.

I personally think that we would be best off for NOW going with JUST EPS scope for the

assertion and having the RM assertion mean:

<wsrmp:RMAssertion wsp:Optional="true"/> == WS-RM supported. The sending endpoint MAY choose to use a Sequence to send any (or all) of the messages sent to the endpoint as described in the WSDL.

<wsrmp:RMAssertion wsp:Optional="false"/> == WS-RM required. The sending endpoint MUST use a

Sequence for all messages sent to that endpoint as described in the WSDL.

When the policy assertion is attached to a WSDL port/endpoint or binding, it applies to messages

sent from the service consumer to the service provider.

When attached to an EPR, it means any (or all) messages sent to the referenced endpoint be sent

using RM.

Cheers,

Christopher Ferris

Chris F: my concerns are that implementations might not support message subject level, and the interoperability problems this may cause. There is nothing about endpoints rejecting messages. This led me to propose two levels. At endpoint level you want to say rm support is here, and at message policy subject level you would have a switch which is “and”ed with the endpoint assertion.

Chris F: I think there are pub sub use cases that different users support different levels of reliability. Restricted proposal involves receiving endpoint asserting its use of Reliability.

Paul F suggested the discussion be taken to the list.

Chris will try to write a concrete proposal

Continue to discuss on email.

3 Any other business

Doug D: We need to have answers to the questions raised by Microsoft, as I posted in http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200602/msg00193.html

Action: Marc G will give answers to questions raised about anon reply to

ws-rx message