parameters (Rel 81-86)

[Jacques Durand <JDurand@fsw.fujitsu.com>]

Title: parameters (Rel 81-86)

I would propose we create a small task force to generate a group proposal for Rel 81 - 86
(configuration Parameters), as it is an issue with several possible ramifications and assumptions,
that we need to sort out and decide on before shaping a coherent proposal.
(e.g. what is the scope of these parameters?
- all connections sender-receiver an RMP is involved in?
- One individual connection?
- One group?)

Here is a summary of my (revised) initial but partial proposal on these:

Rel 81: Maximum message lifetime/duration 
- cancelled (ExpiryTime is now mandatory)

Rel 82: Maximum message group (or message sequence) lifetime
- propose to rename removeAfter attribute, as GroupExpiryTime or ExpiryTime,
like for messages.
- propose to add GroupMaxIdleTime parameter as an option to terminate a group
based on maximum idle time between two messages. But would only apply if
GroupExpiryTime not specified.

Rel 83: Resend interval (related REL 47)
- as proposed in issue list.

Rel 84: Retransmission count (related REL 47)
- as proposed in issue list.

Rel 85: Duplicate search scope (minimum number of past messages to look-up)
- to defer, as maybe more an implementation issue tied to overall available store size.

Rel 86: Unordered messages window size (max number of messages to hold)
- to cancel, see proposal for Rel 57.
implementations will have to detect their persistent store limits.

So I see at least 3 parameters (Rels 82, 83, 84) that represent some
form of RM agreement that govern the behavior of a Sender, of a receiver or both,
and that should not appear in message headers. The editorial treatment of these
could be something like:
"When reliability feature XYZ is required, an RMP MUST represent and persist
the parameters <...> [for each connection][for all conenctions,...]"
These paraemters can then be referred to by the spec to describe the behavior of an RMP.

Regards,

jacques