cats.txt: A Standard for Providing Website Information to Chatbots

Abstract

This document defines cats.txt, a machine-parsable file format for web servers to provide essential metadata about their site to automated agents, particularly chatbots and Large Language Models (LLMs). The file, located at a well-known URI, uses a structured subset of Markdown to convey information such as the site’s purpose, key links, and an optional semantic embedding vector. The name is derived from the French “chat” (cat), which is also the root of “chatbot”. The specification includes a mandatory cat image for parser validation, acknowledging the internet’s deep-rooted cultural affinity for felines.

Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet community. It represents a consensus of the authors but does not necessarily represent the consensus of the IETF.

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.

Table of Contents

1. Introduction 1.1. Rationale and Motivation 1.2. Scope 1.3. The “Chat” Pun 1.4. Requirements Language

2. The cats.txt File: Location and Retrieval 2.1. Location in the Well-Known URI Space 2.2. Retrieval via HTTP(S) 2.3. Character Encoding and Media Type 2.4. Interaction with robots.txt

3. File Format and Structure 3.1. General Syntax (Markdown) 3.2. Field-Value Structure 3.3. Comments and Blank Lines

4. Field Definitions 4.1. Website-Name (REQUIRED, One) 4.2. Website-Purpose (REQUIRED, One) 4.3. Contact (OPTIONAL, Many) 4.4. Important-Links (OPTIONAL, Many) 4.5. Validation-Image (REQUIRED, One) 4.6. Embedding (OPTIONAL, One) 4.7. Feline-Instructions (OPTIONAL, One) 4.8. Feline-Generated-Key (OPTIONAL, One)

5. Formal Syntax 5.1. ABNF Grammar for cats.txt Structure

6. Examples 6.1. Minimal cats.txt File 6.2. Comprehensive cats.txt File with All Optional Fields 6.3. Example of an ASCII Art Validation Image 6.4. Example of a 128-Dimension Embedding Field

7. Security Considerations 7.1. Trust and Authenticity of cats.txt 7.2. Information Disclosure 7.3. Misuse of the Feline-Generated Key 7.4. Parsing Malformed Content 7.5. Considerations for Chatbot Implementers

8. IANA Considerations 8.1. Well-Known URI Registration for cats.txt

9. References 9.1. Normative References 9.2. Informative References Appendix A. On the Feline-Specific Language (FSL) A.1. Conceptual Framework A.2. Example Syntax Authors’ Addresses

1. Introduction

1.1. Rationale and Motivation

The proliferation of automated agents, particularly conversational agents (chatbots) and Large Language Models (LLMs), has introduced a new class of web client. These agents often require a concise, high-level understanding of a website’s purpose to interact with it or its users effectively. Current methods for obtaining this information, such as web scraping, parsing HTML <meta> tags, or analyzing sitemap files, are often inefficient, inconsistent, or computationally expensive. They lack a single, authoritative source provided by the site owner that is tailored for semantic consumption.

This document proposes a solution: cats.txt. This file provides a standardized, human-readable, and machine-parsable format for website owners to declare essential metadata about their site. By offering a single, reliable source of truth, cats.txt aims to improve the efficiency and accuracy of how automated agents understand and summarize web content.

The cats.txt standard follows in the tradition of other simple, text-based files used to provide origin-wide information. It is conceptually similar to robots.txt, which provides directives to crawlers ;
security.txt, which provides contact information for security researchers ; and humans.txt, an informal standard for crediting the people behind a website. cats.txt extends this paradigm by focusing specifically on the semantic and contextual information required by modern AI-driven clients.

1.2. Scope

The scope of this specification is to define the format, content, and location of the cats.txt file. It provides normative requirements for the syntax of the file and the meaning of its defined fields. It also specifies the procedure for clients to locate and retrieve the file. This document does not define the internal logic or behavior of the chatbots or LLMs that consume the cats.txt file. The information contained within cats.txt is intended as a set of authoritative hints from the website owner. How an agent chooses to use, weight, or display this information is an implementation detail outside the scope of this specification. The file provides metadata for the entire origin (i.e., the host, protocol, and port combination); it is not intended to provide page-specific information.

