File: rfc8977.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2787 lines) | stat: -rw-r--r-- 139,473 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8977: Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging</title>
<meta content="Mario Loffredo" name="author">
<meta content="Maurizio Martinelli" name="author">
<meta content="Scott Hollenbeck" name="author">
<meta content="
       The Registration Data Access Protocol (RDAP) does not include core functionality for clients to provide sorting and paging parameters for control of large result sets.  This omission can lead to unpredictable server processing of queries and client processing of responses.  This unpredictability can be greatly reduced if clients can provide servers with their preferences for managing large responses.  This document describes RDAP query extensions that allow clients to specify their preferences for sorting and paging result sets. 
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="RDAP" name="keyword">
<meta content="Sorting" name="keyword">
<meta content="Paging" name="keyword">
<meta content="8977" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8977.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8977" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-sorting-and-paging-20" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8977</td>
<td class="center">RDAP Sorting and Paging</td>
<td class="right">January 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Loffredo, et al.</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8977" class="eref">8977</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-01" class="published">January 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">M. Loffredo</div>
<div class="org">IIT-CNR/Registro.it</div>
</div>
<div class="author">
      <div class="author-name">M. Martinelli</div>
<div class="org">IIT-CNR/Registro.it</div>
</div>
<div class="author">
      <div class="author-name">S. Hollenbeck</div>
<div class="org">Verisign Labs</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8977</h1>
<h1 id="title">Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The Registration Data Access Protocol (RDAP) does not include core functionality for clients to provide sorting and paging parameters for control of large result sets.  This omission can lead to unpredictable server processing of queries and client processing of responses.  This unpredictability can be greatly reduced if clients can provide servers with their preferences for managing large responses.  This document describes RDAP query extensions that allow clients to specify their preferences for sorting and paging result sets.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8977">https://www.rfc-editor.org/info/rfc8977</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-conventions-used-in-this-do" class="xref">Conventions Used in This Document</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-rdap-query-parameter-specif" class="xref">RDAP Query Parameter Specification</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-sorting-and-paging-metadata" class="xref">Sorting and Paging Metadata</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.2.2.1.2.1">
                    <p id="section-toc.1-1.2.2.1.2.1.1" class="keepWithNext"><a href="#section-2.1.1" class="xref">2.1.1</a>.  <a href="#name-rdap-conformance" class="xref">RDAP Conformance</a><a href="#section-toc.1-1.2.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-count-parameter" class="xref">"count" Parameter</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-sort-parameter" class="xref">"sort" Parameter</a><a href="#section-toc.1-1.2.2.3.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.2.2.3.2.1">
                    <p id="section-toc.1-1.2.2.3.2.1.1"><a href="#section-2.3.1" class="xref">2.3.1</a>.  <a href="#name-sorting-properties-declarat" class="xref">Sorting Properties Declaration</a><a href="#section-toc.1-1.2.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="compact toc ulEmpty" id="section-toc.1-1.2.2.3.2.2">
                    <p id="section-toc.1-1.2.2.3.2.2.1"><a href="#section-2.3.2" class="xref">2.3.2</a>.  <a href="#name-representing-sorting-links" class="xref">Representing Sorting Links</a><a href="#section-toc.1-1.2.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-cursor-parameter" class="xref">"cursor" Parameter</a><a href="#section-toc.1-1.2.2.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.2.2.4.2.1">
                    <p id="section-toc.1-1.2.2.4.2.1.1"><a href="#section-2.4.1" class="xref">2.4.1</a>.  <a href="#name-representing-paging-links" class="xref">Representing Paging Links</a><a href="#section-toc.1-1.2.2.4.2.1.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-negative-answers" class="xref">Negative Answers</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-implementation-consideratio" class="xref">Implementation Considerations</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-jsonpath-operators" class="xref">JSONPath Operators</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-approaches-to-result-pagina" class="xref">Approaches to Result Pagination</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-b.1" class="xref">B.1</a>.  <a href="#name-specific-issues-raised-by-r" class="xref">Specific Issues Raised by RDAP</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.c" class="xref">Appendix C</a>.  <a href="#name-implementation-notes" class="xref">Implementation Notes</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-c.1" class="xref">C.1</a>.  <a href="#name-sorting" class="xref">Sorting</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-c.2" class="xref">C.2</a>.  <a href="#name-counting" class="xref">Counting</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-c.3" class="xref">C.3</a>.  <a href="#name-paging" class="xref">Paging</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.e" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">The availability of functionality for result sorting and paging provides benefits to both clients and servers in the implementation of RESTful services <span>[<a href="#REST" class="xref">REST</a>]</span>.  These benefits include:<a href="#section-1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-2.1">reducing the server response bandwidth requirements<a href="#section-1-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.2">improving server response time<a href="#section-1-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.3">improving query precision and, consequently, obtaining more relevant results<a href="#section-1-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.4">decreasing server query processing load<a href="#section-1-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.5">reducing client response processing time<a href="#section-1-2.5" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-3">Approaches to implementing features for result sorting and paging can be grouped into two main categories:<a href="#section-1-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-1-4">
<li id="section-1-4.1">
          <p id="section-1-4.1.1">Sorting and paging are implemented through the introduction of additional parameters in the query string (e.g., the Open Data Protocol (ODATA) <span>[<a href="#ODATA-PART1" class="xref">ODATA-PART1</a>]</span>).<a href="#section-1-4.1.1" class="pilcrow">¶</a></p>
</li>
        <li id="section-1-4.2">Information related to the number of results and the specific portion of the result set to be returned, in addition to a set of ready-made links for the result set scrolling, are inserted in the HTTP header of the request/response <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>.<a href="#section-1-4.2" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-1-5">However, there are some drawbacks associated with the use of the HTTP header.  First, the header properties cannot be set directly from a web browser.  Moreover, in an HTTP session, the information on the status (i.e., the session identifier) is usually inserted in the header or a cookie, while the information on the resource identification or the search type is included in the query string.  Finally, providing custom information through HTTP headers assumes the client has prior knowledge of the server implementation, which is widely considered a Representational State Transfer (REST) design anti-pattern.  As a result, this document describes a specification based on the use of query parameters.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">Currently, RDAP <span>[<a href="#RFC7482" class="xref">RFC7482</a>]</span> defines two query types:<a href="#section-1-6" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-1-7">
        <dt id="section-1-7.1">lookup:
</dt>
        <dd style="margin-left: 1.5em" id="section-1-7.2">the server returns only one object<a href="#section-1-7.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-1-7.3">search:
</dt>
        <dd style="margin-left: 1.5em" id="section-1-7.4">the server returns a collection of objects<a href="#section-1-7.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-1-8">While the lookup query does not raise issues regarding response size management, the search query can potentially generate a large result set that is often truncated according to server limits.  Besides, it is not possible to obtain the total number of objects found that might be returned in a search query response <span>[<a href="#RFC7483" class="xref">RFC7483</a>]</span>.  Lastly, there is no way to specify sort criteria to return the most relevant objects at the beginning of the result set.  Therefore, the client might traverse the whole result set to find the relevant objects or, due to truncation, might not find them at all.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">The specification described in this document extends RDAP query capabilities to enable result sorting and paging by adding new query parameters that can be applied to RDAP search path segments.  The service is implemented using the Hypertext Transfer Protocol (HTTP) <span>[<a href="#RFC7230" class="xref">RFC7230</a>]</span> and the conventions described in <span>[<a href="#RFC7480" class="xref">RFC7480</a>]</span>.<a href="#section-1-9" class="pilcrow">¶</a></p>
<p id="section-1-10">The implementation of the new parameters is technically feasible, as operators for counting, sorting, and paging rows are currently supported by the major relational database management systems.<a href="#section-1-10" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-conventions-used-in-this-do">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-conventions-used-in-this-do" class="section-name selfRef">Conventions Used in This Document</a>
        </h3>
<p id="section-1.1-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
    to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
          <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals,
    as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
</section>
<div id="rdap-query-parameter-specification">
<section id="section-2">
      <h2 id="name-rdap-query-parameter-specif">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-rdap-query-parameter-specif" class="section-name selfRef">RDAP Query Parameter Specification</a>
      </h2>
<p id="section-2-1">The new query parameters are <span class="bcp14">OPTIONAL</span> extensions of path segments defined in <span>[<a href="#RFC7482" class="xref">RFC7482</a>]</span>.  They are as follows:<a href="#section-2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-2">
        <dt id="section-2-2.1">"count":
</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.2">a boolean value that allows a client to request the return of the total number of objects found<a href="#section-2-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-2.3">"sort":
</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.4">a string value that allows a client to request a specific sort order for the result set<a href="#section-2-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-2.5">"cursor":
</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.6">a string value representing a pointer to a specific fixed-size portion of the result set<a href="#section-2-2.6" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-2-3">Augmented Backus-Naur Form (ABNF) <span>[<a href="#RFC5234" class="xref">RFC5234</a>]</span> is used in the following sections to describe the formal syntax of these new parameters.<a href="#section-2-3" class="pilcrow">¶</a></p>
<div id="sorting_and_paging_metadata">
<section id="section-2.1">
        <h3 id="name-sorting-and-paging-metadata">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-sorting-and-paging-metadata" class="section-name selfRef">Sorting and Paging Metadata</a>
        </h3>
