On Mon, Jul 03, 2006 at 09:34:37AM +0200, Peter Koch allegedly wrote: > On Sat, Jul 01, 2006 at 11:27:37PM +0100, Stephen Farrell wrote: > > > #2 3.1 Just checking. This part says: "Periods are allowed in selectors and > > are component separators. If keys are stored in DNS, the period defines > > sub-domain boundaries." Does that mean that the lookup for tcd.ie's foo.bar > > selector is in foo.bar_domainkey.tcd.ie? I assume so. If it means something > > else then I'm confused. > > first, I think you meant "foo.bar._domainkey.tcd.ie"? > Then, while "." is the DNS label separator, it is possible to have "." > within a label, but that needs proper escaping. Also, I'm not sure that > it works in all cases, although modern implementations should avoid those > pitfalls that arose from converting back and forth between wire and > presentation > format in earlier days. This is similar to having one of these > [EMAIL PROTECTED] addresses in the DNS SOA RNAME field. > Logically speaking, the "." in your example would really belong into the > label.
The original text could probably benefit from using more accurate DNS terminology. The intent is that the string foo.bar is valid selector syntax and that "foo" is one dns label and "bar" is another dns label. In other words, a selector is not constrained to be a single label. Back to Peter's concerns and example, I think the case is that the "." in the Selector syntax is always interpreted as a dns label separator as the syntax does not allow for that distinction between the two interpretations. To do that, we would have to invent something like "foo.bar"._domainkey syntax to mean that "foo.bar" is a single dns label or maybe foo\.bar._domainkey. That seems ugly and unnecessary - especially since DKIM already imposed constraints on the contents of labels, this seems like another acceptable constraint. I hope that's the obvious interpretation. I base that on the likelihood that a lot of people probably don't even realize you can have periods in labels. Mark. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
