Network Working Group                                      S. Hollenbeck
Internet-Draft                                            VeriSign, Inc.
Expires: March 26, 2006                               September 22, 2005


  Service Lookup System (SLS) Mapping for the Extensible Provisioning
                             Protocol (EPP)
                    draft-hollenbeck-epp-sls-00.txt

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 March 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes an Extensible Provisioning Protocol (EPP)
   extension mapping for the provisioning and management of Service
   Lookup System (SLS) data stored in a shared central repository.
   Specified in XML, the mapping defines EPP command syntax and
   semantics as applied to SLS data elements.






Hollenbeck               Expires March 26, 2006                 [Page 1]

Internet-Draft               EPP SLS Mapping              September 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions Used In This Document  . . . . . . . . . . . .  3
   2.  Object Attributes  . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Booleans . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Tags . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.3.  Locales  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.4.  Service Provider Identifiers . . . . . . . . . . . . . . .  4
     2.5.  Service URIs . . . . . . . . . . . . . . . . . . . . . . .  5
     2.6.  Business Categories  . . . . . . . . . . . . . . . . . . .  5
     2.7.  Registration Periods . . . . . . . . . . . . . . . . . . .  5
     2.8.  Contact and Client Identifiers . . . . . . . . . . . . . .  5
     2.9.  Authorization Information  . . . . . . . . . . . . . . . .  5
     2.10. Status Values  . . . . . . . . . . . . . . . . . . . . . .  6
     2.11. Dates and Times  . . . . . . . . . . . . . . . . . . . . .  7
   3.  EPP Command Mapping  . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  EPP Query Commands . . . . . . . . . . . . . . . . . . . .  8
       3.1.1.  EPP <check> Command  . . . . . . . . . . . . . . . . .  8
       3.1.2.  EPP <info> Command . . . . . . . . . . . . . . . . . . 11
       3.1.3.  EPP <transfer> Command . . . . . . . . . . . . . . . . 16
     3.2.  EPP Transform Commands . . . . . . . . . . . . . . . . . . 19
       3.2.1.  EPP <create> Command . . . . . . . . . . . . . . . . . 20
       3.2.2.  EPP <delete> Command . . . . . . . . . . . . . . . . . 23
       3.2.3.  EPP <renew> Command  . . . . . . . . . . . . . . . . . 24
       3.2.4.  EPP <transfer> Command . . . . . . . . . . . . . . . . 26
       3.2.5.  EPP <update> Command . . . . . . . . . . . . . . . . . 29
     3.3.  Offline Review of Requested Actions  . . . . . . . . . . . 33
   4.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 36
   5.  Internationalization Considerations  . . . . . . . . . . . . . 46
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 47
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 47
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 48
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 48
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 49
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 50
   Intellectual Property and Copyright Statements . . . . . . . . . . 51













Hollenbeck               Expires March 26, 2006                 [Page 2]

Internet-Draft               EPP SLS Mapping              September 2005


1.  Introduction

   A number of events and technology requirements explored over the last
   several years serve to remind us that the Domain Name System (DNS)
   [RFC1034] functions well as the Internet's system for assigning
   static textual identifiers to host resources, but functions poorly as
   a set of user-visible names.  Most recently, internationalization
   issues -- the inherent ambiguity of natural language, problems
   working with Unicode in an environment that requires exact-match
   lookups, user desire for convenient, natural language names, the
   impact of trademark law, etc. -- have highlighted this distinction.
   It can also be argued that an entirely different system of
   identifiers intended for human use is needed in addition to a system
   that is designed to work well for protocol elements, such as Uniform
   Resource Identifiers (URIs).

   The Service Lookup System (SLS) is an "above DNS" identification
   system implemented using the Extensible Provisioning protocol (EPP)
   [I-D.hollenbeck-epp-rfc3730bis] and the Internet Registry Information
   Service (IRIS) [RFC3981].  EPP provides controlled access features to
   register and maintain SLS identifiers.  IRIS provides public access
   features to search for and resolve SLS identifiers.

   This document describes an SLS data mapping for EPP version 1.0.
   This mapping is specified using the Extensible Markup Language (XML)
   1.0 [W3C.REC-xml-20001006] and XML Schema notation ([W3C.REC-
   xmlschema-1-20010502], [W3C.REC-xmlschema-2-20010502]).

   The EPP core protocol specification 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.  Familiarity with the IRIS SLS
   registry [I-D.daigle-iris-slsreg] is required to understand the IRIS
   SLS concepts described in this document.

1.1.  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 BCP 14, RFC 2119
   [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 are only provided to illustrate element
   relationships and are not a REQUIRED feature of this specification.

   XML is case sensitive.  Unless stated otherwise, XML specifications



Hollenbeck               Expires March 26, 2006                 [Page 3]

Internet-Draft               EPP SLS Mapping              September 2005


   and examples provided in this document MUST be interpreted in the
   character case presented to develop a conforming implementation.


2.  Object Attributes

   An EPP SLS 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.  Booleans

   Boolean values MUST be represented in the XML Schema format described
   in Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema-2-
   20010502].

2.2.  Tags

   A tag is an unstructured, registered label associated with the
   services in an SLS object.  A tag has a specified minimum length, no
   maximum length, and MUST be represented using the "token" data type
   described in Part 2 of the W3C XML Schema recommendation [W3C.REC-
   xmlschema-2-20010502].  The combination of tag, locale, and service
   provider identifier uniquely identifies an SLS object.

2.3.  Locales

   A locale is identified using a combination of a language identifier,
   an OPTIONAL script code, an OPTIONAL territory code, and an OPTIONAL
   variant code.  Language identifier syntax, script code syntax, and
   territory code syntax is specified in RFC XXXX [I-D.ietf-ltru-
   registry].  Variant codes MUST NOT overlap with script or territory
   codes; they MUST have either one letter or have more than 4 letters.
   The combination of locale, tag, and service provider identifier
   uniquely identifies an SLS object.

2.4.  Service Provider Identifiers

   Service providers are identified using text strings that are
   registered with IANA as described in Section 2.8 of RFC 3730bis
   [I-D.hollenbeck-epp-rfc3730bis].  A service provider identifier has a
   specified minimum length, a specified maximum length, and MUST be
   represented using a restricted form of the "token" data type
   described in Part 2 of the W3C XML Schema recommendation [W3C.REC-
   xmlschema-2-20010502].



Hollenbeck               Expires March 26, 2006                 [Page 4]

Internet-Draft               EPP SLS Mapping              September 2005


2.5.  Service URIs

   A service URI is a URI of any type that identifies a specific service
   associated with the tag/locale combination.  URIs are represented
   using the "anyURI" data type described in Part 2 of the W3C XML
   Schema recommendation [W3C.REC-xmlschema-2-20010502].
   Internationalized Resource Identifiers (IRIs) are acceptable.  URI
   syntax is specified in Standard 66, RFC 3986 [RFC3986].  IRI syntax
   is specified in RFC 3987 [RFC3987].

2.6.  Business Categories

   Business categories are text fields used to provide classification
   information about the entity described by the tag.  Semantic values
   are a matter of implementation policy.  A business category has a
   specified minimum length, no maximum length, and MUST be represented
   using the "token" data type described in Part 2 of the W3C XML Schema
   recommendation [W3C.REC-xmlschema-2-20010502].

2.7.  Registration Periods

   Registration periods define the subscription period of an SLS object.
   Periods are measured in either months or years depending on
   implementation policy.  A registration period has a specified
   inclusive minimum, a specified inclusive maximum, and MUST be
   represented using the "unsignedShort" data type described in Part 2
   of the W3C XML Schema recommendation [W3C.REC-xmlschema-2-20010502].

2.8.  Contact and Client Identifiers

   All EPP contacts are identified by a server-unique identifier.
   Contact identifiers are character strings with a specified minimum
   length, a specified maximum length, and a specified format.  An XML
   attribute identifies the contact type.

   All EPP clients are identified by a server-unique identifier.  Client
   identifiers are character strings with a specified minimum length, a
   specified maximum length, and a specified format.  Client identifiers
   use the "clIDType" client identifier syntax described in RFC 3730bis
   [I-D.hollenbeck-epp-rfc3730bis].

2.9.  Authorization Information

   Authorization information is used to help prevent unintended
   disclosure of information to unauthorized clients and to confirm
   certian transform commands.  Password-based authorization information
   is represented using the "normalizedString" data type described in
   Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema-2-



Hollenbeck               Expires March 26, 2006                 [Page 5]

Internet-Draft               EPP SLS Mapping              September 2005


   20010502].  Other forms of authorization information can be defined
   by protocol extension.

