RE: Question on EXT_CENC in draft-ietf-rmt-flute-revised

Given that ALC can in fact be used to send "bounded/discrete" objects 
aka files, it is clear to me that as long as the sender uses ALC to 
send such objects, CENC is as applicable to ALC as it is to FLUTE.

I don't see the related specification as a difficult endeavor at all.

As to requirements and use cases, I can talk about other standards 
bodies' specifications that use ALC for file transfer, but I think we 
don't need to really get to that debate, as we have a clear notion of 
sending files via ALC already and specifying CENC for that makes perfect sense.

Lakshminath

At 02:36 AM 10/25/2006, [email protected] wrote:
>Hi All
>
>Interesting question and worth a little thought.
>
>I guess no one has implemented this for generic ALC objects, so it's
>rather less mature a feature than a standards track FLUTE would merit
>(experimental FLUTE already had 4 genetically different implementations
>ran against each other prior to the experimental RFC - maybe more like
>DS than EXP, but it certainly improved the spec enormously). Considering
>what is ALC and what is FLUTE, it seems that generic ALC CENC wouldn't
>be trivial in practice - now the long winded ("first Rod RMT email in
>ages") bit...
>
>With only a cursory look, ALC CENC seems harmless, though it lacks a
>driving use case. (Pretty much what Vincent emailed).
>
>For files (the interesting transport objects :), FDT description of
>field CENC was the right level of flexibility without too much
>complexity or else too much overhead. This was discussed in the early
>days of FLUTE (initially FDALC) and probably there will be some email
>references to this in the 2002/3/4 time frame. The FDT encoding CENC was
>added later as a compromise to avoid the less desirable alternative of a
>hierarchy of FDT descriptions. Specifically for reliable multicast
>_file_ delivery, FLUTE is the right tool and CENC data is available in
>FDTs for that. (As a side note, 3GPP-MBMS specifies not to use the CENC
>header at all - i.e. no CENC for FDTs).
>
>OTOH, ALC provides general "object" transfer with no particular bounds,
>making it as applicable to "stream objects" as it is to
>"bounded/discrete objects" (the latter being an interchangeable
>pseudonym for "files" with FLUTE). Which means that a file-based
>encoding (e.g. gzip) applied generally to ALC without exclusive profiles
>would be flawed. Some kind of "pseudo-file" structure would be needed
>(e.g. breaking ALC objects into blocks and performing CENC on those,
>although not all FEC codes would block and then symbol -> direct to
>symbol is perfectly acceptable). So some design issues would need
>addressing and maturing from a few different perspectives.
>
>Since FLUTE is the file delivery profiling of ALC, I wouldn't recommend
>embarking on an "oboe" or "panpipe" adventure or something of that
>nature to have a redundant FLUTE-clone. Given the 4 year brewing time of
>FLUTE and the amount of RMT input (which has now subsided), that would
>be a bit masochistic (contrary to the spectator perspective, developing
>FLUTE has been a royal pain on more than one occasion).
>
>Dondeti, do you have a non-file/non-discrete-object use case for ALC
>CENC? There's quite a lot of use case and technical problem solving
>mileage needed before I'm convinced a FLUTE->ALC switch is a good idea.
>Taking a leaf out of the IPv6 manual, it seems to be neither of
>"necessary and sufficient".
>
>(At this rate, I guess my next "new thread mailing" to RMT comes around
>February - great Christmases to one and all :)
>
>Cheers, Rod.
>
>(PS Magnus, worry not, I throw some brain time on FLUTE security before
>the snow ;)
>
>
> >-----Original Message-----
> >From: ext Lakshminath Dondeti [mailto:[email protected]]
> >Sent: 18 October, 2006 11:39
> >To: Vincent Roca
> >Cc: Charles Lo; [email protected]
> >Subject: Re: [Rmt] Question on EXT_CENC in draft-ietf-rmt-flute-revised
> >
> >
> >At 03:57 AM 10/9/2006, Vincent Roca wrote:
> >>Hello Lakshminath,
> >>
> >>>I have a question on EXT_CENC specified in
> >>>draft-ietf-rmt-flute-revised.  As per the draft, the header
> >extension
> >>>is "ALC PI Specific."  The question I have is whether the extension
> >>>can be used for any ALC object.  If not, how is content
> >encoding of an
> >>>ALC object signaled?
> >>
> >>In the FLUTE context, EXT_CENC is only meant to specify the
> >(optional)
> >>encoding of an FDT Instance. If an object (that is not an FDT
> >Instance)
> >>carried in a FLUTE session is to be content encoded, then
> >it's signaled
> >>in the "Content-Encoded" attribute of the associated file element in
> >>the FDT Instance. You'll find an example in Appendix B.
> >>
> >>If ALC is used by an application that is not FLUTE, then it's unclear
> >>to me whether EXT_CENC can be used or not for any ALC object
> >or not...
> >>I don't see any good reason to prevent it, though.
> >>Maybe it would be good to move it's definition to the ALC I-D
> >and make
> >>clear in the FLUTE I-D that in this context it is restricted
> >to an FDT
> >>Instance. Opinion?
> >
> >Thanks Vincent.  I think so too.  Let's move it into the ALC
> >i-d and make the appropriate references and clarifications in
> >the FLUTE i-d.
> >
> >Perhaps the editors of those i-ds can incorporate this change
> >in the next revisions?  Are the drafts being revised for the
> >coming IETF meeting?  Thanks in advance to the editors for
> >their work on this.
> >
> >best,
> >Lakshminath
> >
> >>Cheers,
> >>
> >>    Vincent
> >>
> >>_______________________________________________
> >>Rmt mailing list
> >>[email protected]
> >>https://www1.ietf.org/mailman/listinfo/rmt
> >
> >
> >_______________________________________________
> >Rmt mailing list
> >[email protected]
> >https://www1.ietf.org/mailman/listinfo/rmt
> >
>
>_______________________________________________
>Rmt mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/rmt