Subject: [Ietf-not43] From answer to domain

From: chris.ambler at enom.com (Chris Ambler)
Date: Wed Oct 15 13:08:58 2003

><domain> is a derivation of <result>.
>
>Keep in mind that xsd's are only the formal definition of the schema. 
>Implementations are free to use other validation methods so long as they 
>accomplish the same task.

Ah, that makes more sense.

So, in the XSD, it is codified that the Item element of the answer element,
being of type resultType, may be serialized as a simpleEntityType,
limitsType or serviceIdentificationType. I added the allowance such that it
could also be serialized as a domainType, and all works well.

Now, let's make sure I have this clear:

Once I fill in the domain element with all of my entities, I then put the
actual elements that the entities reference in the additional element,
ensuring that the entityName fields match. Correct?

Heretical question: if the XSD is just a suggestion, as you intimate, what
prevents me from breaking normalization and adding the allowance that, for
example, the technicalContacts element of the domain element may contain, in
addition to an iris:entity element, a contact element?

Okay, let's say I don't do that (because your objection will be, "yes, that
breaks normalization, and we'd prefer that not happen), but put the actual
element in the additional element... is there a procedure whereby I can push
my XSD back out as the "official XSD for using the dreg:domain inside of an
answer element for the purpose of registrar WHOIS transmission?" or some
such?

The goal being to publish that XSD as well as my sample code when we're all
done so other registrars can participate (yes, I just got the OK from eNom
to push the code and spec for this out into the public once it's working).

Christopher

---

From: davidb at verisignlabs.com (David Blacka)
Date: Wed Oct 15 14:04:42 2003

> answer element for the purpose of registrar WHOIS transmission?" or 

I might be misunderstanding this whole conversation, but it seems to me 
that you are trying to use the IRIS/DREG1 schema for some 
non-IRIS/DREG1 purpose, and that you are having some difficulties 
because of this.

Is the goal to create a WHOIS interchange format that will interoperate 
with CRISP, or is this an independent effort?  (By interoperate, I am 
thinking that there may be a desire for a registrar to use one of these 
files as the data source for an IRIS/DREG1 server).

If this is an independent effort, then you should just be using the 
DREG1 schema as a starting point.  The DREG1 schema was designed in the 
context of the IRIS architecture.  If that architecture isn't there, 
then the schema isn't going to be ideal.  In that case, you may as well 
as create your own (albeit similar) schema.

If it isn't an independent effort, then we need to make sure we 
understand how your efforts and IRIS need to interoperate.  The schemas 
are not set in stone, but we need to understand the problems before we 
can judge what changes (if any) need to be made to the schemas.

--
David Blacka    <[email-masked]>
Sr. Engineer    Verisign Applied Research