Subject: [weirds] Required values in JSON responses

From: Audric Schiltknecht <[email-masked]>
Date: Fri, 24 Oct 2014 09:43:43 -0400

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?

Thank you.

Audric

---

From: Andy Newton <[email-masked]>
Date: Fri, 24 Oct 2014 14:02:20 +0000

On 10/24/14, 9:43 AM, "Audric Schiltknecht"
<[email-masked]> wrote:

>Hello,
>
>I have not followed all previous discussions about this, so I may be
>missing some information regarding this issue.
>
>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
>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.
>

No, I think you found a wording glitch. I propose the following change:

OLD:

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.

-andy

---

From: Maarten Bosteels <[email-masked]>
Date: Fri, 24 Oct 2014 15:11:05 +0000

>   included JSON values containing registration data based on their

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

>
>-andy
>
>
>_______________________________________________
>weirds mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/weirds

---

From: Audric Schiltknecht <[email-masked]>
Date: Fri, 24 Oct 2014 11:22:21 -0400

> Replaced "free to not included" by "free to not include"

That looks better, indeed.

Related to the 'objectClassName' requirement, Section 5 may also need to
be changed:

   In addition to the "links" array with a self link, servers SHOULD
   provide an "objectClassName" (see Section 4.9) string in each object.

I think it is possible to completely remove this sentence, since it is
already expressed in Section 4.9 (as a REQUIRED value).

Regards,
Audric

---

From: Andy Newton <[email-masked]>
Date: Fri, 24 Oct 2014 15:55:04 +0000

>Replaced "free to not included" by "free to not include"

Thanks.

-andy

---

From: Andy Newton <[email-masked]>
Date: Fri, 24 Oct 2014 15:56:34 +0000

>already expressed in Section 4.9 (as a REQUIRED value).

I agree.

-andy