RFC 1835
Architecture of the WHOIS++ service
Architecture of the WHOIS++ service 🎀
okay bestie, let's get into it 💅 this is RFC 1835, and it's giving networking history.
- Number and title: RFC 1835, "Architecture of the WHOIS++ service"
- Series: Network Working Group, Request for Comments
- Authors: P. Deutsch, R. Schoultz, P. Faltstrom, and C. Weider
- Affiliations: Deutsch, Faltstrom, and Weider are from BUNYIP INFORMATION SYSTEMS, Inc. Schoultz is from KTHNOC.
- Category: Standards Track 🦋
- Date: August 1995
- Obsoletes/Updates: the title block doesn't list anything it obsoletes or updates
Status of this Memo ⭐
this doc specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 for the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so share away 💖
Abstract 🌸
okay so WHOIS++ is an extension of the trivial WHOIS service from RFC 954 that lets WHOIS-like servers share more structured info with the Internet 🧚 it adds an extended WHOIS data model and query protocol, plus a companion extensible, distributed indexing service. there are also new options, like multiple languages and character sets, more advanced search expressions, structured data, and a bunch of other useful features. and there's an optional authentication mechanism to protect all or part of the WHOIS++ information database from unauthorized access 🔐 it's giving security glow-up.
Table of Contents 🍓
Part I - WHOIS++ Overview ................................. 3
1.1. Purpose and Motivation .............................. 3
1.2. Basic Information Model ............................. 4
1.2.1. Changes to the current WHOIS Model ................ 5
1.2.2. Registering WHOIS++ servers ....................... 5
1.2.3. The WHOIS++ Search Selection Mechanism ............ 7
1.2.4. The WHOIS++ Architecture .......................... 7
1.3. Indexing in WHOIS++ ................................. 8
1.4. Getting Help ........................................ 9
1.4.1. Minimum HELP Required ............................. 9
1.5. Options and Constraints ............................. 10
1.6. Formatting Responses ................................ 10
1.7. Reporting Warnings and Errors ....................... 11
1.8. Privacy and Security Issues ......................... 11
Part II - WHOIS++ Implementation .......................... 12
2.1. The WHOIS++ interaction model ....................... 12
2.2. The WHOIS++ Command set ............................. 12
2.2.1. System Commands ................................... 13
2.2.1.1. The COMMANDS command ............................ 14
2.2.1.2. The CONSTRAINTS command ......................... 15
2.2.1.3. The DESCRIBE command ............................ 15
2.2.1.4. The HELP command ................................ 15
2.2.1.5. The LIST command ................................ 15
2.2.1.6. The POLLED-BY command ........................... 15
2.2.1.7. The POLLED-FOR command .......................... 16
2.2.1.8. The SHOW command ................................ 16
2.2.1.9. The VERSION command ............................. 16
2.2.2. The Search Command ................................ 16
2.2.2.1. Format of a Search Term ......................... 17
2.2.2.2. Format of a Search String ....................... 18
2.3. WHOIS++ Constraints ................................. 19
2.3.1. Required Constraints .............................. 20
2.3.2. Optional CONSTRAINTS .............................. 21
2.3.2.1. The SEARCH Constraint ........................... 22
2.3.2.2. The FORMAT Constraint ........................... 22
2.3.2.3. The MAXFULL Constraint .......................... 22
2.3.2.4. The MAXHITS Constraint .......................... 23
2.3.2.5. The CASE Constraint ............................. 23
2.3.2.6. The AUTHENTICATE Constraint ..................... 23
2.3.2.7. The NAME Constraint ............................. 23
2.3.2.8. The PASSWORD Constraint ......................... 23
2.3.2.9. The LANGUAGE Constraint ......................... 23
2.3.2.10. The INCHARSET Constraint ....................... 24
2.3.2.11. The IGNORE Constraint .......................... 24
2.3.2.12. The INCLUDE Constraint ......................... 24
2.4. Server Response Modes ............................... 24
2.4.1. Default Responses ................................. 25
2.4.2. Format of Responses ............................... 25
2.4.3. Syntax of a Formatted Response .................... 26
2.4.3.1. A FULL format response .......................... 26
2.4.3.2. ABRIDGED Format Response ........................ 27
2.4.3.3. HANDLE Format Response .......................... 27
2.4.3.4. SUMMARY Format Response ......................... 27
2.4.3.5. SERVERS-TO-ASK Response ......................... 28
2.4.4. System Generated Messages ......................... 28
2.5. Compatibility with Older WHOIS Servers .............. 29
3. Miscellaneous ......................................... 29
3.1. Acknowledgements .................................... 29
3.2. References .......................................... 29
3.3. Authors' Addresses .................................. 30
Appendix A - Some Sample Queries .......................... 31
Appendix B - Some sample responses ........................ 31
Appendix C - Sample responses to system commands .......... 33
Appendix D - Sample whois++ session ....................... 35
Appendix E - System messages .............................. 36
Appendix F - The WHOIS++ BNF Grammar ...................... 38
Appendix G - Description of Regular expressions ........... 401. Part I - WHOIS++ Overview 🦋
1.1. Purpose and Motivation 💭
so the current NIC WHOIS service [HARR85] is a very limited directory service. it has info about a small number of Internet users registered with the DDN NIC 🗂️ over time it got extra features and similar services popped up on other hosts, but honestly those additions were ad hoc and uncoordinated, which is a whole mess ngl 🙈
the basic WHOIS model treats each record like a Rolodex card: a block of text with a unique identifier (a handle) and very little structure. you can search for strings inside a record, or look up a record by its handle, using a super simple query-response protocol.
it's useful, sure, but the current NIC WHOIS service can't work as a general White Pages for the whole Internet 💀 one server can't guarantee a response or reliability, a full-scale directory would generate huge traffic, and it could have a massive number of users. so yeah, a trivial architecture like this is obviously not built for what the Internet needs from information services. not it 😭
this document describes the architecture and protocol for WHOIS++, which is a simple, distributed, and extensible information lookup service built on a small set of extensions to the original WHOIS model ✨ these extensions let the new service meet the community's need for a simple directory, and the extensible design is expected to be useful in lots of other information service areas too 🌈
the new features include an extension to the trivial WHOIS data model and query protocol, plus a companion extensible, distributed indexing service. there are also other options, like boolean operators, more powerful search constraints and search methods, and structured data that makes both the client and server parts of the conversation stricter and easier to parse 💅 there's an optional authentication mechanism too, to protect all or part of the WHOIS++ information database from unauthorized access, and it's briefly described here 🔐
the WHOIS++ architecture lets directory contents be maintained in a distributed way, and it lets you use the WHOIS++ indexing service to find more WHOIS++ servers 🧚 there's a general overview of that service included for completeness, but the indexing extensions are described in a separate paper.
1.2. Basic Information Model 🌸
WHOIS++ is centered on a recommendation to structure user information around a set of standardized information templates. these templates are ordered sets of data elements, also called attribute-value pairs 🍓
adding these structured templates to a server, then finding and searching them, is meant to be simple. making and using customized templates should also be possible with little effort, although their use should be discouraged where suitable standardized templates already exist 🙅♀️
we also offer ways for users to limit searches to desired attributes or template types. that's in addition to the existing commands for specifying handles or simple strings 🎀
the minimalist approach is expected to find a home where the high cost of setting up and running traditional White Pages services can't currently be justified 💖
also, the architecture makes no assumptions about the search and retrieval mechanisms used inside individual servers. operators are free to use dedicated database formats, fast indexing software, or even gateways to other directory services to store and retrieve information, if they want 🫶
the WHOIS++ server basically works as a known front end, offering a simple data model and communicating over a well-known port and query protocol 🦋 the format of both queries and replies is structured so client software can generate searches and display results. at the same time, some effort went into keeping responses at least somewhat readable by humans, so entry cost stays low and debugging is easier 🌈
as for the actual implementation details of an individual WHOIS++ search engine, those are left to the implementor 👑 the hope is that this simple, extensible approach will encourage experimentation and better search engines ✨
1.2.1. Changes to the current WHOIS Model 💅
okay so the current WHOIS model is giving very basic 🥺. The NIC WHOIS database is just a pile of individual records, and each record gets its own unique identifier, called the "handle." Each record is a bunch of lines of info, with zero structure and no real ordering. You can kind of tell each record is about one user or one service, but the database never actually says so.
We made two big glow-ups to this model ✨. First, the info is structured as collections of data elements, which are simple attribute/value pairs. Every record holds a specific, ordered set of these elements 🎀.
Second, the records are now typed 🦋. Each record is built from one of a defined set of templates, and every template has a fixed, specific number of data elements. This means users can easily narrow their searches to certain collections of info, like info about people, services, paper abstracts, software descriptions, and more. Main character energy 👑.
One last upgrade: every WHOIS++ database on the Internet has to be given a unique handle, just like each record has its own handle 🔥.
The WHOIS++ database structure is shown in Fig. 1 🌸.
______________________________________________________________________
| |
| + Single unique WHOIS++ database handle |
| |
| _______ _______ _______ |
| handle3 |.. .. | handle6 |.. .. | handle9 |.. .. | |
| _______ | _______ | _______ | |
| handle2 |.. .. | handle5 |.. .. | handle8 |.. .. | |
| _______ | _______ | _______ | |
| handle1 |.. .. | handle4 |.. .. | handle7 |.. .. | |
| |.. .. | |.. .. | |.. .. | |
| ------- ------- ------- |
| Template Template Template |
| Type 1 Type 2 Type 3 |
| |
| |
| |
| |
| Fig.1 - Structure of a WHOIS++ database. |
| |
| Notes: - Entire database is identified by a single unique WHOIS |
| handle. |
| - Each record has a single unique handle and a specific set |
| of attributes, determined by the template type used. |
| - Each value associated with an attribute can be any ASCII |
| string up to a specified length. |
|______________________________________________________________________|1.2.2. Registering WHOIS++ servers 🦄
here's the plan: individual database handles get registered through the Internet Assigned Numbers Authority (the IANA), which keeps them unique 🔐. That way, every WHOIS++ entry on the Internet is a unique pair: a server handle plus a record handle. Iconic. 💖
Using a registered handle is way better than using the host's IP address 🙅♀️. The WHOIS++ server for a domain might move around over time, and an IP address would not survive that. If we keep the unique WHOIS++ handle through a move, we can still use it for resource discovery and networked information retrieval (see [IIIR] for a discussion of resource and discovery and support issues) 🧚.
There are many ways to guarantee that server handles are unique. We'll talk about those in a separate paper 📄.
We really believe that organizing info around these templates makes life easier for administrators, which means they're more likely to actually make their info available 🙌. And as users get familiar with the data elements in each template, they'll be way better at building their searches, which makes the whole service more useful 💅.
1.2.3. The WHOIS++ Search Selection Mechanism 🔍
The WHOIS++ search mechanism is meant to be super simple 🫶. A search command is made of one or more search terms, plus an optional set of global constraints (specifiers that modify or control a search).
Search terms let the user specify a template type, an attribute, a value, or a handle that any returned record must satisfy. Each search term can also have an optional set of local constraints that only apply to that one term 🎯.
Think of a WHOIS++ database as one big rolodex-style collection of typed records 📇. Each term adds another constraint that the selected output records have to meet. So every term does a subtractive selection: any record that doesn't fulfil the term gets thrown out of the result set 🗑️. Boolean searches are possible too, using AND, OR, NOT and parentheses 🧠.
1.2.4. The WHOIS++ Architecture 🏗️
The WHOIS++ directory service is split into two components: the base level server, which is described in this paper, and an indexing server 🧩. A single physical server can act as both a base level server and an indexing server.
A base level server only contains filled templates 📝. An indexing server holds forward knowledge (q.v.) and pointers to other indexing servers or base level servers 🗺️.
1.3. Indexing in WHOIS++ 🗂️
Indexing is what ties lots of base level servers and index servers together into one unified directory service 💫.
Every base level server and index server that wants to join this unified directory service has to generate "forward knowledge" for the entries it contains 🎁. One type of forward knowledge is the "centroid" 💜.
Here's an example of a centroid 👀. Say a whois++ server contains exactly three records, like this:
Record 1 Record 2
Template: Person Template: Person
First-Name: John First-Name: Joe
Last-Name: Smith Last-Name: Smith
Favourite-Drink: Labatt Beer Favourite-Drink: Molson Beer
Record 3
Template: Domain
Domain-Name: foo.edu
Contact-Name: Mike Foobarthe centroid for this server would be:
Template: Person
First-Name: Joe
John
Last-Name: Smith
Favourite-Drink:Beer
Labatt
Molson
Template: Domain
Domain-Name: foo.edu
Contact-Name: Mike
FoobarAn index server then collects this centroid for the server as forward knowledge 📥.
Index servers can collect forward knowledge for any servers they want 🫧. Basically, every server the index server knows about can be searched with one single query to the index server. The index server holds the forward knowledge along with pointers to the servers it indexes, and it can refer the query to any servers that might have info that matches 🎯.
Implementors of this protocol are strongly encouraged to build centroid generation into their servers 💖.
-------------------------------------------------------------------
____ ____
top level | | | |
whois index | | | |
servers ---- ----
____ ____
first level | | | |
whois index | | | |
servers ---- ----
____ ____ ____
individual | | | | | |
whois servers | | | | | |
---- ---- ----
Fig. 2 - Indexing system architecture.
-------------------------------------------------------------------1.4. Getting Help 🆘
Another upgrade to basic WHOIS is that every server has to support at least a minimal set of help commands 🩷. Users can find out about the individual server and about the whole WHOIS++ service. This works through the new extended information model: there are two specific template formats, and each server has to offer at least one example record of each format. So the operator of each WHOIS service is expected to have at least one SERVICES record and one HELP record, both reachable through the right commands 📚.
1.4.1. Minimum HELP Required 🙋♀️
Running this command:
DESCRIBEgives brief info about the WHOIS++ server 🖥️.
Running this command:
HELPgives a brief description of the WHOIS++ service itself 🌈.
The text of both required help records should contain pointers to additional help subjects that are available 🔗.
Running this command:
HELP <searchstring>may give info on any topic 🔎.
1.5. Options and Constraints ⚙️
The WHOIS++ service runs on a minimal core set of commands and controlling constraints 🧱. A small set of extra optional commands and constraints can also be supported. These let users do things like set up security options, modify the info contents of a server, or add multilingual support 🌍. The required set of WHOIS++ commands is summarized in section 2.2. WHOIS++ constraints are described in section 2.3. Optional constraints are described in section 2.3.2 📖.
1.6. Formatting Responses 🎀
The output a WHOIS++ server returns is structured so machines can parse and handle it automatically 🤖. What's especially useful is being able to return summary info about a search, without having to send back the entire results 📊.
All search output comes back in one of five output formats: FULL, ABRIDGED, HANDLE, SUMMARY or SERVER-TO-ASK 💅. Heads up, though: a conforming server is only required to support the first four formats 👀.
When it's available, SERVER-TO-ASK format is used to say that a search can't be completed, but one or more alternative WHOIS++ servers might be able to do it 🦋.
The details of each output format are specified in section 2.4 ✨.
1.7. Reporting Warnings and Errors 🚨
The formatted response from WHOIS++ commands can encode warning or error messages, which makes parsing and machine handling easier 🫶. The syntax of the output formats is described in detail in section 2.4, and the details of WHOIS++ warnings and error conditions are in Appendix E 📚.
All system messages are numerical, but they can be tagged with text 🔢. It's up to the client whether that text gets shown to the user 🙋♀️.
1.8. Privacy and Security Issues 🔒
okay bestie, so WHOIS++ was originally built as a simple lookup service with no authentication at all 🫶. But sometimes you do need to prove who you are, so there's an optional way to authenticate each WHOIS++ transaction ✨.
The current authentication mechanism is PASSWORD, which is simple password authentication 🔑. Any other scheme name has to begin with the characters X-, and that means it's experimental and non-standard 🧪. Not standard, so be careful, babe 💀.
Also, the authentication mechanism doesn't pick the actual authentication scheme for you. It's just a framework that says "this transaction needs auth" and "here are the mechanisms to use" 💅. It's extensible, so individual implementors are free to add their own mechanisms 🌈.
This document also includes a very simple authentication scheme, where a username and password get sent together with the search string, so the server can check that the user has access to the information 🎀. But real talk: this is NOT by any means a method recommended to secure the data itself, because both the password and the information get transferred unencrypted over the network 😭. Do not use this as your security blanket, fr fr.
Here's the tea 🍵. Default services like white pages are unauthenticated, so people can either forget about the implications and just show all the data to the whole public Internet 🙈, or they panic that the Internet is so dangerous that everything gets hidden, and then the whole idea of a global white pages service is lost 💔. So the type of authentication scheme you pick and the public nature of the Internet both still have to be taken into account when you assess the security and authentication of the information being served 🦋.
A more detailed exposition on security is outside the scope of this document 📚.
2. Part II - WHOIS++ Implementation 💖
2.1. The WHOIS++ interaction model
okay so a WHOIS++ server will normally listen for TCP connections on the allocated WHOIS++ port 🔌 (though honestly, a WHOIS++ server can be accessed over any TCP connection, so it's flexible). Once a connection is established, the server sends out a banner message and then just waits for input 👀. The command in that input gets processed, the results get returned, and then there's an ending system message 🎬. If the optional HOLD constraint hasn't been specified, the connection gets terminated right after that ✂️.
Now, if the server supports the optional HOLD constraint, and that constraint shows up in any command, the server keeps listening on the connection for another line of input 🧚. This keeps going for as long as the sender keeps adding the required HOLD constraint to each new command 🔁.
Also, each server is allowed to set an optional timeout value, and that value should be shown in the response to the CONSTRAINTS command ⏰. If there's a timeout, the server is free to kill an idle connection at any time after that delay has passed with no input from the client 💤. If the server does end the connection because of the timeout, the system message will say so 📩. And the client can't change the timeout value, so don't even try, bestie 🙅♀️.
2.2. The WHOIS++ Command set
There are two types of WHOIS++ commands: system commands and the WHOIS++ search command 💅.
The whole command set is made up of a core set of required system commands, one required search command, and an optional set of system commands that support features not every server has to support 🧩. The required system commands are listed in Table I, and the details on allowable search terms for the search command are in Table II 📋.
Each WHOIS++ command can also use one or more controlling constraints, which can override defaults or otherwise change how the server behaves 🎛️. There's a core set of constraints that every conforming server must support: SEARCH (which controls the type of search), FORMAT (which decides the output format), and MAXHITS (which decides the max number of matches a search can return) 🔥. These required constraints are summarized in Table III 📝.
There's also an extra set of optional constraints for supporting different character sets, showing whether a transaction needs authentication (and what kind), and letting you run multiple transactions in one session 🌸. Those are listed in Table IV 🦄.
And here's a cute trick 🪄: using the required COMMANDS and CONSTRAINTS system commands, you can ask any WHOIS++ server what commands and constraints it supports 🕵️♀️.
2.2.1. System Commands
System commands are how you talk to the server for info or to control how it operates 🛠️. They include commands to list the template types a server has, to get one blank template of any available type, and to get the list of valid commands and constraints on a server 📜.
There are also commands to get the current version of the WHOIS++ protocol supported, to use a simple help subsystem, and to get a brief description of the service 📣. That description is meant to help with automatically registering the service with yellow pages directory services, among other things 🗂️. All of these commands are required from a conforming WHOIS++ server 💯.
------------------------------------------------------------------------
Short Long Form Functionality
----- --------- -------------
COMMANDS [ ':' HOLD ] list valid WHOIS++ commands
supported by this server
CONSTRAINTS [ ':' HOLD ] List valid constraints
supported by this server
DESCRIBE [ ':' HOLD ] Describe this server,
formating the response
using a standard
"Services" template
'?' HELP [<string> [':' <cnstrnts>]] System help, using a "Help"
template
LIST [':' <cnstrnts>] List templates supported
by this system
POLLED-BY [ ':' HOLD ] List indexing servers
that are know to track
this server
POLLED-FOR [ ':' HOLD ] List information about
what this server is
tracking for
SHOW <string> [':' <cnstrnts>] Show contents of templates
specified
VERSION [ ':' HOLD ] return current version of
the protocol supported.
Table I - Required WHOIS++ SYSTEM commands.
------------------------------------------------------------------------Below are descriptions of each command. Examples of responses to each command are in Appendix C 🎀.
2.2.1.1. The COMMANDS command
The COMMANDS command returns a list of the commands the server supports 📃. The response is formatted as a FULL response 💅.
2.2.1.2. The CONSTRAINTS command
The CONSTRAINTS command returns a list of constraints and the values of those the server supports ✨. The response is formatted as a FULL response, and every constraint gets its own separate record 🗃️. The template name for these records is CONSTRAINT, and no attention is paid to handles 🙈. Each record has, at minimum, these two fields:
"Constraint", which holds the attribute name being described"Default", which shows the default value for that constraint
And if the client is allowed to change the value of the constraint, there's also a:
"Range"field, which lists the values this server supports as a comma separated list, or, if the range is numerical, as a pair of numbers separated with a hyphen 🌈
2.2.1.3. The DESCRIBE command
The DESCRIBE command gives a brief description of the server in a "Services" template 🧁. The result is formatted as a FULL response 💖.
2.2.1.4. The HELP command
The HELP command takes an optional argument, which is the subject you want help with 🆘.
2.2.1.5. The LIST command
The LIST command returns the names of the templates available on the server 📚. The answer comes back in FULL format 💅.
2.2.1.6. The POLLED-BY command
The POLLED-BY command returns a list of servers, along with the templates and attribute names those servers polled as centroids from this server 🕸️. The format is FULL with two attributes, Template and Field. Each of these is a list of the names of the templates or fields that were polled 🦋. An empty result means either that the server isn't polled by anyone, or that it doesn't support indexing 🫠.
2.2.1.7. The POLLED-FOR command
The POLLED-FOR command returns a list of servers that this server has polled, plus the template and attribute names for each one 🔍. The answer is in FULL format with two attributes, Template and Field 🎀. An empty result means either that the server isn't polling anyone, or that it doesn't support indexing 🥲.
2.2.1.8. The SHOW command
The SHOW command takes a template name as its argument and returns info about that specific template, formatted as a FULL response 🪞. The answer is a blank template with the name you requested 🫧.
2.2.1.9. The VERSION command
The output is a FULL response containing a record with the template name VERSION 🏷️. That record must have an attribute named "Version", and its value is "1.0" for this version of the protocol 👑. The record may also have the extra fields "Program-Name" and "Program-Version", which give info about the server implementation if the server wants to share it 🧚♀️.
2.2.2. The Search Command
A search command is made up of one or more search terms, which might each have local constraints, followed by an optional colon and a set of global search constraints 🔎.
Each attribute value in the WHOIS++ database gets divided into one or more words separated by whitespace, and each search term operates on every word in that attribute value 🧠.
You can combine two or more search terms with the boolean operators AND, OR, or NOT (on top of the implied AND between terms) 🧮. AND has higher precedence than OR, but you can change that with parentheses 🍓.
Search constraints that apply to every search term are called global constraints 🌍. Local constraints override global constraints for the search term they're attached to 💫. The search terms and the global constraints are separated with a colon (:), and any additional global constraints get tacked onto the end of the search command, delimited with a semicolon (;) 🩷.
If the different search constraints can't all be fulfilled, or they just can't be combined, the server may choose to ignore some of the constraints, but still do the search and return some records 🤷♀️.
The required constraints are summarized in Table III, and the optional constraints are summarized in Table IV 📑.
And as an option, the server may accept specs for attributes to include or exclude from a reply 🪄. So users could ask for only certain attributes to come back, or ask for specific attributes to be filtered out, which lets them create custom views 💜. It's giving main character energy 👑.
2.2.2.1. Format of a Search Term ✨
Okay bestie, so every search term is one of these four forms:
- A search string, followed by an optional semicolon and a set of semicolon-separated local constraints.
- A search term specifier (as listed in Table II), followed by
=, followed by a search string, an optional semicolon and a set of semicolon-separated local constraints. - An abbreviated search term specifier, followed by a search string, followed by an optional semicolon and a set of semicolon-separated local constraints.
- A combination of attribute name, followed by
=, followed by a search string, followed by an optional semicolon and a set of semicolon-separated local constraints.
If you don't give a term identifier, the search only checks attribute values. That's the same as using the identifier VALUE 💅
If you use the SEARCH-ALL specifier, the search checks everything: all template names, handles, attribute names and attribute values 🔥
When the user writes the term like "<attribute_name> = <value>", that counts as an ATTRIBUTE-VALUE search 🎀
For how the system reply is formatted, and how to pick the right reply format, check out section 2.4 📖
-------------------------------------------------------------------
Valid specifiers:
-----------------
Name Functionality
---- -------------
ATTRIBUTE-VALUE [ ';' <constrnt>]* allows combining
attribute and value
specifiers in one term.
HANDLE [ ';' <constrnt>]* Confine search to handles.
SEARCH-ALL [ ';' <constrnt>]* Search everything.
TEMPLATE [ ';' <constrnt>]* Confine search to
template names.
VALUE [ ';' <constrnt>]* Confine search to attribute
values. This is the default.
(Note: The name HANDLE can be replaced with the shortname '!')
Acceptable forms of a search specifier:
---------------------------------------
1) <searchstring> [';' <constraint>]*
2) <specifier> = <searchstring> [';' <constraint>]*
3) <shortspecifier> <searchstring> [';' <constraint>]*
4) <attribute_name> = <searchstring> [';' <constraint>]*
(Note: A <constraint> is a name of a valid local constraint.)
Table II - Valid search command term specifiers.
-------------------------------------------------------------------2.2.2.2. Format of a Search String 🧵
Special characters that need quoting get a backslash, \, in front of them.
These are the special characters:
- space
' ' - tab
- equal sign
'=' - comma
',' - colon
':' - backslash
'\' - semicolon
';' - asterisk
'*' - period
'.' - parenthesis
'()' - square brackets
'[]' - dollar sign
'$' - circumflex
'^'
If the search term is written in a character set other than ISO-8859-1, it must be specified with the constraint INCHARSET 🌍
2.3. WHOIS++ Constraints 💜
Constraints are the server's hints 🎀
Constraints are hints or recommendations to the server about how to handle a command. They can also override default behaviour, like asking the server not to drop the connection after a command finishes 🔌
So a user might send SEARCH=exact, which means the search engine should do an exact match. They might also send LANGUAGE=Fr, which means the server should use French for fuzzy matches. They could even get system messages in French 🇫🇷
In general, constraints look like <constraintname>=<value>, where <value> is one of a set of valid values. The one big exception is HOLD, which takes no argument 🙈
Every constraint can be used as a global constraint, but only a few can be used as local ones. Check Tables IV and V to see which ones are local 👀
The CONSTRAINTS system command lists the search constraints a particular server supports 📋
If a server can't satisfy a constraint, the reply will tell the user through system messages. The search still happens, and the server simply ignores the constraints it doesn't support 🫶
2.3.1. Required Constraints 🔒
The following CONSTRAINTS must be supported in all conforming WHOIS++ servers.
------------------------------------------------------------------
Format LOCAL/GLOBAL
------ -------------
SEARCH= {exact | lstring } LOCAL/GLOBAL
FORMAT= {full | abridged | handle | summary } GLOBAL
MAXHITS= { 1-<max-allowed> } GLOBAL
Table III - Required WHOIS++ constraints.
------------------------------------------------------------------2.3.2. Optional CONSTRAINTS 🌈
The following CONSTRAINTS and constraint values are optional for a conforming WHOIS++ server, but a server may support them. If a server does support them, their names and supported values must be returned in the response to the CONSTRAINTS command ✨
---------------------------------------------------------------------
Format LOCAL/GLOBAL
------ -------------
SEARCH= { regex | fuzzy | substring | <X-format> } LOCAL/GLOBAL
CASE= { ignore | consider } LOCAL/GLOBAL
FORMAT= { server-to-ask | <X-format> } GLOBAL
MAXFULL= { 1-<max-allowed> } GLOBAL
AUTHENTICATE= password GLOBAL
NAME= <string> GLOBAL
PASSWORD= <string> GLOBAL
INCHARSET= { us-ascii | iso-8859-* } GLOBAL
LANGUAGE= <As defined in ISO 639:1988> GLOBAL
HOLD GLOBAL
IGNORE= {attributelist} GLOBAL
INCLUDE= {attributelist} GLOBAL
Table IV - Optional WHOIS++ constraints.
----------------------------------------------------------------------2.3.2.1. The SEARCH Constraint 🔍
The SEARCH constraint picks the method used for the search. The default method is exact. Here's what each method does:
exact: the search succeeds for a word that exactly matches the search string.substring: the search succeeds for a word that matches a part of a word.regex: the search succeeds for a word when a regular expression matches the searched data. Regular expressions are built from'*','.','^','$'and'[]'. For more on regular expressions, see Appendix G 🧠fuzzy: the search succeeds for words that match the search string using an algorithm designed to catch closely related names with different spellings, like names that sound the same. The server picks the algorithm, and it may change depending on template name, attribute name and language used (see Constraint Language above) 🎧lstring: the search succeeds for words that begin with the search string.
2.3.2.2. The FORMAT Constraint 📄
The FORMAT constraint describes what format the result comes back in. The default format is FULL. For a description of each format, see Server Response Modes below 💅
2.3.2.3. The MAXFULL Constraint 🔐
The MAXFULL constraint sets the number of matching records the server allows before it switches to SUMMARY responses. The client can try to override this value by setting a different one for that constraint. For example, if the server returns SUMMARY format once there are more than 2 hits for privacy reasons, the server sets MAXFULL to 2 🙈
No matter what format the client asked for, the server changes the response format to SUMMARY when the number of matching records equals or goes over this value ⭐
2.3.2.4. The MAXHITS Constraint 🎯
The MAXHITS constraint sets the maximum number of records the client can get in a search response 🍓
2.3.2.5. The CASE Constraint 🔤
The CASE constraint decides whether the search is case sensitive. By default, case is ignored 🌸
2.3.2.6. The AUTHENTICATE Constraint 🔑
The AUTHENTICATE constraint says which authentication method to use when running the search. Some authentication methods need other constraints too, and the method itself will say which ones 🗝️
The only authentication method described in this document is password. If you use it, the constraints name and password also need to be set 🫣
2.3.2.7. The NAME Constraint 🪪
The NAME constraint only works together with an authentication method named by the authenticate constraint. The only use described in this document is sending a username string. That username, along with the string given to the password constraint, is sent to the server. The server can use that pair of strings for a simple authentication check, a bit like the UNIX login program 🐧
2.3.2.8. The PASSWORD Constraint 🔐
The PASSWORD constraint also only works together with an authentication method named by the authenticate constraint. The only use described in this document is sending a password string. That password, along with the string given to the name constraint, is sent to the server. The server can use that pair of strings for a simple authentication check, similar to the UNIX login program 🖥️
2.3.2.9. The LANGUAGE Constraint 🗣️
The LANGUAGE constraint can give extra info to the fuzzy matching search method. It can also tell the server to send system responses in another language, although the client should really handle that part 💬 The language code defined in RFC 1766 [ALVE95] can be used as a value for the language constraint. Letter case doesn't matter in these codes 🌏
2.3.2.10. The INCHARSET Constraint 🔡
The INCHARSET constraint tells the server which character set the search string itself is written in. The default character set is ISO-8859-1 🇪🇺
2.3.2.11. The IGNORE Constraint 🙅
The IGNORE constraint says which attributes NOT to include in the result. All other attributes get included, just as if they were named explicitly by the include constraint.
If an attribute is named in both theincludeandignoreconstraints, the attribute is included in the result, but the system message must be% 205 Requested constraint not fulfilled. ⚠️
2.3.2.12. The INCLUDE Constraint 🧺
The INCLUDE constraint says which attributes to include in the result. All other attributes get excluded, just as if they were named explicitly by the ignore constraint.
If an attribute is named in both theincludeandignoreconstraints, the attribute is included in the result, but the system message must be% 205 Requested constraint not fulfilled. ⚠️
2.4. Server Response Modes ✨
okay so WHOIS++ servers have five response modes 🎀: FULL, ABRIDGED, HANDLE, SUMMARY and SERVER-TO-ASK. Each one has its own output format, and we get into the exact details in the next sections 💅.
- FULL: the complete contents of a template that matches your query, including the template type, the server handle, and an optional record handle 💖.
- ABRIDGED: a quick summary with (at minimum) the server handle, the matching record handle, and the relevant info for that template ✨.
- HANDLE: one line with the server handle and record handle for a record that matched your query 🦋.
- SUMMARY: just a brief overview: how many matches there were, plus the list of template types where the matches showed up 🌸.
- SERVER-TO-ASK: only pointers to other index servers that might be able to answer your query 🧚.
The server MAY respond with a null answer, and it MAY also respond with a null answer together with a correct system message to indicate that the query was too complex 💀.
2.4.1. Default Responses
By default, a WHOIS++ server gives you FULL responses 👑. The client can change this with the global constraint format.
The server is allowed to give a SUMMARY response if the number of hits goes over the value of the global constraint maxfull 🫶.
The server will never send more matches than the value of the global constraint maxhits, and that's true in every response format 🙅. If the number of matches goes over that value, the server issues the system message 110 (maxhits value exceeded), but it still shows the responses, up to the maxhits value. This is how the server can hide the total number of possible matches for a search command 🙈.
The server response modes are summarized in Table V.
2.4.2. Format of Responses
Each response is a numerical system-generated message (which can be tagged with text), then an optional formatted response message, then a second system-generated message. Basically a sandwich 🥪.
That looks like this:
'%' <system messages> <nl>
[ <formatted response> ]
'%' <system messages> <nl>If a query has no matches, the system is NOT REQUIRED to generate any output as a formatted response, but it MUST still generate system messages 💜.
For info on the format of system messages, check out Appendix E 📖.
2.4.3. Syntax of a Formatted Response
Every formatted response is a response-specific START line, then an optional response-specific data section, then a TERMINATION line 🎀. The exception is HANDLE, which only has a START line. It's totally fine to put any number of blank lines inside a formatted response to make it easier to read 🌈.
Each line SHALL be limited to no more than 81 characters, newline included ✨. If a line (including the REQUIRED leading single space) would go over 81 characters, it gets broken into lines of no more than 81 characters. Every continuation line starts with a + in the first column instead of the leading character 🦋.
If an attribute value in a data section has a line break, the line break MUST be replaced by a CR/LF pair, and the following line begin with a - in the first column instead of the leading character. The attribute name is not repeated on consecutive lines 🔥.
A TERMINATION line is a # in the first column, then one white space character (SPACE or TAB), then the keyword END, then zero or more characters, then a newline 🫶.
A response-specific section will be one of these:
- FULL Format Response
- ABRIDGED Format Response
- HANDLE Format Response
- SUMMARY Format Response
- SERVER-TO-ASK Format Response
Here's where each one gets its details 💅:
2.4.3.1. A FULL format response
A FULL format response is a series of responses. Each one has a START line, the complete template information for the matching record, and a TERMINATION line 💖.
Each START line is a # in the first column, one white space character, the word FULL, another white space character, the name of the template type, one white space character, the server handle, a white space character, an optional record handle, and a newline 🌸.
The template information for the record comes back as a series of lines, each starting with a single space followed by the matching line of the record ✨.
The line of the record SHALL consist of a single space, the attribute name followed by a :, a single space, the value of that attribute, and a newline 💅.
2.4.3.2. ABRIDGED Format Response
Each ABRIDGED format response is a START line, a single-line excerpt of the template information from each matching record, and a TERMINATION line 🦋. The excerpt SHALL include the information that's relevant to the template type 💜.
The START line is a # in the first column, one white space character, the word ABRIDGED, a white space character, the name of the template type, a white space character, the server handle, a white space character, the record handle, and a newline 🎀.
The abridged template information comes back as a line that starts with a single space, followed by the abridged line of the record and a newline pair 🌈.
2.4.3.3. HANDLE Format Response
A HANDLE response is one single START line 🧚. It SHALL start with a # in the first column, then one white space character, the word HANDLE, a white space character, the name of the template, a white space character, the server handle, a white space character, the record handle, and a newline 💖.
2.4.3.4. SUMMARY Format Response
A SUMMARY format response is a single set of responses 🌸. It has a line listing how many matches the query got, followed by a list of every template type that satisfied the query at least once 📖.
The START line SHALL begin with a # in the first column, followed by one white space character, the word SUMMARY, a white space character, the server handle, and a newline 🔥.
Every line after that, until the TERMINATION line, starts with a leading space ✨. The first line SHALL begin with the string matches: , followed by a space, the number of responses to the query, and a newline. The second line SHALL begin with the string templates: , followed by a newline-separated list of the template types that matched the query 💅. Each line after the first one that includes the text templates: MUST begin with a - instead of a space 🙈.
2.4.3.5. SERVER-TO-ASK Response
A SERVER-TO-ASK response gives the client info about a server to contact next in order to resolve a query 🧚. If the server has pointers to more than one server, it sends additional SERVER-TO-ASK responses 🦋.
The SERVER-TO-ASK response will have a START line and a number of lines with attribute-value pairs, separated by CRLF 💖. Each line is indented with one space. A TERMINATION line marks the end of a SERVER-TO-ASK response 🌈.
Each START line is a # in the first column, one white space character, the words SERVER-TO-ASK, a white space character, the handle of the server, and a newline 🎀.
- "Server-Handle" - The server handle of the server pointed at. (req.)
- "Host-Name" - A cached host name for the server pointed at. (opt.)
- "Host-Port" - A cached port number for the server pointed at. (opt.)
Other attributes MAY be present, depending on the index server 🫶.
2.4.4. System Generated Messages
Every system-generated message MUST begin with a % as the first character and a space as the second, then a three-digit number, a space, and an optional text message 🌸. The total length of the line MUST be no more than 81 characters, including the terminating CR LF pair 📏. There's no limit to how many system messages can be generated 💜.
Multiline replies are a bit different. Every line except the last begins with %, then a space, the reply code, a hyphen, and optional text. The last line begins with %, then a space, the reply code, a space, and some optional text ✨.
System messages shown before or after the formatted response section are meant to talk about how the system is running, or about the whole query 🧚. System messages inside the output of one record during a FULL response are meant to talk about only that record. They could, for example, flag a problem with that part of the response 🙈. See Appendix E for a description of system messages 📖.
2.5. Compatibility with Older WHOIS Servers
Okay, so this format is more verbose, but it's still totally human-readable 🫶. Responses from older systems that don't follow this format are still conformant. Their responses get treated as optional text messages with no formatted response attached 🦋. Clients written to this spec would show those responses as an advisory text message, so the user can still read them 💅.
3. Miscellaneous ✨
3.1. Acknowledgements
The WHOIS++ effort started as an intensive brainstorming session at the 24th IETF in Boston, Massachusetts 🎀. Present at the birth, and contributing ideas during that early phase, were (alphabetically) Peter Deutsch, Alan Emtage, Jim Fullton, Joan Gargano, Brad Passwaters, Simon Spero, and Chris Weider 👑. Others who have since helped shape this document with feedback and suggestions include Roxana Bradescu, Patrik Faltstrom, Kevin Gamiel, Dan Kegel, Michael Mealling, Mark Prior and Rickard Schoultz 💖.
3.2 References
[ALVE95] Alvestrand H., "Tags for the Identification of
Languages", RFC 1766, UNINETT, March 1995.
[HARR85] Harrenstein K., Stahl M., and E. Feinler,
"NICNAME/WHOIS", RFC 954, SRI, October 1985.
[IIIR] Weider C., and P. Deutsch, "A Vision of an
Integrated Internet Information Service", RFC 1727
Bunyip Information Systems, Inc., December 1994.
[POST82] Postel J., "Simple Mail Transfer Protocol", STD 10,
RFC 821, USC/Information Sciences Institute,
August 1982.3.3. Authors' Addresses ✨
Meet the squad 🫶 Here's who wrote this RFC and where to find them:
Peter Deutsch
BUNYIP INFORMATION SYSTEMS, Inc.
310 St-Catherine St West,
Suite 202,
Montreal, Quebec H2X 2A1
CANADA
EMail: peterd@bunyip.com
Rickard Schoultz
KTHNOC, SUNET/NORDUnet/Ebone Operations Centre
100 44 STOCKHOLM
SWEDEN
EMail: schoultz@sunet.se
Patrik Faltstrom
BUNYIP INFORMATION SYSTEMS, Inc.
310 St-Catherine St West,
Suite 202,
Montreal, Quebec H2X 2A1
CANADA
EMail: paf@bunyip.com
Chris Weider
BUNYIP INFORMATION SYSTEMS, Inc.
2001 S. Huron Parkway, #12
Ann Arbor, MI 48104
USA
EMail: clw@bunyip.comAppendix A - Some Sample Queries 🔍
okay, this is where it gets fun 💖 The appendix is a bunch of example searches so you can see what whois++ queries actually look like in the wild. Let's go through them 🦋
Example 1: a search for author=chris and template=user.
author=chris and template=userThis gets you every record where the attribute "author" matches "chris", ignoring case. Only USER templates get searched. A record like "Author=Chris Weider" would match. This is the classic search, honestly the most typical one 💅
Example 2: a search for schoultz and rick;search=lstring.
schoultz and rick;search=lstringNow the results are all the records where one attribute value matches "schoultz" exactly, and another one has "rick" as a leading substring, both ignoring case. One matching example is "Name=Rickard choultz" (yes, that's how it's written in the original 😭).
Example 3: a search for value=phone;search=substring.
value=phone;search=substringThis one returns records whose attribute values contain *phone*, like the record "Name=Acme telephone inc.". It will NOT match the attribute name "phone" though, so no sneaky wins there 🙈 Also, since "value" is the default term specifier, you could just write "phone" and get the same result as "value=phone".
Example 4: a search for search-all=Peter ; search=substring;case=consider.
search-all=Peter ; search=substring;case=considerHere the results are all records where attribute names, template names or attribute values match "Peter", and this time case matters. One example is "Friend-Of-Peter: Yes" 🌈
Example 5: a search for ucdavis;search=substring and (gargano or joan):include=name,email.
ucdavis;search=substring and (gargano or joan):include=name,emailThis is a bigger one. It finds records that contain the words "gargano" or "joan" somewhere, and that have "ucdavis" somewhere inside a word. The only fields shown in the result are "name" and "email" ✨ Main character energy for sure.
Appendix B - Some sample responses 📦
Now we see what the server sends back. There are four kinds of response formats, and the server spits out each one in its own way 💖
1) FULL format responses:
# FULL USER SERVERHANDLE1 PD45
Name: Peter Deutsch
email: peterd@bunyip.com
# END
# FULL USER SERVERHANDLE1 AE1
Name: Alan Emtage
email: bajan@bunyip.com
# END
# FULL USER SERVERHANDLE1 NW1
Name: Nick West
Favourite-Bicycle-Forward-Wheel-Brand: New Bicy
+cles Acme Inc.
email: nick@bicycle.acme.com
My-favourite-song: Happy birthday to you!
-Happy birthday to you!
-Happy birthday dear Nick!
-Happy birthday to you.
# END
# FULL SERVICES SERVERHANDLE1 WWW1
Type: World Wide Web
Location: the world
# END
--------------------2) An ABRIDGED format response:
# ABRIDGED USER SERVERHANDLE1 PD45
Peter Deutsch peterd@bunyip.com
# END
# ABRIDGED USER SERVERHANDLE1 AE1
Alan Emtage bajan@bunyip.com
# END
# ABRIDGED USER SERVERHANDLE1 WWW1
World Wide Web the world
# END
--------------------3) HANDLE format responses:
# HANDLE USER SERVERHANDLE1 PD45
# HANDLE USER SERVERHANDLE1 AE1
# HANDLE SERVICES SERVERHANDLE1 WWW1
--------------------4) A SUMMARY HANDLE format response:
# SUMMARY SERVERHANDLE1
Matches: 175
Templates: User
- Services
- Abstracts
# ENDAppendix C - Sample responses to system commands 🧚
This is the appendix for the server's system commands, like asking what's available or what version it's running. Let's peek at each one 👀
C.1 Response to the LIST command
# FULL LIST SERVERHANDLE1
Templates: USER
-SERVICES
-HELP
# ENDC.2 Response to the SHOW command
This example shows the result after issuing "show user":
# FULL USER SERVERHANDLE1
Name:
Email:
Work-Phone:
Organization-Name:
City:
Country:
# ENDC.3 Response to the POLLED-BY command
# FULL POLLED-BY SERVERHANDLE1
Server-handle: serverhandle2
Cached-Host-Name: sunic.sunet.se
Cached-Host-Port: 7070
Template: USER
Field: ALL
# END
# FULL POLLED-BY SERVERHANDLE1
Server-handle: serverhandle3
Cached-Host-Name: kth.se
Cached-Host-Port: 7070
Template: ALL
Field: Name,Email
# ENDC.4 Response to the POLLED-FOR command
# FULL POLLED-FOR SERVERHANDLE1
Server-Handle: serverhandle5
Template: ALL
Field: Name,Address,Job-Title,Organization-Name,
+Organization-Address,Organization-Name
# END
# FULL POLLED-FOR SERVERHANDLE1
Server-Handle: serverhandle4
Template: USER
Field: ALL
# ENDC.5 Response to the VERSION command
# FULL VERSION BUNYIP.COM
Version: 1.0
Program-Name: kth-whoisd
Program-Version: 2.0
# ENDC.6 Response to the CONSTRAINTS command
# FULL CONSTRAINT COMEDIA.SE
Constraint: format
Default: full
Range: full,abridged,summary,handle
# END
# FULL CONSTRAINT COMEDIA.SE
Constraint: maxhits
Default: 200
Range: 1-1000
# END
# FULL CONSTRAINT COMEDIA.SE
Constraint: search
Default: exact
Range: exact,substring,lstring
# END
# FULL CONSTRAINT COMEDIA.SE
Constraint: maxfull
Default: 20
# ENDC.3 Response to the COMMANDS command
# FULL COMMANDS SERVERHANDLE1
Commands: commands
-constraints
-describe
-help
-list
-polled-by
-polled-for
-show
-version
# ENDAppendix D - Sample whois++ session 🎬
Okay, this is a full play-by-play of a client and a server chatting 🍓 In the transcript, the > marks what the server says and the < marks what the client says. The angle brackets are not part of the actual conversation, they're just there to show who's talking.
Client connects to the server
>% 220-Welcome to
>% 220-the whois++ server
>% 220 at ACME inc.
<name=Nick:hold
>% 200 Command okay
>
># FULL USER ACME.COM NW1
> name: Nick West
> email: nick@acme.com
># END
># SERVER-TO-ASK ACME.COM
> Server-Handle: SUNETSE01
> Host-Name: whois.sunet.se
> Host-Port: 7070
># END
># SERVER-TO-ASK ACME.COM
> Server-Handle: KTHSE01
># END
>% 226 Tranfer complete
<version
>% 200 Command okay
># FULL VERSION ACME.COM
> Version: 1.0
># END
>% 226 Tranfer complete
>% 203 Bye
Server closes the connectionSo in the example above, the client connected to a whois++ server and asked for every record where the attribute "name" equals "Nick". On top of that, it asked the server to keep the connection open after the response, using the global constraint "HOLD" 💅
The server replied with one record, plus pointers to two other servers. Those servers either hold records or point to even more servers, so it's like a whole web of info 🕸️
Then the client asked for the server's version number, this time without using HOLD. After the server answered with the protocol version, it closed the connection. Bye bye 👋
Also, notice how each response from the server starts with system message 200 (Command OK) and ends with system message 226 (Transfer Complete). That's the pattern to look for ✨
Appendix E - System messages 💬
Last stop in this part: system messages 🧁 A system message starts with a %, then a space, then a three digit number, then another space, and then an optional text message. A single line message must be no more than 81 characters long, counting the CR LF pair at the end. There's no limit on how many system messages can be generated, which is very generous of them honestly 🌸
If a system message runs over multiple lines, you put a hyphen instead of a space in column 6, right after the numeric code, on every line except the last one. The last line gets a space there instead 🫶
Example 1:
% 200 Command okayExample 2:
% 220-Welcome to
% 220-the whois++ server
% 220 at ACME inc.Here's the tea ☕ The client is not expected to parse the text part of the response, with one exception: when it gets reply 600, the text part is the name of a character set. The server uses that character set for the rest of the response. The valid values for character sets are specified in the "characterset" list in the BNF listing in Appendix F 🌈
If you're curious about the theory behind these reply codes, it's described in Appendix E in STD 10, RFC 821 [POST82] 📚
Now for the big table of system response codes 💅 Here it is, exactly as it is in the original:
List of system response codes
------------------------------
110 Too many hits The number of matches exceeded
the value specified by the
maxhits constraint. Server
will still reply with as many
records as "maxhits" allows.
111 Requested constraint not supported One or more constraints in
query is not implemented, but
the search is still done.
112 Requested constraint not fullfilled One or more constraints in
query has unacceptable value
and was therefore not used,
but the search is still done.
200 Command Ok Command accepted and executed.
The client must wait for a
transaction end system message.
201 Command Completed successfully Command accepted and executed.
203 Bye Server is closing connection
220 Service Ready Greeting message. Server is
accepting commands.
226 Transaction complete End of data. All responses to
query are sent.
430 Authentication needed Client requested information
that needs authentication.
500 Syntax error
502 Search expression too complicated This message is sent when the
server is not able to resolve
a query (i.e. when a client
sent a regular expression that
is too deeply nested).
530 Authentication failed The authentication phase
failed.
600 <token> Subsequent attribute values
are encoded in the charater
set specified by <token>.Table V - System response codes
Appendix F - The WHOIS++ BNF Grammar ✨
okay bestie, here's the whole WHOIS++ grammar in BNF 🧚 it's the official recipe for what a valid query looks like, so it's giving very precise vibes 💅
whois-command = ( system-command [":" "hold"]
/ terms [":" globalcnstrnts] ) NL
system-command = "constraints"
/ "describe"
/ "commands"
/ "polled-by"
/ "polled-for"
/ "version"
/ "list"
/ "show" [1*SP string]
/ "help" [1*SP string]
/ "?" [string]
terms = and-expr *("or" and-expr)
and-expr = not-expr *("and" not-expr)
not-expr = ["not"] (term / ( "(" terms ")" ))
term = generalterm / specificterm
/ shorthandle / combinedterm
generalterm = string *(";" localcnstrnt)
specificterm = specificname "=" string
*(";" localcnstrnt)
specificname = "handle" / "value"
shorthandle = "!" string *(";" localcnstrnt)
combinedterm = string "=" string *(";" localcnstrnt)
globalcnstrnts = globalcnstrnt *(";" globalcnstrnt)
globalcnstrnt = localcnstrnt
/ "format" "=" format
/ "maxfull" "=" 1*digit
/ "maxhits" "=" 1*digit
/ opt-globalcnst
opt-globalcnst = "hold"
/ "authenticate" "=" auth-method
/ "name" "=" string
/ "password" "=" string
/ "language" "=" language
/ "incharset" "=" characterset
/ "ignore" "=" string
/ "include" "=" string
format = "full" / "abridged" / "handle" / "summary"
/ "server-to-ask"
language = <The language code defined in RFC1766 [ALVE95]>
characterset = "us-ascii" / "iso-8859-1" / "iso-8859-2" /
"iso-8859-3" / "iso-8859-4" / "iso-8859-5" /
"iso-8859-6" / "iso-8859-7" / "iso-8859-8" /
"iso-8859-9" / "iso-8859-10" / "utf-8" /
charset-value
charset-value = 1*char
localcnstrnt = "search" "=" searchvalue /
"case" "=" casevalue
searchvalue = "exact" / "substring" / "regex" / "fuzzy"
/ "lstring"
casevalue = "ignore" / "consider"
auth-method = "password"
string = 0*char
char = "\" specialchar
/ <Characters 0-255 (decimal) except specialchar>
specialchar = " " / <tab> / "=" / "," / ":" / ";" / "\" /
"*" / "." / "(" / ")" / "[" / "]" / "^" /
"$" / "!" / "?"
digit = "0" / "1" / "2" / "3" / "4" /
"5" / "6" / "7" / "8" / "9"
NL = <CR LF (decimal 13 10)>
NOTE: Significant blanks must be escaped. The following
characters, when significant to the query, may be preceded
and/or followed by a single blank:
: ; , ( ) = !heads up: blanks that matter to your query need escaping, and only these characters are allowed a single blank before and/or after them: : ; , ( ) = ! 🙈
Appendix G - Description of Regular expressions 🌈
okay so the regex stuff in here is the same kind you'll find in tons of other apps and operating systems 💜 it's pretty simple though, and it does NOT do the logical AND and OR operators, so don't go looking for those lol 🙈
searches using regular expressions are always substring matching, unless the regex has ^ or $ in it. that's the whole vibe ✨
Character Function
--------- --------
<any except those listed in this table> Matches itself
. Matches any character
a* Matches zero or more 'a'
[ab] Matches 'a' or 'b'
[a-c] Matches 'a', 'b' or 'c'
^ Matches beginning of
a token
$ Matches end of a token
Examples
---------
String Matches Matches not
------- ------- -----------
hello xhelloy heello
h.llo hello helio
h.*o hello helloa
h[a-f]llo hello hgllo
^he.* hello ehello
.*lo$ hello helloo📦 where this page comes from
- ietf: rfc1835 1995-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms