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 2/1 teleconf


Prelim minutes are attached for 2/1 teleconf.

Please provide corrections to list before monday morning.

-- 
----------------------------------------------------
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 2/1/2007

Prelim Minutes of OASIS WS-RX Teleconference

Feb 1, 2007

 

Start Time:4:00 PM Eastern Daylight Time

 

Sanjay 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 25, 2007 meeting minutes

Preliminary Minutes: http://lists.oasis-open.org/archives/ws-rx/200701/msg00105.html

 

4) AI Review

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

 

5) Approval of Latest Working Drafts.

http://lists.oasis-open.org/archives/ws-rx/200701/msg00111.html

 

6) New issues

 

7) Discussion of PR Issues

 

a> PR015 RMD polling

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

 

b> PR029 Opaqueness of URI identifiers not preserved by RM anon URI

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

 

c> PR035 Delivery Assurance

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

 

d> PR009 "Duplicate Elimination" and "Message Ordering"

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

 

e> PR020 Message ordering and duplication

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

 

f> PR038 Need to clarify relationship between the WS-RM specification and MakeConnection specification

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

 

8) Any other business

 

Marc G suggested we move DA issues and issus 38 to top of list.

 

Agreed to move 15 and 29 to the end.

3         Approval of the 1/25 Minutes;

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

 

Tom moved to approve 1/25 minutes, Doug D seconded.

 

§    No objections, minutes of 1/25 approved.

 

4         AI Review

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

 

124 closed

 

130 closed

 

131 closed

5         Approval of Latest Working Drafts.

http://lists.oasis-open.org/archives/ws-rx/200701/msg00111.html

 

Sanjay: By approving this WG we are moving closed issues to pending status.

 

Marc G: all the closed issues, except for those in the agenda for this meeting, are applied.

 

Sanjay: the WG incorporate all issues pending, and 23, 37, and 39.

 

Marc G moved to accept WG and move incorporated issues to closed,  Doug D seconded.

 

No objection, WGs approved and issues incorporated to be marked as closed.

6         New Issues

none

 

7         Discussion of PR Issues

7.1      c> PR035 Delivery Assurance

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

 

Peter proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200702/msg00000.html

 

Deliver definition

Deliver: The act of transferring responsibility for a message from the RM Destination to

the Application Destination.

 

 

Added 2.4

2.4 Delivery Assurances

This section defines a number of Delivery Assurance assertions, which can be supported

by RM Sources and RM Destinations. These assertions can be specified as policy

assertions using the WS-Policy framework [WS-Policy]. For details on this see the WSRM

Policy specification [WS-RM Policy]

AtLeastOnce

Each message is to be delivered at least once, or else an error MUST be raised by the RM

Source and/or RM Destination. The requirement on an RM Source is that it SHOULD

retry transmission of every message sent by the Application Source until it receives an

acknowledgement from the RM Destination. The requirement on the RM Destination is

that it SHOULD retry the transfer to the Application Destination of any message that it

accepts from the RM Source, until that message has been successfully delivered. There is

no requirement for the RM Destination to apply duplicate message filtering.

AtMostOnce

Each message is to be delivered at most once. The RM Source MAY retry transmission

of unacknowledged messages, but is NOT REQUIRED to do so. The requirement on the

RM Destination is that it MUST filter out duplicate messages, i.e. that it MUST NOT

deliver a duplicate of a message that has already been delivered.

ExactlyOnce

Each message is to be delivered exactly once; if a message cannot be delivered then an

error MUST be raised by the RM Source and/or RM Destination. The requirement on an

RM Source is that it SHOULD retry transmission of every message sent by the

Application Source until it receives an acknowledgement from the RM Destination. The

requirement on the RM Destination is that it SHOULD retry the transfer to the

Application Destination of any message that it accepts from the RM Source until that

message has been successfully delivered, and that it MUST NOT deliver a duplicate of a

message that has already been delivered.

InOrder

Messages from each individual sequence are to be delivered in the same order they have

been sent by the Application Source. The requirement on an RM Source is that it MUST

ensure that the ordinal position of each message in the sequence (as indicated by a

message sequence number) is consistent with the order in which the messages have been

sent from the Application Source. The requirement on the RM Destination is that it

MUST deliver received messages for each sequence in the order indicated by the

message numbering. This DeliveryAssurance can be used in combination with any of the

AtLeastOnce, AtMostOnce or ExactlyOnce assertions, and the requirements of those

assertions MUST also be met. In particular if the AtLeastOnce or ExactlyOnce assertion

applies and the RM Destination detects a gap in the sequence then the RM Destination

MUST NOT deliver any subsequent messages from that sequence until the missing

messages are received or until the sequence is closed.

 

        Policy addition:

<wsrmp:DeliveryAssurance>

<wsp:Policy>

[ <wsrmp:ExactlyOnce/> |

<wsrmp:AtLeastOnce/> |

<wsrmp:AtMostOnce> ]

