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: Prelim minutes of 1/14 teleconf


Prelim minutes of 1/14 teleconf attached.
Please provide corrections 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 1/11/2007

Prelim Minutes of OASIS WS-RX Teleconference

Jan 11, 2007

 

Start Time:4:00 PM Eastern Daylight Time

 

Paul F acted as chair.

 

Textual Conventions

 

Ø  Action Item

Motion

§    Resolution

 

1         Roll Call

From Kavi:

 

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 Jan 4th, 2006 meeting minutes

 

4) AI Review

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

 

5) New Issues

 

6) WS-Policy feedback

 

7) Issue progress review

 

8) Discussion of PR Issues

 

PR021 Piggy-backing problematic

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

 

PR022 RMD cannot detect some incomplete Sequences

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i022

 

PR007 RM Destination lacks a mechanism for cleanly terminating inbound sequences

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i007

 

PR035 Delivery Assurance

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035

 

PR009 "Duplicate Elimination" and "Message Ordering"

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009

 

PR020 Message ordering and duplication

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020

 

PR027 Where do Sequence Faults go when the RMS is anonymous

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i027

 

9) Any other business

 

 

1         Approval of the 1/4 Minutes;

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

Tom moved to approve 1/4 minutes, Chris F seconded.

 

§    No objections, minutes of 1/4 approved.

 

2         AI Review

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

 

#0117: Marc G will sort out with Chairs and editors on apportioning existing issue against the core spec and the new Make Connection spec

Owner: Marc Goodner

Status: Open – Marc will add new make connection spec to list of target specs, and reassign issues accordingly.

Assigned: 2007-01-03

Due: ---

 

 

#0119: Ashok to prepare draft feedback to policy working group, on need to be careful to avoid dependency related problems

Owner: Ashok Malhotra

Status: Closed

Assigned: 2007-01-11

Due: ---

 

 

#0120: Ashok to raise new issue about nesting policy assertions for RM

Owner: Ashok Malhotra

Status: Closed

Assigned: 2007-01-11

Due: ---

 

 

#0121: Gill will provide concrete language around item 2 in his proposal for issue 21.

Owner: Gilbert Pilz

Status: Closed

Assigned: 2007-01-11

Due: ---

 

 

#0122: Gill will provide concrete language around item 2 in his proposal for issue 21.

Owner: Gilbert Pilz

Status: Closed

Assigned: 2007-01-11

Due: ---

 

 

#0123: Gil to provide a concrete proposal to resolve issue 007 to include a finalAck in the closeSequence and TerminateSequence message

Owner: Gilbert Pilz

Status: Closed

Assigned: 2007-01-11

Due: ---

 

3         New Issues

Ashok Raised New Issue

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

In my original note (below) I pointed out that RM Policy had three assertions:

1. <wsrmp:RMAssertion [wsp:Optional="true"]? ... >

2. <wsrmp:SequenceSTR [wsp:Optional="true"]? ... />

3. <wsrmp:SequenceTransportSecurity [wsp:Optional="true"]? ... />

 

Assertion 2 depends on assertion 1 and is invalid unless 1 is present.

Assertion 3 depends on 1 and the presence of a sp:TransportBinding assertion.  Both must be present for assertion 3 to be valid.

 

These dependencies lead to a problem with WS-Policy normalization if, say, you have a policy containing only assertions 1 and 2 and both are marked 'optional'.  Such a policy would normalize to 4 policy alternatives { (1,2), (1), (2), () }  One of the policy alternatives would contain assertion 2 and not assertion 1 which is invalid.

 

PROPOSAL:

Make assertions 2 and 3 possible nested elements of assertion 1.

For example:

 

<wsrmp:RMAssertion [wsp:Optional="true"]? ... >

    <wsp:Policy>

         <wsrmp:SequenceSTR [wsp:Optional="true"]? ... />           

    </wsp:Policy>

</wsrmp:RMAssertion>

 

(Only either 2 or 3 must appear in the nested policy?)

 

This does not solve the problem of assertion 3 depending on sp:TransportBinding but, at least, solves part of the problem.

 

All the best, Ashok

 

Accepted New Issue with Ashok as owner.

4         WS-Policy feedback

 

Ashok emai: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00025.html

On the 1/4 telcon I was given an action item to suggested clarifying wording to the WS-Policy WG.

