Mark Delany wrote:
Speaking to JD Falk, actually putting selectors within heirarchical
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
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:
strikes me as less manageable (and more ugly) than:
Regardless, Peter makes a good point, we should ratify and clarify the
meaning of periods in a Selector.
to djinn up a new piece of punctuation for an aggregation point.
NOTE WELL: This list operates according to