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

[Chris Ambler]

Andrew Newton Said...

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

It's a port 43 thing, but more. In essence, we're standardizing on the
<domain> element as an inter-registrar format for exchanging WHOIS data to
facilitate transfers. We're making that available, on a whitelisted basis,
to other registrars. Some of us are implementing a /xml switch in our port
43, and some of us are also making the data available via SOAP web services.
As part of this, at least here at eNom, we're also making all of our public
interfaces consume the web service as a central point of data before
reformatting the output. So, for example, our old port 43 code had lots of
database calls to gather WHOIS data. Now, it simply calls a SOAP web service
and takes the XML output, routes it through an XSLT and spits it out. Much
more efficient, and much easier to maintain.

So the key is that all data needed must be encapsulated in the <domain>
element without the need for another trip to the service. Hence, the issue.

I hope that gives you a clear idea of what we're doing.

>Yes, the handles are most likely to be different for every registry and 
>registrar.  I'm not sure about non-existent.  

The point being that they're irrelevant for WHOIS output. We want to output
the actual data, not the handles. Sure, we might include the handle for
completeness' sake, but that's additional.

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

Which is the goal, yes.

So it seems to me that what I need to do is include the entities as
codified, but then also include the actual data in the <additional> element,
and then write my consumption code such that the entity is used simply to
identify which element in the <additional> area I should use for the data.

The unfortunate part is that this creates a lot of extra work for this
particular application (which is a non-trivial use of the standard).

Would it be possible to define a schema whereby entities can be replaced by
the actual elements that they would reference? An "I promise that there are
no circular references and you need not go back to the service for more
data" schema, if you will?

Perhaps an attribute on the <domain> tag called "self-contained" or some
such?

Failing that, could anyone hack an example of a self-contained <domain>
return? How would that be constructed?

Christopher