Subject: [apps-discuss] [Editorial Errata Reported] RFC7601 (4671)

From: RFC Errata System <[email-masked]>
Date: Mon, 18 Apr 2016 09:05:54 -0700 (PDT)

The following errata report has been submitted for RFC7601,
"Message Header Field for Indicating Message Authentication Status".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=7601&eid=4671

--------------------------------------
Type: Editorial
Reported by: Ale <[email-masked]>

Section: 2.3

Original Text
-------------
   The "ptype" in the ABNF above indicates the general type of property
   being described by the result being reported, upon which the reported
   result was based.  Coupled with the "property", which is more
   specific, they indicate from which particular part of the message the
   reported data were extracted.

Corrected Text
--------------
   The "ptype" in the ABNF above indicates the general type of property
   being described by the value being reported, upon which the reported
   result was based.  Coupled with the "property", which is more
   specific, they indicate from which particular part of the message the
   reported "pvalue"s were extracted.

Notes
-----
The original text can be understood in multiple ways, depending on the meaning attributed to the term "result".  The corrected text I submit is one of the possible interpretations.  Note that if the first appearance of the term is assumed to be the ABNF "result", then ptype becomes an attribute of method, thereby setting a limit of one ptype per resinfo, as coincidentally it actually is.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7601 (draft-ietf-appsawg-rfc7001bis-11)
--------------------------------------
Title               : Message Header Field for Indicating Message Authentication Status
Publication Date    : August 2015
Author(s)           : M. Kucherawy
Category            : PROPOSED STANDARD
Source              : ART Area General Application Working Group
Area                : Applications and Real-Time
Stream              : IETF
Verifying Party     : IESG

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 18 Apr 2016 10:47:36 -0700

On Mon, Apr 18, 2016 at 9:05 AM, RFC Errata System <
[email-masked]> wrote:

> The original text can be understood in multiple ways, depending on the
> meaning attributed to the term "result".  The corrected text I submit is
> one of the possible interpretations.  Note that if the first appearance of
> the term is assumed to be the ABNF "result", then ptype becomes an
> attribute of method, thereby setting a limit of one ptype per resinfo, as
> coincidentally it actually is.
>

Though it would be nice if there was some more obvious way to disambiguate
other than renaming the tokens into non-words, I note that the quoted
strings in both the original and corrected versions refer to ABNF tokens,
however "result" is not quoted, and doesn't refer to the ABNF.

As for the correction, to be more grammatically correct, I would use:

-- BEGIN --
The "ptype" in the ABNF above indicates the general type of property being
described by the value being reported, upon which the reported result was
based.  Coupled with the "property", which is more specific, it indicates
from which particular part of the message the "pvalue" was extracted.
-- END --

Otherwise, the suggestion seems fine to me, though I disagree with the
characterization that there's a limit of one ptype per resinfo.  There's
nothing precluding the existence of a method that bases its result on two
distinct ptype/properties, or chooses to report none, for example.

-MSK