ENUM -- Telephone Number Mapping                            A. Mayrhofer
Working Group                                                   O. Lendl
Internet-Draft                                                   enum.at
Expires: April 7, 2005                                       M. Haberler
                                                                     IPA
                                                         October 7, 2004


        ENUM Validation Architecture and Token Format Definition
                   draft-mayrhofer-enum-validation-00

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 7, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   ENUM domains track the right-to-use of the underlying E.164 number.
   The process of asserting this is called "validation".  This document
   describes a generalized role model and a XML data format -- the
   validation token -- to convey validation related information.




Mayrhofer, et al.        Expires April 7, 2005                  [Page 1]

Internet-Draft        ENUM Validation Architecture          October 2004


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3

   2.  Roles and their Suitability for Validation . . . . . . . . . .  3
     2.1   The Registry . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2   The Number-Range Holder (NRH)  . . . . . . . . . . . . . .  3
     2.3   The Registrar  . . . . . . . . . . . . . . . . . . . . . .  4
     2.4   The Validation Entity (VE) . . . . . . . . . . . . . . . .  4

   3.  Example Scenarios  . . . . . . . . . . . . . . . . . . . . . .  4
     3.1   Fully Segregated Roles . . . . . . . . . . . . . . . . . .  4
     3.2   ITSP acts as Registrar and VE  . . . . . . . . . . . . . .  4
     3.3   Cooperating Number-Range Holder  . . . . . . . . . . . . .  5
     3.4   ENUM enabled Telco . . . . . . . . . . . . . . . . . . . .  5

   4.  Validation Process Requirements  . . . . . . . . . . . . . . .  5

   5.  The Validation Token . . . . . . . . . . . . . . . . . . . . .  5
     5.1   Attribute description  . . . . . . . . . . . . . . . . . .  6
     5.2   Signature  . . . . . . . . . . . . . . . . . . . . . . . .  7
     5.3   Examples . . . . . . . . . . . . . . . . . . . . . . . . .  7
       5.3.1   Unsigned token without subscriber information  . . . .  7
       5.3.2   Unsigned token with subscriber information . . . . . .  8
       5.3.3   Signed token . . . . . . . . . . . . . . . . . . . . .  8

   6.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1   Token Core Schema  . . . . . . . . . . . . . . . . . . . . 11
     6.2   Token Data Schema  . . . . . . . . . . . . . . . . . . . . 12

   7.  Wider applicability  . . . . . . . . . . . . . . . . . . . . . 14

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15

       Intellectual Property and Copyright Statements . . . . . . . . 17














Mayrhofer, et al.        Expires April 7, 2005                  [Page 2]

Internet-Draft        ENUM Validation Architecture          October 2004


1.  Introduction

   TLD domain registrations are typically handled on a
   first-come-first-served basis.  The registration data is the complete
   source of ownership information.

   An ENUM [2] domain is an attribute of an E.164 number, and thus is
   inextricably linked to the status and the holder of the number.
   Therefore, the right-to-use in the number is a precondition to
   delegation of the domain and relinquishing the number implies
   cancellation of the domain.

   During the process of registration, it must be guaranteed that some
   trusted party does actually confirm the right-to-use of the
   registrant.  If the telco which initially assigned the number to the
   registrant acts as his registrar, then he can assert the right-to-use
   as neccessary.  If the number-holder tries to register his ENUM
   domain independently of his telco, then he has to prove his right to
   the ENUM domain.

   Besides this "initial validation", provisions must be made to ensure
   that the state of the ENUM domain tracks any change in the ownership
   of the number.

2.  Roles and their Suitability for Validation

2.1  The Registry

   The Registry typically operates the master database of delegated ENUM
   domains and runs the authoritative nameservers for the relevant zone
   under e164.arpa.

   While the registry could try to check the legitimacy of incoming
   delegation requests, a registry is a natural monopoly and it may be
   undesirable to task it with the validation problem.

   However, the registry should be able to verify that requests have
   been properly validated, preferrably in a fully automated way.

2.2  The Number-Range Holder (NRH)

   The right to use on a number is typically assigned to the subscriber
   (the "number-holder") by a telco (in case of number block
   allocations) or by the local numbering authority (in case of direct
   assignments).  The associated subscriber data is the primary source
   of number assignment information.

   A telco assigning numbers to customers may easily assert the



