RFC 3402
Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm
Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm 💖
okay bestie, this is RFC 3402 🦋 It's the second part of the DDDS series, and it's the one where the actual algorithm lives. It was written by M. Mealling at Verisign in October 2002 and it's a Standards Track doc (aka the real deal). It obsoletes RFC 2915 and RFC 2168, and it updates RFC 2276. So those older specs are officially retired and this one is the new hotness 🔥
Status of This Memo ✨
ok so this part is the official "what kind of doc is this" bit 💅 It's an Internet standards track protocol for the Internet community, and it's open for discussion and suggestions for improvements. If you want the current standardization state, check the "Internet Official Protocol Standards" (STD 1) list. And distribution of this memo is unlimited, so share away 🌸
Copyright Notice 🎀
Copyright (C) The Internet Society (2002). All Rights Reserved. 💜
Abstract 🌈
this doc describes the Dynamic Delegation Discovery System (DDDS) algorithm, which is how you apply dynamically retrieved string transformation rules to an application-unique string 🧚 Well-formed rules basically reflect who's in charge of managing the info linked to that string, which is giving delegation vibes 👑
It's also part of a series that's fully specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). And this is important: it is impossible to understand any doc in this series without reading the others 🙈 no skipping!!
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Algorithm . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Components of a Rule . . . . . . . . . . . . . . . . . . . . . 6
3.2 Substitution Expression Syntax . . . . . . . . . . . . . . . . 6
3.3 The Complete Algorithm . . . . . . . . . . . . . . . . . . . . 8
4. Specifying An Application . . . . . . . . . . . . . . . . . . 9
5. Specifying A Database . . . . . . . . . . . . . . . . . . . . 11
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1 An Automobile Parts Identification System . . . . . . . . . . 12
6.2 A Document Identification Service . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 171. Introduction 🦋
okay so the DDDS is used to do lazy binding of strings to data 💅 That's what lets it support dynamically configured delegation systems. The way it works is it maps some unique string to data stored in a DDDS Database by iteratively applying string transformation rules, and it keeps going until a terminal condition is reached ✨
This doc describes the general DDDS algorithm, not any one particular application or usage scenario. The whole series is specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401) [1]. Again, it is very important to note that it is impossible to read and understand a single doc in that series without reading the related ones 🙈
The DDDS's history is kind of a glow-up from work done by the Uniform Resource Name Working Group 💖 When Uniform Resource Names (URNs) [6] were first formulated, people wanted a way to find an authoritative server for a URN, even though a URN by design has no info about network locations. So a system was made that could use a database of rules, applied to a URN, to find out info about specific chunks of syntax. That system was originally called the Resolver Discovery Service (RDS) [7], and it only applied to URNs 🌸
Over time, other systems started using this same algorithm and infrastructure for non-URN stuff (see Section 6 for examples of other ways to use the DDDS) 🧚 That changed some of the underlying assumptions, so they needed clarifying. These docs update those original URN specs so new applications and rule databases can be developed in a standardized way. It's giving organization ✨
This document obsoletes RFC 2168 [11] and RFC 2915 [9], and it also updates RFC 2276 [7]. 💅
2. Terminology 🎀
ok the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be interpreted as described in RFC 2119. Those words are the strict ones, so pay attention 👑
Here's the vocab you need to know 💜
- Application Unique String: A string that is the initial input to a DDDS application. Its lexical structure must imply a unique delegation path, which gets analyzed and traced by the repeated selection and application of Rewrite Rules 🦋
- Rewrite Rule: A rule that gets applied to an Application Unique String to produce either a new key (to select a new rewrite rule from the rule database) or a final result string that gets returned to the calling application. Also simply called a Rule ✨
- First Well Known Rule: A rewrite rule that is defined by the application and is not actually in the Rule Database. It's used to produce the first valid key 🌸
- Terminal Rule: A Rewrite Rule that, when used, yields a string that is the final result of the DDDS process, rather than another database key 🛑
- Application: A set of protocols and specifications that specify actual values for the various generalized parts of the DDDS algorithm. An Application must define the syntax and semantics of the Application Unique String, the First Well Known Rule, and one or more Databases that are valid for the Application 🧚
- Rule Database: Any store of Rules where a unique key can identify a set of Rules that specify the delegation step used when that particular Key is used 💖
- Services: A common rule database may be used to associate different services with a given Application Unique String, e.g., different protocol functions, different operational characteristics, geographic segregation, backwards compatibility, etc. Possible service differences might be message receiving services for email/fax/voicemail, load balancing over web servers, selection of a nearby mirror server, cost vs performance trade-offs, etc. These Services are included as part of a Rule so the Application can make branching decisions based on whether one branch or the other applies from a Service standpoint 🍓
- Flags: Most Applications will need a way for a Rule to signal to the Application that some Rules provide particular outcomes that others do not, e.g., different output formats, extensibility mechanisms, terminal rule signaling, etc. Most Databases will define a Flags field that an Application can use to encode various values that express these signals 🌈
3. The Algorithm 💅
okay the big moment 😭 The DDDS algorithm is based on the concept of Rewrite Rules 👑 These rules get collected into a DDDS Rule Database and accessed by given unique keys. A given Rule, when applied to an Application Unique String, transforms that String into a new Key, which can be used to retrieve a new Rule from the Rule Database. That new rule then gets reapplied to the original Application Unique String, and the cycle repeats until a terminating condition is reached 🔁
Now, this part is super important 🫶 An Application MUST NOT apply a Rule to the output of a previous Rule. All Rewrite Rules for all Applications must always apply to the exact same Application Unique String that the algorithm started with. No cap, that's the rule 💀
It's a fundamental assumption that the Application Unique String has some kind of regular, lexical structure that the rules can be applied to 🧚 The DDDS also assumes the lexical element used to make a delegation decision is simple enough to fit inside the Application Unique String itself. And the DDDS does not solve the case where a delegation decision uses knowledge from outside the AUS and the Rule, like time of day, financial transactions, rights management, etc. That's just not its job 🙈
Diagrammatically, the algorithm looks like this 🦋
+--------- Application Unique String
| +-----+
| |input|
| +-------+ +---------+
| | First Well Known Rule |
| +-------+ +--------+
| |output|
| +------+
| First Key
| |
| +----<--------------<--------------+
| | |
| key (a DDDS database always |
| +-----+ takes a key and returns |
| |input| a rule) ^
| +---------+ +------------+ |
| | Lookup key in DDDS Database| |
| +---------+ +-----------+ |
| |output| |
| +------+ |
| rule set |
| | |
| | (the input to a rule |
| rule set is the rule and the AUS. ^
| +-----+ The output is always |
+---------------->|input| either a key or the result) |
+---------------+ +------------------+ |
| Apply Rules to Application Unique String| |
| until non-empty result are obtained | |
| that meet the applications requirements | |
+---------------+ +-----------------+ |
|output| |
+------+ ^
key |
| |
v |
+--------------------------------------+ |
| Was the last matching rule terminal? | No >------+
+--------------------------------------+
Yes (if the rule isn't terminal then
| its output is the new key which
| is used to find a new rule set)
+------------------------------------+
| The output of the last rule is the |
| result desired by the application |
+------------------------------------+3.1 Components of a Rule
okay so every Rule is made up of 4 pieces of info, and they're all lowkey iconic 💅
- A Priority 🔢 is just a number that decides which of two otherwise equal rules gets to go first. This lets the database say "these two rules get you roughly the same result, but one delegation path might be faster, better, or cheaper," and that tiny number handles the drama between them 💜
- A Set of Flags 🚩 are the attributes that decide if a rule is the last one applied. That final rule is the terminal rule, and its output is supposed to be what the application actually wanted ✨ Flags are unique across Applications. An Application can say it's using a flag that some other Application defined, but it has to use that other Application's definition. One Application can't redefine a Flag that belongs to another one, period 🙅♀️ This might mean a registry of Flags is needed someday, but right now it's not a requirement, so chill 🌸
- A Description of Services 🎀 describes the semantic vibes of a particular delegation branch. Sometimes two branches are basically twins, except one leads to a result with a certain set of features and the other leads to a different set. Those features can be operational stuff like load balancing, geographically based traffic segregation, or degraded-but-backwardly-compatible functions for older clients, etc. Example: two rules could both apply to the same delegation decision for a string. One rule might lead to a terminal rule that gives you info for high availability environments 🔥 and the other might lead to an archival service that's slower but way more stable over long periods of time 🦋
- A Substitution Expression ✂️ is the actual string-modifying part of the rule. It's a combo of a POSIX Extended Regular Expression [8] and a replacement string, kind of like a Unix sed-style substitution expression 🧚
3.2 Substitution Expression Syntax
okay bestie, the character set(s) the substitution expression lives in and can act on depend on BOTH the Application and the Database being used 🌈 An Application has to define which character sets are allowed for the Application Unique String. A DDDS Database spec has to define which character sets are required for producing its keys and how the substitution expression itself gets encoded. The grammar-required characters below only mean something once a specific character set is defined for the Database and/or Application, so keep that in mind 🫶
Real sed-style substitution expressions aren't appropriate for this application for a bunch of reasons, so instead the contents of the regexp field MUST follow this grammar:
subst-expr = delim-char ere delim-char repl delim-char *flags
delim-char = "/" / "!" / <Any octet not in 'POS-DIGIT' or 'flags'>
; All occurrences of a delim_char in a subst_expr
; must be the same character.>
ere = <POSIX Extended Regular Expression>
repl = *(string / backref)
string = *(anychar / escapeddelim)
anychar = <any character other than delim-char>
escapeddelim = "\" delim-char
backref = "\" POS-DIGIT
flags = "i"
POS-DIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"The result of applying the substitution expression to the String MUST result in a key that obeys the rules of the Database 🔑 (unless it's a Terminal Rule, in which case the output follows the rules of the application). Because the regular expression can be improperly specified, and then a non-conforming key can get built, client software SHOULD verify that the result is a legal database key before using it 🙈 safety first, always.
Backref expressions in the repl portion get replaced by the (possibly empty) string of characters enclosed by '(' and ')' in the ERE portion. N is a single digit from 1 through 9, inclusive, and it picks out the N'th backref expression, the one that begins with the N'th '(' and continues to the matching ')'. For example, the ERE
(A(B(C)DE)(F)G)has these backref expressions:
\1 = ABCDEFG
\2 = BCDE
\3 = C
\4 = F
\5..\9 = error - no matching subexpressionThe "i" flag means the ERE matching SHALL be performed in a case-insensitive fashion 🌸 Also, any backref replacements MAY be normalized to lower case when the "i" flag is given. This flag only has meaning when both the Application and Database define a character set where case insensitivity is valid, so it's not a free-for-all 💅
The first character in the substitution expression shall be used as the character that delimits the components of the substitution expression. There must be exactly three non-escaped occurrences of the delimiter character in a substitution expression. Since escaped occurrences of the delimiter character get interpreted as occurrences of that character, digits MUST NOT be used as delimiters 🚫 backrefs would get confused with literal digits otherwise, which is an absolute mess. Similarly, if flags are specified in the substitution expression, the delimiter character must not also be a flag character. Bestie, don't make it confusing for yourself 😭
3.3 The Complete Algorithm
okay here's the exact DDDS algorithm, and it's giving step-by-step main character energy 👑
- The First Well Known Rule is applied to the Application Unique String, which produces a Key 🗝️
- The Application asks the Database for the ordered set of Rules that are bound to that Key (see NOTE below on order details) 📋
- The Substitution Expression for each Rule in the list is applied, in order, to the Application Unique String until a non-empty string is produced. The position in the list gets noted, and the Rule that produced the non-empty string is used for the next step. If the next step rejects this rule and returns to this step, then the Substitution Expression application process continues at the point where it left off ⏯️ If the list is exhausted without a valid match, then the application is notified that no valid output was available 💀
- If the Service description of the rule doesn't meet the client's requirements, go back to step 3 and keep going through the already retrieved list of rules. If it does match the client's requirements, then this Rule is used for the next step. If and only if the client is capable of handling it, and it's deemed safe to do so by the Application's specification, the client may make a note of the current Rule but still return to step 3 as though it had rejected it. In either case, the output of this step is one and only one Rule 🎯
- If the Flags part of the Rule designates that this Rule is not Terminal, go back to step 2 with the substitution result as the new Key 🔁
- Notify the Application that the process has finished, and provide the Application with the Flags and Services part of the Rule along with the output of the last Substitution Expression 🎉
NOTE 1: In some applications and/or databases, the result set can express the case where two or more Rules are considered equal. These Rules are treated as the same Rule, each one possibly having a Priority, which is used to communicate a preference for otherwise equivalent Rules. This allows Rules to act as fallbacks for others. It should be noted that this is a real Preference, not a load balancing mechanism. Applications should define the difference carefully 🧁
NOTE 2: Databases may or may not have rules that determine when and how records within that database expire (expiration dates, times to live, etc.). These expiration mechanisms must be adhered to in all cases 🕰️ Specifically, since the expiration of a database's record could cause a new Rule to be retrieved that is inconsistent with previous Rules, while in the algorithm any attempts to optimize the process by falling back to previous keys and Rules MUST ensure that no previously retrieved Rule has expired. If a Rule has expired, then the application MUST start over at Step 1 🔄 no cap, this one is serious.
4. Specifying an Application ✨
okay so before this algorithm can do anything useful, somebody has to write a spec describing an application and one or more databases 🧚 to go with it. to specify an application, you need these pieces of info:
Application Unique String: this is the only string the rewrite rules will apply to. it needs some regular structure and has to be unique within the application, so that anyone applying Rules from the same Database ends up with the same Keys 🔑. for example, the URI Resolution application defines the Application Unique String to be a URI.
no application is allowed to define an Application Unique String in a way that the Key from a rewrite rule gets treated as the Application Unique String for a new rule 🙅♀️. that leads to sendmail style rewrite rules, which are fragile and error prone, and nobody wants that drama. the one exception is when an application defines some flag or state where its rules get suspended and a new DDDS Application (or some other set of rules) takes over. if that happens, then by definition none of these rules apply. one example is the URI Resolution application's 'p' flag, which says the next step is 'protocol specific' and therefore outside the scope of DDDS 💅.
First Well Known Rule: this is the first rule that, when applied to the Application Unique String, produces the first valid Key 🗝️. it can be written in the same form as a Rule, or it can be something more complex. for example, the URI Resolution application might say the first Key is the sequence of characters in the URI up to but not including the first colon (the URI scheme).
Valid Databases: the application can define which Databases are valid 📚. for each Database, the Application has to define how the First Well Known Rule's output (the first Key) gets turned into something valid for that Database. for example, the URI Resolution application could use the Domain Name System (DNS) as a Database, and the operation would be turning the first Key into a DNS-valid domain-name. on top of that, for each Database an Application defines, it also has to specify which character sets will produce the correct Keys. in the URI Resolution example, a URI's character set is 7 bit ASCII, which matches pretty well with DNS's 8 bit limitation on characters in its zone files. it's giving compatibility 🫶.
Expected Output: the Application has to define what the expected output of the Terminal Rule should be ✅. for example, the URI Resolution application is all about finding servers that hold authoritative data about a given URI. so the output of the terminal rule is info (hosts, ports, protocols, etc.) that's used to contact that authoritative server.
⚠️ bestie, pay attention here: there's been some confusion about load balancing and the DDDS 'Priority' 🙈. a rule's Priority is just that: a way of saying one rule is "better, faster, cheaper" than another. if an application needs a way for a client to load balance between servers (like weighted random selection, etc.), it should do that outside the DDDS algorithm. for example, applications that use the DNS Database may use the SRV record to signify that a particular service is actually handled by several hosts cooperating with each other. the difference is that load balancing happens between hosts that are identical to each other, whereas DDDS is concerned with delegation paths that have some particular feature set or administrative domain 💖.
5. Specifying A Database ✨
ok so every Application needs at least one corresponding Database to retrieve its Rules from 📦. a given Database can be used by more than one Application, and if that happens, each rule has to use some combination of its Services and/or substitution expression so it only matches the Application Unique Strings it's actually valid for 🎯.
a Database specification has to include the following pieces of info:
General Specification: the Database needs a general specification. this can reference other standards (SQL, DNS, etc.) or fully specify a novel database system 🧠. this specification MUST be clear about which character sets are allowed, so everyone knows which character set the Keys and Rules are encoded in.
Lookup Procedure: this explains how a query gets formulated and submitted to the database 🔍. if the database is used for other purposes too (like DNS), the spec has to be clear about how a query is formulated specifically for the database to act as a DDDS database. for example, a DNS based Database has to specify which Resource Records or Query Types get used.
Key Format: if any operations are needed to turn a Key into something valid for the database, those operations have to be clearly defined 🛠️. for example, with a DNS database, the Keys have to be constructed as valid domain-names.
Rule Format: the specification for the output format of a rule 📝.
Rule Insertion Procedure: a specification for how a Rule gets inserted into the database 📥. this can include policy statements about whether or not a Rule is allowed to be added.
Rule Collision Avoidance: since a Database can be shared by multiple Applications (ENUM and URI Resolution, for example), the spec has to be clear about how rule collisions get avoided 💥. there are usually two methods:
- 1) disallow one key from being valid in two different Applications.
- 2) if 1 isn't possible, write the substitution expression so the regular expression part contains enough of the Application Unique String in its match to tell the two Applications apart.
6. Examples ✨
the examples here are for pedagogical purposes only 🎓. they're taken from fictitious applications that haven't been specified in any published document, so don't go looking for them in the RFC library lol 🙃.
6.1 An Automobile Parts Identification System
imagine a system where all the automobile manufacturers come together and create a standardized part numbering system for the various parts (nuts, bolts, frames, instruments, etc.) that make up automobile manufacturing and repair 🚗. the problem is that the auto industry is a very distributed system, where parts are built by various third parties all around the world 🌍. to find info about a given part, a system has to figure out who makes that part and contact them about it.
to make this distributed system work, the identification number assigned to a part is assigned hierarchically. the first 5 digits make up a parts manufacturer ID number. the next 3 digits are an auto line identifier (Ford, Toyota, etc.). the rest of the digits get assigned by the parts manufacturer, according to rules the manufacturer decides on their own 💅.
the auto industry decides to use the DDDS to build a distributed information retrieval system that routes queries to the actual owner of the data 🦋. the industry specifies a database and a query syntax for retrieving rewrite rules (the APIDA Network), and then specifies the Auto Parts Identification DDDS Application (APIDA) 👑.
the APIDA specification would define the following:
- Application Unique String: the part number.
- First Well Known Rule: take the first 5 digits (the manufacturers ID number) and use that as the Key.
- Valid Databases: The APIDA Network.
- Expected Output: EDIFAC information about the part.
the APIDA Network Database specification would define the following:
- General Specification: a network of EDI enabled databases and services that, when given a subcomponent of a part number, will return an XML encoded rewrite rule 🧾.
- Lookup Procedure: following normal APIDA Network protocols, ask the network for a rewrite rule for the Key.
- Key Format: no conversion is required.
- Rule Format: see APIDA Network documentation for the XML DTD.
- Rule Insertion Procedure: determined by the authority that has control over each section of the part number. I.e., in order to get a manufacturer ID you must be a member of the Auto Parts Manufacturers Association 🏢.
to see how the system works, imagine the part number 4747301AB7D. the system takes the first 5 digits, '47473', and asks the network for that Rewrite Rule 🔎. this Rule is provided by the parts manufacturer's database, and it lets the manufacturer either further sub-delegate the space or point the querier directly at the EDIFAC information in the system.
in this example, let's suppose the manufacturer returns a Rule that says the next 3 digits should be used as part of a query to their service in order to find a new Rule ✨. this new Rule lets the parts manufacturer further delegate the query to their parts factories for each auto line. in our example part number, the number '01A' denotes the Toyota line of cars 🚙. the Rule the manufacturer returns further delegates the query to a supply house in Japan 🇯🇵. this Rule also denotes that it is terminal, so the result of this last query is the actual information about the part 🎀.
6.2 A Document Identification Service ✨
okay so this one is basically the last example's little cousin 🦋 The documents here are kinda like the auto parts from before, but the info about each doc lives super close to the author, usually right on their desktop 💻 So the delegations can get reeeally deep, bestie. 🌸 To stop everyone from piling into one giant flat list of authors, the authors get sorted into organizations and departments. Very neat, very organized, very iconic 💅
Let's pretend the Application Unique String looks like this:
<organization>-<department>-<author>:<project>-<bookcase>-<book>Here's how the Application spec would look:
- Application Unique String: the Document ID string given above.
- First Well Known Rule: the characters up to but not including the first
-is treated as the first Key. 🔑 - Valid Databases: the DIS LDAP Directory.
- Expected Output: a record from an LDAP server containing bibliographic information about the document in XML. 📄
Now the Database spec for the DIS LDAP Directory. Ngl this part is so satisfying 🧚
- General Specification: the Database uses the LDAP directory service. Each LDAP server has a record that contains the Rewrite Rule. Rules refer to other LDAP servers using the LDAP URL scheme. 🌈
- Lookup Procedure: using standard LDAP queries, the client asks the LDAP server for information about the Key.
- Key Format: no conversion is necessary. 🙌
- Rule Format: See the LDAP Rewrite Rule specification.
- Rule Insertion Procedure: See the procedures published by the entity that has authority over that section of the DIS tree. The first section, the organization, is owned by the DIS Agency. 👑
So in this setup, the first lookup grabs the organization's Rule. At that point the organization can point the client straight at some big, organization-wide database that has the expected output 🎀 Other orgs might decentralize it so the Rules end up delegating the query all the way down to the author's document management environment of choice. It's giving flexibility, periodt 💖
7. Security Considerations 🔐
This document just defines the DDDS algorithm, so by itself it doesn't imply any security issues. ✨ It's only when this algorithm gets coupled with a Database and an Application that the security considerations can be known well enough to list them out, beyond just saying that dynamic delegation points are a possible point of attack. 😭 Serious energy here, bestie. 💀
8. IANA Considerations 📋
This document doesn't create any requirements on the IANA. 🌸 Database and Application specifications may have considerable requirements, but they can't be listed here.
References 📚
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[6] Moats, R., "URN Syntax", RFC 2141, May 1997.
[7] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998.
[8] The Institute of Electrical and Electronics Engineers, "IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1)", IEEE Std 1003.2-1992, ISBN 1-55937-255-9, January 1993.
[9] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, August 2000.
[10] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[11] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997.
Author's Address 🖊️
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
EMail: michael@neonym.net URI: http://www.verisignlabs.com
Full Copyright Statement ⚖️
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 💜
📦 where this page comes from
- ietf: rfc3402 2002-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms