Informative References - This document is a product of the Internet Engineering Task Force (IET

International Telecommunications Union, "The International Public Telecommunication Numbering Plan",

T Recommendation E.164, Feb 2005.

[Instructions2authors]

Reynolds, J. and R. Braden, "Instructions to Request for Comments (RFC) Authors", RFC Editor http://

www.rfc-editor.org/rfc-editor/instructions2authors.txt, August 2004.

[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.

[RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.

[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.

[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.

[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.

[RFC3764] Peterson, J., "enumservice registration for Session

Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.

[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.

[RFC4238] Vaudreuil, G., "Voice Message Routing Service", RFC 4238, October 2005.

[RFC4759] Stastny, R., Shockey, R., and L. Conroy, "The ENUM Dip Indicator Parameter for the "tel" URI", RFC 4759, December 2006.

[RFC4846] Klensin, J. and D. Thaler, "Independent Submissions to the RFC Editor", RFC 4846, July 2007.

[RFC4969] Mayrhofer, A., "IANA Registration for vCard Enumservice", RFC 4969, August 2007.

[RFC4979] Mayrhofer, A., "IANA Registration for Enumservice ’XMPP’", RFC 4979, August 2007.

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA Registrations of Enumservices", RFC 6118, March 2011.

Appendix A. IANA Registration Template Examples

This section contains non-normative examples of the XML-chunk-based IANA Registration Template:

This is the first example:

<class>Protocol-Based</class>

<type>email</type>

<subtype>mailto</subtype>

<urischeme>mailto</urischeme>

This Enumservice indicates that the resource can be addressed by the associated URI in order to send an email.

</paragraph>

</functionalspec>

See <xref type="rfc" data="rfc4355"/>, Section 6.

</security>

<usage>COMMON</usage>

</registrationdocs>

</requesters>

</record>

<name>Lawrence Conroy</name>

<org>Siemens Roke Manor Research</org>

<uri>mailto:lwc@roke.co.uk</uri>

</person>

</people>

This is the second example.

<class>Protocol-Based</class>

This Enumservice indicates that the resource identified is an XMPP entity.

</paragraph>

</functionalspec>

See <xref type="rfc" data="rfc4979"/>, Section 6.

</security>

<usage>COMMON</usage>

</registrationdocs>

</requesters>

</record>

<name>Alexander Mayrhofer</name>

<uri>mailto:alexander.mayrhofer@enum.at</uri>

</person>

</people>

This is the third example:

<class>Application-Based</class>

<type>voicemsg</type>

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>

See <xref type="rfc" data="rfc4279"/>, Section 3.

</security>

<usage>COMMON</usage>

</registrationdocs>

</requesters>

Implementers should review a non-exclusive list of examples in <xref type="rfc" data="rfc4279"/>, Section 7.

</paragraph>

</additionalinfo>

</record>

<name>Jason Livingood</name>

<org>Comcast Cable Communications</org>

<uri>mailto:jason_livingood@cable.comcast.com</uri>

</person>

<name>Donald Troshynski</name>

<org>Acme Packet</org>

<uri>mailto:dtroshynski@acmepacket.com</uri>

</person>

</people>

In the third IANA Registration Template example above, the "voicemsg"

Enumservice is used. This Enumservice actually has several Subtypes, and one of those is shown in the example. For each Subtype, an

individual Registration Template must be submitted to IANA, so that an Enumservice with several Subtypes will have several corresponding IANA Registration Templates. This is to avoid any ambiguity of the relation between <subtype> and <urischeme> elements.

Appendix B. Changes from RFC 3761

This section lists the changes applied to the Enumservice

registration process and the IANA registry definition, compared to RFC 3761.

o While RFC 3761 required "Standards track or Experimental" RFCs for an Enumservice to be registered, this document mandates

"Specification Required", which implies the use of a Designated Expert.

o This document defines the classification of Enumservices. The IANA Registration Template has been complemented to contain a <class> element (Enumservice Class).

o A new element <registrationdocs> (Enumservice Specification) has been added to the IANA Registration Template.

o The former field "Any other information that the author deems interesting" of the IANA Registration Template turned into the <additionalinfo> element (Further Information).

o The Enumservice "Name" field has been removed from the IANA Registration Template.

o The Registration Template is now a chunk of XML data, reflecting IANA’s recent work to convert registries to XML.

Authors’ Addresses Bernie Hoeneisen

Ucom Standards Track Solutions GmbH CH-8000 Zuerich

Switzerland

Phone: +41 44 500 52 44

EMail: bernie@ietf.hoeneisen.ch (bernhard.hoeneisen AT ucom.ch) URI: http://www.ucom.ch/

Alexander Mayrhofer enum.at GmbH

Karlsplatz 1/9 Wien A-1010 Austria

Phone: +43 1 5056416 34

EMail: alexander.mayrhofer@enum.at URI: http://www.enum.at/

Jason Livingood

Comcast Cable Communications One Comcast Center

1701 John F. Kennedy Boulevard Philadelphia, PA 19103

USA

Phone: +1-215-286-7813

EMail: jason_livingood@cable.comcast.com URI: http://www.comcast.com/

Dans le document This document is a product of the Internet Engineering Task Force (IETF) (Page 34-40)