[ietf-dkim] New Issue: protecting a domain name vs. protecting a domain tree

[robert at barclayfamily.com]

 Date: Wed, 9 Apr 2008 11:27:27 -0700
> From: dhc at dcrocker.net
> To: eric+dkim at sendmail.org
> CC: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] New Issue: protecting a domain name vs. protecting a	domain tree

> 
> I believe the Step 2 query only makes sense for ADSP in the context of covering 
> an entire sub-tree, but that ADSP does not describe the larger framework into 
> which Step 2 fits, for accomplishing that goal.
> 
> d/
> -- 
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net

Dave,

I think this misstates what that query actually accomplishes. What step 2 tells you is whether the thing you are looking at even is a domain and thus a candidate to have a domain policy. In the example Eric gave the record he mentioned would still only cover example.com. If a.b.example.com existed and you wanted to cover an entire sub-tree a.b.example.com would still need to have its own policy. Since some.thing.example.com doesn't exist I am not sure it makes sense to say it is part of that sub-tree. Even as written there is no indication that anything about the policy of example.com covers some.thing.example.com nor even any indication that there is such a policy. What the spec says is to return an error.

I think a cleaner way to express what I think you get out of step 2 (though a less efficient algorithm I suspect) would be to make step 2 step 1 and add some text around the error saying that searching for domain policies for anything that is not a domain is not within the scope of this document.

Robert

> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html

_________________________________________________________________
Use video conversation to talk face-to-face with Windows Live Messenger.
http://www.windowslive.com/messenger/connect_your_way.html?ocid=TXT_TAGLM_WL_Refresh_messenger_video_042008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20080409/3180d89d/attachment.html