draft-blanchet-regext-rdap-deployfindings.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc category="info" ipr="trust200902" docName="draft-blanchet-regext-rdap-deployfindings-05">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>

<front>
<title>RDAP Deployment Findings and Update</title>
<author initials='M.' surname="Blanchet" fullname='Marc Blanchet'>
  <organization>Viagenie</organization>
  <address>
    <postal>
      <street>246 Aberdeen</street>
      <city>Quebec</city>
      <region>QC</region>
      <code>G1R 2E1</code>
      <country>Canada</country>
    </postal>
    <email>marc.blanchet@viagenie.ca</email>
    <uri>http://viagenie.ca</uri>
  </address>
</author>
<date/>
<abstract>
<t>Registration Access Data Protocol(RDAP) is being deployed in domain and IP address registries. This document describes issues and findings while interfacing with the known server implementations and deployments. It also provides recommendations for the specifications.</t>
</abstract>
</front>
<middle>
  <section title="Introduction">
<t>While developing various tools and software related to RDAP, issues have been found and are documented below. This document should help in writing future version of the specifications and provide better conformant deployment. It is split in various sections based on where the fix should be applied. Obviously, there are different levels of severity of the issues, including nits or very minor. The actual instances and organisations running the RDAP servers where the issues were found are not listed.</t>
  </section>
<section title="IANA RDAP Registries Related Issues">
<t>This section describes issues related to the IANA non-Bootstrap registries as specified in <xref target="RFC7483"/>.</t>
    <section title="Values not Registered or Similar">
    <t>The <eref target="https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml">IANA RDAP JSON Values registry</eref> contains various values expected in JSON responses. The following table shows values not registered in the registry but seen in the field. The second column shows the possible corresponding values already registered. </t>
<t>Recommendation: implementations should replace their custom values with the registered ones, when one exist. Implementors should register their values when there is no corresponding registered one.
</t>
  <texttable>
   <preamble>Remarks Type</preamble>
   <ttcol>Unregistered Values</ttcol>
   <ttcol>Possibly Corresponding Registered Values</ttcol>
   <c>object truncated due to server policy</c><c>object truncated due to authorization</c>
   <c>Response truncated due to authorization</c><c>object truncated due to authorization</c>
   <c>Object truncated due to authorization</c><c>object truncated due to authorization</c>
   <c>object redacted due to authorization</c><c>object truncated due to authorization</c>
  </texttable>
  <texttable>
   <preamble>Event Action</preamble>
   <ttcol>Unregistered Values</ttcol>
   <ttcol>Possibly Corresponding Registered Values</ttcol>
   <c>delegation check</c><c></c>
   <c>last correct delegation check</c><c></c>
   <c>last update</c><c>last changed</c>
  </texttable>
  <texttable>
   <preamble>Status Value</preamble>
   <ttcol>Unregistered Values</ttcol>
   <ttcol>Possibly Corresponding Registered Values</ttcol>
   <c>server deleted prohibited</c><c>server delete prohibited</c>
   <c>ok</c><c>active</c>
  </texttable>
<texttable>
<preamble>Role Value</preamble>
<ttcol>Unregistered Values</ttcol>
<ttcol>Possibly Corresponding Registered Values</ttcol>
<c>owner</c><c>registrant</c>
</texttable>
<section title="Registry Entity">
<t>The (domain or IP) registry itself is currently not modeled in entities in RDAP. In an whois query for a TLD itself, the Remarks contains the URL of the registry entity (for registration information) and the whois entry of the registry is returned. In RDAP context, the RDAP server URL of the TLD registry should also be returned. Therefore, IANA RDAP server should send this data for the TLDs as part of its RDAP response.  These semantics are currently not modeled. </t>
<t>This document proposes that RDAP servers may send an entity with role "registry" in the top-level of the RDAP response. This entity would have embedded [links] to its web server ("rel": "self", "type": "text/html") and rdap server ("rel": "self", "type": "application/rdap+json").</t>
<t>IANA Action: add a new row "registry", "role" to the RDAP JSON Values registry.</t>
</section>
</section>
  <section title="RDAP Extensions not Registered">
    <t>The <eref target="https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml">IANA RDAP Extensions registry</eref> contains various extensions values expected in RDAP JSON responses in the rdapCconformance member. It is our understanding from <xref target="RFC7483"/> section 4.1 and <xref target="RFC7480"/> section 8.1 that only the prefix of the extension (i.e. "rdap_ObjectTag"), not the whole string ("rdap_objectTag_level_0"), need to be registered in the IANA registry. However, some entries in the IANA RDAP extensions registry seem to imply a 0 version as part of the registered value.</t>
