[ietf-dkim] Misc. fairly minor issues

[Michael Thomas]

Mark Delany wrote:

>On Tue, Jul 04, 2006 at 05:17:52PM +0200, Peter Koch allegedly wrote:
>  
>
>>Well, I don't think there's a new invention necessary, just a clarification
>>whether or not the selector makes up a single label. To me it looks
>>cleaner from the protocol POV to go for a single label, while there
>>are operational counterarguments.
>>    
>>
>
>If it weren't for allowing periods in a Selector I would agree that a
>Selector should be treated as a single label.
>
>But allowing a period implies some implementation counter arguments
>too. In particular the standard client libraries I've used don't allow
>you to issue queries with periods in labels. Nor as far as I can tell
>do the standard Unix command line tools.
>
>So, having a selector as a single label might have some appeal, I
>suspect that the confusion over periods would be quite significant.
>
>As far as I recall the rationale for periods was primarily
>operational. Beauty is in the eye of the beholder, but:
>
>	s1_zurich._domainkey.ibm.com
>	s2_zurich._domainkey.ibm.com
>
>strikes me as less manageable (and more ugly) than:
>
>	s1.zurich._domainkey.ibm.com
>	s2.zurich._domainkey.ibm.com
>
>
>Regardless, Peter makes a good point, we should ratify and clarify the
>meaning of periods in a Selector.
>  
>
Speaking to JD Falk, actually putting selectors within heirarchical 
subdomains could
have the interesting property of an easy way for an operator segregate 
out the "type"
of traffic certain selectors emit, and thus allow you to aggregate 
reputation to that
subdomain boundary. All out of scope for -base, of course, but leaving 
it the way we
have it now allows us to do these sorts of experiments going forward 
without having
to djinn up a new piece of punctuation for an aggregation point.

       Mike