From: http://www.ietf.org/internet-drafts/draft-chung-idnop-epp-idn-00.txt
EPP Internationalized Domain Name Mapping
Reference: draft-chung-idnop-epp-idn-00.txt

-------------------------------------------------------------------------

                                               Edmon Chung & Henry Tong 
Internet Draft                                                   Neteka 
<draft-chung-idnop-epp-idn-00.txt>                                      
                                                             April 2003 
 
 
               EPP Internationalized Domain Name Mapping 
 
 
STATUS OF THIS MEMO 
 
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026.  
    
   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 reader is cautioned not to depend on the values that appear in 
   examples to be current or complete, since their purpose is primarily 
   educational.  Distribution of this memo is unlimited. 
    
   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.  
    
Abstract 
    
   This document describes an Extensible Provisioning Protocol (EPP) 
   mapping for the provisioning and management of Internationalized 
   Internet domain names (that includes English alphanumeric domain 
   names) stored in a shared central repository.  Specified in XML, the 
   mapping defines EPP command syntax and semantics as applied to domain 
   names. 
    
   More specifically, EPP-IDN intends to provide a mechanism for 
   explicitly managing and provisioning Reserved Variants and Zone 
   Variants created for a Primary Domain Name. 
    
Conventions Used In This Document 
    
   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 [RFC2119]. 
    
   In examples, "C:" represents lines sent by a protocol client and "S:" 
   represents lines returned by a protocol server.  Indentation and 
   white space in examples is provided only to illustrate element 
   relationships and is not a REQUIRED feature of this protocol. 
  
Chung & Tong                                                   [Page 1] 
EPP-IDN                                                      April 2003 
 
 
Table of Contents 
    
   1. Introduction....................................................2 
   1.1 Relationship of IDN Objects and Domain Objects.................2 
   2. Object Attributes...............................................3 
   2.1 Domain, Host and Name Server Names.............................3 
   2.2 Status Values..................................................4 
   3. EPP Command Mapping.............................................4 
   3.1 EPP Query Commands.............................................4 
   3.1.1 EPP <check> Command..........................................4 
   3.1.2 EPP <info> Command...........................................7 
   3.1.2.1 <idn:info> command.........................................7 
   3.1.2.2 <idn:varInfo> command......................................9 
   3.1.3 EPP <transfer> Query Command................................11 
   3.2 EPP Transform Commands........................................11 
   3.2.1 EPP <create> Command........................................11 
   3.2.2 EPP <delete> Command........................................15 
   3.2.3 EPP <renew> Command.........................................15 
   3.2.4 EPP <transfer> Command......................................15 
   3.2.5 EPP <update> Command........................................15 
   3.2.6 Offline Review of Requested Actions.........................18 
   4. Formal Syntax..................................................20 
   5. Internationalization Considerations............................20 
   6. IANA Considerations............................................20 
   7. Security Considerations........................................20 
    
1. Introduction 
    
   This document describes an Internationalized Internet domain name 
   (IDN) mapping for version 1.0 of the Extensible Provisioning Protocol 
   (EPP).  This mapping is specified using the Extensible Markup 
   Language (XML) 1.0 as described in [XML] and XML Schema notation as 
   described in [XMLS-1] and [XMLS-2]. 
    
   [EPP] provides a complete description of EPP command and response 
   structures.  A thorough understanding of the base protocol 
   specification is necessary to understand the mapping described in 
   this document. 
    
   XML is case sensitive.  Unless stated otherwise, XML specifications 
   and examples provided in this document MUST be interpreted in the 
   character case presented to develop a conforming implementation. 
    
1.1 Relationship of IDN Objects and Domain Objects 
    
   This document assumes that IDN objects have a subordinate 
   relationship to a superordinate domain name object.  An IDN object 
   contains a set of IDN variants, this entire set being a subordinate 
   object for the superordinate domain name object, known as the Primary 
   Domain for the IDN object. 
    
   For example, a primary domain "example.com" has a superoordinate 
   relationship to the IDN Object (which is a set of domain names û IDN 
  
Chung & Tong                                                   [Page 2] 
EPP-IDN                                                      April 2003 
 
 
   Variants):{"variant1.com";"variant2.com";..."variantX.com"}.  EPP 
   actions (such as object transfers) that do not preserve this 
   relationship MUST be explicitly disallowed. 
    
   An IDN object MUST NOT be created in a repository for which no 
   superordinate domain name (primary domain) object exists.  Also, the 
   creation of an IDN object cannot be initiated by the client, but 
   rather MUST be generated upon creation of a subperordinate domain 
   object.  An IDN obejct MAY be updated by a client afterwards.  The 
   <create> command for this specification therefore is intended to be 
   used to create the primary domain of the IDN obejct instead of an IDN 
   object itself. 
    
   An IDN variant, however may be expressly created and/or modified by 
   the client using an <update> command.  The rationalities for 
   particular types of IDN variants are not discussed within this 
   document.  For further information, please refer to [Charprep] and 
   [Zoneprep]. 
    
2. Object Attributes 
    
   An EPP IDN object has attributes and associated values that can be 
   viewed and modified by the sponsoring client or the server.  This 
   section describes each attribute type in detail.  The formal syntax 
   for the attribute values described here can be found in the "Formal 
   Syntax" section of this document and in the appropriate normative 
   references. 
    
