RFC3731 日本語訳
3731 Extensible Provisioning Protocol (EPP) Domain Name Mapping. S.Hollenbeck. March 2004. (Format: TXT=92527 bytes) (Obsoleted by RFC4931) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Hollenbeck Request for Comments: 3731 VeriSign, Inc. Category: Standards Track March 2004
Network Working Group S. Hollenbeck Request for Comments: 3731 VeriSign, Inc. Category: Standards Track March 2004
Extensible Provisioning Protocol (EPP) Domain Name Mapping
Extensible Provisioning Protocol (EPP) Domain Name Mapping
Status of this Memo
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Abstract
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.
Table of Contents
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Relationship of Domain Objects and Host Objects . . . . 2
1.2. Conventions Used In This Document . . . . . . . . . . . 4
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Domain and Host Names . . . . . . . . . . . . . . . . . 4
2.2. Contact and Client Identifiers. . . . . . . . . . . . . 5
2.3. Status Values . . . . . . . . . . . . . . . . . . . . . 5
2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . 7
2.5. Validity Periods. . . . . . . . . . . . . . . . . . . . 7
2.6. Authorization Information . . . . . . . . . . . . . . . 7
2.7. Other DNS Resource Record Attributes. . . . . . . . . . 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. . . . . . . . . . . . . . . 10
3.1.3. EPP <transfer> Query Command. . . . . . . . . . 16
3.2. EPP Transform Commands. . . . . . . . . . . . . . . . . 18
3.2.1. EPP <create> Command. . . . . . . . . . . . . . 19
3.2.2. EPP <delete> Command. . . . . . . . . . . . . . 21
3.2.3. EPP <renew> Command . . . . . . . . . . . . . . 23
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Relationship of Domain Objects and Host Objects . . . . 2 1.2. Conventions Used In This Document . . . . . . . . . . . 4 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Domain and Host Names . . . . . . . . . . . . . . . . . 4 2.2. Contact and Client Identifiers. . . . . . . . . . . . . 5 2.3. Status Values . . . . . . . . . . . . . . . . . . . . . 5 2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . 7 2.5. Validity Periods. . . . . . . . . . . . . . . . . . . . 7 2.6. Authorization Information . . . . . . . . . . . . . . . 7 2.7. Other DNS Resource Record Attributes. . . . . . . . . . 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. . . . . . . . . . . . . . . 10 3.1.3. EPP <transfer> Query Command. . . . . . . . . . 16 3.2. EPP Transform Commands. . . . . . . . . . . . . . . . . 18 3.2.1. EPP <create> Command. . . . . . . . . . . . . . 19 3.2.2. EPP <delete> Command. . . . . . . . . . . . . . 21 3.2.3. EPP <renew> Command . . . . . . . . . . . . . . 23
Hollenbeck Standards Track [Page 1] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 1] RFC 3731 EPP Domain Name Mapping March 2004
3.2.4. EPP <transfer> Command. . . . . . . . . . . . . 24
3.2.5. EPP <update> Command. . . . . . . . . . . . . . 27
3.2.6. Offline Review of Requested Actions . . . . . . 29
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 32
5. Internationalization Considerations . . . . . . . . . . . . . 41
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
7. Security Considerations . . . . . . . . . . . . . . . . . . . 42
8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 42
9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 43
9.1. Normative References. . . . . . . . . . . . . . . . . . 43
9.2. Informative References. . . . . . . . . . . . . . . . . 43
10. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 44
11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 45
3.2.4. EPP <transfer> Command. . . . . . . . . . . . . 24 3.2.5. EPP <update> Command. . . . . . . . . . . . . . 27 3.2.6. Offline Review of Requested Actions . . . . . . 29 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 32 5. Internationalization Considerations . . . . . . . . . . . . . 41 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 7. Security Considerations . . . . . . . . . . . . . . . . . . . 42 8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 42 9. References. . . . . . . . . . . . . . . . . . . . . . . . . . 43 9.1. Normative References. . . . . . . . . . . . . . . . . . 43 9.2. Informative References. . . . . . . . . . . . . . . . . 43 10. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 44 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 45
1. Introduction
1. Introduction
This document describes an Internet domain name 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].
This document describes an Internet domain name 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].
[RFC3730] 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.
[RFC3730] 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.
XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation.
1.1. Relationship of Domain Objects and Host Objects
1.1. Relationship of Domain Objects and Host Objects
The EPP mapping for host objects is described in [RFC3732]. This document assumes that domain name objects have a superordinate relationship to subordinate host name objects. For example, domain name "example.com" has a superordinate relationship to host name "ns1.example.com". EPP actions (such as object transfers) that do not preserve this relationship MUST be explicitly disallowed.
The EPP mapping for host objects is described in [RFC3732]. This document assumes that domain name objects have a superordinate relationship to subordinate host name objects. For example, domain name "example.com" has a superordinate relationship to host name "ns1.example.com". EPP actions (such as object transfers) that do not preserve this relationship MUST be explicitly disallowed.
A host name object can be created in a repository for which no superordinate domain name object exists. For example, host name "ns1.example.com" can be created in the ".example" repository so that DNS domains in ".example" can be delegated to the host. Such hosts are described as "external" hosts in this specification since the name of the host does not belong to the name space of the repository in which the host is being used for delegation purposes.
A host name object can be created in a repository for which no superordinate domain name object exists. For example, host name "ns1.example.com" can be created in the ".example" repository so that DNS domains in ".example" can be delegated to the host. Such hosts are described as "external" hosts in this specification since the name of the host does not belong to the name space of the repository in which the host is being used for delegation purposes.
Hollenbeck Standards Track [Page 2] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 2] RFC 3731 EPP Domain Name Mapping March 2004
Whether a host is external or internal relates to the repository in which the host is being used for delegation purposes. Whether an internal host is subordinate or not relates to a domain within the repository. For example, host ns1.example1.com is a subordinate host of domain example1.com, but it is a not a subordinate host of domain example2.com. ns1.example1.com can be used as a name server for example2.com. In this case, ns1.example1.com MUST be treated as an internal host, subject to the rules governing operations on subordinate hosts within the same repository.
Whether a host is external or internal relates to the repository in which the host is being used for delegation purposes. Whether an internal host is subordinate or not relates to a domain within the repository. For example, host ns1.example1.com is a subordinate host of domain example1.com, but it is a not a subordinate host of domain example2.com. ns1.example1.com can be used as a name server for example2.com. In this case, ns1.example1.com MUST be treated as an internal host, subject to the rules governing operations on subordinate hosts within the same repository.
Name server hosts for domain delegation can be specified as either references to existing host objects or as domain attributes that describe a host machine. A server operator MUST use one name server specification form consistently. A server operator that announces support for host objects in an EPP greeting MUST NOT allow domain attributes to describe a name server host machine. A server operator that does not announce support for host objects MUST allow domain attributes to describe a name server host machine. When domain attributes are used to describe a name server host machine, IP addresses SHOULD be required only as needed to generate DNS glue records.
Name server hosts for domain delegation can be specified as either references to existing host objects or as domain attributes that describe a host machine. A server operator MUST use one name server specification form consistently. A server operator that announces support for host objects in an EPP greeting MUST NOT allow domain attributes to describe a name server host machine. A server operator that does not announce support for host objects MUST allow domain attributes to describe a name server host machine. When domain attributes are used to describe a name server host machine, IP addresses SHOULD be required only as needed to generate DNS glue records.
Name servers are specified within a <domain:ns> element. This element MUST contain one or more <domain:hostObj> elements or one or more <domain:hostAttr> elements. A <domain:hostObj> element contains the fully qualified name of a known name server host object. A <domain:hostAttr> element contains the following child elements:
Name servers are specified within a <domain:ns> element. This element MUST contain one or more <domain:hostObj> elements or one or more <domain:hostAttr> elements. A <domain:hostObj> element contains the fully qualified name of a known name server host object. A <domain:hostAttr> element contains the following child elements:
- A <domain:hostName> element that contains the fully qualified name
of a host.
- A <domain:hostName> element that contains the fully qualified name of a host.
- Zero or more OPTIONAL <domain:hostAddr> elements that contain the
IP addresses to be associated with the host. Each element MAY
contain an "ip" attribute to identify the IP address format.
Attribute value "v4" is used to note IPv4 address format.
Attribute value "v6" is used to note IPv6 address format. If the
"ip" attribute is not specified, "v4" is the default attribute
value. IP address syntax requirements are described in Section
2.5 of the EPP host mapping [RFC3732].
- Zero or more OPTIONAL <domain:hostAddr> elements that contain the IP addresses to be associated with the host. Each element MAY contain an "ip" attribute to identify the IP address format. Attribute value "v4" is used to note IPv4 address format. Attribute value "v6" is used to note IPv6 address format. If the "ip" attribute is not specified, "v4" is the default attribute value. IP address syntax requirements are described in Section 2.5 of the EPP host mapping [RFC3732].
Example host object name server elements for domain example.com:
Example host object name server elements for domain example.com:
<domain:ns>
<domain:hostObj>ns1.example.com</domain:hostObj>
<domain:hostObj>ns1.example.net</domain:hostObj>
</domain:ns>
<domain:ns> <domain:hostObj>ns1.example.com</domain:hostObj> <domain:hostObj>ns1.example.net</domain:hostObj> </domain:ns>
Hollenbeck Standards Track [Page 3] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 3] RFC 3731 EPP Domain Name Mapping March 2004
Example host attribute name server elements for domain example.com:
Example host attribute name server elements for domain example.com:
<domain:ns>
<domain:hostAttr>
<domain:hostName>ns1.example.com</domain:hostName>
<domain:hostAddr
ip="v4">192.0.2.2</domain:hostAddr>
<domain:hostAddr
ip="v6">1080:0:0:0:8:800:200C:417A</domain:hostAddr>
</domain:hostAttr>
<domain:hostAttr>
<domain:hostName>ns1.example.net</domain:hostName>
</domain:hostAttr>
</domain:ns>
<domain:ns> <domain:hostAttr> <domain:hostName>ns1.example.com</domain:hostName> <domain:hostAddr ip="v4">192.0.2.2</domain:hostAddr> <domain:hostAddr ip="v6">1080:0:0:0:8:800:200C:417A</domain:hostAddr> </domain:hostAttr> <domain:hostAttr> <domain:hostName>ns1.example.net</domain:hostName> </domain:hostAttr> </domain:ns>
1.2. Conventions Used In This Document
1.2. 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].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples is provided only to illustrate element relationships and is not a REQUIRED feature of this protocol.
In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples is provided only to illustrate element relationships and is not a REQUIRED feature of this protocol.
2. Object Attributes
2. Object Attributes
An EPP domain 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.
An EPP domain object has attributes and associated values that can be viewed and modified by the sponsoring client or the server. This section describes each attribute type in detail. The formal syntax for the attribute values described here can be found in the "Formal Syntax" section of this document and in the appropriate normative references.
2.1. Domain and Host Names
2.1. Domain and Host Names
The syntax for domain and host names described in this document MUST conform to [RFC952] as updated by [RFC1123]. At the time of this writing, RFC 3490 [RFC3490] describes a standard to use certain ASCII name labels to represent non-ASCII name labels. These conformance requirements might change as a result of progressing work in developing standards for internationalized domain names. A server MAY restrict allowable domain names to a particular top level domain, second level domain, or other domain for which the server is authoritative. The trailing dot required when these names are stored in a DNS zone is implicit and MUST NOT be provided when exchanging host and domain names.
The syntax for domain and host names described in this document MUST conform to [RFC952] as updated by [RFC1123]. At the time of this writing, RFC 3490 [RFC3490] describes a standard to use certain ASCII name labels to represent non-ASCII name labels. These conformance requirements might change as a result of progressing work in developing standards for internationalized domain names. A server MAY restrict allowable domain names to a particular top level domain, second level domain, or other domain for which the server is authoritative. The trailing dot required when these names are stored in a DNS zone is implicit and MUST NOT be provided when exchanging host and domain names.
Hollenbeck Standards Track [Page 4] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 4] RFC 3731 EPP Domain Name Mapping March 2004
2.2. Contact and Client Identifiers
2.2. 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. Contact identifiers use the "clIDType" client identifier syntax described in [RFC3730].
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. Contact identifiers use the "clIDType" client identifier syntax described in [RFC3730].
2.3. Status Values
2.3. Status Values
A domain object MUST always have at least one associated status value. Status values can be set only by the client that sponsors a domain object and by the server on which the object resides. A client can change the status of a domain 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 domain object MUST always have at least one associated status value. Status values can be set only by the client that sponsors a domain object and by the server on which the object resides. A client can change the status of a domain 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.
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 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:
Status Value Descriptions:
- clientDeleteProhibited, serverDeleteProhibited
- clientDeleteProhibited, serverDeleteProhibited
Requests to delete the object MUST be rejected.
Requests to delete the object MUST be rejected.
- clientHold, serverHold
- clientHold, serverHold
DNS delegation information MUST NOT be published for the object.
DNS delegation information MUST NOT be published for the object.
- clientRenewProhibited, serverRenewProhibited
- clientRenewProhibited, serverRenewProhibited
Requests to renew the object MUST be rejected.
Requests to renew the object MUST be rejected.
- clientTransferProhibited, serverTransferProhibited
- clientTransferProhibited, serverTransferProhibited
Requests to transfer the object MUST be rejected.
Requests to transfer the object MUST be rejected.
Hollenbeck Standards Track [Page 5] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 5] RFC 3731 EPP Domain Name Mapping March 2004
- clientUpdateProhibited, serverUpdateProhibited
- clientUpdateProhibited, serverUpdateProhibited
Requests to update the object (other than to remove this status) MUST be rejected.
Requests to update the object (other than to remove this status) MUST be rejected.
- inactive
- inactive
Delegation information has not been associated with the object.
Delegation information has not been associated with the object.
- ok
- 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.
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
- 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.
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.
With one exception, transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status is set. The only exception is that a <transfer> command to approve, reject, or cancel a transfer MAY be processed while an object is in "pendingTransfer" status.
With one exception, transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingRenew, pendingTransfer, or pendingUpdate status is set. The only exception is that a <transfer> command to approve, reject, or cancel a transfer MAY be processed while an object is in "pendingTransfer" status.
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.
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.
"ok" status MUST NOT be combined with any other status.
"pendingDelete" status MUST NOT be combined with either "clientDeleteProhibited" or "serverDeleteProhibited" 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.
"pendingRenew" status MUST NOT be combined with either "clientRenewProhibited" or "serverRenewProhibited" status.
"pendingTransfer" status MUST NOT be combined with either "clientTransferProhibited" or "serverTransferProhibited" status.
"pendingTransfer" status MUST NOT be combined with either "clientTransferProhibited" or "serverTransferProhibited" status.
Hollenbeck Standards Track [Page 6] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 6] RFC 3731 EPP Domain Name Mapping March 2004
"pendingUpdate" status MUST NOT be combined with either "clientUpdateProhibited" or "serverUpdateProhibited" 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.
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.
Other status combinations not expressly prohibited MAY be used.
2.4. Dates and Times
2.4. 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 [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.
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 [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.
2.5. Validity Periods
2.5. Validity Periods
A domain name object MAY have a specified validity period. If server policy supports domain object validity periods, the validity period is defined when a domain 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 domain object's validity period.
A domain name object MAY have a specified validity period. If server policy supports domain object validity periods, the validity period is defined when a domain 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 domain 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.
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.
2.6. Authorization Information
2.6. Authorization Information
Authorization information is associated with domain objects to facilitate transfer operations. Authorization information is assigned when a domain object is created, and it might be updated in the future. This specification describes password-based authorization information, though other mechanisms are possible.
Authorization information is associated with domain objects to facilitate transfer operations. Authorization information is assigned when a domain object is created, and it might be updated in the future. This specification describes password-based authorization information, though other mechanisms are possible.
2.7. Other DNS Resource Record Attributes
2.7. Other DNS Resource Record Attributes
While the DNS allows many resource record types to be associated with a domain, this mapping only explicitly specifies elements that describe resource records used for domain delegation and resolution. Facilities to provision other domain-related resource record types can be developed by extending this mapping.
While the DNS allows many resource record types to be associated with a domain, this mapping only explicitly specifies elements that describe resource records used for domain delegation and resolution. Facilities to provision other domain-related resource record types can be developed by extending this mapping.
Hollenbeck Standards Track [Page 7] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 7] RFC 3731 EPP Domain Name Mapping March 2004
The provisioning method described in this mapping separates discrete data elements by data type. This method of data definition allows XML Schema processors to perform basic syntax validation tasks, reducing ambiguity and the amount of parsing and syntax-checking work required of protocol processors. Provisioning and extension methods that aggregate data into opaque strings are possible, but such methods SHOULD NOT be used because they impose additional parsing, interpretation, and validation requirements on protocol processors.
The provisioning method described in this mapping separates discrete data elements by data type. This method of data definition allows XML Schema processors to perform basic syntax validation tasks, reducing ambiguity and the amount of parsing and syntax-checking work required of protocol processors. Provisioning and extension methods that aggregate data into opaque strings are possible, but such methods SHOULD NOT be used because they impose additional parsing, interpretation, and validation requirements on protocol processors.
3. EPP Command Mapping
3. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found in [RFC3730]. The command mappings described here are specifically for use in provisioning and managing Internet domain names via EPP.
A detailed description of the EPP syntax and semantics can be found in [RFC3730]. The command mappings described here are specifically for use in provisioning and managing Internet domain names via EPP.
3.1. EPP Query Commands
3.1. EPP Query Commands
EPP provides three commands to retrieve domain information: <check> to determine if a domain object can be provisioned within a repository, <info> to retrieve detailed information associated with a domain object, and <transfer> to retrieve domain object transfer status information.
EPP provides three commands to retrieve domain information: <check> to determine if a domain object can be provisioned within a repository, <info> to retrieve detailed information associated with a domain object, and <transfer> to retrieve domain object transfer status information.
3.1.1. EPP <check> Command
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.
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 a <domain:check> element that identifies the domain namespace and the location of the domain schema. The <domain:check> element contains the following child elements:
In addition to the standard EPP command elements, the <check> command MUST contain a <domain:check> element that identifies the domain namespace and the location of the domain schema. The <domain:check> element contains the following child elements:
- One or more <domain:name> elements that contain the fully
qualified names of the domain objects to be queried.
- One or more <domain:name> elements that contain the fully qualified names of the domain objects to be queried.
Hollenbeck Standards Track [Page 8] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 8] RFC 3731 EPP Domain Name Mapping March 2004
Example <check> command:
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: <domain:check C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> C: <domain:name>example.com</domain:name> C: <domain:name>example.net</domain:name> C: <domain:name>example.org</domain:name> C: </domain:check> C: </check> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
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: <domain:check C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> C: <domain:name>example.com</domain:name> C: <domain:name>example.net</domain:name> C: <domain:name>example.org</domain:name> C: </domain:check> C: </check> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
When a <check> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:chkData> element that identifies the domain namespace and the location of the domain schema. The <domain:chkData> element contains one or more <domain:cd> elements that contain the following child elements:
When a <check> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:chkData> element that identifies the domain namespace and the location of the domain schema. The <domain:chkData> element contains one or more <domain:cd> elements that contain the following child elements:
- A <domain:name> element that contains the fully qualified name of
the queried domain object. 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.
- A <domain:name> element that contains the fully qualified name of the queried domain object. 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.
- An OPTIONAL <domain:reason> element that MAY be provided when an
object can not be provisioned. If present, this element contains
server-specific text to help explain why the object can not be
provisioned. This text MUST be represented in the response
language previously negotiated with the client; an OPTIONAL "lang"
attribute MAY be present to identify the language if the
negotiated value is something other than the default value of "en"
(English).
- An OPTIONAL <domain:reason> element that MAY be provided when an object can not be provisioned. If present, this element contains server-specific text to help explain why the object can not be provisioned. This text MUST be represented in the response language previously negotiated with the client; an OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en" (English).
Hollenbeck Standards Track [Page 9] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 9] RFC 3731 EPP Domain Name Mapping March 2004
Example <check> response:
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: <domain:chkData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:cd> S: <domain:name avail="1">example.com</domain:name> S: </domain:cd> S: <domain:cd> S: <domain:name avail="0">example.net</domain:name> S: <domain:reason>In use</domain:reason> S: </domain:cd> S: <domain:cd> S: <domain:name avail="1">example.org</domain:name> S: </domain:cd> S: </domain:chkData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
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: <domain:chkData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:cd> S: <domain:name avail="1">example.com</domain:name> S: </domain:cd> S: <domain:cd> S: <domain:name avail="0">example.net</domain:name> S: <domain:reason>In use</domain:reason> S: </domain:cd> S: <domain:cd> S: <domain:name avail="1">example.org</domain:name> S: </domain:cd> S: </domain:chkData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
An EPP error response MUST be returned if a <check> command can not be processed for any reason.
An EPP error response MUST be returned if a <check> command can not be processed for any reason.
3.1.2. EPP <info> Command
3.1.2. EPP <info> Command
The EPP <info> command is used to retrieve information associated with a domain 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
The EPP <info> command is used to retrieve information associated with a domain 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
Hollenbeck Standards Track [Page 10] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 10] RFC 3731 EPP Domain Name Mapping March 2004
returned. If the querying client is not the sponsoring client, and the client does not provide valid authorization information, server policy determines which OPTIONAL elements are returned.
returned. If the querying client is 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 a <domain:info> element that identifies the domain namespace and the location of the domain schema. The <domain:info> element contains the following child elements:
標準のEPP指揮機関に加えて、<インフォメーション>コマンドは<ドメインを含まなければなりません: ドメイン名前空間とドメイン図式の位置を特定するインフォメーション>要素。 <ドメイン: インフォメーション>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object to be queried. An OPTIONAL "hosts" attribute is
available to control return of information describing hosts
related to the domain object. A value of "all" (the default,
which MAY be absent) returns information describing both
subordinate and delegated hosts. A value of "del" returns
information describing only delegated hosts. A value of "sub"
returns information describing only subordinate hosts. A value of
"none" returns no information describing delegated or subordinate
hosts.
- <ドメイン: 質問されるべきドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。 ホストについて説明する情報の属性が利用可能であるOPTIONAL「ホスト」コントロール復帰はドメインオブジェクトに関連しました。 「すべて」(欠けるかもしれないデフォルト)の値は下位のものと同様に代表として派遣されたホストについて説明する情報を返します。 "del"の値は説明が代表として派遣しただけである情報にホストを返します。 「潜水艦」の値は下位のホストだけについて説明する情報を返します。 「なにも」の値は代表として派遣されたか下位のホストについて説明する情報を全く返しません。
- An OPTIONAL <domain:authInfo> element that contains authorization
information associated with the domain object or authorization
information associated with the domain object's registrant or
associated contacts. An OPTIONAL "roid" attribute MUST be used to
identify the registrant or contact object if and only if the given
authInfo is associated with a registrant or contact object, and
not the domain object itself. 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.
- OPTIONAL<ドメイン: ドメインオブジェクトに関連している承認情報か承認情報を含むauthInfo>要素がドメインオブジェクトの記入者か関連接触と交際しました。 そして、記入者か接触オブジェクトを特定するのにOPTIONAL"roid"属性を使用しなければならない、与えられたauthInfoがドメインではなく、記入者か接触オブジェクトに関連している場合にだけ、それ自体で反対してください。 この要素が提供されないか、または承認情報が無効であるなら、サーバ方針は、コマンドが拒絶されるかどうか、または応答情報がクライアントに返されるかどうか決定します。
Hollenbeck Standards Track [Page 11] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[11ページ]RFC3731EPPドメイン名
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: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> C: <domain:name hosts="all">example.com</domain:name> C: </domain:info> C: </info> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <インフォメーション>C: <ドメイン: インフォメーションC: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチC:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン-1.0C:、」 ドメイン-1.0.xsd、「>C:」 <ドメイン: 名前ホストが等しい、「すべて、「>example.com</ドメイン: >をCと命名してください」 </ドメイン: インフォメーション>C: </インフォメーション>C: <clTRID>ABC-12345</clTRID>C: </コマンド>C: </epp>。
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: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> C: <domain:name hosts="all">example.com</domain:name> C: <domain:authInfo> C: <domain:pw>2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:info> C: </info> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <インフォメーション>C: <ドメイン: インフォメーションC: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチC:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン-1.0C:、」 ドメイン-1.0.xsd、「>C:」 <ドメイン: 名前ホストが等しい、「すべて、「>example.com</ドメイン: >をCと命名してください」 <ドメイン: authInfo>C: <ドメイン: pw>2fooBAR</ドメイン: pw>C: </ドメイン: authInfo>C: </ドメイン: インフォメーション>C: </インフォメーション>C: <clTRID>ABC-12345</clTRID>C: </コマンド>C: </epp>。
Hollenbeck Standards Track [Page 12] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[12ページ]RFC3731EPPドメイン名
When an <info> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:infData> element that identifies the domain namespace and the location of the domain schema. Elements that are not OPTIONAL MUST be returned; OPTIONAL elements are returned based on client authorization and server policy. The <domain:infData> element contains the following child elements:
首尾よく<インフォメーション>コマンドを処理してあるとき、EPP<resData>要素は子供<ドメインを含まなければなりません: ドメイン名前空間とドメイン図式の位置を特定するinfData>要素。 それはOPTIONAL MUSTではありません。要素、返してください。 クライアント承認とサーバ方針に基づいてOPTIONAL要素を返します。 <ドメイン: infData>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object.
- <ドメイン: ドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- A <domain:roid> element that contains the Repository Object
IDentifier assigned to the domain object when the object was
created.
- <ドメイン: オブジェクトが作成されたときドメインオブジェクトに割り当てられたRepository Object IDentifierを含むroid>要素。
- Zero or more OPTIONAL <domain:status> elements that contain the
current status descriptors associated with the domain.
- より多くのOPTIONAL<ドメイン: ゼロかドメインに関連している現在の状態記述子を含む状態>要素。
- If supported by the server, one OPTIONAL <domain:registrant>
element and one or more OPTIONAL <domain:contact> elements that
contain identifiers for the human or organizational social
information objects associated with the domain object.
- 1つのOPTIONAL<ドメイン: 記入者>要素と1つ以上のOPTIONAL<ドメイン: サーバによってサポートされるなら、ドメインオブジェクトに関連している人間の、または、組織的な社会情報オブジェクトのための識別子を含む>要素に連絡してください。
- An OPTIONAL <domain:ns> element that contains the fully qualified
names of the delegated host objects or host attributes (name
servers) associated with the domain object. See section 1.1 for a
description of the elements used to specify host objects or host
attributes.
- OPTIONAL<ドメイン: ドメインオブジェクトに関連づけられて、代表として派遣されたホストオブジェクトの完全に修飾された名前を含む>要素かホストが結果と考える(ネームサーバ)ナノ秒。 要素の記述のためのセクション1.1が以前はよくホストオブジェクトかホスト属性を指定していたのを確実にしてください。
- Zero or more OPTIONAL <domain:host> elements that contain the
fully qualified names of the subordinate host objects that exist
under this superordinate domain object.
- より多くのOPTIONAL<ドメイン: ゼロか存在する下位のホストオブジェクトの完全に修飾された名前を含むホスト>要素がこの「スーパー-縦座標」ドメインの下で反対します。
- A <domain:clID> element that contains the identifier of the
sponsoring client.
- <ドメイン: 後援しているクライアントの識別子を含むclID>要素。
- An OPTIONAL <domain:crID> element that contains the identifier of
the client that created the domain object.
- OPTIONAL<ドメイン: ドメインオブジェクトを作成したクライアントの識別子を含むcrID>要素。
- An OPTIONAL <domain:crDate> element that contains the date and
time of domain object creation.
- OPTIONAL<ドメイン: ドメインオブジェクト作成の日時を含むcrDate>要素。
- An OPTIONAL <domain:exDate> element that contains the date and
time identifying the end of the domain object's registration
period.
- OPTIONAL<ドメイン: ドメインオブジェクトの登録の期間の終わりを特定する日時を含むexDate>要素。
Hollenbeck Standards Track [Page 13] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[13ページ]RFC3731EPPドメイン名
- An OPTIONAL <domain:upID> element that contains the identifier of
the client that last updated the domain object. This element MUST
NOT be present if the domain has never been modified.
- OPTIONAL<ドメイン: ドメインオブジェクトをアップデートしたクライアントの識別子を含むupID>要素。 ドメインが一度も変更されたことがないなら、この要素は存在しているはずがありません。
- An OPTIONAL <domain:upDate> element that contains the date and
time of the most recent domain object modification. This element
MUST NOT be present if the domain object has never been modified.
- OPTIONAL<ドメイン: 最新のドメインオブジェクト修飾の日時を含むupDate>要素。 ドメインオブジェクトが一度も変更されたことがないなら、この要素は存在しているはずがありません。
- An OPTIONAL <domain:trDate> elements that contains the date and
time of the most recent successful domain object transfer. This
element MUST NOT be provided if the domain object has never been
transferred.
- OPTIONAL<ドメイン: それが最新のうまくいっているドメインオブジェクト転送の日時に含むtrDate>要素。 ドメインオブジェクトを一度も移したことがないなら、この要素を提供してはいけません。
- An OPTIONAL <domain:authInfo> element that contains authorization
information associated with the domain 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.
- OPTIONAL<ドメイン: 承認情報を含むauthInfo>要素がドメインオブジェクトと交際しました。 質問しているクライアントが現在の後援しているクライアントである、またはクライアントが有効な承認情報にコマンドを供給したなら、この要素を返すだけでよいです。
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"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:name>example.com</domain:name> S: <domain:roid>EXAMPLE1-REP</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>jd1234</domain:registrant> S: <domain:contact type="admin">sh8013</domain:contact> S: <domain:contact type="tech">sh8013</domain:contact> S: <domain:ns> S: <domain:hostObj>ns1.example.com</domain:hostObj> S: <domain:hostObj>ns1.example.net</domain:hostObj> S: </domain:ns> S: <domain:host>ns1.example.com</domain:host> S: <domain:host>ns2.example.com</domain:host> S: <domain:clID>ClientX</domain:clID>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ドメイン: infData S: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチS:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン1.0秒間:、」 ドメイン-1.0.xsd、「>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: roid>EXAMPLE1-レップ</ドメイン: roid>S: <ドメイン: 状態sは「OK」/>Sと等しいです: <ドメイン: 記入者>jd1234</ドメイン: 記入者>S: <ドメイン: タイプ=に連絡してください、「アドミン、「>sh8013</ドメイン: >Sに連絡してください」 <ドメイン: タイプ=に連絡してください、「科学技術、「>sh8013</ドメイン: >Sに連絡してください」 <ドメイン: ナノ秒>S: <ドメイン: hostObj>ns1.example.com</ドメイン: hostObj>S: <ドメイン: hostObj>ns1.example.net</ドメイン: hostObj>S: </ドメイン: ナノ秒>S: <ドメイン: ホスト>ns1.example.com</ドメイン: >Sを接待してください: <ドメイン: ホスト>ns2.example.com</ドメイン: >Sを接待してください: <ドメイン: clID>ClientX</ドメイン: clID>。
Hollenbeck Standards Track [Page 14] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[14ページ]RFC3731EPPドメイン名
S: <domain:crID>ClientY</domain:crID> S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> S: <domain:upID>ClientX</domain:upID> S: <domain:upDate>1999-12-03T09:00:00.0Z</domain:upDate> S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> S: <domain:trDate>2000-04-08T09:00:00.0Z</domain:trDate> S: <domain:authInfo> S: <domain:pw>2fooBAR</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: <ドメイン: crID>ClientY</ドメイン: crID>S: <ドメイン: crDate>1999-04-03T22:00:00.0Z</ドメイン: crDate>S: <ドメイン: upID>ClientX</ドメイン: upID>S: <ドメイン: >1999-12-03T09:00:00.0Z</ドメインをアップデートしてください: >Sをアップデートしてください: <ドメイン: exDate>2005-04-03T22:00:00.0Z</ドメイン: exDate>S: <ドメイン: trDate>2000-04-08T09:00:00.0Z</ドメイン: trDate>S: <ドメイン: authInfo>S: <ドメイン: pw>2fooBAR</ドメイン: pw>S: </ドメイン: authInfo>S: </ドメイン: infData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54322-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
A server with a different information return policy MAY provide less information in a response.
異なった情報返品条件があるサーバは、より少ない情報を応答に提供するかもしれません。
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: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:name>example.com</domain:name> S: <domain:roid>EXAMPLE1-REP</domain:roid> S: <domain:clID>ClientX</domain:clID> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ドメイン: infData S: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチS:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン1.0秒間:、」 ドメイン-1.0.xsd、「>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: roid>EXAMPLE1-レップ</ドメイン: roid>S: <ドメイン: clID>ClientX</ドメイン: clID>S: </ドメイン: infData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54322-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
Hollenbeck Standards Track [Page 15] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[15ページ]RFC3731EPPドメイン名
An EPP error response MUST be returned if an <info> command can not be processed for any reason.
どんな理由でも<インフォメーション>コマンドを処理できないなら、EPP誤り応答を返さなければなりません。
3.1.3. EPP <transfer> Query Command
3.1.3. EPP<転送>質問命令
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 <domain:transfer> element that identifies the domain namespace and the location of the domain schema. The <domain:transfer> element contains the following child elements:
EPP<転送>命令はクライアントが未定の、そして、完成した転送要求のリアルタイムの状態を決定できる質問操作を提供します。 標準のEPP指揮機関に加えて、<転送>命令は値の「質問」、および<ドメインがある「オプアート」属性を含まなければなりません: ドメイン名前空間とドメイン図式の位置を特定する>要素を移してください。 <ドメイン: 転送>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object to be queried.
- <ドメイン: 質問されるべきドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- An OPTIONAL <domain:authInfo> element that contains authorization
information associated with the domain object or authorization
information associated with the domain object's registrant or
associated contacts. An OPTIONAL "roid" attribute MUST be used to
identify the registrant or contact object if and only if the given
authInfo is associated with a registrant or contact object, and
not the domain object itself. 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.
- OPTIONAL<ドメイン: ドメインオブジェクトに関連している承認情報か承認情報を含むauthInfo>要素がドメインオブジェクトの記入者か関連接触と交際しました。 そして、記入者か接触オブジェクトを特定するのにOPTIONAL"roid"属性を使用しなければならない、与えられたauthInfoがドメインではなく、記入者か接触オブジェクトに関連している場合にだけ、それ自体で反対してください。 この要素が提供されないか、または承認情報が無効であるなら、サーバ方針は、コマンドが拒絶されるかどうか、または応答情報がクライアントに返されるかどうか決定します。
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: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> C: <domain:name>example.com</domain:name> C: <domain:authInfo> C: <domain:pw roid="JD1234-REP">2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <clTRID>ABC-12345</clTRID> C: </command>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <転送オプアート=、「質問、「>C:」 <ドメイン: 転送C: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチC:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン-1.0C:、」 ドメイン-1.0.xsd、「>C:」 <ドメイン: 名前>example.com</ドメイン: >をCと命名してください: <ドメイン: authInfo>C: <ドメイン: pw roidが等しい、「JD1234-レップ、「>2fooBAR</ドメイン: pw>C:、」 </ドメイン: authInfo>C: </ドメイン: >Cを移してください: </転送>C: <clTRID>ABC-12345</clTRID>C: </コマンド>。
Hollenbeck Standards Track [Page 16] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[16ページ]RFC3731EPPドメイン名
C:</epp>
C: </epp>。
When a <transfer> query command has been processed successfully, the EPP <resData> element MUST contain a child <domain:trnData> element that identifies the domain namespace and the location of the domain schema. The <domain:trnData> element contains the following child elements:
首尾よく<転送>質問命令を処理してあるとき、EPP<resData>要素は子供<ドメインを含まなければなりません: ドメイン名前空間とドメイン図式の位置を特定するtrnData>要素。 <ドメイン: trnData>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object.
- <ドメイン: ドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- A <domain:trStatus> element that contains the state of the most
recent transfer request.
- <ドメイン: 最新の転送要求の状態を含むtrStatus>要素。
- A <domain:reID> element that contains the identifier of the client
that requested the object transfer.
- <ドメイン: オブジェクト転送を要求したクライアントの識別子を含むreID>要素。
- A <domain:reDate> element that contains the date and time that the
transfer was requested.
- <ドメイン: 転送が要求された日時を含むreDate>要素。
- A <domain:acID> element that contains the identifier of the client
that SHOULD act upon the transfer request.
- <ドメイン: SHOULDが転送要求に演じるクライアントの識別子を含むacID>要素。
- A <domain: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.
- <ドメイン: 必要であるか完成した応答の日時を含むacDate>要素。 PENDING要求のために、値は日時をサーバで自動化された応答行動を取る前に応答を必要とする特定します。他のすべての状態タイプのために、値は要求が終了した日時を特定します。
- An OPTIONAL <domain:exDate> element that contains the end of the
domain object's validity period if the <transfer> command caused
or causes a change in the validity period.
- OPTIONAL<ドメイン: <転送>命令が有効期間に変化を引き起こすか、または引き起こすならドメインオブジェクトの有効期間の終わりを含むexDate>要素。
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: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ドメイン: trnData S: xmlns: ドメイン=「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチ」
Hollenbeck Standards Track [Page 17] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[17ページ]RFC3731EPPドメイン名
S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:name>example.com</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>ClientX</domain:reID> S: <domain:reDate>2000-06-06T22:00:00.0Z</domain:reDate> S: <domain:acID>ClientY</domain:acID> S: <domain:acDate>2000-06-11T22:00:00.0Z</domain:acDate> S: <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン1.0秒間:、」 ドメイン-1.0.xsd、「>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: </ドメインまでtrStatus>: trStatus>S: <ドメイン: reID>ClientX</ドメイン: reID>S: <ドメイン: reDate>2000-06-06T22:00:00.0Z</ドメイン: reDate>S: <ドメイン: 酸の>ClientY</ドメイン: 酸の>S: <ドメイン: acDate>2000-06-11T22:00:00.0Z</ドメイン: acDate>S: <ドメイン: exDate>2002-09-08T22:00:00.0Z</ドメイン: exDate>S: </ドメイン: trnData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54322-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
An EPP error response MUST be returned if a <transfer> query command can not be processed for any reason.
どんな理由でも<転送>質問命令を処理できないなら、EPP誤り応答を返さなければなりません。
3.2. EPP Transform Commands
3.2. EPP変形コマンド
EPP provides five commands to transform domain objects: <create> to create an instance of a domain object, <delete> to delete an instance of a domain object, <renew> to extend the validity period of a domain object, <transfer> to manage domain object sponsorship changes, and <update> to change information associated with a domain object.
EPPはドメインオブジェクトを変える5つのコマンドを提供します: <はドメインオブジェクトのインスタンスを作成するために>を作成して、<はドメインオブジェクトのインスタンスを削除するために>を削除して、<は、ドメインオブジェクト(ドメインオブジェクトスポンサーシップ変化、および<アップデート>を情報がドメインオブジェクトに関連づけた変化に管理する<転送>)の有効期間を延ばすために>を取り替えます。
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.
通常処理されていて、リアルタイムで終了したコマンドを変えてください。 サーバオペレータは受信するかもしれません、そして、要求された操作が完了できる前に変換が人間であるなら要求された操作を完了しながら命令しますが、延期するプロセスか第三者レビューが必要です。 そのような状況で、サーバは、コマンドを受け取られて、処理してありますが、要求された動きが未定であることに注意するために1001年の応答コードをクライアントに返さなければなりません。 また、サーバは開始を反映するコマンドの対象と要求された動作の完成であるオブジェクトの状態を管理しなければなりません。 操作がいったん完了すると、操作が完了して、オブジェクトの状態が変化したというサービスメッセージを使用して、トランザクションにかかわるすべてのクライアントに通知しなければなりません。
Hollenbeck Standards Track [Page 18] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[18ページ]RFC3731EPPドメイン名
3.2.1. EPP <create> Command
3.2.1. EPP<は>コマンドを作成します。
The EPP <create> command provides a transform operation that allows a client to create a domain object. In addition to the standard EPP command elements, the <create> command MUST contain a <domain:create> element that identifies the domain namespace and the location of the domain schema. The <domain:create> element contains the following child elements:
EPP<はコマンドがクライアントがドメインオブジェクトを作成できる変換操作を供給する>を作成します。 標準のEPPに加えて指揮機関、<は>を作成します。コマンドは<ドメインを含まなければなりません: ドメイン名前空間とドメイン図式の位置を特定する>要素を作成してください。 <ドメイン: >を作成してください。要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object to be created.
- <ドメイン: 作成されるべきドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- An OPTIONAL <domain:period> element that contains the initial
registration period of the domain object. A server MAY define a
default initial registration period if not specified by the
client.
- OPTIONAL<ドメイン: ドメインオブジェクトの新規登録の期間を含む期間の>要素。 クライアントによって指定されないなら、サーバはデフォルト新規登録の期間を定義するかもしれません。
- An OPTIONAL <domain:ns> element that contains the fully qualified
names of the delegated host objects or host attributes (name
servers) associated with the domain object to provide resolution
services for the domain; see section 1.1 for a description of the
elements used to specify host objects or host attributes. A host
object MUST be known to the server before the host object can be
associated with a domain object.
- OPTIONAL<ドメイン: 代表として派遣されたホストオブジェクトの完全に修飾された名前を含む>要素かドメインに関連しているホスト属性(ネームサーバ)が反対するナノ秒はドメインのための解決サービスを提供します。 要素の記述のためのセクション1.1が以前はよくホストオブジェクトかホスト属性を指定していたのを確実にしてください。 ホストオブジェクトをドメインオブジェクトに関連づけることができる前にホストオブジェクトをサーバに知っていなければなりません。
- An OPTIONAL <domain:registrant> element that contains the
identifier for the human or organizational social information
(contact) object to be associated with the domain object as the
object registrant. This object identifier MUST be known to the
server before the contact object can be associated with the domain
object. The EPP mapping for contact objects is described in
[RFC3733].
- OPTIONAL<ドメイン: オブジェクト記入者としてドメインオブジェクトに関連している人間の、または、組織的な社会情報(接触)オブジェクトのために識別子を含む記入者>要素。 接触オブジェクトをドメインオブジェクトに関連づけることができる前にこのオブジェクト識別子をサーバに知っていなければなりません。 オブジェクトを接触に写像するEPPは[RFC3733]で説明されます。
- Zero or more OPTIONAL <domain:contact> elements that contain the
identifiers for other contact objects to be associated with the
domain object. Contact object identifiers MUST be known to the
server before the contact object can be associated with the domain
object.
- より多くのOPTIONAL<ドメイン: ゼロか関連している他の接触オブジェクトのための識別子を含む連絡>要素がドメインで反対します。 接触オブジェクトをドメインオブジェクトに関連づけることができる前に連絡オブジェクト識別子をサーバに知っていなければなりません。
- A <domain:authInfo> element that contains authorization
information to be associated with the domain object. This mapping
includes a password-based authentication mechanism, but the schema
allows new mechanisms to be defined in new schemas.
- <ドメイン: ドメインオブジェクトに関連づけられるべき承認情報を含むauthInfo>要素。 このマッピングはパスワードベースの認証機構を含んでいますが、図式は、新しいメカニズムが新しいschemasで定義されるのを許容します。
Hollenbeck Standards Track [Page 19] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[19ページ]RFC3731EPPドメイン名
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: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> C: <domain:name>example.com</domain:name> C: <domain:period unit="y">2</domain:period> C: <domain:ns> C: <domain:hostObj>ns1.example.com</domain:hostObj> C: <domain:hostObj>ns1.example.net</domain:hostObj> C: </domain:ns> C: <domain:registrant>jd1234</domain:registrant> C: <domain:contact type="admin">sh8013</domain:contact> C: <domain:contact type="tech">sh8013</domain:contact> C: <domain:authInfo> C: <domain:pw>2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <は>Cを作成します: <ドメイン: Cを作成してください: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチC:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン-1.0C:、」 ドメイン-1.0.xsd、「>C:」 <ドメイン: 名前>example.com</ドメイン: >をCと命名してください: <ドメイン: 期間の単位=、「y、「>2</ドメイン: 期間の>C:、」 <ドメイン: ナノ秒>C: <ドメイン: hostObj>ns1.example.com</ドメイン: hostObj>C: <ドメイン: hostObj>ns1.example.net</ドメイン: hostObj>C: </ドメイン: ナノ秒>C: <ドメイン: 記入者>jd1234</ドメイン: 記入者>C: <ドメイン: タイプ=に連絡してください、「アドミン、「>sh8013</ドメイン: >Cに連絡してください」 <ドメイン: タイプ=に連絡してください、「科学技術、「>sh8013</ドメイン: >Cに連絡してください」 <ドメイン: authInfo>C: <ドメイン: pw>2fooBAR</ドメイン: pw>C: </ドメイン: authInfo>C: </ドメイン: >Cを作成してください: </は>Cを作成します: <clTRID>ABC-12345</clTRID>C: </コマンド>C: </epp>。
When a <create> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:creData> element that identifies the domain namespace and the location of the domain schema. The <domain:creData> element contains the following child elements:
EPP<resData>要素は子供<ドメインを含まなければなりません: 首尾よく<がいつ>コマンドを作成するか処理してあって、ドメイン名前空間とドメイン図式の位置を特定するcreData>要素。 <ドメイン: creData>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object.
- <ドメイン: ドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- A <domain:crDate> element that contains the date and time of
domain object creation.
- <ドメイン: ドメインオブジェクト作成の日時を含むcrDate>要素。
- An OPTIONAL <domain:exDate> element that contains the date and
time identifying the end of the domain object's registration
period.
- OPTIONAL<ドメイン: ドメインオブジェクトの登録の期間の終わりを特定する日時を含むexDate>要素。
Hollenbeck Standards Track [Page 20] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[20ページ]RFC3731EPPドメイン名
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: <domain:creData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:name>example.com</domain:name> S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> S: <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate> S: </domain:creData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ドメイン: creData S: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチS:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン1.0秒間:、」 ドメイン-1.0.xsd、「>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: crDate>1999-04-03T22:00:00.0Z</ドメイン: crDate>S: <ドメイン: exDate>2001-04-03T22:00:00.0Z</ドメイン: exDate>S: </ドメイン: creData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54321-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
An EPP error response MUST be returned if a <create> command can not be processed for any reason.
EPP誤り応答は<が>を作成するなら返して、どんな理由でもコマンドを処理できないということであるに違いありません。
3.2.2. EPP <delete> Command
3.2.2. EPP<は>コマンドを削除します。
The EPP <delete> command provides a transform operation that allows a client to delete a domain object. In addition to the standard EPP command elements, the <delete> command MUST contain a <domain:delete> element that identifies the domain namespace and the location of the domain schema. The <domain:delete> element contains the following child elements:
EPP<はコマンドがクライアントがドメインオブジェクトを削除できる変換操作を供給する>を削除します。 標準のEPPに加えて指揮機関、<は>を削除します。コマンドは<ドメインを含まなければなりません: ドメイン名前空間とドメイン図式の位置を特定する>要素を削除してください。 <ドメイン: >を削除してください。要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object to be deleted.
- <ドメイン: 削除されるべきドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
A domain object SHOULD NOT be deleted if subordinate host objects are associated with the domain object. For example, if domain "example.com" exists, and host object "ns1.example.com" also exists, then domain "example.com" SHOULD NOT be deleted until host "ns1.example.com" has been either deleted or renamed to exist in a
ドメイン、SHOULD NOTはオブジェクトが関連している削除されましたが、下位のホストがドメインオブジェクトであったなら反対します。 例えば、ドメイン"example.com"が存在していて、また、ホストオブジェクト"ns1.example.com"が存在していて、次に、ドメインが"example.com"であるというSHOULD NOTであるなら、ホスト"ns1.example.com"がaに存在するように削除されるか、または改名されるまで、削除されてください。
Hollenbeck Standards Track [Page 21] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[21ページ]RFC3731EPPドメイン名
different superordinate domain. A server SHOULD notify clients that object relationships exist by sending a 2305 error response code when a <delete> command is attempted and fails due to existing object relationships. Delegated and subordinate host objects associated with a domain object can be determined using the <info> query command for the domain object.
異なった「スーパー-縦座標」ドメイン。 SHOULDが<が>コマンドを削除するとき2305年の誤り応答コードを送るオブジェクト関係が生きさせるクライアントに通知するサーバは、既存のオブジェクト関係のため試みられて、失敗します。 ドメインオブジェクトに関連している代表として派遣されて下位のホストオブジェクトは、ドメインオブジェクトに<インフォメーション>質問コマンドを使用することで決定できます。
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: <domain:delete C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> C: <domain:name>example.com</domain:name> C: </domain:delete> C: </delete> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <は>Cを削除します: <ドメイン: Cを削除してください: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチC:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン-1.0C:、」 ドメイン-1.0.xsd、「>C:」 <ドメイン: 名前>example.com</ドメイン: >をCと命名してください: </ドメイン: >Cを削除してください: </は>Cを削除します: <clTRID>ABC-12345</clTRID>C: </コマンド>C: </epp>。
When a <delete> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.
首尾よく<がいつ>コマンドを削除するか処理してあって、サーバはEPP応答で<resData>要素なしで反応しなければなりません。
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>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54321-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
Hollenbeck Standards Track [Page 22] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[22ページ]RFC3731EPPドメイン名
An EPP error response MUST be returned if a <delete> command can not be processed for any reason.
EPP誤り応答は<が>を削除するなら返して、どんな理由でもコマンドを処理できないということであるに違いありません。
3.2.3. EPP <renew> Command
3.2.3. EPP<は>コマンドを更新します。
The EPP <renew> command provides a transform operation that allows a client to extend the validity period of a domain object. In addition to the standard EPP command elements, the <renew> command MUST contain a <domain:renew> element that identifies the domain namespace and the location of the domain schema. The <domain:renew> element contains the following child elements:
<が取り替えるEPPはクライアントがドメインオブジェクトの有効期間を延ばすことができる変換操作を提供します>が、命令する。 標準のEPPに加えて指揮機関、<を更新します。>コマンドは<ドメインを含まなければなりません: ドメイン名前空間とドメイン図式の位置を特定する>要素を取り替えてください。 <ドメイン: 更新してください。>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object whose validity period is to be extended.
- <ドメイン: 有効期間が延ばされることになっているドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- A <domain: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.
- <ドメイン: 現在の有効期間が終わる日付を含むcurExpDate>要素。 この値は、繰り返された<が複数の思いがけないうまくいっている更新における結果ではなく、コマンドがする>を取り替えるのを確実にします。
- An OPTIONAL <domain:period> element that contains the number of
units to be added to the registration period of the domain object.
The number of units available MAY be subject to limits imposed by
the server.
- OPTIONAL<ドメイン: ドメインオブジェクトの登録の期間に加えられるべきユニットの数を含む期間の>要素。 ユニットの有効な数はサーバによって課された限界を受けることがあるかもしれません。
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: <domain:renew C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> C: <domain:name>example.com</domain:name> C: <domain:curExpDate>2000-04-03</domain:curExpDate> C: <domain:period unit="y">5</domain:period> C: </domain:renew> C: </renew> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <は>Cを取り替えます: <ドメイン: Cを更新してください: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチC:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン-1.0C:、」 ドメイン-1.0.xsd、「>C:」 <ドメイン: 名前>example.com</ドメイン: >をCと命名してください: <ドメイン: curExpDate>2000年4月3日の</ドメイン: curExpDate>C: <ドメイン: 期間の単位=、「y、「>5</ドメイン: 期間の>C:、」 </ドメイン: >Cを取り替えてください: </は>Cを取り替えます: <clTRID>ABC-12345</clTRID>C: </コマンド>C: </epp>。
Hollenbeck Standards Track [Page 23] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[23ページ]RFC3731EPPドメイン名
When a <renew> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:renData> element that identifies the domain namespace and the location of the domain schema. The <domain:renData> element contains the following child elements:
EPP<resData>要素は子供<ドメインを含まなければなりません: <が更新されるとき、首尾よく>コマンドを処理してあって、ドメイン名前空間とドメイン図式の位置を特定するrenData>要素。 <ドメイン: renData>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object.
- <ドメイン: ドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- An OPTIONAL <domain:exDate> element that contains the date and
time identifying the end of the domain object's registration
period.
- OPTIONAL<ドメイン: ドメインオブジェクトの登録の期間の終わりを特定する日時を含むexDate>要素。
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: <domain:renData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:name>example.com</domain:name> S: <domain:exDate>2005-04-03T22:00:00.0Z</domain:exDate> S: </domain:renData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <resData>S: <ドメイン: renData S: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチS:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン1.0秒間:、」 ドメイン-1.0.xsd、「>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: exDate>2005-04-03T22:00:00.0Z</ドメイン: exDate>S: </ドメイン: renData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54322-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
An EPP error response MUST be returned if a <renew> command can not be processed for any reason.
EPP誤り応答は<が更新されるなら返して、どんな理由でも>コマンドを処理できないということであるに違いありません。
3.2.4. EPP <transfer> Command
3.2.4. EPP<転送>命令
The EPP <transfer> command provides a transform operation that allows a client to manage requests to transfer the sponsorship of a domain object. In addition to the standard EPP command elements, the
EPP<転送>命令はクライアントがドメインオブジェクトのスポンサーシップを移すという要求を管理できる変換操作を提供します。 標準のEPPに加えて、要素を命令してください。
Hollenbeck Standards Track [Page 24] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[24ページ]RFC3731EPPドメイン名
<transfer> command MUST contain a <domain:transfer> element that identifies the domain namespace and the location of the domain schema. The <domain:transfer> element contains the following child elements:
<転送>命令は<ドメインを含まなければなりません: ドメイン名前空間とドメイン図式の位置を特定する>要素を移してください。 <ドメイン: 転送>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object for which a transfer request is to be created,
approved, rejected, or cancelled.
- <ドメイン: 作成されるか、承認されるか、拒絶されるか、または取り消される転送要求がことであるドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- An OPTIONAL <domain:period> element that contains the number of
units to be added to the registration period of the domain 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.
- OPTIONAL<ドメイン: 転送プロセスの完成でドメインオブジェクトの登録の期間に加えられるべきユニットの数を含む期間の>要素。 転送が要求されているときだけ、この要素を使用できます、そして、別の方法で使用されるなら、それを無視しなければなりません。 ユニットの有効な数はサーバによって課された限界を受けることがあるかもしれません。
- A <domain:authInfo> element that contains authorization
information associated with the domain object or authorization
information associated with the domain object's registrant or
associated contacts. An OPTIONAL "roid" attribute MUST be used to
identify the registrant or contact object if and only if the given
authInfo is associated with a registrant or contact object, and
not the domain object itself.
- <ドメイン: ドメインオブジェクトに関連している承認情報か承認情報を含むauthInfo>要素がドメインオブジェクトの記入者か関連接触と交際しました。 そして、記入者か接触オブジェクトを特定するのにOPTIONAL"roid"属性を使用しなければならない、与えられたauthInfoがドメインではなく、記入者か接触オブジェクトに関連している場合にだけ、それ自体で反対してください。
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 [RFC3730].
あらゆるEPP<転送>命令が実行されるために転送操作を特定する「オプアート」属性を含まなければなりません。 すべての属性値のための有効値、定義、および承認は[RFC3730]で定義されます。
Transfer of a domain object MUST implicitly transfer all host objects that are subordinate to the domain object. For example, if domain object "example.com" is transferred and host object "ns1.example.com" exists, the host object MUST be transferred as part of the "example.com" transfer process. Host objects that are subject to transfer when transferring a domain object are listed in the response to an EPP <info> command performed on the domain object.
ドメインオブジェクトの転送はそれとなくすべてのドメインオブジェクトに下位であることのホストオブジェクトを移さなければなりません。 例えば、ドメインオブジェクト"example.com"がわたっていて、ホストオブジェクト"ns1.example.com"が存在しているなら、"example.com"転送プロセスの一部としてホストオブジェクトを移さなければなりません。 ドメインオブジェクトを移すとき転送を被りやすいホストオブジェクトはドメインオブジェクトに実行されたEPP<インフォメーション>コマンドへの応答で記載されています。
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: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <転送オプアート=、「要求、「>C:」 <ドメイン: 転送C: xmlns: ドメイン=「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチ」
Hollenbeck Standards Track [Page 25] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[25ページ]RFC3731EPPドメイン名
C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> C: <domain:name>example.com</domain:name> C: <domain:period unit="y">1</domain:period> C: <domain:authInfo> C: <domain:pw roid="JD1234-REP">2fooBAR</domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
C: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン-1.0C:、」 ドメイン-1.0.xsd、「>C:」 <ドメイン: 名前>example.com</ドメイン: >をCと命名してください: <ドメイン: 期間の単位=、「y、「>1</ドメイン: 期間の>C:、」 <ドメイン: authInfo>C: <ドメイン: pw roidが等しい、「JD1234-レップ、「>2fooBAR</ドメイン: pw>C:、」 </ドメイン: authInfo>C: </ドメイン: >Cを移してください: </転送>C: <clTRID>ABC-12345</clTRID>C: </コマンド>C: </epp>。
When a <transfer> command has been processed successfully, the EPP <resData> element MUST contain a child <domain:trnData> element that identifies the domain namespace and the location of the domain schema. The <domain:trnData> element contains the same child elements defined for a transfer query response.
首尾よく<転送>命令を処理してあるとき、EPP<resData>要素は子供<ドメインを含まなければなりません: ドメイン名前空間とドメイン図式の位置を特定するtrnData>要素。 <ドメイン: trnData>要素は転送質問応答のために定義された同じ子供要素を含んでいます。
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: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:name>example.com</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>ClientX</domain:reID> S: <domain:reDate>2000-06-08T22:00:00.0Z</domain:reDate> S: <domain:acID>ClientY</domain:acID> S: <domain:acDate>2000-06-13T22:00:00.0Z</domain:acDate> S: <domain:exDate>2002-09-08T22:00:00.0Z</domain:exDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1001、「>S:」 首尾よく完成した<msg>Command。 動作未定の</msg>S: </結果>S: <resData>S: <ドメイン: trnData S: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチS:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン1.0秒間:、」 ドメイン-1.0.xsd、「>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: </ドメインまでtrStatus>: trStatus>S: <ドメイン: reID>ClientX</ドメイン: reID>S: <ドメイン: reDate>2000-06-08T22:00:00.0Z</ドメイン: reDate>S: <ドメイン: 酸の>ClientY</ドメイン: 酸の>S: <ドメイン: acDate>2000-06-13T22:00:00.0Z</ドメイン: acDate>S: <ドメイン: exDate>2002-09-08T22:00:00.0Z</ドメイン: exDate>S: </ドメイン: trnData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54322-XYZ</svTRID>S: </trID>。
Hollenbeck Standards Track [Page 26] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[26ページ]RFC3731EPPドメイン名
S: </response> S:</epp>
S: </応答>S: </epp>。
An EPP error response MUST be returned if a <transfer> command can not be processed for any reason.
どんな理由でも<転送>命令を処理できないなら、EPP誤り応答を返さなければなりません。
3.2.5. EPP <update> Command
3.2.5. EPP<アップデート>命令
The EPP <update> command provides a transform operation that allows a client to modify the attributes of a domain object. In addition to the standard EPP command elements, the <update> command MUST contain a <domain:update> element that identifies the domain namespace and the location of the domain schema. The <domain:update> element contains the following child elements:
EPP<アップデート>命令はクライアントがドメインオブジェクトの属性を変更できる変換操作を提供します。 標準のEPP指揮機関に加えて、<アップデート>命令は<ドメインを含まなければなりません: ドメイン名前空間とドメイン図式の位置を特定する>要素をアップデートしてください。 <ドメイン: アップデート>要素は以下の子供要素を含んでいます:
- A <domain:name> element that contains the fully qualified name of
the domain object to be updated.
- <ドメイン: アップデートされるべきドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。
- An OPTIONAL <domain:add> element that contains attribute values to
be added to the object.
- OPTIONAL<ドメイン: オブジェクトに加えられるべき属性値を含む>要素を加えてください。
- An OPTIONAL <domain:rem> element that contains attribute values to
be removed from the object.
- OPTIONAL<ドメイン: オブジェクトから取り除かれるべき属性値を含むレム>要素。
- An OPTIONAL <domain:chg> element that contains object attribute
values to be changed.
- OPTIONAL<ドメイン: 変えられるべきオブジェクト属性値を含むchg>要素。
At least one <domain:add>, <domain:rem>, or <domain:chg> element MUST be provided. The <domain:add> and <domain:rem> elements contain the following child elements:
少なくとも1つの<ドメイン: >、<ドメイン: レム>、または<ドメインを加えてください: chg>要素を提供しなければなりません。 <ドメイン: >と<ドメインを加えてください: レム>要素は以下の子供要素を含んでいます:
- An OPTIONAL <domain:ns> element that contains the fully qualified
names of the delegated host objects or host attributes (name
servers) associated with the domain object to provide resolution
services for the domain; see section 1.1 for a description of the
elements used to specify host objects or host attributes. A host
object MUST be known to the server before the host object can be
associated with a domain object. If host attributes are used to
specify name servers, note that IP address elements are not needed
to identify a name server that is being removed. IP address
elements can safely be absent or ignored in this situation.
- OPTIONAL<ドメイン: 代表として派遣されたホストオブジェクトの完全に修飾された名前を含む>要素かドメインに関連しているホスト属性(ネームサーバ)が反対するナノ秒はドメインのための解決サービスを提供します。 要素の記述のためのセクション1.1が以前はよくホストオブジェクトかホスト属性を指定していたのを確実にしてください。 ホストオブジェクトをドメインオブジェクトに関連づけることができる前にホストオブジェクトをサーバに知っていなければなりません。 ホスト属性がネームサーバを指定するのに使用されるなら、取り除かれているネームサーバがIPアドレス要素が特定される必要はないことに注意してください。 IPアドレス要素は、安全に欠けるかこの状況で無視できます。
- Zero or more <domain:contact> elements that contain the
identifiers for contact objects to be associated with or removed
from the domain object. Contact object identifiers MUST be known
to the server before the contact object can be associated with the
domain object.
- より多くの<ドメイン: ゼロか接触オブジェクトがオブジェクトを関連づけられるか、またはドメインから取り除かれる識別子を含む連絡>要素。 接触オブジェクトをドメインオブジェクトに関連づけることができる前に連絡オブジェクト識別子をサーバに知っていなければなりません。
Hollenbeck Standards Track [Page 27] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[27ページ]RFC3731EPPドメイン名
- Zero or more <domain: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 <domain:chg> element contains the following child elements:
<ドメイン: chg>要素は以下の子供要素を含んでいます:
- A <domain:registrant> element that contains the identifier for the
human or organizational social information (contact) object to be
associated with the domain object as the object registrant. This
object identifier MUST be known to the server before the contact
object can be associated with the domain object. An empty element
can be used to remove registrant information.
- <ドメイン: オブジェクト記入者としてドメインオブジェクトに関連している人間の、または、組織的な社会情報(接触)オブジェクトのために識別子を含む記入者>要素。 接触オブジェクトをドメインオブジェクトに関連づけることができる前にこのオブジェクト識別子をサーバに知っていなければなりません。 記入者情報を取り除くのに空の要素を使用できます。
- A <domain:authInfo> element that contains authorization
information associated with the domain object. This mapping
includes a password-based authentication mechanism, but the schema
allows new mechanisms to be defined in new schemas. A
<domain:null> element can be used within the <domain:authInfo>
element to remove authorization information.
- <ドメイン: 承認情報を含むauthInfo>要素がドメインオブジェクトと交際しました。 このマッピングはパスワードベースの認証機構を含んでいますが、図式は、新しいメカニズムが新しいschemasで定義されるのを許容します。 <ドメイン: <ドメインの中でヌル>要素を使用できます: 承認情報を取り除くauthInfo>要素。
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: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" C: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 C: domain-1.0.xsd"> C: <domain:name>example.com</domain:name> C: <domain:add> C: <domain:ns> C: <domain:hostObj>ns2.example.com</domain:hostObj> C: </domain:ns> C: <domain:contact type="tech">mak21</domain:contact> C: <domain:status s="clientHold" C: lang="en">Payment overdue.</domain:status> C: </domain:add> C: <domain:rem> C: <domain:ns> C: <domain:hostObj>ns1.example.com</domain:hostObj> C: </domain:ns> C: <domain:contact type="tech">sh8013</domain:contact>
C: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <アップデート>C: <ドメイン: アップデートC: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチC:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン-1.0C:、」 ドメイン-1.0.xsd、「>C:」 <ドメイン: 名前>example.com</ドメイン: >をCと命名してください: <ドメイン: >Cを加えてください: <ドメイン: ナノ秒>C: <ドメイン: hostObj>ns2.example.com</ドメイン: hostObj>C: </ドメイン: ナノ秒>C: <ドメイン: タイプ=に連絡してください、「科学技術、「>mak21</ドメイン: >Cに連絡してください」 <ドメイン: 状態sは"clientHold"Cと等しいです: langが等しい、「アン、「期限が過ぎた>Payment. </ドメイン: 状態>C:、」 </ドメイン: >Cを加えてください: <ドメイン: レム>C: <ドメイン: ナノ秒>C: <ドメイン: hostObj>ns1.example.com</ドメイン: hostObj>C: </ドメイン: ナノ秒>C: <ドメイン: タイプ=に連絡してください、「技術者「>sh8013</ドメイン: 接触>」
Hollenbeck Standards Track [Page 28] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[28ページ]RFC3731EPPドメイン名
C: <domain:status s="clientUpdateProhibited"/> C: </domain:rem> C: <domain:chg> C: <domain:registrant>sh8013</domain:registrant> C: <domain:authInfo> C: <domain:pw>2BARfoo</domain:pw> C: </domain:authInfo> C: </domain:chg> C: </domain:update> C: </update> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>
C: <ドメイン: 状態sは"clientUpdateProhibited"/>Cと等しいです: </ドメイン: レム>C: <ドメイン: chg>C: <ドメイン: 記入者>sh8013</ドメイン: 記入者>C: <ドメイン: authInfo>C: <ドメイン: pw>2BARfoo</ドメイン: pw>C: </ドメイン: authInfo>C: </ドメイン: chg>C: </ドメイン: >Cをアップデートしてください: </アップデート>C: <clTRID>ABC-12345</clTRID>C: </コマンド>C: </epp>。
When an <update> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.
首尾よく<アップデート>命令を処理してあるとき、サーバはEPP応答で<resData>要素なしで反応しなければなりません。
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>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1000、「>S:」 <msg>Commandは首尾よく</msg>Sを完成しました: </結果>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54321-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
An EPP error response MUST be returned if an <update> command can not be processed for any reason.
どんな理由でも<アップデート>命令を処理できないなら、EPP誤り応答を返さなければなりません。
3.2.6. Offline Review of Requested Actions
3.2.6. 要求された動作のオフラインレビュー
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
コマンドはオーダーにおけるサーバによって処理されて、クライアントからそれらを受け取るということです。 コマンドの領収書と処理を確認する即時型反応はサーバによって起こされますが、要求された操作を完了する前に、サーバオペレータは要求された変形コマンドのオフラインレビューを実行するかもしれません。 サーバからの応答が明確に注意しなければならない変形コマンドを受け取られて、処理してある、しかし、要求された動作が処理されるくらいの状況で
Hollenbeck Standards Track [Page 29] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[29ページ]RFC3731EPPドメイン名
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.
<について説明する例がここで含まれていたオフラインレビューを必要とする>コマンドを作成します。 <に対応して返された結果コードとメッセージが>コマンドを作成することに注意してください。
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: <domain:creData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:name>example.com</domain:name> S: <domain:crDate>1999-04-03T22:00:00.0Z</domain:crDate> S: <domain:exDate>2001-04-03T22:00:00.0Z</domain:exDate> S: </domain:creData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </trID> S: </response> S:</epp>
S: <?xmlバージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <応答>S: <結果コードが等しい、「1001、「>S:」 首尾よく完成した<msg>Command。 動作未定の</msg>S: </結果>S: <resData>S: <ドメイン: creData S: xmlns: ドメイン=、「つぼ:ietf:params:xml:ナノ秒: ドメイン1インチS:、」 xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: ドメイン1.0秒間:、」 ドメイン-1.0.xsd、「>S:」 <ドメイン: 名前>example.com</ドメイン: >をSと命名してください: <ドメイン: crDate>1999-04-03T22:00:00.0Z</ドメイン: crDate>S: <ドメイン: exDate>2001-04-03T22:00:00.0Z</ドメイン: exDate>S: </ドメイン: creData>S: </resData>S: <trID>S: <clTRID>ABC-12345</clTRID>S: <svTRID>54321-XYZ</svTRID>S: </trID>S: </応答>S: </epp>。
The status of the domain object after returning this response MUST include "pendingCreate". The server operator reviews the request offline, and informs the client of the outcome of the review by queuing a service message for retrieval via the <poll> command.
この応答を返した後のドメインオブジェクトの状態は"pendingCreate"を含まなければなりません。 サーバオペレータは、レビューの結果について<投票>命令で検索へのサービスメッセージを列に並ばせることによって、要求をオフラインで再検討して、クライアントに知らせます。
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 <domain:panData> element that identifies the domain namespace and the location of the domain schema. The <domain:panData> element contains the following child elements:
サービスメッセージは<応答>、<msgQ>、通知について説明する<msg>要素のテキストを含まなければなりません。 さらに、EPP<resData>要素は子供<ドメインを含まなければなりません: ドメイン名前空間とドメイン図式の位置を特定するpanData>要素。 <ドメイン: panData>要素は以下の子供要素を含んでいます:
Hollenbeck Standards Track [Page 30] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[30ページ]RFC3731EPPドメイン名
- A <domain:name> element that contains the fully qualified name of
the domain object. The <domain:name> 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.
- <ドメイン: ドメインオブジェクトの完全に修飾された名前を含む要素と>を命名してください。 <ドメイン: 名前>要素はREQUIRED"paResult"属性を含んでいます。 上向きのブール値は要求が承認されて、終了したのを示します。 否定的ブール値は、要求が否定されて、要求された行動が取られていないのを示します。
- A <domain: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.
- <ドメイン: クライアントトランザクション識別子とサーバトランザクション識別子を含むpaTRID>要素は、コマンドを処理するためにオリジナルの応答とともに帰りました。 クライアントであるならオリジナルの<がある識別子が>コマンドを作成する場合にだけクライアントトランザクション識別子をOPTIONALであり、返すでしょう。
- A <domain:paDate> element that contains the date and time
describing when review of the requested action was completed.
- <ドメイン: 要求された動作のレビューがいつ終了したかを説明する日時を含むpaDate>要素。
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: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:name paResult="1">example.com</domain:name> S: <domain:paTRID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </domain:paTRID> S: <domain:paDate>1999-04-04T22:00:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>BCD-23456</clTRID> S: <svTRID>65432-WXY</svTRID> S: </trID>
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: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:domain-1.0 S: domain-1.0.xsd"> S: <domain:name paResult="1">example.com</domain:name> S: <domain:paTRID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54321-XYZ</svTRID> S: </domain:paTRID> S: <domain:paDate>1999-04-04T22:00:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>BCD-23456</clTRID> S: <svTRID>65432-WXY</svTRID> S: </trID>
Hollenbeck Standards Track [Page 31] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 31] RFC 3731 EPP Domain Name Mapping March 2004
S: </response> S:</epp>
S: </response> S:</epp>
4. Formal Syntax
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.
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"?>
BEGIN <?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:domain-1.0"
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"
xmlns:host="urn:ietf:params:xml:ns:host-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">
<schema targetNamespace="urn:ietf:params:xml:ns:domain-1.0" xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xmlns:host="urn:ietf:params:xml:ns:host-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"/>
<import namespace="urn:ietf:params:xml:ns:host-1.0"
schemaLocation="host-1.0.xsd"/>
<!-- 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"/> <import namespace="urn:ietf:params:xml:ns:host-1.0" schemaLocation="host-1.0.xsd"/>
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
domain provisioning schema.
</documentation>
</annotation>
<annotation> <documentation> Extensible Provisioning Protocol v1.0 domain provisioning schema. </documentation> </annotation>
<!--
Child elements found in EPP commands.
-->
<element name="check" type="domain:mNameType"/>
<element name="create" type="domain:createType"/>
<element name="delete" type="domain:sNameType"/>
<element name="info" type="domain:infoType"/>
<element name="renew" type="domain:renewType"/>
<!-- Child elements found in EPP commands. --> <element name="check" type="domain:mNameType"/> <element name="create" type="domain:createType"/> <element name="delete" type="domain:sNameType"/> <element name="info" type="domain:infoType"/> <element name="renew" type="domain:renewType"/>
Hollenbeck Standards Track [Page 32] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 32] RFC 3731 EPP Domain Name Mapping March 2004
<element name="transfer" type="domain:transferType"/>
<element name="update" type="domain:updateType"/>
<!--
Child elements of the <create> command.
-->
<complexType name="createType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="period" type="domain:periodType"
minOccurs="0"/>
<element name="ns" type="domain:nsType"
minOccurs="0"/>
<element name="registrant" type="eppcom:clIDType"
minOccurs="0"/>
<element name="contact" type="domain:contactType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="authInfo" type="domain:authInfoType"/>
</sequence>
</complexType>
<element name="transfer" type="domain:transferType"/> <element name="update" type="domain:updateType"/> <!-- Child elements of the <create> command. --> <complexType name="createType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="period" type="domain:periodType" minOccurs="0"/> <element name="ns" type="domain:nsType" minOccurs="0"/> <element name="registrant" type="eppcom:clIDType" minOccurs="0"/> <element name="contact" type="domain:contactType" minOccurs="0" maxOccurs="unbounded"/> <element name="authInfo" type="domain:authInfoType"/> </sequence> </complexType>
<complexType name="periodType">
<simpleContent>
<extension base="domain:pLimitType">
<attribute name="unit" type="domain:pUnitType"
use="required"/>
</extension>
</simpleContent>
</complexType>
<complexType name="periodType"> <simpleContent> <extension base="domain:pLimitType"> <attribute name="unit" type="domain:pUnitType" use="required"/> </extension> </simpleContent> </complexType>
<simpleType name="pLimitType">
<restriction base="unsignedShort">
<minInclusive value="1"/>
<maxInclusive value="99"/>
</restriction>
</simpleType>
<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>
<simpleType name="pUnitType"> <restriction base="token"> <enumeration value="y"/> <enumeration value="m"/> </restriction> </simpleType>
<complexType name="nsType">
<choice>
<element name="hostObj" type="eppcom:labelType"
maxOccurs="unbounded"/>
<element name="hostAttr" type="domain:hostAttrType"
<complexType name="nsType"> <choice> <element name="hostObj" type="eppcom:labelType" maxOccurs="unbounded"/> <element name="hostAttr" type="domain:hostAttrType"
Hollenbeck Standards Track [Page 33] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 33] RFC 3731 EPP Domain Name Mapping March 2004
maxOccurs="unbounded"/>
</choice>
</complexType>
<!--
Name servers are either host objects or attributes.
-->
maxOccurs="unbounded"/> </choice> </complexType> <!-- Name servers are either host objects or attributes. -->
<complexType name="hostAttrType">
<sequence>
<element name="hostName" type="eppcom:labelType"/>
<element name="hostAddr" type="host:addrType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<!--
If attributes, addresses are optional and follow the
structure defined in the host mapping.
-->
<complexType name="hostAttrType"> <sequence> <element name="hostName" type="eppcom:labelType"/> <element name="hostAddr" type="host:addrType" minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType> <!-- If attributes, addresses are optional and follow the structure defined in the host mapping. -->
<complexType name="contactType">
<simpleContent>
<extension base="eppcom:clIDType">
<attribute name="type" type="domain:contactAttrType"/>
</extension>
</simpleContent>
</complexType>
<complexType name="contactType"> <simpleContent> <extension base="eppcom:clIDType"> <attribute name="type" type="domain:contactAttrType"/> </extension> </simpleContent> </complexType>
<simpleType name="contactAttrType">
<restriction base="token">
<enumeration value="admin"/>
<enumeration value="billing"/>
<enumeration value="tech"/>
</restriction>
</simpleType>
<simpleType name="contactAttrType"> <restriction base="token"> <enumeration value="admin"/> <enumeration value="billing"/> <enumeration value="tech"/> </restriction> </simpleType>
<complexType name="authInfoType">
<choice>
<element name="pw" type="eppcom:pwAuthInfoType"/>
<element name="ext" type="eppcom:extAuthInfoType"/>
</choice>
</complexType>
<complexType name="authInfoType"> <choice> <element name="pw" type="eppcom:pwAuthInfoType"/> <element name="ext" type="eppcom:extAuthInfoType"/> </choice> </complexType>
<!--
Child element of commands that require a single name.
-->
<complexType name="sNameType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<!-- Child element of commands that require a single name. --> <complexType name="sNameType"> <sequence> <element name="name" type="eppcom:labelType"/>
Hollenbeck Standards Track [Page 34] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 34] RFC 3731 EPP Domain Name Mapping March 2004
</sequence>
</complexType>
<!--
Child element of commands that accept multiple names.
-->
<complexType name="mNameType">
<sequence>
<element name="name" type="eppcom:labelType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</sequence> </complexType> <!-- Child element of commands that accept multiple names. --> <complexType name="mNameType"> <sequence> <element name="name" type="eppcom:labelType" maxOccurs="unbounded"/> </sequence> </complexType>
<!--
Child elements of the <info> command.
-->
<complexType name="infoType">
<sequence>
<element name="name" type="domain:infoNameType"/>
<element name="authInfo" type="domain:authInfoType"
minOccurs="0"/>
</sequence>
</complexType>
<!-- Child elements of the <info> command. --> <complexType name="infoType"> <sequence> <element name="name" type="domain:infoNameType"/> <element name="authInfo" type="domain:authInfoType" minOccurs="0"/> </sequence> </complexType>
<complexType name="infoNameType">
<simpleContent>
<extension base = "eppcom:labelType">
<attribute name="hosts" type="domain:hostsType"
default="all"/>
</extension>
</simpleContent>
</complexType>
<complexType name="infoNameType"> <simpleContent> <extension base = "eppcom:labelType"> <attribute name="hosts" type="domain:hostsType" default="all"/> </extension> </simpleContent> </complexType>
<simpleType name="hostsType">
<restriction base="token">
<enumeration value="all"/>
<enumeration value="del"/>
<enumeration value="none"/>
<enumeration value="sub"/>
</restriction>
</simpleType>
<simpleType name="hostsType"> <restriction base="token"> <enumeration value="all"/> <enumeration value="del"/> <enumeration value="none"/> <enumeration value="sub"/> </restriction> </simpleType>
<!--
Child elements of the <renew> command.
-->
<complexType name="renewType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="curExpDate" type="date"/>
<!-- Child elements of the <renew> command. --> <complexType name="renewType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="curExpDate" type="date"/>
Hollenbeck Standards Track [Page 35] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 35] RFC 3731 EPP Domain Name Mapping March 2004
<element name="period" type="domain:periodType"
minOccurs="0"/>
</sequence>
</complexType>
<element name="period" type="domain:periodType" minOccurs="0"/> </sequence> </complexType>
<!--
Child elements of the <transfer> command.
-->
<complexType name="transferType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="period" type="domain:periodType"
minOccurs="0"/>
<element name="authInfo" type="domain:authInfoType"
minOccurs="0"/>
</sequence>
</complexType>
<!-- Child elements of the <transfer> command. --> <complexType name="transferType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="period" type="domain:periodType" minOccurs="0"/> <element name="authInfo" type="domain:authInfoType" minOccurs="0"/> </sequence> </complexType>
<!--
Child elements of the <update> command.
-->
<complexType name="updateType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="add" type="domain:addRemType"
minOccurs="0"/>
<element name="rem" type="domain:addRemType"
minOccurs="0"/>
<element name="chg" type="domain:chgType"
minOccurs="0"/>
</sequence>
</complexType>
<!-- Child elements of the <update> command. --> <complexType name="updateType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="add" type="domain:addRemType" minOccurs="0"/> <element name="rem" type="domain:addRemType" minOccurs="0"/> <element name="chg" type="domain:chgType" minOccurs="0"/> </sequence> </complexType>
<!--
Data elements that can be added or removed.
-->
<complexType name="addRemType">
<sequence>
<element name="ns" type="domain:nsType"
minOccurs="0"/>
<element name="contact" type="domain:contactType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="status" type="domain:statusType"
minOccurs="0" maxOccurs="11"/>
</sequence>
</complexType>
<!-- Data elements that can be added or removed. --> <complexType name="addRemType"> <sequence> <element name="ns" type="domain:nsType" minOccurs="0"/> <element name="contact" type="domain:contactType" minOccurs="0" maxOccurs="unbounded"/> <element name="status" type="domain:statusType" minOccurs="0" maxOccurs="11"/> </sequence> </complexType>
<!--
<!--
Hollenbeck Standards Track [Page 36] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 36] RFC 3731 EPP Domain Name Mapping March 2004
Data elements that can be changed.
-->
<complexType name="chgType">
<sequence>
<element name="registrant" type="domain:clIDChgType"
minOccurs="0"/>
<element name="authInfo" type="domain:authInfoChgType"
minOccurs="0"/>
</sequence>
</complexType>
Data elements that can be changed. --> <complexType name="chgType"> <sequence> <element name="registrant" type="domain:clIDChgType" minOccurs="0"/> <element name="authInfo" type="domain: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 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.
-->
<complexType name="authInfoChgType">
<choice>
<element name="pw" type="eppcom:pwAuthInfoType"/>
<element name="ext" type="eppcom:extAuthInfoType"/>
<element name="null"/>
</choice>
</complexType>
<!-- Allow the authInfo value to be nullified by including an empty element within the choice. --> <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="domain:chkDataType"/>
<element name="creData" type="domain:creDataType"/>
<element name="infData" type="domain:infDataType"/>
<element name="panData" type="domain:panDataType"/>
<element name="renData" type="domain:renDataType"/>
<element name="trnData" type="domain:trnDataType"/>
<!-- Child response elements. --> <element name="chkData" type="domain:chkDataType"/> <element name="creData" type="domain:creDataType"/> <element name="infData" type="domain:infDataType"/> <element name="panData" type="domain:panDataType"/> <element name="renData" type="domain:renDataType"/> <element name="trnData" type="domain:trnDataType"/>
<!--
<check> response elements.
-->
<complexType name="chkDataType">
<!-- <check> response elements. --> <complexType name="chkDataType">
Hollenbeck Standards Track [Page 37] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 37] RFC 3731 EPP Domain Name Mapping March 2004
<sequence>
<element name="cd" type="domain:checkType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<sequence> <element name="cd" type="domain:checkType" maxOccurs="unbounded"/> </sequence> </complexType>
<complexType name="checkType">
<sequence>
<element name="name" type="domain:checkNameType"/>
<element name="reason" type="eppcom:reasonType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="checkType"> <sequence> <element name="name" type="domain:checkNameType"/> <element name="reason" type="eppcom:reasonType" minOccurs="0"/> </sequence> </complexType>
<complexType name="checkNameType">
<simpleContent>
<extension base="eppcom:labelType">
<attribute name="avail" type="boolean"
use="required"/>
</extension>
</simpleContent>
</complexType>
<complexType name="checkNameType"> <simpleContent> <extension base="eppcom:labelType"> <attribute name="avail" type="boolean" use="required"/> </extension> </simpleContent> </complexType>
<!--
<create> response elements.
-->
<complexType name="creDataType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="crDate" type="dateTime"/>
<element name="exDate" type="dateTime"
minOccurs="0"/>
</sequence>
</complexType>
<!-- <create> response elements. --> <complexType name="creDataType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="crDate" type="dateTime"/> <element name="exDate" type="dateTime" minOccurs="0"/> </sequence> </complexType>
<!--
<info> response elements.
-->
<complexType name="infDataType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="roid" type="eppcom:roidType"/>
<element name="status" type="domain:statusType"
minOccurs="0" maxOccurs="11"/>
<element name="registrant" type="eppcom:clIDType"
minOccurs="0"/>
<element name="contact" type="domain:contactType"
minOccurs="0" maxOccurs="unbounded"/>
<!-- <info> response elements. --> <complexType name="infDataType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="roid" type="eppcom:roidType"/> <element name="status" type="domain:statusType" minOccurs="0" maxOccurs="11"/> <element name="registrant" type="eppcom:clIDType" minOccurs="0"/> <element name="contact" type="domain:contactType" minOccurs="0" maxOccurs="unbounded"/>
Hollenbeck Standards Track [Page 38] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 38] RFC 3731 EPP Domain Name Mapping March 2004
<element name="ns" type="domain:nsType"
minOccurs="0"/>
<element name="host" type="eppcom:labelType"
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="domain:authInfoType"
minOccurs="0"/>
</sequence>
</complexType>
<element name="ns" type="domain:nsType" minOccurs="0"/> <element name="host" type="eppcom:labelType" 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="domain: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="domain:statusValueType"
use="required"/>
<attribute name="lang" type="language"
default="en"/>
</extension>
</simpleContent>
</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="domain: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="inactive"/>
<enumeration value="ok"/>
<enumeration value="pendingCreate"/>
<simpleType name="statusValueType"> <restriction base="token"> <enumeration value="clientDeleteProhibited"/> <enumeration value="clientHold"/> <enumeration value="clientRenewProhibited"/> <enumeration value="clientTransferProhibited"/> <enumeration value="clientUpdateProhibited"/> <enumeration value="inactive"/> <enumeration value="ok"/> <enumeration value="pendingCreate"/>
Hollenbeck Standards Track [Page 39] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 39] RFC 3731 EPP Domain Name Mapping March 2004
<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>
<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="name" type="domain:paNameType"/>
<element name="paTRID" type="epp:trIDType"/>
<element name="paDate" type="dateTime"/>
</sequence>
</complexType>
<!-- Pending action notification response elements. --> <complexType name="panDataType"> <sequence> <element name="name" type="domain:paNameType"/> <element name="paTRID" type="epp:trIDType"/> <element name="paDate" type="dateTime"/> </sequence> </complexType>
<complexType name="paNameType">
<simpleContent>
<extension base="eppcom:labelType">
<attribute name="paResult" type="boolean"
use="required"/>
</extension>
</simpleContent>
</complexType>
<complexType name="paNameType"> <simpleContent> <extension base="eppcom:labelType"> <attribute name="paResult" type="boolean" use="required"/> </extension> </simpleContent> </complexType>
<!--
<renew> response elements.
-->
<complexType name="renDataType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="exDate" type="dateTime"
minOccurs="0"/>
</sequence>
</complexType>
<!-- <renew> response elements. --> <complexType name="renDataType"> <sequence> <element name="name" type="eppcom:labelType"/> <element name="exDate" type="dateTime" minOccurs="0"/> </sequence> </complexType>
<!--
<transfer> response elements.
-->
<complexType name="trnDataType">
<sequence>
<!-- <transfer> response elements. --> <complexType name="trnDataType"> <sequence>
Hollenbeck Standards Track [Page 40] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 40] RFC 3731 EPP Domain Name Mapping March 2004
<element name="name" type="eppcom:labelType"/>
<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>
<element name="name" type="eppcom:labelType"/> <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
<!-- End of schema. --> </schema> END
5. Internationalization Considerations
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. 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.
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. 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.
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 [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.
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 [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.
This document requires domain and host name syntax as specified in [RFC952] as updated by [RFC1123]. At the time of this writing, RFC 3490 [RFC3490] describes a standard to use certain ASCII name labels to represent non-ASCII name labels. These conformance requirements might change as a result of progressing work in developing standards for internationalized domain names.
This document requires domain and host name syntax as specified in [RFC952] as updated by [RFC1123]. At the time of this writing, RFC 3490 [RFC3490] describes a standard to use certain ASCII name labels to represent non-ASCII name labels. These conformance requirements might change as a result of progressing work in developing standards for internationalized domain names.
Hollenbeck Standards Track [Page 41] RFC 3731 EPP Domain Name Mapping March 2004
Hollenbeck Standards Track [Page 41] RFC 3731 EPP Domain Name Mapping March 2004
6. IANA Considerations
6. IANA Considerations
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Two URI assignments have been registered by the IANA.
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Two URI assignments have been registered by the IANA.
Registration request for the domain namespace:
Registration request for the domain namespace:
URI: urn:ietf:params:xml:ns:domain-1.0
URI: urn:ietf:params:xml:ns:domain-1.0
Registrant Contact: See the "Author's Address" section of this document.
Registrant Contact: See the "Author's Address" section of this document.
XML: None. Namespace URIs do not represent an XML specification.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the domain XML schema:
Registration request for the domain XML schema:
URI: urn:ietf:params:xml:schema:domain-1.0
URI: urn:ietf:params:xml:schema:domain-1.0
Registrant Contact: See the "Author's Address" section of this document.
記入者接触: このドキュメントの「作者のアドレス」セクションを見てください。
XML: See the "Formal Syntax" section of this document.
XML: このドキュメントの「正式な構文」セクションを見てください。
7. Security Considerations
7. セキュリティ問題
Authorization information as described in section 2.6 is REQUIRED to create a domain 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.
セクション2.6で説明される承認情報はドメインオブジェクトを作成するREQUIREDです。 この情報はクライアント承認がコマンドを実行することを決定する追加手段として何らかの質問と転送操作に使用されます。 不注意な公開から承認情報を保護しない場合、権限のない転送操作と権限のない情報リリースをもたらすことができます。 クライアントとサーバの両方が、承認情報が高級な暗号化メカニズムで保存されて、交換されて、プライバシーサービスを提供するのを確実にしなければなりません。
The object mapping described in this document does not provide any other security services or introduce any additional considerations beyond those described by [RFC3730] and protocol layers used by EPP.
本書では説明されたオブジェクトマッピングは、[RFC3730]とEPPによって使用されたプロトコル層によって説明されたものを超えていかなる他のセキュリティー・サービスも提供もしませんし、どんな追加問題も紹介もしません。
8. Acknowledgements
8. 承認
This document was originally written as an individual submission Internet-Draft. The provreg working group later adopted it as a working group document and provided many invaluable comments and suggested improvements. The author wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions.
このドキュメントは元々、個々の服従インターネット草稿として書かれました。 provregワーキンググループは、後でワーキンググループドキュメントとしてそれを採用して、多くの非常に貴重なコメントと提案改善を提供しました。 作者は彼らのプロセスと編集の貢献のためにWGいすのエドワード・ルイスとJaap Akkerhuisの取り組みを承認したがっています。
Hollenbeck Standards Track [Page 42] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[42ページ]RFC3731EPPドメイン名
Specific suggestions that have been incorporated into this document were provided by Joe Abley, Chris Bason, Eric Brunner-Williams, Jordyn Buchanan, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, Asbjorn Steira, Bruce Tonkin, and Rick Wesson.
このドキュメントに組み入れられた特定の提案はジョーAbley、クリスBason、エリック・ブルンナー-ウィリアムズ、Jordynブキャナン、デーヴ・クロッカー、Ayesha Damaraju、アンソニー・イーデン、Sheer El-Showk、クラウスMalorny、ダン・マンリー、マイケルMealling、パトリックMevzek、Asbjorn Steira、ブルース・トンキン、およびリック・ウェッソンによって提供されました。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC952] Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet
Host Table Specification", RFC 952, October 1985.
[RFC952] HarrenstienとK.とスタールとM.とE.Feinler、「DODインターネットホストテーブル仕様」、RFC952、1985年10月。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123] ブレーデン、R.、エド、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[RFC3339]Klyne(G.とC.ニューマン)は「インターネットで以下の日付を入れて、調節します」。 「タイムスタンプ」、RFC3339、2002年7月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3688] 食事、M.、「IETF XML登録」、BCP81、RFC3688、2004年1月。
[RFC3730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
RFC 3730, March 2004.
2004年のS.、「広げることができる食糧を供給するプロトコル(EPP)」、RFC3730行進の[RFC3730]Hollenbeck。
[RFC3732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Host Mapping", RFC 3732, March 2004.
[RFC3732] Hollenbeck、S.、「広げることができる食糧を供給するプロトコル(EPP)はマッピングをホスティングする」RFC3732、2004年3月。
[RFC3733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", RFC 3733, March 2004.
[RFC3733] Hollenbeck、S.、「広げることができる食糧を供給するプロトコル(EPP)はマッピングに連絡する」RFC3733、2004年3月。
[XML] Editor T. Bray et al.: "Extensible Markup Language (XML)
1.0 (Second Edition)", W3C Recommendation 6 October 2000.
[XML] エディタT.Bray他: 「拡張マークアップ言語(XML)1.0(第2版)」、W3C推薦2000年10月6日。
[XMLS-1] Editors H. Thompson et al.: "XML Schema Part 1:
Structures", W3C Recommendation 2 May 2001.
[XMLS-1] エディターズH.トンプソン他: 「XML図式第1部:」 「構造」、W3C推薦2001年5月2日。
[XMLS-2] Editors P. Biron, A. Malhotra: "XML Schema Part 2:
Datatypes", W3C Recommendation 2 May 2001.
[XMLS-2] エディターズP.ビロン、A.Malhotra: 「XML図式第2部:」 「データ型式」、W3C推薦2001年5月2日。
9.2. Informative References
9.2. 有益な参照
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, February 2000.
[RFC2781]ホフマン、2000年2月のP.とF.Yergeau、「UTF-16、ISO10646のコード化」RFC2781。
Hollenbeck Standards Track [Page 43] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[43ページ]RFC3731EPPドメイン名
[RFC3490] Faltstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3490] FaltstromとP.とホフマンとP.とA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
10. Author's Address
10. 作者のアドレス
Scott Hollenbeck VeriSign Global Registry Services 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
スコット・Hollenbeckのベリサインのグローバルな登録サービス21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
EMail: shollenbeck@verisign.com
メール: shollenbeck@verisign.com
Hollenbeck Standards Track [Page 44] RFC 3731 EPP Domain Name Mapping March 2004
2004年3月を写像するHollenbeck標準化過程[44ページ]RFC3731EPPドメイン名
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
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.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Hollenbeck Standards Track [Page 45]
Hollenbeck標準化過程[45ページ]
一覧
スポンサーリンク