<p id="section-2.1-1">According to most advanced principles in REST design, collectively
        known as HATEOAS (Hypermedia as the Engine of Application State)
        <span>[<a href="#HATEOAS" class="xref">HATEOAS</a>]</span>, a client entering a REST application through
        an initial URI should use server-provided links to dynamically
        discover available actions and access the resources it needs.  In this
        way, the client is neither required to have prior knowledge of the
        service nor, consequently, to hard code the URIs of different
        resources.  This allows the server to make URI changes as the API
        evolves without breaking clients.  Definitively, a REST service should
        be as self-descriptive as possible.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">Therefore, servers implementing the query parameters described in this specification <span class="bcp14">SHOULD</span> provide additional information in their responses about both the available sorting criteria and possible pagination.  Such information is collected in two <span class="bcp14">OPTIONAL</span> response elements named "sorting_metadata" and "paging_metadata".<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">The "sorting_metadata" element contains the following properties:<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.1-4">
          <dt id="section-2.1-4.1">"currentSort": "String" (<span class="bcp14">OPTIONAL</span>)
</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-4.2">Either the value of the "sort" parameter as specified in the query string or
the sort applied by default, if any.<a href="#section-2.1-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-4.3">"availableSorts": "AvailableSort[]" (<span class="bcp14">OPTIONAL</span>)
</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-4.4">
            <p id="section-2.1-4.4.1">An array of objects, with each element describing an available sort criterion. The AvailableSort object includes the following members:<a href="#section-2.1-4.4.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.1-4.4.2">
              <dt id="section-2.1-4.4.2.1">"property": "String" (<span class="bcp14">REQUIRED</span>)
</dt>
              <dd style="margin-left: 1.5em" id="section-2.1-4.4.2.2">The name that can be used by the client to request the sort criterion.<a href="#section-2.1-4.4.2.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-2.1-4.4.2.3">"default": "Boolean" (<span class="bcp14">REQUIRED</span>)
</dt>
              <dd style="margin-left: 1.5em" id="section-2.1-4.4.2.4">Indicator of whether the sort criterion is applied by default. An RDAP server <span class="bcp14">MUST</span> define only one default sorting property for each object class.<a href="#section-2.1-4.4.2.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-2.1-4.4.2.5">"jsonPath": "String" (<span class="bcp14">OPTIONAL</span>)
</dt>
              <dd style="margin-left: 1.5em" id="section-2.1-4.4.2.6">The JSONPath expression of the RDAP field corresponding to the property.<a href="#section-2.1-4.4.2.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-2.1-4.4.2.7">"links": "Link[]" (<span class="bcp14">OPTIONAL</span>)
</dt>
              <dd style="margin-left: 1.5em" id="section-2.1-4.4.2.8">An array of links as described in <span>[<a href="#RFC8288" class="xref">RFC8288</a>]</span> containing the
query string that applies the sort criterion.<a href="#section-2.1-4.4.2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-2.1-5">At least one of the "currentSort" and "availableSorts" properties
        <span class="bcp14">MUST</span> be present.<a href="#section-2.1-5" class="pilcrow">¶</a></p>
<p id="section-2.1-6">The "paging_metadata" element contains the following fields:<a href="#section-2.1-6" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.1-7">
          <dt id="section-2.1-7.1">"totalCount": "Numeric" (<span class="bcp14">OPTIONAL</span>)
</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-7.2">A numeric value representing the total number of objects found.  It
<span class="bcp14">MUST</span> be provided if and only if the query string contains the
"count" parameter.<a href="#section-2.1-7.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-7.3">"pageSize": "Numeric" (<span class="bcp14">OPTIONAL</span>)
</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-7.4">A numeric value representing the number of objects that should have been
returned in the current page.  It <span class="bcp14">MUST</span> be provided if and only
if the total number of objects exceeds the page size.  This property is
redundant for RDAP clients because the page size can be derived from the
length of the search results array, but it can be helpful if the end user
interacts with the server through a web browser.<a href="#section-2.1-7.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-7.5">"pageNumber": "Numeric" (<span class="bcp14">OPTIONAL</span>)
</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-7.6">A numeric value representing the number of the current page in the result
set.  It <span class="bcp14">MUST</span> be provided if and only if the total number of
objects found exceeds the page size.<a href="#section-2.1-7.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-7.7">"links": "Link[]" (<span class="bcp14">OPTIONAL</span>)
</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-7.8">An array of links as described in <span>[<a href="#RFC8288" class="xref">RFC8288</a>]</span> containing the
reference to the next page.  In this specification, only forward pagination is
described because it is all that is necessary to traverse the result set.<a href="#section-2.1-7.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<div id="rdap-conformance">
<section id="section-2.1.1">
          <h4 id="name-rdap-conformance">
<a href="#section-2.1.1" class="section-number selfRef">2.1.1. </a><a href="#name-rdap-conformance" class="section-name selfRef">RDAP Conformance</a>
          </h4>
<p id="section-2.1.1-1">Servers returning the "paging_metadata" element in their response
          <span class="bcp14">MUST</span> include the string literal "paging" in the
          rdapConformance array.  Servers returning the "sorting_metadata"
          element <span class="bcp14">MUST</span> include the string literal
          "sorting".<a href="#section-2.1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="count-parameter">
<section id="section-2.2">
        <h3 id="name-count-parameter">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-count-parameter" class="section-name selfRef">"count" Parameter</a>
        </h3>
<p id="section-2.2-1">Currently, RDAP does not allow a client to determine
        the total number of results in a query response when the result
        set is truncated.  This is inefficient because the user cannot
        determine if the result set is complete.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">The "count" parameter provides additional functionality that allows
        a client to request information from the server that specifies the
        total number of objects matching the search pattern.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3">The following is an example of an RDAP query including the "count" parameter:<a href="#section-2.2-3" class="pilcrow">¶</a></p>
<p id="section-2.2-4">https://example.com/rdap/domains?name=example*.com&amp;count=true<a href="#section-2.2-4" class="pilcrow">¶</a></p>
<p id="section-2.2-5">The ABNF syntax is the following:<a href="#section-2.2-5" class="pilcrow">¶</a></p>
<div id="section-2.2-6">
<pre class="sourcecode lang-abnf">
   count = "count=" ( trueValue / falseValue )
   trueValue = ("true" / "yes" / "1")
   falseValue = ("false" / "no" / "0")
</pre><a href="#section-2.2-6" class="pilcrow">¶</a>
</div>
<p id="section-2.2-7">A trueValue means that the server <span class="bcp14">MUST</span> provide the
        total number of objects in the "totalCount" field of the
        "paging_metadata" element (<a href="#count-in-response-example" class="xref">Figure 1</a>).  A falseValue means that the
        server <span class="bcp14">MUST NOT</span> provide this number.<a href="#section-2.2-7" class="pilcrow">¶</a></p>
<span id="name-example-of-rdap-response-wi"></span><div id="count-in-response-example">
<figure id="figure-1">
          <div id="section-2.2-8.1">
<pre class="sourcecode lang-json">
{
  "rdapConformance": [
        "rdap_level_0",
        "paging"
  ],
  ...
  "paging_metadata": {
    "totalCount": 43
  },
  "domainSearchResults": [
    ...
  ]
}
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-example-of-rdap-response-wi" class="selfRef">Example of RDAP Response with "paging_metadata" Element Containing the "totalCount" Field</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sort-parameter">
<section id="section-2.3">
        <h3 id="name-sort-parameter">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-sort-parameter" class="section-name selfRef">"sort" Parameter</a>
        </h3>
<p id="section-2.3-1">RDAP does not provide any capability to specify the result set sort criteria.  A server could implement a default sorting scheme according to the object class, but this feature is not mandatory and might not meet user requirements.  Sorting can be addressed by the client, but this solution is rather inefficient.  Sorting features provided by the RDAP server could help avoid truncation of relevant results.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">The "sort" parameter allows the client to ask the server to sort the results according to the values of one or more properties and according to the sort direction of each property.  The ABNF syntax is the following:<a href="#section-2.3-2" class="pilcrow">¶</a></p>
<div id="section-2.3-3">
<pre class="sourcecode lang-abnf">
   sort = "sort=" sortItem *( "," sortItem )
   sortItem = property-ref [":" ( "a" / "d" ) ]
   property-ref = ALPHA *( ALPHA / DIGIT / "_" )
</pre><a href="#section-2.3-3" class="pilcrow">¶</a>
</div>
<p id="section-2.3-4">"a" means that an ascending sort <span class="bcp14">MUST</span> be applied; "d" means that a descending sort <span class="bcp14">MUST</span> be applied.  If the sort direction is absent, an ascending sort <span class="bcp14">MUST</span> be applied.<a href="#section-2.3-4" class="pilcrow">¶</a></p>
<p id="section-2.3-5">The following are examples of RDAP queries that include the "sort" parameter:<a href="#section-2.3-5" class="pilcrow">¶</a></p>
<p id="section-2.3-6">
https://example.com/rdap/domains?name=example*.com&amp;sort=name<a href="#section-2.3-6" class="pilcrow">¶</a></p>
<p id="section-2.3-7">
https://example.com/rdap/
domains?name=example*.com&amp;sort=registrationDate:d<a href="#section-2.3-7" class="pilcrow">¶</a></p>
<p id="section-2.3-8">
https://example.com/rdap/
domains?name=example*.com&amp;sort=lockedDate,name<a href="#section-2.3-8" class="pilcrow">¶</a></p>
<p id="section-2.3-9">Except for sorting IP addresses and values denoting dates and times, servers <span class="bcp14">MUST</span> implement sorting according to the JSON value type of the RDAP field the sorting property refers to.  That is, JSON strings <span class="bcp14">MUST</span> be sorted lexicographically, and JSON numbers <span class="bcp14">MUST</span> be sorted numerically.  Values denoting dates and times <span class="bcp14">MUST</span> be sorted in chronological order.  If IP addresses are represented as JSON strings, they <span class="bcp14">MUST</span> be sorted based on their numeric conversion.<a href="#section-2.3-9" class="pilcrow">¶</a></p>
<p id="section-2.3-10">The conversion of an IPv4 address to a number is possible since each dotted format IPv4 address is a representation of a number written in a 256-based manner; for example, 192.168.0.1 means 1*256^0 + 0*256^1 + 168*256^2 + 192*256^3 = 3232235521.  Similarly,  an IPv6 address can be converted into a number by applying the base 65536.  Therefore, the numerical representation of the IPv6 address 2001:0db8:85a3:0:0:8a2e:0370:7334 is 42540766452641154071740215577757643572.  Built-in functions and libraries for converting IP addresses into numbers are available in most known programming languages and relational database management systems.<a href="#section-2.3-10" class="pilcrow">¶</a></p>
<p id="section-2.3-11">If the "sort" parameter presents an allowed sorting property, it <span class="bcp14">MUST</span> be provided in the "currentSort" field of the "sorting_metadata" element.<a href="#section-2.3-11" class="pilcrow">¶</a></p>
<div id="sorting_properties">
<section id="section-2.3.1">
          <h4 id="name-sorting-properties-declarat">
