Extensible Provisioning Protocol (EPP) Contact Mapping
RFC 4933

"voice" type="contact:e164Type"
         minOccurs="0"/>
        <element name="fax" type="contact:e164Type"
         minOccurs="0"/>
        <element name="email" type="eppcom:minTokenType"/>
        <element name="authInfo" type="contact:authInfoType"/>
        <element name="disclose" type="contact:discloseType"
         minOccurs="0"/>
      </sequence>
    </complexType>

    <complexType name="postalInfoType">
      <sequence>
        <element name="name" type="contact:postalLineType"/>
        <element name="org" type="contact:optPostalLineType"
         minOccurs="0"/>
        <element name="addr" type="contact:addrType"/>
      </sequence>
      <attribute name="type" type="contact:postalInfoEnumType"
       use="required"/>
    </complexType>

Hollenbeck                  Standards Track                    [Page 31]
RFC 4933                  EPP Contact Mapping                   May 2007

    <simpleType name="postalInfoEnumType">
      <restriction base="token">
        <enumeration value="loc"/>
        <enumeration value="int"/>
      </restriction>
    </simpleType>

    <complexType name="addrType">
      <sequence>
        <element name="street" type="contact:optPostalLineType"
         minOccurs="0" maxOccurs="3"/>
        <element name="city" type="contact:postalLineType"/>
        <element name="sp" type="contact:optPostalLineType"
         minOccurs="0"/>
        <element name="pc" type="contact:pcType"
         minOccurs="0"/>
        <element name="cc" type="contact:ccType"/>
      </sequence>
    </complexType>

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

    <complexType name="discloseType">
      <sequence>
        <element name="name" type="contact:intLocType"
         minOccurs="0" maxOccurs="2"/>
        <element name="org" type="contact:intLocType"
         minOccurs="0" maxOccurs="2"/>
        <element name="addr" type="contact:intLocType"
         minOccurs="0" maxOccurs="2"/>
        <element name="voice" minOccurs="0"/>
        <element name="fax" minOccurs="0"/>
        <element name="email" minOccurs="0"/>
      </sequence>
      <attribute name="flag" type="boolean" use="required"/>
    </complexType>

    <complexType name="intLocType">
      <attribute name="type" type="contact:postalInfoEnumType"
       use="required"/>
    </complexType>

Hollenbeck                  Standards Track                    [Page 32]
RFC 4933                  EPP Contact Mapping                   May 2007

   <!--
   Child element of commands that require only an identifier.
   -->
    <complexType name="sIDType">
      <sequence>
        <element name="id" type="eppcom:clIDType"/>
      </sequence>
    </complexType>

   <!--
   Child element of commands that accept multiple identifiers.
   -->
    <complexType name="mIDType">
      <sequence>
        <element name="id" type="eppcom:clIDType"
         maxOccurs="unbounded"/>
      </sequence>
    </complexType>

   <!--
   Child elements of the <info> and <transfer> commands.
   -->
    <complexType name="authIDType">
      <sequence>
        <element name="id" type="eppcom:clIDType"/>
        <element name="authInfo" type="contact:authInfoType"
         minOccurs="0"/>
      </sequence>
    </complexType>

   <!--
   Child elements of the <update> command.
   -->
    <complexType name="updateType">
      <sequence>
        <element name="id" type="eppcom:clIDType"/>
        <element name="add" type="contact:addRemType"
         minOccurs="0"/>
        <element name="rem" type="contact:addRemType"
         minOccurs="0"/>
        <element name="chg" type="contact:chgType"
         minOccurs="0"/>
      </sequence>
    </complexType>

   <!--
   Data elements that can be added or removed.
   -->

