System for Managing a Shared Domain Registry
draft-nzrs-srs-01

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 June 3, 2009.

Abstract

This document describes the typical usage and communication protocol of a client/server shared registry system for management of domain name registrations. The system described is a "thick registry" system, providing support for the storage and management of both the technical and the registrant contact information concerning domain registrations. The system relies on the existing HTTP and HTTPS infrastructure for transport and secure transfer to avoid having to implement a dedicated protocol and server environment. A bespoke XML format is used to communicate between clients and the SRS server.

Comments are solicited and should be addressed to the mailing list at srsstandards-l@nzrs.net.nz and/or the author. The mailing list management page can be found at https://mailman.nzrs.net.nz/cgi-bin/mailman/listinfo/srsstandards-l.

Table of Contents

1.  Introduction
2.  Conventions used in this Document
    2.1.  Terminology
3.  System Description
    3.1.  The Public
    3.2.  Registrars
    3.3.  The Registry
    3.4.  The Domain Registration Cycle
        3.4.1.  Registration Grace Period
        3.4.2.  Renewal Grace Period
        3.4.3.  Auto-renew Grace Period
        3.4.4.  Redemption Grace Period
4.  Authentication, Security and Authorization
    4.1.  Authentication
    4.2.  Security
    4.3.  Authorization
5.  Communication
    5.1.  Request Format
    5.2.  Response Format
        5.2.1.  Response
        5.2.2.  Error
6.  SRS Requests
    6.1.  Domain Query Actions
        6.1.1.  ActionDetailsQry
        6.1.2.  DomainDetailsQry
        6.1.3.  UDAIValidQry
        6.1.4.  Whois
    6.2.  Domain Write Actions
        6.2.1.  DomainCreate
        6.2.2.  DomainUpdate
    6.3.  Registrar Query Actions
        6.3.1.  GetMessages
        6.3.2.  RegistrarAccountQry
        6.3.3.  RegistrarDetailsQry
    6.4.  Registrar Write Actions
        6.4.1.  RegistrarUpdate
    6.5.  Registry Actions
        6.5.1.  AccessControlListAdd
        6.5.2.  AccessControlListQry
        6.5.3.  AccessControlListRemove
        6.5.4.  AdjustRegistrarAccount
        6.5.5.  BilledUntilAdjustment
        6.5.6.  BillingExtract
        6.5.7.  BuildDnsZoneFiles
        6.5.8.  DeferredIncomeDetailQry
        6.5.9.  DeferredIncomeSummaryQry
        6.5.10.  GenerateDomainReport
        6.5.11.  QryBillingAmount
        6.5.12.  RegistrarCreate
        6.5.13.  RunLogCreate
        6.5.14.  RunLogQry
        6.5.15.  ScheduleCancel
        6.5.16.  ScheduleCreate
        6.5.17.  ScheduleQry
        6.5.18.  ScheduleUpdate
        6.5.19.  SetBillingAmount
        6.5.20.  SysParamsQry
        6.5.21.  SysParamsUpdate
7.  SRS Response Types
    7.1.  AccessControlList
    7.2.  BillingAmount
    7.3.  BillingTrans
    7.4.  DeferredRegistrarIncome
    7.5.  Domain
    7.6.  DomainTransfer
    7.7.  Error
    7.8.  RawRequest and RawResponse
    7.9.  Registrar
    7.10.  RunLog
    7.11.  Schedule
    7.12.  SysParam
    7.13.  UDAIValid
8.  Information Elements
    8.1.  AccessControlListEntry
    8.2.  ActionIdFilter
    8.3.  Allowed2LDs
    8.4.  AuditDetails
    8.5.  AuditText
    8.6.  AuditTextFilter
    8.7.  CancelAuditText
    8.8.  BaseMonth
    8.9.  BaseYear
    8.10.  Contact Details Elements
    8.11.  Contact Details Search Filters
    8.12.  CreateAuditText
    8.13.  Date Range Elements
    8.14.  Description
    8.15.  DomainNameFilter
    8.16.  EncryptKey
    8.17.  EncryptKeys
    8.18.  ErrorDetails
    8.19.  FieldList
    8.20.  IncomeMonth
    8.21.  IncomeYear
    8.22.  NameServers
    8.23.  NameServerFilter
    8.24.  ParamValue
    8.25.  PostalAddress
    8.26.  PostalAddressFilter
    8.27.  Telephone Number Details
    8.28.  Role
    8.29.  Roles
    8.30.  RunLogDetails
    8.31.  SecondLD
    8.32.  Server
    8.33.  ServerFilter
    8.34.  Signature
    8.35.  Timestamp Elements
    8.36.  TransferredDomain
    8.37.  XML
9.  Internal Entities
    9.1.  Actions
        9.1.1.  DomainWriteAction
        9.1.2.  DomainQueryAction
        9.1.3.  RegistrarWriteAction
        9.1.4.  RegistrarQueryAction
        9.1.5.  RegistryAction
        9.1.6.  Action
    9.2.  Accounts
        9.2.1.  AccountingAction
        9.2.2.  BillStatus
    9.3.  Booleans
        9.3.1.  True
        9.3.2.  False
        9.3.3.  Boolean
    9.4.  Contact Details
        9.4.1.  Contact
        9.4.2.  ContactAttr
    9.5.  Contact Details Filters
        9.5.1.  ContactFilter
        9.5.2.  ContactFilterAttr
    9.6.  Currency
        9.6.1.  Dollars
    9.7.  Dates And Times
        9.7.1.  Date
        9.7.2.  Time
        9.7.3.  TimeStamp
        9.7.4.  DateRange
    9.8.  Domain Names
        9.8.1.  DomainName
    9.9.  Domain Status
        9.9.1.  RegDomainStatus
        9.9.2.  DomainStatus
    9.10.  Duration
        9.10.1.  Term
    9.11.  Numeric
        9.11.1.  Number
    9.12.  Registrar Identifiers
        9.12.1.  RegistrarId
        9.12.2.  RegistrarIdOrOTHERS
    9.13.  Responses
        9.13.1.  ActionResponse
    9.14.  System Roles
        9.14.1.  Role
    9.15.  Scheduled Processes
        9.15.1.  ScheduledJob
    9.16.  Telephone Numbers
        9.16.1.  PhoneAttr
    9.17.  Unique Identifiers
        9.17.1.  UID
10.  Text Filter
11.  Security Considerations
12.  IANA Considerations
13.  References
    13.1.  Normative References
    13.2.  Informative References
Appendix A.  Example
    A.1.  Whois request
Appendix B.  Acknowledgements
Appendix C.  DTD
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

This document describes the Shared Registry System (SRS), a system for managing a shared domain name registry. This system broadly satisfies the requirements for a generic registry-registrar protocol as defined in RFC 3375 (Hollenbeck, S., “Generic Registry-Registrar Protocol Requirements,” September 2002.) [RFC3375]. As this system only addresses the issue of managing a shared registry service and uses HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] as its transport layer, implementations are expected to be relatively easy.

This document also describes the communication protocol used by the SRS system. This protocol uses messages in an XML format for system requests and responses. The DTD for the SRS protocol is provided in its entirety as an appendix (DTD) to this document, and individual parts of the protocol are covered in depth throughout the document.

The SRS works in a connection-oriented fashion with no session state. The registrar sends a request document to the registry containing commands to be executed by the SRS and the result of processing these commands is returned as the response. Each registrar request document receives a response document containing the result of processing all of the requests in a single request document.

Public Key Infrastructure (PKI) is used to manage issues of security, authentication of requests and non-repudiation of actions. Exchange of keys between the registry and registrars is outside the scope of this document.

A system built using this protocol is used by .nz Registry Services (NZRS) and a sample implementation consisting of client and server software is available from the Sourceforge web site.

2.  Conventions used in this Document

The definitions of Registry, Registrar, and Registrant from RFC 3375 (Hollenbeck, S., “Generic Registry-Registrar Protocol Requirements,” September 2002.) [RFC3375] are used in this document and are included below.

SRS:

a software implementation of the shared registry system described here.

Registry:

An entity that provides back-end domain name registration services to registrars, managing a central repository of information associated with domain name delegations. A registry is typically responsible for publication and distribution of zone files used by the Domain Name System.

Registrar:

An entity that provides front-end domain name registration services to registrants, providing a public interface to registry services.

Registrant:

An entity that registers domain names in a registry through the services provided by a registrar. Registrants include individuals, organizations, and corporations.

UDAI:

The Unique Domain Authentication Identifier (UDAI) is a domain code that is generated by the SRS and stored by the registrar and registrant to restrict updates to domain details. The value of the UDAI is not stored within the SRS, but a message digest of the value is kept to check the integrity of domain update and transfer requests. The UDAI SHOULD be an ASCII (American National Standards Institute, “Coded Character Set - 7-bit American Standard Code for Information Interchange,” 1968.) [US‑ASCII] encoded character string.

2.1.  Terminology

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 RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

3.  System Description

The SRS provides the functions required to support all of the usual business functions of a domain registration service, including:

• creation, maintenance, querying and deletion of domain details
• querying of public details of a domain - to support a public WHOIS service
• transfer of domains between registrars
• creation, maintenance, querying and deletion of registrar details
• regular zone file creation for domains delegated to appear in the domain name system (DNS)
• registrar account query, maintenance, and message polling
• creation and cancellation of scheduled jobs in the SRS to support business functions (such as building zone files and releasing and renewing domains)
• management and configuration of the SRS by the registry
• billing and accounting functions to work with the registry's accounting system

Direct and indirect interactions with the SRS may be split into three main groups:

• the public (including registrants),
• registrars,
• and the registry.

Their interactions with the SRS are summarized below.

                  +-----------+
                  |  Public/  |
                  |registrants|
                  |           |                   Public
                  +-----------+
                    ^   ^   ^
              WHOIS |   |   | DNS queries
      +-------------+   |   +-------------+
      |                 v                 |
      |           +-----------+           |
      |           |Registrar  |           |
      |           |service    |           |
      |           |           |           |       Registrars
      |           +-----------+           |
      |                 ^                 |
      |                 | HTTP/HTTPS      |
      |                 | (SRS protocol)  |
      v                 v                 v
+-----------+     +-----------+     +-----------+
|Whois      |     |SRS        |     |DNS        |
|server     |<--->|           |---->|           |
|           |     |           |     |           | Registry
+-----------+     +-----------+     +-----------+

3.1.  The Public

The public (and registrants - the domain registering public) have no direct access to the SRS server. They interact with the system through:

• querying domain ownership details in the public WHOIS system,
• performing hostname lookups to access services hosted on the internet,
• registering domains by establishing a business relationship with a registrar,
• transferring their registered domains between registrars,
• and maintaining their own domain details through systems provided by a registrar.

3.2.  Registrars

Registrars generate most of the work that the SRS server handles. They are expected to maintain their own registrar details within the SRS as an aspect of their business relationship with the registry. They also offer services to the public, or a restricted section of the public, to manage domain registrations. These public services are likely to include:

• checking availability of domain names,
• registering domain names,
• transferring domain names from another registrar,
• cancelling domain registrations,
• billing for domain registrations,
• and providing a service to allow registrants to maintaining domain details.

In addition to their customer services, registrars are expected to regularly poll the SRS server using the GetMessages (GetMessages) request, to retrieve details of actions relevant to their business with the registry that they have not initiated directly (for instance, registrant-initiated transfers of domains from them to another registrar, and actions performed by the registry on their behalf).

3.3.  The Registry

Generally the registry will be responsible for maintaining all of the information associated with domain name registrations (including both the technical information required to produce zone files and the contact information for registrars and registrants), running the SRS service to support registrars' and its own maintenance of domains, running a public WHOIS service compliant with RFC 3912 (Daigle, L., “WHOIS Protocol Specification,” September 2004.) [RFC3912], regular backups, data security, and running name servers for their domains.

By running a "thick registry" system, the registry provides security, stability and backup of the registry information, and ensures that registrants are protected against registrar failures.

The information for the public WHOIS service and the name server zone files is derived from the data held in the SRS server. Most registered domains will be delegated to other nameservers.

3.4.  The Domain Registration Cycle

Registrants may register domains through registrars according to the limitations of the available subdomains allowed by the registry, and any policy decisions that the registry applies to domain naming.

Registries are encouraged to apply a system of grace periods to the registration cycle of domains once they have initially been registered. The .nz Registry Service applies the following grace periods:

• registration grace period
• renewal grace period
• auto-renew grace period
• redemption grace period

Each grace period exists for a specific period of time that is typically measured in days. The duration of each grace period is a matter of registry operational policy that is not addressed in this document.

3.4.1.  Registration Grace Period

The registration grace period applies after the initial registration of a domain name. If the domain name is cancelled by the registrar during this period, all registrar account transactions (billing) for the domain will also be cancelled. The domain name is released back to the available pool of names. A registrant may not transfer the management of a domain to another registrar during this period.

The registry MAY restrict domain cancellations in this term to prevent a single registrar from cancelling a particular domain more than once during the registration grace period.

3.4.2.  Renewal Grace Period

The renewal grace period applies after a domain name registration period is explicitly extended (renewed) by the registrar. If the domain name is cancelled by the registrar during this period, the registrar account transaction for the renewal will also be cancelled and the BilledUntil date of the domain rolled back to the previous value.

3.4.3.  Auto-renew Grace Period

The auto-renew grace period applies after a domain name registration period expires and is extended (renewed) automatically by the registry. If the domain name is cancelled by the registrar during this period, the registrar account transaction for the renewal will also be cancelled and the BilledUntil date of the domain rolled back to the previous value.

3.4.4.  Redemption Grace Period

The redemption grace period applies after a domain registration is cancelled by a registrant. It defines the length of time that a domain will stay in the cancelled state ("PendingRelease" status). After this time expires, the registry will release the domain name back to the available pool of names.

4.  Authentication, Security and Authorization

4.1.  Authentication

A two factor authentication system is used to establish the identity of the user that makes a request:

• A unique numeric identifier issued to each registrar by the registry
• An OpenPGP-compatible signature of the request body

Registrars are issued with a unique numeric identifier when their account is first created in the SRS. This registrar identifier MUST be included on client requests to allow the SRS server to identify the client. Failure to provide a correct identifier as part of the request SHALL result in the SRS server returning an error response.

The registrar must also maintain at least one public, private OpenPGP-compatible key pair for authentication. One or more public keys are provided to the registry when the registrar account is first created and the registrar MUST sign requests using one of its registered private keys. This information is used for authentication and to ensure non-repudiation of requests. The registrar may provide multiple public keys to ease the process of expiring old or revoked keys without interrupting the work of the registrar.

If a request does not have a signature, or the signature does not confirm that the identity of the registrar that signed the request matches the registrar identifier attached to the request, then the SRS server SHALL return an error response.

Responses from the SRS server MUST also be signed. Responses are signed by the registry using the registry's private key. The registry public key MUST be made easily available to registrars to allow authentication of response messages. This ensures that registrars can be confident that the responses to their requests are authentic, and have not been altered in transit.

4.2.  Security

The request and response signature mechanism provides a means of ensuring that messages have not been tampered with in transit. In addition to this, all requests for private data (data that cannot be retrieved using the public WHOIS system) MUST use an encrypted HTTP connection (HTTPS) for data security. If a request for private data is received via an unencrypted HTTP connection, the SRS server SHALL return an error response.

Only the Whois (Whois) request may be issued over an unencrypted HTTP connection.

4.3.  Authorization

SRS implementations SHOULD impose a permissions model to restrict the SRS requests that users are allowed to access. Action and role types are defined in the protocol definition for this purpose. If the originating user does not possess all of the permissions required to complete a request, the server SHOULD reject the transaction.

Transactions sent to the server MUST identify the registrar making the request. Registrars SHALL NOT be permitted to perform functions using an effective registrar other than their own. Any such requests received by the registry SHALL be rejected.

The registry SHOULD only access the SRS server through the same interface provided to registrars and SHOULD have one or more well-known registrar identifiers allocated to itself for the purpose of maintaining the registry. No changes should be made to public or private data in the SRS using other means of access that the registry may have available (for example, direct access to a database store).

The registry MAY perform SRS functions using an arbitrary effective registrar value.

Registrants and the public have no direct access to the SRS.

5.  Communication

All communication with the SRS is performed using XML (Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, “Extensible Markup Language (XML) 1.0 (2nd ed),” October 2000.) [W3C.REC‑xml] documents encoded in UTF-8 (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) [RFC3629] and sent using HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) [RFC2616] or HTTPS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818]. The request body MAY contain multiple independent requests to be performed on the SRS. The response MAY include a response to each request in the XML document, or a single error response. The SRS SHOULD process the requests in the order that they are received in the request body.

The user should ensure that:

• requests in an XML document are ordered logically to prevent errors due to sequencing (for example, attempting to update a domain record before creating it)
• the number of requests per XML document is limited to ensure acceptable processing time and response size

Both request and response messages MUST be accompanied by a digital signature of the complete XML request body (the value of the r parameter to the HTTP messages detailed below). The digital signature authentication method follows the specification in section 2.2 of OpenPGP Message Format (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.) [RFC4880] and MUST be encoded in ASCII Armor (see section 6.2 of [RFC4880] (Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, “OpenPGP Message Format,” November 2007.)) for inclusion in the HTTP request. The SRS protocol is a signature-only application of OpenPGP.

SRS implementations MAY define a limit on the response size to support service level agreements on response time. SRS implementations MAY reject requests in an XML document if they would otherwise exceed a defined limit on the response size or response time.

The VerMajor and VerMinor attributes are required in the first element of each request and response to allow clients and servers to modify their behaviour dependent on the version of the protocol that they support. The meaning of the two fields is:

VerMajor:

Major version number of the protocol. This number only changes when major changes are made to the system that are not backward compatible with previous versions; for example, client/server interface changes (changes to the protocol DTD).

VerMinor:

Minor version number of the protocol. This number changes for minor updates to the protocol that are backward compatible with previous versions with the same major version number.

An SRS server MUST reject any request made with a major version number that is greater than the SRS server's own supported version. SRS server implementations MAY support requests made with a major version number that is less than the SRS server's own supported version.

5.1.  Request Format

Requests MUST include three parameters in the HTTP POST request:

The XML request document MUST be formatted using the NZSRSRequest element. The NZSRSRequest element MAY contain one or more requests. Valid requests names are defined by the Action (Action) entity.