2.10.  Status Values

   An SLS object MUST always have at least one associated status value.
   Status values can be set only by the client that sponsors an SLS
   object and by the server on which the object resides.  A client can
   change the status of an SLS object using the EPP <update> command.
   Each status value MAY be accompanied by a string of human-readable
   text that describes the rationale for the status applied to the
   object.

   A client MUST NOT alter status values set by the server.  A server
   MAY alter or override status values set by a client subject to local
   server policies.  The status of an object MAY change as a result of
   either a client-initiated transform command or an action performed by
   a server operator.

   Status values that can be added or removed by a client are prefixed
   with "client".  Corresponding status values that can be added or
   removed by a server are prefixed with "server".  Status values that
   do not begin with either "client" or "server" are server-managed.

   Status Value Descriptions:

   -  clientDeleteProhibited, serverDeleteProhibited

      Requests to delete the object MUST be rejected.

   -  clientHold, serverHold

      IRIS lookup information MUST NOT be published for the object.

   -  clientRenewProhibited, serverRenewProhibited

      Requests to renew the object MUST be rejected.

   -  clientTransferProhibited, serverTransferProhibited

      Requests to transfer the object MUST be rejected.

   -  clientUpdateProhibited, serverUpdateProhibited

      Requests to update the object (other than to remove this status)
      MUST be rejected.





Hollenbeck               Expires March 26, 2006                 [Page 6]

Internet-Draft               EPP SLS Mapping              September 2005


   -  ok

      This is the normal status value for an object that has no pending
      operations or prohibitions.  This value is set and removed by the
      server as other status values are added or removed.

   -  pendingCreate, pendingDelete, pendingRenew, pendingTransfer,
      pendingUpdate

      A transform command has been processed for the object, but the
      action has not been completed by the server.  Server operators can
      delay action completion for a variety of reasons, such as to allow
      for human review or third-party action.  A transform command that
      is processed, but whose requested action is pending, is noted with
      response code 1001.

      When the requested action has been completed, the pendingCreate,
      pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate
      status value MUST be removed.  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.

   "ok" status MUST NOT be combined with any other status.

   "pendingDelete" status MUST NOT be combined with either
   "clientDeleteProhibited" or "serverDeleteProhibited" status.

   "pendingRenew" status MUST NOT be combined with either
   "clientRenewProhibited" or "serverRenewProhibited" status.

   "pendingTransfer" status MUST NOT be combined with either
   "clientTransferProhibited" or "serverTransferProhibited" status.

   "pendingUpdate" status MUST NOT be combined with either
   "clientUpdateProhibited" or "serverUpdateProhibited" status.

   The pendingCreate, pendingDelete, pendingRenew, pendingTransfer, and
   pendingUpdate status values MUST NOT be combined with each other.

   Other status combinations not expressly prohibited MAY be used.

2.11.  Dates and Times

   Date and time attribute values MUST be represented in Universal
   Coordinated Time (UTC) using the Gregorian calendar.  The extended
   date-time form using upper case "T" and "Z" characters defined in RFC
   3339 [RFC3339] MUST be used to represent date-time values as XML



Hollenbeck               Expires March 26, 2006                 [Page 7]

Internet-Draft               EPP SLS Mapping              September 2005


   Schema does not support truncated date-time forms or lower case "T"
   and "Z" characters.


3.  EPP Command Mapping

   A detailed description of the EPP syntax and semantics can be found
   in the EPP core protocol specification [I-D.hollenbeck-epp-
   rfc3730bis].  The command mappings described here are specifically
   for use in provisioning and managing SLS data elements via EPP.

3.1.  EPP Query Commands

   EPP provides three commands to retrieve object information: <check>
   to determine if an object is known to the server, <info> to retrieve
   detailed information associated with an object, and <transfer> to
   retrieve 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.  It provides a hint that allows a
   client to anticipate the success or failure of provisioning an object
   using the <create> command as object provisioning requirements are
   ultimately a matter of server policy.

   In addition to the standard EPP command elements, the <check> command
   MUST contain an <eppSLS:check> element that identifies the object
   namespace and the location of the object schema.  The <eppSLS:check>
   element contains the following child elements:

   -  An <eppSLS:tagRec> element that identifies the SLS object to be
      queried.  The <eppSLS:tagRec> element contains the following child
      elements:

      -  An <eppSLS:tag> element that contains the tag of the SLS object
         to be queried.

      -  An <eppSLS:locale> element that identifies the locale of the
         SLS object to be queried.  The <eppSLS:locale> element contains
         the following child elements:

         -  An <eppSLS:langCode> element that contains the language code
            of the SLS object to be queried.







Hollenbeck               Expires March 26, 2006                 [Page 8]

Internet-Draft               EPP SLS Mapping              September 2005


         -  An OPTIONAL <eppSLS:scriptCode> element that contains the
            script code of the SLS object to be queried.

         -  An OPTIONAL <eppSLS:terrCode> element that contains the
            territory code of the SLS object to be queried.

         -  An OPTIONAL <eppSLS:varCode> element that contains the
            variant code of the SLS object to be queried.

   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:      <eppSLS:check
   C:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   C:       eppSLS-1.0.xsd">
   C:        <eppSLS:tagRec>
   C:          <eppSLS:tag>Example Tag</eppSLS:tag>
   C:          <eppSLS:locale>
   C:            <eppSLS:langCode>en</eppSLS:langCode>
   C:            <eppSLS:terrCode>US</eppSLS:terrCode>
   C:          </eppSLS:locale>
   C:        </eppSLS:tagRec>
   C:      </eppSLS: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 <eppSLS:chkData> element that
   identifies the object namespace and the location of the object
   schema.  The <eppSLS:chkData> element contains an <eppSLS:cd> element
   that contains the following child elements:

   -  An <eppSLS:tagRec> element that identifies the SLS object that was
      queried.  This element MUST contain an "avail" attribute whose
      value indicates object availability (can it be provisioned or not)
      at the moment the <check> command was completed.  A value of "1"
      or "true" means that the object can be provisioned.  A value of
      "0" or "false" means that the object can not be provisioned.  The
      <eppSLS:tagRec> element contains the following child elements:



Hollenbeck               Expires March 26, 2006                 [Page 9]

Internet-Draft               EPP SLS Mapping              September 2005



      -  An <eppSLS:tag> element that contains the tag of the SLS object
         that was queried.

      -  An <eppSLS:locale> element that identifies the locale of the
         SLS object that was queried.  The <eppSLS:locale> element
         contains the following child elements:

         -  An <eppSLS:langCode> element that contains the language code
            of the SLS object that was queried.

         -  An OPTIONAL <eppSLS:scriptCode> element that contains the
            script code of the SLS object that was queried.

         -  An OPTIONAL <eppSLS:terrCode> element that contains the
            territory code of the SLS object that was queried.

         -  An OPTIONAL <eppSLS:varCode> element that contains the
            variant code of the SLS object that was queried.

      -  An <eppSLS:provID> element that contains the IANA-registered
         identifier of the service provider.





























Hollenbeck               Expires March 26, 2006                [Page 10]

Internet-Draft               EPP SLS Mapping              September 2005


   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:      <eppSLS:chkData
   S:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   S:       eppSLS-1.0.xsd">
   S:        <eppSLS:cd>
   S:          <eppSLS:tagRec avail="1">
   S:            <eppSLS:tag>Example Tag</eppSLS:tag>
   S:            <eppSLS:locale>
   S:              <eppSLS:langCode>en</eppSLS:langCode>
   S:              <eppSLS:terrCode>US</eppSLS:terrCode>
   S:            </eppSLS:locale>
   S:            <eppSLS:provID>EXAMPLE</eppSLS:provID>
   S:          </eppSLS:tagRec>
   S:        </eppSLS:cd>
   S:      </eppSLS: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 can not
   be processed for any reason.

3.1.2.  EPP <info> Command

   The EPP <info> command is used to retrieve information associated
   with an SLS object.  The response to this command MAY vary depending
   on the identity of the querying client, use of authorization
   information, and server policy towards unauthorized clients.  If the
   querying client is the sponsoring client, all available information
   MUST be returned.  If the querying client is not the sponsoring
   client, but the client provides valid authorization information, all
   available information MUST be returned.  If the querying client is



Hollenbeck               Expires March 26, 2006                [Page 11]

