[Ietf-not43] Constructing an all-inclusive <domain> response

[Andrew Newton]

Chris Ambler wrote:

> One of the goals of the XML whois format project being developed is to be
> able to encapsulate all of the data needed for a WHOIS response into a
> single XML output. As such, the elements and arguments of the <domain>
> element in dreg are a superset of what we need. That's perfect, as we can
> leave those elements that we don't need either nil, or simply unspecified
> (where allowed).

Is this a port 43 nicname/whois thing?  Or are you using the term 
"whois" in a more general meaning (i.e. talking about as a service 
rather than a protocol)?

> In looking at the specification, I note that entities are used for most
> items, like contacts, nameservers, and the like. They're specified using
> handles in the examples (in the entityName argument). In the WHOIS realm,
> these handles will be different for every registrar, if not completely
> nonexistent. What we need to do is be able to specify all entities within
> the response, in full, in a registrar-agnostic fashion.

Yes, the handles are most likely to be different for every registry and 
registrar.  I'm not sure about non-existent.  Most of the entities 
should have natural keys at the very least (i.e. domain name for 
<domain> and host name or IP address for <host>).  Only <contact> seems 
to be lacking one, and there a simple synthetic key can be created. 
Section 3.4 lists the different entity classes that may be used.

> It appears to me that the only way to do this is to put those records within
> the <additional> element, which seems to eliminate the usefulness of
> elements like <techicalContacts>, <registrant> and the like.

Population of the additional section is dependent on the operator.  It 
is not required.  When populated, it does stop a requery by the client. 
  For the client, it gives the distinction between the data queried and 
the data referenced by the data queried.  This is an important 
distinction when dealing with non-text UI's.

> Why can't a (or any number of) <dreg:contact> element(s) be contained within
> <technicalContacts> or <registrant> or other such elements? Why must one use
> <iris:entity> elements when the more specific elements are expected?

It is done primarily for normalization reasons.  One of the early 
versions of IRIS (probably -00) did exactly this, and I quickly 
discovered what a pain it was to deal with denormalized entities on the 
client side.  I got to strip out a lot of code for -03 because of this.

Admittedly, this may seem non-obvious at first.  But when you get into 
cases where one contact object is referenced by multiple domains or 
where the data must be juggled in the UI (such as in a tree widget), 
this is extremely beneficial and stops the client from having to intuit 
the return values.

-andy