Syntax:

<!ELEMENT NZSRSRequest ((%Action;)+)>
<!ATTLIST NZSRSRequest
        VerMajor    (1|2)         #REQUIRED
        VerMinor    %Number;      #REQUIRED
        RegistrarId %RegistrarId; #IMPLIED>

Example of a request body prior to encoding:

n=50041&r=
<NZSRSRequest VerMajor="2" VerMinor="47" RegistrarId="50041">
    <Whois DomainName="example.org" />
</NZSRSRequest>&s=-----BEGIN PGP SIGNATURE-----...

5.2.  Response Format

The body of the SRS server response MUST include two parameters:

The XML response document MUST be formatted using the NZSRSResponse element. The NZSRSResponse element MAY contain one or more Response (Response) elements or an Error (Error) element.

Syntax:

<!ELEMENT NZSRSResponse (Response+|Error)>
<!ATTLIST NZSRSResponse
        VerMajor    (2)           #REQUIRED
        VerMinor    %Number;      #REQUIRED
        RegistrarId %RegistrarId; #IMPLIED>

Example of a decoded response message:

r=<?xml version="1.0" encoding="utf-8"?>
<NZSRSResponse VerMajor="2" VerMinor="47" RegistrarId="50041">
    <Response Action="Whois" FeId="4" FeSeq="137"
      OrigRegistrarId="50041" RecipientRegistrarId="50041" Rows="1">
        <FeTimeStamp Year="2007" Month="10" Day="19" Hour="14"
           Minute="7" Second="51" TimeZoneOffset="+13:00" />
        <Domain DomainName="example.org">...</Domain>
    </Response>
</NZSRSResponse>&s=-----BEGIN PGP SIGNATURE-----...

5.2.1.  Response

The response element acts as a container for all response types, including errors to individual requests in an XML document. If an error is encountered in parsing the request, or the client specified a major protocol version higher than that supported by the server, the SRS server MUST return the Error (Error) element with no Response container.

The response element may contain any of the following:

• multiple responses in response to a GetMessages (GetMessages) request, or
• a single action response (ActionResponse) specific to the type of action request.

The Response element must specify:

The Response element may also specify:

The Response element MUST contain an FeTimeStamp (Timestamp Elements) element, which shows the time and date that the request was processed by the SRS server, and also MAY contain one of the SRS response types (SRS Response Types).

Syntax:

<!ELEMENT Response (FeTimeStamp,
                    (Response*|%ActionResponse;)?
                   )>
<!ATTLIST Response
        Action (%Action;|UnknownTransaction|DomainTransfer) #REQUIRED
        FeId                 %Number;      #REQUIRED
        FeSeq                %Number;      #REQUIRED
        OrigRegistrarId      %RegistrarId; #REQUIRED
        TransId              %UID;         #IMPLIED
        Rows                 %Number;      #IMPLIED
        Count                %Number;      #IMPLIED
        MoreRowsAvailable    %Boolean;     #IMPLIED
        RecipientRegistrarId %RegistrarId; #IMPLIED>

5.2.2.  Error

An Error response may be returned for a whole request - for instance, when the request body failed validation or incorrect authentication was provided - or for one or more requests from the XML document body. In either case, the Error element will be used.

This document does not specify the error codes and situations. All SRS server errors SHOULD be treated as a failed request by the client and the SRS server MUST NOT change any stored details if it returns an error to the client request.

6.  SRS Requests

The SRS defines request elements that support the running of the shared domain registry from both a technical and a business perspective. Implementations SHOULD ensure that access to requests and data is restricted to comply with legal obligations and the registry's own business requirements.

To support the implementation of a flexible permissions model for SRS users, the requests are grouped into five major categories:

Domain query:

requests that allow users to query domain related information stored in the SRS

Domain write:

requests that allow users to create and update domain related information in the SRS

Registrar query:

requests that allow users to query registrar related information stored in the SRS

Registrar write:

requests that allow users to create and update registrar related information in the SRS

Registry:

requests that support registry business functions, SRS system settings, running jobs on the SRS, and billing functions

Typically, registrars will have access to the domain query, domain write and registrar query requests, as well as the ability to maintain their own registrar information within the SRS. Administrative users will be able to create registrars and run registry requests - normally this will be restricted to the registry itself.

All requests that result in an update to data held by the SRS server MUST provide an ActionId to identify the request. The combination of RegistrarId and ActionId for a request MUST be unique. This allows requests to be fully identified by the user that made the request and the ActionId that the user assigned to it. SRS server implementations SHOULD maintain a full audit trail by logging all update requests and their outcomes.

If the SRS server receives a request with the same RegistrarId and ActionId as a previous request, but different request details, it MUST return an Error (Error) response. If the SRS server receives a request with the same RegistrarId and ActionId as a previous request, and identical request details, it MUST respond by returning the response that was sent to the original request.

6.1.  Domain Query Actions

The domain query requests are:

6.1.1.  ActionDetailsQry

The ActionDetailsQry request allows the user to retrieve the original XML document and signature for a previous request to the SRS, and also the XML document and signature for the response that was returned. The user must supply the correct ActionId of the original request. Registrars SHOULD be restricted to only retrieving the details of requests that they were the originating registrar for.

6.1.1.1.  Request

The ActionDetailsQry request is an empty element that must specify:

Additionally, the request may specify:

Syntax:

<!ELEMENT ActionDetailsQry EMPTY>
<!ATTLIST ActionDetailsQry
        QryId                  %UID; #IMPLIED
        ActionId               %UID; #REQUIRED
        OriginatingRegistrarId %UID; #IMPLIED>

6.1.1.2.  Response

The response to an ActionDetailsQry request will be either an Error (Error) element or a RawRequest and a RawResponse (RawRequest and RawResponse) element containing the XML and the registrar signature of the original request and response. If a QryId was provided in the request, it is returned in the TransId attribute of the Response element.

6.1.2.  DomainDetailsQry

The DomainDetailsQry request allows the user to retrieve the stored details (including details that will not be shown for a public WHOIS query) for one or more domains. The request can be used to view historical details for a domain and may return a full update history for a domain.

Registrars are expected to only request information on domains that they currently manage. SRS implementations SHOULD restrict access to non-public domain information to the managing registrar. If historical data is requested for a period when the registrar did not manage a particular domain - for example, in the case of domain transfers - then only the public details as returned by the Whois (Whois) request shall be returned for this time.

6.1.2.1.  Request

The DomainDetailsQry request may specify:

For the optional Status, Delegate, Term, and RegistrantRef filters, if the attribute is not specified, then the results will not be filtered on these fields.

The request may also include elements to specify other filters to limit the results returned by the SRS server and to change the list of fields that are returned in the results. All of the filters are optional and, with the exception of the DomainNameFilter, may only occur once in the request. The DomainNameFilter may occur multiple times in the request and details of domains that match any of the provided filters will be returned in the results.

The elements that can be included in the DomainDetailsQry request are:

• DomainNameFilter (DomainNameFilter)
• NameServerFilter (NameServerFilter)
• RegistrantContactFilter (Contact Details Search Filters)
• AdminContactFilter (Contact Details Search Filters)
• TechnicalContactFilter (Contact Details Search Filters)
• ResultDateRange (Date Range Elements)
• SearchDateRange (Date Range Elements)
• ChangedInDateRange (Date Range Elements)
• RegisteredDateRange (Date Range Elements)
• LockedDateRange (Date Range Elements)
• CancelledDateRange (Date Range Elements)
• BilledUntilDateRange (Date Range Elements)
• AuditTextFilter (AuditTextFilter)
• ActionIdFilter (ActionIdFilter)
• FieldList (FieldList)

The FieldList element specifies the fields to be returned for each domain in the result set. If no FieldList is specified, the SRS server will only return the DomainName and Status for each domain.

Syntax:

<!ELEMENT DomainDetailsQry (DomainNameFilter*,NameServerFilter?,
                           RegistrantContactFilter?,
                           AdminContactFilter?,
                           TechnicalContactFilter?,
                           ResultDateRange?,SearchDateRange?,
                           ChangedInDateRange?,
                           RegisteredDateRange?,LockedDateRange?,
                           CancelledDateRange?,
                           BilledUntilDateRange?,
                           AuditTextFilter?,ActionIdFilter?,
                           FieldList?)>
<!ATTLIST DomainDetailsQry
        QryId         %UID;               #IMPLIED
        Status        (%RegDomainStatus;) #IMPLIED
        Delegate      %Boolean;           #IMPLIED
        Term          %Term;              #IMPLIED
        RegistrantRef %UID;               #IMPLIED
        MaxResults    %Number;            #IMPLIED
        SkipResults   %Number;            #IMPLIED
        CountResults  %Boolean;           "0">

6.1.2.2.  Response

The response to a DomainDetailsQry request will be either an Error (Error) element, or zero or more Domain (Domain) elements that matched the filters specified in the request. If a QryId was provided in the request, it is returned in the TransId attribute of the Response element.

If a FieldList was specified in the request, the fields provided in any returned Domain elements will match the list provided unless restricted due to ownership by a registrar other than the registrar making the request - in such cases only the public Whois information shall be returned. DomainName will always be returned for all matched domains.

By default, only the DomainName and Status details shall be returned for each Domain.

The ResultDateRange element in a DomainDetailsQry request has a number of affects on the response:

• the results shall be extracted by first selecting all of the domains that were managed by the requesting registrar during the given date range and then applying the other filters to this new result set to produce the final response
• the EffectiveDateRange will also be returned for each result domain, regardless of whether it was specified by a FieldList attribute
• the MaxResults and SkipResults elements in the request (if specified) are treated as a maximum number of distinct domains and a number of distinct domains to skip - the actual number of results returned may exceed MaxResults due to having multiple entries for each domain returned with different effective date ranges

6.1.3.  UDAIValidQry

The UDAIValidQry request allows users to check a UDAI strings against the details stored by the SRS for a domain. Changes to domains may only be made with a valid UDAI.

6.1.3.1.  Request

The UDAIValidQry request is an empty element that must specify:

Additionally, the request may specify:

Syntax:

<!ELEMENT UDAIValidQry EMPTY>
<!ATTLIST UDAIValidQry
        QryId      %UID;        #IMPLIED
        DomainName %DomainName; #REQUIRED
        UDAI       %UID;        #REQUIRED>

6.1.3.2.  Response

The response to a UDAIValidQry request will be a UDAIValid (UDAIValid) element. If a QryId was provided in the request, it is returned in the TransId attribute of the Response element.

6.1.4.  Whois

The Whois request allows users to retrieve the public information stored on domains. The details requested may be the full public details, or a simple check of the status of the domain.

6.1.4.1.  Request

The Whois request is an empty element that must specify:

Additionally, the request may specify:

Syntax:

<!ELEMENT Whois EMPTY>
<!ATTLIST Whois
        QryId      %UID;        #IMPLIED
        FullResult %Boolean;    "1"
        SourceIP   CDATA        #IMPLIED
        DomainName %DomainName; #REQUIRED>

6.1.4.2.  Response

The response to a Whois request will be either an Error (Error) element, or a Domain (Domain) element. If a QryId was provided in the request, it is returned in the TransId attribute of the Response element.

The amount of detail returned for matched domains will depend on the request details and the domain status:

• if the domain is not currently registered, only the domain's name and status ("Available") will be returned,
• if the request is not for a full result, only the domain status will be returned,
• otherwise, the Domain element will be returned with any of the public details for which the SRS server has a value stored

The public details for a domain should be set by the registry's policy. For the .nz registry, the public details are:

• DomainName
• Status
• RegisteredDate
• CancelledDate
• LockedDate
• BilledUntil
• EffectiveFrom
• Delegate
• RegistrarPublicContact
• RegistrantContact
• AdminContact
• TechnicalContact
• NameServers
• AuditDetails

6.2.  Domain Write Actions

The domain write requests are:

6.2.1.  DomainCreate

The DomainCreate request allows users to request the creation of a new domain in the SRS. The domain created will be managed by the registrar that makes the request - or by the effective registrar for the request, if the request is made by the registry. This request will only be successful if the domain name is available.

6.2.1.1.  Request

The DomainCreate request must specify:

Additionally, the request may specify:

The request must also include a RegistrantContact (Contact Details Elements) details element for the domain, and may include elements defining the AdminContact (Contact Details Elements), TechnicalContact (Contact Details Elements), and NameServers (NameServers) for the domain, and also AuditText (AuditText) for the transaction.

Syntax:

<!ELEMENT DomainCreate (RegistrantContact,AdminContact?,
                       TechnicalContact?,NameServers?,AuditText?)>
<!ATTLIST DomainCreate
        ActionId      %UID;        #REQUIRED
        DomainName    %DomainName; #REQUIRED
        RegistrantRef %UID;        #IMPLIED
        Term          %Term;       #REQUIRED
        Delegate      %Boolean;    "1">

6.2.1.2.  Response

The response to a DomainCreate request will be either an Error (Error) element, or a full Domain (Domain) element. The Domain element will only be returned if the domain creation is successful.

6.2.2.  DomainUpdate

The DomainUpdate request allows users to update the details of existing domains and to perform various update functions, including:

• transferring a domain
• cancelling a domain
• un-cancelling a domain
• renewing a domain
• changing the delegation status of a domain
• requesting a new domain UDAI

Domain details may be updated individually or combined in a single request that updates multiple parts of the domain information.

In the absence of a valid UDAI, domain updates are restricted to the registrar that currently manages a domain, or to suitably authorized registry users. If a registrant provides the UDAI for their domain to a registrar other than the one that currently manages the domain, the other registrar will be able to perform an update to the domain. If the UDAI is valid, then the new registrar may make any required updates to the domain details and the SRS server will automatically initiate a domain transfer as part of processing the request.

A domain can be transferred regardless of the status of the domain (that is, the status of the domain can be "Active" or "PendingRelease" at the time of the transfer), however, the domain MUST NOT be locked. A locked domain cannot be transferred until it is unlocked. Registrants SHOULD have access to the UDAI for their domains to allow them to transfer their domains freely between registrars.

6.2.2.1.  Request

The DomainUpdate request must specify:

Additionally, the request may specify:

For the boolean attributes, if the attribute is not specified in the update request, then no change will be made to the related domain details.

The DomainUpdate request must also include a DomainNameFilter (DomainNameFilter) element to identify the domain(s) to be updated and may include elements defining the new details for RegistrantContact (Contact Details Elements), AdminContact (Contact Details Elements), TechnicalContact (Contact Details Elements), and NameServers (NameServers) for the domain, and also AuditText (AuditText) for the transaction.

Syntax:

<!ELEMENT DomainUpdate (DomainNameFilter+,RegistrantContact?,
                       AdminContact?,TechnicalContact?,
                       NameServers?,AuditText?)>
<!ATTLIST DomainUpdate
        ActionId      %UID;     #REQUIRED
        UDAI          %UID;     #IMPLIED
        NewUDAI       %Boolean; #IMPLIED
        RegistrantRef %UID;     #IMPLIED
        Term          %Term;    #IMPLIED
        Delegate      %Boolean; #IMPLIED
        Renew         %Boolean; #IMPLIED
        NoAutoRenew   %Boolean; #IMPLIED
        Lock          %Boolean; #IMPLIED
        Cancel        %Boolean; #IMPLIED
        Release       %Boolean; #IMPLIED
        FullResult    %Boolean; "1">

6.2.2.2.  Response

The response to a DomainUpdate request will be either an Error (Error) element, or a Domain (Domain) element. By default the Domain element returned will include the following fields:

• DomainName
• AuditDetails
• Status
• Delegate
• Term
• NameServers
• RegistrantRef
• RegistrarId
• RegistrantContact
• AdminContact
• TechnicalContact
• BilledUntil
• RegisteredDate
• CancelledDate
• LockedDate

If the FullResult parameter in the request is false, the DomainName and AuditDetails fields will be returned along with any of the other fields above that have been updated by the transaction.

6.3.  Registrar Query Actions

The registrar query requests are:

6.3.1.  GetMessages

The GetMessages request allows the user to retrieve messages that they may have been unaware of, or to confirm the status of a specific transaction that had been sent previously. Messages that registrars may miss are likely to include requests that are made by the registry on the registrar's behalf, and domain transfer requests issued by other registrars transferring domains at the request of a registrant.

The GetMessages request MUST NOT be accompanied by any other requests within a request document.

6.3.1.1.  Request

The GetMessages request that may specify:

The GetMessages request may also include a TransDateRange (Date Range Elements) element and an AuditTextFilter (AuditTextFilter) element.

Either an ActionId or a TransDateRange MUST be specified in order for the request to succeed.

Syntax:

<!ELEMENT GetMessages (TransDateRange?,AuditTextFilter?)>
<!ATTLIST GetMessages
        QryId                  %UID;                 #IMPLIED
        OriginatingRegistrarId %RegistrarIdOrOTHERS; #IMPLIED
        ActionId               %UID;                 #IMPLIED
        RecipientRegistrarId   %RegistrarId;         #IMPLIED
        MaxResults             %Number;              #IMPLIED
        SkipResults            %Number;              #IMPLIED
        CountResults           %Boolean;             "0">

6.3.1.2.  Response

The response to a GetMessages request will be either an Error (Error) element or one or more Response (Response) elements containing the details of messages that match the request specification.

6.3.2.  RegistrarAccountQry

The RegistrarAccountQry request allows the user to retrieve the details of billing transactions made in the account of a registrar.

6.3.2.1.  Request

The request may specify:

The RegistrarAccountQry request may also include a TransDateRange (Date Range Elements) element and an InvoiceDateRange (Date Range Elements) element.

Syntax:

<!ELEMENT RegistrarAccountQry (TransDateRange?,InvoiceDateRange?)>
<!ATTLIST RegistrarAccountQry
        QryId         %UID;          #IMPLIED
        RegistrantRef %UID;          #IMPLIED
        DomainName    %DomainName;   #IMPLIED
        InvoiceId     %UID;          #IMPLIED
        MaxResults    %Number;       #IMPLIED
        SkipResults   %Number;       #IMPLIED
        TransStatus   (%BillStatus;) #IMPLIED
        CountResults  %Boolean;      "0">

6.3.2.2.  Response

The response to a RegistrarAccountQry request will be either an Error (Error) element or a set of BillingTrans (BillingTrans) elements.

6.3.3.  RegistrarDetailsQry

