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

[Art Botterell <acb@incident.com>]

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