[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: initial thoughts
At 1:48 AM +0000 4/3/03, Adam M. Costello wrote:
Couldn't you simply say that when more than one key matches, use the
longest match? It would be trickier to implement, but that's exactly
how routing tables work. It seems pretty easy to describe. Whether it
would be worth the additional complexity, I don't know.
How do others feel about this?
> > We both propose partitioning the set of admissible labels into
> > groups (bundles). Paul imagines a function that constructs the
> entire group given any member of the group, while I imagine a
> function that computes a group identifier given any member of the
> group, where the group identifier could be a single member of the
> group arbitrarily chosen to stand for the whole group. Either
> kind of function implies the same partition of the space, and both
> functions would use the same tables, but I think the group-id
> function might be easier to describe and understand.
This seems like a somewhat academic difference
Yes, it is academic, because it's possible to define the exact same
bundles either way. But people might find it difficult to wrap their
heads around the bundle-generating function and reason about it. I
know I do.
Please propose alternate wording, then. The folks on the list could
compare them and see which makes more sense. Given that they come up
with the same bundles, we obviously would want to have the clearer
However, maybe wait until I get the -01 draft out with all the
changes I have been promising...
> > Will it scale?
Suppose JPNIC decides that hiragana and katakana should block each
Er, in order to say that something doesn't scale, you need to use
real-world examples. JPNIC has already stated that they have no
intention to do this.
It is easy to come up with extreme examples for *any* protocol, then
say "if you do this a zillion times it doesn't scale". Please show
the scaling properties for typical use and, if they show that the
current proposal cannot be deployed over the long term, what changes
would be needed.
> Speaking of "scaling", your suggestion makes scaling harder. That
is, the registration process would have to include a step where
the registrant chooses some things from a list. This is much more
difficult than the registry saying "here's what you get, you can
contact us if you don't like it". Well, of course they won't like it,
but at least the process isn't blocked.
I would still call that "registrant chooses", even though the registry
is offering a default choice, because the registry still needs to be
able to store lists of visible names for registrants who ask to deviate
from the default. When I said "registry chooses", I meant that the
registrant has zero input, so that the registry could define the choice
algorithmically and omit any capability of storing lists.
Right, but you're missing the problem of time-scaling. Any automated
process that has a dependent step that includes novice end-users
deciding something that they have no expertise in will scale more
poorly than one that doesn't have the step in the control steps.
--Paul Hoffman, Director
--Internet Mail Consortium