added finding servers section

src/SUMMARY.md

@@ -25,7 +25,7 @@
     - [Extending RDAP](protocol/extensions.md)
 - [Finding Servers](bootstrapping/README.md)
     // TOOD mention redirect servers
-    - [The IANA Files](bootstrapping/iana.md)
+    - [Bootstrapping](bootstrapping/iana.md)
     - [Redirects](bootstrapping/redirects.md)
     - [Referrals](bootstrapping/referrals.md)
 

src/bootstrapping/README.md

@@ -1 +1,20 @@
 # Finding Servers
+
+RDAP servers exist for various types of Internet registration services:
+
+1. top-level domain registries
+1. second-level and below domain registries
+1. domain registrars
+1. regional internet registries
+1. national internet registries
+1. local internet registries
+1. the IANA
+
+The method to find the appropriate server to query depends on the type
+of service being targetted. There are three basic mechanisms to find a server:
+
+1. ["Bootstrapping"](iana.md) - This is the process defined by [RFC 9224](https://datatracker.ietf.org/doc/html/rfc9224) and [RFC 7480](https://datatracker.ietf.org/doc/html/rfc7480#autoid-28).
+2. [Redirects](redirects.md) - HTTP redirects by another RDAP server as defined by [RFC 7480](https://datatracker.ietf.org/doc/html/rfc7480#autoid-10).
+3. [Referrals](referrals.md) - Links from one RDAP server to another using a [`link`](../protocol/common_data_structures.html#links).
+
+The process of getting to redirects or referrals always begins with "bootstrapping" in some form.

src/bootstrapping/iana.md

@@ -1 +1,100 @@
-# The IANA Files
+# RDAP Bootstrapping
+
+"Bootstrapping" is, according to [WikiPedia](https://en.wikipedia.org/wiki/Bootstrapping):
+
+> In general, bootstrapping usually refers to a self-starting process that is supposed to continue or grow without external input.
+
+In RDAP, it is the first process to finding an RDAP server, and the last when the RDAP server being sought is that for either
+a TLD ([ccTLD](../glossary.md#cctld) or [gTLD](../glossary.md#gtld)) or the [IANA](../glossary.md#iana). This process is defined 
+by [RFC 9224](https://datatracker.ietf.org/doc/html/rfc9224), which a client may execute explicitly or via a redirect server
+as described in [RFC 7480](https://datatracker.ietf.org/doc/html/rfc7480#autoid-28).
+
+---
+
+There is no official list of RDAP bootstrap services, however two of the most popular are the ones run by [ARIN](https://rdap-bootstrap.arin.net/bootstrap)
+and [RDAP.ORG](https://rdap.org), the latter of which [reports](https://mailarchive.ietf.org/arch/msg/regext/ElTMpcFDeZ_L43U9UbKqaBowjak/)
+10 million query redirects daily.
+
+---
+
+The title of [RFC 9224](https://datatracker.ietf.org/doc/html/rfc9224), "Finding the Authoritative Registration Data Access Protocol (RDAP) Service"
+is misleading in that the RFC only describes the discovery of RDAP sources registered with [IANA](../glossary.md#iana). Important as those sources
+may be, they are not "authoritative" for second and third level domain registries (e.g. co.uk), IP addresses and Automous System Numbers transfered
+between [RIRs](../glossary.md#rir), number resources of [NIRs](../glossary.md#nir) and [LIRs](../glossary.md#lir), and domain contacts of "thin" TLDs
+where the information resides solely at a domain registrar.
+
+## The Boostrap Files
+
+Bootstrapping starts with one of 5 IANA files, depending on the information being sought.
+
+| Type                      | Link                                          |
+| ------------------------- | --------------------------------------------- |
+| Forward DNS               | <https://data.iana.org/rdap/dns.json>         |
+| IPv4 Addresses            | <https://data.iana.org/rdap/ipv4.json>        |
+| IPv6 Addresses            | <https://data.iana.org/rdap/ipv6.json>        |
+| Autonomous System Numbers | <https://data.iana.org/rdap/asn.json>         |
+| Object Tags               | <https://data.iana.org/rdap/object-tags.json> |
+
+For all but Object Tags, the files are structured as illustrated in [RFC 9224](https://datatracker.ietf.org/doc/html/rfc9224#name-structure-of-the-rdap-boots):
+
+```json
+{
+  "version": "1.0",
+  "publication": "YYYY-MM-DDTHH:MM:SSZ",
+  "description": "Some text",
+  "services": [
+    [
+      ["entry1", "entry2", "entry3"],
+      [
+        "https://registry.example.com/myrdap/",
+        "http://registry.example.com/myrdap/"
+      ]
+    ],
+    [
+      ["entry4"],
+      [
+        "https://example.org/"
+      ]
+    ]
+  ]
+}
+```
+
+The entries are either domain names (e.g. ".com", ".xyz"), IP address CIDR blocks (either v6 or v4),
+or Autonomous System Number (ASN) ranges, and the arrays are the [RDAP Base URLs](../protocol/rdap_urls.md#base-urls) 
+of the services for those resources.
+
+Each entry type as a specific matching strategy:
+
+| Type       | Example Entries                                | Evaluation               |
+| ---------- | ---------------------------------------------- | ------------------------ |
+| DNS        | `["net", "com"]`                               | Longest Label-wise match |
+| IPv4       | `["198.51.100.0/24", "192.0.0.0/8"]`           | Most specific match      |
+| IPv6       | `["2001:db8:4000::/36", "2001:db8:ffff::/48"]` | Most specific match      |
+| Object Tag | `["YYYY", "XXXX"]`                             | Exact match              |
+
+## The IANA is the Root
+
+[IANA](../glossary.md#iana) is represented as an empty string ("") in the `dns.json` file. Though IANA's base URLs
+are only represented in the `dns.json` file, this should not be misconstrued to mean IANA's RDAP services only contain
+TLD information.
+
+---
+
+As of this writing, IANA has not placed their RDAP URLs into the RDAP `dns.json` bootstrap file as root (""), though
+there is an entry for ".int".
+
+---
+
+## Object Tags
+
+Object Tags were introduced as a mechanism to provide bootstrapping to things in RDAP that had no
+natural bootstrapping process, mostly RDAP entities. That is, [RFC 8521](https://datatracker.ietf.org/doc/html/rfc8521)
+defines how tags can be applied to objects which can also be used to find the servers where those
+objects are defined.
+
+In more simple terms, this means identifying a suffix on a string is an object tag and then querying
+the server for it. For example, an entity with a handle of "FOO-ARIN" can be found in the ARIN RDAP server
+because the handle name is suffixed by "-ARIN".
+
+Object tags can also be used to direct clients at RDAP services using "short names". Neither usage is in wide spread use.

src/bootstrapping/redirects.md

@@ -1 +1,43 @@
 # Redirects
+
+An [HTTP redirect is a type of response](../protocol/response_types.md#redirects) a client recieves from
+a server when the server wishes the client to send the query elsewhere.
+
+```svgbob
++---------+   "GET /ip/101.100.49.1"                               +---------+
+|         |  --------------------------------------------------->  |         |
+|         |                                                        |         |
+| Client  |                                                        | Server  |
+|         |  <---------------------------------------------------  |         |
+|         |    "HTTP/1.1 301 MOVED PERMANENTLY"                    |         |
++---------+    "location: https://rdap.apnic.net/ip/101.100.49.1"  +---------+
+```
+
+This is used widely among the RIRs to supplement the normal [bootstrapping](iana.md) process
+to accommodate Internet number resources that have been transfered from on RIR to another
+(IANA does not record these transfers).
+
+In the following example, a client uses bootstrapping to query LACNIC for 21.1.1.1, however
+that resource has been transferred to ARIN therefore LACNIC issues a redirect.
+
+```mermaid
+sequenceDiagram
+    Client->>LACNIC: GET /ip/21.1.1.1
+    LACNIC->>Client: HTTP/1.1 301 MOVED PERMANENTLY 
+    Client->>ARIN: GET /ip/21.1.1.1
+    ARIN->>Client: HTTP/1.1 200 OK
+```
+
+The following example is from [Appendix C of RFC 7480](https://datatracker.ietf.org/doc/html/rfc7480#autoid-28).
+However, that example also shows a redirector (an RDAP server performing redirects for clients) and is more
+fully described as follows:
+
+```mermaid
+sequenceDiagram
+    Client->>Redirector: GET /ip/21.1.1.1
+    Redirector->>Client: HTTP/1.1 301 MOVED PERMANENTLY 
+    Client->>LACNIC: GET /ip/21.1.1.1
+    LACNIC->>Client: HTTP/1.1 301 MOVED PERMANENTLY 
+    Client->>ARIN: GET /ip/21.1.1.1
+    ARIN->>Client: HTTP/1.1 200 OK
+```

src/bootstrapping/referrals.md

@@ -1 +1,24 @@
 # Referrals
+
+Referrals are not a formal mechanism in RDAP but are often used to link
+a resource in one RDAP server to another. They are in wide-spread use within
+the [gTLD](../glossary.md#gtld) services to allow a gTLD registry to
+point a client at a domain name in a gTLD registrar.
+
+Referrals work using the [`links`](../protocol/common_data_structures.html#links)
+data structure when the `type` attribute of the link is set to the RDAP media
+type "application/rdap+json".
+
+```json
+{
+  "value" : "https://registry.example/domain/foo.example",
+  "rel"   : "related",
+  "href"  : "https://registrar.example/domain/foo.example"
+}
+```
+
+The [ICANN Response Profile] specifies that these referrals be made using
+the `related` relationship type.
+
+The soon-to-be [RIR Search](https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-rir-search-09#name-link-relations)
+will define referrals for "up", "down", "top", "bottom".

src/misc/contributing.md

@@ -1,6 +1,6 @@
 # Contributing
 
-Contributions to this book are welcome.
+Contributions to this book are welcome. If you have a GitHub account, click the "edit" icon above. Otherwise:
 
 1. To request the addition of an implementation or service, please open a GitHub issue [here](https://github.com/anewton1998/rdap_guide/issues).
 1. For minor text changes, either:

src/misc/glossary.md

@@ -42,6 +42,16 @@ INRs are composed of [RIRs](#rir) but also Local Internet Registries (LIRs) and
 
 jCard is the JSON version of the [vCard](#vcard) standard, which defines the details of a contact. It is standardized in [RFC 7095](https://datatracker.ietf.org/doc/html/rfc7095).
 
+### LIR
+
+A "Local Internet Regitry", sometimes known as an Internet Service Provider (ISP), receives number resources from another [INR](#inr) for
+re-allocation to customers.
+
+### NIR
+
+A "National Internet Registry" is an [INR](#inr) that receives Internet number resources from an [RIR](#rir) for redistribution in a specific
+country or economy.
+
 ### NRO
 
 The [Number Resource Organization](https://www.nro.net/) is a coordination group for the [RIRs](#rir).