Re: [weirds] Response container structure

Andy Newton <andy@arin.net> Tue, 18 September 2012 02:37 UTC

Return-Path: <andy@arin.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 0CC3621F8435 for <weirds@ietfa.amsl.com>; Mon, 17 Sep 2012 19:37:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.521
X-Spam-Level:
X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599]
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 uXq73+1Ge6hy for <weirds@ietfa.amsl.com>; Mon, 17 Sep 2012 19:37:35 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id 49CFB21F8419 for <weirds@ietf.org>; Mon, 17 Sep 2012 19:37:35 -0700 (PDT)
Received: by smtp1.arin.net (Postfix, from userid 323) id A49D616520D; Mon, 17 Sep 2012 22:37:34 -0400 (EDT)
Received: from CHAXCH06.corp.arin.net (chaxch06.corp.arin.net [192.149.252.95]) by smtp1.arin.net (Postfix) with ESMTP id D786B165201; Mon, 17 Sep 2012 22:37:33 -0400 (EDT)
Received: from CHAXCH04.corp.arin.net (10.1.30.19) by CHAXCH06.corp.arin.net (192.149.252.95) with Microsoft SMTP Server (TLS) id 14.2.283.3; Mon, 17 Sep 2012 22:37:26 -0400
Received: from CHAXCH02.corp.arin.net ([169.254.2.100]) by CHAXCH04.corp.arin.net ([10.1.30.19]) with mapi id 14.02.0298.004; Mon, 17 Sep 2012 22:37:32 -0400
From: Andy Newton <andy@arin.net>
To: Byron Ellacott <bje@apnic.net>, Francisco Obispo <fobispo@isc.org>
Thread-Topic: [weirds] Response container structure
Thread-Index: AQHNlKOEMgx/JUEDdU6jax6CGftCgZeOmLwAgAEGGgD//8T7AA==
Date: Tue, 18 Sep 2012 02:37:31 +0000
Message-ID: <CC7D5502.D158%andy@arin.net>
In-Reply-To: <1A26DD8D-DAB9-42C7-A42A-960FD528D11B@apnic.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [192.149.252.97]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <80E13F66ADE2E94A87890EC5DF17866D@corp.arin.net>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "weirds@ietf.org" <weirds@ietf.org>
Subject: Re: [weirds] Response container structure
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: Tue, 18 Sep 2012 02:37:36 -0000

On 9/17/12 10:08 PM, "Byron Ellacott" <bje@apnic.net> wrote:

>If someone is willing to demonstrate that their weirds server would
>require such a flag to meet actual or reasonably likely policy
>conditions, I'd be OK with including it.  Otherwise, it's just one more
>thing client software will need to consider, and the protocol will need
>to include.

That's an interesting take. I'll posit that even if such a flag were
needed for some policy reason, another policy will pop up needing another
flag, etcŠ But like you said, if somebody can demonstrate the need...

>>Actually, yes there is a very good technical reason. Not all registries
>> wish to model all data as first class objects. This is the cause of the
>> issue of name servers being attributes on domains vs being first class
>> objects. See section 4 of Unified Response
>> 
>>(http://tools.ietf.org/html/draft-designteam-weirds-using-http-01#section
>>-9
>> ). I also see that we will have this issue with entities.
>
>(http://tools.ietf.org/html/draft-newton-weirds-unified-json-response-00#s
>ection-4)


DOH!

>I was thinking that you could just take the data you'd put inline in that
>section and move it down to an additional, but you're right in that where
>there's no handle or other identifier you'd be making up a UUID or
>something just to link the two items together, and it might be quite
>misleading to clients to have a handle that cannot be queried for
>separately.


Exactly!

>Regarding duplicated data objects, the unified response draft only has
>one entity object per entity handle.  There's no difference, that I can
>see.  It might be fractionally harder to find the particular type of
>entity you want, but one of the things we quickly see with the domain
>survey data is that the types of entities recorded is one of the most
>widely variant facets of registration data - I don't know that it's
>feasible to specify an enumeration of entity roles, and it might be hard
>to even specify a minimum set.


Agreed.

-andy