<a href="#section-2.3.1" class="section-number selfRef">2.3.1. </a><a href="#name-sorting-properties-declarat" class="section-name selfRef">Sorting Properties Declaration</a>
          </h4>
<p id="section-2.3.1-1">In the "sort" parameter ABNF syntax, the element named "property-ref" represents a reference to a property of an RDAP object.  Such a reference could be expressed by using a JSONPath expression (named "jsonpath" in the following).<a href="#section-2.3.1-1" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2">JSONPath is a syntax, originally based on the XML XPath notation <span>[<a href="#W3C.CR-xpath-31-20170321" class="xref">W3C.CR-xpath-31-20170321</a>]</span>, which represents a path to select an element (or a set of elements) in a JSON document <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span>.  For example, the jsonpath to select the value of the ASCII name inside an RDAP domain lookup response is "$.ldhName", where $ identifies the root of the document object model (DOM).  Another way to select a value inside a JSON document is the JSON Pointer <span>[<a href="#RFC6901" class="xref">RFC6901</a>]</span>.<a href="#section-2.3.1-2" class="pilcrow">¶</a></p>
<p id="section-2.3.1-3">While JSONPath and JSON Pointer are both commonly adopted
          notations to select any value inside JSON data, neither is
          particularly concise and easy to use
          (e.g., "$.domainSearchResults[*].events[?(@.eventAction='registration')].eventDate"
          is the jsonpath of the registration date in an RDAP domain search
          response).<a href="#section-2.3.1-3" class="pilcrow">¶</a></p>
<p id="section-2.3.1-4">Therefore, this specification defines the "property-ref" element in terms of names identifying RDAP properties.  However, not all the RDAP properties are suitable to be used in sort criteria. These properties include:<a href="#section-2.3.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3.1-5.1">
              <p id="section-2.3.1-5.1.1">properties providing service information (e.g., links, notices, and remarks)<a href="#section-2.3.1-5.1.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-2.3.1-5.2">
              <p id="section-2.3.1-5.2.1">multivalued properties (e.g., status, roles, and variants)<a href="#section-2.3.1-5.2.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-2.3.1-5.3">properties representing relationships to other objects (e.g., entities)<a href="#section-2.3.1-5.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-2.3.1-6">On the contrary, properties expressed as values of other
          properties (e.g., registration date) could be used in such a
          context.<a href="#section-2.3.1-6" class="pilcrow">¶</a></p>
<p id="section-2.3.1-7">A list of properties an RDAP server <span class="bcp14">MAY</span> implement
          is defined.  The properties are divided into two groups:
          object-common properties and object-specific properties.<a href="#section-2.3.1-7" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3.1-8.1">
              <p id="section-2.3.1-8.1.1">Object-common properties. Object-common properties are derived from merging the "eventAction" and the "eventDate" properties. The following values of the "sort" parameter are defined:<a href="#section-2.3.1-8.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3.1-8.1.2.1">registrationDate<a href="#section-2.3.1-8.1.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-2.3.1-8.1.2.2">reregistrationDate<a href="#section-2.3.1-8.1.2.2" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-2.3.1-8.1.2.3">lastChangedDate<a href="#section-2.3.1-8.1.2.3" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-2.3.1-8.1.2.4">expirationDate<a href="#section-2.3.1-8.1.2.4" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-2.3.1-8.1.2.5">deletionDate<a href="#section-2.3.1-8.1.2.5" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-2.3.1-8.1.2.6">reinstantiationDate<a href="#section-2.3.1-8.1.2.6" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-2.3.1-8.1.2.7">transferDate<a href="#section-2.3.1-8.1.2.7" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-2.3.1-8.1.2.8">lockedDate<a href="#section-2.3.1-8.1.2.8" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-2.3.1-8.1.2.9">unlockedDate<a href="#section-2.3.1-8.1.2.9" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li class="normal" id="section-2.3.1-8.2">
              <p id="section-2.3.1-8.2.1">Object-specific properties. Note that some of these properties are also defined as query path segments. These properties include:<a href="#section-2.3.1-8.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3.1-8.2.2.1">Domain: name<a href="#section-2.3.1-8.2.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-2.3.1-8.2.2.2">Nameserver: name, ipv4, ipv6<a href="#section-2.3.1-8.2.2.2" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-2.3.1-8.2.2.3">Entity: fn, handle, org, email, voice, country, cc, city<a href="#section-2.3.1-8.2.2.3" class="pilcrow">¶</a>
</li>
              </ul>
</li>
          </ul>
<p id="section-2.3.1-9">The correspondence between these sorting properties and the RDAP
          object classes is shown in <a href="#table_sorting_properties_definition" class="xref">Table 1</a>.  Some of the sorting
          properties defined for the RDAP entity class are related to jCard
          elements <span>[<a href="#RFC7095" class="xref">RFC7095</a>]</span>, but because jCard is the JSON format
          for vCard, the corresponding definitions
          are included in the vCard specification <span>[<a href="#RFC6350" class="xref">RFC6350</a>]</span>.<a href="#section-2.3.1-9" class="pilcrow">¶</a></p>
<p id="section-2.3.1-10">An RDAP server <span class="bcp14">MUST NOT</span> use the defined sorting
          properties with a meaning other than that described in <a href="#table_sorting_properties_definition" class="xref">Table 1</a>.<a href="#section-2.3.1-10" class="pilcrow">¶</a></p>
<span id="name-definitions-of-sorting-prop"></span><div id="table_sorting_properties_definition">
<table class="center" id="table-1">
            <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-definitions-of-sorting-prop" class="selfRef">Definitions of Sorting Properties</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Object class</th>
                <th class="text-left" rowspan="1" colspan="1">Sorting property</th>
                <th class="text-left" rowspan="1" colspan="1">RDAP property</th>
                <th class="text-left" rowspan="1" colspan="1">RFC 7483</th>
                <th class="text-left" rowspan="1" colspan="1">RFC 6350</th>
                <th class="text-left" rowspan="1" colspan="1">RFC 8605</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Searchable objects</td>
                <td class="text-left" rowspan="1" colspan="1">Common properties</td>
                <td class="text-left" rowspan="1" colspan="1">eventAction values suffixed by "Date"</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-4.5" class="relref">4.5</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Domain</td>
                <td class="text-left" rowspan="1" colspan="1">name</td>
                <td class="text-left" rowspan="1" colspan="1">unicodeName/ ldhName</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.3" class="relref">5.3</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Nameserver</td>
                <td class="text-left" rowspan="1" colspan="1">name</td>
                <td class="text-left" rowspan="1" colspan="1">unicodeName/ ldhName</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.2" class="relref">5.2</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">ipv4</td>
                <td class="text-left" rowspan="1" colspan="1">v4 ipAddress</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.2" class="relref">5.2</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">ipv6</td>
                <td class="text-left" rowspan="1" colspan="1">v6 ipAddress</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.2" class="relref">5.2</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Entity</td>
                <td class="text-left" rowspan="1" colspan="1">handle</td>
                <td class="text-left" rowspan="1" colspan="1">handle</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.1" class="relref">5.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">fn</td>
                <td class="text-left" rowspan="1" colspan="1">jCard fn</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.1" class="relref">5.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc6350#section-6.2.1" class="relref">6.2.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">org</td>
                <td class="text-left" rowspan="1" colspan="1">jCard org</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.1" class="relref">5.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc6350#section-6.6.4" class="relref">6.6.4</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">voice</td>
                <td class="text-left" rowspan="1" colspan="1">jCard tel with type="voice"</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.1" class="relref">5.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc6350#section-6.4.1" class="relref">6.4.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">email</td>
                <td class="text-left" rowspan="1" colspan="1">jCard email</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.1" class="relref">5.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc6350#section-6.4.2" class="relref">6.4.2</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">country</td>
                <td class="text-left" rowspan="1" colspan="1">country name in jCard adr</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.1" class="relref">5.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc6350#section-6.3.1" class="relref">6.3.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">cc</td>
                <td class="text-left" rowspan="1" colspan="1">country code in jCard adr</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.1" class="relref">5.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc8605#section-3.1" class="relref">3.1</a>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1"></td>
                <td class="text-left" rowspan="1" colspan="1">city</td>
                <td class="text-left" rowspan="1" colspan="1">locality in jCard adr</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc7483#section-5.1" class="relref">5.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <a href="https://www.rfc-editor.org/rfc/rfc6350#section-6.3.1" class="relref">6.3.1</a>
