[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                            M. Hunt
Internet-Draft                             New Zealand Registry Services
Intended status: Standards Track                           July 26, 2010
Expires: January 27, 2011


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

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 author:
   matt@nzrs.net.nz

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 27, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Hunt                    Expires January 27, 2011                [Page 1]

Internet-Draft                     SRS                         July 2010


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.



































Hunt                    Expires January 27, 2011                [Page 2]

Internet-Draft                     SRS                         July 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   7
   2.  Conventions used in this Document . . . . . . . . . . . . . .   7
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   8
   3.  System Description  . . . . . . . . . . . . . . . . . . . . .   8
     3.1.  The Public  . . . . . . . . . . . . . . . . . . . . . . .   9
     3.2.  Registrars  . . . . . . . . . . . . . . . . . . . . . . .  10
     3.3.  The Registry  . . . . . . . . . . . . . . . . . . . . . .  10
     3.4.  The Domain Registration Cycle . . . . . . . . . . . . . .  11
       3.4.1.  Registration Grace Period . . . . . . . . . . . . . .  11
       3.4.2.  Renewal Grace Period  . . . . . . . . . . . . . . . .  12
       3.4.3.  Auto-renew Grace Period . . . . . . . . . . . . . . .  12
       3.4.4.  Redemption Grace Period . . . . . . . . . . . . . . .  12
   4.  Authentication, Security and Authorization  . . . . . . . . .  12
     4.1.  Authentication  . . . . . . . . . . . . . . . . . . . . .  12
     4.2.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  13
     4.3.  Authorization . . . . . . . . . . . . . . . . . . . . . .  13
   5.  Communication . . . . . . . . . . . . . . . . . . . . . . . .  14
     5.1.  Request Format  . . . . . . . . . . . . . . . . . . . . .  15
     5.2.  Response Format . . . . . . . . . . . . . . . . . . . . .  17
       5.2.1.  Response  . . . . . . . . . . . . . . . . . . . . . .  18
       5.2.2.  Error . . . . . . . . . . . . . . . . . . . . . . . .  19
   6.  SRS Requests  . . . . . . . . . . . . . . . . . . . . . . . .  19
     6.1.  Domain Query Actions  . . . . . . . . . . . . . . . . . .  20
       6.1.1.  ActionDetailsQry  . . . . . . . . . . . . . . . . . .  21
       6.1.2.  DomainDetailsQry  . . . . . . . . . . . . . . . . . .  22
       6.1.3.  UDAIValidQry  . . . . . . . . . . . . . . . . . . . .  26
       6.1.4.  Whois . . . . . . . . . . . . . . . . . . . . . . . .  27
     6.2.  Domain Write Actions  . . . . . . . . . . . . . . . . . .  29
       6.2.1.  DomainCreate  . . . . . . . . . . . . . . . . . . . .  29
       6.2.2.  DomainUpdate  . . . . . . . . . . . . . . . . . . . .  31
     6.3.  Handle Query Action . . . . . . . . . . . . . . . . . . .  35
       6.3.1.  HandleDetailsQry  . . . . . . . . . . . . . . . . . .  35
     6.4.  Handle Write Actions  . . . . . . . . . . . . . . . . . .  37
       6.4.1.  HandleCreate  . . . . . . . . . . . . . . . . . . . .  37
       6.4.2.  HandleUpdate  . . . . . . . . . . . . . . . . . . . .  38
     6.5.  Message Query Action  . . . . . . . . . . . . . . . . . .  39
       6.5.1.  GetMessages . . . . . . . . . . . . . . . . . . . . .  39
     6.6.  Message Write Action  . . . . . . . . . . . . . . . . . .  41
       6.6.1.  RegistrarUpdate . . . . . . . . . . . . . . . . . . .  42
     6.7.  Registrar Query Actions . . . . . . . . . . . . . . . . .  42
       6.7.1.  RegistrarAccountQry . . . . . . . . . . . . . . . . .  43
       6.7.2.  RegistrarDetailsQry . . . . . . . . . . . . . . . . .  44
     6.8.  Registrar Write Actions . . . . . . . . . . . . . . . . .  45
       6.8.1.  RegistrarUpdate . . . . . . . . . . . . . . . . . . .  46
     6.9.  Registry Actions  . . . . . . . . . . . . . . . . . . . .  47
       6.9.1.  AccessControlListAdd  . . . . . . . . . . . . . . . .  49



Hunt                    Expires January 27, 2011                [Page 3]

Internet-Draft                     SRS                         July 2010


       6.9.2.  AccessControlListQry  . . . . . . . . . . . . . . . .  50
       6.9.3.  AccessControlListRemove . . . . . . . . . . . . . . .  51
       6.9.4.  AdjustRegistrarAccount  . . . . . . . . . . . . . . .  52
       6.9.5.  BilledUntilAdjustment . . . . . . . . . . . . . . . .  54
       6.9.6.  BuildDnsZoneFiles . . . . . . . . . . . . . . . . . .  54
       6.9.7.  DeferredIncomeDetailQry . . . . . . . . . . . . . . .  55
       6.9.8.  DeferredIncomeSummaryQry  . . . . . . . . . . . . . .  57
       6.9.9.  GenerateDomainReport  . . . . . . . . . . . . . . . .  58
       6.9.10. BillingAmountQry  . . . . . . . . . . . . . . . . . .  59
       6.9.11. RegistrarCreate . . . . . . . . . . . . . . . . . . .  59
       6.9.12. RunLogCreate  . . . . . . . . . . . . . . . . . . . .  61
       6.9.13. RunLogQry . . . . . . . . . . . . . . . . . . . . . .  62
       6.9.14. ScheduleCancel  . . . . . . . . . . . . . . . . . . .  63
       6.9.15. ScheduleCreate  . . . . . . . . . . . . . . . . . . .  64
       6.9.16. ScheduleQry . . . . . . . . . . . . . . . . . . . . .  65
       6.9.17. ScheduleUpdate  . . . . . . . . . . . . . . . . . . .  66
       6.9.18. BillingAmountUpdate . . . . . . . . . . . . . . . . .  67
       6.9.19. SysParamsCreate . . . . . . . . . . . . . . . . . . .  69
       6.9.20. SysParamsQry  . . . . . . . . . . . . . . . . . . . .  70
       6.9.21. SysParamsUpdate . . . . . . . . . . . . . . . . . . .  71
   7.  SRS Response Types  . . . . . . . . . . . . . . . . . . . . .  71
     7.1.  AccessControlList . . . . . . . . . . . . . . . . . . . .  71
     7.2.  AckResponse . . . . . . . . . . . . . . . . . . . . . . .  73
     7.3.  BillingAmount . . . . . . . . . . . . . . . . . . . . . .  73
     7.4.  BillingTrans  . . . . . . . . . . . . . . . . . . . . . .  74
     7.5.  DeferredRegistrarIncome . . . . . . . . . . . . . . . . .  76
     7.6.  Domain  . . . . . . . . . . . . . . . . . . . . . . . . .  77
     7.7.  DomainTransfer  . . . . . . . . . . . . . . . . . . . . .  81
     7.8.  Error . . . . . . . . . . . . . . . . . . . . . . . . . .  83
     7.9.  Handle  . . . . . . . . . . . . . . . . . . . . . . . . .  84
     7.10. Message . . . . . . . . . . . . . . . . . . . . . . . . .  84
     7.11. RawRequest and RawResponse  . . . . . . . . . . . . . . .  85
     7.12. Registrar . . . . . . . . . . . . . . . . . . . . . . . .  86
     7.13. RunLog  . . . . . . . . . . . . . . . . . . . . . . . . .  88
     7.14. Schedule  . . . . . . . . . . . . . . . . . . . . . . . .  89
     7.15. SysParam  . . . . . . . . . . . . . . . . . . . . . . . .  91
     7.16. UDAIValid . . . . . . . . . . . . . . . . . . . . . . . .  91
   8.  Information Elements  . . . . . . . . . . . . . . . . . . . .  92
     8.1.  AccessControlListContentFilter  . . . . . . . . . . . . .  92
     8.2.  AccessControlListEntry  . . . . . . . . . . . . . . . . .  93
     8.3.  ActionIdFilter  . . . . . . . . . . . . . . . . . . . . .  94
     8.4.  AddressFilter . . . . . . . . . . . . . . . . . . . . . .  94
     8.5.  Allowed2LDs . . . . . . . . . . . . . . . . . . . . . . .  94
     8.6.  AuditDetails  . . . . . . . . . . . . . . . . . . . . . .  95
     8.7.  AuditText . . . . . . . . . . . . . . . . . . . . . . . .  95
     8.8.  AuditTextFilter . . . . . . . . . . . . . . . . . . . . .  95
     8.9.  CancelAuditText . . . . . . . . . . . . . . . . . . . . .  96
     8.10. ChangedDomains  . . . . . . . . . . . . . . . . . . . . .  96



Hunt                    Expires January 27, 2011                [Page 4]

Internet-Draft                     SRS                         July 2010


     8.11. Contact Details Elements  . . . . . . . . . . . . . . . .  96
     8.12. Contact Details Search Filters  . . . . . . . . . . . . .  99
     8.13. CreateAuditText . . . . . . . . . . . . . . . . . . . . .  99
     8.14. Date Range Elements . . . . . . . . . . . . . . . . . . . 100
     8.15. Description . . . . . . . . . . . . . . . . . . . . . . . 102
     8.16. DomainNameFilter  . . . . . . . . . . . . . . . . . . . . 102
     8.17. EncryptKey  . . . . . . . . . . . . . . . . . . . . . . . 102
     8.18. EncryptKeys . . . . . . . . . . . . . . . . . . . . . . . 103
     8.19. EPPAuth . . . . . . . . . . . . . . . . . . . . . . . . . 103
     8.20. ErrorDetails  . . . . . . . . . . . . . . . . . . . . . . 103
     8.21. FieldList . . . . . . . . . . . . . . . . . . . . . . . . 104
     8.22. HandleIdFilter  . . . . . . . . . . . . . . . . . . . . . 105
     8.23. NameServers . . . . . . . . . . . . . . . . . . . . . . . 106
     8.24. NameServerFilter  . . . . . . . . . . . . . . . . . . . . 106
     8.25. ParamValue  . . . . . . . . . . . . . . . . . . . . . . . 106
     8.26. PostalAddress . . . . . . . . . . . . . . . . . . . . . . 107
     8.27. PostalAddressFilter . . . . . . . . . . . . . . . . . . . 107
     8.28. TypeFilter  . . . . . . . . . . . . . . . . . . . . . . . 108
     8.29. Telephone Number Details  . . . . . . . . . . . . . . . . 108
     8.30. RegistrarIdFilter . . . . . . . . . . . . . . . . . . . . 108
     8.31. Role  . . . . . . . . . . . . . . . . . . . . . . . . . . 109
     8.32. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 109
     8.33. RunLogDetails . . . . . . . . . . . . . . . . . . . . . . 110
     8.34. SecondLD  . . . . . . . . . . . . . . . . . . . . . . . . 110
     8.35. Server  . . . . . . . . . . . . . . . . . . . . . . . . . 110
     8.36. ServerFilter  . . . . . . . . . . . . . . . . . . . . . . 111
     8.37. Signature . . . . . . . . . . . . . . . . . . . . . . . . 112
     8.38. Timestamp Elements  . . . . . . . . . . . . . . . . . . . 112
     8.39. TransferredDomain . . . . . . . . . . . . . . . . . . . . 116
     8.40. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
   9.  Internal Entities . . . . . . . . . . . . . . . . . . . . . . 116
     9.1.  Actions . . . . . . . . . . . . . . . . . . . . . . . . . 116
       9.1.1.  DomainWriteAction . . . . . . . . . . . . . . . . . . 116
       9.1.2.  DomainQueryAction . . . . . . . . . . . . . . . . . . 117
       9.1.3.  HandleQueryAction . . . . . . . . . . . . . . . . . . 117
       9.1.4.  HandleWriteAction . . . . . . . . . . . . . . . . . . 117
       9.1.5.  RegistrarWriteAction  . . . . . . . . . . . . . . . . 117
       9.1.6.  RegistrarQueryAction  . . . . . . . . . . . . . . . . 118
       9.1.7.  RegistryAction  . . . . . . . . . . . . . . . . . . . 118
       9.1.8.  Action  . . . . . . . . . . . . . . . . . . . . . . . 118
       9.1.9.  ActionEtc . . . . . . . . . . . . . . . . . . . . . . 119
     9.2.  Accounts  . . . . . . . . . . . . . . . . . . . . . . . . 119
       9.2.1.  AccountingAction  . . . . . . . . . . . . . . . . . . 119
       9.2.2.  BillStatus  . . . . . . . . . . . . . . . . . . . . . 119
     9.3.  Booleans  . . . . . . . . . . . . . . . . . . . . . . . . 120
       9.3.1.  True  . . . . . . . . . . . . . . . . . . . . . . . . 120
       9.3.2.  False . . . . . . . . . . . . . . . . . . . . . . . . 120
       9.3.3.  Boolean . . . . . . . . . . . . . . . . . . . . . . . 120



Hunt                    Expires January 27, 2011                [Page 5]

Internet-Draft                     SRS                         July 2010


     9.4.  Contact Details . . . . . . . . . . . . . . . . . . . . . 120
       9.4.1.  Contact . . . . . . . . . . . . . . . . . . . . . . . 120
       9.4.2.  ContactAttr . . . . . . . . . . . . . . . . . . . . . 120
     9.5.  Contact Details Filters . . . . . . . . . . . . . . . . . 121
       9.5.1.  ContactFilter . . . . . . . . . . . . . . . . . . . . 121
       9.5.2.  ContactFilterAttr . . . . . . . . . . . . . . . . . . 121
     9.6.  Currency  . . . . . . . . . . . . . . . . . . . . . . . . 121
       9.6.1.  Dollars . . . . . . . . . . . . . . . . . . . . . . . 121
     9.7.  Dates And Times . . . . . . . . . . . . . . . . . . . . . 122
       9.7.1.  Date  . . . . . . . . . . . . . . . . . . . . . . . . 122
       9.7.2.  Time  . . . . . . . . . . . . . . . . . . . . . . . . 122
       9.7.3.  TimeStamp . . . . . . . . . . . . . . . . . . . . . . 122
       9.7.4.  DateRange . . . . . . . . . . . . . . . . . . . . . . 122
     9.8.  Domain Names  . . . . . . . . . . . . . . . . . . . . . . 123
       9.8.1.  DomainName  . . . . . . . . . . . . . . . . . . . . . 123
     9.9.  Domain Status . . . . . . . . . . . . . . . . . . . . . . 123
       9.9.1.  RegDomainStatus . . . . . . . . . . . . . . . . . . . 123
       9.9.2.  DomainStatus  . . . . . . . . . . . . . . . . . . . . 123
     9.10. Duration  . . . . . . . . . . . . . . . . . . . . . . . . 123
       9.10.1. Term  . . . . . . . . . . . . . . . . . . . . . . . . 123
     9.11. Message Types . . . . . . . . . . . . . . . . . . . . . . 124
       9.11.1. GetMessagesTypes  . . . . . . . . . . . . . . . . . . 124
     9.12. Numeric . . . . . . . . . . . . . . . . . . . . . . . . . 124
       9.12.1. Number  . . . . . . . . . . . . . . . . . . . . . . . 124
     9.13. Registrar Identifiers . . . . . . . . . . . . . . . . . . 124
       9.13.1. RegistrarId . . . . . . . . . . . . . . . . . . . . . 124
       9.13.2. RegistrarIdOrOTHERS . . . . . . . . . . . . . . . . . 125
     9.14. Responses . . . . . . . . . . . . . . . . . . . . . . . . 125
       9.14.1. ActionResponse  . . . . . . . . . . . . . . . . . . . 125
     9.15. System Roles  . . . . . . . . . . . . . . . . . . . . . . 125
       9.15.1. Role  . . . . . . . . . . . . . . . . . . . . . . . . 125
     9.16. Scheduled Processes . . . . . . . . . . . . . . . . . . . 126
       9.16.1. ScheduledJob  . . . . . . . . . . . . . . . . . . . . 126
     9.17. Telephone Numbers . . . . . . . . . . . . . . . . . . . . 126
       9.17.1. PhoneAttr . . . . . . . . . . . . . . . . . . . . . . 126
     9.18. Unique Identifiers  . . . . . . . . . . . . . . . . . . . 127
       9.18.1. UID . . . . . . . . . . . . . . . . . . . . . . . . . 127
   10. Text Filter . . . . . . . . . . . . . . . . . . . . . . . . . 127
   11. Security Considerations . . . . . . . . . . . . . . . . . . . 128
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 129
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . . 129
     13.1. Normative References  . . . . . . . . . . . . . . . . . . 129
     13.2. Informative References  . . . . . . . . . . . . . . . . . 130
   Appendix A.  Example  . . . . . . . . . . . . . . . . . . . . . . 130
     A.1.  Whois request . . . . . . . . . . . . . . . . . . . . . . 131
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . . 131
   Appendix C.  RELAX NG schema  . . . . . . . . . . . . . . . . . . 131
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 162



Hunt                    Expires January 27, 2011                [Page 6]

Internet-Draft                     SRS                         July 2010


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 [RFC3375].  As this system only addresses the
   issue of managing a shared registry service and uses HTTP [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 schema for the SRS protocol, in RELAX NG
   compact syntax, is provided in its entirety as an appendix
   (Appendix C) 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 [1] 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
   [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.




Hunt                    Expires January 27, 2011                [Page 7]

Internet-Draft                     SRS                         July 2010


   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 [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 [RFC2119].


3.  System Description

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

   o  creation, maintenance, querying and deletion of domain details

   o  querying of public details of a domain - to support a public WHOIS
      service

   o  transfer of domains between registrars

   o  creation, maintenance, querying and deletion of registrar details

   o  regular zone file creation for domains delegated to appear in the
      domain name system (DNS)

   o  registrar account query, maintenance, and message polling

   o  creation and cancellation of scheduled jobs in the SRS to support
      business functions (such as building zone files and releasing and
      renewing domains)

   o  management and configuration of the SRS by the registry




Hunt                    Expires January 27, 2011                [Page 8]

Internet-Draft                     SRS                         July 2010


   o  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:

   o  the public (including registrants),

   o  registrars,

   o  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:

   o  querying domain ownership details in the public WHOIS system,

   o  performing hostname lookups to access services hosted on the
      internet,



Hunt                    Expires January 27, 2011                [Page 9]

Internet-Draft                     SRS                         July 2010


   o  registering domains by establishing a business relationship with a
      registrar,

   o  transferring their registered domains between registrars,

   o  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:

   o  checking availability of domain names,

   o  registering domain names,

   o  transferring domain names from another registrar,

   o  cancelling domain registrations,

   o  billing for domain registrations,

   o  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 (Section 6.5.1)
   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 [RFC3912],
   regular backups, data security, and running name servers for their
   domains.



Hunt                    Expires January 27, 2011               [Page 10]

Internet-Draft                     SRS                         July 2010


   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:

   o  registration grace period

   o  renewal grace period

   o  auto-renew grace period

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







Hunt                    Expires January 27, 2011               [Page 11]

Internet-Draft                     SRS                         July 2010


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:

   o  A unique numeric identifier issued to each registrar by the
      registry

   o  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



Hunt                    Expires January 27, 2011               [Page 12]

Internet-Draft                     SRS                         July 2010


   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 (Section 6.1.4) 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



Hunt                    Expires January 27, 2011               [Page 13]

Internet-Draft                     SRS                         July 2010


   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 [W3C.REC-xml]
   documents encoded in UTF-8 [RFC3629] and sent using HTTP [RFC2616] or
   HTTPS [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:

   o  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)

   o  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 [RFC4880] and MUST be encoded in ASCII
   Armor (see section 6.2 of [RFC4880]) 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:




Hunt                    Expires January 27, 2011               [Page 14]

Internet-Draft                     SRS                         July 2010


   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 schema).

   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:

   +-----------+-------------------------------------------------------+
   | Parameter | Description                                           |
   +-----------+-------------------------------------------------------+
   | n         | The registry-assigned registrar identifier.           |
   | r         | The XML request, encoded in UTF-8.                    |
   | s         | An OpenPGP-compatible signature of the XML request    |
   |           | document, signed with the registrar's private key.    |
   |           | Presented in ASCII armored format and encoded in      |
   |           | UTF-8.                                                |
   +-----------+-------------------------------------------------------+

   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 (Section 9.1.8)
   entity.

















Hunt                    Expires January 27, 2011               [Page 15]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.NZSRSRequest =
     element NZSRSRequest {
       attribute VerMajor { Number },
       attribute VerMinor { Number },
       attribute RegistrarId { RegistrarId }?,
       (element.DomainCreate
        | element.DomainUpdate
        | element.HandleCreate
        | element.HandleUpdate
        | element.HandleDetailsQry
        | element.Whois
        | element.DomainDetailsQry
        | element.ActionDetailsQry
        | element.UDAIValidQry
        | element.RegistrarCreate
        | element.RegistrarUpdate
        | element.RegistrarDetailsQry
        | element.RegistrarAccountQry
        | element.GetMessages
        | element.AckMessage
        | element.SysParamsCreate
        | element.SysParamsUpdate
        | element.SysParamsQry
        | element.RunLogCreate
        | element.RunLogQry
        | element.ScheduleCreate
        | element.ScheduleCancel
        | element.ScheduleQry
        | element.ScheduleUpdate
        | element.BillingAmountUpdate
        | element.BillingAmountQry
        | element.DeferredIncomeSummaryQry
        | element.DeferredIncomeDetailQry
        | element.BilledUntilAdjustment
        | element.BuildDnsZoneFiles
        | element.GenerateDomainReport
        | element.AdjustRegistrarAccount
        | element.AccessControlListQry
        | element.AccessControlListAdd
        | element.AccessControlListRemove)+
     }








Hunt                    Expires January 27, 2011               [Page 16]

Internet-Draft                     SRS                         July 2010


   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:

   +-----------+-------------------------------------------------------+
   | Parameter | Description                                           |
   +-----------+-------------------------------------------------------+
   | r         | The XML response, encoded in UTF-8.                   |
   | s         | An OpenPGP-compatible signature of the XML response   |
   |           | document, signed with the registry's private key.     |
   |           | Presented in ASCII armored format and encoded in      |
   |           | UTF-8.                                                |
   +-----------+-------------------------------------------------------+

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

   Syntax:

   element.NZSRSResponse =
     element NZSRSResponse {
       attribute VerMajor { Number },
       attribute VerMinor { Number },
       attribute RegistrarId { RegistrarId }?,
       (element.Response+ | element.Error)
     }

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





Hunt                    Expires January 27, 2011               [Page 17]

Internet-Draft                     SRS                         July 2010


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 (Section 7.8) element with no
   Response container.

   The response element may contain any of the following:

   o  multiple responses in response to a GetMessages (Section 6.5.1)
      request, or

   o  a single action response (Section 9.14.1) specific to the type of
      action request.

   The Response element must specify:

   +-----------------+-------------------------------------------------+
   | Attribute       | Description                                     |
   +-----------------+-------------------------------------------------+
   | Action          | The name of the request action (Section 9.1.9)  |
   |                 | that this is a response to.                     |
   | FeId            | The unique identifier of the SRS server that    |
   |                 | handled the request.                            |
   | FeSeq           | The unique identifier for the request on the    |
   |                 | server that handled the request.                |
   | OrigRegistrarId | The unique identifier for the user that         |
   |                 | submitted the request to the SRS server.        |
   +-----------------+-------------------------------------------------+

   The Response element may also specify:

   +----------------------+--------------------------------------------+
   | Attribute            | Description                                |
   +----------------------+--------------------------------------------+
   | TransId              | The identifier (either an ActionId or a    |
   |                      | QryId) for the transaction submitted by    |
   |                      | the user that originated the request.      |
   | Rows                 | The number of results returned in the      |
   |                      | current response body.                     |
   | Count                | The total number of matches found in the   |
   |                      | SRS that satisfied the request query       |
   |                      | conditions.                                |
   | MoreRowsAvailable    | A boolean value indicating whether this    |
   |                      | response was truncated by an SRS limit on  |
   |                      | the number of results returned.            |



Hunt                    Expires January 27, 2011               [Page 18]

Internet-Draft                     SRS                         July 2010


   | RecipientRegistrarId | The unique identifier for the user that    |
   |                      | the response is returned to.               |
   +----------------------+--------------------------------------------+

   The Response element MUST contain an FeTimeStamp (Section 8.38)
   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
   (Section 7).

   Syntax:

   element.Response =
     element Response {
       attribute Action { ActionEtc },
       attribute FeId { Number },
       attribute FeSeq { Number },
       attribute OrigRegistrarId { RegistrarId },
       attribute TransId { UID }?,
       attribute Rows { Number }?,
       attribute Count { Number }?,
       attribute MoreRowsAvailable { Boolean }?,
       attribute RecipientRegistrarId { RegistrarId }?,
       element.FeTimeStamp,
       (element.Response* | ActionResponse | element.AckResponse)?
     }

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



Hunt                    Expires January 27, 2011               [Page 19]

Internet-Draft                     SRS                         July 2010


   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 (Section 7.8) 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:









Hunt                    Expires January 27, 2011               [Page 20]

Internet-Draft                     SRS                         July 2010


   +------------------+------------------------------------------------+
   | Action           | Description                                    |
   +------------------+------------------------------------------------+
   | ActionDetailsQry | Retrieve the XML content and signature for a   |
   |                  | previous SRS request and the response that it  |
   |                  | received.                                      |
   | DomainDetailsQry | Retrieve the current stored details for a      |
   |                  | domain.                                        |
   | UDAIValidQry     | Check the validity of a UDAI code for a        |
   |                  | domain.                                        |
   | Whois            | Retrieve the public WHOIS data for a domain.   |
   +------------------+------------------------------------------------+

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:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is the action identifier   |
   |           | for a previous request to the SRS.                    |
   +-----------+-------------------------------------------------------+

   Additionally, the request may specify:

   +------------------------+------------------------------------------+
   | Attribute              | Description                              |
   +------------------------+------------------------------------------+
   | QryId                  | A query identifier. This has no meaning  |
   |                        | within the SRS; if provided, it will be  |
   |                        | returned in the response to this         |
   |                        | request.                                 |
   | OriginatingRegistrarId | A user identifier. The identifier of the |
   |                        | registrar that originally requested the  |
   |                        | action that matches the provided         |
   |                        | ActionId.                                |
   +------------------------+------------------------------------------+




Hunt                    Expires January 27, 2011               [Page 21]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.ActionDetailsQry =
     element ActionDetailsQry {
       attribute QryId { UID }?,
       attribute ActionId { UID },
       attribute OriginatingRegistrarId { UID }?,
       empty
     }

6.1.1.2.  Response

   The response to an ActionDetailsQry request will be either an Error
   (Section 7.8) element or a RawRequest and a RawResponse
   (Section 7.11) 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
   (Section 6.1.4) request shall be returned for this time.

6.1.2.1.  Request

   The DomainDetailsQry request may specify:













Hunt                    Expires January 27, 2011               [Page 22]

Internet-Draft                     SRS                         July 2010


   +---------------+---------------------------------------------------+
   | Attribute     | Description                                       |
   +---------------+---------------------------------------------------+
   | QryId         | A query identifier. This has no meaning within    |
   |               | the SRS; if provided, it will be returned in the  |
   |               | response to this request.                         |
   | Status        | A text filter. Matched against the registration   |
   |               | status of domains. Valid values are "Active" and  |
   |               | "PendingRelease".                                 |
   | Delegate      | A boolean value. Matched against the delegation   |
   |               | status of domains.                                |
   | Term          | A numeric value. Matched against the billing term |
   |               | for domains.                                      |
   | RegistrantRef | A text filter. Matched against the                |
   |               | registrar-provided customer reference of a        |
   |               | domain's registrant.                              |
   | MaxResults    | A numeric value. Used to specify the maximum      |
   |               | number of domain records to return. If not        |
   |               | specified, the default defined by the server      |
   |               | implementation will be used.                      |
   | SkipResults   | A numeric value that defaults to 0. Used to       |
   |               | specify the number of records at the start of a   |
   |               | results set to be skipped before returning domain |
   |               | results. Can be used with MaxResults to retrieve  |
   |               | a large result set in pages.                      |
   | CountResults  | A boolean value that defaults to false. If true,  |
   |               | the response should only return the number of     |
   |               | matches for the query and no specific domain      |
   |               | details. If MaxResults or SkipResults is defined  |
   |               | and CountResults is true then the server SHALL    |
   |               | return an error response.                         |
   +---------------+---------------------------------------------------+

   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:




Hunt                    Expires January 27, 2011               [Page 23]

Internet-Draft                     SRS                         July 2010


   o  DomainNameFilter (Section 8.16)

   o  NameServerFilter (Section 8.24)

   o  RegistrantContactFilter (Section 8.12)

   o  AdminContactFilter (Section 8.12)

   o  TechnicalContactFilter (Section 8.12)

   o  ResultDateRange (Section 8.14)

   o  SearchDateRange (Section 8.14)

   o  ChangedInDateRange (Section 8.14)

   o  RegisteredDateRange (Section 8.14)

   o  LockedDateRange (Section 8.14)

   o  CancelledDateRange (Section 8.14)

   o  BilledUntilDateRange (Section 8.14)

   o  AuditTextFilter (Section 8.8)

   o  ActionIdFilter (Section 8.3)

   o  FieldList (Section 8.21)

   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.


















Hunt                    Expires January 27, 2011               [Page 24]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.DomainDetailsQry =
     element DomainDetailsQry {
       attribute QryId { UID }?,
       attribute Status { RegDomainStatus }?,
       attribute Delegate { Boolean }?,
       attribute Term { Term }?,
       attribute RegistrantRef { UID }?,
       attribute MaxResults { Number }?,
       attribute SkipResults { Number }?,
       [ a:defaultValue = "0" ] attribute CountResults { Boolean }?,
       element.DomainNameFilter*,
       element.NameServerFilter?,
       element.RegistrantContactFilter?,
       element.AdminContactFilter?,
       element.TechnicalContactFilter?,
       element.ResultDateRange?,
       element.SearchDateRange?,
       element.ChangedInDateRange?,
       element.RegisteredDateRange?,
       element.LockedDateRange?,
       element.CancelledDateRange?,
       element.BilledUntilDateRange?,
       element.AuditTextFilter?,
       element.ActionIdFilter?,
       element.FieldList?
     }

6.1.2.2.  Response

   The response to a DomainDetailsQry request will be either an Error
   (Section 7.8) element, or zero or more Domain (Section 7.6) 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



Hunt                    Expires January 27, 2011               [Page 25]

Internet-Draft                     SRS                         July 2010


   number of affects on the response:

   o  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

   o  the EffectiveDateRange will also be returned for each result
      domain, regardless of whether it was specified by a FieldList
      attribute

   o  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:

     +------------+--------------------------------------------------+
     | Attribute  | Description                                      |
     +------------+--------------------------------------------------+
     | DomainName | A text string. The name of the domain to check.  |
     | UDAI       | A text string. The UDAI to be checked.           |
     +------------+--------------------------------------------------+

   Additionally, the request may specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | QryId     | A query identifier. This has no meaning within the    |
   |           | SRS; if provided, it will be returned in the response |
   |           | to this request.                                      |
   +-----------+-------------------------------------------------------+







Hunt                    Expires January 27, 2011               [Page 26]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.UDAIValidQry =
     element UDAIValidQry {
       attribute QryId { UID }?,
       attribute DomainName { DomainName },
       attribute UDAI { UID },
       empty
     }

6.1.3.2.  Response

   The response to a UDAIValidQry request will be a UDAIValid
   (Section 7.16) 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:

   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | DomainName | A text string. The domain name for which the details |
   |            | are requested.                                       |
   +------------+------------------------------------------------------+

   Additionally, the request may specify:

   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | QryId      | A query identifier. This has no meaning within the   |
   |            | SRS; if provided, it will be returned in the         |
   |            | response to this request.                            |
   | FullResult | A boolean value. Indicates whether the full domain   |
   |            | details should be returned. If false, only the       |
   |            | status of the domain shall be returned. Defaults to  |
   |            | true.                                                |






Hunt                    Expires January 27, 2011               [Page 27]

Internet-Draft                     SRS                         July 2010


   | SourceIP   | An IP address. The source IP address of the request. |
   |            | This may be used to monitor and limit Whois          |
   |            | requests.                                            |
   +------------+------------------------------------------------------+

   Syntax:

   element.Whois =
     element Whois {
       attribute QryId { UID }?,
       [ a:defaultValue = "1" ] attribute FullResult { Boolean }?,
       attribute SourceIP { text }?,
       attribute DomainName { DomainName },
       empty
     }

6.1.4.2.  Response

   The response to a Whois request will be either an Error (Section 7.8)
   element, or a Domain (Section 7.6) 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:

   o  if the domain is not currently registered, only the domain's name
      and status ("Available") will be returned,

   o  if the request is not for a full result, only the domain status
      will be returned,

   o  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:

   o  DomainName

   o  Status

   o  RegisteredDate

   o  CancelledDate

   o  LockedDate




Hunt                    Expires January 27, 2011               [Page 28]

Internet-Draft                     SRS                         July 2010


   o  BilledUntil

   o  EffectiveFrom

   o  Delegate

   o  RegistrarPublicContact

   o  RegistrantContact

   o  AdminContact

   o  TechnicalContact

   o  NameServers

   o  AuditDetails

6.2.  Domain Write Actions

   The domain write requests are:

   +--------------+----------------------------------------------------+
   | Request      | Description                                        |
   +--------------+----------------------------------------------------+
   | DomainCreate | Register a new domain in the SRS.                  |
   | DomainUpdate | Update the stored details of an existing domain in |
   |              | the SRS.                                           |
   +--------------+----------------------------------------------------+

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.

   SRS implementations SHOULD support internationalized domain names
   (IDNs).  Domain names containing non-ASCII characters MUST use the
   Punycode encoding RFC3492 [RFC3492] for the DomainName attribute, and
   provide the domain name in the original scripts in the
   DomainNameUnicode attribute.  The DomainNameLanguage attribute may be
   used to provide a description of the original script and language for
   the domain name.






Hunt                    Expires January 27, 2011               [Page 29]

Internet-Draft                     SRS                         July 2010


6.2.1.1.  Request

   The DomainCreate request must specify:

   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | ActionId   | An action identifier. This is a unique identifier    |
   |            | for the request to the SRS server.                   |
   | DomainName | A text string. The domain name to be created. Must   |
   |            | conform to the format and syntax in RFC 1035         |
   |            | [RFC1035], RFC 1123 [RFC1123], and RFC 2181          |
   |            | [RFC2181]. For domain names containing non-ASCII     |
   |            | characters this MUST be formatted according to RFC   |
   |            | 3492 [RFC3492].                                      |
   | Term       | A numeric value. The number of months to bill when   |
   |            | the domain is registered or renewed.                 |
   +------------+------------------------------------------------------+

   Additionally, the request may specify:

   +--------------------+----------------------------------------------+
   | Attribute          | Description                                  |
   +--------------------+----------------------------------------------+
   | DomainNameUnicode  | A UTF-8 text string. The domain name in the  |
   |                    | script intended by the registrant. Used for  |
   |                    | internationalized domain names (IDNs).       |
   | DomainNameLanguage | A text string. For domain names using        |
   |                    | non-ASCII characters, this should provide    |
   |                    | the language and script for the unicode      |
   |                    | domain name. For example, ".NZ LATIN"        |
   | RegistrantRef      | A customer identifier. Assigned to the       |
   |                    | registrant by the registrar.                 |
   | Delegate           | A boolean value that defaults to true.       |
   |                    | Indicates whether the domain should be       |
   |                    | delegated to appear in the DNS. Requires     |
   |                    | details of name servers to be provided with  |
   |                    | the domain creation request.                 |
   +--------------------+----------------------------------------------+

   The request must also include a RegistrantContact (Section 8.11)
   details element for the domain, and may include elements defining the
   AdminContact (Section 8.11), TechnicalContact (Section 8.11), and
   NameServers (Section 8.23) for the domain, and also AuditText
   (Section 8.7) for the transaction.






Hunt                    Expires January 27, 2011               [Page 30]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.DomainCreate =
     element DomainCreate {
       attribute ActionId { UID },
       attribute DomainName { DomainName },
       attribute DomainNameUnicode { DomainNameUnicode }?,
       attribute DomainNameLanguage { DomainNameLanguage }?,
       attribute RegistrantRef { UID }?,
       attribute Term { Term },
       [ a:defaultValue = "1" ] attribute Delegate { Boolean }?,
       element.RegistrantContact,
       element.AdminContact?,
       element.TechnicalContact?,
       element.NameServers?,
       element.AuditText?
     }

6.2.1.2.  Response

   The response to a DomainCreate request will be either an Error
   (Section 7.8) element, or a full Domain (Section 7.6) 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:

   o  transferring a domain

   o  cancelling a domain

   o  un-cancelling a domain

   o  renewing a domain

   o  changing the delegation status of a domain

   o  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



Hunt                    Expires January 27, 2011               [Page 31]

Internet-Draft                     SRS                         July 2010


   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:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is a unique identifier for |
   |           | the request to the SRS server.                        |
   +-----------+-------------------------------------------------------+

   Additionally, the request may specify:

   +---------------+---------------------------------------------------+
   | Attribute     | Description                                       |
   +---------------+---------------------------------------------------+
   | UDAI          | A text string. The UDAI for the domain.           |
   | NewUDAI       | A boolean value. Allows the user to request       |
   |               | generation of a new UDAI for the domain. The      |
   |               | server MAY provide a new UDAI value regardless of |
   |               | the value of this parameter.                      |
   | RegistrantRef | A customer identifier. Assigned to the registrant |
   |               | by the registrar.                                 |
   | Term          | A numeric value. The number of months to bill     |
   |               | when the domain is registered or renewed.         |
   | Delegate      | A boolean value. Indicates whether the domain     |
   |               | should be delegated to appear in the DNS.         |
   |               | Requires details of name servers to be available  |
   |               | to the SRS server.                                |
   | Renew         | A boolean value. Indicates that the domain should |
   |               | be billed for a further billing period            |
   |               | immediately, rather than waiting for it to        |
   |               | expire.                                           |




Hunt                    Expires January 27, 2011               [Page 32]

Internet-Draft                     SRS                         July 2010


   | NoAutoRenew   | A boolean value. Indicates that the domain should |
   |               | not automatically renew at the expiry date. Only  |
   |               | the registry can change the automatic renewal     |
   |               | status for a domain.                              |
   | Lock          | A boolean value. Specifies the lock status of the |
   |               | domain. Locked domains cannot be updated until    |
   |               | they are unlocked by the registry. If the         |
   |               | attribute is not specified, the current lock      |
   |               | setting will remain unchanged. SRS                |
   |               | implementations MAY allow registrars to change    |
   |               | the lock status of domains.                       |
   | Cancel        | A boolean value. Specifies a request to change    |
   |               | the status of a domain. If true, a domain in      |
   |               | "Active" status will change to "PendingRelease";  |
   |               | domains in any other status will remain           |
   |               | unchanged. If false, a domain in "PendingRelease" |
   |               | status will change to "Active"; domains in any    |
   |               | other status will remain unchanged. If the        |
   |               | attribute is not specified, the current status    |
   |               | will remain unchanged.                            |
   | Release       | A boolean value. Specifies that the domain should |
   |               | become "Available" after the cancellation grace   |
   |               | period expires.                                   |
   | FullResult    | A boolean value. Specifies that a full domain     |
   |               | result is required (if true), or only the changed |
   |               | fields (if false). Defaults to true.              |
   +---------------+---------------------------------------------------+

   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
   (Section 8.16) element to identify the domain(s) to be updated and
   may include elements defining the new details for RegistrantContact
   (Section 8.11), AdminContact (Section 8.11), TechnicalContact
   (Section 8.11), and NameServers (Section 8.23) for the domain, and
   also AuditText (Section 8.7) for the transaction.













Hunt                    Expires January 27, 2011               [Page 33]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.DomainUpdate =
     element DomainUpdate {
       attribute ActionId { UID },
       attribute UDAI { UID }?,
       attribute NewUDAI { Boolean }?,
       attribute RegistrantRef { UID }?,
       attribute Term { Term }?,
       attribute Delegate { Boolean }?,
       attribute Renew { Boolean }?,
       attribute NoAutoRenew { Boolean }?,
       attribute Lock { Boolean }?,
       attribute Cancel { Boolean }?,
       attribute Release { Boolean }?,
       [ a:defaultValue = "1" ] attribute FullResult { Boolean }?,
       element.DomainNameFilter+,
       element.RegistrantContact?,
       element.AdminContact?,
       element.TechnicalContact?,
       element.NameServers?,
       element.AuditText?
     }

6.2.2.2.  Response

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

   o  DomainName

   o  AuditDetails

   o  Status

   o  Delegate

   o  Term

   o  NameServers

   o  RegistrantRef

   o  RegistrarId

   o  RegistrantContact




Hunt                    Expires January 27, 2011               [Page 34]

Internet-Draft                     SRS                         July 2010


   o  AdminContact

   o  TechnicalContact

   o  BilledUntil

   o  RegisteredDate

   o  CancelledDate

   o  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.  Handle Query Action

   The system provides a single request for accessing details of
   handles:

      +------------------+-----------------------------------------+
      | Action           | Description                             |
      +------------------+-----------------------------------------+
      | HandleDetailsQry | Retrieve the details of object handles. |
      +------------------+-----------------------------------------+

6.3.1.  HandleDetailsQry

   The HandleDetailsQry request allows the user to retrieve the details
   of handles that match their search parameters.  Handles are used to
   provide a simple shorthand for referring to registrant details in the
   registry.

   Registrars SHALL be limited to accessing details of handles
   associated directly with their RegistrarID.  The registry user may
   search details of all handles.

6.3.1.1.  Request

   The HandleDetailsQry request may specify:










Hunt                    Expires January 27, 2011               [Page 35]

Internet-Draft                     SRS                         July 2010


   +--------------+----------------------------------------------------+
   | Attribute    | Description                                        |
   +--------------+----------------------------------------------------+
   | MaxResults   | A numeric value. Used to specify the maximum       |
   |              | number of handle records to return. If not         |
   |              | specified, the default defined by the server       |
   |              | implementation will be used.                       |
   | SkipResults  | A numeric value that defaults to 0. Used to        |
   |              | specify the number of records at the start of a    |
   |              | results set to be skipped before returning handle  |
   |              | results. Can be used with MaxResults to retrieve a |
   |              | large result set in pages.                         |
   | CountResults | A boolean value that defaults to false. If true,   |
   |              | the response should only return the number of      |
   |              | matches for the query and no specific handle       |
   |              | details. If MaxResults or SkipResults is defined   |
   |              | and CountResults is true then the server SHALL     |
   |              | return an error response.                          |
   +--------------+----------------------------------------------------+

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

   o  HandleIdFilter (Section 8.22)

   o  SearchDateRange (Section 8.14)

   o  ChangedInDateRange (Section 8.14)

   o  ContactFilter (Section 8.12)

   Syntax:

   element.HandleDetailsQry =
     element HandleDetailsQry {
       attribute MaxResults { Number }?,
       attribute SkipResults { Number }?,
       [ a:defaultValue = "0" ] attribute CountResults { Boolean }?,
       element.HandleIdFilter*,
       element.SearchDateRange?,
       element.ChangedInDateRange?,
       element.ContactFilter?
   }

6.3.1.2.  Response

   The response to a HandleDetailsQry request will be either an Error
   (Section 7.8) element or zero or more Handle (Section 7.9) elements -



Hunt                    Expires January 27, 2011               [Page 36]

Internet-Draft                     SRS                         July 2010


   dependent on the number of handles matched the query specification.

   If CountResults was specified in the request and the request was
   valid, then the number of rows that matched the query specification
   shall be returned, but no Handle elements will be included.

6.4.  Handle Write Actions

   The handle write requests are:

   +--------------+----------------------------------------------------+
   | Request      | Description                                        |
   +--------------+----------------------------------------------------+
   | HandleCreate | Request creation of a new handle belonging to the  |
   |              | current registrar (or effective registrar) with    |
   |              | the provided details.                              |
   | HandleUpdate | Request update of handle details for a handle      |
   |              | belonging to the current registrar (or effective   |
   |              | registar).                                         |
   +--------------+----------------------------------------------------+

6.4.1.  HandleCreate

   The HandleCreate request allows users to request the creation of a
   new handle in the SRS.  The handle created will belong to the
   registrar that makes the request - or to the effective registrar for
   the request, if the request is made by the registry.  This request
   will only be successful if a handle with the same identifier
   belonging to the current effective registrar does not already exist.

6.4.1.1.  Request

   The HandleCreate request must specify:

   +--------------------------------+----------------------------------+
   | Attribute                      | Description                      |
   +--------------------------------+----------------------------------+
   | ActionId                       | An action identifier. This is a  |
   |                                | unique identifier for the        |
   |                                | request to the SRS server.       |
   | A handle identifier. This is a |                                  |
   | unique identifier for the      |                                  |
   | handle to be created.          |                                  |
   +--------------------------------+----------------------------------+

   The request may also include ContactAttr (Section 9.4.2) entity and a
   Contact (Section 9.4.1) entity to provide contact details for the
   handle, and AuditText (Section 8.7) for the transaction.



Hunt                    Expires January 27, 2011               [Page 37]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.HandleCreate =
     element HandleCreate {
       attribute ActionId { UID },
       attribute HandleId { UID },
       ContactAttr,
       Contact,
       element.AuditText?
     }

6.4.1.2.  Response

   The response to a HandleCreate request will be either an Error
   (Section 7.8) element, or a full Handle (Section 7.9) element.  The
   Handle element will only be returned if the handle creation is
   successful.

6.4.2.  HandleUpdate

   The HandleUpdate request allows the user to update detais for a
   contact handle that they previously created.  The registry may
   maintain information for handles belonging to any registrar.

6.4.2.1.  Request

   The request must specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is a unique identifier for |
   |           | the request to the SRS server.                        |
   | HandleId  | A handle identifier. This is a unique identifier for  |
   |           | the handle to be created.                             |
   +-----------+-------------------------------------------------------+

   Additionally, the request may specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | Delete    | A boolean value that defaults to false. If true, the  |
   |           | update should cause the matching handle belonging to  |
   |           | the effective registrar to be deleted.                |
   +-----------+-------------------------------------------------------+

   The HandleUpdate request may also include new contact details for the



Hunt                    Expires January 27, 2011               [Page 38]

Internet-Draft                     SRS                         July 2010


   handle and audit details for the update:

   o  ContactAttr (Section 9.4.2)

   o  Contact (Section 9.4.1)

   o  AuditText (Section 8.7)

   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.HandleUpdate =
     element HandleUpdate {
       attribute ActionId { UID },
       attribute HandleId { UID },
       attribute Delete { Boolean }?,
       ContactAttr,
       Contact,
       element.AuditText?
     }

6.4.2.2.  Response

   The response to a HandleUpdate request will be either an Error
   (Section 7.8) element or a Handle (Section 7.12) element showing the
   updated state of the handle details.

6.5.  Message Query Action

   Registrars are provided with a single request for obtaining messages
   from the system:

   +-------------+-----------------------------------------------------+
   | Request     | Description                                         |
   +-------------+-----------------------------------------------------+
   | GetMessages | Retrieve responses generated by the SRS server for  |
   |             | a registrar.                                        |
   +-------------+-----------------------------------------------------+

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



Hunt                    Expires January 27, 2011               [Page 39]

Internet-Draft                     SRS                         July 2010


   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.5.1.1.  Request

   The GetMessages request that may specify:

   +------------------------+------------------------------------------+
   | Attribute              | Description                              |
   +------------------------+------------------------------------------+
   | QryId                  | A query identifier. This has no meaning  |
   |                        | within the SRS; if provided, it will be  |
   |                        | returned in the response to this         |
   |                        | request.                                 |
   | OriginatingRegistrarId | A user identifier. The identifier of the |
   |                        | registrar that originally requested the  |
   |                        | action. Also accepts the special "other  |
   |                        | registrar" (Section 9.13.2) value.       |
   | ActionId               | An action identifier. This is the action |
   |                        | identifier for a previous request to the |
   |                        | SRS.                                     |
   | RecipientRegistrarId   | A user identifier. The registrar         |
   |                        | identifier of the registrar that the     |
   |                        | messages retrieved were intended for.    |
   |                        | Only registry users can retrieve         |
   |                        | messages intended for a user other than  |
   |                        | themselves.                              |
   | MaxResults             | A numeric value. Used to specify the     |
   |                        | maximum number of messages to return. If |
   |                        | not specified, the default defined by    |
   |                        | the server implementation will be used.  |
   | SkipResults            | A numeric value. Used to specify the     |
   |                        | number of records at the start of a      |
   |                        | results set to be skipped before         |
   |                        | returning domain results. Can be used    |
   |                        | with MaxResults to retrieve a large      |
   |                        | result set in pages.                     |
   | CountResults           | A boolean value that defaults to false.  |
   |                        | If true, the response should only return |
   |                        | the number of matches for the query and  |
   |                        | no messages. If MaxResults or            |
   |                        | SkipResults is defined and CountResults  |
   |                        | is true then the server SHALL return an  |
   |                        | error response.                          |





Hunt                    Expires January 27, 2011               [Page 40]

Internet-Draft                     SRS                         July 2010


   | QueueMode              | A boolean value that defaults to false.  |
   |                        | If true, the response should only return |
   |                        | messages that have not previously been   |
   |                        | acknowledged (using AckMessage).         |
   +------------------------+------------------------------------------+

   The GetMessages request may also include a TransDateRange
   (Section 8.14) element, an AuditTextFilter (Section 8.8) element and
   may include one or more TypeFilter (Section 8.28) elements to limit
   the type of messages returned.

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

   Syntax:

   element.GetMessages =
     element GetMessages {
       attribute QryId { UID }?,
       attribute OriginatingRegistrarId { RegistrarIdOrOTHERS }?,
       attribute ActionId { UID }?,
       attribute RecipientRegistrarId { RegistrarId }?,
       attribute MaxResults { Number }?,
       attribute SkipResults { Number }?,
       [ a:defaultValue = "0" ] attribute CountResults { Boolean }?,
       [ a:defaultValue = "0" ] attribute QueueMode { Boolean }?,
       element.TransDateRange?,
       element.AuditTextFilter?,
       element.TypeFilter*
     }

6.5.1.2.  Response

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

6.6.  Message Write Action

   Registrars are provided with a single request for acknowledging
   receipt of messages from the system:









Hunt                    Expires January 27, 2011               [Page 41]

Internet-Draft                     SRS                         July 2010


   +------------+------------------------------------------------------+
   | Request    | Description                                          |
   +------------+------------------------------------------------------+
   | AckMessage | Acknowledge receipt of a message retrieved using     |
   |            | GetMessages.                                         |
   +------------+------------------------------------------------------+

6.6.1.  RegistrarUpdate

   The AckMessage request allows the user to acknowledge receipt of a
   message retrieved using GetMessages to prevent the system from
   returning the message in response to subsequent GetMessages requests.

6.6.1.1.  Request

   The request must specify:

   +-----------------+-------------------------------------------------+
   | Attribute       | Description                                     |
   +-----------------+-------------------------------------------------+
   | ActionId        | An action identifier. This is a unique          |
   |                 | identifier for the request to the SRS server.   |
   | OrigRegistrarId | The unique identifier for the user that         |
   |                 | submitted the request to the SRS server.        |
   | TransId         | The identifier (either an ActionId or a QryId)  |
   |                 | for the transaction submitted by the user that  |
   |                 | originated the request.                         |
   +-----------------+-------------------------------------------------+

   Syntax:

   element.AckMessage =
     element AckMessage {
       attribute ActionId { UID },
       attribute OriginatingRegistrarId { RegistrarId },
       attribute TransId { UID }
     }

6.6.1.2.  Response

   The response to an AckMessage request will be either an Error
   (Section 7.8) element or a Response (Section 5.2.1) element.

6.7.  Registrar Query Actions

   The registrar query requests are:





Hunt                    Expires January 27, 2011               [Page 42]

Internet-Draft                     SRS                         July 2010


   +---------------------+---------------------------------------------+
   | Request             | Description                                 |
   +---------------------+---------------------------------------------+
   | RegistrarAccountQry | Request details of transactions in the      |
   |                     | account of a registrar.                     |
   | RegistrarDetailsQry | Request the registrar details stored by the |
   |                     | SRS server.                                 |
   +---------------------+---------------------------------------------+

6.7.1.  RegistrarAccountQry

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

6.7.1.1.  Request

   The request may specify:

   +---------------+---------------------------------------------------+
   | Attribute     | Description                                       |
   +---------------+---------------------------------------------------+
   | QryId         | A query identifier. This has no meaning within    |
   |               | the SRS; if provided, it will be returned in the  |
   |               | response to this request.                         |
   | RegistrantRef | A text filter. Matched against the                |
   |               | registrar-provided customer reference of a        |
   |               | registrant.                                       |
   | DomainName    | A text filter. Matched against the domain name    |
   |               | that billing amounts relate to.                   |
   | InvoiceId     | An invoice identifier. Used to match billing      |
   |               | records that have been associated with an         |
   |               | invoice.                                          |
   | MaxResults    | A numeric value. Used to specify the maximum      |
   |               | number of messages to return. If not specified,   |
   |               | the default defined by the server implementation  |
   |               | will be used.                                     |
   | SkipResults   | A numeric value. Used to specify the number of    |
   |               | records at the start of a results set to be       |
   |               | skipped before returning domain results. Can be   |
   |               | used with MaxResults to retrieve a large result   |
   |               | set in pages.                                     |
   | TransStatus   | A BillStatus (Section 9.2.2) value. Used to       |
   |               | filter on the bill status of billing amounts.     |








Hunt                    Expires January 27, 2011               [Page 43]

Internet-Draft                     SRS                         July 2010


   | CountResults  | A boolean value that defaults to false. If true,  |
   |               | the response should only return the number of     |
   |               | matches for the query and no messages. If         |
   |               | MaxResults or SkipResults is defined and          |
   |               | CountResults is true then the server SHALL return |
   |               | an error response.                                |
   +---------------+---------------------------------------------------+

   The RegistrarAccountQry request may also include a TransDateRange
   (Section 8.14) element and an InvoiceDateRange (Section 8.14)
   element.

   Syntax:

   element.RegistrarAccountQry =
     element RegistrarAccountQry {
       attribute QryId { UID }?,
       attribute RegistrantRef { UID }?,
       attribute DomainName { DomainName }?,
       attribute InvoiceId { UID }?,
       attribute MaxResults { Number }?,
       attribute SkipResults { Number }?,
       attribute TransStatus { BillStatus }?,
       [ a:defaultValue = "0" ] attribute CountResults { Boolean }?,
       element.TransDateRange?,
       element.InvoiceDateRange?
     }

6.7.1.2.  Response

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

6.7.2.  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.7.2.1.  Request

   The request may specify:







Hunt                    Expires January 27, 2011               [Page 44]

Internet-Draft                     SRS                         July 2010


   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | QryId       | A query identifier. This has no meaning within the  |
   |             | SRS; if provided, it will be returned in the        |
   |             | response to this request.                           |
   | RegistrarId | A user identifier. The registrar identifier of the  |
   |             | registrar to retrieve stored details for.           |
   | NameFilter  | A text filter. Matched against the registrar names  |
   |             | stored in the SRS server.                           |
   +-------------+-----------------------------------------------------+

   The RegistrarDetailsQry request may also include a ResultDateRange
   (Section 8.14) 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 =
     element RegistrarDetailsQry {
       attribute QryId { UID }?,
       attribute RegistrarId { RegistrarId }?,
       attribute NameFilter { text }?,
       element.ResultDateRange?
     }

6.7.2.2.  Response

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

6.8.  Registrar Write Actions

   Registrars typically only have access to a single request for the
   maintenance of their details stored at the SRS:








Hunt                    Expires January 27, 2011               [Page 45]

Internet-Draft                     SRS                         July 2010


    +-----------------+-----------------------------------------------+
    | Request         | Description                                   |
    +-----------------+-----------------------------------------------+
    | RegistrarUpdate | Updates the details stored about a registrar. |
    +-----------------+-----------------------------------------------+

6.8.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.8.1.1.  Request

   The request must specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is a unique identifier for |
   |           | the request to the SRS server.                        |
   +-----------+-------------------------------------------------------+

   Additionally, the request may specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | Name      | A text string. The registrar's identifier in the      |
   |           | registry's accounting system.                         |
   | AccRef    | A text string. The registrar's identifier in the      |
   |           | registry's accounting system.                         |
   | URL       | A text string. The registrar's public web site        |
   |           | address.                                              |
   +-----------+-------------------------------------------------------+

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

   o  RegistrarPublicContact (Section 8.11)

   o  RegistrarSRSContact (Section 8.11)

   o  DefaultTechnicalContact (Section 8.11)

   o  EncryptKeys (Section 8.18)





Hunt                    Expires January 27, 2011               [Page 46]

Internet-Draft                     SRS                         July 2010


   o  EPPAuth (Section 8.19)

   o  Allowed2LDs (Section 8.5)

   o  Roles (Section 8.32)

   o  AuditText (Section 8.7)

   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 =
     element RegistrarUpdate {
       attribute ActionId { UID },
       attribute Name { text }?,
       attribute AccRef { text }?,
       attribute URL { text }?,
       element.RegistrarPublicContact?,
       element.RegistrarSRSContact?,
       element.DefaultTechnicalContact?,
       element.EncryptKeys?,
       element.EPPAuth?,
       element.Allowed2LDs?,
       element.Roles?,
       element.AuditText?
     }

6.8.1.2.  Response

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

6.9.  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:









Hunt                    Expires January 27, 2011               [Page 47]

Internet-Draft                     SRS                         July 2010


   +--------------------------+----------------------------------------+
   | Request                  | Description                            |
   +--------------------------+----------------------------------------+
   | AccessControlListAdd     | Adds one or more entries to the        |
   |                          | registry's access control list.        |
   | AccessControlListQry     | Queries the registry's access control  |
   |                          | list.                                  |
   | AccessControlListRemove  | Removes one or more entries from the   |
   |                          | registry's access control list.        |
   | AdjustRegistrarAccount   | Creates billing transactions in order  |
   |                          | to adjust the details of a registrar's |
   |                          | account with the registry.             |
   | BilledUntilAdjustment    | Adjusts the end date of billing for a  |
   |                          | domain name.                           |
   | BuildDnsZoneFiles        | Builds the registry's DNS zone files   |
   |                          | including details of all of the        |
   |                          | currently delegated domain.            |
   | DeferredIncomeDetailQry  | Reports on the billing transactions    |
   |                          | that contribute to an amount of        |
   |                          | deferred income for an income month.   |
   | DeferredIncomeSummaryQry | Reports on all deferred income for an  |
   |                          | income month.                          |
   | GenerateDomainReport     | Generates a report on all of the       |
   |                          | domains registered in the SRS.         |
   | BillingAmountQry         | Queries the per-term charge for domain |
   |                          | registration over time.                |
   | RegistrarCreate          | Creates a new registrar in the SRS and |
   |                          | assigns initial details to the record. |
   | RunLogCreate             | Creates an entry in the SRS server     |
   |                          | log.                                   |
   | RunLogQry                | Queries details of entries in the SRS  |
   |                          | server log.                            |
   | ScheduleCancel           | Cancels a scheduled process in the SRS |
   |                          | server.                                |
   | ScheduleCreate           | Creates a scheduled process in the SRS |
   |                          | server.                                |
   | ScheduleQry              | Queries details of a scheduled process |
   |                          | in the SRS server.                     |
   | ScheduleUpdate           | Updates the details of a scheduled     |
   |                          | process in the SRS server.             |
   | BillingAmountUpdate      | Inserts a new per-term charge for      |
   |                          | domain registrations.                  |
   | SysParamsCreate          | Creates new configurable system        |
   |                          | parameter entries in the SRS server.   |
   | SysParamsQry             | Queries the details of configurable    |
   |                          | system parameters in the SRS server.   |





Hunt                    Expires January 27, 2011               [Page 48]

Internet-Draft                     SRS                         July 2010


   | SysParamsUpdate          | Updates the details of configurable    |
   |                          | system parameters in the SRS server.   |
   +--------------------------+----------------------------------------+

6.9.1.  AccessControlListAdd

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

6.9.1.1.  Request

   The request must specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is a unique identifier for |
   |           | the request to the SRS server.                        |
   | Resource  | A text string. An identifier for the system or        |
   |           | resource to which the access control list entries     |
   |           | should be added. For example, this might specify a    |
   |           | service name such as "whoisd".                        |
   | List      | A text string. A description of the function of the   |
   |           | access control list to which the access control lists |
   |           | should be added. For example, "allow" or "deny".      |
   +-----------+-------------------------------------------------------+

   Additionally, the request may specify:

   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | FullResult | A boolean value. Indicates whether the result        |
   |            | returned should contain full details of entries in   |
   |            | the modified access control lists.                   |
   +------------+------------------------------------------------------+

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










Hunt                    Expires January 27, 2011               [Page 49]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.AccessControlListAdd =
     element AccessControlListAdd {
       attribute Resource { text },
       attribute List { text },
       attribute ActionId { UID },
       [ a:defaultValue = "1" ] attribute FullResult { Boolean }?,
       element.AccessControlListEntry+,
       element.AuditText?
     }

6.9.1.2.  Response

   The response to an AccessControlListAdd request will be either an
   Error (Section 7.8) or one AccessControlList (Section 7.1) element.
   The attribute SizeChange will indicate the number of entries added.

6.9.2.  AccessControlListQry

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

6.9.2.1.  Request

   The request may specify:

   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | Resource   | A text string. Used to match the system or resource  |
   |            | name of the access control list.                     |
   | List       | A text string. Used to match the name of the access  |
   |            | control list.                                        |
   | Type       | A text string. Specifies what datatype the list is.  |
   | FullResult | A boolean value. Indicates whether the result        |
   |            | returned should contain full details of entries in   |
   |            | the matched access control lists.                    |
   +------------+------------------------------------------------------+












Hunt                    Expires January 27, 2011               [Page 50]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.AccessControlListQry =
     element AccessControlListQry {
       attribute Resource { text }?,
       attribute List { text }?,
       attribute Type { text }?,
       [ a:defaultValue = "0" ] attribute FullResult { Boolean }?,
       AccessControlListContentFilter*
     }

6.9.2.2.  Response

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

   Type must be provided to return AccessControlListEntry elements
   inside the AccessControlList (Section 7.1) element.  Currently
   supported values for Type are: "ip", "domain", "registrar",
   "registrar_ip" and "registrar_domain".

   If Type is provided the AccessControlListQry element may contain some
   AccessControlListContentFilter (Section 8.1) elements to search on
   the list's contents.

   If Type is provided and FullResult is 1, the response will contain
   AccessControlList elements and AccessControlListEntry elements with
   their EffectiveDate elements for matched lists.

6.9.3.  AccessControlListRemove

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

6.9.3.1.  Request

   The request must specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is a unique identifier for |
   |           | the request to the SRS server.                        |
   | Resource  | A text string. An identifier for the system or        |
   |           | resource of the access control list from which the    |
   |           | entries should be removed.                            |



Hunt                    Expires January 27, 2011               [Page 51]

Internet-Draft                     SRS                         July 2010


   | List      | A text string. A description of the function of the   |
   |           | access control list from which the entries should be  |
   |           | removed.                                              |
   +-----------+-------------------------------------------------------+

   Additionally, the request may specify:

   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | FullResult | A boolean value. Indicates whether the result        |
   |            | returned should contain full details of entries in   |
   |            | the modified access control lists.                   |
   +------------+------------------------------------------------------+

   The AccessControlListRemove request must also include one or more
   AccessControlListEntry (Section 8.2) elements to specify the entries
   to be removed from the access control lists, and may include an
   AuditText (Section 8.7) element.

   Syntax:

   element.AccessControlListRemove =
     element AccessControlListRemove {
       attribute Resource { text },
       attribute List { text },
       attribute ActionId { UID },
       [ a:defaultValue = "1" ] attribute FullResult { Boolean }?,
       element.AccessControlListEntry*,
       element.AuditText?
     }

6.9.3.2.  Response

   The response to an AccessControlListRemove request will be either an
   Error (Section 7.8) or one AccessControlList (Section 7.1) element.
   The attribute SizeChange will indicate the number of entries removed;
   this will be a negative integer or zero.

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





Hunt                    Expires January 27, 2011               [Page 52]

Internet-Draft                     SRS                         July 2010


6.9.4.1.  Request

   The request must specify:

   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | ActionId    | An action identifier. This is a unique identifier   |
   |             | for the request to the SRS server.                  |
   | RegistrarId | A user identifier. The identifier of the registrar  |
   |             | whose account is to be adjusted.                    |
   | DomainName  | A text string. The name of the domain for which the |
   |             | registrar's account is being adjusted.              |
   | Months      | An integer. The number of months of payment to      |
   |             | credit to, or debit from the registrar's account    |
   |             | for the specified domain.                           |
   | ActionType  | A text string. A valid accounting action; either    |
   |             | 'Credit' or 'Debit'.                                |
   +-------------+-----------------------------------------------------+

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

   Syntax:

   element.AdjustRegistrarAccount =
     element AdjustRegistrarAccount {
       attribute RegistrarId { RegistrarId },
       attribute DomainName { DomainName },
       attribute ActionId { UID },
       attribute Months { Number },
       attribute ActionType { AccountingAction },
       element.TransactionDate,
       element.BillPeriodStart,
       element.BillPeriodEnd,
       element.AuditText
     }

6.9.4.2.  Response

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





Hunt                    Expires January 27, 2011               [Page 53]

Internet-Draft                     SRS                         July 2010


6.9.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.9.5.1.  Request

   The request must specify:

   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | DomainName | A text string. The name of the domain to adjust the  |
   |            | billed until date for.                               |
   | ActionId   | An action identifier. This is a unique identifier    |
   |            | for the request to the SRS server.                   |
   +------------+------------------------------------------------------+

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

   Syntax:

   element.BilledUntilAdjustment =
     element BilledUntilAdjustment {
       attribute DomainName { DomainName },
       attribute ActionId { UID },
       element.NewBilledUntilDate,
       element.AuditText
     }

6.9.5.2.  Response

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

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



Hunt                    Expires January 27, 2011               [Page 54]

Internet-Draft                     SRS                         July 2010


   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.9.6.1.  Request

   The request must specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is a unique identifier for |
   |           | the request to the SRS server.                        |
   +-----------+-------------------------------------------------------+

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

   Syntax:

   element.BuildDnsZoneFiles =
     element BuildDnsZoneFiles {
       attribute ActionId { UID },
       element.RunDate
     }

6.9.6.2.  Response

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

6.9.7.  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 (Section 6.9.8) request).

6.9.7.1.  Request

   The request must specify:






Hunt                    Expires January 27, 2011               [Page 55]

Internet-Draft                     SRS                         July 2010


   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | BaseMonth   | An integer. The latest month (January = 1, December |
   |             | = 12) of the base year to consider billing          |
   |             | transactions for when calculating deferred income.  |
   |             | Billing transactions up to, and including, this     |
   |             | month will be included.                             |
   | BaseYear    | An integer. The latest year to consider billing     |
   |             | transactions for when calculating deferred income.  |
   | IncomeMonth | An integer. The month (January = 1, December = 12)  |
   |             | of the income year to calculate deferred income     |
   |             | for.                                                |
   | IncomeYear  | An integer. The year to calculate deferred income   |
   |             | for.                                                |
   +-------------+-----------------------------------------------------+

   Additionally, the request may specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | QryId     | A query identifier. This has no meaning within the    |
   |           | SRS; if provided, it will be returned in the response |
   |           | to this request.                                      |
   +-----------+-------------------------------------------------------+

   Syntax:

   element.DeferredIncomeDetailQry =
     element DeferredIncomeDetailQry {
       attribute BaseMonth { text },
       attribute BaseYear { text },
       attribute IncomeMonth { text },
       attribute IncomeYear { text },
       attribute QryId { UID }?,
       empty
     }

6.9.7.2.  Response

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






Hunt                    Expires January 27, 2011               [Page 56]

Internet-Draft                     SRS                         July 2010


6.9.8.  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.9.8.1.  Request

   The request must specify:

   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | BaseMonth   | An integer. The latest month (January = 1, December |
   |             | = 12) of the base year to consider billing          |
   |             | transactions for when calculating deferred income.  |
   |             | Billing transactions up to, and including, this     |
   |             | month will be included.                             |
   | BaseYear    | An integer. The latest year to consider billing     |
   |             | transactions for when calculating deferred income.  |
   | IncomeMonth | An integer. The month (January = 1, December = 12)  |
   |             | of the income year to calculate deferred income     |
   |             | for.                                                |
   | IncomeYear  | An integer. The year to calculate deferred income   |
   |             | for.                                                |
   +-------------+-----------------------------------------------------+

   Additionally, the request may specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | QryId     | A query identifier. This has no meaning within the    |
   |           | SRS; if provided, it will be returned in the response |
   |           | to this request.                                      |
   +-----------+-------------------------------------------------------+















Hunt                    Expires January 27, 2011               [Page 57]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.DeferredIncomeSummaryQry =
     element DeferredIncomeSummaryQry {
       attribute BaseMonth { text },
       attribute BaseYear { text },
       attribute IncomeMonth { text },
       attribute IncomeYear { text },
       attribute QryId { UID }?,
       empty
     }

6.9.8.2.  Response

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

6.9.9.  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.9.9.1.  Request

   The request must specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is a unique identifier for |
   |           | the request to the SRS server.                        |
   +-----------+-------------------------------------------------------+

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

   Syntax:

   element.GenerateDomainReport =
     element GenerateDomainReport {
       attribute ActionId { UID },
       element.RunDate
     }



Hunt                    Expires January 27, 2011               [Page 58]

Internet-Draft                     SRS                         July 2010


6.9.9.2.  Response

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

6.9.10.  BillingAmountQry

   The BillingAmountQry 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.9.10.1.  Request

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

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | QryId     | A query identifier. This has no meaning within the    |
   |           | SRS; if provided, it will be returned in the response |
   |           | to this request.                                      |
   +-----------+-------------------------------------------------------+

   Syntax:

   element.BillingAmountQry =
     element BillingAmountQry {
       attribute QryId { UID }?,
       empty
     }

6.9.10.2.  Response

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

6.9.11.  RegistrarCreate

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






Hunt                    Expires January 27, 2011               [Page 59]

Internet-Draft                     SRS                         July 2010


6.9.11.1.  Request

   The request must specify:

   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | ActionId    | An action identifier. This is a unique identifier   |
   |             | for the request to the SRS server.                  |
   | Name        | A text string. The name of the registrar.           |
   | AccRef      | A text string. The registrar's identifier in the    |
   |             | registry's accounting system.                       |
   | RegistrarId | A user identifier. The unique number to be assigned |
   |             | to the new registrar.                               |
   +-------------+-----------------------------------------------------+

   Additionally, the request may specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | URL       | A text string. The registrar's public web site        |
   |           | address.                                              |
   +-----------+-------------------------------------------------------+

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

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










Hunt                    Expires January 27, 2011               [Page 60]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.RegistrarCreate =
     element RegistrarCreate {
       attribute ActionId { UID },
       attribute Name { text },
       attribute AccRef { text },
       attribute RegistrarId { RegistrarId },
       attribute URL { text }?,
       element.RegistrarPublicContact,
       element.RegistrarSRSContact,
       element.DefaultTechnicalContact,
       element.EncryptKeys,
       element.EPPAuth?,
       element.Allowed2LDs?,
       element.Roles?,
       element.AuditText?
     }

6.9.11.2.  Response

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

6.9.12.  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.9.12.1.  Request

   The request must specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is a unique identifier for |
   |           | the request to the SRS server.                        |
   +-----------+-------------------------------------------------------+

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




Hunt                    Expires January 27, 2011               [Page 61]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.RunLogCreate =
     element RunLogCreate {
       attribute ActionId { UID },
       element.FirstRunDate,
       element.RunLog
     }

6.9.12.2.  Response

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

6.9.13.  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.9.13.1.  Request

   The request may specify:

   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | QryId       | A query identifier. This has no meaning within the  |
   |             | SRS; if provided, it will be returned in the        |
   |             | response to this request.                           |
   | ProcessName | A text string. The name of a scheduled job process  |
   |             | that created the run log. This will be matched      |
   |             | against existing run log entries to limit the       |
   |             | results returned.                                   |
   | Parameters  | A text string. The parameters with which a process  |
   |             | was called. This will be matched against existing   |
   |             | run log entries to limit the results returned.      |
   +-------------+-----------------------------------------------------+

   The RunLogQry request may also include a LogDateRange (Section 8.14)
   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.




Hunt                    Expires January 27, 2011               [Page 62]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.RunLogQry =
     element RunLogQry {
       attribute QryId { UID }?,
       attribute ProcessName { text }?,
       attribute Parameters { text }?,
       element.LogDateRange?
     }

6.9.13.2.  Response

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

6.9.14.  ScheduleCancel

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

6.9.14.1.  Request

   The request must specify:

   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | ActionId    | An action identifier. This is a unique identifier   |
   |             | for the request to the SRS server.                  |
   | ProcessName | A text string. The name of a scheduled job process  |
   |             | to be cancelled.                                    |
   +-------------+-----------------------------------------------------+

   Additionally, the request may specify:

   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | Parameters | A text string. The parameters with which a process   |
   |            | to be cancelled was called.                          |
   +------------+------------------------------------------------------+

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



Hunt                    Expires January 27, 2011               [Page 63]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.ScheduleCancel =
     element ScheduleCancel {
       attribute ActionId { UID },
       attribute ProcessName { ScheduledJob },
       attribute Parameters { text }?,
       element.FirstRunDate,
       element.AuditText?
     }

6.9.14.2.  Response

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

6.9.15.  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
   (Section 9.16.1) entity.

6.9.15.1.  Request

   The request must specify:

   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | ActionId    | An action identifier. This is a unique identifier   |
   |             | for the request to the SRS server.                  |
   | ProcessName | A text string. The name of the process to be        |
   |             | executed at the designated time.                    |
   | Frequency   | An text string. The delay between repeat executions |
   |             | of the process, after the initial run date. The     |
   |             | format for this is implementation dependent but it  |
   |             | is recommended that a simple text description be    |
   |             | used; as examples: "15 minutes", "1 hour", "1 day". |
   |             | Registries should ensure that the frequency is not  |
   |             | shorter than the run-time for the process.          |
   +-------------+-----------------------------------------------------+

   Additionally, the request may specify:




Hunt                    Expires January 27, 2011               [Page 64]

Internet-Draft                     SRS                         July 2010


   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | Parameters | A text string. The parameters to be passed to the    |
   |            | process when it is executed.                         |
   +------------+------------------------------------------------------+

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

   Syntax:

   element.ScheduleCreate =
     element ScheduleCreate {
       attribute ProcessName { ScheduledJob },
       attribute Frequency { text },
       attribute Parameters { text }?,
       attribute ActionId { UID },
       element.FirstRunDate,
       element.FinalRunDate?,
       element.AuditText?
     }

6.9.15.2.  Response

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

6.9.16.  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.9.16.1.  Request

   The request may specify:








Hunt                    Expires January 27, 2011               [Page 65]

Internet-Draft                     SRS                         July 2010


   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | QryId       | A query identifier. This has no meaning within the  |
   |             | SRS; if provided, it will be returned in the        |
   |             | response to this request.                           |
   | ProcessName | A text string. Used to match against the name of a  |
   |             | scheduled process.                                  |
   | Parameters  | A text string. Used to match against the parameters |
   |             | specified for a scheduled process.                  |
   +-------------+-----------------------------------------------------+

   The ScheduleQry request may also include an ActiveOn (Section 8.38)
   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 (Section 8.38) element to
   match against the first run dates of scheduled jobs.

   Syntax:

   element.ScheduleQry =
     element ScheduleQry {
       attribute QryId { UID }?,
       attribute ProcessName { text }?,
       attribute Parameters { text }?,
       element.ActiveOn?,
       element.FirstRunDate?
     }

6.9.16.2.  Response

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

6.9.17.  ScheduleUpdate

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

6.9.17.1.  Request

   The request may specify:








Hunt                    Expires January 27, 2011               [Page 66]

Internet-Draft                     SRS                         July 2010


   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | ActionId    | An action identifier. This is a unique identifier   |
   |             | for the request to the SRS server.                  |
   | ProcessName | A text string. The name of the process to be        |
   |             | executed at the designated time.                    |
   +-------------+-----------------------------------------------------+

   Additionally, the request may specify:

   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | Parameters | A text string. The parameters to be passed to the    |
   |            | process when it is executed.                         |
   +------------+------------------------------------------------------+

   The ScheduleUpdate request must also include a FirstRunDate
   (Section 8.38) element to specify the new first run date for the
   process.  The request may include a LastRunDate (Section 8.38)
   element to specify a new date at which the process last ran and an
   AuditText (Section 8.7) element providing details about the schedule
   update request.

   Syntax:

   element.ScheduleUpdate =
     element ScheduleUpdate {
       attribute ActionId { UID },
       attribute Parameters { text }?,
       attribute Frequency { text }?,
       attribute ProcessName { ScheduledJob },
       element.FirstRunDate,
       element.LastRunDate?,
       element.AuditText?
     }

6.9.17.2.  Response

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

6.9.18.  BillingAmountUpdate

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



Hunt                    Expires January 27, 2011               [Page 67]

Internet-Draft                     SRS                         July 2010


   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 BillingAmountUpdate 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.9.18.1.  Request

   The request must specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is a unique identifier for |
   |           | the request to the SRS server.                        |
   +-----------+-------------------------------------------------------+

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

   Syntax:

   element.BillingAmountUpdate =
     element BillingAmountUpdate {
       attribute ActionId { UID },
       element.BillingAmount
     }

   Example:

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

6.9.18.2.  Response

   The response to a BillingAmountUpdate request will be either an Error
   (Section 7.8) element or a set of BillingAmount (Section 7.3)
   elements, one for each billing amount in the history of the SRS



Hunt                    Expires January 27, 2011               [Page 68]

Internet-Draft                     SRS                         July 2010


   server and the new value.

   Example:

   <Response Action="BillingAmountUpdate" 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.9.19.  SysParamsCreate

   The SysParamsCreate request allows the registry to add configurable
   parameters to the SRS server.

6.9.19.1.  Request

   The request must specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is a unique identifier for |
   |           | the request to the SRS server.                        |
   +-----------+-------------------------------------------------------+

   The SysParamsCreate request must include one or more SysParam
   (Section 7.15) elements containing the new parameters and their
   details.

   The SysParamsCreate request may also include an AuditText
   (Section 8.7) element giving further details of the action.





Hunt                    Expires January 27, 2011               [Page 69]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.SysParamsCreate =
     element SysParamsCreate {
       attribute ActionId { UID },
       element.SysParam+,
       element.AuditText?
     }

6.9.19.2.  Response

   The response to a SysParamsCreate request will be either an Error
   (Section 7.8) element or a set of SysParam (Section 7.15) elements,
   one for each new system parameter.

6.9.20.  SysParamsQry

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

6.9.20.1.  Request

   The request may specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | QryId     | A query identifier. This has no meaning within the    |
   |           | SRS; if provided, it will be returned in the response |
   |           | to this request.                                      |
   +-----------+-------------------------------------------------------+

   Syntax:

   element.SysParamsQry =
     element SysParamsQry {
       attribute QryId { UID }?,
       empty
     }

6.9.20.2.  Response

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





Hunt                    Expires January 27, 2011               [Page 70]

Internet-Draft                     SRS                         July 2010


6.9.21.  SysParamsUpdate

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

6.9.21.1.  Request

   The request must specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | ActionId  | An action identifier. This is a unique identifier for |
   |           | the request to the SRS server.                        |
   +-----------+-------------------------------------------------------+

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

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

   Syntax:

   element.SysParamsUpdate =
     element SysParamsUpdate {
       attribute ActionId { UID },
       element.SysParam+,
       element.AuditText?
     }

6.9.21.2.  Response

   The response to a SysParamsUpdate request will be either an Error
   (Section 7.8) element or a set of SysParam (Section 7.15) 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:




Hunt                    Expires January 27, 2011               [Page 71]

Internet-Draft                     SRS                         July 2010


   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | Resource  | A text string. The system that the access control     |
   |           | list is intended to be applied to.                    |
   | List      | A text string. A descriptive name for the access      |
   |           | control list; for example, "whitelist".               |
   | Type      | A text string. The type of access control list that   |
   |           | is being returned. Registries may maintain different  |
   |           | lists for different purposes, for example, blacklists |
   |           | and whitelists for controlling access.                |
   +-----------+-------------------------------------------------------+

   Additionally, the AccessControlList element may specify:

   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | Size or    | An integer. For a list query, the Size attribute     |
   | SizeChange | should be included, providing the number of entries  |
   |            | in the list. For a list change, the SizeChange       |
   |            | element should be included, providing the number of  |
   |            | list entries changed (positive for additions,        |
   |            | negative for deletions).                             |
   +------------+------------------------------------------------------+

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

   Syntax:

   element.AccessControlList =
     element AccessControlList {
       attribute Resource { text },
       attribute List { text },
       ( attribute Size { Number }
         | attribute SizeChange { Number } )?,
       attribute Type { text }?,
       element.AccessControlListEntry*
     }











Hunt                    Expires January 27, 2011               [Page 72]

Internet-Draft                     SRS                         July 2010


   Example:

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

7.2.  AckResponse

   The AckResponse element is used by the SRS to return the result of an
   AckMessage request.

   The AckResponse element must specify:

   +------------------------+------------------------------------------+
   | Attribute              | Description                              |
   +------------------------+------------------------------------------+
   | OriginatingRegistrarId | The unique identifier for the user that  |
   |                        | submitted the AckMessage request to the  |
   |                        | SRS server.                              |
   | TransId                | The identifier for the transaction       |
   |                        | submitted by the user that originated    |
   |                        | the request.                             |
   | Remaining              | An integer. The number of messages for   |
   |                        | the originating user that have not yet   |
   |                        | been acknowledged.                       |
   +------------------------+------------------------------------------+

   Definition:

   element.AckResponse =
     element AckResponse {
       attribute OriginatingRegistrarId { RegistrarId },
       attribute TransId { UID },
       attribute Remaining { Number }
   }

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




Hunt                    Expires January 27, 2011               [Page 73]

Internet-Draft                     SRS                         July 2010


   The element content consists of an Amount attribute containing the
   charge in the registry's chosen currency, and may also include an
   EffectiveDate (Section 8.38) 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:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | Amount    | A numeric currency value. The amount charged per-term |
   |           | for domain registration and renewal.                  |
   +-----------+-------------------------------------------------------+

   The BillingAmount element may also include an EffectiveDate
   (Section 8.38) element.

   Syntax:

   element.BillingAmount =
     element BillingAmount {
       attribute Amount { Dollars },
       element.EffectiveDate?
     }

   Example:

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

7.4.  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:










Hunt                    Expires January 27, 2011               [Page 74]

Internet-Draft                     SRS                         July 2010


   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | RegistrarId | A user identifier. The identifier of the registrar  |
   |             | that manages the domain that the billing amount     |
   |             | relates to.                                         |
   | Type        | A text string. The type of transaction that the     |
   |             | billing amount relates to, for instance, "Create"   |
   |             | or "Renew" a domain.                                |
   | TransStatus | A text string. The status of the billing            |
   |             | transaction; valid values are defined by the        |
   |             | BillStatus (Section 9.2.2) entity.                  |
   | DomainName  | A text string. The domain name that the billing     |
   |             | transaction relates to.                             |
   | BillingTerm | An integer. The number of months of payment for     |
   |             | which the billing transaction was issued.           |
   | Amount      | A numeric currency value. The amount of money       |
   |             | attached to the billing transaction.                |
   +-------------+-----------------------------------------------------+

   The BillingTrans element may also specify:

   +---------------+---------------------------------------------------+
   | Attribute     | Description                                       |
   +---------------+---------------------------------------------------+
   | RegistrantRef | A customer identifier. A reference assigned to    |
   |               | the registrant by the registrar.                  |
   | InvoiceId     | An invoice identifier. The identifier from the    |
   |               | registry's accounting system that relates to the  |
   |               | billing transaction.                              |
   +---------------+---------------------------------------------------+

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











Hunt                    Expires January 27, 2011               [Page 75]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.BillingTrans =
     element BillingTrans {
       attribute RegistrarId { RegistrarId },
       attribute Type { text },
       attribute TransStatus { BillStatus },
       attribute DomainName { DomainName },
       attribute RegistrantRef { UID }?,
       attribute BillingTerm { Term },
       attribute InvoiceId { UID }?,
       attribute Amount { Dollars },
       element.InvoiceDate?,
       element.TransDate,
       element.BillPeriodStart,
       element.BillPeriodEnd
     }

   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.5.  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:












Hunt                    Expires January 27, 2011               [Page 76]

Internet-Draft                     SRS                         July 2010


   +--------------+----------------------------------------------------+
   | Attribute    | Description                                        |
   +--------------+----------------------------------------------------+
   | RegistrarId  | A user identifier. The identifier of the registrar |
   |              | that the deferred income amount relates to.        |
   | BilledAmount | A numeric currency value. The amount of a billed   |
   |              | amount that can be realised in the income month,   |
   |              | considering all billing transactions up to and     |
   |              | including the base month.                          |
   | BilledCount  | An integer.                                        |
   | BaseMonth    | An integer. The latest month (January = 1,         |
   |              | December = 12) of the base year to consider        |
   |              | billing transactions for.                          |
   | BaseYear     | An integer. The latest year to consider billing    |
   |              | transactions for.                                  |
   | IncomeMonth  | An integer. The month (January = 1, December = 12) |
   |              | of the income year.                                |
   | IncomeYear   | An integer. The year to calculate deferred income  |
   |              | for.                                               |
   +--------------+----------------------------------------------------+

   Syntax:

   element.DeferredRegistrarIncome =
     element DeferredRegistrarIncome {
       attribute BaseMonth { text },
       attribute BaseYear { text },
       attribute IncomeMonth { text },
       attribute IncomeYear { text },
       attribute RegistrarId { RegistrarId },
       attribute BilledAmount { Dollars },
       attribute BilledCount { Number },
       empty
     }

7.6.  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:









Hunt                    Expires January 27, 2011               [Page 77]

Internet-Draft                     SRS                         July 2010


   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | DomainName | A text string. The domain name. Must conform to the  |
   |            | format and syntax in RFC 1035 [RFC1035], RFC 1123    |
   |            | [RFC1123], and RFC 2181 [RFC2181].                   |
   +------------+------------------------------------------------------+

   The Domain element may also specify:

   +----------------------+--------------------------------------------+
   | Attribute            | Description                                |
   +----------------------+--------------------------------------------+
   | Delegate             | A boolean value. Indicates whether the     |
   |                      | domain should be delegated to appear in    |
   |                      | the DNS.                                   |
   | DomainNameUnicode    | A UTF-8 text string. The domain name in    |
   |                      | the script intended by the registrant.     |
   |                      | Used for internationalized domain names    |
   |                      | (IDNs).                                    |
   | DomainNameUnicode    | A text string. For domain names using      |
   |                      | non-ASCII characters, this is the domain   |
   |                      | name in the script intended by the         |
   |                      | registrant. Used for internationalized     |
   |                      | domain names (IDNs).                       |
   | DomainNameUnicodeHex | A text string. For domain names using      |
   |                      | non-ASCII characters, this is the domain   |
   |                      | name encoded in a unicode hex format (for  |
   |                      | example, m<U+0101>ori.example.org). Used   |
   |                      | for internationalized domain names (IDNs). |
   | DomainNameLanguage   | A text string. For domain names using      |
   |                      | non-ASCII characters, this contains the    |
   |                      | language and script for the unicode domain |
   |                      | name. For example, ".NZ LATIN"             |
   | RegistrantRef        | A customer identifier. Assigned to the     |
   |                      | registrant by the registrar.               |
   | RegistrarId          | A user identifier. The unique identifier   |
   |                      | for the registrar that manages the domain. |
   | RegistrarName        | A text string. The name of the registrar   |
   |                      | that manages the domain.                   |
   | Status               | A text string. The registration status of  |
   |                      | the domain. Valid values are defined by    |
   |                      | the RegDomainStatus (Section 9.9.1)        |
   |                      | entity.                                    |
   | Term                 | A numeric value. The number of months to   |
   |                      | bill when the domain is renewed.           |
   | UDAI                 | A text string. The UDAI to be checked.     |
   +----------------------+--------------------------------------------+



Hunt                    Expires January 27, 2011               [Page 78]

Internet-Draft                     SRS                         July 2010


   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:

   o  NameServers (Section 8.23)

   o  RegistrantContact (Section 8.11)

   o  RegistrarPublicContact (Section 8.11)

   o  AdminContact (Section 8.11)

   o  TechnicalContact (Section 8.11)

   o  BilledUntil (Section 8.38)

   o  RegisteredDate (Section 8.38)

   o  CancelledDate (Section 8.38)

   o  LockedDate (Section 8.38)

   o  AuditDetails (Section 8.6)




























Hunt                    Expires January 27, 2011               [Page 79]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.Domain =
     element Domain {
       attribute DomainName { DomainName },
       attribute DomainNameUnicode { DomainNameUnicode }?,
       attribute DomainNameUnicodeHex { DomainNameUnicodeHex }?,
       attribute DomainNameLanguage { DomainNameLanguage }?,
       attribute RegistrantRef { UID }?,
       attribute RegistrarName { text }?,
       attribute Status { DomainStatus }?,
       attribute Delegate { Boolean }?,
       attribute Term { Term }?,
       attribute RegistrarId { RegistrarId }?,
       attribute UDAI { UID }?,
       element.NameServers?,
       element.RegistrantContact?,
       element.RegistrarPublicContact?,
       element.AdminContact?,
       element.TechnicalContact?,
       element.BilledUntil?,
       element.RegisteredDate?,
       element.CancelledDate?,
       element.LockedDate?,
       element.AuditDetails?
     }

























Hunt                    Expires January 27, 2011               [Page 80]

Internet-Draft                     SRS                         July 2010


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



Hunt                    Expires January 27, 2011               [Page 81]

Internet-Draft                     SRS                         July 2010


   registrar for.  This element will be returned in response to a
   GetMessages (Section 6.5.1) request.

   The DomainTransfer element must specify:

   +---------------+---------------------------------------------------+
   | Attribute     | Description                                       |
   +---------------+---------------------------------------------------+
   | RegistrarName | A text string. The name of the registrar that the |
   |               | domain has been transferred to.                   |
   | Minute        | An integer value. The minute in which the domain  |
   |               | transfer occurred.                                |
   | Hour          | An integer value. The hour in which the domain    |
   |               | transfer occurred.                                |
   | Day           | An integer value. The day in which the domain     |
   |               | transfer occurred.                                |
   | Month         | An integer value. The month in which the domain   |
   |               | transfer occurred.                                |
   | Year          | An integer value. The year in which the domain    |
   |               | transfer occurred.                                |
   +---------------+---------------------------------------------------+

   The DomainTransfer element may also specify:

   +----------------+--------------------------------------------------+
   | Attribute      | Description                                      |
   +----------------+--------------------------------------------------+
   | Second         | An integer value. The second in which the domain |
   |                | transfer occurred.                               |
   | TimeZoneOffset | An integer value. The TimeZoneOffset from UTC of |
   |                | the SRS server that processed the domain         |
   |                | transfer.                                        |
   +----------------+--------------------------------------------------+

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

   Syntax:

   element.DomainTransfer =
     element DomainTransfer {
       attribute RegistrarName { text },
       TimeStamp,
       element.TransferredDomain+
     }





Hunt                    Expires January 27, 2011               [Page 82]

Internet-Draft                     SRS                         July 2010


   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.8.  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:

    +-----------+----------------------------------------------------+
    | Attribute | Description                                        |
    +-----------+----------------------------------------------------+
    | ErrorId   | SRS system identifier for the error that occurred. |
    | Severity  | Indicative severity level for the error.           |
    | Hint      | SRS server hint for addressing the error.          |
    +-----------+----------------------------------------------------+

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

   Syntax:

   element.Error =
     element Error {
       attribute ErrorId { UID },
       attribute Severity { Number },
       attribute Hint { UID },
       element.Description,
       element.ErrorDetails*
     }

   Example:

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







Hunt                    Expires January 27, 2011               [Page 83]

Internet-Draft                     SRS                         July 2010


7.9.  Handle

   The Handle element allows the SRS server to return details associated
   with a contact handle.  It must include a RegistrarID attribute
   referencing the registrar that created the handle.  It may also
   include the ContactAttr (Section 9.4.2) attribute definitions,
   Contact (Section 9.4.1) element content, the AuditDetails
   (Section 8.6) element referencing the most recent update to the
   handle, and the ChangedDomains (Section 8.10) element.

   Syntax:

   element.Handle =
     element Handle {
       attribute RegistrarId { RegistrarId }
       ContactAttr,
       Contact,
       element.AuditDetails?,
       element.ChangedDomains?
     }

   Example:

   <Handle
       RegistrarID="100"
       HandleId="EXAMPLE-1"
       Name="Example Registration Services, Inc."
       ActionId="1021021">
       <PostalAddress
           Address1="14 Example Road"
           Address2="Example Plaza"
           City="Example"
           CountryCode="US" />
       <AuditDetails RegistrarId="100" ActionId="1021021">
           <AuditText>Add handle for ERS Inc.</AuditText>
       </AuditDetails>
   </Handle>

7.10.  Message

   The Message element allows the SRS server to return message details
   to the user along with an indication of the number of messages
   outstanding.  The Message response element is used when the
   GetMessages (Section 6.5.1) request is used with QueueMode enabled.

   It contains a Response (Section 5.2.1) element and has an optional
   attribute, Remaining, indicating the number of messages for the
   effective registrar of the request that have not yet been



Hunt                    Expires January 27, 2011               [Page 84]

Internet-Draft                     SRS                         July 2010


   acknowledged, and which are not included in the current action
   response.

   Syntax:

   element.Message =
     element Message {
          element.Response,
          attribute Remaining { Number }?
     }

7.11.  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 (Section 8.40) and Signature (Section 8.37)
   elements with content encoded as parsed character data.

   Syntax:

   element.RawRequest =
     element RawRequest {
       element.XML,
       element.Signature
     }

   element.RawResponse =
     element RawResponse {
       element.XML,
       element.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>






Hunt                    Expires January 27, 2011               [Page 85]

Internet-Draft                     SRS                         July 2010


7.12.  Registrar

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

   The Registrar element must specify:

   +-------------+-----------------------------------------------------+
   | Attribute   | Description                                         |
   +-------------+-----------------------------------------------------+
   | RegistrarId | A user identifier. The unique number to be assigned |
   |             | to the new registrar.                               |
   | Name        | A text string. The name of the registrar.           |
   | AccRef      | A text string. The registrar's identifier in the    |
   |             | registry's accounting system.                       |
   +-------------+-----------------------------------------------------+

   The Registrar element may also specify:

   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | URL       | A text string. The public web site address for the    |
   |           | registrar.                                            |
   +-----------+-------------------------------------------------------+

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

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











Hunt                    Expires January 27, 2011               [Page 86]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.Registrar =
     element Registrar {
       attribute RegistrarId { RegistrarId },
       attribute Name { text },
       attribute AccRef { text },
       attribute URL { text }?,
       element.RegistrarPublicContact,
       element.RegistrarSRSContact,
       element.DefaultTechnicalContact,
       element.EncryptKeys,
       element.EPPAuth?,
       element.Allowed2LDs?,
       element.Roles?,
       element.AuditDetails?
     }

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



Hunt                    Expires January 27, 2011               [Page 87]

Internet-Draft                     SRS                         July 2010


   =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.13.  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:

   +--------------+----------------------------------------------------+
   | Attribute    | Description                                        |
   +--------------+----------------------------------------------------+
   | ActionStatus | A text string. The status of the process that      |
   |              | created the log.                                   |
   | ProcessName  | A text string. The name of the process that        |
   |              | created the run log entry.                         |
   +--------------+----------------------------------------------------+




Hunt                    Expires January 27, 2011               [Page 88]

Internet-Draft                     SRS                         July 2010


   The RunLog element may also specify:

   +------------+------------------------------------------------------+
   | Attribute  | Description                                          |
   +------------+------------------------------------------------------+
   | Parameters | A text string. The parameters with which the process |
   |            | was called.                                          |
   | Control    | A text string. A free-text field for storing extra   |
   |            | information about the process run. For example, SRS  |
   |            | server implementations may store the name of the     |
   |            | server that executed the process and the completion  |
   |            | time of the process here.                            |
   +------------+------------------------------------------------------+

   Syntax:

   element.RunLog =
     element RunLog {
       attribute ProcessName { text },
       attribute Parameters { text }?,
       attribute ActionStatus { text },
       attribute Control { text }?,
       element.RunLogTimeStamp,
       element.RunLogDetails?
     }

7.14.  Schedule

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

   The Schedule element must specify:

   +---------------------+---------------------------------------------+
   | Attribute           | Description                                 |
   +---------------------+---------------------------------------------+
   | ProcessName         | A text string. The name of the scheduled    |
   |                     | job process.                                |
   | Frequency           | An text string. The delay between repeat    |
   |                     | executions of the process, after the        |
   |                     | initial run date.                           |
   | CreateByRegistrarId | A user identifier. The registry's registrar |
   |                     | identifier that was used to create the      |
   |                     | scheduled job.                              |
   | CreateActionId      | An action identifier. This is the unique    |
   |                     | identifier for the request to the SRS       |
   |                     | server that created the scheduled job.      |
   +---------------------+---------------------------------------------+



Hunt                    Expires January 27, 2011               [Page 89]

Internet-Draft                     SRS                         July 2010


   The Schedule element may also specify:

   +---------------------+---------------------------------------------+
   | Attribute           | Description                                 |
   +---------------------+---------------------------------------------+
   | Parameters          | A text string. The parameters to be passed  |
   |                     | to the process when it is executed.         |
   | CancelByRegistrarId | A user identifier. The registry's registrar |
   |                     | identifier that was used to cancel the      |
   |                     | scheduled job.                              |
   | CancelActionId      | An action identifier. This is the unique    |
   |                     | identifier for the request to the SRS       |
   |                     | server that cancelled the scheduled job.    |
   +---------------------+---------------------------------------------+

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

   Syntax:

   element.Schedule =
     element Schedule {
       attribute ProcessName { ScheduledJob },
       attribute Frequency { text },
       attribute Parameters { text }?,
       attribute CreateByRegistrarId { UID },
       attribute CreateActionId { UID },
       attribute CancelByRegistrarId { UID }?,
       attribute CancelActionId { UID }?,
       element.FirstRunDate,
       element.FinalRunDate?,
       element.CreateAuditText?,
       element.CancelAuditText?
     }











Hunt                    Expires January 27, 2011               [Page 90]

Internet-Draft                     SRS                         July 2010


   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.15.  SysParam

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

   The SysParam element must specify:

     +-----------+---------------------------------------------------+
     | Attribute | Description                                       |
     +-----------+---------------------------------------------------+
     | Name      | A text string. The name of the system parameter.  |
     +-----------+---------------------------------------------------+

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

   Syntax:

   element.SysParam =
     element SysParam {
       attribute Name { text },
       element.ParamValue,
       element.AuditDetails?
     }

7.16.  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:






Hunt                    Expires January 27, 2011               [Page 91]

Internet-Draft                     SRS                         July 2010


   +-----------+-------------------------------------------------------+
   | Attribute | Description                                           |
   +-----------+-------------------------------------------------------+
   | Valid     | A boolean value. The validity status of the tested    |
   |           | UDAI value.                                           |
   +-----------+-------------------------------------------------------+

   Syntax:

   element.UDAIValid =
     element UDAIValid {
       attribute Valid { Boolean },
       empty
     }

   Example:

   <UDAIValid Valid="1" />


8.  Information Elements

   This section documents elements from the schema 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.  AccessControlListContentFilter

   The AccessControlListContentFilter is a simple container for elements
   that provide search patterns for access control list data.

   Zero or more such filters may be supplied; filters of the same type
   logically OR and groups of the distinct types of filters are
   logically AND.

   Currently supported are AddressFilter (Section 8.4),
   RegistrarIdFilter (Section 8.30) and DomainNameFilter (Section 8.16),
   which correspond to the three possible data attributes of an
   AccessControlListEntry (Section 8.2)

   An AccessControlListContentFilter element is used by the
   AccessControlList (Section 7.1) element to return details of access
   control lists, and by the AccessControlListAdd (Section 6.9.1) and
   AccessControlListRemove (Section 6.9.3) queries to specify entries to
   add to and remove from access control lists.




Hunt                    Expires January 27, 2011               [Page 92]

Internet-Draft                     SRS                         July 2010


   Syntax:

   AccessControlListContentFilter =
     element.DomainNameFilter
     | element.RegistrarIdFilter
     | element.AddressFilter

8.2.  AccessControlListEntry

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

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

   DomainName:  A domain name.

   RegistrarId:  A RegistrarId.

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

   Currently allowed is DomainName, Address, RegistrarId, and
   RegistrarId with either DomainName and Address.  One of these
   combinations must be satisfied.

   The Address may include a network mask length, for example:
   192.0.2.32/28 may match addresses on that network, for for example
   192.0.2.41, if the list is queried in a properly semantic way, for
   example with a AddressFilter (Section 8.4) field in an
   AccessControlListQry (Section 6.9.2).

   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
   (Section 7.1) element to return details of access control lists, and
   by the AccessControlListAdd (Section 6.9.1) and
   AccessControlListRemove (Section 6.9.3) queries to specify entries to
   add to and remove from access control lists.






Hunt                    Expires January 27, 2011               [Page 93]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.AccessControlListEntry =
     element AccessControlListEntry {
       attribute Address { text }?,
       attribute DomainName { text }?,
       attribute RegistrarId { RegistrarId }?,
       attribute Comment { text }?,
       element.EffectiveDate?
     }

8.3.  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 (Section 10).

   Syntax:

   element.ActionIdFilter =
     element ActionIdFilter {
       text
     }

8.4.  AddressFilter

   The AddressFilter element is a simple element that contains parsed
   character data.  The content of this element is used as a PostgreSQL
   inet address, in a contains-or-equals operation, so for example
   192.0.2.41 would match a 192.0.2.32/28 datum.

   Syntax:

   element.AddressFilter =
     element AddressFilter {
       text
     }

8.5.  Allowed2LDs

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








Hunt                    Expires January 27, 2011               [Page 94]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.Allowed2LDs =
     element Allowed2LDs {
       element.SecondLD*
     }

8.6.  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
   (Section 8.38) element and a text description in an AuditText
   (Section 8.7) element.

   Syntax:

   element.AuditDetails =
     element AuditDetails {
       attribute RegistrarId { text }?,
       attribute ActionId { UID }?,
       element.AuditTime?,
       element.AuditText?
     }

8.7.  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 =
     element AuditText {
       text
     }

8.8.  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
   (Section 10).






Hunt                    Expires January 27, 2011               [Page 95]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.AuditTextFilter =
     element AuditTextFilter {
       text
     }

8.9.  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 (Section 7.14)
   response element.

   Syntax:

   element.CancelAuditText =
     element CancelAuditText {
       text
     }

8.10.  ChangedDomains

   The ChangedDomains element is a container for Domain (Section 7.6)
   elements.  It is returned in a Handle (Section 7.9) element when
   multiple domains are updated by a HandleUpdate (Section 6.4.2)
   request.

   Syntax:

   element.CancelAuditText =
     element CancelAuditText {
       text
     }

8.11.  Contact Details Elements

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

   o  AdminContact

   o  DefaultTechnicalContact

   o  RegistrantContact





Hunt                    Expires January 27, 2011               [Page 96]

Internet-Draft                     SRS                         July 2010


   o  RegistrarPublicContact

   o  RegistrarSRSContact

   o  TechnicalContact

   The contact details elements are defined using the Contact
   (Section 9.4.1) entity definition for the element content, and the
   ContactAttr (Section 9.4.2) 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 (Section 8.26), Phone (Section 8.29), and
   Fax (Section 8.29) details.



































Hunt                    Expires January 27, 2011               [Page 97]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.AdminContact =
     element AdminContact {
       ContactAttr,
       Contact
     }

   element.DefaultTechnicalContact =
     element DefaultTechnicalContact {
       ContactAttr,
       Contact
     }

   element.RegistrantContact =
     element RegistrantContact {
       ContactAttr,
       Contact
     }

   element.RegistrarPublicContact =
     element RegistrarPublicContact {
       ContactAttr,
       Contact
     }

   element.RegistrarSRSContact =
     element RegistrarSRSContact {
       ContactAttr,
       Contact
     }

   element.TechnicalContact =
     element TechnicalContact {
       ContactAttr,
       Contact
     }

   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>




Hunt                    Expires January 27, 2011               [Page 98]

Internet-Draft                     SRS                         July 2010


8.12.  Contact Details Search Filters

   The contact details search filter elements all share a common
   definition referenced from the ContactFilter (Section 9.5.1) entity
   definition for the element content, and the ContactFilterAttr
   (Section 9.5.2) 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
   (Section 6.1.2) 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
   (Section 8.27), Phone (Section 8.29), and Fax (Section 8.29) details.

   Syntax:

   element.AdminContactFilter =
     element AdminContactFilter {
       ContactAttrFilter,
       ContactFilter
     }

   element.RegistrantContactFilter =
     element RegistrantContactFilter {
       ContactAttrFilter,
       ContactFilter
     }

   element.TechnicalContactFilter =
     element TechnicalContactFilter {
       ContactAttrFilter,
       ContactFilter
     }

8.13.  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 (Section 7.14) response
   element.




Hunt                    Expires January 27, 2011               [Page 99]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.CreateAuditText =
     element CreateAuditText {
       text
     }

8.14.  Date Range Elements

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

   o  AuditTime

   o  BilledUntilDateRange

   o  CancelledDateRange

   o  ChangedInDateRange

   o  InvoiceDateRange

   o  LockedDateRange

   o  LogDateRange

   o  RegisteredDateRange

   o  ResultDateRange

   o  SearchDateRange

   o  TransDateRange

   The content of the date range elements is defined using the DateRange
   (Section 9.7.4) entity.  The date range elements can contain two
   optional elements, a From (Section 8.38) date and a To (Section 8.38)
   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 =
     element AuditTime {



Hunt                    Expires January 27, 2011              [Page 100]

Internet-Draft                     SRS                         July 2010


       DateRange
     }

   element.BilledUntilDateRange =
     element BilledUntilDateRange {
       DateRange
     }

   element.CancelledDateRange =
     element CancelledDateRange {
       DateRange
     }

   element.ChangedInDateRange =
     element ChangedInDateRange {
       DateRange
     }

   element.InvoiceDateRange =
     element InvoiceDateRange {
       DateRange
     }

   element.LockedDateRange =
     element LockedDateRange {
       DateRange
     }

   element.LogDateRange =
     element LogDateRange {
       DateRange,
       empty
     }

   element.RegisteredDateRange =
     element RegisteredDateRange {
       DateRange
     }

   element.ResultDateRange =
     element ResultDateRange {
       DateRange
     }

   element.SearchDateRange =
     element SearchDateRange {
       DateRange
     }



Hunt                    Expires January 27, 2011              [Page 101]

Internet-Draft                     SRS                         July 2010


   element.TransDateRange =
     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.15.  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 (Section 7.8) element.

   Syntax:

   element.Description =
     element Description {
       text
     }

8.16.  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 (Section 10) for
   matching against domain names.

   Syntax:

   element.DomainNameFilter =
     element DomainNameFilter {
       text
     }

8.17.  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 (Section 8.18) element.



Hunt                    Expires January 27, 2011              [Page 102]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.EncryptKey =
     element EncryptKey {
       text
     }

8.18.  EncryptKeys

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

   Syntax:

   element.EncryptKeys =
     element EncryptKeys {
       element.EncryptKey*
     }

8.19.  EPPAuth

   The EPPAuth element is an empty element with a single attribute:
   Password.  It is used to view and update the password a registrar
   uses to connect via the EPP protocol.

   The Password can be supplied as a Unix-style hashed password of the
   form "$5$saltstring$hash", if so SHA-256 [FIPS.180-2.2002] and a salt
   must be used.  Plain text may be provided instead (defined as not
   looking like a Unix-style hashed password at the start), which will
   be hashed.

   Once set, the hash will be returned in the Password attribute.

   Syntax:

   element.EPPAuth =
     element EPPAuth {
       attribute Password { text }
     }

8.20.  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 (Section 7.8) element.




Hunt                    Expires January 27, 2011              [Page 103]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.ErrorDetails =
     element ErrorDetails {
       text
     }

8.21.  FieldList

   The FieldList element is an empty element with a set of Boolean
   (Section 9.3.3) attributes.  It is used in the DomainDetailsQry
   (Section 6.1.2) 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.







Hunt                    Expires January 27, 2011              [Page 104]

Internet-Draft                     SRS                         July 2010


   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 =
     element FieldList {
       attribute Status { Boolean }?,
       attribute NameServers { Boolean }?,
       attribute RegistrantContact { Boolean }?,
       attribute RegisteredDate { Boolean }?,
       attribute AdminContact { Boolean }?,
       attribute TechnicalContact { Boolean }?,
       attribute LockedDate { Boolean }?,
       attribute Delegate { Boolean }?,
       attribute RegistrarId { Boolean }?,
       attribute RegistrarName { Boolean }?,
       attribute RegistrantRef { Boolean }?,
       attribute LastActionId { Boolean }?,
       attribute ChangedByRegistrarId { Boolean }?,
       attribute Term { Boolean }?,
       attribute BilledUntil { Boolean }?,
       attribute CancelledDate { Boolean }?,
       attribute AuditText { Boolean }?,
       attribute EffectiveFrom { Boolean }?,
       empty
     }

8.22.  HandleIdFilter

   The HandleIdFilter element contains a pattern match string to match
   against the stored handles.  The content should be a valid text
   filter (Section 10).





Hunt                    Expires January 27, 2011              [Page 105]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.HandleIdFilter =
     element HandleIdFilter {
       text
     }

8.23.  NameServers

   The NameServers element is a simple container for Server
   (Section 8.35) 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 =
     element NameServers {
       element.Server*
     }

8.24.  NameServerFilter

   The NameServerFilter element is a simple container for ServerFilter
   (Section 8.36) elements.  It is used in the DomainDetailsQry
   (Section 6.1.2) 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 =
     element NameServerFilter {
       element.ServerFilter+
     }

8.25.  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 (Section 7.15) element.






Hunt                    Expires January 27, 2011              [Page 106]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.ParamValue =
     element ParamValue {
       text
     }

8.26.  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 [ISO.3166.1988] two-
   letter country code.

   Syntax:

   element.PostalAddress =
     element PostalAddress {
       attribute Address1 { text }?,
       attribute Address2 { text }?,
       attribute City { text }?,
       attribute Province { text }?,
       attribute CountryCode { text }?,
       attribute PostalCode { text }?,
       empty
     }

8.27.  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 =
     element PostalAddressFilter {
       attribute Address1 { text }?,
       attribute Address2 { text }?,
       attribute City { text }?,
       attribute Province { text }?,
       attribute CountryCode { text }?,
       attribute PostalCode { text }?,
       empty
     }






Hunt                    Expires January 27, 2011              [Page 107]

Internet-Draft                     SRS                         July 2010


8.28.  TypeFilter

   The TypeFilter element is an empty element with a single attribute,
   Type.  It is used to specify message types when retrieving messages
   from the SRS.

   The Type attribute must be a valid GetMessagesTypes (Section 9.11.1)
   value.

   Syntax:

   element.TypeFilter =
     element TypeFilter {
       attribute Type { GetMessagesTypes }
     }

8.29.  Telephone Number Details

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

   o  Fax

   o  Phone

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

   Syntax:

   element.Fax =
     element Fax {
       PhoneAttr,
       empty
     }

   element.Phone =
     element Phone {
       PhoneAttr,
       empty
     }

8.30.  RegistrarIdFilter

   The RegistrarIdFilter element is a simple element that contains
   parsed character data.  The content of this element is used as a
   RegistrarId.  The purpose in making this an element is so that
   multiple values can be provided.



Hunt                    Expires January 27, 2011              [Page 108]

Internet-Draft                     SRS                         July 2010


   Syntax:

   element.RegistrarIdFilter =
     element RegistrarIdFilter {
       text
     }

8.31.  Role

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

   Syntax:

   Role =
     "Registrar"
     | "Registry"
     | "Whois"
     | "Query"
     | "CreateDomain"
     | "UpdateDomain"
     | "TransferDomain"
     | "CancelDomain"
     | "UncancelDomain"
     | "UpdateRegistrar"
     | "Administer"
     | "Supervisor"
     | "Connect"
     | "ReleaseDomain"
     | "QueryACL"
     | "UpdateACL"
     | "QueryRegACL"

8.32.  Roles

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

   Syntax:

   element.Roles =
     element Roles {
       element.Role*
     }





Hunt                    Expires January 27, 2011              [Page 109]

Internet-Draft                     SRS                         July 2010


8.33.  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 (Section 7.15) element
   and contains process data to be stored in the SRS log.

   Syntax:

   element.RunLogDetails =
     element RunLogDetails {
       text
     }

8.34.  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
   (Section 8.5) 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 =
     element SecondLD {
       attribute DomainName { DomainName },
       empty
     }

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



Hunt                    Expires January 27, 2011              [Page 110]

Internet-Draft                     SRS                         July 2010


   notation, for example, 192.0.2.14

   The IP6Addr value should be given in any of the formats described in
   RFC 4291 [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 (Section 8.23) element
   to specify name server details.

   Syntax:

   element.Server =
     element Server {
       attribute FQDN { text },
       attribute IP4Addr { text }?,
       attribute IP6Addr { text }?,
       empty
     }

8.36.  ServerFilter

   The ServerFilter element is an empty element.  It has the same
   attributes as the Server (Section 8.35) 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
   (Section 8.24) element to specify the server details to match.

   Syntax:

   element.ServerFilter =
     element ServerFilter {
       attribute FQDN { text }?,
       attribute IP4Addr { text }?,
       attribute IP6Addr { text }?,
       empty
     }






Hunt                    Expires January 27, 2011              [Page 111]

Internet-Draft                     SRS                         July 2010


8.37.  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
   (Section 7.11) elements when returning details of previous SRS
   transactions.

   Syntax:

   element.Signature =
     element Signature {
       text
     }

8.38.  Timestamp Elements

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

   o  ActiveOn

   o  BilledUntil

   o  BillPeriodEnd

   o  BillPeriodStart

   o  CancelledDate

   o  EffectiveDate

   o  FeTimeStamp

   o  FinalRunDate

   o  FirstRunDate

   o  From

   o  InvoiceDate

   o  LastRunDate

   o  LockedDate





Hunt                    Expires January 27, 2011              [Page 112]

Internet-Draft                     SRS                         July 2010


   o  NewBilledUntilDate

   o  RegisteredDate

   o  RunDate

   o  RunLogTimeStamp

   o  To

   o  TransactionDate

   o  TransDate

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

   Syntax:

   element.ActiveOn =
     element ActiveOn {
       TimeStamp
     }

   element.BilledUntil =
     element BilledUntil {
       TimeStamp,
       empty
     }

   element.BillPeriodEnd =
     element BillPeriodEnd {
       TimeStamp,
       empty
     }

   element.BillPeriodStart =
     element BillPeriodStart {
       TimeStamp,
       empty
     }

   element.CancelledDate =
     element CancelledDate {
       TimeStamp,
       empty
     }




Hunt                    Expires January 27, 2011              [Page 113]

Internet-Draft                     SRS                         July 2010


   element.EffectiveDate =
     element EffectiveDate {
       TimeStamp,
       empty
     }

   element.FeTimeStamp =
     element FeTimeStamp {
       TimeStamp,
       empty
     }

   element.FinalRunDate =
     element FinalRunDate {
       TimeStamp,
       empty
     }

   element.FirstRunDate =
     element FirstRunDate {
       TimeStamp,
       empty
     }

   element.From =
     element From {
       TimeStamp,
       empty
     }

   element.InvoiceDate =
     element InvoiceDate {
       TimeStamp,
       empty
     }

   element.LastRunDate =
     element LastRunDate {
       TimeStamp,
       empty
     }

   element.LockedDate =
     element LockedDate {
       TimeStamp,
       empty
     }




Hunt                    Expires January 27, 2011              [Page 114]

Internet-Draft                     SRS                         July 2010


   element.NewBilledUntilDate =
     element NewBilledUntilDate {
       TimeStamp,
       empty
     }

   element.RegisteredDate =
     element RegisteredDate {
       TimeStamp,
       empty
     }

   element.RunDate =
     element RunDate {
       TimeStamp,
       empty
     }

   element.RunLogTimeStamp =
     element RunLogTimeStamp {
       TimeStamp,
       empty
     }

   element.To =
     element To {
       TimeStamp,
       empty
     }

   element.TransactionDate =
     element TransactionDate {
       TimeStamp,
       empty
     }

   element.TransDate =
     element TransDate {
       TimeStamp,
       empty
     }

   Example of an EffectiveDate element:

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





Hunt                    Expires January 27, 2011              [Page 115]

Internet-Draft                     SRS                         July 2010


8.39.  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 (Section 7.7) element.

   Syntax:

   element.TransferredDomain =
     element TransferredDomain {
       text
     }

8.40.  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 (Section 7.11) elements when returning details of
   previous SRS transactions.

   Syntax:

   element.XML =
     element XML {
       text
     }


9.  Internal Entities

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

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:

   DomainWriteAction =
     "DomainCreate"
     | "DomainUpdate"



Hunt                    Expires January 27, 2011              [Page 116]

Internet-Draft                     SRS                         July 2010


9.1.2.  DomainQueryAction

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

   Definition:

   DomainQueryAction =
     "Whois"
     | "DomainDetailsQry"
     | "ActionDetailsQry"
     | "UDAIValidQry"

9.1.3.  HandleQueryAction

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

   Definition:

   HandleQueryAction =
     "HandleDetailsQry"

9.1.4.  HandleWriteAction

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

   Definition:

   HandleWriteAction =
     "HandleCreate"
     | "HandleUpdate"

9.1.5.  RegistrarWriteAction

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

   Definition:

   RegistrarWriteAction =
     "RegistrarCreate"
     | "RegistrarUpdate"







Hunt                    Expires January 27, 2011              [Page 117]

Internet-Draft                     SRS                         July 2010


9.1.6.  RegistrarQueryAction

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

   Definition:

   RegistrarQueryAction =
     "RegistrarDetailsQry"
     | "RegistrarAccountQry"
     | "GetMessages"

9.1.7.  RegistryAction

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

   Definition:

   RegistryAction =
     "SysParamsUpdate"
     | "SysParamsQry"
     | "SysParamsCreate"
     | "RunLogCreate"
     | "RunLogQry"
     | "ScheduleCreate"
     | "ScheduleCancel"
     | "ScheduleQry"
     | "ScheduleUpdate"
     | "BillingExtract"
     | "SetBillingAmount"
     | "BillingAmountQry"
     | "DeferredIncomeSummaryQry"
     | "DeferredIncomeDetailQry"
     | "BilledUntilAdjustment"
     | "BuildDnsZoneFiles"
     | "GenerateDomainReport"
     | "AdjustRegistrarAccount"
     | "AccessControlListQry"
     | "AccessControlListAdd"
     | "AccessControlListRemove"

9.1.8.  Action

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




Hunt                    Expires January 27, 2011              [Page 118]

Internet-Draft                     SRS                         July 2010


   Definition:

   Action =
     DomainWriteAction
     | DomainQueryAction
     | HandleWriteAction
     | HandleQueryAction
     | RegistrarWriteAction
     | RegistrarQueryAction
     | RegistryAction

9.1.9.  ActionEtc

   The ActionEtc entity defines the valid values for the response action
   string.  It includes all the valid values of the Action
   (Section 9.1.8) entity and, additionally, the strings
   "UnknownTransaction", "DomainTransfer" and "AckMessage".

   Definition:

   ActionEtc =
     Action
     | "UnknownTransaction"
     | "DomainTransfer"
     | "AckMessage"

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:

   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:

   BillStatus = "PendingConfirmation" | "Confirmed"






Hunt                    Expires January 27, 2011              [Page 119]

Internet-Draft                     SRS                         July 2010


9.3.  Booleans

9.3.1.  True

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

   Definition:

   True = "1"

9.3.2.  False

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

   Definition:

   False = "0"

9.3.3.  Boolean

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

   Definition:

   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:

   Contact =
     element.PostalAddress?,
     element.Phone?,
     element.Fax?

9.4.2.  ContactAttr

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




Hunt                    Expires January 27, 2011              [Page 120]

Internet-Draft                     SRS                         July 2010


   Definition:

   ContactAttr =
     attribute HandleId { text }?,
     attribute Name { text }?,
     attribute Email { text }?,
     attribute ActionId { text }?

9.5.  Contact Details Filters

9.5.1.  ContactFilter

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

   Definition:

   ContactFilter =
     element.PostalAddressFilter?,
     element.Phone?,
     element.Fax?

9.5.2.  ContactFilterAttr

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

   Definition:

   ContactAttrFilter =
     attribute HandleId { text }?,
     attribute Name { text }?,
     attribute Email { text }?

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:

   Dollars = xsd:decimal { fractionDigits = "2" }





Hunt                    Expires January 27, 2011              [Page 121]

Internet-Draft                     SRS                         July 2010


9.7.  Dates And Times

9.7.1.  Date

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

   Definition:

   Date =
     attribute Year { Number },
     attribute Month { Number },
     attribute Day { Number }

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:

   Time =
     attribute Hour { Number },
     attribute Minute { Number },
     attribute Second { Number }?,
     attribute TimeZoneOffset { text }?

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 (Section 9.7.1) and Time (Section 9.7.2)
   entities.

   Definition:

   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 (Section 8.38) element and an
   optional To (Section 8.38) element.  Both the From and To element are
   empty elements with attributes as defined in the TimeStamp
   (Section 9.7.3) entity.



Hunt                    Expires January 27, 2011              [Page 122]

Internet-Draft                     SRS                         July 2010


   Definition:

   DateRange =
     element.From?,
     element.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:

   DomainName = string

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:

   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:

   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.






Hunt                    Expires January 27, 2011              [Page 123]

Internet-Draft                     SRS                         July 2010


   Definition:

   Term = xsd:positiveInteger

9.11.  Message Types

9.11.1.  GetMessagesTypes

   The GetMessagesTypes entity defines the valid values for attributes
   that hold a message type name.

   Definition:

   GetMessagesTypes = "third-party" | "server-generated-data"

9.12.  Numeric

9.12.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:

   Number = xsd:nonNegativeInteger

9.13.  Registrar Identifiers

9.13.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 (Section 9.12.1) 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:

   RegistrarId = xsd:positiveInteger



Hunt                    Expires January 27, 2011              [Page 124]

Internet-Draft                     SRS                         July 2010


9.13.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
   (Section 6.5.1) request, to specify a registrar identifier other than
   the registrar making the request.

   Definition:

   RegistrarIdOrOTHERS = RegistrarId | "OTHERS"

9.14.  Responses

9.14.1.  ActionResponse

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

   Definition:

   ActionResponse =
     element.Error
     | element.Domain*
     | element.UDAIValid
     | element.DomainTransfer
     | element.BillingTrans*
     | element.DeferredRegistrarIncome*
     | element.Registrar*
     | element.SysParam*
     | element.RunLog*
     | element.Schedule*
     | element.AccessControlList*
     | (element.RawRequest, element.RawResponse)
     | element.BillingAmount*
     | element.Handle*
     | element.Message*

9.15.  System Roles

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



Hunt                    Expires January 27, 2011              [Page 125]

Internet-Draft                     SRS                         July 2010


   to.

   Definition:

   Role =
     "Registrar"
     | "Registry"
     | "Whois"
     | "Query"
     | "CreateDomain"
     | "UpdateDomain"
     | "TransferDomain"
     | "CancelDomain"
     | "UncancelDomain"
     | "UpdateRegistrar"
     | "Administer"
     | "Supervisor"
     | "Connect"
     | "ReleaseDomain"
     | "QueryACL"
     | "UpdateACL"

9.16.  Scheduled Processes

9.16.1.  ScheduledJob

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

   Definition:

   ScheduledJob =
     "BuildDnsZoneFiles"
     | "ReleaseDomains"
     | "RenewDomains"
     | "GenerateDomainReport"
     | "GenerateStatsReport"

9.17.  Telephone Numbers

9.17.1.  PhoneAttr

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







Hunt                    Expires January 27, 2011              [Page 126]

Internet-Draft                     SRS                         July 2010


   Definition:

   PhoneAttr =
     attribute CountryCode { text }?,
     attribute AreaCode { text }?,
     attribute LocalNumber { text }?

9.18.  Unique Identifiers

9.18.1.  UID

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

   Definition:

   UID = string


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:

              +----------+---------------------------------+
              | Wildcard | Description                     |
              +----------+---------------------------------+
              | ?        | matches any single character    |
              | *        | matches zero or more characters |
              +----------+---------------------------------+

   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.














Hunt                    Expires January 27, 2011              [Page 127]

Internet-Draft                     SRS                         July 2010


          Text filter pattern matching examples for domain names:

   +---------------+------------------------+--------------------------+
   | Text filter   | Domain                 | Result                   |
   | pattern       |                        |                          |
   +---------------+------------------------+--------------------------+
   | alpha.*.org   | alpha.example.org      | Match                    |
   | alpha.*.org   | alpha.beta.example.org | No match                 |
   | *.example.org | alpha.example.org      | Match                    |
   | *.example.org | alpha.beta.example.org | Match                    |
   | *.example.org | example.org            | No match                 |
   | alpha.*       | alpha.example          | Match                    |
   | alpha.*       | alpha.co.example       | No match                 |
   | *             | any.example.org        | Match (* on its own will |
   |               |                        | match all domains in the |
   |               |                        | SRS)                     |
   +---------------+------------------------+--------------------------+


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.





Hunt                    Expires January 27, 2011              [Page 128]

Internet-Draft                     SRS                         July 2010


12.  IANA Considerations

   This document has no actions for IANA.


13.  References

13.1.  Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

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

   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
              Specification", RFC 2181, July 1997.

   [RFC4880]  Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC3492]  Costello, A., "Punycode: A Bootstring encoding of Unicode
              for Internationalized Domain Names in Applications
              (IDNA)", RFC 3492, March 2003.

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

   [W3C.REC-xml]
              Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
              "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-
              xml, October 2000, <http://www.w3.org/TR/REC-xml>.

   [ISO.3166.1988]
              International Organization for Standardization, "Codes for
              the representation of names of countries, 3rd edition",
              ISO Standard 3166, August 1988.

   [FIPS.180-2.2002]



Hunt                    Expires January 27, 2011              [Page 129]

Internet-Draft                     SRS                         July 2010


              National Institute of Standards and Technology, "Secure
              Hash Standard", FIPS PUB 180-2, August 2002, <http://
              csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.

13.2.  Informative References

   [RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912,
              September 2004.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC3375]  Hollenbeck, S., "Generic Registry-Registrar Protocol
              Requirements", RFC 3375, September 2002.

   [US-ASCII]
              American National Standards Institute, "Coded Character
              Set - 7-bit American Standard Code for Information
              Interchange", ANSI X3.4, 1986, 1968.

URIs

   [1]  <http://sourceforge.net/projects/dnrs/>


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.





















Hunt                    Expires January 27, 2011              [Page 130]

Internet-Draft                     SRS                         July 2010


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.

   o  The SRS Implementation Team at Catalyst IT Limited

   o  Dave Baker of .nz Registry Services


Appendix C.  RELAX NG schema




Hunt                    Expires January 27, 2011              [Page 131]

Internet-Draft                     SRS                         July 2010


   Complete RELAX NG schema for the SRS protocol (compact syntax):
# protocol.rnc:  RELAX NG schema for NZ Shared Registry System Protocol
#
# Author:     Srdjan Jankovic
# Version:    Release version 5.1
# Revised:    SRS Development Team
#
# Based on a prototype written by Ewen McNeill, 2002/03/05

# The NZ SRS registrar/registry protocol consists of an (externally)
#  signed XML request document containing a series of actions to be
#  performed on the register (updating it, or extracting information
#  from it), which is answered by an (externally) signed XML response
#  document containing answers to each of those actions, or an overall
#  error message.
#
#  Each action has its own element to specify that action, and there
#  is also a response element which is used to enclose each response
#  to an action.
#
#  Each update-type action has an id number which is the registrar's
#  identification for the action, which must be unique in all requests
#  made to the register by that registrar.  The status of each action
#  with an id number can be queried with the "getmsg" action.
#
#  The registrar internally is the effective registrar of the
#  transaction.  This must normally match the registrar UID specified
#  externally.  However the registry may set this to a specific
#  registrar other than its own "psuedo registrar" to perform actions
#  "as if" it was that registrar, eg filter by that registrar.
#
#  It is also included to assist debugging (by allowing network streams
#  to be more directly linked to the registrar).
#
#  ====================================================================
#
# Copyright 2002-2009 NZ Registry Services
#
# This file is part of the Shared Registry System
#
# The Shared Registry System is free software; you can redistribute it
# and/or modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# The Shared Registry System is distributed in the hope that it will be
# useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU



Hunt                    Expires January 27, 2011              [Page 132]

Internet-Draft                     SRS                         July 2010


# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with the Shared Registry System; if not, write to the Free
# Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
# 02111-1307  USA
#

namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"

# == Common entities ===================================================

# Simple data types

Number = xsd:nonNegativeInteger
Dollars = xsd:decimal { fractionDigits = "2" }
True = "1"
False = "0"
Boolean = False | True

# Valid date
Date =
  attribute Year { Number },
  attribute Month { Number },
  attribute Day { Number }
# Valid time.
# If TimeZoneOffset omitted, NZ local time assumed. The mandatory format
# is (+/-)HH:MM (the sign is mandatory!), although (+/-)HHMM will be
# accepted with the ':' silently added.
# If Second is omitted, it defaults to 0
Time =
  attribute Hour { Number },
  attribute Minute { Number },
  attribute Second { Number }?,
  attribute TimeZoneOffset { text }?

TimeStamp = Date, Time

# Valid domain name
DomainName = string

# Valid DomainName details - for registering IDN
DomainNameUnicode = string
DomainNameUnicodeHex = string
DomainNameLanguage = string

# Valid unique identifier ?
UID = string



Hunt                    Expires January 27, 2011              [Page 133]

Internet-Draft                     SRS                         July 2010


# Valid term
Term = xsd:positiveInteger

RegistrarId = xsd:positiveInteger

RegistrarIdOrOTHERS = RegistrarId | "OTHERS"

# Complex data types/definitions
ActionResponse =
  element.Error
  | element.Domain*
  | element.UDAIValid
  | element.DomainTransfer
  | element.BillingTrans*
  | element.DeferredRegistrarIncome*
  | element.Registrar*
  | element.SysParam*
  | element.RunLog*
  | element.Schedule*
  | element.AccessControlList*
  | (element.RawRequest, element.RawResponse)
  | element.BillingAmount*
  | element.Handle*
  | element.Message*

RegDomainStatus = "Active" | "PendingRelease"
DomainStatus = RegDomainStatus | "Available"
BillStatus = "PendingConfirmation" | "Confirmed"

Contact =
  element.PostalAddress?,
  element.Phone?,
  element.Fax?

ContactAttr =
  attribute HandleId { text }?,
  attribute Name { text }?,
  attribute Email { text }?,
  attribute ActionId { text }?

ContactFilter =
  element.PostalAddressFilter?,
  element.Phone?,
  element.Fax?

ContactAttrFilter =
  attribute HandleId { text }?,
  attribute Name { text }?,



Hunt                    Expires January 27, 2011              [Page 134]

Internet-Draft                     SRS                         July 2010


  attribute Email { text }?

PhoneAttr =
  attribute CountryCode { text }?,
  attribute AreaCode { text }?,
  attribute LocalNumber { text }?

Role =
  "Registrar"
  | "Registry"
  | "Whois"
  | "Query"
  | "CreateDomain"
  | "UpdateDomain"
  | "TransferDomain"
  | "CancelDomain"
  | "UncancelDomain"
  | "UpdateRegistrar"
  | "Administer"
  | "Supervisor"
  | "Connect"
  | "ReleaseDomain"
  | "QueryACL"
  | "UpdateACL"
  | "QueryRegACL"

ScheduledJob =
  "BuildDnsZoneFiles"
  | "ReleaseDomains"
  | "RenewDomains"
  | "GenerateDomainReport"
  | "GenerateStatsReport"

DateRange =
  element.From?,
  element.To?

AccountingAction = "Credit" | "Debit"

# == Root element ======================================================

element.NZSRSRequest =
  element NZSRSRequest {
    attribute VerMajor { Number },
    attribute VerMinor { Number },
    attribute RegistrarId { RegistrarId }?,
    (element.DomainCreate
     | element.DomainUpdate



Hunt                    Expires January 27, 2011              [Page 135]

Internet-Draft                     SRS                         July 2010


     | element.HandleCreate
     | element.HandleUpdate
     | element.HandleDetailsQry
     | element.Whois
     | element.DomainDetailsQry
     | element.ActionDetailsQry
     | element.UDAIValidQry
     | element.RegistrarCreate
     | element.RegistrarUpdate
     | element.RegistrarDetailsQry
     | element.RegistrarAccountQry
     | element.GetMessages
     | element.AckMessage
     | element.SysParamsCreate
     | element.SysParamsUpdate
     | element.SysParamsQry
     | element.RunLogCreate
     | element.RunLogQry
     | element.ScheduleCreate
     | element.ScheduleCancel
     | element.ScheduleQry
     | element.ScheduleUpdate
     | element.BillingAmountUpdate
     | element.BillingAmountQry
     | element.DeferredIncomeSummaryQry
     | element.DeferredIncomeDetailQry
     | element.BilledUntilAdjustment
     | element.BuildDnsZoneFiles
     | element.GenerateDomainReport
     | element.AdjustRegistrarAccount
     | element.AccessControlListQry
     | element.AccessControlListAdd
     | element.AccessControlListRemove)+
  }

element.NZSRSResponse =
  element NZSRSResponse {
    attribute VerMajor { Number },
    attribute VerMinor { Number },
    attribute RegistrarId { RegistrarId }?,
    (element.Response+ | element.Error)
  }

# == Request actions ===================================================

# ++ Domain details update actions +++++++++++++++++++++++++++++++++++++

# Create new domain name (record)



Hunt                    Expires January 27, 2011              [Page 136]

Internet-Draft                     SRS                         July 2010


# ActionResponse: (Domain|Error)
element.DomainCreate =
  element DomainCreate {
    attribute ActionId { UID },
    attribute DomainName { DomainName },
    attribute DomainNameUnicode { DomainNameUnicode }?,
    attribute DomainNameLanguage { DomainNameLanguage }?,
    attribute RegistrantRef { UID }?,
    attribute Term { Term },
    [ a:defaultValue = "1" ] attribute Delegate { Boolean }?,
    element.RegistrantContact,
    element.AdminContact?,
    element.TechnicalContact?,
    element.NameServers?,
    element.AuditText?
  }

# Update domain record
# Usage:
#   - update all domain records that match DomainNameFilter
#     pattern (? replaces a single character, * replaces a group of
#     characters); not all updates are possible (sensible)
#   Following actions are invoked by setting corresponding attribute
#   to %True; or opposite actions when set to %False; - omission of
#   the attribute means no action:
#   - newUDAI - force a new authentication UID to be generated
#   - renew
#   - cancel
#   - lock
#   Transfer to another registrar is an implied operation - if non-owner
#   registrar is doing an update, the domain is transferred to the new
#   registrar. For this operation UDAI is required, and the
#   DomainNameFilter must be a simple domain name (no wildcards!)
# ActionResponse: (Domain+|Error)
element.DomainUpdate =
  element DomainUpdate {
    attribute ActionId { UID },
    attribute UDAI { UID }?,
    attribute NewUDAI { Boolean }?,
    attribute RegistrantRef { UID }?,
    attribute Term { Term }?,
    attribute Delegate { Boolean }?,
    attribute Renew { Boolean }?,
    attribute NoAutoRenew { Boolean }?,
    attribute Lock { Boolean }?,
    attribute Cancel { Boolean }?,
    attribute Release { Boolean }?,
    [ a:defaultValue = "1" ] attribute FullResult { Boolean }?,



Hunt                    Expires January 27, 2011              [Page 137]

Internet-Draft                     SRS                         July 2010


    element.DomainNameFilter+,
    element.RegistrantContact?,
    element.AdminContact?,
    element.TechnicalContact?,
    element.NameServers?,
    element.AuditText?
  }

element.HandleCreate =
  element HandleCreate {
    attribute ActionId { UID },
    attribute HandleId { UID },
    ContactAttr,
    Contact,
    element.AuditText?
  }

element.HandleUpdate =
  element HandleUpdate {
    attribute ActionId { UID },
    attribute HandleId { UID },
    attribute Delete { Boolean }?,
    ContactAttr,
    Contact,
    element.AuditText?
  }

element.HandleDetailsQry =
  element HandleDetailsQry {
    attribute MaxResults { Number }?,
    attribute SkipResults { Number }?,
    [ a:defaultValue = "0" ] attribute CountResults { Boolean }?,
    element.HandleIdFilter*,
    element.SearchDateRange?,
    element.ChangedInDateRange?,
    element.ContactFilter?
  }

element.DomainNameFilter =
  element DomainNameFilter {
    text
  }

# ++ Domain details query actions  +++++++++++++++++++++++++++++++++++++

# Whois  (retrieve details of DomainName)
# ActionResponse: (Domain|Error)
element.Whois =



Hunt                    Expires January 27, 2011              [Page 138]

Internet-Draft                     SRS                         July 2010


  element Whois {
    attribute QryId { UID }?,
    [ a:defaultValue = "1" ] attribute FullResult { Boolean }?,
    attribute SourceIP { text }?,
    attribute DomainName { DomainName },
    empty
  }

# UDAIValidQry - enquire if the UDAI for a domain is correct
# ActionResponse: (UDAIValid)
element.UDAIValidQry =
  element UDAIValidQry {
    attribute QryId { UID }?,
    attribute DomainName { DomainName },
    attribute UDAI { UID },
    empty
  }

# General register query
# ActionResponse: (Domain*|Error)
element.DomainDetailsQry =
  element DomainDetailsQry {
    attribute QryId { UID }?,
    attribute Status { RegDomainStatus }?,
    attribute Delegate { Boolean }?,
    attribute Term { Term }?,
    attribute RegistrantRef { UID }?,
    attribute MaxResults { Number }?,
    attribute SkipResults { Number }?,
    [ a:defaultValue = "0" ] attribute CountResults { Boolean }?,
    element.DomainNameFilter*,
    element.NameServerFilter?,
    element.RegistrantContactFilter?,
    element.AdminContactFilter?,
    element.TechnicalContactFilter?,
    element.ResultDateRange?,
    element.SearchDateRange?,
    element.ChangedInDateRange?,
    element.RegisteredDateRange?,
    element.LockedDateRange?,
    element.CancelledDateRange?,
    element.BilledUntilDateRange?,
    element.AuditTextFilter?,
    element.ActionIdFilter?,
    element.FieldList?
  }

element.AuditTextFilter =



Hunt                    Expires January 27, 2011              [Page 139]

Internet-Draft                     SRS                         July 2010


  element AuditTextFilter {
    text
  }

element.ActionIdFilter =
  element ActionIdFilter {
    text
  }

# Query request - returns request-response pair
# ActionResponse: ((RawRequest,RawResponse)|Error)
element.ActionDetailsQry =
  element ActionDetailsQry {
    attribute QryId { UID }?,
    attribute ActionId { UID },
    attribute OriginatingRegistrarId { UID }?,
    empty
  }

# ++ Registar details update actions +++++++++++++++++++++++++++++++++++
# ActionResponse: (Registrar|Error)
element.RegistrarCreate =
  element RegistrarCreate {
    attribute ActionId { UID },
    attribute Name { text },
    attribute AccRef { text },
    attribute RegistrarId { RegistrarId },
    attribute URL { text }?,
    element.RegistrarPublicContact,
    element.RegistrarSRSContact,
    element.DefaultTechnicalContact,
    element.EncryptKeys,
    element.EPPAuth?,
    element.Allowed2LDs?,
    element.Roles?,
    element.AuditText?
  }

element.RegistrarUpdate =
  element RegistrarUpdate {
    attribute ActionId { UID },
    attribute Name { text }?,
    attribute AccRef { text }?,
    attribute URL { text }?,
    element.RegistrarPublicContact?,
    element.RegistrarSRSContact?,
    element.DefaultTechnicalContact?,
    element.EncryptKeys?,



Hunt                    Expires January 27, 2011              [Page 140]

Internet-Draft                     SRS                         July 2010


    element.EPPAuth?,
    element.Allowed2LDs?,
    element.Roles?,
    element.AuditText?
  }

# ++ Registar details query actions ++++++++++++++++++++++++++++++++++++

# ActionResponse: (Registrar*|Error)
element.RegistrarDetailsQry =
  element RegistrarDetailsQry {
    attribute QryId { UID }?,
    attribute RegistrarId { RegistrarId }?,
    attribute NameFilter { text }?,
    element.ResultDateRange?
  }

# RegistrarAccountQry (obtain billing records)
# ActionResponse: (BillingTrans*|Error)
element.RegistrarAccountQry =
  element RegistrarAccountQry {
    attribute QryId { UID }?,
    attribute RegistrantRef { UID }?,
    attribute DomainName { DomainName }?,
    attribute InvoiceId { UID }?,
    attribute MaxResults { Number }?,
    attribute SkipResults { Number }?,
    attribute TransStatus { BillStatus }?,
    [ a:defaultValue = "0" ] attribute CountResults { Boolean }?,
    element.TransDateRange?,
    element.InvoiceDateRange?
  }

# BillingAmount Transactions
# (To set the monthly charge for Billing)
# ActionResponse: (BillingAmount*|Error)
element.BillingAmountUpdate =
  element BillingAmountUpdate {
    attribute ActionId { UID },
    element.BillingAmount
  }

element.BillingAmountQry =
  element BillingAmountQry {
    attribute QryId { UID }?,
    empty
  }




Hunt                    Expires January 27, 2011              [Page 141]

Internet-Draft                     SRS                         July 2010


element.BillingAmount =
  element BillingAmount {
    attribute Amount { Dollars },
    element.EffectiveDate?
  }

element.EffectiveDate =
  element EffectiveDate {
    TimeStamp,
    empty
  }

# ++ Query date ranges +++++++++++++++++++++++++++++++++++++++++++++++++

element.ResultDateRange =
  element ResultDateRange {
    DateRange
  }

element.SearchDateRange =
  element SearchDateRange {
    DateRange
  }

element.ChangedInDateRange =
  element ChangedInDateRange {
    DateRange
  }

element.RegisteredDateRange =
  element RegisteredDateRange {
    DateRange
  }

element.CancelledDateRange =
  element CancelledDateRange {
    DateRange
  }

element.LockedDateRange =
  element LockedDateRange {
    DateRange
  }

element.BilledUntilDateRange =
  element BilledUntilDateRange {
    DateRange
  }



Hunt                    Expires January 27, 2011              [Page 142]

Internet-Draft                     SRS                         July 2010


element.InvoiceDateRange =
  element InvoiceDateRange {
    DateRange
  }

element.TransDateRange =
  element TransDateRange {
    DateRange
  }

# ++ Query field list ++++++++++++++++++++++++++++++++++++++++++++++++++

element.FieldList =
  element FieldList {
    attribute Status { Boolean }?,
    attribute NameServers { Boolean }?,
    attribute RegistrantContact { Boolean }?,
    attribute RegisteredDate { Boolean }?,
    attribute AdminContact { Boolean }?,
    attribute TechnicalContact { Boolean }?,
    attribute LockedDate { Boolean }?,
    attribute Delegate { Boolean }?,
    attribute RegistrarId { Boolean }?,
    attribute RegistrarName { Boolean }?,
    attribute RegistrantRef { Boolean }?,
    attribute LastActionId { Boolean }?,
    attribute ChangedByRegistrarId { Boolean }?,
    attribute Term { Boolean }?,
    attribute BilledUntil { Boolean }?,
    attribute CancelledDate { Boolean }?,
    attribute AuditText { Boolean }?,
    attribute EffectiveFrom { Boolean }?,
    empty
  }

# ++ Registry actions ++++++++++++++++++++++++++++++++++++++++++++++++++

# ActionResponse: (SysParam*|Error)
element.SysParamsCreate =
  element SysParamsCreate {
    attribute ActionId { UID },
    element.SysParam+,
    element.AuditText?
  }

element.SysParamsUpdate =
  element SysParamsUpdate {
    attribute ActionId { UID },



Hunt                    Expires January 27, 2011              [Page 143]

Internet-Draft                     SRS                         July 2010


    element.SysParam+,
    element.AuditText?
  }

element.SysParamsQry =
  element SysParamsQry {
    attribute QryId { UID }?,
    empty
  }

# ActionResponse: (RunLog|Error)
element.RunLogCreate =
  element RunLogCreate {
    attribute ActionId { UID },
    element.FirstRunDate,
    element.RunLog
  }

# ActionResponse: (RunLog*|Error)
element.RunLogQry =
  element RunLogQry {
    attribute QryId { UID }?,
    attribute ProcessName { text }?,
    attribute Parameters { text }?,
    element.LogDateRange?
  }

element.LogDateRange =
  element LogDateRange {
    DateRange,
    empty
  }

# ActionResponse: (Schedule|Error)
element.ScheduleCreate =
  element ScheduleCreate {
    attribute ProcessName { ScheduledJob },
    attribute Frequency { text },
    attribute Parameters { text }?,
    attribute ActionId { UID },
    element.FirstRunDate,
    element.FinalRunDate?,
    element.AuditText?
  }

element.ScheduleCancel =
  element ScheduleCancel {
    attribute ActionId { UID },



Hunt                    Expires January 27, 2011              [Page 144]

Internet-Draft                     SRS                         July 2010


    attribute ProcessName { ScheduledJob },
    attribute Parameters { text }?,
    element.FirstRunDate,
    element.AuditText?
  }

element.ScheduleUpdate =
  element ScheduleUpdate {
    attribute ActionId { UID },
    attribute Parameters { text }?,
    attribute Frequency { text }?,
    attribute ProcessName { ScheduledJob },
    element.FirstRunDate,
    element.LastRunDate?,
    element.AuditText?
  }

element.FinalRunDate =
  element FinalRunDate {
    TimeStamp,
    empty
  }

element.ScheduleQry =
  element ScheduleQry {
    attribute QryId { UID }?,
    attribute ProcessName { text }?,
    attribute Parameters { text }?,
    element.ActiveOn?,
    element.FirstRunDate?
  }

element.ActiveOn =
  element ActiveOn {
    TimeStamp
  }

element.DeferredIncomeSummaryQry =
  element DeferredIncomeSummaryQry {
    attribute BaseMonth { text },
    attribute BaseYear { text },
    attribute IncomeMonth { text },
    attribute IncomeYear { text },
    attribute QryId { UID }?,
    empty
  }

element.DeferredRegistrarIncome =



Hunt                    Expires January 27, 2011              [Page 145]

Internet-Draft                     SRS                         July 2010


  element DeferredRegistrarIncome {
    attribute BaseMonth { text },
    attribute BaseYear { text },
    attribute IncomeMonth { text },
    attribute IncomeYear { text },
    attribute RegistrarId { RegistrarId },
    attribute BilledAmount { Dollars },
    attribute BilledCount { Number },
    empty
  }

element.DeferredIncomeDetailQry =
  element DeferredIncomeDetailQry {
    attribute BaseMonth { text },
    attribute BaseYear { text },
    attribute IncomeMonth { text },
    attribute IncomeYear { text },
    attribute QryId { UID }?,
    empty
  }

element.BilledUntilAdjustment =
  element BilledUntilAdjustment {
    attribute DomainName { DomainName },
    attribute ActionId { UID },
    element.NewBilledUntilDate,
    element.AuditText
  }

element.NewBilledUntilDate =
  element NewBilledUntilDate {
    TimeStamp,
    empty
  }

element.BuildDnsZoneFiles =
  element BuildDnsZoneFiles {
    attribute ActionId { UID },
    element.RunDate
  }

element.GenerateDomainReport =
  element GenerateDomainReport {
    attribute ActionId { UID },
    element.RunDate
  }

element.RunDate =



Hunt                    Expires January 27, 2011              [Page 146]

Internet-Draft                     SRS                         July 2010


  element RunDate {
    TimeStamp,
    empty
  }

element.AdjustRegistrarAccount =
  element AdjustRegistrarAccount {
    attribute RegistrarId { RegistrarId },
    attribute DomainName { DomainName },
    attribute ActionId { UID },
    attribute Months { Number },
    attribute ActionType { AccountingAction },
    element.TransactionDate,
    element.BillPeriodStart,
    element.BillPeriodEnd,
    element.AuditText
  }

element.TransactionDate =
  element TransactionDate {
    TimeStamp,
    empty
  }

element.AccessControlListQry =
  element AccessControlListQry {
    attribute Resource { text }?,
    attribute List { text }?,
    attribute Type { text }?,
    [ a:defaultValue = "0" ] attribute FullResult { Boolean }?,
    AccessControlListContentFilter*
  }

AccessControlListContentFilter =
  element.DomainNameFilter
  | element.RegistrarIdFilter
  | element.AddressFilter

element.RegistrarIdFilter =
  element RegistrarIdFilter {
    text
  }

element.AddressFilter =
  element AddressFilter {
    text
  }




Hunt                    Expires January 27, 2011              [Page 147]

Internet-Draft                     SRS                         July 2010


element.AccessControlListRemove =
  element AccessControlListRemove {
    attribute Resource { text },
    attribute List { text },
    attribute ActionId { UID },
    [ a:defaultValue = "1" ] attribute FullResult { Boolean }?,
    element.AccessControlListEntry*,
    element.AuditText?
  }

element.AccessControlListAdd =
  element AccessControlListAdd {
    attribute Resource { text },
    attribute List { text },
    attribute ActionId { UID },
    [ a:defaultValue = "1" ] attribute FullResult { Boolean }?,
    element.AccessControlListEntry+,
    element.AuditText?
  }

element.AccessControlList =
  element AccessControlList {
    attribute Resource { text },
    attribute List { text },
    ( attribute Size { Number }
      | attribute SizeChange { Number } )?,
    attribute Type { text }?,
    element.AccessControlListEntry*
  }

element.AccessControlListEntry =
  element AccessControlListEntry {
    attribute Address { text }?,
    attribute DomainName { text }?,
    attribute RegistrarId { RegistrarId }?,
    attribute Comment { text }?,
    element.EffectiveDate?
  }

# == GetMessages =======================================================

# Get message by UID, or messages since date/time for the Effective
# registrar
#
# Non-DTD enforced compliance:
#   - either UID or date range must be supplied
# ActionResponses: (Response|Error)
element.GetMessages =



Hunt                    Expires January 27, 2011              [Page 148]

Internet-Draft                     SRS                         July 2010


  element GetMessages {
    attribute QryId { UID }?,
    attribute OriginatingRegistrarId { RegistrarIdOrOTHERS }?,
    attribute ActionId { UID }?,
    attribute RecipientRegistrarId { RegistrarId }?,
    attribute MaxResults { Number }?,
    attribute SkipResults { Number }?,
    [ a:defaultValue = "0" ] attribute CountResults { Boolean }?,
    [ a:defaultValue = "0" ] attribute QueueMode { Boolean }?,
    element.TransDateRange?,
    element.AuditTextFilter?,
    element.TypeFilter*
  }

GetMessagesTypes = "third-party" | "server-generated-data"

element.TypeFilter =
  element TypeFilter {
    attribute Type { GetMessagesTypes }
  }

# == AckMessage ========================================================

# ACK message by originating RegistrarId/UID
# ActionResponse: (Response|Error)
element.AckMessage =
  element AckMessage {
    attribute ActionId { UID },
    attribute OriginatingRegistrarId { RegistrarId },
    attribute TransId { UID }
  }

# == ActionResponse ====================================================

# ++ Response ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# This is a "one size fits all" response, which
# can contain any type of response.  Errors to individual actions
# can be specified within the response (errors in parsing the total
# request are handled by the error ELEMENT).  The response may
# contain multiple domain records (eg, for queries), and may contain
# a complete history of the domain.
# The registrar and id will match those passed in for most requests,
# but will be present to uniquely identify a getmsg response.
# Most requests will result in a single response; but getmsg requests
# for messages since a date/time will result in one response per
# response found.
# The DomainTransfer differs from the rest in that it is not a direct
# response to an action, but a message for the registrar generated by



Hunt                    Expires January 27, 2011              [Page 149]

Internet-Draft                     SRS                         July 2010


# an action of another registrar. It may be returned in response to a
# GetMessages action.
DomainWriteAction =
  "DomainCreate"
  | "DomainUpdate"

DomainQueryAction =
  "Whois"
  | "DomainDetailsQry"
  | "ActionDetailsQry"
  | "UDAIValidQry"

HandleWriteAction =
  "HandleCreate"
  | "HandleUpdate"

HandleQueryAction =
  "HandleDetailsQry"

RegistrarWriteAction =
  "RegistrarCreate"
  | "RegistrarUpdate"

RegistrarQueryAction =
  "RegistrarDetailsQry"
  | "RegistrarAccountQry"
  | "GetMessages"

RegistryAction =
  "SysParamsUpdate"
  | "SysParamsCreate"
  | "SysParamsQry"
  | "RunLogCreate"
  | "RunLogQry"
  | "ScheduleCreate"
  | "ScheduleCancel"
  | "ScheduleQry"
  | "ScheduleUpdate"
  | "BillingExtract"
  | "SetBillingAmount"
  | "BillingAmountQry"
  | "DeferredIncomeSummaryQry"
  | "DeferredIncomeDetailQry"
  | "BilledUntilAdjustment"
  | "BuildDnsZoneFiles"
  | "GenerateDomainReport"
  | "AdjustRegistrarAccount"
  | "AccessControlListQry"



Hunt                    Expires January 27, 2011              [Page 150]

Internet-Draft                     SRS                         July 2010


  | "AccessControlListAdd"
  | "AccessControlListRemove"
  | "BillingAmountUpdate"

Action =
  DomainWriteAction
  | DomainQueryAction
  | HandleWriteAction
  | HandleQueryAction
  | RegistrarWriteAction
  | RegistrarQueryAction
  | RegistryAction

ActionEtc =
  Action
  | "UnknownTransaction"
  | "DomainTransfer"
  | "AckMessage"

element.Response =
  element Response {
    attribute Action { ActionEtc },
    attribute FeId { Number },
    attribute FeSeq { Number },
    attribute OrigRegistrarId { RegistrarId },
    attribute TransId { UID }?,
    attribute Rows { Number }?,
    attribute Count { Number }?,
    attribute MoreRowsAvailable { Boolean }?,
    attribute RecipientRegistrarId { RegistrarId }?,
    element.FeTimeStamp,
    (element.Response* | ActionResponse | element.AckResponse)?
  }

element.AckResponse =
  element AckResponse {
    attribute OriginatingRegistrarId { RegistrarId },
    attribute TransId { UID },
    attribute Remaining { Number }
  }


# ++ Error +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# Errors can be either specific to a requested action, or generic
# to the whole request.  A globally unique errorid identifies the
# error that occured, and a human-readable string describing the
# error is enclosed.
# The errorids are assigned like HTTP, where there are three digits



Hunt                    Expires January 27, 2011              [Page 151]

Internet-Draft                     SRS                         July 2010


# to identify the error.  The first digit indicates approximately
# the status (success, failure, etc); the second is a subcategory of
# that, and the third is used for fine detail indications.
# The exact list of errors is in SRS::Error module.
element.Error =
  element Error {
    attribute ErrorId { UID },
    attribute Severity { Number },
    attribute Hint { UID },
    element.Description,
    element.ErrorDetails*
  }

element.Description =
  element Description {
    text
  }

element.ErrorDetails =
  element ErrorDetails {
    text
  }

element.FeTimeStamp =
  element FeTimeStamp {
    TimeStamp,
    empty
  }

# == Lower level elements ==============================================

# Zone information: fields held in the register, that can be obtained
# through the registrar/registry protocol.
# and/or maintainable through the registry protocol.

# ++ Domain details ++++++++++++++++++++++++++++++++++++++++++++++++++++
# NOTE: the domain authid (UDAI) is sent ONLY if it has been newly
# generated; otherwise it is assumed that the registrar has the
# previous value cached.
element.Domain =
  element Domain {
    attribute DomainName { DomainName },
    attribute DomainNameUnicode { DomainNameUnicode }?,
    attribute DomainNameUnicodeHex { DomainNameUnicodeHex }?,
    attribute DomainNameLanguage { DomainNameLanguage }?,
    attribute RegistrantRef { UID }?,
    attribute RegistrarName { text }?,
    attribute Status { DomainStatus }?,



Hunt                    Expires January 27, 2011              [Page 152]

Internet-Draft                     SRS                         July 2010


    attribute Delegate { Boolean }?,
    attribute Term { Term }?,
    attribute RegistrarId { RegistrarId }?,
    attribute UDAI { UID }?,
    element.NameServers?,
    element.RegistrantContact?,
    element.RegistrarPublicContact?,
    element.AdminContact?,
    element.TechnicalContact?,
    element.BilledUntil?,
    element.RegisteredDate?,
    element.CancelledDate?,
    element.LockedDate?,
    element.AuditDetails?
  }

element.BilledUntil =
  element BilledUntil {
    TimeStamp,
    empty
  }

element.LockedDate =
  element LockedDate {
    TimeStamp,
    empty
  }

element.RegisteredDate =
  element RegisteredDate {
    TimeStamp,
    empty
  }

element.CancelledDate =
  element CancelledDate {
    TimeStamp,
    empty
  }

element.DomainTransfer =
  element DomainTransfer {
    attribute RegistrarName { text },
    TimeStamp,
    element.TransferredDomain+
  }

element.TransferredDomain =



Hunt                    Expires January 27, 2011              [Page 153]

Internet-Draft                     SRS                         July 2010


  element TransferredDomain {
    text
  }

element.UDAIValid =
  element UDAIValid {
    attribute Valid { Boolean },
    empty
  }

# Name servers
# The IP address should be included if and only if the fqdn is within
# the zone that it is associated with
# the IP6Addr may be in any of the formats specified by RFC 2373, ie.
#     1.  X:X:X:X:X:X:X:X         (Fully Specified)
#     2.  X:X:X::X                ('::' denotes compressed zeroes )
#     3.  X:X:X:X:X:X:d.d.d.d     ('d.d.d.d' denotes an IP4 Address)
element.NameServers =
  element NameServers {
    element.Server*
  }

element.Server =
  element Server {
    attribute FQDN { text },
    attribute IP4Addr { text }?,
    attribute IP6Addr { text }?,
    empty
  }

# Name server Filter
# As above, but a filter for a search
element.NameServerFilter =
  element NameServerFilter {
    element.ServerFilter+
  }

element.ServerFilter =
  element ServerFilter {
    attribute FQDN { text }?,
    attribute IP4Addr { text }?,
    attribute IP6Addr { text }?,
    empty
  }

# ++ Registrar details +++++++++++++++++++++++++++++++++++++++++++++++++

element.Registrar =



Hunt                    Expires January 27, 2011              [Page 154]

Internet-Draft                     SRS                         July 2010


  element Registrar {
    attribute RegistrarId { RegistrarId },
    attribute Name { text },
    attribute AccRef { text },
    attribute URL { text }?,
    element.RegistrarPublicContact,
    element.RegistrarSRSContact,
    element.DefaultTechnicalContact,
    element.EncryptKeys,
    element.EPPAuth?,
    element.Allowed2LDs?,
    element.Roles?,
    element.AuditDetails?
  }

element.Allowed2LDs =
  element Allowed2LDs {
    element.SecondLD*
  }

element.SecondLD =
  element SecondLD {
    attribute DomainName { DomainName },
    empty
  }

element.Roles =
  element Roles {
    element.Role*
  }

element.Role =
  element Role {
    attribute RoleName { Role },
    empty
  }

element.EncryptKeys =
  element EncryptKeys {
    element.EncryptKey*
  }

element.EncryptKey =
  element EncryptKey {
    text
  }

element.EPPAuth =



Hunt                    Expires January 27, 2011              [Page 155]

Internet-Draft                     SRS                         July 2010


  element EPPAuth {
    attribute Password { text }
  }

# ++ Billing transaction +++++++++++++++++++++++++++++++++++++++++++++++

element.BillingTrans =
  element BillingTrans {
    attribute RegistrarId { RegistrarId },
    attribute Type { text },
    attribute TransStatus { BillStatus },
    attribute DomainName { DomainName },
    attribute RegistrantRef { UID }?,
    attribute BillingTerm { Term },
    attribute InvoiceId { UID }?,
    attribute Amount { Dollars },
    element.InvoiceDate?,
    element.TransDate,
    element.BillPeriodStart,
    element.BillPeriodEnd
  }

element.InvoiceDate =
  element InvoiceDate {
    TimeStamp,
    empty
  }

element.TransDate =
  element TransDate {
    TimeStamp,
    empty
  }

element.BillPeriodStart =
  element BillPeriodStart {
    TimeStamp,
    empty
  }

element.BillPeriodEnd =
  element BillPeriodEnd {
    TimeStamp,
    empty
  }

# ++ Contact information: for registrant, admin, technical +++++++++++++




Hunt                    Expires January 27, 2011              [Page 156]

Internet-Draft                     SRS                         July 2010


element.RegistrantContact =
  element RegistrantContact {
    ContactAttr,
    Contact
  }

element.RegistrantContactFilter =
  element RegistrantContactFilter {
    ContactAttrFilter,
    ContactFilter
  }

element.AdminContact =
  element AdminContact {
    ContactAttr,
    Contact
  }

element.AdminContactFilter =
  element AdminContactFilter {
    ContactAttrFilter,
    ContactFilter
  }

element.TechnicalContact =
  element TechnicalContact {
    ContactAttr,
    Contact
  }

element.TechnicalContactFilter =
  element TechnicalContactFilter {
    ContactAttrFilter,
    ContactFilter
  }

element.ChangedDomains =
  element ChangedDomains {
     element.Domain*
  }

element.Handle =
  element Handle {
    attribute RegistrarId { RegistrarId },
    ContactAttr,
    Contact,
    element.AuditDetails?,
    element.ChangedDomains?



Hunt                    Expires January 27, 2011              [Page 157]

Internet-Draft                     SRS                         July 2010


  }


element.Message =
  element Message {
    element.Response,
    attribute Remaining { Number }?
  }

element.HandleIdFilter =
  element HandleIdFilter {
    text
  }

element.ContactFilter =
  element ContactFilter {
    ContactAttrFilter,
    ContactFilter
  }

element.RegistrarPublicContact =
  element RegistrarPublicContact {
    ContactAttr,
    Contact
  }

element.DefaultTechnicalContact =
  element DefaultTechnicalContact {
    ContactAttr,
    Contact
  }

element.RegistrarSRSContact =
  element RegistrarSRSContact {
    ContactAttr,
    Contact
  }

# Country is an ISO 3166-1 country code
element.PostalAddress =
  element PostalAddress {
    attribute Address1 { text }?,
    attribute Address2 { text }?,
    attribute City { text }?,
    attribute Province { text }?,
    attribute CountryCode { text }?,
    attribute PostalCode { text }?,
    empty



Hunt                    Expires January 27, 2011              [Page 158]

Internet-Draft                     SRS                         July 2010


  }

element.PostalAddressFilter =
  element PostalAddressFilter {
    attribute Address1 { text }?,
    attribute Address2 { text }?,
    attribute City { text }?,
    attribute Province { text }?,
    attribute CountryCode { text }?,
    attribute PostalCode { text }?,
    empty
  }

element.Phone =
  element Phone {
    PhoneAttr,
    empty
  }

element.Fax =
  element Fax {
    PhoneAttr,
    empty
  }

# ++ Raw responses +++++++++++++++++++++++++++++++++++++++++++++++++++++

element.RawRequest =
  element RawRequest {
    element.XML,
    element.Signature
  }

element.RawResponse =
  element RawResponse {
    element.XML,
    element.Signature
  }

element.XML =
  element XML {
    text
  }

element.Signature =
  element Signature {
    text
  }



Hunt                    Expires January 27, 2011              [Page 159]

Internet-Draft                     SRS                         July 2010


# ++ System Parameters +++++++++++++++++++++++++++++++++++++++++++++++++

element.SysParam =
  element SysParam {
    attribute Name { text },
    element.ParamValue,
    element.AuditDetails?
  }

element.ParamValue =
  element ParamValue {
    text
  }

# ++ Run Log +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

element.RunLog =
  element RunLog {
    attribute ProcessName { text },
    attribute Parameters { text }?,
    attribute ActionStatus { text },
    attribute Control { text }?,
    element.RunLogTimeStamp,
    element.RunLogDetails?
  }

element.RunLogDetails =
  element RunLogDetails {
    text
  }

element.RunLogTimeStamp =
  element RunLogTimeStamp {
    TimeStamp,
    empty
  }

# ++ Schedule ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

# Frequency in ?
element.Schedule =
  element Schedule {
    attribute ProcessName { ScheduledJob },
    attribute Frequency { text },
    attribute Parameters { text }?,
    attribute CreateByRegistrarId { UID },
    attribute CreateActionId { UID },
    attribute CancelByRegistrarId { UID }?,



Hunt                    Expires January 27, 2011              [Page 160]

Internet-Draft                     SRS                         July 2010


    attribute CancelActionId { UID }?,
    element.FirstRunDate,
    element.FinalRunDate?,
    element.CreateAuditText?,
    element.CancelAuditText?
  }

element.FirstRunDate =
  element FirstRunDate {
    TimeStamp,
    empty
  }

element.LastRunDate =
  element LastRunDate {
    TimeStamp,
    empty
  }

element.CreateAuditText =
  element CreateAuditText {
    text
  }

element.CancelAuditText =
  element CancelAuditText {
    text
  }

# ++ Audit details ++++++++++++++++++++++++++++++++++++++++++

element.AuditDetails =
  element AuditDetails {
    attribute RegistrarId { text }?,
    attribute ActionId { UID }?,
    element.AuditTime?,
    element.AuditText?
  }

element.AuditTime =
  element AuditTime {
    DateRange
  }

element.AuditText =
  element AuditText {
    text
  }



Hunt                    Expires January 27, 2011              [Page 161]

Internet-Draft                     SRS                         July 2010


# == Various ===========================================================

element.From =
  element From {
    TimeStamp,
    empty
  }

element.To =
  element To {
    TimeStamp,
    empty
  }

start = element.NZSRSRequest | element.NZSRSResponse


Author's Address

   Matthew Hunt
   New Zealand Registry Services
   Level 9
   Exchange Place
   5-7 Willeston Street
   Wellington
   New Zealand

   Email: matt@nzrs.net.nz
   URI:   http://www.nzrs.net.nz/






















Hunt                    Expires January 27, 2011              [Page 162]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/