Internet-Draft               EPP SLS Mapping              September 2005


   not the sponsoring client, and the client does not provide valid
   authorization information, server policy determines which OPTIONAL
   elements are returned.  In addition to the standard EPP command
   elements, the <info> command MUST contain an <eppSLS:info> element
   that identifies the object namespace and the location of the object
   schema.  The <eppSLS:info> element contains the following child
   elements:

   -  An <eppSLS:tagRec> element that identifies the SLS object to be
      queried.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      command described in Section 3.1.1.

   -  An OPTIONAL <eppSLS:authInfo> element that contains authorization
      information associated with the SLS object.  If this element is
      not provided or if the authorization information is invalid,
      server policy determines if the command is rejected or if response
      information will be returned to the client.

   Example <info> command with authorization information:

   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:      <eppSLS:info
   C:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   C:       eppSLS-1.0.xsd">
   C:        <eppSLS:tagRec>
   C:          <eppSLS:tag>Example Tag</eppSLS:tag>
   C:          <eppSLS:locale>
   C:            <eppSLS:langCode>en</eppSLS:langCode>
   C:            <eppSLS:terrCode>US</eppSLS:terrCode>
   C:          </eppSLS:locale>
   C:        </eppSLS:tagRec>
   C:        <eppSLS:authInfo>
   C:          <eppSLS:pw>2fooBAR</eppSLS:pw>
   C:        </eppSLS:authInfo>
   C:      </eppSLS:info>
   C:    </info>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>




Hollenbeck               Expires March 26, 2006                [Page 12]

Internet-Draft               EPP SLS Mapping              September 2005


   Example <info> command without authorization information:

   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:      <eppSLS:info
   C:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   C:       eppSLS-1.0.xsd">
   C:        <eppSLS:tagRec>
   C:          <eppSLS:tag>Example Tag</eppSLS:tag>
   C:          <eppSLS:locale>
   C:            <eppSLS:langCode>en</eppSLS:langCode>
   C:            <eppSLS:terrCode>US</eppSLS:terrCode>
   C:          </eppSLS:locale>
   C:        </eppSLS:tagRec>
   C:      </eppSLS: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 <eppSLS:infData> element that
   identifies the object namespace and the location of the object
   schema.  Elements that are not OPTIONAL MUST be returned; OPTIONAL
   elements are returned based on client authorization and server
   policy.  The <eppSLS:infData> element contains the following child
   elements:

   -  An <eppSLS:tagRec> element that identifies the SLS object that was
      queried.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      response described in Section 3.1.1.

   -  An OPTIONAL <eppSLS:tagSvcs> element that contains one or more
      <eppSLS:svcURI> elements.  Each <eppSLS:svcURI> element contains
      the URI of a service associated with the SLS object.

   -  An OPTIONAL <eppSLS:busCat> element that contains the business
      category text associated with the SLS object.






Hollenbeck               Expires March 26, 2006                [Page 13]

Internet-Draft               EPP SLS Mapping              September 2005


   -  Zero or more OPTIONAL <eppSLS:status> elements that contain the
      current status descriptors associated with the SLS object.

   -  If supported by the server, one OPTIONAL <eppSLS:registrant>
      element and one or more OPTIONAL <eppSLS:contact> elements that
      contain identifiers for the human or organizational social
      information objects associated with the SLS object.

   -  An <eppSLS:clID> element that contains the identifier of the
      sponsoring client.

   -  An OPTIONAL <eppSLS:crID> element that contains the identifier of
      the client that created the SLS object.

   -  An OPTIONAL <eppSLS:crDate> element that contains the date and
      time of SLS object creation.

   -  An OPTIONAL <eppSLS:upID> element that contains the identifier of
      the client that last updated the SLS object.  This element MUST
      NOT be present if the SLS object has never been modified.

   -  An OPTIONAL <eppSLS:upDate> element that contains the date and
      time of the most recent SLS object modification.  This element
      MUST NOT be present if the SLS object has never been modified.

   -  An OPTIONAL <eppSLS:exDate> element that contains the date and
      time identifying the end of the SLS object's registration period.

   -  An OPTIONAL <eppSLS:trDate> elements that contains the date and
      time of the most recent successful SLS object transfer.  This
      element MUST NOT be provided if the SLS object has never been
      transferred.

   -  An OPTIONAL <eppSLS:authInfo> element that contains authorization
      information associated with the SLS object.  This element MUST
      only be returned if the querying client is the current sponsoring
      client, or if the client supplied valid authorization information
      with the command.

   Example <info> response for an authorized client:

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



Hollenbeck               Expires March 26, 2006                [Page 14]

Internet-Draft               EPP SLS Mapping              September 2005


   S:      <msg>Command completed successfully</msg>
   S:    </result>
   S:    <resData>
   S:      <eppSLS:infData
   S:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   S:       eppSLS-1.0.xsd">
   S:        <eppSLS:tagRec>
   S:          <eppSLS:tag>Example Tag</eppSLS:tag>
   S:          <eppSLS:locale>
   S:            <eppSLS:langCode>en</eppSLS:langCode>
   S:            <eppSLS:terrCode>US</eppSLS:terrCode>
   S:          </eppSLS:locale>
   S:          <eppSLS:provID>EXAMPLE</eppSLS:provID>
   S:        </eppSLS:tagRec>
   S:        <eppSLS:tagSvcs>
   S:          <eppSLS:svcURI>http://www.example.com</eppSLS:svcURI>
   S:          <eppSLS:svcURI>mailto:admin@example.com</eppSLS:svcURI>
   S:        </eppSLS:tagSvcs>
   S:        <eppSLS:busCat>Example Producer</eppSLS:busCat>
   S:        <eppSLS:status s="ok"/>
   S:        <eppSLS:registrant>jd1234</eppSLS:registrant>
   S:        <eppSLS:contact type="admin">sh8013</eppSLS:contact>
   S:        <eppSLS:contact type="tech">sh8013</eppSLS:contact>
   S:        <eppSLS:clID>ClientX</eppSLS:clID>
   S:        <eppSLS:crID>ClientY</eppSLS:crID>
   S:        <eppSLS:crDate>1999-04-03T22:00:00.0Z</eppSLS:crDate>
   S:        <eppSLS:upID>ClientX</eppSLS:upID>
   S:        <eppSLS:upDate>1999-12-03T09:00:00.0Z</eppSLS:upDate>
   S:        <eppSLS:exDate>2005-04-03T22:00:00.0Z</eppSLS:exDate>
   S:        <eppSLS:trDate>2000-04-08T09:00:00.0Z</eppSLS:trDate>
   S:        <eppSLS:authInfo>
   S:          <eppSLS:pw>2fooBAR</eppSLS:pw>
   S:        </eppSLS:authInfo>
   S:      </eppSLS:infData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54322-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

   A server with a different information return policy MAY provide less
   information in a response.






Hollenbeck               Expires March 26, 2006                [Page 15]

Internet-Draft               EPP SLS Mapping              September 2005


   Example <info> response for an unauthorized client:

   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:      <eppSLS:infData
   S:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   S:       eppSLS-1.0.xsd">
   S:        <eppSLS:tagRec>
   S:          <eppSLS:tag>Example Tag</eppSLS:tag>
   S:          <eppSLS:locale>
   S:            <eppSLS:langCode>en</eppSLS:langCode>
   S:            <eppSLS:terrCode>US</eppSLS:terrCode>
   S:          </eppSLS:locale>
   S:          <eppSLS:provID>EXAMPLE</eppSLS:provID>
   S:        </eppSLS:tagRec>
   S:        <eppSLS:clID>ClientX</eppSLS:clID>
   S:      </eppSLS: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 can not
   be processed for any reason.

3.1.3.  EPP <transfer> Command

   The EPP <transfer> command provides a query operation that allows a
   client to determine real-time status of pending and completed
   transfer requests.  In addition to the standard EPP command elements,
   the <transfer> command MUST contain an "op" attribute with value
   "query", and an <eppSLS:transfer> element that identifies the object
   namespace and the location of the object schema.  The <eppSLS:
   transfer> element contains the following child elements:





Hollenbeck               Expires March 26, 2006                [Page 16]

Internet-Draft               EPP SLS Mapping              September 2005


   -  An <eppSLS:tagRec> element that identifies the SLS object to be
      queried.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      command described in Section 3.1.1.

   -  An OPTIONAL <eppSLS:authInfo> element that contains authorization
      information associated with the SLS object.  If this element is
      not provided or if the authorization information is invalid,
      server policy determines if the command is rejected or if response
      information will be returned to the client.

   Example <transfer> query 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:    <transfer op="query">
   C:      <eppSLS:transfer
   C:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   C:       eppSLS-1.0.xsd">
   C:        <eppSLS:tagRec>
   C:          <eppSLS:tag>Example Tag</eppSLS:tag>
   C:          <eppSLS:locale>
   C:            <eppSLS:langCode>en</eppSLS:langCode>
   C:            <eppSLS:terrCode>US</eppSLS:terrCode>
   C:          </eppSLS:locale>
   C:        </eppSLS:tagRec>
   C:        <eppSLS:authInfo>
   C:          <eppSLS:pw>2fooBAR</eppSLS:pw>
   C:        </eppSLS:authInfo>
   C:      </eppSLS:transfer>
   C:    </transfer>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

   When a <transfer> query command has been processed successfully, the
   EPP <resData> element MUST contain a child <eppSLS:trnData> element
   that identifies the object namespace and the location of the object
   schema.  The <eppSLS:trnData> element contains the following child
   elements:






