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