[Ietf-not43] From answer to domain

[hardie at qualcomm.com]

As I read the charter, this work is out of scope for CRISP.  Note
this line in particular:

"Backwards compatibility with existing administrative directory services
such as WHOIS is not a goal of this effort."

I recognize that what you are trying to do is a bit closer to "make WHOIS
forward compatible with CRISP", but I think the same logic applies.
The group has defined a set of requirements, and it is pretty clear
that this work does not meet those requirements.

This does not mean I want to discourage you from this work, but I would
like you to distinguish it from CRISP.  One way to do that might be to
set up a separate mailing list and provide a pointer to this list describing
the list's purpose; you might also wish to talk to the DREG schema authors
directly.

			regards,
				Ted Hardie


At 11:25 AM -0700 10/15/2003, Chris Ambler wrote:
>A small bit of history - Rick Wesson published a draft a couple of years ago
>with a simple XML format for WHOIS exchange. Essentially, an XML
>encapsulation of all of the stuff you'd want to see in WHOIS output. I took
>that draft and changed it to support what we need today. Rick took a look at
>it and said, "Hey, dreg has all of this stuff - why not just use that rather
>than make a whole new format?" That made sense to me, as the dreg schema
>does, indeed, have everything we need.
>
>The solution is a constrained one. We want to just emit domain information,
>and we want to do it in a single transmission - no extra trips to the server
>to resolve IDs or handles.
>
>As such, the solution seems to be to emit a resultSet with an answer
>containing a single domain, and an additional element with the contacts and
>nameservers and such in the same resultSet.
>
>The goal here is to create a WHOIS interchange format. Period. At Rick's
>urging, we're using dreg instead of something new, simply because they'd be,
>essentially, the same thing. The only difficulty here is in getting the data
>into a single transmission, which is made slightly challenging because of
>the normalization issue. But including the elements in the additional
>element should solve this.
>
>So the fact that we don't re-invent the wheel should mean that this makes
>sense then and there. As for the future, it allows us to be open to more of
>the features for this and future projects, and to more easily integrate our
>WHOIS output with other, larger IRIS-based projects. No?
>
>Christopher
>
>-----Original Message-----
>From: David Blacka [mailto:davidb at verisignlabs.com]
>Sent: Wednesday, October 15, 2003 11:05 AM
>To: Chris Ambler
>Cc: ietf-not43 at lists.verisignlabs.com
>Subject: Re: [Ietf-not43] From answer to domain
>
>
>On Wednesday, October 15, 2003, at 01:08  PM, Chris Ambler wrote:
>
>> 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?
>
>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    <davidb at verisignlabs.com>
>Sr. Engineer    Verisign Applied Research
>_______________________________________________
>Ietf-not43 mailing list
>Ietf-not43 at lists.verisignlabs.com
>https://lists.verisignlabs.com/mailman/listinfo/ietf-not43