Subject: RE: [Rmt] Expires attribute in FLUTE FDT

From: "Mark Watson" <[email-masked]>
Date: Thu, 22 Jun 2006 09:57:19 -0700

Rod,

Ok, I didn't spot that. To be unambiguous, though, we need to add the following:
- the syntax description below needs to be directly connected to the "Expires" attribute - at the moment it just says '...expressed within the FDT Instance...'
- 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."

Regards,

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, June 22, 2006 6:28 AM
To: [email-masked]; Mark Watson
Cc: [email-masked]
Subject: RE: [Rmt] Expires attribute in FLUTE FDT

Hi Guys

You are probably looking at §3.4.2 and expecting some mention of syntax around here "...The "FDT-Instance" element MUST contain "Expires" attribute, which tells the expiry time of the FDT Instance..." 

However, a quick "NTP" keyword search will bring you to §3.3 and this snippet of text...
"     An FDT Instance is valid until its expiration time.  The
      expiration time is expressed within the FDT Instance payload as a
      32 bit data field.  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."

The schema (§3.4.2) shows a string, so populating the sting with unsigned 32 bit integer (decimal) exactly as it would be in a NTP stamp is straight forward. It was never an issue in the interoperability tests. 

I guess that's as unambiguous as it gets. Do we need to add the word "decimal"?

It's always been these most significant 32 bits of an NTP timestamp. In the very inception of FLUTE and FDTs Pekka and I argued for an XML timestamp ("dateTime") due to flexibility and human readability. The NTP stamp is easier parsing, is more concise and was simply there first. I don't have a good enough academic reason to change it, and certainly at this stage there are plenty of SBO-co-ordination and commercial implementation reasons to leave it as it is.

If Mark and Vincent were not simply having bad days, then there's reason to add some redundant text to clarify this point. I would guess to §3.4.2, but it's probably better if someone having a good day and still confused proposes some minimal text in what they think is the best place. (Note, the related §3.3 text should be left as-is).

Cheers, Rod.

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).

>-----Original Message-----
>From: ext Vincent Roca [mailto:[email-masked]] 
>Sent: 20 June, 2006 13:55
>To: Mark Watson
>Cc: [email-masked]
>Subject: Re: [Rmt] Expires attribute in FLUTE FDT
>
>Hello Mark,
>
>> It appears that the syntax of this attribute is not specified in 
>> either RFC 3926 or draft-itef-rmt-flute-revised-01 except to 
>say that 
>> it is a string.
>>
>> This is something of an omission.
>
>Oups, that's incredible but you're right!
>
>> The general approach and indeed recommendation in the FLUTE spec is 
>> that FDT attributes use the same syntax as their eponymous HTTP 
>> headers, which would suggest a format for Expires of e.g. 
>"Thu, 01 Dec
>> 1994 16:00:00 GMT" for this string (See 
>> <http://www..ietf.org/rfc/rfc2616.txt section 14.21
>> <http://www.ietf.org/rfc/rfc2616.txt%20section%2014.21>>)
>>
>> However, this doesn't align with the examples in FLUTE or the 
>> draft-mehta-rmt-flute-iop-05, which show a decimal number, 
>presumably 
>> an NTP timestamp.
>>
>> Suggestions ?
>
>Let's analyze the pro/cons.
>
>In favor of an NTP timestamp:
>---------------------------------------
>
>1- Current practice (implementations) and example (FLUTE RFC 
>and I-D) suggest using the upper 32 bits (seconds since 
>January1st, 1900) of an NTP timestamp.
>Additionally the FLUTE Interop I-D says:
>" o The FDT Instance root element 'FDT-Instance' MUST contain 
>an 'Expires' attribute with a valid Network Time Protocol 
>(NTP) time value."
>BTW this is certainly not the place where this should be specified!!!
>Therefore if we want to preserve backward compatibility we 
>need to keep this implicit rule and of course clarify the I-D.
>
>Note that this is not the full 64 bit NTP timestamp, but only the upper
>32 bits
>(seconds) (called NTP Timestamp/high below). This point must 
>also be clarified.
>
>2- the FLUTE document says (section 3.3):
>" * A sender MUST use an expiry time in the future upon 
>creation of an FDT Instance relative to its Sender Current Time (SCT)."
>The "EXT_TIME/SCT high" information is a 32 bit time value. 
>Since the expiry time is defined relative to the EXT_TIME/SCT, 
>it seems wise to keep the same meaning and format for the 
>"Expires" field.
>
>A difference though is that EXT_TIME/SCT contains the sender's 
>wall-clock time, not necessarily an NTP timestamp. Do we need 
>to mandate the fact that Expires is an NTP timestamp or be 
>more liberal? That's a topic that we need to clarify too.
>
>3- an NTP timestamp/high is easy to process at both ends. E.g. 
>a sender retrieves the "UNIX" current time (assuming he is NTP 
>synchronized), adds the desired FDT Instance duration in 
>seconds (plus the UNIX to NTP offset) and that's it.
>The same is true for receivers. No need to go through "textual 
>date to integer"
>conversion.
>
>In favor of HTTP like textual dates:
>---------------------------------------------
>
>4- NTP timestamps are not readable at all;
>
>5- NTP timestamps are not in line with the general HTTP 
>philosophy that FLUTE follows.
>
>
>An alternative could be to enable HTTP-Date format __in 
>addition to__ NTP Timestamp/high. Since HTTP-Date format 
>begins with a "weekday"
>letter, this format can easily be distinguished from the NTP 
>timestamps/high format which begins with a digit.
>A drawback is that it adds some more complexity to a protocol 
>which, all in all, is already rather complex.
>
>I am in favor of either for the NTP timestamp/High format, or 
>for the dual representation.
>
>
>Cheers,
>
>Vincent
>
>NB: BTW Mark, can you remove the SCT/ERT fields from the Fig. 
>1, Default LCT header format (draft-ietf-rmt-bb-lct-revised-03.txt).
>
>_______________________________________________
>Rmt mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rmt
>

_______________________________________________
Rmt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rmt

---

From: Vincent Roca <[email-masked]>
Date: Fri, 23 Jun 2006 10:37:44 +0200

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.

>       unsigned integer representing the time in seconds relative to 0 hours
Okay, except for the requirement to use NTP which can be discussed (see 
below).

> 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 (…
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