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
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
更新Enumservices的旧IANA注册
Abstract
摘要
This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761.
本文档修订了IANA根据RFC 3761中定义的Enumservice注册表现已过时的规范注册的所有Enumservices。
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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IESG Action . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Legacy Enumservice Registrations Converted to XML Chunks . . . 5
4.1. email:mailto . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. ems:mailto . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. ems:tel . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. fax:tel . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. ft:ftp . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. h323 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. ical-access:http . . . . . . . . . . . . . . . . . . . . . 12
4.8. ical-access:https . . . . . . . . . . . . . . . . . . . . 13
4.9. ical-sched:mailto . . . . . . . . . . . . . . . . . . . . 14
4.10. ifax:mailto . . . . . . . . . . . . . . . . . . . . . . . 15
4.11. im . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.12. mms:mailto . . . . . . . . . . . . . . . . . . . . . . . . 17
4.13. mms:tel . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.14. pres . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.15. pstn:sip . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.16. pstn:tel . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.17. sip . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.18. sms:mailto . . . . . . . . . . . . . . . . . . . . . . . . 24
4.19. sms:tel . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.20. unifmsg:http . . . . . . . . . . . . . . . . . . . . . . . 26
4.21. unifmsg:https . . . . . . . . . . . . . . . . . . . . . . 27
4.22. unifmsg:sip . . . . . . . . . . . . . . . . . . . . . . . 28
4.23. unifmsg:sips . . . . . . . . . . . . . . . . . . . . . . . 29
4.24. vcard . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.25. videomsg:http . . . . . . . . . . . . . . . . . . . . . . 31
4.26. videomsg:https . . . . . . . . . . . . . . . . . . . . . . 32
4.27. videomsg:sip . . . . . . . . . . . . . . . . . . . . . . . 33
4.28. videomsg:sips . . . . . . . . . . . . . . . . . . . . . . 34
4.29. voice:tel . . . . . . . . . . . . . . . . . . . . . . . . 35
4.30. voicemsg:http . . . . . . . . . . . . . . . . . . . . . . 37
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IESG Action . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Legacy Enumservice Registrations Converted to XML Chunks . . . 5
4.1. email:mailto . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. ems:mailto . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. ems:tel . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. fax:tel . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5. ft:ftp . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.6. h323 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. ical-access:http . . . . . . . . . . . . . . . . . . . . . 12
4.8. ical-access:https . . . . . . . . . . . . . . . . . . . . 13
4.9. ical-sched:mailto . . . . . . . . . . . . . . . . . . . . 14
4.10. ifax:mailto . . . . . . . . . . . . . . . . . . . . . . . 15
4.11. im . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.12. mms:mailto . . . . . . . . . . . . . . . . . . . . . . . . 17
4.13. mms:tel . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.14. pres . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.15. pstn:sip . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.16. pstn:tel . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.17. sip . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.18. sms:mailto . . . . . . . . . . . . . . . . . . . . . . . . 24
4.19. sms:tel . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.20. unifmsg:http . . . . . . . . . . . . . . . . . . . . . . . 26
4.21. unifmsg:https . . . . . . . . . . . . . . . . . . . . . . 27
4.22. unifmsg:sip . . . . . . . . . . . . . . . . . . . . . . . 28
4.23. unifmsg:sips . . . . . . . . . . . . . . . . . . . . . . . 29
4.24. vcard . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.25. videomsg:http . . . . . . . . . . . . . . . . . . . . . . 31
4.26. videomsg:https . . . . . . . . . . . . . . . . . . . . . . 32
4.27. videomsg:sip . . . . . . . . . . . . . . . . . . . . . . . 33
4.28. videomsg:sips . . . . . . . . . . . . . . . . . . . . . . 34
4.29. voice:tel . . . . . . . . . . . . . . . . . . . . . . . . 35
4.30. voicemsg:http . . . . . . . . . . . . . . . . . . . . . . 37
4.31. voicemsg:https . . . . . . . . . . . . . . . . . . . . . . 38
4.32. voicemsg:sip . . . . . . . . . . . . . . . . . . . . . . . 39
4.33. voicemsg:sips . . . . . . . . . . . . . . . . . . . . . . 40
4.34. voicemsg:tel . . . . . . . . . . . . . . . . . . . . . . . 41
4.35. vpim:ldap . . . . . . . . . . . . . . . . . . . . . . . . 42
4.36. vpim:mailto . . . . . . . . . . . . . . . . . . . . . . . 43
4.37. web:http . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.38. web:https . . . . . . . . . . . . . . . . . . . . . . . . 46
4.39. xmpp . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
6. Security Considerations . . . . . . . . . . . . . . . . . . . 47
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.1. Normative References . . . . . . . . . . . . . . . . . . . 48
8.2. Informative References . . . . . . . . . . . . . . . . . . 49
Appendix A. Former Content of the IANA Repository . . . . . . . . 49
4.31. voicemsg:https . . . . . . . . . . . . . . . . . . . . . . 38
4.32. voicemsg:sip . . . . . . . . . . . . . . . . . . . . . . . 39
4.33. voicemsg:sips . . . . . . . . . . . . . . . . . . . . . . 40
4.34. voicemsg:tel . . . . . . . . . . . . . . . . . . . . . . . 41
4.35. vpim:ldap . . . . . . . . . . . . . . . . . . . . . . . . 42
4.36. vpim:mailto . . . . . . . . . . . . . . . . . . . . . . . 43
4.37. web:http . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.38. web:https . . . . . . . . . . . . . . . . . . . . . . . . 46
4.39. xmpp . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
6. Security Considerations . . . . . . . . . . . . . . . . . . . 47
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.1. Normative References . . . . . . . . . . . . . . . . . . . 48
8.2. Informative References . . . . . . . . . . . . . . . . . . 49
Appendix A. Former Content of the IANA Repository . . . . . . . . 49
[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.
[RFC6117]已淘汰[RFC3761]的IANA注册部分。由于IANA Enumservice注册表包含根据RFC 3761制度注册的各种Enumservices，因此这些注册不符合[RFC6117]中规定的新指南。为了确保IANA上所有Enumservice注册之间的一致性，本文档将（现在）缺失的元素添加到这些遗留注册中。此外，所有遗留Enumservice注册都转换为新的XML块格式，并且在认为必要时，应用少量编辑更正。
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.
但是，本文档仅将[RFC6117]的IANA注意事项部分中指定的缺少的元素添加到XML块中，但没有完成相应Enumservice规范中（现在）缺少的部分。为了符合[RFC6117]中规定的新注册制度，这些服务规范仍需修订。
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:
本文件更新了以下RFC：
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]
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]
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
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.
根据[RFC3761]，任何Enumservice注册都必须作为标准跟踪、实验或BCP（最佳当前实践）RFC发布。[RFC6117]不再有此要求，即“需要规范”，这意味着使用指定专家[RFC5226]就足够了。
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].
本文件将Enumservice注册更新的批准要求更改为所需规范，由[RFC6117]中所述的指定专家审查规范和请求。
In the following, the legacy Enumservice Registrations are converted to XML chunks that include the new elements introduced by [RFC6117].
在下文中，旧版Enumservice注册被转换为XML块，其中包括[RFC6117]引入的新元素。
(Note that references in Sections 4.1 - 4.39 refer to the references section within the respective Enumservice Specification.)
（请注意，第4.1节至第4.39节中的参考资料是指相应Enumservice规范中的参考资料部分。）
<record>
<!-- email:mailto -->
<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"/>
<record>
<!-- email:mailto -->
<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>
</requesters>
</record>
<record>
<!-- ems:mailto -->
<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>
<record>
<!-- ems:mailto -->
<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>
<record>
<!-- ems:tel -->
<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>
<record>
<!-- ems:tel -->
<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>
<record>
<!-- fax:tel -->
<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>
<record>
<!-- fax:tel -->
<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>
<record>
<!-- ft:ftp -->
<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>
<record>
<!-- ft:ftp -->
<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>
<record>
<!-- h323 -->
<class>Protocol-Based</class>
<type>h323</type>
<!-- No subtype -->
<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>
<record>
<!-- h323 -->
<class>Protocol-Based</class>
<type>h323</type>
<!-- No subtype -->
<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>
<record>
<!-- ical-access:http -->
<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>
<record>
<!-- ical-access:http -->
<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>
<record>
<!-- ical-access:https -->
<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>
<record>
<!-- ical-access:https -->
<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>
<record>
<!-- ical-sched:mailto -->
<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>
<record>
<!-- ical-sched:mailto -->
<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>
<record>
<!-- ifax:mailto -->
<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>
<record>
<!-- ifax:mailto -->
<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>
<record>
<!-- im -->
<class>Application-Based, Common</class>
<type>im</type>
<!-- No subtype -->
<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>
<record>
<!-- im -->
<class>Application-Based, Common</class>
<type>im</type>
<!-- No subtype -->
<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>
<record>
<!-- mms:mailto -->
<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>
<record>
<!-- mms:mailto -->
<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>
<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>
<record>
<!-- mms:tel -->
<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
<record>
<!-- mms:tel -->
<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>
be tariff differences in using the MMS rather than
using the SMS or EMS.
</paragraph>
</additionalinfo>
</record>
<record>
<!-- pres -->
<class>Application-Based, Common</class>
<type>pres</type>
<!-- No subtype -->
<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>
<record>
<!-- pres -->
<class>Application-Based, Common</class>
<type>pres</type>
<!-- No subtype -->
<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>
<record>
<!-- pstn:sip -->
<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>
<record>
<!-- pstn:sip -->
<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>
<record>
<!-- pstn:tel -->
<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>
<record>
<!-- pstn:tel -->
<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>
<record>
<!-- sip -->
<class>Protocol-Based</class>
<type>sip</type>
<!-- No subtype -->
<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>
<record>
<!-- sip -->
<class>Protocol-Based</class>
<type>sip</type>
<!-- No subtype -->
<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>
<record>
<!-- sms:mailto -->
<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>
<record>
<!-- sms:mailto -->
<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>
<record>
<!-- sms:tel -->
<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>
<record>
<!-- sms:tel -->
<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>
<record>
<!-- unifmsg:http -->
<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>
<record>
<!-- unifmsg:http -->
<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>
<record>
<!-- unifmsg:https -->
<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>
<record>
<!-- unifmsg:https -->
<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>
<record>
<!-- unifmsg:sip -->
<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>
<record>
<!-- unifmsg:sip -->
<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>
<record>
<!-- unifmsg:sips -->
<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>
<record>
<!-- unifmsg:sips -->
<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>
<record>
<!-- vcard -->
<class>Data Type-Based</class>
<type>vcard</type>
<!-- No subtype -->
<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>
<record>
<!-- vcard -->
<class>Data Type-Based</class>
<type>vcard</type>
<!-- No subtype -->
<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>
<record>
<!-- videomsg:http -->
<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>
<record>
<!-- videomsg:http -->
<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>
<record>
<!-- videomsg:https -->
<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>
<record>
<!-- videomsg:https -->
<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>
<record>
<!-- videomsg:sip -->
<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>
<record>
<!-- videomsg:sip -->
<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>
<record>
<!-- videomsg:sips -->
<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>
<record>
<!-- videomsg:sips -->
<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>
<record>
<!-- voice:tel -->
<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
<record>
<!-- voice:tel -->
<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>
连接到PSTN或PLMN，或提供到这些网络的间接连接。子系统将使用生成的URI中保留的电话号码进行语音呼叫。语音呼叫被置于使用E.164号码将呼叫路由到适当目的地的网络上</段落><段落>注意，PSTN/PLMN连接可能是间接的。接收该NAPTR的最终用户可以与通信服务提供商有关系，该通信服务提供商使用基于IP的协议（例如SIP或H.323）接受来自该子系统的呼叫发起请求，并使用远程网关服务将呼叫放置到PSTN。在这种情况下，提供者可以使用“tel:”URI接受请求，或者具有将“tel:”URI值转换为“协议本机”形式的定义机制</段落><段落>应完全限定“tel:”URI值（使用RFC 3966[10]的“全局电话号码”形式）。不应使用该文件中定义的“本地电话号码”，除非NAPTR所在区域的控制器确保所有可以访问资源记录的客户端都可以明确区分该号码，并且可以将来自其网络接入点的呼叫路由到该目的地</段落><段落>引用包含在<xref type=“rfc”data=“rfc4415”/>中</段落></additionalinfo></record>
<record>
<!-- voicemsg:http -->
<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>
<record>
<!-- voicemsg:http -->
<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>
<record>
<!-- voicemsg:https -->
<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>
<record>
<!-- voicemsg:https -->
<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>
<record>
<!-- voicemsg:sip -->
<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>
<record>
<!-- voicemsg:sip -->
<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>
<record>
<!-- voicemsg:sips -->
<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>
<record>
<!-- voicemsg:sips -->
<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>
<record>
<!-- voicemsg:tel -->
<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>
<record>
<!-- voicemsg:tel -->
<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>
<record>
<!-- vpim:ldap -->
<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>
<record>
<!-- vpim:ldap -->
<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>
<record>
<!-- vpim:mailto -->
<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>
<record>
<!-- vpim:mailto -->
<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>
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>
<record>
<!-- web:http -->
<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>
<record>
<!-- web:http -->
<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>
<record>
<!-- web:https -->
<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>
<record>
<!-- web:https -->
<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>
<record>
<!-- xmpp -->
<class>Protocol-Based</class>
<type>xmpp</type>
<!-- No subtype -->
<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>
<record>
<!-- xmpp -->
<class>Protocol-Based</class>
<type>xmpp</type>
<!-- No subtype -->
<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 replaced all legacy Enumservice Registrations as per Section 4.
IANA根据第4节替换了所有遗留Enumservice注册。
Since this document does not introduce any technology or protocol, there are no security issues to be considered for this document itself.
由于本文件未介绍任何技术或协议，因此本文件本身不存在安全问题。
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.
作者要感谢为本文件的编制提供反馈或重大贡献的以下人员：Jari Arkko、Scott Bradner、Gonzalo Camarillo、Alfred Hoenes、Ari Keranen和Alexey Melnikov。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[RFC3761]Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[RFC3762] Levin, O., "Telephone Number Mapping (ENUM) Service Registration for H.323", RFC 3762, April 2004.
[RFC3762]Levin，O.，“H.323的电话号码映射（ENUM）服务注册”，RFC 3762，2004年4月。
[RFC3764] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
[RFC3764]Peterson，J.，“会话启动协议（SIP）记录地址的枚举服务注册”，RFC 3764，2004年4月。
[RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service Registration for Presence Services", RFC 3953, January 2005.
[RFC3953]Peterson，J.，“状态服务的电话号码映射（ENUM）服务注册”，RFC 3953，2005年1月。
[RFC4002] Brandner, R., Conroy, L., and R. Stastny, "IANA Registration for Enumservice 'web' and 'ft'", RFC 4002, February 2005.
[RFC4002]Brandner，R.，Conroy，L.，和R.Stastny，“Enumservice‘web’和‘ft’的IANA注册”，RFC 4002，2005年2月。
[RFC4143] Toyoda, K. and D. Crocker, "Facsimile Using Internet Mail (IFAX) Service of ENUM", RFC 4143, November 2005.
[RFC4143]丰田章男，K.和D.克罗克，“使用ENUM的互联网邮件（IFAX）服务进行传真”，RFC 41432005年11月。
[RFC4238] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, October 2005.
[RFC4238]Vaudreuil，G.“语音消息路由服务”，RFC 4238，2005年10月。
[RFC4355] Brandner, R., Conroy, L., and R. Stastny, "IANA Registration for Enumservices email, fax, mms, ems, and sms", RFC 4355, January 2006.
[RFC4355]Brandner，R.，Conroy，L.，和R.Stastny，“IANA注册电子邮件、传真、彩信、ems和短信服务”，RFC 43552006年1月。
[RFC4415] Brandner, R., Conroy, L., and R. Stastny, "IANA Registration for Enumservice Voice", RFC 4415, February 2006.
[RFC4415]Brandner，R.，Conroy，L.，和R.Stastny，“Enumservice Voice的IANA注册”，RFC 4415，2006年2月。
[RFC4769] Livingood, J. and R. Shockey, "IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information", RFC 4769, November 2006.
[RFC4769]Livingood，J.和R.Shockey，“包含公共交换电话网（PSTN）信令信息的Enumservice的IANA注册”，RFC 4769，2006年11月。
[RFC4969] Mayrhofer, A., "IANA Registration for vCard Enumservice", RFC 4969, August 2007.
[RFC4969]Mayrhofer，A.，“vCard Enumservice的IANA注册”，RFC 4969，2007年8月。
[RFC4979] Mayrhofer, A., "IANA Registration for Enumservice 'XMPP'", RFC 4979, August 2007.
[RFC4979]Mayrhofer，A.，“枚举服务'XMPP'的IANA注册”，RFC 4979，2007年8月。
[RFC5028] Mahy, R., "A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services", RFC 5028, October 2007.
[RFC5028]Mahy，R.“即时消息（IM）服务的电话号码映射（ENUM）服务注册”，RFC 5028，2007年10月。
[RFC5278] Livingood, J. and D. Troshynski, "IANA Registration of Enumservices for Voice and Video Messaging", RFC 5278, July 2008.
[RFC5278]Livingood，J.和D.Troshynski，“语音和视频信息服务的IANA注册”，RFC 5278，2008年7月。
[RFC5333] Mahy, R. and B. Hoeneisen, "IANA Registration of Enumservices for Internet Calendaring", RFC 5333, October 2009.
[RFC5333]Mahy，R.和B.Hoeneisen，“互联网日历服务的IANA注册”，RFC 53332009年10月。
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations", RFC 6117, March 2011.
[RFC6117]Hoenesen，B.，Mayrhofer，A.，和J.Livingood，“Enumservices的IANA注册：指南，模板和IANA注意事项”，RFC 61172011年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Enumservice Registrations
枚举服务注册
(last updated 2009-10-13)
（最后更新日期：2009-10-13）
Registries included below: - Enumservice Registrations
包括以下注册表：-枚举服务注册
Registry Name: Enumservice Registrations Reference: [RFC3761] Registration Procedures: Require an RFC approved by the IESG
注册表名称：Enumservice注册参考：[RFC3761]注册过程：需要IESG批准的RFC
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.
注意：Enumservice规范包含功能规范（即它可以用于什么）、有效协议和可能返回的URI方案。
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]
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: "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: "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: "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]
服务名称：“web”类型：“web”子类型：“http”URI方案：“http:”功能规范：此ENUMservice表示关联URI方案标识的资源能够作为信息源。必须注意的是，检索到的信息可能是多种多样的。通常，通过“http:”URI联系资源会提供一个文档。此文档可以包含引用，这些引用将触发许多不同类型信息的下载，如音频、视频或可执行代码。因此，在联系资源时，不能更具体地说明可以预期的信息类型。安全注意事项：见[RFC4002]第5节。预期用途：常见作者：Rudolf Brandner（Rudolf.Brandner&siemens.com）Lawrence Conroy（lwc&roke.co.uk）Richard Stastny（Richard.Stastny&oefeg.at）作者认为有趣的任何其他信息：无[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]
服务名称：“web”类型：“web”子类型：“https”URI方案：“https:”功能规范：此ENUMservice表示由关联URI方案标识的资源能够作为信息源，可以使用TLS或安全套接字层协议与之联系。必须注意的是，检索到的信息可能是多种多样的。通常，通过“https:”URI联系资源会提供一个文档。此文档可以包含所有不同类型的信息，如音频、视频或可执行代码。因此，在联系资源时，我们无法更具体地了解所期望的信息。安全注意事项：见[RFC4002]第5节。预期用途：常见作者：Rudolf Brandner（Rudolf.Brandner&siemens.com）Lawrence Conroy（lwc&roke.co.uk）Richard Stastny（Richard.Stastny&oefeg.at）作者认为有趣的任何其他信息：无[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]
服务名称：“ft”类型：“ft”子类型：“ftp”URI方案：“ftp:”功能规范：此ENUMservice表示由关联URI方案标识的资源是可以从中检索文件或文件列表的文件服务。安全注意事项：见[RFC4002]第5节。预期用途：常见作者：Rudolf Brandner（Rudolf.Brandner&siemens.com）Lawrence Conroy（lwc&roke.co.uk）Richard Stastny（Richard.Stastny&oefeg.at）作者认为有趣的任何其他信息：无[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名称：“email”Enumservice类型：“email”Enumservice子类型：“mailto”URI方案：“mailto:”功能规范：此Enumservice表示远程资源可以通过关联的URI方案寻址，以便发送电子邮件。安全注意事项：参见[RFC4355]第6节预期用途：普通作者：鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（作者联系方式参见[RFC4355]）作者认为有趣的任何其他信息：无
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名称：“fax”Enumservice类型：“fax”Enumservice子类型：“tel”URI方案：“tel:”功能规范：此Enumservice表示可以联系关联URI方案标识的资源，以提供通信会话，在此会话期间可以发送传真文档。选择此NAPTR的客户机将支持使用[RFC4355]中[12]和[13]中规定的PSTN会话和传输协议生成传真文件并将其发送给收件人。简言之，他们将拥有一个具有本地或共享PSTN访问的传真程序，可通过该程序发送传真。安全注意事项：参见[RFC4355]第6节预期用途：普通作者：鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（作者联系方式参见[RFC4355]）作者认为有趣的任何其他信息：无
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名称：“sms”Enumservice类型：“sms”Enumservice子类型：“tel”URI方案：“tel:”功能规范：此Enumservice表示由关联URI方案标识的资源能够使用[RFC4355]中的短消息服务（sms）[14]接收消息。安全注意事项：此Enumservice没有特定的安全问题。但是，第6节的一般考虑因素适用。预期用途：常见作者：鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（作者联系方式见[RFC4355]）作者认为有趣的任何其他信息：无
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名称：“sms”Enumservice类型：“sms”Enumservice子类型：“mailto”URI方案：“mailto:”功能规范：此Enumservice表示由关联URI方案标识的资源能够使用电子邮件协议接收消息。SMS内容通过SMTP发送，使用TS 23.140[15]第8.4.4节和TS 26.140[16]第4节规定的格式（参考文献请参见[RFC4355]）作为彩信。在这样的消息中，SMS内容以文本或应用程序/八位字节流MIME子部分的形式承载（参见TS 26.140[16]，第4.1节），参考文献参见[RFC4355]。安全注意事项：此Enumservice没有特定的安全问题。但是，第6节的一般考虑因素适用，见[RFC4355]。预期用途：常见作者：鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（作者联系方式见[RFC4355]）作者认为有趣的任何其他信息：无
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名称：“ems”Enumservice类型：“ems”Enumservice子类型：“tel”URI方案：“tel:”功能规范：此Enumservice表示由关联URI方案标识的资源能够使用增强型消息服务（ems）[14]接收消息（参考请参阅[RFC4355]）。安全注意事项：此Enumservice没有特定的安全问题。但是，第6节的一般考虑因素适用。参见[RFC4355]预期用途：普通作者：鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（作者联系方式参见[RFC4355]）作者认为有趣的任何其他信息：注意，EMS的指示可被视为暗示接收者也能在该地址接收SMS消息。
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名称：“ems”Enumservice类型：“ems”Enumservice子类型：“mailto”URI方案：“mailto:”功能规范：此Enumservice表示由关联URI方案标识的资源能够使用电子邮件协议接收消息。EMS内容使用TS 23.140[15]第8.4.4节和TS 26.140[16]第4节规定的格式通过SMTP以彩信的形式发送。在这样的消息中，EMS内容以文本或应用程序/八位字节流MIME子部分的形式携带（见TS 26.140[16]，第4.1节）。有关参考信息，请参阅[RFC4355]安全注意事项：此Enumservice没有特定的安全问题。但是，[RFC4355]第6节的一般考虑因素适用。预期用途：常见作者：鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（作者联系方式见[RFC4355]）作者认为有趣的任何其他信息：无
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名称：“mms”Enumservice类型：“mms”Enumservice子类型：“tel”URI方案：“tel:”功能规范：此Enumservice表示由关联URI方案标识的资源能够使用彩信服务（mms）接收消息[15]。有关参考信息，请参阅[RFC4355]安全注意事项：此Enumservice没有特定的安全问题。但是，[RFC4355]第6节的一般考虑因素适用。预期用途：常见作者：Rudolf Brandner、Lawrence Conroy、Richard Stastny（有关作者联系方式，请参见[RFC4355]）作者认为有趣的任何其他信息：请注意，如果不支持SMS承载，MMS可作为交付SMS RP-DATA RPDU的替代方案。如果条目包含此Enumservice，则实际上可以认为这意味着收件人能够在此地址接收EMS或SMS消息。在终端系统设计上的这种选择确实有两个小警告；虽然在实践中，目前支持彩信的所有终端都支持SMS，但将来可能不一定如此，而且使用彩信而不是使用SMS或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]
Enumservice名称：“mms”Enumservice类型：“mms”Enumservice子类型：“mailto”URI方案：“mailto:”功能规范：此Enumservice表示由关联URI方案标识的资源能够使用电子邮件协议接收消息。彩信使用TS 23.140[15]第8.4.4节和TS 26.140[16]第4节规定的格式通过SMTP发送。在MMS环境（MMSE，支持多媒体服务的网络基础设施）内部和之间，其他状态数据（例如，重要信息的收费）在MMS中继服务器之间交换。因此，尽管这些服务器使用SMTP作为其应用程序交换的“承载者”，但它们将其内部状态映射到SMTP消息交换中携带的专用头。[17]中详细描述了此类MMSE中使用的报头。参考资料参见[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.
安全注意事项：此Enumservice没有特定的安全问题。但是，[RFC4355]第6节的一般考虑因素适用。预期用途：常见作者：Rudolf Brandner、Lawrence Conroy、Richard Stastny（有关作者联系方式，请参见[RFC4355]）作者认为有趣的任何其他信息：MMS体系结构描述了MMSE和接受“标准”SMTP消息的“传统消息传递系统”（标记为MM3）之间的接口。因此，尽管从基于Internet的邮件服务器的角度来看，支持此接口的MMS中继服务器显示为标准SMTP服务器，但它充当网关和转换器，添加MMS环境内部和之间使用的内部状态数据。[17]中描述了该机制，其中还包括对负责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 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.
服务名称：E.164至VPIM LDAP URL URI类型：“LDAP:”类型：VPIM子类型：LDAP功能规范：参见[RFC4238]第3.2节至第3.3节预期用途：常见作者：Greg Vaudreuil（gregv&ieee.org）安全注意事项：o恶意重定向与任何服务相关的一个基本危险是，解析程序数据库中的恶意条目将导致客户端将E.164解析为错误的LDAP URL。可能的目的是使客户机连接到恶意LDAP服务器并检索（或无法检索）包含欺诈或破坏性信息的资源。o拒绝服务通过删除E.164映射到的URL，恶意入侵者可能会删除客户端访问LDAP目录服务器的能力。
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
Enumservice名称：“voice”Enumservice类型：“voice”Enumservice子类型：“tel”URI方案：“tel:”功能规范：此Enumservice指示的通信类型为“交互式语音”。从协议的角度来看，该通信预期涉及承载音频数据的双向媒体流。客户机可能暗示，控制持有此服务的NAPTR人口的人员在使用此NAPTR生成的URI进行联系时指示其参与交互式语音会话的能力。安全注意事项：参见[RFC4415]第5节预期用途：普通作者：鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（作者联系方式见作者地址部分）作者认为有趣的任何其他信息：o此Enumservice表示负责NAPTR的人员可通过PSTN访问（公共交换电话网络）或PLMN（公共陆地移动网络），使用生成的URI值。o使用此子类型启动语音服务所需的子系统类型为“拨号器”。这是一个子系统，提供到PSTN或PLMN的本地连接，或提供到这些网络的间接连接
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.
子系统将使用生成的URI中的电话号码进行语音呼叫。语音呼叫被置于使用E.164号码将呼叫路由到适当目的地的网络上。o注意，PSTN/PLMN连接可能是间接的。接收该NAPTR的最终用户可以与通信服务提供商有关系，该通信服务提供商使用基于IP的协议（例如SIP或H.323）接受来自该子系统的呼叫发起请求，并使用远程网关服务将呼叫放置到PSTN。在这种情况下，提供程序可以使用“tel:”URI接受请求，或者使用定义的机制将“tel:”URI值转换为“协议本机”形式。o“tel:”URI值应完全限定（使用RFC3966[10]的“全局电话号码”表）。不应使用该文件中定义的“本地电话号码”，除非NAPTR所在区域的控制器确保所有可以访问资源记录的客户端都可以明确区分该号码，并且可以将来自其网络接入点的呼叫路由到该目的地。
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名称：“pstn”Enumservice类型：“pstn”Enumservice子类型：“tel”URI方案：“tel:”功能规范：这些Enumservices表示标识的远程资源可以通过关联的URI方案寻址，以便启动电信会话，其中可能包括双向语音或其他通信，到PSTN。这些URI可能包含RFC 4694[10]中规定的号码可移植性数据。安全注意事项：见[RFC4769]第7节。预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.comcast.com）Richard Shockey（Richard.Shockey&neustar.biz）作者认为有趣的任何其他信息：在实践中应使用数字可携性倾角指示器（npdi）（见下文[RFC4769]第4节中的示例）。
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名称：“pstn”Enumservice类型：“pstn”Enumservice子类型：“sip”URI方案：“sip:”功能规范：这些Enumservices表示可以通过关联的URI方案寻址标识的远程资源，以便启动电信会话，其中可能包括双向语音或其他通信，到PSTN。安全注意事项：见[RFC4769]第7节。预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.comcast.com）Richard Shockey（Richard.Shockey&neustar.biz）作者认为有趣的任何其他信息：在实践中应使用数字可携性倾角指示器（npdi）（见下文[RFC4769]第4节中的示例）。
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名称：“vCard”Enumservice名称：“vCard”Enumservice类型：“vCard”Enumservice子类型：不适用URI方案：“http”、“https”功能规范：根据RFC 2426，此Enumservice表示标识的资源是普通vCard，可使用http/https访问[7]。从指定的资源获取vCard的客户端应期望访问受到限制。此外，对所提供数据的理解可能因客户身份而异。安全注意事项：参见第5节[RFC4969]预期用途：常见作者：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名称：“XMPP”Enumservice类型：“XMPP”Enumservice子类型：不适用URI方案：“XMPP”功能规范：此Enumservice表示标识的资源是XMPP实体。安全注意事项：参见[RFC4979]第6节预期用途：常见作者：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名称：“im”Enumservice类型：“im”Enumservice子类型：不适用URI方案：“im:”功能规范：此Enumservice表示标识的资源是“im:”URI。“im:”URI方案没有标识任何将用于处理即时消息接收或传递的特定协议，而是使用RFC 3861[4]中的机制来发现目标资源是否也支持查询枚举的参与方支持的im协议。安全注意事项：参见[RFC5028]第3节预期用途：共同作者：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名称：“voicemsg”Enumservice类型：“voicemsg”Enumservice子类型：“sip”URI方案：“sip:”功能规范：此Enumservice表示标识的远程资源可以由关联的URI方案寻址，以便启动到语音消息传递系统的语音通信会话。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.com）Don Troshynski（dtroshynski&acmepacket.com）作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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)
Enumservice名称：“voicemsg”Enumservice类型：“voicemsg”Enumservice子类型：“sips”URI方案：“sips:”功能规范：此Enumservice表示标识的远程资源可以由关联的URI方案寻址，以便启动到语音消息传递系统的语音通信会话。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：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]
作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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名称：“voicemsg”Enumservice类型：“voicemsg”Enumservice子类型：“tel”URI方案：“tel:”功能规范：此Enumservice表示标识的远程资源可以由关联的URI方案寻址，以便启动到语音消息传递系统的语音通信会话。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.com）Don Troshynski（dtroshynski&acmepacket.com）作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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名称：“voicemsg”Enumservice类型：“voicemsg”Enumservice子类型：“http”URI方案：“http:”功能规范：此Enumservice表示由关联URI方案标识的远程资源能够作为信息源。请注意，检索到的信息可能是多种多样的。通常，通过“http:”[11]URI联系资源会提供一个文档。此文档可以包含引用，这些引用将触发许多不同类型信息的下载，例如文本、音频、视频、可执行代码，甚至语音消息文件。因此，在联系资源时，不能更具体地说明所期望的信息类型。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.com）Don Troshynski（dtroshynski&acmepacket.com）作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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名称：“voicemsg”Enumservice类型：“voicemsg”Enumservice子类型：“https”URI方案：“https:”功能规范：此Enumservice表示由关联的URI方案标识的远程资源能够作为信息源，可以使用TLS或安全套接字层协议与之联系。请注意，检索到的信息可能是多种多样的。通常，通过“https:”[12]URI联系资源会提供一个文档。此文档可以包含引用，这些引用将触发许多不同类型信息的下载，例如文本、音频、视频、可执行代码，甚至语音消息文件。因此，在联系资源时，不能更具体地说明所期望的信息类型。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.com）Don Troshynski（dtroshynski&acmepacket.com）作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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名称：“videomsg”Enumservice类型：“videomsg”Enumservice子类型：“sip”URI方案：“sip:”功能规范：此Enumservice表示标识的远程资源可以由关联的URI方案寻址，以便启动到视频消息传递系统的视频通信会话。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.com）Don Troshynski（dtroshynski&acmepacket.com）作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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名称：“videomsg”Enumservice类型：“videomsg”Enumservice子类型：“sips”URI方案：“sips:”功能规范：此Enumservice表示标识的远程资源可以通过关联的URI方案寻址，以便启动到视频消息传递系统的视频通信会话。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.com）Don Troshynski（dtroshynski&acmepacket.com）作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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名称：“videomsg”Enumservice类型：“videomsg”Enumservice子类型：“http”URI方案：“http:”功能规范：此Enumservice表示由关联URI方案标识的远程资源能够作为信息源。请注意，检索到的信息可能是多种多样的。通常，通过“http:”[11]URI联系资源会提供一个文档。此文档可以包含引用，这些引用将触发许多不同类型信息的下载，例如文本、音频、视频、可执行代码，甚至视频消息文件。因此，在联系资源时，不能更具体地说明所期望的信息类型。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.com）Don Troshynski（dtroshynski&acmepacket.com）作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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名称：“videomsg”Enumservice类型：“videomsg”Enumservice子类型：“https”URI方案：“https:”功能规范：此Enumservice表示由关联的URI方案标识的远程资源能够作为信息源，可以使用TLS或安全套接字层协议与之联系。请注意，检索到的信息可能是多种多样的。通常，通过“https:”[12]URI联系资源会提供一个文档。此文档可以包含引用，这些引用将触发许多不同类型信息的下载，例如文本、音频、视频、可执行代码，甚至视频消息文件。因此，在联系资源时，不能更具体地说明所期望的信息类型。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.com）Don Troshynski（dtroshynski&acmepacket.com）作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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名称：“unifmsg”Enumservice类型：“unifmsg”Enumservice子类型：“sip”URI方案：“sip:”功能规范：此Enumservice表示标识的远程资源可以由关联的URI方案寻址，以便启动到统一消息系统的统一通信会话。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.com）Don Troshynski（dtroshynski&acmepacket.com）作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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名称：“unifmsg”Enumservice类型：“unifmsg”Enumservice子类型：“sips”URI方案：“sips:”功能规范：此Enumservice表示标识的远程资源可以由关联的URI方案寻址，以便启动到统一消息系统的统一通信会话。安全注意事项：参见[RFC5278]的第3节预期用途：普通作者：Jason Livingood（Jason_Livingood&cable.com）作者认为有趣的任何其他信息：实施者应在[RFC5278]的第7节中查看以下非排他性示例列表
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名称：“unifmsg”Enumservice类型：“unifmsg”Enumservice子类型：“http”URI方案：“http:”功能规范：此Enumservice表示由关联URI方案标识的远程资源能够作为信息源。请注意，检索到的信息可能是多种多样的。通常，通过“http:”[11]URI联系资源会提供一个文档。此文档可以包含引用，这些引用将触发许多不同类型信息的下载，例如文本、音频、视频、可执行代码，甚至视频消息文件。因此，在联系资源时，不能更具体地说明所期望的信息类型。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.com）Don Troshynski（dtroshynski&acmepacket.com）作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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名称：“unifmsg”Enumservice类型：“unifmsg”Enumservice子类型：“https”URI方案：“https:”功能规范：此Enumservice表示由关联的URI方案标识的远程资源能够作为信息源，可以使用TLS或安全套接字层协议与之联系。请注意，检索到的信息可能是多种多样的。通常，通过“https:”[12]URI联系资源会提供一个文档。此文档可以包含引用，这些引用将触发许多不同类型信息的下载，例如文本、音频、视频、可执行代码，甚至视频消息文件。因此，在联系资源时，不能更具体地说明所期望的信息类型。安全注意事项：参见[RFC5278]第3节预期用途：常见作者：Jason Livingood（Jason_Livingood&cable.com）Don Troshynski（dtroshynski&acmepacket.com）作者认为有趣的任何其他信息：实施者应查看[RFC5278]第7节中的非排他性示例列表
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名称：“ical sched”Enumservice类型：“ical sched”Enumservice子类型：“mailto”URI方案：'mailto:'功能规范：此Enumservice表示标识的资源可以由用于通过iMIP[6]协议的Internet邮件使用Internet日历进行调度的关联URI寻址。安全注意事项：见[RFC5333]第4节。预期用途：共同作者：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名称：“ical access”Enumservice类型：“ical access”Enumservice子类型：“http”URI方案：“http:”功能规范：此Enumservice表示标识的资源可以通过关联的URI寻址，以便使用CalDAV访问用户的日历（例如忙/闲状态）[7]互联网日历协议。安全注意事项：见[RFC5333]第4节。预期用途：共同作者：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)
Enumservice名称：“ical access”Enumservice类型：“ical access”Enumservice子类型：“https”URI方案：“https:”功能规范：此Enumservice表示可以通过关联的URI寻址标识的资源，以便使用CalDAV访问用户的日历（例如忙/闲状态）[7]互联网日历协议。安全注意事项：见[RFC5333]第4节。预期用途：共同作者：Rohan Mahy（Rohan&ekabal.com）
Authors' Addresses
作者地址
Bernie Hoeneisen Ucom Standards Track Solutions GmbH CH-8000 Zuerich Switzerland
伯尼霍内森Ucom标准轨道解决方案有限公司CH-8000瑞士祖里希
Phone: +41 44 500 52 44
EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: http://www.ucom.ch/
Phone: +41 44 500 52 44
EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch)
URI: http://www.ucom.ch/
Alexander Mayrhofer enum.at GmbH Karlsplatz 1/9 Wien A-1010 Austria
Alexander Mayrhofer enum.at GmbH卡尔斯普拉茨1/9维也纳A-1010奥地利
Phone: +43 1 5056416 34
EMail: alexander.mayrhofer@enum.at
URI: http://www.enum.at/
Phone: +43 1 5056416 34
EMail: alexander.mayrhofer@enum.at
URI: http://www.enum.at/