Mayrhofer, et al.        Expires April 7, 2005                  [Page 3]

Internet-Draft        ENUM Validation Architecture          October 2004


   right-to-use for their subscribers.  However it is unlikely that all
   telcos will participate in ENUM validation.

2.3  The Registrar

   A registrar performs ENUM domain delegations on behalf of a
   numberholder by interacting with the registry, typically through a
   protocol like EPP [5].  This is the same role registrars fulfill in
   the TLD world.

   While registrar usually "owns" the customer and thus can assert his
   identity, he may lack authoritative number-assignment information.

2.4  The Validation Entity (VE)

   The Validation Entity asserts the right-to-use of a subscriber for a
   given E.164 number.  This role may be performed by several parties
   and is not neccessarily limited to a single legal entity.

   The actual validation methods employed might vary depending on the
   particular party, available data-sources, subscriber choice, and
   regulatory requirements.  See Section 3 for examples.

   The VE may assert successful validation by supplying a standardized
   "Validation Token" to the registrar for passing to the registry.  The
   registry could formally verify its contents, origin and integrity,
   regardless of the method and source of validation information used.

3.  Example Scenarios

   The following section describes potential role allocations.  While in
   theory all roles could be fulfilled by different entities, in
   practice a party may assume several roles simultaneously.

3.1  Fully Segregated Roles

   An Internet Telephony Service Provider (ITSP) acts as registrar and
   offers an ENUM-enabled service based on existing geographic numbers.
   The number-range holders (telcos) do not provide validation entity
   services.  The ITSP contracts a directory assistance operator to
   provide VE services.

3.2  ITSP acts as Registrar and VE

   An ITSP offers ENUM-enabled services for mobile numbers.  For
   validation the ITSP uses a SMS (Short Message Service) confirmation
   loop to establish the link between his customer and the number.




Mayrhofer, et al.        Expires April 7, 2005                  [Page 4]

Internet-Draft        ENUM Validation Architecture          October 2004


3.3  Cooperating Number-Range Holder

   The number-range holder provides VE services.  The ITSP contracts the
   NRH for validation.

3.4  ENUM enabled Telco

   A broadband ISP provides VoIP services to subscribers using his own
   number ranges.  He performs validation by reference to his subscriber
   database.

4.  Validation Process Requirements

   An ENUM domain delegation to a different entity than the number
   holder is faulty and a potential privacy risk.  Extending
   registration data with validation information avoids this risk, if
   the registry can assert its authenticity and integrity.

   If trust relationships is established between the registry and the
   VE's, then these checks can be applied regardless which VE supplied
   the validation information for a registrar for a given registration,
   and without the need for direct interaction of a VE with the
   registry.  This simplifies the most common case (ENUM enabled telco
   scenario, Section 3.4) while retaining choice for registrars and
   avoiding a single, prescribed validation entity.

   To enable the registry to automatically verify validation information
   produced by potentially many VE's and presented by different
   registrars, a standardized data format for validation information is
   required.  It establishes a communication channel between VE's and
   the registry without adding direct interaction and introducing
   another VE/registry protocol.

   Validation information must provide auditable non-repudiation of
   origin and content.  Timestamps must allow to limit the validity
   period of the asserted right-to-use.

   The data format of the validation information must allow for number
   holder related information.  This information is required to assist
   in recurring validation.

5.  The Validation Token

   A validation token is a XML [6] document format for conveying
   validation related information from validation entities to the
   registry.  Its attributes and associated values contain information
   deemed to be neccessary for asserting the right-to-use and
   revalidation.



Mayrhofer, et al.        Expires April 7, 2005                  [Page 5]

Internet-Draft        ENUM Validation Architecture          October 2004


   The relevant parts of the validation token are signed by the VE using
   XML-Signature [3].  This signature as described in Section 5.2 allows
   checking authenticity and origin of a token.

