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] Proposal to extend the EDXL TargetArea to allow more flexible targeting/filtering/content routing


Friends -

My impression is that this proposed change, well-intentioned though  
it surely is, would be both unnecessary and harmful.

Unnecessary because it really just duplicates the existing <keyword>  
structure under a different name within the <targetArea> block.   
Anything that could be asserted in the new structure can already be  
asserted using <keyword> or <recipientAddress> (although maybe we  
should generalize the name of <recipientAddress> to avoid over-narrow  
interpretations... please see below.)

It doesn't seem to me that EDXL applications should need to look for  
domain-specific designators in two different places within the DE.   
In fact, I don't see why non-location-aware devices should have to  
process <targetArea> blocks at all.

And harmful because it would sanction the use of system-specific  
(i.e., not universally understood) codes as aliases for geospatial  
descriptions.  That would diverge from our policy of using OGC, ISO  
and UN/LOCODE standard representations, and would create a serious  
functional interoperability problem.  (We've tolerated that practice  
in a limited form and with strong caveats in CAP, in order to provide  
backward compatibility with SAME and other existing alert-targeting  
codes... but there's no need to introduce it into the fresh fields of  
EDXL.)

I'm afraid this proposal is based on a misunderstanding of  
<targetArea> as the only part of the EDXL Distribution Element (DE)  
that describes the target audience.  That's simply not the case.

The optional <targetArea> structure describes a "target area" in  
geospatial terms (either explicitly using OGC-compliant features or  
by reference to well-known political boundaries using standard  
international codes.)  But other tags in the DE, including <keyword>,  
<recipientRole> and <recipientAddress>, also describe the target  
audience, in non-geospatial and potentially system- or context- 
specific terms.

The suggestion that the existence of intermediate routing devices  
somehow requires the proposed change also seems misguided.  The whole  
purpose of the DE is to allow senders to describe where they want the  
enclosed content to go without needing to specify how each particular  
transport system will route it, which is something they may not know  
and may not even be permitted to know (e.g., within secure networks.)

Delivery systems that have their own internal address space and  
routing processes are pretty common.  But it was never our intent to  
require senders to specify in the DE each explicit address and  
routing step within each network (even though <keyword> and  
<recipientAddress> could, in a pinch, be used to do so.)  Instead,  
we've tried to give senders a system-independent way to describe the  
desired set or sets of destinations, trusting each specific delivery  
system to map those objectives transparently to its own internal  
mechanics.

After all, are senders outside a particular broadcast system likely  
to keep track of all of its internal addresses and the current  
physical locations corresponding to each?  I shouldn't think many  
system operators would want to disclose that information and, even if  
they did, that would be a awful burden to put on the senders.

So an EDXL gateway for that particular system routinely would need to  
perform a mapping from the delivery objectives set forth in the DE to  
its own system-specific addresses... which it could insert into the  
DE for internal routing using <keyword> to refer to sets of internal  
nodes ("groups") and/or <recipientAddress> for specific internal  
nodes.  Again, none of this is unique to broadcast environments.

And of course nothing would precludes an "outside" sender from  
specifying system-internal group or individual addresses in the same  
way, if it happened to know them, e.g., via an explicit subscription.

As an alternative, in the interests of avoiding unnecessary  
duplication and not diverging from geospatial standards, I'd like to  
propose that <recipientAddress> be relabeled "<explicitAddress>" in  
order to clarify that it can refer to any recipient device, whether  
it's an end-point or a relay (since as noted above, the sender may  
not always know, or need to know, which it is)... and also that we  
consider whether <explicitAddress> should have a domain/value  
substructure consistent with <keyword>, <recipientRole> and  
<senderRole>, in order to deconflict addresses from various systems.

All this is in pursuit of the rule of parsimony, aka the "KISS*  
Principal."  It would be easy to address each individual use-case by  
tossing more features into the spec, but that's the road toward  
incoherence and bloat.  Our first question should always be "is there  
a way to solve this within the existing structures?"  In this case  
the answer is "yes."

- Art

* "Keep It Simple, Sweetheart"



On May 26, 2005, at 5/26/05 12:30 PM, Kon Wilms wrote:

