Hi Scott,
please find below some possible changes to RFC7483bis.
1) Section 1.2 - I would replace the following sentence:
OLD
simple data types conveyed in JSON strings
NEW
simple data types conveyed in JSON primitive types (strings, numbers,
booleans, and null)
2) Section 2.1 - I would replace the following sentence:
OLD
In other words, servers are free to not
include JSON members containing registration data based on their own
policies.
NEW
In other words, servers are free to not
include unrequired/optional JSON members containing registration
data based on their own
policies.
3) Section 3 - There are some empty lines in the text.
4) Section 4.1 - I would rewrite the following sentence using MUST or
REQUIRED:
This data structure appears only in
the topmost JSON object of a response.
5) Section 4.4 - The following sentence seems to be inconsistent with
the content of some figures (e.g. Fig. 15, 17, 23, ...) where a "lang"
element is included in jCard
The "lang" attribute may appear anywhere in an object class or data
structure except for in jCard objects.
6) Section 6 - I would uppercase the word "may" in the following sentence:
Some non-answer responses may return entity bodies with information
that could be more descriptive.
In addition, which members of an error response are required?
7) Section 10.2.3 - The definition of "last changed" event type seems to
be inconsistent with "upDate" defined in RFC 5731,5732,5733. For
example, I report an extract from RFC5731 here in the following:
- An OPTIONAL <domain:upDate> element that contains the date and
time of the most recent domain-object modification. This element
MUST NOT be present if the domain object has never been modified.
So, should we redefine the "last changed" event accordingly? Should we
change all the examples where "last changed" date is equal to
"registration" date?
Best,
Mario
Il 08/06/2020 17:24, internet-dra...@ietf.org ha scritto:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the
IETF.
Title : JSON Responses for the Registration Data Access
Protocol (RDAP)
Authors : Scott Hollenbeck
Andy Newton
Filename : draft-ietf-regext-rfc7483bis-00.txt
Pages : 84
Date : 2020-06-08
Abstract:
This document describes JSON data structures representing
registration information maintained by Regional Internet Registries
(RIRs) and Domain Name Registries (DNRs). These data structures are
used to form Registration Data Access Protocol (RDAP) query
responses.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7483bis/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-regext-rfc7483bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rfc7483bis-00
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo
#pleasestayathome
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
