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 WS-RX Teleconf 10/26


Prelim minutes attached.

Please post 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

Prelim Minutes of OASIS WS-RX Teleconference

Oct 26, 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:

 

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 Oct 19, 2006 meeting minutes

http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/20816/MinutesWSRX-101906.html

 

4) AI Review

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

 

5) Report from the Implementation SC

 

6) Discussion of PR Issues

PR004 Editorial comments

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

 

PR005 Sequence Ranges Overlap

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

 

PR023 CreateSequenceRefused fault should apply to sender and receiver

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

 

PR001 WS-Addressing comment on ws-rm related to use of extended anonymous uri

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

 

PR006 Destination of Seq faults

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

 

PR024 When to send CloseSequenceResponse vs. SequenceClosedfault

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

 

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

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

 

PR008 Underlying protocol bindings

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

 

PR009 "Duplicate Elimination" and "Message Ordering"

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

 

 

7) Any other business

 

Bob F will give an addressing update for 5a.

 

Marc G: I would be good to review planned schedule to CS at the next call.

 

Marc G: might want to move discussion to PR001 to end of call, due to recent posting by Dug.

 

No objection: PR001 moved to last positionl

3         Approval of the 10/19 Minutes;

http://www.oasis-open.org/committees/download.php/20751/MinutesWSRX-100506.html

 

There was confusion abut the next call date, which was incorrectly listed as Next Tuesday.

Also, the date on the top was 10/10..

 

Tom moved to approved 10/19  minutes, Paul C seconded.

 

§    No objections, minutes of 10/19 approved.

 

4         AI Review

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

 

#0111: Paul and Bob to work out joint WS-RX/WS-Addressing forum for further discussion of pr001 issue.

Owner: Paul Fremantle

Status: Open

Assigned: 2006-10-05

Due: ---

 

Continue to defer.

 

Ø  ACTION: paul F to add explanation for use of piggybacking.

5         Reports

5.1      Report from the Implementation SC

 

Paul F: running at 30 % coverage of tests.  The group seems to run out of focus.  No spec issues have been found yet.

 

Dug D: more lack of momentum than spec issues.

 

Marc G: we have been busy lately, and have not devoted enough resources.

 

Paul F:  Lets note the: target for Monday the 6th of November to finish the tests.

 

5.2      WS-Addressing update

Bob presented the latest discussions from the ws-addressing group.  There are two new markers proposed  for addressable and non addressable return eprs. 

 

Bob: If either of two options in proposal succeed, it will take the wsdl binding back to last call (minimal 4 week).

 

Paul C: where is testing status of wsdl binding.

 

Bob: there has been testing.   It has been suspended.

 

Tom: what about wsdl 2.0 availability.

 

Bob: we are dealing with all available wsdl versions, as they become available.

 

Paul C:  status on CR stated testing would be in phases, wsdl 1.1 followed by wsdl 2.

 

Anish: w3c allows specs to be one step ahead of other specs.  WSDL 2 is in CR.  Only if WSDL 2 does not go to pr there could there be a problem.

 

 

6         Discussion of PR Issues

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

 

Ø  Action: Marc G to keep people on public comment list notified of the current issue numbers.

 

 

6.1      PR004 Editorial comments

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

 

Mail from dug: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200610/msg00109.html

Leaving the boundaries of being just a monkey I started to work on these nits and Gil's (all part of PR004):

Some comments:

- Quite a few of the refs to sections 3.x were wrong, so I had to change most of those - if people are inclined please check those, esp. in the state tables

- soap1.1 is a Note not a Member Submission - I know they changes the term but when you follow the link it still says "Note" so I'm leaning towards not changing that one

- Schema references - any one have any opinion on which version we should point to?

- can't see the odd bold stuff you mention in point 25

- 26: did it for WSRM and WSRMP

 

WSRMP

- 1 -  don't see the italic issue you reference

 

All other changes are applied but not checked-in yet.

 

thanks,

-Doug

 

Paul: 4th editition for XML, 2nd edition for schema

 

Motion to accept proposed changes by Gil and Marc in the PR Issue 004, to resolve 004, seconded by Marc G:

 

§    No objection issue 4 closed by accepting changes form Gil and Marc.

6.2      PR005 Sequence Ranges Overlap

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

Description

 

          The RM spec says, w.r.t. Seq Ack Ranges:

          The ranges SHOULD NOT overlap.

          Why isn't this a MUST NOT?  It smells like an interop issue if we don't know if the other side can deal with it.

       

Raised against / Related drafts

    ws-rm revision: cd04

Related Issues

Origin

    Doug Davis

 

          Proposal 12006-10-19

    Change it to a MUST NOT

 

 

Motion by Dug to accept proposal 1, seconded by Marc G.

 

§    No objection, Issue PR023 resolved by accepting proposal 1.

 

6.3      PR023 CreateSequenceRefused fault should apply to sender and receiver

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

