Re: Expires attribute in FLUTE FDT

Hello Mark and Rod,

> - the syntax description below needs to be directly connected to the "Expires" attribute - at the moment it just says '...expressed within the FDT Instance...'
>   
Yes, adding the "Expires" keyword at the place where this field is 
defined avoids
any confusion.

> - absolutely we need to say 'decimal' - there are an infinite number of ways of representing a "32-bit unsigned integer" within a "string" field and a large (though finite) number of those are actually practical and used in real protocols. So presently it is rather ambiguous.
>
> I would reword the section from 3.3 as follows:
>
> 	"An FDT Instance is valid until its expiration time.  The
>       expiration time is expressed within the FDT Instance "Expires"
>       attribute as a 32 bit unsigned integer in decimal notation.  The value
>       of the data field represents the 32 most significant bits of a 64 bit
>       Network Time Protocol (NTP) [5] time value.  These 32 bits provide an
>       unsigned integer representing the time in seconds relative to 0 hours
>       1 January 1900."
>   
Okay, except for the requirement to use NTP which can be discussed (see 
below).


Rod, you say:
> PS Note, FLUTE does not assume that the sender is time synchronised, and wall clock time is fine. I believe 3GPP, DVB and OMA profiling of FLUTE applications describes system time synchronisation (e.g. SNTP use in 3GPP-MBMS).
>   
No. Since it is said that the "Expires" field contains the upper 32 bits 
of the NTP time value,
then the sender __must__ be synchronized (at least loosely). It's quite 
different from the text
defining the EXT_TIME SCT extension (draft-ietf-rmt-bb-lct-revised-03):

      "When the SCT-High flag is set, the associated 32 bit time value
      provides an unsigned integer representing the time in seconds of
      the sender's wall clock.  In the particular case where NTP is
      used, these 32 bits provide an unsigned integer representing the
      time in seconds relative to 00:00 hours GMT, January 1st 1900,
      (i.e. the most significant 32 bits of a full 64 bit NTP time
      value)."


In fact, and it was probably the reason why we chose NTP timestamps, a time
synchronization is required between sender and receivers to correctly 
process
the "Expires" field. Using NTP is one possibility (currently the only 
one given
the FLUTE "Expires" text).

If the FLUTE sender wants to use his non-synchronized wall clock time (which
is fine IMHO), then he must add an LCT EXT_TIME/SCT HE in the packet
containing the FDT Instance. This way, a receiver will be able to 
re-synchronize
the FDT Instance expiration date relative to his own (non-synchronized) wall
clock time. Does it make sense or am I still in a "bad day" ;-)

Cheers,

    Vincent