Subject: Updated FLUTE 06 (Was: [Rmt] Two trivial changes to yesterday's FLUTE 05 spec.)

From: [email-masked]
Date: Fri, 14 Nov 2003 11:56:42 +0200

Dear RMT folks,

One of the FLUTE authors (Rami Lehtonen) found four minor issues with FLUTE 05.

-Version number to be changed to 4 bits (as used usually, for example in ALC)
-Version number scheme to be changed. For FLUTE version 1 the field will use value '1' instead of '0'.
-The FLUTE 05 had a typo in in chapter 3.4.3. In the figure, the field "FDT instance ID" 
 should be replaced with "reserved" text
-Explicitely state that when EXT_COMP header is used, it is used together with a proper FDT instance header.
 (Actually, this was implicit in the document. However, making it explicit makes text specification clearer=

I took time and typed the final adjustements in; please find document FLUTE 06 attached. 
I will now proceed to submit the draft to I-D queue.

After that I certainly feel that FLUTE 06 is ready for WGLC. 

Best Regards,
 Toni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> [email-masked]
> Sent: 13 November, 2003 22:47
> To: [email-masked]
> Subject: [Rmt] Two trivial changes to yesterday's FLUTE 05 spec.
> 
> 
> Dear RMT folks,
> 
> I got two last minute comments directly after sending FLUTE -05 out.
> I think both comments are valid and make FLUTE even more usable.
> 
> (1.) The version of FLUTE should be signalled in EXT_FDT to enable 
>      forward extensibility some day. The field enables receivers
>      quickly and with low resource consumption to determine whether 
>      it can or cannot understand the protocol version.
> 
> (2.) The FLUTE specification should allow use of optional compression
>      for the FDT Instance Payload. The compression should be a new
>      optional header extension that may be applied to FDT Instances. 
> 
> Implementing the changes is very straightforward.
> The changes needed are:
> 
> -----------
> Change (1.)
> -----------
> 
> Old text:
> "
> 3.4.1 Format of FDT Instance Header
> 
>    FDT Instance Header (EXT_FDT) is a new fixed length, ALC 
> PI specific
>    LCT header extension [4]. The Header Extension Type (HET) for the
>    extension is 192. Its format is defined below:
> 
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   HET = 192   |              FDT Instance ID                  |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>    FDT Instance ID, 24 bits:
> 
>    For each file delivery session the numbering of FDT 
> Instances starts
>    from '0' and is incremented by exactly one for each subsequent FDT
>    Instance. After reaching the maximum value (2^24-1), the numbering
>    starts again from '0'. When wraparound from 2^24-1 to 0 
> occurs, 0 is
>    considered higher than 2^24-1. Receiver handling of wraparound and
>    other special situations (for example, missing FDT Instance IDs
>    resulting in longer increments than one) is left out of this
>    specification to individual implementations of FLUTE.
> "
> 
> 
> New text:
> "
> 3.4.1 Format of FDT Instance Header
> 
>    FDT Instance Header (EXT_FDT) is a new fixed length, ALC 
> PI specific
>    LCT header extension [4]. The Header Extension Type (HET) for the
>    extension is 192. Its format is defined below:
> 
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   HET = 192   | V |            FDT Instance ID                |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    
>    Version of FLUTE, 2 bits:
>    
>    This document specifies FLUTE version 1. Hence in any ALC packet 
>    that belongs to the file delivery session as specified in 
> this specification 
>    MUST set this field to '0'.
> 
>    FDT Instance ID, 22 bits:
> 
>    For each file delivery session the numbering of FDT 
> Instances starts
>    from '0' and is incremented by exactly one for each subsequent FDT
>    Instance. After reaching the maximum value (2^22-1), the numbering
>    starts again from '0'. When wraparound from 2^22-1 to 0 
> occurs, 0 is
>    considered higher than 2^22-1. Receiver handling of wraparound and
>    other special situations (for example, missing FDT Instance IDs
>    resulting in longer increments than one) is left out of this
>    specification to individual implementations of FLUTE.
> "
> 
> 
> -----------
> Change (2.)
> -----------
> 
> New section 3.4.3:
> 
> "
> 3.4.3 Compression of FTD Instances
> 
>    The FDT Instance payload MAY be compressed. This 
> specification defines
>    FDT Instance Compression Header (EXT_COMP). EXT_COMP is a 
> new fixed length, 
>    ALC PI specific LCT header extension [4]. The Header 
> Extension Type (HET) 
>    for the extension is 193. If the FDT Instance payload is 
> compressed, 
>    the EXT_COMP MUST be used to signal the compression type. 
>    In that case, EXT_COMP header extension MUST be used in 
> all ALC packets 
>    carrying the same FDT Instance ID. Within a file delivery 
> session, both 
>    uncompressed and compressed FDT Instances MAY appear. If 
> compression is not 
>    used for a given FDT Instance, the EXT_COMP MUST NOT be 
> used in any packet 
>    carrying the FDT Instance ID. The format of EXT_COMP is 
> defined below:
> 
>     0                   1                   2                   3
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |   HET = 193   |     Comp      |        Reserved               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    
>    Compression algoritm (Comp), 8 bits:
>    
>    This field signals the compression algrorithm used in the 
> FDT Instance 
>    payload. The definition of this field is outside the scope of this 
>    specification. Applicable compression algorithms include, 
> for example,
>    Zlib [Ref RFC 1950], DEFLATE [Ref RFC 1951] and Gzip [Ref 
> RFC 1952].
>    
>    Reserved, 16 bits:
> 
>    This field MUST be set to all '0'.
> "
> 
> In addition, I will add three Informational References 
> (RFC-1950, RFC-1951 and RFC-1952).
> 
> Fortunately I did not submit FLUTE 05 to I-D queue yesterday.
> Thus, will implement the changes above to the draft I sent
> on the RMT mailing list yesterday. Consequently, I will submit 
> updated FLUTE 05.
> 
> If you agree, it would be great to have working group last call on 
> the draft immediately to move it to an Experimental RFC.
> 
> 
> Best Regards,
>   Toni
>