5.1  Attribute description

   A token MUST contain the following attributes:

   o  A single validation "serial" string uniquely identifying a
      validation token for a certain VE.
   o  A single "e164number" attribute, containing the E.164 number in
      international format for which validation was carried out.
   o  A single "validator" id, identifying the VE.
   o  A single "method" id, identifying the method used by the VE for
      validation.
   o  A single "registrar" id, identifying the registrar for which
      validation was carried out.
   o  A single "createdate" attribute, containing the date of
      validation, formatted as "full-date" according to RFC3339 [4].
   o  A single "expiredate" attribute, marking the expiration date of
      the validation token, formatted as "full-date" according to
      RFC3339.

   A token MAY contain a "tokendata" section.  The section contains
   information about the entity whose right-to-use is being asserted.

   o  A single "organisation" attribute, containing the full name of the
      entity.
   o  A single "commercialregisternumber" attribute, containing the
      entity's registration number.
   o  A single "title" attribute.
   o  A single "firstname" attribute.
   o  A single "lastname" attribute.
   o  A single "address" section, containing the following attributes:
      *  A single mandatory "streetname" attribute
      *  A single optional "streetnumber" attribute
      *  A single optional "apartment" attribute
      *  A single mandatory "postalcode" attribute
      *  A single mandatory "city" attribute
      *  A single optional "state" attribute
      *  A single mandatory "country" attribute
   o  up to 10 "phone" attributes, containing full E.164 numbers
   o  up to 10 "fax" attributes, containing full E.164 numbers
   o  up to 10 "email" attributes

   Basically, all attributes are optional.  In case an address section
   is used, several components are mandatory for conformance with the
   E.115 [1] recommendation.  The reason for this is that "computerized



Mayrhofer, et al.        Expires April 7, 2005                  [Page 6]

Internet-Draft        ENUM Validation Architecture          October 2004


   directory assistance" accessible through the E.115 interface may be a
   source of validation information.

5.2  Signature

   The validation token is generated by a validation entity and passed
   via a registrar to the registry which then acts upon the content of
   the token.  A digital signature on the token guarantees that
   o  the token was indeed generated by the indicated VE (authenticity)
   o  the token was not tampered with in transit (integrity)
   o  auditing the validation process is possible (non-repudiation).

   The cryptographic signature on the token follows XML-DSIG [9].  As
   tokens might be transmitted as part of an already XML based protocol
   the transform as specified in [10] is used.  In order to make the
   signature an integral part of the token the "enveloped"-signature
   mode is employed.  The actual signature uses the RSA-SHA1 algorithm
   and relies on X.509 certificates.

   This document does not dictate a public key infrastructure.  Whether
   the registry acts as a certificate authority, accepts certs from a
   public CA, or only accepts pre-registered keys is a local policy
   choice.

5.3  Examples

5.3.1  Unsigned token without subscriber information

   This format encompasses other proposals concerning ENUM validation
   which describe a simple flag that indicates a successful validation.


   <?xml version="1.0" encoding="utf-8" standalone="no" ?>
   <token xmlns="http://www.enum.at/xsd/enum-token-1.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation=
         "http://www.enum.at/xsd/enum-token-1.0 enum-token-1.0.xsd">
     <validation serial="4711-7654321">
       <e164number>+43123456789</e164number>
       <validator>4711</validator>
       <registrarid>42</registrarid>
       <method>1</method>
       <createdate>2004-10-07</createdate>
       <expiredate>2005-04-07</expiredate>
     </validation>
   </token>





Mayrhofer, et al.        Expires April 7, 2005                  [Page 7]

Internet-Draft        ENUM Validation Architecture          October 2004


5.3.2  Unsigned token with subscriber information


   <?xml version="1.0" encoding="utf-8" standalone="no" ?>
   <token xmlns="http://www.enum.at/xsd/enum-token-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation=
         "http://www.enum.at/xsd/enum-token-1.0 enum-token-1.0.xsd">
     <validation serial="4711-1234567">
       <e164number>+43123456789</e164number>
       <validator>4711</validator>
       <registrarid>42</registrarid>
       <method>1</method>
       <createdate>2004-10-07</createdate>
       <expiredate>2005-04-07</expiredate>
     </validation>
     <tokendata xmlns="http://www.enum.at/xsd/enum-tokendata-1.0"
       xsi:schemaLocation=
       "http://www.enum.at/xsd/enum-tokendata-1.0 enum-tokendata-1.0.xsd">
       <contact>
         <organisation>Demo-org Inc.</organisation>
         <commercialregisternumber>DO-2345678</commercialregisternumber>
         <title>Dr.</title>
         <firstname>Max</firstname>
         <lastname>Mustermann</lastname>
         <address>
           <streetname>Lindenstrasse</streetname>
           <streetnumber>42</streetnumber>
           <apartment>4711</apartment>
           <postalcode>1010</postalcode>
           <city>Wien</city>
           <state>n/a</state>
           <country>AT</country>
         </address>
         <phone>+431234412</phone>
         <fax>+431234412512</fax>
         <email>mail1@example.com</email>
         <email>mail2@example.com</email>
       </contact>
     </tokendata>
   </token>