2.1 Domain, Host and Name Server Names 
    
   Internationalized domain, host and name server names, as specified in 
   [RFC3490], described in this document MUST inherit the 
   internationalization conventions expressed in [EPP]: "EPP is 
   represented in XML, which provides native support for encoding 
   information using the Unicode character set and its more compact 
   representations including UTF-8 [RFC2279].  Conformant XML processors 
   recognize both UTF-8 and UTF-16 [RFC2781].  Though XML includes 
   provisions to identify and use other character encodings through use 
   of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is 
   RECOMMENDED in environments where parser encoding support 
   incompatibility exists." 
    
   Additionally, all internationalized domain, host and name server 
   names must be a fully qualified IDN as determined by [RFC3490] and 
   [RFC3491].  Note however that the transport format SHOULD NOT be in 
   an ACE format and SHOULD follow the conventions expressed in [EPP]. 
    
   The syntax for non-internationalized domain, host and name server 
   names described in this document MUST conform to [RFC952] as updated 
   by [RFC1123].  These conformance requirements might change as a 
   result of progressing work in developing standards for 
   internationalized domain names.   
    
  
Chung & Tong                                                   [Page 3] 
EPP-IDN                                                      April 2003 
 
 
   A server MAY restrict allowable domain names to a particular top 
   level domain, second level domain, or other domain for which the 
   server is authoritative.  The trailing dot required when these names 
   are stored in a DNS zone is implicit and MUST NOT be provided when 
   exchanging domain, host and name server names. 
    
2.2 Status Values 
    
   An IDN object contains a set of domain names, better described as IDN 
   Variants, which in turn MAY have name server attributes as well as 
   subordinated host objects.  Statuses for these attributes will be 
   further discussed in Section 3.  An IDN object DO NOT have its own 
   independent status, and will inherit the statuses determined by its 
   superordinate domain object, i.e. its primary domain. 
    
3. EPP Command Mapping 
    
   A detailed description of the EPP syntax and semantics can be found 
   in [EPP].  The command mappings described here are specifically for 
   use in provisioning and managing IDN Objects, which contain a set of 
   IDN Variants (Internationalized domain names), as a subordinate of a 
   primary domain (domain object) via EPP. 
    
3.1 EPP Query Commands 
    
   EPP provides three commands to retrieve domain information: <check> 
   to determine if a domain object can be provisioned within a 
   repository, <info> to retrieve detailed information associated with a 
   domain object, and <transfer> to retrieve domain object transfer 
   status information. 
    
3.1.1 EPP <check> Command 
    
   The EPP <check> command is used to determine if an object can be 
   provisioned within a repository.  In the case of an IDN object, a 
   <check> command returns the manageability (in other words, 
   specifically what elements within the IDN object can be provisioned) 
   of each IDN variant that is contained in the IDN object.  It may also 
   be used as a generic <check> command to discover whether the primary 
   domain can be provisioned, together with the availability and 
   manageability of its set of IDN variants. 
    
   In addition to the standard EPP command elements, the <check> command 
   must contain an <idn:check> element that identifies the IDN namespace 
   and the location of the IDN schema.  The <idn:check> element contains 
   one or more <idn:primary> elements that contain the following child 
   elements: 
    
   - An <idn:name> element that contains a fully qualified name of the 
   domain objects to be queried. 
    
   - One or more OPTIONAL <idn:lang> element that contains an attribute 
   "l" identifying the language of the queried primary domain.  If the 
  
Chung & Tong                                                   [Page 4] 
EPP-IDN                                                      April 2003 
 
 
   "l" attribute is not set, AND the domain in question does NOT exist, 
   then the default value will be l="undefined".  The value of the "l" 
   attribute MUST be a language code defined in the ISO639-2 standard 
   presented as specified by [RFC3066] or "undefined" indicating that 
   the language is undefined. 
    
   Example <check> command: 
    
   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
   C:     epp-1.0.xsd"> 
   C:  <command> 
   C:    <check> 
   C:      <idn:check 
   C:       xmlns:idn="urn:ietf:params:xml:ns:idn-1.0" 
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0 
   C:       idn-1.0.xsd"> 
   C:        <idn:primary> 
   C:          <idn:name>example.com</idn:name> 
   C:          <idn:lang l="en"/> 
   C:        </idn:primary> 
   C:        <idn:primary> 
   C:          <idn:name>example.net</idn:name> 
   C:        </idn:primary> 
   C:      </domain:check> 
   C:    </check> 
   C:    <clTRID>ABC-12345</clTRID> 
   C:  </command> 
   C:</epp> 
    
   When a <check> command has been processed successfully, the EPP 
   <resData> element MUST contain a child <idn:chkData> element that 
   identifies the IDN namespace and the location of the IDN schema. The 
   <idn:chkData> element contains one or more <idn:cd> elements that 
   contain the following child elements: 
    
   - An <idn:primary> element that contains the fully qualified name of 
   the queried domain object (primary domain).  This element MUST 
   contain an "avail" attribute whose value indicates object 
   availability (does the primary domain exist or not) at the moment the 
   <check> command was completed. A value of "1" or "true" means that 
   the object does NOT exist.  A value of "0" or "false" means that the 
   object already exists. 
    
   - An OPTIONAL <idn:reason> element that MAY be provided when an 
   object can not be provisioned.  If present, this element contains 
   server-specific text to help explain why the object can not be 
   provisioned.  This text MUST be represented in the response language 
   previously negotiated with the client; an OPTIONAL "lang" attribute 
   MAY be present to identify the language if the negotiated value is 
   something other than the default value of "en" (English). 
  
