Hi Scott,

please find my comments below.

Il 17/06/2020 15:23, Hollenbeck, Scott ha scritto:
From: regext <regext-boun...@ietf.org> On Behalf Of Mario Loffredo
Sent: Thursday, June 11, 2020 11:09 AM
To: regext@ietf.org; internet-dra...@ietf.org; i-d-annou...@ietf.org
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt

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)

[SAH] OK

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.



[SAH] Let me suggest a different rewording: "In other words, servers are free to 
omit unrequired/optional JSON members containing registration data based on their own 
policies"

Agreed.
3) Section 3 - There are some empty lines in the text.



[SAH] I'll try to fix those.


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.



[SAH] Suggestion: "This data structure MUST appear in the topmost JSON object of a 
response"
Agreed.

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.
[SAH] Agreed. I'll strike "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?



[SAH] Agreed on the use of MAY. The text says that an error includes all three 
fields (error code, title, and description). I believe that means that all 
three are REQIUIRED.

In my opinion "errorCode" should be required while "description" should be optional. About "title", I don't have a clear position.
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?

[SAH] I think we can leave this one alone. The meaning seems clear to me since 
we also have the registration event. We could change the examples, but before I 
do that I'd like to know what people have implemented. Do servers return this 
value for an object that has been registered, but never updated?

OK. I agree with you that we should wait for other opinions.


Mario


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

Reply via email to