This clarification is motivated by the dependencies between the RM assertions as discussed in my earlier notes.

To recap, there are three RM assertions:

<wsrmp:RMAssertion [wsp:Optional="true"]? ... >

<wsrmp:SequenceSTR [wsp:Optional="true"]? ... />

<wsrmp:SequenceTransportSecurity [wsp:Optional="true"]? ... />

 

Assertion 2 depends on assertion 1 and is invalid unless 1 is present.

Assertion 3 depends on 1 and the presence of a sp:TransportBinding assertion.  Both must be present for assertion 3 to be valid.

 

1. The WS-Policy Framework document says in section 3.1:

"[Definition: A policy assertion represents an individual requirement, capability, or other property of a behavior.]

The word "individual" is not accurate.  If  assertion 2 and assertion 1 are used the capability is defined by their combination. 

In the security domain, several assertions may be needed to define a capability.

Thus, change the above sentence to something like "[Definition: A policy assertion represents an requirement, capability, or other property of a behavior that is defined, possibly, in combination with other assertions in with assertion-specific semantics.]

 

2. The Guidelines for Policy Assertions document discusses dependencies between assertions in section 6.

It would be useful in this section to warn the assertion authors that dependencies between assertions can create difficulties when policies are normalized.  It may also be desirable to add an example of a policy that contains two assertions whose validity depends on one another.  If both assertions are marked 'optional', then the two of the four policy alternatives which are generated will contain only one of the two assertions and may be invalid.

 

 

All the best, Ashok

 

Chris F: we need a specific proposal to close the issue, with exact wording.  This proposal is an outline of the solution.

 

Paul F: from RX point of view we can move to make this feedback, and if we get more detailed feedback that is a bonus.

 

Chris F: It is not clear that anything is broken.

 

Paul F: the policy WG asked for feedback and this is our feedback

 

Marc G: I do not agree with this feedback.  There is an issue with the RM policy assertion, not with WS-Policy.  We can fix it ourselves, with no changes required to policy itself.  Regarding Guidelines feedback, we might do that, but only after closing the new issue.

 

Chris F: the proposal for solution is on target, but we need to review in detail the entire solution.  Then we have to take a closer look, do we really have multiple assertions that define a capability, or are there dependencies between capabilities.  I agree that feedback to guidelines can come after we solve our problems.

 

Anish: Issue with STR sequence assertion.  Another problem is SequenceTransport Security, which has dependencies on transport security.  The first issue does not require feedback, but the second issue should be sent to Policy WG.

 

Paul F: Deadline for feedback is tomorrow.  We have the issue work, and we have the feedback.  Lets focus on what feedback we give Policy wg.

 

Marc G: I would suggest feedback be sent by individuals if they feel it necessary.  Cross dependency in our sequenceTransport Security could also be a problem in our spec.  The wording could be improved, it does not have to be worded as a dependency.  Details are in the transport assertions.

 

Chris F: the feedback we can give is on guidelines and primer docs.   We will have contributions soon on this.  However, have we identified any problems with their policy framework.

 

Paul F; I cannot see consensus for a WG response out of this meeting.  Ashok can submit on his own behalf, but we will wait for resolving the new issue before sending feedback to ws- policy group.

 

No disagreement.

 

Action: Chris F will present a proposal on policy assertions for WSRM Delivery assurances.

5         Issue progress review

Marc updated the issues list.

 

Paul F: more work is needed on Issue List.  We need concrete proposals for issues open.  We have concrete proposals for all except the policy assertions on DAs. We have two proposals.

 

Chris F: I am almost done with a proposal which I will send soon.

 

Action: Chris F will present a proposal on policy assertions for WSRM Delivery assurances.

 

6         Discussion of PR Issues

 

6.1      PR021 Piggy-backing problematic

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

Gill: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/pdf00005.pdf

 

Text regarding changes to 3.2 (regardings use of MAYs) from email are not yet included in the propoal I posted.  We could add these.

 

Chris F: My problems were in 3.8 and 3.9. regarding change of MAYs to CANs

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

 

