Re: [weirds] Required values in JSON responses

Andy Newton <andy@arin.net> Fri, 24 October 2014 15:55 UTC

Return-Path: <andy@arin.net>
X-Original-To: weirds@ietfa.amsl.com
Delivered-To: weirds@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B781A1A88 for <weirds@ietfa.amsl.com>; Fri, 24 Oct 2014 08:55:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4evgYDyuhq56 for <weirds@ietfa.amsl.com>; Fri, 24 Oct 2014 08:55:06 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by ietfa.amsl.com (Postfix) with ESMTP id BA4051A1AD1 for <weirds@ietf.org>; Fri, 24 Oct 2014 08:55:05 -0700 (PDT)
Received: by smtp1.arin.net (Postfix, from userid 323) id 74F8A1650CE; Fri, 24 Oct 2014 11:55:05 -0400 (EDT)
Received: from chaedge02.corp.arin.net (chaedge02.corp.arin.net [192.149.252.119]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTP id AE91C1650CB; Fri, 24 Oct 2014 11:55:04 -0400 (EDT)
Received: from CHACAS01.corp.arin.net (10.1.30.107) by chaedge02.corp.arin.net (192.149.252.119) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 24 Oct 2014 11:56:54 -0400
Received: from CHAMBX02.corp.arin.net ([fe80::905e:9b4d:2909:f55a]) by CHACAS01.corp.arin.net ([fe80::a98b:1e52:e85a:5979%13]) with mapi id 14.03.0181.006; Fri, 24 Oct 2014 11:55:04 -0400
From: Andy Newton <andy@arin.net>
To: Maarten Bosteels <maarten.bosteels@dnsbelgium.be>, Audric Schiltknecht <audric.schiltknecht@viagenie.ca>, "weirds@ietf.org" <weirds@ietf.org>
Thread-Topic: [weirds] Required values in JSON responses
Thread-Index: AQHP75CKaS8IjIzGwUKoETxvWBeEt5w/Rx6AgABWRYD//8k4gA==
Date: Fri, 24 Oct 2014 15:55:04 +0000
Message-ID: <D06FEE89.31094%andy@arin.net>
In-Reply-To: <D070383D.169DE%maartenb@dnsbelgium.be>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.7.130812
x-originating-ip: [10.1.35.138]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <B39356120AB4E547B49FCCAB9F341287@corp.arin.net>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/weirds/afYbmUY_PP86jBHDzBAeP-NvVB0
Subject: Re: [weirds] Required values in JSON responses
X-BeenThere: weirds@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 24 Oct 2014 15:55:08 -0000

On 10/24/14, 11:11 AM, "Maarten Bosteels" <maarten.bosteels@dnsbelgium.be>
wrote:

>
>
>On 24/10/14 16:02, "Andy Newton" <andy@arin.net> wrote:
>
>>On 10/24/14, 9:43 AM, "Audric Schiltknecht"
>><audric.schiltknecht@viagenie.ca> wrote:
>>
>>>Hello,
>>>
>>>I have not followed all previous discussions about this, so I may be
>>>missing some information regarding this issue.
>>>
>>>In current JSON response draft (version 10):
>>>
>>>* Section 2.1:
>>>   Clients processing JSON responses need to be prepared for values
>>>   specified in this document to be absent from a response, as no JSON
>>>   value listed is required to appear in a response.  In other words,
>>>   servers are free to not included values based on their own policies.
>>>
>>>I understand this statement as the fact that there is no REQUIRED values
>>>defined in all the document (and that in fact, even an empty JSON
>>>response is a valid response).
>>>
>>>(Also, there is a small nit: "servers are free to not included values"
>>>->
>>>"servers are free to not include values").
>>>
>>>
>>>However,
>>>* Section 4.9
>>>   An objectClassName is REQUIRED in all RDAP
>>>   response objects so that the type of the object can be interpreted.
>>>
>>>This sections states that the 'objectClassName' JSON member is REQUIRED.
>>>
>>>Furthermore,
>>>* Section 4.2:
>>>
>>>   The JSON name/values of "rel", "href", "hreflang", "title", "media",
>>>   and "type" correspond to values found in Section 5 of [RFC5988].  The
>>>   "value" JSON value is the context URI as described by [RFC5988].  The
>>>   "href" JSON value MUST be specified.  All other JSON values are
>>>   OPTIONAL.
>>>
>>>Here, the 'href' value is a MUST for 'links' array.
>>>
>>>
>>>Long story short, sections 4.2 and 4.9 both specify required values for
>>>JSON objects whereas Section 2.1 states that there is no required value.
>>>
>>>Did I miss something about that?
>>
>>No, I think you found a wording glitch. I propose the following change:
>>
>>OLD:
>>
>>   Clients processing JSON responses need to be prepared for values
>>   specified in this document to be absent from a response, as no JSON
>>   value listed is required to appear in a response.  In other words,
>>   servers are free to not included values based on their own policies.
>>
>>NEW:
>>
>>
>>   Clients processing JSON responses need to be prepared for values
>>   representing registration data specified in this document to be
>>   absent from a response.  In other words, servers are free to not
>>   included JSON values containing registration data based on their
>>   own policies.
>
>NEWER: 
>
>
>Clients processing JSON responses need to be prepared for values
>   representing registration data specified in this document to be
>   absent from a response.  In other words, servers are free to not
>   include JSON values containing registration data based on their
>   own policies.
>
>Replaced "free to not included" by "free to not include"
>
>br
>Maarten

Thanks.

-andy