The RegistrarDetailsQry request allows the user to retrieve the stored details for a registrar account. Registrars SHOULD be restricted to only retrieving details of their own account. The registry may retrieve information about any registrar.

6.3.3.1.  Request

The request may specify:

The RegistrarDetailsQry request may also include a ResultDateRange (Date Range Elements) element.

If the ResultDateRange element is supplied, it will cause the server to return multiple records for each registrar, describing all the changes that the registrar went through during the given period. Otherwise, if it is not specified, only the latest data for each registrar that matches the filters will be returned. When a ResultDateRange is requested, the Allowed2LDs and the Roles are not returned (there is no historical data available for these fields).

Syntax:

<!ELEMENT RegistrarDetailsQry (ResultDateRange?)>
<!ATTLIST RegistrarDetailsQry
        QryId       %UID;         #IMPLIED
        RegistrarId %RegistrarId; #IMPLIED
        NameFilter  CDATA         #IMPLIED>

6.3.3.2.  Response

The response to a RegistrarDetailsQry request will be either an Error (Error) element or one or more Registrar (Registrar) elements matching the provided filter details.

6.4.  Registrar Write Actions

Registrar's typically only have access to a single requests for the maintenance of their details stored at the SRS:

6.4.1.  RegistrarUpdate

The RegistrarUpdate request allows the user to update their own account details and allows the registry to maintain registrar information for any registrar.

6.4.1.1.  Request

The request must specify:

Additionally, the request may specify:

The RegistrarUpdate request may also include new details for any of the related registrar information elements:

• RegistrarPublicContact (Contact Details Elements)
• RegistrarSRSContact (Contact Details Elements)
• DefaultTechnicalContact (Contact Details Elements)
• EncryptKeys (EncryptKeys)
• Allowed2LDs (Allowed2LDs)
• Roles (Roles)
• AuditText (AuditText)

If an attribute or element is not provided in the request, then the related details SHALL NOT be updated by the SRS server.

Syntax:

<!ELEMENT RegistrarUpdate (RegistrarPublicContact?,
                           RegistrarSRSContact?,
                           DefaultTechnicalContact?,
                           EncryptKeys?,
                           Allowed2LDs?,
                           Roles?,
                           AuditText?)>
<!ATTLIST RegistrarUpdate
        ActionId %UID; #REQUIRED
        Name     CDATA #IMPLIED
        AccRef   CDATA #IMPLIED
        URL      CDATA #IMPLIED>

6.4.1.2.  Response

The response to a RegistrarUpdate request will be either an Error (Error) element or a Registrar (Registrar) element showing the updated state of the user details.

6.5.  Registry Actions

The registry requests are used by the registry to manage the business functions of the SRS. Registrars MUST NOT have access to these functions.

The registry requests are:

6.5.1.  AccessControlListAdd

The AccessControlListAdd request allows the registry to add entries to its access control lists.

6.5.1.1.  Request

The request must specify:

Additionally, the request may specify:

The AccessControlListAdd request must also include one or more AccessControlListEntry (AccessControlListEntry) elements to specify the entries to be added to the access control lists, and an AuditText (AuditText) element giving a description for the addition.

Syntax:

<!ELEMENT AccessControlListAdd (AccessControlListEntry+,
                                AuditText)>
<!ATTLIST AccessControlListAdd
        Resource   CDATA     #REQUIRED
        Type       CDATA     #REQUIRED
        ActionId   %UID;     #REQUIRED
        FullResult %Boolean; "1">

6.5.1.2.  Response

The response to an AccessControlListAdd request will be either an Error (Error) or one or more AccessControlList (AccessControlList) elements. If FullResult was specified in the query, then the returned AccessControlList elements will contain all of the AccessControlListEntry elements belonging to the modified access control lists.

6.5.2.  AccessControlListQry

The AccessControlListQry request allows the registry to retrieve details of the current state of access control lists.

6.5.2.1.  Request

The request may specify:

Syntax:

<!ELEMENT AccessControlListQry EMPTY>
<!ATTLIST AccessControlListQry
        Resource   CDATA     #IMPLIED
        Type       CDATA     #IMPLIED
        FullResult %Boolean; "0">

6.5.2.2.  Response

The response to an AccessControlListQry request will be either an Error (Error) element or zero or more AccessControlList (AccessControlList) elements - dependent on the number of access control lists that matched the query specification.

The effect of the FullResult, Resource, and Type parameters on the results is illustrated by the following table:

6.5.3.  AccessControlListRemove

The AccessControlListRemove request allows the registry to remove entries from access control lists.

6.5.3.1.  Request

The request must specify:

Additionally, the request may specify:

The AccessControlListRemove request must also include one or more AccessControlListEntry (AccessControlListEntry) elements to specify the entries to be removed from the access control lists, and an AuditText (AuditText) element giving a description for the removal.

Syntax:

<!ELEMENT AccessControlListRemove (AccessControlListEntry+,
                                   AuditText)>
<!ATTLIST AccessControlListRemove
        Resource   CDATA     #REQUIRED
        Type       CDATA     #REQUIRED
        ActionId   %UID;     #REQUIRED
        FullResult %Boolean; "1">

6.5.3.2.  Response

The response to an AccessControlListRemove request will be either an Error (Error) element or one or more AccessControlList (AccessControlList) elements. If FullResult was specified in the query, then the returned AccessControlList elements will contain all of the AccessControlListEntry elements belonging to the access control lists.

6.5.4.  AdjustRegistrarAccount

The AdjustRegistrarAccount request allows the registry to adjust the account of a registrar by creating a billing transaction in the registrar's name. This allows the registry to make adjustments by crediting or debiting the registrar account, for instance, in the case of a refunded payment.

6.5.4.1.  Request

The request must specify:

The AdjustRegistrarAccount request must also include the date details for the billing transaction as a TransactionDate (Timestamp Elements) element, a BillPeriodStart (Timestamp Elements) element, and a BillPeriodEnd (Timestamp Elements) element, and also an AuditText (AuditText) element providing audit details for the adjustment.

Syntax:

<!ELEMENT AdjustRegistrarAccount (TransactionDate,
                                  BillPeriodStart,
                                  BillPeriodEnd,
                                  AuditText)>
<!ATTLIST AdjustRegistrarAccount
        RegistrarId %RegistrarId;        #REQUIRED
        DomainName  %DomainName;         #REQUIRED
        ActionId    %UID;                #REQUIRED
        Months      %Number;             #REQUIRED
        ActionType  (%AccountingAction;) #REQUIRED>

6.5.4.2.  Response

The response to a AdjustRegistrarAccount request will be either an Error (Error) element or a BillingTrans (BillingTrans) element for the new transaction details provided.

6.5.5.  BilledUntilAdjustment

The BilledUntilAdjustment request allows the registry to change the date that a domain has been billed until, for example, when a domain is renewed by the registrar before the automatic renewal date arrives.

6.5.5.1.  Request

The request must specify:

The BilledUntilAdjustment request must also include a NewBilledUntilDate (Timestamp Elements) element providing the new date for the domain billed until record, and an AuditText (AuditText) element describing the reason for the change.

Syntax:

<!ELEMENT BilledUntilAdjustment (NewBilledUntilDate,AuditText)>
<!ATTLIST BilledUntilAdjustment
        DomainName %DomainName; #REQUIRED
        ActionId   %UID;        #REQUIRED>

6.5.5.2.  Response

The response to a BilledUntilAdjustment request will be either an Error (Error) element or a full Domain (Domain) element showing all details for the updated domain, including the new BilledUntil date.

6.5.6.  BillingExtract

The BillingExtract request allows the registry to retrieve details of billing transactions and to assign invoice numbers and dates to groups of billing transactions.

This transaction is expected to support the registry's customer invoicing and accounting systems. The registry first extracts the details of fees that have been incurred through domain registrations and renewals for a period. These transactions may be entered into the registry's accounting system to be issued as an invoice to the registrar concerned. Once the invoice has been issued, the BillingExtract may be run again as an invoice extract to assign the accounting system invoice number and maybe the invoice date to the requests and mark the transactions as having been billed.

The registry may use this request to retrieve details of billing transactions for any registrar.

6.5.6.1.  Request

The BillingExtract request must specify:

Additionally, the request may also include:

The request must also include a TransDateRange (Date Range Elements) element and may include an InvoiceDate (Timestamp Elements) element. The TransDateRange element specifies the start date and end date to be included in the billing extract. The InvoiceDate (Timestamp Elements) element, if provided, specifies a date to be applied to the extracted invoice details - this date is only applied to the extracted details if the InvoiceExtract attribute was provided with a true value.

Syntax:

<!ELEMENT BillingExtract (TransDateRange,InvoiceDate?)>
<!ATTLIST BillingExtract
        ActionId          %UID;     #REQUIRED
        InvoiceExtract    %Boolean; #IMPLIED
        RegistrarId       %UID;     #IMPLIED
        ConfirmedTrans    %Boolean; #IMPLIED
        InsideGracePeriod %Boolean; #IMPLIED
        InvoiceId         CDATA     #IMPLIED>

6.5.6.2.  Response

The response to a BillingExtract request will be either an Error (Error) element or a set of BillingTrans (BillingTrans) elements that matched the request terms.

If an invoice extract was requested, the returned transactions will be marked with the provided invoice identifier and maybe the optional invoice date.

6.5.7.  BuildDnsZoneFiles

The BuildDnsZoneFiles request allows the registry to initiate the creation of DNS zone and configuration files for all registered domains that have been set to delegate. The SRS server SHALL generate a run-log entry for this request recording the final status and MAY include statistics on the domains exported to the DNS.

The SRS server MUST NOT allow multiple instances of this request to run simultaneously.

6.5.7.1.  Request

The request must specify:

The BuildDnsZoneFiles request may also include a RunDate (Timestamp Elements) element to specify the date and time to run the zone build process.

Syntax:

<!ELEMENT BuildDnsZoneFiles (RunDate)>
<!ATTLIST BuildDnsZoneFiles
        ActionId %UID; #REQUIRED>

6.5.7.2.  Response

The response to a BuildDnsZoneFiles request will be either an Error (Error) element or a RunLog (RunLog) element containing details produced by the zone file build process.

6.5.8.  DeferredIncomeDetailQry

The DeferredIncomeDetailQry request allows the registry to obtain a report of billing transactions that contribute to an amount of deferred income (for example, to provide a breakdown of the billing transactions that make up an amount of deferred income reported by the DeferredIncomeSummaryQry (DeferredIncomeSummaryQry) request).

6.5.8.1.  Request

The request must specify:

Additionally, the request may specify:

Syntax:

<!ELEMENT DeferredIncomeDetailQry EMPTY>
<!ATTLIST DeferredIncomeDetailQry
        BaseMonth   CDATA #REQUIRED
        BaseYear    CDATA #REQUIRED
        IncomeMonth CDATA #REQUIRED
        IncomeYear  CDATA #REQUIRED
        QryId       %UID; #IMPLIED>

6.5.8.2.  Response

The response to a DeferredIncomeDetailQry request will be either an Error (Error) element or a set of BillingTrans (BillingTrans) elements consisting of all of the billing transactions that contributed to deferred income for the specified period.

6.5.9.  DeferredIncomeSummaryQry

The DeferredIncomeSummaryQry request allows the registry to generate a report on the amount of deferred income that can be realised in any given month for the period provided in the request.

6.5.9.1.  Request

The request must specify:

Additionally, the request may specify:

Syntax:

<!ELEMENT DeferredIncomeSummaryQry EMPTY>
<!ATTLIST DeferredIncomeSummaryQry
        BaseMonth   CDATA #REQUIRED
        BaseYear    CDATA #REQUIRED
        IncomeMonth CDATA #REQUIRED
        IncomeYear  CDATA #REQUIRED
        QryId       %UID; #IMPLIED>

6.5.9.2.  Response

The response to a DeferredIncomeSummaryQry request will be either an Error (Error) element or a set of DeferredRegistrarIncome (DeferredRegistrarIncome) elements containing the deferred income contribution for each registrar for the specified period.

6.5.10.  GenerateDomainReport

The GenerateDomainReport request allows the registry to initiate the creation of a domain report containing details of the domains registered in the SRS system. SRS implementations may vary in the information that they include in this report.

6.5.10.1.  Request

The request must specify:

The GenerateDomainReport request must also include a RunDate (Timestamp Elements) element providing the date and time at which the domain report creation process should run.

Syntax:

<!ELEMENT GenerateDomainReport (RunDate)>
<!ATTLIST GenerateDomainReport
        ActionId %UID; #REQUIRED>

6.5.10.2.  Response

The response to a GenerateDomainReport request will be either an Error (Error) element or a RunLog (RunLog) element containing details produced by the domain report creation process.

6.5.11.  QryBillingAmount

The QryBillingAmount request allows the registry to query all of the billing amounts in the system (including all historical billing amounts, the current effective billing amount and any future billing amounts). It does not set a new billing amount.

6.5.11.1.  Request

The QryBillingAmount request has no required parameters. The request may specify:

Syntax:

<!ELEMENT QryBillingAmount EMPTY>
<!ATTLIST QryBillingAmount
        QryId %UID; #IMPLIED>

6.5.11.2.  Response

The QryBillingAmount response will either be an Error (Error) element or a set of BillingAmount (BillingAmount) elements. If a QryId was provided with the request, this will be returned in the TransId attribute of the Response (Response) element.

6.5.12.  RegistrarCreate

The RegistrarCreate request allows the user to create a new registrar user account in the SRS server and to provide details for it.

6.5.12.1.  Request

The request must specify:

Additionally, the request may specify:

The RegistrarCreate request must also include a RegistrarPublicContact (Contact Details Elements) element specifying the public contact details for the registrar, a RegistrarSRSContact (Contact Details Elements) element specifying the contact details for the registry's use, a DefaultTechnicalContact (Contact Details Elements) element which will be applied to domains registered through the registrar if no other technical contact is specified, and an EncryptKeys (EncryptKeys) element providing one or more public keys that the registrar will use.

The RegistrarCreate request may also include the Allowed2LDs (Allowed2LDs) element specifying the domains in which the registrar may manage domain registrations, a Roles (Roles) element defining system access roles for the registrar, and the AuditText (AuditText) element to provide details on the addition of the new registrar account.

Syntax:

<!ELEMENT RegistrarCreate (RegistrarPublicContact,
                           RegistrarSRSContact,
                           DefaultTechnicalContact,
                           EncryptKeys,
                           Allowed2LDs?,
                           Roles?,
                           AuditText?)>
<!ATTLIST RegistrarCreate
        ActionId    %UID;         #REQUIRED
        Name        CDATA         #REQUIRED
        AccRef      CDATA         #REQUIRED
        RegistrarId %RegistrarId; #REQUIRED
        URL         CDATA         #IMPLIED>

6.5.12.2.  Response

The response to a RegistrarCreate request will be either an Error (Error) element or a Registrar (Registrar) element showing the details for the new registrar account.

6.5.13.  RunLogCreate

The RunLogCreate request allows the registry to request creation of a log entry in the SRS server's run log. This is useful for allowing batch processes that interface with the SRS server to log messages to a standard location.

6.5.13.1.  Request

The request must specify:

The RunLogCreate request must also include a FirstRunDate (Timestamp Elements) element specifying the date at which the process was initiated, and a RunLog (RunLog) element containing the details of the log entry to be created.

Syntax:

<!ELEMENT RunLogCreate (FirstRunDate,RunLog)>
<!ATTLIST RunLogCreate
        ActionId %UID; #REQUIRED>

6.5.13.2.  Response

The response to a RunLogCreate request will be either an Error (Error) element or a RunLog (RunLog) element containing the details of the log entry that was created.

6.5.14.  RunLogQry

The RunLogQry request allows the registry to query the SRS server for details of log entries created by processes that interact with the SRS server.

6.5.14.1.  Request

The request may specify:

The RunLogQry request may also include a LogDateRange (Date Range Elements) element defining the period for which to return run log entry details.

If no limiting terms are specified, the SRS server will return all run log entries. The server MAY impose a limit on the number of entries that are returned in a single response.

Syntax:

<!ELEMENT RunLogQry (LogDateRange?)>
<!ATTLIST RunLogQry
        QryId       %UID; #IMPLIED
        ProcessName CDATA #IMPLIED
        Parameters  CDATA #IMPLIED>

6.5.14.2.  Response

The response to a RunLogQry request will be either an Error (Error) element or a set of RunLog (RunLog) elements matching the provided terms.

6.5.15.  ScheduleCancel

The ScheduleCancel request allows the registry to cancel a scheduled process that has been registered in the SRS server using the ScheduleCreate (ScheduleCreate) request.

6.5.15.1.  Request

The request must specify:

Additionally, the request may specify:

The ScheduleCancel request must also include a FirstRunDate (Timestamp Elements) element identifying the first run date of the scheduled job process to be cancelled, and may include a AuditText (AuditText) element providing the reasons for the job cancellation.

Syntax:

<!ELEMENT ScheduleCancel (FirstRunDate,AuditText?)>
<!ATTLIST ScheduleCancel
        ActionId    %UID;            #REQUIRED
        ProcessName (%ScheduledJob;) #REQUIRED
        Parameters  CDATA            #IMPLIED>

6.5.15.2.  Response

The response to a ScheduleCancel request will be either an Error (Error) element or a Schedule (Schedule) element giving the details of the cancelled job, including the new cancellation date.

6.5.16.  ScheduleCreate

The ScheduleCreate request allows the registry to insert a scheduled job entry into the SRS server to be run at a specified time, and possibly at regular intervals after that time. This may be used to set times for running processes that support the day-to-day work of the registry. These processes are defined by the ScheduledJob (ScheduledJob) entity.

6.5.16.1.  Request

The request must specify:

Additionally, the request may specify:

The ScheduleCreate request must also include a FirstRunDate (Timestamp Elements) element providing the date and time at which the process should first be executed. The request may also include a FinalRunDate (Timestamp Elements) element providing the last date and time at which a repeating process should be executed, and an AuditText (AuditText) element providing details about the process creation request.

Syntax:

<!ELEMENT ScheduleCreate (FirstRunDate,FinalRunDate?,AuditText?)>
<!ATTLIST ScheduleCreate
        ProcessName (%ScheduledJob;) #REQUIRED
        Frequency   CDATA            #REQUIRED
        Parameters  CDATA            #IMPLIED
        ActionId    %UID;            #REQUIRED>

6.5.16.2.  Response

The response to a ScheduleCreate request will be either an Error (Error) element or a Schedule (Schedule) element with the newly created scheduled job details.

6.5.17.  ScheduleQry

The ScheduleQry request allows the registry to query details of scheduled jobs in the SRS system. The results may be filtered to return only scheduled events with particular characteristics.

6.5.17.1.  Request

The request may specify:

The ScheduleQry request may also include an ActiveOn (Timestamp Elements) element providing a date and time at which a process must have been active (between the first run date and the last run date of a repeating process), and a FirstRunDate (Timestamp Elements) element to match against the first run dates of scheduled jobs.

Syntax:

<!ELEMENT ScheduleQry (ActiveOn?,FirstRunDate?)>
<!ATTLIST ScheduleQry
        QryId       %UID; #IMPLIED
        ProcessName CDATA #IMPLIED
        Parameters  CDATA #IMPLIED>

6.5.17.2.  Response

The response to a ScheduleQry request will be either an Error (Error) element or a set of Schedule (Schedule) elements, one for each schedule that matched the request parameters.

6.5.18.  ScheduleUpdate

The ScheduleUpdate request allows the registry to amend the details for an existing Schedule (Schedule) entry in the SRS server.

6.5.18.1.  Request

The request may specify:

Additionally, the request may specify:

The ScheduleUpdate request must also include a FirstRunDate (Timestamp Elements) element to specify the new first run date for the process. The request may include a LastRunDate (Timestamp Elements) element to specify the most recent date at which a repeating process ran and an AuditText (AuditText) element providing details about the schedule update request.

Syntax:

<!ELEMENT ScheduleUpdate (FirstRunDate,LastRunDate?,AuditText?)>
<!ATTLIST ScheduleUpdate
        ActionId    %UID;            #REQUIRED
        Parameters  CDATA            #IMPLIED
        ProcessName (%ScheduledJob;) #REQUIRED>

6.5.18.2.  Response

The response to a ScheduleUpdate request will be either an Error (Error) element or a Schedule (Schedule) element with the new scheduled job details.

6.5.19.  SetBillingAmount

The SetBillingAmount request allows the registry to set a new per-domain monthly charge for registered domains within the SRS.

Each change to the monthly charge MUST also include a date that the new charge will become effective. SRS implementations SHOULD ensure that the effective date is not in the past (that is, charges should not be altered retroactively). Future billing amount changes may be amended by issuing a new SetBillingAmount request with the same effective date.

If the request succeeds, the response will provide a list of all stored billing amounts and their effective dates. On failure an error response is returned.

6.5.19.1.  Request

The request must specify:

The SetBillingAmount request must also include a BillingAmount (BillingAmount) element specifying the new per-domain monthly charge and the effective date for the new charge.

Syntax:

<!ELEMENT SetBillingAmount (BillingAmount)>
<!ATTLIST SetBillingAmount
        ActionId %UID; #REQUIRED>

Example:

<SetBillingAmount ActionId="000000123">
   <BillingAmount Amount="7.50">
       <EffectiveDate Year="2007" Month="11" Day="19" Hour="12"
          Minute="00" Second="00" TimeZoneOffset="+13:00" />
   </BillingAmount>
</SetBillingAmount>

6.5.19.2.  Response

The response to a SetBillingAmount request will be either an Error (Error) element or a set of BillingAmount (BillingAmount) elements, one for each billing amount in the history of the SRS server and the new value.

Example:

<Response Action="SetBillingAmount" FeId="4" FeSeq="214"
  OrigRegistrarId="50041">
   <BillingAmount Amount="6.00">
       <EffectiveDate Year="2004" Month="01" Day="01" Hour="04"
          Minute="00" Second="00" TimeZoneOffset="+13:00" />
   </BillingAmount>
   <BillingAmount Amount="4.00">
       <EffectiveDate Year="2005" Month="01" Day="01" Hour="04"
          Minute="00" Second="00" TimeZoneOffset="+13:00" />
   </BillingAmount>
   <BillingAmount Amount="4.50">
       <EffectiveDate Year="2006" Month="01" Day="01" Hour="04"
          Minute="00" Second="00" TimeZoneOffset="+13:00" />
   </BillingAmount>
   <BillingAmount Amount="7.50">
       <EffectiveDate Year="2007" Month="11" Day="19" Hour="12"
          Minute="00" Second="00" TimeZoneOffset="+13:00" />
   </BillingAmount>
</Response>

6.5.20.  SysParamsQry

The SysParamsQry request allows the registry to obtain a list of the current state of the SRS server's configurable parameters.

6.5.20.1.  Request

The request may specify:

Syntax:

<!ELEMENT SysParamsQry EMPTY>
<!ATTLIST SysParamsQry
        QryId %UID; #IMPLIED>

6.5.20.2.  Response

The response to a SysParamsQry request will be either an Error (Error) element or a set of SysParam (SysParam) elements, one for each user-configurable system parameter in the SRS server implementation.

6.5.21.  SysParamsUpdate

The SysParamsUpdate request allows the registry to update the value of any user configurable parameters in the SRS server implementation.

6.5.21.1.  Request

The request must specify:

The SysParamsUpdate request must include one or more SysParam (SysParam) elements containing the new parameter details.

The SysParamsUpdate request may also include an AuditText (AuditText) element giving further details of the configuration changes.

Syntax:

<!ELEMENT SysParamsUpdate (SysParam+,AuditText?)>
<!ATTLIST SysParamsUpdate
        ActionId %UID; #REQUIRED>

6.5.21.2.  Response

The response to a SysParamsUpdate request will be either an Error (Error) element or a set of SysParam (SysParam) elements, one for each changed system parameter, showing the new value.

7.  SRS Response Types

7.1.  AccessControlList

The AccessControlList element is used by the SRS to return details of the registry's access control lists.

The AccessControlList element must specify:

The AccessControlList element may include one or more AccessControlListEntry (AccessControlListEntry) elements.

Syntax:

<!ELEMENT AccessControlList (AccessControlListEntry*)>
<!ATTLIST AccessControlList
        Resource CDATA #REQUIRED
        Type     CDATA #REQUIRED>

Example:

<AccessControlList Resource="whoisd" Type="blacklist">
    <AccessControlListEntry Address="192.0.2.5", "Blacklisted for
        abuse." />
    <AccessControlListEntry Address="192.0.2.9", "Blacklisted for
        abuse." />
    <AccessControlListEntry Address="192.0.2.237", "Blacklisted at
        owner's request" />
</AccessControlList>

7.2.  BillingAmount

The BillingAmount element is used by the SRS to return details of the amount charged for registered domains and the date that the amount became effective in the SRS.

The element content consists of an Amount attribute containing the charge in the registry's chosen currency, and may also include an EffectiveDate (Timestamp Elements) element containing the date and time that the charge became (or will become, for future changes) effective. The Amount value should be validated as an acceptable currency value.

The BillingAmount element must specify:

The BillingAmount element may also include an EffectiveDate (Timestamp Elements) element.

Syntax:

<!ELEMENT BillingAmount (EffectiveDate?)>
<!ATTLIST BillingAmount
        Amount %Dollars; #REQUIRED>

Example:

<BillingAmount Amount="9.95">
    <EffectiveDate Year="2004" Month="01" Day="01" Hour="04"
        Minute="00" Second="00" TimeZoneOffset="+13:00" />
</BillingAmount>

7.3.  BillingTrans

The BillingTrans element is used by the SRS to return details of charges that have been incurred by registrars over a given billing period.

The BillingTrans element must specify:

The BillingTrans element may also specify:

The BillingTrans element must also include a TransDate (Timestamp Elements) element containing the date on which the billing transaction (domain creation, renewal, etc.) occurred, a BillPeriodStart (Timestamp Elements) and a BillPeriodEnd (Timestamp Elements) element containing the start and end of the billing period to which the transaction belongs. The element may include an InvoiceDate (Timestamp Elements) element containing the date of the invoice to which the billing transaction has been assigned.

Syntax:

<!ELEMENT BillingTrans (InvoiceDate?,TransDate,BillPeriodStart,
                       BillPeriodEnd)>
<!ATTLIST BillingTrans
        RegistrarId   %RegistrarId;  #REQUIRED
        Type          CDATA          #REQUIRED
        TransStatus   (%BillStatus;) #REQUIRED
        DomainName    %DomainName;   #REQUIRED
        RegistrantRef %UID;          #IMPLIED
        BillingTerm   %Term;         #REQUIRED
        InvoiceId     %UID;          #IMPLIED
        Amount        %Dollars;      #REQUIRED>

Example:

<BillingTrans Amount="1.50" BillingTerm="1" DomainName="example.org"
            RegistrantRef="Example registrant" RegistrarId="50041"
            TransStatus="PendingConfirmation" Type="Create">
    <TransDate Day="21" Hour="17" Minute="08" Month="2"
             Second="31" TimeZoneOffset="+13:00" Year="2008" />
    <BillPeriodStart Day="21" Hour="17" Minute="08" Month="2"
             Second="31" TimeZoneOffset="+13:00" Year="2008" />
    <BillPeriodEnd Day="21" Hour="17" Minute="08" Month="3"
             Second="31" TimeZoneOffset="+13:00" Year="2008" />
</BillingTrans>

7.4.  DeferredRegistrarIncome

The DeferredRegistrarIncome element allows the SRS server to return details of deferred income that may be realised in a particular month by considering the domain registration payments that have been made by a registrar up to and including a base month.

The DeferredRegistrarIncome element must specify:

The DeferredRegistrarIncome element must also include BaseMonth (BaseMonth) and BaseYear (BaseYear) element to define the last month of billing transactions to include for calculating deferred income amounts, and IncomeMonth (IncomeMonth) and IncomeYear (IncomeYear) elements to define the month to calculate realised deferred income for.

Syntax:

<!ELEMENT DeferredRegistrarIncome (BaseMonth,BaseYear,IncomeMonth,
                                  IncomeYear)>
<!ATTLIST DeferredRegistrarIncome
        RegistrarId  %RegistrarId; #REQUIRED
        BilledAmount %Dollars;     #REQUIRED
        BilledCount  %Number;      #REQUIRED>

7.5.  Domain

The Domain element can contain full details of a domain and its status within the SRS server and is used for creating and updating domains, as well as for reporting the current domain details.

The Domain element must specify:

The Domain element may also specify:

The Domain element may also include elements to define the contact details, name servers for the domain and various dates relating to the registration. These optional elements are:

• NameServers (NameServers)
• RegistrantContact (Contact Details Elements)
• RegistrarPublicContact (Contact Details Elements)
• AdminContact (Contact Details Elements)
• TechnicalContact (Contact Details Elements)
• BilledUntil (Timestamp Elements)
• RegisteredDate (Timestamp Elements)
• CancelledDate (Timestamp Elements)
• LockedDate (Timestamp Elements)
• AuditDetails (AuditDetails)

Syntax:

<!ELEMENT Domain (NameServers?,RegistrantContact?,
                 RegistrarPublicContact?,AdminContact?,
                 TechnicalContact?,BilledUntil?,
                 RegisteredDate?,CancelledDate?,
                 LockedDate?,AuditDetails?)>
<!ATTLIST Domain
        DomainName    %DomainName;     #REQUIRED
        RegistrantRef %UID;            #IMPLIED
        RegistrarName CDATA            #IMPLIED
        Status        (%DomainStatus;) #IMPLIED
        Delegate      %Boolean;        #IMPLIED
        Term          %Term;           #IMPLIED
        RegistrarId   %RegistrarId;    #IMPLIED
        UDAI          %UID;            #IMPLIED>

Example:

<Domain Delegate="1" DomainName="mydomain.example.org"
      RegistrantRef="RS1001" RegistrarId="50041" Status="Active"
      Term="1" UDAI="ke783oe9">
    <NameServers>
        <Server FQDN="ns1.mydomain.example.org" />
        <Server FQDN="ns2.mydomain.example.org" />
    </NameServers>
    <RegistrantContact Name="John Smith"
        Email="j.smith@mydomain.example.org">
        <PostalAddress Address1="14 Rural Street" Address2="Suburbia"
            City="Wellington" CountryCode="NZ" PostalCode="6135" />
        <Phone AreaCode="4" CountryCode="64" LocalNumber="111234" />
        <Fax AreaCode="4" CountryCode="64" LocalNumber="111235" />
    </RegistrantContact>
    <AdminContact Name="ISP Administrator"
        Email="admin@myisp.example.org">
        <PostalAddress Address1="1 Main Road" Address2="Central"
            City="Wellington" CountryCode="NZ" PostalCode="6001" />
        <Phone AreaCode="4" CountryCode="64" LocalNumber="111123" />
        <Fax AreaCode="4" CountryCode="64" LocalNumber="111124" />
    </AdminContact>
    <TechnicalContact Name="ISP Technician"
        Email="tech@myisp.example.org">
        <PostalAddress Address1="1 Main Road" Address2="Central"
            City="Wellington" CountryCode="NZ" PostalCode="6001" />
        <Phone AreaCode="4" CountryCode="64" LocalNumber="111125" />
        <Fax AreaCode="4" CountryCode="64" LocalNumber="111126" />
    </TechnicalContact>
    <BilledUntil Hour="10" Minute="00" Second="00"
        Day="1" Month="2" Year="2009" TimeZoneOffset="+13:00" />
    <RegisteredDate Hour="10" Minute="00" Second="00"
        Day="1" Month="2" Year="2008" TimeZoneOffset="+13:00" />
    <AuditDetails ActionId="Domain create for mydomain.example.org"
        RegistrarId="50041">
        <AuditTime>
            <From Hour="10" Minute="00" Second="00" Day="1"
                Month="2" Year="2008" TimeZoneOffset="+13:00" />
        </AuditTime>
        <AuditText>Domain created for John Smith, RS8974</AuditText>
    </AuditDetails>
</Domain>

7.6.  DomainTransfer

The DomainTransfer element is used by the SRS to inform a registrar of the transfer of one of the domains that they were the managing registrar for. This element will be returned in response to a GetMessages (GetMessages) request.

The DomainTransfer element must specify:

The DomainTransfer element may also specify:

The DomainTransfer element must also include one or more TransferredDomain (TransferredDomain) elements to define the domain names that have been transferred to another registrar.

Syntax:

<!ELEMENT DomainTransfer (TransferredDomain+)>
<!ATTLIST DomainTransfer
        RegistrarName CDATA #REQUIRED
        %TimeStamp;>

Example:

<DomainTransfer RegistrarName="My ISP" Hour="10" Minute="00"
    Second="00" Day="1" Month="4" Year="2008" TimeZoneOffset="+13" />
    <TransferredDomain>domain.co.example</TransferredDomain>
</DomainTransfer>

7.7.  Error

The Error element may be used to present details of errors that occur when processing individual requests or a whole transaction.

The Error element must specify:

The Error element also contains a Description (Description) element and may also provide ErrorDetails (ErrorDetails) elements with extra description of the error.

Syntax:

<!ELEMENT Error (Description, ErrorDetails*)>
<!ATTLIST Error
        ErrorId      %UID;    #REQUIRED
        Severity     %Number; #REQUIRED
        Hint         %UID;    #REQUIRED>

Example:

<Error Hint="MALFORMED_REQUEST_ERROR" ErrorId="INVALID_FIELD"
     Severity="er">
<Description>Invalid value in field</Description>
<ErrorDetails>DomainName</ErrorDetails>
</Error>

7.8.  RawRequest and RawResponse

The RawRequest and RawResponse elements allow the SRS server to return the details of a previous request and response. The details are returned as XML (XML) and Signature (Signature) elements with content encoded as parsed character data.

Syntax:

<!ELEMENT RawRequest (XML,Signature)>

<!ELEMENT RawResponse (XML,Signature)>

Example:

<Response Action="ActionDetailsQry" FeId="4" FeSeq="137"
  OrigRegistrarId="50041">
    <RawRequest>
        <XML>&lt;NZSRSRequest VerMajor="2" ...</XML>
        <Signature>-----BEGIN PGP SIGNATURE-----...</Signature>
    </RawRequest>
    <RawResponse>
        <XML>&lt;NZSRSResponse VerMajor="2" ...</XML>
        <Signature>-----BEGIN PGP SIGNATURE-----...</Signature>
    </RawResponse>
</Response>

7.9.  Registrar

The Registrar element is used to contain the details for a registrar.

The Registrar element must specify:

The Registrar element may also specify:

The Registrar element must also include a RegistrarPublicContact (Contact Details Elements) element specifying the public contact details for the registrar, a RegistrarSRSContact (Contact Details Elements) element specifying the contact details for the registry's use, a DefaultTechnicalContact (Contact Details Elements) element which will be applied to domains registered through the registrar if no other technical contact is specified, and an EncryptKeys (EncryptKeys) element providing one or more public keys that the registrar will use.

The Registrar element may also include the Allowed2LDs (Allowed2LDs) element specifying the subdomains managed by the registry in which the registrar may manage domain registrations, a Roles (Roles) element defining system access roles for the registrar, and the AuditText (AuditText) element to provide details on the addition of the new registrar account.

Syntax:

<!ELEMENT Registrar (RegistrarPublicContact,RegistrarSRSContact,
                    DefaultTechnicalContact,EncryptKeys,
                    Allowed2LDs?,Roles?,AuditDetails?)>
<!ATTLIST Registrar
        RegistrarId %RegistrarId; #REQUIRED
        Name        CDATA         #REQUIRED
        AccRef      CDATA         #REQUIRED
        URL         CDATA         #IMPLIED>

Example:

<Registrar AccRef="Reg8974" Name="My ISP" RegistrarId="50041">
    <RegistrarPublicContact Name="Customer Service"
        Email="custserv@myisp.example.org">
        <PostalAddress Address1="1 Main Road" Address2="Central"
            City="Wellington" CountryCode="NZ" PostalCode="6001" />
        <Phone AreaCode="4" CountryCode="64" LocalNumber="111123" />
        <Fax AreaCode="4" CountryCode="64" LocalNumber="111124" />
    </RegistrarPublicContact>
    <RegistrarSRSContact Name="Admin"
        Email="admin@myisp.example.org">
        <PostalAddress Address1="1 Main Road" Address2="Central"
            City="Wellington" CountryCode="NZ" PostalCode="6001" />
        <Phone AreaCode="4" CountryCode="64" LocalNumber="111125" />
        <Fax AreaCode="4" CountryCode="64" LocalNumber="111126" />
    </RegistrarSRSContact>
    <DefaultTechnicalContact Name="ISP Technician"
        Email="tech@myisp.example.org">
        <PostalAddress Address1="1 Main Road" Address2="Central"
            City="Wellington" CountryCode="NZ" PostalCode="6001" />
        <Phone AreaCode="4" CountryCode="64" LocalNumber="111123" />
        <Fax AreaCode="4" CountryCode="64" LocalNumber="111124" />
    </DefaultTechnicalContact>
    <EncryptKeys>
        <EncryptKey>-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)