Hollenbeck               Expires March 26, 2006                [Page 17]

Internet-Draft               EPP SLS Mapping              September 2005


   -  An <eppSLS:tagRec> element that identifies the SLS object that was
      queried.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      command described in Section 3.1.1.

   -  An <eppSLS:trStatus> element that contains the state of the most
      recent transfer request.

   -  An <eppSLS:reID> element that contains the identifier of the
      client that requested the object transfer.

   -  An <eppSLS:reDate> element that contains the date and time that
      the transfer was requested.

   -  An <eppSLS:acID> element that contains the identifier of the
      client that SHOULD act upon the transfer request.

   -  An <eppSLS:acDate> element that contains the date and time of a
      required or completed response.  For a PENDING request, the value
      identifies the date and time by which a response is required
      before an automated response action will be taken by the server.
      For all other status types, the value identifies the date and time
      when the request was completed.

   -  An OPTIONAL <eppSLS:exDate> element that contains the end of the
      SLS object's validity period if the <transfer> command caused or
      causes a change in the validity period.
























Hollenbeck               Expires March 26, 2006                [Page 18]

Internet-Draft               EPP SLS Mapping              September 2005


   Example <transfer> query 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:      <eppSLS:trnData
   S:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   S:       eppSLS-1.0.xsd">
   S:        <eppSLS:tagRec>
   S:          <eppSLS:tag>Example Tag</eppSLS:tag>
   S:          <eppSLS:locale>
   S:            <eppSLS:langCode>en</eppSLS:langCode>
   S:            <eppSLS:terrCode>US</eppSLS:terrCode>
   S:          </eppSLS:locale>
   S:        </eppSLS:tagRec>
   S:        <eppSLS:trStatus>pending</eppSLS:trStatus>
   S:        <eppSLS:reID>ClientX</eppSLS:reID>
   S:        <eppSLS:reDate>2000-06-06T22:00:00.0Z</eppSLS:reDate>
   S:        <eppSLS:acID>ClientY</eppSLS:acID>
   S:        <eppSLS:acDate>2000-06-11T22:00:00.0Z</eppSLS:acDate>
   S:        <eppSLS:exDate>2002-09-08T22:00:00.0Z</eppSLS:exDate>
   S:      </eppSLS:trnData>
   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 <transfer> query command
   can not be processed for any reason.

3.2.  EPP Transform Commands

   EPP provides five commands to transform objects: <create> to create
   an instance of an object, <delete> to delete an instance of an
   object, <renew> to extend the validity period of an object,
   <transfer> to manage object sponsorship changes, and <update> to
   change information associated with an object.



Hollenbeck               Expires March 26, 2006                [Page 19]

Internet-Draft               EPP SLS Mapping              September 2005


   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 provides a transform operation that allows a
   client to create an SLS object.  In addition to the standard EPP
   command elements, the <create> command MUST contain an <eppSLS:
   create> element that identifies the object namespace and the location
   of the object schema.  The <eppSLS:create> element contains the
   following child elements:

   -  An <eppSLS:tagRec> element that identifies the SLS object to be
      created.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      response described in Section 3.1.1.

   -  An OPTIONAL <eppSLS:tagSvcs> element that contains one or more
      <eppSLS:svcURI> elements.  Each <eppSLS:svcURI> element contains
      the URI of a service to be associated with the SLS object.

   -  An OPTIONAL <eppSLS:busCat> element that contains the business
      category text to be associated with the SLS object.

   -  An OPTIONAL <eppSLS:registrant> element that contains the
      identifier for the human or organizational social information
      (contact) object to be associated with the SLS object as the
      object registrant.  This object identifier MUST be known to the
      server before the contact object can be associated with the SLS
      object.  The EPP mapping for contact objects is described in RFC
      3733bis [I-D.hollenbeck-epp-rfc3733bis].

   -  Zero or more OPTIONAL <eppSLS:contact> elements that contain the
      identifiers for other contact objects to be associated with the
      SLS object.  Contact object identifiers MUST be known to the
      server before the contact object can be associated with the SLS
      object.




Hollenbeck               Expires March 26, 2006                [Page 20]

Internet-Draft               EPP SLS Mapping              September 2005


   -  An <eppSLS:authInfo> element that contains authorization
      information to be associated with the SLS object.  This mapping
      includes a password-based authentication mechanism, but the schema
      allows new mechanisms to be defined in new schemas.

   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:      <eppSLS:create
   C:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   C:       eppSLS-1.0.xsd">
   C:        <eppSLS:tagRec>
   C:          <eppSLS:tag>Example Tag</eppSLS:tag>
   C:          <eppSLS:locale>
   C:            <eppSLS:langCode>en</eppSLS:langCode>
   C:            <eppSLS:terrCode>US</eppSLS:terrCode>
   C:          </eppSLS:locale>
   C:        </eppSLS:tagRec>
   C:        <eppSLS:tagSvcs>
   C:          <eppSLS:svcURI>http://www.example.com</eppSLS:svcURI>
   C:          <eppSLS:svcURI>mailto:admin@example.com</eppSLS:svcURI>
   C:        </eppSLS:tagSvcs>
   C:        <eppSLS:busCat>Example Producer</eppSLS:busCat>
   C:        <eppSLS:period unit="y">2</eppSLS:period>
   C:        <eppSLS:registrant>jd1234</eppSLS:registrant>
   C:        <eppSLS:contact type="admin">sh8013</eppSLS:contact>
   C:        <eppSLS:contact type="tech">sh8013</eppSLS:contact>
   C:        <eppSLS:authInfo>
   C:          <eppSLS:pw>2fooBAR</eppSLS:pw>
   C:        </eppSLS:authInfo>
   C:      </eppSLS:create>
   C:    </create>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

   When a <create> command has been processed successfully, the EPP
   <resData> element MUST contain a child <eppSLS:creData> element that
   identifies the object namespace and the location of the object
   schema.  The <eppSLS:creData> element contains the following child
   elements:



Hollenbeck               Expires March 26, 2006                [Page 21]

Internet-Draft               EPP SLS Mapping              September 2005


   -  An <eppSLS:tagRec> element that identifies the SLS object that was
      created.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      response described in Section 3.1.1.

   -  An <eppSLS:crDate> element that contains the date and time of SLS
      object creation.

   -  An OPTIONAL <eppSLS:exDate> element that contains the date and
      time identifying the end of the SLS object's registration period.

   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:      <eppSLS:creData
   S:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   S:       eppSLS-1.0.xsd">
   S:        <eppSLS:tagRec>
   S:          <eppSLS:tag>Example Tag</eppSLS:tag>
   S:          <eppSLS:locale>
   S:            <eppSLS:langCode>en</eppSLS:langCode>
   S:            <eppSLS:terrCode>US</eppSLS:terrCode>
   S:          </eppSLS:locale>
   S:        </eppSLS:tagRec>
   S:        <eppSLS:crDate>1999-04-03T22:00:00.0Z</eppSLS:crDate>
   S:        <eppSLS:exDate>2001-04-03T22:00:00.0Z</eppSLS:exDate>
   S:      </eppSLS:creData>
   S:    </resData>
   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 a <create> command can not
   be processed for any reason.




Hollenbeck               Expires March 26, 2006                [Page 22]

Internet-Draft               EPP SLS Mapping              September 2005


3.2.2.  EPP <delete> Command

   The EPP <delete> command provides a transform operation that allows a
   client to delete an SLS object.  In addition to the standard EPP
   command elements, the <delete> command MUST contain an <eppSLS:
   delete> element that identifies the object namespace and the location
   of the object schema.  The <eppSLS:delete> element contains the
   following child elements:

   -  An <eppSLS:tagRec> element that identifies the SLS object to be
      deleted.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      command described in Section 3.1.1.

   Example <delete> 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:    <delete>
   C:      <eppSLS:delete
   C:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   C:       eppSLS-1.0.xsd">
   C:        <eppSLS:tagRec>
   C:          <eppSLS:tag>Example Tag</eppSLS:tag>
   C:          <eppSLS:locale>
   C:            <eppSLS:langCode>en</eppSLS:langCode>
   C:            <eppSLS:terrCode>US</eppSLS:terrCode>
   C:          </eppSLS:locale>
   C:        </eppSLS:tagRec>
   C:      </eppSLS:delete>
   C:    </delete>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

   When a <delete> command has been processed successfully, a server
   MUST respond with an EPP response with no <resData> element.









