No, the solution I
have proposed is not ruled out by the results of any previous proposals and it
is not an editorial issue. My proposal to resolve it is partially editorial in
removing discussion of DAs but not in the sense that it removes the DAs from
the policy assertion.
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Thursday, December 08, 2005
11:29 AM
To: 'Anish Karmarkar'; wsrx
Subject: RE: [ws-rx] i050 proposal
+1
But I think this thread has been
debating of the wrong problem...
Let us be
precise:
Read
carefully i050: it is about the editorial treatment of DAs, NOT about their
exposure as a run-time artifact (which has already been resolved in i009).
The DAs
having now a formal representation with i009, there is no question they should
be specified somewhere. Solution (a) is ruled out. Issue 009 is actually
including a technical definition of the DAs that relates to RMD duties, so that
seems to cover sol (b). Keeping a general definition in wsrm spec as we have
today does not hurt, and I think developers can connect the dots between
protocol features and how to implement DAs. So I'm happy.
Jacques
-----Original
Message-----
From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
Sent: Wednesday, December 07, 2005
11:11 PM
To: wsrx
Subject: Re: [ws-rx] i050 proposal
I would
like to make a another proposal for this issue:
Close with no action.
DAs are
important to users of the specification and layers above.
Applications (and customers) use
message reliability to offer deliver
guarantees. I would say that this
is a core requirement supported by
usecases that have been discussed
in the past. I remain unconvinced by
the argument that let the users of
the WSRM figure out DAs. I would like
to see the the RM protocol talk
about it, figure out how it works and
get interop on it.
DAs are a
contract between the RMD and AD (which do not affect the
messages on the wire) and the TC
has already voted on making this
contract public. The TC voted to
create a new policy artifact (assertion
or parameter) that can be
advertised, essentially allowing the DAs to be
public. I believe this is the right
thing to do as it supports a lot of
usecases that have been discussed in
this as well as the WSRM TC.
I also
don't understand what is gained by removing them? I would also
like to mention that our charter
requires DAs.
Thx.
-Anish
--
Marc
Goodner wrote:
> The list archive doesn't seem
to have the content of this message. I'm
> resending to try and correct
that. Regards, Marc g
>
>
________________________________________
> From: Marc Goodner [mailto:mgoodner@microsoft.com]
> Sent: Tuesday, November 22,
2005 11:19 AM
> To: wsrx
> Subject: [ws-rx] i050 proposal
>
> All,
>
> After following the discussion
around this issue and thinking carefully
> I do believe that attempting
to expose the delivery assurances was a
> mistake and they should be
removed from the spec. I am unconvinced by
> the use cases for the need of
exposing these. None of them strike me as
> things that the core protocol
needs in order to function properly or
> that would add value to users
of the protocol be they developers,
> administrators or
applications. However I am sympathetic to those that
> believe it is important to
keep the descriptions of the guarantees in
> the core spec.
>
> Therefore I have prepared the
following proposal to remove the delivery
> assurance from the RM Policy
spec and the language around delivery
> assurances in the core spec.
Essentially what the changes to the core
> spec do is remove references
to "delivery assurance" changing them
> instead to talk about the
"guarantee" in effect.
>
> A lot of the problem with the
delivery assurances being viewed as a
> concrete thing that was
missing from the specification comes from the
> line "This guarantee is
specified as a delivery assurance", the key
> problem there being the word
"specified". These were intended to be
> abstract definitions of the
guarantees that could be provided by use of
> WS-RM and not something to be
formally specified and advertised by an
> RMD or RMS. This
interpretation is strongly backed by these lines from
> the contributed WS-RM
specification that are still present in the CD:
> "Persistence
considerations related to an endpoint's ability to satisfy
> the delivery assurances
defined below are the responsibility of the
> implementation and do not
affect the wire protocol. As such, they are
> out of scope of this
specification."
>
> I believe that if the
following proposal, were it to be accepted, would
> go a long way to getting us
back to work on the core protocol. The
> amount of discussion around
this topic and issues being raised, none of
> which impact the wire
protocol, is evidence as to why this subject was
> left out of scope for the
contributed specification.
>
> Regards,
> Marc g
>
> Proposal to close i050
>
>>From wsrm-1.1-spec-cd-01
make the following changes:
>
> Line 161, strike this text:
> "This guarantee is
specified as a delivery assurance."
>
> Line 162: change "the
delivery assurances" to "guarantees"
>
> Line 163-167 change:
> "The protocol defined
here allows endpoints to meet this guarantee for
> the delivery assurances
defined below. However, the means by which these
> delivery assurances are
manifested by either the RM Source or RM
> Destination roles is an
implementation concern, and is out of scope of
> this specification."
>
> To:
> "The protocol defined
here allows endpoints to meet the guarantees
> defined below. However, the
means by which these guarantees are
> manifested by either the RM
Source or RM Destination roles is an
> implementation concern, and is
out of scope of this specification."
>
>
> Line 168-169 change:
> "Note that the underlying
protocol defined in this specification remains
> the same regardless of the
delivery assurance."
>
> To:
> "Note that the underlying
protocol defined in this specification is
> independent of guarantees in
effect at the RMS or RMD. I.e.,
> irrespective of the delivery
assurance, this specification, for the
> non-error case, requires the
RMS to retransmit a message until an
> acknowledgement is received
from the RM Destination for every message
> that the RMS sends in the
Sequence."
>
> Line 173: change
"delivery assurances" to "guarantees"
>
> Line 180-181 change:
> "This delivery assurance
is the logical "and" of the two prior delivery
> assurances."
>
> To:
> "This guarantee is the
logical "and" of the two prior guarantees."
>
> Line 182-183 change:
> "This delivery assurance
may be combined with any of the above delivery
> assurances."
>
> To:
> "This guarantee may be
combined with any of the above guarantees."
>
> Line 185: change
"assurance" to "guarantee"
>
> Lines 204-205: strike these
lines to remove definition of "delivery
> assurance"
>
> Lines 275-276 change:
> "Messages for which the
delivery assurance applies MUST contain a
> <wsrm:Sequence> header
block."
>
> To:
> "Messages in a WS-RM
sequence MUST contain a <wsrm:Sequence> header
> block."
>
>
>>From wsrmp-1.1-spec-cd-01
make the following changes:
> Remove section 2.5 by striking
lines 233-267
>
>