</td>
                <td class="text-left" rowspan="1" colspan="1"></td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-2.3.1-12">Regarding the definitions in <a href="#table_sorting_properties_definition" class="xref">Table 1</a>, some further considerations are needed to disambiguate some cases:<a href="#section-2.3.1-12" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3.1-13.1">
              <p id="section-2.3.1-13.1.1">Since the response to a search on either domains or nameservers might include both A-labels and U-labels <span>[<a href="#RFC5890" class="xref">RFC5890</a>]</span> in general, a consistent sorting policy <span class="bcp14">MUST</span> treat the unicodeName and ldhName as two representations of the same value.  The unicodeName value <span class="bcp14">MUST</span> be used while sorting if it is present; when the unicodeName is unavailable, the value of the ldhName <span class="bcp14">MUST</span> be used instead.<a href="#section-2.3.1-13.1.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-2.3.1-13.2">
              <p id="section-2.3.1-13.2.1">The jCard "sort-as" parameter <span class="bcp14">MUST</span> be ignored for the sorting capability described in this document.<a href="#section-2.3.1-13.2.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-2.3.1-13.3">
              <p id="section-2.3.1-13.3.1">Even if a nameserver can have multiple IPv4 and IPv6 addresses, the most common configuration includes one address for each IP version.  Therefore, this specification makes the assumption that nameservers have a single IPv4 and/or IPv6 value.  When more than one address per IP version is presented, sorting <span class="bcp14">MUST</span> be applied to the first value.<a href="#section-2.3.1-13.3.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-2.3.1-13.4">
              <p id="section-2.3.1-13.4.1">Multiple events with a given action on an object might be returned.  If this occurs, sorting <span class="bcp14">MUST</span> be applied to the most recent event.<a href="#section-2.3.1-13.4.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-2.3.1-13.5">Except for handle values, all the sorting properties defined for entity objects can be multivalued according to the definition of vCard as given in <span>[<a href="#RFC6350" class="xref">RFC6350</a>]</span>.  When more than one value is presented, sorting <span class="bcp14">MUST</span> be applied to the preferred value identified by the parameter pref="1".  If the "pref" parameter is missing, sorting <span class="bcp14">MUST</span> be applied to the first value.<a href="#section-2.3.1-13.5" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-2.3.1-14">The "jsonPath" field in the "sorting_metadata" element is used to clarify the RDAP response field the sorting property refers to.  The mapping between the sorting properties and the jsonpaths of the RDAP response fields is shown below.  The JSONPath operators used herein are described in <a href="#jsonpath-operators" class="xref">Appendix A</a>.<a href="#section-2.3.1-14" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3.1-15.1">
              <p id="section-2.3.1-15.1.1">Searchable objects<a href="#section-2.3.1-15.1.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.3.1-15.1.2">
                <dt id="section-2.3.1-15.1.2.1">registrationDate</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.1.2.2">
                  <p id="section-2.3.1-15.1.2.2.1">$.domainSearchResults[*].events[?(@.eventAction=="registration")].eventDate<a href="#section-2.3.1-15.1.2.2.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.1.2.3">reregistrationDate</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.1.2.4">
                  <p id="section-2.3.1-15.1.2.4.1">$.domainSearchResults[*].events[?(@.eventAction=="reregistration")].eventDate<a href="#section-2.3.1-15.1.2.4.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.1.2.5">lastChangedDate</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.1.2.6">
                  <p id="section-2.3.1-15.1.2.6.1">$.domainSearchResults[*].events[?(@.eventAction=="last changed")].eventDate<a href="#section-2.3.1-15.1.2.6.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.1.2.7">expirationDate</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.1.2.8">
                  <p id="section-2.3.1-15.1.2.8.1">$.domainSearchResults[*].events[?(@.eventAction=="expiration")].eventDate<a href="#section-2.3.1-15.1.2.8.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.1.2.9">deletionDate</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.1.2.10">
                  <p id="section-2.3.1-15.1.2.10.1">$.domainSearchResults[*].events[?(@.eventAction=="deletion")].eventDate<a href="#section-2.3.1-15.1.2.10.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.1.2.11">reinstantiationDate</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.1.2.12">
                  <p id="section-2.3.1-15.1.2.12.1">$.domainSearchResults[*].events[?(@.eventAction=="reinstantiation")].eventDate<a href="#section-2.3.1-15.1.2.12.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.1.2.13">transferDate</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.1.2.14">
                  <p id="section-2.3.1-15.1.2.14.1">$.domainSearchResults[*].events[?(@.eventAction=="transfer")].eventDate<a href="#section-2.3.1-15.1.2.14.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.1.2.15">lockedDate</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.1.2.16">
                  <p id="section-2.3.1-15.1.2.16.1">$.domainSearchResults[*].events[?(@.eventAction=="locked")].eventDate<a href="#section-2.3.1-15.1.2.16.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.1.2.17">unlockedDate</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.1.2.18">
                  <p id="section-2.3.1-15.1.2.18.1">$.domainSearchResults[*].events[?(@.eventAction=="unlocked")].eventDate<a href="#section-2.3.1-15.1.2.18.1" class="pilcrow">¶</a></p>
</dd>
              <dd class="break"></dd>
</dl>
</li>
            <li class="normal" id="section-2.3.1-15.2">
              <p id="section-2.3.1-15.2.1">Domain<a href="#section-2.3.1-15.2.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.3.1-15.2.2">
                <dt id="section-2.3.1-15.2.2.1">name</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.2.2.2">
                  <p id="section-2.3.1-15.2.2.2.1">$.domainSearchResults[*].[unicodeName,ldhName]<a href="#section-2.3.1-15.2.2.2.1" class="pilcrow">¶</a></p>
</dd>
              <dd class="break"></dd>
</dl>
</li>
            <li class="normal" id="section-2.3.1-15.3">
              <p id="section-2.3.1-15.3.1">Nameserver<a href="#section-2.3.1-15.3.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.3.1-15.3.2">
                <dt id="section-2.3.1-15.3.2.1">name</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.3.2.2">
                  <p id="section-2.3.1-15.3.2.2.1">$.nameserverSearchResults[*].[unicodeName,ldhName]<a href="#section-2.3.1-15.3.2.2.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.3.2.3">ipv4</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.3.2.4">
                  <p id="section-2.3.1-15.3.2.4.1">$.nameserverSearchResults[*].ipAddresses.v4[0]<a href="#section-2.3.1-15.3.2.4.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.3.2.5">ipv6</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.3.2.6">
                  <p id="section-2.3.1-15.3.2.6.1">$.nameserverSearchResults[*].ipAddresses.v6[0]<a href="#section-2.3.1-15.3.2.6.1" class="pilcrow">¶</a></p>
</dd>
              <dd class="break"></dd>
</dl>
</li>
            <li class="normal" id="section-2.3.1-15.4">
              <p id="section-2.3.1-15.4.1">Entity<a href="#section-2.3.1-15.4.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2.3.1-15.4.2">
                <dt id="section-2.3.1-15.4.2.1">handle</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.4.2.2">
                  <p id="section-2.3.1-15.4.2.2.1">$.entitySearchResults[*].handle<a href="#section-2.3.1-15.4.2.2.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.4.2.3">fn</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.4.2.4">
                  <p id="section-2.3.1-15.4.2.4.1">$.entitySearchResults[*].vcardArray[1][?(@[0]=="fn")][3]<a href="#section-2.3.1-15.4.2.4.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.4.2.5">org</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.4.2.6">
                  <p id="section-2.3.1-15.4.2.6.1">$.entitySearchResults[*].vcardArray[1][?(@[0]=="org")][3]<a href="#section-2.3.1-15.4.2.6.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.4.2.7">voice</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.4.2.8">
                  <p id="section-2.3.1-15.4.2.8.1">$.entitySearchResults[*].vcardArray[1][?(@[0]=="tel" &amp;&amp; @[1].type=="voice")][3]<a href="#section-2.3.1-15.4.2.8.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.4.2.9">email</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.4.2.10">
                  <p id="section-2.3.1-15.4.2.10.1">$.entitySearchResults[*].vcardArray[1][?(@[0]=="email")][3]<a href="#section-2.3.1-15.4.2.10.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.4.2.11">country</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.4.2.12">
                  <p id="section-2.3.1-15.4.2.12.1">$.entitySearchResults[*].vcardArray[1][?(@[0]=="adr")][3][6]<a href="#section-2.3.1-15.4.2.12.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.4.2.13">cc</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.4.2.14">
                  <p id="section-2.3.1-15.4.2.14.1">$.entitySearchResults[*].vcardArray[1][?(@[0]=="adr")][1].cc<a href="#section-2.3.1-15.4.2.14.1" class="pilcrow">¶</a></p>
</dd>
                <dd class="break"></dd>
<dt id="section-2.3.1-15.4.2.15">city</dt>
                <dd style="margin-left: 1.5em" id="section-2.3.1-15.4.2.16">
                  <p id="section-2.3.1-15.4.2.16.1">$.entitySearchResults[*].vcardArray[1][?(@[0]=="adr")][3][3]<a href="#section-2.3.1-15.4.2.16.1" class="pilcrow">¶</a></p>
</dd>
              <dd class="break"></dd>
</dl>
</li>
          </ul>
<p id="section-2.3.1-16">Additional notes on the provided jsonpaths:<a href="#section-2.3.1-16" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3.1-17.1">
              <p id="section-2.3.1-17.1.1">Those related to the event dates are defined only for the
              "domain" object.  To obtain the equivalent jsonpaths for
              "entity" and "nameserver", the path segment
              "domainSearchResults" must be replaced with
              "entitySearchResults" and "nameserverSearchResults",
              respectively.<a href="#section-2.3.1-17.1.1" class="pilcrow">¶</a></p>
