OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [emergency] EDXL Target Areas for device coded recipients


Art et. al. -

Sorry for jumping into the middle of this discussion, but are there any use 
cases that have been written that capture the essence of the problem we are 
trying to solve here? If I just read the email thread, I would think that 
there may a number of existing Internet standards related to mobile wireless 
networks, routing, etc that may either provide a solution or well considered 
guidance for a solution.

Thanks for providing clarity!

Carl


----- Original Message ----- 
From: "Art Botterell" <acb@incident.com>
To: "Emergency Mgt XML TC" <emergency@lists.oasis-open.org>
Sent: Wednesday, May 25, 2005 4:12 PM
Subject: Re: [emergency] EDXL Target Areas for device coded recipients


> On May 25, 2005, at 1:06 PM, Kon Wilms wrote:
>
>> What if the device receiving the data is not the intended recipient?
>
> Not sure what you have in mind... but if the device has been  programmed 
> to process messages for recipients in a particular area, I  assume it 
> will.
>
>> This sounds a little half-baked. This is supposed to be a routing
>> mechanism, after all.
>
> Gee... could I maybe encourage you to think twice before throwing  around 
> terms like "half-baked"?... it sounds a bit hostile and a  number of folks 
> spent a fair amount of time working on this, so some  of them might take 
> offense. Would you settle for just saying that you  yourself don't fully 
> buy it yet?
>
> The point is that this isn't supposed to be a routing mechanism, per 
> se... its supposed to be a generic method of representing routing 
> assertions to any number of different potential routing mechanisms.   That 
> forces us to a higher level of abstraction.
>
>> Any device can be moved without changing its identity. This is a
>> universal problem, and one which is actually more easily solved by  using
>> routing IDs instead of geographical data. Any change to a device
>> location translates to a modification at only the server-side, which
>> then re-associates the IDs with the new geographical area.
>
> But what if the server doesn't know?  E.g., I might want to address 
> mobile wireless devices in an area a mile around a potential  explosion. 
> Should I have to maintain a server-side table of where  every device is at 
> all times?  Location awareness isn't always  centralized... sometimes it's 
> decentralized and sometimes its pushed  all the way to the edge.  We need 
> to be able to support all those cases.
>
>> If I want to target EDXL distribution to specific devices that will
>> re-route content, what do I use?
>
> If you need to send a message to a particular address, for whatever 
> purpose, you could use the <recipientAddress>.  But wouldn't that be  a 
> bit like having to name all the IP routers involved in the address  of an 
> email?  The point is to abstract the intended routing result  from the 
> network-specific particulars.
>
>> - Is targetarea restricted to the incident target area only and not  the
>> routing target area(s)?
>
> That's an important distinction, and one we may not have been  explicit 
> enough about.  I'd say that <targetArea> describes the  sender's estimate 
> of where appropriate recipients are located...  which will usually be a 
> somewhat larger area than that directly  affected by the incident itself.
>
> (Which isn't to say that a recipient couldn't try to get messages for 
> somewhere else in which it has an interest... e.g., a resident on a 
> hilltop might have a business down in the valley and want messages  for 
> there, too... but whether such "remote" messages would be  available would 
> depend on the particular dissemination system serving  that user.)
>
>> - Does recipient define the viewer of the content, or a device that  may
>> not be the viewer of the content (Hopefully not both).
>
> The recipient might be a human that will view the content, or it  might be 
> a device that will process it, either for subsequent human  consumption or 
> for some automated purpose.  The binding between  addresses and humans can 
> get complicated, of course, what with  forwarding, aliasing and such.  But 
> the target is whoever or whatever  needs the information, for whatever 
> purpose.
>
> Hope that helps,
>
> - Art
>
>
> ---------------------------------------------------------------------
> 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
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]