[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]