Re: Question on EXT_CENC in draft-ietf-rmt-flute-revised
Vincent Roca <vincent.roca <at> inrialpes.fr>
2006-10-25 14:15:18 GMT
It seems to me that the main benefit of moving CENC to ALC is to
clarify and rationalize things when it's still feasible.
Since object encoding can potentially be required by any application
built on top of ALC (FLUTE being one of them), no matter whether
it is applied to "stream objects" or "bounded/discrete objects", it's
not a bad idea to leave the door open. Of course, with "stream
objects" a gzip encoding is meaningless as you say, but one can
probably find another encoding for these objects (even if I don't
have one in mind). An ALC CENC mechanism can be made
sufficiently flexible so that we do not restrict its use to bounded
Concerning the applications that could benefit from this ALC
(1) they already exist, our simple and stupid FCAST file
transfer application being one of them. Even if there's currently
no need to standardize it, there are use cases where it's sufficient.
Why should I use a more complex application then? If an
ALC CENC exists, then FCAST would be able to (e.g.) gzip big
files on the fly. And there are perhaps other similar applications,
designed outside of the RMT group, that have the same needs,
(2) there are probably ALC use-cases we can't even imagine today
that would need it. Perhaps Lakshminath has one of them in mind...
Even if it's not the case, I'd prefer not to close this door today.
And I don't think it's a tough work to move the text, even if I