Doug D moved to accept Gil;s proposal with modifications for 3.8 and 3.8 suggested by Chris F (and with editors to also fix wording of 3.2, seconded by Gil.

 

No Objections: Issue 21 Closed with agreed resolution.

 

6.2      PR022 RMD cannot detect some incomplete Sequences

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i022

 

Gil proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/pdf00009.pdf

 

Gil: change wording that unless there is a good reason you add last message number to terminate or close sequence messages.

 

Gil: there is an outstanding issue from Jacques, where discard is required, Should should be MUST.  I disagree with this amendment.  The Definition of SHOULD includes what Jacques is concerned about.

 

Tom: this proposal resolves my concerns.

 

Matt: the diagram might need minor editing to agree with text.

 

Gill: I agree.

 

Marc: there were a couple of other editoral nits, to leave to editors.  I will send notes.

 

Doug D: I sent a note to list.  Message 42 on list

 

Gill: I agree with these proposed edits.

 

Matt moved to accept proposal from Gil to resolve PR022 , seconded by Doug D.

 

No Objection, PR022 Closed with proposed change from Gil.

 

 

6.3      PR007 RM Destination lacks a mechanism for cleanly terminating inbound sequences

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i007

 

Gill proposal for 7: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/pdf00011.pdf

 

Gil: there has been discussion on the Email list.  We have come to agreement on state tables, which is reflected in this draft.  There is a minor edit needed to fix the state table.

 

Marc G: this seems good from my point of view.  Agree that we Need additional column for state table for RMS.  

 

MrGoodner: responding party/receiving party throughout should be sender/receiver instead

 

Discussion of the details of state table changes ensued.

 

Matt: Introduced a terminating state to RMD.  It does put requirement to RMD to support this new state.

 

Doug D:that’s  fine

 

Gil moved to accept proposal for PR007 with Matt’s state table changes and Marc G wording changes, seconded by Marc G.

No objections, PR006 closed by accepting proposal for changes.

 

 

6.4      PR035 Delivery Assurance

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i035

 

We can discuss Definitions from Jacques:

 

Jacques original Note:: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00026.html

 

Rationale for a rewording of DA definitions that were used a year ago:

 

AtLeastOnce

 

Previous:

 

- Every message sent will be delivered or an error will be raised on at least one endpoint. Some messages may be delivered more than once.

 

 Proposed:

 

for every sent message, either the RMD has received the message and successfully delivered it, or at least one of the AS or the AD is made aware of a delivery failure. Note: There is no guarantee that if delivered, the message is delivered just once. Also it may happen that both delivery and failure notification occur for a message.

 

[comment: pretty much same. Just relate it better to the messaging model: re-emphasizes that " deliver"  must be understood with the precise meaning given in glossary,  i.e. as delivery to AD, not in its general sense. Same for errors raised. Also mention that cases where message is delivered yet an error is raised, are not ruled out - cannot be always prevented.]

 

AtMostOnce

 

Previous:

 

Messages will be delivered at most once without duplication or an error will be raised on at least one endpoint. It is possible that some messages in a sequence may not be delivered.

 

Proposed:

 

A message shall not be delivered more than once by the RMD. Message duplicates are identified based on Sequence ID and Sequence number. Note: there is no guarantee that the message is delivered or that an error is raised if not.

 

[comment: the previous definition is not crisp enough - users expect more than to tolerate accidental duplicate deliveries provided they have been flagged (why not just prevent the delivery of duplicate if you can notify about it, which assumes you can detect them in the first place?) In any case, I believe the protocol has the ability to enable this stronger definition, which also defines duplicates]

 

ExactlyOnce (can be added although just a combination of other DAs)

 

Previous:

 

Every message sent will be delivered without duplication or an error will be raised on at least one endpoint. This delivery assurance is the logical "and" of the two prior delivery assurances.

 

Proposed: This DA is equivalent to the combination of  AtLeastOnceDelivery and AtMostOnceDelivery DAs (i.e. combining their requirements).

 

[comment: previous no longer adequate with a new, tighter definition of AtMostOnce. Prefer to just say that this is a logical combination of two prior DAs. Also, do we really need this DA if we can combine DAs?]

 

InOrder

 

Previous:

 

Messages will be delivered in the order that they were sent. This delivery assurance may be combined with any of the above delivery assurances. It requires that the messages within a Sequence will be delivered in an order so that the message numbers are monotonically increasing. Note that this assurance says nothing about duplications or omissions. Note also that it is only applicable to messages in the same Sequence. Cross Sequence ordering of messages is not in the scope of this specification.

 

Proposed: When delivering messages from a same sequence, an RMD does so in the same order they have been sent by the application source (AS) to the RMS. This only means a message will not be delivered if another message sent after it has already been delivered. Note: The ordering concerns only messages from the same sequence - not across sequences. Additional delivery constraints are not precluded by this delivery assurance - e.g. to not deliver a message if a previous one is still missing.

 

[comment: reworded in order to be explicit that "send"  must be understood as in glossary: passing a message from AS to RMS, not in its general sense. Also previous wording seems to imply that " messages will be delivered"  is a guarantee, in first sentence, which may be confusing even if denied subsequently. Also avoiding references to "message numbers"  in a general DA def. That already assumes a specific protocol (how are these numbers assigned, etc.) which is introduced only later in the spec.]

 

Chris F comments; http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00036.html

Jacques,

 

Actually, I think that the definitions you have suggested are not quite right. It is important

IMO that the defnitions not prescribe the behavior of the RMD, but rather describe the

outcome as perceived external to the RMD/AD processing.

 

My reasoning is that we don't want to be specifying the implementation of the RMD.

 

To say that the RMD can only "deliver" the message to the AD once would need a formal

definiton of "deliver". Does that mean that it will only ATTEMPT delivery to the AD once? What of that

fails? What if there is transactionality between the RMD and AD such that a failed processing

of the message results in a rollback? Would a retry be in violation of the expressed DA since the

message is delivered more than once?

 

I think that the definitions should read something along the following lines:

 

AtLeastOnce - describes a delivery assurance characteristic of the processing of the messages

within an RM Sequence received by the ultimate receiver such that the each message in the Sequence,

received by the RMD, is processed to conclusion at least once. This means that a given message in the

Sequence that  was received and acknowledged by the RMD MAY be processed to conclusion more than

once. It also means that duplicate filtering SHOULD NOT be applied by the ultimate receiver.

 

AtMostOnce - describes a delivery assurance characteristic of the processing of the messages

within an RM Sequence such that the messages within the Sequence received by the ultimate

receiver are processed to conclusion at most once. This means that a given message(s) within

the Sequence that was received and acknowledged by the RMD might not be processed to conclusion.

It also means  that a given message within the Sequence MUST NOT be processed to

conclusion more than once (ie. duplicate filtering MUST be applied by the ultimate receiver).

 

ExactlyOnce - describes a delivery assurance characteristic of the processing of the messages

within a Sequence such that each message within an RM Sequence received by the ultimate receiver

MUST be processed to conclusion exactly once (ie, duplicate filtering MUST be applied).

It also means that the receiving endpoint SHOULD make every effort to ensure that each message

within the Sequence received by the RMD will be processed to conclusion.

 

Cheers,

 

Christopher Ferris

 

Chris F: Jacques has definition for In order.  This can be combined with others.

 

Tom: I am happy about the wording of In order.

 

Paul F: is this ready.

 

Chris F: Matt Lovett wants to take a shot at clearing up the wording.  Jacques sent a note on follow up, which we are still discussing regarding receipt and responsibilities.  He notes my definitions do not use the word delivery.  I would like to keep the details of delivery between RMD and AD.  These contracts can vary (e.g., duplicate elimination might be in application), however the RMD must always ack.

 

Action: Matt to provide a wordsmithed proposal for PR 0035.

 

Anish: one difference in two proposals regard the fault case.  These definitions are for the non fault case.  When they are not met, faults can ocurr.  These guaranteed either hold of the implementation will fault.

 

 

Paul F: are there any other things we can talk about regarding the Policy assertions for DA.

 

Chris F: my proposal for Policy DA assertions uses nested assertions. Is anyone concerned?

 

No one objected in principal.

 

Chris F: I think Ignorable would be better for these assertions.

 

Tom: I think ignorable is acceptable for the DA policy assertions because the client protocol is invariant to their being in affect.  This is different in the case of WS-Reliability, since the sender does not need to resend unless guaranteed delivery is in afecct.  In WS-RM the sender always resends, and the receiver always acks.

 

Chair F:  this is my thinking

chris: <wsrmp:DeliveryAssurance ...>

    <wsp:policy>

        <wsp:All>

            [<wsrmp:ExactlyOnce/>|<wsrmp:AtLeastOnce/>|<wsrmp:AtMostOnce>]

            <wsrmp:InOrder/>?

        </wsp:All>

    </wsp:policy>

</wsrmp:DeliveryAssurance>

 

Discussion on need for InOrder as its own nested assertion.

 

Marc G: why do we need extra wrapper, deliveryAssurance.

 

Discussion on nested policy, policy intersection, and use of ignorable.

 

Agreed to have email discussion based on Chris F proposal after he posts it.

 

6.5      PR009 "Duplicate Elimination" and "Message Ordering"

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i009

defer

6.6      PR020 Message ordering and duplication

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i020

defer

6.7      PR027 Where do Sequence Faults go when the RMS is anonymous

http://docs.oasis-open.org/ws-rx/issues/pr/Issues.xml#i027

 

Latest Email: http://www.oasis-open.org/archives/ws-rx/200701/msg00044.html

I agree.

 

Re-reading my proposal, I think this whole issue is CNA against the main

spec, and therefore should be retargeted to the MC spec.

 

Paul

 

 

Gilbert Pilz wrote:

> One comment in line . . .

>

>> -----Original Message-----

>> From: Paul Fremantle [mailto:paul@wso2.com]

>> Sent: Thursday, January 04, 2007 1:12 PM

>> To: ws-rx@lists.oasis-open.org

>> Subject: [ws-rx] PR027 review

>> 

>> PR027 was captured as an issue during the discussion of

>> MakeConnection.

>> 

>> The issue is this:

>> 

>> Suppose the acksTo address is a distinct anonymous URI.

>> 

>> There are two options:

>> 

>> 1) the acksTo may be the WSA anon + reference parameters In

