Network Working Group                                         Ning Zhang
INTERNET-DRAFT                                             NeuStar, Inc.
December 2001                                     Expires: June 30, 2002


         Extensible Provisioning Protocol Subscription Mapping
                    <draft-zhang-epp-svcsub-00.txt>

Status of this Memo

  This document is an Internet-Draft and is in full conformance with all
  provisions of Section 10 of RFC2026.

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

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

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

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

Abstract

  This document describes an Extensible Provisioning Protocol (EPP)
  mapping for the provisioning and management of service subscription
  objects stored in a shared central repository.  Specified in XML, the
  mapping defines EPP command syntax and semantics as applied to
  subscription objects.

Conventions Used In This Document

  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in [RFC2119].










Ning Zhang                Expires June 30, 2002                 [Page 1]

Internet-Draft          EPP Subscription Mapping           December 2001


Table of Contents

  1. Introduction .................................................    3
  2. Object Attributes ............................................    4
  2.1 Subscription Identifiers ....................................    4
  2.2 Service Identifiers .........................................    4
  2.3 Service Parameters ..........................................    4
  2.4 Contact and Client Identifiers ..............................    4
  2.5 Status Values ...............................................    5
  2.6 Dates and Times .............................................    6
  2.7 Validity Periods ............................................    6
  2.8 Authorization Information ...................................    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 ........................................    9
  3.1.3 EPP <transfer> Command ....................................   12
  3.2 EPP Transform Commands ......................................   15
  3.2.1 EPP <create> Command ......................................   15
  3.2.2 EPP <delete> Command ......................................   17
  3.2.3 EPP <renew> Command .......................................   19
  3.2.4 EPP <transfer> Command ....................................   21
  3.2.5 EPP <update> Command ......................................   23
  4. Formal Syntax ................................................   26
  5. Internationalization Considerations ..........................   34
  6. IANA Considerations ..........................................   35
  7. Security Considerations ......................................   36
  8. Acknowledgements .............................................   37
  9. References ...................................................   38
  10. Authors' Address ............................................   39
  A. Full Copyright Statement .....................................   40




















Ning Zhang                Expires June 30, 2002                 [Page 2]

Internet-Draft          EPP Subscription Mapping           December 2001


1. Introduction

  This document describes a service subscription mapping for version 1.0
  of the Extensible Provisioning Protocol (EPP).  This mapping is
  specified using the Extensible Markup Language (XML) 1.0 as described
  in [XML] and XML Schema notation as described in [XMLS-1] and
  [XMLS-2]. However, notification or delivery methods for subscription
  services are not covered by this document.

  [EPP] provides a complete description of EPP command and response
  structures.  A thorough understanding of the base protocol
  specification is necessary to understand the mapping described in this
  document.

  XML is case sensitive.  Unless stated otherwise, XML specifications
  and examples provided in this document MUST be interpreted in the
  character case presented to develop a conforming implementation.


































Ning Zhang                Expires June 30, 2002                 [Page 3]

Internet-Draft          EPP Subscription Mapping           December 2001


2. Object Attributes

  An EPP subscription object has attributes and associated values that
  may 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.

2.1 Subscription Identifiers

  All EPP subscriptions are identified by a server-unique identifier.
  Subscription identifiers are character strings with a specified
  minimum length, a specified maximum length and a specified format.
  Subscription identifiers use the "subIDType" syntax described in the
  "Formal Syntax" section of this document.

2.2 Service Identifiers

  Every EPP subscription MUST be associated with a subscription service.
  A registry server MAY support a set of pre-defined services.  All EPP
  subscription services are identified by a server-unique identifier.
  Service identifiers are character strings with a specified minimum
  length, a specified maximum length and a specified format. Service
  identifiers use the "svcIDType" syntax described in the "Formal
  Syntax" section of this document.

2.3 Service Parameters

  Every EPP subscription MAY be associated with a set of service
  parameters that are meaningful to the service subscribed.  Service
  parameters are character strings with a specified minimum length, a
  specified maximum length and a specified format. A REQUIRED "name"
  attribute is provided to specify the name of a service parameter.

  A registry server MAY support a set of pre-defined parameter values
  and types associated with each service provided. Also the registry
  server MAY impose a limit on the number of parameters that can be
  supplied with a single subscription. Service parameters use the
  "svcParamType" syntax described in the "Formal Syntax" section of this
  document.

2.4 Contact and Client Identifiers

  All EPP contacts and clients are identified by a server-unique
  identifier.  Contact and client identifiers are character strings with
  a specified minimum length, a specified maximum length, and a
  specified format.  Contact and client identifiers use the "clIDType"
  client identifier syntax described in [EPP].



Ning Zhang                Expires June 30, 2002                 [Page 4]

Internet-Draft          EPP Subscription Mapping           December 2001


2.5 Status Values

  A subscription object MUST always have at least one associated status
  value.  Status values MAY be set only by the client that sponsors a
  subscription object and by the server on which the object resides.  A
  client MAY change the status of a subscription 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.

  Status values that may be added or removed by a client are prefixed
  with "client".  Corresponding status values that may 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.

  clientSuspended, serverSuspended

  Service for the subscription has been suspended.

  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.

  inactive

  Service for the subscription has not been activated.

  ok




Ning Zhang                Expires June 30, 2002                 [Page 5]

Internet-Draft          EPP Subscription Mapping           December 2001


  This is the nominal status value for an object that has no pending
  operations, suspensions, or prohibitions.

  pendingDelete

  A delete request has been received for the object, but the object has
  not yet been purged from the server database.

  pendingTransfer

  A transfer request has been received for the object, and completion of
  the request is pending.  Transform commands other than <transfer> MUST
  be rejected while an object is in this state.

  pendingVerification

  A create or update request has been received for the object, and
  completion of the request is pending.

  "ok" status MUST NOT be combined with any other status.
  "pendingDelete" status MUST NOT be combined with either
  "clientDeleteProhibited" or "serverDeleteProhibited" status.
  "pendingTransfer" status MUST NOT be combined with either
  "clientTransferProhibited" or "serverTransferProhibited" status.  All
  other status value combinations are valid.

