----- Original Message -----
From: "Duke Hillard"
Sent: Friday, March 08, 2002 4:23 PM
: The following TLDs are in the usdom.tab for analog 4.16
: but don't appear at IANA. I am guessing [...] that they
: do appear in latest version analog for sake of legacy
: logs or servers.
:
: cs = Czech Republic and Slovakia
: fx = France (European Territory)
: gb = United Kingdom
: su = Former USSR
: zr = Democratic Republic of the Congo
One of your [snipped] guesses was correct: each of the
above five ccTLDs appear in the *dom.tab files for the
latest version of Analog [5.21].
On the subject of *dom.tab files ... based on my initial
perusal of the [uk|us]dom.tab files distributed with
Analog 5.21, I have decided to go ahead and revise the
domain file with the aim of providing it to others who
might wish to use it.
At this point, I have restructured the file into separate
categories (ccTLDs, generic TLDs, etc.), added in entries
known to be missing (one ccTLD, a number of generic TLDs),
reworded a few of the descriptions associated with entries,
and begun to revise the "organization level" numbers for certain
entries, based on information from their respective registrars.
Anyway, I have a number of questions, I'm hoping someone with
more experience with the domain file and/or Stephen Turner can
lend a hand here.
(1) Is there any outside interest in the contents of the revised
file? I ask only because it might impact some lesser decisions
that have to be made about the file itself.
(2) Am I to interpret the following passage from the Analog
Web site [http://www.analog.cx/docs/domfile.html] to mean
that, given the choice of assigning a higher or lower
organization level, I ought to prefer the higher:
"There are some problems with [assigning a single level].
A few countries have organisations at both levels 2 and 3
[...] In those cases I've favoured false negatives over
false positives by using the bigger number. (Also there
is a correction which will make most of them right again:
the first component is always removed from a hostname of
three or more components.)"
I'm most interested in the "correction" mentioned - does
it really improve results at all? Is it *really* better
to be more restrictive when choosing a single "level"?
Has anyone been bitten by the finality of the present
single-value assignment for organization levels?
Getting the most out of the current single-value system
has me stumped in the face of real-world naming practices.
This is where I need a little help.
(3) There are a surprising number of ccTLDs that take a mixed
approach to "organization levels" -- a lot of cases where
the value could be 2 or 3 (or even more) with no clear
favoring of one over the other. Some generic TLDs exhibit
similar mixing.
Is there a chance, Stephen, of introducing greater flexibility
into the domain file. I was thinking that some manner of not
only accounting for the first-level component, but all possible
second-level (and so on) components might permit truer sorting
and organization identification. I don't know how this might
impact performance, but here is an example taken from one real
ccTLD, .sc [http://www.nic.sc/policies.html]:
sc Seychelles
sc.com Commercial
sc.gov Government
sc.net Network
sc.org Non-Profits
sc.edu Educational
[The above reversed to see the branching more clearly -- be
thankful I didn't select a "deeper" scheme, such as that for
traditional .us organizations. :p]
I'm working out how to best represent mixed levels of domains
in an easy-to-modify configuration file, but permitting explicit
mapping of known mixed domain groupings would:
* alleviate the need to pick one level over another;
* add more depth to reports, if chosen -- especially in
cases where the naming scheme may indicate geographic
(e.g., one .no scheme) or other meaningful distinctions;
* enhance flexibility and readability by specifying actual
naming practices rather than abstract numbers;
* allow for custom subdomain separation to identify
organizational relations accurately (e.g., bigtelco.net
offers small businesses domains like foo.bigtelco.net
where foo bears no relation to bigtelco other than
when it pays the bills; and
* permit "tiering" of domain reports by allowing users to
select identification of specific domains or only the
generic subgroups that naming practices form.
This is turning into a rant... I'm more than willing to help
collect the information on actual naming schemes (heck, I'm
already doing that now), I'd just like to know whether there
is interest and/or developer support behind an improvement in
the domain file.
As formerly-rigid grouped TLDs (.ca, .us, any ccTLD looking to
forego organization for the almighty dollar, etc.) adopt naming
schemes that allow names outside grouped categories, this seems
like an important topic to consider in making the most of Analog.
Maybe this is too much to ask?
Anyway, I hope this sparks some discussion -- I really would like
to know whether anyone out there would be interested in a modified
domain file. It may take a couple days to properly document the
changes I made, though ...
- don
+------------------------------------------------------------------------
| This is the analog-help mailing list. To unsubscribe from this
| mailing list, go to
| http://lists.isite.net/listgate/analog-help/unsubscribe.html
|
| List archives are available at
| http://www.mail-archive.com/analog-help@lists.isite.net/
| http://lists.isite.net/listgate/analog-help/archives/
| http://www.tallylist.com/archives/index.cfm/mlist.7
+------------------------------------------------------------------------
