2.2. Generic message structure¶

This section describes the top-level syntax of the XML messages and explains how it relates to various message types.

All messages must begin with an XML prolog to:

identify the version of XML that is being used (1.0 or 1.1),
identify the character encoding of the message (optional), and
provide a hint to an XML parser that an external schema file is needed to validate the XML instance (optional).

Example of XML prolog¶

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

Note

UTF-8 is the recommended and default character encoding for use with EPP.

If the document requires an external definition (such as a schema) to be complete (for example to determine default values for absent optional attributes), then it is not standalone.

After the prolog, the root element follows and identifies the protocol and its version. This is always <epp> in the standard base EPP namespace (urn:ietf:params:xml:ns:epp-1.0) which must be declared at the <epp> element. See also Namespaces & schemas on how to enable client-side XML validation.

Example of the root element¶

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<epp
   xmlns="urn:ietf:params:xml:ns:epp-1.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">

   <!-- message content -->

</epp>

Note

It is customary in the FRED and in the examples of this publication to declare this namespace as the default namespace (the one which does not have a prefix).

A namespace can be used for the element, at which it was declared, and all its descendants and their attributes. More on the scoping of namespaces.

The singular child of the <epp> element determines the type of a message and it must be one of the following:

<hello> – service discovery request (contents and use described in Service discovery),
<greeting> – service discovery reply (contents and use described in Service discovery),
<command> – container for a standard EPP command (contents and use described in Commands & responses),
<response> – reply to a command (contents and use described in Commands & responses),
<extension> – protocol extension (non-standard request). The protocol extensions are described in FRED protocol extension.

Request-reply mapping of message types

The following table contains an illustration of relationships between the message types to clarify which types are requests sent by a client and which are replies sent by the server.

Service aspect	Request	Reply
Service discovery	`hello`	`greeting`
Commands	`command`	`response`
Protocol extensions	`extension`	`response` [1]