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

From: chris.ambler at enom.com (Chris Ambler)
Date: Tue Oct 14 00:15:01 2003

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).

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.

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.

It seems non-optimal to have an entity with the elements, specify an
entityName attribute (using a registrar-specific handle or, in the case
where one doesn't exist, generate a unique ID), and then have to make
another query to resolve it. I note, in one of the examples, that such an
entity is specified for a <technicalContacts> element, and then codified in
a <dreg:contact> element within the <additional> element. Is this how it is
supposed to be done when the return data needs to be complete? That adds a
lot of processing on the consumer side. And in the same example, the entity
elements for name servers and the <registrant> element aren't supplied in
full at all. Is one expected to make another query for them based on the
contents of the entityName argument? For WHOIS, this isn't really an option.

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?

Once again, there is always the strong possibility that I'm missing the
obvious in my haste to both grok the specification and code an
implementation simultaneously.

Christopher

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Tue Oct 14 08:10:19 2003

> leave those elements that we don't need either nil, or simply unspecified

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)?

> 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.

> 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.

> <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