mQGiBEfpmesRBADBkcApvlyH67pTIDObNgUm40u5WuLMkBvP8a9RWJNACdbUjMj+
...
=nDaR
-----END PGP PUBLIC KEY BLOCK-----</EncryptKey>
    </EncryptKeys>
    <Allowed2LDs>
        <SecondLD DomainName="co.example" />
        <SecondLD DomainName="org.example" />
    </Allowed2LDs>
    <Roles>
        <Role RoleName="CancelDomain" />
        <Role RoleName="Connect" />
        <Role RoleName="CreateDomain" />
        <Role RoleName="Query" />
        <Role RoleName="Registrar" />
        <Role RoleName="TransferDomain" />
        <Role RoleName="UncancelDomain" />
        <Role RoleName="UpdateDomain" />
        <Role RoleName="UpdateRegistrar" />
        <Role RoleName="Whois" />
    </Roles>
    <AuditDetails ActionId="Registrar update My ISP"
        RegistrarId="50041">
        <AuditTime>
            <From Hour="17" Minute="09" Second="10" Day="21"
                Month="2" Year="2008" TimeZoneOffset="+13:00" />
        </AuditTime>
        <AuditText>Update contact details</AuditText>
    </AuditDetails>
</Registrar>

7.10.  RunLog

The RunLog element is used to provide details of log messages from processes, such as batch processes, that interact with the SRS server. This includes the scheduled job processes that support the running of the registry, as well as any other systems that wish to log messages in the SRS server log.

The RunLog element must specify:

The RunLog element may also specify:

Syntax:

<!ELEMENT RunLog (RunLogTimeStamp,RunLogDetails?)>
<!ATTLIST RunLog
        ProcessName  CDATA #REQUIRED
        Parameters   CDATA #IMPLIED
        ActionStatus CDATA #REQUIRED
        Control      CDATA #IMPLIED>

7.11.  Schedule

The Schedule element is used to return details of scheduled events within the SRS system.

The Schedule element must specify:

The Schedule element may also specify:

The Schedule element must also include a FirstRunDate (Timestamp Elements) element specifying the first date and time at which the process should be executed, and may also include a FinalRunDate (Timestamp Elements) element specifying the last time at which the process should run (for a repeating process), a CreateAuditText (CreateAuditText) element providing details on the creation of the scheduled job entry, and a CancelAuditText (CancelAuditText) element providing details on the cancellation of the scheduled job entry.

Syntax:

<!ELEMENT Schedule (FirstRunDate,FinalRunDate?,CreateAuditText?,
                   CancelAuditText?)>
<!ATTLIST Schedule
        ProcessName         (%ScheduledJob;) #REQUIRED
        Frequency           CDATA            #REQUIRED
        Parameters          CDATA            #IMPLIED
        CreateByRegistrarId %UID;            #REQUIRED
        CreateActionId      %UID;            #REQUIRED
        CancelByRegistrarId %UID;            #IMPLIED
        CancelActionId      %UID;            #IMPLIED>

Example:

<Schedule CreateActionId="BUILDZONES-20060601"
          CreateByRegistrarId="50001" Frequency="01:00:00"
          Parameters="" ProcessName="BuildDnsZoneFiles">
    <FirstRunDate Day="21" Hour="17" Minute="10" Month="2"
                  Second="30" TimeZoneOffset="+13:00" Year="2008" />
    <CreateAuditText>Registry regular zone build</CreateAuditText>
</Schedule>

7.12.  SysParam

The SysParam element is used to return details of system settings and any audit details relating to them.

The SysParam element must specify:

The SysParam element must include a ParamValue (ParamValue) element containing the value of the system parameter, and may include an AuditDetails (AuditDetails) element containing details about the most recent change to the parameter.

Syntax:

<!ELEMENT SysParam (ParamValue, AuditDetails?)>
<!ATTLIST SysParam
        Name CDATA #REQUIRED>

7.13.  UDAIValid

The UDAIValid response element is used to return the result of checking the validity of a UDAI string for a given DomainName. The element has a single boolean attribute containing the result of the UDAI validation.

The UDAIValid element must specify:

Syntax:

<!ELEMENT UDAIValid EMPTY>
<!ATTLIST UDAIValid
        Valid %Boolean; #REQUIRED>

Example:

<UDAIValid Valid="1" />

8.  Information Elements

This section documents elements from the XML DTD that are not used as request or response elements. These information elements contain data passed between the client and server during normal registry usage. The elements are used by requests and responses throughout the system.

8.1.  AccessControlListEntry

The AccessControlListEntry contains details for a single entry in the registry's access control list and may also include an EffectiveDate (Timestamp Elements) element containing the date and time that the access control list entry became effective. It has two attributes:

Address:

An identifier to be used to match and control client access to network services (for example, an IP address or a range of IP addresses).

Comment:

A brief comment giving the reason for entry in the access control list.

The Address is a required element and should contain a value that can be used to control access to network services. For example, a range of IPv4 addresses in the format: 192.0.2.0/24.

The Comment is an optional element which can be used to maintain a record of the reason that Addresses were added to the access control list.

The AccessControlListEntry element is used by the AccessControlList (AccessControlList) element to return details of access control lists, and by the AccessControlListAdd (AccessControlListAdd) and AccessControlListRemove (AccessControlListRemove) queries to specify entries to add to and remove from access control lists.

Syntax:

<!ELEMENT AccessControlListEntry (EffectiveDate?)>
<!ATTLIST AccessControlListEntry
        Address CDATA #REQUIRED
        Comment CDATA #IMPLIED>

8.2.  ActionIdFilter

The ActionIdFilter element contains a pattern match string to match against the stored action identifiers of previous requests made to the SRS. The content should be a valid text filter (Text Filter).

Syntax:

