[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 wording.

However, maybe wait until I get the -01 draft out with all the changes I have been promising...

 > > Will it scale?
 > Absolutely.

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