Subject: [ietf-dkim] Consensus call on d=/i= clarification

From: Stephen Farrell <[email-masked]>
Date: Mon, 16 Feb 2009 16:36:03 +0000

Hi All,

We've had some recent discussion about d=/i= on the list
and a couple of concrete proposals for clarifications to
make to RFC 4871.
   - The first is Dave's erratum I-D. [1]
   - The second is a proposal from Eliot.[2]

Barry and I would like to see if there's rough consensus
on one of these, and, if so, we'll then work with Pasi to
get that processed. (There is an open question as to whether
the erratum I-D fits the RFC editor's erratum model or not,
perhaps mostly due to its length, but we'll handle that if/when
we have WG rough consensus on the meat of the topic. For now,
ignore the process issues, and let's see what clarification
we'd like.)

So, can you please reply to the list with *one* of the
following opinions, before the end of next Monday, Feb
23rd.

(a) The erratum I-D [1] is ready to go. Process it.
(b) The erratum I-D [1] is the way to go, but needs work.
    (Then specify your changes in "NEW"/"OLD" style.)
(c) Eliot's proposal [2] is ready to go. Process it.
(d) Eliot's proposal [2] is the way to go, but needs work.
    (Then specify your changes in "NEW"/"OLD" style.)
(e) None of the above.

Thanks,
Stephen & Barry.

[1] http://tools.ietf.org/html/draft-ietf-dkim-rfc4871-errata
[2] http://mipassoc.org/pipermail/ietf-dkim/2009q1/011150.html

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Mon, 16 Feb 2009 09:28:46 -0800

(d).  My suggested changes to Eliot's proposal are at
http://mipassoc.org/pipermail/ietf-dkim/2009q1/011153.html

-Jim

---

From: Eliot Lear <[email-masked]>
Date: Mon, 16 Feb 2009 19:55:16 +0100

> http://mipassoc.org/pipermail/ietf-dkim/2009q1/011153.html

+1.

Eliot

---

From: [email-masked] (Wietse Venema)
Date: Mon, 16 Feb 2009 15:05:15 -0500 (EST)

> (a) The erratum I-D [1] is ready to go. Process it.

Motivation:

Adding tweaks to a confusing document does not remove the confusion
(you can consider this my variant of Brooks's law).

Confusion is removed by stating clear terms up-front, and by casting
the discussion into those terms.

	Wietse

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 16 Feb 2009 14:52:02 -0500

+1.

Scott K

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 16 Feb 2009 13:23:00 -0800

> (a) The erratum I-D [1] is ready to go. Process it.

(a)

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 16 Feb 2009 21:57:17 -0000

>(a) The erratum I-D [1] is ready to go. Process it.

R's,
John

PS: There's nothing wrong in what Eliot says, but it doesn't address
the problem of what DKIM's output is.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Siegel, Ellen" <[email-masked]>
Date: Mon, 16 Feb 2009 17:03:49 -0500

> the problem of what DKIM's output is.

+1

------------------
Ellen Siegel
Constant Contact

---

From: Suresh Ramasubramanian <[email-masked]>
Date: Mon, 16 Feb 2009 14:48:31 -0800

> the discussion into those terms.

+1 for a.  The confusion is minimized by Dave's draft.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 16 Feb 2009 15:36:00 -0800

Stephen Farrell wrote:
>     (There is an open question as to whether

It does fit, and the timeframe for Errata works much better for the market need 
for the correction, than does the timeframe of a revised RFC.

> (a) The erratum I-D [1] is ready to go. Process it.

a), please.

For example, Eliot's draft does not attend to the basic requirement for 
specifying what is primary output. (Or, for that matter, distinguishing output 
from protocol internals.)

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Feb 2009 17:32:33 -0800

+1.

For what its worth, a reputation system can utilize an opaque i= value  
to isolate messages identified as abusive, provided the number of such  
exceptions is kept within a practical range.  The alternative might  
require each receiver to deal with abuse that might have been  
consolidated by the i= value.

Dave's draft  goes a bit too far when describing even the domain as  
being opaque.  Is this attempting to suggest the d= value is not that  
of a domain?

While the i= value can be opaque, any language that appears to lessen  
its relationship to that of on whose behalf the signature had been  
added should also warn against overlapping real and fictitious  
namespace if only to better support the uses described by ADSP.

-Doug

---

From: Al Iverson <[email-masked]>
Date: Mon, 16 Feb 2009 22:37:00 -0600

(A), please.

--
Sent from my awesome T-Mobile G1.
Al Iverson - www.aliverson.com

R's,
John

_______________________________________________ NOTE WELL: This list
operates according to http://m...
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Feb 2009 07:47:12 +0100

> from protocol internals.)

And that is because it is not a basic requirement; and in fact hits 
against our charter limit of discussing reputation systems.  You've 
cleverly couched this debate in terms of interoperability, but what are 
we really talking about?  It's the input to reputation services, no 
matter what terminology you throw at the matter.

Eliot

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Feb 2009 01:12:22 -0500

> the discussion into those terms.

Its called Focused Confusion.

-- 
Sincerely

Hector Santos
http://www.santronics.com

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Feb 2009 01:20:37 -0500

> (a) The erratum I-D [1] is ready to go. Process it.

It is far from ready, and despite the marketing genius behind it, for 
the sake of getting this done only, I vote A.

-- 
Sincerely

Hector Santos

---

From: Jon Callas <[email-masked]>
Date: Tue, 17 Feb 2009 01:42:41 -0800

+1

	Jon

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 17 Feb 2009 07:38:13 -0800

Eliot Lear wrote:
>> specifying what is primary output. 
...
> matter what terminology you throw at the matter.

Eliot,

You are confusing the difference between output and input.  DKIM Signature 
output, versus Assessment input.  The Errata discusses the former, but you are 
referring to the latter.

Protocols have payload, or output.  A protocol that does not specify what its 
payload is is not complete.

Take a look at Figure 1 in the new Deployment draft:

    <http://dkim.org/specs/draft-ietf-dkim-deployment-03.html>

Note the transition from Identity Validator to Identity Assessor.  The former is 
part of DKIM; the latter is not.  But that transition entails delivery of the 
payload by DKIM to its receive-side consuming module, the Assessor.

The current RFC 4871 does not specify what its payload is, versus what is 
internal to the protocol operations.  The DKIM-Signature: header field contains 
both DKIM internals and DKIM payload.  Which is which?

Take a look at the TCP Header Format diagram in the TCP spec:

    <http://www.rfc-editor.org/rfc/rfc793.txt>

Note the field at the end labeled "data".  That's payload.

The DKIM spec has no equivalently clear and precise definition of its payload.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Tue, 17 Feb 2009 08:58:05 -0800

> The DKIM spec has no equivalently clear and precise definition of  

Your version of the errata declares the d= value, ( a domain which  
includes all contained sub-domains) to be opaque to the "Identity  
Assessor".   DKIM has established that a signer controls this domain,  
unlike the possible sub-domains within the i= value.  Even Ellen seems  
to have confused the role of i= values with that of d= values in her  
statements.   The d= value should be considered definitive and  
extremely useful to an "Identity Assessor".  In addition, the DKIM  
signature semantics limit  i= value assertions to be at or below the  
domain defined by the d= value.

Taking away the d= value as input to an "Identity Assessor" will mean  
no relationship can be established.   Why must a reasonably safe  
conclusion require an undefined external entity or mechanism to  
restore an obvious and safe relationship such as From [email-masked], i=[email-masked] 
  d=example.com?  An email-address signed by the email-address domain  
offers significant value when assessing whether the email-address may  
have been spoofed, does it not?  Is this not the function of "DKIM"  
and an "Identity Assessor"?

At least Eliot's version of the errata did not significantly modify  
the role of the d= value.  Efforts to change DKIM definitions should  
be done within a subsequent draft, and not in a rushed errata.

While indeed the i= value can be opaque, it is often used to represent  
valid email-addresses as with ADSP.  If the DKIM WG were to declare in  
some document or errata that the i= fictitious and real namespace  
should not collide within the same message,  this would help restore  
value to ADSP without the need of some out-of-band signaling.  IMHO,  
ADSP should only require that the d= value match against a From email- 
address, and allow the i= value to play whatever role the domain may  
wish.

Why add unnecessary overhead to an already high overhead protocol?
Why add unnecessary delay by mandating the use of redundant auxiliary  
mechanisms?

-Doug

---

From: <[email-masked]>
Date: Tue, 17 Feb 2009 10:01:31 -0500

a||c  

Bill Oxley
Messaging Engineer
Cox Communications, Inc
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Monday, February 16, 2009 11:36 AM
To: ietf-dkim
Cc: [email-masked]
Subject: [ietf-dkim] Consensus call on d=/i= clarification

Hi All,

Thanks,
Stephen & Barry.

---

From: Jeff Macdonald <[email-masked]>
Date: Tue, 17 Feb 2009 14:27:11 -0500

+1

-- 
Jeff Macdonald
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Feb 2009 15:31:56 -0500

Dave CROCKER wrote:
> Protocols have payload, or output.  

Geez, I would swear Payload is Input.  Well Output for the sender, 
Input for the receiver.

> A protocol that does not specify what its 

Huh? Why are you making this so complex with mumbo jumbo?

The PAYLOAD is SMTP 2822 mail packet/block/data (pick one).  Lets not 
confuse this ok?

DKIM is a process of validating a signed 2822 (header+body) payload. 
Period.

That payload was OUTPUT for the sender, INPUT for the receiver. Its 
relative. Its still the SMTP payload.

What is passed to external utilities is not defined. It could be the 
entire payload or part of the payload.

What you need do to for DKIM is clearly define what are the process 
parameters, what needs to the passed to other layers.

Can you equate the model DKIM (plus its "Assessors") using functional 
definitions? for example:

     DKIM_OUTPUT = DKIM_VALIDATOR(2822,BODY [,2821])

     DKIM_RESULT = DKIM_ASSESSOR(DKIM_OUTPUT, 2822?, I=?, [,2821])

etc.

This will allow you to define and resolve your boundary conditions. 
It will allow designer prepare their implementations so the 
communications is resolved.  It WILL even help define if process 
separation will work, even dynamically or delayed and/or a tigher 
integration is necessary.

-- 
Sincerely

Hector Santos

---

From: Jim Fenton <[email-masked]>
Date: Tue, 17 Feb 2009 15:26:08 -0800

> both DKIM internals and DKIM payload.  Which is which?

This is a fair point, but is much broader than the d=/i= question that
is the subject of this erratum.  I believe that this should be
considered as a separate erratum.

The way in which draft-ietf-dkim-rfc4871-errata-02 is written, the d=
value is payload, i= MAY be payload if present.  How can the i= value
only sometimes be payload?

But -rfc4871-errata-02 defines this backwards.  The erratum makes
everything else internals, which eliminates a lot of information that
might be useful to a downstream assessor.  For example:

- h= is needed by assessors that might want to know whether a given
header field is signed by the signature.  This is needed to support John
Callas's suggestion that additional assertions might be contained in a
header field signed by the signature.  Without the h= value, the
assessor has no way of knowing what's signed.

- l= would be needed by an assessor that wants to present only signed
portions of the body to the user. 

- as-yet undefined DKIM-Signature tags are likely to be payload, such as
additional identifier tags described by Jon Callas.

There are a few values (b=, bh= and s=, for example) that don't seem
useful to downstream assessors, but many others are.

The notion that DKIM has a single output (presumably d=) is flawed,
unless that single output is a vector (list of tag/value pairs) or a
pointer to a DKIM-Signature header field that verified successfully.

Back to the errata question:  An erratum is supposed to be about a
single topic.  This is different from the question of d= vs. i=
confusion, and that's why it's not part of Eliot's erratum proposal (or
my amendment).

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 17 Feb 2009 15:52:16 -0800