Chung & Tong                                                   [Page 5] 
EPP-IDN                                                      April 2003 
 
 
    
   - One or more OPTIONAL <idn:name> elements that contain IDN variants 
   that correspond to the queried primary domain.  This element MAY 
   contain an availability "a" attribute whose value indicates object 
   availability (does the primary domain exist or not) at the moment the 
   <check> command was completed.  A value of "1" or "true" means that 
   the object does NOT exist.  A value of "0" or "false" means that the 
   object already exists.  If the registry policy is to by default 
   reserve all character equivalency variants, then the "a" attribute 
   will not be required. 
    
   If the primary domain exists and the variant availability value = 
   "true", it means that the particular IDN variant MAY be provisioned 
   by the client as a Reserved Variant.  Further manageability will 
   depend on the following two OPTIONAL attributes 
    
   The two OPTIONAL attributes identified as Reserved Variant Type ("r") 
   and Zone Variant Type ("z") describe the manageability of the IDN 
   variant based on the policy determined by the registry.   
    
   For "r", a value of "nRV" means that the IDN Variant is a Normal 
   Reserved Variants (nRV), which can be further provisioned and 
   activated as a Zone Variant.  A value of "rRV" indicates that the IDN 
   Variant is a Restricted Reserved Variants (rRV), which cannot be 
   further provisioned.  A value of "aZV" identifies that the IDN 
   Variant will automatically be included as Zone Variants, further 
   provisioning capability will depend on the "z" value. 
    
   For "z", a value of "N" returns a list of the Normal Zone Variants.  
   A value of "S" returns a list of the Zone Variants mandated to have 
   same name server delegations as its primary domain (by registry 
   policy).  A value of "A" returns a list of Zone Variants mandated to 
   be aliased to the primary domain name (by registry policy). 
    
   Example <check> response: 
    
   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
   S:     epp-1.0.xsd"> 
   S:  <response> 
   S:    <result code="1000"> 
   S:      <msg>Command completed successfully</msg> 
   S:    </result> 
   S:    <resData> 
   S:      <idn:chkData 
   S:       xmlns:idn="urn:ietf:params:xml:ns:idn-1.0" 
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0 
   S:       idn-1.0.xsd"> 
   S:        <idn:cd> 
   S:          <idn:primary avail="0">example.com</idn:primary> 
   S:          <idn:name a="1" r="nRV" z="N">variant1.com</idn:name> 
  
Chung & Tong                                                   [Page 6] 
EPP-IDN                                                      April 2003 
 
 
   S:          <idn:name a="1" r="nRV" z="S">variant2.com</idn:name> 
   S:          <idn:name a="1" r="rRV">variant3.com</idn:name> 
   S:          <idn:name a="1" r="aZV" z="A">variant4.com</idn:name> 
   S:          <idn:name a="1" r="nRV" z="N">variant5.com</idn:name> 
   S:          <idn:name a="0" r="nRV" z="N">variant6.com</idn:name> 
   S:        </idn:cd> 
   S:        <idn:cd> 
   S:          <idn:primary avail="1">example.net</idn:primary> 
   S:          <idn:reason>In use</idn:reason> 
   S:          <idn:name a="0" r="nRV" z="N">variantA.com</idn:name> 
   S:          <idn:name a="0" r="nRV" z="N">variantB.com</idn:name> 
   S:          <idn:name a="1" r="nRV" z="N">variantC.com</idn:name> 
   S:        </domain:cd> 
   S:      </domain:chkData> 
   S:    </resData> 
   S:    <trID> 
   S:      <clTRID>ABC-12345</clTRID> 
   S:      <svTRID>54322-XYZ</svTRID> 
   S:    </trID> 
   S:  </response> 
   S:</epp> 
    
   An EPP error response MUST be returned if a <check> command cannot be 
   processed for any reason. 
    
3.1.2 EPP <info> Command 
    
   The EPP <info> command is used to retrieve information associated 
   with an IDN object.  There are two types of EPP <info> commands 
   defined in this specifcation.  An <idn:info> command that retrieves 
   overall information of the IDN object for a given primary domain, and 
   an <idn:varInfo> command that retrieves detailed information of a 
   particular IDN variant (within the IDN object). 
    
3.1.2.1 <idn:info> command 
    
   To retrieve overall information about an IDN object, i.e. the 
   existing set of IDN variants within the set and their respective 
   statuses, the <idn:info> command is used.  In addition to the 
   standard EPP command elements, the <info> command MUST contain an 
   <idn:info> element that identifies the IDN namespace and the location 
   of the IDN schema.  The <idn:info> element contains an <idn:primary> 
   element that contains the fully qualified name of the domain object 
   that identifies the IDN object (which in essense is the name of the 
   superordinate domain object, or primary domain) to be queried.  Two 
   OPTIONAL attributes are available to control return of information 
   describing elements related to the IDN object.   
    
   The two attributes are identified as the Reserved Variant Type ("r") 
   and the Zone Variant Type ("z") respectively. 
    
   For "r", a value of "all" returns the entire list of Reserved 
   Variants.  A value of "nRV" returns a list of the Normal Reserved 
  