<!ELEMENT ActionIdFilter (#PCDATA)>

8.3.  Allowed2LDs

The Allowed2LDs element contains zero or more SecondLD (SecondLD) elements and is used to hold a list of the subdomains managed by the registry for which a registrar may manage domain registrations.

Syntax:

<!ELEMENT Allowed2LDs (SecondLD*)>

8.4.  AuditDetails

The AuditDetails element contains the registrar and action identifiers of actions for system auditing purposes. The element may also contain details of the time of the action in an AuditTime (Timestamp Elements) element and a text description in an AuditText (AuditText) element.

Syntax:

<!ELEMENT AuditDetails (AuditTime?,AuditText?)>
<!ATTLIST AuditDetails
        RegistrarId CDATA #IMPLIED
        ActionId    %UID; #IMPLIED>

8.5.  AuditText

The AuditText element is a simple element that contains parsed character data that describes an action in the SRS. For instance, it may contain a text description of the purpose of a request.

Syntax:

<!ELEMENT AuditText (#PCDATA)>

8.6.  AuditTextFilter

The AuditTextFilter element is a simple element that contains parsed character data. The content of this element is used as a pattern match string to match against audit text for previous transactions made to the SRS. The content should be a valid text filter (Text Filter).

Syntax:

<!ELEMENT AuditTextFilter (#PCDATA)>

8.7.  CancelAuditText

The CancelAuditText element is a simple element that contains parsed character data. The content of this element is used to hold the text of an audit message provided during cancellation of a scheduled process in the SRS. It is used by the Schedule (Schedule) response element.

Syntax:

<!ELEMENT CancelAuditText (#PCDATA)>

8.8.  BaseMonth

The BaseMonth element is an empty element. It has a single attribute, Month, that must contain a valid month value in the range 1 to 12.

Syntax:

<!ELEMENT BaseMonth EMPTY>
<!ATTLIST BaseMonth
        Month %Number; #REQUIRED>

8.9.  BaseYear

The BaseYear element is an empty element. It has a single attribute, Year, that must contain a valid year value.

Syntax:

<!ELEMENT BaseYear EMPTY>
<!ATTLIST BaseYear
        Year %Number; #REQUIRED>

8.10.  Contact Details Elements

The SRS protocol employs many contact details elements that all share a common definition. The contact details elements are:

• AdminContact
• DefaultTechnicalContact
• RegistrantContact
• RegistrarPublicContact
• RegistrarSRSContact
• TechnicalContact

The contact details elements are defined using the Contact (Contact) entity definition for the element content, and the ContactAttr (ContactAttr) entity for the element attribute definitions.

The contact details elements have Name and Email attributes to store the contact name and email address; either attribute may be omitted where appropriate. The contact details elements may also include elements for PostalAddress (PostalAddress), Phone (Telephone Number Details), and Fax (Telephone Number Details) details.

Syntax:

<!ELEMENT AdminContact (%Contact;)>
<!ATTLIST AdminContact %ContactAttr;>

<!ELEMENT DefaultTechnicalContact (%Contact;)>
<!ATTLIST DefaultTechnicalContact %ContactAttr;>

<!ELEMENT RegistrantContact (%Contact;)>
<!ATTLIST RegistrantContact %ContactAttr;>

<!ELEMENT RegistrarPublicContact (%Contact;)>
<!ATTLIST RegistrarPublicContact %ContactAttr;>

<!ELEMENT RegistrarSRSContact (%Contact;)>
<!ATTLIST RegistrarSRSContact %ContactAttr;>

<!ELEMENT TechnicalContact (%Contact;)>
<!ATTLIST TechnicalContact %ContactAttr;>

Example:

<AdminContact Name="John Doe" Email="john_doe@example.org">
    <PostalAddress Address1="1 Example Street" Address2=""
        City="Example" CountryCode="NZ" PostalCode="99001"
        Province="" />
    <Phone CountryCode="99" AreaCode="8" LocalNumber="555-5678"/>
    <Fax CountryCode="99" AreaCode="8" LocalNumber="555-5679"/>
</AdminContact>

8.11.  Contact Details Search Filters

The contact details search filter elements all share a common definition referenced from the ContactFilter (ContactFilter) entity definition for the element content, and the ContactFilterAttr (ContactFilterAttr) entity for the element attribute definitions. The contact details filters are used to provide fields for matching against stored contact details when using the DomainDetailsQry (DomainDetailsQry) request. Only the details provided in the filter are used to match against stored values in the SRS, this enables general matches, for instance, to select all domains with a particular administrative contact name.

The contact details filter elements have the same structure as the contact details elements. Name and Email attributes specify the match values for contact name and email address; either attribute may be omitted where appropriate. The contact details filter elements may also include filter details elements for PostalAddress (PostalAddressFilter), Phone (Telephone Number Details), and Fax (Telephone Number Details) details.

Syntax:

<!ELEMENT AdminContactFilter (%ContactFilter;)>
<!ATTLIST AdminContactFilter %ContactAttrFilter;>

<!ELEMENT RegistrantContactFilter (%ContactFilter;)>
<!ATTLIST RegistrantContactFilter %ContactAttrFilter;>

<!ELEMENT TechnicalContactFilter (%ContactFilter;)>
<!ATTLIST TechnicalContactFilter %ContactAttrFilter;>

8.12.  CreateAuditText

The CreateAuditText element is a simple element that contains parsed character data. The content of this element is used to hold the text of an audit message provided during creation of a scheduled process in the SRS. It is used by the Schedule (Schedule) response element.

Syntax:

<!ELEMENT CreateAuditText (#PCDATA)>

8.13.  Date Range Elements

The SRS protocol employs many date range elements that all share a common definition. The date range elements are:

• AuditTime
• BilledUntilDateRange
• CancelledDateRange
• ChangedInDateRange
• InvoiceDateRange
• LockedDateRange
• LogDateRange
• RegisteredDateRange
• ResultDateRange
• SearchDateRange
• TransDateRange

The content of the date range elements is defined using the DateRange (DateRange) entity. The date range elements can contain two optional elements, a From (Timestamp Elements) date and a To (Timestamp Elements) date, that define the start and end of a range of dates.

If the From date is omitted, SRS implementations SHOULD use the earliest action in the system as the From date value. If the To date is omitted, SRS implementation SHOULD use the current date as the To date value.

Syntax:

<!ELEMENT AuditTime            (%DateRange;)>

<!ELEMENT BilledUntilDateRange (%DateRange;)>

<!ELEMENT CancelledDateRange   (%DateRange;)>

<!ELEMENT ChangedInDateRange   (%DateRange;)>

<!ELEMENT InvoiceDateRange     (%DateRange;)>

<!ELEMENT LockedDateRange      (%DateRange;)>

<!ELEMENT LogDateRange         (%DateRange;)>

<!ELEMENT RegisteredDateRange  (%DateRange;)>

<!ELEMENT ResultDateRange      (%DateRange;)>

<!ELEMENT SearchDateRange      (%DateRange;)>

<!ELEMENT TransDateRange       (%DateRange;)>

Example of a ResultDateRange element:

<ResultDateRange>
    <From Year="2008" Month="01" Day="01" Hour="00"
        Minute="00" Second="00" TimeZoneOffset="+13:00" />
    <To Year="2008" Month="01" Day="31" Hour="23"
        Minute="59" Second="59" TimeZoneOffset="+13:00" />
</ResultDateRange>

8.14.  Description

The Description element is a simple element that contains parsed character data. The content of this element is a text description of an error condition. It is used by the Error (Error) element.

Syntax:

<!ELEMENT Description (#PCDATA)>

8.15.  DomainNameFilter

The DomainNameFilter element is a simple element that contains parsed character data. The content of this element is used as a pattern match string to match against the names of domains registered in the SRS. The content should be a valid text filter (Text Filter) for matching against domain names.

Syntax:

<!ELEMENT DomainNameFilter (#PCDATA)>

8.16.  EncryptKey

The EncryptKey element is a simple element that contains parsed character data. The content of this element will be an ASCII armored copy of a registrar's OpenPGP-compatible public key. It is used by the EncryptKeys (EncryptKeys) element.

Syntax:

<!ELEMENT EncryptKey (#PCDATA)>

8.17.  EncryptKeys

The EncryptKeys element is a simple simple container for EncryptKey (EncryptKey) elements. It is used when creating and updating registrars and when the SRS returns details of registrars.

Syntax:

<!ELEMENT EncryptKeys (EncryptKey*)>

8.18.  ErrorDetails

The ErrorDetails element is a simple element that contains parsed character data. The content of this element is a text description providing further details about an error condition. It is used by the Error (Error) element.

Syntax:

<!ELEMENT ErrorDetails (#PCDATA)>

8.19.  FieldList

The FieldList element is an empty element with a set of Boolean (Boolean) attributes. It is used in the DomainDetailsQry (DomainDetailsQry) request to specify the domain details to return for matching domains in the SRS.

The domain details that may be requested and their FieldList attributes are:

Status:

The registration status of the domain ("Active" or "PendingRelease").

NameServers:

The list of name servers that the domain is delegated to.

RegisteredDate:

The date and time that the domain was registered.

AdminContact:

The domain's administrative contact details.

RegistrantContact:

The domain's registrant contact details.

TechnicalContact:

The domain's technical contact details.

LockedDate:

The date that a locked domain was locked.

Delegate:

Whether the domain is delegated in the DNS system.

RegistrarId:

The registry-assigned registrar number.

RegistrarName:

The name of the registrar that manages the domain.

RegistrantRef:

The personal reference for the registrant of the domain.

LastActionId:

The unique identifier for the last transaction that amended the domain details in the SRS.

ChangedByRegistrarId:

The identifier of the registrar that last updated the domain.

Term:

The billing term for the domain registration.

BilledUntil:

The date and time that the domain has been billed until.

CancelledDate:

The date that a cancelled domain registration was cancelled.

AuditText:

The audit text for changes to the domain. This is an optional reference for the user.

EffectiveFrom:

The date that this domain record was replaced.

Syntax:

<!ELEMENT FieldList EMPTY>
<!ATTLIST FieldList
        Status               %Boolean; #IMPLIED
        NameServers          %Boolean; #IMPLIED
        RegistrantContact    %Boolean; #IMPLIED
        RegisteredDate       %Boolean; #IMPLIED
        AdminContact         %Boolean; #IMPLIED
        TechnicalContact     %Boolean; #IMPLIED
        LockedDate           %Boolean; #IMPLIED
        Delegate             %Boolean; #IMPLIED
        RegistrarId          %Boolean; #IMPLIED
        RegistrarName        %Boolean; #IMPLIED
        RegistrantRef        %Boolean; #IMPLIED
        LastActionId         %Boolean; #IMPLIED
        ChangedByRegistrarId %Boolean; #IMPLIED
        Term                 %Boolean; #IMPLIED
        BilledUntil          %Boolean; #IMPLIED
        CancelledDate        %Boolean; #IMPLIED
        AuditText            %Boolean; #IMPLIED
        EffectiveFrom        %Boolean; #IMPLIED>

8.20.  IncomeMonth

The IncomeMonth element is an empty element. It has a single attribute, Month, that must contain a valid month value in the range 1 to 12.

Syntax:

<!ELEMENT IncomeMonth EMPTY>
<!ATTLIST IncomeMonth
        Month %Number; #REQUIRED>

8.21.  IncomeYear

The IncomeYear element is an empty element. It has a single attribute, Year, that must contain a valid year value.

Syntax:

<!ELEMENT IncomeYear EMPTY>
<!ATTLIST IncomeYear
        Year %Number; #REQUIRED>

8.22.  NameServers

The NameServers element is a simple container for Server (Server) elements. It is used when creating and updating domains and when the SRS returns details of the name servers for domains. SRS implementations MAY set a limit on the number of server elements that can be provided.

Syntax:

<!ELEMENT NameServers (Server*)>

8.23.  NameServerFilter

The NameServerFilter element is a simple container for ServerFilter (ServerFilter) elements. It is used in the DomainDetailsQry (DomainDetailsQry) request to specify name server details to match against the details of domains in the SRS.

If multiple ServerFilter elements are provided, the SRS should return domain results that match any of the provided filters (assuming that other filter restrictions are also met).

Syntax:

<!ELEMENT NameServerFilter (ServerFilter+)>

8.24.  ParamValue

The ParamValue element is a simple element that contains parsed character data. The content of this element is the value of an SRS system parameter. It is used by the SysParam (SysParam) element.

Syntax:

<!ELEMENT ParamValue       (#PCDATA)>

8.25.  PostalAddress

The PostalAddress element is an empty element with attributes for describing postal address details. SRS implementations SHOULD validate the CountryCode as a valid ISO 3166 (International Organization for Standardization, “Codes for the representation of names of countries, 3rd edition,” August 1988.) [ISO.3166.1988] two-letter country code.

Syntax:

<!ELEMENT PostalAddress EMPTY>
<!ATTLIST PostalAddress
        Address1    CDATA #IMPLIED
        Address2    CDATA #IMPLIED
        City        CDATA #IMPLIED
        Province    CDATA #IMPLIED
        CountryCode CDATA #IMPLIED
        PostalCode  CDATA #IMPLIED>

8.26.  PostalAddressFilter

The PostalAddressFilter element is an empty element with attributes for describing postal address details to match against details held by the SRS.

Syntax:

<!ELEMENT PostalAddressFilter EMPTY>
<!ATTLIST PostalAddressFilter
        Address1    CDATA #IMPLIED
        Address2    CDATA #IMPLIED
        City        CDATA #IMPLIED
        Province    CDATA #IMPLIED
        CountryCode CDATA #IMPLIED
        PostalCode  CDATA #IMPLIED>

8.27.  Telephone Number Details

There are two telephone number details elements that share a common definition:

• Fax
• Phone

The telephone number details elements are empty elements that use the PhoneAttr (PhoneAttr) entity for attribute declarations.

Syntax:

<!ELEMENT Fax EMPTY>
<!ATTLIST Fax %PhoneAttr;>

<!ELEMENT Phone EMPTY>
<!ATTLIST Phone %PhoneAttr;>

8.28.  Role

The Role element is an empty element. It has a single attribute, RoleName, that must contain a value as defined by the Role (Role) entity.

Syntax:

<!ELEMENT Role EMPTY>
<!ATTLIST Role
        RoleName (%Role;) #REQUIRED>

8.29.  Roles

The Roles element is a simple container for Role (Role) elements. It is used when creating and updating registrars and when the SRS returns details of registrars.

Syntax:

<!ELEMENT Roles (Role*)>

8.30.  RunLogDetails

The RunLogDetails element is a simple element that contains parsed character data. The content of this element is the value of an SRS system parameter. It is used by the SysParam (SysParam) element and contains process data to be stored in the SRS log.

Syntax:

<!ELEMENT RunLogDetails (#PCDATA)>

8.31.  SecondLD

The SecondLD element is an empty element. It has a single attribute, DomainName, that will contain a subdomain for which a given registrar has domain registration privileges. It is used by the Allowed2LDs (Allowed2LDs) element.

The SecondLD element MAY contain subdomains at any level in the domain name system hierarchy that the registry supports registrations for. It is not technically restricted to second level domains.

Syntax:

<!ELEMENT SecondLD EMPTY>
<!ATTLIST SecondLD
        DomainName %DomainName; #REQUIRED>

8.32.  Server

The Server element is an empty element. It has three attributes:

FQDN:

The fully qualified domain name of the server.

IP4Addr:

The IPv4 address of the server.

IP6Addr:

The IPv6 address of the server.

The fully qualified domain name is a required attribute. The IP address fields should only be included if the fully qualified domain name is within the domain that the server is a name server for.

The IP4Addr value should be given in standard dotted-decimal notation, for example, 192.0.2.14

The IP6Addr value should be given in any of the formats described in RFC 4291 (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.) [RFC4291], for example:

Fully specified (preferred form):

2001:DB8:0:0:0:0:C000:20E

Compressed form:

2001:DB8::C000:20E

Alternative form:

2001:DB8:0:0:0:0:192.0.2.14 (or 2001:DB8::192.0.2.14)

The Server element is used by the NameServers (NameServers) element to specify name server details.

Syntax:

<!ELEMENT Server EMPTY>
<!ATTLIST Server
        FQDN    CDATA #REQUIRED
        IP4Addr CDATA #IMPLIED
        IP6Addr CDATA #IMPLIED>

8.33.  ServerFilter

The ServerFilter element is an empty element. It has the same attributes as the Server (Server) element, however all of the attributes are optional in the ServerFilter element. The content of the ServerFilter attributes is used to match against name server details held by the SRS.

The ServerFilter element is used by the NameServerFilter (NameServerFilter) element to specify the server details to match.

Syntax:

<!ELEMENT ServerFilter EMPTY>
<!ATTLIST ServerFilter
        FQDN    CDATA #IMPLIED
        IP4Addr CDATA #IMPLIED
        IP6Addr CDATA #IMPLIED>

8.34.  Signature

The Signature element is a simple element that contains parsed character data. The content of this element is the OpenPGP-compatible signature of a request message in ASCII armored format and encoded in UTF-8. It is used by the RawRequest and RawResponse (RawRequest and RawResponse) elements when returning details of previous SRS transactions.

Syntax:

<!ELEMENT Signature (#PCDATA)>

8.35.  Timestamp Elements

The SRS protocol employs many timestamp elements that all share a common definition. The timestamp elements are:

• ActiveOn
• BilledUntil
• BillPeriodEnd
• BillPeriodStart
• CancelledDate
• EffectiveDate
• FeTimeStamp
• FinalRunDate
• FirstRunDate
• From
• InvoiceDate
• LastRunDate
• LockedDate
• NewBilledUntilDate
• RegisteredDate
• RunDate
• RunLogTimeStamp
• To
• TransactionDate
• TransDate

The timestamp elements are empty elements that use the TimeStamp (TimeStamp) entity for attribute declarations.

Syntax:

<!ELEMENT ActiveOn           EMPTY>
<!ATTLIST ActiveOn           %TimeStamp;>

<!ELEMENT BilledUntil        EMPTY>
<!ATTLIST BilledUntil        %TimeStamp;>

<!ELEMENT BillPeriodEnd      EMPTY>
<!ATTLIST BillPeriodEnd      %TimeStamp;>

<!ELEMENT BillPeriodStart    EMPTY>
<!ATTLIST BillPeriodStart    %TimeStamp;>

<!ELEMENT CancelledDate      EMPTY>
<!ATTLIST CancelledDate      %TimeStamp;>

<!ELEMENT EffectiveDate      EMPTY>
<!ATTLIST EffectiveDate      %TimeStamp;>

<!ELEMENT FeTimestamp        EMPTY>
<!ATTLIST FeTimestamp        %TimeStamp;>

<!ELEMENT FinalRunDate       EMPTY>
<!ATTLIST FinalRunDate       %TimeStamp;>

<!ELEMENT FirstRunDate       EMPTY>
<!ATTLIST FirstRunDate       %TimeStamp;>

<!ELEMENT From               EMPTY>
<!ATTLIST From               %TimeStamp;>

<!ELEMENT InvoiceDate        EMPTY>
<!ATTLIST InvoiceDate        %TimeStamp;>

<!ELEMENT LastRunDate        EMPTY>
<!ATTLIST LastRunDate        %TimeStamp;>

<!ELEMENT LockedDate         EMPTY>
<!ATTLIST LockedDate         %TimeStamp;>

<!ELEMENT NewBilledUntilDate EMPTY>
<!ATTLIST NewBilledUntilDate %TimeStamp;>

<!ELEMENT RegisteredDate     EMPTY>
<!ATTLIST RegisteredDate     %TimeStamp;>

<!ELEMENT RunDate            EMPTY>
<!ATTLIST RunDate            %TimeStamp;>

<!ELEMENT RunLogTimeStamp    EMPTY>
<!ATTLIST RunLogTimeStamp    %TimeStamp;>

<!ELEMENT To                 EMPTY>
<!ATTLIST To                 %TimeStamp;>

<!ELEMENT TransactionDate    EMPTY>
<!ATTLIST TransactionDate    %TimeStamp;>

<!ELEMENT TransDate          EMPTY>
<!ATTLIST TransDate          %TimeStamp;>

Example of an EffectiveDate element:

<EffectiveDate Year="2007" Month="11" Day="19" Hour="12"
    Minute="00" Second="00" TimeZoneOffset="+13:00" />

8.36.  TransferredDomain

The TransferredDomain element is a simple element that contains parsed character data. The content of the element is the domain name of a domain that has been transferred from one registrar to another. It is used by the DomainTransfer (DomainTransfer) element.

Syntax:

<!ELEMENT TransferredDomain (#PCDATA)>

8.37.  XML

The XML element is a simple element that contains parsed character data. The content of this element is the XML content of a request or response message encoded in UTF-8. It is used by the RawRequest and RawResponse (RawRequest and RawResponse) elements when returning details of previous SRS transactions.

Syntax:

<!ELEMENT XML (#PCDATA)>

9.  Internal Entities

The XML DTD for the SRS communications protocol uses internal entities to provide common definitions in the DTD. These entities also enhance the readability of the DTD.

9.1.  Actions

9.1.1.  DomainWriteAction

The DomainWriteAction entity defines the valid values for attributes that hold the name of a domain write request.

Definition:

<!ENTITY % DomainWriteAction "DomainCreate|
                              DomainUpdate">

9.1.2.  DomainQueryAction

The DomainQueryAction entity defines the valid values for attributes that hold the name of a domain query request.

Definition:

<!ENTITY % DomainQueryAction "Whois|
                              DomainDetailsQry|
                              ActionDetailsQry|
                              UDAIValidQry">

9.1.3.  RegistrarWriteAction

The RegistrarWriteAction entity defines the valid values for attributes that hold the name of a registrar write request.

Definition:

<!ENTITY % RegistrarWriteAction "RegistrarCreate|
                                 RegistrarUpdate">

9.1.4.  RegistrarQueryAction

The RegistrarQueryAction entity defines the valid values for attributes that hold the name of a registrar query request.

Definition:

<!ENTITY % RegistrarQueryAction "RegistrarDetailsQry|
                                 RegistrarAccountQry|
                                 GetMessages">

9.1.5.  RegistryAction

The RegistryAction entity defines the valid values for attributes that hold the name of a registry request.

Definition:

<!ENTITY % RegistryAction "SysParamsUpdate|
                           SysParamsQry|
                           RunLogCreate|
                           RunLogQry|
                           ScheduleCreate|
                           ScheduleCancel|
                           ScheduleQry|
                           ScheduleUpdate|
                           BillingExtract|
                           SetBillingAmount|
                           QryBillingAmount|
                           DeferredIncomeSummaryQry|
                           DeferredIncomeDetailQry|
                           BilledUntilAdjustment|
                           BuildDnsZoneFiles|
                           GenerateDomainReport|
                           AdjustRegistrarAccount|
                           AccessControlListQry|
                           AccessControlListAdd|
                           AccessControlListRemove">

9.1.6.  Action

The Action entity defines the valid values for attributes that hold the name of an SRS request. It is defined in terms of the various action entity definitions.

Definition:

<!ENTITY % Action "%DomainWriteAction;|
                   %DomainQueryAction;|
                   %RegistrarWriteAction;|
                   %RegistrarQueryAction;|
                   %RegistryAction;"

9.2.  Accounts

9.2.1.  AccountingAction

The AccountingAction entity defines the valid values for attributes that hold the name of an accounting action type.

Definition:

<!ENTITY % AccountingAction "Credit|
                             Debit>

9.2.2.  BillStatus

The BillStatus entity defines the valid values for attributes that hold the name of a billing status.

Definition:

<!ENTITY % BillStatus "PendingConfirmation|
                       Confirmed">

9.3.  Booleans

9.3.1.  True

The True entity defines a fixed integer value for true boolean values in the SRS protocol.

Definition:

<!ENTITY % True "1">

9.3.2.  False

The False entity defines a fixed integer value for false boolean values in the SRS protocol.

Definition:

<!ENTITY % False "0">

9.3.3.  Boolean

The Boolean entity defines the valid values for attributes that hold a boolean value.

Definition:

<!ENTITY % Boolean "(%False;|%True;)">

9.4.  Contact Details

9.4.1.  Contact

The Contact entity defines a content model for elements that contain contact details.

Definition:

<!ENTITY % Contact "PostalAddress?,Phone?,Fax?">

9.4.2.  ContactAttr

The ContactAttr entity defines the attribute specification for elements that contain contact details.

Definition:

<!ENTITY % ContactAttr "Name  CDATA #IMPLIED
                        Email CDATA #IMPLIED">

9.5.  Contact Details Filters

9.5.1.  ContactFilter

The ContactFilter entity defines a content model for elements that contain contact filter details.

Definition:

<!ENTITY % ContactFilter "PostalAddressFilter?,Phone?,Fax?">

9.5.2.  ContactFilterAttr

The ContactFilterAttr entity defines the attribute specification for elements that contain contact filter details.

Definition:

<!ENTITY % ContactAttrFilter "Name  CDATA #IMPLIED
                              Email CDATA #IMPLIED">

9.6.  Currency

9.6.1.  Dollars

The Dollars entity defines a value definition for attributes that contain currency values. SRS implementations SHOULD ensure that values given and received in attributes of this type conform to valid values in their registry's working currency.

Definition:

<!ENTITY % Dollars "CDATA">

9.7.  Dates And Times

9.7.1.  Date

The Date entity defines the attribute specification for elements that contain date details.

Definition:

<!ENTITY % Date "Year  %Number; #REQUIRED
                 Month %Number; #REQUIRED
                 Day   %Number; #REQUIRED">

9.7.2.  Time

The Time entity defines the attribute specification for elements that contain time details. SRS implementations MAY use their local timezone offset from UTC as a default value for TimeZoneOffset if this field is not populated.

Definition:

<!ENTITY % Time "Hour           %Number; #REQUIRED
                 Minute         %Number; #REQUIRED
                 Second         %Number; #IMPLIED
                 TimeZoneOffset CDATA    #IMPLIED">

9.7.3.  TimeStamp

The TimeStamp entity defines a composite attribute specification for elements that contain a combined date and time value. It is defined in terms of the Date (Date) and Time (Time) entities.

Definition:

<!ENTITY % TimeStamp "%Date; %Time;">

9.7.4.  DateRange

The DateRange entity defines a content model for elements that contain a start date and time and an end date and time. Such elements consist of an optional From (Timestamp Elements) element and an optional To (Timestamp Elements) element. Both the From and To element are empty elements with attributes as defined in the TimeStamp (TimeStamp) entity.

Definition:

<!ENTITY % DateRange "From?,To?">

9.8.  Domain Names

9.8.1.  DomainName

The DomainName entity defines the valid value definition for attributes that hold a domain name.

Definition:

<!ENTITY % DomainName "CDATA">

9.9.  Domain Status

9.9.1.  RegDomainStatus

The RegDomainStatus entity defines the valid values for attributes that hold the status of registered domains.

Definition:

<!ENTITY % RegDomainStatus "Active|
                            PendingRelease">

9.9.2.  DomainStatus

The DomainStatus entity defines the valid values for attributes that hold the status of both registered and unregistered domains.

Definition:

<!ENTITY % DomainStatus "%RegDomainStatus;|
                         Available">

9.10.  Duration

9.10.1.  Term

The Term entity defines the valid value definition for attributes that hold a timespan. Generally this will be an integer number of months representing the registry's billing cycle for registered domains.

Definition:

<!ENTITY % Term "%Number;">

9.11.  Numeric

9.11.1.  Number

The Number entity defines the valid value definition for attributes that hold a number. SRS implementations SHOULD ensure that data provided in such attributes is numeric.

Definition:

<!ENTITY % Number "CDATA">

9.12.  Registrar Identifiers

9.12.1.  RegistrarId

The RegistrarId entity defines the valid value definition for attributes that hold a registrar identifier. Registrar identifiers in the SRS are numeric and this entity is defined in terms of the Number (Number) entity.

Registrar identifiers are assigned to registrars for performing registrar functions and to the registry for performing registry functions.

The registry may have more than one identity, with each identity having separate roles and permissions in the system. The registry's registrar identifiers should be known to registrars so that registrars can identify actions performed by the registry.

Definition:

<!ENTITY % RegistrarId "%Number;">

9.12.2.  RegistrarIdOrOTHERS

The RegistrarIdOrOTHERS entity defines the valid value definition for attributes that hold a registrar identifier or the special value "OTHERS". SRS Implementations SHOULD ensure that data provided in such attributes is either a valid registrar identifier or the string "OTHERS". The value "OTHERS" may be used instead of a registrar identifier in some cases, for example when using the GetMessages (GetMessages) request, to specify a registrar identifier other than the registrar making the request.

Definition:

<!ENTITY % RegistrarIdOrOTHERS "CDATA">

9.13.  Responses

9.13.1.  ActionResponse

The ActionResponse entity defines the valid values for attributes that hold the name of an action response type.

Definition:

<!ENTITY % ActionResponse "Error|
                           Domain*|
                           UDAIValid|
                           DomainTransfer|
                           BillingTrans*|
                           DeferredRegistrarIncome*|
                           Registrar*|
                           SysParam*|
                           RunLog*|
                           Schedule*|
                           AccessControlList*|
                           (RawRequest,RawResponse)|
                           BillingAmount*">

9.14.  System Roles

9.14.1.  Role

The Role entity defines the valid values for attributes that hold the name of a system role type. Roles may be used by implementations to restrict the requests that users (typically registrars) have access to.

Definition:

<!ENTITY % Role "Registrar|
                 Registry|
                 Whois|
                 Query|
                 CreateDomain|
                 UpdateDomain|
                 TransferDomain|
                 CancelDomain|
                 UncancelDomain|
                 UpdateRegistrar|
                 Administer|
                 Supervisor|
                 Connect|
                 ReleaseDomain|
                 QueryACL|
                 UpdateACL">

9.15.  Scheduled Processes

9.15.1.  ScheduledJob

The ScheduledJob entity defines the valid values for attributes that hold the name of a scheduled job type.

Definition:

<!ENTITY % ScheduledJob "BuildDnsZoneFiles|
                         ReleaseDomains|
                         RenewDomains|
                         GenerateDomainReport|
                         GenerateStatsReport"

9.16.  Telephone Numbers

9.16.1.  PhoneAttr

The PhoneAttr entity defines the attribute specification for elements that telephone or fax number details.

Definition:

<!ENTITY % PhoneAttr "CountryCode %NumberFilter; #IMPLIED
                      AreaCode    %NumberFilter; #IMPLIED
                      LocalNumber %NumberFilter; #IMPLIED">

9.17.  Unique Identifiers

9.17.1.  UID

The UID entity defines a value definition for attributes that contain unique identifier values.

Definition:

<!ENTITY % UID "CDATA">

10.  Text Filter

The text filter provides support for case-insensitive matching of a character string against information held in the SRS. Two wildcard characters are supported:

Note: when a text filter pattern is used for matching against domain names, the wildcard characters will not match the dot-separator character. The only exception to this is when the * wildcard is used at the start of the text filter pattern, in this case the wildcard may match any characters, as shown in the examples below.

Text filter pattern matching examples for domain names:

11.  Security Considerations

Care should be taken to ensure that no private data is sent over any unsecured transport. HTTPS MUST be used for all transactions involving private data - that is, data that cannot be retrieved using the public WHOIS system.

The exchange of public keys between registry and registrar when a new registrar is created in the SRS SHOULD be handled in a secure way with careful identity verification by both parties.

Storage of private keys by the registry and the registrar must be handled carefully to avoid compromise. Keys should be changed on an occasional basis, according to current best practice, to ensure that the SRS remains secure. The registrar may provide the registry with more than one valid public key to support migration from one key to another and the expiration of old keys.

Registrars MUST be restricted to only viewing data that is publicly available (that is, data that can be retrieved using the public WHOIS system), and data that they manage. Registrars MUST NOT be able to access through the SRS registry information that is managed by other registrars and is not available through the public WHOIS system.

The registry SHOULD access all requests and data through the SRS system. This allows the implementation to ensure that there is only a single way to access the system functions and data.

12.  IANA Considerations

This document has no actions for IANA.

13.  References

13.1. Normative References

13.2. Informative References

Appendix A.  Example

This example shows a typical request and response document. The example does not show the full format of the multipart request body that must be sent to the server for a request.

A.1.  Whois request

Example of a Whois request (formatted for readability):

C: n=50041&r=<!DOCTYPE NZSRSRequest SYSTEM "protocol.dtd">
C: <NZSRSRequest VerMajor="2" VerMinor="0" RegistrarId="500411">
C:    <Whois FullResult="0" DomainName="example.org"/>
C: </NZSRSRequest>
C: &s=-----BEGIN PGP SIGNATURE-----
C: Version: Crypt::OpenPGP 1.03
C:
C: iQBGBAARAgAGBQJHtLqmAAoJECvUc6XZCUibvs4An2qp5xHugp7tOjO4pmxTqb3k
C: N63OAJ44F+/O3bsRhIGoqrCjvg1hlFAK0A==
C: =5C/k
C: -----END PGP SIGNATURE-----

S: r=<?xml version="1.0"?>
S: <!DOCTYPE NZSRSResponse SYSTEM "protocol.dtd">
S: <NZSRSResponse VerMajor="2" VerMinor="0" RegistrarId="1">
S:    <Response Action="Whois" FeId="7" FeSeq="1996051"
S:        OrigRegistrarId="1" RecipientRegistrarId="1">
S:       <FeTimeStamp Day="15" Hour="11" Minute="03" Month="2"
S:              Second="18" TimeZoneOffset=" 13:00" Year="2008"/>
S:       <Domain DomainName="example.org" Status="Active"/>
S:    </Response>
S: </NZSRSResponse>
S: &s=-----BEGIN PGP SIGNATURE-----
S: Version: Crypt::OpenPGP 1.03
S:
S: iQBGBAARAgAGBQJHtLqmAAoJENi/K6P6QHemSbgAn2W3SQFFZzI1GKbGbiJZtq4w
S: k7SxAJ491nPIkU/8kJvJ+No+Ysiph19Whw==
S: =r5Vn
S: -----END PGP SIGNATURE-----

Appendix B.  Acknowledgements

The author would like to thank the following groups and individuals for reviewing this document in draft format and providing very helpful comments and advice.

• The SRS Implementation Team at Catalyst IT Limited - Steven Craig, Evan Giles, John Praill, Andrew Ruthven, and Sam Vilain.
• Dave Baker of .nz Registry Services

Appendix C.  DTD

Complete DTD for the SRS protocol:

<!-- DTD for NZ Shared Registry System Protocol -->

<!-- Entity declarations -->

<!ENTITY % Number "CDATA">

<!ENTITY % NumberFilter "CDATA">

<!ENTITY % Dollars "CDATA">

<!ENTITY % True "1">

<!ENTITY % False "0">

<!ENTITY % Boolean "(%False;|%True;)">

<!ENTITY % Date "Year  %Number; #REQUIRED
        Month %Number; #REQUIRED
        Day   %Number; #REQUIRED">

<!ENTITY % Time "Hour           %Number; #REQUIRED
                 Minute         %Number; #REQUIRED
                 Second         %Number; #IMPLIED
                 TimeZoneOffset CDATA    #IMPLIED">

<!ENTITY % TimeStamp "%Date; %Time;">

<!ENTITY % DomainName "CDATA">

<!ENTITY % UID "CDATA">

<!ENTITY % Term "%Number;">

<!ENTITY % RegistrarId "%Number;">

<!ENTITY % RegistrarIdOrOTHERS "CDATA">

<!ENTITY % DomainWriteAction "DomainCreate|DomainUpdate">

<!ENTITY % DomainQueryAction "Whois|DomainDetailsQry|
                              ActionDetailsQry|UDAIValidQry">

<!ENTITY % RegistrarWriteAction "RegistrarCreate|RegistrarUpdate">

<!ENTITY % RegistrarQueryAction "RegistrarDetailsQry|
                                 RegistrarAccountQry|GetMessages">

<!ENTITY % RegistryAction "SysParamsUpdate|SysParamsQry|
                           RunLogCreate|RunLogQry|
                           ScheduleCreate|ScheduleCancel|
                           ScheduleQry|ScheduleUpdate|
                           BillingExtract|SetBillingAmount|
                           QryBillingAmount|
                           DeferredIncomeSummaryQry|
                           DeferredIncomeDetailQry|
                           BilledUntilAdjustment|
                           BuildDnsZoneFiles|
                           GenerateDomainReport|
                           AdjustRegistrarAccount|
                           AccessControlListQry|
                           AccessControlListAdd|
                           AccessControlListRemove">

<!ENTITY % Action "%DomainWriteAction;|%DomainQueryAction;|
        %RegistrarWriteAction;|%RegistrarQueryAction;|
        %RegistryAction;">

<!ENTITY % ActionResponse "Error|Domain*|UDAIValid|DomainTransfer|
                           BillingTrans*|DeferredRegistrarIncome*|
                           Registrar*|SysParam*|RunLog*|Schedule*|
                           AccessControlList*|
                           (RawRequest,RawResponse)|
                           BillingAmount*">

<!ENTITY % RegDomainStatus "Active|PendingRelease">

<!ENTITY % DomainStatus "%RegDomainStatus;|Available">

<!ENTITY % BillStatus "PendingConfirmation|Confirmed">

<!ENTITY % ScheduledJob "BuildDnsZoneFiles|ReleaseDomains|
                         RenewDomains|GenerateDomainReport|
                         GenerateStatsReport">

<!ENTITY % Contact "PostalAddress?,Phone?,Fax?">

<!ENTITY % ContactAttr "Name  CDATA #IMPLIED
                        Email CDATA #IMPLIED">

<!ENTITY % ContactFilter "PostalAddressFilter?,Phone?,Fax?">

<!ENTITY % ContactAttrFilter "Name  CDATA #IMPLIED
                              Email CDATA #IMPLIED">

<!ENTITY % PhoneAttr "CountryCode %NumberFilter; #IMPLIED
                      AreaCode    %NumberFilter; #IMPLIED
                      LocalNumber %NumberFilter; #IMPLIED">

<!ENTITY % Role "Registrar|Registry|Whois|Query|CreateDomain|
                 UpdateDomain|TransferDomain|CancelDomain|
                 UncancelDomain|UpdateRegistrar|Administer|
                 Supervisor|Connect|ReleaseDomain|QueryACL|
                 UpdateACL">

<!ENTITY % DateRange "From?,To?">

<!ENTITY % AccountingAction "Credit|Debit">

<!-- DATA ELEMENTS -->

<!-- Parsed character data elements -->

<!ELEMENT ActionIdFilter (#PCDATA)>

<!ELEMENT AuditText (#PCDATA)>

<!ELEMENT AuditTextFilter (#PCDATA)>

<!ELEMENT CancelAuditText (#PCDATA)>

<!ELEMENT CreateAuditText (#PCDATA)>

<!ELEMENT Description (#PCDATA)>

<!ELEMENT DomainNameFilter (#PCDATA)>

<!ELEMENT EncryptKey (#PCDATA)>

<!ELEMENT ErrorDetails (#PCDATA)>

<!ELEMENT ParamValue (#PCDATA)>

<!ELEMENT RunLogDetails (#PCDATA)>

<!ELEMENT Signature (#PCDATA)>

<!ELEMENT TransferredDomain (#PCDATA)>

<!ELEMENT XML (#PCDATA)>

<!-- Contact information: for registrant, admin, technical  -->
<!ELEMENT RegistrantContact       (%Contact;)>
<!ATTLIST RegistrantContact       %ContactAttr;>

<!ELEMENT RegistrantContactFilter (%ContactFilter;)>
<!ATTLIST RegistrantContactFilter %ContactAttrFilter;>

<!ELEMENT AdminContact            (%Contact;)>
<!ATTLIST AdminContact            %ContactAttr;>

<!ELEMENT AdminContactFilter      (%ContactFilter;)>
<!ATTLIST AdminContactFilter      %ContactAttrFilter;>

<!ELEMENT TechnicalContact        (%Contact;)>
<!ATTLIST TechnicalContact        %ContactAttr;>

<!ELEMENT TechnicalContactFilter  (%ContactFilter;)>
<!ATTLIST TechnicalContactFilter  %ContactAttrFilter;>

<!ELEMENT RegistrarPublicContact  (%Contact;)>
<!ATTLIST RegistrarPublicContact  %ContactAttr;>

<!ELEMENT DefaultTechnicalContact (%Contact;)>
<!ATTLIST DefaultTechnicalContact %ContactAttr;>

<!ELEMENT RegistrarSRSContact     (%Contact;)>
<!ATTLIST RegistrarSRSContact     %ContactAttr;>

<!-- Postal address -->
<!ELEMENT PostalAddress EMPTY>
<!ATTLIST PostalAddress
        Address1    CDATA #IMPLIED
        Address2    CDATA #IMPLIED
        City        CDATA #IMPLIED
        Province    CDATA #IMPLIED
        CountryCode CDATA #IMPLIED
        PostalCode  CDATA #IMPLIED>

<!-- Postal address filter -->
<!ELEMENT PostalAddressFilter EMPTY>
<!ATTLIST PostalAddressFilter
        Address1    CDATA #IMPLIED
        Address2    CDATA #IMPLIED
        City        CDATA #IMPLIED
        Province    CDATA #IMPLIED
        CountryCode CDATA #IMPLIED
        PostalCode  CDATA #IMPLIED>

<!-- Telephone numbers -->
<!ELEMENT Phone            EMPTY>
<!ATTLIST Phone            %PhoneAttr;>

<!ELEMENT Fax              EMPTY>
<!ATTLIST Fax              %PhoneAttr;>

<!-- Time stamps (date and time) -->
<!ELEMENT ActiveOn EMPTY>
<!ATTLIST ActiveOn %TimeStamp;>

<!ELEMENT BillPeriodEnd EMPTY>
<!ATTLIST BillPeriodEnd %TimeStamp;>

<!ELEMENT BillPeriodStart EMPTY>
<!ATTLIST BillPeriodStart %TimeStamp;>

<!ELEMENT BilledUntil EMPTY>
<!ATTLIST BilledUntil %TimeStamp;>

<!ELEMENT EffectiveDate EMPTY>
<!ATTLIST EffectiveDate %TimeStamp;>

<!ELEMENT FeTimeStamp EMPTY>
<!ATTLIST FeTimeStamp %TimeStamp;>

<!ELEMENT FinalRunDate EMPTY>
<!ATTLIST FinalRunDate %TimeStamp;>

<!ELEMENT FirstRunDate EMPTY>
<!ATTLIST FirstRunDate %TimeStamp;>

<!ELEMENT From EMPTY>
<!ATTLIST From %TimeStamp;>

<!ELEMENT InvoiceDate EMPTY>
<!ATTLIST InvoiceDate %TimeStamp;>

<!ELEMENT LastRunDate EMPTY>
<!ATTLIST LastRunDate %TimeStamp;>

<!ELEMENT NewBilledUntilDate EMPTY>
<!ATTLIST NewBilledUntilDate %TimeStamp;>

<!ELEMENT RunDate EMPTY>
<!ATTLIST RunDate %TimeStamp;>

<!ELEMENT RunLogTimeStamp EMPTY>
<!ATTLIST RunLogTimeStamp %TimeStamp;>

<!ELEMENT LockedDate EMPTY>
<!ATTLIST LockedDate %TimeStamp;>

<!ELEMENT RegisteredDate EMPTY>
<!ATTLIST RegisteredDate %TimeStamp;>

<!ELEMENT CancelledDate  EMPTY>
<!ATTLIST CancelledDate  %TimeStamp;>

<!ELEMENT To EMPTY>
<!ATTLIST To %TimeStamp;>

<!ELEMENT TransDate EMPTY>
<!ATTLIST TransDate %TimeStamp;>

<!ELEMENT TransactionDate EMPTY>
<!ATTLIST TransactionDate %TimeStamp;>

<!-- Date ranges  -->
<!ELEMENT AuditTime (%DateRange;)>

<!ELEMENT BilledUntilDateRange (%DateRange;)>

<!ELEMENT CancelledDateRange (%DateRange;)>

<!ELEMENT ChangedInDateRange (%DateRange;)>

<!ELEMENT LockedDateRange (%DateRange;)>

<!ELEMENT LogDateRange (%DateRange;)>

<!ELEMENT InvoiceDateRange (%DateRange;)>

<!ELEMENT RegisteredDateRange (%DateRange;)>

<!ELEMENT ResultDateRange (%DateRange;)>

<!ELEMENT SearchDateRange (%DateRange;)>

<!ELEMENT TransDateRange (%DateRange;)>

<!-- Base month for deferred income calculations -->
<!ELEMENT BaseMonth EMPTY>
<!ATTLIST BaseMonth
        Month %Number; #REQUIRED>

<!-- Base year for deferred income calculations -->
<!ELEMENT BaseYear EMPTY>
<!ATTLIST BaseYear
        Year %Number; #REQUIRED>

<!-- Income month for deferred income calculations -->
<!ELEMENT IncomeMonth EMPTY>
<!ATTLIST IncomeMonth
        Month %Number; #REQUIRED>

<!-- Income year for deferred income calculations -->
<!ELEMENT IncomeYear EMPTY>
<!ATTLIST IncomeYear
        Year %Number; #REQUIRED>

<!-- Name server container -->
<!ELEMENT NameServers (Server*)>

<!-- Server -->
<!ELEMENT Server EMPTY>
<!ATTLIST Server
        FQDN    CDATA #REQUIRED
        IP4Addr CDATA #IMPLIED
        IP6Addr CDATA #IMPLIED>

<!-- Name server filter -->
<!ELEMENT NameServerFilter    (ServerFilter+)>

<!-- Server filter -->
<!ELEMENT ServerFilter EMPTY>
<!ATTLIST ServerFilter
        FQDN    CDATA #IMPLIED
        IP4Addr CDATA #IMPLIED
        IP6Addr CDATA #IMPLIED>

<!-- Domain registration permission list -->
<!ELEMENT Allowed2LDs (SecondLD*)>
<!ELEMENT SecondLD EMPTY>
<!ATTLIST SecondLD
        DomainName %DomainName; #REQUIRED>

<!-- Registrar/user role definition -->
<!ELEMENT Roles (Role*)>
<!ELEMENT Role EMPTY>
<!ATTLIST Role
        RoleName (%Role;) #REQUIRED>

<!-- Encryption keys -->
<!ELEMENT EncryptKeys (EncryptKey*)>

<!-- Audit details element -->
<!ELEMENT AuditDetails (AuditTime?,AuditText?)>
<!ATTLIST AuditDetails
        RegistrarId CDATA #IMPLIED
        ActionId    %UID; #IMPLIED>

<!-- Access control list element -->
<!ELEMENT AccessControlList (AccessControlListEntry*)>
<!ATTLIST AccessControlList
        Resource CDATA #REQUIRED
        Type     CDATA #REQUIRED>

<!-- Access control list entry element -->
<!ELEMENT AccessControlListEntry (EffectiveDate?)>
<!ATTLIST AccessControlListEntry
        Address                CDATA                 #REQUIRED
        Comment                CDATA                 #IMPLIED>

<!-- Query field list -->
<!ELEMENT FieldList EMPTY>
<!ATTLIST FieldList
        Status               %Boolean; #IMPLIED
        NameServers          %Boolean; #IMPLIED
        RegistrantContact    %Boolean; #IMPLIED
        RegisteredDate       %Boolean; #IMPLIED
        AdminContact         %Boolean; #IMPLIED
        TechnicalContact     %Boolean; #IMPLIED
        LockedDate           %Boolean; #IMPLIED
        Delegate             %Boolean; #IMPLIED
        RegistrarId          %Boolean; #IMPLIED
        RegistrarName        %Boolean; #IMPLIED
        RegistrantRef        %Boolean; #IMPLIED
        LastActionId         %Boolean; #IMPLIED
        ChangedByRegistrarId %Boolean; #IMPLIED
        Term                 %Boolean; #IMPLIED
        BilledUntil          %Boolean; #IMPLIED
        CancelledDate        %Boolean; #IMPLIED
        AuditText            %Boolean; #IMPLIED
        EffectiveFrom        %Boolean; #IMPLIED>

<!-- REQUEST AND RESPONSE ROOT ELEMENTS -->

<!-- Root request element -->
<!ELEMENT NZSRSRequest ((%Action;)+)>
<!ATTLIST NZSRSRequest
        VerMajor    (1|2)         #REQUIRED
        VerMinor    %Number;      #REQUIRED
        RegistrarId %RegistrarId; #IMPLIED>

<!-- Root response element -->
<!ELEMENT NZSRSResponse (Response+|Error)>
<!ATTLIST NZSRSResponse
        VerMajor    (2)           #REQUIRED
        VerMinor    %Number;      #REQUIRED
        RegistrarId %RegistrarId; #IMPLIED>

<!-- SUCCESS RESPONSE CONTAINER -->
<!-- Response -->
<!ELEMENT Response (FeTimeStamp, (Response*|%ActionResponse;)?)>
<!ATTLIST Response
        Action               (%Action;|UnknownTransaction|
                              DomainTransfer)     #REQUIRED
        FeId                 %Number;             #REQUIRED
        FeSeq                %Number;             #REQUIRED
        OrigRegistrarId      %RegistrarId;        #REQUIRED
        TransId              %UID;                #IMPLIED
        Rows                 %Number;             #IMPLIED
        Count                %Number;             #IMPLIED
        MoreRowsAvailable    %Boolean;            #IMPLIED
        RecipientRegistrarId %RegistrarId;        #IMPLIED>

<!-- REQUEST ELEMENTS -->

<!-- Query previous request and response details
     Response: ((RawRequest,RawResponse)|Error) -->
<!ELEMENT ActionDetailsQry EMPTY>
<!ATTLIST ActionDetailsQry
        QryId                  %UID; #IMPLIED
        ActionId               %UID; #REQUIRED
        OriginatingRegistrarId %UID; #IMPLIED>

<!-- Query domain details
     Response: (Domain*|Error) -->
<!ELEMENT DomainDetailsQry (DomainNameFilter*,NameServerFilter?,
        RegistrantContactFilter?,
        AdminContactFilter?,TechnicalContactFilter?,
        ResultDateRange?,SearchDateRange?,
        ChangedInDateRange?,
        RegisteredDateRange?,LockedDateRange?,
        CancelledDateRange?,BilledUntilDateRange?,
        AuditTextFilter?,ActionIdFilter?,FieldList?)>
<!ATTLIST DomainDetailsQry
        QryId         %UID;               #IMPLIED
        Status        (%RegDomainStatus;) #IMPLIED
        Delegate      %Boolean;           #IMPLIED
        Term          %Term;              #IMPLIED
        RegistrantRef %UID;               #IMPLIED
        MaxResults    %Number;            #IMPLIED
        SkipResults   %Number;            #IMPLIED
        CountResults  %Boolean;           "0">

<!-- Query if the given UDAI matches the UDAI for a domain
     Response: (UDAIValid) -->
<!ELEMENT UDAIValidQry EMPTY>
<!ATTLIST UDAIValidQry
        QryId      %UID;        #IMPLIED
        DomainName %DomainName; #REQUIRED
        UDAI       %UID;        #REQUIRED>

<!-- Retrieve public details for a domain (WHOIS)
     Response: (Domain|Error) -->
<!ELEMENT Whois EMPTY>
<!ATTLIST Whois
        QryId      %UID;        #IMPLIED
        FullResult %Boolean;    "1"
        SourceIP   CDATA        #IMPLIED
        DomainName %DomainName; #REQUIRED>

<!-- Create new domain record
     Response: (Domain|Error) -->
<!ELEMENT DomainCreate (RegistrantContact,
        AdminContact?,
        TechnicalContact?,
        NameServers?,
        AuditText?)>
<!ATTLIST DomainCreate
        ActionId      %UID;        #REQUIRED
        DomainName    %DomainName; #REQUIRED
        RegistrantRef %UID;        #IMPLIED
        Term          %Term;       #REQUIRED
        Delegate      %Boolean;    "1">

<!-- Update domain record(s)
     Response: (Domain+|Error) -->
<!ELEMENT DomainUpdate (DomainNameFilter+,RegistrantContact?,
                        AdminContact?,TechnicalContact?,
                        NameServers?,AuditText?)>
<!ATTLIST DomainUpdate
        ActionId      %UID;     #REQUIRED
        UDAI          %UID;     #IMPLIED
        NewUDAI       %Boolean; #IMPLIED
        RegistrantRef %UID;     #IMPLIED
        Term          %Term;    #IMPLIED
        Delegate      %Boolean; #IMPLIED
        Renew         %Boolean; #IMPLIED
        NoAutoRenew   %Boolean; #IMPLIED
        Lock          %Boolean; #IMPLIED
        Cancel        %Boolean; #IMPLIED
        Release       %Boolean; #IMPLIED
        FullResult    %Boolean; "1">

<!-- Query access control list entries
     Response: (AccessControlList*|Error) -->
<!ELEMENT AccessControlListQry EMPTY>
<!ATTLIST AccessControlListQry
        Resource   CDATA     #IMPLIED
        Type       CDATA     #IMPLIED
        FullResult %Boolean; "0">

<!-- Remove access control list entries
     Response: (AccessControlList+|Error) -->
<!ELEMENT AccessControlListRemove (AccessControlListEntry+,
                                   AuditText)>
<!ATTLIST AccessControlListRemove
        Resource   CDATA     #REQUIRED
        Type       CDATA     #REQUIRED
        ActionId   %UID;     #REQUIRED
        FullResult %Boolean; "1">

<!-- Add access control list entries
     Response: (AccessControlList*|Error) -->
<!ELEMENT AccessControlListAdd (AccessControlListEntry+,
                                AuditText)>
<!ATTLIST AccessControlListAdd
        Resource   CDATA     #REQUIRED
        Type       CDATA     #REQUIRED
        ActionId   %UID;     #REQUIRED
        FullResult %Boolean; "1">

<!-- Get SRS generated messages for a registrar
     Response: (Response|Error) -->
<!ELEMENT GetMessages (TransDateRange?,AuditTextFilter?)>
<!ATTLIST GetMessages
        QryId                  %UID;                 #IMPLIED
        OriginatingRegistrarId %RegistrarIdOrOTHERS; #IMPLIED
        ActionId               %UID;                 #IMPLIED
        RecipientRegistrarId   %RegistrarId;         #IMPLIED
        MaxResults             %Number;              #IMPLIED
        SkipResults            %Number;              #IMPLIED
        CountResults           %Boolean;             "0">

<!-- Query registrar details
     Response: (Registrar*|Error) -->
<!ELEMENT RegistrarDetailsQry (ResultDateRange?)>
<!ATTLIST RegistrarDetailsQry
        QryId       %UID;         #IMPLIED
        RegistrarId %RegistrarId; #IMPLIED
        NameFilter  CDATA         #IMPLIED>

<!-- Query registrar account (obtain billing records)
     Response: (BillingTrans*|Error) -->
<!ELEMENT RegistrarAccountQry (TransDateRange?,InvoiceDateRange?)>
<!ATTLIST RegistrarAccountQry
        QryId         %UID;          #IMPLIED
        RegistrantRef %UID;          #IMPLIED
        DomainName    %DomainName;   #IMPLIED
        InvoiceId     %UID;          #IMPLIED
        MaxResults    %Number;       #IMPLIED
        SkipResults   %Number;       #IMPLIED
        TransStatus   (%BillStatus;) #IMPLIED
        CountResults  %Boolean;      "0">

<!-- Insert details for a new registrar
     Response: (Registrar|Error) -->
<!ELEMENT RegistrarCreate (RegistrarPublicContact,
                           RegistrarSRSContact,
                           DefaultTechnicalContact,EncryptKeys,
                           Allowed2LDs?,Roles?,AuditText?)>
<!ATTLIST RegistrarCreate
        ActionId    %UID;         #REQUIRED
        Name        CDATA         #REQUIRED
        AccRef      CDATA         #REQUIRED
        RegistrarId %RegistrarId; #REQUIRED
        URL         CDATA         #IMPLIED>

<!-- Update existing registrar details
     Response: (Registrar|Error) -->
<!ELEMENT RegistrarUpdate (RegistrarPublicContact?,
                           RegistrarSRSContact?,
                           DefaultTechnicalContact?,EncryptKeys?,
                           Allowed2LDs?,Roles?,AuditText?)>
<!ATTLIST RegistrarUpdate
        ActionId %UID; #REQUIRED
        Name     CDATA #IMPLIED
        AccRef   CDATA #IMPLIED
        URL      CDATA #IMPLIED>

<!-- Adjust a registrar's account by adding billing transactions
     Response: (BillingTrans|Error) -->
<!ELEMENT AdjustRegistrarAccount (TransactionDate,BillPeriodStart,
                                  BillPeriodEnd,AuditText)>
<!ATTLIST AdjustRegistrarAccount
        RegistrarId %RegistrarId;        #REQUIRED
        DomainName  %DomainName;         #REQUIRED
        ActionId    %UID;                #REQUIRED
        Months      %Number;             #REQUIRED
        ActionType  (%AccountingAction;) #REQUIRED>

<!-- Adjust the billed until date for a domain
     Response: (Domain|Error) -->
<!ELEMENT BilledUntilAdjustment (NewBilledUntilDate,AuditText)>
<!ATTLIST BilledUntilAdjustment
        DomainName %DomainName; #REQUIRED
        ActionId   %UID;        #REQUIRED>

<!-- Obtain billing records (optionally assign them to an invoice)
     Response: (BillingTrans*|Error) -->
<!ELEMENT BillingExtract (TransDateRange,InvoiceDate?)>
<!ATTLIST BillingExtract
        ActionId          %UID;     #REQUIRED
        InvoiceExtract    %Boolean; #IMPLIED
        RegistrarId       %UID;     #IMPLIED
        ConfirmedTrans    %Boolean; #IMPLIED
        InsideGracePeriod %Boolean; #IMPLIED
        InvoiceId         CDATA     #IMPLIED>

<!-- Initiate process to rebuild the DNS zone files
     Response: (RunLog|Error) -->
<!ELEMENT BuildDnsZoneFiles (RunDate)>
<!ATTLIST BuildDnsZoneFiles
        ActionId %UID; #REQUIRED>

<!-- Query billing transaction details of deferred income
     Response: (BillingTrans*|Error) -->
<!ELEMENT DeferredIncomeDetailQry EMPTY>
<!ATTLIST DeferredIncomeDetailQry
        BaseMonth   CDATA #REQUIRED
        BaseYear    CDATA #REQUIRED
        IncomeMonth CDATA #REQUIRED
        IncomeYear  CDATA #REQUIRED
        QryId       %UID; #IMPLIED>

<!-- Query summary details of deferred income
     Response: (BillingTrans*|Error) -->
<!ELEMENT DeferredIncomeSummaryQry EMPTY>
<!ATTLIST DeferredIncomeSummaryQry
        BaseMonth   CDATA #REQUIRED
        BaseYear    CDATA #REQUIRED
        IncomeMonth CDATA #REQUIRED
        IncomeYear  CDATA #REQUIRED
        QryId       %UID; #IMPLIED>

<!-- Initiate process to create a domain report
     Response: (RunLog|Error) -->
<!ELEMENT GenerateDomainReport (RunDate)>
<!ATTLIST GenerateDomainReport
        ActionId %UID; #REQUIRED>

<!-- Query domain billing amounts in the system
     Response: (BillingAmount*|Error) -->
<!ELEMENT QryBillingAmount EMPTY>
<!ATTLIST QryBillingAmount
        QryId %UID; #IMPLIED>

<!-- Create a new run log entry
     Response: (RunLog|Error) -->
<!ELEMENT RunLogCreate (FirstRunDate,RunLog)>
<!ATTLIST RunLogCreate
        ActionId %UID; #REQUIRED>

<!-- Query existing run log entries
     Response: (RunLog*|Error) -->
<!ELEMENT RunLogQry (LogDateRange?)>
<!ATTLIST RunLogQry
        QryId       %UID; #IMPLIED
        ProcessName CDATA #IMPLIED
        Parameters  CDATA #IMPLIED>

<!-- Cancel a scheduled job entry
     Response: (Schedule|Error) -->
<!ELEMENT ScheduleCancel (FirstRunDate,AuditText?)>
<!ATTLIST ScheduleCancel
        ActionId    %UID;            #REQUIRED
        ProcessName (%ScheduledJob;) #REQUIRED
        Parameters  CDATA            #IMPLIED>

<!-- Create a new scheduled job entry
     Response: (Schedule|Error) -->
<!ELEMENT ScheduleCreate (FirstRunDate,FinalRunDate?,AuditText?)>
<!ATTLIST ScheduleCreate
        ProcessName (%ScheduledJob;) #REQUIRED
        Frequency   CDATA            #REQUIRED
        Parameters  CDATA            #IMPLIED
        ActionId    %UID;            #REQUIRED>

<!-- Query details of existing scheduled job entries
     Response: (Schedule*|Error) -->
<!ELEMENT ScheduleQry (ActiveOn?,FirstRunDate?)>
<!ATTLIST ScheduleQry
        QryId       %UID; #IMPLIED
        ProcessName CDATA #IMPLIED
        Parameters  CDATA #IMPLIED>

<!-- Update an existing scheduled job entry
     Response: (Schedule|Error) -->
<!ELEMENT ScheduleUpdate (FirstRunDate,LastRunDate?,AuditText?)>
<!ATTLIST ScheduleUpdate
        ActionId    %UID;            #REQUIRED
        Parameters  CDATA            #IMPLIED
        ProcessName (%ScheduledJob;) #REQUIRED>

<!-- Create a new billing amount
     Response: (BillingAmount*|Error) -->
<!ELEMENT SetBillingAmount (BillingAmount)>
<!ATTLIST SetBillingAmount
        ActionId %UID; #REQUIRED>

<!-- Query details of configurable system parameters
     Response: (SysParam*|Error) -->
<!ELEMENT SysParamsQry EMPTY>
<!ATTLIST SysParamsQry
        QryId %UID; #IMPLIED>

<!-- Update details of configurable system parameters
     Response: (SysParam*|Error) -->
<!ELEMENT SysParamsUpdate (SysParam+,AuditText?)>
<!ATTLIST SysParamsUpdate
        ActionId %UID; #REQUIRED>

<!-- RESPONSE ELEMENTS -->

<!-- Billing amount -->
<!ELEMENT BillingAmount (EffectiveDate)>
<!ATTLIST BillingAmount
        Amount %Dollars; #REQUIRED>

<!-- Billing transaction -->
<!ELEMENT BillingTrans (InvoiceDate?,TransDate,BillPeriodStart,
                        BillPeriodEnd)>
<!ATTLIST BillingTrans
        RegistrarId   %RegistrarId;  #REQUIRED
        Type          CDATA          #REQUIRED
        TransStatus   (%BillStatus;) #REQUIRED
        DomainName    %DomainName;   #REQUIRED
        RegistrantRef %UID;          #IMPLIED
        BillingTerm   %Term;         #REQUIRED
        InvoiceId     %UID;          #IMPLIED
        Amount        %Dollars;      #REQUIRED>

<!-- Deferred registrar income amount -->
<!ELEMENT DeferredRegistrarIncome (BaseMonth,BaseYear,
                                   IncomeMonth,IncomeYear)>
<!ATTLIST DeferredRegistrarIncome
        RegistrarId  %RegistrarId; #REQUIRED
        BilledAmount %Dollars;     #REQUIRED
        BilledCount  %Number;      #REQUIRED>

<!-- Domain element -->
<!ELEMENT Domain (NameServers?,RegistrantContact?,
                  RegistrarPublicContact?,AdminContact?,
                  TechnicalContact?,BilledUntil?,RegisteredDate?,
                  CancelledDate?,LockedDate?,AuditDetails?)>
<!ATTLIST Domain
        DomainName    %DomainName;     #REQUIRED
        RegistrantRef %UID;            #IMPLIED
        RegistrarName CDATA            #IMPLIED
        Status        (%DomainStatus;) #IMPLIED
        Delegate      %Boolean;        #IMPLIED
        Term          %Term;           #IMPLIED
        RegistrarId   %RegistrarId;    #IMPLIED
        UDAI          %UID;            #IMPLIED>

<!-- Domain transfer message -->
<!ELEMENT DomainTransfer (TransferredDomain+)>
<!ATTLIST DomainTransfer
        RegistrarName CDATA #REQUIRED
        %TimeStamp;>

<!-- Error -->
<!ELEMENT Error (Description, ErrorDetails*)>
<!ATTLIST Error
        ErrorId  %UID;    #REQUIRED
        Severity %Number; #REQUIRED
        Hint     %UID;    #REQUIRED>

<!-- Raw request -->
<!ELEMENT RawRequest (XML,Signature)>

<!-- Raw response -->
<!ELEMENT RawResponse (XML,Signature)>

<!-- Registrar details  -->
<!ELEMENT Registrar (RegistrarPublicContact,RegistrarSRSContact,
                     DefaultTechnicalContact,EncryptKeys,
                     Allowed2LDs?,Roles?,AuditDetails?)>
<!ATTLIST Registrar
        RegistrarId %RegistrarId; #REQUIRED
        Name        CDATA         #REQUIRED
        AccRef      CDATA         #REQUIRED
        URL         CDATA         #IMPLIED>

<!-- Run Log -->
<!ELEMENT RunLog (RunLogTimeStamp, RunLogDetails?)>
<!ATTLIST RunLog
        ProcessName  CDATA #REQUIRED
        Parameters   CDATA #IMPLIED
        ActionStatus CDATA #REQUIRED
        Control      CDATA #IMPLIED>

<!-- Schedule -->
<!ELEMENT Schedule (FirstRunDate,FinalRunDate?,CreateAuditText?,
                    CancelAuditText?)>
<!ATTLIST Schedule
        ProcessName         (%ScheduledJob;) #REQUIRED
        Frequency           CDATA            #REQUIRED
        Parameters          CDATA            #IMPLIED
        CreateByRegistrarId %UID;            #REQUIRED
        CreateActionId      %UID;            #REQUIRED
        CancelByRegistrarId %UID;            #IMPLIED
        CancelActionId      %UID;            #IMPLIED>

<!-- System parameter -->
<!ELEMENT SysParam (ParamValue, AuditDetails?)>
<!ATTLIST SysParam
        Name CDATA #REQUIRED>

<!-- UDAI validity -->
<!ELEMENT UDAIValid EMPTY>
<!ATTLIST UDAIValid
        Valid %Boolean; #REQUIRED>

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

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.