Internet Engineering Task Force (IETF) B. Hoeneisen
Request for Comments: 6118 Ucom.ch
Updates: 3762, 3764, 3953, 4143, 4002, A. Mayrhofer
4238, 4355, 4415, 4769, 4969, enum.at
4979, 5028, 5278, 5333 March 2011
Category: Standards Track
ISSN: 2070-1721
Update of Legacy IANA Registrations of Enumservices
Abstract
抽象
This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761.
このドキュメントは、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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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]で指定された新たな登録制度に準拠するためには、それらのEnumservice仕様は、まだ改訂する必要があります。
It is important to note that this document does not update the functional specification of the concerned Enumservices.
この文書が関係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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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（最も良いCurrent Practice）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].
この文書では、[RFC6117]で説明したように仕様や要求が指定の専門家によって検討されていることにより、仕様が必要にEnumservice登録の更新の承認要件を変更します。
In the following, the legacy Enumservice Registrations are converted to XML chunks that include the new elements introduced by [RFC6117].
以下では、レガシーEnumservice登録は[RFC6117]によって導入された新たな要素を含むXMLチャンクに変換されます。
(Note that references in Sections 4.1 - 4.39 refer to the references section within the respective Enumservice Specification.)
（ - 4.39各Enumservice仕様内の参照セクションを参照のセクションで参照が4.1であることに注意してください。）
<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>
</リクエスタ> </記録>
<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>
<!-- 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>
<!-- 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: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>
<!-- 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>
<!-- 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タイプ= "人物" データ= "Rudolf_Brandner" /> <XREFタイプ= "人物" データ= "Lawrence_Conroy" /> <XREFタイプ= "人物" データ= "Richard_Stastny" /> </リクエスタ> <additionalinfo> <パラグラフ> MMSのアーキテクチャは、「標準」SMTPメッセージを受け付ける（MM3と表記）MMSEと「従来のメッセージングシステム」間のインタフェースを記述します。このインタフェースをサポートするMMSリレーサーバーは、インターネットベースのメールサーバの観点から、標準のSMTPサーバとして表示されているがこのように、それはMMS環境内との間で使用される内部状態データを追加して、ゲートウェイとトランスレータとして機能します。このメカニズムは、MMSの設計の責任者機関によって合意された仕様への参照を含む、[17]に記載されています。 </パラグラフ> <パラグラフ>参照は</ XREFタイプ= "RFC" データ= "rfc4355">に含まれています。 </パラグラフ> </ additionalinfo> </記録>
<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>
<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: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>
<!-- 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>
<!-- 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: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>
<!-- 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: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: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 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>
<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: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: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: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番号ではない番号計画で</パラグラフ> <パラグラフ> E.164番号計画の数字、ないURIは、その番号</パラグラフ> <パラグラフ>のために存在するE2U + VPIM：mailtoの電子メールアドレスどこのサービスが利用できません唯一の電話番号は、以前に知られていました。 </パラグラフ> </ additionalinfo> </記録>
<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>
<!-- 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.
ヤリArkko、スコット・ブラッドナー、ゴンサロ・カマリロ、アルフレッドHoenes、アリKeranen、とアレクセイ・メルニコフ：作者はこのドキュメントの開発にフィードバックや重要な貢献を提供している以下の方々に感謝したいと思います。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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、RFC 3761、2004年4月 "統一資源識別子（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）へのE.164"。
[RFC3762] Levin, O., "Telephone Number Mapping (ENUM) Service Registration for H.323", RFC 3762, April 2004.
[RFC3762]レヴィン、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]ピーターソン、J.、 "セッション開始プロトコル（SIP）アドレス・オブ・レコードのenumservice登録"、RFC 3764、2004年4月。
[RFC3953] Peterson, J., "Telephone Number Mapping (ENUM) Service Registration for Presence Services", RFC 3953, January 2005.
[RFC3953]ピーターソン、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.、コンロイ、L.、およびR. Stastny、 "Enumservice 'ウェブ' の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.クロッカー、RFC 4143、2005年11月 "ENUMのインターネットメール（IFAX）サービスを使用してファクシミリ"。
[RFC4238] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, October 2005.
[RFC4238]ヴォードルイユ、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.、コンロイ、L.、およびR. Stastny、 "Enumservices電子メール、ファックス、MMS、EMS、およびSMSのためのIANA登録"、RFC 4355、2006年1月。
[RFC4415] Brandner, R., Conroy, L., and R. Stastny, "IANA Registration for Enumservice Voice", RFC 4415, February 2006.
[RFC4415] Brandner、R.、コンロイ、L.、およびR. Stastny、 "Enumserviceボイスの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.ショッキー、RFC 4769、2006年11月 "公開を含むEnumserviceためのIANA登録は、シグナリング情報を交換電話網（PSTN）"。
[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.、 "Enumservice '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]マーイ、R.、 "インスタントメッセージングのための電話番号マッピング（ENUM）サービス登録（IM）サービス"、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、 "音声とビデオメッセージングのためのEnumservicesのIANA登録"、RFC 5278、2008年7月。
[RFC5333] Mahy, R. and B. Hoeneisen, "IANA Registration of Enumservices for Internet Calendaring", RFC 5333, October 2009.
[RFC5333]マーイ、R.とB. Hoeneisen、 "インターネット予定表のためのEnumservicesのIANA登録"、RFC 5333、2009年10月。
[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, "IANA Registration of Enumservices: Guide, Template, and IANA Considerations", RFC 6117, March 2011.
[RFC6117] Hoeneisen、B.、Mayrhofer、A.、およびJ. Livingood、 "EnumservicesのIANA登録：ガイド、テンプレート、およびIANAの考慮事項"、RFC 6117、2011年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月。
Appendix A. Former Content of the IANA Repository
IANAリポジトリの付録A.元のコンテンツ
Enumservice Registrations
Enumservice登録
(last updated 2009-10-13)
（最終更新2009年10月13日）
Registries included below: - Enumservice Registrations
レジストリは以下に含ま： - Enumservice登録
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]
レジストリ：サービス名： "H323" URIスキーム（S）： "H323：" 機能仕様：[RFC3762]セキュリティ上の考慮事項の "E2U + H323 ENUMサービス3" セクションを参照してください：セクション "5.セキュリティの考慮事項" のを参照してください[ RFC3762]意図している用法：COMMON著者：oriTをレヴィン[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]
サービス名： "SIP" タイプ（S）： "SIP" サブタイプ（S）：N / URIスキーム（S）： "SIP" には、 "すする：" 機能仕様を：[RFC3764]セキュリティ上の考慮事項のセクション4を参照してください： [RFC3764]対象使用のセクション6：COMMON者：ジョン・ピーターソン（jon.peterson＆neustar.biz）著者が面白いと判断する任意の他の情報：[RFC3764]のセクション3を参照して、[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]
サービス名：「IFAX」タイプ：「IFAX」サブタイプ：「のmailto」URIスキーム：ファクシミリは標準のインターネットメールのプロファイルであるとアドレッシング標準のインターネットメールを使用するため、「mailtoの」URIスキームは、「MAILTO」です。機能仕様：[RFC4143]のセキュリティの考慮事項のセクション1を参照してください：[RFC4143]の項参照3意図している用法：COMMON著者：清豊田（toyoda.kiyoshi＆jp.panasonic.com）デイヴ・クロッカー（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]
サービス名： "PRES" URIスキーム（S）： "PRES：" 機能仕様：[RFC3953]セキュリティ上の考慮事項のセクション4を参照してください：[RFC3953]意図している用法の第6章を参照してください：COMMON著者：ジョン・ピーターソン（jon.peterson＆neustar.biz ）著者は面白いと判断するその他の情報：のセクション3を参照してください[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]
サービス名：「ウェブ」タイプ：「ウェブ」サブタイプ：「HTTP」URIスキーム：「HTTP：」機能仕様：このENUMserviceは、関連するURIスキームによって識別されるリソースは、情報源となりうることを示しています。これは、取得した情報の種類は、マニホールドであってもよいことに留意する必要があります。 URIは、文書を提供しています。通常は、「HTTP」によるリソースに連絡。この文書では、オーディオまたはビデオまたは実行可能コードのような情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に期待することができる情報の種類についてより具体的にすることはできません。セキュリティの考慮：[RFC4002]のセクション5を参照してください。意図した使用法：COMMON著者：ルドルフBrandner（rudolf.brandner＆siemens.com）ローレンス・コンロイ（LWC＆roke.co.uk）リチャード・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]
サービス名：「ウェブ」タイプ：「ウェブ」サブタイプ：「https」のURIスキーム：「HTTPS：」機能仕様：このENUMserviceは関連するURIスキームによって識別されるリソースがあることができ、情報の源であることが可能であることを示していますTLSまたはセキュアソケットレイヤプロトコルを使用して連絡しました。これは、取得した情報の種類は、マニホールドであってもよいことに留意する必要があります。 URIは、文書を提供しています。通常は、「HTTPS」によってリソースに連絡。この文書では、オーディオまたはビデオまたは実行可能コードのような情報のすべての異なる種類を含めることができます。このように、一つはリソースに連絡する際に期待するのはどのような情報がより具体的にすることはできません。セキュリティの考慮：[RFC4002]のセクション5を参照してください。意図した使用法：COMMON著者：ルドルフBrandner（rudolf.brandner＆siemens.com）ローレンス・コンロイ（LWC＆roke.co.uk）リチャード・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を参照してください。意図した使用法：COMMON著者：ルドルフBrandner（rudolf.brandner＆siemens.com）ローレンス・コンロイ（LWC＆roke.co.uk）リチャード・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名：「電子メール」Enumserviceタイプ：「電子メール」Enumserviceサブタイプ：「のmailto」URIスキーム：「MAILTO：」機能仕様：このEnumserviceは、リモートリソースが電子メールを送信するために、関連するURIスキームによって対処することができることを示しています。セキュリティの考慮：COMMON著者：ルドルフBrandner、ローレンスコンロイ、リチャードStastny（著者の連絡先詳細は[RFC4355]を参照）その他の情報作者が興味深いと考える：なし[RFC4355]のセクション6使用目的を参照してください
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名：「ファックス」Enumserviceタイプ：「ファックス」Enumserviceサブタイプ：「TEL」URIスキーム：「TEL：」機能仕様：このEnumserviceは関連するURIスキームによって識別されるリソースは、通信セッションを提供するために、連絡をすることが可能であることを示していますその間、ファクシミリ文書を送信することができます。このNAPTRを選択するクライアントは[RFC4355]で、[12]で指定されたPSTNセッションと転送プロトコルを使用して受信者にファクス文書を生成して送信するためのサポートを持っている[13]します - 要するに、彼らは地元でのFAXプログラムを持っていますまたは、彼らはファックスを送信することができ、その上PSTN回線を共有しました。セキュリティの考慮：COMMON著者：ルドルフBrandner、ローレンスコンロイ、リチャードStastny（著者の連絡先詳細は[RFC4355]を参照）その他の情報作者が興味深いと考える：なし[RFC4355]のセクション6使用目的を参照してください
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節の一般的な考慮事項が適用されます。意図した使用法：COMMON著者：ルドルフBrandner、ローレンスコンロイ、リチャードStastny（著者の連絡先詳細は[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コンテンツはMMSメッセージとして、TS 23.140 [15]セクション8.4.4およびTS 26.140 [16]セクション4（参照は[RFC4355]を参照）で指定されたフォーマットを使用して、SMTPを介して送信されます。このようなメッセージ内で、SMSの内容は、テキストまたはアプリケーション/オクテットストリームのMIMEサブ部分のいずれかとして実施される（TS 26.140 [16]、セクション4.1を参照）を参照するために[RFC4355]を参照。セキュリティの考慮事項：このEnumserviceとは、特定のセキュリティ上の問題はありません。しかし、第6節の一般的な考慮事項が適用され、[RFC4355]を参照してください。意図した使用法：COMMON著者：ルドルフBrandner、ローレンスコンロイ、リチャードStastny（著者の連絡先詳細は[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節の一般的な考慮事項が適用されます。 COMMON著者：[RFC4355]対象使用参照ルドルフBrandner、ローレンスコンロイ、リチャードStastnyを（著者コンタクト詳細を参照[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コンテンツはMMSメッセージとして、TS 23.140 [15]セクション8.4.4およびTS 26.140 [16]セクション4で指定されたフォーマットを使用して、SMTPを介して送信されます。このようなメッセージ内に、EMSのコンテンツは、（TS 26.140 [16]、セクション4.1を参照）テキストまたはアプリケーション/オクテットストリームのMIMEサブ部分のいずれかとして実施されます。参照のために[RFC4355]のセキュリティの考慮事項を参照してください。このEnumserviceとは、特定のセキュリティ上の問題はありません。ただし、[RFC4355]のセクション6の一般的な考慮事項が適用されます。意図した使用法：COMMON著者：ルドルフBrandner、ローレンスコンロイ、リチャードStastny（著者の連絡先詳細は[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の一般的な考慮事項が適用されます。意図した使用法：COMMON著者：ルドルフBrandner、ローレンスコンロイ、リチャードStastny（著者の連絡先詳細は[RFC4355]を参照）その他の情報作者が興味深いと考える：MMSがあれば、SMS RP-DATAのRPDUを提供するための代替として使用できることに注意してください例えば、SMSベアラがサポートされていません。エントリこのEnumserviceが含まれている場合、実際にはこれは、受信者がこのアドレスにEMSまたはSMSメッセージを受信することが可能であることを意味すると解釈することができます。エンドシステムの設計上のような選択肢は二つの小さな注意点を持っています。実際にいる間だけでなくMMS今日のサポートSMSをサポートしているすべての端末が、それが必ずしも将来のケースではないかもしれない、とMMSを使用してではなく、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スキームによって識別されたリソースは、電子メールプロトコルを使用してメッセージを受信することが可能であることを示しています。 MMSメッセージは、TS 23.140で指定されたフォーマットを使用して、SMTPを介して送信されている[15]セクション8.4.4およびTS 26.140 [16]内およびMMS環境（MMSE、マルチメディアサービスをサポートするネットワークインフラストラクチャ）、状態の他の部分との間の部4 （例えば、課金重要情報）データがMMSリレーサーバとの間で交換されます。これらのサーバーは、それらのアプリケーションの交換のための「ベアラ」としてSMTPを使用しているがこのように、それらは、SMTPメッセージ交換で運ば特殊ヘッダにその内部状態をマッピングします。例えばMMSEで使用されるヘッダは[17]に詳細に記載されています。参照のために[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の一般的な考慮事項が適用されます。意図した使用法：COMMON著者：ルドルフBrandner、ローレンスコンロイ、リチャードStastny（著者の連絡先詳細は[RFC4355]を参照）その他の情報作者が興味深いと考える：MMSアーキテクチャはMMSEと「従来のメッセージングシステム」間のインタフェースを記述する（とラベル「標準」SMTPメッセージを受け入れMM3）。このインタフェースをサポートするMMSリレーサーバーは、インターネットベースのメールサーバの観点から、標準のSMTPサーバとして表示されているがこのようにして、内およびMMS環境との間で使用される内部状態データを追加、ゲートウェイトランスレータとして働きます。このメカニズムは、MMSの設計の責任者機関によって合意された仕様への参照を含む、[17]に記載されています。
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.
サービス名：E.164はのMailToをVPIMする：URL URIタイプ： "にmailto：" タイプ：VPIMサブタイプ：MAILTO機能仕様：COMMON著者：グレッグボードルイ（gregv＆ieee.org）エラー[RFC4238]の4.4経由のセクション4.2を参照してください使用を意図し番号計画でE.164番号OないE.164番号O番号計画では、ないURLがE2U + VPIM Oその数に対して存在しません：条件にmailtoサービスは使用できませんセキュリティに関する注意事項：悪意のあるリダイレクトOに関連する基本的な危険性の一つこのような任意のサービスには、リゾルバのデータベースに悪質なエントリは、クライアントが間違った電子メールのURLにE.164を解決するようになりますということです。可能な意図は、クライアントが間違った宛先に情報を送信させるかもしれません。 E.164マップ先のURLを除去することにより、サービス拒否O、悪意のある侵入者がリソースにアクセスするためのクライアントの機能を削除することができます。 O迷惑メールは、ENUMサービスを介して電子メールアドレスの露出は電話番号だけが以前に知られていた電子メールアドレスの多数のバルクメーラのアクセスを提供します。
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.
サービス名：VPIM LDAPのURL URIタイプのE.164： "LDAP：" タイプ：VPIMサブタイプ：LDAP機能仕様：[RFC4238]の3.3経由のセクション3.2を参照してください使用目的：COMMON著者：グレッグボードルイ（gregv＆ieee.org）セキュリティの考慮事項：O悪意のあるリダイレクトこのような任意のサービスに関連する基本的な危険性の一つは、リゾルバのデータベースに悪質なエントリが間違ったLDAPのURLにE.164を解決するためにクライアントを引き起こすということです。可能な目的は、クライアントが不正なLDAPサーバに接続し、取得（または取得に失敗）不正または有害な情報を含むリソースさせるかもしれません。 E.164マップ先のURLを除去することにより、サービス拒否O、悪意のある侵入者は、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 subsystem will use the telephone number held in the generated URI to place a voice call. The voice call is placed to a network that uses E.164 numbers to route calls to an appropriate destination. o Note that the PSTN/PLMN connection may be indirect. The end user receiving this NAPTR may have a relationship with a Communications Service Provider that accepts call initiation requests from that subsystem using an IP-based protocol such as SIP or H.323, and places the call to the PSTN using a remote gateway service. In this case the Provider may either accept requests using "tel:" URIs or has a defined mechanism to convert "tel:" URI values into a "protocol-native" form. o The "tel:" URI value SHOULD be fully qualified (using the "global phone number" form of RFC3966 [10]). A "local phone number" as defined in that document SHOULD NOT be used unless the controller of the zone in which the NAPTR appears is sure that it can be distinguished unambiguously by all clients that can access the resource record and that a call from their network access points can be routed to that destination.
Enumservice名：「声」Enumserviceタイプ：「声」Enumserviceサブタイプ：「TEL」URIスキーム：「TEL：」機能仕様：このEnumserviceが示す通信の種類は、「対話型音声」です。プロトコルの観点から、この通信は、オーディオデータを搬送する双方向メディアストリームを含むことが期待されます。クライアントは、このEnumserviceを保持NAPTRの人口を制御する人が、このNAPTRによって生成されたURIを使用して接触した場合に、対話型音声セッションに従事するために彼らの能力を示すことを意味し得ます。セキュリティに関する注意事項：著者は面白いと考えるルドルフBrandner、ローレンスコンロイ、リチャードStastny（著者の連絡先の詳細のために著者のアドレスセクションを参照してください）その他の情報：COMMON著者：[RFC4415]のセクション5は、使用目的を参照してください。このEnumserviceは人ということを示しているoをNAPTRの責任は、生成されたURIの値を使用してPSTN（公衆交換電話網）またはPLMN（公衆陸上モバイルネットワーク）を介してアクセス可能です。 Oこのサブタイプの音声Enumserviceを開始するのに必要なサブシステムの種類は、「ダイヤラ」です。これは、PSTNまたはPLMNへのローカル接続を提供し、またはそれはこれらのネットワークへの間接接続を提供していずれかのサブシステムです。サブシステムは、音声通話を置くために生成されたURIで開催された電話番号を使用します。音声通話は、適切な宛先にコールをルーティングするためにE.164番号を使用するネットワークに配置されています。 O PSTN / PLMN接続は間接的であってもよいことに留意されたいです。このNAPTRを受信側ユーザは、SIPまたはH.323のようなIPベースのプロトコルを使用して、そのサブシステムから発信要求を受け付ける通信サービスプロバイダと関係を持って、リモートゲートウェイサービスを使用して、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への双方向の音声または他の通信を含むことができるセッション、。 [10] RFC 4694で指定されるように、これらのURIは、番号ポータビリティデータを含んでいてもよいです。セキュリティの考慮：[RFC4769]のセクション7を参照してください。意図した使用法：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）リチャード・ショッキー（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を参照してください。意図した使用法：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）リチャード・ショッキー（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サブタイプ：N / URIスキーム： "HTTP"、 "HTTPS" 機能仕様：これEnumserviceは、特定されたリソースが普通のvCardであることを示し応じHTTP / HTTPSを使用してアクセスすることができるRFC 2426、[7]。示されたリソースからのvCardを取得するクライアントは、アクセスが制限されることを期待すべきです。また、提供されたデータの理解は、クライアントのIDによって異なる場合があります。セキュリティに関する注意事項：第5節[RFC4969]使用目的を参照してください：COMMON著者：アレクサンダー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サブタイプ：N / URIスキーム： "XMPP" 機能仕様：このEnumserviceは特定されたリソースは、XMPP実体であることを示しています。セキュリティの考慮：[RFC4979]使用目的のセクション6を参照してください：COMMON著者：アレクサンダー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サブタイプ：N / URIスキーム（S）： "IM：" 機能仕様：URI：このEnumserviceは、識別されたリソースが 'IM' であることを示しています。 「IM」パーティ問い合わせるENUMによってサポートされるIMプロトコルでもあるかどうかをURIスキームはRFC 3861に機構むしろ、インスタント・メッセージング・レシートまたは送達を処理するために使用される任意の特定のプロトコルを識別しない[4]発見するために使用されターゲット・リソースによってサポートされています。セキュリティの考慮事項：[RFC5028]意図している用法のセクション3を参照してください：COMMON著者：ロハンマーイ（ロハン＆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サブタイプ：URIスキームを「SIP」：「一口：」機能仕様：このEnumserviceは特定されたリモートリソースが声を開始するために関連付けられているURIスキームによって対処可能であることを示していますボイスメッセージシステムへの通信セッション。セキュリティの考慮は：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）ドンTroshynski（dtroshynski＆acmepacket.com）著者は面白いと考えるその他の情報：[RFC5278]使用目的の第3節を参照の実装者は、例の非排他的なリストを確認する必要があります[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サブタイプ：「一口」URIスキーム：「一口：」機能仕様：このEnumserviceは特定されたリモートリソースが声を開始するために関連付けられているURIスキームによって対処可能であることを示していますボイスメッセージシステムへの通信セッション。セキュリティの考慮：COMMON著者：：[RFC5278]のセクション3は、使用目的を参照してくださいジェイソンLivingood（jason_livingood＆cable.comcast.com）ドン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スキームによって対処可能であることを示していますボイスメッセージシステムへの通信セッション。セキュリティの考慮は：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）ドンTroshynski（dtroshynski＆acmepacket.com）著者は面白いと考えるその他の情報：[RFC5278]使用目的の第3節を参照の実装者は、例の非排他的なリストを確認する必要があります[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は、文書を提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいは音声メッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。セキュリティの考慮は：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）ドンTroshynski（dtroshynski＆acmepacket.com）著者は面白いと考えるその他の情報：[RFC5278]使用目的の第3節を参照の実装者は、例の非排他的なリストを確認する必要があります[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は、ドキュメントを提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいは音声メッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。セキュリティの考慮は：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）ドンTroshynski（dtroshynski＆acmepacket.com）著者は面白いと考えるその他の情報：[RFC5278]使用目的の第3節を参照の実装者は、例の非排他的なリストを確認する必要があります[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スキームによって対処可能であることを示していますビデオメッセージングシステムへの通信セッション。セキュリティの考慮は：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）ドンTroshynski（dtroshynski＆acmepacket.com）著者は面白いと考えるその他の情報：[RFC5278]使用目的の第3節を参照の実装者は、例の非排他的なリストを確認する必要があります[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サブタイプ：「一口」URIスキーム：「一口：」機能仕様：このEnumserviceが確認リモートリソースがビデオを開始するために関連付けられているURIスキームによって対処可能であることを示していますビデオメッセージングシステムへの通信セッション。セキュリティの考慮は：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）ドンTroshynski（dtroshynski＆acmepacket.com）著者は面白いと考えるその他の情報：[RFC5278]使用目的の第3節を参照の実装者は、例の非排他的なリストを確認する必要があります[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は、文書を提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいはビデオメッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。セキュリティの考慮は：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）ドンTroshynski（dtroshynski＆acmepacket.com）著者は面白いと考えるその他の情報：[RFC5278]使用目的の第3節を参照の実装者は、例の非排他的なリストを確認する必要があります[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は、ドキュメントを提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいはビデオメッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。セキュリティの考慮は：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）ドンTroshynski（dtroshynski＆acmepacket.com）著者は面白いと考えるその他の情報：[RFC5278]使用目的の第3節を参照の実装者は、例の非排他的なリストを確認する必要があります[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スキームによって対処可能であることを示していますユニファイドメッセージングシステムへの通信セッション。セキュリティの考慮は：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）ドンTroshynski（dtroshynski＆acmepacket.com）著者は面白いと考えるその他の情報：[RFC5278]使用目的の第3節を参照の実装者は、例の非排他的なリストを確認する必要があります[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サブタイプ：「一口」URIスキーム：「一口：」機能仕様：このEnumserviceは特定されたリモートリソースが統一を開始するために関連付けられているURIスキームによって対処可能であることを示していますユニファイドメッセージングシステムへの通信セッション。セキュリティに関する注意事項：著者は面白いと考えるジェイソンLivingood（jason_livingood＆cable.comcast.com）その他情報：COMMON著者：[RFC5278]のセクション3使用目的をすべて見る実装者はセクション7で以下の例の非排他的なリストを確認する必要があります[RFC5278 ]
Enumservice Name: "unifmsg" Enumservice Type: "unifmsg" Enumservice Subtype: "http" URI Schemes: 'http:' Functional Specification: This Enumservice indicates that the remote resource identified by the associated URI scheme is capable of being a source of information. Note that the kind of information retrieved can be manifold. Usually, contacting a resource by an 'http:' [11] URI provides a document. This document can contain references that will trigger the download of many different kinds of information, such as text, audio, video, executable code, or even video message files. Thus, one cannot be more specific about the kind of information expected when contacting the resource. Security Considerations: See Section 3 of [RFC5278] Intended Usage: COMMON Authors: Jason Livingood (jason_livingood&cable.comcast.com) Don Troshynski (dtroshynski&acmepacket.com) Any other information the author deems interesting: Implementers should review a non-exclusive list of examples below in Section 7 of [RFC5278]
Enumservice名：「unifmsg」Enumserviceタイプ：「unifmsg」Enumserviceサブタイプ：「HTTP」URIスキーム：「HTTP：」機能仕様：このEnumserviceは、関連するURIスキームによって識別されたリモートリソースは、情報のソースであることが可能であることを示しています。取得した情報の種類は、マニホールドできることに注意してください。通常、によってリソースを接触させることを「のhttp：」[11] URIは、文書を提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいはビデオメッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。セキュリティの考慮は：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）ドンTroshynski（dtroshynski＆acmepacket.com）著者は面白いと考えるその他の情報：[RFC5278]使用目的の第3節を参照の実装者は、例の非排他的なリストを確認する必要があります[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は、ドキュメントを提供します。この文書は、テキスト、オーディオ、ビデオ、実行可能コード、あるいはビデオメッセージファイルなどの情報の多くの異なる種類のダウンロードをトリガーするの参照を含めることができます。このように、一つはリソースに連絡する際に予想される情報の種類についてより具体的にすることはできません。セキュリティの考慮は：COMMON著者：ジェイソンLivingood（jason_livingood＆cable.comcast.com）ドンTroshynski（dtroshynski＆acmepacket.com）著者は面白いと考えるその他の情報：[RFC5278]使用目的の第3節を参照の実装者は、例の非排他的なリストを確認する必要があります[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スキーム（S）： 'のmailto：' 機能仕様：このEnumserviceは、識別されたリソースが使用関連URIによって対処することができることを示していますiMIPの[6]プロトコルでインターネットメールを介してインターネットのカレンダーを使用してスケジューリングのため。セキュリティの考慮事項：[RFC5333]のセクション4を参照してください。意図している用法：COMMON著者：ロハンマーイ（ロハン＆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のアクセス」Enumserviceタイプ：「iCalのアクセス」Enumserviceサブタイプ：「HTTP」URIスキーム（S）：「HTTP：」機能仕様：このEnumserviceは特定されたリソースがで関連するURIによって対処可能であることを示していますインターネットカレンダーのためのCalDAV [7]プロトコルを使用して、ユーザのカレンダーにアクセスするために（例えば、フリー/ビジーステータス）。セキュリティの考慮事項：[RFC5333]のセクション4を参照してください。意図している用法：COMMON著者：ロハンマーイ（ロハン＆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のアクセス」Enumserviceタイプ：「iCalのアクセス」Enumserviceサブタイプ：「https」のURIスキーム（S）：「HTTPS：」機能仕様：このEnumserviceは特定されたリソースがで関連するURIによって対処可能であることを示していますインターネットカレンダーのためのCalDAV [7]プロトコルを使用して、ユーザのカレンダーにアクセスするために（例えば、フリー/ビジーステータス）。セキュリティの考慮事項：[RFC5333]のセクション4を参照してください。意図している用法：COMMON著者：ロハンマーイ（ロハン＆ekabal.com）
Authors' Addresses
著者のアドレス
Bernie Hoeneisen Ucom Standards Track Solutions GmbH CH-8000 Zuerich Switzerland
バーニーHoeneisen UCOM標準化過程ソリューションズ社CH-8000チューリッヒスイス
Phone: +41 44 500 52 44 EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) URI: http://www.ucom.ch/
電話：+41 44 500 52 44 Eメール：（ucom.ch AT bernhard.hoeneisen）bernie@ietf.hoeneisen.ch URI：http://www.ucom.ch/
Alexander Mayrhofer enum.at GmbH Karlsplatz 1/9 Wien A-1010 Austria
アレクサンダーMayrhoferは1010年オーストリアウィーンGmbH社カールス1/9をenum.at
Phone: +43 1 5056416 34 EMail: alexander.mayrhofer@enum.at URI: http://www.enum.at/
電話：+43 1 5056416 34電子メール：URI alexander.mayrhofer@enum.at：http://www.enum.at/