Murray S. Kucherawy wrote:
> On Tue, 17 Feb 2009, Jim Fenton wrote:
>> [...]
> Perhaps this is a terminology question.

No, the confusion is much deeper than that.  It's about a protocol layering and 
protocol specification scope.

The fact that upper layers sometimes reach down into lower layer information, 
and the fact that this is sometimes useful, does not eliminate the nature of the 
layering or the fact that there is a layering violation.  Protocol layering is a 
matter of design discipline, not just terminology.

In this case, it appears that Jim is confusing the sole stated goal of DKIM:

      "permitting a signing domain to claim responsibility for the introduction 
of a message into the mail stream"

with other useful goals.  He's conflating these other goals, such as validation 
of message content, into the DKIM Signing spec, on the theory that someone, 
sometime, might want to do it a variety of yet-to-be-specified functions.

Apparently the feeling is that any constraint in the Signing spec will somehow 
prevent value-add functions that go beyond the spec.

d/
-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Feb 2009 15:41:17 -0800 (PST)

In a DNS reply, is the "answer" section the payload, or does the payload 
include the header (e.g. the answer count, the authority count, the 
additional count, some flags)?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Jim Fenton <[email-masked]>
Date: Tue, 17 Feb 2009 16:25:51 -0800

Dave CROCKER wrote:
>>> everything else internals, which eliminates a lot of information
>>> that might be useful to a downstream assessor.  For example:
>>> [...]
>>
> No, the confusion is much deeper than that.  It's about a protocol
> layering and protocol specification scope.
>
> The fact that upper layers sometimes reach down into lower layer
> information, and the fact that this is sometimes useful, does not
> eliminate the nature of the layering or the fact that there is a
> layering violation.  Protocol layering is a matter of design
> discipline, not just terminology.

