On 14/Dec/11 06:45, Murray S. Kucherawy wrote:
>> From: ietf.org On Behalf Of John R Levine
>
> [...] RFC5451 gives a standard way to report this result, so it
> makes sense to either require that it be there, or don't send a
> report at all.
>
> What about:
>
> "Syntax as specified in <xref target="AUTH-RESULTS"/>.
> Furthermore, <xref target="ARF"/> specifies this field is OPTIONAL
> and appears at most once; for this extension, this field MUST be
> present, but MUST reflect only a single authentication method's
> result."
+1, let me try to further improve that:
<t hangText="Authentication-Results:">
The syntax is as specified in <xref target="AUTH-RESULTS"/>.
While <xref target="ARF"/> specifies this field is OPTIONAL
and appears at most once, for this extension this field MUST be
present: it MUST reflect the single email authentication method
failure that is being reported, and only that.
</t>
>> Move [the rest of the paragraph] to just above section 3.1 and
>> change it to:
>>
>> A single report describes a single authentication failure.
>> Multiple reports MAY be used to report multiple failures for
>> a single message.
>
> That works.
+1, but that way we loose the correlation with the A-R field. In
addition, the document structure is not clear-cut.
Section 3.1 has a title of *New ARF Feedback Type* while it is
actually redefining header fields. Indeed, its anchor is "arf-fields".
The first two-liner paragraph is the only justification for the
section's title. It says "See Section 3.3 for details", which is
probably a typo as that reference is deceptive here --Section 3.3
defines the possible values of the new header field Auth-Failure,
whose name spells the same as the new value of Feedback-Type being
thus introduced.
I'd propose to slightly reorganize Section 3 like so:
* Change the title of current Section 3 (anchor="arf-extend") to
something like "Definition of the Extension", i.e. not just the
fields.
* Move the last subsection of Section 2 as the first one here,
changing its title and wording, e.g. as follows:
<section anchor="technologies" title="Semantics">
<t>There are technologies in email security that provide
authentication services and some that do authorization.
These are often conflated. A discussion of this that
is useful for establishing context can be found in Section
1.5.2 in <xref target="AUTH-RESULTS"/>.</t>
<t>The failures that can be reported using this extension
correspond to <xref target="AUTH-RESULTS"/>' methods appearing
in the "Email Authentication Methods" IANA registry, or parts
thereof.</t>
<t>A single report describes a single authentication failure.
Multiple reports MAY be used to report multiple failures for
a single message.</t>
</section>
* Change the title of the current Section 3.1 (anchor="arf-fields",
which would be renumbered to 3.2) to something like "Modified Header
Fields".
* Insert a new bullet for the type, e.g.
<t hangText="Feedback-Type:"> Reports formatted according to this
extension MUST have the new type "auth-failure".</t>
Please remove the last bullet from that list, Delivery-Result. There
is already a paragraph devoted to it in the current Section 3.2.2
(anchor="arf-headers-2"), where it belongs.
For the other bullets, IMHO it makes more sense to specify precisely
what value for what method should be reported in which header field,
than trying to change their 2119 status. In case we wish to defer
precise specifications to method-specific RFCs, we should defer to
them any related 2119 considerations as well.
Reported-URI is never mentioned in the document, except in the
example. Please remove it from there too.
Lastly, in the *IANA Considerations* section the names are not exact:
In Section 5.1, s/Feedback Report Feedback Type Registry/"Feedback
Report Type Values" registry/ and s/Feedback Type:/Feedback Type Name:/.
In Section 5.2, s/Feedback Report Header Names Registry/"Feedback
Report Header Fields" registry/.
_______________________________________________
marf mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/marf
