[no subject]

The purpose and intent of this parameter is possibly underspecified, The 
intent that the authors (well, certainly
my understanding) had is that a Sequence could be unilaterally terminated 
by either the RMS or RMD should there be no
activity against the Sequence for a period of the specified duration. 
Thus, should no messages be received by
the RMD for the specified wsrm:InactivityTimeout duration, it **could** 
terminate the Sequence at its discretion. 
(It does not need to do so). Likewise, should an RMS not receive any 
SequenceAcknowledgements for the 
specified  wsrm:InactivityTimeout duration, despite having attempted to 
transmit messages during that 
period (hence it was likely expecting them) then it could unilaterally 
terminate the Sequence.

Of course, discretion should be used in selecting a suitable value for 
this parameter, probably based on the
expected frequency of activity (and adding a suitably generous margin of 
error). However, it is not the intent
that this parameter specify the frequency with which messages are to be 
retransmitted by the RMS.

The intent was to provide a means by which an RMD could reclaim resources 
for which it appears that 
the corresponding RMS has "left the building", "bit the dust", "rode off 
into the sunset" (e.g. possibly come
to a horribly nasty and greusome end).

Mr. Praline: 'Ello, I wish to register a complaint.
(The owner does not respond.)

Mr. Praline: 'Ello, Miss?

Owner: What do you mean "miss"?

Mr. Praline: I'm sorry, I have a cold. I wish to make a complaint!

Owner: We're closin' for lunch.

Mr. Praline: Never mind that, my lad. I wish to complain about this parrot 
what I purchased not half an hour ago from this very boutique.

Owner: Oh yes, the, uh, the Norwegian Blue...What's,uh...What's wrong with 
it?

Mr. Praline: I'll tell you what's wrong with it, my lad. 'E's dead, that's 
what's wrong with it!

Owner: No, no, 'e's uh,...he's resting. 

Mr. Praline: Look, matey, I know a dead parrot when I see one, and I'm 
looking at one right now.

[...]

Owner: No no! 'E's pining! 

Mr. Praline: 'E's not pinin'! 'E's passed on! This parrot is no more! He 
has ceased to be! 'E's expired and 
gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! 
If you hadn't nailed 'im to the perch 'e'd 
be pushing up the daisies! 'Is metabolic processes are now 'istory! 'E's 
off the twig! 'E's kicked the bucket,
'e's shuffled off 'is mortal coil, run down the curtain and joined the 
bleedin' choir invisibile!! THIS IS AN 
EX-PARROT!! 

(Sorry, couldn't resist!)

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295

"Vikas Deolaliker" <vikas@sonoasystems.com> wrote on 07/22/2005 02:39:46 
PM:

> 
> 
> *Title*: RM Policy Assertion Model's Base Retransmission Interval
> Clarification Needed
> 
> *Description*:
> The RM policy assertion model defines InactivityTimeout  and
> BaseRetransmissionInterval. The text in the specification WS-RM Policy 
(Page
> 5) implies that these two parameters are essentially serving the same
> purpose i.e. to trigger a retransmit based on a timeout value. If this 
is
> the intention, the spec needs to clarify the pecking order for an
> implementation i.e. what if timeout occurs before base retransmission
> interval has expired. 
> 
> *Justification*:
> There is no obvious case mentioned in the spec that requires two timers 
for
> retransmission upon timeout. 
> 
> *Target*: (core | soap | wsdl | policy | schema | all)
> Policy
> 
> *Type: *(design | editorial)
> design
> 
> *Proposal*:
> 
> 1) Merge the two into one timer called Retransmission Timeout. 
> 
> *Related issues*:
> 
> None
> 
>