Re: [Rmt] FLUTE revised 12

Hi Mike

Jani nailed the FDT question. (By definition, flute delivers discrete media objects - files - and so there immeasurable ways to extend FLUTE by using specific mime type files, dedicating TOIs to specific purposes and other out-of-the-scope-of-this-document add-ins. Thus, I guess that modifying the FDT schema in a non backwards compatible manner was an error of process which we need to correct. Otherwise, the RMT achievement of making a single IETF defined multicast file delivery protocol common across all relevant SDOs would be laid to waste, which is clearly against the goal of the RMT revised documents.)

The other essential thing is that, as far as I can work out, all the other flute-revised modifications _are_ backwards compatible. If I didn't miss something, then the undefined extra elements extension feature in FDTs seems insufficient reward to break backwards compatibility.

As for changes upstream (alc/lct), they both remain both backwards compatible and version 1 - right?

Cheers, Rod.

On 7 Feb 2011, at 08:51, "ext Jani Peltotalo" <jani.peltotalo@tut.fi> wrote:

> Hi Mike,
> 
> Rod's main question is why the FDT Instance XML schema is modified. All
> other changes are backwards compatible, since LCT and ALC version
> numbers are not changed.
> 
> An FDT instance according to the old schema can look like below:
> 
> <FDT-Instance Expires="3506420475">
>   <File TOI="1"
>      Content-Location="file:///home/user/RFCs/rfc5775.txt"
>      Content-Length="59518"
>      Content-MD5="7UxYyGyH2m8csPm2opRDJw=="
>      FEC-OTI-FEC-Encoding-ID="0"
>      FEC-OTI-Maximum-Source-Block-Length="64"
>      FEC-OTI-Encoding-Symbol-Length="1428"/>
> </FDT-Instance>
> 
> An according to the new schema it is possible to also have other
> elements inside FDT-Instance, like below:
> 
> <FDT-Instance Expires="3506420475">
>   <File TOI="1"
>      Content-Location="file:///home/user/RFCs/rfc5775.txt"
>      Content-Length="59518"
>      Content-MD5="7UxYyGyH2m8csPm2opRDJw=="
>      FEC-OTI-FEC-Encoding-ID="0"
>      FEC-OTI-Maximum-Source-Block-Length="64"
>      FEC-OTI-Encoding-Symbol-Length="1428"/>
>   <Some-Extension foo="bar"/>
> </FDT-Instance>
> 
> This new FDT Instance will be discarded by the old receivers, since
> there is no information what to do with unknown elements. So is there
> really need for this extension? In the old schema it is possible to have
> private attributes, but not private elements.
> 
> BR,
> Jani
>> Hi Rod,
>> A good place to start is to look at section 11, the change log.  A lot of the changes were across the different specs (ALC & LCT and FEC BB), moving the functionality around from FLUTE to LCT or ALC, etc.  These changes are really difficult to undo the already existing revised RFCs for LCT, ALC and FEC BB.  Also, some XML changes, etc.
>> 
>> What is your main concern with having this be FLUTE version 2 instead of FLUTE version 1?
>> Best, Mike
>> 
>> 
>> On 2/6/11 10:52 AM, "Rod Walsh" <rod.walsh@nokia.com> wrote:
>> 
>> Hi all
>> 
>> Do we have an answer on the question: why is a non-backwards compatible FDT schema necessarily?
>> 
>> (I.e. I am concerned that the right path forward might be to discard changes which remove backwards compatibility, and so far we are collectively ignoring this elephant in the room. What did I miss?)
>> 
>> Cheers, Rod.
>> 
>> 
>> 
>> On 4 Feb 2011, at 17:40, "ext Luby, Michael" <luby@qualcomm.com> wrote:
>> 
>> David, Other RMTers,
>> 
>> There is now version 12 of FLUTE revised available as an Internet Draft.  The major change in version 12 compared to version 11 is to change the FLUTE version number from 1 to 2.  This was changed in all the references to the FLUTE version, and there is wording added to Section 3.1 on the requirements around the FLUTE version number in operation for both senders and receivers.  Also, the FLUTE version number is added as an optional parameter in Section  6.  The change log in Section 11 is also updated.  There are also a few grammatical fixes/improvements/clarifications.
>> 
>> I would like to thank Don Gillies for spending the time and enthusiastically getting up to speed on FLUTE (and also ALC and LCT and FEC BB) in a detailed way and helping to carefully craft the changes in this late stage draft, he did a wonderful job (and in the final RFC he should be thanked in the acknowledgements for his contributions).  However,  I take complete responsibility for all errors or issues that are introduced into this version 12 from version 11.  (So, read it over carefully and make sure that it is ok, etc.).
>> 
>> Thanks, Mike
>> _______________________________________________
>> Rmt mailing list
>> Rmt@ietf.org
>> https://www.ietf.org/mailman/listinfo/rmt
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Rmt mailing list
>> Rmt@ietf.org
>> https://www.ietf.org/mailman/listinfo/rmt