-> Shared TLD Definition.
by "Rick H. Wesson"
-> Re: Regestry Management (was: Re:
http://www.newdom.com/register/structures/cgi.html)
by Michael Dillon
-> Re: NEWDOM: Shared TLD Definition.
by perry@piermont.com
-> Re: NEWDOM: Shared TLD Definition.
by "Rick H. Wesson"
-> Re: NEWDOM: Shared TLD Definition.
by perry@piermont.com
-> Re: Registry Management
by "Dave Collier-Brown"
-> Re: Registry Management
by "Richard J. Sexton"
----------------------------------------------------------------------
Date: 1 Nov 1996 08:48:21 -0800
From: perry@piermont.com
Subject: Re: Regestry Management (was: Re:
http://www.newdom.com/register/structures/cgi.html)
"Rick H. Wesson" writes:
> I think we should use CORBA, I'm working on a public domain
> implementation to go allong with a draft I'm working on for
> regestry integration.
>
> Atached is the idl that describes Contacts, Name Servers and Domains.
> You'll see that there is no mention of the length of fields. Why?
> Because there does not need to be a length.
>
> Exception handleing is very difficult using HTTP PUT/GET mehods,
> CORBA has these built in, allong with language and platform indepandance.
> If a domain name is too long the application should throw an exception
> describing the problem.
Speaking purely for me as an old programmer:
1) I don't think CORBA has transactional abilities (I may be wrong,
but...) You may find yourself needing something more general so you
can do a two-phase commit.
2) I have suspicions that database paradigms work better than
distributed object paradigms -- that is to say, you should be
looking more at SQL, less at stuff like CORBA.
Perry
----------------------------------------------------------------------
Date: 1 Nov 1996 08:48:28 -0800
From: perry@piermont.com
Subject: Re: Regestry Management (was: Re:
http://www.newdom.com/register/structures/cgi.html)
"Rick H. Wesson" writes:
> I think we should use CORBA, I'm working on a public domain
> implementation to go allong with a draft I'm working on for
> regestry integration.
>
> Atached is the idl that describes Contacts, Name Servers and Domains.
> You'll see that there is no mention of the length of fields. Why?
> Because there does not need to be a length.
>
> Exception handleing is very difficult using HTTP PUT/GET mehods,
> CORBA has these built in, allong with language and platform indepandance.
> If a domain name is too long the application should throw an exception
> describing the problem.
Speaking purely for me as an old programmer:
1) I don't think CORBA has transactional abilities (I may be wrong,
but...) You may find yourself needing something more general so you
can do a two-phase commit.
2) I have suspicions that database paradigms work better than
distributed object paradigms -- that is to say, you should be
looking more at SQL, less at stuff like CORBA.
Perry
----------------------------------------------------------------------
Date: 1 Nov 1996 09:03:42 -0800
From: perry@piermont.com
Subject: Re: Regestry Management (was: Re:
http://www.newdom.com/register/structures/cgi.html)
"Richard J. Sexton" writes:
> I'm going to admit complete ignorance to what CORBA is
> or what it does. Although I've written database engines
> nearly 20 years ago, I, in general loathe the cursed
> things and whereever possible use the filesystem
> as the database and "find" as the engine, if for
> no other reason that a guy a I knew at Informix
> thought it was a good (and funny) idea.
Unfortunately, this method isn't practical if you need a mission
critical database with locking and transactions and logs.
> >Exception handleing is very difficult using HTTP PUT/GET mehods,
> >CORBA has these built in, allong with language and platform indepandance.
> >If a domain name is too long the application should throw an exception
> >describing the problem.
>
> Um, this is not a terrific problem:
>
> "The domain name you entered:
>
> ddjsddjskjskljdlkjdl;kjsdl;kjsdldsdlkjsdlkjsljljdsd.biz
>
> is xx characters. The limit is yy characters. PLease
> go back and fix this field."
That isn't what was meant. I believe we are talking about things like
being able to handle transaction commits and automated update.
I really don't think HTTP is the right protocol, either.
Perry
----------------------------------------------------------------------
Date: 1 Nov 1996 10:09:04 -0800
From: "Rick H. Wesson"
Subject: Re: NEWDOM: Re: Regestry Management (was: Re:
http://www.newdom.com/register/structures/cgi.html)
On Nov 1, 11:47am, Perry E. Metzger wrote:
> Subject: NEWDOM: Re: Regestry Management (was: Re: http://www.newdom.com/r
> "Rick H. Wesson" writes:
> > I think we should use CORBA, I'm working on a public domain
> > implementation to go allong with a draft I'm working on for
> > regestry integration.
> >
> > Atached is the idl that describes Contacts, Name Servers and Domains.
> > You'll see that there is no mention of the length of fields. Why?
> > Because there does not need to be a length.
> >
> > Exception handleing is very difficult using HTTP PUT/GET mehods,
> > CORBA has these built in, allong with language and platform indepandance.
> > If a domain name is too long the application should throw an exception
> > describing the problem.
>
> Speaking purely for me as an old programmer:
>
> 1) I don't think CORBA has transactional abilities (I may be wrong,
> but...) You may find yourself needing something more general so you
> can do a two-phase commit.
CORBA doesnt have a two phase commit, infact it is not responsible for the
DataStore, the OODB I use is responsible and does have a two pahse commit.
CORBA is not a database, it is an interface specification.
> 2) I have suspicions that database paradigms work better than
> distributed object paradigms -- that is to say, you should be
> looking more at SQL, less at stuff like CORBA.
I look at corba to give me a common interface that I can layer on top
of anyones DB. This allows any of the regestries to implement what ever
underlying database they want and still all the regestries have the same
interface to their datastore, and anyone elses.
- -Rick
- --
Rick H. Wesson
----------------------------------------------------------------------
Date: 1 Nov 1996 10:09:39 -0800
From: "Rick H. Wesson"
Subject: Re: NEWDOM: Re: Regestry Management (was: Re:
http://www.newdom.com/register/structures/cgi.html)
On Nov 1, 11:47am, Perry E. Metzger wrote:
> Subject: NEWDOM: Re: Regestry Management (was: Re: http://www.newdom.com/r
> "Rick H. Wesson" writes:
> > I think we should use CORBA, I'm working on a public domain
> > implementation to go allong with a draft I'm working on for
> > regestry integration.
> >
> > Atached is the idl that describes Contacts, Name Servers and Domains.
> > You'll see that there is no mention of the length of fields. Why?
> > Because there does not need to be a length.
> >
> > Exception handleing is very difficult using HTTP PUT/GET mehods,
> > CORBA has these built in, allong with language and platform indepandance.
> > If a domain name is too long the application should throw an exception
> > describing the problem.
>
> Speaking purely for me as an old programmer:
>
> 1) I don't think CORBA has transactional abilities (I may be wrong,
> but...) You may find yourself needing something more general so you
> can do a two-phase commit.
CORBA doesnt have a two phase commit, infact it is not responsible for the
DataStore, the OODB I use is responsible and does have a two pahse commit.
CORBA is not a database, it is an interface specification.
> 2) I have suspicions that database paradigms work better than
> distributed object paradigms -- that is to say, you should be
> looking more at SQL, less at stuff like CORBA.
I look at corba to give me a common interface that I can layer on top
of anyones DB. This allows any of the regestries to implement what ever
underlying database they want and still all the regestries have the same
interface to their datastore, and anyone elses.
- -Rick
- --
Rick H. Wesson
----------------------------------------------------------------------
Date: 1 Nov 1996 11:32:49 -0800
From: "Richard J. Sexton"
Subject: Re: Regestry Management (was: Re:
http://www.newdom.com/register/structures/cgi.html)
At 12:03 PM 11/1/96 -0500, you wrote:
>I really don't think HTTP is the right protocol, either.
>
>Perry
Please go on...
- --
Richard J. Sexton
richard@alter.nic Debate, process, and accountability.
richard@vrx.net
----------------------------------------------------------------------
Date: 1 Nov 1996 13:42:50 -0800
From: "Rick H. Wesson"
Subject: Shared TLD Definition.
Could anyone please define a shared TLD for me?
Thanks,
- -Rick
- --
Rick H. Wesson
----------------------------------------------------------------------
Date: 1 Nov 1996 13:42:56 -0800
From: Michael Dillon
Subject: Re: Regestry Management (was: Re:
http://www.newdom.com/register/structures/cgi.html)
On Fri, 1 Nov 1996, Richard J. Sexton wrote:
> At 12:03 PM 11/1/96 -0500, you wrote:
>
>
> >I really don't think HTTP is the right protocol, either.
> >
> >Perry
>
> Please go on...
As someone who probably has similar commercial database experience to
Perry, I would like to agree with him and disagree with him.
I agree because HTTP really is not a suitable way to communicate with a
database.
I disagree because I would place the HTTP in a different position in the
architecture. If you go back in the archive of this list you will se that
I talked about a three-tiered architecture although I don't believe I used
that term.
The bottom tier would be the backend database and I would strongly
recommend using a commercial product for this since all the freeware stuf
that I know of is horrendously complex (ingres, postgres) or else it does
not handle multiuser record locking (dbm, Berkeley db and most of the
stuff on the free databases list). I would like to see a clear definition
of the interface for this database to ease a registry switching database
products and to facilitate the developpment of tools used internal to the
registry.
The second tier is where all the intelligence resides. This is where a
program vets the data and rejects incorrect, inconsistent or incomplete
transactions. Again, the interfaces to the second tier would be clearly
defined to allow multiple forms of client access. In the http scenario,
CGI scripts would work at the second tier.
The first tier is the client interface that the user interacts with. I
believe that for many uses HTTP via a web browser would be an ideal
interface here and I think that for automated access by agents the ideal
would be an application that communicates via HTTP POST transactions. Thus
the data definitions from the third tier have to work their way up to this
first tier in the form of standard HTML field names, types and lengths.
However, I think we need to maintain an email interface to the whole
registry system as well. This should not be hard because it only involves
writing a wrapper that interfaces to the second tier and could even be
accomplished by producing a wrapper that does HTTP POST transactions. It's
up to the registry how to approach this. And I believe that a telnet
interface should also be supplied. This is pretty straightforward by
supplying a shell login with /usr/bin/lynx as the shell and leveraging off
the WWW interface already created. Just make sure your pages are Lynx
enhanced.
In addition to specification of interfaces and databases, some work that I
would like to see done includes the following:
A version of Lynx that uses the typical navigation keys most modern
computers use. In other words, the 4 arrow keys would navigate through
the page on the screen and selection of a URL would be accomplished by
pressing ENTER. Without this Lynx isn't so good for a telnet interface.
A multiuser database server with record locking capabilities that
layers on top of your choice of free database. This is important to
ensure that free or low-cost registries can be viable. Since the
dbm, gdbm and Berkeley db libraries can only be effectively used by
a single process, this server will be that process and will queue
up requests from multiple clients. Since the server has exclusive
access to the database it can also enforce record locking as well.
If people generally feel that this architecture is a good idea, maybe we
should start parcelling out the elements of the shared registries to the
different tiers and mention what tier we are talking about in future
messages.
Michael Dillon - ISP & Internet Consulting
Memra Software Inc. - Fax: +1-604-546-3049
http://www.memra.com - E-mail: michael@memra.com
----------------------------------------------------------------------
Date: 1 Nov 1996 14:33:37 -0800
From: perry@piermont.com
Subject: Re: NEWDOM: Shared TLD Definition.
"Rick H. Wesson" writes:
> Could anyone please define a shared TLD for me?
In my mind, it would be a TLD administered by a large group of
registries rather than by a single registry, possibly using a shared
lock/database machine to maintain mutual consistancy. A variety of
legal models are possible.
Perry
----------------------------------------------------------------------
Date: 1 Nov 1996 14:44:51 -0800
From: "Rick H. Wesson"
Subject: Re: NEWDOM: Shared TLD Definition.
On Nov 1, 5:33pm, Perry E. Metzger wrote:
> Subject: Re: NEWDOM: Shared TLD Definition.
> "Rick H. Wesson" writes:
> > Could anyone please define a shared TLD for me?
>
> In my mind, it would be a TLD administered by a large group of
> registries rather than by a single registry, possibly using a shared
> lock/database machine to maintain mutual consistancy. A variety of
> legal models are possible.
>
Does this model still hold up if the Main database resides
on a local set of machines? It is that a set of distribueted operators
manage the system through the same interfaces. that make sthis a shared
system.
ie you are not saying 'Shared TLD' = Distributed TLD Databse? but that
its management is distributed.
- -Rick
- --
Rick H. Wesson
----------------------------------------------------------------------
Date: 1 Nov 1996 15:04:24 -0800
From: perry@piermont.com
Subject: Re: NEWDOM: Shared TLD Definition.
"Rick H. Wesson" writes:
> > > Could anyone please define a shared TLD for me?
> >
> > In my mind, it would be a TLD administered by a large group of
> > registries rather than by a single registry, possibly using a shared
> > lock/database machine to maintain mutual consistancy. A variety of
> > legal models are possible.
>
> Does this model still hold up if the Main database resides
> on a local set of machines? It is that a set of distribueted operators
> manage the system through the same interfaces. that make sthis a shared
> system.
>
> ie you are not saying 'Shared TLD' = Distributed TLD Databse? but that
> its management is distributed.
I don't think you can successfully run distributed databases above a
certain fairly small size, and besides you are dealing with
potentially mutually hostile registries and under those circumstances
designing a distribution protocol gets very hard.
I would therefore suggest that shared TLD does not mean a distributed
database, but rather multiple registries with access to a single
database run by a trusted third party, presumably one prohibited by
contract from being a registry.
Perry
----------------------------------------------------------------------
Date: 1 Nov 1996 22:20:04 -0800
From: "Dave Collier-Brown"
Subject: Re: Registry Management
Michael Dillon wrote:
| I disagree because I would place the HTTP in a different position in the
| architecture. If you go back in the archive of this list you will se that
| I talked about a three-tiered architecture although I don't believe I used
| that term.
I quite agree: I see a simple mime-like or smtp-like stream protocol
front-ended by a ``thin client'', with something quite robust
as the back end.
It's pretty easy to do a front end in html, but the four horsemen of
the apocalypse get you if you try to do anything hard across long
lines:
latency, or ``it seems to be taking a long time...
I wonder if it crashed''
partial competion, or ``It seems to have allocated me the
domain, but my name isn't in there with it''
repeated execution (stuttering) or, ``that's odd, it
said it succeeded, then it said it failed. I wonder
which is true''
(and I forget the fourth one... I'll have to read the paper again)
- --dave
----------------------------------------------------------------------
Date: 1 Nov 1996 23:00:23 -0800
From: "Richard J. Sexton"
Subject: Re: Registry Management
At 09:19 PM 11/1/96 EST, you wrote:
>Michael Dillon wrote:
>| I disagree because I would place the HTTP in a different position in the
>| architecture. If you go back in the archive of this list you will se that
>| I talked about a three-tiered architecture although I don't believe I used
>| that term.
>
> I quite agree: I see a simple mime-like or smtp-like stream protocol
>front-ended by a ``thin client'', with something quite robust
>as the back end.
>
> It's pretty easy to do a front end in html, but the four horsemen of
>the apocalypse get you if you try to do anything hard across long
>lines:
> latency, or ``it seems to be taking a long time...
> I wonder if it crashed''
> partial competion, or ``It seems to have allocated me the
> domain, but my name isn't in there with it''
> repeated execution (stuttering) or, ``that's odd, it
> said it succeeded, then it said it failed. I wonder
> which is true''
> (and I forget the fourth one... I'll have to read the paper again)
Oh piffle. I've been writing application code for 27 of my 40 years
and compared to powerline packet switched networks or RF network
programming, web apps are a breeze. Hint: LOTS of error checking.
When you get right down to it, it's a very simple database app.
- --
Richard J. Sexton
richard@Alter.NIC
