Re: FLUTE revision

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
>