Subject: [apps-discuss] AD Evaluation of draft-ietf-appsawg-rrvs-header-field

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 1 Mar 2014 12:44:37 -0800

Colleagues,

Barry has done his evaluation of this draft and there's one point we'd like
to revisit with the WG before we send it on to IETF-wide Last Call and then
IESG Evaluation.

Both forms of the extension use a timestamp that includes
hours:minutes:seconds.  Two things we've been asked to either affirm or
reconsider here:

1) Is that level of precision necessary?  Isn't just the date good enough?

2) Does using to-the-second precision expose us to problems possibly
introduced by clock synchronization issues?  If yes, how bad?

My own answers as an implementer are that clock synchronization issues are
rare these days (though we can do a "MUST use NTP" to ram the point home),
per-second precision is how these things are typically stored in their
backing databases, that precision in the protocol is preferable since the
supporting data are available anyway, and most things that generate or
parse timestamps in mail do dates with times already so the implementation
cost is low.  That's not to say, of course, that doing a date-only
implementation would be expensive, but it is slightly less work to use
stuff we already have.

Are there any concurring, dissenting, or different opinions?

-MSK

---

From: "John Levine" <[email-masked]>
Date: 2 Mar 2014 00:21:13 -0000

>1) Is that level of precision necessary?  Isn't just the date good enough?

Anyone who gives the same e-mail address to two different people in
the same day deserve what they get.  But, ...

>introduced by clock synchronization issues?  If yes, how bad?

If it's just a date, you get pathological issues from time zones.  If
Bob in Auckland signs up for a Yahoo account when it's 10 AM on the
2nd in New Zealand, but 1 PM on the 1st in California, what date goes
into the RRVS field? I can imagine this being an issue if people in
Europe or Asia set up a new mail account at a webmail provider in
California and then immediately use it to sign up for bank or
e-commerce accounts at institutions in Europe or Asia or vice versa.

Leave it as is, the time stamps include the time zone, and the issue goes away.

R's,
John

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 1 Mar 2014 17:57:13 -0800

On Sat, Mar 1, 2014 at 12:44 PM, Murray S. Kucherawy <[email-masked]>wrote:

> Colleagues,
>
> Barry has done his evaluation of this draft and there's one point we'd
> like to revisit with the WG before we send it on to IETF-wide Last Call and
> then IESG Evaluation.
>

I'd say leave it as is. For all effective purposes, if one truncates a time
field, it's the same as filling the missing fields with zeroes so if that
is what a sender wishes to do, they can feel free to do so.

I think that the potential issues with clock skew are small enough to be
ignored. If a user is racing to exploit a free account so quickly that
clock skew works in their favor, it's just as likely to work against them
and I have no sympathy.

--Kurt Andersen

---

From: Ned Freed <[email-masked]>
Date: Sat, 01 Mar 2014 19:33:33 -0800 (PST)

> clock skew works in their favor, it's just as likely to work against them

I agree, and I will add that another reason not to use truncated time values is
that doing so effectively creates another time representation syntax. The main
reason the syntaxes used in this document were chosen was in order to match
existing email syntax usage. As a result implementations don't have to write
new parsers and incure the costs associated with doing so.

				Ned

---

From: Barry Leiba <[email-masked]>
Date: Sun, 2 Mar 2014 10:37:08 +0000

> new parsers and incure the costs associated with doing so.

This and the other comments so far are sufficient; thanks.  No need to
discuss this further.

Barry