RE: Organisation filtering RE: [Nms-cgi-devel] Anyone...Anyone...?

[Simon W. <es...@ou...>]

On Thu, 13 Feb 2003, Wizard wrote:

> > grep the domain for a blocked_org
> > if successful, check the tld.
> >   if generic check the second level domain
> 
> What determines "generic"? A list of gTLDs & ccTLDs? or something else?

Actually I realised that it could be simplified a bit:

domain contains a blocked_org {
  blocked_org in 2nd level {
    deny
  }else ccTLD and blocked_org in 3rd level and generic 2nd level {
    deny
  }
}
accept

This covers ccTLDs without generic 2nd levels, such as .fi and those that 
do (.uk), as well as the gTLDs.

To answer your specific question, generic as in gTLD.
 
> > The caveat would be if there were a legitimate use of, say, .com under a
> > ccTLD that uses .co with a host of aol, e.g. aol.com.uk would be
> > blocked.
> 
> That does fail on my tests, but so far it's the only scenario that I have
> found that doesn't do what I expect. Unfortunately, there are actually
> domains like that: br...@ne..., in...@ne..., ac...@ac..., etc.

A further check could be added that would force a second element into an 
Organisation role when there are only two elements.

> > I *still think* that it's too open to getting wrong though as it will
> > only work for pan global companies who have registered their name in
> > every ccTLD.
> 
> I really don't see that we can ever make this completely fool-proof, given
> what we are dealing with. So far, the *.ac.dk is the only scenario that I
> have to indicate where my test doesn't DWIM (and from what you're saying,
> yours do to). Not to say that it won't in numerous other situations, but I
> haven't seen it yet, so I'm not clear regarding your concern about it's
> workings. I understand you feel there is some issue here, and I'm not
> arguing with you, but I guess I'm just not clear on where the issue lies (or
> what the difference is).

I just think that is going to be nigh on impossible to test and/or
document it so that it makes sense to our users, that frankly struggle (in
some instances) with *very* *simple* configurations in FormMail and so on.

I think that we will end up with too many weird edge cases that will just 
confuse people and/or a maintenance nightmare of trying to code around 
them when they turn up.

I'm sorry that I've failed to convince you of the dangers I see in this
approach and the risk that we will create something that is almost
impossible to test and that will produce unpredictable results, at least
for the class of users we expect to use it.

> Perhaps, if you could patch together some code when you have a moment, I'll
> be glad to try it out. If you can't, my code is just a subroutine that can
> easily be replaced/removed prior to release (returns a 1|0).
> Let me know,
> Grant M.

You're the lead on the project and I am short of CFT so I'm reluctant to
write code that isn't going to be used. I prefer designing first and
coding second (well, third actually, after tests :) whereas you're jumping
straight into code which is I think causing some of the confusion.

Go for what you think is best and when it's ready we'll test it.

Note to all - can someone pitch in with views on this please. Am I barking 
up the wrong tree entirely ?

Simon.