5.3.3  Signed token

   This example uses an X.509 based signature which includes the
   certificate of the signing validation entity.  Thus the validity of



Mayrhofer, et al.        Expires April 7, 2005                  [Page 8]

Internet-Draft        ENUM Validation Architecture          October 2004


   the signature can be verified without the need for a keyserver.

   For improved legibility, the example token has been reformatted, and
   parts of the certificate and actual signature have been removed.  The
   text below should be considered prototypic, and is not a valid token.


   <token Id="TOKEN" xmlns="http://www.enum.at/xsd/enum-token-1.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation=
        "http://www.enum.at/xsd/enum-token-1.0 enum-token-1.0.xsd">
     <validation serial="4711-1234567">
       <e164number>+43123456789</e164number>
       <validator>4711</validator>
       <registrarid>42</registrarid>
       <method>1</method>
       <createdate>2004-10-07</createdate>
       <expiredate>2005-04-07</expiredate>
     </validation>
     <tokendata xmlns="http://www.enum.at/xsd/enum-tokendata-1.0"
        xsi:schemaLocation=
        "http://www.enum.at/xsd/enum-tokendata-1.0
                  enum-tokendata-1.0.xsd">
       <contact>
         <organisation>Demo-org Inc.</organisation>
         <commercialregisternumber>DO-2345678</commercialregisternumber>
         <title>Dr.</title>
         <firstname>Max</firstname>
         <lastname>Mustermann</lastname>
         <address>
           <streetname>Lindenstrasse</streetname>
           <streetnumber>42</streetnumber>
           <apartment>4711</apartment>
           <postalcode>1010</postalcode>
           <city>Wien</city>
           <state>n/a</state>
           <country>AT</country>
         </address>
         <phone>+431234412</phone>
         <fax>+431234412512</fax>
         <email>mail1@example.com</email>
         <email>mail2@example.com</email>
       </contact>
     </tokendata>
   <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
     <SignedInfo>
       <CanonicalizationMethod
         Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>



Mayrhofer, et al.        Expires April 7, 2005                  [Page 9]

Internet-Draft        ENUM Validation Architecture          October 2004


       <SignatureMethod
         Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
       <Reference URI="#TOKEN">
       <Transforms>
         <Transform Algorithm=
         	"http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
         <Transform Algorithm=
           "http://www.w3.org/2001/10/xml-exc-c14n#">
   	<InclusiveNamespaces
   	   PrefixList="enum-token enum-tokendata"
   	   xmlns="http://www.w3.org/2001/10/xml-exc-c14n#"/>
         </Transform>
       </Transforms>
       <DigestMethod Algorithm=
       	"http://www.w3.org/2000/09/xmldsig#sha1"/>
       <DigestValue>nx1li5twhfh/wrXm5JvANBxGPAg=</DigestValue>
       </Reference>
     </SignedInfo>
   <SignatureValue>iw+xek4sGOzI4/rlNXTvpmC1o//u2SM

   [...]

   4wLKpao74qmgX/R2r2G5m3xoRhjmMzX+LI0Y9UywMkk=</SignatureValue>
   <KeyInfo>
     <X509Data>
       <X509Certificate>MIIDZjCCAs+gAwIBAgIBBDANBgk

   [...]

   MvwKYwhcpQ9UdM/w7VpXQqf+CEj0XSyqxGw65UsHIOijgiG/WyhSj+Lzriw7CTge
   P2iAJkJVC4t2XA==
       </X509Certificate>
     </X509Data>
   </KeyInfo>
   </Signature></token>




6.  Formal Syntax

   The formal syntax of the validation token is specified using XML
   schema notation [7][8].  Two schemas are defined: The "token core
   schema" contains mandatory attribute definitions, the "token data
   schema" defines the format of the optional "tokendata" section.






Mayrhofer, et al.        Expires April 7, 2005                 [Page 10]

Internet-Draft        ENUM Validation Architecture          October 2004


