Subject: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt

From: [email-masked]
Date: Mon, 08 Jun 2020 08:24:46 -0700

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/

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 11 Jun 2020 17:09:29 +0200

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, [email-masked] ha scritto:
> _______________________________________________
> regext mailing list
> [email-masked]
> 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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 17 Jun 2020 13:23:45 +0000

From: regext <[email-masked]> On Behalf Of Mario Loffredo
Sent: Thursday, June 11, 2020 11:09 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt

Hi Scott,

OLD

NEW

simple data types conveyed in JSON primitive types (strings, numbers, booleans, and null)

[SAH] OK

OLD 

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"

[SAH] I'll try to fix those.

4) Section 4.1 - I would rewrite the following sentence using MUST or REQUIRED:

[SAH] Suggestion: "This data structure MUST appear 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

[SAH] Agreed. I'll strike "except for in jCard objects".

[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.

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:

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?

Best,

Mario

 
 
Abstract:

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 17 Jun 2020 19:05:01 +0200

Hi Scott,

please find my comments below.

> [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.
> [SAH] Suggestion: "This data structure MUST appear in the topmost JSON object of a response"
Agreed.
> [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.
> [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 h…

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

Mario

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 17 Jun 2020 19:35:26 +0000

> -----Original Message-----
> From: Mario Loffredo <[email-masked]>
> Sent: Wednesday, June 17, 2020 1:05 PM
> To: Hollenbeck, Scott <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]

[snip]

> > [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.

Something else to think about. RFC 7480 describes required error response codes, so for the sake of consistency I think that makes the errorCode a MUST. 7480 also says "Optionally, it MAY include additional information regarding the negative answer in the HTTP entity body". That sounds to me like the title and description can be OPTIONAL. Does that sound reasonable? What have people actually implemented?

Scott

---

From: Tom Harrison <[email-masked]>
Date: Thu, 18 Jun 2020 09:44:00 +1000

On Wed, Jun 17, 2020 at 01:23:45PM +0000, Hollenbeck, Scott wrote:
>> 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 motivation for including "except in jCard objects" originally was
to make it clear that an implementor couldn't include the lang
attribute as defined in this section in a jCard object.  To preserve
that aspect while making it clear that the language-related content
defined in jCard may be used, I think the following would work better:

    The "lang" attribute as defined in this section may appear
    anywhere in an object class or data structure, except for in jCard
    objects.  To avoid any doubt, language-related tags and parameters
    defined by jCard itself may be used in jCard objects.

though the wording is a little awkward.    

>> 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:
>> 
>> 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?

We return this value for objects that have been registered, but not
updated, mainly because distinguishing these two dates in our systems
for some objects is non-trivial.  I think the current text supports
this approach, even given the presence of the 'registration' event
type (and regardless of whether those events are included in the
response), and that the current text is fine.  (We do intend to
include 'registration' events at some point, and would prefer to
continue including 'last changed' events alongside them even when the
values are the same, so that things continue to work as they did
previously for existing clients.)

-Tom

---

From: Tom Harrison <[email-masked]>
Date: Thu, 18 Jun 2020 09:49:56 +1000

On Wed, Jun 17, 2020 at 07:35:26PM +0000, Hollenbeck, Scott wrote:
>> In my opinion "errorCode" should be required while "description"
>> should be optional. About "title", I don't have a clear position.
> 
> Something else to think about. RFC 7480 describes required error
> response codes, so for the sake of consistency I think that makes
> the errorCode a MUST. 7480 also says "Optionally, it MAY include
> additional information regarding the negative answer in the HTTP
> entity body". That sounds to me like the title and description can
> be OPTIONAL. Does that sound reasonable? What have people actually
> implemented?

We always return the error code and the title, but sometimes omit the
description.  I think making title and description optional is
reasonable, since it's better to have a partial error response body
than none.

-Tom

---

From: "Patrick Mevzek" <[email-masked]>
Date: Wed, 17 Jun 2020 20:30:57 -0500

On Wed, Jun 17, 2020, at 08:23, Hollenbeck, Scott wrote:
> 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 
> [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 
> implemented. Do servers return this value for an object that has been 
> registered, but never updated?

The problem I think is that we try to bake too much policy stuff here in the protocol.
There is no harm at the protocol level (both EPP or RDAP) if upDate/last changed is there
even right after just a create.

The EPP wording may infer that should not happen but one could argue that a creation
is a kind of modification in fact. And even without arguing I am sure some EPP
servers set upDate right after creation, probably because, even if the registrar
sees only a create, for the registry it could be internally a create + update
(like create the domain without  the nameservers and then add nameservers).
The EPP text does not specify "if the domain object has never been modified." but
by modified registry or registrar?

Take the case also of defered domain creations, those starting in pendingCreate and
allocated later. It may happen that crDate is the time at which the request came in
but upDate will then be set when the status change from pendingCreate to ok.
This status change is a modification and hence per above text could allow upDate
to be set, yet it is not a registrar triggered modification.

So I am neutral on the change to apply or not apply in RDAP specification, but I
would emphasize that whatever you do, like for EPP, you will find implementations
that add the last changed date right after creation and creation only.
This is for me more policy stuff (and good registry documentation would specify
that somewhere, even if I bet it doesn't happen), as it has no real consequences
on the protocol or interoperability matters.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Jasdip Singh <[email-masked]>
Date: Thu, 18 Jun 2020 02:18:23 +0000

On Jun 17, 2020, at 9:23 AM, Hollenbeck, Scott <shollenbeck=[email-masked]<mailto:shollenbeck=[email-masked]>> wrote:

+1

For a registered but never updated scenario, we return the “last change” date as well, equal to the “registration” date.

Jasdip

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 18 Jun 2020 13:02:36 +0000

From: Jasdip Singh <[email-masked]>
Sent: Wednesday, June 17, 2020 10:18 PM
To: Hollenbeck, Scott <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rfc7483bis-00.txt

   +1

   Jasdip

   [SAH] Thanks for the feedback, everyone. I’ll leave this one alone.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 18 Jun 2020 13:08:53 +0000

> From: Tom Harrison <[email-masked]>
> Sent: Wednesday, June 17, 2020 7:44 PM
> Cc: [email-masked]; [email-masked]
> >> with the content of some figures (e.g. Fig. 15, 17, 23, ...) where a
> >> "lang" element is included in jCard
> >>
> The motivation for including "except in jCard objects" originally was to make
> it clear that an implementor couldn't include the lang attribute as defined in
> this section in a jCard object.  To preserve that aspect while making it clear
> that the language-related content defined in jCard may be used, I think the
> following would work better:
>

Thanks for the suggestion, Tom. How about this instead?

"The "lang" attribute as defined in this section may appear anywhere in an object class or data structure, except for in jCard objects.  The "Language Tag" value described in RFC 7095 [RFC7095] MAY be used in jCard objects."

Scott

---

From: Tom Harrison <[email-masked]>
Date: Mon, 22 Jun 2020 08:14:35 +1000

On Thu, Jun 18, 2020 at 01:08:53PM +0000, Hollenbeck, Scott wrote:
>> The motivation for including "except in jCard objects" originally
>> was to make it clear that an implementor couldn't include the lang
>> attribute as defined in this section in a jCard object.  To
>> preserve that aspect while making it clear that the
>> language-related content defined in jCard may be used, I think the
>>     anywhere in an object class or data structure, except for in
>>     jCard objects.  To avoid any doubt, language-related tags and
>>     parameters defined by jCard itself may be used in jCard
>>     objects.
>> 
> "The "lang" attribute as defined in this section may appear anywhere
> in an object class or data structure, except for in jCard objects.
> The "Language Tag" value described in RFC 7095 [RFC7095] MAY be used
> in jCard objects."

I think this is fine, but the MAY could be interpreted in isolation as
implying that the document contains some more general prohibition on
the use of all of jCard's functionality, which might lead to
confusion.  It's hardly a big problem, but another suggestion:

    The "lang" attribute as defined in this section may appear
    anywhere in an object class or data structure, except for in jCard
    objects.  jCard supports similar functionality by way of the
    LANGUAGE property parameter: see Section 5.1 of [RFC6350].

Simply striking the second sentence is another option, too (so that
the only change from RFC 7483 is the addition of "as defined in this
section").  But in any event, I think your suggested text is fine.

-Tom

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 22 Jun 2020 11:14:23 +0000

> Sent: Sunday, June 21, 2020 6:15 PM
> I think this is fine, but the MAY could be interpreted in isolation as implying
> that the document contains some more general prohibition on the use of all
> of jCard's functionality, which might lead to confusion.  It's hardly a big
> problem, but another suggestion:
>
> Simply striking the second sentence is another option, too (so that the only
> change from RFC 7483 is the addition of "as defined in this section").  But in
> any event, I think your suggested text is fine.

I'll use your suggestion. I just realized, though, that we should also change "may" to "MAY" in " The "lang" attribute as defined in this section may appear". Thanks for the feedback!

Scott