Hollenbeck               Expires March 26, 2006                [Page 23]

Internet-Draft               EPP SLS Mapping              September 2005


   Example <delete> 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:    <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 a <delete> command can not
   be processed for any reason.

3.2.3.  EPP <renew> Command

   The EPP <renew> command provides a transform operation that allows a
   client to extend the validity period of an SLS object.  In addition
   to the standard EPP command elements, the <renew> command MUST
   contain an <eppSLS:renew> element that identifies the object
   namespace and the location of the object schema.  The <eppSLS:renew>
   element contains the following child elements:

   -  An <eppSLS:tagRec> element that identifies the SLS object to be
      renewed.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      command described in Section 3.1.1.

   -  An <eppSLS:curExpDate> element that contains the date on which the
      current validity period ends.  This value ensures that repeated
      <renew> commands do not result in multiple unanticipated
      successful renewals.

   -  An OPTIONAL <eppSLS:period> element that contains the number of
      units to be added to the registration period of the SLS object.
      The number of units available MAY be subject to limits imposed by
      the server.







Hollenbeck               Expires March 26, 2006                [Page 24]

Internet-Draft               EPP SLS Mapping              September 2005


   Example <renew> 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:    <renew>
   C:      <eppSLS:renew
   C:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   C:       eppSLS-1.0.xsd">
   C:        <eppSLS:tagRec>
   C:          <eppSLS:tag>Example Tag</eppSLS:tag>
   C:          <eppSLS:locale>
   C:            <eppSLS:langCode>en</eppSLS:langCode>
   C:            <eppSLS:terrCode>US</eppSLS:terrCode>
   C:          </eppSLS:locale>
   C:        </eppSLS:tagRec>
   C:        <eppSLS:curExpDate>2000-04-03</eppSLS:curExpDate>
   C:        <eppSLS:period unit="y">5</eppSLS:period>
   C:      </eppSLS:renew>
   C:    </renew>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

   When a <renew> command has been processed successfully, the EPP
   <resData> element MUST contain a child <eppSLS:renData> element that
   identifies the object namespace and the location of the object
   schema.  The <eppSLS:renData> element contains the following child
   elements:

   -  An <eppSLS:tagRec> element that identifies the SLS object that was
      renewed.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      command described in Section 3.1.1.

   -  An OPTIONAL <eppSLS:exDate> element that contains the date and
      time identifying the end of the SLS object's registration period.










Hollenbeck               Expires March 26, 2006                [Page 25]

Internet-Draft               EPP SLS Mapping              September 2005


   Example <renew> 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:      <eppSLS:renData
   S:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   S:       eppSLS-1.0.xsd">
   S:        <eppSLS:tagRec>
   S:          <eppSLS:tag>Example Tag</eppSLS:tag>
   S:          <eppSLS:locale>
   S:            <eppSLS:langCode>en</eppSLS:langCode>
   S:            <eppSLS:terrCode>US</eppSLS:terrCode>
   S:          </eppSLS:locale>
   S:        </eppSLS:tagRec>
   S:        <eppSLS:exDate>2005-04-03T22:00:00.0Z</eppSLS:exDate>
   S:      </eppSLS:renData>
   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 <renew> command can not
   be processed for any reason.

3.2.4.  EPP <transfer> Command

   The EPP <transfer> command provides a transform operation that allows
   a client to manage requests to transfer the sponsorship of an SLS
   object.  In addition to the standard EPP command elements, the
   <transfer> command MUST contain an <eppSLS:transfer> element that
   identifies the object namespace and the location of the object
   schema.  The <eppSLS:transfer> element contains the following child
   elements:






Hollenbeck               Expires March 26, 2006                [Page 26]

Internet-Draft               EPP SLS Mapping              September 2005


   -  An <eppSLS:tagRec> element that identifies the SLS object for
      which a transfer request is to be created, approved, rejected, or
      cancelled.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      command described in Section 3.1.1.

   -  An OPTIONAL <eppSLS:period> element that contains the number of
      units to be added to the registration period of the SLS object at
      completion of the transfer process.  This element can only be used
      when a transfer is requested, and it MUST be ignored if used
      otherwise.  The number of units available MAY be subject to limits
      imposed by the server.

   -  An <eppSLS:authInfo> element that contains authorization
      information associated with the SLS object.

   Every EPP <transfer> command MUST contain an "op" attribute that
   identifies the transfer operation to be performed.  Valid values,
   definitions, and authorizations for all attribute values are defined
   in RFC 3730bis [I-D.hollenbeck-epp-rfc3730bis].































Hollenbeck               Expires March 26, 2006                [Page 27]

Internet-Draft               EPP SLS Mapping              September 2005


   Example <transfer> request 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:    <transfer op="request">
   C:      <eppSLS:transfer
   C:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   C:       eppSLS-1.0.xsd">
   C:        <eppSLS:tagRec>
   C:          <eppSLS:tag>Example Tag</eppSLS:tag>
   C:          <eppSLS:locale>
   C:            <eppSLS:langCode>en</eppSLS:langCode>
   C:            <eppSLS:terrCode>US</eppSLS:terrCode>
   C:          </eppSLS:locale>
   C:        </eppSLS:tagRec>
   C:        <eppSLS:period unit="y">1</eppSLS:period>
   C:        <eppSLS:authInfo>
   C:          <eppSLS:pw>2fooBAR</eppSLS:pw>
   C:        </eppSLS:authInfo>
   C:      </eppSLS:transfer>
   C:    </transfer>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

   When a <transfer> command has been processed successfully, the EPP
   <resData> element MUST contain a child <eppSLS:trnData> element that
   identifies the object namespace and the location of the object
   schema.  The <eppSLS:trnData> element contains the same child
   elements defined for a transfer query response as described in
   Section 3.1.3.















Hollenbeck               Expires March 26, 2006                [Page 28]

Internet-Draft               EPP SLS Mapping              September 2005


   Example <transfer> 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="1001">
   S:      <msg>Command completed successfully; action pending</msg>
   S:    </result>
   S:    <resData>
   S:      <eppSLS:trnData
   S:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   S:       eppSLS-1.0.xsd">
   S:        <eppSLS:tagRec>
   S:          <eppSLS:tag>Example Tag</eppSLS:tag>
   S:          <eppSLS:locale>
   S:            <eppSLS:langCode>en</eppSLS:langCode>
   S:            <eppSLS:terrCode>US</eppSLS:terrCode>
   S:          </eppSLS:locale>
   S:        </eppSLS:tagRec>
   S:        <eppSLS:trStatus>pending</eppSLS:trStatus>
   S:        <eppSLS:reID>ClientX</eppSLS:reID>
   S:        <eppSLS:reDate>2000-06-08T22:00:00.0Z</eppSLS:reDate>
   S:        <eppSLS:acID>ClientY</eppSLS:acID>
   S:        <eppSLS:acDate>2000-06-13T22:00:00.0Z</eppSLS:acDate>
   S:        <eppSLS:exDate>2002-09-08T22:00:00.0Z</eppSLS:exDate>
   S:      </eppSLS:trnData>
   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 <transfer> command can
   not be processed for any reason.

3.2.5.  EPP <update> Command

   The EPP <update> command provides a transform operation that allows a
   client to modify the attributes of an SLS object.  In addition to the
   standard EPP command elements, the <update> command MUST contain an
   <eppSLS:update> element that identifies the object namespace and the
   location of the object schema.  The <eppSLS:update> element contains



Hollenbeck               Expires March 26, 2006                [Page 29]

