Subject: [core] #6: Date option text needs update

From: "core issue tracker" <[email-masked]>
Date: Fri, 11 Jun 2010 09:58:07 -0000

#6: Date option text needs update
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  Cullen Jennings <fluffy@…>        
     Type:  defect              |      Status:  new                               
 Priority:  trivial             |   Milestone:                                    
Component:  coap                |     Version:                                    
 Severity:  -                   |    Keywords:                                    
--------------------------------+-------------------------------------------
 Fix the text of the date option and simplify it.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/6>
core <http://tools.ietf.org/core/>

---

From: "core issue tracker" <[email-masked]>
Date: Wed, 30 Jun 2010 08:46:48 -0000

Priority:  trivial             |   Milestone:  coap-01                           
Changes (by zach@…):

  * milestone:  => coap-01

Comment:

 - The current text is a bit too complex and has three different lengths.
 Current text below, how can we make this a single length? Could someone
 spin some text? Here is the current text:

 {{{

 3.2.5.  Date Option

    The Date Option indicates the creation time and date of a given
    resource representation.  It MAY be used in response and notify
    messages.  The integer value is the number of seconds, after midnight
    UTC, January 1, 1970.  This time format cannot represent time values
    prior to January 1, 1970.  The latest UTC time value that can be
    represented by a 31 bit integer value is 03:14:07 on January 19,
    2038.  Time values beyond 03:14:07 on January 19, 2038, are
    represented by 39 bit integer values which is sufficient to represent
    dates that should be enough for anyone.  For applications requiring
    more accuracy, a 48-bit integer MAY be included representing this
    value in milliseconds instead of seconds.

 }}}

 - And a more extreme question, do we really need a Date Option at all in
 CoAP? Most constrained devices do not keep absolute time.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/6#comment:1>
core <http://tools.ietf.org/core/>

---

From: "Stuber, Michael" <[email-masked]>
Date: Wed, 30 Jun 2010 06:42:49 -0700

Do we need use 1970 as the basis for Epoch?  I realize it's traditional, but it seems to me were giving up over 1.2 billion seconds worth of bits worrying about the past -- more than 1/2 the space available in 31 bits.  If we are going to include a date option, we should seriously consider basing it on a new epoch, such as 2010/1/1 or 2000/1/1.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> core issue tracker
> Sent: Wednesday, June 30, 2010 1:47 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [core] #6: Date option text needs update
> 
> --------------------------------+---------------------------------------
> --------------------------------+----
> --------------------------------+---------------------------------------
> --------------------------------+----
> Changes (by zach@…):
> 
>   * milestone:  => coap-01
> 
> 
> Comment:
> 
>  - And a more extreme question, do we really need a Date Option at all
> in  CoAP? Most constrained devices do not keep absolute time.
> 
> --
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Peter Bigot <[email-masked]>
Date: Wed, 30 Jun 2010 09:23:08 -0500

I think dropping the Date option is a sound choice; it eliminates all sorts
of problems with inappropriate cross-device time comparisons, as well as
time zone and leap second maintenance and the implied existence of a
real-time clock.  The value of knowing when a message was formatted doesn't
seem very high (unlike the value of knowing when a particular observation
took place: but that's content, not header).

Times based on the POSIX epoch should be familiar to most people using
Internet protocols.  If a date option is preserved, I think we should have a
good reason for selecting a non-standard epoch that will require special
code to convert to something useful (as it is now, a developer can just use
ctime(3)).

Peter

On Wed, Jun 30, 2010 at 8:42 AM, Stuber, Michael
<[email-masked]>wrote:

> Do we need use 1970 as the basis for Epoch?  I realize it's traditional,
> but it seems to me were giving up over 1.2 billion seconds worth of bits
> worrying about the past -- more than 1/2 the space available in 31 bits.  If
> we are going to include a date option, we should seriously consider basing
> it on a new epoch, such as 2010/1/1 or 2000/1/1.
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 30 Jun 2010 23:39:56 +0200

On Jun 30, 2010, at 16:23, Peter Bigot wrote:

> special code to convert

Here is my public domain implementation of converting UTC epoch 2010-01-01 to epoch 1970-01-01:

t += 1262304000;

I think most people can figure out the inverse if we write this into the spec :-)

I agree that date representation is not an easy problem to handle right, but the amount of code for handling different epochs may not the limiting factor here.

Adding 40 years to the lifetime of the 32-bit version just postpones the problem.  
Until 2146, that is (assuming an unsigned 32-bit value, which is what we have elsewhere in the protocol), or at least until 2078 (signed 32-bit).

On the other hand: 
The date of a resource can be in the past.
There are very few resources on the Web that date before 1970-01-01, but many before 2010-01-01.

