Difference between revisions of "RFC6118"
Line 13: | Line 13: | ||
This document revises all Enumservices that were IANA registered | This document revises all Enumservices that were IANA registered | ||
under the now obsolete specification of the Enumservice registry | under the now obsolete specification of the Enumservice registry | ||
− | defined in RFC 3761. | + | defined in [[RFC3761|RFC 3761]]. |
'''Status of This Memo''' | '''Status of This Memo''' | ||
Line 23: | Line 23: | ||
received public review and has been approved for publication by the | received public review and has been approved for publication by the | ||
Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | ||
− | Internet Standards is available in Section 2 of RFC 5741. | + | Internet Standards is available in Section 2 of [[RFC5741|RFC 5741]]. |
Information about the current status of this document, any errata, | Information about the current status of this document, any errata, | ||
Line 34: | Line 34: | ||
document authors. All rights reserved. | document authors. All rights reserved. | ||
− | This document is subject to BCP 78 and the IETF Trust's Legal | + | This document is subject to [[BCP78|BCP 78]] and the IETF Trust's Legal |
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | ||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | ||
Line 60: | Line 60: | ||
== Introduction == | == Introduction == | ||
− | + | [[RFC6117]] has obsoleted the IANA registration section of [[RFC3761]]. | |
Since the IANA Enumservice registry contains various Enumservices | Since the IANA Enumservice registry contains various Enumservices | ||
− | registered under the regime of RFC 3761, those registrations do not | + | registered under the regime of [[RFC3761|RFC 3761]], those registrations do not |
− | conform to the new guidelines as specified in | + | conform to the new guidelines as specified in [[RFC6117]]. To ensure |
consistency among all Enumservice registrations at IANA, this | consistency among all Enumservice registrations at IANA, this | ||
document adds the (nowadays) missing elements to those legacy | document adds the (nowadays) missing elements to those legacy | ||
Line 71: | Line 71: | ||
However, this document only adds the missing elements to the XML | However, this document only adds the missing elements to the XML | ||
− | chunks as specified in the IANA Considerations section of | + | chunks as specified in the IANA Considerations section of [[RFC6117]], |
but it does not complete the (nowadays) missing sections of the | but it does not complete the (nowadays) missing sections of the | ||
corresponding Enumservice Specifications. In order to conform with | corresponding Enumservice Specifications. In order to conform with | ||
− | the new registration regime as specified in | + | the new registration regime as specified in [[RFC6117]], those |
Enumservice Specifications still have to be revised. | Enumservice Specifications still have to be revised. | ||
Line 82: | Line 82: | ||
The following RFCs are updated by this document: | The following RFCs are updated by this document: | ||
− | o | + | o [[RFC3762]] |
− | o | + | o [[RFC3764]] |
− | o | + | o [[RFC3953]] |
− | o | + | o [[RFC4143]] |
− | o | + | o [[RFC4002]] |
− | o | + | o [[RFC4238]] |
− | o | + | o [[RFC4355]] |
− | o | + | o [[RFC4415]] |
− | o | + | o [[RFC4769]] |
− | o | + | o [[RFC4969]] |
− | o | + | o [[RFC4979]] |
− | o | + | o [[RFC5028]] |
− | o | + | o [[RFC5278]] |
− | o | + | o [[RFC5333]] |
== Terminology == | == Terminology == | ||
Line 101: | Line 101: | ||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | ||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | ||
− | document are to be interpreted as described in RFC 2119 | + | document are to be interpreted as described in [[RFC2119|RFC 2119]] [[RFC2119]]. |
== IESG Action == | == IESG Action == | ||
− | According to | + | According to [[RFC3761]], any Enumservice registration had to be |
published as a Standards Track, Experimental, or BCP (Best Current | published as a Standards Track, Experimental, or BCP (Best Current | ||
− | Practice) RFC. | + | Practice) RFC. [[RFC6117]] no longer has this requirement, i.e., |
"Specification Required", which implies the use of a Designated | "Specification Required", which implies the use of a Designated | ||
− | Expert | + | Expert [[RFC5226]], is sufficient. |
This document changes the approval requirement for updates to | This document changes the approval requirement for updates to | ||
Enumservice registrations to Specification Required, whereby the | Enumservice registrations to Specification Required, whereby the | ||
specification and request are reviewed by a Designated Expert as | specification and request are reviewed by a Designated Expert as | ||
− | described in | + | described in [[RFC6117]]. |
== Legacy Enumservice Registrations Converted to XML Chunks == | == Legacy Enumservice Registrations Converted to XML Chunks == | ||
In the following, the legacy Enumservice Registrations are converted | In the following, the legacy Enumservice Registrations are converted | ||
− | to XML chunks that include the new elements introduced by | + | to XML chunks that include the new elements introduced by [[RFC6117]]. |
(Note that references in Sections 4.1 - 4.39 refer to the references | (Note that references in Sections 4.1 - 4.39 refer to the references | ||
Line 144: | Line 144: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4355"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 190: | Line 190: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4355"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 228: | Line 228: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4355"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 280: | Line 280: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4355"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 311: | Line 311: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4002"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4002"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 337: | Line 337: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc3762"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc3762"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 369: | Line 369: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5333"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5333"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 401: | Line 401: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5333"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5333"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 433: | Line 433: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5333"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5333"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 457: | Line 457: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4143"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4143"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 487: | Line 487: | ||
does not identify any particular protocol that will | does not identify any particular protocol that will | ||
be used to handle instant messaging receipt or | be used to handle instant messaging receipt or | ||
− | delivery, rather the mechanism in RFC 3861 [4] is | + | delivery, rather the mechanism in [[RFC3861|RFC 3861]] [4] is |
used to discover whether an IM protocol supported by | used to discover whether an IM protocol supported by | ||
the party querying ENUM is also supported by the | the party querying ENUM is also supported by the | ||
Line 501: | Line 501: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5028"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5028"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 553: | Line 553: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4355"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 611: | Line 611: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4355"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 654: | Line 654: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc3953"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc3953"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 689: | Line 689: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4769"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4769"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 732: | Line 732: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4769"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4769"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 765: | Line 765: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc3764"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc3764"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 813: | Line 813: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4355"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 851: | Line 851: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4355"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 894: | Line 894: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 943: | Line 943: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 979: | Line 979: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,015: | Line 1,015: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,061: | Line 1,061: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4969"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4969"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,102: | Line 1,102: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,151: | Line 1,151: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,187: | Line 1,187: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,223: | Line 1,223: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,267: | Line 1,267: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4415"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4415"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,308: | Line 1,308: | ||
<paragraph> | <paragraph> | ||
The "tel:" URI value SHOULD be fully qualified | The "tel:" URI value SHOULD be fully qualified | ||
− | (using the "global phone number" form of RFC 3966 | + | (using the "global phone number" form of [[RFC3966|RFC 3966]] |
[10]). A "local phone number" as defined in that | [10]). A "local phone number" as defined in that | ||
document SHOULD NOT be used unless the controller of | document SHOULD NOT be used unless the controller of | ||
Line 1,356: | Line 1,356: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,405: | Line 1,405: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,441: | Line 1,441: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,477: | Line 1,477: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,513: | Line 1,513: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc5278"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,560: | Line 1,560: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4238"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4238"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,605: | Line 1,605: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4238"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4238"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,659: | Line 1,659: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4002"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4002"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,698: | Line 1,698: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4002"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4002"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,727: | Line 1,727: | ||
<usage>COMMON</usage> | <usage>COMMON</usage> | ||
<registrationdocs> | <registrationdocs> | ||
− | <xref type="rfc" data="rfc4979"/> (updated by RFC 6118) | + | <xref type="rfc" data="rfc4979"/> (updated by [[RFC6118|RFC 6118]]) |
− | <xref type="rfc" data="RFC 6118"/> | + | <xref type="rfc" data="[[RFC6118|RFC 6118]]"/> |
</registrationdocs> | </registrationdocs> | ||
<requesters> | <requesters> | ||
Line 1,756: | Line 1,756: | ||
=== Normative References === | === Normative References === | ||
− | + | [[RFC2026]] Bradner, S., "The Internet Standards Process -- Revision | |
− | 3", BCP 9, RFC 2026, October 1996. | + | 3", [[BCP9|BCP 9]], [[RFC2026|RFC 2026]], October 1996. |
− | + | [[RFC2119]] Bradner, S., "Key words for use in RFCs to Indicate | |
− | Requirement Levels", BCP 14, RFC 2119, March 1997. | + | Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997. |
− | + | [[RFC3761]] Faltstrom, P. and M. Mealling, "The E.164 to Uniform | |
Resource Identifiers (URI) Dynamic Delegation Discovery | Resource Identifiers (URI) Dynamic Delegation Discovery | ||
− | System (DDDS) Application (ENUM)", RFC 3761, April 2004. | + | System (DDDS) Application (ENUM)", [[RFC3761|RFC 3761]], April 2004. |
− | + | [[RFC3762]] Levin, O., "Telephone Number Mapping (ENUM) Service | |
− | Registration for H.323", RFC 3762, April 2004. | + | Registration for H.323", [[RFC3762|RFC 3762]], April 2004. |
− | + | [[RFC3764]] Peterson, J., "enumservice registration for Session | |
− | Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, | + | Initiation Protocol (SIP) Addresses-of-Record", [[RFC3764|RFC 3764]], |
April 2004. | April 2004. | ||
− | + | [[RFC3953]] Peterson, J., "Telephone Number Mapping (ENUM) Service | |
− | Registration for Presence Services", RFC 3953, | + | Registration for Presence Services", [[RFC3953|RFC 3953]], |
January 2005. | January 2005. | ||
− | + | [[RFC4002]] Brandner, R., Conroy, L., and R. Stastny, "IANA | |
− | Registration for Enumservice 'web' and 'ft'", RFC 4002, | + | Registration for Enumservice 'web' and 'ft'", [[RFC4002|RFC 4002]], |
February 2005. | February 2005. | ||
− | + | [[RFC4143]] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail | |
− | (IFAX) Service of ENUM", RFC 4143, November 2005. | + | (IFAX) Service of ENUM", [[RFC4143|RFC 4143]], November 2005. |
− | + | [[RFC4238]] Vaudreuil, G., "Voice Message Routing Service", [[RFC4238|RFC 4238]], | |
October 2005. | October 2005. | ||
− | + | [[RFC4355]] Brandner, R., Conroy, L., and R. Stastny, "IANA | |
Registration for Enumservices email, fax, mms, ems, and | Registration for Enumservices email, fax, mms, ems, and | ||
− | sms", RFC 4355, January 2006. | + | sms", [[RFC4355|RFC 4355]], January 2006. |
− | + | [[RFC4415]] Brandner, R., Conroy, L., and R. Stastny, "IANA | |
− | Registration for Enumservice Voice", RFC 4415, | + | Registration for Enumservice Voice", [[RFC4415|RFC 4415]], |
February 2006. | February 2006. | ||
− | + | [[RFC4769]] Livingood, J. and R. Shockey, "IANA Registration for an | |
Enumservice Containing Public Switched Telephone Network | Enumservice Containing Public Switched Telephone Network | ||
− | (PSTN) Signaling Information", RFC 4769, November 2006. | + | (PSTN) Signaling Information", [[RFC4769|RFC 4769]], November 2006. |
− | + | [[RFC4969]] Mayrhofer, A., "IANA Registration for vCard Enumservice", | |
− | RFC 4969, August 2007. | + | [[RFC4969|RFC 4969]], August 2007. |
− | + | [[RFC4979]] Mayrhofer, A., "IANA Registration for Enumservice 'XMPP'", | |
− | RFC 4979, August 2007. | + | [[RFC4979|RFC 4979]], August 2007. |
− | + | [[RFC5028]] Mahy, R., "A Telephone Number Mapping (ENUM) Service | |
Registration for Instant Messaging (IM) Services", | Registration for Instant Messaging (IM) Services", | ||
− | RFC 5028, October 2007. | + | [[RFC5028|RFC 5028]], October 2007. |
− | + | [[RFC5278]] Livingood, J. and D. Troshynski, "IANA Registration of | |
− | Enumservices for Voice and Video Messaging", RFC 5278, | + | Enumservices for Voice and Video Messaging", [[RFC5278|RFC 5278]], |
July 2008. | July 2008. | ||
− | + | [[RFC5333]] Mahy, R. and B. Hoeneisen, "IANA Registration of | |
− | Enumservices for Internet Calendaring", RFC 5333, | + | Enumservices for Internet Calendaring", [[RFC5333|RFC 5333]], |
October 2009. | October 2009. | ||
− | + | [[RFC6117]] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA | |
Registration of Enumservices: Guide, Template, and IANA | Registration of Enumservices: Guide, Template, and IANA | ||
− | Considerations", RFC 6117, March 2011. | + | Considerations", [[RFC6117|RFC 6117]], March 2011. |
=== Informative References === | === Informative References === | ||
− | + | [[RFC5226]] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |
− | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | + | IANA Considerations Section in RFCs", [[BCP26|BCP 26]], [[RFC5226|RFC 5226]], |
May 2008. | May 2008. | ||
Line 1,837: | Line 1,837: | ||
Registry Name: Enumservice Registrations | Registry Name: Enumservice Registrations | ||
− | Reference: | + | Reference: [[RFC3761]] |
Registration Procedures: Require an RFC approved by the IESG | Registration Procedures: Require an RFC approved by the IESG | ||
Line 1,849: | Line 1,849: | ||
URI Scheme(s): "h323:" | URI Scheme(s): "h323:" | ||
Functional Specification: | Functional Specification: | ||
− | See Section "3. The E2U+H323 ENUM Service" of | + | See Section "3. The E2U+H323 ENUM Service" of [[RFC3762]] |
Security considerations: | Security considerations: | ||
− | see section "5. Security Considerations" of | + | see section "5. Security Considerations" of [[RFC3762]] |
Intended usage: COMMON | Intended usage: COMMON | ||
Author: Orit Levin | Author: Orit Levin | ||
− | + | [[RFC3762]] | |
Service Name: "SIP" | Service Name: "SIP" | ||
Line 1,860: | Line 1,860: | ||
Subtype(s): N/A | Subtype(s): N/A | ||
URI Scheme(s): "sip", "sips:" | URI Scheme(s): "sip", "sips:" | ||
− | Functional Specification: see Section 4 of | + | Functional Specification: see Section 4 of [[RFC3764]] |
− | Security considerations: see Section 6 of | + | Security considerations: see Section 6 of [[RFC3764]] |
Intended usage: COMMON | Intended usage: COMMON | ||
Author: Jon Peterson (jon.peterson&neustar.biz) | Author: Jon Peterson (jon.peterson&neustar.biz) | ||
Any other information that the author deems interesting: | Any other information that the author deems interesting: | ||
− | see Section 3 of | + | see Section 3 of [[RFC3764]] |
− | + | [[RFC3764]] | |
Service Name: "ifax" | Service Name: "ifax" | ||
Line 1,875: | Line 1,875: | ||
standard Internet mail and uses standard Internet mail | standard Internet mail and uses standard Internet mail | ||
addressing. | addressing. | ||
− | Functional Specification: see section 1 of | + | Functional Specification: see section 1 of [[RFC4143]] |
− | Security Considerations: see section 3 of | + | Security Considerations: see section 3 of [[RFC4143]] |
Intended usage: COMMON | Intended usage: COMMON | ||
Author: Kiyoshi Toyoda(toyoda.kiyoshi&jp.panasonic.com) | Author: Kiyoshi Toyoda(toyoda.kiyoshi&jp.panasonic.com) | ||
Dave Crocker(dcrocker&brandenburg.com) | Dave Crocker(dcrocker&brandenburg.com) | ||
− | + | [[RFC4143]] | |
Service Name: "pres" | Service Name: "pres" | ||
URI Scheme(s): "pres:" | URI Scheme(s): "pres:" | ||
− | Functional Specification: see Section 4 of | + | Functional Specification: see Section 4 of [[RFC3953]] |
− | Security considerations: see Section 6 of | + | Security considerations: see Section 6 of [[RFC3953]] |
Intended usage: COMMON | Intended usage: COMMON | ||
Author: Jon Peterson (jon.peterson&neustar.biz) | Author: Jon Peterson (jon.peterson&neustar.biz) | ||
Any other information that the author deems interesting: | Any other information that the author deems interesting: | ||
− | See Section 3 of | + | See Section 3 of [[RFC3953]] |
− | + | [[RFC3953]] | |
Service Name: "web" | Service Name: "web" | ||
Line 1,907: | Line 1,907: | ||
can be expected when contacting the resource. | can be expected when contacting the resource. | ||
Security Considerations: | Security Considerations: | ||
− | See section 5 of | + | See section 5 of [[RFC4002]]. |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 1,914: | Line 1,914: | ||
Richard Stastny (richard.stastny&oefeg.at) | Richard Stastny (richard.stastny&oefeg.at) | ||
Any other information the author deems interesting: None | Any other information the author deems interesting: None | ||
− | + | [[RFC4002]] | |
Service Name: "web" | Service Name: "web" | ||
Line 1,931: | Line 1,931: | ||
what information to expect when contacting the resource. | what information to expect when contacting the resource. | ||
Security Considerations: | Security Considerations: | ||
− | See section 5 of | + | See section 5 of [[RFC4002]]. |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 1,938: | Line 1,938: | ||
Richard Stastny (richard.stastny&oefeg.at) | Richard Stastny (richard.stastny&oefeg.at) | ||
Any other information the author deems interesting: None | Any other information the author deems interesting: None | ||
− | + | [[RFC4002]] | |
Service Name: "ft" | Service Name: "ft" | ||
Line 1,949: | Line 1,949: | ||
file listing can be retrieved. | file listing can be retrieved. | ||
Security Considerations: | Security Considerations: | ||
− | See section 5 of | + | See section 5 of [[RFC4002]]. |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 1,956: | Line 1,956: | ||
Richard Stastny (richard.stastny&oefeg.at) | Richard Stastny (richard.stastny&oefeg.at) | ||
Any other information the author deems interesting: None | Any other information the author deems interesting: None | ||
− | + | [[RFC4002]] | |
Enumservice Name: "email" | Enumservice Name: "email" | ||
Line 1,967: | Line 1,967: | ||
email. | email. | ||
Security Considerations: | Security Considerations: | ||
− | See Section 6 of | + | See Section 6 of [[RFC4355]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | ||
− | contact detail see | + | contact detail see [[RFC4355]]) |
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
None | None | ||
Line 1,987: | Line 1,987: | ||
and sending facsimile documents to the recipient using the PSTN | and sending facsimile documents to the recipient using the PSTN | ||
session and transfer protocols specified in [12] and [13] in | session and transfer protocols specified in [12] and [13] in | ||
− | + | [[RFC4355]] - in short, they will have a fax | |
program with a local or shared PSTN access over which they can | program with a local or shared PSTN access over which they can | ||
send faxes. | send faxes. | ||
Security Considerations: | Security Considerations: | ||
− | See Section 6 of | + | See Section 6 of [[RFC4355]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | ||
− | contact detail see | + | contact detail see [[RFC4355]]) |
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
None | None | ||
Line 2,006: | Line 2,006: | ||
This Enumservice indicates that the resource identified by the | This Enumservice indicates that the resource identified by the | ||
associated URI scheme is capable of receiving a message using | associated URI scheme is capable of receiving a message using | ||
− | the Short Message Service (SMS) [14] in | + | the Short Message Service (SMS) [14] in [[RFC4355]]. |
Security Considerations: | Security Considerations: | ||
There are no specific security issues with this Enumservice. | There are no specific security issues with this Enumservice. | ||
Line 2,013: | Line 2,013: | ||
Authors: | Authors: | ||
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | ||
− | contact detail see | + | contact detail see [[RFC4355]]) |
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
None | None | ||
Line 2,027: | Line 2,027: | ||
SMS content is sent over SMTP using the format specified by TS | SMS content is sent over SMTP using the format specified by TS | ||
23.140 [15] section 8.4.4 and TS 26.140 [16] section 4 (for | 23.140 [15] section 8.4.4 and TS 26.140 [16] section 4 (for | ||
− | references see | + | references see [[RFC4355]]), as an MMS message. Within such a |
message, SMS content is carried as either a text or | message, SMS content is carried as either a text or | ||
application/octet-stream MIME sub-part (see TS 26.140 [16] , | application/octet-stream MIME sub-part (see TS 26.140 [16] , | ||
section 4.1) | section 4.1) | ||
− | For references see | + | For references see [[RFC4355]]. |
Security Considerations: | Security Considerations: | ||
There are no specific security issues with this Enumservice. | There are no specific security issues with this Enumservice. | ||
However, the general considerations of Section 6 apply, see | However, the general considerations of Section 6 apply, see | ||
− | + | [[RFC4355]]. | |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | ||
− | contact detail see | + | contact detail see [[RFC4355]]) |
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
None | None | ||
Line 2,051: | Line 2,051: | ||
associated URI scheme is capable of receiving a message using | associated URI scheme is capable of receiving a message using | ||
the Enhanced Message Service (EMS) [14] (For reference see | the Enhanced Message Service (EMS) [14] (For reference see | ||
− | + | [[RFC4355]]). | |
Security Considerations: | Security Considerations: | ||
There are no specific security issues with this Enumservice. | There are no specific security issues with this Enumservice. | ||
However, the general considerations of Section 6 apply. | However, the general considerations of Section 6 apply. | ||
− | See | + | See [[RFC4355]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | ||
− | contact detail see | + | contact detail see [[RFC4355]]) |
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Note that an indication of EMS can be taken as implying that | Note that an indication of EMS can be taken as implying that | ||
Line 2,078: | Line 2,078: | ||
either a text or application/octet-stream MIME sub-part (see | either a text or application/octet-stream MIME sub-part (see | ||
TS 26.140 [16] , section 4.1). | TS 26.140 [16] , section 4.1). | ||
− | For references see | + | For references see [[RFC4355]] |
Security Considerations: | Security Considerations: | ||
There are no specific security issues with this Enumservice. | There are no specific security issues with this Enumservice. | ||
− | However, the general considerations of Section 6 of | + | However, the general considerations of Section 6 of [[RFC4355]] |
apply. | apply. | ||
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | ||
− | contact detail see | + | contact detail see [[RFC4355]]) |
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
None | None | ||
Line 2,098: | Line 2,098: | ||
associated URI scheme is capable of receiving a message using | associated URI scheme is capable of receiving a message using | ||
the Multimedia Messaging Service (MMS) [15]. | the Multimedia Messaging Service (MMS) [15]. | ||
− | For references see | + | For references see [[RFC4355]] |
Security Considerations: | Security Considerations: | ||
There are no specific security issues with this Enumservice. | There are no specific security issues with this Enumservice. | ||
− | However, the general considerations of Section 6 of | + | However, the general considerations of Section 6 of [[RFC4355]] |
apply. | apply. | ||
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | ||
− | contact detail see | + | contact detail see [[RFC4355]]) |
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Note that MMS can be used as an alternative to deliver an SMS | Note that MMS can be used as an alternative to deliver an SMS | ||
Line 2,137: | Line 2,137: | ||
specialised headers carried in the SMTP message exchanges. | specialised headers carried in the SMTP message exchanges. | ||
The headers used in such MMSE are described in detail in [17]. | The headers used in such MMSE are described in detail in [17]. | ||
− | For references see | + | For references see [[RFC4355]] |
Security Considerations: | Security Considerations: | ||
There are no specific security issues with this Enumservice. | There are no specific security issues with this Enumservice. | ||
− | However, the general considerations of Section 6 of | + | However, the general considerations of Section 6 of [[RFC4355]] |
apply. | apply. | ||
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author | ||
− | contact detail see | + | contact detail see [[RFC4355]]) |
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
The MMS Architecture describes an interface between the MMSE and | The MMS Architecture describes an interface between the MMSE and | ||
Line 2,163: | Line 2,163: | ||
Type: VPIM | Type: VPIM | ||
Subtype: MAILTO | Subtype: MAILTO | ||
− | Functional Specification: See section 4.2 through 4.4 of | + | Functional Specification: See section 4.2 through 4.4 of [[RFC4238]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Author: Greg Vaudreuil (gregv&ieee.org) | Author: Greg Vaudreuil (gregv&ieee.org) | ||
Line 2,192: | Line 2,192: | ||
Type: VPIM | Type: VPIM | ||
Subtype: LDAP | Subtype: LDAP | ||
− | Functional Specification: See section 3.2 through 3.3 of | + | Functional Specification: See section 3.2 through 3.3 of [[RFC4238]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Author: Greg Vaudreuil (gregv&ieee.org) | Author: Greg Vaudreuil (gregv&ieee.org) | ||
Line 2,223: | Line 2,223: | ||
URI generated by this NAPTR. | URI generated by this NAPTR. | ||
Security Considerations: | Security Considerations: | ||
− | See Section 5 of | + | See Section 5 of [[RFC4415]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for | Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for | ||
Line 2,266: | Line 2,266: | ||
initiate a telecommunication session, which may include two-way | initiate a telecommunication session, which may include two-way | ||
voice or other communications, to the PSTN. These URIs may | voice or other communications, to the PSTN. These URIs may | ||
− | contain number portability data as specified in RFC 4694 [10]. | + | contain number portability data as specified in [[RFC4694|RFC 4694]] [10]. |
− | Security Considerations: See Section 7 of | + | Security Considerations: See Section 7 of [[RFC4769]]. |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,274: | Line 2,274: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
A Number Portability Dip Indicator (npdi) should be used in | A Number Portability Dip Indicator (npdi) should be used in | ||
− | practice (see examples below in Section 4 of | + | practice (see examples below in Section 4 of [[RFC4769]]). |
Enumservice Name: "pstn" | Enumservice Name: "pstn" | ||
Line 2,285: | Line 2,285: | ||
initiate a telecommunication session, which may include two-way | initiate a telecommunication session, which may include two-way | ||
voice or other communications, to the PSTN. | voice or other communications, to the PSTN. | ||
− | Security Considerations: See Section 7 of | + | Security Considerations: See Section 7 of [[RFC4769]]. |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,292: | Line 2,292: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
A Number Portability Dip Indicator (npdi) should be used in | A Number Portability Dip Indicator (npdi) should be used in | ||
− | practice (see examples below in Section 4 of | + | practice (see examples below in Section 4 of [[RFC4769]]). |
Enumservice Name: "vCard" | Enumservice Name: "vCard" | ||
Line 2,301: | Line 2,301: | ||
Functional Specification: | Functional Specification: | ||
This Enumservice indicates that the resource identified is a | This Enumservice indicates that the resource identified is a | ||
− | plain vCard, according to RFC 2426, which may be accessed using | + | plain vCard, according to [[RFC2426|RFC 2426]], which may be accessed using |
HTTP/ HTTPS [7]. | HTTP/ HTTPS [7]. | ||
Clients fetching the vCard from the resource indicated should | Clients fetching the vCard from the resource indicated should | ||
Line 2,307: | Line 2,307: | ||
of the data provided may vary depending on the client's | of the data provided may vary depending on the client's | ||
identity. | identity. | ||
− | Security Considerations: see Section 5 | + | Security Considerations: see Section 5 [[RFC4969]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Author: Alexander Mayrhofer <alexander.mayrhofer&enum.at> | Author: Alexander Mayrhofer <alexander.mayrhofer&enum.at> | ||
Line 2,318: | Line 2,318: | ||
This Enumservice indicates that the resource identified is an | This Enumservice indicates that the resource identified is an | ||
XMPP entity. | XMPP entity. | ||
− | Security Considerations: see Section 6 of | + | Security Considerations: see Section 6 of [[RFC4979]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Author: Alexander Mayrhofer <alexander.mayrhofer&enum.at> | Author: Alexander Mayrhofer <alexander.mayrhofer&enum.at> | ||
Line 2,331: | Line 2,331: | ||
any particular protocol that will be used to handle | any particular protocol that will be used to handle | ||
instant messaging receipt or delivery, rather the mechanism | instant messaging receipt or delivery, rather the mechanism | ||
− | in RFC 3861 [4] is used to discover whether an IM protocol | + | in [[RFC3861|RFC 3861]] [4] is used to discover whether an IM protocol |
supported by the party querying ENUM is also supported by | supported by the party querying ENUM is also supported by | ||
the target resource. | the target resource. | ||
− | Security considerations: See section 3 of | + | Security considerations: See section 3 of [[RFC5028]] |
Intended usage: COMMON | Intended usage: COMMON | ||
Author: Rohan Mahy (rohan&ekabal.com) | Author: Rohan Mahy (rohan&ekabal.com) | ||
Line 2,347: | Line 2,347: | ||
initiate a voice communication session to a voice messaging | initiate a voice communication session to a voice messaging | ||
system. | system. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,354: | Line 2,354: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "voicemsg" | Enumservice Name: "voicemsg" | ||
Line 2,365: | Line 2,365: | ||
initiate a voice communication session to a voice messaging | initiate a voice communication session to a voice messaging | ||
system. | system. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,373: | Line 2,373: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "voicemsg" | Enumservice Name: "voicemsg" | ||
Line 2,384: | Line 2,384: | ||
initiate a voice communication session to a voice messaging | initiate a voice communication session to a voice messaging | ||
system. | system. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,391: | Line 2,391: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "voicemsg" | Enumservice Name: "voicemsg" | ||
Line 2,408: | Line 2,408: | ||
files. Thus, one cannot be more specific about the kind of | files. Thus, one cannot be more specific about the kind of | ||
information expected when contacting the resource. | information expected when contacting the resource. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,415: | Line 2,415: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "voicemsg" | Enumservice Name: "voicemsg" | ||
Line 2,433: | Line 2,433: | ||
message files. Thus, one cannot be more specific about the kind | message files. Thus, one cannot be more specific about the kind | ||
of information expected when contacting the resource. | of information expected when contacting the resource. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,440: | Line 2,440: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "videomsg" | Enumservice Name: "videomsg" | ||
Line 2,451: | Line 2,451: | ||
initiate a video communication session to a video messaging | initiate a video communication session to a video messaging | ||
system. | system. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,458: | Line 2,458: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "videomsg" | Enumservice Name: "videomsg" | ||
Line 2,469: | Line 2,469: | ||
initiate a video communication session to a video messaging | initiate a video communication session to a video messaging | ||
system. | system. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,476: | Line 2,476: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "videomsg" | Enumservice Name: "videomsg" | ||
Line 2,493: | Line 2,493: | ||
files. Thus, one cannot be more specific about the kind of | files. Thus, one cannot be more specific about the kind of | ||
information expected when contacting the resource. | information expected when contacting the resource. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,500: | Line 2,500: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "videomsg" | Enumservice Name: "videomsg" | ||
Line 2,518: | Line 2,518: | ||
message files. Thus, one cannot be more specific about the kind | message files. Thus, one cannot be more specific about the kind | ||
of information expected when contacting the resource. | of information expected when contacting the resource. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,525: | Line 2,525: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "unifmsg" | Enumservice Name: "unifmsg" | ||
Line 2,536: | Line 2,536: | ||
initiate a unified communication session to a unified messaging | initiate a unified communication session to a unified messaging | ||
system. | system. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,543: | Line 2,543: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "unifmsg" | Enumservice Name: "unifmsg" | ||
Line 2,554: | Line 2,554: | ||
initiate a unified communication session to a unified messaging | initiate a unified communication session to a unified messaging | ||
system. | system. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,560: | Line 2,560: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "unifmsg" | Enumservice Name: "unifmsg" | ||
Line 2,577: | Line 2,577: | ||
files. Thus, one cannot be more specific about the kind of | files. Thus, one cannot be more specific about the kind of | ||
information expected when contacting the resource. | information expected when contacting the resource. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,584: | Line 2,584: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "unifmsg" | Enumservice Name: "unifmsg" | ||
Line 2,602: | Line 2,602: | ||
message files. Thus, one cannot be more specific about the kind | message files. Thus, one cannot be more specific about the kind | ||
of information expected when contacting the resource. | of information expected when contacting the resource. | ||
− | Security Considerations: See Section 3 of | + | Security Considerations: See Section 3 of [[RFC5278]] |
Intended Usage: COMMON | Intended Usage: COMMON | ||
Authors: | Authors: | ||
Line 2,609: | Line 2,609: | ||
Any other information the author deems interesting: | Any other information the author deems interesting: | ||
Implementers should review a non-exclusive list of examples | Implementers should review a non-exclusive list of examples | ||
− | below in Section 7 of | + | below in Section 7 of [[RFC5278]] |
Enumservice Name: "ical-sched" | Enumservice Name: "ical-sched" | ||
Line 2,620: | Line 2,620: | ||
Internet calendaring via Internet mail with the iMIP [6] | Internet calendaring via Internet mail with the iMIP [6] | ||
protocol. | protocol. | ||
− | Security considerations: See Section 4 of | + | Security considerations: See Section 4 of [[RFC5333]]. |
Intended usage: COMMON | Intended usage: COMMON | ||
Author: | Author: | ||
Line 2,634: | Line 2,634: | ||
calendar (for example free/busy status) using the CalDAV [7] | calendar (for example free/busy status) using the CalDAV [7] | ||
protocol for Internet calendaring. | protocol for Internet calendaring. | ||
− | Security considerations: See Section 4 of | + | Security considerations: See Section 4 of [[RFC5333]]. |
Intended usage: COMMON | Intended usage: COMMON | ||
Author: | Author: | ||
Line 2,648: | Line 2,648: | ||
calendar (for example free/busy status) using the CalDAV [7] | calendar (for example free/busy status) using the CalDAV [7] | ||
protocol for Internet calendaring. | protocol for Internet calendaring. | ||
− | Security considerations: See Section 4 of | + | Security considerations: See Section 4 of [[RFC5333]]. |
Intended usage: COMMON | Intended usage: COMMON | ||
Author: | Author: |
Latest revision as of 03:36, 22 October 2020
Internet Engineering Task Force (IETF) B. Hoeneisen Request for Comments: 6118 Ucom.ch Updates: 3762, 3764, 3953, 4143, 4002, A. Mayrhofer
4238, 4355, 4415, 4769, 4969, enum.at 4979, 5028, 5278, 5333 March 2011
Category: Standards Track ISSN: 2070-1721
Update of Legacy IANA Registrations of Enumservices
Abstract
This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6118.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
4. Legacy Enumservice Registrations Converted to XML Chunks . . . 5
Contents
Introduction
RFC6117 has obsoleted the IANA registration section of RFC3761. Since the IANA Enumservice registry contains various Enumservices registered under the regime of RFC 3761, those registrations do not conform to the new guidelines as specified in RFC6117. To ensure consistency among all Enumservice registrations at IANA, this document adds the (nowadays) missing elements to those legacy registrations. Furthermore, all legacy Enumservice registrations are converted to the new XML-chunk format, and, where deemed necessary, minor editorial corrections are applied.
However, this document only adds the missing elements to the XML chunks as specified in the IANA Considerations section of RFC6117, but it does not complete the (nowadays) missing sections of the corresponding Enumservice Specifications. In order to conform with the new registration regime as specified in RFC6117, those Enumservice Specifications still have to be revised.
It is important to note that this document does not update the functional specification of the concerned Enumservices.
The following RFCs are updated by this document:
o RFC3762 o RFC3764 o RFC3953 o RFC4143 o RFC4002 o RFC4238 o RFC4355 o RFC4415 o RFC4769 o RFC4969 o RFC4979 o RFC5028 o RFC5278 o RFC5333
Terminology
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 RFC 2119 RFC2119.
IESG Action
According to RFC3761, any Enumservice registration had to be published as a Standards Track, Experimental, or BCP (Best Current Practice) RFC. RFC6117 no longer has this requirement, i.e., "Specification Required", which implies the use of a Designated Expert RFC5226, is sufficient.
This document changes the approval requirement for updates to Enumservice registrations to Specification Required, whereby the specification and request are reviewed by a Designated Expert as described in RFC6117.
Legacy Enumservice Registrations Converted to XML Chunks
In the following, the legacy Enumservice Registrations are converted to XML chunks that include the new elements introduced by RFC6117.
(Note that references in Sections 4.1 - 4.39 refer to the references section within the respective Enumservice Specification.)
email:mailto
<record> <class>Application-Based, Common</class> <type>email</type> <subtype>mailto</subtype> <urischeme>mailto</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource can be addressed by the associated URI in order to send an email. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc4355"/>, Section 6. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/>
</requesters> </record>
ems:mailto
<record> <class>Application-Based, Common</class> <type>ems</type> <subtype>mailto</subtype> <urischeme>mailto</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI is capable of receiving a message using an email protocol. </paragraph> <paragraph> EMS content is sent over SMTP using the format specified by TS 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4, as an MMS message. Within such a message, EMS content is carried as either a text or application/octet-stream MIME sub-part (see TS 26.140 [16], Section 4.1). </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc4355"/>. </paragraph> </functionalspec> <security> <paragraph> There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of <xref type="rfc" data="rfc4355"/> apply. </paragraph> </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/> </requesters> </record>
ems:tel
<record> <class>Application-Based, Common</class> <type>ems</type> <subtype>tel</subtype> <urischeme>tel</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI is capable of receiving a message using the Enhanced Message Service (EMS) [14]. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc4355"/>. </paragraph> </functionalspec> <security> <paragraph> There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of <xref type="rfc" data="rfc4355"/> apply. </paragraph> </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/> </requesters> <additionalinfo> <paragraph> Note that an indication of EMS can be taken as implying that the recipient is capable of receiving SMS messages at this address as well. </paragraph> </additionalinfo> </record>
fax:tel
<record> <class>Application-Based, Subset</class> <type>fax</type> <subtype>tel</subtype> <urischeme>tel</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI is capable of being contacted to provide a communication session during which facsimile documents can be sent. </paragraph> <paragraph> A client selecting this NAPTR will have support for generating and sending facsimile documents to the recipient using the PSTN session and transfer protocols specified in [12] and [13] in <xref type="rfc" data="rfc4355"/> - in short, they will have a fax program with a local or shared PSTN access over which they can send faxes. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc4355"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc4355"/>, Section 6. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/> </requesters> </record>
ft:ftp
<record> <class>Application-Based, Subset</class> <type>ft</type> <subtype>ftp</subtype> <urischeme>ftp</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI is a file service from which a file or file listing can be retrieved. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc4002"/>, Section 5. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4002"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/> </requesters> </record>
h323
<record> <class>Protocol-Based</class> <type>h323</type> <urischeme>h323</urischeme> <functionalspec> See <xref type="rfc" data="rfc3762"/>, Section 3. </functionalspec> <security> See <xref type="rfc" data="rfc3762"/>, Section 5. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc3762"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Orit_Levin"/> </requesters> </record>
ical-access:http
<record> <class>Application-Based, Common</class> <type>ical-access</type> <subtype>http</subtype> <urischeme>http</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified can be addressed by the associated URI in order to access a user's calendar (for example free/busy status) using the CalDAV [7] protocol for Internet calendaring. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc5333"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5333"/>, Section 4. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5333"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rohan_Mahy"/> </requesters> </record>
ical-access:https
<record> <class>Application-Based, Common</class> <type>ical-access</type> <subtype>https</subtype> <urischeme>https</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified can be addressed by the associated URI in order to access a user's calendar (for example free/busy status) using the CalDAV [7] protocol for Internet calendaring. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc5333"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5333"/>, Section 4. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5333"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rohan_Mahy"/> </requesters> </record>
ical-sched:mailto
<record> <class>Application-Based, Common</class> <type>ical-sched</type> <subtype>mailto</subtype> <urischeme>mailto</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified can be addressed by the associated URI used for scheduling using Internet calendaring via Internet mail with the iMIP [6] protocol. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc5333"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5333"/>, Section 4. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5333"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rohan_Mahy"/> </requesters> </record>
4.10. ifax:mailto
<record> <class>Application-Based, Subset</class> <type>ifax</type> <subtype>mailto</subtype> <urischeme>mailto</urischeme> <functionalspec> See <xref type="rfc" data="rfc4143"/>, Section 1. </functionalspec> <security> See <xref type="rfc" data="rfc4143"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4143"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Kiyoshi_Toyoda"/> <xref type="person" data="Dave_Crocker"/> </requesters> <additionalinfo> <paragraph> The URI Scheme is 'mailto' because facsimile is a profile of standard Internet mail and uses standard Internet mail addressing. </paragraph> </additionalinfo> </record>
4.11. im
<record> <class>Application-Based, Common</class> <type>im</type> <urischeme>im</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified is an 'im:' URI. The 'im:' URI scheme does not identify any particular protocol that will be used to handle instant messaging receipt or delivery, rather the mechanism in RFC 3861 [4] is used to discover whether an IM protocol supported by the party querying ENUM is also supported by the target resource. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc5028"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5028"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5028"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rohan_Mahy"/> </requesters> </record>
4.12. mms:mailto
<record> <class>Application-Based, Common</class> <type>mms</type> <subtype>mailto</subtype> <urischeme>mailto</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI is capable of receiving a message using an email protocol. </paragraph> <paragraph> MMS messages are sent over SMTP using the format specified by TS 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4. </paragraph> <paragraph> Within and between MMS Environments (MMSE, network infrastructures that support the MultiMedia Service), other pieces of state data (for example, charging-significant information) are exchanged between MMS Relay Servers. Thus, although these servers use SMTP as the "bearer" for their application exchanges, they map their internal state to specialized header fields carried in the SMTP message exchanges. The header fields used in such MMSE are described in detail in [17]. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc4355"/>. </paragraph> </functionalspec> <security> <paragraph> There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of <xref type="rfc" data="rfc4355"/> apply. </paragraph> </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters>
<xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/> </requesters> <additionalinfo> <paragraph> The MMS Architecture describes an interface between the MMSE and "legacy messaging systems" (labelled as MM3) that accepts "standard" SMTP messages. Thus, although the MMS Relay Server that supports this interface appears as a standard SMTP server from the perspective of an Internet-based mail server, it acts as a gateway and translator, adding the internal state data that is used within and between the MMS Environments. This mechanism is described in [17], which also includes references to the specifications agreed by those bodies responsible for the design of the MMS. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc4355"/>. </paragraph> </additionalinfo> </record>
4.13. mms:tel
<record> <class>Application-Based, Common</class> <type>mms</type> <subtype>tel</subtype> <urischeme>tel</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI is capable of receiving a message using the Multimedia Messaging Service (MMS) [15]. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc4355"/>. </paragraph> </functionalspec> <security> <paragraph> There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of <xref type="rfc" data="rfc4355"/> apply. </paragraph> </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/> </requesters> <additionalinfo> <paragraph> Note that MMS can be used as an alternative to deliver an SMS RP-DATA RPDU if, for example, the SMS bearer is not supported. If an entry includes this Enumservice, then in effect this can be taken as implying that the recipient is capable of receiving EMS or SMS messages at this address. Such choices on the end system design do have two small caveats; whilst in practice all terminals supporting MMS today support SMS as well, it might not necessarily be the case in the future, and there may
be tariff differences in using the MMS rather than using the SMS or EMS. </paragraph> </additionalinfo> </record>
4.14. pres
<record> <class>Application-Based, Common</class> <type>pres</type> <urischeme>pres</urischeme> <functionalspec> See <xref type="rfc" data="rfc3953"/>, Section 4. </functionalspec> <security> See <xref type="rfc" data="rfc3953"/>, Section 6. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc3953"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jon_Peterson"/> </requesters> <additionalinfo> <paragraph> See <xref type="rfc" data="rfc3953"/>, Section 3. </paragraph> </additionalinfo> </record>
4.15. pstn:sip
<record> <class>Application-Based, Common</class> <type>pstn</type> <subtype>sip</subtype> <urischeme>sip</urischeme> <functionalspec> <paragraph> These Enumservices indicate that the resource identified can be addressed by the associated URI in order to initiate a telecommunication session, which may include two-way voice or other communications, to the PSTN. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc4769"/>, Section 7. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4769"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Richard_Shockey"/> </requesters> <additionalinfo> <paragraph> A Number Portability Dip Indicator (npdi) should be used in practice (see <xref type="rfc" data="rfc4769"/>, Section 4). </paragraph> </additionalinfo> </record>
4.16. pstn:tel
<record> <class>Application-Based, Ancillary</class> <type>pstn</type> <subtype>tel</subtype> <urischeme>tel</urischeme> <functionalspec> <paragraph> These Enumservices indicate that the resource identified can be addressed by the associated URI in order to initiate a telecommunication session, which may include two-way voice or other communications, to the PSTN. These URIs may contain number portability data as specified in RFC4694 [10]. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc4769"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc4769"/>, Section 7. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4769"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Richard_Shockey"/> </requesters> <additionalinfo> <paragraph> A Number Portability Dip Indicator (npdi) should be used in practice (see <xref type="rfc" data="rfc4769"/>, Section 4). </paragraph> </additionalinfo> </record>
4.17. sip
<record> <class>Protocol-Based</class> <type>sip</type> <urischeme>sip</urischeme> <urischeme>sips</urischeme> <functionalspec> See <xref type="rfc" data="rfc3764"/>, Section 4. </functionalspec> <security> See <xref type="rfc" data="rfc3764"/>, Section 6. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc3764"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jon_Peterson"/> </requesters> <additionalinfo> <paragraph> See <xref type="rfc" data="rfc3764"/>, Section 3. </paragraph> </additionalinfo> </record>
4.18. sms:mailto
<record> <class>Application-Based, Common</class> <type>sms</type> <subtype>mailto</subtype> <urischeme>mailto</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI is capable of receiving a message using an email protocol. </paragraph> <paragraph> SMS content is sent over SMTP using the format specified by TS 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4, as an MMS message. Within such a message, SMS content is carried as either a text or application/octet-stream MIME sub-part (see TS 26.140 [16], Section 4.1) </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc4355"/>. </paragraph> </functionalspec> <security> <paragraph> There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of <xref type="rfc" data="rfc4355"/> apply. </paragraph> </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/> </requesters> </record>
4.19. sms:tel
<record> <class>Application-Based, Common</class> <type>sms</type> <subtype>tel</subtype> <urischeme>tel</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI is capable of receiving a message using the Short Message Service (SMS) [14]. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc4355"/>. </paragraph> </functionalspec> <security> <paragraph> There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of <xref type="rfc" data="rfc4355"/> apply. </paragraph> </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4355"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/> </requesters> </record>
4.20. unifmsg:http
<record> <class>Application-Based, Common</class> <type>unifmsg</type> <subtype>http</subtype> <urischeme>http</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI scheme is capable of being a source of information. </paragraph> <paragraph> Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc5278"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.21. unifmsg:https
<record> <class>Application-Based, Common</class> <type>unifmsg</type> <subtype>https</subtype> <urischeme>https</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol. </paragraph> <paragraph> Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc5278"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.22. unifmsg:sip
<record> <class>Application-Based, Common</class> <type>unifmsg</type> <subtype>sip</subtype> <urischeme>sip</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified can be addressed by the associated URI scheme in order to initiate a unified communication session to a unified messaging system. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.23. unifmsg:sips
<record> <class>Application-Based, Common</class> <type>unifmsg</type> <subtype>sips</subtype> <urischeme>sips</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified can be addressed by the associated URI scheme in order to initiate a unified communication session to a unified messaging system. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.24. vcard
<record> <class>Data Type-Based</class> <type>vcard</type> <urischeme>http</urischeme> <urischeme>https</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified is a plain vCard, according to RFC2426, which may be accessed using HTTP / HTTPS [7]. </paragraph> <paragraph> Clients fetching the vCard from the resource indicated should expect access to be restricted. Additionally, the comprehension of the data provided may vary depending on the client's identity. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc4969"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc4969"/>, Section 5. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4969"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Alexander_Mayrhofer"/> </requesters> </record>
4.25. videomsg:http
<record> <class>Application-Based, Common</class> <type>videomsg</type> <subtype>http</subtype> <urischeme>http</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI scheme is capable of being a source of information. </paragraph> <paragraph> Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc5278"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.26. videomsg:https
<record> <class>Application-Based, Common</class> <type>videomsg</type> <subtype>https</subtype> <urischeme>https</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol. </paragraph> <paragraph> Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc5278"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.27. videomsg:sip
<record> <class>Application-Based, Common</class> <type>videomsg</type> <subtype>sip</subtype> <urischeme>sip</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified can be addressed by the associated URI scheme in order to initiate a video communication session to a video messaging system. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.28. videomsg:sips
<record> <class>Application-Based, Common</class> <type>videomsg</type> <subtype>sips</subtype> <urischeme>sips</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified can be addressed by the associated URI scheme in order to initiate a video communication session to a video messaging system. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.29. voice:tel
<record> <class>Application-Based, Common</class> <type>voice</type> <subtype>tel</subtype> <urischeme>tel</urischeme> <functionalspec> <paragraph> The kind of communication indicated by this Enumservice is "Interactive Voice". From a protocol perspective, this communication is expected to involve bidirectional media streams carrying audio data. </paragraph> <paragraph> A client may imply that the person controlling population of a NAPTR holding this Enumservice indicates their capability to engage in an interactive voice session when contacted using the URI generated by this NAPTR. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc4415"/>, Section 5. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4415"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/> </requesters> <additionalinfo> <paragraph> This Enumservice indicates that the person responsible for the NAPTR is accessible via the PSTN (Public Switched Telephone Network) or PLMN (Public Land Mobile Network) using the value of the generated URI. </paragraph> <paragraph>The kind of subsystem required to initiate a Voice Enumservice with this Subtype is a "Dialler". This is a subsystem that either provides a local
connection to the PSTN or PLMN, or that provides an indirect connection to those networks. The subsystem will use the telephone number held in the generated URI to place a voice call. The voice call is placed to a network that uses E.164 numbers to route calls to an appropriate destination. </paragraph> <paragraph> Note that the PSTN/PLMN connection may be indirect. The end user receiving this NAPTR may have a relationship with a Communications Service Provider that accepts call initiation requests from that subsystem using an IP-based protocol such as SIP or H.323, and places the call to the PSTN using a remote gateway service. In this case, the Provider may either accept requests using "tel:" URIs or has a defined mechanism to convert "tel:" URI values into a "protocol-native" form. </paragraph> <paragraph> The "tel:" URI value SHOULD be fully qualified (using the "global phone number" form of RFC 3966 [10]). A "local phone number" as defined in that document SHOULD NOT be used unless the controller of the zone in which the NAPTR appears is sure that it can be distinguished unambiguously by all clients that can access the resource record and that a call from their network access points can be routed to that destination. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc4415"/>. </paragraph> </additionalinfo> </record>
4.30. voicemsg:http
<record> <class>Application-Based, Common</class> <type>voicemsg</type> <subtype>http</subtype> <urischeme>http</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI scheme is capable of being a source of information. </paragraph> <paragraph> Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even voice message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc5278"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.31. voicemsg:https
<record> <class>Application-Based, Common</class> <type>voicemsg</type> <subtype>https</subtype> <urischeme>https</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol. </paragraph> <paragraph> Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even voice message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. </paragraph> <paragraph> References are contained in <xref type="rfc" data="rfc5278"/>. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.32. voicemsg:sip
<record> <class>Application-Based, Common</class> <type>voicemsg</type> <subtype>sip</subtype> <urischeme>sip</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.33. voicemsg:sips
<record> <class>Application-Based, Common</class> <type>voicemsg</type> <subtype>sips</subtype> <urischeme>sips</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.34. voicemsg:tel
<record> <class>Application-Based, Common</class> <type>voicemsg</type> <subtype>tel</subtype> <urischeme>tel</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc5278"/>, Section 3. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc5278"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Jason_Livingood"/> <xref type="person" data="Don_Troshynski"/> </requesters> <additionalinfo> <paragraph> Implementers should review a non-exclusive list of examples in Section 7 of <xref type="rfc" data="rfc5278"/>. </paragraph> </additionalinfo> </record>
4.35. vpim:ldap
<record> <class>Data Type-Based</class> <type>vpim</type> <subtype>ldap</subtype> <urischeme>ldap</urischeme> <functionalspec> See <xref type="rfc" data="rfc4238"/>, Section 3.2 - 3.3. </functionalspec> <security> <paragraph> Malicious Redirection: One of the fundamental dangers related to any service such as this is that a malicious entry in a resolver's database will cause clients to resolve the E.164 into the wrong LDAP URI. The possible intent may be to cause the client to connect to a rogue LDAP server and retrieve (or fail to retrieve) a resource containing fraudulent or damaging information. </paragraph> <paragraph> Denial of Service: By removing the URI to which the E.164 maps, a malicious intruder may remove the client's ability to access the LDAP directory server. </paragraph> </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4238"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Greg_Vaudreuil"/> </requesters> </record>
4.36. vpim:mailto
<record> <class>Data Type-Based</class> <type>vpim</type> <subtype>mailto</subtype> <urischeme>mailto</urischeme> <functionalspec> See <xref type="rfc" data="rfc4238"/>, Section 4.2 - 4.4. </functionalspec> <security> <paragraph> Malicious Redirection: One of the fundamental dangers related to any service such as this is that a malicious entry in a resolver's database will cause clients to resolve the E.164 into the wrong email URI. The possible intent may be to cause the client to send the information to an incorrect destination. </paragraph> <paragraph> Denial of Service: By removing the URI to which the E.164 maps, a malicious intruder may remove the client's ability to access the resource. </paragraph> <paragraph> Unsolicited Bulk Email: The exposure of email addresses through the ENUM service provides a bulk mailer access to large numbers of email addresses where only the telephone number was previously known. </paragraph> </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4238"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Greg_Vaudreuil"/> </requesters> <additionalinfo> <paragraph> Error Conditions: </paragraph> <paragraph>
E.164 number not in the numbering plan </paragraph> <paragraph> E.164 number in the numbering plan, but no URIs exist for that number </paragraph> <paragraph> E2U+vpim:mailto Service unavailable of email addresses where only the telephone number was previously known. </paragraph> </additionalinfo> </record>
4.37. web:http
<record> <class>Application-Based, Common</class> <type>web</type> <subtype>http</subtype> <urischeme>http</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI is capable of being a source of information. It has to be noted that the kind of information retrieved can be manifold. Usually, contacting a resource by an "http:" URI provides a document. This document can contain references that will trigger download of many different kinds of information, like audio or video or executable code. Thus, one cannot be more specific about the kind of information that can be expected when contacting the resource. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc4002"/>, Section 5. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4002"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/> </requesters> </record>
4.38. web:https
<record> <class>Application-Based, Common</class> <type>web</type> <subtype>https</subtype> <urischeme>https</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified by the associated URI is capable of being a source of information, which can be contacted by using TLS or the Secure Socket Layer protocol. It has to be noted that the kind of information retrieved can be manifold. Usually, contacting a resource by an "https:" URI provides a document. This document can contain all different kinds of information, like audio or video or executable code. Thus, one cannot be more specific what information to expect when contacting the resource. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc4002"/>, Section 5. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4002"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Rudolf_Brandner"/> <xref type="person" data="Lawrence_Conroy"/> <xref type="person" data="Richard_Stastny"/> </requesters> </record>
4.39. xmpp
<record> <class>Protocol-Based</class> <type>xmpp</type> <urischeme>xmpp</urischeme> <functionalspec> <paragraph> This Enumservice indicates that the resource identified is an XMPP entity. </paragraph> </functionalspec> <security> See <xref type="rfc" data="rfc4979"/>, Section 6. </security> <usage>COMMON</usage> <registrationdocs> <xref type="rfc" data="rfc4979"/> (updated by RFC 6118) <xref type="rfc" data="RFC 6118"/> </registrationdocs> <requesters> <xref type="person" data="Alexander_Mayrhofer"/> </requesters> </record>
IANA Considerations
IANA replaced all legacy Enumservice Registrations as per Section 4.
Security Considerations
Since this document does not introduce any technology or protocol, there are no security issues to be considered for this document itself.
Acknowledgements
The authors would like to thank the following people who have provided feedback or significant contributions to the development of this document: Jari Arkko, Scott Bradner, Gonzalo Camarillo, Alfred Hoenes, Ari Keranen, and Alexey Melnikov.
References
Normative References
RFC2026 Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
RFC2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC3761 Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
RFC3762 Levin, O., "Telephone Number Mapping (ENUM) Service
Registration for H.323", RFC 3762, April 2004.
RFC3764 Peterson, J., "enumservice registration for Session
Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
RFC3953 Peterson, J., "Telephone Number Mapping (ENUM) Service
Registration for Presence Services", RFC 3953, January 2005.
RFC4002 Brandner, R., Conroy, L., and R. Stastny, "IANA
Registration for Enumservice 'web' and 'ft'", RFC 4002, February 2005.
RFC4143 Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail
(IFAX) Service of ENUM", RFC 4143, November 2005.
RFC4238 Vaudreuil, G., "Voice Message Routing Service", RFC 4238,
October 2005.
RFC4355 Brandner, R., Conroy, L., and R. Stastny, "IANA
Registration for Enumservices email, fax, mms, ems, and sms", RFC 4355, January 2006.
RFC4415 Brandner, R., Conroy, L., and R. Stastny, "IANA
Registration for Enumservice Voice", RFC 4415, February 2006.
RFC4769 Livingood, J. and R. Shockey, "IANA Registration for an
Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information", RFC 4769, November 2006.
RFC4969 Mayrhofer, A., "IANA Registration for vCard Enumservice",
RFC 4969, August 2007.
RFC4979 Mayrhofer, A., "IANA Registration for Enumservice 'XMPP'",
RFC 4979, August 2007.
RFC5028 Mahy, R., "A Telephone Number Mapping (ENUM) Service
Registration for Instant Messaging (IM) Services", RFC 5028, October 2007.
RFC5278 Livingood, J. and D. Troshynski, "IANA Registration of
Enumservices for Voice and Video Messaging", RFC 5278, July 2008.
RFC5333 Mahy, R. and B. Hoeneisen, "IANA Registration of
Enumservices for Internet Calendaring", RFC 5333, October 2009.
RFC6117 Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA
Registration of Enumservices: Guide, Template, and IANA Considerations", RFC 6117, March 2011.
Informative References
RFC5226 Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
Appendix A. Former Content of the IANA Repository
Enumservice Registrations
(last updated 2009-10-13)
Registries included below: - Enumservice Registrations
Registry Name: Enumservice Registrations Reference: RFC3761 Registration Procedures: Require an RFC approved by the IESG
Note: Enumservice specifications contain the functional specification (i.e. what it can be used for), the valid protocols, and the URI schemes that may be returned.
Registry: Service Name: "H323" URI Scheme(s): "h323:" Functional Specification: See Section "3. The E2U+H323 ENUM Service" of RFC3762 Security considerations: see section "5. Security Considerations" of RFC3762 Intended usage: COMMON Author: Orit Levin RFC3762
Service Name: "SIP" Type(s): "SIP" Subtype(s): N/A URI Scheme(s): "sip", "sips:" Functional Specification: see Section 4 of RFC3764 Security considerations: see Section 6 of RFC3764 Intended usage: COMMON Author: Jon Peterson (jon.peterson&neustar.biz) Any other information that the author deems interesting: see Section 3 of RFC3764 RFC3764
Service Name: "ifax" Type: "ifax" Subtype: "mailto" URI Scheme: "mailto" The URI Scheme is "mailto" because facsimile is a profile of standard Internet mail and uses standard Internet mail addressing. Functional Specification: see section 1 of RFC4143 Security Considerations: see section 3 of RFC4143 Intended usage: COMMON Author: Kiyoshi Toyoda(toyoda.kiyoshi&jp.panasonic.com) Dave Crocker(dcrocker&brandenburg.com) RFC4143
Service Name: "pres" URI Scheme(s): "pres:" Functional Specification: see Section 4 of RFC3953 Security considerations: see Section 6 of RFC3953 Intended usage: COMMON Author: Jon Peterson (jon.peterson&neustar.biz) Any other information that the author deems interesting: See Section 3 of RFC3953 RFC3953
Service Name: "web" Type: "web" Subtype: "http" URI Scheme: 'http:' Functional Specification: This ENUMservice indicates that the resource identified by the associated URI scheme is capable of being a source of information. It has to be noted that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' URI provides a document. This document can contain references that will trigger download of many different kinds of information, like audio or video or executable code. Thus, one can not be more specific about the kind of information that can be expected when contacting the resource. Security Considerations: See section 5 of RFC4002. Intended Usage: COMMON Authors: Rudolf Brandner (rudolf.brandner&siemens.com) Lawrence Conroy (lwc&roke.co.uk) Richard Stastny (richard.stastny&oefeg.at) Any other information the author deems interesting: None RFC4002
Service Name: "web" Type: "web" Subtype: "https" URI Scheme: 'https:' Functional Specification: This ENUMservice indicates that the resource identified by the associated URI scheme is capable of being a source of information, which can be contacted by using TLS or Secure Socket Layer protocol. It has to be noted that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' URI provides a document. This document can contain all different kind of information, like audio or video or executable code. Thus, one can not be more specific what information to expect when contacting the resource. Security Considerations: See section 5 of RFC4002. Intended Usage: COMMON Authors: Rudolf Brandner (rudolf.brandner&siemens.com) Lawrence Conroy (lwc&roke.co.uk) Richard Stastny (richard.stastny&oefeg.at) Any other information the author deems interesting: None RFC4002
Service Name: "ft" Type: "ft" Subtype: "ftp" URI Scheme: 'ftp:' Functional Specification: This ENUMservice indicates that the resource identified by the associated URI scheme is a file service from which a file or file listing can be retrieved. Security Considerations: See section 5 of RFC4002. Intended Usage: COMMON Authors: Rudolf Brandner (rudolf.brandner&siemens.com) Lawrence Conroy (lwc&roke.co.uk) Richard Stastny (richard.stastny&oefeg.at) Any other information the author deems interesting: None RFC4002
Enumservice Name: "email" Enumservice Type: "email" Enumservice Subtype: "mailto" URI Scheme: 'mailto:' Functional Specification: This Enumservice indicates that the remote resource can be addressed by the associated URI scheme in order to send an email. Security Considerations: See Section 6 of RFC4355 Intended Usage: COMMON Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see RFC4355) Any other information the author deems interesting: None
Enumservice Name: "fax" Enumservice Type: "fax" Enumservice Subtype: "tel" URI Scheme: 'tel:' Functional Specification: This Enumservice indicates that the resource identified by the associated URI scheme is capable of being contacted to provide a communication session during which facsimile documents can be sent. A client selecting this NAPTR will have support for generating and sending facsimile documents to the recipient using the PSTN session and transfer protocols specified in [12] and [13] in RFC4355 - in short, they will have a fax program with a local or shared PSTN access over which they can send faxes. Security Considerations: See Section 6 of RFC4355 Intended Usage: COMMON Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see RFC4355) Any other information the author deems interesting: None
Enumservice Name: "sms" Enumservice Type: "sms" Enumservice Subtypes: "tel" URI Scheme: 'tel:' Functional Specification: This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using the Short Message Service (SMS) [14] in RFC4355. Security Considerations: There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply. Intended Usage: COMMON Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see RFC4355) Any other information the author deems interesting: None
Enumservice Name: "sms" Enumservice Type: "sms" Enumservice Subtypes: "mailto" URI Scheme: 'mailto:' Functional Specification: This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using an email protocol. SMS content is sent over SMTP using the format specified by TS 23.140 [15] section 8.4.4 and TS 26.140 [16] section 4 (for references see RFC4355), as an MMS message. Within such a message, SMS content is carried as either a text or application/octet-stream MIME sub-part (see TS 26.140 [16] , section 4.1) For references see RFC4355. Security Considerations: There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply, see RFC4355. Intended Usage: COMMON Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see RFC4355) Any other information the author deems interesting: None
Enumservice Name: "ems" Enumservice Type: "ems" Enumservice Subtype: "tel" URI Scheme: 'tel:' Functional Specification: This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using the Enhanced Message Service (EMS) [14] (For reference see RFC4355). Security Considerations: There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply. See RFC4355 Intended Usage: COMMON Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see RFC4355) Any other information the author deems interesting: Note that an indication of EMS can be taken as implying that the recipient is capable of receiving SMS messages at this address as well.
Enumservice Name: "ems" Enumservice Type: "ems" Enumservice Subtypes: "mailto" URI Scheme: 'mailto:' Functional Specification: This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using an email protocol. EMS content is sent over SMTP using the format specified by TS 23.140 [15] section 8.4.4 and TS 26.140 [16] section 4, as an MMS message. Within such a message, EMS content is carried as either a text or application/octet-stream MIME sub-part (see TS 26.140 [16] , section 4.1). For references see RFC4355 Security Considerations: There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of RFC4355 apply. Intended Usage: COMMON Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see RFC4355) Any other information the author deems interesting: None
Enumservice Name: "mms" Enumservice Type: "mms" Enumservice Subtype: "tel" URI Scheme: 'tel:' Functional Specification: This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using the Multimedia Messaging Service (MMS) [15]. For references see RFC4355 Security Considerations: There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of RFC4355 apply. Intended Usage: COMMON Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see RFC4355) Any other information the author deems interesting: Note that MMS can be used as an alternative to deliver an SMS RP-DATA RPDU if, for example, the SMS bearer is not supported. If an entry includes this Enumservice, then in effect this can be taken as implying that the recipient is capable of receiving EMS or SMS messages at this address. Such choices on the end system design do have two small caveats; whilst in practice all terminals supporting MMS today support SMS as well, it might not necessarily be the case in the future, and there may be tariff differences in using the MMS rather than using the SMS or EMS.
Enumservice Name: "mms" Enumservice Type: "mms" Enumservice Subtypes: "mailto" URI Scheme: 'mailto:' Functional Specification: This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using an email protocol. MMS messages are sent over SMTP using the format specified by TS 23.140 [15] section 8.4.4 and TS 26.140 [16] section 4. Within and between MMS Environments (MMSE, network infrastructures that support the MultiMedia Service), other pieces of state data (for example, charging-significant information) are exchanged between MMS Relay Servers. Thus, although these servers use SMTP as the "bearer" for their application exchanges, they map their internal state to specialised headers carried in the SMTP message exchanges. The headers used in such MMSE are described in detail in [17]. For references see RFC4355
Security Considerations: There are no specific security issues with this Enumservice. However, the general considerations of Section 6 of RFC4355 apply. Intended Usage: COMMON Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see RFC4355) Any other information the author deems interesting: The MMS Architecture describes an interface between the MMSE and "legacy messaging systems" (labelled as MM3) which accepts "standard" SMTP messages. Thus although the MMS Relay Server that supports this interface appears as a standard SMTP server from the perspective of an Internet-based mail server, it acts as a gateway and translator, adding the internal state data that is used within and between the MMS Environments. This mechanism is described in [17], which also includes references to the specifications agreed by those bodies responsible for the design of the MMS.
Service Name: E.164 to VPIM MailTo: URL URI Type: "Mailto:" Type: VPIM Subtype: MAILTO Functional Specification: See section 4.2 through 4.4 of RFC4238 Intended Usage: COMMON Author: Greg Vaudreuil (gregv&ieee.org) Error Conditions: o E.164 number not in the numbering plan o E.164 number in the numbering plan, but no URLs exist for that number o E2U+VPIM:Mailto Service unavailable Security Considerations: o Malicious Redirection One of the fundamental dangers related to any service such as this is that a malicious entry in a resolver's database will cause clients to resolve the E.164 into the wrong email URL. The possible intent may be to cause the client to send the information to an incorrect destination. o Denial of Service By removing the URL to which the E.164 maps, a malicious intruder may remove the client's ability to access the resource. o Unsolicited Bulk Email The exposure of email addresses through the ENUM service provides a bulk mailer access to large numbers of email addresses where only the telephone number was previously known.
Service Name: E.164 to VPIM LDAP URL URI Type: "LDAP:" Type: VPIM Subtype: LDAP Functional Specification: See section 3.2 through 3.3 of RFC4238 Intended Usage: COMMON Author: Greg Vaudreuil (gregv&ieee.org) Security Considerations: o Malicious Redirection One of the fundamental dangers related to any service such as this is that a malicious entry in a resolver's database will cause clients to resolve the E.164 into the wrong LDAP URL. The possible intent may be to cause the client to connect to a rogue LDAP server and retrieve (or fail to retrieve) a resource containing fraudulent or damaging information. o Denial of Service By removing the URL to which the E.164 maps, a malicious intruder may remove the client's ability to access the LDAP directory server.
Enumservice Name: "voice" Enumservice Type: "voice" Enumservice Subtype: "tel" URI Scheme: 'tel:' Functional Specification: The kind of communication indicated by this Enumservice is "Interactive Voice". From a protocol perspective, this communication is expected to involve bidirectional media streams carrying audio data. A client may imply that the person controlling population of a NAPTR holding this Enumservice indicates their capability to engage in an interactive voice session when contacted using the URI generated by this NAPTR. Security Considerations: See Section 5 of RFC4415 Intended Usage: COMMON Authors: Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see Authors' Addresses section) Any other information the author deems interesting: o This Enumservice indicates that the person responsible for the NAPTR is accessible via the PSTN (Public Switched Telephone Network) or PLMN (Public Land Mobile Network) using the value of the generated URI. o The kind of subsystem required to initiate a Voice Enumservice with this sub-type is a "Dialler". This is a subsystem that either provides a local connection to the PSTN or PLMN, or that provides an indirect connection to those networks. The
subsystem will use the telephone number held in the generated URI to place a voice call. The voice call is placed to a network that uses E.164 numbers to route calls to an appropriate destination. o Note that the PSTN/PLMN connection may be indirect. The end user receiving this NAPTR may have a relationship with a Communications Service Provider that accepts call initiation requests from that subsystem using an IP-based protocol such as SIP or H.323, and places the call to the PSTN using a remote gateway service. In this case the Provider may either accept requests using "tel:" URIs or has a defined mechanism to convert "tel:" URI values into a "protocol-native" form. o The "tel:" URI value SHOULD be fully qualified (using the "global phone number" form of RFC3966 [10]). A "local phone number" as defined in that document SHOULD NOT be used unless the controller of the zone in which the NAPTR appears is sure that it can be distinguished unambiguously by all clients that can access the resource record and that a call from their network access points can be routed to that destination.
Enumservice Name: "pstn" Enumservice Type: "pstn" Enumservice Subtype: "tel" URI Scheme: 'tel:' Functional Specification: These Enumservices indicate that the remote resource identified can be addressed by the associated URI scheme in order to initiate a telecommunication session, which may include two-way voice or other communications, to the PSTN. These URIs may contain number portability data as specified in RFC 4694 [10]. Security Considerations: See Section 7 of RFC4769. Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Richard Shockey (richard.shockey&neustar.biz) Any other information the author deems interesting: A Number Portability Dip Indicator (npdi) should be used in practice (see examples below in Section 4 of RFC4769).
Enumservice Name: "pstn" Enumservice Type: "pstn" Enumservice Subtype: "sip" URI Scheme: 'sip:' Functional Specification: These Enumservices indicate that the remote resource identified can be addressed by the associated URI scheme in order to initiate a telecommunication session, which may include two-way voice or other communications, to the PSTN. Security Considerations: See Section 7 of RFC4769. Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Richard Shockey (richard.shockey&neustar.biz) Any other information the author deems interesting: A Number Portability Dip Indicator (npdi) should be used in practice (see examples below in Section 4 of RFC4769).
Enumservice Name: "vCard" Enumservice Name: "vCard" Enumservice Type: "vcard" Enumservice Subtype: n/a URI Schemes: "http", "https" Functional Specification: This Enumservice indicates that the resource identified is a plain vCard, according to RFC 2426, which may be accessed using HTTP/ HTTPS [7]. Clients fetching the vCard from the resource indicated should expect access to be restricted. Additionally, the comprehension of the data provided may vary depending on the client's identity. Security Considerations: see Section 5 RFC4969 Intended Usage: COMMON Author: Alexander Mayrhofer <alexander.mayrhofer&enum.at>
Enumservice Name: "XMPP" Enumservice Type: "xmpp" Enumservice Subtype: n/a URI Schemes: "xmpp" Functional Specification: This Enumservice indicates that the resource identified is an XMPP entity. Security Considerations: see Section 6 of RFC4979 Intended Usage: COMMON Author: Alexander Mayrhofer <alexander.mayrhofer&enum.at>
Enumservice Name: "im" Enumservice Type: "im" Enumservice Subtypes: N/A URI scheme(s): "im:" Functional Specification: This Enumservice indicates that the resource identified is an 'im:' URI. The 'im:' URI scheme does not identify any particular protocol that will be used to handle instant messaging receipt or delivery, rather the mechanism in RFC 3861 [4] is used to discover whether an IM protocol supported by the party querying ENUM is also supported by the target resource. Security considerations: See section 3 of RFC5028 Intended usage: COMMON Author: Rohan Mahy (rohan&ekabal.com)
Enumservice Name: "voicemsg" Enumservice Type: "voicemsg" Enumservice Subtypes: "sip" URI Schemes: 'sip:' Functional Specification: This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "voicemsg" Enumservice Type: "voicemsg" Enumservice Subtypes: "sips" URI Schemes: 'sips:' Functional Specification: This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com)
Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "voicemsg" Enumservice Type: "voicemsg" Enumservice Subtype: "tel" URI Schemes: 'tel:' Functional Specification: This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a voice communication session to a voice messaging system. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "voicemsg" Enumservice Type: "voicemsg" Enumservice Subtype: "http" URI Schemes: 'http:' Functional Specification: This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information. Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even voice message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "voicemsg" Enumservice Type: "voicemsg" Enumservice Subtype: "https" URI Schemes: 'https:' Functional Specification: This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol. Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even voice message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "videomsg" Enumservice Type: "videomsg" Enumservice Subtypes: "sip" URI Schemes: 'sip:' Functional Specification: This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a video communication session to a video messaging system. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "videomsg" Enumservice Type: "videomsg" Enumservice Subtypes: "sips" URI Schemes: 'sips:' Functional Specification: This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a video communication session to a video messaging system. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "videomsg" Enumservice Type: "videomsg" Enumservice Subtype: "http" URI Schemes: 'http:' Functional Specification: This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information. Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "videomsg" Enumservice Type: "videomsg" Enumservice Subtype: "https" URI Schemes: 'https:' Functional Specification: This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol. Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "unifmsg" Enumservice Type: "unifmsg" Enumservice Subtypes: "sip" URI Schemes: 'sip:' Functional Specification: This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a unified communication session to a unified messaging system. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "unifmsg" Enumservice Type: "unifmsg" Enumservice Subtypes: "sips" URI Schemes: 'sips:' Functional Specification: This Enumservice indicates that the remote resource identified can be addressed by the associated URI scheme in order to initiate a unified communication session to a unified messaging system. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "unifmsg" Enumservice Type: "unifmsg" Enumservice Subtype: "http" URI Schemes: 'http:' Functional Specification: This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information. Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "unifmsg" Enumservice Type: "unifmsg" Enumservice Subtype: "https" URI Schemes: 'https:' Functional Specification: This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information, which can be contacted using TLS or the Secure Socket Layer protocol. Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'https:' [12] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. Security Considerations: See Section 3 of RFC5278 Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of RFC5278
Enumservice Name: "ical-sched" Enumservice Type: "ical-sched" Enumservice Subtypes: "mailto" URI scheme(s): 'mailto:' Functional Specification: This Enumservice indicates that the resource identified can be addressed by the associated URI used for scheduling using Internet calendaring via Internet mail with the iMIP [6] protocol. Security considerations: See Section 4 of RFC5333. Intended usage: COMMON Author: Rohan Mahy (rohan&ekabal.com)
Enumservice Name: "ical-access" Enumservice Type: "ical-access" Enumservice Subtypes: "http" URI scheme(s): 'http:' Functional Specification: This Enumservice indicates that the resource identified can be addressed by the associated URI in order to access a user's calendar (for example free/busy status) using the CalDAV [7] protocol for Internet calendaring. Security considerations: See Section 4 of RFC5333. Intended usage: COMMON Author: Rohan Mahy (rohan&ekabal.com)
Enumservice Name: "ical-access" Enumservice Type: "ical-access" Enumservice Subtypes: "https" URI scheme(s): 'https:' Functional Specification: This Enumservice indicates that the resource identified can be addressed by the associated URI in order to access a user's calendar (for example free/busy status) using the CalDAV [7] protocol for Internet calendaring. Security considerations: See Section 4 of RFC5333. Intended usage: COMMON Author: Rohan Mahy (rohan&ekabal.com)
Authors' Addresses
Bernie Hoeneisen Ucom Standards Track Solutions GmbH CH-8000 Zuerich Switzerland
Phone: +41 44 500 52 44 EMail: [email protected] (bernhard.hoeneisen AT ucom.ch) URI: http://www.ucom.ch/
Alexander Mayrhofer enum.at GmbH Karlsplatz 1/9 Wien A-1010 Austria
Phone: +43 1 5056416 34 EMail: [email protected] URI: http://www.enum.at/