<wsrmp:InOrder/> ?

</wsp:Policy>

</wsrmp:DeliveryAssurance> ?

 

/wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance

This expression, which may be omitted, describes the message delivery quality of

service between the RM and application layer. When used by an RM Destination

it expresses the delivery assurance in effect between the RM Destination and its

corresponding application destination, and it also indicates requirements on any

RM Source that transmits messages to this RM destination. Conversely when used

by an RM Source it expresses the delivery assurance in effect between the RM

Source and its corresponding application source, as well as indicating

requirements on any RM Destination that receives messages from this RM Source.

In either case the delivery assurance does not affect the messages transmitted on

the wire. Absence of this expression from a wsrmp:RMAssertion policy

assertion simply means that the endpoint has chosen not to advertise its delivery

assurance characteristics.

/wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy

This required element identifies additional requirements for the use of the

wsrmp:DeliveryAssurance.

/wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/

wsrmp:ExactlyOnce

This expresses the ExactlyOnce Delivery Assurance defined in [WS-RM].

/wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/

wsrmp:AtLeastOnce

This expresses the AtLeastOnce Delivery Assurance defined in [WS-RM].

/wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/

wsrmp:AtMostOnce

This expresses the AtMostOnce Delivery Assurance defined in [WS-RM].

/wsrmp:RMAssertion/wsp:Policy/wsrmp:DeliveryAssurance/wsp:Policy/

wsrmp:InOrder

This expresses the InOrder Delivery Assurance defined in [WS-RM].

 

Jacques suggestions: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200702/msg00002.html

Peter:


Why did you change the last sentence of InOrder def in a stronger requirement ? I think what you had before was better...

By saying now (for composition AtLeastOnce+InOrder):

" the RM Destination MUST NOT deliver any subsequent messages from that sequence until the missing messages are received or until the sequence is closed."

You are ruling out the following scenario:

- I am interested in having the RM layer do its best to transmit and deliver and tell me when it could not (error raised). So that's AtLeastOnce. But in addition I am also interested in having the messages that are delivered, to be delivered in order - even if there are gaps (e.g. the sender is monitoring quantitative indicators, and periodically sending report messages but it is OK to loose a few messages - as few as possible though - but the ordering is critical to reflect accurately the "trends").

