Subject: [regext] FW: Incompatibility between RFC 8521 and RFC 7484

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 15 Oct 2019 15:17:30 +0000

FYI, folks. Does anyone have any thoughts on the better path forward?

Scott

-----Original Message-----
From: Andy Newton <[email-masked]>
Sent: Tuesday, October 15, 2019 9:28 AM
To: Hollenbeck, Scott <[email-masked]>; Patrick Mevzek <[email-masked]>
Subject: [EXTERNAL] Re: Incompatibility between RFC 8521 and RFC 7484

I think option 2 is better than option 1, though it is likely more work. All that said, it's probably a wg decision.

-andy
________________________________________
From: Hollenbeck, Scott <[email-masked]>
Sent: Tuesday, October 15, 2019 9:23 AM
To: Andy Newton; [email-masked]
Subject: RE: Incompatibility between RFC 8521 and RFC 7484

I can't say that I do, Andy. I agree that 8521 isn't consistent with the specification from 7484. So, we could do one of two things:

Publish errata for 8521 noting that "The bootstrap service registry for the RDAP service provider space is represented using the structure specified in Section 3 of RFC 7484" should be changed to " The bootstrap service registry for the RDAP service provider space is _modeled after_ the structure specified in Section 3 of RFC 7484", or

Publish errata for 8521 to change the contact stuff, and then work with IANA to remove the contact values.

Is there another option? Does one of these options feel better than the other?

Scott

> -----Original Message-----
> From: Andy Newton <[email-masked]>
> Sent: Monday, October 14, 2019 1:52 PM
> To: Patrick Mevzek <[email-masked]>; Hollenbeck, Scott
> <[email-masked]>
> Subject: [EXTERNAL] Re: Incompatibility between RFC 8521 and RFC 7484
>
> I think what you have discovered is what we tend to call "a problem".
> :)
>
> Yeah, there is an incompatibility here.
>
> Scott, can you remember why we put the contact information in the registry?
>
> -andy
> ________________________________________
> From: Patrick Mevzek <[email-masked]>
> Sent: Monday, October 14, 2019 11:44 AM
> To: Scott Hollenbeck; Andy Newton
> Subject: Incompatibility between RFC 8521 and RFC 7484
>
> Hello Scott and Andrew,
>
> Currently working on RDAP, I found this case that I am not sure to
> understand and may look like some discrepancy between these two RFCs.
> So I am submitting the question first to both of you as writers of RFC
> 8521 if you can let me know where I am doing a mistake.
>
>
> So RFC 8521 section 3 says:
> The bootstrap service registry for the RDAP service provider space is
>    represented using the structure specified in Section 3 of RFC 7484
>    [RFC7484].
>
> Now section 3 of RFC 7484 says:
>  Additionally, a "services" member contains the registry items
>    themselves, as an array.  Each item of the array contains a second-
>    level array, with two elements, each of them being a third-level
>    array.
>
>    Each element of the Services Array is a second-level array with two
>    elements: in order, an Entry Array and a Service URL Array.
>
>    The Entry Array contains all entries that have the same set of base
>    RDAP URLs.  The Service URL Array contains the list of base RDAP URLs
>    usable for the entries found in the Entry Array.  Elements within
>    these two arrays are not sorted in any way.
>
> </quote>
>
> Now the emphasis on "2 elements" multiple times.
>
> The formal definition in section 10.2 concurs:
>  o  services-list: a MEMBER with MEMBER-NAME "services" and MEMBER-
>       VALUE a services-array
>
>    o  services-array: an ARRAY, where each ARRAY-VALUE is a service
>
>    o  service: an ARRAY of 2 elements, where the first ARRAY-VALUE is a
>       an entry-list and the second ARRAY-VALUE is a service-uri-list
>
>    o  entry-list: an ARRAY, where each ARRAY-VALUE is an entry
>
>    o  entry: a STRING
>
>    o  service-uri-list: an ARRAY, where each ARRAY-VALUE is a service-
>       uri
>
>    o  service-uri: a STRING
>
> </quote>
>
> With that definition, if we now go back to RFC 8521 section 3 and read
> further, we get:
> The JSON output of this registry contains contact
>    information for the registered service provider identifiers,
>    alphanumeric identifiers that identify RDAP service providers, and
>    base RDAP service URLs as shown in this example.
> </quote>
> Which makes it an array with 3 elements and the example shows the same:
>
>   "services": [
>     [
>       ["[email-masked]"],
>       ["YYYY"],
>       [
>         "https://example.com/rdap/"
>       ]
>     ],
>
>
> So it looks to me that the structure used by RFC 8521 is not
> conforming to what RFC 7484 defines.
>
> What did I miss?
>
> Regards from Cayman Islands,
>
> --
>   Patrick Mevzek
>   [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Wed, 16 Oct 2019 01:01:59 -0500

> FYI, folks. Does anyone have any thoughts on the better path forward?

Between:
1) Publish errata for 8521 noting that "The bootstrap service registry for the RDAP service provider space is represented using the structure specified in Section 3 of RFC 7484" should be changed to " The bootstrap service registry for the RDAP service provider space is _modeled after_ the structure specified in Section 3 of RFC 7484", or

and 

2) Publish errata for 8521 to change the contact stuff, and then work with IANA to remove the contact values.