Internet-Draft               EPP SLS Mapping              September 2005


   the following child elements:

   -  An <eppSLS:tagRec> element that identifies the SLS object to be
      updated.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      command described in Section 3.1.1.

   -  An OPTIONAL <eppSLS:add> element that contains attribute values to
      be added to the object.

   -  An OPTIONAL <eppSLS:rem> element that contains attribute values to
      be removed from the object.

   -  An OPTIONAL <eppSLS:chg> element that contains object attribute
      values to be changed.

   At least one <eppSLS:add>, <eppSLS:rem>, or <eppSLS:chg> element MUST
   be provided if the command is not being extended.  All of these
   elements MAY be omitted if an <update> extension is present.  The
   <eppSLS:add> and <eppSLS:rem> elements contain the following child
   elements:

   -  Zero or more <eppSLS:contact> elements that contain the
      identifiers for contact objects to be associated with or removed
      from the SLS object.  Contact object identifiers MUST be known to
      the server before the contact object can be associated with the
      SLS object.

   -  Zero or more <eppSLS:status> elements that contain status values
      to be applied to or removed from the object.  When specifying a
      value to be removed, only the attribute value is significant;
      element text is not required to match a value for removal.

   -  An OPTIONAL <eppSLS:tagSvcs> element.  The <eppSLS:tagSvcs>
      element contains one or more <eppSLS:svcURI> elements that contain
      URIs for services to be associated with or removed from the SLS
      object.

   An <eppSLS:chg> element contains the following child elements:

   -  An OPTIONAL <eppSLS:busCat> element that contains business
      category text to be associated with the SLS object.

   -  An OPTIONAL <eppSLS:registrant> element that contains the
      identifier for the human or organizational social information
      (contact) object to be associated with the SLS object as the
      object registrant.  This object identifier MUST be known to the
      server before the contact object can be associated with the SLS



Hollenbeck               Expires March 26, 2006                [Page 30]

Internet-Draft               EPP SLS Mapping              September 2005


      object.  An empty element can be used to remove registrant
      information.

   -  An OPTIONAL <eppSLS:authInfo> element that contains authorization
      information to be associated with the SLS object.  This mapping
      includes a password-based authentication mechanism, but the schema
      allows new mechanisms to be defined in new schemas.  An <eppSLS:
      null> element can be used within the <eppSLS:authInfo> element to
      remove authorization information.










































Hollenbeck               Expires March 26, 2006                [Page 31]

Internet-Draft               EPP SLS Mapping              September 2005


   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
   C:     epp-1.0.xsd">
   C:  <command>
   C:    <update>
   C:      <eppSLS:update
   C:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   C:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   C:       eppSLS-1.0.xsd">
   C:        <eppSLS:tagRec>
   C:          <eppSLS:tag>Example Tag</eppSLS:tag>
   C:          <eppSLS:locale>
   C:            <eppSLS:langCode>en</eppSLS:langCode>
   C:            <eppSLS:terrCode>US</eppSLS:terrCode>
   C:          </eppSLS:locale>
   C:        </eppSLS:tagRec>
   C:        <eppSLS:add>
   C:          <eppSLS:contact type="tech">mak21</eppSLS:contact>
   C:          <eppSLS:status s="clientHold"
   C:           lang="en">Payment overdue.</eppSLS:status>
   C:          <eppSLS:tagSvcs>
   C:            <eppSLS:svcURI>dns:s.example?type=CERT</eppSLS:svcURI>
   C:          </eppSLS:tagSvcs>
   C:        </eppSLS:add>
   C:        <eppSLS:rem>
   C:          <eppSLS:contact type="tech">sh8013</eppSLS:contact>
   C:          <eppSLS:status s="clientUpdateProhibited"/>
   C:        </eppSLS:rem>
   C:        <eppSLS:chg>
   C:          <eppSLS:busCat/>
   C:          <eppSLS:registrant>sh8013</eppSLS:registrant>
   C:          <eppSLS:authInfo>
   C:            <eppSLS:pw>2BARfoo</eppSLS:pw>
   C:          </eppSLS:authInfo>
   C:        </eppSLS:chg>
   C:      </eppSLS: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.




Hollenbeck               Expires March 26, 2006                [Page 32]

Internet-Draft               EPP SLS Mapping              September 2005


   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">
   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.3.  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.

   Examples describing a <create> command that requires offline review
   are included here.  Note the result code and message returned in
   response to the <create> command.














Hollenbeck               Expires March 26, 2006                [Page 33]

Internet-Draft               EPP SLS Mapping              September 2005


   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:      <eppSLS:creData
   S:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   S:       eppSLS-1.0.xsd">
   S:        <eppSLS:tagRec>
   S:          <eppSLS:tag>Example Tag</eppSLS:tag>
   S:          <eppSLS:locale>
   S:            <eppSLS:langCode>en</eppSLS:langCode>
   S:            <eppSLS:terrCode>US</eppSLS:terrCode>
   S:          </eppSLS:locale>
   S:        </eppSLS:tagRec>
   S:        <eppSLS:crDate>1999-04-03T22:00:00.0Z</eppSLS:crDate>
   S:        <eppSLS:exDate>2001-04-03T22:00:00.0Z</eppSLS:exDate>
   S:      </eppSLS:creData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>ABC-12345</clTRID>
   S:      <svTRID>54321-XYZ</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>

   The status of the SLS 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 MUST contain text in the <response>, <msgQ>,
   <msg> element that describes the notification.  In addition, the EPP
   <resData> element MUST contain a child <eppSLS:panData> element that
   identifies the object namespace and the location of the object
   schema.  The <eppSLS:panData> element contains the following child
   elements:








Hollenbeck               Expires March 26, 2006                [Page 34]

Internet-Draft               EPP SLS Mapping              September 2005


   -  An <eppSLS:tagRec> element that identifies the SLS object being
      processed.  The <eppSLS:tagRec> element used in this context is
      identical to the <eppSLS:tagRec> element used by the <check>
      command described in Section 3.1.1, except that the <eppSLS:
      tagRec> element contains a REQUIRED "paResult" attribute.  A
      positive boolean value indicates that the request has been
      approved and completed.  A negative boolean value indicates that
      the request has been denied and the requested action has not been
      taken.

   -  An <eppSLS:paTRID> element that contains the client transaction
      identifier and server transaction identifier returned with the
      original response to process the command.  The client transaction
      identifier is OPTIONAL and will only be returned if the client
      provided an identifier with the original <create> command.

   -  An <eppSLS:paDate> element that contains the date and time
      describing when review of the requested action was completed.

































Hollenbeck               Expires March 26, 2006                [Page 35]

Internet-Draft               EPP SLS Mapping              September 2005


   Example "review completed" service message:

   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="1301">
   S:      <msg>Command completed successfully; ack to dequeue</msg>
   S:    </result>
   S:    <msgQ count="5" id="12345">
   S:      <qDate>1999-04-04T22:01:00.0Z</qDate>
   S:      <msg>Pending action completed successfully.</msg>
   S:    </msgQ>
   S:    <resData>
   S:      <eppSLS:panData
   S:       xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
   S:       xsi:schemaLocation="urn:ietf:params:xml:ns:eppSLS-1.0
   S:       eppSLS-1.0.xsd">
   S:        <eppSLS:tagRec paResult="1">
   S:          <eppSLS:tag>Example Tag</eppSLS:tag>
   S:          <eppSLS:locale>
   S:            <eppSLS:langCode>en</eppSLS:langCode>
   S:            <eppSLS:terrCode>US</eppSLS:terrCode>
   S:          </eppSLS:locale>
   S:        </eppSLS:tagRec>
   S:        <eppSLS:paTRID>
   S:          <clTRID>ABC-12345</clTRID>
   S:          <svTRID>54321-XYZ</svTRID>
   S:        </eppSLS:paTRID>
   S:        <eppSLS:paDate>1999-04-04T22:00:00.0Z</eppSLS:paDate>
   S:      </eppSLS:panData>
   S:    </resData>
   S:    <trID>
   S:      <clTRID>BCD-23456</clTRID>
   S:      <svTRID>65432-WXY</svTRID>
   S:    </trID>
   S:  </response>
   S:</epp>


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



Hollenbeck               Expires March 26, 2006                [Page 36]

Internet-Draft               EPP SLS Mapping              September 2005


   are used to note the beginning and ending of the schema for URI
   registration purposes.

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

   <schema targetNamespace="urn:ietf:params:xml:ns:eppSLS-1.0"
           xmlns:eppSLS="urn:ietf:params:xml:ns:eppSLS-1.0"
           xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
           xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
           xmlns="http://www.w3.org/2001/XMLSchema"
           elementFormDefault="qualified">

   <!--
   Import common element types.
   -->
     <import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
             schemaLocation="eppcom-1.0.xsd"/>
     <import namespace="urn:ietf:params:xml:ns:epp-1.0"
             schemaLocation="epp-1.0.xsd"/>

     <annotation>
       <documentation>
         Extensible Provisioning Protocol v1.0
         Service Lookup System (SLS) provisioning schema.
       </documentation>
     </annotation>

   <!--
   Child elements found in EPP commands.
   -->
     <element name="check" type="eppSLS:sTagType"/>
     <element name="create" type="eppSLS:createType"/>
     <element name="delete" type="eppSLS:sTagType"/>
     <element name="info" type="eppSLS:infoType"/>
     <element name="renew" type="eppSLS:renewType"/>
     <element name="transfer" type="eppSLS:transferType"/>
     <element name="update" type="eppSLS:updateType"/>

   <!--
   Child elements of the <create> command.
   -->
     <complexType name="createType">
       <sequence>
         <element name="tagRec" type="eppSLS:tagRecType"/>
         <element name="tagSvcs" type="eppSLS:tagServiceType"/>
         <element name="busCat" type="eppSLS:businessCategoryType"
          minOccurs="0"/>



