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: PR009 and PR020: outline of a proposal


 
(treating PR009 and PR020 together here, - ignoring slight differences)
 
After more discussion with issues originators: they want mostly a couple of things:
 
1. Definitions for the reliability assurances mentioned in the charter (At-least-once, At-most-once...) . These are informally defined in the charter but these definitions really belong in the spec, using the precise terminology introduce by the messaging model, and also referring to protocol elements. For example, there are several mentions of  " message duplicate" , but no clear definition of this term (how is a message identified ? with wsa:MessageId? or by sequence ID + sequence # ? the latter is only alluded to in the 2.4 example)
 
Rationale: even if the support and requirement for reliability assurances is out of scope, product developers need to refer to common definitions when they decide to implement these. Their implementation will affect the design of RMD product from the start.
 
 
2. RM Policy assertions that identify these reliability assurances.
 
Rationale: for those implementors who have decided to implement reliability assurances, the users of their products need to be able to exchange agreements or capabilities on these. For those service providers who require or support these assurances, there needs to be an interoperable way to advertise them.
 
Note: clearly there may be more reliablity assurances than the minimal set mentioned in the charter - and in particular, there may be several flavors of ordered message delivery. Also different flavors of what to do in case of failure. But a minimal set is needed in a first phase.
 
 
So... sounds a bit like "deja-vu"  , but note that the above proposal does NOT make any requirement on implementations, and does NOT impose that the protocol vary with the delivery assurance. Only that a core set of definitions and  policy representations be present for those who choose to implement them and to share them.
 
Regards,
Jacques


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