Re: [apps-discuss] I-D Action: draft-ietf-appsawg-rfc7001bis-02.txt

["Murray S. Kucherawy" <[e-mail]>]

On Sun, Feb 22, 2015 at 9:27 PM, John Levine <[e-mail]> wrote:

> Either I'm going blind, or this draft doesn't address the issues in
> errata 4201 which was the main reason we're doing this revision.  It
> needs to define the ptypes and properties for each result type.
>

My understanding of the erratum is that the definition of "header" as a
ptype is that the property will then contain a header field name, while "d"
(which is what DKIM uses to report the signing domain) is not a known
header field name.  I think that's addressed by what I just proposed to
Stephane.


> Section 2.7.1 (or some place) needs to say that for DKIM results, the
> ptype is "header" and the property for each header is the name of
> fields in the DKIM signature header with the values are the value of
> the field.
>

That's in 2.3 now, and I proposed splitting it off to 2.8.1, which aligns
it with your suggestion.


> Section 2.7.2 needs to say that for SPF results, the ptype is "spf",
> the properties are helo and mailfrom, with the values being the
> arguments to those commands, with the mailfrom value just being the
> address, not any extra keywords.  For Sender-ID, I suppose the ptype
> is sender-id and the properties are the PRA or something, but I've
> never seen a Sender-ID A-R header so I'm not sure.
>

The ptype is "header", the property is whatever header field the PRA was
pulled from, and the value is the PRA.  That's shown in the registry, which
was created by RFC5451 in Section 6.2.  That's at least what my running
code does, but that's the only implementation with which I'm familiar.

Section 2.7.3 and 2.7.4 and 2.7.5 similarly need to define the ptype
> and properties that appear for iprev and SMTP AUTH and VBR and ATPS
> and ADSP.  Again, I haven't seen any of those and I don't know what
> the running code does.
>

Same answer as above.  The registry contains the specific
method/ptype/property combinations that have been registered and what they
mean.  Many of them were first created by the IANA Considerations section
of RFC5451, but they don't have a specific bit of prose dedicated to them
beyond that.  They seemed pretty straightforward for the last two versions
to get consensus; what's changed?

-MSK