2.6 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 defined in [ISO8601] MUST be used to represent date-
  time values as XML Schema does not support truncated date-time forms.

2.7 Validity Periods

  A subscription object MAY have a specified validity period.  If server
  policy supports subscription object validity periods, the validity
  period is defined when a subscription object is created, and it MAY be
  extended by the EPP <renew> or <transfer> commands.  As a matter of
  server policy, this specification does not define actions to be taken
  upon expiration of a subscription object's validity period.

  Validity periods are measured in years or months with the appropriate
  units specified using the "unit" attribute.  Valid values for the
  "unit" attribute are "y" for years and "m" for months.  The minimum
  allowable period value is one decimal (1).  The maximum allowable
  value is ninety-nine decimal (99).  A server MAY support a lower
  maximum value.



Ning Zhang                Expires June 30, 2002                 [Page 6]

Internet-Draft          EPP Subscription Mapping           December 2001


2.8 Authorization Information

  Authorization information is associated with subscription objects to
  facilitate transfer operations if they are supported by the registry.
  Also it MAY BE REQUIRED for processing <info>, <update>, <delete> and
  <renew> commands, depending on registry policy.  Authorization
  information MAY BE assigned when a subscription object is created, and
  it MAY be updated in the future.  This specification describes
  password-based authorization information, though other mechanisms are
  possible.









































Ning Zhang                Expires June 30, 2002                 [Page 7]

Internet-Draft          EPP Subscription Mapping           December 2001


3. EPP Command Mapping

  A detailed description of the EPP syntax and semantics can be found in
  [EPP].  The command mappings described here are specifically for use
  in provisioning and managing subscription objects via EPP.

3.1 EPP Query Commands

  EPP provides three commands to retrieve subscription information:
  <check> to determine if a subscription object is available for
  provisioning, <info> to retrieve detailed information associated with
  a subscription object, and <transfer> to retrieve subscription object
  transfer status information.

3.1.1 EPP <check> Command

  The EPP <check> command is used to determine if an object may 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 <check> command.  Object availability and provisioning
  conditions are a matter of server policy.

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

  - One or more <svcsub:id> elements that contain the identifiers of the
  subscription objects to be queried.

  Example <check> command:

  C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  C:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  C:     xsi:schemaLocation="urn:iana:xml:ns:epp-1.0 epp-1.0.xsd">
  C:  <command>
  C:    <check>
  C:      <svcsub:check xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  C:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  C:       svcsub-1.0.xsd">
  C:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  C:        <svcsub:id>SVCSUB-SERVICE-2</svcsub:id>
  C:        <svcsub:id>SVCSUB-SERVICE-3</svcsub:id>
  C:      </svcsub:check>
  C:    </check>
  C:    <clTRID>ABC-12345</clTRID>
  C:  </command>



Ning Zhang                Expires June 30, 2002                 [Page 8]

Internet-Draft          EPP Subscription Mapping           December 2001


  C:</epp>

  When a <check> command has been processed successfully, the EPP
  <resData> element MUST contain a child <svcsub:chkData> element that
  identifies the subscription namespace and the location of the
  subscription schema.  The <svcsub:chkData> element contains the
  following child elements:

  - One or more <svcsub:cd> elements that contain the server-unique
  identifier for the queried subscription objects and an "x" attribute
  whose value identifies the object as either "+" for a known object or
  "-" for an unknown subscription.

  Example <check> response:

  S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  S:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  S:     xsi:schemaLocation="urn:iana:xml:ns:epp-1.0 epp-1.0.xsd">
  S:  <response>
  S:    <result code="1000">
  S:      <msg>Command completed successfully</msg>
  S:    </result>
  S:    <resData>
  S:      <svcsub:chkData xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  S:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  S:       svcsub-1.0.xsd">
  S:        <svcsub:cd x="+">SVCSUB-SERVICE-1</svcsub:cd>
  S:        <svcsub:cd x="-">SVCSUB-SERVICE-2</svcsub:cd>
  S:        <svcsub:cd x="+">SVCSUB-SERVICE-3</svcsub:cd>
  S:      </svcsub:chkData>
  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 <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
  a subscription object.  In addition to the standard EPP command
  elements, the <info> command MUST contain a <svcsub:info> element that
  identifies the subscription namespace and the location of the



Ning Zhang                Expires June 30, 2002                 [Page 9]

Internet-Draft          EPP Subscription Mapping           December 2001


  subscription schema.  The <svcsub:info> element contains the following
  child elements:

  - A <svcsub:id> element that contains the server-unique identifier of
  the subscription object to be queried.

  - An OPTIONAL <svcsub:userid> element that can be used for
  authorization purpose in addition to the <svcsub:authInfo> element.
  The value of this element may be provisioned via other channels.
  Registry policy on a specific service will specify the mechanism of
  the userid provisioning and decide if the userid information is
  REQUIRED for the operation.

  - An OPTIONAL <svcsub:authInfo> element that contains authorization
  information associated with the subscription object or authorization
  information associated with the subscription object's registrant or
  associated contacts.  Registry policy on a specific service will
  specify the mechanism of the object association and decide if the
  authorization information is REQUIRED for the operation.

  Example <info> command:

  C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  C:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  C:     xsi:schemaLocation="urn:iana:xml:ns:epp-1.0 epp-1.0.xsd">
  C:  <command>
  C:    <info>
  C:      <svcsub:info xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  C:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  C:       svcsub-1.0.xsd">
  C:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  C:        <svcsub:userid>MYUSERID</svcsub:userid>
  C:        <svcsub:authInfo type="pw">2fooBar</svcsub:authInfo>
  C:      </svcsub: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 <svcsub:infData> element that
  identifies the subscription namespace and the location of the
  subscription schema. The <svcsub:infData> element contains the
  following child elements:

  - A <svcsub:id> element that contains the server-unique identifier of
  the subscription object.



