[ietf-dkim] Issue: Repeated headers

[Murray S. Kucherawy]

> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Charles Lindsey
> Sent: Tuesday, April 19, 2011 12:56 PM
> To: DKIM
> Subject: [ietf-dkim] Issue: Repeated headers
> 
> Yes indeed. We discussed lots of wording for all of this, and the one that
> has got into the document is about the worst.

Where is your proposed alternate text?  Complaining without it isn't especially helpful during a WGLC.

> It is Absolutely Pointless to check for minor infringements of 5233 et al,
> and so to say that implementors SHOULD check for some "reasonable" subset
> of infringements is ridiculous, unless you spell out what "reasonable"
> really implies. Now AFAICS, minor infringements in the format of
> particular headers etc, "naughty" as they might be, have no impact on
> DKIM. The "naughtiness" will be signed, so you can see whether it was
> present at signature time, if you happen to care about it.

I believe the added text adequately addresses this problem, especially the new Section 8.15.  I also believe that the chair has said we have rough consensus on this point.

> So if we are going to have normative language (such as SHOULD or MUST),
> then let us address it to the known problem, rather than to some vague
> "reasonable" test that might lead people to waste time on things that are
> not broken, and omit the one case that is broken.

We do have normative language, in 3.8.  And the text in 8.15 makes it clear what the attack is, and therefore what the "reasonable" defenses are.

> 1. What exactly do we really REALLY want implementors to do in this
> matter.?

I believe Sections 3.8 and 8.15 make this clear to anyone that's designing and implementing software in this area.

> 2. Is it to be a SHOULD or a MUST?

Given the RFC2119 definition, I think we've appropriately settled on SHOULD.

I don't want to re-hash all the arguments.  What we have is a compromise between two hard-argued positions, and I think reopening it now will just drag everything out even longer.