> Folks,
>
> In my first iteration of implementing EDXL for satellite and edge
> network delivery of EDXL messages, I came across some potential  
> problems
> during the use case scenario/planning stages. This is a proposal to  
> add
> an element to correct these issues.
>
> To start off, I need to point out that this issue is not specific  
> to my
> implementation. So, following, my proposal to add an element to  
> resolve
> this issue, starting with the definition of the distribution element
> from the current EDXL draft:
>
> "The EDXL Distribution Element (DE) comprises a <Distribution> element
> as described hereafter, optional <targetArea> elements describing
> geospatial or political target area for message delivery, and a set of
> <messageElement> elements each containing specific information  
> regarding
> a particular item of content, which it includes within a  
> <contentObject>
> structure. The included content may be any XML or other file or
> document."
>
> By definition of the above, the targetArea elements are to be used to
> target message delivery. The current targetArea elements include:
> circle, polygon, country, primaryJuristiction, and
> secondaryJurisdiction.
>
> However, how do we deliver messages to devices that cannot make use of
> geo-spatial targeting? (the remaining fields are not granular  
> enough for
> targeting)
>
> --- A little explanation on one-way network data delivery:
>
> All edge network, terrestrial, and satellite one-way receiver devices
> make use of a unique and/or group identifier to receive and filter  
> data.
> This is either a system-specific ID, their MAC address, a fixed PID, a
> port number, or some form of 'target' name. This is done because it is
> the most optimum method of filtering traffic over a one-way network
> (since the ID can reside on the device's firmware and/or be inserted
> into the headers of the packet payloads). In most cases any of these
> lower-level device characteristics are abstracted by use of a generic
> device identifier. Directv, Echostar, Loral, Sky,... all utilize this
> mechanism as a base for addressing devices, tied directly to  
> Subscriber
> Management and Data Delivery servers, and indirectly to Conditional
> Access systems.
>
> So there is, as I see it, a problem here with delivery of messages to
> target areas for these devices and networks - being that they cannot
> make use of the existing fields in the targetArea block, and cannot
> perform geo-location resolution.
>
> --- So, possible solutions:
>
> "use the keyword or recipientAddress which reside in the distribution
> block"
>
> - The first issue with using either of these fields is that it does  
> not
> mesh with the definition of the EDXL distribution element, since in
> essence this equates to using non-targetarea sections of the
> specification for targetArea-related use.
>
> - The second issue is that the targeted receiver device may not be the
> recipient of the message. Take for example a satellite distribution
> mechanism that feeds a local area network via a satellite edge router.
> This is an intermediary recipient. The edge router must be targeted,
> because one cannot target the tertiary devices as we don't know what
> they are. There is a hand-off between the satellite and local  
> networks,
> the two have no connection, and as such the satellite delivery system
> must be able to deliver messages to its edge receivers. Using the
> recipientAddress or keyword field once again defeats the purpose of  
> the
> targetArea, and also leads to one having 'non-final-recipient
> recipients', which no doubt will cause content routing issues.
>
> In conclusion, using these fields doesn't seem like the correct
> approach, but more like a quick-fix solution where a field not  
> intended
> for targetArea use is being used for precisely that. Which adds
> ambiguity to the spec and could lead to significant routing issues  
> in 2
> +hop networks.
>
> --- A proposal to fix this issue:
>
> - targetArea is the correct area to use for targeting, and as such
> should support more generic reception and high-level routing of data.
>
> - when delivering data over a network that cannot support geo-location
> lookup and makes use of group/device targeting and hand-off between
> multiple networks, the server must add an additional targetArea  
> element
> to the EDXL message, while still retaining the original targetArea
> blocks (these may contain geographical targeting information), thus
> allowing final recipients that can perform geographical lookup to  
> filter
> their data.
>
> - in order to prevent device/network-specific implementations and
> non-interoperability, the identifier (maybe identifier isn't the  
> correct
> keyword to use) block should appear as follows:
>
> <targetArea>
> <identifier>
>   <keyword>
>     <valueListUrn>valueListUrn<./valueListURN>
>     <value>value<./value>
>   <./keyword>
> <./identifier>
> <./targetArea>
> where the identifier block occurs 0..n with 1..n keyword blocks
>
> or
>
> <targetArea>
> <identifier>
>   <valueListUrn>valueListUrn<./valueListURN>
>   <value>value<./value>
> <./identifier>
> <./targetArea>
> where the identifier block occurs 0..n
>
> With the above mechanism, the proposed identifier block can be used to
> enable one-way delivery targeting of messaging when using edge devices
> and content filtering hubs, be this over terrestrial, satellite, or
> cable IP delivery networks. It would also support filtering and  
> hand-off
> across multiple vendors using non-compatible multi-hop networks, since
> non-compatible networks can make use of the Urn/value elements,  
> keeping
> the EDXL content abstracted from multi-hop interoperability issues.
>
> Cheers
> Kon
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]