Ning Zhang                Expires June 30, 2002                [Page 10]

Internet-Draft          EPP Subscription Mapping           December 2001


  - A <svcsub:roid> element that contains the Repository Object
  IDentifier assigned to the subscription object when the object was
  created.

  - One or more <svcsub:status> elements that describe the status of the
  subscription object.

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

  - A <svcsub:service> element that contains the server-unique
  identifier of the service subscribed by the subscription.

  - Zero or more <svcsub:param> elements that contain the service
  parameters to be associated with the subscription object. Each element
  MUST include a REQUIRED "name" attribute for identifying the name of
  the service parameter.

  - A <svcsub:clID> element that contains the identifier of the
  sponsoring client.

  - A <svcsub:crID> element that contains the identifier of the client
  that created the subscription object.

  - A <svcsub:crDate> element that contains the date and time of
  subscription object creation.

  - A <svcsub:exDate> element that contains the date and time
  identifying the end of the subscription object's registration period.

  - A <svcsub:upID> element that contains the identifier of the client
  that last updated the subscription object.  This element MUST NOT be
  present if the subscription object has never been modified.

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

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

  - A <svcsub:authInfo> element that contains authorization information
  to be associated with the subscription object. This element MUST NOT
  be provided if the querying client is not the current sponsoring



Ning Zhang                Expires June 30, 2002                [Page 11]

Internet-Draft          EPP Subscription Mapping           December 2001


  client.

  Example <info> response:

  S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  S:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  S:     xsi:schemaLocation="urn:iana:xml:ns:epp-1.0 epp-1.0.xsd">
  S:  <response>
  S:    <result code="1000">
  S:      <msg>Command completed successfully</msg>
  S:    </result>
  S:    <resData>
  S:      <svcsub:infData xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  S:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  S:       svcsub-1.0.xsd">
  S:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  S:        <svcsub:roid>SVC12345-NEULEVEL</svcsub:roid>
  S:        <svcsub:status s="clientDeleteProhibited"/>
  S:        <svcsub:status s="clientTransferProhibited"/>
  S:        <svcsub:registrant>jd1234</svcsub:registrant>
  S:        <svcsub:contact type="admin">sh8013</svcsub:contact>
  S:        <svcsub:contact type="billing">sh8013</svcsub:contact>
  S:        <svcsub:service>DOMAIN-NAME-WATCH</svcsub:service>
  S:        <svcsub:param name="exact">neustar</svcsub:param>
  S:        <svcsub:param name="regexp">*neulevel*</svcsub:param>
  S:        <svcsub:clID>ClientY</svcsub:clID>
  S:        <svcsub:crID>ClientX</svcsub:crID>
  S:        <svcsub:crDate>2001-12-03T22:00:00.0Z</svcsub:crDate>
  S:        <svcsub:upID>ClientX</svcsub:upID>
  S:        <svcsub:upDate>2001-12-05T09:00:00.0Z</svcsub:upDate>
  S:        <svcsub:exDate>2009-12-03T09:00:00.0Z</svcsub:exDate>
  S:        <svcsub:trDate>2002-04-08T09:00:00.0Z</svcsub:trDate>
  S:        <svcsub:authInfo type="pw">2fooBAR</svcsub:authInfo>
  S:      </svcsub:infData>
  S:    </resData>
  S:    <trID>
  S:      <clTRID>ABC-12346</clTRID>
  S:      <svTRID>54321-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




Ning Zhang                Expires June 30, 2002                [Page 12]

Internet-Draft          EPP Subscription Mapping           December 2001


  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 a <svcsub:transfer> element that identifies the subscription
  namespace and the location of the subscription schema.  The
  <svcsub:transfer> element MUST contain the following child elements:

  - A <svcsub:id> element that contains the server-unique identifier of
  the subscription object to be queried.

  - An OPTIONAL <svcsub:userid> element that can be used for
  authorization purpose in addition to the <svcsub:authInfo> element.
  The value of this element may be provisioned via other channels.
  Registry policy on a specific service will specify the mechanism of
  the userid provisioning and decide if the userid information is
  REQUIRED for the operation.

  - An OPTIONAL <svcsub:authInfo> element that contains authorization
  information associated with the subscription object or authorization
  information associated with the subscription object's registrant or
  associated contacts.  Registry policy on a specific service will
  specify the mechanism of the object association and decide if the
  authorization information is REQUIRED for the operation.

  Example <transfer> query command:

  C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  C:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  C:     xsi:schemaLocation="urn:iana:xml:ns:epp-1.0 epp-1.0.xsd">
  C:  <command>
  C:    <transfer op="query">
  C:      <svcsub:transfer xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  C:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  C:       svcsub-1.0.xsd">
  C:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  C:      </svcsub: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 <svcsub:trnData> element
  that identifies the subscription namespace and the location of the
  subscription schema. The <svcsub:trnData> element contains the
  following child elements:



Ning Zhang                Expires June 30, 2002                [Page 13]

Internet-Draft          EPP Subscription Mapping           December 2001


  - A <svcsub:id> element that contains the server-unique identifier for
  the queried subscription object.

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

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

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

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

  - A <svcsub: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 SHOULD be taken by the server.  For all
  other status types, the value identifies the date and time when the
  request was completed.

  Example <transfer> query response:

  S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  S:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  S:     xsi:schemaLocation="urn:iana:xml:ns:epp-1.0 epp-1.0.xsd">
  S:  <response>
  S:    <result code="1000">
  S:      <msg>Command completed successfully</msg>
  S:    </result>
  S:    <resData>
  S:      <svcsub:trnData xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  S:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  S:       svcsub-1.0.xsd">
  S:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  S:        <svcsub:trStatus>pending</svcsub:trStatus>
  S:        <svcsub:reID>ClientX</svcsub:reID>
  S:        <svcsub:reDate>2000-06-06T22:00:00.0Z</svcsub:reDate>
  S:        <svcsub:acID>ClientY</svcsub:acID>
  S:        <svcsub:acDate>2000-06-11T22:00:00.0Z</svcsub:acDate>
  S:      </svcsub:trnData>
  S:    </resData>
  S:    <trID>
  S:      <clTRID>ABC-12345</clTRID>
  S:      <svTRID>54321-XYZ</svTRID>
  S:    </trID>



