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


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]