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

[Art Botterell <acb@incident.com>]

Renato -

Your points have great merit, of course.  Let me offer some personal  
thoughts, and perhaps some of the other TC members will want to make  
their own observations.

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.

As for <sender>, perhaps I misunderstand, but I don't think we  
actually limit these ids to email addresses... one might also use a  
Jabber-style extention of the email address, or even a URI of some  
sort.  The only requirements are that it's a) in a globally-unique  
namespace, and b) locally unique within that namespace.  Also, isn't  
it fairly common to assign email-style addresses to processes or  
other non-human agents?  Again, our intent was to allow implementers  
to use as much of their native addressing schemes as they liked, so  
long as they're namespaced for global uniqueness... and also to  
facilitate debugging by making these ids as meaningful as possible by  
human inspection.

But certainly this is collaboration and you're a member of the TC, so  
I hope you'll feel free to make the case for alternatives approaches.

- Art

On May 9, 2005, at 6:54 AM, Renato Iannella wrote:

>
>
> Hi all comments/feedback on 2-May-2005 version of EDXL for IDs used  
> in the distribution element.
>
> 1 - messageID
>
> I am concerned that this is not a globally unique identifier.
> I would recommend that this take the form of a UUID for global  
> interoperability.
>
> 2 - senderID
>
> I am concerned that this only allows email addresses.
> What if the sender is not human but a system (ie web service)??
>
> 3 - messageReference
>
> If (1) is adopted above, then the value would simply be the UUID of  
> the original message.
>
> 4 - recipientAddress
>
> Same concerns as (2) - but since this is a URI then an email  
> address or Web Service
> location is possible? (Ie recipient maybe human or machine?)
>
>
> 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.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs  
> in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>