IANA Registration for Enumservice 'web' and 'ft'
RFC 4002
Document | Type |
RFC - Proposed Standard
(February 2005; No errata)
Updated by RFC 6118
Was draft-ietf-enum-webft (enum WG)
|
|
---|---|---|---|
Authors | Lawrence Conroy , Rudolf Brandner , Richard Stastny | ||
Last updated | 2015-10-14 | ||
Replaces | draft-brandner-enumservice-webft | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4002 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | (None) |
Network Working Group R. Brandner Request for Comments: 4002 Siemens AG Category: Standards Track L. Conroy Siemens Roke Manor Research R. Stastny Oefeg February 2005 IANA Registration for Enumservice 'web' and 'ft' Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document registers the Enumservices 'web' and 'ft' by using the URI schemes 'http:', 'https:' and 'ftp:' as per the IANA registration process defined in 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 Brandner, et al. Standards Track [Page 1] RFC 4002 IANA Registration for Enumservice web and ft February 2005 1. Introduction ENUM (E.164 Number Mapping, RFC 3761 [2]) is a system that transforms E.164 numbers [3] into domain names and that then uses DNS (Domain Name Service, RFC 1034 [4]) services such as delegation through NS records and NAPTR records to look up what services are available for a specific domain name. This document registers 'Enumservices' according to the guidelines given in RFC 3761 [2] to be used for provisioning in the services field of an NAPTR [7] resource record to indicate what class of functionality a given end point offers. The registration is defined within the DDDS (Dynamic Delegation Discovery System [5][6][7][8][9]) hierarchy, for use with the "E2U" DDDS Application, defined in RFC 3761 [2]. The following 'Enumservices' are registered with this document: 'web' and 'ft'. These share a common feature in that they each indicate that the functionality of the given end points and the associated resources are primarily sources of information. According to RFC 3761 [2], the 'Enumservice' registered must be able to function as a selection mechanism when one chooses between one NAPTR resource record and another. This means that the registration MUST specify what is expected when that NAPTR record is used, and the URI scheme that is the outcome of use. Therefore an 'Enumservice' acts as a hint, indicating the kind of service with which the URI constructed by using the regexp field is associated. More than one 'Enumservice' can be included within a single NAPTR; this indicates that there is more than one service that can be achieved by using the associated URI scheme. The common thread with this set of definitions is that they reflect the kind of service that the end user will hope to achieve with the communication by using the associated URI. The services specified here are NOT intended to specify the protocol or even the method of connection that MUST be used to achieve each service. Instead, we define the kind of interactive behavior that an end user will expect, leaving the end system to decide (based on policies outside the scope of this specification) how to execute the service. Brandner, et al. Standards Track [Page 2] RFC 4002 IANA Registration for Enumservice web and ft February 2005 As the same URI scheme may be used for different services (e.g., 'tel:') and the same kind of service may use different URI schemes (e.g., for VoIP, 'sip:', 'h323:', and 'tel:' may be used), it isShow full document text