[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 Wed, 2005-05-25 at 18:12 -0400, Art Botterell wrote: > 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. But you haven't addressed content routing devices, and thats what I'm attempting to address. These are intermediary reception devices that sit at the edge of a network, but do not parse the content. They are targets for delivery, but the recipients are other systems on their local or next-hop networks. > > 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? Good job on the misquote and the rest of the lame insinuations and fabricated commentary - A+ for effort, F- for tact. Now, if you're done with your whining, lets recap the facts - 1. you gave me a proposal (use a keyword field in the distribution block), and 2. I think that proposal is half-baked. Why? Because the EDXL spec specifically states "<targetArea> elements describing geospatial or political target area for message delivery". Going by this definition, I should use the targetarea to direct reception of messages. But according to you I shouldn't. We can argue this back and forth as many times as we want, but it all boils down to this: Targetarea functionality as it is defined right now will not work for satellite, terrestrial and datacasting distribution and routing of EDXL content. Why? At the headend, a device is going to encapsulate the data and deliver it. At best one wants to preserve as much of the EDXL message as possible. The originating message may only have geographical information. The headend system has functionality to perform target area to device mapping, but where does it store that functionality? Outside of the EDXL message? Most likely. Yet, now you are mixing multiple layers of referenced protocols, defeating the purpose of EDXL, since I may need to retain that information to determine how I received the message. Before you jump up and give me the token 'this sounds like a specific implementation issue' line, I give you this response - our receiver devices have built-in embedded map servers. I can easily use targetareas of geographical coordinates to target MY devices. However 99% of ALL OTHER satellite and terrestrial devices use the common targeting mechanism of a device identifier, and have no mapping or geo-capability at all. County and jurisdiction are equally unusable, as they are not granular enough. So I propose - Add an 'identifier' field to the targetarea section, which lets people who cannot target geographically at the 'receiver device level' accomplish their goals. <identifier> <keyword> <valueListUrn>valueListUrn<./valueListURN> <value>value<./value> <./keyword> <./identifier> (ignore the .'s) where keyword occurs 1..n and identifier occurs 0..n. This would give the most flexibility. Cheers Kon
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]