> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Hector Santos > Sent: Wednesday, May 04, 2011 4:22 PM > To: ietf-dkim@mipassoc.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