I think it depends on the need or not to have contact information.

If needed:

- then option 1 applies, but I would think you need a little more explanation than
just "is _modeled after_"; this is still probably the faster solution
- or contact information could be handled elsewhere in the document,
with inspiration from other RDAP specifications, using "remarks", "notices" or 
even "links" but that would need far more changes including to 8521 and is really
more a 8521-bis than an errata. Or else just considering that for any URL given
it can still be used with the "help" query case, which should be enough as the first
step to know "who" is behind a given RDAP URL.

If not needed:

- option 2 is better but more work. Maybe interoperability issues for anyone
already implementing this RFC?

I think the contact information comes because of §3.1
So it seems useful to have, but then why not say contact information is useful
for all other bootstrap documents (domain, IPv4, IPv6, etc.) also? 
This would mean an 7484-bis, so again quite some work.

What do people having implemented RFC 8521 think about that?

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 25 Oct 2019 14:05:00 +0000

There've been no other contributions to this discussion, so I'm leaning towards the path of least work to address the issue Patrick identified. That means errata for 8521 to note that the structure of the registry is based on the structure from 7484, but it includes the additional contact information.

Scott

> From: regext <[email-masked]> On Behalf Of Patrick Mevzek
> Sent: Wednesday, October 16, 2019 2:02 AM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [regext] FW: Incompatibility between RFC 8521 and
> RFC 7484
>
>
>
> 1) Publish errata for 8521 noting that "The bootstrap service registry for the
> RDAP service provider space is represented using the structure specified in
> Section 3 of RFC 7484" should be changed to " The bootstrap service registry
> for the RDAP service provider space is _modeled after_ the structure
> specified in Section 3 of RFC 7484", or
>
> and
>
> - then option 1 applies, but I would think you need a little more explanation
> than just "is _modeled after_"; this is still probably the faster solution
> - or contact information could be handled elsewhere in the document, with
> inspiration from other RDAP specifications, using "remarks", "notices" or
> even "links" but that would need far more changes including to 8521 and is
> really more a 8521-bis than an errata. Or else just considering that for any
> URL given it can still be used with the "help" query case, which should be
> enough as the first step to know "who" is behind a given RDAP URL.
>
> If not needed:
>
> I think the contact information comes because of §3.1 So it seems useful to
> have, but then why not say contact information is useful for all other
> bootstrap documents (domain, IPv4, IPv6, etc.) also?
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Andrew Newton <[email-masked]>
Date: Fri, 25 Oct 2019 10:06:08 -0400

Yeah, if nobody cares that strongly then an errata will suffice.
Perhaps we can do something about this in a set of bis versions of the
specs if/when that comes about.

-andy