Rel 50, 52, 57 revised

Rel 50: (solution b) Semantics of ExpiryTime:
-------------------------------

Proposal:

ExpiryTime indicates the ultimate date after which the receiver RMP MUST
not make a received message available to the application. 

After a message has been sent for the first time, ExpiryTime in a message 
MUST NOT be modified in any case by the Sender, when resending the message:
two messages with same ID (duplicates) MUST also have same ExpiryTime.

When a message expires on the Sender side before being sucessfully sent,
a Sender RMP MUST NOT send it or resend it, and must communicate a delivery failure 
to the Sender application.

When a message received by an RMP expires before being delivered to the
application, and if guaranteed delivery is required, an RMP MUST make available
to the Sender a fault message, with Fault code "MessageExpired".

When receiving a message that has already expired, an RMP MAY decide to
not accept the message. In that case, and if guaranteed delivery is required, 
the RMP will not generate a positive Acknowledgement and will directly generate 
a fault instead.

NOTES: 
- It is possible that a positive acknowledgement has been generated for a message 
that is later discarded by the RMP, e.g. due to expiration. In such case a Fault is
always generated to the Sender.
- Given the above definition of ExpiryTime, in case duplicate elimination is required, 
when a received message is processed, it is sufficient to only check for its duplicates 
among IDs of past messages that have not expired yet at the time of the duplicate check.