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: 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
> 
> 


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