Ning Zhang                Expires June 30, 2002                [Page 14]

Internet-Draft          EPP Subscription Mapping           December 2001


  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 subscription objects: <create>
  to create an instance of a subscription object, <delete> to delete an
  instance of a subscription object, <renew> to extend the validity
  period of a subscription object, <transfer> to manage subscription
  object sponsorship changes, and <update> to change information
  associated with a subscription object.

3.2.1 EPP <create> Command

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

  - A <svcsub:id> element that contains the identifier of the
  subscription object to be created.

  - A <svcsub:service> element that contains the server-unique
  identifier of the service subscribed by the subscription.

  - Zero or more <svcsub:param> elements that contain the service
  parameters to be associated with the subscription object. Each element
  MUST include a REQUIRED "name" attribute for identifying the name of
  the service parameter.

  - An OPTIONAL <svcsub:period> element that contains the initial
  registration/subscription period of the subscription object.  A server
  MAY define a default initial registration/subscription period if not
  specified by the client.

  - An OPTIONAL <svcsub:registrant> element that contains the identifier
  for the human or organizational social information (contact) object to
  be associated with the subscription object as the object registrant.
  This object identifier MUST be known to the server before the contact
  object can be associated with the subscription object.  The EPP
  mapping for contact objects is described in [EPP-C].

  - Zero or more OPTIONAL <svcsub:contact> elements that contain the



Ning Zhang                Expires June 30, 2002                [Page 15]

Internet-Draft          EPP Subscription Mapping           December 2001


  identifiers for other contact objects to be associated with the
  subscription object.  Contact object identifiers MUST be known to the
  server before the contact object can be associated with the
  subscription object.

  - An OPTIONAL <svcsub:authInfo> element that contains authorization
  information to be associated with the subscription object. It MAY BE
  REQUIRED for specific services as defined by the registry server.

  Example <create> command:

  C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  C:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  C:     xsi:schemaLocation="urn:iana:xml:ns:epp-1.0
  C:     epp-1.0.xsd">
  C:  <command>
  C:    <create>
  C:      <svcsub:create xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  C:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  C:       svcsub-1.0.xsd">
  C:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  C:        <svcsub:service>DOMAIN-NAME-WATCH</svcsub:service>
  C:        <svcsub:param name="exact">neustar</svcsub:param>
  C:        <svcsub:param name="regexp">*neulevel*</svcsub:param>
  C:        <svcsub:period unit="y">2</svcsub:period>
  C:        <svcsub:registrant>jd1234</svcsub:registrant>
  C:        <svcsub:contact type="admin">sh8013</svcsub:contact>
  C:        <svcsub:contact type="billing">sh8013</svcsub:contact>
  C:        <svcsub:authInfo type="pw">2fooBAR</svcsub:authInfo>
  C:      </svcsub: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 <svcsub:creData> element that
  identifies the subscription namespace and the location of the
  subscription schema.  The <svcsub:creData> element contains the
  following child elements:

  - A <svcsub:id> element that contains the identifier of the
  subscription object created.

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




Ning Zhang                Expires June 30, 2002                [Page 16]

Internet-Draft          EPP Subscription Mapping           December 2001


  Example <create> response:

  S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  S:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  S:     xsi:schemaLocation="urn:iana: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:      <svcsub:creData
  S:       xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  S:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  S:       svcsub-1.0.xsd">
  S:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  S:        <svcsub:exDate>2003-12-03T22:00:00.0Z</svcsub:exDate>
  S:      </svcsub: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.

3.2.2 EPP <delete> Command

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

  - A <svcsub:id> element that contains the identifier of the
  subscription object to be deleted.

  - An OPTIONAL <svcsub:userid> element that can be used for
  authorization purpose in addition to the <svcsub:authInfo> element.
  The value of this element may be provisioned via other channels.
  Registry policy on a specific service will specify the mechanism of
  the userid provisioning and decide if the userid information is
  REQUIRED for the operation.



Ning Zhang                Expires June 30, 2002                [Page 17]

Internet-Draft          EPP Subscription Mapping           December 2001


  - An OPTIONAL <svcsub:authInfo> element that contains authorization
  information associated with the subscription object or authorization
  information associated with the subscription object's registrant or
  associated contacts.  Registry policy on a specific service will
  specify the mechanism of the object association and decide if the
  authorization information is REQUIRED for the operation.

  Example <delete> command:

  C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  C:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  C:     xsi:schemaLocation="urn:iana:xml:ns:epp-1.0
  C:     epp-1.0.xsd">
  C:  <command>
  C:    <delete>
  C:      <svcsub:delete
  C:       xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  C:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  C:       svcsub-1.0.xsd">
  C:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  C:      </svcsub: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.

  Example <delete> response:

  S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  S:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  S:     xsi:schemaLocation="urn:iana: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>




Ning Zhang                Expires June 30, 2002                [Page 18]

Internet-Draft          EPP Subscription Mapping           December 2001


  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 a subscription object.  In
  addition to the standard EPP command elements, the <renew> command
  MUST contain a <svcsub:renew> element that identifies the subscription
  namespace and the location of the subscription schema.  The
  <svcsub:renew> element contains the following child elements:

  - A <svcsub:id> element that contains the identifier of the
  subscription object whose validity period is to be extended.

  - A <svcsub: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 <svcsub:period> element that contains the number of
  units to be added to the registration period of the subscription
  object.

  - An OPTIONAL <svcsub:userid> element that can be used for
  authorization purpose in addition to the <svcsub:authInfo> element.
  The value of this element may be provisioned via other channels.
  Registry policy on a specific service will specify the mechanism of
  the userid provisioning and decide if the userid information is
  REQUIRED for the operation.

  - An OPTIONAL <svcsub:authInfo> element that contains authorization
  information associated with the subscription object or authorization
  information associated with the subscription object's registrant or
  associated contacts.  Registry policy on a specific service will
  specify the mechanism of the object association and decide if the
  authorization information is REQUIRED for the operation.

  Example <renew> command:

  C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  C:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  C:     xsi:schemaLocation="urn:iana:xml:ns:epp-1.0
  C:     epp-1.0.xsd">
  C:  <command>
  C:    <renew>
  C:      <svcsub:renew



