Internet DRAFT - draft-neves-epp-brorg
draft-neves-epp-brorg
Network Working Group F. Neves
Internet-Draft H. Kobayashi
Expires: February 24, 2007 Registro.br
August 23, 2006
BR Organization Mapping for the Extensible Provisioning Protocol (EPP)
draft-neves-epp-brorg-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 24, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of .br
organizational social information stored in a shared central
repository. Specified in XML, this mapping extends the EPP contact
mapping to provide additional features required for the provisioning
of .br organizational social information.
Neves & Kobayashi Expires February 24, 2007 [Page 1]
Internet-Draft EPP BR Organization Mapping August 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used In This Document . . . . . . . . . . . . 3
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Contacts . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 4
3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 4
3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 7
3.1.3. EPP <transfer> Command . . . . . . . . . . . . . . . . 10
3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 11
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 11
3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 13
3.2.3. EPP <transfer> Command . . . . . . . . . . . . . . . . 13
3.2.4. EPP <renew> Command . . . . . . . . . . . . . . . . . 13
3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 13
3.3. Offline Review of Requested Actions . . . . . . . . . . . 15
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Internationalization Considerations . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23
8.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Changes from version 02 . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26
Neves & Kobayashi Expires February 24, 2007 [Page 2]
Internet-Draft EPP BR Organization Mapping August 2006
1. Introduction
This document describes a .br organization mapping for version 1.0 of
the Extensible Provisioning Protocol (EPP). This mapping, an
extension of the contact mapping described in [I-D.hollenbeck-epp-
rfc3733bis], is specified using the Extensible Markup Language (XML)
1.0, as described in [W3C.REC-xml-20040204], and XML Schema notation,
as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-
xmlschema-2-20041028].
The EPP core protocol specification [I-D.hollenbeck-epp-rfc3730bis]
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.
1.1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
In examples, "C:" represents lines sent by a protocol client and "S:"
represents lines returned by a protocol server. Indentation and
white spaces in examples is provided only to ilustrate element
relationships and is not a REQUIRED feature of this protocol.
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.
2. Object Attributes
This extension adds elements to the EPP contact mapping
[I-D.hollenbeck-epp-rfc3733bis]. Only new element descriptions are
described here.
2.1. Contacts
All EPP contacts are identified by a server-unique identifier.
Individual social information 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 [I-D.hollenbeck-epp-rfc3733bis].
Neves & Kobayashi Expires February 24, 2007 [Page 3]
Internet-Draft EPP BR Organization Mapping August 2006
2.2. Proxy
In some situations, an organization may not yet have local branch
offices. In this case, it will be represented by local legal
representative.
The registration of such organizations is done by off-line
procedures.
3. EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found
in the EPP core protocol specification [I-D.hollenbeck-epp-
rfc3730bis]. The command mappings described here are specifically
for use in provisioning and managing .br organization objects via
EPP.
3.1. EPP Query Commands
EPP provides three commands to retrieve object information: <check>
to determine if an object is known to the server, <info> to retrieve
detailed information associated with an object, and <transfer> to
retrieve object transfer status information.
3.1.1. EPP <check> Command
This extension defines additional elements to the EPP <check> command
described in the EPP contact mapping [I-D.hollenbeck-epp-rfc3733bis].
No additional elements are defined for the EPP <check> response.
The EPP <check> command is used to determine if an object can be
provisioned within a repository. In addition to the EPP command
elements described in the EPP contact mapping [I-D.hollenbeck-epp-
rfc3733bis], the <check> command MUST contain an <extension> element.
The <extension> element MUST contain a child element <brorg:check>
element that identifies the extension namespace and the location of
the extension schema. The <brorg:check> element contains one or more
<brorg:cd> child elements containing the following child element:
- A <brorg:id> element that contains the server-unique identifier of
the object.
- A <brorg:organization> element that identifies the queried object.
Neves & Kobayashi Expires February 24, 2007 [Page 4]
Internet-Draft EPP BR Organization Mapping August 2006
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: <contact:check
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
C: contact-1.0.xsd">
C: <contact:id>e123456</contact:id>
C: <contact:id>e654321</contact:id>
C: </contact:check>
C: </check>
C: <extension>
C: <brorg:check
C: xmlns:brorg="urn:ietf:params:xml:ns:brorg-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:brorg-1.0
C: brorg-1.0.xsd">
C: <brorg:cd>
C: <brorg:id>e123456</brorg:id>
C: <brorg:organization>
C: 043.828.151/0001-45
C: </brorg:organization>
C: </brorg:cd>
C: <brorg:cd>
C: <brorg:id>e654321</brorg:id>
C: <brorg:organization>
C: 005.506.560/0001-36
C: </brorg:organization>
C: </brorg:cd>
C: </brorg:check>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an extended <check> command has been processed successfully, the
EPP <resData> element MUST contain child elements as described in the
EPP contact mapping [I-D.hollenbeck-epp-rfc3733bis]. In addition,
the EPP <response> element MAY contain a child <extension> element.
The <extension> element MUST contain a child <brorg:chkData> element
that identifies the extension namespace and the location of the
extension schema. The <brorg:chkData> element contain the following
child element:
Neves & Kobayashi Expires February 24, 2007 [Page 5]
Internet-Draft EPP BR Organization Mapping August 2006
- One or more <brorg:ticketInfo> elements that contain the following
child elements.
- A <brorg:organization> element that identifies the checked
organization.
- A <brorg:ticketNumber> element that contains the identifier of
an existing domain name registration request for the
organization.
- A <brorg:domainName> element that contains the fully qualified
domain name of the registration request identified by the
<brorg:ticketNumber> element.
The <extension> element is used by an EPP server only if all of the
following conditions are met for at least one of the organizations
being checked:
- The organization identified by the <brorg:organization> does not
exist.
- There is a pending domain registration request for the
organization identified by the <brorg:organization>. This pending
domain registration request is identified by the <brorg:
ticketNumber> response element.
- The existing pending domain registration request was not created
by the sponsoring client that performed the <brorg:check> command.
Neves & Kobayashi Expires February 24, 2007 [Page 6]
Internet-Draft EPP BR Organization Mapping August 2006
Example <check> response with <extension> element:
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: <contact:chkData
S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
S: contact-1.0.xsd">
S: <contact:cd>
S: <contact:id avail="0">e12345</contact:id>
S: </contact:cd>
S: </contact:chkData>
S: </resData>
S: <extension>
S: <brorg:chkData
S: xmlns:brorg="urn:ietf:params:xml:ns:brorg-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:brorg-1.0
S: brorg-1.0.xsd">
S: <brorg:ticketInfo>
S: <brorg:organization>
S: 005.506.560/0001-36
S: </brorg:organization>
S: <brorg:ticketNumber>1234</brorg:ticketNumber>
S: <brorg:domainName>exemplo.com.br</brorg:domainName>
S: </brorg:ticketInfo>
S: </brorg:chkData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
3.1.2. EPP <info> Command
This extension defines additional elements to the EPP <info> command
and EPP <info> response described in the EPP contact mapping
[I-D.hollenbeck-epp-rfc3733bis].
Neves & Kobayashi Expires February 24, 2007 [Page 7]
Internet-Draft EPP BR Organization Mapping August 2006
The EPP <info> command is used to retrieve information associated
with an object. In addition to the EPP command elements described in
the EPP contact mapping [I-D.hollenbeck-epp-rfc3733bis], the <info>
command MUST contain an <extension> element. The <extension> element
MUST contain a child element <brorg:info> element that identifies the
extension namespace and the location of the extension schema. The
<brorg:info> element contains the following child element:
- A <brorg:organization> element that contains the identifier of the
organization object.
Example <info> command:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <info>
C: <contact:info
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
C: contact-1.0.xsd">
C: <contact:id>e654321</contact:id>
C: </contact:info>
C: </info>
C: <extension>
C: <brorg:info
C: xmlns:brorg="urn:ietf:params:xml:ns:brorg-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:brorg-1.0
C: brorg-1.0.xsd">
C: <brorg:organization>
C: 005.506.560/0001-36
C: </brorg:organization>
C: </brorg:info>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an <info> command has been processed successfully, the EPP
<resData> element MUST contain child elements as described in the EPP
contact mapping [I-D.hollenbeck-epp-rfc3733bis]. In addition, the
EPP <response> element MUST contain a child <extension> element. The
<extension> element MUST contain a child <brorg:infData> element that
identifies the extension namespace and the location of the extension
schema. The <brorg:infData> element contains the following child
Neves & Kobayashi Expires February 24, 2007 [Page 8]
Internet-Draft EPP BR Organization Mapping August 2006
elements:
- A <brorg:organization> element that identifies the queried object.
- One or more <brorg:contact> elements that contain identifiers for
the human social information objects associated with the
organization object.
- An OPTIONAL <brorg:responsible> element that contains the name of
a person responsible for the organization.
- An OPTIONAL <brorg:proxy> element that contains the identifier for
an organization object that represents the queried organization
object.
- Zero or more <brorg:domainName> elements that contain the fully
qualified names of domain objects associated with this
organization.
Example <info> response:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <contact:infData
S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
S: contact-1.0.xsd">
S: <contact:id>e654321</contact:id>
S: <contact:roid>e654321-REP</contact:roid>
S: <contact:status s="ok"/>
S: <contact:postalInfo type="int">
S: <contact:name>Example Inc.</contact:name>
S: <contact:addr>
S: <contact:street>
S: Av. Nacoes Unidas, 11541
S: </contact:street>
S: <contact:street>7o. andar</contact:street>
S: <contact:city>Sao Paulo</contact:city>
S: <contact:sp>SP</contact:sp>
S: <contact:pc>04578-000</contact:pc>
Neves & Kobayashi Expires February 24, 2007 [Page 9]
Internet-Draft EPP BR Organization Mapping August 2006
S: <contact:cc>BR</contact:cc>
S: </contact:addr>
S: </contact:postalInfo>
S: <contact:voice x="1234">+55.1155093500</contact:voice>
S: <contact:fax>+55.1155093501</contact:fax>
S: <contact:email>jdoe@example.com.br</contact:email>
S: <contact:clID>ClientY</contact:clID>
S: <contact:crID>ClientX</contact:crID>
S: <contact:crDate>2005-12-05T12:00:00.0Z</contact:crDate>
S: <contact:upID>ClientX</contact:upID>
S: <contact:upDate>2005-12-05T12:00:00.0Z</contact:upDate>
S: <contact:disclose flag="0">
S: <contact:voice/>
S: <contact:email/>
S: </contact:disclose>
S: </contact:infData>
S: </resData>
S: <extension>
S: <brorg:infData
S: xmlns:brorg="urn:ietf:params:xml:ns:brorg-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:brorg-1.0
S: brorg-1.0.xsd">
S: <brorg:organization>
S: 005.506.560/0001-36
S: </brorg:organization>
S: <brorg:contact type="admin">fan</brorg:contact>
S: <brorg:responsible>John Doe</brorg:responsible>
S: <brorg:domainName>antispam.br</brorg:domainName>
S: <brorg:domainName>cert.br</brorg:domainName>
S: <brorg:domainName>dns.br</brorg:domainName>
S: <brorg:domainName>nic.br</brorg:domainName>
S: <brorg:domainName>ptt.br</brorg:domainName>
S: <brorg:domainName>registro.br</brorg:domainName>
S: </brorg:infData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if an extended <info> command
can not be processed for any reason.
3.1.3. EPP <transfer> Command
This extension does not add any elements to the EPP <transfer>
Neves & Kobayashi Expires February 24, 2007 [Page 10]
Internet-Draft EPP BR Organization Mapping August 2006
command or <transfer> response described in the EPP contact mapping
[I-D.hollenbeck-epp-rfc3733bis].
3.2. EPP Transform Commands
EPP provides five commands to transform objects: <create> to create
an instance of an object, <delete> to delete an instance of an
object, <renew> to extend the validity period of an object,
<transfer> to manage object sponsorship changes, and <update> to
change information associated with an object.
3.2.1. EPP <create> Command
This extension defines additional elements to the EPP <create>
command described in the EPP contact mapping [I-D.hollenbeck-epp-
rfc3733bis]. No additional elements are defined for the EPP <create>
response.
The EPP <create> command provides a transform operation that allows a
client to create an organization object. In addition to the EPP
command elements described in the EPP contact mapping
[I-D.hollenbeck-epp-rfc3733bis], the <create> command MUST contain an
<extension> element. The <extension> element MUST contain a child
<brorg:create> element that identifies the extension namespace and
the location of the extension schema. The <brorg:create> element
contains the following child elements:
- A <brorg:organization> element that contains the identifier of the
organization object.
- One or more <brorg:contact> elements that contain identifiers for
the human social information objects associated with the
organization object.
- An OPTIONAL <brorg:responsible> element that contains the name of
a person responsible for the organization.
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: <contact:create
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
Neves & Kobayashi Expires February 24, 2007 [Page 11]
Internet-Draft EPP BR Organization Mapping August 2006
C: xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
C: contact-1.0.xsd">
C: <contact:id>e123456</contact:id>
C: <contact:postalInfo type="int">
C: <contact:name>Example Inc.</contact:name>
C: <contact:addr>
C: <contact:street>
C: Av. Nacoes Unidas, 11541
C: </contact:street>
C: <contact:street>7o. andar</contact:street>
C: <contact:city>Sao Paulo</contact:city>
C: <contact:sp>SP</contact:sp>
C: <contact:pc>04578-000</contact:pc>
C: <contact:cc>BR</contact:cc>
C: </contact:addr>
C: </contact:postalInfo>
C: <contact:voice x="1234">+55.1155093500</contact:voice>
C: <contact:fax>+55.1155093501</contact:fax>
C: <contact:email>jdoe@example.com</contact:email>
C: <contact:authInfo>
C: <contact:pw>2fooBAR</contact:pw>
C: </contact:authInfo>
C: <contact:disclose flag="0">
C: <contact:voice/>
C: <contact:email/>
C: </contact:disclose>
C: </contact:create>
C: </create>
C: <extension>
C: <brorg:create
C: xmlns:brorg="urn:ietf:params:xml:ns:brorg-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:brorg-1.0
C: brorg-1.0.xsd">
C: <brorg:organization>
C: 005.506.560/0001-36
C: </brorg:organization>
C: <brorg:contact type="admin">fan</brorg:contact>
C: <brorg:responsible>John Doe</brorg:responsible>
C: </brorg:create>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an extended <create> command has been processed successfully,
the EPP response is as described in the EPP contact mapping
[I-D.hollenbeck-epp-rfc3733bis].
Neves & Kobayashi Expires February 24, 2007 [Page 12]
Internet-Draft EPP BR Organization Mapping August 2006
3.2.2. EPP <delete> Command
This extension does not add any elements to the EPP <delete> command
or <delete> response described in the EPP contact mapping
[I-D.hollenbeck-epp-rfc3733bis].
3.2.3. EPP <transfer> Command
This extension does not add any elements to the EPP <transfer>
command or <transfer> response described in the EPP contact mapping
[I-D.hollenbeck-epp-rfc3733bis].
3.2.4. EPP <renew> Command
Renew semantics do not apply to organization objects, so there is no
mapping defined for the EPP <renew> command.
3.2.5. EPP <update> Command
This extension defines additional elements for the EPP <update>
command described in the EPP contact mapping [I-D.hollenbeck-epp-
rfc3733bis]. No additional elements are defined for the EPP <update>
response.
The EPP <update> command provides a transform operation that allows a
client to change the state of an object. In addition to the EPP
command elements described in the EPP contact mapping
[I-D.hollenbeck-epp-rfc3733bis], the <update> command MUST contain a
child <extension> element. The <extension> element MUST contain a
child <brorg:update> element that identifies the extension namespace
and the location of the extension schema. The <brorg:update> element
contains the following child elements:
- A <brorg:organization> element that contains the identifier of the
organization object.
- An OPTIONAL <brorg:add> element that contains attribute values to
be added to the object.
- An OPTIONAL <brorg:rem> element that contains attribute values to
be removed from the object.
- An OPTIONAL <brorg:chg> element that contains attribute values to
be changed.
At least one <brorg:add>, <brorg:rem>, or <brorg:chg> element MUST be
provided. The <brorg:add> and <brorg:rem> elements contain the
following child element:
Neves & Kobayashi Expires February 24, 2007 [Page 13]
Internet-Draft EPP BR Organization Mapping August 2006
- One or more <brorg:contact> elements that contain identifiers for
human social information objects associated with the organization
object.
A <brorg:chg> element contains the following child element:
- A <brorg:responsible> element that contains the name of a person
responsible for the organization.
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: <contact:update
C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
C: contact-1.0.xsd">
C: <contact:id>e654321</contact:id>
C: </contact:update>
C: </update>
C: <extension>
C: <brorg:update
C: xmlns:brorg="urn:ietf:params:xml:ns:brorg-1.0"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:brorg-1.0
C: brorg-1.0.xsd">
C: <brorg:organization>
C: 005.506.560/0001-36
C: </brorg:organization>
C: <brorg:add>
C: <brorg:contact type="admin">hkk</brorg:contact>
C: </brorg:add>
C: <brorg:rem>
C: <brorg:contact type="admin">fan</brorg:contact>
C: </brorg:rem>
C: <brorg:chg>
C: <brorg:responsible>John Joe</brorg:responsible>
C: </brorg:chg>
C: </brorg:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Neves & Kobayashi Expires February 24, 2007 [Page 14]
Internet-Draft EPP BR Organization Mapping August 2006
When an extended <update> command has been processed successfully,
the EPP response is as described in the EPP contact mapping
[I-D.hollenbeck-epp-rfc3733bis].
3.3. Offline Review of Requested Actions
Commands are processed by a server in the order they are received
from a client. Though an immediate response confirming receipt and
processing of the command is produced by the server, a server
operator MAY perform an offline review of requested transform
commands before completing the requested action. In such situations,
the response from the server MUST clearly note that the transform
command has been received and processed, but the requested action is
pending. The status of the corresponding object MUST clearly reflect
processing of the pending action. The server MUST notify the client
when offline processing of the action has been completed.
An example describing a <create> command that requires offline review
is included here. Note the result code and message returned in
response to the <create> command.
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <response>
S: <result code="1001">
S: <msg>Command completed successfully; action pending</msg>
S: </result>
S: <resData>
S: <contact:creData
S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
S: contact-1.0.xsd">
S: <contact:id>e123456</contact:id>
S: <contact:crDate>2005-12-05T12:00:00.0Z</contact:crDate>
S: </contact:creData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
The status of the contact object after returning this response MUST
include "pendingCreate". The server operator reviews the request
Neves & Kobayashi Expires February 24, 2007 [Page 15]
Internet-Draft EPP BR Organization Mapping August 2006
offline, and informs the client of the outcome of the review by
either queuing a service message for retrieval via the <poll> command
or by using an out-of-band mechanism to inform the client of the
request.
In addition to the EPP elements described in the EPP contact mapping
[I-D.hollenbeck-epp-rfc3733bis], the <poll> command <response>
element MUST contain a child <extension> element. The <extension>
element MUST contain a child <brorg:panData> element that identifies
the extension namespace and the location of the extension schema.
The <brorg:panData> element contains the following child element:
- A <brorg:organization> element that contains the identifier of the
organization object.
- An OPTIONAL <brdomain:reason> element containing a human-readable
message that describes the reason for denying the request. The
language of the response is identified via an OPTIONAL "lang"
attribute. If not specified, the default attribute value MUST be
"en" (English).
Neves & Kobayashi Expires February 24, 2007 [Page 16]
Internet-Draft EPP BR Organization Mapping August 2006
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>2005-12-05T12:01:00.0Z</qDate>
S: <msg>Pending action completed successfully.</msg>
S: </msgQ>
S: <resData>
S: <contact:panData
S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:contact-1.0
S: contact-1.0.xsd">
S: <contact:id paResult="0">e123450</contact:id>
S: <contact:paTRID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </contact:paTRID>
S: <contact:paDate>2005-12-05T12:00:00.0Z</contact:paDate>
S: </contact:panData>
S: </resData>
S: <extension>
S: <brorg:panData
S: xmlns:brorg="urn:ietf:params:xml:ns:brorg-1.0"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:brorg-1.0
S: brorg-1.0.xsd">
S: <brorg:organization>
S: 004.857.383/6000-10
S: </brorg:organization>
S: <brorg:reason lang="pt">
S: Este documento nao existe na base de dados da SRF.
S: </brorg:reason>
S: </brorg:panData>
S: </extension>
S: <trID>
S: <clTRID>BCD-23456</clTRID>
S: <svTRID>65432-WXY</svTRID>
S: </trID>
S: </response>
S:</epp>
Neves & Kobayashi Expires February 24, 2007 [Page 17]
Internet-Draft EPP BR Organization Mapping August 2006
4. Formal Syntax
An EPP object mapping is specified in XML Schema notation. The
formal syntax presented here is a complete schema representation of
the object mapping suitable for automated validation of EPP XML
instances. The BEGIN and END tags are not part of the schema; they
are used to note the beginning and ending of the schema for URI
registration purposes.
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:brorg-1.0"
xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"
xmlns:brorg="urn:ietf:params:xml:ns:brorg-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:epp-1.0"
schemaLocation="epp-1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"
schemaLocation="eppcom-1.0.xsd"/>
<import namespace="urn:ietf:params:xml:ns:contact-1.0"
schemaLocation="contact-1.0.xsd"/>
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
domain name extension schema for .br domain provisioning.
</documentation>
</annotation>
<!--
Global elements
-->
<simpleType name="orgIDType">
<restriction base="token">
<minLength value="1"/>
<maxLength value="30"/>
</restriction>
</simpleType>
<complexType name="contactType">
Neves & Kobayashi Expires February 24, 2007 [Page 18]
Internet-Draft EPP BR Organization Mapping August 2006
<simpleContent>
<extension base="eppcom:clIDType">
<attribute name="type" type="brorg:contactAttrType"/>
</extension>
</simpleContent>
</complexType>
<simpleType name="contactAttrType">
<restriction base="token">
<enumeration value="admin"/>
<enumeration value="billing"/>
<enumeration value="member"/>
</restriction>
</simpleType>
<complexType name="mContactType">
<sequence>
<element name="contact" type="brorg:contactType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="chgType">
<sequence>
<element name="responsible" type="contact:postalLineType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="checkType">
<sequence>
<element name="id" type="eppcom:clIDType"/>
<element name="organization" type="brorg:orgIDType"/>
</sequence>
</complexType>
<complexType name="ticketInfoType">
<sequence>
<element name="organization" type="brorg:orgIDType"/>
<element name="ticketNumber" type="unsignedInt"/>
<element name="domainName" type="eppcom:labelType"/>
</sequence>
</complexType>
<!--
Child elements found in EPP commands.
-->
<element name="check" type="brorg:mIDType"/>
Neves & Kobayashi Expires February 24, 2007 [Page 19]
Internet-Draft EPP BR Organization Mapping August 2006
<element name="create" type="brorg:createType"/>
<element name="info" type="brorg:sIDType"/>
<element name="update" type="brorg:updateType"/>
<!--
Child elements of the <check> command.
-->
<complexType name="mIDType">
<sequence>
<element name="cd" type="brorg:checkType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<!--
Child elements of the <create> command.
-->
<complexType name="createType">
<sequence>
<element name="organization" type="brorg:orgIDType"/>
<element name="contact" type="brorg:contactType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="responsible" type="contact:postalLineType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Child elements of the <info> command.
-->
<complexType name="sIDType">
<sequence>
<element name="organization" type="brorg:orgIDType"/>
</sequence>
</complexType>
<!--
Child elements of the <update> command
-->
<complexType name="updateType">
<sequence>
<element name="organization" type="brorg:orgIDType"/>
<element name="add" type="brorg:mContactType"
minOccurs="0"/>
<element name="rem" type="brorg:mContactType"
minOccurs="0"/>
<element name="chg" type="brorg:chgType" minOccurs="0"/>
</sequence>
Neves & Kobayashi Expires February 24, 2007 [Page 20]
Internet-Draft EPP BR Organization Mapping August 2006
</complexType>
<!--
Child response elements.
-->
<element name="chkData" type="brorg:chkDataType"/>
<element name="infData" type="brorg:infDataType"/>
<element name="panData" type="brorg:panDataType"/>
<!--
<check> response elements.
-->
<complexType name="chkDataType">
<sequence>
<element name="ticketInfo" type="brorg:ticketInfoType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<!--
<info> response elements.
-->
<complexType name="infDataType">
<sequence>
<element name="organization" type="brorg:orgIDType"/>
<element name="contact" type="brorg:contactType"
maxOccurs="unbounded"/>
<element name="responsible" type="contact:postalLineType"
minOccurs="0"/>
<element name="proxy" type="brorg:orgIDType"
minOccurs="0"/>
<element name="domainName" type="eppcom:labelType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<!--
Pending action notification response elements
-->
<complexType name="panDataType">
<sequence>
<element name="organization" type="brorg:orgIDType"/>
<element name="reason" type="epp:msgType" minOccurs="0"/>
</sequence>
</complexType>
</schema>
END
Neves & Kobayashi Expires February 24, 2007 [Page 21]
Internet-Draft EPP BR Organization Mapping August 2006
5. Internationalization Considerations
EPP is represented in XML, which provides native support for encoding
information using the Unicode character set and its more compact
representations, including UTF-8 [RFC3629]. Conformant XML
processors recognize both UTF-8 and UTF-16 [RFC2781]. Though XML
includes provisions to identify and use other character encodings
through use of an "encoding" attribute in an <?xml?> declaration, use
of UTF-8 is RECOMMENDED in environments where parser encoding support
incompatibility exists.
As an extension of the EPP contact mapping [I-D.hollenbeck-epp-
rfc3733bis], the elements, element content, attributes, and attribute
values described in this document MUST inherit the
internationalization conventions used to represent higher-layer
domain and core protocol structures present in an XML instance that
includes this extension.
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 requested to IANA:
Registration request for the extension namespace:
URI: urn:ietf:params:xml:ns:brorg-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: None. Namespace URIs do not represent an XML specification.
Registration request for the extension XML schema:
URI: urn:ietf:params:xml:schema:brorg-1.0
Registrant Contact: See the "Author's Address" section of this
document.
XML: See the "Formal Syntax" section of this document.
7. Security Considerations
The mapping extensions described in this document do not provided any
security services beyond those described by EPP [I-D.hollenbeck-epp-
Neves & Kobayashi Expires February 24, 2007 [Page 22]
Internet-Draft EPP BR Organization Mapping August 2006
rfc3730bis], the EPP contact mapping [I-D.hollenbeck-epp-rfc3733bis],
and protocol layers used by EPP.
8. References
8.1. Normative References
[I-D.hollenbeck-epp-rfc3730bis]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
draft-hollenbeck-epp-rfc3730bis-02 (work in progress),
July 2006.
[I-D.hollenbeck-epp-rfc3733bis]
Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
Contact Mapping", draft-hollenbeck-epp-rfc3733bis-03 (work
in progress), August 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[W3C.REC-xml-20040204]
Maler, E., Paoli, J., Sperberg-McQueen, C., Bray, T., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
Edition)", World Wide Web Consortium Recommendation REC-
xml-20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204>.
[W3C.REC-xmlschema-1-20041028]
Thompson, H., Beech, D., Mendelsohn, N., and M. Maloney,
"XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028]
Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
Second Edition", World Wide Web Consortium
Recommendation REC-xmlschema-2-20041028, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
8.2. Informative References
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, February 2000.
Neves & Kobayashi Expires February 24, 2007 [Page 23]
Internet-Draft EPP BR Organization Mapping August 2006
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
Appendix A. Changes from version 02
1. Element responsible included in sections 3.1.2, 3.2.1, and 3.2.5
and in the formal syntax
2. Added extension elements to the <brorg:check> response in section
3.1.1 and in the formal syntax
Neves & Kobayashi Expires February 24, 2007 [Page 24]
Internet-Draft EPP BR Organization Mapping August 2006
Authors' Addresses
Frederico A. C. Neves
NIC.br / Registro.br
Av. das Nacoes Unidas, 11541, 7
Sao Paulo, SP 04578-000
BR
Phone: +55 11 5509 3511
Email: fneves@registro.br
URI: http://registro.br/
Hugo Koji Kobayashi
NIC.br / Registro.br
Av. das Nacoes Unidas, 11541, 7
Sao Paulo, SP 04578-000
BR
Phone: +55 11 5509 3511
Email: koji@registro.br
URI: http://registro.br/
Neves & Kobayashi Expires February 24, 2007 [Page 25]
Internet-Draft EPP BR Organization Mapping August 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Neves & Kobayashi Expires February 24, 2007 [Page 26]