Description

 

          In section 4.6 the CreaetSequenceRefused fault is defined as a sender fault. This fault should apply to sender or receiver.

       

Raised against / Related drafts

    ws-rm revision: cd04

Related Issues

Origin

 

          Marc Goodner

       

 

Paul F: No clear proposal.  Agreed to postpone for discussion next week.

 

Marc G: I need to work some more on this.

6.4      PR001 WS-Addressing comment on ws-rm related to use of extended anonymous uri

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

 

deferred

 

6.5      PR006 Destination of Seq faults

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

Description

 

          From spec: Line 893

          RM Destinations that generate Sequence faults SHOULD send those faults to the same [destination] as Acknowledgement messages.

          The text is a bit unclear.  Does it mean that sending it is optional or is the EPR it sends it to optional?  I think the intent was just the act of sending it is option, but it must go to the AcksTo EPR.

       

Raised against / Related drafts

    ws-rm revision: cd04

Related Issues

Origin

    Doug Davis

 

          Proposal 12006-10-19

    RM Destinations that generate Sequence faults SHOULD transmit those faults. If the fault is transmitted, it MUST be transmitted to the same [destination] as Acknowledgement messages.

 

General agreement.

 

Chris F moved, Matt seconded to accept proposal to resolve PR006.

 

Jacques: what if there is a soap fault along with a sequence fault.  A soap fault for a received message is going on the soap back channel.   Soap faults might go over the request back channel, rather than the AcksTo EPR.

 

Anish: you made distinction between soap faults and sequence faults.  The soap must understand , version mismatch etc will go over back channel   However the proposed text is scoped to sequence faults, so I am ok with the text as proposed.  Sequence faults are defined in section 4.  If you generate rm faults, the address to send them is the acksTo address.

 

Bob: these rm “faults” are really protocol control messages to the acks to, it it not a fault in the sense of other application specs.

 

Paul: we do not define sequence fault yet.  We should define sequence fault as “any of those faults defined in this spec”.  

 

Paul F: I do not agree to change the name from “fault” is acceptable.

 

Marc G: we are using soap faults to transmit these, so they are faults.

 

Dug: lets add new term sequence fault.

 

Paul F: I propose that we amend Dug proposal by also adding a new definition for Sequence Fault as “any of those faults defined in this spec”.,

 

Paul C: if text refers to named text fault, is that a sequence fault.

 

Dug G: sequence create refused is sent to acks to, so it is not a sequence fault.

 

Chris F: it “sequence fault” is only used twice, why not change those two places to be clearer.

 

Chris change text on lines 892 and 893 from “sequence faults” to “such faults”

 

Paul C:

        Rm destination that generate faults related to know sequences SHOULD transmit those faults. If these faults are transmitted, they MUST be transmitted to the same [destination] as Acknowledgement messages. 
 

Dug moved to amend motion to use the following text, seconded by Chris F: “Destinations that generate faults related to known sequences SHOULD transmit those faults. If  transmitted, such faults MUST be transmitted to the same [destination] as Acknowledgement messages.”

 

§    No objection to amendment.

 

§    No objection to accepting proposed amended resolution to resolve Issue PR006.

 

6.6      PR024 When to send CloseSequenceResponse vs. SequenceClosedfault

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

 

Description

 

          In section 4.7 describing the SequenceClosed fault one reason the fault must be returned is that an RMD is “…asked to close a Sequence that is already closed.” However, in section 3.5 that describes CloseSequence it says that for a closed sequence the RMD must process all Sequence Lifecycle messages including CloseSequence. It also says that subsequent CloseSequence messages have no further effect.

       

Raised against / Related drafts

    ws-rm revision: cd04

Related Issues

Origin

 

          Marc Goodner

       

Proposal:

Strike the text in section 4.7 saying the SequenceClosed fault should be returned when the RMD is asked to close already closed sequences.

 

Chris F: we also have to change the state tables.

 

Dug D: the editors could update the state tables.

 

Dug D moved to accept Marc G proposal, with change to state tables, Seconded by Marc G.

 

§    No objection, Issue Pr024 closed with accepting Marc G proposal and changing state table.

 

6.7      PR007 RM Destination lacks a mechanism for cleanly terminating inbound sequences.

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

