Hi Rod,
My team and I tried to track down through all the SDOs whether or not there
is an issue wrt these inconsistencies in the past, and it consumed a lot of
time and was inconclusive, and we don't have the time to keep digging.

There is this potential inconsistency, and possibly others.  Even if these
potential inconsistencies can be "resolved" (by checking every existing SDO
spec and ensuring that they don't use any of the incompatible features of
RFC3926/RFC3451, and then also making sure that SDOs are not in the process
of standardizing on any incompatible features from RFC3926/RFC3451), to
obtain compatibility there would still have to be RMT-wg consensus to remove
a potentially important capability from FLUTE revised to make it backwards
compatibility (remove the feature to allow future extensions to the FDT
instance without having to flip the version yet again, as pointed out by
Jani below).

So, what is the downside of allowing the FLUTE version to be 2?  I haven't
heard anything about that recently.
Best, Mike  


On 2/7/11 1:04 AM, "Rod Walsh" <rod.walsh@nokia.com> wrote:

> So there's also a systematic problem with LCT version numbers. Ouch!
> 
> The updated EXT_TIME isn't a problem generally (old client from a new server
> will see that no SCT is set and ignore the new header, new client from an old
> server will ignore the old header and there would be no new extension included
> anyway). However, if an instance of LCT demanded that clients/receivers use
> SCT, then we have a problem. Do we know of any such cases?
> 
> I spotted just one SCT reference in old flute, that makes a requirement that
> is inevitably fulfilled in new flute (FDT expiry > SCT, =0 in new flute). So
> maybe this is a non-issue for FLUTE.
> 
> Did anyone check against the host of SDOs if EXT_TIME use is forbidden,
> allowed or mandated in their adoption of LCT?
> 
> What are the other LCT or ALC same version incompatibilities?
> 
> Cheers, Rod.
> 
> 
> On 7 Feb 2011, at 10:21, "ext Luby, Michael" <luby@qualcomm.com> wrote:
> 
>> 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
>>