ENUM Implementation Issues and Experiences
RFC 5483
Network Working Group L. Conroy
Request for Comments: 5483 RMRL
Category: Informational K. Fujiwara
JPRS
March 2009
ENUM Implementation Issues and Experiences
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This document captures experiences in implementing systems based on
the ENUM protocol and experiences of ENUM data that have been created
by others. As such, it clarifies the ENUM and Dynamic Delegation
Discovery System standards. Its aim is to help others by reporting
both what is "out there" and potential pitfalls in interpreting the
set of documents that specify the ENUM protocol. It does not revise
the standards but is intended to provide technical input to future
revisions of those documents.
Conroy & Fujiwara Informational [Page 1]
RFC 5483 ENUM Experiences March 2009
Table of Contents
1. Introduction ....................................................3
1.1. Document Goal ..............................................3
1.2. Terminology ................................................3
2. Character Sets and ENUM .........................................4
2.1. Character Sets - Non-ASCII Considered Harmful ..............4
2.1.1. Non-ASCII in the Regular Expression Field ...........5
2.1.2. Non-ASCII Support - Conclusions .....................6
2.2. Case Sensitivity ...........................................7
2.3. Regexp Field Delimiter .....................................7
2.4. Regexp Meta-Character Issue ................................8
3. Unsupported NAPTRs ..............................................8
3.1. Non-Compliant Client Behaviour .............................9
4. ENUM NAPTR Processing ..........................................10
4.1. Common Non-Compliant Client Behaviour .....................11
4.1.1. Example ............................................11
4.2. Order/Priority Values - Processing Sequence ...............12
4.3. Use of Order and Preference Fields ........................13
4.4. NAPTRs with Identical ORDER/PRIORITY Values ...............14
4.4.1. Compound NAPTRs and Implicit
ORDER/REFERENCE Values .............................14
4.5. Processing Order Value across Domains .....................15
5. Non-Terminal NAPTR Processing ..................................16
5.1. Non-Terminal NAPTRs - Necessity ...........................16
5.2. Non-Terminal NAPTRs - Considerations ......................17
5.2.1. Non-Terminal NAPTRs - General ......................17
5.2.2. Non-Terminal NAPTRs - Loop Detection and Response ..17
5.2.3. Field Content in Non-Terminal NAPTRs ...............17
6. Backwards Compatibility ........................................20
6.1. Services Field Syntax .....................................20
7. Collected Implications for ENUM Provisioning ...................21
8. Collected Implications for ENUM Clients ........................23
8.1. Non-Terminal NAPTR Processing .............................25
9. Security Considerations ........................................26
10. Acknowledgements ..............................................27
11. References ....................................................27
11.1. Normative References .....................................27
11.2. Informative References ...................................29
Conroy & Fujiwara Informational [Page 2]
RFC 5483 ENUM Experiences March 2009
1. Introduction
1.1. Document Goal
The goal of this document is to clarify the ENUM and Dynamic
Delegation Discovery System (DDDS) standards. It does not itself
revise ENUM or DDDS standards but is intended to provide technical
input to future revisions of those documents. It also serves to
advise implementers on the pitfalls that they may find. It
Show full document text