The MessageId value is required to be unique. We mean
globally, universally and forevermore unique. Based on that requirement,
a duplicate message should never be created except as part of retries
for reliable messaging (or through a faulty transfer).
[Jacques
Durand] Understood. This requirement for global uniqueness of
messageID might deserve a more explicit statement, as RFC2392 could
be interpreted mostly as a format requirement. (also, maybe we should
recommend an ID method : date & time stamp with sender host domain
name, or support in existing languages, like Java UID function in server
package)
Another issue related to time: I think the current
wording makes the handling of different time zones (message sent in one zone
and received in another zone) error prone (3.1.6.4). The XML Schema dateTime
does not necessarily mandate the use of UTC. I think we should make it more
explicit that the canonical representation of dateTime should be
used: the sender should either append its time zone (difference with
UTC) to its local time, or use the UTC time (appended with "Z"). (as required
for other MS timestamps), Then, I would rephrase:
" In this context, the TimeToLive has expired if the time
of the internal clock of the Receiving
MSH is greater than the value of TimeToLive for the
message.
as:
In this context, the TimeToLive has expired if the time
of the internal clock of the Receiving
MSH , adjusted as UTC time, is greater than the value of TimeToLive for the message
adjusted as UTC time.
(or
maybe we should say somewhere more generally that all time comparisons apply
to UTC version of the time/date)
Otherwise, some users/vendors of a careless MSH will
have some surprise when sending "reliable" messages to Japan (receiver MSH
will likely discard them all !)
regards,
Jacques
Durand