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