![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
On Thursday, March 19, 1998 10:52 AM, Karl Auerbach[SMTP:karl at CaveBear.com] wrote: @ @> Another place that .COM Clusters can be useful @> is when "censorship" is desired. One can imagine @> deploying a .COM Cluster that only had the Fortune @> 10,000 COMpany names in the data base. @ @Ummm, subsets are a really bad idea. That will cause asymetrical @connectivity (or rather, assymetrical resolvability of names.) @ @We should chose not to follow that path. As someone once said -- that way @lies madness. @ Yes...but some CEOs of companies make very strange decisions when confronted with Affirmative Action and EEO issues. If they do not, then they find themselves in court being asked if they considered taking steps to prevent all of the awful things from happening in the workplace and they want to make sure their answer is..."yes, we took (and paid for) all known steps..". BTW...public libraries now have a similar situation. Some people would like to see a .COM server that only has .COM names in it that could be viewed in printed publications in the library. In other words, a service bureau would start with an empty server and add .COM names based on scanning printed publications each month. If the .COM name appears in print, then it is added. Once added, it becomes part of the library's "approved list". This again gets driven by the need for library administrators to have a clear and precise way to define how a .COM name was made available. As it turns out, librarians have had a WWW-like network for years where they share reference entries. As they run across things, they enter them into a special format and libraries share the entries. This could be extended to share the lists of "approved" .COM names. Again, if libraries are willing to pay for this "service" there might be companies willing to provide the service. That is what free markets are all about. - Jim Fleming Unir Corporation IBC, Tortola, BVI
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.