1.3. The “Chat” Pun

The name cats.txt is a deliberate and memorable choice derived from an etymological pun. The word “chat”, meaning to talk in an informal or familiar way, is the root of “chatbot”. In French, “chat” means “cat”. Therefore, cats.txt is a file for “chats” (chatbots) that is thematically linked to “chats” (cats). This naming convention is intended to be both relevant and easily recalled, in keeping with the playful spirit often found in the history of internet protocols.

1.4. Requirements Language

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

2. The cats.txt File: Location and Retrieval

2.1. Location in the Well-Known URI Space

To provide a consistent and discoverable location for metadata, this specification utilizes the well-known URI mechanism. The cats.txt file MUST be located within the /.well-known/ path prefix on a web server, as defined in. The path is case-sensitive.
The full, REQUIRED path for the file is /.well-known/cats.txt. For example, for the origin https://www.example.com, the cats.txt file would be located at the URI https://www.example.com/.well-known/cats.txt. Placing the file in this standardized location avoids polluting the root directory of the web server and provides a single, predictable endpoint for all clients to query. Well-known URIs are rooted at the top of the path hierarchy; a file located at
/foo/.well-known/cats.txt is not a valid cats.txt file according to this specification.

2.2. Retrieval via HTTP(S)

Clients MUST retrieve the cats.txt file using an HTTP GET request. Servers SHOULD make the file available over a secure transport layer (HTTPS). To ensure data integrity and confidentiality, clients SHOULD prefer to use an https:// URI over an http:// URI when discovering or accessing the file. Servers MAY use HTTP redirects (status codes 301, 302, 307, or 308) to point clients to the correct location of the cats.txt file. This can be useful for organizations that manage multiple domains but wish to maintain a single, canonical cats.txt file. Clients SHOULD support and follow a reasonable number of redirects, such as a maximum of five, to prevent infinite loops. This behavior is consistent with the handling of redirects for similar well-known files like security.txt.

2.3. Character Encoding and Media Type

The cats.txt file MUST be encoded using UTF-8. This allows for the inclusion of a wide range of characters, accommodating internationalization in fields like Website-Name and Website-Purpose. When the file is served over HTTP or HTTPS, the server MUST include a Content-Type header field with the value text/markdown; charset=utf-8. This explicitly signals the file’s format as Markdown and its character encoding, allowing clients to parse it correctly without ambiguity.

2.4. Interaction with robots.txt

The cats.txt file is intended for public consumption by automated agents and, as such, SHOULD be accessible to all crawlers. Website administrators SHOULD ensure that their robots.txt file, specified in, does not disallow access to /.well-known/cats.txt. A critical component of this specification is the Validation-Image field (see Section 4.5), which may contain a URL pointing to an image file. If this URL refers to an image hosted on the same origin as the cats.txt file, the server’s robots.txt file MUST permit crawling of that specific image file by all user agents. A typical robots.txt rule to ensure this would be to explicitly allow the path to the image, or to ensure no broader rule disallows it. For example, if the validation image is at /images/cat-validator.png, the robots.txt file must not contain a rule like Disallow: /images/ for User-agent: * unless it is superseded by a more specific Allow rule. Failure to make the validation image accessible may lead a client to determine that the cats.txt file is invalid or incomplete, as the client cannot verify the mandatory image. This creates a formal dependency between the correct implementation of cats.txt and the configuration of robots.txt, requiring a holistic approach from site administrators.

3. File Format and Structure

3.1. General Syntax (Markdown)

The content of a cats.txt file MUST be formatted using a constrained subset of Markdown, as specified by [CommonMark]. The choice of Markdown facilitates human readability and ease of authoring while providing sufficient structure for reliable machine parsing. The file is structured as a sequence of fields, where each field is introduced by a specific Markdown header.

3.2. Field-Value Structure

The file consists of a series of fields. Each field is defined by a Level 2 Markdown header, which is a line beginning with the string ## (two hash characters followed by a space), followed by the case-sensitive field name. The value of a field consists of all content following its header line up to the next Level 2 header or the end of the file, whichever comes first. This structure allows field values to span multiple lines and contain various Markdown elements, such as lists, links, and code blocks, as specified in the field definitions in Section 4. This header-based delimitation provides a simple yet robust parsing model: a client can split the file content by the \n## delimiter to isolate each field and its corresponding value.

