Re: [Rmt] FLUTE revised 12

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