RFC 3824
Using E.164 numbers with the Session Initiation Protocol (SIP)
Title block: the RFC 3824 deets 🎀
Okay so this one is RFC 3824, titled Using E.164 numbers with the Session Initiation Protocol (SIP) 📞✨ It's from the Network Working Group and was published in June 2004. The authors are J. Peterson, H. Liu, J. Yu (all from NeuStar) and B. Campbell (from dynamicsoft). Its category is Informational, which means it gives info to the Internet community and does not specify an Internet standard 🧚. It doesn't list anything it obsoletes or updates, so it's a pretty chill standalone doc 💅
Status of This Memo 🦋
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 🌸
Copyright (C) The Internet Society (2004).
Abstract 💖
Okay, so telephone numbers show up in SIP apps all the time 📱, and a lot of those numbers can be looked up with ENUM 🔍. ENUM was actually one of the main reasons it was created, but we still need proper procedures for hooking ENUM up to SIP implementations 🫶 This doc shows how the two protocols can work together, and it clears up how ENUM records get written and processed for SIP apps. It also gives guidance for when ENUM can't be used to resolve a telephone number, for whatever reason 😭
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Handling Telephone Numbers in SIP . . . . . . . . . . . . . . 3
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 5
5. Authoring NAPTR Records for SIP . . . . . . . . . . . . . . . 6
5.1. The Service Field . . . . . . . . . . . . . . . . . . . 6
5.2. Creating the Regular Expression: Matching . . . . . . . 6
5.3. Creating the Regular Expression: The URI . . . . . . . . 7
5.4. Setting Order and Preference amongst Records . . . . . . 8
5.5. Example of a Well-Formed ENUM NAPTR Record Set for SIP. 8
6. Processing ENUM Records . . . . . . . . . . . . . . . . . . . 8
6.1. Contending with Multiple SIP records . . . . . . . . . . 8
6.2. Processing the Selected NAPTR Record . . . . . . . . . . 9
7. Compatibility with RFC 3761. . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 161. Introduction ✨
Okay so ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS (Domain Name Service, RFC 1034 [4]) to translate certain telephone numbers, like '+12025332600', into URIs (Uniform Resource Identifiers, RFC 2396 [9]), like 'sip:user@sipcarrier.com'. ENUM mainly exists so that systems that rely on telephone numbers can talk to systems that use URIs to route transactions 🔀 E.164 [10] is the ITU-T standard international numbering plan, and every globally reachable telephone number is organized under it 🌍
SIP (Session Initiation Protocol, RFC 3261 [2]) is a text-based application protocol 💬 It lets two endpoints on the Internet find each other so they can swap context info about a session they want to share. Common SIP apps include Internet telephony, instant messaging, video, Internet gaming, and other kinds of real-time communications 🎮 SIP is also a multi-service protocol, so it can start sessions involving different forms of real-time communication all at once. Main character energy 👑
The biggest thing SIP is used for right now is Voice-over-IP (VoIP) 📞 which means SIP apps end up dealing with telephone numbers a lot. The thing is, telephone numbers can't be routed using the regular DNS resolution procedures that were standardized for SIP (see [14]), since those rely on SIP URIs 😩 ENUM gives us a way to translate E.164 numbers into URIs, and those can include SIP URIs too 🙌 So this doc explains how SIP can handle telephone numbers by using ENUM. It proposes guidelines for authoring the DNS records ENUM uses, and for client-side processing once those records come back 🧁
The guidelines in this doc are aimed specifically at authoring and processing ENUM records for SIP apps. They assume you already know about Naming Authority Pointer (NAPTR) records (RFC 3403 [6]) and ENUM (RFC 3761 [1]) 🤓 Only the parts of NAPTR record authoring and processing that matter for SIP, or that need extra clarification, are covered here. These procedures don't update or override the NAPTR or ENUM core docs, so no drama there 🫶
Quick tea ☕ The ENUM spec got revised shortly before this doc was published. The revision came from the update of the NAPTR system described in RFC 2915 [12] to the Dynamic Delegation Discovery System (DDDS) family of specs (including RFC 3403). So this doc also gives some guidance for handling records designed for the original RFC 2916 [16] 📜
Here's the layout of the rest of the doc 🗺️ Section 3 suggests general behavior for SIP user agents that run into telephone numbers. Section 4 gives an overview of where SIP and ENUM overlap. The proposed normative guidelines for ENUM record authoring and processing in a SIP context are in Section 5 and Section 6 respectively. And Section 7 covers some things to think about when revising RFC 2916 ✨
2. Terminology 🎀
In this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3]. They indicate requirement levels for compliant SIP implementations 💜
3. Handling Telephone Numbers in SIP 📱
Okay so there are a bunch of reasons a user might want to start a SIP request that targets an E.164 number 🥰 One super common one is when the user is calling from the PSTN through a PSTN-SIP gateway. These gateways usually map routing info from the PSTN straight onto SIP signaling 🌉 Or a native SIP user might purposely start a session addressed to an E.164 number. Maybe the target is known by that number, or the caller's SIP user agent only has a traditional numeric keypad 🔢 A request that first targets a regular SIP URI can also get redirected to an E.164 number. Mostly these are requests for a telephony session (voice calls), but tons of other services are reached through telephone numbers too, including instant messaging 💬
Unlike a URI, a telephone number doesn't have a host name, or any hints about where to deliver a request for it on the Internet 🤷♀️ SIP user agents or proxy servers could be set up statically with a mapping of destinations for particular telephone numbers or number ranges. But the mapping is huge and complicated, so it'd be way better for SIP user agents to query for a destination right when they need one for a specific number 🧠
In that case, a user agent might use ENUM to find a URI tied to the E.164 number, including a SIP URI 💖 Any URIs found through ENUM can then be used normally to route SIP requests to their destination 🚀 Also, support for the NAPTR DNS resource record format is already specified for regular SIP URI processing in [14], so using ENUM isn't really a big departure from baseline SIP DNS routing. Lowkey easy 🦋
Most of the rest of this doc is about procedures for using ENUM. A few guidelines in the rest of this section cover cases where ENUM isn't used, for whatever reason 🫧
If a user agent can't translate an E.164 number with ENUM, it can create a type of SIP Request-URI that contains a telephone number. Since telephony is one of the most common SIP apps, a lot of work has already gone into how telephone numbers get represented in SIP 📚 In particular, the tel URL from RFC 2806 [8] has been identified as a way to carry telephone routing info within SIP. A tel URL usually consists of the number in E.164 format with a plus sign in front, like tel:+12025332600. This format is so useful that it's been built into the baseline SIP spec. The user portion of a SIP URI can contain a tel URL (without the scheme string), like sip:+12025332600@carrier.com;user=phone. So a SIP proxy server might get a request from a user agent with a tel URL in the Request-URI 🥹 One way the proxy can handle that is by launching an ENUM query itself, and then proxying the SIP request according to the ENUM records it gets back 🔁
If ENUM isn't supported, or if ENUM requests come back with no records for a telephone number, local policy can decide how to forward SIP requests with an E.164 number in the Request-URI 🧭 Usually these calls get routed to gateways that connect SIP networks with the PSTN 🌈 Those proxy server policies might be set up dynamically with routing info for telephone numbers by TRIP [15] 💅
And as a matter of precedence, SIP user agents should attempt to translate telephone numbers to URIs with ENUM, if implemented, before creating a tel URL and deferring the routing of the request to a SIP proxy server 👑 Honestly this is the main vibe for this whole section, periodt 💜
4. Design Principles ✨
Okay so the ENUM + SIP thing has always been clearly useful, but how the two should actually work together? Total drama 💅 People argued for ages about how many SIP URIs belong in ENUM, what kind of URIs they should be, and whether the "service" field of NAPTR records should carry capability info. So here's the philosophy behind every recommendation in this doc 🫶
Address-of-record SIP URIs appear in ENUM, not contact address URIs. Roughly speaking, an address-of-record is the canonical identity of a SIP user. It usually shows up in the From field of SIP requests that user sends 🎀 A contact address is the URI of a device. SIP registration (the REGISTER method) temporarily binds a device's contact address to a user's address-of-record. A DNS record has a long time-to-live compared to how long SIP registrations last 😭 Also, an address-of-record stays available even when any single device is gone. So ENUM is way better at representing a long-term identity than the URI of a device a user is only temporarily hanging out with. If ENUM were meant to point at specific devices, it would be better to translate telephone numbers to IPv4 addresses than to URIs, since URIs express something richer 💖
SIP URIs in ENUM do not convey capability information. SIP already has its own methods for negotiating capabilities between user agents. That includes SDP [13], the use of Require/Supported to negotiate extensions in RFC 3261, and callee capabilities [11] ✨ Putting more limited capability info in ENUM is at best redundant, and at worst it could mislead SIP's negotiation system 🙈 Also, addresses-of-record don't have capabilities. Only devices registered under an address-of-record actually have capabilities. And putting contact addresses in ENUM is not recommended 💀
Only one SIP URI, ideally, appears in an ENUM record set for a telephone number. Providing multiple SIP URIs that reach the same user in ENUM might seem attractive at first 👀 But if a user can be contacted at multiple addresses, you get way more flexibility when those URIs are managed by a SIP location service, and that service is identified by a single ENUM record. Behaviour for parallel and sequential forking in SIP, for example, is better handled in SIP than in a pile of ENUM records 👑
User agents, rather than proxy servers, should process ENUM records. The assumptions behind NAPTR record processing mean the ENUM client needs to know the set of enumservices supported by the entity trying to communicate. A SIP proxy server is unlikely to know the enumservices supported by the originator of a SIP request 🧚
5. Authoring NAPTR Records for SIP 🌸
This document doesn't make any assumptions about who writes NAPTR records (service providers or end users) or how a finished record gets uploaded to the right DNS servers 🤷♀️ Authorship here is only about how the NAPTR records themselves get built.
There are a few general guidelines for writing DNS records that ENUM NAPTR record set authors should keep in mind. The biggest one: authors SHOULD keep record sets relatively small, because DNS isn't built for shipping big files 📦 Five or six NAPTR records is totally reasonable, but policies that push for record sets with hundreds of NAPTR records are not appropriate 🙅♀️ Also, DNS records stick around for a long time. So authors SHOULD NOT use ENUM NAPTR records to express relationships between E.164 numbers and URIs that only exist for a short time ⏳ DNS works best when records can be trusted to stay valid for a reasonable stretch (at least several hours) 🍓
5.1. The Service Field
The Service field of a NAPTR record (per RFC 3403) holds a string token that names the protocol or service tied to that record, and it gives you a little hint about the kind of URI you'll get out of it 🔥 ENUM [1] requires that these service fields, called "enumservices", get registered with IANA.
There's an enumservice for SIP that the ENUM working group came up with (see [7]). It uses the format E2U+sip to say that a SIP address-of-record shows up in the URI field of a NAPTR record 🦋 It is strongly RECOMMENDED that NAPTR record authors use the E2U+sip service field whenever the regexp contains a SIP address-of-record URI ✨
5.2. Creating the Regular Expression: Matching
Writing the regular expression (henceforth regexp) in a NAPTR record for ENUM is way easier because there's no antecedent in the substitution (aka the section between the first two delimiters) 💖 It is RECOMMENDED that implementations use an exclamation point as the delimiter, since that's the only delimiter used throughout the ENUM core specification 🫶
When a NAPTR record gets processed, the antecedent expression is matched against the starting string (for ENUM, that's the telephone number) to help find the right record in a set 🔍 But in ENUM, the record set is found through a reverse lookup in the e164.arpa domain, which is based on the starting string. So the client usually doesn't need to analyse the starting string any further 🙌 In those cases the antecedent is usually 'greedy', meaning it uses the regexp ^.*$, which matches any starting string 🌈 Some ENUM record set authors might want the full power of regexps and create non-greedy antecedents. The DDDS standard says ENUM resolvers MUST NOT... sorry, it says they must support these regexps when they're present, so that's the vibe 😤 For a simple mapping from a telephone number to a SIP URI, a greedy regexp usually does the job ✨
Example:
"!^.*$!sip:user@example.com!"Now here's the thing. Even when the antecedent is greedy, that does not make the replacement field in NAPTR records a good alternative to writing a regexp. Authors of NAPTR records for ENUM MUST NOT use the replacement field in records with an E2U+sip service field 🚫 Literally don't do it, bestie 💀
5.3. Creating the Regular Expression: The URI
The consequent side of a regexp contains a URI. NAPTR records meant for session initiation (including SIP telephony) SHOULD use a SIP URI 📞 I know that sounds super obvious, but there are other URIs that could seem fine for SIP apps too: 'tel' URIs, 'im' or 'pres' URIs, or others describing specific services that might get invoked through SIP 👀 They can look reasonable in some situations, but putting them in NAPTR records instead of SIP URIs could weaken how services compose and how capabilities get negotiated in SIP 😬
It is RECOMMENDED that ENUM record authors always use the SIP or SIPS URI scheme when the service field is E2U+sip, and the URIs in question MUST be addresses-of-record, not contact addresses 💅
Here's the context: SIP users can register one or more contact addresses with a SIP registrar. The proxy infrastructure of an administrative domain then consults that registrar to reach the end user whenever requests come in for their address-of-record 📬 A big part of why URIs are useful is that they represent a logical service tied to a user, not a device. And if ENUM ever really needs to target specific devices instead of URIs, then a hypothetical E2IPv4+sip enumservice would be the better fit 🧚
5.4. Setting Order and Preference amongst Records
For maximal compatibility, authors of ENUM records for SIP SHOULD always use the same order value for all NAPTR records in an ENUM record set 🎀 If you do want relative preference among NAPTR records, express it solely with the preference field 🌸
5.5. Example of a Well-Formed ENUM NAPTR Record Set for SIP
$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa.
IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:user@example.com!" .
IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!" .6. Processing ENUM Records 🔥
These guidelines don't even come close to fully describing the NAPTR algorithm or how NAPTR records get processed 🙈 Implementers should get familiar with the DDDS algorithm and ENUM before reading this section, no cap 📚
Although ENUM record sets will sometimes consist of just a single E2U+sip record, this section assumes that people integrating ENUM and SIP have to be ready for more complicated scenarios 💜 Also, even though we recommend that clients be generous in what they receive, and try to make sense of potentially confusing NAPTR records, that does NOT mean we recommend any of the potentially troublesome authoring practices that make this generosity necessary 😭✨
6.1. Contending with Multiple SIP records 💅
okay so, if an ENUM query gives you back multiple NAPTR records with a service field of E2U+sip, or another service field SIP might use (like E2U+pres, see [17]) 🦋, the ENUM client first has to figure out whether it should use several records or just pick one 🤔. We already covered why authoring ENUM record sets with multiple NAPTR records for SIP is a pitfall back in Section 4 ✨.
If the ENUM client is a user agent, it eventually has to pick a single NAPTR record to serve as the Request-URI of the SIP request 🎯. If the records have different preferences, the most preferred record SHOULD be used 👑. If two or more records share the most preferred status, the ENUM client SHOULD randomly decide which one gets used 🎲, though it MAY defer to a local policy that uses some other method to pick a record 🫶.
If the ENUM client is a SIP intermediary that can act as a redirect server, it SHOULD send back a 3xx response with more than one Contact header field, one for each of the selected NAPTR records in the ENUM record set 🧚. If the NAPTR records have different preferences, you can use q values in the Contact header fields to match those preferences 💜. Or, the redirect server MAY pick a single record following the NAPTR preference fields (or randomly when no preference is specified) and send that one URI in a Contact header field in a 3xx response 🌸.
Otherwise, if the ENUM client is a SIP intermediary that can act as a proxy server, it MAY fork the request when it gets multiple appropriate NAPTR records in an ENUM record set 🔥. Depending on the relative precedence values, the proxy may want to fork sequentially or in parallel ✨. However, the proxy MUST build a route set from these NAPTR records that consists exclusively of SIP or SIPS URIs, not other URI schemes 🙈. Alternatively, the proxy server MAY select a single record following the NAPTR preference fields (or randomly when no preference is specified, or following local policy) and proxy the request with a Request-URI matching the URI field of that NAPTR record. Though again, it MUST select a record that contains a SIP or SIPS URI 💀.
Heads up, bestie: there are significant limitations when a proxy server processes ENUM record sets instead of a user agent. So it is RECOMMENDED that SIP network elements act as redirect servers rather than proxy servers after doing an ENUM query 👑
6.2. Processing the Selected NAPTR Record 🎀
Obviously, once you've picked an appropriate NAPTR record, you pull the URI out of the regexp field 💖. The URI sits between the second and third exclamation points in the string 💅. Once you've got that URI, it SHOULD be used as the Request-URI of the SIP request the ENUM query was launched for ✨.
SIP clients should do some sanity checks on the URI 🧐. Mainly they want to make sure they support its scheme, but they also want to check that it's well-formed. Clients MUST at least verify that the Request-URI does not target themselves 🙅. That's the bare minimum, bestie.
Once you've pulled an address-of-record out of the selected NAPTR record, clients follow the standard SIP mechanisms (see [14]) to work out how to forward the request 🚀. This might mean launching follow-up NAPTR or SRV queries to figure out how best to route to the domain in that address-of-record 🗺️. But clients MUST NOT make the same ENUM query recursively (if the URI returned by ENUM is or contains a tel URL, see [8]) 🚫.
Note that SIP requests based on NAPTR records can fail for any number of reasons 💀. If there are multiple SIP-relevant NAPTR records in an ENUM record set, then after a failure on the initial attempt with one NAPTR record, SIP user agents MAY retry the request with a different NAPTR record from that set 🔁.
7. Compatibility with RFC 2916 🌈
The ENUM specification is currently being revised in the ENUM WG 🛠️. The new one, RFC 3761 [1], is based on the Dynamic Delegation Discovery System [5] revision to the NAPTR resource record specified in RFC 2915 [12] 💜. For the most part, DDDS is an organizational revision that makes the algorithmic parts of record processing separable from any underlying database format (like the NAPTR DNS resource record) 🧠.
The biggest change in RFC 3761 is the concept of enumservices ✨. The original ENUM spec, RFC 2916, specified a bunch of "service" values you could use for ENUM, including sip+E2U 🍓. RFC 3761 brings in an IANA registration system with new guidelines for registering enumservices. These aren't necessarily split into separate "service" and "protocol" fields anymore, and they allow more complex structures 🧩. To tell RFC 3761 enumservices apart from RFC 2916 ones, the string "E2U" is the leading element in an enumservice field. In RFC 2916 it was the trailing element 🔄.
An enumservice for SIP addresses-of-record is described in [7] 💌. This enumservice uses the enumservice field E2U+sip 💅. RFC 3761-compliant authors of ENUM records for SIP MUST therefore use the E2U+sip enumservice field instead of the sip+E2U field 🚨. For backwards compatibility with existing legacy records, though, the sip+E2U field SHOULD be supported by an ENUM client that supports SIP 🫶.
Also, the terminology of DDDS differs in a number of ways from the initial NAPTR terminology in RFC 2916 📚. DDDS introduces the concept of an Application, an Application Specific String, a First Well Known Rule, and so on 🤓. The terminology in this document is a little looser (it refers to a 'starting string', for example, where 'Application Specific String' would be used for DDDS) 💭. The new terminology is reflected in RFC 3761 ✨.
8. Security Considerations 🔐
DNS doesn't make policy decisions about the records it shares with an inquirer 🙈. All DNS records must be assumed to be available to all inquirers at all times 😭. So the information in an ENUM record set must be considered open to the public, which is a cause for some privacy considerations 🫣.
Ordinarily, when you give someone your telephone number, you don't expect them to be able to trivially figure out your full name and place of employment 💀. If, however, you create a NAPTR record for use with ENUM that maps your telephone number to a SIP URI like julia.roberts@example.com, expect to get a lot of calls from excited fans 🌟.
Unlike a traditional telephone number, the target of a SIP URI may require that callers provide cryptographic credentials for authentication and authorization before a user is alerted 🔒. In this respect, ENUM in concert with SIP can actually provide far greater protection from unwanted callers than the existing PSTN, despite the public availability of ENUM records 🛡️.
Users of ENUM who are still uncomfortable with revealing their names may, since identities on the Internet aren't exactly scarce, publish a less revealing SIP URI. Something like sip:anonymous00045@example.com or even sip:anonymous00045@anonymous-redirector.example.org could work, and that could in turn point to their internal URI 🕵️.
An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC [18] to these, is provided in [1] 🔍.
9. References 📚
9.1. Normative References
[1] Faltstrom, P. and M. Mealling, "E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD13, RFC 1034, November 1987.
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403,
October 2002.
[7] Peterson, J., "enumservice registration for SIP Addresses-of-
Record", RFC 3764, April 2004.
[8] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August
1998.9.2. Informative References
[10] International Telecommunications Union, "Recommendation E.164:
The international public telecommunication numbering plan", May
1997, <http://www.itu.int>.
[11] Rosenberg, J., Schulzrinne, H. and P. Kyzviat, "Indicating User
Agent Capabilities in the Session Initiation Protocol (SIP)",
Work in Progress, June 2003.
[12] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[13] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[14] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol:
Locating SIP Servers", RFC 3263, June 2002.
[15] Rosenberg, J., Squire, M., and H. Salama, "Telephony Routing
over IP (TRIP)", RFC 3219, August 2001.
[16] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
[17] Peterson, J., "Enumservice Registration for Presence Services",
Work in Progress, February 2003.
[18] Arends, R., et al., "Protocol Modifications for the DNS
Security Extensions", Work in Progress, May 2004.Appendix A. Acknowledgments 🙏
The authors would like to thank Richard Shockey for his input on privacy issues, and Tom McGarry and Rohan Mahy for overall comments and analysis 💖. Thanks are due as well to Juan Heinanen and Lawrence E. Conroy for advice on updating this document to better reflect RFC 3761 🫶. Special thanks go to Patrik Faltstrom and Michael Mealling for significantly reducing the size of this document by producing a tight and well-specified successor to RFC 2916 👑. Richard Stastny and Patrik Faltstrom also provided valuable notes on the valid usage of non-greedy regexp antecedents 🌸.
Authors' Addresses 🦋
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Hong Liu
NeuStar, Inc.
46000 Center Oak Plaza
Sterling, VA 20166
USA
EMail: hong.liu@neustar.biz
URI: http://www.neustar.biz/
James Yu
NeuStar, Inc.
46000 Center Oak Plaza
Sterling, VA 20166
USA
Phone: +1 571/434-5572
EMail: james.yu@neustar.biz
URI: http://www.neustar.biz/
Ben Campbell
dynamicsoft
5100 Tennyson Parkway
Suite 1200
Plano, TX 75024
USA
EMail: bcampbell@dynamicsoft.com
URI: http://www.dynamicsoft.com/Full Copyright Statement 🎀
Okay bestie, let's talk copyright 📜 The Internet Society (2004) holds the copyright on this one ✨ This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 💅
Also, this doc comes "AS IS" 😭 THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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 🙈
Intellectual Property 🦋
The IETF doesn't take a side on whether any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this document are valid or how far they reach 🌸 It also doesn't know whether any license under those rights might be available, and it hasn't done its own digging to find any such rights either 🤷♀️ If you want the details on how rights work for RFC documents, check out BCP 78 and BCP 79 📚
Copies of IPR disclosures made to the IETF Secretariat are kept around, along with any assurances of licenses that are going to be made available. You can also find the results of any attempt to get a general license or permission to use these proprietary rights for implementers or users of this specification 💜 All of that lives in the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF also invites anyone who's interested to flag any copyrights, patents or patent applications, or other proprietary rights that might cover technology needed to implement this standard 🧚 Send that info to the IETF at ietf-ipr@ietf.org ✨
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society 🌈 Thank you to whoever keeps the lights on! 💖
📦 where this page comes from
- ietf: rfc3824 2004-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms