RFC 4002

IANA Registration for Enumservice 'web' and 'ft'

📅 published February 2005, from ietf

RFC 4002: IANA Registration for Enumservice 'web' and 'ft' 🦋

okay bestie, this is RFC 4002 🎀 It's a Standards Track doc, dated February 2005, written by Rudolf Brandner (Siemens AG), Lawrence Conroy (Siemens Roke Manor Research) and Richard Stastny (Oefeg). It came out of the Network Working Group. The title block has no "Obsoletes" or "Updates" line, so it doesn't replace or update anything else 💅

Status of This Memo

ok so this section says the doc specifies an Internet standards track protocol for the Internet community and asks 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 ✨

Copyright (C) The Internet Society (2005) 🫶

Abstract

this doc registers the Enumservices 'web' and 'ft' 🦋 It does that by using the URI schemes http:, https: and ftp:, following the IANA registration process from the ENUM specification (RFC 3761).

Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
3.  Web Service  . . . . . . . . . . . . . . . . . . . . . . . . .  3
    3.1.  Introduction . . . . . . . . . . . . . . . . . . . . . .  3
    3.2.  Web Service Registration with 'http:'  . . . . . . . . .  3
    3.3.  Web Service Registration with 'https:' . . . . . . . . .  4
4.  FT Service Registration  . . . . . . . . . . . . . . . . . . .  5
5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
6.  IANA Considerations . . .. . . . . . . . . . . . . . . . . . .  7
7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  7
    7.1.  Normative References . . . . . . . . . . . . . . . . . .  7
    7.2.  Informative References . . . . . . . . . . . . . . . . .  8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 10

1. Introduction ✨

so ENUM (E.164 Number Mapping, RFC 3761 [2]) is the system that turns E.164 numbers [3] into domain names 📞 It then uses DNS (Domain Name Service, RFC 1034 [4]) stuff, like delegation through NS records and NAPTR records, to find out what services are available for a specific domain name 🧚

this doc registers 'Enumservices' following the guidelines in RFC 3761 [2]. They get used in the services field of a NAPTR [7] resource record to show what class of functionality an end point offers 💜 The registration sits inside the DDDS (Dynamic Delegation Discovery System [5][6][7][8][9]) hierarchy, for use with the "E2U" DDDS Application, which is defined in RFC 3761 [2] 🌈

the Enumservices registered here are 'web' and 'ft' 💖 They have a shared vibe: each one says the end points and their resources are mainly sources of information 📚

according to RFC 3761 [2], the registered Enumservice must be able to work as a selection mechanism when someone picks between one NAPTR resource record and another. So the registration MUST specify what is expected when that NAPTR record is used, and the URI scheme that comes out of using it 🔥

so an Enumservice is basically a hint 💅 It tells you what kind of service the URI built from the regexp field is for. You can put more than one Enumservice in a single NAPTR, which means more than one service can be reached using the matching URI scheme 🦋

the big theme across all of these is the kind of service the end user is hoping to get from the communication through the matching URI 🎀

the services specified here are NOT intended to specify the protocol or even the method of connection that MUST be used to get each service 🙈 Instead, they describe the kind of interactive behavior an end user will expect. The end system gets to decide how to actually run the service, based on policies that are outside the scope of this spec ✨

same URI scheme can serve different services (e.g., 'tel:') and the same kind of service can use different URI schemes (e.g., for VoIP, 'sip:', 'h323:', and 'tel:' may be used). So sometimes you have to name both the service and the URI scheme in use 💅

RFC 3761 [2] has service parameters that let you specify a 'type' and a 'subtype'. In this set of specs, the 'type' (the more generic term) defines the service, and the 'subtype' defines the URI scheme 🌸

2. Terminology 💜

okay here's the key word squad 💅 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1] 🫶

3. Web Service 🌈

3.1. Introduction 🦋

the Enumservices in this section say the resource behind the associated URI can be a source of information ✨

3.2. Web Service Registration with 'http:' 🎀

here's the template, exactly as registered:

Enumservice Name: "web"
Enumservice Type: "web"
Enumservice Subtype: "http"
URI Scheme: 'http:'

Functional Specification: this Enumservice says the resource behind the associated URI scheme can be a source of information 🌸

the kind of info you get back can be all over the place 🙈 Usually, hitting a resource with an http: [11] URI gives you a document. That document can have references that trigger downloads of lots of different kinds of info, like audio, video, or executable code 💀 So you can't get any more specific about what kind of info to expect from the resource 🔥

Security Considerations: there are no specific security issues with this Enumservice 🛡️ However, the general considerations of Section 5 apply 🫶

Intended Usage: Intended Usage: COMMON 💅

Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see the Authors' Addresses section) 🌸

Any other information the author deems interesting: None ✨

3.3. Web Service Registration with 'https:' 💖

here's the template for this one:

Enumservice Name: "web"
Enumservice Type: "web"
Enumservice Subtype: "https"
URI Scheme: 'https:'

Functional Specification: this Enumservice says the resource behind the associated URI scheme can be a source of information, and you can reach it using TLS or the Secure Socket Layer protocol 🔐

