Re: [emergency] EDXL 2-May-2005: Distribution element : IDs

[Renato Iannella <renato@nicta.com.au>]

On 11 May 2005, at 15:54, Art Botterell wrote:

> As you know, our current approach is to use a combination of the 
> message id, sender id and timestamp as the "primary key" for 
> individual messages, as per the definition in <references>.  That's to 
> allow senders to use their own internal message numbering systems, if 
> they have them, and to namespace them within their own domains... and 
> to "timespace" them with the timestamp.  Also it's a bit more 
> informative on inspection than a UUID.  But I'm sure we're all open to 
> input on why some other way would be better.

My view is that the information about the senderID and timestamp 
already appears, so there is no
need to repeat this as part of a <reference>. If there is a need to 
support internal message numbering
systems, then I would recommend that we make the <reference> element of 
URI datatype and individual
systems can prefix with their domain name (etc) and also allow those 
who wish to use other URI systems
(such as UUID).

As an example, Web Services Notification (WSN) uses UUID for its 
message identifiers.

(BTW - we should look at WSN as a mechanisms for EDXL message 
subscription and exchange ;-)

> As for <sender>, perhaps I misunderstand, but I don't think we 
> actually limit these ids to email addresses...

Yes we do. The document says "... in the form user@hostname..."


Cheers...

Dr Renato Iannella
Project Leader, NICTA, Brisbane, QLD, AUSTRALIA
P: +61 7 3000 0484 F: +61 7 3000 0480 M: +61 4 1313 2206
E: renato@nicta.com.au W: http://nicta.com.au


--------------------------------------------------------------------------
This email and any attachments may be confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.