</li>
            <li class="normal" id="section-2.3.1-17.2">Those related to jCard elements are specified without taking
            into account the "pref" parameter.  Servers that sort those values
            identified by the "pref" parameter <span class="bcp14">SHOULD</span> update a
            jsonpath by adding an appropriate filter.  For example, if the
            email values identified by pref="1" are considered for sorting,
            the jsonpath of the "email" sorting property should be
            $.entitySearchResults[*].vcardArray[1][?(@[0]=="email" &amp;&amp;
            @[1].pref=="1")][3].<a href="#section-2.3.1-17.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="sorting_links">
<section id="section-2.3.2">
          <h4 id="name-representing-sorting-links">
<a href="#section-2.3.2" class="section-number selfRef">2.3.2. </a><a href="#name-representing-sorting-links" class="section-name selfRef">Representing Sorting Links</a>
          </h4>
<p id="section-2.3.2-1">An RDAP server <span class="bcp14">MAY</span> use the "links" array of the "sorting_metadata" element to provide ready-made references <span>[<a href="#RFC8288" class="xref">RFC8288</a>]</span> to the available sort criteria (<a href="#sort-link-in-response-example" class="xref">Figure 2</a>).  Each link represents a reference to an alternate view of the results.<a href="#section-2.3.2-1" class="pilcrow">¶</a></p>
<p id="section-2.3.2-2">The "value", "rel", and "href" JSON values <span class="bcp14">MUST</span> be specified.  All other JSON values are <span class="bcp14">OPTIONAL</span>.<a href="#section-2.3.2-2" class="pilcrow">¶</a></p>
<span id="name-example-of-a-sorting_metada"></span><div id="sort-link-in-response-example">
<figure id="figure-2">
            <div id="section-2.3.2-3.1">