$ curl -I http://www.ietf.org/rfc/rfc2429.txt
HTTP/1.1 200 OK
Date: Wed, 30 Jun 2010 21:13:05 GMT
Server: Apache/2.2.4 (Linux/SUSE) mod_ssl/2.2.4 OpenSSL/0.9.8e PHP/5.2.6 with Suhosin-Patch mod_python/3.3.1 Python/2.5.1 mod_perl/2.0.3 Perl/v5.8.8
Last-Modified: Fri, 09 Oct 1998 22:01:08 GMT             <===========
ETag: "1caecdd-a89e-59363100"
Accept-Ranges: bytes
Content-Length: 43166
Vary: Accept-Encoding
Content-Type: text/plain

Since CoAP can be gatewayed into HTTP both ways, and might be added to systems that exist today, we should have a good answer on what to do with these old dates.

Fortunately, most of the applications of dates in CoAP itself can live with the inaccuracy introduced by leap seconds, so maybe we don't have to distinguish between monotonic time (TAI) and wall clock time (UTC).

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Wed, 30 Jun 2010 17:00:17 -0500

I recently moved, and my copy of Fielding's dissertation is in a box
somewhere, so a clarification please:

I read "creation time and date of a given resource representation"
literally, so that (for example) if I have a temperature sensor that I
sample every five minutes, when I respond to a request to get that resource
in a particular format (json or xml), I create the representation and set
the date to when I created that json or xml representation---not when I
collected the sample (which is either the resource, or an instance of the
resource, or something else that isn't the representation of the resource).

Similarly, if I have to flush a cache and subsequently need to recreate a
representation of a resource with the same value, I would have used the
current date/time on that fresh representation.

Is the date option intended to instead provide some resource-specific date
concept like Last-Modified?  If so, the description of the option needs to
be changed.

And/or the technical term "resource representation" needs to be clearly
defined somewhere.

Peter

On Wed, Jun 30, 2010 at 4:39 PM, Carsten Bormann <[email-masked]> wrote:

> I agree that date representation is not an easy problem to handle right,
> but the amount of code for handling different epochs may not the limiting
> factor here.
>
> Until 2146, that is (assuming an unsigned 32-bit value, which is what we
> have elsewhere in the protocol), or at least until 2078 (signed 32-bit).
>
> On the other hand:
> Server: Apache/2.2.4 (Linux/SUSE) mod_ssl/2.2.4 OpenSSL/0.9.8e PHP/5.2.6
> with Suhosin-Patch mod_python/3.3.1 Python/2.5.1 mod_perl/2.0.3 Perl/v5.8.8
> Since CoAP can be gatewayed into HTTP both ways, and might be added to
> systems that exist today, we should have a good answer on what to do with
> these old dates.
>
> Fortunately, most of the applications of dates in CoAP itself can live with
> the inaccuracy introduced by leap seconds, so maybe we don't have to
> distinguish between monotonic time (TAI) and wall clock time (UTC).
>
> Gruesse, Carsten
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Jul 2010 01:41:51 +0200

On Jul 1, 2010, at 00:00, Peter Bigot wrote:

> I recently moved, and my copy of Fielding's dissertation is in a box somewhere,

http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm

It is not quite clear to me whether the CoAP Date option wants to be an HTTP Date header (14.18 in 2616, 9.3 in draft-ietf-httpbis-p1-messaging-09.txt) or a Last-Modified header (14.29 in 2616, 6.6 in draft-ietf-httpbis-p4-conditional-09.txt).

I think the latter may have been intended.

Which one/what do we need?  HTTP has both for a reason.  Can we live with just one?  A different one?

Gruesse, Carsten

---

From: Szymon <[email-masked]>
Date: Thu, 01 Jul 2010 09:22:42 +0300

Hi.

I guess we can assume that sensor devices, that will be using CoAP, are 
going to create (measure) resources, not get it from a past, I can not 
imagine a case that sensor device would need date before 2010(?). We 
could say that Date option can not be used for time before 2010, it 
should not do a problem.

How about defining relative date. It would say to a requester how many 
seconds ago (from receiving such a request), resource was updated. It 
could be done by defining Date as a signed integer and whether it is 
less that zero then it is relative. It could solve problem of not 
synchronized clock on sensor devices or of not having such a clock. When 
cashing, proxy could change it into absolute date.

Szymon Sasin

On 1.7.2010 0:39, Carsten Bormann wrote:
> Last-Modified: Fri, 09 Oct 1998 22:01:08 GMT<===========

---

From: Zach Shelby <[email-masked]>
Date: Thu, 1 Jul 2010 09:23:54 +0300

> Which one/what do we need?  HTTP has both for a reason.  Can we live with just one?  A different one?

Or do we need one at all? 

As this seems to be an experimental subject at this point, and I am not really sure if anybody is going to use this in real constrained devices. How about we move the date option out of coap-xx and into coap-misc while we are pondering this? I would like to keep only the options we are really sure about in the base spec. How does that sound?

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297