Chung & Tong                                                   [Page 7] 
EPP-IDN                                                      April 2003 
 
 
   Variants (nRV).  A value of "rRV" returns a list of the Restricted 
   Reserved Variants (rRV).  A value of "AutoZV" returns a list of 
   Automatic Zone Variants. 
    
   For "z", a value of "all" returns the entire list of Zone Variants.  
   A value of "N" returns a list of the Normal Zone Variants.  A value 
   of "S" returns a list of the Zone Variants mandated to have same name 
   server delegations as its primary domain (by registry policy).  A 
   value of "A" returns a list of Zone Variants mandated to be aliased 
   to the primary domain name (by registry policy) 
    
   If "r" is set to "all", there SHOULD NOT be a "z" attribute.  If both 
   attributes are present, IDN Variants that satisfy any one of the 
   attribute will be returned.  If none of the attributes are present, 
   all of the IDN Variants within the IDN object will be returned. 
    
   Example <info> command: 
    
   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
   C:     epp-1.0.xsd"> 
   C:  <command> 
   C:    <info> 
   C:      <idn:info 
   C:       xmlns:idn="urn:ietf:params:xml:ns:idn-1.0" 
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0 
   C:       idn-1.0.xsd"> 
   C:        <idn:primary r="nRV" z="S">example.com</idn:primary> 
   C:      </idn:info> 
   C:    </info> 
   C:    <clTRID>ABC-12345</clTRID> 
   C:  </command> 
   C:</epp> 
    
   When an <info> command has been processed successfully, the EPP 
   <resData> element MUST contain a child <idn:infData> element that 
   identifies the IDN namespace and the location of the IDN schema.  The 
   <idn:infData> element contains the following child elements: 
    
   - An <idn:primary> element that contains the fully qualified name of 
   the domain object that identifies the IDN object (which in essence is 
   the name of the superordinate domain object, or primary domain) 
    
   - One or more <idn:name> elements that contains the fully qualified 
   name of the IDN Variant identified.  An <idn:name> element further 
   contains a "status" attribute.  A value of "active" denotes that the 
   particular reserved IDN variant has been activated as a Zone Variant.  
   A value of "inactive" denotes that the particular reserved IDN 
   variant is not a zone variant, therefore will not be published into 
   DNS zone files. 
      
  
Chung & Tong                                                   [Page 8] 
EPP-IDN                                                      April 2003 
 
 
   Example <info> response: 
    
   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
   S:     epp-1.0.xsd"> 
   S:  <response> 
   S:    <result code="1000"> 
   S:      <msg>Command completed successfully</msg> 
   S:    </result> 
   S:    <resData> 
   S:      <idn:infData 
   S:       xmlns:idn="urn:ietf:params:xml:ns:idn-1.0" 
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0 
   S:       idn-1.0.xsd"> 
   S:        <idn:name status="active">variant1.com</idn:name> 
   S:        <idn:name status="inactive">variant2.com</idn:name> 
   S:      </idn:infData> 
   S:    </resData> 
   S:    <trID> 
   S:      <clTRID>ABC-12345</clTRID> 
   S:      <svTRID>54322-XYZ</svTRID> 
   S:    </trID> 
   S:  </response> 
   S:</epp> 
    
   An EPP error response MUST be returned if an <info> command cannot be 
   processed for any reason. 
    
3.1.2.2 <idn:varInfo> command 
    
   To retrieve specific information about an IDN Variant within an IDN 
   Object, i.e. the delegation Name Servers and hosts for a given IDN 
   variant, the <idn:varInfo> command is used.  In addition to the 
   standard EPP command elements, the <info> command MUST contain an 
   <idn:varInfo> element that identifies the IDN namespace and the 
   location of the IDN schema.  The <idn:varInfo> element contains an 
   <idn:name> element that contains the fully qualified name that 
   identifies the IDN Variant to be queried.  An OPTIONAL "hosts" 
   attribute is available to control return of information describing 
   hosts related to the IDN Variant.  A value of "all" (the default, 
   which MAY be absent) returns information describing both subordinate 
   and delegated hosts.  A value of "del" returns information describing 
   only delegate hosts.  A value of "sub" returns information describing 
   only subordinate hosts.  A value of "none" returns no information 
   describing delegated or subordinate hosts. 
    
   Example <info> command: 
    
   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  
Chung & Tong                                                   [Page 9] 
EPP-IDN                                                      April 2003 
 
 
   C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
   C:     epp-1.0.xsd"> 
   C:  <command> 
   C:    <info> 
   C:      <idn:info 
   C:       xmlns:idn="urn:ietf:params:xml:ns:idn-1.0" 
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0 
   C:       idn-1.0.xsd"> 
   C:        <idn:name hosts="all">variant1.com</idn:name> 
   C:      </idn:info> 
   C:    </info> 
   C:    <clTRID>ABC-12345</clTRID> 
   C:  </command> 
   C:</epp> 
    
   When the <info> command has been processed successfully, the EPP 
   <resData> element MUST contain a child <idn:infData> element that 
   identifies the IDN namespace and the location of the IDN schema.  The 
   <idn:infData> element contains the following child elements: 
    
   - An <idn:name> element that contains the fully qualified name that 
   identifies the IDN Variant. 
    
   - Zero or more OPTIONAL <idn:ns> elements that contain the fully 
   qualified names of the delegated host objects (name servers) 
   associated with this IDN variant. 
    
   - Zero or more OPTIONAL <idn:host> elements that contain the fully 
   qualified names of the subordinate host objects that exist under 
   this superordinate IDN variant. 
    
   - An OPTIONAL <idn:status> element that contain the current status 
   ("s") descriptors associated with the IDN variant.  A value of 
   "activated" denotes that the particular reserved IDN variant has 
   been activated as a Zone Variant.  A value of "inactive" denotes 
   that the particular reserved IDN variant is not a zone variant, 
   therefore will not be published into DNS zone files. 
    
   The <idn:status> element MUST be included if the RV type defined is 
   NOT "rRV". 
    
   Example <info> response: 
    
   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
   S:     epp-1.0.xsd"> 
   S:  <response> 
   S:    <result code="1000"> 
   S:      <msg>Command completed successfully</msg> 
   S:    </result> 
   S:    <resData> 
  