This is part of the reason that it's important to recognize that upper
layers may wish to make use of additional information in the signature,
and not only the signing domain.

>      "permitting a signing domain to claim responsibility for the
> introduction of a message into the mail stream"
>
> with other useful goals.  He's conflating these other goals, such as
> validation of message content, into the DKIM Signing spec, on the
> theory that someone, sometime, might want to do it a variety of
> yet-to-be-specified functions.

The DKIM signing specification is a base which may be extended.  It is
for that reason that we worked hard to make sure that the base
specification was extensible (addition of tag/value pairs, for example).

>
> Apparently the feeling is that any constraint in the Signing spec will
> somehow prevent value-add functions that go beyond the spec.

When the specification describes specific payload values, and makes
extensions and other values that might be useful "DKIM internals"
requiring a layering violation to access, it does seem to be
discouraging value-add functions.

But again, why is this part of the erratum seeking to resolve d=/i=
confusion?

-Jim

---

From: Byung-Hee HWANG <[email-masked]>
Date: Wed, 18 Feb 2009 08:55:36 +0900

> [2] http://mipassoc.org/pipermail/ietf-dkim/2009q1/011150.html

For long time i have read the both proposals and comments of people. 
Then let me say that: Eliot's proposal satisfies me. And Dave's erratum 
I-D satisfies me, plus beautiful.. ;;

My conclusion: (b)

Thanks,

byunghee

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Feb 2009 07:59:27 +0100

The question one has to ask is broader than inputs and outputs.  Are 
each of the protocol elements described in the specification clear 
enough to be understood as to their meaning?  If they are not then that 
is what needs to be clarified.  Regardless, this debate about functional 
programming (which is really what this boils down to) is pointless, and 
you are ossifying a structure around a model that you needn't do.  As we 
have seen many times at the IETF, successful specifications are those in 
which the model can easily evolve over time based on circumstances.

This is precisely the case with DKIM, where the AD's and the IESG's 
intent was to walk slowly before we run.  The DKIM specification 
reflects that intent.

Your errata reflect a different intent.

Eliot

On 2/17/09 4:38 PM, Dave CROCKER wrote:
>> cleverly couched this debate in terms of interoperability, but what 
>> are we really talking about?  It's the input to reputation services, 
>> no matter what terminology you throw at the matter.
>
>
> Eliot,
>
> You are confusing the difference between output and input.  DKIM 
> Signature output, versus Assessment input.  The Errata discusses the 
> former, but you are referring to the latter.
>
> Protocols have payload, or output.  A protocol that does not specify 
> what its payload is is not complete.
>
> Note the transition from Identity Validator to Identity Assessor.  The 
> former is part of DKIM; the latter is not.  But that transition 
> entails delivery of the payload by DKIM to its receive-side consuming 
> module, the Assessor.
>
> The current RFC 4871 does not specify what its payload is, versus what 
> is internal to the protocol operations.  The DKIM-Signature: header 
> field contains both DKIM internals and DKIM payload.  Which is which?
>

---

From: [email-masked] (Wietse Venema)
Date: Wed, 18 Feb 2009 07:51:34 -0500 (EST)

> Your errata reflect a different intent.

If intelligent people cannot agree on what is the result of a
protocol, then there is a problem that needs to be fixed.  The
proposed errata address the problem. The alternative does not.

	Wietse

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Feb 2009 13:53:38 +0100

> proposed errata address the problem. The alternative does not.

But that where precisely is the disagreement?  That is the real Q.

Regards,

Eliot

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Feb 2009 08:51:59 -0500

> But that where precisely is the disagreement?  That is the real Q.

In my view, the problem began with the Deployment Guide.  RFC 4871 did 
not match the stated semantics of the non-vetted Deployment Guide,  a 
product designed around out of scope trust-based services, reputation 
ideas and design criterias purely based on heuristics, that is "on 
guessing" [SIC] concepts.

Lets face it.

What we are really dealing with is the issues related to 3rd party 
signers - either external or in-house.  It was thrown out of SSP 
resulting in ADSP, but the only place it really disappear from was the 
WG - moved to behind the scene, to a non-vetted deployment guide.

When SSP was killed and the deployment guide was written, the writing 
was on the wall - DKIM will not work well without reputation services. 

Even the original Deployment Guide stated as much and I posted 
concerns regarding that statement in the guide.  My concern was the 
"batteries required" syndrome and that is exactly what seems to have 
occurred.

