On November 11, 2019 3:54:09 PM UTC, John Levine <jo...@taugh.com> wrote:
>In article
><CAL0qLwbo1AtJ6LG1UuSSoBC-GwjdQsc5CA2h6q5VqMxH=dx...@mail.gmail.com>
>you write:
>>Just to be clear: The policy for changes to that registry is "Expert
>>Review", but since the action that put it there was a document with
>IETF
>>consensus, I'm pretty hesitant about just approving this change based
>on a
>>formal request. I'd rather at least see some consensus discussion
>about
>>it, or even better, a revision/update to RFC8601.
>
>Hey, wait, Expert Review is supposed to be considerably looser than RFC
>Required.
>
>Since there's no danger of running out of token names, I'd encourage
>you to accept new ptypes if they have a clear spec and a plausible use
>case. In this instance, I think the description in the I-D is OK, but
>for the use case I would like some evidence that someone, somewhere is
>implementing it and doing something with the result.
I've had feature requests to include both s= Service Type (due to tlsrpt) and
t= Flags (particularly t=y (testing)). Since they are attributes of the DNS
record and not the signature, I think the proposed dns ptype would be
appropriate.
I plan to implement it in dkimpy and expose the values in dkimpy-milter. I'd
like some indication that it'll move forward first.
I think we can adequately define the ptype in the registry. I don't think we
need to have a spec. For the rest of Ale's draft, I'm not convinced a registry
entry is enough to document the proposed usage. (Speaking as alternate DE - msk
is the primary though, so this is not an attempt to override him).
msk: What do you think about the idea of approving the new ptype now (so I can
file requests for the above, well defined, DKIM result reporting enhancements)?
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
