On 31/Mar/11 09:09, Murray S. Kucherawy wrote:
> On 31/Mar/11 09:03, Hilda Fontana wrote:
>> On Wed, Mar 30, 2011 at 3:52 AM, Murray S. Kucherawy wrote:
>>
>>> The consensus at our IETF 80 meeting was to divide the DKIM
>>> reporting draft into smaller documents. I believe the split
>>> should go as follows:
>>>
>>> - Defining the auth-failure report type (someone besides me
>>> should take up authorship of this, but I’ll do it if nobody
>>> steps up)
>>
>> what does it mean "Defining the auth-failure report type" with
>> DKIM, SPF and Redaction not included?
>
> One document would register the changes to DKIM and ADSP (i.e. the
> updates to the registered lists of tags and values) and one would
> register the new ARF report type. The two documents can be published
> simultaneously and refer to each other.
I should have raised this issue some months ago, but I hadn't clearly
understood the details of the splitting at the time.
One the one hand, the SPF and DKIM method-extensions include similar
text, thereby making it harder to change any of those parts. On the
other hand, the ARF extension mentions DKIM and SPF details again and
again, resulting in tight coupling with each method-extension.
Alternatively, the ARF extension could list what a method extension
must do in order to define and register the details of
failure-reporting for the specific authentication method it addresses.
I mentioned this possibility in a recent message of mines, but nobody
apparently cares. I'm confused, or perhaps it's just July...
Which of the following, if any, is correct?
A The ARF extension will gain in comprehensibility by removing
any method-specific detail. Since that's where admins may
eventually look for deciding whether to enable such feature
in their software, it is better to have it uncluttered.
BTW, why don't we also split dkim-adsp from dkim?
B The splitting is fine as it is, although not in a "normal
form". It is extremely unlikely that "iprev" or any other
method will ever need a failure reporting mechanism. The
sooner we go to testing and deploying, the better.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