Chung & Tong                                                  [Page 10] 
EPP-IDN                                                      April 2003 
 
 
   S:      <idn:infData 
   S:       xmlns:idn="urn:ietf:params:xml:ns:idn-1.0" 
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0 
   S:       idn-1.0.xsd"> 
   S:        <idn:name>variant1.com</idn:name> 
   S:        <idn:ns>ns1.example.com</idn:ns> 
   S:        <idn:host>ns1.variant1.com</idn:host> 
   S:        <idn:status s="active"/> 
   S:      </idn:infData> 
   S:    </resData> 
   S:    <trID> 
   S:      <clTRID>ABC-12345</clTRID> 
   S:      <svTRID>54322-XYZ</svTRID> 
   S:    </trID> 
   S:  </response> 
   S:</epp> 
    
   An EPP error response MUST be returned if an <info> command cannot be 
   processed for any reason. 
    
3.1.3 EPP <transfer> Query Command 
    
   Transfer semantics do not directly apply to IDN objects, so there is 
   no mapping defined for the EPP <transfer> query command. 
    
3.2 EPP Transform Commands 
    
   EPP provides five commands to transform domain objects: <create> to 
   create an instance of a domain object, <delete> to delete an instance 
   of a domain object, <renew> to extend the validity period of a domain 
   object, <transfer> to manage domain object sponsorship changes, and 
   <update> to change information associated with a domain object. 
    
   Transform commands are typically processed and completed in real 
   time.  Server operators MAY receive and process transform commands, 
   but defer completing the requested action if human or third-party 
   review is required before the requested action can be completed.  In 
   such situations the server MUST return a 1001 response code to the 
   client to note that the command has been received and processed, but 
   the  requested action is pending.  The server MUST also manage the 
   status of the object that is the subject of the command to reflect 
   the initiation and completion of the requested action.  Once the 
   action has been completed, all clients involved in the transaction 
   MUST be notified using a service message that the action has been 
   completed and that the status of the object has changed. 
    
3.2.1 EPP <create> Command 
    
   The EPP <create> command for this IDN mapping actually provides a 
   transform operation that allows a client to create a domain object 
   that will be the primary domain for a corresponding subordinate IDN 
   object.  In effect, it replaces the <create> command specified for 

  
Chung & Tong                                                  [Page 11] 
EPP-IDN                                                      April 2003 
 
 
   [EPP-D].  To add an IDN Variant into an IDN object, please refer to 
   Section 3.2.5 based on the <update> command. 
    
   In addition to the standard EPP command elements, the <create> 
   command MUST contain an <idn:create> element that identifies the IDN 
   namespace and the location of the IDN schema.  The <idn:create> 
   element contains the following child elements: 
    
   - A <domain:create> element that identifies the domain namespace and 
   the location of the domain schema.  The <domain:create> element 
   contains child elements as defined in [EPP-D]. 
    
   - One or more <idn:lang> element that identifies the language of the 
   domain name determined by an "l" attribute containing a value based 
   on the language code in the ISO639-2 standard further defined in 
   [RFC3066].  Additionally a value of "undefined" will be allocated by 
   default if the attribute is not defined. 
    
   Example <create> command: 
    
   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
   C:     epp-1.0.xsd"> 
   C:  <command> 
   C:    <create> 
   C:      <idn:create 
   C:       xmlns:idn="urn:ietf:params:xml:ns:idn-1.0" 
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0 
   C:       idn-1.0.xsd"> 
   C:        <domain:create 
   C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 
   C:         xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 
   C:         domain-1.0.xsd"> 
   C:          <domain:name>example.com</domain:name> 
   C:          <domain:period unit="y">2</domain:period> 
   C:          <domain:ns>ns1.example.com</domain:ns> 
   C:          <domain:ns>ns1.example.net</domain:ns> 
   C:          <domain:registrant>jd1234</domain:registrant> 
   C:          <domain:contact type="admin">sh8013</domain:contact> 
   C:          <domain:contact type="tech">sh8013</domain:contact> 
   C:          <domain:authInfo> 
   C:            <domain:pw>2fooBAR</domain:pw> 
   C:          </domain:authInfo> 
   C:        </domain:create> 
   C:        <idn:lang l="en"/> 
   C:      </idn:create> 
   C:    </create> 
   C:    <clTRID>ABC-12345</clTRID> 
   C:  </command> 
   C:</epp> 
    
  
