All,

Here is an example of what I think causes an issue.  The LCT header changed
between RFC3451 and RFC5651.  In RFC3451 there is the T and R fields in bits
12, 13 of the LCT header, that indicates the presence of sender current time
and expected residual time, respectively, in the LCT header.  In RFC5651
these fields MUST be set to zero and MUST be ignored by receivers (and
instead there are EXT_TIME extension headers that can convey this
information). Thus, RFC5651 is not backwards compatible with RFC3451, even
though both have LCT version 1.

FLUTE RFC3926 says to use RFC3451.  FLUTE revised says to use RFC5651.
There are some standards bodies that have specified using FLUTE RFC3926 with
LCT RFC5651, and these standards bodies might be backwards compatible with
using FLUTE revised with LCT5651 in at least this aspect (not sure about
others), but anybody who uses FLUTE RFC3926 with LCT RFC3451 as specified in
FLUTE RFC3926 will not be compatible with FLUTE revised with LCT5651.

There might be other examples as well.

Mike




On 2/6/11 11:57 PM, "Rod Walsh" <rod.walsh@nokia.com> wrote:

> 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