Re: [emergency] EDXL-DE Issues

[Kon Wilms <kon@datacast.biz>]

I'll get the list started:

1. Size element : "Value must be in bytes and represent the raw file
size (not encoded or encrypted)."

How would I know the size if the payload is encrypted and padded by e.g.
the symmetric block cipher algorithm. It may well be that the
originating payload that is to be encapsulated is already encrypted. 'or
encrypted' should be removed.

2. Issue 9: "After much discussion, TC acknowledged the potential for
unwise applications of <derefUri>, but declined the proposal as being
more appropriate to particular application and/or network specs.
However, the TC voted to make <size>  mandatory whenever <derefUri> is
used."

Perhaps someone can point out as to why it is more logical to stuff a
file into an EDXL message using base64 (this increasing message size,
storage requirements on the transmitter and recipient ends, and
bandwidth utilization for the link between the two) when it can be
referenced via URI.

Including large payloads as an excuse to not implement or integrate with
a delivery network is *itself* a 'particular application'.

Making size mandatory is completely pointless on one-way delivery
networks unless a device pre-processes and re-generates all the EDXL
payloads at the origination site.

The TC makes the assumption that these network delivery mechanisms will
be able to efficiently pre-empt or provide QoS data transmissions if a
large file is in the queue. Let alone if the link has limited link
budget or availability. These are all basic network delivery
constraints.

I should also point out that the EDXL spec is inconsistent with the CAP
1.1 spec, and that by the current conclusion of issue 9 the CAP spec is
essentially catering to a 'particular application':

CAP 1.1 DerefURI:

(1) MAY be used either with or instead of the <uri> element in messages
transmitted over one-way (e.g., broadcast) data links *where retrieval
of a resource via a URI is not feasible*.

Cheers
Kon