Murray, your technical *subjective* reasoning is not convincing.
First, as for procedural issues, I have come to understand for bis
work, how Hansen, Klensin and SM describes it. You do not seem to
reflect the same advice and quite often in contradiction.
In regards to AUID, the only technical *non-subjective" protocol
recommendation to consider is the one in section 3.11:
Upon successfully verifying the signature, a receive-side DKIM
verifier MUST communicate the Signing Domain Identifier (d=) to a
consuming Identity Assessor module and MAY communicate the Agent or
User Identifier (i=) if present.
It provides the non-subjective protocol technical justifications for
both outputs to be part of the output requirements. Nothing else need
to be said. Its called Software Engineering. Choosing not to include
it is a subjective implementation reason.
In regards to ODID, its a fundamental message header. Its technical
history and importance should not be something to be explained. In
DKIM, that fundamental messaging entity is reflected as the only
single header requirement for signature binding and per RFC5585,
RFC4686, RFC5017 and RFC5617 an essential part for security.
Most important of all:
DKIM can not mandate which is now a highly questionable protocol with
highly subjective information in it with an highly isolated mandate
for a mandatory single output with a MUST have requirement for a Trust
Identity Assessor without *explicitly exposing* all the minimal
outputs, especially when the default design excludes security protocol
design considerations.
Protocol implementation is whats it all about and for RFC4871bis, it
is for specific implementation design only.
If we want to exclude specific implementations, the Output
Requirements needs to be more open with "DKIM Complete" information
for receivers to better consider.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Murray S. Kucherawy wrote:
>> -----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
