RE: Expires attribute in FLUTE FDT

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 protected] [mailto:[email protected]] 
Sent: Thursday, June 22, 2006 6:28 AM
To: [email protected]; Mark Watson
Cc: [email protected]
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 protected]] 
>Sent: 20 June, 2006 13:55
>To: Mark Watson
>Cc: [email protected]
>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 protected]
>https://www1.ietf.org/mailman/listinfo/rmt
>