Re: [emergency] MPEG (was Re: [emergency] usage scenarios)

[Kon Wilms <kon@datacast.biz>]

On Thu, 2005-08-18 at 13:09 -0700, Art Botterell wrote:
> While it's probably true that jumbo payloads can break some transport  
> or receipt systems, that's equally true for PowerPoint (ask the  
> Navy!) or any number of other formats.  I don't think we should build  
> implementation-based limits into the spec that could hobble future,  
> more capable implementations.

This is not so much to do with bandwidth implications as it is to do
with using XML as a cheap and easy transport mechanism. It is not a
transport and really should not be used as one. Hammering the network is
merely a bi-product of creating these unwieldy XML files.

As for future implementations, due to the fact that EDXL will be routed
over a multitude of networks implies that the size of the message will
always be limited by the lowest bandwidth capability of any recipient.

I recall an RF demo some time back where FEMA stipulated to us that the
messages be delivered within two seconds of their origination. No matter
the size of the pipe and transport mechanism, a large message with
embedded content will take longer than 1 second to process on each side
of the link. And the same issue would be faced by implementers not using
RF delivery.

> (Also, I don't think the issue here is MPEG, per se... obviously the  
> size of a particular MPEG clip relates its duration, resolution,  
> frame rate, image motion and other factors, and some clips might be  
> relatively small.  The concern would be the same for large binaries  
> of any type... and we can only speculate as to what the tolerable  
> file size might be in any particular environment and at any point in  
> time.)

That's a good point - there are too many variables to consider when one
combines all these disparate networks and delivery mechanisms. What
about that one variable that is overlooked and leads to the message not
being delivered in a timely manner to a recipient that really needs it?

> As for supporting multiple access methods, I think the current  
> version of the spec provides that capability... using the "absolute  
> for network, relative for local" approach in <uri>.  But, for the  
> record, I'll add both that and the content size concern to the Issues  
> List.

Thanks.

Cheers
Kon