<pre class="sourcecode lang-json">
{
  "rdapConformance": [
    "rdap_level_0",
    "sorting"
  ],
  ...
  "sorting_metadata": {
     "currentSort": "name",
     "availableSorts": [
       {
       "property": "registrationDate",
       "jsonPath": "$.domainSearchResults[*]
          .events[?(@.eventAction==\"registration\")].eventDate",
       "default": false,
       "links": [
         {
         "value": "https://example.com/rdap/domains?name=example*.com
                   &amp;sort=name",
         "rel": "alternate",
         "href": "https://example.com/rdap/domains?name=example*.com
                  &amp;sort=registrationDate",
         "title": "Result Ascending Sort Link",
         "type": "application/rdap+json"
         },
         {
         "value": "https://example.com/rdap/domains?name=example*.com
                   &amp;sort=name",
         "rel": "alternate",
         "href": "https://example.com/rdap/domains?name=example*.com
                  &amp;sort=registrationDate:d",
         "title": "Result Descending Sort Link",
         "type": "application/rdap+json"
         }
       ]
       },
       ...
     ]
  },
  "domainSearchResults": [
    ...
  ]
}
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-example-of-a-sorting_metada" class="selfRef">Example of a "sorting_metadata" Instance to Implement Result Sorting</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<div id="cursor-parameter">
<section id="section-2.4">
        <h3 id="name-cursor-parameter">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-cursor-parameter" class="section-name selfRef">"cursor" Parameter</a>
        </h3>
<p id="section-2.4-1">The "cursor" parameter defined in this specification can be used to
        encode information about any pagination method.  For example, in the
        case of a simple implementation of the "cursor" parameter to represent
        offset pagination information, the "cursor" value
        "b2Zmc2V0PTEwMCxsaW1pdD01MA==" is the base64 encoding of
        "offset=100,limit=50".  Likewise, in a simple implementation to
        represent keyset pagination information, the "cursor" value
        "ZXhhbXBsZS1OLmNvbQ==" represents the base64 encoding of
        "key=example-N.com" whereby the key value identifies the last row of
        the current page.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
<p id="section-2.4-2">Note that this specification uses a base64 encoding for cursor
        obfuscation just for example.  RDAP servers are <span class="bcp14">NOT RECOMMENDED</span> to obfuscate the "cursor" value through a mere
        base64 encoding.<a href="#section-2.4-2" class="pilcrow">¶</a></p>
<p id="section-2.4-3">This solution lets RDAP providers implement a pagination method
        according to their needs, a user's access level, and the submitted
        query.  Besides, servers can change the method over time without
        announcing anything to clients.  The considerations that have led to
        this solution are described in more detail in <a href="#approaches-to-result-pagination" class="xref">Appendix B</a>.<a href="#section-2.4-3" class="pilcrow">¶</a></p>
<p id="section-2.4-4">The ABNF syntax of the "cursor" parameter is the following:<a href="#section-2.4-4" class="pilcrow">¶</a></p>
<div id="section-2.4-5">
<pre class="sourcecode lang-abnf">
   cursor = "cursor=" 1*( ALPHA / DIGIT / "/" / "=" / "-" / "_" )
</pre><a href="#section-2.4-5" class="pilcrow">¶</a>
</div>
<p id="section-2.4-6">The following is an example of an RDAP query including the "cursor" parameter:<a href="#section-2.4-6" class="pilcrow">¶</a></p>
<p id="section-2.4-7">https://example.com/rdap/domains?name=example*.com
&amp;cursor=wJlCDLIl6KTWypN7T6vc6nWEmEYe99Hjf1XY1xmqV-M=<a href="#section-2.4-7" class="pilcrow">¶</a></p>
<div id="cursor_paging_links">
<section id="section-2.4.1">
          <h4 id="name-representing-paging-links">
<a href="#section-2.4.1" class="section-number selfRef">2.4.1. </a><a href="#name-representing-paging-links" class="section-name selfRef">Representing Paging Links</a>
          </h4>
<p id="section-2.4.1-1">An RDAP server <span class="bcp14">SHOULD</span> use the "links" array of the "paging_metadata" element to provide a ready-made reference <span>[<a href="#RFC8288" class="xref">RFC8288</a>]</span> to the next page of the result set (<a href="#cursor-pagination-link-in-response-example" class="xref">Figure 3</a>).  Examples of additional "rel" values a server <span class="bcp14">MAY</span> implement are "first", "last", and "prev".<a href="#section-2.4.1-1" class="pilcrow">¶</a></p>
<span id="name-example-of-a-paging_metadat"></span><div id="cursor-pagination-link-in-response-example">
<figure id="figure-3">
            <div id="section-2.4.1-2.1">
<pre class="sourcecode lang-json">
{
  "rdapConformance": [
    "rdap_level_0",
    "paging"
  ],
  ...
  "notices": [
    {
      "title": "Search query limits",
      "type": "result set truncated due to excessive load",
      "description": [
      "search results for domains are limited to 50"
      ]
    }
  ],
  "paging_metadata": {
    "totalCount": 73,
    "pageSize": 50,
    "pageNumber": 1,
    "links": [
      {
      "value": "https://example.com/rdap/domains?name=example*.com",
      "rel": "next",
      "href": "https://example.com/rdap/domains?name=example*.com
              &amp;cursor=wJlCDLIl6KTWypN7T6vc6nWEmEYe99Hjf1XY1xmqV-M=",
      "title": "Result Pagination Link",
      "type": "application/rdap+json"
      }
    ]
  },
  "domainSearchResults": [
    ...
  ]
}
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-example-of-a-paging_metadat" class="selfRef">Example of a "paging_metadata" Instance to Implement Cursor Pagination</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="negative-answers">
<section id="section-3">
      <h2 id="name-negative-answers">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-negative-answers" class="section-name selfRef">Negative Answers</a>
      </h2>
<p id="section-3-1">The constraints for the values of parameters are defined by their ABNF
      syntax.  Therefore, each request that includes an invalid value for a
      parameter <span class="bcp14">SHOULD</span> produce an HTTP 400 (Bad Request)
      response code.  The same response <span class="bcp14">SHOULD</span> be returned in
      the following cases:<a href="#section-3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-2.1">
          <p id="section-3-2.1.1">if sorting by either single or multiple properties, the client provides an
unsupported value for the "sort" parameter, as well as a value related to an
object property not included in the response<a href="#section-3-2.1.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-3-2.2">if the client submits an invalid value for the "cursor" parameter<a href="#section-3-2.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-3">Optionally, the response <span class="bcp14">MAY</span> include additional information regarding either the supported sorting properties or the correct "cursor" value in the HTTP entity body (<a href="#sorting-property-error" class="xref">Figure 4</a>).<a href="#section-3-3" class="pilcrow">¶</a></p>
<span id="name-example-of-rdap-error-respo"></span><div id="sorting-property-error">
<figure id="figure-4">
        <div id="section-3-4.1">
<pre class="sourcecode lang-json">
{
    "errorCode": 400,
    "title": "Domain sorting property 'unknown' is not valid",
    "description": [
        "Supported domain sorting properties are:"
        "'aproperty', 'anotherproperty'"
    ]

}
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-example-of-rdap-error-respo" class="selfRef">Example of RDAP Error Response Due to an Invalid Domain Sorting Property Included in the Request</a>
        </figcaption></figure>
</div>
</section>
</div>
<div id="implementation-considerations">
<section id="section-4">
      <h2 id="name-implementation-consideratio">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-implementation-consideratio" class="section-name selfRef">Implementation Considerations</a>
      </h2>
<p id="section-4-1">Implementation of the new parameters is technically feasible, as
      operators for counting, sorting, and paging are currently supported by
      the major relational database management systems.  Similar operators are
      completely or partially supported by the most well-known NoSQL databases
      (e.g., MongoDB, CouchDB, HBase, Cassandra, Hadoop, etc.).  Additional
      implementation notes are included in <a href="#additional-implementation-notes" class="xref">Appendix C</a>.<a href="#section-4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA-considerations">
<section id="section-5">
      <h2 id="name-iana-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-5-1">IANA has registered the following values in the "RDAP Extensions"
      registry:<a href="#section-5-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-5-2">
        <dt id="section-5-2.1">Extension identifier:
</dt>
        <dd style="margin-left: 1.5em" id="section-5-2.2">paging<a href="#section-5-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-2.3">Registry operator:
</dt>
        <dd style="margin-left: 1.5em" id="section-5-2.4">Any<a href="#section-5-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-2.5">Published specification:
</dt>
        <dd style="margin-left: 1.5em" id="section-5-2.6">RFC 8977<a href="#section-5-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-2.7">Contact:
</dt>
        <dd style="margin-left: 1.5em" id="section-5-2.8">IETF &lt;iesg@ietf.org&gt;<a href="#section-5-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-2.9">Intended usage:
</dt>
        <dd style="margin-left: 1.5em" id="section-5-2.10">This extension describes a best practice for result set paging.<a href="#section-5-2.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlParallel dlCompact" id="section-5-3">
        <dt id="section-5-3.1">Extension identifier:
</dt>
        <dd style="margin-left: 1.5em" id="section-5-3.2">sorting<a href="#section-5-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-3.3">Registry operator:
</dt>
        <dd style="margin-left: 1.5em" id="section-5-3.4">Any<a href="#section-5-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-3.5">Published specification:
</dt>
        <dd style="margin-left: 1.5em" id="section-5-3.6">RFC 8977<a href="#section-5-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-3.7">Contact:
</dt>
        <dd style="margin-left: 1.5em" id="section-5-3.8">IETF &lt;iesg@ietf.org&gt;<a href="#section-5-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-3.9">Intended usage: 
</dt>
        <dd style="margin-left: 1.5em" id="section-5-3.10">This extension describes a best practice for result set sorting.<a href="#section-5-3.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="security-considerations">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">Security services for the operations specified in this document are described in <span>[<a href="#RFC7481" class="xref">RFC7481</a>]</span>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">A search query typically requires more server resources (such as memory, CPU cycles, and network bandwidth) when compared to a lookup query.  This increases the risk of server resource exhaustion and subsequent denial of service.  This risk can be mitigated by either restricting search functionality or limiting the rate of search requests.  Servers can also reduce their load by truncating the results in a response.  However, this last security policy can result in a higher inefficiency or risk due to acting on incomplete information if the RDAP server does not provide any functionality to return the truncated results.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">The new parameters presented in this document provide RDAP operators with a way to implement a server that reduces inefficiency risks.  The "count" parameter gives the client the ability to evaluate the completeness of a response.  The "sort" parameter allows the client to obtain the most relevant information at the beginning of the result set.  This can reduce the number of unnecessary search requests.  Finally, the "cursor" parameter enables the user to scroll the result set by submitting a sequence of sustainable queries within server-acceptable limits.<a href="#section-6-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-7">
      <h2 id="name-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-normative-references">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5234">[RFC5234]</dt>
        <dd>
<span class="refAuthor">Crocker, D., Ed.</span><span class="refAuthor"> and P. Overell</span>, <span class="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <span class="seriesInfo">STD 68</span>, <span class="seriesInfo">RFC 5234</span>, <span class="seriesInfo">DOI 10.17487/RFC5234</span>, <time datetime="2008-01" class="refDate">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5890">[RFC5890]</dt>
        <dd>
<span class="refAuthor">Klensin, J.</span>, <span class="refTitle">"Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"</span>, <span class="seriesInfo">RFC 5890</span>, <span class="seriesInfo">DOI 10.17487/RFC5890</span>, <time datetime="2010-08" class="refDate">August 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5890">https://www.rfc-editor.org/info/rfc5890</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6350">[RFC6350]</dt>
        <dd>
<span class="refAuthor">Perreault, S.</span>, <span class="refTitle">"vCard Format Specification"</span>, <span class="seriesInfo">RFC 6350</span>, <span class="seriesInfo">DOI 10.17487/RFC6350</span>, <time datetime="2011-08" class="refDate">August 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6350">https://www.rfc-editor.org/info/rfc6350</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7095">[RFC7095]</dt>
        <dd>
<span class="refAuthor">Kewisch, P.</span>, <span class="refTitle">"jCard: The JSON Format for vCard"</span>, <span class="seriesInfo">RFC 7095</span>, <span class="seriesInfo">DOI 10.17487/RFC7095</span>, <time datetime="2014-01" class="refDate">January 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7095">https://www.rfc-editor.org/info/rfc7095</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7230">[RFC7230]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor"> and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"</span>, <span class="seriesInfo">RFC 7230</span>, <span class="seriesInfo">DOI 10.17487/RFC7230</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7230">https://www.rfc-editor.org/info/rfc7230</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7231">[RFC7231]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor"> and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"</span>, <span class="seriesInfo">RFC 7231</span>, <span class="seriesInfo">DOI 10.17487/RFC7231</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7231">https://www.rfc-editor.org/info/rfc7231</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7480">[RFC7480]</dt>
        <dd>
<span class="refAuthor">Newton, A.</span><span class="refAuthor">, Ellacott, B.</span><span class="refAuthor">, and N. Kong</span>, <span class="refTitle">"HTTP Usage in the Registration Data Access Protocol (RDAP)"</span>, <span class="seriesInfo">RFC 7480</span>, <span class="seriesInfo">DOI 10.17487/RFC7480</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7480">https://www.rfc-editor.org/info/rfc7480</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7481">[RFC7481]</dt>
        <dd>
<span class="refAuthor">Hollenbeck, S.</span><span class="refAuthor"> and N. Kong</span>, <span class="refTitle">"Security Services for the Registration Data Access Protocol (RDAP)"</span>, <span class="seriesInfo">RFC 7481</span>, <span class="seriesInfo">DOI 10.17487/RFC7481</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7481">https://www.rfc-editor.org/info/rfc7481</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7482">[RFC7482]</dt>
        <dd>
<span class="refAuthor">Newton, A.</span><span class="refAuthor"> and S. Hollenbeck</span>, <span class="refTitle">"Registration Data Access Protocol (RDAP) Query Format"</span>, <span class="seriesInfo">RFC 7482</span>, <span class="seriesInfo">DOI 10.17487/RFC7482</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7482">https://www.rfc-editor.org/info/rfc7482</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7483">[RFC7483]</dt>
        <dd>
<span class="refAuthor">Newton, A.</span><span class="refAuthor"> and S. Hollenbeck</span>, <span class="refTitle">"JSON Responses for the Registration Data Access Protocol (RDAP)"</span>, <span class="seriesInfo">RFC 7483</span>, <span class="seriesInfo">DOI 10.17487/RFC7483</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7483">https://www.rfc-editor.org/info/rfc7483</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8259">[RFC8259]</dt>
        <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8288">[RFC8288]</dt>
        <dd>
<span class="refAuthor">Nottingham, M.</span>, <span class="refTitle">"Web Linking"</span>, <span class="seriesInfo">RFC 8288</span>, <span class="seriesInfo">DOI 10.17487/RFC8288</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8288">https://www.rfc-editor.org/info/rfc8288</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8605">[RFC8605]</dt>
      <dd>
<span class="refAuthor">Hollenbeck, S.</span><span class="refAuthor"> and R. Carney</span>, <span class="refTitle">"vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)"</span>, <span class="seriesInfo">RFC 8605</span>, <span class="seriesInfo">DOI 10.17487/RFC8605</span>, <time datetime="2019-05" class="refDate">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8605">https://www.rfc-editor.org/info/rfc8605</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-7.2">
        <h3 id="name-informative-references">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="CURSOR">[CURSOR]</dt>
        <dd>
<span class="refAuthor">Nimesh, R.</span>, <span class="refTitle">"Paginating Real-Time Data with Cursor Based Pagination"</span>, <time datetime="2014-07" class="refDate">July 2014</time>, <span>&lt;<a href="https://www.sitepoint.com/paginating-real-time-data-cursor-based-pagination/">https://www.sitepoint.com/paginating-real-time-data-cursor-based-pagination/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CURSOR-API1">[CURSOR-API1]</dt>
        <dd>
<span class="refAuthor">Facebook</span>, <span class="refTitle">"Facebook for Developers -- Using the Graph API"</span>, <span>&lt;<a href="https://developers.facebook.com/docs/graph-api/using-graph-api">https://developers.facebook.com/docs/graph-api/using-graph-api</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CURSOR-API2">[CURSOR-API2]</dt>
        <dd>
<span class="refAuthor">Twitter</span>, <span class="refTitle">"Twitter Ads API"</span>, <span>&lt;<a href="https://developer.twitter.com/en/docs/twitter-ads-api">https://developer.twitter.com/en/docs/twitter-ads-api</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="GOESSNER-JSON-PATH">[GOESSNER-JSON-PATH]</dt>
        <dd>
<span class="refAuthor">Goessner, S.</span>, <span class="refTitle">"JSONPath - XPath for JSON"</span>, <time datetime="2007-02" class="refDate">February 2007</time>, <span>&lt;<a href="https://goessner.net/articles/JsonPath/">https://goessner.net/articles/JsonPath/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="HATEOAS">[HATEOAS]</dt>
        <dd>
<span class="refAuthor">Jedrzejewski, B.</span>, <span class="refTitle">"HATEOAS - a simple explanation"</span>, <time datetime="2018-02" class="refDate">February 2018</time>, <span>&lt;<a href="https://www.e4developer.com/2018/02/16/hateoas-simple-explanation/">https://www.e4developer.com/2018/02/16/hateoas-simple-explanation/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="JSONPATH-COMPARISON">[JSONPATH-COMPARISON]</dt>
        <dd>
<span class="refTitle">"JSONPath Comparison"</span>, <span>&lt;<a href="https://cburgmer.github.io/json-path-comparison/">https://cburgmer.github.io/json-path-comparison/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="JSONPATH-WG">[JSONPATH-WG]</dt>
        <dd>
<span class="refAuthor">IETF</span>, <span class="refTitle">"JSON Path (jsonpath)"</span>, <span>&lt;<a href="https://datatracker.ietf.org/wg/jsonpath/about/">https://datatracker.ietf.org/wg/jsonpath/about/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="ODATA-PART1">[ODATA-PART1]</dt>
        <dd>
<span class="refAuthor">Pizzo, M.</span><span class="refAuthor">, Handl, R.</span><span class="refAuthor">, and M. Zurmuehl</span>, <span class="refTitle">"OData Version 4.0. Part 1: Protocol Plus Errata 03"</span>, <time datetime="2016-06" class="refDate">June 2016</time>, <span>&lt;<a href="https://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part1-protocol/odata-v4.0-errata03-os-part1-protocol-complete.pdf">https://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part1-protocol/odata-v4.0-errata03-os-part1-protocol-complete.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="REST">[REST]</dt>
        <dd>
<span class="refAuthor">Fielding, R.</span>, <span class="refTitle">"Architectural Styles and the Design of Network-based Software Architectures"</span>, <time datetime="2000" class="refDate">2000</time>, <span>&lt;<a href="https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf">https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6901">[RFC6901]</dt>
        <dd>
<span class="refAuthor">Bryan, P., Ed.</span><span class="refAuthor">, Zyp, K.</span><span class="refAuthor">, and M. Nottingham, Ed.</span>, <span class="refTitle">"JavaScript Object Notation (JSON) Pointer"</span>, <span class="seriesInfo">RFC 6901</span>, <span class="seriesInfo">DOI 10.17487/RFC6901</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6901">https://www.rfc-editor.org/info/rfc6901</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SEEK">[SEEK]</dt>
        <dd>
<span class="refAuthor">EverSQL</span>, <span class="refTitle">"Faster Pagination in Mysql - Why Order By With Limit and Offset is Slow?"</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.eversql.com/faster-pagination-in-mysql-why-order-by-with-limit-and-offset-is-slow/">https://www.eversql.com/faster-pagination-in-mysql-why-order-by-with-limit-and-offset-is-slow/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="W3C.CR-xpath-31-20170321">[W3C.CR-xpath-31-20170321]</dt>
      <dd>
<span class="refAuthor">Robie, J.</span><span class="refAuthor">, Dyck, M.</span><span class="refAuthor">, and J. Spiegel</span>, <span class="refTitle">"XML Path Language (XPath) 3.1"</span>, <span class="refContent">World Wide Web Consortium Recommendation REC-xpath-31-20170321</span>, <time datetime="2017-03" class="refDate">March 2017</time>, <span>&lt;<a href="https://www.w3.org/TR/2017/REC-xpath-31-20170321/">https://www.w3.org/TR/2017/REC-xpath-31-20170321/</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="jsonpath-operators">
<section id="section-appendix.a">
      <h2 id="name-jsonpath-operators">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-jsonpath-operators" class="section-name selfRef">JSONPath Operators</a>
      </h2>
<p id="section-appendix.a-1">The jsonpaths used in this document are provided according to the Goessner proposal <span>[<a href="#GOESSNER-JSON-PATH" class="xref">GOESSNER-JSON-PATH</a>]</span>.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">Such specification requires that implementations support a set of
      "basic operators".  These operators are used to access the elements of a
      JSON structure like objects and arrays, as well as their subelements
      (object members and array items, respectively).  No operations are
      defined for retrieving parent or sibling elements of a given element.
      The root element is always referred to as $ regardless of it being an
      object or array.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">Additionally, the specification permits implementations to support
      arbitrary script expressions.  These can be used to index into an object
      or array, or to filter elements from an array.  While script expression
      behavior is implementation-defined, most implementations support the
      basic relational and logical operators as well as both object member and
      array item access, sufficiently similar for the purpose of this
      document.  Commonly supported operators/functions divided into
      "top-level operators" and "filter operators" are documented in Tables <a href="#table_json_path_top_level_operators" class="xref">2</a> and <a href="#table_json_path_filter_operators" class="xref">3</a>, respectively.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<p id="section-appendix.a-4">For more information on implementation interoperability issues, see
      <span>[<a href="#JSONPATH-COMPARISON" class="xref">JSONPATH-COMPARISON</a>]</span>.  At the time
      of writing, work is beginning on a standardization effort too (see
      <span>[<a href="#JSONPATH-WG" class="xref">JSONPATH-WG</a>]</span>).<a href="#section-appendix.a-4" class="pilcrow">¶</a></p>
<span id="name-jsonpath-top-level-operator"></span><div id="table_json_path_top_level_operators">
<table class="center" id="table-2">
        <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-jsonpath-top-level-operator" class="selfRef">JSONPath Top-Level Operators</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Operator</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">$</td>
            <td class="text-left" rowspan="1" colspan="1">Root element</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">.&lt;name&gt;</td>
            <td class="text-left" rowspan="1" colspan="1">Object member access (dot-notation)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">['&lt;name&gt;']</td>
            <td class="text-left" rowspan="1" colspan="1">Object member access (bracket-notation)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">[&lt;number&gt;]</td>
            <td class="text-left" rowspan="1" colspan="1">Array item access</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">*</td>
            <td class="text-left" rowspan="1" colspan="1">All elements within the specified scope</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">[?(&lt;expression&gt;)]</td>
            <td class="text-left" rowspan="1" colspan="1">Filter expression</td>
          </tr>
        </tbody>
      </table>
</div>
<span id="name-jsonpath-filter-operators"></span><div id="table_json_path_filter_operators">
<table class="center" id="table-3">
        <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-jsonpath-filter-operators" class="selfRef">JSONPath Filter Operators</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Operator</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">@</td>
            <td class="text-left" rowspan="1" colspan="1">Current element being processed</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">.&lt;name&gt;</td>
            <td class="text-left" rowspan="1" colspan="1">Object member access</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">.[&lt;name1&gt;,&lt;name2&gt;]</td>
            <td class="text-left" rowspan="1" colspan="1">Union of object members</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">[&lt;number&gt;]</td>
            <td class="text-left" rowspan="1" colspan="1">Array item access</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">==</td>
            <td class="text-left" rowspan="1" colspan="1">Left is equal to right</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">!=</td>
            <td class="text-left" rowspan="1" colspan="1">Left is not equal to right</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">&lt;</td>
            <td class="text-left" rowspan="1" colspan="1">Left is less than right</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">&lt;=</td>
            <td class="text-left" rowspan="1" colspan="1">Left is less than or equal to right</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">&gt;</td>
            <td class="text-left" rowspan="1" colspan="1">Left is greater than right</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">&gt;=</td>
            <td class="text-left" rowspan="1" colspan="1">Left is greater than or equal to right</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">&amp;&amp;</td>
            <td class="text-left" rowspan="1" colspan="1">Logical conjunction</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">||</td>
            <td class="text-left" rowspan="1" colspan="1">Logical disjunction</td>
          </tr>
        </tbody>
      </table>
</div>
</section>
</div>
<div id="approaches-to-result-pagination">
<section id="section-appendix.b">
      <h2 id="name-approaches-to-result-pagina">
<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-approaches-to-result-pagina" class="section-name selfRef">Approaches to Result Pagination</a>
      </h2>
<p id="section-appendix.b-1">An RDAP query could return a response with hundreds, even thousands, of objects, especially when partial matching is used.  For this reason, the "cursor" parameter addressing result pagination is defined to make responses easier to handle.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<p id="section-appendix.b-2">Presently, the most popular methods to implement pagination in a REST API include offset pagination and keyset pagination.  Neither pagination method requires the server to handle the result set in a storage area across multiple requests since a new result set is generated each time a request is submitted.  Therefore, they are preferred to any other method requiring the management of a REST session.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
<p id="section-appendix.b-3">Using limit and offset operators represents the traditionally used method to implement result pagination.  Both of them can be used individually:<a href="#section-appendix.b-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-appendix.b-4">
        <dt id="section-appendix.b-4.1">"limit=N":
</dt>
        <dd style="margin-left: 1.5em" id="section-appendix.b-4.2">means that the server returns the first N objects of the result set<a href="#section-appendix.b-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-appendix.b-4.3">"offset=N": 
</dt>
        <dd style="margin-left: 1.5em" id="section-appendix.b-4.4">means that the server skips the first N objects and returns objects starting from position N+1<a href="#section-appendix.b-4.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-appendix.b-5">When limit and offset are used together, they provide the ability to identify a specific portion of the result set.  For example, the pair "offset=100,limit=50" returns the first 50 objects starting from position 101 of the result set.<a href="#section-appendix.b-5" class="pilcrow">¶</a></p>
<p id="section-appendix.b-6">Though easy to implement, offset pagination also includes drawbacks:<a href="#section-appendix.b-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-appendix.b-7.1">
          <p id="section-appendix.b-7.1.1">When offset has a very high value, scrolling the result set could take some time.<a href="#section-appendix.b-7.1.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.b-7.2">
          <p id="section-appendix.b-7.2.1">It always requires fetching all rows before dropping as many rows as specified by offset.<a href="#section-appendix.b-7.2.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.b-7.3">It may return inconsistent pages when data are frequently updated (i.e., real-time data).<a href="#section-appendix.b-7.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-appendix.b-8">Keyset pagination <span>[<a href="#SEEK" class="xref">SEEK</a>]</span> adds a query condition that enables the selection of the only data not yet returned.  This method has been taken as the basis for the implementation of a "cursor" parameter <span>[<a href="#CURSOR" class="xref">CURSOR</a>]</span> by some REST API providers <span>[<a href="#CURSOR-API1" class="xref">CURSOR-API1</a>]</span> <span>[<a href="#CURSOR-API2" class="xref">CURSOR-API2</a>]</span>.  The cursor is a URL-safe string opaque to the client and representing a logical pointer to the first result of the next page.<a href="#section-appendix.b-8" class="pilcrow">¶</a></p>
<p id="section-appendix.b-9">Nevertheless, even keyset pagination can be troublesome:<a href="#section-appendix.b-9" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-appendix.b-10.1">
          <p id="section-appendix.b-10.1.1">It needs at least one key field.<a href="#section-appendix.b-10.1.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.b-10.2">
          <p id="section-appendix.b-10.2.1">It does not allow sorting simply by any field because the sorting
          criterion must contain a key.<a href="#section-appendix.b-10.2.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.b-10.3">
          <p id="section-appendix.b-10.3.1">It works best with full composite values supported by database
          management systems (i.e., [x,y]&gt;[a,b]); emulation is possible but
          inelegant and less efficient.<a href="#section-appendix.b-10.3.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.b-10.4">
          <p id="section-appendix.b-10.4.1">It does not allow direct navigation to arbitrary pages because
          the result set must be scrolled in sequential order starting from
          the initial page.<a href="#section-appendix.b-10.4.1" class="pilcrow">¶</a></p>
</li>
        <li class="normal" id="section-appendix.b-10.5">Implementing bidirectional navigation is tedious because all
        comparison and sort operations have to be reversed.<a href="#section-appendix.b-10.5" class="pilcrow">¶</a>
</li>
      </ul>
<div id="pagination-in-rdap">
<section id="section-b.1">
        <h2 id="name-specific-issues-raised-by-r">
<a href="#section-b.1" class="section-number selfRef">B.1. </a><a href="#name-specific-issues-raised-by-r" class="section-name selfRef">Specific Issues Raised by RDAP</a>
        </h2>
<p id="section-b.1-1">Some additional considerations can be made in the RDAP context:<a href="#section-b.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-b.1-2.1">
            <p id="section-b.1-2.1.1">An RDAP object is a conceptual aggregation of information
            generally collected from more than one data structure (e.g.,
            table), and this makes it even harder to implement keyset
            pagination, a task that is already quite difficult.  For example,
            the entity object can include information from different data
            structures (registrars, registrants, contacts, resellers), each
            one with its key field mapping the RDAP entity handle.<a href="#section-b.1-2.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="section-b.1-2.2">
            <p id="section-b.1-2.2.1">Depending on the number of page results as well as the number
            and the complexity of the properties of each RDAP object in the
            response, the time required by offset pagination to skip the
            previous pages could be much faster than the processing time
            needed to build the current page.  In fact, RDAP objects are
            usually formed by information belonging to multiple data
            structures and containing multivalued properties (i.e., arrays);
            therefore, data selection might be a time-consuming
            process.  This situation occurs even though the selection is
            supported by indexes.<a href="#section-b.1-2.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="section-b.1-2.3">Depending on the access levels defined by each RDAP operator,
          the increase in complexity and the decrease in flexibility of keyset
          pagination in comparison to offset pagination could be considered
          impractical.<a href="#section-b.1-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-b.1-3">Ultimately, both pagination methods have benefits and
        drawbacks.<a href="#section-b.1-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="additional-implementation-notes">
<section id="section-appendix.c">
      <h2 id="name-implementation-notes">
<a href="#section-appendix.c" class="section-number selfRef">Appendix C. </a><a href="#name-implementation-notes" class="section-name selfRef">Implementation Notes</a>
      </h2>
<p id="section-appendix.c-1">This section contains an overview of the main choices made during the
      implementation of the capabilities defined in this document in the RDAP public test
      server of Registro.it at the Institute of Informatics and Telematics of
      the National Research Council (IIT-CNR).  The content of this section
      can represent guidance for implementers who plan to provide RDAP
      users with those capabilities.  The RDAP public test server can be
      accessed at <span>&lt;<a href="https://rdap.pubtest.nic.it/">https://rdap.pubtest.nic.it/</a>&gt;</span>.  Further documentation about the server features is
      available at <span>&lt;<a href="https://rdap.pubtest.nic.it/doc/README.html">https://rdap.pubtest.nic.it/doc/README.html</a>&gt;</span>.<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
<section id="section-c.1">
        <h2 id="name-sorting">
<a href="#section-c.1" class="section-number selfRef">C.1. </a><a href="#name-sorting" class="section-name selfRef">Sorting</a>
        </h2>
<p id="section-c.1-1">If no sort criterion is specified in the query string, the results are sorted by a default property: "name" for domains and nameservers, and "handle" for entities.  The server supports multiple property sorting but the "sorting_metadata" object includes only the links to alternative result set views sorted by a single property just to show the list of sorting properties allowed for each searchable object.  The server supports all the object-specific sorting properties described in the specification except for nameserver sorting based on unicodeName, that is, the "name" sorting property is mapped onto the "ldhName" response field.  Regarding the object-common properties, sorting by registrationDate, expirationDate, lastChangedDate, and transferDate is supported.<a href="#section-c.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-c.2">
        <h2 id="name-counting">
<a href="#section-c.2" class="section-number selfRef">C.2. </a><a href="#name-counting" class="section-name selfRef">Counting</a>
        </h2>
<p id="section-c.2-1">The counting operation is implemented through a separate query.  Some relational database management systems support custom operators to get the total count together with the rows, but the resulting query can be considerably more expensive than that performed without the total count.  Therefore, as "totalCount" is an optional response information, always fetching the total number of rows has been considered an inefficient solution.  Furthermore, to avoid the processing of unnecessary queries, when the "count" parameter is included in the submitted query, it is not also repeated in the query strings of the "links" array provided in both "paging_metadata" and "sorting_metadata" objects.<a href="#section-c.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-c.3">
        <h2 id="name-paging">
<a href="#section-c.3" class="section-number selfRef">C.3. </a><a href="#name-paging" class="section-name selfRef">Paging</a>
        </h2>
<p id="section-c.3-1">The server implements the cursor pagination through the keyset
        pagination when sorting by a unique property is requested or the
        default sort is applied. Otherwise, it implements the cursor
        pagination through the offset pagination.  As most relational database
        management systems don't support the comparison of full composite
        values natively, the implementation of full keyset pagination seem to
        be troublesome so, at least initially, a selective applicability of
        keyset pagination is advisable.  Moreover, the "cursor" value encodes
        not only information about pagination but also about the search
        pattern and the other query parameters in order to check the
        consistency of the entire query string.  If the "cursor" value is
        inconsistent with the rest of the query string, the server returns an
        error response.<a href="#section-c.3-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<section id="section-appendix.d">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.d-1">The authors would like to acknowledge <span class="contact-name">Brian Mountford</span>, <span class="contact-name">Tom Harrison</span>, <span class="contact-name">Karl Heinz Wolf</span>, <span class="contact-name">Jasdip Singh</span>, <span class="contact-name">Erik Kline</span>, <span class="contact-name">Éric Vyncke</span>, <span class="contact-name">Benjamin Kaduk</span>, and <span class="contact-name">Roman Danyliw</span> for their contributions to the development of this document.<a href="#section-appendix.d-1" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.e">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mario Loffredo</span></div>
<div dir="auto" class="left"><span class="org">IIT-CNR/Registro.it</span></div>
<div dir="auto" class="left"><span class="street-address">Via Moruzzi,1</span></div>
<div dir="auto" class="left">
<span class="postal-code">56124</span> <span class="locality">Pisa</span> </div>
<div dir="auto" class="left"><span class="country-name">Italy</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mario.loffredo@iit.cnr.it" class="email">mario.loffredo@iit.cnr.it</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://www.iit.cnr.it" class="url">https://www.iit.cnr.it</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Maurizio Martinelli</span></div>
<div dir="auto" class="left"><span class="org">IIT-CNR/Registro.it</span></div>
<div dir="auto" class="left"><span class="street-address">Via Moruzzi,1</span></div>
<div dir="auto" class="left">
<span class="postal-code">56124</span> <span class="locality">Pisa</span> </div>
<div dir="auto" class="left"><span class="country-name">Italy</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:maurizio.martinelli@iit.cnr.it" class="email">maurizio.martinelli@iit.cnr.it</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://www.iit.cnr.it" class="url">https://www.iit.cnr.it</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Scott Hollenbeck</span></div>
<div dir="auto" class="left"><span class="org">Verisign Labs</span></div>
<div dir="auto" class="left"><span class="street-address">12061 Bluemont Way</span></div>
<div dir="auto" class="left">
<span class="locality">Reston</span>, <span class="region">VA</span> <span class="postal-code">20190</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:shollenbeck@verisign.com" class="email">shollenbeck@verisign.com</a>
</div>
<div class="url">
<span>URI:</span>
<a href="https://www.verisignlabs.com/" class="url">https://www.verisignlabs.com/</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>