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: New proposed issues 10/27 - 11/02


Please let me (and the list) know if I missed any issues sent to the week in the last week.

 

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

Proposed-01 Title: SeqAck - None and Final

Proposed-02 Title: Create Sequence Refused Fault is too restrictive

Proposed-03 Title: Reword "Closing a Sequence" section

Proposed-04 Title:Remove LastMessage

Proposed-05 Title: Replace 'response'

Proposed-06 Title: Remove 'correlation' text

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

 

Proposed-01

Title: SeqAck - None and Final

 

Description:  In [1] current schema and pseudo schema doesn't allow None and Final on the same SeqAck - and they should be.

 

Justification: Its possible that a sequence could be closed w/o any Acks.

 

Target: core

 

Proposal: Make schema and pseudo schema support None and Final - like this:

 

<wsrm:SequenceAcknowledgement ...>

  <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier>

    [ [ <wsrm:AcknowledgementRange ...

          Upper="xs:unsignedLong"

          Lower="xs:unsignedLong"/> *

        | <wsrm:None/> ]

        <wsrm:Final/> ?

      | <wsrm:Nack> xs:unsignedLong </wsrm:Nack> + ]

    ...

</wsrm:SequenceAcknowledgement>

 

Note: changed the + to a * on the AckRange element. since Final can appear w/o any AckRanges.

 

 

