hello and some initial comments

[Klaus Malorny <Klaus.Malorny@knipp.de>]

Hello,

first of all, I want to say hello and to introduce myself briefly. I am working
as a software developer for Knipp Medien und Kommunikation GmbH, which is
(beside others) in the domain name registration business. Having the imagination
of a simple but versatile domain registration protocol which is adopted by most
domain registries around the world and which eases the registration business, I
joined the list in the hope to contribute a little bit to reach this goal.


I saw that the discussion is already active for about two weeks; unfortunately,
I had no time to read all postings in the archive. I promise that I will do it,
but for now, I would like to make some general comments I prepared some days ago, 
based on Scott Hollenbeck's drafts and my own thoughts. Please excuse if 
I mention topics which have already been addressed or are currently in discussion.


Low Level Protocol Issues
-------------------------

I saw some discussions about the underlying communication protocol. I support
the idea of using one of the existing/emerging protocols, like BXXP instead of
re-inventing one.


High Level Protocol Issues
--------------------------

As I understand, the client/registrar and the server/registry interact by a
request/response model. In this context, I think it is very important to have
some kind of server initiated interaction (even if done by a polling mechanism).
In some cases, e.g. the transfer of domains between registrars, the
client/registrar needs to be informed asynchronously. In current registration
systems, this is mostly done outside of the core protocol, e.g. by sending
e-mails. This should be integrated into the protocol, both for simplification
and to benefit from other protocol features, like transaction management,
encryption.


Transaction Management
----------------------

The protocol must be able to deal with errornous states, like interruption of
the communication between the two endpoints. So the protocol should incorporate
a transaction management. It should be separated from the design of the
requests, in contrast to the way the problem was solved in the RRP: Here the
commands were designed in a way to allow the client to repeat any command which
it thinks the server might not have executed. Eventually, this may limit the
possibilities of the commands. For example, the "renew" command had to be
extended beyond to its straight forward design to avoid an unwanted extension of
the registration period in the case of a command repetition.


Internationalization/Localization
---------------------------------

Although the protocol must of course support internationalized data, e.g.
Unicode domain names or contact data, it is IMHO not required for the protocol
to support multiple languages itself, e.g. to generate error messages in
different languages. It is more important to make them machine understandable
;-), e.g. to list related information separately and identifiable. It is the
registrar's duty to generate a message suitable for human beings in whatever language
out of it, if the registrar feels the need to (see also below)


Modularisation - Object Model
-----------------------------

To have a modular concept may be an advantage -- it may be useful for registries
which require additional data or policies. If we introduce a concept of abstract
objects, with different concrete object types varying from application to
application,

- we need an object model which describes what properties an object can have and
how an object can interact with other objects

- the protocol must enable the client to get information about the existing
object types and the effect of operations on them (meta information)

- the protocol must not only enable the client to get the information about a
single object, but also the relation of it to other objects.

To give two examples: a query of a domain object should not only report the
contacts and name servers used by the domain, but also dependencies which are
hidden in current systems, e.g. name servers which lie in zone of the domain or
domains which use a certain contact.

If a registrar attempts to transfer a (domain) object, it needs to know whether
it also gets the name servers lying in the domain's zone and which they are.


Object Ownership
----------------

It must be defined how objects appear in a multi-registrar/-client environment.
Are objects owned by one client visible to others, can they be used by others?
What happens on ownership transfers, esp. with related objects? Are they cloned?


Modularisation - Error Reporting
--------------------------------

In case of a modular concept, the error reporting mechanism must have some kind
of flexibility, as operations on different object types may produce different
errors. In general, I propose some kind of classification system, at least in
the following classes

- protocol violations (e.g. bad commands, missing parameters)

- integrity violations (e.g. trying to delete a name server object which still
in use by a domain object)

- policy violations (the command is technically correct, but violates a registry
policy, e.g. modify a domain which is on-hold)


Renewal
-------

Models different to NSI/Verisign model should be supported, esp. shorter periods
and auto-renewal.



regards,

Klaus Malorny


___________________________________________________________________________
     |       |
     | knipp |                   Knipp  Medien und Kommunikation GmbH
      -------                           Technologiepark
                                        Martin-Schmeisser-Weg 9
     Dipl. Inf. Klaus Malorny           44227 Dortmund
     Klaus.Malorny@knipp.de             Tel. +49 231 9703 0