Subject: [apps-discuss] Consensus to change time field in draft-wmills-rrvs-header-field-00?

From: Kurt Andersen <[email-masked]>
Date: Fri, 2 Aug 2013 07:34:29 -0700

I'd like to propose changing the time field in the
draft-wmills-rrvs-header from [MAIL]'s human-oriented text string to
epoch seconds (as used in the DKIM headers [RFC6376 et al]). Such a
usage would be more in keeping with the automated nature of the
messages that are anticipated to make the most use of this header.
Quoting from RFC6376:

      The format is the number of seconds
      since 00:00:00 on January 1, 1970 in the UTC time zone.  The value
      is expressed as an unsigned integer in decimal ASCII.  This value
      is not constrained to fit into a 31- or 32-bit integer.

Please reply if in favor.

Thanks,
  Kurt Andersen

---

From: Ned Freed <[email-masked]>
Date: Sun, 04 Aug 2013 14:13:18 -0700 (PDT)

I strongly object to the change. DKIM is one thing; signature verification
requires unambiguous inputs and interpretation of the field requires DKIM
software in any case.

The situation here is different - the input requirements are far less strict,
and readability of the field is going to be important when problems arise - and
rest assure they are going to.

If RFC 5322 format dates are really a problem - and I don't think they are -
then that's what RFC 3339 is for.

				Ned

> Thanks,
>   Kurt Andersen
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "John Levine" <[email-masked]>
Date: 4 Aug 2013 22:46:19 -0000

>requires unambiguous inputs and interpretation of the field requires DKIM

I'm with Ned.  It's the same format as a Date: header, so if you can't parse
that, you can't handle the rest of the message.

Date parsing libraries are cheap and plentiful.

R's,
John

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 5 Aug 2013 16:08:36 -0700

On Sun, Aug 4, 2013 at 2:13 PM, Ned Freed <[email-masked]> wrote:
> I strongly object to the change [from human-readable to epoch seconds].
> DKIM is one thing; signature verification

I would argue that a security-related header such as this one is
exactly parallel to DKIM. When the header is stripped out through
normal processing as advised in the -01 draft, I'm not sure what the
format of the time field will have to do with solving problems for the
no-longer-extant header.

I acknowledge John's comment about date processing libraries being
commonplace, but I think that putting the data into a machine-oriented
format is more in keeping with the security measure that this header
is supposed to be providing.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Aug 2013 16:52:01 -0700

> is supposed to be providing.

I think Bill and I are in agreement that we don't have a strong preference
as to which form is used and will go with consensus, but here's a minor
counter-argument:

If there's no DKIM verification code in effect at a receiver, then there's
nothing that knows about epoch time format (not that it's complicated) in
use at that receiver; however, that same receiver is probably already
equipped to parse a Date: field.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 6 Aug 2013 00:34:13 -0000

>equipped to parse a Date: field.

Right.  Keep in mind that operating systems designed in suburban
Seattle use internal date formats very unlike the Unix 1970 epoch, and
converting from Unix epoch to their format is not a whole lot easier
than parsing Date: fields.

R's,
John