[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: New proposed issues 8/11 - 8/17
|
In text format this week due to the html problems on the
mail list. Let me know if I missed any. Regards, Marc Goodner Proposed-01: Accurate final acknowledgement of a Sequence
with gaps when RMS decides to stop using it. Proposed-02: Remove dependency on WS-Security -------------------------------------------------------------------------------------------- Proposed-01: Title: Accurate final acknowledgement of a Sequence with
gaps when RMS decides to stop using it. Description: When a Source decides to stop using a sequence,
there is no way the RMS can get a sequence ack that it knows will accurately reflect the
final state of the sequence, i.e. the state the sequence will have at actual
termination time. No matter how long an RMS waits after its last sending and
before requesting its last Ack, some past message that was previously sent and
never acknowledged (for which RM Source had stop any resending effort) could be
received late by RMD (e.g. after being stuck in a router), i.e. after the
sending of the last SequenceAcknowledgement and before the sequence is actually
terminated so that the RMD can reclaim resources. This is the twin sister of
issue i019 which deals with a similar problem but in case of sequence fault
(which gives no chance to RMS to get this final seq ack.) Justification: An RMS (or SA) may decide to stop using a
sequence even though some messages were not received (not acked). But in all
cases, it is important that the RMS gets a final accurate account of which
messages have been received and which have not for this sequence. The RMS may
have to raise an error for those not received. Also if the SA decides to take
remedial action for these (e.g. some resending on its own) it must be given
some means to avoid treating messages that it did not know were already
received in a previous sequence (e.g. avoid resending them later in a new
sequence as they would become undetectable duplicates.) Target: core Type: design Origin: Owner: Proposal: TBD. Outline of a solution: (a) give an RMS a way to trigger a SeqAck that will be
associated with the "closing" of the sequence i.e. no more message
will be accepted by the RMD after this Ack is generated. (b) give an RMS a way to reiterate this trigger in case it
is lost, so that it can get this last SeqAck. -------------------------------------------------------------------------------------------- Proposed-02: Title: Remove dependency on
WS-Security Description: The current draft of
the WS-ReliableMessaging specification includes elements that are defined in
WS-Security. This dependency is unnecessary and creates a number of problems
for WS-RM implementations and the organizations that provide such implementations.
It should therefore be removed. Justification: Lines 502-508 of
WS-ReliableMessaging-v1.0-wd-01 describes the inclusion of a
<wsse:SecurityTokenReference> as a sub-element of the
<wsrm:CreateSequence> element. The reason for including a SecurityTokenReference
in the sequence creation request is to provide the information necessary to
perform authorization checks upon the messages within the sequence. Such
authorization checks are unnecessary as they only serve to defend against a
denial-of-service attack (spoofed sequence identifiers) that can be better
defended against by proper protection of the sequence identifier. In addition
to this there are a large number of denial of service attacks that are not
blocked by these authorization checks. If vendors that provide
implementations of WS-RM are required to support the use of the
SecurityTokenReference during sequence creation in order to be deemed
"compliant" (as the current interopability scenarios indicate), then
such vendors must supply an implementation of WS-Security along with their
implementation of WS-ReliableMessaging. This despite the fact that 99% of
their customers may not be interested in using anything more complicated than
SSL to protect their web services traffic. Although the use of the
SecurityTokenReference element is described as optional, the decision on
whether or not to use this option lies with the RM Source. Since there is no
RM-Policy Assertion that indicates whether or not the RM Destination can accept
the use of this option, negotiating the use of this option requires manual, out
of band communications between the operators of the two systems. This impacts
the usability of the systems that use WS-RM. Target: core Type: design Related Issues: i007 Origin: Gilbert Pilz Owner: Gilbert Pilz Proposal: * Delete lines 458-461 of
WS-ReliableMessaging-v1.0-wd-01 * Delete lines 502-508 of
WS-ReliableMessaging-v1.0-wd-01 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]