Re: [weirds] New Unified DNR/RIR Internet-Drafts

Byron Ellacott <bje@apnic.net> Wed, 05 September 2012 07:32 UTC

Return-Path: <bje@apnic.net>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B75221F854E for <weirds@ietfa.amsl.com>; Wed, 5 Sep 2012 00:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTZWKL6ByauB for <weirds@ietfa.amsl.com>; Wed, 5 Sep 2012 00:32:20 -0700 (PDT)
Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by ietfa.amsl.com (Postfix) with ESMTP id 38DDF21F84EB for <weirds@ietf.org>; Wed, 5 Sep 2012 00:32:19 -0700 (PDT)
Received: from [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1] (unknown [IPv6:2001:dc0:a000:4:4d09:5a5d:ce5a:c2f1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 03BFFB68B6; Wed, 5 Sep 2012 17:32:17 +1000 (EST)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/signed; boundary="Apple-Mail=_53AD82EC-6F4C-4CA0-AC24-BC0D8AF581C6"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Byron Ellacott <bje@apnic.net>
In-Reply-To: <195B86F6-50C8-4708-851F-047D14E8004B@isc.org>
Date: Wed, 05 Sep 2012 17:32:17 +1000
Message-Id: <638F88FD-42E0-43DA-A3FA-2F4DB5E15F98@apnic.net>
References: <831693C2CDA2E849A7D7A712B24E257F0D675F0C@BRN1WNEXMBX01.vcorp.ad.vrsn.com> <CAL0qLwZTUoiju=HSGm1zgfQbDLC4ByNRygfz8WDyh5gjAUydtw@mail.gmail.com> <002b01cd8b12$9527fb30$bf77f190$@cn> <195B86F6-50C8-4708-851F-047D14E8004B@isc.org>
To: Francisco Obispo <fobispo@isc.org>
X-Mailer: Apple Mail (2.1278)
Cc: weirds@ietf.org
Subject: Re: [weirds] New Unified DNR/RIR Internet-Drafts
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "WHOIS-based Extensible Internet Registration Data Service \(WEIRDS\)" <weirds.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/weirds>, <mailto:weirds-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/weirds>
List-Post: <mailto:weirds@ietf.org>
List-Help: <mailto:weirds-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/weirds>, <mailto:weirds-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Sep 2012 07:32:21 -0000

Hi Francisco,

On 05/09/2012, at 1:11 PM, Francisco Obispo wrote:

> In addition, I believe that an extension mechanism for the protocol is necessary to model those unique requirements, specially in the ccTLD world. This hasn't been addressed as far as I know.

The using-http draft hasn't yet been updated to refer to the unified query and response drafts, but in section 9 there is some text to this end.

http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section-9

> Lastly, I also suggested that the response should stand on its own, that is, if someone wanted to change the transport, or even store the documents for later use, they could do so without needing the HTTP headers.

I think that the rdapConformance data structure should achieve this.  The only meta-data in headers is the response code, and the level attribute of the mime-type; the level information should be replicated in the rdapConformance information.  I agree with your reasoning here, so if I've missed something that is only stored in the HTTP headers, please let me know!

I will respond to some of Linlin's comments separately.

  Byron