rfc-4002

IANA Registration for Enumservice 'web' and 'ft'

R. Brandner, L. Conroy, R. Stastny
date2005-02 streamIETF arearai wgenum statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc4002 doi10.17487/RFC4002
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). [STANDARDS-TRACK]

updated by

Extracted elements (14)

design-rationale §1

Enumservices are defined as hints indicating the kind of service associated with a URI, not the protocol or method of connection, leaving end systems to decide how to execute the service based on local policy.

dns

design-rationale §1

The 'type' parameter defines the service generically and the 'subtype' defines the URI scheme, because the same URI scheme may be used for different services and the same service may use different URI schemes.

dns

interoperability-note §1

More than one Enumservice can be included within a single NAPTR record, indicating that more than one service can be achieved by using the associated URI scheme.

dns

normative-requirement §5 MUST NOT

The client MUST ask the querying user for confirmation before evaluating a web URL; the client MUST NOT download and evaluate web content automatically, due to risks from embedded executable content.

http, security

normative-requirement §5 MUST

The data subject MUST give explicit informed consent when their data is published in ENUM, given the implications of publishing on a globally accessible database.

dns, privacy, security

normative-requirement §5 SHOULD

The user SHOULD be asked to confirm opening a web page or starting an ftp session, particularly if the ftp client is configured to send the user's email address as an anonymous password.

http, security

normative-requirement §5 SHOULD

The user SHOULD receive an indication of whether their communication is secured, as the ENUM-using application may appear different from the user's normal browser.

http, security, tls

privacy-consideration §5

Publication of E.164 numbers in ENUM may be effectively permanent because third-party harvesting can copy data before removal; users should be informed that removal from ENUM does not remove harvested copies.

privacy, dns

protocol-element §3.2

An Enumservice registration must specify a Name, Type, Subtype, URI Scheme, Functional Specification, Security Considerations, Intended Usage, and Authors, as required by RFC 3761's registration process.

dns, registry

registry §4

IANA registration of Enumservice 'ft' with subtype 'ftp' using URI scheme 'ftp:', indicating the resource is usable for file retrieval as specified in RFC 1738.

registry, dns

registry §3.2

IANA registration of Enumservice 'web' with subtype 'http' using URI scheme 'http:', indicating the resource is capable of being a source of information.

registry, dns, http

registry §3.3

IANA registration of Enumservice 'web' with subtype 'https' using URI scheme 'https:', indicating the resource is a source of information contactable via TLS or SSL.

registry, dns, http, tls

security-consideration §5

DNS-based ENUM data is globally visible and can be harvested automatically by third parties without the data subject's knowledge, enabling spam via junk faxes or junk SMS linked to published E.164 numbers.

dns, security, privacy

security-consideration §5

Evaluating a web URL involves risks from embedded or linked executable content; automatic evaluation without user confirmation exposes the querying user to automatic download and execution of potentially malicious content.

http, security