[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf

 

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

Proposed-02

Title: Create Sequence Refused Fault is too restrictive
Description: In WS-RM specification[1], the Create Sequence Refused fault requires [Detail] to be empty (lines 836-842) as follows:

 

{
4.7 Create Sequence Refused
This fault is sent in response to a create sequence request that cannot be satisfied.
Properties:
[Code] Sender
[Subcode] wsrm:CreateSequenceRefused
[Reason] The create sequence request has been refused by the RM Destination.
[Detail] empty
}

 

We think that this is too restrictive and should allow any content to be part of [Detail]. The specification should not dictate interpretation of content of the [Detail], but should not restrict its contents.

 

Justification: There may be many reasons to indicate why Create Sequence may be refused by RMD. Further, sequence creation may be composed by security or other extensibility as CreateSequence element allows today. Disallowing [Detail] to contain any element, we are restricting extensibility and ways for tools to interpret the reasons for create sequence to fail. We think that the [Detail] element content may be used for including additional information which may be specific to a platform, composition or extension.

 
Target: core

Proposal: Allow [Detail] to contain any content, instead of requiring it to be empty.

[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf

 

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

Proposed-03

Title: Reword "Closing a Sequence" section

 

Description:

Section 3.6 "Closing a Sequence" contains in introduction to the close operation, and its justification. I think that the current text would benefit from a rework. Lines 625 - 648 of working draft 05 say:

 

There may be times during the use of an RM Sequence that the RM Source or RM Destination will wish to discontinue using a Sequence even if some of the messages have not been successfully delivered to the RM Destination.

In the case where the RM Source wishes to discontinue use of a sequence, while it can send a TerminateSequence to the RM Destination, since this is a one-way message and due to the possibility of late arriving (or lost) messages and Acknowledgements, this would leave the RM Source unsure of the final ranges of messages that were successfully delivered to the RM Destination.

To alleviate this, the RM Source can send a <wsrm:CloseSequence> element, in the body of a message, to the RM Destination to indicate that RM Destination MUST NOT receive any new messages for the specified sequence, other than those already received at the time the <wsrm:CloseSequence> element is interpreted by the RMD.

Upon receipt of this message the RM Destination MUST send aSequenceAcknowledgement to the RM Source. Note, this SequenceAcknowledgement MUST include the <wsrm:Final> element.

While the RM Destination MUST NOT receive any new messages for the specified sequence it MUST still process RM protocol messages. For example, it MUST respond to AckRequested, TerminateSequence as well as CloseSequence messages. Note, subsequent CloseSequence messages have no effect on the state of the sequence.

In the case where the RM Destination wishes to discontinue use of a sequence it may 'close' the sequence itself. Please see wsrm:Final above and the SequenceClosed fault below. Note, the SequenceClosed Fault SHOULD be used in place of the SequenceTerminated Fault, whenever possible, to allow the RM Source to still receive Acknowledgements.

 

Justification: The above text could be clearer.

 

Target: core

Type: editorial

 

Proposal:

Replace the above text (lines 625 - 648) with the following:

 

There may be times during the use of an RM Sequence that the RM Source or RM Destination will wish to discontinue using a Sequence. Simply terminating the Sequence discards the state managed by the RM Destination, leaving the RM Source unaware of the final ranges of messages that were successfully delivered to the RM Destination. To ensure that the Sequence ends with a known final state both the RM Source and RM Destination may choose to 'close' the Sequence before terminating it.

If the RM Source wishes to close the Sequence then it sends a <wsrm:CloseSequence> element, in the body of a message, to the RM Destination. This message indicates that the RM Destination MUST NOT receive any new messages for the specified sequence, other than those already received at the time the <wsrm:CloseSequence> element is interpreted by the RMD. Upon receipt of this message the RM Destination MUST send a SequenceAcknowledgement to the RM Source. Note, this SequenceAcknowledgement MUST include the <wsrm:Final> element.

While the RM Destination MUST NOT receive any new messages for the specified sequence it MUST still process RM protocol messages. For example, it MUST respond to AckRequested, TerminateSequence as well as CloseSequence messages. Note, subsequent CloseSequence messages have no effect on the state of the sequence.

In the case where the RM Destination wishes to discontinue use of a sequence it may close the sequence itself. Please see wsrm:Final above and the SequenceClosed fault below. Note, the SequenceClosed Fault SHOULD be used in place of the SequenceTerminated Fault, whenever possible, to allow the RM Source to still receive Acknowledgements.

 

Related issues: None

 

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

Proposed-04

Title:Remove LastMessage

Description:
The LastMessage element, as part of a Sequence header element, appears superfluous. It seems to serve 2 purposes:
1 - force a SeqAck to be sent back from the RMD
2 - force the RMD to reject any messages with a higher message #

#1 can be done with an AckReq header.  We should avoid having multiple ways to do the same thing.
#2 is really only an issue if someone tries to hijack the sequence - and to protect against that we should be using a real security mechanism like WS-SC/Trust, not the LastMessage element.

When an RMS is done with a sequence it is free to simply Close or Terminate it (whether or not it has all of the Acks it wants - but normally it will wait) - having an additional message exchange to send a LastMessage is unnecessary.

Justification: See above.

Target: core

Proposal:  Remove all references to LastMessage (and related Fault)  from the spec [1].  See attached diff/pdf file for the specific changes.

[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf

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

 

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

Proposed-05

Title: Replace 'response'

Description:  under figure 2, for step 7 replace:

        7.The RM Destination acknowledges receipt of message numbers 1 and 3 in response to the RM Source's <wsrm:LastMessage> token.
with
        7.The RM Destination acknowledges receipt of message numbers 1 and 3 as a result of receiving the RM Source's <wsrm:LastMessage> token.

Justification: "response" could be misleading since some may think of it as a request/response thing.
Basically just a minor editoral change.  We need easy ones for our conf calls  :-)

Target: core

Proposal: see above.

[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf

 

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

Proposed-06

Title: Remove 'correlation' text

Description:

In section 2.2 the spec [1] says:

The RM Source MUST have an endpoint reference that uniquely identifies the RM Destination endpoint; correlations across messages addressed to the unique endpoint MUST be meaningful.

        Does anyone know what correlations its talking about?  If not this text seems pretty useless and should be moved as it could be misleading for some people to think we're talking about WS-Addressing correlation or something.

Justification: Leads to confusion.

Target:  core

Proposal: Remove the text after the semi-colon.

[1] http://www.oasis-open.org/apps/org/workgroup/ws-rx/download.php/15001/wsrm-1.1-spec-wd-05.pdf

 

 



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