Subject: [Rmt] Two trivial changes to yesterday's FLUTE 05 spec.

From: [email-masked]
Date: Thu, 13 Nov 2003 22:46:59 +0200

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