Hollenbeck               Expires March 26, 2006                [Page 37]

Internet-Draft               EPP SLS Mapping              September 2005


         <element name="period" type="eppSLS:periodType"
          minOccurs="0"/>
         <element name="registrant" type="eppcom:clIDType"
          minOccurs="0"/>
         <element name="contact" type="eppSLS:contactType"
          minOccurs="0" maxOccurs="unbounded"/>
         <element name="authInfo" type="eppSLS:authInfoType"/>
       </sequence>
     </complexType>

     <complexType name="tagRecType">
       <sequence>
         <element name="tag" type="eppSLS:tagType"/>
         <element name="locale" type="eppSLS:localeType"/>
         <element name="provID" type="eppSLS:providerIDType"
          minOccurs="0"/>
       </sequence>
     </complexType>

     <simpleType name="tagType">
       <restriction base="token">
         <minLength value="1"/>
       </restriction>
     </simpleType>

     <complexType name="tagServiceType">
       <sequence>
         <element name="svcURI" type="anyURI"
          maxOccurs="unbounded"/>
       </sequence>
     </complexType>

     <complexType name="localeType">
       <sequence>
         <element name="langCode" type="eppSLS:langCodeType"/>
         <element name="scriptCode" type="eppSLS:scriptCodeType"
          minOccurs="0"/>
         <element name="terrCode" type="eppSLS:terrCodeType"
          minOccurs="0"/>
         <element name="varCode" type="eppSLS:varCodeType"
          minOccurs="0"/>
       </sequence>
     </complexType>

     <simpleType name="providerIDType">
       <restriction base="token">
         <pattern value="\w{1,8}"/>
       </restriction>



Hollenbeck               Expires March 26, 2006                [Page 38]

Internet-Draft               EPP SLS Mapping              September 2005


     </simpleType>

   <!--
   Language codes are 2- or 3-letter codes defined in ISO 639.
   -->
     <simpleType name="langCodeType">
       <restriction base="token">
         <pattern value="[a-zA-Z]{2,3}"/>
       </restriction>
     </simpleType>

   <!--
   Script codes are 4-letter codes defined in ISO 15924.
   -->
     <simpleType name="scriptCodeType">
       <restriction base="token">
         <pattern value="[A-Z][a-z]{3}"/>
       </restriction>
     </simpleType>

   <!--
   Territory codes are 2-letter codes defined in ISO 3166.
   -->
     <simpleType name="terrCodeType">
       <restriction base="token">
         <pattern value="[A-Z]{2}"/>
       </restriction>
     </simpleType>

   <!--
   Variant codes contain either 1 character or more than 4 characters.
   -->
     <simpleType name="varCodeType">
       <restriction base="token">
         <pattern value="([a-z]{1})|([a-z]{5,})"/>
       </restriction>
     </simpleType>

     <simpleType name="businessCategoryType">
       <restriction base="token">
         <minLength value="1"/>
       </restriction>
     </simpleType>

     <complexType name="periodType">
       <simpleContent>
         <extension base="eppSLS:pLimitType">
           <attribute name="unit" type="eppSLS:pUnitType"



Hollenbeck               Expires March 26, 2006                [Page 39]

Internet-Draft               EPP SLS Mapping              September 2005


            use="required"/>
         </extension>
       </simpleContent>
     </complexType>

     <simpleType name="pLimitType">
       <restriction base="unsignedShort">
         <minInclusive value="1"/>
         <maxInclusive value="99"/>
       </restriction>
     </simpleType>

     <simpleType name="pUnitType">
       <restriction base="token">
         <enumeration value="y"/>
         <enumeration value="m"/>
       </restriction>
     </simpleType>

     <complexType name="contactType">
       <simpleContent>
         <extension base="eppcom:clIDType">
           <attribute name="type" type="eppSLS:contactAttrType"/>
         </extension>
       </simpleContent>
     </complexType>

     <simpleType name="contactAttrType">
       <restriction base="token">
         <enumeration value="admin"/>
         <enumeration value="tech"/>
       </restriction>
     </simpleType>

     <complexType name="authInfoType">
       <choice>
         <element name="pw" type="normalizedString"/>
         <element name="ext" type="eppcom:extAuthInfoType"/>
       </choice>
     </complexType>

   <!--
   Child element of commands that require a single tag record.
   -->
     <complexType name="sTagType">
       <sequence>
         <element name="tagRec" type="eppSLS:tagRecType"/>
       </sequence>



Hollenbeck               Expires March 26, 2006                [Page 40]

Internet-Draft               EPP SLS Mapping              September 2005


     </complexType>

   <!--
   Child elements of the <info> command.
   -->
     <complexType name="infoType">
       <sequence>
         <element name="tagRec" type="eppSLS:tagRecType"/>
         <element name="authInfo" type="eppSLS:authInfoType"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   Child elements of the <renew> command.
   -->
     <complexType name="renewType">
       <sequence>
         <element name="tagRec" type="eppSLS:tagRecType"/>
         <element name="curExpDate" type="date"/>
         <element name="period" type="eppSLS:periodType"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   Child elements of the <transfer> command.
   -->
     <complexType name="transferType">
       <sequence>
         <element name="tagRec" type="eppSLS:tagRecType"/>
         <element name="period" type="eppSLS:periodType"
          minOccurs="0"/>
         <element name="authInfo" type="eppSLS:authInfoType"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   Child elements of the <update> command.
   -->
     <complexType name="updateType">
       <sequence>
         <element name="tagRec" type="eppSLS:tagRecType"/>
         <element name="add" type="eppSLS:addRemType"
          minOccurs="0"/>
         <element name="rem" type="eppSLS:addRemType"
          minOccurs="0"/>



Hollenbeck               Expires March 26, 2006                [Page 41]

Internet-Draft               EPP SLS Mapping              September 2005


         <element name="chg" type="eppSLS:chgType"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   Data elements that can be added or removed.
   -->
     <complexType name="addRemType">
       <sequence>
         <element name="contact" type="eppSLS:contactType"
          minOccurs="0" maxOccurs="unbounded"/>
         <element name="status" type="eppSLS:statusType"
          minOccurs="0" maxOccurs="11"/>
         <element name="tagSvcs" type="eppSLS:tagServiceType"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   Data elements that can be changed.
   -->
     <complexType name="chgType">
       <sequence>
         <element name="busCat" type="token"
          minOccurs="0"/>
         <element name="registrant" type="eppSLS:clIDChgType"
          minOccurs="0"/>
         <element name="authInfo" type="eppSLS:authInfoChgType"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   Allow the registrant value to be nullified by changing the
   minLength restriction to "0".
   -->
     <simpleType name="clIDChgType">
       <restriction base="token">
         <minLength value="0"/>
         <maxLength value="16"/>
       </restriction>
     </simpleType>

   <!--
   Allow the authInfo value to be nullified by including an
   empty element within the choice.
   -->



Hollenbeck               Expires March 26, 2006                [Page 42]

Internet-Draft               EPP SLS Mapping              September 2005


     <complexType name="authInfoChgType">
       <choice>
         <element name="pw" type="eppcom:pwAuthInfoType"/>
         <element name="ext" type="eppcom:extAuthInfoType"/>
         <element name="null"/>
       </choice>
     </complexType>

   <!--
   Child response elements.
   -->
     <element name="chkData" type="eppSLS:chkDataType"/>
     <element name="creData" type="eppSLS:creDataType"/>
     <element name="infData" type="eppSLS:infDataType"/>
     <element name="panData" type="eppSLS:panDataType"/>
     <element name="renData" type="eppSLS:renDataType"/>
     <element name="trnData" type="eppSLS:trnDataType"/>

   <!--
   <check> response elements.
   -->
     <complexType name="chkDataType">
       <sequence>
         <element name="cd" type="eppSLS:checkType"
          maxOccurs="unbounded"/>
       </sequence>
     </complexType>

     <complexType name="checkType">
       <sequence>
         <element name="tagRec" type="eppSLS:checkTagRecType"/>
         <element name="reason" type="eppcom:reasonType"
          minOccurs="0"/>
       </sequence>
     </complexType>

     <complexType name="checkTagRecType">
       <complexContent>
         <extension base="eppSLS:tagRecType">
           <attribute name="avail" type="boolean"
            use="required"/>
         </extension>
       </complexContent>
     </complexType>

   <!--
   <create> response elements.
   -->



