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

[Art Botterell <acb@incident.com>]

Check the attitude at the door, will you, Kon?  This really isn't  
about you.

Personally, for all the reasons I've explained before, I think it  
would be an interoperability mistake to encourage building system- 
specific codes into the targetArea block.  Besides which, in this  
case it would be misleading, since the router isn't necessarily in  
the target area.

If you needs specific addressing a mechanism is provided, which is  
<recipientAddress>.  Or for even more flexibility you could hold your  
nose and simply use a <keyword>.

- Art


On May 25, 2005, at 8:25 PM, Kon Wilms wrote:

> 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
>
>
>
> ---------------------------------------------------------------------
> 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
>