same deal with the info: the kind of info you get can be manifold 🌈 Usually, hitting a resource with an https: URI [12] gives you a document. That document can include lots of different kinds of info, like audio, video, or executable code 🧚 So you can't be more specific about what info to expect when you contact the resource 💅

Security Considerations: there are no specific security issues with this Enumservice 🛡️ However, the general considerations of Section 5 apply 🫶

Intended Usage: Intended Usage: COMMON 🎀

Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see the Authors' Addresses section) 🌸

Any other information the author deems interesting: None ✨

4. FT Service Registration 🍓

the template, exactly as registered:

Enumservice Name: "ft"
Enumservice Type: "ft"
Enumservice Subtype: "ftp"
URI Scheme: 'ftp:'

Functional Specification: this Enumservice says the resource behind the associated URI scheme is a service you can use the way RFC 1738 [10] describes for ftp:, like file retrieval 📁

Security Considerations: there are no specific security issues with this Enumservice 🛡️ However, the general considerations of Section 5 apply 🫶

Intended Usage: Intended Usage: COMMON 💅

Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see the Authors' Addresses section) 🌸

Any other information the author deems interesting: None ✨

5. Security Considerations 🚨

okay bestie, this section is seriously important 🙈 As ENUM uses it, DNS is a global, distributed database. So anything stored there is visible to anyone, anonymously 👀 Yes, that's not really different from putting your number in a phone book, but it does mean your data can get collected automatically, with no sign that it's happening or who's doing it 😭

third parties harvest data a lot to build target lists for unrequested messages. Basically, it's how spam happens 📧💀 Anyone who uses a web-archived mailing list knows the spam they get goes up after they post to the list. Publishing a phone number in ENUM is no different, and it could be used to send "junk faxes" or "junk SMS", for example 📠

lots of mailing list people have more than one email address and use "sacrificial" accounts when they post, to help filter out unwanted emails 🧢 That doesn't really work with phone numbers. The PSTN E.164 number assignment process is way more involved, and usually one E.164 number (or a fixed range of numbers) goes with each PSTN access. So you can't really have a "sacrificial" phone number for a publication 😭

because publishing data to a globally accessible database has real implications, the data subject MUST give explicit informed consent when data gets published in ENUM 🫶 As a principle, that's non-negotiable 🔒

the data subject should also know that, because harvesters store the data, removing it from publication won't delete the copies that were already taken 💔 Basically, any publication may be permanent 🌧️

that said, regulations in many regions say the data subject can ask at any time for the data to be removed from publication, and that consent for its publication has to be explicitly confirmed at regular intervals ✨

the user SHOULD be asked to confirm before opening a web page or starting an ftp session (especially if the ftp client is set up to send the user's email address as an "anonymous" user password) 🙈

using a web:http or ft:ftp service is not secure 🚩 So the user should be just as careful about entering personal data as they would be in any other client application 💅 Even though this isn't a feature of ENUM or these Enumservices, the ENUM-using application on the end system can look different from the user's "normal" browser. So the user SHOULD receive an indication of whether their communication is secured 🔐

okay, this part is the big one 🔥 Evaluating a web page can mean running embedded (or linked) content, which might include executable code. So evaluating a web URL comes with risks 💀 If automatic evaluation of a web link were used, the querying user would be exposed to the risks of automatically downloading and running that content. So the client MUST ask the querying user for confirmation before evaluating the web URL, and the client MUST NOT download and evaluate the web content automatically 🚫

the threats specific to ENUM depending on DNS (threats covered in [14]), and how DNSSEC [13] applies to them, are covered in RFC 3761 [2] 🧚

6. IANA Considerations 🌸

okay so IANA already did the paperwork 📋✨ They registered Enumservice 'web' and 'ft' using the registration process from the ENUM spec [2]. Iconic behavior, honestly.

7. References 📚

7.1. Normative References

  • [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
  • [3] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164 , May 1997.
  • [4] Mockapetris, P., "Domain names - concepts and facilities", STD 13, 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 Two: The Algorithm", RFC 3402, October 2002.
  • [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
  • [8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
  • [9] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, October 2002.
  • [10] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
  • [11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

7.2. Informative References

  • [13] Arends, R. and et al., "Protocol Modifications for the DNS Security Extensions", Work in Progress.
  • [14] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.

Authors' Addresses 🎀

Rudolf Brandner
Siemens AG
Hofmannstr. 51
81359 Munich
Germany

Phone: +49-89-722-51003
EMail: rudolf.brandner@siemens.com


Lawrence Conroy
Siemens Roke Manor Research
Roke Manor
Romsey
United Kingdom

Phone: +44-1794-833666
EMail: lwc@roke.co.uk


Richard Stastny
Oefeg
Postbox 147
1103 Vienna
Austria

Phone: +43-664-420-4100
EMail: richard.stastny@oefeg.at

Copyright (C) The Internet Society (2005).

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.

This document and the information contained herein are provided on an "AS IS" basis and 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 takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🧚

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from