Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6118

Update of Legacy IANA Registrations of Enumservices

Pages: 68
Proposed Standard
Updates:  37623764395341434002423843554415476949694979502852785333
Part 1 of 3 – Pages 1 to 22
None   None   Next

Top   ToC   RFC6118 - Page 1
Internet Engineering Task Force (IETF)                      B. Hoeneisen
Request for Comments: 6118                                       Ucom.ch
Updates: 3762, 3764, 3953, 4143, 4002,                      A. Mayrhofer
         4238, 4355, 4415, 4769, 4969,                           enum.at
         4979, 5028, 5278, 5333                               March 2011
Category: Standards Track
ISSN: 2070-1721


          Update of Legacy IANA Registrations of Enumservices

Abstract

This document revises all Enumservices that were IANA registered under the now obsolete specification of the Enumservice registry defined in RFC 3761. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6118. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Top   ToC   RFC6118 - Page 2
   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.

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
Top   ToC   RFC6118 - Page 3
     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
Top   ToC   RFC6118 - Page 4

1. Introduction

[RFC6117] has obsoleted the IANA registration section of [RFC3761]. Since the IANA Enumservice registry contains various Enumservices registered under the regime of RFC 3761, those registrations do not conform to the new guidelines as specified in [RFC6117]. To ensure consistency among all Enumservice registrations at IANA, this document adds the (nowadays) missing elements to those legacy registrations. Furthermore, all legacy Enumservice registrations are converted to the new XML-chunk format, and, where deemed necessary, minor editorial corrections are applied. However, this document only adds the missing elements to the XML chunks as specified in the IANA Considerations section of [RFC6117], but it does not complete the (nowadays) missing sections of the corresponding Enumservice Specifications. In order to conform with the new registration regime as specified in [RFC6117], those Enumservice Specifications still have to be revised. It is important to note that this document does not update the functional specification of the concerned Enumservices. The following RFCs are updated by this document: o [RFC3762] o [RFC3764] o [RFC3953] o [RFC4143] o [RFC4002] o [RFC4238] o [RFC4355] o [RFC4415] o [RFC4769] o [RFC4969] o [RFC4979] o [RFC5028] o [RFC5278] o [RFC5333]

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
Top   ToC   RFC6118 - Page 5

3. IESG Action

According to [RFC3761], any Enumservice registration had to be published as a Standards Track, Experimental, or BCP (Best Current Practice) RFC. [RFC6117] no longer has this requirement, i.e., "Specification Required", which implies the use of a Designated Expert [RFC5226], is sufficient. This document changes the approval requirement for updates to Enumservice registrations to Specification Required, whereby the specification and request are reviewed by a Designated Expert as described in [RFC6117].

4. Legacy Enumservice Registrations Converted to XML Chunks

In the following, the legacy Enumservice Registrations are converted to XML chunks that include the new elements introduced by [RFC6117]. (Note that references in Sections 4.1 - 4.39 refer to the references section within the respective Enumservice Specification.)

4.1. email:mailto

<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"/>
Top   ToC   RFC6118 - Page 6
       </requesters>
     </record>

4.2. ems:mailto

<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>
Top   ToC   RFC6118 - Page 7

4.3. ems:tel

<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>
Top   ToC   RFC6118 - Page 8

4.4. fax:tel

<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>
Top   ToC   RFC6118 - Page 9

4.5. ft:ftp

<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>
Top   ToC   RFC6118 - Page 10

4.6. h323

<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>
Top   ToC   RFC6118 - Page 11

4.7. ical-access:http

<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>
Top   ToC   RFC6118 - Page 12

4.8. ical-access:https

<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>
Top   ToC   RFC6118 - Page 13

4.9. ical-sched:mailto

<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>
Top   ToC   RFC6118 - Page 14

4.10. ifax:mailto

<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>
Top   ToC   RFC6118 - Page 15

4.11. im

<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>
Top   ToC   RFC6118 - Page 16

4.12. mms:mailto

<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>
Top   ToC   RFC6118 - Page 17
        <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>
Top   ToC   RFC6118 - Page 18

4.13. mms:tel

<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
Top   ToC   RFC6118 - Page 19
          be tariff differences in using the MMS rather than
          using the SMS or EMS.
        </paragraph>
      </additionalinfo>
    </record>

4.14. pres

<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>
Top   ToC   RFC6118 - Page 20

4.15. pstn:sip

<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>
Top   ToC   RFC6118 - Page 21

4.16. pstn:tel

<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>
Top   ToC   RFC6118 - Page 22

4.17. sip

<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>


(next page on part 2)

Next Section