Chung & Tong                                                  [Page 12] 
EPP-IDN                                                      April 2003 
 
 
   A client MAY also specify the IDN variants it would like to be 
   included to an IDN object upon the creation of a domain object for a 
   primary domain.   
    
   In that case, for the <idn:create> element, there MUST be One or more 
   additional child <idn:var> elements containing a child <idn:name> 
   element.  The <idn:name> element contains the fully qualified name of 
   an IDN variant. 
    
   The <idn:var> element MAY additionally have zero or more <idn:ns> 
   child elements that contain the fully qualified name of a known name 
   server host object.  A host object MUST be known to the server before 
   a name server attribute can be added or removed from a domain object.  
   The EPP mapping for host objects is described in [EPP-H]. 
    
   Example <create> command with specifications for IDN variants: 
    
   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
   C:     epp-1.0.xsd"> 
   C:  <command> 
   C:    <create> 
   C:      <idn:create 
   C:       xmlns:idn="urn:ietf:params:xml:ns:idn-1.0" 
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0 
   C:       idn-1.0.xsd"> 
   C:        <domain:create 
   C:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 
   C:         xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 
   C:         domain-1.0.xsd"> 
   C:          <domain:name>example.com</domain:name> 
   C:          <domain:period unit="y">2</domain:period> 
   C:          <domain:ns>ns1.example.com</domain:ns> 
   C:          <domain:ns>ns1.example.net</domain:ns> 
   C:          <domain:registrant>jd1234</domain:registrant> 
   C:          <domain:contact type="admin">sh8013</domain:contact> 
   C:          <domain:contact type="tech">sh8013</domain:contact> 
   C:          <domain:authInfo> 
   C:            <domain:pw>2fooBAR</domain:pw> 
   C:          </domain:authInfo> 
   C:        </domain:create> 
   C:        <idn:lang l="en"/> 
   C:        <idn:var> 
   C:          <idn:name>variant1.com</idn:name> 
   C:          <idn:ns>ns1.example.org</idn:ns> 
   C:        </idn:var> 
   C:        <idn:var><idn:name>variant2.com</idn:name></idn:var> 
   C:        <idn:var><idn:name>variant3.com</idn:name></idn:var> 
   C:        <idn:var><idn:name>variant4.com</idn:name></idn:var> 
   C:        <idn:var> 
   C:          <idn:name r="nRV">variant5.com</idn:name> 
  
Chung & Tong                                                  [Page 13] 
EPP-IDN                                                      April 2003 
 
 
   C:        </idn:var> 
   C:      </idn:create> 
   C:    </create> 
   C:    <clTRID>ABC-12345</clTRID> 
   C:  </command> 
   C:</epp> 
    
   A client SHOULD be very clear of the server policies for character 
   equivalence management before attempting to create the set of IDN 
   variants upon domain creation. 
    
   An EPP error response MUST be returned if a <create> command attempts 
   to create IDN variants that are not identified as a variant as a 
   variant based on the policies of the server or if the delegation to 
   independent name servers is not allowed. 
    
   When a <create> command has been processed successfully, the EPP 
   <resData> element MUST contain a child <idn:creData> element that 
   identifies the IDN namespace and the location of the IDN schema. The 
   <idn:creData> element contains the following child elements: 
    
   - A <domain:creData> element that identifies the domain namespace and 
   the location of the domain schema.  The <domain:creData> element 
   contains child elements as defined in [EPP-D]. 
    
   - One or more child <idn:name> elements.  Each <idn:name> element 
   contains an IDN variant, along with three attributes: "a", "r" and 
   "z".  The values to be used and their significance are the same as 
   that identified in Section 3.1.1. 
    
   Example <create> response: 
    
   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
   S:     epp-1.0.xsd"> 
   S:  <response> 
   S:    <result code="1000"> 
   S:      <msg>Command completed successfully</msg> 
   S:    </result> 
   S:    <resData> 
   S:      <idn:creData 
   S:       xmlns:idn="urn:ietf:params:xml:ns:idn-1.0" 
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0 
   S:       idn-1.0.xsd"> 
   S:        <domain:creData 
   S:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 
   S:         xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 
   S:         domain-1.0.xsd"> 
   S:          <domain:name>example.com</domain:name> 
   S:          <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> 
   S:          <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate> 
  
Chung & Tong                                                  [Page 14] 
EPP-IDN                                                      April 2003 
 
 
   S:        </domain:creData> 
   S:        <idn:name a="1" r="nRV" z="N">variant1.com</idn:name> 
   S:        <idn:name a="1" r="nRV" z="S">variant2.com</idn:name> 
   S:        <idn:name a="1" r="rRV">variant3.com</idn:name> 
   S:        <idn:name a="1" r="aZV" z="A">variant4.com</idn:name> 
   S:        <idn:name a="1" r="nRV" z="N">variant5.com</idn:name> 
   S:        <idn:name a="0" r="nRV" z="N">variant6.com</idn:name> 
   S:      </idn:creData> 
   S:    </resData> 
   S:    <trID> 
   S:      <clTRID>ABC-12345</clTRID> 
   S:      <svTRID>54321-XYZ</svTRID> 
   S:    </trID> 
   S:  </response> 
   S:</epp> 
    
   If the client included specifications for creation of the IDN 
   variants, the server MAY optionally omit the policy and availability 
   information for the IDN variants in the response. 
    
   An EPP error response MUST be returned if a <create> command cannot 
   be processed for any reason. 
    
3.2.2 EPP <delete> Command 
    
   Delete semantics do not directly apply to IDN objects, so there is no 
   mapping defined for the EPP <delete> query command.  To delete an IDN 
   variant from an IDN object, please refer to the <update> command 
   described in Section 3.2.5. 
    
3.2.3 EPP <renew> Command 
    
   Renew semantics do not directly apply to IDN objects, so there is no 
   mapping defined for the EPP <renew> query command. 
    
   It is however noted that IDN variants, potentially treated as a 
   domain object, which is a superordinate for host object, SHOULD have 
   its expiry date and time synchronized with its own superordinate 
   domain object, more specifically the primary domain of the IDN object 
   containing the particular IDN variant.  Renewal of the primary domain 
   MUST effect a renewal for all of the relevant IDN variants within the 
   subordinate IDN object. 
    
3.2.4 EPP <transfer> Command 
    
   Transfer semantics do not directly apply to IDN objects, so there is 
   no mapping defined for the EPP <transfer> query command. 
    