Hollenbeck                  Standards Track                    [Page 33]
RFC 4933                  EPP Contact Mapping                   May 2007

    <complexType name="addRemType">
      <sequence>
        <element name="status" type="contact:statusType"
         maxOccurs="7"/>
      </sequence>
    </complexType>

   <!--
   Data elements that can be changed.
   -->
    <complexType name="chgType">
      <sequence>
        <element name="postalInfo" type="contact:chgPostalInfoType"
         minOccurs="0" maxOccurs="2"/>
        <element name="voice" type="contact:e164Type"
         minOccurs="0"/>
        <element name="fax" type="contact:e164Type"
         minOccurs="0"/>
        <element name="email" type="eppcom:minTokenType"
         minOccurs="0"/>
        <element name="authInfo" type="contact:authInfoType"
         minOccurs="0"/>
        <element name="disclose" type="contact:discloseType"
         minOccurs="0"/>
      </sequence>
    </complexType>

    <complexType name="chgPostalInfoType">
      <sequence>
        <element name="name" type="contact:postalLineType"
         minOccurs="0"/>
        <element name="org" type="contact:optPostalLineType"
         minOccurs="0"/>
        <element name="addr" type="contact:addrType"
         minOccurs="0"/>
      </sequence>
      <attribute name="type" type="contact:postalInfoEnumType"
       use="required"/>
    </complexType>

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

Hollenbeck                  Standards Track                    [Page 34]
RFC 4933                  EPP Contact Mapping                   May 2007

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

    <complexType name="checkType">
      <sequence>
        <element name="id" type="contact:checkIDType"/>
        <element name="reason" type="eppcom:reasonType"
         minOccurs="0"/>
      </sequence>
    </complexType>

    <complexType name="checkIDType">
      <simpleContent>
        <extension base="eppcom:clIDType">
          <attribute name="avail" type="boolean"
           use="required"/>
        </extension>
      </simpleContent>
    </complexType>

   <!--
   <create> response elements.
   -->
    <complexType name="creDataType">
      <sequence>
        <element name="id" type="eppcom:clIDType"/>
        <element name="crDate" type="dateTime"/>
      </sequence>
    </complexType>

   <!--
   <info> response elements.
   -->
    <complexType name="infDataType">
      <sequence>
        <element name="id" type="eppcom:clIDType"/>
        <element name="roid" type="eppcom:roidType"/>
        <element name="status" type="contact:statusType"
         maxOccurs="7"/>
        <element name="postalInfo" type="contact:postalInfoType"
         maxOccurs="2"/>

Hollenbeck                  Standards Track                    [Page 35]
RFC 4933                  EPP Contact Mapping                   May 2007

        <element name="voice" type="contact:e164Type"
         minOccurs="0"/>
        <element name="fax" type="contact:e164Type"
         minOccurs="0"/>
        <element name="email" type="eppcom:minTokenType"/>
        <element name="clID" type="eppcom:clIDType"/>
        <element name="crID" type="eppcom:clIDType"/>
        <element name="crDate" type="dateTime"/>
        <element name="upID" type="eppcom:clIDType"
         minOccurs="0"/>
        <element name="upDate" type="dateTime"
         minOccurs="0"/>
        <element name="trDate" type="dateTime"
         minOccurs="0"/>
        <element name="authInfo" type="contact:authInfoType"
         minOccurs="0"/>
        <element name="disclose" type="contact:discloseType"
         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="contact:statusValueType"
           use="required"/>
          <attribute name="lang" type="language"
           default="en"/>
        </extension>
      </simpleContent>
    </complexType>

    <simpleType name="statusValueType">
      <restriction base="token">
        <enumeration value="clientDeleteProhibited"/>
        <enumeration value="clientTransferProhibited"/>
        <enumeration value="clientUpdateProhibited"/>
        <enumeration value="linked"/>
        <enumeration value="ok"/>
        <enumeration value="pendingCreate"/>
        <enumeration value="pendingDelete"/>
        <enumeration value="pendingTransfer"/>
        <enumeration value="pendingUpdate"/>
        <enumeration value="serverDeleteProhibited"/>

Hollenbeck                  Standards Track                    [Page 36]
RFC 4933                  EPP Contact Mapping                   May 2007

        <enumeration value="serverTransferProhibited"/>
        <enumeration value="serverUpdateProhibited"/>
      </restriction>
    </simpleType>

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

    <complexType name="paCLIDType">
      <simpleContent>
        <extension base="eppcom:clIDType">
          <attribute name="paResult" type="boolean"
           use="required"/>
        </extension>
      </simpleContent>
    </complexType>

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

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

