Subject: [ietf-dkim] selectors, _policy._domainkey

From: Tony Hansen <[email-masked]>
Date: Wed, 12 Jul 2006 13:59:44 -0400

There's a glitch in the ABNF for s=. It refers to both "subdomain" and
"sub-domain". Both should be "sub-domain".

In section 3.6.2.1, we could reserve the use of _* labels as used in
leaves off of _domainkey for extensions related to DKIM.

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

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Jul 2006 09:06:43 -0400

Eric Allman wrote:
> Since the only other thing that can be in _domainkey (in the current
> draft at least) is selectors, and those can't have underscores, is there
> a need to do this?

SSP (as it exists now) wants to use _policy._domainkey. That's not a
selector and would be under _domainkey. Does base need to reserve space
for it?

	Tony Hansen
	[email-masked]

---

From: Eric Allman <[email-masked]>
Date: Thu, 13 Jul 2006 09:41:48 -0400

Sorry, let me try again.

Base doesn't talk about policy (any more), so the only thing it 
permits in the _domainkey subdomain is a selector.  Selectors cannot 
begin with underscores, hence there is no possible conflict (at the 
base level).

There is a possible conflict if others start to put other stuff in 
that subdomain.  There are two cases here:

* They use names that do not begin with underscore.  In that case 
they are at risk of conflicting with selectors.  I suppose we could 
add something that says "don't use this namespace for anything else 
without using an underscore", although that seems a bit obvious. 
However, it's not what you originally suggested.

* They use names that begin with underscore.  In this case there is 
no possibility that they conflict with selectors.  Then the question 
is "does -base 'own' the _domainkey namespace?"  If so, we should be 
explicit, probably adding it as another registry for IANA to manage. 
If not, then it isn't -base's place to say how others can use that 
subdomain.

I think we may be in violent agreement, since we are both forming 
these messages in the form of questions.  I don't know the answer, 
but it does seem a bit weird to (for example) define a registry that 
starts out empty (since we can't talk about _policy).  It seems like 
it would make more sense for the SSP document to discuss that.

eric

--On July 13, 2006 9:06:43 AM -0400 Tony Hansen <[email-masked]> wrote:

> Eric Allman wrote:
>>> In section 3.6.2.1, we could reserve the use of _* labels as used
>>> in leaves off of _domainkey for extensions related to DKIM.
>>
>> Since the only other thing that can be in _domainkey (in the
>> current draft at least) is selectors, and those can't have
>> underscores, is there a need to do this?
>
> selector and would be under _domainkey. Does base need to reserve
> space for it?
>
> 	Tony Hansen
> 	[email-masked]

---

From: Tony Hansen <[email-masked]>
Date: Thu, 13 Jul 2006 14:43:09 -0400

If Dave's draft-crocker-dns-attrleaf-01.txt goes forward (that creates a
registry for _* names in DNS), DKIM of course should be registered in it.

I was working under the presumption that -base owns _domainkey,
DomainKeys not withstanding.

But there could also be an argument that DKIM has only laid claim to the
names that look like atoms. And if someone wants to lay claim to another
piece of the DNS namespace, such as _policy._domainkey, that too should
be registered in the _* DNS registry.

As long as we're happy that somebody in the future *could*, unlikely as
it is, grab an _foo._domainkey and *NOT* have anything to do with DKIM,
I'll back off on my previous suggestion.

	Tony Hansen
	[email-masked]

Eric Allman wrote:
> Sorry, let me try again.
> 
> Base doesn't talk about policy (any more), so the only thing it permits
> in the _domainkey subdomain is a selector.  Selectors cannot begin with
> underscores, hence there is no possible conflict (at the base level).
> 
> There is a possible conflict if others start to put other stuff in that
> subdomain.  There are two cases here:
> 
> * They use names that do not begin with underscore.  In that case they
> are at risk of conflicting with selectors.  I suppose we could add
> something that says "don't use this namespace for anything else without
> using an underscore", although that seems a bit obvious. However, it's
> not what you originally suggested.
> 
> * They use names that begin with underscore.  In this case there is no
> possibility that they conflict with selectors.  Then the question is
> "does -base 'own' the _domainkey namespace?"  If so, we should be
> explicit, probably adding it as another registry for IANA to manage. If
> not, then it isn't -base's place to say how others can use that subdomain.
> 
> I think we may be in violent agreement, since we are both forming these
> messages in the form of questions.  I don't know the answer, but it does
> seem a bit weird to (for example) define a registry that starts out
> empty (since we can't talk about _policy).  It seems like it would make
> more sense for the SSP document to discuss that.
> 
> eric
> 
>

---

From: Eric Allman <[email-masked]>
Date: Thu, 13 Jul 2006 07:11:33 -0400

> There's a glitch in the ABNF for s=. It refers to both "subdomain"
> and "sub-domain". Both should be "sub-domain".

Thanks.  As it is I had already changed the ABNF here for -04, so it 
was already fixed.

Since the only other thing that can be in _domainkey (in the current 
draft at least) is selectors, and those can't have underscores, is 
there a need to do this?

eric