Ning Zhang                Expires June 30, 2002                [Page 19]

Internet-Draft          EPP Subscription Mapping           December 2001


  C:       xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  C:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  C:       svcsub-1.0.xsd">
  C:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  C:        <svcsub:curExpDate>2003-12-03</svcsub:curExpDate>
  C:        <svcsub:period unit="y">5</svcsub:period>
  C:      </svcsub: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 <svcsub:creData> element that
  identifies the subscription namespace and the location of the
  subscription schema.  The <svcsub:creData> element contains the
  following child elements:

  - A <svcsub:id> element that contains the identifier of the
  subscription object whose validity period is extended.

  - A <svcsub:exDate> element that contains the date and time
  identifying the end of the subscription object's registration period.

  Example <renew> response:

  S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  S:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  S:     xsi:schemaLocation="urn:iana: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:      <svcsub:creData
  S:       xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  S:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  S:       svcsub-1.0.xsd">
  S:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  S:        <svcsub:exDate>2008-12-03T22:00:00.0Z</svcsub:exDate>
  S:      </svcsub:creData>
  S:    </resData>
  S:    <trID>
  S:      <clTRID>ABC-12345</clTRID>
  S:      <svTRID>54321-XYZ</svTRID>
  S:    </trID>



Ning Zhang                Expires June 30, 2002                [Page 20]

Internet-Draft          EPP Subscription Mapping           December 2001


  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 a
  subscription object.  In addition to the standard EPP command
  elements, the <transfer> command MUST contain a <svcsub:transfer>
  element that identifies the subscription namespace and the location of
  the subscription schema.  The <svcsub:transfer> element contains the
  following child elements:

  - A <svcsub:id> element that contains the identifier of the
  subscription object for which a transfer request is to be created,
  approved, rejected, or cancelled.

  - An OPTIONAL <svcsub:period> element that contains the number of
  units to be added to the registration period of the subscription
  object at completion of the transfer process.  This element MAY only
  be used when a transfer is requested, and it MUST be ignored if used
  otherwise.

  - An OPTIONAL <svcsub:userid> element that can be used for
  authorization purpose in addition to the <svcsub:authInfo> element.
  The value of this element may be provisioned via other channels.
  Registry policy on a specific service will specify the mechanism of
  the userid provisioning and decide if the userid information is
  REQUIRED for the operation.

  - A <svcsub:authInfo> element that contains authorization information
  associated with the subscription object or authorization information
  associated with the subscription object's registrant or associated
  contacts.  This element is REQUIRED only when a transfer is requested,
  and it MUST be ignored if used otherwise.

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

  Example <transfer> request command:

  C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  C:<epp xmlns="urn:iana:xml:ns:epp-1.0"



Ning Zhang                Expires June 30, 2002                [Page 21]

Internet-Draft          EPP Subscription Mapping           December 2001


  C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  C:     xsi:schemaLocation="urn:iana:xml:ns:epp-1.0
  C:     epp-1.0.xsd">
  C:  <command>
  C:    <transfer op="request">
  C:      <svcsub:transfer
  C:       xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  C:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  C:       svcsub-1.0.xsd">
  C:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  C:        <svcsub:period unit="y">1</svcsub:period>
  C:        <svcsub:authInfo type="pw" roid="JD1234-BIZ">
  C:          2fooBAR
  C:        </svcsub:authInfo>
  C:      </svcsub: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 <svcsub:trnData> element that
  identifies the subscription namespace and the location of the
  subscription schema.  The <svcsub:trnData> element contains the same
  child elements defined for a transfer query response.

  Example <transfer> response:

  S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  S:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  S:     xsi:schemaLocation="urn:iana: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:      <svcsub:trnData
  S:       xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  S:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  S:       svcsub-1.0.xsd">
  S:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  S:        <svcsub:trStatus>pending</svcsub:trStatus>
  S:        <svcsub:reID>ClientX</svcsub:reID>
  S:        <svcsub:reDate>2001-12-08T22:00:00.0Z</svcsub:reDate>
  S:        <svcsub:acID>ClientY</svcsub:acID>
  S:        <svcsub:acDate>2001-12-13T22:00:00.0Z</svcsub:acDate>



Ning Zhang                Expires June 30, 2002                [Page 22]

Internet-Draft          EPP Subscription Mapping           December 2001


  S:        <svcsub:exDate>2004-12-03T22:00:00.0Z</svcsub:exDate>
  S:      </svcsub:trnData>
  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 <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 a subscription object.  In addition
  to the standard EPP command elements, the <update> command MUST
  contain a <svcsub:update> element that identifies the subscription
  namespace and the location of the subscription schema. The
  <svcsub:update> element contains the following child elements:

  - A <svcsub:id> element that contains the identifier of the
  subscription object to be updated.

  - An OPTIONAL <svcsub:authInfo> element that contains authorization
  information associated with the subscription object or authorization
  information associated with the subscription object's registrant or
  associated contacts.  Registry policy on a specific service will
  specify the mechanism of the object association and decide if the
  authorization information is REQUIRED for the operation.

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

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

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

  At least one <svcsub:add>, <svcsub:rem>, or <svcsub:chg> element MUST
  be provided.  The <svcsub:add> and <svcsub:rem> elements contain the
  following child elements:

  - Zero or more <svcsub:param> elements that contain the service
  parameters to be associated with or removed from the subscription
  object. Each element MUST include a REQUIRED "name" attribute for