Hollenbeck                  Standards Track                    [Page 37]
RFC 4933                  EPP Contact Mapping                   May 2007

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
   REQUIRED with this specification.

   All date-time values presented via EPP MUST be expressed in Universal
   Coordinated Time using the Gregorian calendar.  The 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
   [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
   values as the XML Schema does not support truncated date-time forms
   or lower case "T" and "Z" characters.

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

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.

   Registration request for the contact namespace:

   URI: urn:ietf:params:xml:ns:contact-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 contact XML schema:

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

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

Hollenbeck                  Standards Track                    [Page 38]
RFC 4933                  EPP Contact Mapping                   May 2007

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

7.  Security Considerations

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

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

8.  Acknowledgements

   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.

   Specific suggestions that have been incorporated into this document
   were provided by Chris Bason, Eric Brunner-Williams, Jordyn Buchanan,
   Robert Burbidge, Dave Crocker, Ayesha Damaraju, Anthony Eden, Sheer
   El-Showk, Dipankar Ghosh, Klaus Malorny, Dan Manley, Michael
   Mealling, Patrick Mevzek, Asbjorn Steira, and Rick Wesson.

9.  References

9.1.  Normative References

   [ISO.3166.1997]
              International Organization for Standardization, "Codes for
              the representation of names of countries and their
              subdivisions -- Part 1: Country codes", ISO Standard 3166,
              October 1997.

   [ITU.E164.2005]
              International Telecommunication Union, "The international
              public telecommunication numbering plan", ITU-
              T Recommendation E.164, February 2005.

Hollenbeck                  Standards Track                    [Page 39]
RFC 4933                  EPP Contact Mapping                   May 2007

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

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

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

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

   [RFC4930]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
              RFC 4930, May 2007.

   [W3C.REC-xml-20040204]
              Yergeau, F., Maler, E., Sperberg-McQueen, C., Bray, T.,
              and J. Paoli, "Extensible Markup Language (XML) 1.0 (Third
              Edition)", World Wide Web Consortium FirstEdition REC-xml-
              20040204, February 2004,
              <http://www.w3.org/TR/2004/REC-xml-20040204>.

   [W3C.REC-xmlschema-1-20041028]
              Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech,
              "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>.

9.2.  Informative References

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

   [RFC3733]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
              Contact Mapping", RFC 3733, March 2004.

Hollenbeck                  Standards Track                    [Page 40]
RFC 4933                  EPP Contact Mapping                   May 2007

Appendix A.  Changes from RFC 3733

   1.   Minor reformatting as a result of converting I-D source format
        from nroff to XML.

   2.   Removed this text from Section 2.2:

        "With one exception, transform commands MUST be rejected when a
        pendingCreate, pendingDelete, 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."

   3.   Fixed examples in Section 2.9 (added missing "/" characters).

   4.   Changed text in Section 3.1.3 from "A <contact:acID> element
        that contains the identifier of the client that SHOULD act upon
        the transfer request" to "A <contact:acID> element that contains
        the identifier of the client that SHOULD act upon a PENDING
        transfer request.  For all other status types, the value
        identifies the client that took the indicated action".

   5.   Fixed the example response in Section 3.2.4 to use the correct
        response code and response text.

   6.   Changed text in Section 3.2.5 from "At least one <contact:add>,
        <contact:rem>, or <contact:chg> element MUST be provided." to
        "At least one <contact:add>, <contact:rem>, or <contact:chg>
        element MUST be provided if the command is not being extended.
        All of these elements MAY be omitted if an <update> extension is
        present."

   7.   Changed text in Section 3.3 (old Section 3.2.6) from this:

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

        to this:

        "The server operator reviews the request offline, and informs
        the client of the outcome of the review either by 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."

   8.   Removed text describing use of the XML Schema schemaLocation
        attribute.  This is an optional attribute that doesn't need to
        be mandated for use in EPP.

Hollenbeck                  Standards Track                    [Page 41]
RFC 4933                  EPP Contact Mapping                   May 2007

   9.   Updated text describing a requirement to use UTF-8 encoding in
        the "Internationalization Considerations" section.

   10.  Removed references to RFC 3339 and replaced them with references
        to the W3C XML Schema specification.

   11.  Updated the E.164 reference.

   12.  Updated EPP and XML references.  Updated reference from RFC 2279
        to RFC 3629.

Author's Address

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

   EMail: shollenbeck@verisign.com

Hollenbeck                  Standards Track                    [Page 42]
RFC 4933                  EPP Contact Mapping                   May 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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.

   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, THE IETF TRUST 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.

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.

   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.

Acknowledgement

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

Hollenbeck                  Standards Track                    [Page 43]