-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Wednesday, May 04, 2011 4:22 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
You want AUID and RFC5322.From added to the Output Requirements
section explicitly. At least two other participants disagree on
either technical or procedural grounds.
1) I have not seen any no arguments based on technical merits, or one
that didn't have an substantial proof. Purely procedural and even SM
showed your opinion on procedural (for BIS work) was not quite IETF
correct.
You're not reading our replies then. So here we go again, once more for the
record, one of each:
Technical: The AUID is an unvetted value. The local-part and the subdomain
could be garbage. It's inappropriate for a security protocol to return a
possibly false value in the context of saying something was cryptographically
validated. Moreover, the suggestion conflates protocol and implementation; you
can already pass the AUID, the From: field, or any other value you want to an
adjacent layer or module without requiring a change to the current wording of
3.9. The fact that some adjacent modules want or need it is not proscribed by
the current wording either, so the proposed change is actually unnecessary.
Procedural: Working group consensus to date has been to list only SDID as the
required output, along with a status (see RFC5672, and RFC4871bis WGLC
traffic). Adding a value to the list of outputs is in contradiction to the
Draft Standards advancement process (see BCP9, Section 4.1.2). Only removing
things is allowed. SM didn't correct my interpretation of BCP9, but rather
highlighted another aspect of it. What he said and what I said are both
correct.
2) There are at least four others (including myself) who agree with
the ODID proposal of both variable or one of them.
I've only seen one other that supports the RFC5322.From as being a mandatory
output. So let's tackle that now too, for the record:
Technical: The RFC5322.From is an unvetted value. The entire field could be
garbage. It's inappropriate; see above, same reasons.
Procedural: Adding a value, see above, same reasons.
So what's the compromise?
Your ball. You are the editor of the documents. Its up to you to
reduce the conflicts with proposed compromising text. Murray, I am
not your problem as much you believe, insist it is.
I encourage you to read The Tao of IETF, http://www.ietf.org/tao.html,
especially Section 5.3 which explains the role of the document editor.
Contrary to what you seem to believe, it is not our job to find a way to slip
your suggestion in to the document just because it is repeated often. Rather,
a change to a standards track document, which RFC4871 and RFC5672 are, requires
working group consensus and then similarly consensus up the chain of approval.
It is not up to us to encourage consensus or compromise for submitted ideas;
it's up to the people making the submissions. That's you here. If you want
the change, you do the legwork.
So far I don't see consensus that the RFC5322.From or AUID additions to 3.9 is
an allowable change procedurally, or a supported one technically. That's why
it's not included. You may of course appeal to the chair if you have different
information than I do, but that's where it stands.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html