Ning Zhang                Expires June 30, 2002                [Page 23]

Internet-Draft          EPP Subscription Mapping           December 2001


  identifying the name of the service parameter.

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

  - Zero or more <svcsub: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.

  A <svcsub:chg> element contains the following child elements:

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

  - An OPTIONAL <svcsub:userid> element that can be used for
  authorization purpose in addition to the <svcsub:authInfo> element.
  The value of this element may be provisioned via other channels.
  Registry policy on a specific service will specify the mechanism of
  the userid provisioning and decide if the userid information is
  REQUIRED for the operation.

  - A <svcsub:authInfo> element that contains authorization information
  associated with the subscription object.

  Example <update> command:

  C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  C:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  C:     xsi:schemaLocation="urn:iana:xml:ns:epp-1.0
  C:     epp-1.0.xsd">
  C:  <command>
  C:    <update>
  C:      <svcsub:update
  C:       xmlns:svcsub="urn:iana:xml:ns:svcsub-1.0"
  C:       xsi:schemaLocation="urn:iana:xml:ns:svcsub-1.0
  C:       svcsub-1.0.xsd">
  C:        <svcsub:id>SVCSUB-SERVICE-1</svcsub:id>
  C:        <svcsub:add>
  C:          <svcsub:param name="hamming5">LEVEL</svcsub:param>
  C:          <svcsub:contact type="tech">mak21</svcsub:contact>



Ning Zhang                Expires June 30, 2002                [Page 24]

Internet-Draft          EPP Subscription Mapping           December 2001


  C:          <svcsub:status s="clientSuspended" lang="en">
  C:            Payment overdue.
  C:          </svcsub:status>
  C:        </svcsub:add>
  C:        <svcsub:rem>
  C:          <svcsub:param name="exact">NEULEVEL</svcsub:param>
  C:          <svcsub:contact type="tech">sh8013</svcsub:contact>
  C:          <svcsub:status s="clientUpdateProhibited"/>
  C:        </svcsub:rem>
  C:        <svcsub:chg>
  C:          <svcsub:registrant>sh8013</svcsub:registrant>
  C:          <svcsub:authInfo type="pw">2BARfoo</svcsub:authInfo>
  C:        </svcsub:chg>
  C:        <svcsub:userid>myUserId</svcsub:userid>
  C:        <svcsub:authInfo type="pw">2fooBAR</svcsub:authInfo>
  C:      </svcsub:update>
  C:    </update>
  C:    <clTRID>ABC-12345</clTRID>
  C:  </command>
  C:</epp>

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

  Example <update> response:

  S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
  S:<epp xmlns="urn:iana:xml:ns:epp-1.0"
  S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  S:     xsi:schemaLocation="urn:iana: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.







Ning Zhang                Expires June 30, 2002                [Page 25]

Internet-Draft          EPP Subscription Mapping           December 2001


4. Formal Syntax

  An EPP object mapping is specified in XML Schema notation.  The formal
  syntax presented here is a complete schema representation of the
  object mapping suitable for automated validation of EPP XML instances.
  The BEGIN and END tags are not part of the schema; they are used to
  note the beginning and ending of the schema for URI registration
  purposes.

  BEGIN

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

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

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

    <annotation>
      <documentation>
        Extensible Provisioning Protocol v1.0
        service subscription provisioning schema.
      </documentation>
    </annotation>

  <!--
  Types used within an EPP greeting.
  -->
    <element name="svc"/>

  <!--
  Child elements found in EPP commands.
  -->
    <element name="check" type="svcsub:mNameType"/>
    <element name="create" type="svcsub:createType"/>
    <element name="delete" type="svcsub:sNameType"/>
    <element name="info" type="svcsub:sNameType"/>
    <element name="renew" type="svcsub:renewType"/>



Ning Zhang                Expires June 30, 2002                [Page 26]

Internet-Draft          EPP Subscription Mapping           December 2001


    <element name="transfer" type="svcsub:transferType"/>
    <element name="update" type="svcsub:updateType"/>

  <!--
  Child elements of the <create> command.
  -->
    <complexType name="createType">
      <sequence>
        <element name="id" type="svcsub:subIDType"/>
        <element name="service" type="svcsub:svcIDType"/>
        <element name="param" type="svcsub:svcParamType"
         minOccurs="0" maxOccurs="unbounded"/>
        <element name="period" type="svcsub:periodType"
         minOccurs="0"/>
        <element name="registrant" type="eppcom:clIDType"
         minOccurs="0"/>
        <element name="contact" type="svcsub:contactType"
         minOccurs="0" maxOccurs="unbounded"/>
        <element name="authInfo" type="eppcom:authInfoType"
         minOccurs="0"/>
      </sequence>
    </complexType>

    <complexType name="periodType">
      <simpleContent>
        <extension base="svcsub:pLimitType">
          <attribute name="unit" type="svcsub:pUnitType"
           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>



Ning Zhang                Expires June 30, 2002                [Page 27]

Internet-Draft          EPP Subscription Mapping           December 2001


        <extension base="eppcom:clIDType">
          <attribute name="type" type="svcsub:contactAttrType"
           use="optional"/>
        </extension>
      </simpleContent>
    </complexType>

    <simpleType name="contactAttrType">
      <restriction base="token">
        <enumeration value="admin"/>
        <enumeration value="billing"/>
        <enumeration value="tech"/>
        <enumeration value="primary"/>
        <enumeration value="secondary"/>
        <enumeration value="bizlock"/>
        <!--minLength value="3"/>
        <maxLength value="64"/-->
      </restriction>
    </simpleType>

    <simpleType name="subIDType">
      <restriction base="token">
        <minLength value="3"/>
        <maxLength value="64"/>
      </restriction>
    </simpleType>

    <simpleType name="svcIDType">
      <restriction base="token">
        <minLength value="3"/>
        <maxLength value="64"/>
      </restriction>
    </simpleType>

    <complexType name="svcParamType">
      <simpleContent>
        <extension base="token">
          <attribute name="name" type="svcsub:svcParamAttrType"
           use="required"/>
        </extension>
      </simpleContent>
    </complexType>

    <simpleType name="svcParamAttrType">
      <restriction base="token">
      </restriction>
    </simpleType>