I had no problem with the reputation services - it inevitable. Its 
required in my view as this technology matures.  It is something we 
will include too.

However, from a SMTP product standpoint, in my view, I always felt 
POLICY was the middle ground to help address the obvious FRAUD that 
will prevail with wide deployment - FRAUD that SHOULD NOT be based on 
Heuristics or "Guessing."

It was always my hope that the IETF WG chairs will control the 
powerful forces behind the scene making DKIM more complex than it 
ought to be.  People need to remember that small systems will suffer 
the consequences when the BAD GUYS try to exploit larger system and 
domains with their reputation servers employed against the smaller 
systems who may not have the Batteries or even same batteries required.

-- 
Sincerely

Hector Santos

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Feb 2009 14:16:13 -0800

On Feb 18, 2009, at 4:51 AM, Wietse Venema wrote:

> Eliot Lear:
>>
>> The question one has to ask is broader than inputs and outputs.   
>> Are each of the protocol elements described in the specification  
>> clear enough to be understood as to their meaning?  If they are not  
>> then that is what needs to be clarified.  Regardless, this debate  
>> about functional programming (which is really what this boils down  
>> to) is pointless, and you are ossifying a structure around a model  
>> that you needn't do.  As we have seen many times at the IETF,  
>> successful specifications are those in which the model can easily  
>> evolve over time based on circumstances.
>>

Eliot makes a good point.  Eloit's errata does less violence to DKIM.   
However, rather than describing the i= value as a being an opaque  
string, when this value within the i= value matches exactly with that  
of some signed header field, it should be safe to assume name  
collision has been avoided which is easily done with DKIM.  Otherwise,  
extensions like ADSP represent little more than a signature mandate  
with little other value.

A rush to create an errata that emasculates the information offered by  
DKIM (without batteries) seems ill advised.  The general goal DKIM's  
charter was to enable detection of domain spoofing.  As such, the d=  
value within the DKIM signature can not be described as opaque to  
achieve this role.  DKIM is not just an exercise of attaching  
cryptographic tokens unrelated to other message content.

Although a DKIM  i= value may include namespace that does not  
reference a valid destination, this namespace is still that of the  
same domain.  Any semblance of accountability requires that DKIM  
ensure a valid signature represents message control by an  
authoritative entity for this domain's namespace.  As a general  
practice, this entity should avoid colliding non-valid and valid  
namespace within the same message, or the i= value might be deceptive.  
In general, DKIM should not sanction deceptive messages.

-Doug

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Wed, 18 Feb 2009 17:26:13 -0500

Stephen and Barry, 

I have a procedural question on how the responses to the consensus call
will be evaluated for options a,b,c,d. 

Will it be a+b vs c+d to get a general sense of direction and then
evaluate each option with in an approach or will each option be
evaluated independently (that is, response to a would be considered
separately from responses to b and responses to c evaluated separately
from responses to d)?

Thanks in advance

Mike

> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Stephen Farrell

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 18 Feb 2009 17:09:24 -0800

Jim,

I think this is at least the second time I've seen you offer this line of 
commentary and I still don't understand it.  On its surface, your comments seem 
to me to be a complete non sequitor with the question at hand.

The best I can guess is that you think that distinguishing payload from protocol 
internals somehow creates an access barrier to the internals.  I can't guess 
what your evidence for this conclusion is, since the history of value-added APIs 
goes against your claim.

In general, seem to be confusing protocol definition with API definition, and yu 
seem to be claiming that ensuring specification discipline and clarity somehow 
prevents later protocol enhancement, although it demonstrably does not.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 18 Feb 2009 17:30:11 -0800 (PST)

> (a) The erratum I-D [1] is ready to go. Process it.

If there is indeed a requirement to conform to the concept that a protocol 
must specify its payload, I believe this is the right way to go.  At 
present, a new API implementor has no clear indication of what a minimal 
DKIM implementation has to provide to be compliant.

To recite my prior example, the payload of a DNS reply is the answer which 
all APIs have to return, but there's auxilliary data (flags, counts, glue 
records) which an API might choose to expose as well, and some consumers 
might want.  An implementor of a protocol can choose to expose via its API 
whatever it wants (our DKIM library offer the means to get at pretty much 
everything), but it has to do the prescribed minimum.  Then it becomes a 
matter of choosing the API that satisfies the consumer's needs; a minimal 
one, or a more feature-rich one.  Typical DNS implementations have a "just 
give me the answer" API, namely the gethostbyxxx() calls, or something 
more detailed, namely the res_xxx() interface.

RFC3464 (DSNs) section 3 specifies what a minimal implementation of that 
specification needs to do to be compliant.  I think what this document 
does is essentially analogous with respect to DKIM.

I would also be satisfied with a change which stipulates that both i= and 
d=, or the UAID and SDID, are both mandatory outputs, but I don't want or 
need this strongly enough to advance it in a formal manner.  This could be 
done in DKIM v2, or the "bis" draft whenever that comes, or an extension 
draft, or something.

I don't believe all of the introduced terminology is strictly necessary, 
and note it makes the erratum document somewhat bloated and people 
reasonably find that uncomfortable.  But I don't believe that makes the 
document incorrect or more technically difficult to apply.

-MSK

---

From: Florian Sager <[email-masked]>
Date: Thu, 19 Feb 2009 15:38:12 +0100

Murray S. Kucherawy schrieb:

> > My vote:
>   
>> >> a) The erratum I-D [1] is ready to go. Process it.
>> >>     
>>     
That's correct. As a summary of what I've read in the last mails with
inclusion of the experience I made with data collection, evaluation and
publishing in www.dkim-reputation.org:

- the UAID definition in draft-ietf-dkim-rfc4871-errata-02 is suitable;
as far as I can see Jim's proposal of r= was made having a higher
identifier stability in mind. IMHO, concerning stability, with r=
nothing more can be reached as with the definition of the UAID in the
errata document.
Reasons for that: Jim was talking about the indirect transition of
reputation by the referring r= identifier. I think the following trust
hierarchy is correct in principle: "author -> author identifier ->
signing domain -> DNS". I consider the lower part of the hierarchy
"signing domain -> DNS" as the trust anchor in DKIM. I see no
auto+technical+trustworthy means to provide a transition of reputation
beyond this trust anchor --> transition aspect fails. The idea of a 1*r=
: N*identities relation reverses the hierarchy --> not usable. The
result is: r= is conceptual equal to i= (it doesn't really matter if i=
contains d=, it's still opaque). Did I miss something?

- I confirm the rare use of i=; the errata clarifies some
misunderstanding but it won't lead to a broader use 'cause the
advantages of the additional effort to include i= are unclear at the
moment. But: thinking about a higher identifier precision in reputation
systems (I just refer to good signers, bad signers will try to trick the
rep-systems anyway) I'd absolutely appreciate if in the errata doc,
"Section 3.5 The DKIM-Signature Header Field" the sentence "The syntax
is a standard email address where the Local-part MAY be omitted." could
be replaced by "The syntax is a standard email address where the
Local-part SHOULD be set to a user unique value". Coming back to the
last discussion: in my view a reputation system has to deal with
arbitrary UAID values, I am missing the requirement that lead to the
"protocol" discussion (?)

Regards,
Florian

---

From: John Levine <[email-masked]>
Date: 19 Feb 2009 17:18:23 -0000

>Local-part SHOULD be set to a user unique value".

Well, not user, since there seems to be general agreement that the
address of a mailing list would be a reasonable i= value, and the
domain part can (and in this message does) encode part of the user
identity, but it seems clear enough what you're asking for.

This gets us back to the question of whether i= values have to be
stable, and if they do, what does stable mean.  Given the lack of
consensus about just about everything else related to i=, even though
there are many scenarios where it would be handy for i= to be stable,
I'd rather let people come up with a clear definitions of what stable
identifiers they want and what they mean, then create a new tag or
two to put them into the signature.

R's,
John

---

From: SM <[email-masked]>
Date: Sat, 21 Feb 2009 23:40:37 -0800

>    - The second is a proposal from Eliot.[2]

[snip]

>     (Then specify your changes in "NEW"/"OLD" style.)

The erratum (draft-ietf-dkim-rfc4871-errata-02 - item a) introduces 
new terms such as the User Agent Identifier, Identity Assessor and 
Signing Domain Identifier.  It then goes into an explanation of how 
they tie into DKIM.  Eliot's proposal (item c) falls within the usual 
boundary for an errata as it tries to provide clarity without 
introducing new terminology.

An errata is generally noncontroversial.  Instead of being a 
clarification of the d= and i= tags in the current specification, 
this one turned into a determination of how DKIM will be used in 
future.  One of the proposal affects the work currently being done on 
ADSP.  I'll quote Section 2.7 of draft-ietf-dkim-ssp-09:

   "Note:   ADSP is incompatible with valid DKIM usage in which a signer
       uses "i=" with values that are not the same as addresses in mail
       headers.  In that case, a possible workaround could be to add a
       second DKIM signature a "d=" value that matches the Author
       Address, but no "i="."

With the change, we may need to sign the message more than once in 
some circumstances if we are using the i= tag.  That's an extra 
overhead both for signers and verifiers.

Quoting part of Jim's proposal:

   "In many cases, the i= tag will not be present in the DKIM-Signature
    header field at all; it is not required unless the signing key
    restricts the signing identity or identities via its g= value."

That is better suited for a document about deployment.

J.D. suggested leaving i= opaque and see what operators (on both ends 
of the transaction) do with it.  That could be discussed in a 
document about deployment.

Given the scope of Dave's proposal, I'm still not comfortable with it 
as an erratum.  I choose Eliot's proposal (d).

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 22 Feb 2009 00:58:56 -0800 (PST)

> as an erratum.  I choose Eliot's proposal (d).

(d) included a "with the following changes" provision.  What changes are 
you suggesting (or supporting)?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Sun, 22 Feb 2009 04:08:32 -0500

+1

Based on SM's excellent summary review, I change my original A entry 
to D.

Thanks SM.

-- 
Sincerely

Hector Santos

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 22 Feb 2009 07:29:09 -0800

(Subject changed, to take this out of the tally thread.)

SM,

You cite some issues that I would be interested is seeing you expand a bit:

SM wrote:
> An errata is generally noncontroversial. 

First, you say "generally" which means that an errata is not disqualified by 
being controversial.  Further, I've never heard of any requirement for being 
non-requirement.  My own experience with errata is pretty small, but I've seen 
them range from silly to obvious.

  Instead of being a
> future. 

I don't understand this statement, if it means more than your stated concern 
about ADSP.  FIrst, any specification is determining how things will be done in 
the future.  Any correction (errata) to a specification is modifying the 
specification and, therefore, also determining how things will be done in the 
future.  You imply there is something bad about this, whereas it's inherent. 
Please clarify.

  One of the proposal affects the work currently being done on
> overhead both for signers and verifiers.

I am reasonably certain the draft Errata makes no such requirement.  At the 
least, Please explain.  Your quotation, above, does not contain any text that 
makes this obvious to me.

It is further confusing that you cite some ADSP text as the basis for your 
concern about the Errata draft, but then go on to cite some of Jim's text as the 
basis for saying his is the better choice.

> document about deployment.

Leaving i= as opaque is the job of a specification, not a usage document.  How 
does Jim's draft help leave i= as opaque?

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Sun, 22 Feb 2009 08:49:08 -0800

At 00:58 22-02-2009, Murray S. Kucherawy wrote:
>(d) included a "with the following changes" provision.  What changes 
>are you suggesting (or supporting)?

I'm reusing text from Eliot's and Jim's proposal.  From Section 5 of RFC 4871:

OLD

    i=  Identity of the user or agent (e.g., a mailing list manager) on
        behalf of which this message is signed (dkim-quoted-printable;
        OPTIONAL, default is an empty Local-part followed by an "@"
        followed by the domain from the "d=" tag).  The syntax is a
        standard email address where the Local-part MAY be omitted.  The
        domain part of the address MUST be the same as or a subdomain of
        the value of the "d=" tag

NEW

     i=  Identity of the user or agent (e.g., a mailing list manager) on
         behalf of which this message is signed (dkim-quoted-printable;
         OPTIONAL, default is an empty Local-part followed by an "@"
         followed by the domain from the "d=" tag).  The syntax is a
         standard email address where the Local-part MAY be omitted.  The
         domain part of the address MUST be the same as or a subdomain of
         the value of the "d=" tag.  Absent additional external information
         outside of the context of the "g=" tag, verifiers MUST treat the
         Local-part contents as an opaque string.  The Local-part and any
         "subdomain" of the "d=" value that appears in the "i=" tag are
         significant only to the signer.

OLD

  INFORMATIVE DISCUSSION: This document does not require the value
            of the "i=" tag to match the identity in any message header
            fields.  This is considered to be a verifier policy issue.
            Constraints between the value of the "i=" tag and other
            identities in other header fields seek to apply basic
            authentication into the semantics of trust associated with a
            role such as content author.  Trust is a broad and complex
            topic and trust mechanisms are subject to highly creative
            attacks.  The real-world efficacy of any but the most basic
            bindings between the "i=" value and other identities is not
            well established, nor is its vulnerability to subversion by
            an attacker.  Hence reliance on the use of these options
            should be strictly limited.  In particular, it is not at all
            clear to what extent a typical end-user recipient can rely on
            any assurances that might be made by successful use of the
            "i=" options.

NEW

INFORMATIVE DISCUSSION: This document does not require the value
            of the "i=" tag to match the identity in any message header
            fields.  This is considered to be a verifier policy issue.
            Although its syntax might suggest otherwise, the "i="
            value need not be in the namespace that contains the mailbox
            of the user or agent.  Constraints between the value of the
            "i=" tag and other identities in other header fields seek to
            apply basic authentication into the semantics of trust
            associated with a role such as content author.  Trust is a
            broad and complex topic and trust mechanisms are subject to
            highly creative attacks.  The real-world efficacy of any but
            the most basic bindings between the "i=" value and other
            identities is not well established, nor is its vulnerability
            to subversion by an attacker.  Hence reliance on the use of
            these options should be strictly limited.  In particular, it
            is not at all clear to what extent a typical end-user recipient
            can rely on any assurances that might be made by successful use
            of the "i=" options.

Regards,
-sm

---

From: Eliot Lear <[email-masked]>
Date: Sun, 22 Feb 2009 21:30:02 +0100

> them range from silly to obvious.

Right, which is something I believe the RFC-Editor intended to fix.  
Neither silly nor obvious are suitable.  If there truly is confusion, 
that's a more appropriate point.

> future.  You imply there is something bad about this, whereas it's inherent.

Allow me: thus far the interoperability issue is related to the 
relationship between i= and d=.  Nobody has demonstrated anything more 
than that.  You've decided that it is necessary for there to be a single 
primary output.  That goes beyond addressing the confusion.  QED.

> basis for saying his is the better choice.

That is what some of us call "a comparison".

> does Jim's draft help leave i= as opaque?

Dave, you're (repeatedly) missing the point, as you like to say to me.  
Operational experience can provide guidance as to how best i= should be 
used, and whether you are in fact correctly defining a single primary 
output.  It's called "slow as you go", for new areas of work.

Eliot

---

From: SM <[email-masked]>
Date: Sun, 22 Feb 2009 13:03:45 -0800

Hi Dave,
At 07:29 22-02-2009, Dave CROCKER wrote:
>First, you say "generally" which means that an errata is not 
>disqualified by being controversial.  Further, I've never heard of 
>any requirement for being non-requirement.  My own experience with 
>errata is pretty small, but I've seen them range from silly to obvious.

I am not stating that the requirement for an errata is that it must 
not be controversial.  This was merely a comment on the entire errata 
discussion.

>I don't understand this statement, if it means more than your stated 
>concern about ADSP.  FIrst, any specification is determining how 
>things will be done in the future.  Any correction (errata) to a 
>specification is modifying the specification and, therefore, also 
>determining how things will be done in the future.  You imply there 
>is something bad about this, whereas it's inherent. Please clarify.

I am not implying that there is anything bad about your proposal or 
having an erratum.  My comment (I'm not using the word concern as it 
would be too strong in this context) is that the decision to choose 
between d= and i= affects the direction of any work done on DKIM in future.

>I am reasonably certain the draft Errata makes no such 
>requirement.  At the least, Please explain.  Your quotation, above, 
>does not contain any text that makes this obvious to me.

That text is from Section 2.7 of draft-ietf-dkim-ssp-09.  Your draft 
Errata does not make such a requirement.

>It is further confusing that you cite some ADSP text as the basis 
>for your concern about the Errata draft, but then go on to cite some 
>of Jim's text as the basis for saying his is the better choice.

I did not link Jim's text to my citation of the ADSP text.  Now I see 
that it can be confusing.  I was going through the comments from 
several people to get a view of what had been discussed.  I commented 
on a specific part of Jim's proposal and then went on to explain why 
I chose (d).

>Leaving i= as opaque is the job of a specification, not a usage 
>document.  How does Jim's draft help leave i= as opaque?

I suggested some text for the errata.  The text leaves the Local-part 
of the "i=" value as opaque.

Regards,
-sm

---

From: John Levine <[email-masked]>
Date: 22 Feb 2009 22:31:47 -0000

>overhead both for signers and verifiers.

Actually, you may have to sign twice if you want to use ADSP and you
happen to use i= values that don't match the From: address, regardless
of the semantics of your i=.  Even if you intend the i= to be e-mail
addresses, they still don't have to match the From: address.  That's
why I added the note you quoted.

Nothing in the proposed errata changes that.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Sun, 22 Feb 2009 14:07:44 -0800

> them range from silly to obvious.

The IESG statement on RFC errata at
http://www.ietf.org/IESG/STATEMENTS/iesg-statement-07-30-2008.txt says,
in part:

> 7. Changes that modify the working of a protocol to something that
> might be different from the intended consensus when the document
> was approved should be either Hold for Document Update or
> Rejected. Deciding between these two depends on judgment.

That "might" in the statement sets a high bar that an erratum should be
approved only if it is clear that it doesn't change the intended
consensus.  When an erratum is controversial doesn't necessarily mean
that it differs from the intended consensus when the document was
approved, but definitely needs to be considered by whomever (Pasi?) is
the approving authority.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Sun, 22 Feb 2009 16:27:03 -0800

> approved, but definitely needs to be considered by whomever (Pasi?) is

There was absolutely no consensus that there was a single output of
the DKIM verifier. In fact, it never even came up until _after_ it
became rfc4871 -- the Interop was the first I heard Crocker going
on about this. Regardless of whether people think this is a good
or bad change it is most definitely *NOT* errata. It is a very large
change to the semantics of DKIM, and a bad one at that.

There is already a process for making substantive changes to a
proposed standard: get a community and some consensus around
the change and recycle the document as a new PS.

       Mike

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Sun, 22 Feb 2009 20:21:05 -0500

> (a) The erratum I-D [1] is ready to go. Process it.

I would have voted (b) because like Murray I believe that the errata
might be less verbose. Not having any specific recommendations I
therefore fall back to (a).

Mike

> [email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Wednesday, February 18, 2009 8:30 PM
> To: Stephen Farrell
> Cc: [email-masked]; ietf-dkim
> Subject: Re: [ietf-dkim] Consensus call on d=/i= clarification
> 
> My vote:
>

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 22 Feb 2009 18:12:14 -0800

Florian,

Hi.

If you meant this posting, on Thursday, to be a vote in the consensus call, I do 
not see your explicitly choosing one.  I think you are indicating support for 
choice (a) or (b), but it's important that you post a statement that says 
exactly what your choice is.

d/

-- 

   Dave Crocker

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 22 Feb 2009 18:43:18 -0800

Eliot Lear wrote:
>     You've decided that it is necessary for there to be a single 

A number of the latest set of posts indicate that some folks haven't read RFCX 
4871, and I don't mean "carefully". It almost looks as if they haven't read it 
at all.  Worse, the point that is constantly being ignored was proffered quite 
clearly in the Errata draft.  So it appears they haven't read that document either.

The Errata draft cites the text already in RFC 4871 that specifies a single 
output value.  The text is not subtle or hidden.  It is explicit and clear.

The requirement for specifying a single output is already specified in RFC 4871. 
  However the document failed to define which of the two candidate values is 
that output.  The Errata draft fixes this error, exactly as the Errata draft 
says it does.

Part of the requirement for having a legitimate discussion is that uncomfortable 
facts and considerations have to be dealt with in one's response.  If such data 
are ignored, then all one is doing is selling, not discussing.  That makes the 
interaction political rather than technical.

> approved, but definitely needs to be considered by whomever (Pasi?) is

Right.

So it's probably a good thing that the RFC explicitly calls for a single output 
value.  It means we had wg consensus on the intent ot specify a single output value.

That leaves no doubt that the failure to specify one was an error.

Errata fix errors.

d/

-- 

   Dave Crocker

-- 

   Dave Crocker

---

From: bat <[email-masked]>
Date: Sun, 22 Feb 2009 19:14:21 -0800

My sentiments exactly.  (a)

-- 
Brad

---

From: Michael Thomas <[email-masked]>
Date: Sun, 22 Feb 2009 19:32:38 -0800

> output value.  The text is not subtle or hidden.  It is explicit and clear.
Section 6.3:

6.3.  Interpret Results/Apply Local Policy

   It is beyond the scope of this specification to describe what actions
   a verifier system should make, but an authenticated email presents an
   opportunity to a receiving system that unauthenticated email cannot.
   Specifically, an authenticated email creates a predictable identifier
   by which other decisions can reliably be managed, such as trust and
   reputation.  Conversely, unauthenticated email lacks a reliable
   identifier that can be used to assign trust and reputation.  It is
   reasonable to treat unauthenticated email as lacking any trust and
   having no positive reputation.

What part of "beyond the scope" is so difficult to understand? DKIM
produces a large set of authenticated bits. It's not our job to rank them,
let along pick "one" winner to exclusion of all other bits. Use and
experience will pick those winners, not some ill-conceived errata
trying to rewrite history.
> The requirement for specifying a single output is already specified in RFC 4871. 
No it doesn't.
> interaction political rather than technical.

This is rich.

       Mike

---

From: Steve Atkins <[email-masked]>
Date: Sun, 22 Feb 2009 19:02:37 -0800

I'm not impressed by any of the options, but I think the erratum is  
the least bad.

So....

>    (Then specify your changes in "NEW"/"OLD" style.)

OLD:

     ... permitting a person, role or organization that owns the signing
     domain to claim responsibility

NEW:

Either

     ... permitting a signing domain to claim responsibility

or

     ... permitting a person, role or organization that owns the signing
     domain to claim responsibility, either directly or via a proxy to  
whom
     they have delegated that authority.

I don't have any strong emotional attachment to this change, and would  
be content to be counted as (a) if nobody else considers this change  
worthwhile.

Cheers,
   Steve

---

From: Jim Fenton <[email-masked]>
Date: Sun, 22 Feb 2009 19:52:36 -0800

> output value.  The text is not subtle or hidden.  It is explicit and clear.

The text you cite specifies a single purpose.  It says nothing about
there being a single output value.  There is considerable text in the
erratum trying to draw the inference that single purpose => single
output value.  But if it were that explicit and clear, this text would
not be needed.

The phrase "single output value" appears nowhere in RFC 4871.

> value.  It means we had wg consensus on the intent ot specify a single output value.

The controversy I was referring to is not limited to the issue of
specifying a single output value.

In the context of the ADSP draft, you have said that text in the draft
(which has been through WG and IETF last call) doesn't necessarily mean
that there was WG consensus, unless there had also been substantial
mailing list discussion on the topic.  Now you're saying that text in
the document is evidence of WG consensus.

You can't have it both ways.

-Jim

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 22 Feb 2009 20:29:55 -0800

Jim Fenton wrote:
> there being a single output value.  

Jim,

    "permitting a signing domain to claim responsibility"

and

    "DKIM separates the question of the identity of the signer of the message 
from the purported author of the message. In particular, a signature includes 
the identity of the signer."

do specify a single output value, because "a signing domain" and "the identity 
of the signer" do not simply state a purpose; they state and constrain a function.

Please start by considering the use of "a" and its definition.

> You can't have it both ways.

Care to cite the specific postings that you are suggesting provide some sort of 
contradictory statements?

d/

-- 

   Dave Crocker

---

From: "Chris Lewis" <[email-masked]>
Date: Sun, 22 Feb 2009 23:16:39 -0500

---

From: Michael Thomas <[email-masked]>
Date: Sun, 22 Feb 2009 21:34:08 -0800

> of the signer" do not simply state a purpose; they state and constrain a function.
Complete and utter rubbish revisionist history.  "Includes" means exactly
what it says: one piece of information in a set. Whether the verifier 
considers
that most important or even a relevant piece of information is via 6.3:

   "beyond the scope of this specification"

Section 6 is The section that describes what a Verifier
must perform. It says absolutely nothing about "output",
"primary" or anything else of the sort. It is purposefully
vague. If you don't like that, try to respin another PS;
trying to slip this in as an errata is an abuse of process.	

		Mike

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Feb 2009 11:36:49 +0000

So I think this thread seems to have descended into the
fairly pointless and unproductive category. Maybe let's
leave it there while Barry and I tot up the responses
to the concensus call and see what we (as chairs) make
of that.

In particular:

>> clearly in the Errata draft.  So it appears they haven't read that document either.

Dave - you know that a lot of the folks that disagree with you here
have read and contributed substantially to 4871. Saying otherwise
isn't helpful.

...
> This is rich.

Mike - please take a deep breath before hitting "send." Just
being annoyed on the list is also not at all helpful. There
are clearly a bunch of folks who have contributed to 4871
that do agree with the approach Dave is espousing here so
just labelling that revisionism only serves to aggravate and
won't get us closer to resolving the issue.

Thanks,
Stephen.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Feb 2009 10:12:49 -0800

> won't get us closer to resolving the issue.
They may agree with Dave, but that does not alter the fact that
what Dave is saying does not match the history or the intent of the
document. I'll add that it is Dave who is using history here to prop
up his argument. That is all the more problematic when it simply
isn't the case.

In any case, I'd like to understand the process by which a substantial
change in semantics is allowed under the rubric of "errata". IIRC,
errata did not even exist until relatively recently, so any other time
this would have required that the document be recycled. To my mind,
this looks a lot like the overall IETF process is being short circuited
in a last-man-standing kind of way. Errata should not be a vehicle to
fly under the radar with fundamental semantic changes. The "primary
output" errata clearly qualifies.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 23 Feb 2009 10:49:17 -0800

Stephen Farrell wrote:
>> change in semantics is allowed under the rubric of "errata". 
>>     
>
> I also believe "substantial change" is not allowed and wouldn't
> get the ok from our AD to use the RFC editor's errata process.
> However, at this point we're still trying to establish whether
> we have rough consensus in the WG as to the change we want to
> make.
>   

The thing is that the _rest_ of the errata is wholly uncontroversial,
and is largely the result of interoperability testing and experience.
Trying to roll in Dave's erratum is what is causing friction, and
frankly adds to confusion instead of reducing it.
> Whether that can be processed as an erratum is another day's work
> (regardless of the file name of the I-D). It is the case that a
> few people have commented that this change might not fit the
> errata process whereas others clearly think that its ok to proceed
> with it as an erratum. We'll find out which opinion is correct in
> the end, but for now, I at least don't claim to know.
>   

Wouldn't it be better to know whether something falls into the category
_first_? At this point in the WG life cycle, there are not very many people
paying attention.  I suspect that a lot of the votes to move forward is to
just correct the uncontroversial stuff. Why can't we just separate those
two instead of bundling them?

       Mike

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Feb 2009 18:28:17 +0000

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Feb 2009 11:35:13 -0800

On Feb 23, 2009, at 10:12 AM, Michael Thomas wrote:

> Stephen Farrell wrote:
>> So I think this thread seems to have descended into the fairly  
>> pointless and unproductive category. Maybe let's leave it there  
>> while Barry and I tot up the responses to the concensus call and  
>> see what we (as chairs) make of that.
>>
>> In particular:
>>
>> Michael Thomas wrote:
>>
>>> Dave CROCKER wrote:
>>>
>>>> A number of the latest set of posts indicate that some folks  
>>>> haven't read RFCX 4871, and I don't mean "carefully". It almost  
>>>> looks as if they haven't read it at all.  Worse, the point that  
>>>> is constantly being ignored was proffered quite clearly in the  
>>>> Errata draft.  So it appears they haven't read that document  
>>>> either.
>>
>> Mike - please take a deep breath before hitting "send." Just being  
>> annoyed on the list is also not at all helpful. There are clearly a  
>> bunch of folks who have contributed to 4871 that do agree with the  
>> approach Dave is espousing here so just labelling that revisionism  
>> only serves to aggravate and won't get us closer to resolving the  
>> issue.
>
> They may agree with Dave, but that does not alter the fact that what  
> Dave is saying does not match the history or the intent of the  
> In any case, I'd like to understand the process by which a  
> substantial change in semantics is allowed under the rubric of  
> "errata". IIRC, errata did not even exist until relatively recently,  
> so any other time this would have required that the document be  
> recycled. To my mind, this looks a lot like the overall IETF process  
> is being short circuited in a last-man-standing kind of way. Errata  
> should not be a vehicle to fly under the radar with fundamental  
> semantic changes. The "primary output" errata clearly qualifies.

Mike is right and has a right to be angry.  Dave's new direction for  
DKIM should require rechartering of the DKIM WG since offering  
information unrelated to other header field content was never the  
asserted or chartered goal of DKIM.

-Doug