>> this case acks can only get back either if the replyTo EPR

>> matches the acksTo EPR.

>> 

>> 2) the acksTo may be the RX anon + id

>> In this case I think acks must be polled for using

>> MakeConnection. Of course they may be piggybacked onto other

>> messages destined for the same RX anon URI. This isn't clear

>> from the spec.

>> 

>> I think we need to address case #2 in the new MC spec document.

>> 

>> I believe case #1 is already covered by the following text in the

>> specification:

>> Implementations MUST NOT use an endpoint reference in the

>> AcksTo element that would prevent the sending of Sequence

>> Acknowledgements back to the RM Source.

>> 

>> I suggest we add the same text to AcksTo that we have for Endpoint:

>> Implementations MAY use the WS-RM anonymous URI template and

>> doing so implies that messages will be retrieved using a

>> mechanism such as the MakeConnection message (see section 3.7).

>

> I think this opens up a interesting issue w/regards to the MC split; to what

> extent and in which manner should the base spec refer to the MC spec and

> vice versa?  It seems to me that there are two ways we can go on this:

>

> 1.) The base spec obliquely refers to the MC spec in the manner you suggest

> (i.e. using phrases such as "mechanisms such as . . ."). The MC spec, in

> turn, fills in the gaps in the base spec.

>

> 2.) The base spec doesn't refer at all to the MC spec. The MC spec overrules

