← Prev in month ← Prev in thread
Next in thread → Next in month →

parameters (Rel 81-86)

From
Jacques Durand <>
Date
2003-10-14T20:15:21+00:00
ID
Thread
parameters (Rel 81-86)
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
← Prev in month ← Prev in thread
Next in thread → Next in month →