Internet DRAFT - draft-hollenbeck-epp-sls
draft-hollenbeck-epp-sls
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]
