Re: initial thoughts

[Paul Hoffman / IMC <phoffman@xxxxxxx>]

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
> other.

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