[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 { 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. ---------------------------------------------------------------------------- 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 Origin: http://www.oasis-open.org/apps/org/workgroup/ws-rx/email/archives/200511/msg00019.html ---------------------------------------------------------------------------- Proposed-05 Title: Replace 'response' ---------------------------------------------------------------------------- Proposed-06 Title: Remove 'correlation' text |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]