> portions of the base spec.

>

> I think (2) is a preferable solution to (1). (1) inevitably leads to a base

> spec which doesn't stand alone and which, when implemented and/or deployed

> without MC support, has holes in it. To pick the most glaring example, what

> should the base spec say about reliable responses to a non-addressable

> client? If it says "it can be done but you have to use something like MC"

> you've got a hole because you aren't defining what happens if you *don't*

> have something like MC.

>

> - gp

> 

>> I will let the monk^D^D^D^Deditors figure out where this goes

>> in the new specs :-)

>> 

>> Paul

>> 

>> 

 

Paul F gave an overview of this issue.

 

Paul F: with regards to the main spec we can close this issue.

 

Paul F: with regards to the make Connection spec we might want to add text for clarification.

 

Doug D: I would prefer to close the whole thing without action.

 

Gil: I am ok about closing this issue.  However we may need to add another issue, on clarification of the behavior when make connection is not in use.

 

Doug D: :would this be guidance or normative behaviour.

 

Gil: the base spec cannot mandate the use of make connection.

 

Doug D: Gil should open a new issue, which is broader than the scope of PR27.

 

Doug D moved to close PR27  issue without action, seconded by Tom R

 

No objection, Issue Pr27 closed with no action.

 

Action: Gil to open new issue to clarify behavior when make connection is not in use.

 

7         Any other business

none



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]