Ning Zhang                Expires June 30, 2002                [Page 28]

Internet-Draft          EPP Subscription Mapping           December 2001


    <simpleType name="userIDType">
      <restriction base="token">
        <minLength value="3"/>
        <maxLength value="64"/>
      </restriction>
    </simpleType>

  <!--
  Child element of commands that require a single name.
  -->
    <complexType name="sNameType">
      <sequence>
        <element name="id" type="svcsub:subIDType"/>
        <element name="userid" type="svcsub:userIDType"
         minOccurs="0"/>
        <element name="authInfo" type="eppcom:authInfoType"
         minOccurs="0"/>
      </sequence>
    </complexType>

  <!--
  Child element of commands that accept multiple names.
  -->
    <complexType name="mNameType">
      <sequence>
        <element name="id" type="svcsub:subIDType"
         maxOccurs="unbounded"/>
      </sequence>
    </complexType>

  <!--
  Child elements of the <renew> command.
  -->
    <complexType name="renewType">
      <sequence>
        <element name="id" type="svcsub:subIDType"/>
        <element name="curExpDate" type="date"/>
        <element name="period" type="svcsub:periodType"
         minOccurs="0"/>
        <element name="userid" type="svcsub:userIDType"
         minOccurs="0"/>
        <element name="authInfo" type="eppcom:authInfoType"
         minOccurs="0"/>
      </sequence>
    </complexType>

  <!--
  Child elements of the <transfer> command.



Ning Zhang                Expires June 30, 2002                [Page 29]

Internet-Draft          EPP Subscription Mapping           December 2001


  -->
    <complexType name="transferType">
      <sequence>
        <element name="id" type="svcsub:subIDType"/>
        <element name="period" type="svcsub:periodType"
         minOccurs="0"/>
        <element name="userid" type="svcsub:userIDType"
         minOccurs="0"/>
        <element name="authInfo" type="eppcom:authInfoType"
         minOccurs="0"/>
      </sequence>
    </complexType>

  <!--
  Child elements of the <update> command.
  -->
    <complexType name="updateType">
      <sequence>
        <element name="id" type="svcsub:subIDType"/>
        <choice minOccurs="1" maxOccurs="3">
          <element name="add" type="svcsub:addRemType"
           minOccurs="0"/>
          <element name="rem" type="svcsub:addRemType"
           minOccurs="0"/>
          <element name="chg" type="svcsub:chgType"
           minOccurs="0"/>
         </choice>
        <element name="userid" type="svcsub:userIDType"
         minOccurs="0"/>
        <element name="authInfo" type="eppcom:authInfoType"
         minOccurs="0"/>
      </sequence>
    </complexType>

  <!--
  Data elements that can be added or removed.
  -->
    <complexType name="addRemType">
      <choice minOccurs="1" maxOccurs="3">
        <element name="param" type="svcsub:svcParamType"
         minOccurs="0" maxOccurs="unbounded"/>
        <element name="contact" type="svcsub:contactType"
         minOccurs="0" maxOccurs="unbounded"/>
        <element name="status" type="svcsub:statusType"
         minOccurs="0" maxOccurs="14"/>
      </choice>
    </complexType>




Ning Zhang                Expires June 30, 2002                [Page 30]

Internet-Draft          EPP Subscription Mapping           December 2001


  <!--
  Data elements that can be changed.
  -->
    <complexType name="chgType">
      <sequence>
        <element name="registrant" type="eppcom:clIDType"
         minOccurs="0"/>
        <element name="authInfo" type="eppcom:authInfoType"
         minOccurs="0"/>
      </sequence>
    </complexType>

  <!--
  Child response elements.
  -->
    <element name="chkData" type="svcsub:chkDataType"/>
    <element name="creData" type="svcsub:creDataType"/>
    <element name="infData" type="svcsub:infDataType"/>
    <element name="trnData" type="svcsub:trnDataType"/>

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

    <complexType name="checkType">
      <simpleContent>
        <extension base = "eppcom:labelType">
          <attribute name="x" type="eppcom:checkType"
           use="required"/>
        </extension>
      </simpleContent>
    </complexType>

  <!--
  <create> and <renew> response elements.
  -->
    <complexType name="creDataType">
      <sequence>
        <element name="id" type="svcsub:subIDType"/>
        <element name="exDate" type="dateTime"
         minOccurs="0"/>
      </sequence>



Ning Zhang                Expires June 30, 2002                [Page 31]

Internet-Draft          EPP Subscription Mapping           December 2001


    </complexType>

  <!--
  <info> response elements.
  -->
    <complexType name="infDataType">
      <sequence>
        <element name="id" type="svcsub:subIDType"/>
        <element name="roid" type="eppcom:roidType"/>
        <element name="status" type="svcsub:statusType"
         maxOccurs="14"/>
        <element name="registrant" type="svcsub:contactType"
         minOccurs="0"/>
        <element name="contact" type="svcsub:contactType"
         minOccurs="0" maxOccurs="unbounded"/>
        <element name="service" type="svcsub:svcIDType"/>
        <element name="param" type="svcsub:svcParamType"
         minOccurs="0" maxOccurs="unbounded"/>
        <element name="clID" type="eppcom:clIDType"/>
        <element name="crID" type="eppcom:clIDType"/>
        <element name="crDate" type="dateTime"/>
        <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="eppcom: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">
      <simpleContent>
        <extension base="normalizedString">
          <attribute name="s" type="svcsub:statusValueType"
           use="required"/>
          <attribute name="lang" type="language"
           use="optional" default="en"/>
        </extension>
      </simpleContent>
    </complexType>