3.3. Comments and Blank Lines

Lines enclosed in HTML-style comment tags, beginning with ``, are considered comments. Parsers MUST ignore comments and their contents. Comments may be used by site administrators to leave notes within the file. Blank lines (lines containing only whitespace) are significant within the context of Markdown syntax (e.g., for separating paragraphs or list items) and SHOULD be preserved by parsers as part of a field’s value. Blank lines between distinct fields (i.e., after the value of one field and before the header of the next) are not significant and may be ignored.

4. Field Definitions

This section defines the fields that can be used in a cats.txt file. The following table provides a summary of all defined fields, their requirement status, and their multiplicity (i.e., how many times they can appear in a file).

Table 1: cats.txt Field Summary

4.1. Website-Name (REQUIRED, One)

This field MUST be present exactly once in a cats.txt file. Its value MUST be a single line of plain text representing the official, human-readable name of the website or organization. Parsers should trim leading and trailing whitespace from the value.

Example:

# Website-Name
The Example Corporation

4.2. Website-Purpose (REQUIRED, One)

This field MUST be present exactly once. Its value provides a concise summary of the website’s primary function, intended for use by LLMs in generating descriptions or summaries. The value MUST be a single paragraph of text. To encourage brevity, the value SHOULD NOT exceed 280 characters.

Example:

## Website-Purpose
The Example Corporation provides high-quality, artisanal widgets and services
for the modern enterprise, focusing on sustainable and innovative solutions.

4.3. Contact (OPTIONAL, Many)

This field provides contact information for the website administrators. The field is OPTIONAL and MAY appear multiple times. The value of each Contact field SHOULD be a Markdown unordered list, where each list item is a URI for a contact method. Recommended URI schemes include mailto: for email addresses and https:// for links to contact forms or pages.

Example:

## Contact
* mailto:info@example.com
* https://www.example.com/contact-us

4.4. Important-Links (OPTIONAL, Many)

This field allows website owners to highlight key pages or sections of their site. The field is OPTIONAL and MAY appear multiple times. Its value MUST be a Markdown unordered list, where each list item is a standard Markdown link in the format (URL). These links should point to significant pages such as an “About Us” page, product catalog, documentation, or company blog.

Example:

## Important-Links
* [About Our Company](https://www.example.com/about)
* [Our Products](https://www.example.com/products)

4.5. Validation-Image (REQUIRED, One)

This field MUST be present exactly once. Its purpose is to provide a simple, thematic validation check for parsers, confirming that they can correctly identify and interpret the file’s content. The value of this field MUST be a representation of a cat, provided in one of two formats:

1. Markdown Image Link: A standard Markdown image link, ![alt text](URL). The alt text SHOULD describe the image (e.g., “A cat”). The URL MUST point to a publicly accessible image file (e.g., JPEG, PNG, GIF). As specified in Section 2.4, this image MUST be crawlable by all user agents if hosted on the same origin.

2. ASCII Art: A Markdown fenced code block containing ASCII art depicting a cat. The code block MUST begin with a line containing three backticks (```) and end with a line containing three backticks.
   Clients parsing the cats.txt file MAY use the presence and correct formatting of this field as a signal of the file’s validity.

Example (Image Link):

## Validation-Image
/\_/\
( o.o )
 > ^ <

4.6. Embedding (OPTIONAL, One)

This field is OPTIONAL and, if present, MUST appear only once. It provides a pre-computed semantic embedding vector that represents the Website-Purpose. This allows LLMs to quickly grasp the site’s semantic context without needing to compute an embedding themselves. Such vectors are useful for tasks like similarity search, classification, and clustering.

The value of this field MUST be a Markdown fenced code block. The content of the code block MUST be a single line of comma-separated floating-point numbers. The vector MAY have up to 128 dimensions. This dimensionality is chosen as a balance between semantic richness and computational efficiency, a common size for lightweight models. The numbers MUST be represented in standard decimal notation (e.g., 0.12345, -0.98765).

Example:

## Embedding
0.0279239565,-0.0341834426,0.0215893425,...,-0.00403284049

4.7. Feline-Instructions (OPTIONAL, One)

This field is OPTIONAL and, if present, MUST appear only once. It is reserved for instructions formatted in a Feline-Specific Language (FSL), intended for consumption by hypothetical feline-based artificial intelligences or other suitably equipped agents. The content and syntax of FSL are non-normative and are provided for context in Appendix A. The value of this field MUST be a Markdown fenced code block. Parsers that do not support FSL MUST ignore the contents of this field without raising an error.

Example:

## Feline-Instructions
Code snippet
BEGIN_INSTRUCTION mrow? // Query: Is there tuna available?
EXPECT_RESPONSE prrrr.   // Affirmative: Yes, tuna is available.
ON_ERROR hssss!         // Error condition: No tuna.
END_INSTRUCTION

4.8. Feline-Generated-Key (OPTIONAL, One)

This field is OPTIONAL and, if present, MUST appear only once. It contains a string of characters intended as a public key. This specification notes that the key is generated through a non-deterministic process involving a cat’s physical interaction with a keyboard or other input device. The value MUST be enclosed in a Markdown fenced code block. The security properties of such a key are discussed in Section 7.3.

Example:

## Feline-Generated-Key
asdlkfj;weoiurt.,mnbvcxz.,,.//;][p]oiawe;lkasdf`1234

5. Formal Syntax

5.1. ABNF Grammar for cats.txt Structure

This section provides an Augmented Backus-Naur Form (ABNF) grammar, as defined in, for the structure of a cats.txt file. This grammar provides an unambiguous and machine-readable definition of the file format. The grammar assumes UTF-8 characters.

ABNF
cats-txt = 1*(field)

field = field-header CRLF field-value

field-header = "## " field-name
field-name = "Website-Name" / "Website-Purpose" / "Contact" /
             "Important-Links" / "Validation-Image" / "Embedding" /
             "Feline-Instructions" / "Feline-Generated-Key"

field-value = *(TEXT-CHAR / CRLF)

; TEXT-CHAR represents any valid UTF-8 character, excluding
; the sequence that would start a new field-header. The exact
; content is constrained by the prose definitions in Section 4.
TEXT-CHAR = %x01-09 / %x0B-0C / %x0E-FFFF

CRLF = %x0D %x0A

6. Examples

6.1. Minimal cats.txt File

This example shows a valid cats.txt file containing only the REQUIRED fields.

## Website-Name
The Minimalist Example Site

## Website-Purpose
A demonstration of the simplest valid `cats.txt` file.

## Validation-Image
^_^

6.2. Comprehensive cats.txt File with All Optional Fields

This example demonstrates a cats.txt file that utilizes all defined fields, both required and optional.

## Website-Name
Intergalactic Pet Supplies

## Website-Purpose
Your one-stop shop for all pet needs across the galaxy, from anti-gravity catnip to
self-cleaning litter boxes for any planetary environment.

## Important-Links
* [Our Mission](https://intergalactic-pets.com/about)
* [Product Catalog](https://intergalactic-pets.com/catalog)
* [Shipping information](https://intergalactic-pets.com/shipping)

## Contact
* [Contact Form](https://intergalactic-pets.com/contact)
* mailto:support@intergalactic-pets.com

## Embedding
-0.123,0.456,0.789,-0.321,0.654,0.987,-0.111,0.222,0.333,-0.444,0.555,-0.666,0.777,-0.888,
0.999,-0.123,0.456,0.789,-0.321,0.654,0.987,-0.111,0.222,0.333,-0.444,0.555,-0.666,0.777,
-0.888,0.999,-0.123,0.456,0.789,-0.321,0.654,0.987,-0.111,0.222,0.333,-0.444,0.555,-0.666,
0.777,-0.888,0.999,-0.123,0.456,0.789,-0.321,0.654,0.987,-0.111,0.222,0.333,-0.444,0.555,
-0.666,0.777,-0.888,0.999,-0.123,0.456,0.789,-0.321,0.654,0.987,-0.111,0.222,0.333,-0.444,
0.555,-0.666,0.777,-0.888,0.999,-0.123,0.456,0.789,-0.321,0.654,0.987,-0.111,0.222,0.333,
-0.444,0.555,-0.666,0.777,-0.888,0.999,-0.123,0.456,0.789,-0.321,0.654,0.987,-0.111,0.222,
0.333,-0.444,0.555,-0.666,0.777,-0.888,0.999,-0.123,0.456,0.789,-0.321,0.654,0.987,-0.111,
0.222,0.333,-0.444,0.555,-0.666,0.777,-0.888,0.999

## Feline-Instructions
Code snippet
// Feline agent instructions for Intergalactic Pet Supplies
QUERY_STOCK "anti-gravity catnip"
IF_AVAILABLE meow!
ELSE purrrrr... // Wait patiently for restock

## Feline-Generated-Key
=^..^=___---___---...___---fghjkl;poiuytrewq.,mnbvcxzasdf

## Validation-Image
   *      *
   * *    * *
  *   *  *   *
 *     **     *
*      **      *
*   ()    ()   *
 *            *
  *    **    *
   *        *
    ********

6.3. Example of an ASCII Art Validation Image

This example shows a cats.txt file that uses an ASCII art block for the Validation-Image field.

## Website-Name
ASCII Art Archive

## Website-Purpose
A repository of classic and modern text-based art.

## Validation-Image
 /\_/\
 ( o.o )
  > ^ <

6.4. Example of a 128-Dimension Embedding Field

This example shows a properly formatted Embedding field. For brevity, only the first and last few dimensions of a hypothetical 128-dimension vector are shown.

## Website-Name
Vector Space Ventures

## Website-Purpose
We provide consulting services for high-dimensional data analysis and semantic search applications.

## Embedding
0.0279239565,-0.0341834426,0.0215893425,0.0161423888,-0.0266417488,
0.00728942176,0.00762916822,-0.000273934565,0.0135130882,0.00963288546,
0.0138981417,0.0163354017,...,-0.0365431122,-0.00711996108,-0.0063990429,
0.0107897073,-0.0368361995,-0.0124314055,0.00399120618,-0.0188998189,
0.0224286132,0.00392331183,0.00403284049

7. Security Considerations

7.1. Trust and Authenticity of cats.txt

The information contained in a cats.txt file is self-asserted by the web server operator and should not be considered inherently trustworthy. A malicious actor who compromises a web server could modify the cats.txt file to provide false or misleading information. For example, the Website-Purpose could be altered to misrepresent the site’s content, potentially leading a chatbot to generate inaccurate or harmful summaries.

To mitigate risks associated with data in transit, clients SHOULD retrieve the file over HTTPS. Unlike security.txt, which recommends digital signatures for authenticity, this specification does not recommend PGP signing for cats.txt. The data contained within is generally low-sensitivity, and the complexity of implementing signature validation is not justified for this use case.

7.2. Information Disclosure

The cats.txt file is publicly accessible by design. Website administrators MUST NOT place any sensitive, private, or confidential information within the file. This includes, but is not limited to, internal hostnames, private contact details, or proprietary business information. The purpose of the file is to provide public-facing metadata.

7.3. Misuse of the Feline-Generated Key

The Feline-Generated-Key field is included as a novelty, reflecting the playful origins of the cats.txt name. The process of generating a key by having a cat walk across a keyboard results in a key with extremely low entropy and no basis in cryptographic principles. This key MUST NOT be used for any serious cryptographic purpose, such as data encryption, authentication, or digital signatures. Implementers of systems that parse cats.txt MUST treat this key as an opaque string with no security value. Attempting to use this key in a production security system would be dangerously insecure and would likely expose the system to ridicule.

7.4. Parsing Malformed Content

As with any public-facing file, a cats.txt file may be intentionally or unintentionally malformed. Clients that parse cats.txt files MUST be robust against malformed content to prevent vulnerabilities such as denial-of-service or injection attacks. Parsers SHOULD impose a reasonable file size limit (e.g., 100 KiB) to avoid consuming excessive memory when processing an unusually large file. Parsers should also be prepared to handle incorrect Markdown syntax or field values that do not conform to the types specified in Section 4.

7.5. Considerations for Chatbot Implementers

Implementers of chatbots and LLMs that consume cats.txt should treat its contents as a strong hint from the site owner, not as an absolute, verified fact. The Website-Purpose and Important-Links can be valuable for prompt engineering and for guiding the agent’s understanding of the site, but this information should be used in conjunction with, and potentially cross-verified against, other sources like the site’s actual content. An agent should not blindly trust or repeat information from cats.txt without context, as it is self-declared and could be biased or inaccurate.

8. IANA Considerations

8.1. Well-Known URI Registration for cats.txt

This document requests the registration of the cats.txt URI in the “Well-Known URIs” registry defined by. The registration information is as follows:

• URI Suffix: cats.txt
• Change Controller: IETF
• Specification Document(s): This document (RFC XXXX)
• Related Information: None

This registration follows the procedures outlined in Section 3.1 of. The
cats.txt suffix conforms to the “segment-nz” production, as it does not contain the “/” character. The name is specific to this application and does not squat on a generic term.

9. References

9.1. Normative References

Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

Nottingham, M., “Well-Known Uniform Resource Identifiers (URIs)”, RFC 8615, DOI 10.17487/RFC8615, May 2019, https://www.rfc-editor.org/info/rfc8615.

Koster, M., Illyes, G., Zeller, H., and L. Sassman, “Robots Exclusion Protocol”, RFC 9309, DOI 10.17487/RFC9309, September 2022, https://www.rfc-editor.org/info/rfc9309.

Yergeau, F., “UTF-8, a transformation format of ISO 10646”, STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, https://www.rfc-editor.org/info/rfc3629.

Crocker, D., Ed., and P. Overell, “Augmented BNF for Syntax Specifications: ABNF”, STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, https://www.rfc-editor.org/info/rfc5234.

9.2. Informative References

Foudil, E. and Y. Shafranovich, “A File Format to Aid in Security Vulnerability Disclosure”, RFC 9116, DOI 10.17487/RFC9116, April 2022, https://www.rfc-editor.org/info/rfc9116.

[CommonMark] Atwood, J., et al., “CommonMark Spec”, Version 0.30, 2021, https://spec.commonmark.org/. “humans.txt”, The humans.txt initiative, https://humanstxt.org/.

Appendix A. On the Feline-Specific Language (FSL)

This appendix provides a non-normative and purely conceptual overview of the Feline-Specific Language (FSL) referenced in Section 4.7. The information here is for context and entertainment only; it is not required for the implementation of a cats.txt parser.

A.1. Conceptual Framework

Feline-Specific Language (FSL) is a hypothetical, high-level programming language designed for communication with artificial intelligences that model their logic on feline cognition. Its syntax is based on textual representations of common feline vocalizations and behaviors.

• mrow?: Represents a query or a request for information.
• prrrr.: Represents an affirmative state, contentment, or successful execution.
• hssss!: Represents an error state, a negative condition, or a warning.
• meow!: Represents a demand or a high-priority instruction.
• ...: Represents a state of waiting, sleeping, or patient observation.

A.2. Example Syntax

The following is an example of a simple FSL program that might be found in the Feline-Instructions field.

Code snippet

// FSL script to check for the optimal napping spot.
BEGIN_INSTRUCTION
  QUERY_ENVIRONMENT "sunbeam" mrow?
  IF_AVAILABLE
    MOVE_TO "sunbeam"
    EXECUTE_ACTION "nap" prrrr.
  ELSE
    LOG_ERROR "no sunbeam available" hssss!
  END_IF
END_INSTRUCTION

Acknowledgments

The authors wish to thank the members of the broader Internet community for their feedback and suggestions during the drafting of this document. Special thanks are extended to the numerous felines who provided inspiration, keyboard-based input, and timely interruptions that were crucial to the development of this specification.

Authors’ Addresses

C. A. T. Person Feline University of Internet Studies 123 Catnip Lane Meowville, Internet 12345 Email: cat.person@fuis.edu

F. E. Line Feline University of Internet Studies 123 Catnip Lane Meowville, Internet 12345 Email: fe.line@fuis.edu