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(_dot_)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(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html