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


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]