Re: FLUTE revision

Hi Mike&all,

Yes, this is one possibility to signal the FLUTE version for whole FLUTE
session. It still have negative influence on FLUTE version 1 receivers,
which might buffer quite a lot unnecessary data, if the FDT Instance is
not received early enough.

BR,
Jani
> Actually, looking at the FLUTE doc, it seems that the only place where the
> FLUTE version number is carried is in the FDT Instance header EXT_FDT, which
> is an ALC PI specific LCT header extension, i.e., in EXT_FDT there is a
> FLUTE version number that MUST be set to 2.  If this is correct, then it
> seems fine that the version number carried in the LCT header is the ALC
> version number, which is 1.  Comments on this?
> 
> 
> On 1/26/11 12:33 AM, "Luby, Michael" <[email protected]> wrote:
> 
>> Thanks Jani for bringing this to our attention. We will take a look at this.
>> The easiest solution off the top of my head is to specify in the FLUTE draft
>> that the LCT version number in the LCT header MUST be interpreted as the
>> FLUTE version number field (just like what ALC does when it uses LCT).
>> However, we'll look at it more closely.
>> Best, Mike
>>
>>
>> On 1/25/11 11:02 PM, "Jani. Fi" <[email protected]> wrote:
>>
>>> Hi Mike,
>>>
>>> Of course we can/must specify in the text as you mention below. However
>>> in the packet only place to signal the version number is LCT version
>>> number (V) field:
>>>
>>> LCT version number (V): 4 bits
>>>
>>> Indicates the LCT version number.  The LCT version number for this
>>> specification is 1.
>>>
>>> In RFC 5775 it is then mentioned:
>>>
>>> "The version number of ALC specified in this document is 1. The version
>>> number field of the LCT header MUST be interpreted as the ALC version
>>> number field. This version of ALC implicitly makes use of version 1 of
>>> the LCT building block defined in [RFC 5651]."
>>>
>>> This kind of text is missing from the experimental FLUTE RFC and from
>>> the revised FLUTE, but if we want to overload this field with FLUTE
>>> version number (as we have done in our implementation based in
>>> experimental RFC) to enable receivers to distinguish FLUTE versions 1
>>> and 2, the packet is not anymore align with the ALC and LCT RFCs.
>>>
>>> It is also possible to leave this field for ALC/LCT version numbers and
>>> use for example reserved bits or LCT header extension to signal FLUTE
>>> version. All in all, in my opinion it is necessary to signal FLUTE
>>> version 2 somewhere in the FLUTE packet to be backwards compatible with
>>> the receivers based on the experimental FLUTE RFC.
>>>
>>> BR,
>>> Jani
>>>
>>>> Hi Jani,
>>>> I'm missing where the version of FLUTE must be the same as the version of
>>>> ALC and LCT. It seems that if we define this specification to be FLUTE
>>>> version 2, and this FLUTE specification explicitly says that it must be used
>>>> with ALC version 1 as specified in RFC 5775 and that it must be used with
>>>> LCT version 1 as specified in RFC 5651 then there is no ambiguity, but maybe
>>>> I'm missing something?  I think what you are saying is that there is an
>>>> overloaded field that carries both the FLUTE version and the ALC version and
>>>> the LCT version?  If so, can you point to that?
>>>> Mike
>>>>
>>>>
>>>> On 1/25/11 12:51 AM, "Jani. Fi" <[email protected]> wrote:
>>>>
>>>>> Dear RMTers,
>>>>>
>>>>> One side effect of the version number change is problem with ALC and LCT
>>>>> versions. Version number is signalled in the LCT header field and in
>>>>> RFCs 5775 and 5651 (FLUTE revised will be working on top of these RFCs)
>>>>> version number is specified to be 1.
>>>>>
>>>>> So it is not possible to signal FLUTE version 2 and ALC/LCT version 1 in
>>>>> the same header field.
>>>>>
>>>>> BR,
>>>>> Jani
>>>>>
>>>>>> Dear RMTers, We are in the process of revising FLUTE ­11, to produce
>>>>>> FLUTE ­12, and it is clear at this point that the FLUTE version number
>>>>>> will transition from 1 to 2.  One question that has arisen: Can an FDT
>>>>>> instance have a TOI > 0 with an EXT_FDT LCT extension header containing
>>>>>> the FDT Instance ID?  I think it is and should be restricted to TOI = 0
>>>>>> for carrying FDT instances, but there is some ambiguities in the text
>>>>>> here and there that might be construed to suggest otherwise.
>>>>>> Mike  
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Rmt mailing list
>>>>>> [email protected]
>>>>>> https://www.ietf.org/mailman/listinfo/rmt
>