3.2.5 EPP <update> Command 
    
   The EPP <update> command provides a transform operation that allows a 
   client to modify the attributes of a domain object.  In addition to 
   the standard EPP command elements, the <update> command MUST contain 
  
Chung & Tong                                                  [Page 15] 
EPP-IDN                                                      April 2003 
 
 
   an <idn:update> element that identifies the IDN namespace and the 
   location of the IDN schema. The <idn:update> element contains the 
   following child elements: 
    
   - An <idn:primary> element that contains the fully qualified name of 
   the domain object that identifies the IDN object (which in essense is 
   the name of the superordinate domain object, or primary domain) to be 
   updated. 
    
   - An OPTIONAL <idn:add> element that contains attribute values to be 
   added to the object. 
    
   - An OPTIONAL <idn:rem> element that contains attribute values to be 
   removed from the object. 
    
   - An OPTIONAL <idn:chg> element that contains object attribute values 
   to be changed. 
    
   At least one <idn:add>, <idn:rem>, or <idn:chg> element MUST be 
   provided.  The <idn:add> and <idn:rem> elements contain one or more 
   <idn:var> child elements, which contains the following child 
   elements:  
    
   - An <idn:name> element that contains the fully qualified name of the 
   IDN variant to be updated, added to or removed from the IDN object. 
    
   - Zero or more <idn:ns> elements that contain the fully qualified 
   name of a known name server host object.  A host object MUST be known 
   to the server before a name server attribute can be added or removed 
   from a domain object.  The EPP mapping for host objects is described 
   in [EPP-H]. 
    
   To remove an IDN variant, there MUST NOT be any other child elements 
   except for the <idn:name> element within the particular <idn:var> 
   element. 
    
   An <idn:chg> element contains the following child elements: 
    
   - An <idn:name> element that contains the fully qualified name of the 
   IDN variant to be updated. 
    
   - An <idn:status> element that contain status values to be applied to 
   the IDN variant.  Only two statuses are defined: "ok" indicates that 
   that the IDN variant is to be included into the DNS zone files; 
   "inactive" indicates that the IDN variant is not to be included into 
   the DNS zone files of the registry. 
    
   Example <update> command: 
    
   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
  
Chung & Tong                                                  [Page 16] 
EPP-IDN                                                      April 2003 
 
 
   C:     epp-1.0.xsd"> 
   C:  <command> 
   C:    <update> 
   C:      <idn:update 
   C:       xmlns:idn="urn:ietf:params:xml:ns:idn-1.0" 
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:idn-1.0 
   C:       idn-1.0.xsd"> 
   C:        <idn:add> 
   C:          <idn:var> 
   C:            <idn:name>variant1.com</idn:name> 
   C:            <idn:ns>ns2.variant1.com</idn:ns> 
   C:            <idn:ns>ns3.variant1.com</idn:ns> 
   C:          </idn:var> 
   C:          <idn:var> 
   C:            <idn:name>variant5.com</idn:name> 
   C:            <idn:ns>ns2.variant5.com</idn:ns> 
   C:          </idn:var> 
   C:        </idn:add> 
   C:        <idn:rem> 
   C:          <idn:var> 
   C:            <idn:name>variant1.com</idn:name> 
   C:            <idn:ns>ns1.variant1.com</idn:ns> 
   C:          </idn:var> 
   C:        </idn:rem> 
   C:        <idn:rem> 
   C:          <idn:var> 
   C:            <idn:name>variant3.com</idn:name> 
   C:          </idn:var> 
   C:        </idn:rem> 
   C:        <idn:chg> 
   C:          <idn:var> 
   C:            <idn:name>variant5.com</idn:name> 
   C:            <idn:status s="activated"/> 
   C:          </idn:var> 
   C:        </idn:chg> 
   C:      </idn:update> 
   C:    </update>  
   C:    <clTRID>ABC-12345</clTRID> 
   C:  </command> 
   C:</epp> 
    
   When an <update> command has been processed successfully, a server 
   MUST respond with an EPP response with no <resData> element. 
    
   Example <update> response: 
    
   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
   S:     epp-1.0.xsd"> 
   S:  <response> 
   S:    <result code="1000"> 
  
Chung & Tong                                                  [Page 17] 
EPP-IDN                                                      April 2003 
 
 
   S:      <msg>Command completed successfully</msg> 
   S:    </result> 
   S:    <trID> 
   S:      <clTRID>ABC-12345</clTRID> 
   S:      <svTRID>54321-XYZ</svTRID> 
   S:    </trID> 
   S:  </response> 
   S:</epp> 
    
   An EPP error response MUST be returned if an <update> command can not 
   be processed for any reason. 
    
3.2.6 Offline Review of Requested Actions 
    
   Commands are processed by a server in the order they are received 
   from a client.  Though an immediate response confirming receipt and 
   processing of the command is produced by the server, a server 
   operator MAY perform an offline review of requested transform 
   commands before completing the requested action.  In such situations 
   the response from the server MUST clearly note that the transform 
   command has been received and processed, but the requested action is 
   pending.  The status of the corresponding object MUST clearly reflect 
   processing of the pending action.  The server MUST notify the client 
   when offline processing of the action has been completed. 
    
   An example describing a <create> response that required offline 
   review is included here.  Note the result code and message returned 
   in response to the <create> command. 
    
   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> 
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" 
   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 
   S:     epp-1.0.xsd"> 
   S:  <response> 
   S:    <result code="1001"> 
   S:      <msg>Command completed successfully; action pending</msg> 
   S:    </result> 
   S:    <resData> 
   S:      <idn:creData> 
   S:        <domain:creData 
   S:         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" 
   S:         xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 
   S:         domain-1.0.xsd"> 
   S:          <domain:name>example.com</domain:name> 
   S:          <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> 
   S:          <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate> 
   S:        </domain:creData> 
   S:      </idn:creData> 
   S:    </resData> 
   S:    <trID> 
   S:      <clTRID>ABC-12345</clTRID> 
   S:      <svTRID>54321-XYZ</svTRID> 
  
