Re: Question on EXT_CENC in draft-ietf-rmt-flute-revised
Lakshminath Dondeti <[email protected]>
| Newsgroups | gmane.ietf.rmt |
|---|---|
| Message-ID | <[email protected]> |
Hi Vincent, Thanks for sharing your thoughts on this. Like I noted in my earlier emails on this topic, it makes perfect sense to move CENC support to ALC. The drafts are "open" at the moment and it appears like we have the window of opportunity to make the change to address some of the use cases you list, and also to make the generic applicability of CENC to ALC objects feasible. As you say, I don't see how the spec work related to this can be complex. We may have to put some notes saying not all encodings are applicable to all types of objects, but that I am sure is not a big issue really! regards, Lakshminath At 07:15 AM 10/25/2006, Vincent Roca wrote: >Hello Rod, > >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 >objects. > >Concerning the applications that could benefit from this ALC >level CENC: >(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, >who knows? >(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 >might miss something.. > >Cheers, > > Vincent