6.1  Token Core Schema


   <?xml version="1.0" encoding="UTF-8"?>
     <schema targetNamespace="http://www.enum.at/xsd/enum-token-1.0"
       xmlns:enum-token="http://www.enum.at/xsd/enum-token-1.0"
       xmlns:enum-tokendata="http://www.enum.at/xsd/enum-token-data-1.0"
       xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
       xmlns="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified">

       <import namespace="http://www.w3.org/2000/09/xmldsig#"
         schemaLocation="xmldsig-core-schema.xsd"/>
       <import namespace="http://www.enum.at/xsd/enum-token-data-1.0"
         schemaLocation="enum-tokendata-1.0.xsd"/>

       <annotation>
         <documentation>
           enum.at Validation Token Format 1.0
         </documentation>
       </annotation>

       <element name="token" type="enum-token:tokenBaseType"/>

       <simpleType name="serialType">
         <restriction base="string">
           <pattern value="[a-zA-Z0-9\-]+"/>
           <minLength value="1"/>
           <maxLength value="40"/>
         </restriction>
       </simpleType>

       <simpleType name="e164Type">
         <restriction base="token">
           <maxLength value="25"/>
           <pattern value="\+\d+"/>
         </restriction>
       </simpleType>

       <complexType name="valDataType">
         <sequence>
           <element name="e164number" type="enum-token:e164Type"/>
           <element name="validator" type="unsignedInt"/>
           <element name="registrarid" type="unsignedInt"/>
           <element name="method" type="unsignedInt"/>
           <element name="createdate" type="date"/>
           <element name="expiredate" type="date"/>
         </sequence>



Mayrhofer, et al.        Expires April 7, 2005                 [Page 11]

Internet-Draft        ENUM Validation Architecture          October 2004


         <attribute name="serial" type="enum-token:serialType"
          use="required"/>
       </complexType>

       <complexType name="tokenBaseType">
         <sequence>
           <element name="validation" type="enum-token:valDataType"/>
           <any namespace="http://www.enum.at/xsd/enum-token-data-1.0"
            minOccurs="0"/>
           <any namespace="http://www.w3.org/2000/09/xmldsig#"/>
         </sequence>
         <attribute name="Id" type="ID" use="required"/>
       </complexType>
     </schema>



6.2  Token Data Schema

   <?xml version="1.0" encoding="UTF-8"?>

     <schema targetNamespace="http://www.enum.at/xsd/enum-token-data-1.0"
       xmlns:enum-td="http://www.enum.at/xsd/enum-token-data-1.0"
       xmlns="http://www.w3.org/2001/XMLSchema"
       elementFormDefault="qualified">

       <annotation>
         <documentation>
           enum.at Validation Token Format 1.0
           optional tokendata format definition
         </documentation>
       </annotation>

       <element name="tokendata" type="enum-td:tokenDataType"/>

       <simpleType name="e164Type">
         <restriction base="token">
           <maxLength value="25"/>
           <pattern value="\+\d+"/>
         </restriction>
       </simpleType>

       <simpleType name="shortTokenType">
         <restriction base="token">
           <maxLenght value="20"/>
   	<minLength value="1"/>
         <restriction>
       </simpleType>



Mayrhofer, et al.        Expires April 7, 2005                 [Page 12]

Internet-Draft        ENUM Validation Architecture          October 2004


       <simpleType name="longTokenType">
         <restriction base="token">
           <maxLenght value="60"/>
   	<minLength value="1"/>
         <restriction>
       </simpleType>

       <simpleType name="emailType">
         <restriction base="token">
           <minLength value="4"/>
           <maxLength value="64"/>
           <pattern value=".+@.+\..+"/>
         </restriction>
       </simpleType>

       <complexType name="addressType">
         <sequence>
           <element name="streetname" type="enum-td:longTokenType"/>
           <element name="streetnumber" type="enum-td:shortTokenType"/>
           <element name="apartment" type="enum-td:shortTokenType"
            minOccurs="0"/>
           <element name="postalcode" type="enum-td:shortTokenType"/>
           <element name="city" type="enum-td:shortTokenType"/>
           <element name="state" type="enum-td:shortTokenType"
            minOccurs="0"/>
           <element name="country" type="enum-td:shortTokenType"/>
         </sequence>
       </complexType>

       <group name="tokenContactBaseGroup">
         <sequence>
           <element name="organisation" type="enum-td:longTokenType"
            minOccurs="0"/>
           <element name="commercialregisternumber"
                   type="enum-td:shortTokenType"
            minOccurs="0"/>
           <element name="title" type="enum-td:shortTokenType"
            minOccurs="0"/>
           <element name="firstname" type="enum-td:longTokenType"
            minOccurs="0"/>
           <element name="lastname" type="enum-td:longTokenType"
            minOccurs="0"/>
           <element name="address" type="enum-td:addressType"
            minOccurs="0"/>
           <element name="phone" type="enum-td:e164type"
            minOccurs="0" maxOccurs="10" />
           <element name="fax" type="enum-td:e164type"
            minOccurs="0" maxOccurs="10" />