Chung & Tong                                                  [Page 18] 
EPP-IDN                                                      April 2003 
 
 
   S:    </trID> 
   S:  </response> 
   S:</epp> 
    
   The status of the domain object after returning this response MUST 
   include "pendingCreate".  The server operator reviews the request 
   offline, and informs the client of the outcome of the review by 
   queuing a service message for retrieval via the <poll> command. 
    
   The service message will pertain the domain object identified by the 
   primary domain and therefore will be exactly the same as defined in 
   [EPP-D]. 
    
    







































  
Chung & Tong                                                  [Page 19] 
EPP-IDN                                                      April 2003 
 
 
4. Formal Syntax 
    
   An EPP object mapping is specified in XML Schema notation.  The 
   formal syntax presented here is a complete schema representation of 
   the object mapping suitable for automated validation of EPP XML 
   instances. 
    
   The BEGIN and END tags are not part of the schema; they are used to 
   note the beginning and ending of the schema for URI registration 
   purposes. 
    
   BEGIN 
    
   [To be included] 
    
   END 
    
    
5. Internationalization Considerations 
    
   This document describes the management and provisioning of 
   Internationalized domain names with considerations to IDN variants 
   created by character equivalence preparations issues.  For more 
   information on the subject matter please refer to [Charprep] and 
   [Zoneprep]. 
    
   EPP is represented in XML, which provides native support for encoding 
   information using the Unicode character set and its more compact 
   representations including UTF-8 [RFC2279].  Conformant XML processors 
   recognize both UTF-8 and UTF-16 [RFC2781].  Though XML includes 
   provisions to identify and use other character encodings through use 
   of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is 
   RECOMMENDED in environments where parser encoding support 
   incompatibility exists. 
    
6. IANA Considerations 
    
   This document uses URNs to describe XML namespaces and XML schemas 
   conforming to a registry mechanism described in [IETF-XML].  Since 
   this is intended to be a proposed standard for the management and 
   provisioning of Internationalized domain names, two URI assignments 
   for the relevant elements may be requested. 
    
7. Security Considerations 
    
   The mapping extensions described in this document do not provide any 
   security services beyond those described by EPP [EPP], the EPP domain 
   name mapping [EPP-D], and protocol layers used by EPP. 
    
    



  
Chung & Tong                                                  [Page 20] 
EPP-IDN                                                      April 2003 
 
 
Acknowledgements 
    
   The author acknowledges that large portions of this document has been 
   directly taken from the Extensible Provisioning Protocol Domain Name 
   Mapping draft <draft-ietf-provreg-epp-domain-06.txt> and the 
   Extensible Provisioning Protocol Host Mapping draft <draft-ietf-
   provreg-epp-host-06.txt>, both of which written by Scott Hollenbeck. 
    
References 
    
   Normative references: 
    
   [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", work in 
   progress. 
    
   [EPP-D] S. Hollenbeck: "Extensible Provisioning Protocol Domain Name 
   Mapping", work in progress. 
    
   [EPP-H] S. Hollenbeck: "Extensible Provisioning Protocol Host 
   Mapping", work in progress. 
    
   [EPP-C] S. Hollenbeck: "Extensible Provisioning Protocol Contact 
   Mapping", work in progress. 
    
   IETF-XML] M. Mealling: "The IETF XML Registry", work in progress. 
    
   [RFC2119] S. Bradner: "Key Words for Use in RFCs to Indicate 
   Requirement Levels", BCP 14, RFC 2119, March 1997. 
    
   [RFC3403] M. Mealling: "Dynamic Delegation Discovery System (DDDS) 
   Part Three: The Domain Name System (DNS) Database", RFC 3403, October 
   2002. 
    
   [XML] Editors T. Bray et al.: "Extensible Markup Language (XML) 1.0 
   (Second Edition)", W3C Recommendation 6 October 2000. 
    
   [XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures", 
   W3C Recommendation 2 May 2001. 
    
   [XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2: 
   Datatypes", W3C Recommendation 2 May 2001. 
    
   Informative references: 
    
   [RFC2279] F. Yergeau: "UTF-8, a transformation format of ISO 10646", 
   RFC 2279, January 1998. 
    
   [RFC2781] P. Hoffman, F. Yergeau, "UTF-16, an encoding of ISO 10646", 
   RFC 2781, February 2000. 
    
   [EPP-E.164] S. Hollenbeck: "Extensible Provisioning Protocol E.164 
   Number Mapping", work in progress. 
    
  
Chung & Tong                                                  [Page 21] 
EPP-IDN                                                      April 2003 
 
 
    
Authors' Address: 
    
   Edmon Chung 
   Neteka 
   Suite 100, 243 College St., 
   Toronto, Ontario, 
   Canada M5T 1R5 
   edmon@neteka.com 
    
   Henry Tong 
   Neteka 
   Suite 100, 243 College St., 
   Toronto, Ontario, 
   Canada M5T 1R5 
   henry@neteka.com 
    




































  
Chung & Tong                                                  [Page 22]