>> It would be beneficial if the rfc would at least recommend one order.
...
> I tend to agree,
...
>> In short, I think the paragraph should just be removed.
>
> Agree here too.
On the theory that quick exchange might represent the beginnings of consensus,
I'll anticipate our doing a change.
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Mark Martinec
> Sent: Friday, March 11, 2011 10:09 AM
> To: IETF DKIM WG
> Subject: [ietf-dkim] draft-ietf-dkim-rfc4871bis-03: issues with 'z=
> Copied header fields'
>
> [..
Section 3.6.1. states:
k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and
verifiers MUST support the "rsa" key type. The "rsa" key type
indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey
[RFC3447] (see Sections Section 3.1 and A.1.1) is being use
Section 3.5. of draft-ietf-dkim-rfc4871bis-03 describes the 'z' tag.
I have two comments on this tag.
issue #1. When dealing with an implementation, I realized that the
specification text has nothing to say on the *order* of header fields in
the 'z' tag. It does say that any header fields may be i
Dave CROCKER wrote:
>> Not only is it confusing, it's wrong. Wildcard records work just fine when
>> the
>> wildcard is below the _domainkey label, e.g. *.foo._domainkey.example. They
>> work
>> less fine in other cases.
>
> The modified text I offered is intended to handle several coverage pr