Mayrhofer, et al.        Expires April 7, 2005                 [Page 13]

Internet-Draft        ENUM Validation Architecture          October 2004


           <element name="email" type="enum-td:emailType"
            minOccurs="0" maxOccurs="10" />
         </sequence>
       </group>

       <complexType name="contactType">
         <sequence>
           <group ref="enum-td:tokenContactBaseGroup"/>
         </sequence>
       </complexType>

       <complexType name="tokenDataType">
         <sequence>
           <element name="contact" type="enum-td:contactType"/>
         </sequence>
       </complexType>

     </schema>

7.  Wider applicability

   The basic idea of this validation token can be helpful to other
   registries where any request for a delegation must be accompanied by
   a proof of ownership.

   One example are all the specialized TLDs with strict rules on who
   qualifies for registering a domain under that TLD.

   Even liberal TLDs could make use of validation tokens during a
   sunrise phase, where only applicants with a prior right to a name are
   allowed to register a domain.

   Moving away from the domain business, telephone number portablity
   verification needs to solve roughly the same validation problem as
   the ENUM domain delegation.  A formalized system based on signed
   tokens could replace the manual process used in many countries.

8  References

   [1]   ITU-T, "Computerized Directory Assistance", Recommendation
         E.115, February 1995.

   [2]   Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
         Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
         Application (ENUM)", RFC 3761, April 2004.

   [3]   Eastlake, D., Reagle, J. and D. Solo, "(Extensible Markup
         Language) XML-Signature Syntax and Processing", RFC 3275, March



Mayrhofer, et al.        Expires April 7, 2005                 [Page 14]

Internet-Draft        ENUM Validation Architecture          October 2004


         2002.

   [4]   Klyne, G. and C. Newman, "Date and Time on the Internet:
         Timestamps", RFC 3339, July 2002.

   [5]   Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC
         3730, March 2004.

   [6]   Paoli, J., Sperberg-McQueen, C., Bray, T. and E. Maler,
         "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
         FirstEdition REC-xml-20001006, October 2000.

   [7]   Maloney, M., Beech, D., Mendelsohn, N. and H. Thompson, "XML
         Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502,
         May 2001.

   [8]   Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", W3C
         REC REC-xmlschema-2-20010502, May 2001.

   [9]   Solo, D., Reagle, J. and D. Eastlake, "XML-Signature Syntax and
         Processing", W3C REC REC-xmldsig-core-20020212, February 2002.

   [10]  3rd, D., Boyer, J. and J. Reagle, "Exclusive XML
         Canonicalization Version 1.0", W3C REC
         REC-xml-exc-c14n-20020718, July 2002.


Authors' Addresses

   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/













Mayrhofer, et al.        Expires April 7, 2005                 [Page 15]

Internet-Draft        ENUM Validation Architecture          October 2004


   Otmar Lendl
   enum.at GmbH
   Karlsplatz 1/9
   Wien  A-1010
   Austria

   Phone: +43 1 5056416 33
   EMail: otmar.lendl@enum.at
   URI:   http://www.enum.at/


   Michael Haberler
   Internet Foundation Austria
   Waehringerstrasse 3/18
   Wien  A-1090
   Austria

   Phone: +43 664 4213465
   EMail: mah@eunet.at
   URI:   http://www.nic.at/ipa/































Mayrhofer, et al.        Expires April 7, 2005                 [Page 16]

Internet-Draft        ENUM Validation Architecture          October 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Mayrhofer, et al.        Expires April 7, 2005                 [Page 17]