Hi Folks,
I've looked through Rainer's proposal for a better TIMESTAMP and have
some slight modifications to propose. These are for:
- TIMESTAMP field and formats of TIMESTAMP-3339 and TIMESTAMP-3164
(Rather than 3339-TIMESTAMP.)
- Maximum TIMESTAMP field length of 30 characters (that should give
4 secfrac characters if the rest of the field is maximally filled -
having 5 characters in the offset with a "+"/"-" rather than "Z".)
[I just like bounding these things. :-) ]
- A note about using TIMESTAMP-3339 in syslog-sign packets.
- A note about the concern for the overall length of the packet if
using TIMESTAMP-3339.
Please look this over and send back comments to the list. If this looks
good, then we can ask Jon to place it into the next version of the ID.
---vvv--- Proposed change to Section 2.2 ---vvv---
The TIMESTAMP field is either a timestamp as defined in RFC 3164 denoted
as TIMESTAMP-3164, or as a formalized timestamp as taken from RFC 3339.
A sender SHOULD format the timestamp as a RFC 3339 timestamp described
below as TIMESTAMP-3339. A receiver MUST accept both formats.
The TIMESTAMP-3164 is the local time and is in the format of "Mmm
dd hh:mm:ss" (without the quote marks) where:
Mmm is the English language abbreviation for the month of the
year with the first character in uppercase and the other two
characters in lowercase. The following are the only acceptable
values:
Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
dd is the day of the month. If the day of the month is less than
10, then it MUST be represented as a space and then the number.
For example, the 7th day of August would be represented as "Aug
7", with two spaces between the "g" and the "7".
hh:mm:ss is the local time. The hour (hh) is represented in a
24-hour format. Valid entries are between 00 and 23, inclusive.
The minute (mm) and second (ss) entries are between 00 and 59
inclusive.
The following syntax MUST be used when using a TIMESTAMP-3339. This
is specified using the syntax description notation defined in [ABNF].
date-fullyear = 4DIGIT
date-month = 2DIGIT ; 01-12
date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on
; month/year
time-hour = 2DIGIT ; 00-23
time-minute = 2DIGIT ; 00-59
time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap second
; rules
time-secfrac = "." 1*DIGIT
time-numoffset = ("+" / "-") time-hour ":" time-minute
time-offset = "Z" / time-numoffset
partial-time = time-hour ":" time-minute ":" time-second
[time-secfrac]
full-date = date-fullyear "-" date-month "-" date-mday
full-time = partial-time time-offset
date-time = full-date "T" full-time
RFC 3339 makes allowances for multiple formats for a timestamp to be
used in various cases. This document mandates a single format. The
primary characteristics of TIMESTAMP-3339 used in this document are
as follows.
- the "T" and "Z" characters in this syntax MUST be upper case.
- usage of the "T" character is mandatory. It MUST NOT be replaced by
any other character (like a space character).
- the sender SHOULD include time-secfrac (fractional seconds) if its
clock accuracy permits.
- the entire length of the TIMESTAMP-3339 field MUST NOT exceed 30
characters.
A sample of this format is:
1985-04-12T23:20:50.52Z
This represents 20 minutes and 50.52 seconds after the 23rd hour of
April 12th, 1985 in UTC.
Messages containing Signature Blocks and Certificate Blocks as
described in this document SHOULD use the TIMESTAMP-3339 format in
the TIMESTAMP field. It is not mandated that they do so at this time
since most of the receivers in use today will not be able to understand
that format and may modify those packets according to Section 4.3 of
RFC 3164.
A single space character MUST follow the TIMESTAMP field.
Receivers parsing the date format SHOULD check if the TIMESTAMP is a
TIMESTAMP-3339. The "T" character at position 11 of the string can be
used as a rough indication for this. However, the receiver MUST NOT rely
solely on the "T" character but also parse the other data for validity.
A receiver SHOULD check for TIMESTAMP-3339 format first and, if
unsuccessful, assume a TIMESTAMP-3164. If it is also not a TIMESTAMP-3164
format, the receiver MUST NOT try any other timestamp format but consider
the TIMESTAMP to be invalid or missing from the received syslog message.
If a relay receives a TIMESTAMP-3164, it SHOULD forward the message
with a TIMESTAMP-3164 but MAY reformat it to a TIMESTAMP-3339 if
configured to do so. Relays should be aware that the TIMESTAMP-3339 may
be longer than the TIMESTAMP-3164 and a replacement of the TIMESTAMP-3164
with a TIMESTAMP-3339 may increase the length of the entire packet beyond
1024 bytes. If a relay receives a TIMESTAMP-3339 it MUST forward the
message with a TIMESTAMP-3339. It MUST NOT reformat it to a
TIMESTAMP-3164.
---^^^--- Proposed change to Section 2.2 ---^^^---
Thanks,
Chris