I would keep InOrder+AtLeastOnce open enough by replacing your MUST NOT by SHOULD NOT above. Every flavor of ordered delivery can then be controlled with additional parameters such as our IncompleteSequenceBehavior (when its value is "DiscardFollowingFirstGap” that would achieve your current definition)

Minor edit, to catch-up with the new definition of "Deliver"

Replace "transfer"  with "delivery" in def of AtLeastOnce and of ExactlyOnce:

"...The requirement on the RM Destination is
that it SHOULD retry the
transfer to the Application Destination of any message... "

Thanks,

Jacques

 

There was discussion on Jacques proposed changes.

 

Jacques: In order does not disallow gaps. In some cases it might not have to wait forever for missing message in sequence.  We do not need to bring all flavors in general definition, however it should be able to be refined with further parameters, such as incompleteSequenceBehavour.

 

Doug B moved to accept proposal to close issue 35 as worded by Peter Niblet, seconded by Doug D.

Jacques: I can accept these definitions, even though I would prefer a wordsmithing.

 

Ashok: I have a concern about the agreed policy assertions for RM assertions from last week.  These DA assertions are being added to the RM assertions.  They need to be fit into the structure for RM assertions.

 

Marc G: The editors can resolve any such difficulties.

 

No objection, issue 35 resolved with Peter Niblett proposal.

 

Sanjay: Ashok can post any concerns on the agreed text on the mailing list.

 

 

 

7.2      Close related issues

d> PR009 "Duplicate Elimination" and "Message Ordering"

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

 

e> PR020 Message ordering and duplication

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

 

Marc G moved to close issues 9 and 20 as duplicates of issue 35, seconded by Jacqeus.

 

No objection,  issues 9 and 20 closed as duplicates of issue 35.

 

 

7.3      f> PR038

Need to clarify relationship between the WS-RM specification and MakeConnection specification

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

 

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

changes to lines 384 to 395:

Implementations MUST NOT use an endpoint reference in the Endpoint element that would prevent the

sending of Sequence Lifecycle Message, etc. For example, using the WS-Addressing

"http://www.w3.org/2005/08/addressing/none" IRI would make it impossible for the RM Destination to ever

send Sequence Lifecycle Messages (e.g. TerminateSequence) to the RM Source for the Offered

Sequence. Implementations MAY use the WS-MakeConnection anonymous URI template and doing so

implies that messages will be retrieved using a mechanism such as the MakeConnection message.

 

The Offer of an Endpoint containing the "http://www.w3.org/2005/08/addressing/anonymous" IRI as its

address is problematic due to the inability of a source to connect to this address and retry

unacknowledged messages (as described in Section 2.3). When offering a Sequence with such an IRI, an

endpoint MUST ensure that it will provide the protocol back-channel opportunities necessary to carry

Sequence Traffic Messages for the offered Sequence, as well as any Sequence Lifecycle Messages

and/or Acknowledgement Requests that the anonymous RM Destination expects to receive for this

Sequence. In the absence of sufficient assurance that the endpoint offering the sequence will provide

these opportunities, an RM Destination MUST NOT accept (via the

/wsrm:CreateSequenceResponse/wsrm:Accept element described below) an Offer that contains the

"http://www.w3.org/2005/08/addressing/anonymous" IRI as its address.

 

Anish: I am concerned that the mention of extension is taken away.

 

Anish: you will not see issues until reliability problems occur.  I would like to call out that we need to call out that if you do not have an agreed upon way of assuring a way to resend these messages, reliability will not occur.

 

Jacques: I do not think we need an explicit reference to Make connection in the core spec.  If there is a way to use the RM layer you are fine.

 

Anish: I do not say we have to point to MC spec, but there are several ways to skin this cat (including resending a request with the response piggybacked).  That is what is meant by extensibility.  This spec does not say how it is done, and if you used this scenario you must make sure the appropriate mechanisms are in place.

 

Gil: add one sentence “the base spec does not define a mechanism for this”

 

Anish: I would be happy with that solution.

 

Paul F: Make connection has two variants one which does use the URI.

 

Jacques: I am ok with adding such a sentence, but it is a tricky editorial point.  Regardless of make connection you might decide to use rms and rmd in particular ways to make this happen.

 

Gil: add following before sentence “In the absence of sufficient assurance”

“Note that this specification does not define any mechanisms for providing this assurance”

 

Gil moved to close issue 38 with his proposal and the additional sentence, Jacques seconded.

 

No objection, issue 38 closed with Gil proposal along with additional sentence “Note that this specification does not define any mechanisms for providing this assurance”

 

 

a> PR015 RMD polling

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

 

Doug D proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00092.html

Proposes New text in section 3.4 of Make Connection Spec for separate policy assertion.

 

Doug D moved to close issue 15, Charleton seconded

 

No objection, issue 15 closed with Doug D proposal

 

7.4      b> PR029 Opaqueness of URI identifiers not preserved by RM anon URI

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

 

Doug D proposal: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200701/msg00087.html

 

 

Jonathan: I do not think this completely resolves the issue, but cannot complain too much.

 

Paul F: at one time we thought of adding this as reference parameter for UUID.   I still think this is a cleaner solution, but it does not matter that much to me.

 

Doug D: give resolution of CR33 in WS-addressing, this is an acceptable solution.

 

Anish: the problem is with epr comparison when they include ref parms.

 

Paul F: we would define our own ref parm for UUID,  what is problem with other ref parms in epr?  This UUID uniquely identifies who the destination of the anonymous URI is.

 

Chris F: an EPR is not an identifier.  We cannot use it as an identifier.

 

Anish: in answer to Paul, we have to identify who the sender is.  If the ref parm is necessary to identify the sender, we can have two eprs with same value of our ref parm, but have additional ref parms.  Are these significant in the comparison of EPR for identity.

 

Paul F: server not allowed to look at ref parm was a reason used in the past.  However, the WS addressing proposed one use of ref parms to resolve our problem.  I thing it is a neater option to solve our problems.

 

Doug D: we have gone thru these discussions many times.  If Paul wants to make his point, he can raise new issue

 

Doug D moved to resolve issue 29 with his proposal, seconded by Gil.

 

Tom: I speak in favor of the motion, since we are putting this into the ReplyTo header we should not rely on special epr comparison rules.  If we were defining our own header, with an epr value type, we might be able to get away with a special comparison rule, using our ref par.  But this is for use in replyTo.

 

Gil: I also speak in favor.

 

Jonathan: we could decide to change the syntax to text however.

 

No objection to resolve issue 29 with Doug D proposal.

 

8         Any other business

 

Sanjay: we can now produce a CD05 candidate for all three documents, and decide at some meeting if it has substantial changes.  We can vote on this document’s progress in the next few meetings. If substantial changes are voted, we need to have a second public review.

 

Paul C: as a result of moving make connection to another spec, we have changed schema.   Do we have to change the namespace URI.  We need to discuss this as an explicit decision.

 

Doug D: I did update the namespace on everything, because it was required in my opinion.

 

Paul C: a namespace change might affect some members decision on significant change.

 

Tom R: Some members might think a small schema change is not a significant.  We have taken away items so we need to change namespace.

 

Paul C moved to change namespace identifier in the documents, to the current date, seconded by Doug D.

 

No objection, namespace to be changed in next CD document for all three specs..

 

Bob F: ws addressing wishes a review of the metadata document by the members of this group.

 

Meeting ended at 5:25 PM eastern time.

 



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