Subject: [Rmt] Expires attribute in FLUTE FDT

From: "Mark Watson" <[email-masked]>
Date: Fri, 16 Jun 2006 16:07:01 -0700

All,

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.

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 ?

Best regards,

Mark Watson

Digital Fountain

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

---

From: Vincent Roca <[email-masked]>
Date: Tue, 20 Jun 2006 12:54:46 +0200

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

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

---

From: <[email-masked]>
Date: Thu, 22 Jun 2006 16:28:23 +0300

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,
>
>> headers, which would suggest a format for Expires of e.g. 
>"Thu, 01 Dec
>> 1994 16:00:00 GMT" for this string (See 
>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.
>" o The FDT Instance root element 'FDT-Instance' MUST contain 
>an 'Expires' attribute with a valid Network Time Protocol 
>(NTP) time value."
>Therefore if we want to preserve backward compatibility we 
>need to keep this implicit rule and of course clarify the I-D.
>
>(seconds) (called NTP Timestamp/high below). This point must 
>also be clarified.
>
>" * 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.
>
>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.
>
>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).
>