<t>The following table shows values seen in the field in the first column, corresponding prefix (guessed as there is no normalized delimiter) in the second column and if the prefix is registered in IANA registry in the third column.</t>
<t>This registry may end up listing all names of all registries if each one has his own extension. Moreover, there is no normalized delimiter of the prefix in the full string, which may not help the RDAP client to parse and interpret correctly. As with <xref target="RFC6350"/>, we may instead use the First Come First Serve(FCFS) private enterprise numbers (PEN) registry to automatically have an organisation prefix defined without creating another set of org names within this registry and have the delimiter be "_" following the PEN.</t>
<t>Recommendation (short term): implementations should replace their custom values with the registered ones, when one exist. Implementors should register their values when there is no corresponding registered one.</t>
  <texttable>
   <preamble></preamble>
   <ttcol>Values Seen</ttcol>
   <ttcol>Corresponding Assumed Prefix</ttcol>
   <ttcol>Prefix Already Registered in IANA</ttcol>
   <c>rdap_objectTag_level_0</c><c>rdap_objectTag</c><c>Y</c>
   <c>fred_version_0</c><c>fred</c><c>Y</c>
   <c>rdap_openidc_level_0</c><c>rdap_openidc</c><c>N</c>
   <c>icann_rdap_technical_implementation_guide_0</c><c>icann_rdap_technical_implementation_guide</c><c>N</c>
   <c>icann_rdap_response_profile_0</c><c>icann_rdap_response_profile</c><c>N</c>
   <c>itNic_level_0</c><c>itNic</c><c>N</c>
   <c>nicbr_level_0</c><c>nicbr</c><c>N</c>
   <c>ur_domain_check_level_0</c><c></c><c>N</c>
   <c>history_version_0</c><c></c><c>N</c>
   <c>registrar_api_0</c><c></c><c>N</c>
  </texttable>
  </section>
  </section>
  <section title="RDAP Responses">
  <t>This section discusses issues found related to RDAP responses, specified in <xref target="RFC7483"/>.</t>
