RE: [sitefinder-tech-discuss] Pseudo code please

[Martin Hannigan <...>]

I'd like to agree to disagree on the user experience. 

Most people I talk to say "Veri" WHO? gTLD what? .com/.net you mean MSN?
and don't know or care what happens when a domain doesn't exist. I've run
this topically past a fairly decent sized group of people, even some
strangers
over a Guinness, and most are clueless.

Heh. Cost me a date in one case. I should've had my priorities
straight on that one. ;)


-M



> -----Original Message-----
> From: Owen DeLong [mailto:owen@delong.com]
> Sent: Thursday, October 23, 2003 6:53 PM
> To: Andrew Newton; Kee Hinckley
> Cc: sitefinder-tech-discuss@lists.elistx.com
> Subject: Re: [sitefinder-tech-discuss] Pseudo code please
> 
> 
> > To be clear:  you have internal applications that have one 
> code path for
> > .com and .net and a separate code path for .biz, .edu, 
> etc...?  This raises a bunch of questions:  Not that it 
> happens all that often, but what do you do when new TLD's 
> come on-line?  And where are you getting your spec on the TLD 
> structure?  What are you doing for the ccTLD's?
> >
> No.  I have applications (internal and otherwise) which are 
> not currently impacted by
> activities in other domains which have chosen to implement 
> wildcards.  They have
> the same code path, but, due to usage patterns and other 
> issues, the results of
> wildcards in those domains are not problematic.  Whether you 
> like it or not,
> user expectation of behavior is an important issue in this, 
> and, changing it without
> approval of the community within the zone is not a good idea.
> 
> It doesn't matter how many times Verisign tries to rephrase 
> the question to push
> me into a hole where I can't make this clear.  Application 
> behavior is _NOT_
> the only issue.  Expected ZONE behavior is something users 
> actually understand.
> Also, the impact of wildcards in a zone with <=1,000 
> delegated sub-zones is a
> bit less than .com or .net.  If you can't recogize that, then 
> I suggest you
> try the following experiment:
> 
>         Hand count the number of NS records in .MUSEUM.
>         Hand count the number of NS records in .US
>         Hand count the number of NS records in .COM
>         Hand count the number of NS records in .NET
> 
> >> One of the problems is that a wildcard introduces new policy into
> >> something that was previously assumed to be purely 
> technical. VeriSign's
> >> A record wildcard policy is that it provides a web site 
> and a fake mail
> >> server.  Another registry might have a completely 
> different service they
> >> make available.  How is a web browser supposed to know which is the
> >> case?  Another problem is that wildcards have side 
> effects.  VeriSign
> >> incorrectly assumed that A records were used solely in 
> order to connect
> >> to the machine in question.  Therefore they assumed that if they
> >> disallowed connections on other services, everything would be fine.
> >> That's not true.  A records are also used to determine 
> existence.  Sure,
> >> the spec doesn't require that it work. But how many of the tens of
> >> thousands of people who have written code that calls 
> gethostbyname do
> >> you think knew that?
> >
> > You'll get no argument here.  There do no appear to be 
> guidelines for this.  However, VeriSign would be willing to 
> participate in their creation.
> >
> Cool... I guess what is needed is a comment on the applicable RFC that
> reads something like:
> 
> The operator of a ZONE which contains NS records for 
> delegated sub-zones
> within that ZONE MUST NOT incorporate wildcard records into that ZONE
> without the consent of the overwhelming (>80%) majority of the points
> of authority subsidiary to said zone.
> 
> The operator of a ZONE of public trust (.edu, .org, .com, .net) which
> is operating it on behalf of ICANN/IANA in the best interests of the
> internet MUST NOT make changes to the ZONE other than as prescribed
> by ICANN/IANA.  This does not apply to sponsored TLDs where ICANN/IANA
> has turned exclusive governance of those ZONES over to the ZONE holder
> and such governance was established within the first 3 years 
> of operation
> of said ZONE.
> 
> 
> 
> Owen
> 

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.elistx.com/unsubscribe>