Subject: [ietf-dkim] another try at my question on options in TXT records

From: Tony Hansen <[email-masked]>
Date: Mon, 20 Feb 2006 19:58:42 -0500

Since my question before was hijacked by a totally different thread, I'm
going to ask again under another thread:

We allow extra options to be specified in a DKIM-Signature header, but
do not allow extra options to be specified in a DKIM TXT record. (I
don't recall this being discussed before, but just may not remember it.)
Should we? If not, how would we do upwardly-compatible changes without
requiring multiple DNS entries for both an old and new entry?

	Tony Hansen
	[email-masked]
_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Feb 2006 17:04:25 -0800

> requiring multiple DNS entries for both an old and new entry?

I liked Arvel's response.

1. Additional options may be defined later.

2. A validator that does not recognize a particular option MUST ignore it.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to 
http://dkim.org/ietf-list-rules.html

---

From: Mark Delany <[email-masked]>
Date: Tue, 21 Feb 2006 01:34:45 +0000

> requiring multiple DNS entries for both an old and new entry?

If the spec doesn't say it, then it's an oversight. The intent has
always been to allow new tags in Selectors/policy and that existing
code should ignore unrecognized tags.

Mark.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Feb 2006 09:11:37 +0100

I've added all this fun stuff to the issue tracker.

---

From: Tony Hansen <[email-masked]>
Date: Tue, 21 Feb 2006 09:17:43 -0500

This issue came up while testing with someone else. I had left the a=
option in my DNS selector records (from an *early* version of the
draft), and their implementation choked because of the currently invalid
option.

I'm glad the consensus so far is for unrecognized options to be optional.

	Tony Hansen
	[email-masked]

Arvel Hathcock wrote:
> Yes we should.  I was under the impression that unknown options would
> simply be ignored.  That's the only way to make upwardly compatible
> change easily right?

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 21 Feb 2006 10:57:15 -0600

> I'm glad the consensus so far is for unrecognized options to be

Section 3.2 which covers the DKIM-Signature header and the DNS records 
already says "Unrecognized tags MUST be ignored" so I think we're good here.

-- 
Arvel

---

From: Tony Hansen <[email-masked]>
Date: Tue, 21 Feb 2006 17:47:59 -0500

Trying to refute the complaint I had gotten, from a person I was testing
with, about an errant field in my TXT record, I had totally missed the
wording in section 3.2. Unknown tags in the dkim-signature header are
mentioned in a couple other places, including section 3.5, but there's
nothing other than section 3.2 that deals with unknown tags in the TXT
record. Thanks for adding additional clarification.

	Tony

Eric Allman wrote:
> Actually the spec already says that unknown tags must be ignored, but it
> could be clarified.  Section 3.2 (the overview definition of tag-lists)
> says "Unrecognized tags MUST be ignored."  I've added that same sentence
> to both Section 3.5 (DKIM-Signature header field) and 3.6.1 (Textual
> representation of key).
> 
> Is there someplace I'm not seeing that says that we don't allow extra
> options in a DKIM TXT record?
> 
> eric
> 
> 
> 
> --On February 20, 2006 7:58:42 PM -0500 Tony Hansen <[email-masked]> wrote:
> 
>> Since my question before was hijacked by a totally different
>> thread, I'm going to ask again under another thread:
>>
>> We allow extra options to be specified in a DKIM-Signature header,
>> but do not allow extra options to be specified in a DKIM TXT
>> record. (I don't recall this being discussed before, but just may
>> not remember it.) Should we? If not, how would we do
>> upwardly-compatible changes without requiring multiple DNS entries
>> for both an old and new entry?
>>
>>     Tony Hansen
>>     [email-masked]