<section title="Cross-origin resource sharing(CORS)">
<t>As specified in <xref target="RFC7480"/>, the HTTP "Access-Control-Allow-Origin: *" header should be included in the responses, to enable Web clients to work properly. Some RDAP servers do not set this header. RFC7480 says "it is RECOMMENDED that servers". It should be updated to "for any public Internet deployment, servers MUST".
</t>
</section>
<section title="Object Class Name empty">
<t>A non-conformant server sends the following answer, where the value of "objectClassName" is an empty string (as well as "handle" also empty). As per <xref target="RFC7483"/> section 4.9, this "objectClassName" value is required.
Extract of the seen response:
<figure><artwork>
{
  entities: [
   {
   "entities": [
     {
     "objectClassName": "",
     "handle": "",
     }
   ],
 ],
}
</artwork></figure>
</t>
</section>
<section title="Links Relation Values">
<t>
The links relation values as specified in <xref target="RFC7483"/> section 4.3 refer to <xref target="RFC5988"/> which creates the <eref target="https://www.iana.org/assignments/link-relations/link-relations.xhtml">IANA Link Relations registry</eref>. This registry contains a large number of values where most of them do not apply to the RDAP deployment. As seen with other values above that are similar to registered ones but not used, we list here the ones we have seen. It would be appropriate to further describes the main ones in the RFC so implementors focus on ones that are expected instead of picking the wrong ones in the IANA registry or to define new ones and do not register them.</t>
<texttable>
<preamble>Links Relation Values Seen</preamble>
<ttcol>Values</ttcol>
<ttcol>Registered in IANA registry</ttcol>
<c>about</c><c>Y</c>
<c>alternate</c><c>Y</c>
<c>copyright</c><c>Y</c>
<c>describedBy</c><c>Y</c>
<c>help</c><c>Y</c>
<c>related</c><c>Y</c>
<c>self</c><c>Y</c>
<c>terms-of-service</c><c>Y</c>
<c>up</c><c>Y</c>
<c>https://restOfURLRedacted</c><c>N</c>
</texttable>
<t>As shown in the table, an implementation put an URL as the value of the "rel", instead of an actual registered value.</t>
</section>
<section title="Related link pointing to self causes infinite loop">
<t>An RDAP server returns a link of "rel": "related" is pointing to itself, therefore causing the RDAP client to fetch the object again, then read the related link and then fetch again, creating an infinite loop. Extract of the seen response:
<figure><artwork>
{
  "links": [
    {
    "title": "Self",
    "rel": "self",
    "type": "application/rdap+json",
    "href": "https://rdapserver.example.com/domain/example.net"
    },
    {
    "title": "Registrar Data for this object",
    "rel": "related",
    "href": "https://rdapserver.example.com/domain/example.net",
    "type": "application/rdap+json"
    }
  ],
}
</artwork></figure>
Recommendation: do not put related link same as self. RFC7483 section 4.2 should be updated to add the following text: "A link of "rel": "related" should not have the "href" value the same as the value of "href" of link of "rel": "self".
</t>
</section>

<section title="Link without rel">
<t>An RDAP server returns a link with no "rel" property, so the client parser has no clue what is this data and what to do with it. Extract of the seen response:
<figure><artwork>
{
"links": [
  {
   title: "My Corporation",
   href: "http://mycorp.mytld"
   }
],
}
</artwork></figure>
Recommendation: Any link must have a "rel" value. RFC7483 says that only href is mandatory. RFC7483 should be updated to have both rel and href mandatory. The original text "The "href" JSON value MUST be specified." should be changed to "The "href" and "rel" JSON values MUST be specified."
</t>
</section>
<section title="Value and href for IDNs in links">
<t>An RDAP server should return a link with "rel": "self" with a href corresponding to the target URL and value as context URI. In case of idn, there are at least two possible representations of the URI: with the A-label or U-label in the URI, the latter known as IRI (<xref target="RFC3987"/>). Moreover, the query may be of a U-Label or A-Label or combination of these types of labels. Therefore, there is an ambiguity in which representation should be the canonical one sent. This also applies to any type of "rel" for links. Extract of the seen response:
<figure><artwork>
{
  "links": [
   {
   "rel": "self",
   "href": "http://myrdapserver.xn--abcd/domain/example.ULABEL"
   }
  ],
}
</artwork></figure>
Recommendation: All links of any "rel" types should always be returned in the A-Label form for IDNs in the href or value members, independent of if the query was a U-Label or A-Label or a mix. This should be added to <xref target="RFC7483"/>.
</t>
</section>

 <section title="Registrant Entity Too Deep">
   <t>An RDAP server returns the registrant entity in a subentity, which makes difficult to parse given the expectation is the registrant would be at the top level. Extract of the seen response:
<figure><artwork>
{
 entities: [ 
  { 
    "objectClassName": "entity",
    "handle": "HANDLE1",
    "roles": [ "abuse" ], 
    "vcardArray": [ ... ],
    "entities": [
       {
       "objectClassName": "entity",
       "handle": "HANDLE2",
       "roles": [ "registrant" ], 
       "vcardArray": [ ... ],
       }
    ],
],
</artwork></figure>
   Recommendation: put the registrant in the top-level entities as follows:
<figure><artwork>
{
 entities: [
  { 
    "objectClassName": "entity",
    "handle": "HANDLE1",
    "roles": [ "abuse" ],
    "vcardArray": [ ... ]
  },
  {
    "objectClassName": "entity",
    "handle": "HANDLE2",
    "roles": [ "registrant" ],
    "vcardArray": [ ... ],
  }
],
</artwork></figure>
</t>
</section>
  </section>
<section title="Queries">
 <t>This section talks about support of RFC7482 queries and the RDAP server behaviors seen.</t>
 <section title="URL encoding of :">
  <t>For RIR registries, the ip query may include an IPv6 address which then includes one or many ":". Clients may decide to do percent-encoding of the query. In one RDAP server, the server rejected the percent-encoded query of an IPv6 address. For example,
https://rdapserver.example.com/ip/2001%3Adb8%3A0%3A%3A/48 is rejected, while https://rdapserver.example.com/ip/2001:db8:0::/48 is accepted. </t>
<t>Recommendation: accept both percent-encoded queries or non-percent encoded queries.
  </t>
 </section>
</section>
<section title="Domain Registrar RDAP Server Location">
<t>The <eref target="https://www.icann.org/en/system/files/files/rdap-technical-implementation-guide-15feb19-en.pdf">ICANN RDAP Profile</eref> section 3.2 requires the domain registries who do not have registrant information (so-called thin registries) to put a specific link of "rel": "related" pointing to the domain registrar responsible for the domain being queried, so that a client can get the registrant information using a second query to the related link. However, the semantics seems ambiguous as other RDAP servers may use the "rel": "related" for other related means, but not the specific semantic of finding the registrant data. Therefore, a possible mitigation is to define a new "rel" type of "registrantInfo" (mnemonic TBD) to carry the specific semantic of registrant info.</t>
</section>
<section title="Issues related to RFC7482">
<section title="Search patterns that are not">
<t>Section 3.2.1 of <xref target="RFC7482"/> says: "domains?nsIp=ZZZZ.  ZZZZ is a search pattern representing an IPv4 [RFC1166] or IPv6 [RFC5952] address.".  Search pattern has been used throughout the document as something that can include ‘*’, while here, it does not.  The syntax statement is also misleading. Similarly, section 3.2.2 says: "nameservers?ip=YYYY YYYY is a search pattern representing an IPv4 [RFC1166] or IPv6 [RFC5952] address."
</t>
<t>Recommendation: in <xref target="RFC7482"/>, replace: "ZZZZ is a search pattern representing an IPv4" by "ZZZZ is an IPv4", "Syntax: domains?nsIp=&lt;domain search pattern&gt;" by "Syntax: domains?nsIp=&lt;nameserver IP address&gt;", "YYYY is a search pattern representing an IPv4" by "YYYY is an IPv4", "Syntax: nameservers?ip=&lt;nameserver search pattern&gt;" by "Syntax: nameservers?ip=&lt;nameserver IP address&gt;"
</t>
</section>
</section>
<section title="IANA RDAP Bootstrap Registries Related Issues">
<t>This section describes issues related to the IANA Bootstrap registries as specified in <xref target="RFC7484"/>.</t>
<section title="Missing Trailing Char in Bootstrap Registries">
<t><xref target="RFC7484"/> section 3 says: "Base RDAP URLs MUST have a trailing "/" character". However, some values in the various IANA Bootstrap registries do not have the trailing "/" character. These should be added to provide consistency.</t>
</section>
<section title="Single target value">
<t><xref target="RFC7484"/> provides a way to list multiple RDAP servers for an entry. This flexibility was designed initially to support multiple URI types, such as http: and https, and to provide some level of redundancy. However, given that security deployment policy is to use https everywhere and redundancy can be accomplished in other ways, deployment has shown that all entries in all bootstrap registries have a single target RDAP URL value. Therefore, we can consider updating the RFC to provide only one target value. However, this should be done carefully to avoid breaking current deployed clients.</t>
</section>
</section>

  <section title="Security Considerations">
     <t>Proper conformance to specifications helps security. However, no security issues have been found in the context of this draft.</t>
  </section>
  <section title="IANA Considerations">
<t>This document request IANA to add the following values to this registry. TBD. See 'IANA Action:' within the document. </t>
  </section>
  <section title="Acknowledgements">
     <t>Audric Schiltknecht, Mario Loffredo, Justin Mack, James Gould have provided input and suggestions to this document.</t>
  </section>
</middle>
<back>
  <references title="Normative References">
<?rfc include="reference.RFC.7480" ?>
<?rfc include="reference.RFC.7482" ?>
<?rfc include="reference.RFC.7483" ?>
<?rfc include="reference.RFC.7484" ?>
  </references>
  <references title="Informative References">
<?rfc include="reference.RFC.3987" ?>
<?rfc include="reference.RFC.5988" ?>
<?rfc include="reference.RFC.6350" ?>
  </references>
</back>
</rfc>