Ning Zhang                Expires June 30, 2002                [Page 32]

Internet-Draft          EPP Subscription Mapping           December 2001


    <simpleType name="statusValueType">
      <restriction base="token">
        <enumeration value="clientDeleteProhibited"/>
        <enumeration value="clientSuspended"/>
        <enumeration value="clientRenewProhibited"/>
        <enumeration value="clientTransferProhibited"/>
        <enumeration value="clientUpdateProhibited"/>
        <enumeration value="inactive"/>
        <enumeration value="ok"/>
        <enumeration value="pendingDelete"/>
        <enumeration value="pendingTransfer"/>
        <enumeration value="pendingVerification"/>
        <enumeration value="serverDeleteProhibited"/>
        <enumeration value="serverSuspended"/>
        <enumeration value="serverRenewProhibited"/>
        <enumeration value="serverTransferProhibited"/>
        <enumeration value="serverUpdateProhibited"/>
      </restriction>
    </simpleType>

  <!--
  <transfer> response elements.
  -->
    <complexType name="trnDataType">
      <sequence>
        <element name="id" type="svcsub:subIDType"/>
        <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









Ning Zhang                Expires June 30, 2002                [Page 33]

Internet-Draft          EPP Subscription Mapping           December 2001


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.  Compliant XML processors are
  REQUIRED to understand both UTF-8 and UTF-16.  Though XML includes
  provisions to identify other character set encodings through use of an
  "encoding" attribute in an <?xml?> declaration, EPP use with character
  sets other than UTF-8 is NOT RECOMMENDED.

  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.  Both extended and
  truncated date and time forms defined in [ISO8601] MAY be used, though
  a server SHOULD use one form or the other consistently.

  Humans, organizations, and other entities often need to represent
  social information in both a commonly understood character set and a
  locally optimized character set.  This specification provides features
  allowing representation of social information in both a subset of
  UTF-8 for broad readability and unrestricted UTF-8 for local
  optimization.




























Ning Zhang                Expires June 30, 2002                [Page 34]

Internet-Draft          EPP Subscription Mapping           December 2001


6. IANA Considerations

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

  Registration request for the contact namespace:

  URI: urn:iana:xml:ns:svcsub-1.0

  Registrant Contact: See the "Author's Address" section of this
  document.

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

  Registration request for the subscription XML schema:

  URI: urn:iana:xml:schema:svcsub-1.0

  Registrant Contact: See the "Author's Address" section of this
  document.

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




























Ning Zhang                Expires June 30, 2002                [Page 35]

Internet-Draft          EPP Subscription Mapping           December 2001


7. Security Considerations

  The object mapping described in this document does not provide any
  security services or introduce any additional considerations beyond
  those described by [EPP] and protocol layers used by EPP.

  In addition, subscription services provided by a registry SHOULD take
  precaution to prevent the scenario that a single subscription object
  could generate a large quantity of service notifications or
  deliveries.









































Ning Zhang                Expires June 30, 2002                [Page 36]

Internet-Draft          EPP Subscription Mapping           December 2001


8. Acknowledgements

  This document was written as an individual submission Internet-Draft.
















































Ning Zhang                Expires June 30, 2002                [Page 37]

Internet-Draft          EPP Subscription Mapping           December 2001


9. References

  [EPP] S. Hollenbeck: "Extensible Provisioning Protocol", Internet-
  Draft <draft-hollenbeck-epp-04.txt>, work in progress.  (To be
  replaced by the RFC name when this memo is published.)

  [EPP-C] S. Hollenbeck: "Extensible Provisioning Protocol Contact
  Mapping", Internet-Draft <draft-hollenbeck-epp-contact-02.txt>, work
  in progress.

  [IETF-XML] M. Mealling: "The IETF XML Registry", work in progress.

  [ISO8601] ISO 8601:1988 (E): "Data elements and interchange formats -
  Information interchange - Representation of dates and times", June
  1988.

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

  [RFC2279] F. Yergeau: "UTF-8, a transformation format of ISO 10646",
  RFC 2279, January 1998.

  [US-ASCII] Coded Character Set -- 7-bit American Standard Code for
  Information Interchange, ANSI X3.4-1986; also: ISO/IEC 646 (IRV).

  [XML] Editor T. Bray et al.: "Extensible Markup Language (XML) 1.0
  (Second Edition)", W3C Recommendation 6 October 2000.

  [XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1: Structures",
  W3C Recommendation 2 May 2001.

  [XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2:
  Datatypes", W3C Recommendation 2 May 2001.


















Ning Zhang                Expires June 30, 2002                [Page 38]

Internet-Draft          EPP Subscription Mapping           December 2001


10. Author's Address

  Ning Zhang
  NeuStar, Inc.
  1120 Vermont Ave, N.W.
  Suite 400
  Washington, DC 20005
  Phone: +1 202 533 2600
  Email: Ning.Zhang@NeuStar.BIZ










































Ning Zhang                Expires June 30, 2002                [Page 39]

Internet-Draft          EPP Subscription Mapping           December 2001


A. Full Copyright Statement

  Copyright (C) The Internet Society 2001. All Rights Reserved.

  This document and translations of it may be copied and furnished to
  others, and derivative works that comment on or otherwise explain it
  or assist in its implementation may be prepared, copied, published and
  distributed, in whole or in part, without restriction of any kind,
  provided that the above copyright notice and this paragraph are
  included on all such copies and derivative works. However, this
  document itself may not be modified in any way, such as by removing
  the copyright notice or references to the Internet Society or other
  Internet organizations, except as needed for the purpose of developing
  Internet standards in which case the procedures for copyrights defined
  in the Internet Standards process must be followed, or as required to
  translate it into languages other than English.

  The limited permissions granted above are perpetual and will not be
  revoked by the Internet Society or its successors or assigns.

  This document and the information contained herein is provided on an
  "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  TASK FORCE DISCLAIMS 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.

Acknowledgement

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




















Ning Zhang                Expires June 30, 2002                [Page 40]