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