Hollenbeck               Expires March 26, 2006                [Page 43]

Internet-Draft               EPP SLS Mapping              September 2005


     <complexType name="creDataType">
       <sequence>
         <element name="tagRec" type="eppSLS:tagRecType"/>
         <element name="crDate" type="dateTime"/>
         <element name="exDate" type="dateTime"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   <info> response elements.
   -->
     <complexType name="infDataType">
       <sequence>
         <element name="tagRec" type="eppSLS:tagRecType"/>
         <element name="tagSvcs" type="eppSLS:tagServiceType"
          minOccurs="0"/>
         <element name="busCat" type="eppSLS:businessCategoryType"
          minOccurs="0"/>
         <element name="status" type="eppSLS:statusType"
          minOccurs="0" maxOccurs="10"/>
         <element name="registrant" type="eppcom:clIDType"
          minOccurs="0"/>
         <element name="contact" type="eppSLS:contactType"
          minOccurs="0" maxOccurs="unbounded"/>
         <element name="clID" type="eppcom:clIDType"/>
         <element name="crID" type="eppcom:clIDType"
          minOccurs="0"/>
         <element name="crDate" type="dateTime"
          minOccurs="0"/>
         <element name="upID" type="eppcom:clIDType"
          minOccurs="0"/>
         <element name="upDate" type="dateTime"
          minOccurs="0"/>
         <element name="exDate" type="dateTime"
          minOccurs="0"/>
         <element name="trDate" type="dateTime"
          minOccurs="0"/>
         <element name="authInfo" type="eppSLS:authInfoType"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   Status is a combination of attributes and an optional human-readable
   message that may be expressed in languages other than English.
   -->
     <complexType name="statusType">



Hollenbeck               Expires March 26, 2006                [Page 44]

Internet-Draft               EPP SLS Mapping              September 2005


       <simpleContent>
         <extension base="normalizedString">
           <attribute name="s" type="eppSLS:statusValueType"
            use="required"/>
           <attribute name="lang" type="language"
            default="en"/>
         </extension>
       </simpleContent>
     </complexType>

     <simpleType name="statusValueType">
       <restriction base="token">
         <enumeration value="clientDeleteProhibited"/>
         <enumeration value="clientHold"/>
         <enumeration value="clientRenewProhibited"/>
         <enumeration value="clientTransferProhibited"/>
         <enumeration value="clientUpdateProhibited"/>
         <enumeration value="ok"/>
         <enumeration value="pendingCreate"/>
         <enumeration value="pendingDelete"/>
         <enumeration value="pendingRenew"/>
         <enumeration value="pendingTransfer"/>
         <enumeration value="pendingUpdate"/>
         <enumeration value="serverDeleteProhibited"/>
         <enumeration value="serverHold"/>
         <enumeration value="serverRenewProhibited"/>
         <enumeration value="serverTransferProhibited"/>
         <enumeration value="serverUpdateProhibited"/>
       </restriction>
     </simpleType>

   <!--
   Pending action notification response elements.
   -->
     <complexType name="panDataType">
       <sequence>
         <element name="tagRec" type="eppSLS:paTagRecType"/>
         <element name="paTRID" type="epp:trIDType"/>
         <element name="paDate" type="dateTime"/>
       </sequence>
     </complexType>

     <complexType name="paTagRecType">
       <complexContent>
         <extension base="eppSLS:tagRecType">
           <attribute name="paResult" type="boolean"
            use="required"/>
         </extension>



Hollenbeck               Expires March 26, 2006                [Page 45]

Internet-Draft               EPP SLS Mapping              September 2005


       </complexContent>
     </complexType>

   <!--
   <renew> response elements.
   -->
     <complexType name="renDataType">
       <sequence>
         <element name="tagRec" type="eppSLS:tagRecType"/>
         <element name="exDate" type="dateTime"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   <transfer> response elements.
   -->
     <complexType name="trnDataType">
       <sequence>
         <element name="tagRec" type="eppSLS:tagRecType"/>
         <element name="trStatus" type="eppcom:trStatusType"/>
         <element name="reID" type="eppcom:clIDType"/>
         <element name="reDate" type="dateTime"/>
         <element name="acID" type="eppcom:clIDType"/>
         <element name="acDate" type="dateTime"/>
         <element name="exDate" type="dateTime"
          minOccurs="0"/>
       </sequence>
     </complexType>

   <!--
   End of schema.
   -->
   </schema>
   END


5.  Internationalization Considerations

   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 [RFC3629].  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.




Hollenbeck               Expires March 26, 2006                [Page 46]

Internet-Draft               EPP SLS Mapping              September 2005


   All date-time values presented via EPP MUST be expressed in Universal
   Coordinated Time using the Gregorian calendar.  XML Schema allows use
   of time zone identifiers to indicate offsets from the zero meridian,
   but this option MUST NOT be used with EPP.  The extended date-time
   form using upper case "T" and "Z" characters defined in RFC 3339
   [RFC3339] MUST be used to represent date-time values as XML Schema
   does not support truncated date-time forms or lower case "T" and "Z"
   characters.


6.  IANA Considerations

   This document uses URNs to describe XML namespaces and XML schemas
   conforming to a registry mechanism described in RFC 3688 [RFC3688].
   Two URI assignments are requested.

   Registration request for the extension namespace:

   URI: urn:ietf:params:xml:ns:eppSLS-1.0

   Registrant Contact: IESG

   XML: None.  Namespace URIs do not represent an XML specification.

   Registration request for the extension XML schema:

   URI: urn:ietf:params:xml:schema:eppSLS-1.0

   Registrant Contact: IESG

   XML: See the "Formal Syntax" section of this document.


7.  Security Considerations

   Authorization information as described in Section 3.2.1 is REQUIRED
   to create an SLS object.  This information is used in some query and
   transfer operations as an additional means of determining client
   authorization to perform the command.  Failure to protect
   authorization information from inadvertent disclosure can result in
   unauthorized transfer operations and unauthorized information
   release.  Both client and server MUST ensure that authorization
   information is stored and exchanged with high-grade encryption
   mechanisms to provide privacy services.

   The object mapping described in this document does not provide any
   other security services or introduce any additional considerations
   beyond those described by RFC 3730bis [I-D.hollenbeck-epp-rfc3730bis]



Hollenbeck               Expires March 26, 2006                [Page 47]

Internet-Draft               EPP SLS Mapping              September 2005


   and protocol layers used by EPP.


8.  Acknowledgements

   The author would like to thank the following people who have provided
   significant contributions to the development of this document:

   Mark Kosters, Andrew Newton.


9.  References

9.1.  Normative References

   [I-D.daigle-iris-slsreg]
              Daigle, L. and A. Newton, "IRIS Service Lookup System",
              draft-daigle-iris-slsreg-00 (work in progress), May 2005.

   [I-D.hollenbeck-epp-rfc3730bis]
              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              draft-hollenbeck-epp-rfc3730bis-00 (work in progress),
              September 2005.

   [I-D.hollenbeck-epp-rfc3733bis]
              Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Contact Mapping", draft-hollenbeck-epp-rfc3733bis-00 (work
              in progress), September 2005.

   [I-D.ietf-ltru-registry]
              Phillips, A. and M. Davis, "Tags for Identifying
              Languages", draft-ietf-ltru-registry-12 (work in
              progress), August 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC3981]  Newton, A. and M. Sanz, "IRIS: The Internet Registry
              Information Service (IRIS) Core Protocol", RFC 3981,
              January 2005.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.




Hollenbeck               Expires March 26, 2006                [Page 48]

Internet-Draft               EPP SLS Mapping              September 2005


   [RFC3987]  Duerst, M. and M. Suignard, "Internationalized Resource
              Identifiers (IRIs)", RFC 3987, January 2005.

   [W3C.REC-xml-20001006]
              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.

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

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

9.2.  Informative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC2781]  Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
              10646", RFC 2781, February 2000.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.





















Hollenbeck               Expires March 26, 2006                [Page 49]

Internet-Draft               EPP SLS Mapping              September 2005


Author's Address

   Scott Hollenbeck
   VeriSign, Inc.
   21345 Ridgetop Circle
   Dulles, VA  20166-6503
   US

   Email: shollenbeck@verisign.com










































Hollenbeck               Expires March 26, 2006                [Page 50]

Internet-Draft               EPP SLS Mapping              September 2005


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 (2005).  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.




Hollenbeck               Expires March 26, 2006                [Page 51]