Hi all,

Based on the feedback on this list, I have re-worded my suggestion for
the change to syslog-sign:

---- begin suggestion ----
  The TIMESTAMP field is either a RFC3164-TIMESTAMP or a
RFC3339-TIMESTAMP. A sender SHOULD format the timestamp as a
RFC3339-TIMESTAMP. A receiver MUST accept both formats.

The RFC3164-TIMESTAMP 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 RFC3339-TIMESTAMP is as specified in [RFC3339]:

The following syntax MUST be used when using a RFC3339-TIMESTAMP. 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

  Other than in RFC3339

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

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.

For complete details and samples see RFC3339.



   A single space character MUST follow the TIMESTAMP field.

Receivers parsing the date format SHOULD check if the TIMESTAMP is a
RFC3339-TIMESTAMP. 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 RFC3339-TIMESTAMP format first and, if
unsuccessful, assume a RFC3164-TIMESTAMP. If it is also not an
RFC3164-TIMESTAMP the receiver MUST NOT try any other timestamp format
but consider this message to be invalid.

If a relay receives a RFC3164-TIMESTAMP, it SHOULD forward the message
with a RFC3164-TIMESTAMP but MAY reformat it to a RFC3339-TIMESTAMP if
configured to do so. If a relay receives a RFC3339-TIMESTAMP it MUST
forward the message with a RFC3339-TIMESTAMP. It MUST NOT reformat it to
a RFC3164-TIMESTAMP.
---- end suggestion ----

There are two changes to my original suggestion:

- I have removed the requirement to format the timestamp in UTC
- a relay is now permitted to reformat a RFC3164-TIMESTAMP to a
RFC3339-TIMESTAMP

As far as I kept track, there is one point open to discussion. Andrew
Ross suggested that the timestamp should be fixed length. I will post a
reply to his original message, so if somebody would like to jump in,
that would be fine. Other then that, I think we have reached consensus
on the new text. Any opposition against this?

Rainer


Reply via email to