Description

 

            Stipulate the following scenario: a client and server communicate using asynchronous, two-way, reliable messaging. During the initial sequence creation the client offers a sequence to the server and this offer is accepted. Some number of requests and responses are exchanged using the requested and offered sequences. At some later time the user of the client application causes that application to exit. It is obvious that the client-side RMS should  clean up the outgoing, client-to-server sequence by sending a wsrm:TerminateSequence message (possibly preceded by a wsrm:CloseSequence message) to the server-side RMS. What is not clear is what steps the client-side RMD should take to clean up the incoming, server-to-client sequence. There are three basic courses of action:

 

            1.) The client-side RMD could do nothing to clean up the incoming sequence. From a distributed systems viewpoint this seems less than optimal as it leaves the server-side RMS with a "dangling sequence". If the server-side RMS ever tried to use this dangling sequence it would engage the entire RMS machinery for messages that would never get through (send, retry, request acks, retry, request acks, etc.).

 

            2.) The client could wait for a length of time sufficient for it to consider the inbound sequence to be "inactive", then exit. There are a couple of problems with this. Firstly the user that caused the client to exit may grow impatient and attempt to terminate the client by other means. Secondly, outside of the optional expiration time, there is no mutually agreed upon inactivity period for a sequence.

 

            3.) The client-side RMD could send a message to the server-side RMS to indicate that the inbound, server-to-client sequence is being cleaned up. Since the direction of the wsrm:TerminateSequence message is specified by WS-ReliableMessaging 1.1 as being from the RMS to the RMD only, this leaves either the wsrm:SequenceTerminated or wsrm:SequenceClosed faults as the only viable messages for the client-side RMD to use. This brings up all the problems attendant with using faults/exceptions to indicate "normal" application behavior. The server-side RMS may construe the appearance of a fault as an indication of some lower-level problem, etc.

 

            Note that, although this issue is discussed in the context of a client application attempting to exit, it is applicable in any situation where the process/VM that "contains" an RMD must exit in a relatively short period of time for whatever reason.

         

Raised against / Related drafts

    ws-rm revision: cd04

Related Issues

Origin

    Gilbert Pilz

 

          Proposal 12006-10-19

 

          Amend the wording of section 3.6 (Sequence Termination) to indicate that a wsrm:TerminateSequence/wsrm:TerminateSequenceResponse exchange may be initiated by the RMD.

 

Dug: why not use close sequence?

 

Chris F: any RMS or RMD can issue terminatedSequence Fault at any time.  Issueing a sequence terminated when done would be alright.

 

Marc G: you are asking for clean shutdown when you are exceptionally going down.  It does not sound right to me.  I worry about other implications allowing an RMD to terminate a sequence like this.

 

Jacques: the fault works, unless there is a need to guarantee common view of state.  It would be good to cleanly terminate sequence from RMD.  Terminate sequence might be sufficient.

 

Chris F: two situations:

1)      client wants reliable bi dir. When it is done it is done, it does not care about the other side.  Final state cleanup is not required.  The acks speak for themselves.

2)      The things fall over dead, let things clear themselves up.

 

If client is happy because it got all acks

 

Tom: why is it not enough to rely on acks.  At worst case the sender will think that messages were not received, when in fact they were.  If this is the only state synch issue, I do not see a reason to go beyond use of sequenceTerminated fault.

 

Gil: It would be helpful if an rmd that knew it was going down, to help the rms get a better knowledge of the state of the sequence.  Would like to distinguish clean tear down from catastrophic failure.

 

Paul F: since this is about helping, perhaps a final sequence ack could be used to allow the server to clean up.  We can do this without change of protocol, but could just make a recommendation.

 

Gil: annotating a sequenceTerminated fault with a final sequence ack, might suffice.

 

Gill: a sequenceTerminated Fault sounds too drastic for a shutdown.

 

Dug: how about a sub element of terminated fault to indicate this case.

 

Paul F: a sequence terminated fault after the final Close.

 

Gil: an RMD cannot send close sequence or terminate sequence.  However the RMD can send an ack with the Final marker.

 

Ø  Action: Gil and Paul will work on a new proposal for Pr0008.

 

6.8      PR008 Underlying protocol bindings

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

 

Marc G moved (seconded by Dug) to close PR008 with no action, since underlying protocol bindings are outside of charter.

 

Jacques: the Authors need to know how to bind to an underlying protocol.

 

Marc G: perhaps we should clarify that while this is beyond our charter, RSP group might be able to deal with underlying protocol bindings.

 

§    Issue Pr008 closed without change, and sending notice to issue author that protocol bindings are out of scope of this group, but could be dealt with in WS-I RSP group.

6.9      PR009 "Duplicate Elimination" and "Message Ordering"

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

Description

 

          2.1 This specification dose not define how to realize "Duplicate Elimination" and "Message Ordering".

          It is a serious issue for industry organizations in Japan and Asia to adopt the specification.

          We strongly recommend to define them to make various implementations interoperable.

       

Raised against / Related drafts

    ws-rm revision: cd04

Related Issues

Origin

    eBusinss Asia Committee

 

 

Discussion on closing without action.

 

Jacques pointed out that we could clarify how you can do duplicate elimination and message ordering.

 

Paul F: how about us working on a primer.  I could take some clarifications from the past and produce a first cut at a primer.

 

Tom: I thought we still have a sentence in the document that the protocol supports duplicate elimination and message ordering.

 

 

1         Any other business

 

Meeting closed at 5:30 PM Eastern.

_______________________________________________________________________
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]