[ietf-dkim] selectors, _policy._domainkey

[Eric Allman]

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 <tony at att.com> 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?
>
> 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
> 	tony at att.com
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>