Registry-Registrar System (1.0) REFERENCE MANUAL (1.21)€¦ · WHOIS Query 17 9.6. Query Domain...

Israel Internet Association (ISOC-IL) 6 Bareket St., POB 7210, Petach Tikvah 49517, Israel

Registry-Registrar System (1.0)

REFERENCE MANUAL (1.21)

November 2007

Copyright © 2006, Israel Internet Association (ISOC-IL)

All rights reserved.

ISOC-IL Reg-Reg Reference Manual (1.21)

of 89

REFERENCE MANUAL

ISOC-IL Registry-Registrar System ("REG-REG")

Table of Contents

1. General ........................................................................3

2. Terminology ....................................................................4 2.1. Terms used throughout this document 4 2.2. The REG-REG System – Overview 7

3. REG-REG basics .................................................................8 3.1. Object 8

3.2. Attribute 8 3.3. Domain Name Record and Objects – schematic view 9

4. REG-REG – Technical Requirements ..............................................10 4.1. Domain Name 10

4.2. Request 10 4.3. XML 11

4.4. Non-XML (human readable) Mail sent by the REG-REG Server 17

5. Registration Actions – General Description ....................................17

5.1. General Legend 17

6. Registration Actions – Operations on Domain Name Records ......................17

6.1. Create Domain 17 6.2. Update Domain 17 6.3. Delete Domain 17

6.4. Reassign Domain 17 6.5. Renew Domain 17

6.6. Transfer Domain 17

7. Registration Actions – Operations on Contact Objects ..........................17

7.1. Create Contact 17 7.2. Update Contact 17

7.3. Delete Contact 17

8. Information and General Purpose Operations ....................................17

8.1. Cancel Request 17 8.2. Info Domain 17

8.3. Info Contact 17 8.4. Check Domain 17

9. Information Retrieval Interface ("IRI") .......................................17 9.1. Access 17

9.2. Login Page 17 9.3. Users Management 17 9.4. Main Page 17 9.5. WHOIS Query 17 9.6. Query Domain Names managed by an AR 17 9.7. Query Contacts Managed by an AR 17 9.8. Query status of requests pertaining to Domain Name Records 17 9.9. Query status of requests pertaining to Contact Object 17 9.10. Credit Log 17 9.11. Purchase Credit 17 9.12. Manage Password 17

9.13. Manage IRI Authorized Users 17

10. Testbed Information ...........................................................17

10.1. How to register 17 10.2. Testbed URLs and addresses 17

10.3. Registry behavior simulation in testbed environment 17

APPENDIX A – REG-REG Response Codes.................................................17

APPENDIX B – Mail Messages..........................................................17

APPENDIX C – Error Message IDs......................................................17

APPENDIX D – List of Figures........................................................17


of 89

1. General

The ISOC-IL REG-REG system introduces an interface between

Accredited Registrars (ARs) and the .il ccTLD registry. This

interface is available exclusively to ARs, who use it to

perform the entire set of functions against the Domain Name

Registry (new name registration, modifications and deletion of

names, querying the status of names etc.).

This document specifies the technical elements of the interface

to the .il REG-REG system. The system uses elements of the EPP

protocol family, although it is not a standard implementation

of EPP, nor does it claim compliance with EPP or RRP.

ARs should use this document (or its subsequent versions) to

develop their interface to the system (client side). ISOC-IL

will make an effort to make future versions of this

specification backwards-compatible, however such compatibility

is not guaranteed.


of 89

2. Terminology

2.1. Terms used throughout this document

AR - Accredited Registrar. A

company accredited by ISOC-IL

as a Registrar of the .il ccTLD

Registry.

AR Code - A two letter identification

code of the AR. The code is

handed to the AR at the signing

of the Accreditation Agreement.

AR Main EPP Mail

Address - A mail address of the AR,

registered with the Registry,

to which all Server Responses

are sent.

AR Main Regular

Mail Address - A mail address of the AR,

registered with the Registry,

to which regular (i.e., non-

XML) mail is sent.

Attribute - As defined in Section 3.2.

ccTLD - country code Top Level

Domain. Israel's ccTLD is

".il".

Domain Name As defined in Section 4.1.

Domain Name

Record - The information stored in the

Registry about a specific

Domain Name, namely its

Registrant, Managing Registrar,

Administrative Contact,

Technical Contact, Zone Contact

and DNS Name Servers. See

scheme in Section 3.3.

Extensions Block - As defined in Section 4.3(d).

Expiry Date - The date on which a Domain

Name Record is scheduled to

expire. Domain Names can be

registered, renewed or

reassigned in whole

Registration Units only, and in

every occasion, expiry may not

exceed the Maximal Registration

Period from the date of the

transaction.


of 89

Handle - A Contact Object's (as

defined in Section 3.1) unique

identifier within the Registry.

A Handle is created

automatically by the REG-REG

Server upon the creation of a

Contact Object, and is of the

following format:

"<AR Code>-<xy><number>-IL"

where:

"<xy>" – Name initials of the

Contact.

"<number>" – An integer.

The hyphens and the string "IL"

are constants.

IL Extensions - The Registry's additions to

the Standard EPP.

The IL Extensions

implementation is guided by RFC

3730.

ISOC-IL - The Israel Internet

Association. Administrator and

operator of the .il ccTLD

Registry.

IRI - The Information Retrieval

Interface provided by the

Registry to the AR. The IRI is

described in detail in sec. 9.

Managing AR - The AR responsible for a

particular Object.

(1) In a Domain Name Record, AR's name is an Attribute

of the Object.

(2) In a Contact Object, AR Code forms a part of the

Object's Handle.

Maximal

Registration

Period

- Two Registration Units.

Object - As defined in Section 3.1.

Principal User - An IRI user with sub-users

management authorities. The

Principal user is single per

AR.

Registration

Action - One of the actions regarding

an Object that a Managing AR is

entitled to perform, e.g.,

registering a new Domain Name.

Registration Unit - Registration of one Domain

Name, for a period of one

calendar year. Registration of

Domain Names and their renewal

is done in whole Registration

Units only.


of 89

REG-REG Client - A system that generates and

handles the AR's Registration

Actions and communicates with

the REG-REG Server.

REG-REG Server - The Registry's server that

handles ARs' Registration

Actions.

Reference Label - As defined in Section 6.1(f).

Request - A PGP-signed mail, containing

the appropriate XML code for

the desired Registration Action

sent by a REG-REG Client to the

REG-REG Server.

Role - A Domain Name Record contains

three Contact Objects (see

Section 3.3). Each those

Contact Object has a title,

namely: Administrative Contact,

Technical Contact and Zone

Contact, collectively referred

to as Roles.

- The differences between the

different Contacts' authorities

are outside the scope of this

document.

Standard EPP - Extensible Provisioning

Protocol, published in RFC

3730.

Standard EPP

Block - As defined in Section 4.3(d)

The Registry - The .il ccTLD Domain Name

Registry, operated by ISOC-IL.


of 89

2.2. The REG-REG System – Overview

The REG-REG System is an asynchronous, XML-based system

which gives ISOC-IL's ARs a secured and authenticated

tool to manage Registration Actions in the Registry.

The AR's communication with the REG-REG Server is done by

sending a Request to the REG-REG Server in a PGP-signed

mail. The REG-REG Server responses are sent as PGP-signed

mail as well.

A REG-REG Client is not supplied by the Registry, and

needs to be implemented by the AR independently.

The Registry provides a testing environment to allow ARs

to test the Clients they build for correct operation.

An Information Retrieval Interface ("IRI") is provided

for retrieval of information and follow-up on Objects

managed by the AR, the AR's Registration Actions and the

AR's available credit.

The REG-REG system makes use of principles, objects and

terminology from EPP.

However, the REG-REG is NOT a Standard EPP

implementation, nor does it claim EPP conformance.

For example, a principal difference is that Standard EPP

is synchronous, and has a notion of session management;

the current implementation of the IL REG-REG system,

being asynchronous, has no notion of a session.


of 89

3. REG-REG basics

3.1. Object

An Object is an independent information unit in the

Registry. For example, a Contact Person is an Object

containing details of a specific contact person.

An Object has a unique identifier in the Registry, and

can be updated by submission of a Request pertaining

directly to that Object.

An Object can be referred to by different Domain Name

Records, and under different Roles in a Domain Name

Record.

(a) Objects Management

Only the Managing AR of an Object can update it.

An update made to an Object will be reflected in

all Objects pointing to the modified Object. For

example, updating the mail address of a Contact

Object will be reflected in all Domain Names

Records in which this Contact object is listed.

A Contact Object exists only in the realm of the

Managing AR. An AR cannot refer (or use in any

other way) Contact Objects that are associated with

a different AR.

(b) List of REG-REG Object types:

(1) Domain Name Record; (2) Contact Object.

3.2. Attribute

An Attribute is an information unit which is associated

with a specific Object. For example, the Domain Name

Registrant is an Attribute of the Domain Name Record.

(a) Managing Attributes

In order to update an Attribute, the Managing AR of

the Object containing the Attribute needs to submit

a Request pertaining to the Object.

Updating identical Attributes associated with more

than one Object, requires the submission of one

Request per each Object to which the Attributes

associate. For example, updating the physical

address of a Registrant who holds 5 Domain Names,

will require 5 separate update request, one per

each Domain Name.


of 89

(b) List of REG-REG Attributes:

(1) Registrant; (2) DNS Information; (3) Registrar. (4) Reference to a Contact Object. Reference is

made by way of Contact Object's Handle.

3.3. Domain Name Record and Objects – schematic view

Figure 1: Domain Name Record Object

Figure 2: Contact Object

example.co.il

(1) Registrant Details. (Attribute) a. Name. b. Organization. c. Physical Address. d. Tel. e. Fax. f. Email.

(2) Administrative Contact. (Reference to Object) a. AR-BL12345-IL

(3) Technical Contact. (Reference to Object) a. AR-AL54321-IL

(4) Zone Contact. (Reference to Object) a. AR-DS3432-IL.

(5) DNS Information. (Attribute) a. dns.ofexample.co.il b. ns1.dnsname.com

(6) Managing Registrar (Attribute) a. AB

AR-BL12345-IL a. Name. b. Organization. c. Physical Address. d. Tel. e. Fax. f. Email.


of 89

4. REG-REG – Technical Requirements

4.1. Domain Name

(a) General

A Domain Name in the Registry is a textual string

of the form "<3rd level>.<SLD>.il", where:

• ".il" is the ccTLD.

• <SLD>: is one of the following Second Level

Domain Names: (1) "co", (2) "org".

• <3rd level>: a string that is –

o Comprised only of the following

characters:

� Lowercase Latin letters ('a' to

'z').

� Digits ('0' to '9').

� Hyphen ('-').

o At-least 3 characters long.

o At-most 64 characters long.

o Does not start or end with a hyphen.

o Does not contain two consecutive

hyphens.

For example: in the Domain Name "isoc.org.il",

"isoc" is the 3rd level, "org" is the SLD, and "il"

is the ccTLD.

It should be noted that there are additional

requirements that may be imposed on the 3rd level

string. These requirements are not technical in

nature and are primarily derived from the Domain

Name Allocation Rules. Being such, they are not

relevant for the development of the REG-REG Client,

but in any case messages sent as a result of such

requirements not being met, will be standard REG-

REG messages.

4.2. Request

(a) Signature

Registration Requests will be sent by mail, signed

with the AR's PGP private key.

The mail will be verified using the AR's public-

key, which will be handed to the Registry at the

time of signing the Accreditation Agreement.

(b) Subject Line

The mail MUST include the string "[EPPMail]" in the

subject line. The string may be positioned anywhere

in the subject line.

Mail messages that do not include the above string

will be SILENTLY DISCARDED, with no rejection

(“bounce”) message.


of 89

(c) Recipient

Registration Actions shall be sent to:

<[email protected]>. Please refer to sec

10.2 regarding information relating to sending

Registration Actions to the testbed system.

(d) Mail Body

The body of the mail will contain exactly one MIME

part of type text/plain, which will contain only

the XML Request, as outlined below. No other types

of MIME body parts will be recognized or accepted.

MIME Charset can be one of: ISO-8859-1, us-ascii or

UTF-8.

4.3. XML

(a) XML Case Sensitivity

XML is case sensitive. Unless specifically

specified otherwise, case distinction MUST be kept.

(b) XML File – general structure

Every XML instance MUST begin with the declaration

<?XML?>, indicating one of the identified character

sets (UTF-8, ASCII-7 or ISO-8859-1) and XML version

1.0.

All Registration Actions are to be included between

the tags <epp> and </epp>.

Figure 3: XML File: General Structure

(c) Validation of XML files

The Registry provides XML Schema files (xsd), to

allow ARs to validate compatibility of syntax and

semantics of Requests with the REG-REG system.

Using the Schema is recommended.

When using the schema, ALL Requests MUST be

validated against the file: "epp.xsd". This file

automatically imports all schemas required for the

validation.

Schema files are available at: http://register.isoc.org.il/reg-reg/schema/Schema.tgz

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

<epp xmlns="urn:ietf:params:ns:epp-1.0"

xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd">

. . .

</epp>


of 89

(d) REG-REG Client Request – general structure

A REG-REG Client Request is of the following

format:

Figure 4: REG-REG Client Request: General Structure

Legend:

• <command> … </command>:

Contains the Registration Action block. A

Registration Action block is comprised of two

blocks:

o Standard EPP Block – between the tags

<someaction>…</someaction>:

Part of the Registration Action that

contains Standard EPP XML code.

The XML in the Standard EPP Block

corresponds to the "command" part of

EPP.

o Extensions Block – between the tags

<extension> … </extension>:

Implements ISOC-IL's Extensions to the

Standard EPP XML code.

Some IL Extensions are mandatory, as

outlined in this document.

• <clTRID> ... </clTRID>

AR's transaction identifier. The identifier

shall be of the following format: AR Code,

followed by a hyphen, followed by a serial

number (comprised of the characters '0'—'9'

only, between 1 and 9999999999). For Example:

"AB-209876". The identifier should be unique

within the AR's range of identifiers. This

identifier is not used by the REG-REG Server,

and is returned in the REG-REG Server's

response AS IS.


<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"…>

<command>

<someaction> ... </someaction>

<extension>

...

</extension>

<clTRID>AB-209876</clTRID> </command>

</epp>


of 89

(e) REG-REG Server response – general XML structure

A REG-REG Server response is of the following

format:

Figure 5: REG-REG Server Response: General Structure

Legend:

• <response> … </response>

Contains the REG-REG Server Response block.

• <result> … </result>

Contains details of the result of the

processing of a Request, including:

o A result code.

o <msg> … </msg>:

human readable message between the

tags. Please refer to the following

section for additional information.

o <value> … </value>:

A set of values relevant to the

Registration Action performed.

• <resData>…</resData>:

Contains specific information on the Object

or Registration Action performed, e.g, the

Object's identifier.

• <trID> … </trID>:

Comprised of two blocks, the combination of

which creates a unique identifier of the

transaction performed:

o <clTRID> … </clTRID>:

AR's identifier included in the

Request.

<svTRID> … </svTRID>:

A unique identifier generated by the

REG-REG Server. The format of the

identifier is: "ISOC-IL-[AR

Code][number] [Time Stamp]".


<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instanc" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"

xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xmlns:isocil="http://www.isoc.org.il/xml/epp/isocil-

1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdurn:ietf:params:xml:ns:contact-1.0

contact-1.0.xsdurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdhttp://www.isoc.org.il/xml/epp/isocil-

1.0">

<response>

<result code="1000"> <msg> ... </msg>

<value> ... </value>

</result> <resData> ... </resData>

<extension>

... </extension>

<trID>

<clTRID>BL-209876</clTRID>

<svTRID>ISOCIL-AB716 20051117110800</svTRID>

</trID>

</response>

</epp>


of 89

Please refer to Appendix A for a list of the

response codes and their corresponding messages.

(f) REG-REG Server response – the <msg> tag

The <msg> tag includes information in a human

readable form. It also includes the Request ID (as

defined in sec 5.1). The Request ID is also

included in the Response Subject Line (see

following section).

Where the result code corresponds to a denial of

request which was handled manually in the Registry,

additional information for the grounds for the

denial will be included between the <msg> … </msg>

tags, denoting an "Error Message id(s)" followed by

a code.

A short description of the message relating to the

code is included in the <resData> block, between

the tags <MailMsgs>.

For example:

Figure 6: REG-REG Server Response: <resData> tag

Please refer to Appendix C for a complete

description of the error message ids and their

meaning.

(g) REG-REG Server Response – Mail Subject Line and Recipient

The Subject Line of the REG-REG Server's Response

is of the following format:

"[EPPMail] <request status>: <request type> <domain

name>, requestid <Request ID>, <svTRID>, <clTRID>"

Where:

- "[EPPMail]" – a constant string.

- <request status> - is one of the following:

"Pending", "Success", "Reject", "Error".

- <request type> - is one of the following:

"createdomain", "updatedomain", "deletedomain",

"transferdomain", "renewdomain", "reassigndomain".

- <domain name> - is the Domain Name with regard to

which the Request was submitted.

… <msg>Your request was denied (Error message(s) id(s): 400; domain requestid=D323860)</msg>

... <resData>

<mailMsgs>

<isoc:mailmsg id="400">Incomplete/invalid holder data</isoc:mailmsg> </mailMsgs>

</resData>

…


of 89

- "requestid" – a constant string

- <request ID> - as defined in 5.1.

- <svTRID> - as defined in 5.1.

- <clTRID> - as defined in 5.1.

The Server's response is sent to the AR Main EPP

Address, without regard to the "from" address of

the mail sent to the REG-REG Server.

(h) REG-REG Server Response – Notification of a successful submission of a request: Pending Status

In cases where the Request has been queued for

processing, the initial response of the REG-REG

Server following a successful submission of a

Request will be a notification on the "Pending"

status of the Request.

The "Pending" notification is for information

purposes only and does not require an action by the

Client.

The final response with the result of the

processing of the Request will be sent by the REG-

REG Server upon completion of the processing.

Figure 7: REG-REG Server Response: notification of successful

submission


<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instanc"

xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"

xmlns:isocil="http://www.isoc.org.il/xml/epp/isocil-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdurn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsdurn:ietf:params:xml:ns:domain-1.0 domain-

1.0.xsdhttp://www.isoc.org.il/xml/epp/isocil-1.0">

<response> <result code="1001">

<msg>Submission completed successfully (domain requestid=D204169)</msg>

</result> <trID>


<svTRID>ISOCIL-BL1634 20051117110800</svTRID>

</trID>

</response>

</epp>


of 89

4.4. Non-XML (human readable) Mail sent by the REG-REG Server

There are two types of mail messages that have no strict

formats.

- Error messages for Requests that were a-priori denied,

e.g., bad PGP signature.

- Various notifications in a human readable form

initiated by the Registry, e.g., warning on a low credit

level or a request to respond to a Transfer request.

In those messages, the Subject Line begins with the

string "[ILREG]".

Information on those Mail Messages can be found in

Appendix B.

The non-XML messages are sent to the AR Main Regular Mail

Address, and to the email address of the AR main contact

person registered with the Registry.


of 89

5. Registration Actions – General Description

In the following sections the various Registration Actions are

described in detail, including the various XML files exchanged

between the REG-REG Client and the REG-REG Server during the

life-cycle of a Request.

5.1. General Legend

Occurrence Indicates the number of times an

element can appear in a Request,

where:

"1" – exactly 1 instance MUST

appear.

"0-1" – at most 1 instance MAY

appear.

"1-*" – as many as needed, but

at-least once.

String Any text, including whitespaces

of any form.

Token A String that contains no space

characters.

Date In the following format:

CCYY-MM-DD

dateTime In the following format:

CCYY-MM-DDThh:mm:ss.sss

The time is local Israeli time

(IST=GMT+2 or IDT=GMT+3).

Request ID - A unique identifier of a

Request in the Registry, of the

following format:

"[letter][integer]", where:

[letter] – 'D' for Requests

pertaining to Domain Name

Records, and 'C' for Requests

pertaining to Contact Object

Reqeusts.

[integer] – a serial number.

<clTRID> AR's transaction identifier. The

format of the identifier is: "[AR

Code]-[integer]"

<svTRID> A unique transaction identifier

generated by the REG-REG Server.

The format of the identifier is:

"ISOC-IL-[AR Code][integer] [Time

Stamp]".


of 89

6. Registration Actions – Operations on Domain Name Records

6.1. Create Domain

(a) Purpose

Create a new Domain Name Record.

(b) Authority

Any AR can submit a Create Domain Request.

(c) Result

A new Domain Name Record is created for an initial

one Registration Period, with the submitting AR as

the Managing Registrar.

(d) Attributes and Objects in a Domain Name Record

As outlined in Scheme 2 (sec 3.3 above) a Domain

Name Record contains 3 Attributes, and 3 referrals

to Contact Objects.

The Attributes of a Domain Name Record are: (1)

Registrant, (2) Managing AR, and (3) DNS

Information.

The referrals to Contact Objects in a Domain Name

Record are: (1) Administrative Contact, (2)

Technical Contact and (3) Zone Contact.

(e) Relating to an existing Object in a Create Domain Request

Relating to existing Objects is done by including

the Object's Handle, between the appropriate tags.

For example:

Figure 8: Relating an existing Contact Object in a Create Domain Request

The above example will cause the Contact Object AB-

BL1234-IL to be the Administrative Contact of the

Domain Name Record created.

(f) Creation of new Contact Objects in a Create Domain Request

The Create Domain command allows for the creation

of new Contact Objects within the Request.

This is done by writing a reference label

("Reference Label") between the <domain:contact> …

</domain:contact> tags in the Standard EPP Block,

and including the details referring to that label

in the Extensions Block, between the tags

<isocil:contact> … </isocil:contact>.

(...)

<domain:contact type="admin">AB-BL1234-IL</domain:contact>

(...)


of 89

Figure 9: Creating a new Contact Object within a Create Domain

Request

In the above example – "NEW3" is the Reference

Label of the new Contact Object to be created. The

details of the Contact are those between the tags

<isocil:contact>...</isocil:contact>, identified by

including the label "NEW3" between the tags

<contact:id> ... </contact:id>.

The Reference Label MUST be of the following

format: the string "NEW[digit]".

Any mismatch between Reference Labels included in

the Standard EPP Block and the Extension Block will

result in an error. An appropriate error message

will be sent by the EPP Server, and the Request

will not be processed.

As explained in sec 3.1 above, a Contact Object can

be listed under different Roles. The result of the

above example is the creation of *one* new Object.

This Object will be listed as the Administrative

and Technical Contact for the Domain Name Record

created. This Object will have its unique Handle,

for future reference.

The REG-REG Server does not check whether an

existing Object in the Registry has identical

details. A new Handle will be created every time

this option is used.

(...Standard EPP Block...)

<domain:contact type="admin">NEW3</domain:contact> <domain:contact type="tech">NEW3</domain:contact>

(...Extensions Block ...)

<isocil:contact> <contact:id>NEW3</contact:id>

<contact:type>domain</contact:type>

<contact:postalInfo type="int">

<contact:name>Israel Israeli</contact:name>

<contact:org>Some Company Ltd.</contact:org> <contact:addr>

<contact:street>7 Herzl St.</contact:street>

<contact:city>Haifa</contact:city>

<contact:sp></contact:sp>

<contact:pc>12345</contact:pc>

<contact:cc>IL</contact:cc>

</contact:addr>

</contact:postalInfo>

<contact:voice>+972 4 8095001</contact:voice> <contact:fax>+972 8 8870432</contact:fax>

<contact:email>

[email protected] </contact:email>

</isocil:contact>


of 89

(g) Defining a Registrant Attribute

Defining the Domain Name Registrant is done using

the labeling method explained in sec (f) above.

The <contact type> tag is "Registrant".

The Registrant Attribute is mandatory.

(h) Lock Transfer Option

The Lock Transfer option, when turned on, will

cause the immediate rejection of any Transfer

requests (see sec. 6.5(g)) submitted to the Domain

Name Record.

This option can be turned off exclusively by the

Managing AR, by submitting an Update Domain Request

(see sec. 0).

The circumstances under which the Lock Transfer

should be used are outside the scope of this

document.

To turn the Lock Transfer on the string "true"

should be typed between the tags

<domain:locktransfer> and </domain:locktransfer>.

The default value assumed by the REG-REG Server is

"false".

The Lock Transfer tags are not mandatory, and

should be used in a Create Domain Request only if

changing the default value is needed.


of 89

(i) Code Example

Figure 10: Create Domain Request


<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"

xmlns:isocil="http://www.isoc.org.il/xml/epp/isocil-1.0"

xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"

xmlns:domainrequest="http://www.isoc.org.il/xml/epp/isocil-domainrequest-1.0"

xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsd

http://www.isoc.org.il/xml/epp/isocil-1.0 isocil-1.0.xsd

urn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsd

http://www.isoc.org.il/xml/epp/isocil-domainrequest-1.0 isocil-domainrequest-1.0.xsd

urn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsd">

<command>

<create>

<domain:create>

<domain:name>example.co.il</domain:name>

<domain:ns>

<domain:hostAttr>

<domain:hostName>ns.hostingcompany.co.il</domain:hostName>

</domain:hostAttr>

<domain:hostAttr>

<domain:hostName>ns.example.co.il</domain:hostName>

<domain:hostAddr>193.168.0.1</domain:hostAddr>

</domain:hostAttr>

</domain:ns>

<domain:registrant>NEW1</domain:registrant>

<domain:contact type="admin">AB-SS15170-IL</domain:contact>

<domain:contact type="tech">NEW2</domain:contact>

<domain:contact type="zone">AB-SS15170-IL</domain:contact>

<domain:locktransfer>true</domain:locktransfer>

<domain:period unit="y">2</domain:period>

</domain:create>

</create>

<extension>

<isocil:ext>

<isocil:create>

<isocil:contact>

<contact:id>NEW1</contact:id>

<contact:type>registrant</contact:type>



<contact:org>Great Company Inc.</contact:org>

<contact:addr>

<contact:street>7 Herzl</contact:street>

<contact:city>Tel Aviv</contact:city>




</contact:addr>


<contact:voice>+972 3 9883301</contact:voice>

<contact:fax>+972 8 9770002</contact:fax>

<contact:email>[email protected]</contact:email>

</isocil:contact>

<isocil:contact>





<contact:org>Some Company Ltd.</contact:org>

<contact:addr>

<contact:street>100 Herzl Avenue</contact:street>

<contact:city>Jerusalem</contact:city>




</contact:addr>





</isocil:contact>

</isocil:create>

</isocil:ext>

</extension>

<clTRID>AB-1971</clTRID>

</command>

</epp>


of 89

Legend:

• <domain:create> ... </domain:create>:

Defines that the desired Registration Action,

Create Domain, where:

o <domain:name> ... </domain:name>

Defines the Domain Name to be created.

o <domain:ns> ... </domain:ns>

Defines a DNS Information block, where

<domain:hostAttr> ... /domain:hostAttr>

defines the details of one DNS server:

� <domain:hostName> ...

</domain:hostname> - contains the

DNS server's host name.

� <domain:hostAddr> ...

</domain:hostAddr> - contains the

DNS server's IP address.

o <domain:registrant> ...

</domain:registrant>

Contains the Reference Label to the

Extension Block, where the Regsitrant's

details are listed.

o <domain:contact> ... </domain:contact>

Contains either an already existing

Contact Object Handle (managed by the

submitting AR), or a Reference Label to

the Extension Block where a new

contact's details are listed.

The <domain:contact> tag attribute

"type" – defines the Contact's Role,

which is one of the following:

� "admin" – Administrative Contact.

� "tech" – Technical Contact.

� "zone" – Zone Contact.

o <domain:locktransfer>…</domain:locktran

sfer>

Controlling the Lock Transfer option.

(see sub-sec. (h) above).

o <domain:period …> … </domain:period>

The registration period requested, up

to and including the Maximal

Registration Period, expressed in

Registration Units.

• <isocil:ext>...</isocil:ext>

Defines the IL Extension Block.

• <isocil:contact>...</isocil:contact>

A Contact Object creation block.

o <contact:id>...</contact:id>

Contains a Reference Label declared in

the Standard EPP Block.

o <contact:type>...</contact:type>

Contains one of the following:

� "registrant" – to indicate that

the details are of the Registrant


of 89

(a Domain Name Record Attribute).

This one is mandatory.

� "domain" – to indicate that the

details are of a Contact Object.

• <contact:postalInfo>...</contact:postalInfo>

Contains a block defining the Contact's

details.

The Tag attribute type="int" should be

included as specified in the example.

o <contact:name>...</contact:name

Contains the Contact's full name. In

case of a person, name and surname

separated by a space. In case of a

legal-entity, e.g, a company, the

company's full name, including

appropriate suffix, e.g., "Ltd." –

separated by spaces.

o <contact:org>...</contact:org>

Contains the Contact's organization.

o <contact:addr>...</contact:addr>

A block containing the postal

information associated with the

Contact:

� <contact:street>...<contact:stree

t>

Contains the street and number of

the Contact's address.

� <contact:city>...</contact:city>

Contact's city.

� <contact:sp>...</contact:sp>

Contact's State/Province.

� <contact:pc>...</contact:pc>

Contact's postal code.

� <contact:cc>...</contact:cc>

Contact's two-letter country

code, according to ISO-3166.

o <contact:voice>...</contact:voice>

Contact's telephone number, in the

following format:

"+[country code] [area code] [phone

number]".

o <contact:fax>...</contact:fax>

Contact's facsimile number, in


number]".

o <contact:email>...</contact:email>

Contact's direct mail address.


of 89

(j) Tags occurrence table

TAG occurrences min-max

Size+ remarks

<epp> 1

<command> 1

<create> 1

<domain:create> 1

<domain:name> 1 Token: 9-73.

<domain:ns> 1 Token.

<domain:hostAttr> 0-13

<domain:hostname> Token: 1-100.

<domain:hostAddr> Obligatory when Glue record needed.

<domain:contact type="admin">

1

<domain:contact type="tech">

1

<domain:contact type="zone">

1

<domain:locktransfer> 0-1

<domain:period> 1

<extension> 1

<isocil:ext> 1

<isocil:create> 1

<isocil:contact> 1-4 All subtags but: <contact:org> <contact:sp> <contact:pc> <contact:voice> <contact:fax> are mandatory.

<clTRID> 1 token : 4-64


of 89

(k) Additional Response Data (<resData> block) – in a SUCCESS message

The REG-REG Server's response upon the successful

completion of a Create Domain Request:

Figure 11: <resData> block in Server's response to Create

Domain Request

Legend:

• <domain:creData> … </domain:creData>

Information on the creation of the Domain

Name Record, where:

o <domain:name>…</domain:name>

Specifies the Domain Name Record

created.

o <domain:crDate>…</domain:crDate>

Specifies the creation time of the

Domain Name, in XML dateTime format.

o <domain:expDate>…</domain:expDate>

Specifies current expiry date of the

Domain Name, in XML dateTime format.

o <domain:contact …>

Specifies the Handles of the different


<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instanc" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"

xmlns:isocil="http://www.isoc.org.il/xml/epp/isocil-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0

epp-1.0.xsdurn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsdurn:ietf:params:xml:ns:domain-1.0 domain-


<response>

<result>

<code>1000</code>

<msg>Command completed successfully (domain requestid=D323957)</msg>

</result> <resData>

<domain:creData>

<domain:name>example222.co.il</domain:name> <domain:crDate>2006-07-12T11:31:03.000Z</domain:crDate>

<domain:expDate>2007-07-12T23:59:59.000Z</domain:expDate>

<domain:contact type="admin">BL-II13-IL</domain:contact> <domain:contact type="tech">BL-BS11-IL</domain:contact>

<domain:contact type="zone">BL-BS11-IL</domain:contact>

<domain:transferlocked>1</domain:transferlocked>

<domain:ns>

<domain:hostAttr>


<domain:hostAddr />

</domain:hostAttr>

<domain:hostAttr> <domain:hostName>ns.example.co.il</domain:hostName>

<domain:hostAddr />

</domain:hostAttr>

</domain:ns>

</domain:creData> </resData>

<trID>

<clTRID>BL-1111</clTRID> <svTRID>ISOCIL-BL146 20060712113302</svTRID>

</trID>

</response> </epp>


of 89

contacts registered for the Domain

Name.

o <domain:transferlocked>

1 – indicates that the locktransfer

option for the Domain Name is turned

on. 0 = turned off.

o <domain:ns>

Indicates the DNS servers registered

for the Domain Name.

o <trID>

Indicates transaction ID. Comprised of

the client trID and the server trID.


of 89

6.2. Update Domain

(a) Purpose

Updating details in a Domain Name Record.

(b) Authority

Only the Managing AR of a Domain Name Record can

submit an Update Domain Request against that name.

(c) Update Domain Request - content

An Update Domain Request MUST contain only the

Domain Name Record information units that are being

actually updated.

The data regarding any information unit that is

being included in an Update Domain Request MUST

include all the unit's mandatory tags. All

mandatory tags MUST be non-empty. Information

pertaining to specific mandatory tags that is not

being updated MUST include the data that is

registered in the Domain Name Record prior to the

submission of the Request. Empty non-mandatory tags

will override the information in the Domain Name

Record relating to those tags.

Registration Record units cannot be deleted by

inclusion of an empty unit in an Update Domain

Request.

There is an option to create new Contact Objects in

an Update Domain Request. The implementation is

identical to the one used in the Create Domain

Request. Please refer to Sec. 6.1(f) for further

information. This option should be used only in

cases where the new Contact Object needs to be

associated with the Domain Name Record being

updated; otherwise, the Create Contact Request

should be used.


of 89

(d) Code Example

Figure 12: Update Domain Request

The above is an example of the fullest Update

Domain Request possible.













<command> <update>

<domain:update>

<domain:name>example.co.il</domain:name> <domain:chg>

<domain:ns>

<domain:hostAttr>

<domain:hostName>ns1.example.co.il</domain:hostName>


</domain:hostAttr>

<domain:hostAttr>

<domain:hostName>ns21.hostingcompany.co.il</domain:hostName>

</domain:hostAttr> </domain:ns>

<domain:contact type="admin">AB-IT949-IL</domain:contact>

<domain:contact type="tech">AB-IT949-IL</domain:contact> <domain:contact type="zone">AB-IT949-IL</domain:contact>

<domain:locktransfer>false</domain:locktransfer>

</domain:chg> </domain:update>

</update>

<extension>

<isocil:ext>

<isocil:update>

<isocil:contact>



<contact:name>Israel Israeli</contact:name> <contact:org>Great Company Ltd.</contact:org>

<contact:addr>

<contact:street>7 Jabotinsky St.</contact:street> <contact:city>Ramat Gan</contact:city>


<contact:pc>33233</contact:pc> <contact:cc>IL</contact:cc>

</contact:addr>





</isocil:contact>

</isocil:update>

</isocil:ext>

</extension>


</command>

</epp>


of 89

If for example, an update to the Registrant's

information is not needed, the whole <extension> …

</extension> block MUST be excluded from the

Request.

Legend:

• <domain:update> ... </domain:update>:


Update Domain, where:


Defines the Domain Name Record to be

updated.

<domain:chg> ... </domain:chg>

Contains the information units of a

Domain Name Record being updated.

o <domain:ns> ... </domain:ns>






DNS server's name.




Maximal number of DNS Information

blocks is 13.


Contains an existing Contact Object

Handle (managed by the submitting AR.







o <domain:locktransfer> …

</domain:locktransfer>


(see sub-sec. 6.1(h) above).



o <isocil:contact>...</isocil:contact>

Defines the Registrant data that will

be written in the Domain Name Record

after the Update Domain Request is

processed.

o <contact:type>…</contact:type>

Must be "registrant".

o <contact:name>...</contact:name>

Contains Registrant's full name. In






of 89




Contains Registrant's organization.




Registrant:


t>


the Registrant's physical

address.


Regsitrant's city.




Registrant's postal code.


Registrant's two-letter country




following format:


number]"


Registrant's facsimile number, in the

following format:


number]"

<contact:email>...</contact:email>

Regsitrant's direct mail address.


of 89

(e) Tags occurrence table


Size+ remarks

<epp> 1

<command> 1

<update> 1

<domain:update> 1


<domain:chg> 0-1

<domain:ns> 0-1 Token.

<domain:hostAttr> 1-13 If <domain:ns> included.




0-1


0-1


0-1


<extension> 0-1

<isocil:ext> 1

<isocil:update> 1

<isocil:contact> 1 All subtags but: <contact:org> <contact:sp> <contact:pc> <contact:voice> <contact:fax> are mandatory.



of 89

6.3. Delete Domain

(a) Purpose

Delete an existing Domain Name Record.

(b) Authority


submit a Delete Domain Request.

(c) Result

Upon the completion of the Delete Domain Request,

the Domain Name Record will cease to exist. A

Domain Name Record that was deleted, can be re-

created by submission of a complete Create Domain

Request.

(d) Code Example

Figure 13: Delete Domain Request

Legend:

• <domain:delete> ... </domain:delete>:


Delete Domain, where:

<domain:name> ... </domain:name>

Defines the Domain Name to be deleted.

<clTRID> ... </clTRID>

AR's transaction identifier.



Size+ remarks

<epp> 1

<command> 1

<delete> 1

<domain:delete> 1















<command>

<delete>

<domain:delete>

<domain:name>example.org.il</domain:name>

</domain:delete>

</delete>

<clTRID>XY-152</clTRID>

</command>

</epp>


of 89

6.4. Reassign Domain

(a) Purpose

Reassign the Domain Name Record to a new Holder.

(b) Authority


submit a Reassign Domain Request.

(c) Result

The Reassign process is comprised of two

Registration Actions: Delete Domain and Create

Domain – executed one after the other as a single

atomic Registration Action, ensuring that no other

Create Domain Requests for the Domain are processed

in between.

Upon the completion of the Reassign Domain Request,

a new Domain Name Record is created, with the

submitting AR as the Managing AR, for one

Registration Period starting the date the

reassignment is processed.

IMPORTANT – no information is inherited from the

previous Domain Name Record. Where continuity of

operation of the Domain Name is required, the DNS

Information blocks from the previous Domain Name

Record MUST be specifically included in the

Reassign Request.

(d) Code Example

The Reassign request is very similar to the Create

Domain Request. The difference is in the tags

identifying the request type (namely, the <update>

and <reassign> tags).

(Firgue in following page)


of 89

Figure 14: Reassign Domain Request

Legend:













<command>

<update>

<domain:reassign>


<domain:ns>

<domain:hostAttr>


</domain:hostAttr>

<domain:hostAttr>

<domain:hostName>ns.example.co.il</domain:hostName>


</domain:hostAttr>

</domain:ns>

<domain:registrant>NEW1</domain:registrant>

<domain:contact type="admin">MH16016-IL</domain:contact>

<domain:contact type="tech">NEW2</domain:contact>

<domain:contact type="zone">MH16016-IL</domain:contact>

<domain:locktransfer>true</domain:locktransfer>


</domain:reassign>

</update>

<extension>

<isocil:ext>

<isocil:create>

<isocil:contact>





<contact:org>Some Organization</contact:org>

<contact:addr>

<contact:street>12 Herzel St. </contact:street>

<contact:city>Jerusalem</contact:city>

<contact:sp> </contact:sp>



</contact:addr>





</isocil:contact>

<isocil:contact>






<contact:addr>


<contact:city>Beer Sheva</contact:city>

<contact:sp>IL</contact:sp>



</contact:addr>





</isocil:contact>

</isocil:create>

</isocil:ext>

</extension>



of 89

• <domain:reassign> ... </domain:reassign>:


Reassign a Domain, where:


Defines the Domain Name to be

Reassigned.

<domain:ns> ... </domain:ns>






DNS server's name.




o <domain:registrant> ...

</domain:registrant>

Contains the Reference Label to the

Extension Block, where the Regsitrant's

details are listed.


Contains either an already existing

Contact Object Handle (managed by the

submitting AR), or a Reference Label to

the Extension Block where the contact's

details are listed.







o <domain:locktransfer> …

</domain:locktransfer>


(see sec. 6.1(h)). above)


The registration period requested, up

to and including the Maximal

Registration Period, expressed in

Registration Units.



• <isocil:contact>...</isocil:contact>

A Contact Object creation block.


Contains a Reference Label declared in

the Standard EPP Block.

o <contact:type>...</contact:type>

Contains one of the following:

� "registrant" – to indicate that

the details are of the Registrant

(a Domain Name Record Attribute).

� "domain" – to indicate that the

details are of a Contact Object.


of 89

• <contact:postalInfo>...</contact:postalInfo>

Contains a block defining the Contact's

details.

The Tag attribute type="int" should be

included as specified in the example.














Contact:


t>




Contact's city.










following format:


number]"


Contact's facsimile number, in the

following format:


number]"




of 89



Size+ remarks

<epp> 1

<command> 1

<update> 1

<domain:reassign> 1


<domain:ns> 1 Token.

<domain:hostAttr> 0-13




1


1


1

<extension> 1


<domain:period> 1

<isocil:ext> 1

<isocil:create> 1

<isocil:contact> 1-4 All subtags but: <contact:org> <contact:sp> <contact:pc> <contact:voice> <contact:fax> are mandatory.

<contact:type> Registrant contact type obligatory.



of 89

6.5. Renew Domain

(a) Purpose

Extend the Expiry Date of a Domain Name Record for

one Registration Period.

(b) Authority


submit a Renew Domain Request.

(c) Timing

A Renew Domain Request can only be submitted as of

3 months prior to the Expiry Date. Attempting to

renew a Domain Name Record prior to that will

result in an error message indicating that the

Domain Name is not yet up for renewal.

(d) Result

Upon the completion of the Renew Domain Request,

the Expiry Date of the Domain Name will be extended

by one Registration Period.

(e) Code Example

Figure 15: Renew Domain Request

Legend:

• <domain:renew> ... </domain:renew>:


renewal of a Domain, where:


Defines the Domain Name to be Renewed.


The renewal period requested (from

Expiry Date), expressed in Registration

Units. The Expiry Date following the

renewal request may not exceed the

Maximal Registration Period, counted













<command>

<renew>

<domain:renew>



</domain:renew>

</renew>


</command>

</epp>


of 89

from the date of submission of the

renewal request. A request to renew the

registration beyond the Maximal

Registration Period will result in an

error.

o <clTRID> ... </clTRID>

Defines the AR transaction identifier.

(f) Tags occurrence table


Size+ remarks

<epp> 1

<command> 1

<renew> 1

<domain:renew> 1


<domain:period> 1


(g) Additional Response Data (<resData> block) – in a SUCCESS message


completion of a Renew Domain Request:

Figure 16: <resData> block in Server's response to Renew Domain Request

Legend:

• <domain:renData> … </domain:renData>

Information on the renewal of the Domain Name

Record, where:


Specifies the Domain Name Record

renewed.

o <domain:expDate>…</domain:expDate>

Specifies the expiry time of the Domain

Name, in XML dateTime format.




xmlns:isocil="http://www.isoc.org.il/xml/epp/isocil-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0


1.0.xsdhttp://www.isoc.org.il/xml/epp/isocil-1.0"> <response>

<result code="1000">

<msg>Command completed successfully (domain requestid=D202742)</msg> </result>

<resData>

<domain:renData> <domain:name>example.co.il</domain:name>

<domain:expDate>2008-11-03T10:59:44.000Z</domain:expDate>

</domain:renData>

</resData>

<trID>



</trID>

</response> </epp>


of 89

6.6. Transfer Domain

(a) Purpose

Transfer the management of a Domain Name Record

from the current Managing AR to another Managing

AR.

(b) Authority

A Transfer Domain Request MUST be submitted by the

AR acquiring the management of the Domain Name

Record ("Acquiring AR").

(c) Prerequisite Conditions

1. The Transfer Request can only be submitted with regard to Domain Names Records whose Lock

Transfer (see sec. 6.1(h)) status is "false".

An attempt to submit a Transfer request against

a Domain Name Record with Lock Transfer status

"true" will result in an error indicating that

the Domain Name is locked for Transfer.

The Lock Transfer status of a Domain Name

Record can be changed by the Managing AR.

2. The Transfer Domain Request can only refer to existing Contact Objects managed by the

Acquiring AR.

Where necessary, the Acquiring AR needs to

create Contact Object in-advance, prior to

submitting a Transfer Domain Request, using the

Create Contact (see sec 7.1).

(d) Managing AR's Consent

The completion of a Transfer Domain Request is

subject to the Managing AR's consent. Upon the

submission of a Transfer Request by the Acquiring

AR, the Managing AR will be notified of the request

(Please refer to Mail Message no. 2 in Appendix B),

and be required to respond to it, within 5 days.

Lack of response within this time-frame, will be

considered as consent.

The notification is sent to the AR Main Regular

Mail Address.


of 89

(e) Code Examples

Figure 17: Transfer Domain Request

Legend:

• <domain:transfer> ... </domain:transfer>:


Reassign a Domain, where:


Defines the Domain Name to be

trasnferred.



• <domain:contact type="…">[Valid

Handle]</domain:contact>

Defines the Contacts for the Domain Name

under the management of the Acquiring AR,

where.

o <… type="…">

� Defines the Contact's Role:

Admin, Tech or Zone.

o The Handle between the tags MUST be a

Handle managed by the Acquiring AR.

• <clTRID> … </clTRID>

Acquiring AR's transaction identifier.













<command>

<transfer op="request">

<domain:transfer>


</domain:transfer>

</transfer>

<extension>

<isocil:ext>

<isocil:transfer>

<isocil:domain>

<domain:contact type="admin">BL-BL3612-IL</domain:contact>

<domain:contact type="tech">BL-BL3612-IL</domain:contact>

<domain:contact type="zone">BL-BL3612-IL</domain:contact>

</isocil:domain>

</isocil:transfer>

</isocil:ext>

</extension>


</command>

</epp>


of 89

Figure 18: Managing AR's Response to Transfer Request

Legend:

• <transfer> ... </transfer>:


is response to a Transfer Domain, where:

o <...op="reject">

Indicates Managing AR's response to the

Transfer Request.

o The string "reject" means objection.

o The string "approve" means consent.

The circumstances in which the Managing AR

is allowed to object to a Transfer Request

are outside the scope of this document.

• <extension>...</extension>


o <domainrequest:id> …

</domainrequest:id>

� The ID Request of the Transfer,

as indicated in the message sent

by the REG-REG server to the

Managing AR.


Managing AR's transaction identifier.





xmlns:dnsbe="http://www.isoc.org.il/xml/epp/isocil-1.0"

xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0

epp-1.0.xsd

urn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsd

http://www.isoc.org.il/xml/epp/isocil-1.0

isocil-1.0.xsd">

<command>

<transfer op="reject">

<domain:transfer>


</domain:transfer>

</transfer>

<extension>

<isocil:ext>

<isocil:transfer>

<isocil:domain>

<domainrequest:id>202108</domainrequest:id>

</isocil:domain>

</isocil:transfer>

</isocil:ext>

</extension>


</command>

</epp>


of 89

(f) Tags occurrence table

Transfer Domain Request


Size+ remarks

<epp> 1

<command> 1

<transfer op="request>

1

<domain:transfer> 1


<extension> 1

<isocil:ext> 1

<isocil:transfer> 1

<isocil:domain> 1


1


1


1


Managing AR Response


Size+ remarks

<epp> 1

<command> 1

<transfer op=[String]>

1

String to be replaced with "approve" or "reject" as necessary.

<domain:transfer> 1

<domain:name> 1

<extension> 1

<isocil:ext> 1

<isocil:transfer> 1

<isocil:domain> 1

<domainrequest:id> 1



of 89

(g) Additional Response Data (<resData> block) – in a SUCCESS message


completion of a Transfer Domain Request:

Figure 19: <resData> block in Server's response to Transfer

Domain Request

Legend:

• <contact:trnData> … </contact:trnData>

Information on the transfer of the Domain

Name Record, where:


Specifies the Domain Name trasnferred.

o <domain:trStatus>…</domain:trStatus>

Specifies the status of the transfer

request.

o <domain:acID>…</domain:acID>

Name of Acquiring Registrar.

o <domain:reID>…</domain:reID>

Name of former Managing Registrar






xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-

1.0.xsdurn:ietf:params:xml:ns:contact-1.0 contact-1.0.xsdurn:ietf:params:xml:ns:domain-

1.0 domain-1.0.xsdhttp://www.isoc.org.il/xml/epp/isocil-1.0">

<response>

<result code="1000"> <msg>Command completed successfully (domain requestid=D204137)</msg>

</result>

<resData> <domain:trnData>


<domain:trStatus>approved</domain:trStatus> <domain:acID>Registrar 1</domain:acID>

<domain:reID>Registrar 2</domain:reID>

</domain:trnData>

</resData>

<trID>



</trID>

</response> </epp>


of 89

7. Registration Actions – Operations on Contact Objects

7.1. Create Contact

(a) Purpose

Create a Contact Object.

(b) Authority

A Create Contact Request can be submitted by any

AR.

(c) Result

A Contact Object will be created under the

management of the AR submitting the request.

A Handle will be automatically allocated to the

Contact Object by the REG-REG Server, and will be

included in the response sent by the REG-REG

Server.

(d) Code Example

Figure 20: Create Contact Request









<command>

<create>

<contact:create>




<contact:addr>


<contact:city>Ramat Gan</contact:city>


<contact:pc></contact:pc>


</contact:addr>





</contact:create>

</create>

<extension>

<isocil:ext>

<isocil:create>

<isocil:contact>

<isocil:type>domain</isocil:type>

</isocil:contact>

</isocil:create>

</isocil:ext>

</extension>


</command>

</epp>


of 89

Legend:

• <contact:create> ... </contact:create>:


create a Contact Object, where:

o <contact:postalinfo> …

</contact:postalinfo>

Contact's postal information.














Contact:


t>




Contact's city.










following format:


number]"



following format:


number]"




Defines the IL Extension Block. The whole

block as appears in example MUST be a part of

the Request.



(e) Additional Response Data (<resData> block) – in a SUCCESS message


completion of a Create Contact Request:


of 89

Figure 21: <resData> block in Server's response to a Create

Contact Request

Legend:

• <contact:creData> … </contact:creData>

Information on the creation of the Contact

Object, where:

o <contact:id>…</contact:id>

Specifies the Contact's Handle.

o <contact:creDate>…</contact:creDate>

Specifies the creation time of the

Contact Object, in XML dateTime format.



xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xmlns:isocil="http://www.isoc.org.il/xml/epp/isocil-1.0" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0


1.0.xsdhttp://www.isoc.org.il/xml/epp/isocil-1.0"> <response>


<msg>Command completed successfully (contact requestid=C82)</msg> </result>

<resData>

<contact:creData>

<contact:id>SS-AM11639-IL</contact:id>

<contact:crDate>2005-10-31 11:25:00.000</contact:crDate> </contact:creData>

</resData>

<trID>

<clTRID>SS-5</clTRID>

<svTRID>ISOCIL-SS37 20051031112800</svTRID>

</trID>

</response>

</epp>


of 89

7.2. Update Contact

(a) Purpose

Update details of an existing Contact Object.

(b) Authority

Only the Managing AR can update Contact Objects

under his management.

(c) Scope

The Contact Object's name field CANNOT be updated

with Update Contact. If the Contact's name requires

modification, a new Object needs to be created,

using the Create Contact Request (See sec. 7.1).

Attempting to update the Contact's name field with

an Update Contact Request will result in an error.

(d) Result

The information included in the Update Contact

Request will override any existing information.

IMPORTANT: all sub tags of the Contact information

block must be included in the Request. Information

that needs not be updated, needs to be explicitly

included in the Request and contain the Contact's

current data.

(e) Code Example

Figure 22: Update Contact Request









<command>

<update>

<contact:update>

<contact:id>BL-BL3612-IL</contact:id>

<contact:chg>



<contact:addr>

<contact:street>Moshe Levy 11</contact:street>

<contact:city>Tel Aviv</contact:city>




</contact:addr>




</contact:chg>

</contact:update>

</update>


</command>

</epp>


of 89

Legend:

• <contact:update> ... </contact:update>:


create a Contact Object, where:

o <contact:id> ... </contact:id>

The Handle of the Contact Object being

updated.

o <contact:postalinfo> …

</contact:postalinfo>

Contact's postal Info.


Contains the Contact's full name. The

name MUST BE IDENTICAL to the Contact's

existing name. Any deviation will be

interpreted as an attempt to modify the

name field and will result in an error.






Contact:


t>




Contact's city.










following format:


number]"



following format:


number]"



• AR's transaction identifier.


of 89

7.3. Delete Contact

(a) Purpose

Delete a Contact Object.

(b) Authority

Only the Managing AR can delete Contact Objects

under his management.

(c) Condition for deletion

Only Contact Objects that are not included in any

Domain Name Record ("orphans") can be deleted.

Attempting to delete a Contact Object that is

included in at least one Domain Name Record will

result in an error.

(d) Result

Upon a successful deletion of a Contact Object can

not be used in any subsequent request. The deleted

Contact Object can not be restored.

(e) Code Example

Figure 23: Delete Contact Request

Legend:

• <contact:delete> ... </contact:delete>:


delete a Contact Object, where:

o <contact:id>

The deleted Contact's Handle.

o <clTRID>










<command> <delete>

<contact:delete>

<contact:id>AB-SS15177-IL</contact:id> </contact:delete>

</delete>

<clTRID>AB-123010</clTRID> </command>

</epp>


of 89

8. Information and General Purpose Operations

8.1. Cancel Request

(a) Purpose

Withdraw a Request submitted by an AR.

(b) Purpose

A Cancel Request can only be submitted by the AR

who submitted the Request.

(c) Scope

Only Requests whose processing has not started can

be canceled.

Since the initiation of the processing is not

controlled by the AR, the successful cancellation

of a Request is not guaranteed, and is done on a

BEST EFFORT basis.

If the Cancel Request operation is denied, the AR,

in order to undo the change, will be required to

submit a correcting Registration Action as

necessary. For example, if the AR tried to cancel

an Update Domain Request – another Update Domain

Request will need to be submitted in order to

reinstate the previous information.

(d) Code Example

Figure 24: Cancel Request

Legend:

• <domainreqeust:delete> ...

</domainreqeust:delete>:


Cancel Request, where:

o <domainrequest:id> ...

</domainreqeust:id>

The Request ID of the Request, the

cancellation of which is requested.













<command>

<delete>

<domainrequest:delete>

<domainrequest:id>202107</domainrequest:id>

</domainrequest:delete> </delete>


</command> </epp>


of 89

8.2. Info Domain

(a) Purpose

Retrieve complete WHOIS information on a Domain

Name Record.

(b) Authority

An Info Domain Request can be submitted by any AR.

(c) Code Example

Figure 25: Info Domain Request

Legend:

• <info> ... </info>:


is an information retrieval action, where:

o <domain:info> ... </domain:info>

defines that the requested information

if on a Domain Name Record.

o <domain:name>...</domain:name>

Defines the queried Domain Name Record.


AR's transaction identifier

(d) Tag Occurannce Table


Size+ remarks

<epp> 1

<command> 1

<info> 1

<domain:info> 1


<clTRID> 1 token: 3-64













<command>

<info>

<domain:info>

<domain:name>example.org.il</domain:name>

</domain:info>

</info>

<clTRID>SS-5</clTRID>

</command>

</epp>


of 89

(e) Additional Response Data (<resData> block)


completion of an Info Domain Request:

Figure 26: <resData> block in Server's response to a Info

Domain Request


<epp xmlns="urn:ietf:params:xml:ns:epp-1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instanc" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"



xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdurn:ietf:params:xml:ns:contact-1.0

contact-1.0.xsdurn:ietf:params:xml:ns:domain-1.0 domain-


<response>


<msg>Command completed successfully</msg>

</result>

<resData>

<domain:infData>


<domain:contact type="admin">BB-BL1-IL</domain:contact>

<domain:contact type="tech">BB-BL1-IL</domain:contact>

<domain:contact type="zone">BB-BL1-IL</domain:contact>

<domain:ns>

<domain:hostAttr>

<domain:hostName />

<domain:hostAddr />

</domain:hostAttr>

(...)

<domain:hostAttr>

<domain:hostName />

<domain:hostAddr />

</domain:hostAttr>

</domain:ns>

<domain:transferlocked>false</domain:transferlocked>

<domain:clID>BB</domain:clID>

<domain:crID>BB</domain:crID>

<domain:crDate>2006-02-26T11:39:37.000Z</domain:crDate>

<domain:upID>BB</domain:upID>

<domain:upDate>2006-02-26T11:39:37.000Z</domain:upDate>

<domain:exDate>2008-02-26T23:59:59.000Z</domain:exDate>

</domain:infData>

</resData>

<extension>

<isocil:ext>

<isocil:infData>

<isocil:contact>

<isocil:type>registrant</isocil:type>

<contact:postalInfo type="loc">


<contact:org />

<contact:addr>

<contact:street>7 Jabotinsky</contact:street>

<contact:city>Ramat Gab</contact:city>


</contact:addr>





<contact:crID>BB</contact:crID>

<contact:upDate>2006-02-26T11:39:37.000Z</contact:upDate>

<contact:crDate>2006-02-26T11:39:37.000Z</contact:crDate>

</isocil:contact>

</isocil:infData>

</isocil:ext>

</extension>

<resData />

<trID>

<clTRID>BB-120</clTRID>

<svTRID>ISOCIL-BB73 20060306155310</svTRID>

</trID>

</response>

</epp>


of 89

Legend:

• <response> … </response>

The response block, where:

o <resData>…</resData>

Standard EPP block.

o <extension>…</extension>

ISOC-IL extension block.

• <domain:infData> … </domain:infData>

Data on the Domain Name Record where:

o <domain:name>

The Domain Name

o <domain:contact>

The Handles of the contacts listed for

the Domain Name Record. Contact's Role

is identified by the "type" attribute.

o <domain:ns>

DNS servers block (up to 13 DNS

servers).

o <domain:trasnferlocked>

Indicates the Lock Trasnfer status of

the Domain Name Record (either 'true'

or 'false').


of 89

8.3. Info Contact

(a) Purpose

Retrieve information on a Contact Object.

(b) Authority

An Info Contact Request can be submitted only by

Managing AR of the Contact Object.

(c) Code Example

Figure 27: Info Contact Request

Legend:

• <info> ... </info>:



o <contact:info> ... </contact:info>


if on a Contact Object.


Defines the queried Contact Object.



(d) Tag Occurannce Table


Size+ remarks

<epp> 1

<command> 1

<info> 1

<contact:info> 1

<contact:id> 1 Valid Handle

<clTRID> 1 token: 4-64









<command>

<info>

<contact:info>

<contact:id>AB-SR5933-IL</contact:id>

</contact:info>

</info>


</command>

</epp>


of 89

(e) Additional Response Data (<resData> block)


completion of an Info Contact Request:

Figure 28: <resData> block in Server's response to Info

Contact Request

Legend:

• <contact:infData> … </contact:infData>

The block containing the information on the

Contact Object, where:

o <contact:id>…</contact:id>

The Contact Object's Handle.

o <contact:postalInfo>…</contact:postalIn

fo>

Contains the Contact Object's postal

information.

o <contact:voice>…</contact:voice>

Contact's telephone number.

o <contact:fax>…</contact:fax>

Contact's fax number.

o <contact:email>…</contact:email>

Contact's email address.





xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 epp-1.0.xsdurn:ietf:params:xml:ns:contact-1.0

contact-1.0.xsdurn:ietf:params:xml:ns:domain-1.0 domain-1.0.xsdhttp://www.isoc.org.il/xml/epp/isocil-

1.0">

<response>


<msg>Command completed successfully</msg>

</result>

<resData> <contact:infData>

<contact:id>AB-SR5933-IL</contact:id>

<contact:postalInfo type="loc"> <contact:name>John Doe</contact:name>

<contact:org />

<contact:addr>

<contact:street>Moshe Levi 34</contact:street>

<contact:city>Rishon Lezion</contact:city>


</contact:addr>





<contact:crID>AB</contact:crID> <contact:upDate>2006-01-23T16:14:46.000Z</contact:upDate>

<contact:crDate>2006-01-23T16:14:46.000Z</contact:crDate>

</contact:infData> </resData>

<trID>



</trID>

</response>

</epp>


of 89

o <contact:crID>…</contact:crID>

Initials of the AR who created the

Contact.

o <contact:upDate>…</contact:upDate>

Last update of the Object.

o <contact:crDate>…</contact:crDate>

Date of .

o <trID> … </trID>

Transaction Identifier.


of 89

8.4. Check Domain

(a) Purpose

Check whether a Domain Name is registered. The

request may include up to 10 Domains.

(b) Authority

The request may be submitted by any AR.

(c) Result

The reply from the REG-REG server will only

indicate whether the Domain Name Record is

registered without providing additional

information.

(d) Code Example

Figure 29: Check Domain Request

Legend:

• <check> ... </check>:



o <domain:check> ... </domain:cjeck>


if on a Domain Name Record.

o <domain:name>...</domain:name>

Defines the queried Domain Name Record.















<command>

<check>

<domain:check>

<domain:name>airforce2.co.il</domain:name>

</domain:check>

<domain:check>

<domain:name>achi.co.il</domain:name>

</domain:check>

</check>


</command>

</epp>


of 89

(e) Tag Occurannce Table


Size+ remarks

<epp> 1

<command> 1

<check> 1

<domain:info> 1

<domain:name> 1-10 Token: 9-73.

<clTRID> 1 Token: 3-64

(f) Response Example

Figure 30: <resData> block in Server's response to Check

Domain Request

Legend:

• <result> ... </result>:

Indicates the processing status of the

request.

• <resData> ... </resData>

The data sent in response to the specific

Request:

o <domain:cd>...</domain:cd>

Information unit on a Domain name

� <domain:name avail="0">

Indicates that the Domain Name is

not available for registration.



xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"


xmlns:dnsbe="http://www.dns.be/xml/epp/dnsbe-1.0"

xmlns:nsgroup="http://www.dns.be/xml/epp/nsgroup-1.0"

xmlns:agent="http://www.dns.be/xml/epp/agent-1.0"




http://www.isoc.org.il/xml/epp/isocil-1.0 dnsbe-1.0.xsd

<response>


<msg>Command completed successfully</msg> </result>

<resData>

<domain:chkData> <domain:cd>

<domain:name avail=”1”>airforce.co.il</domain:name>

</domain:cd>

<domain:cd>

<domain:name avail=”0”>achi.co.il</domain:name>

</domain:cd>

</domain:chkData>

</resData>

<trID>



</trID> </response>

</epp>


of 89

� <domain:name avail="1">

Indicates that the Domain Name is

available for registration.

• <trID> … </trID>

Unique transaction identifier.

o <clTRID> ...</clTRID>


o <svTRID>...</svTRID>

REG-REG Server transaction identifier.



of 89

9. Information Retrieval Interface ("IRI")

The following is a general description of the Information

Retrieval Interface ("IRI") provided by the Registry.

The information provided by the IRI is real-time information.

9.1. Access

The IRI is accessed by HTTP – at the following URL:

http://iri.isoc.org.il/.

Access to the IRI is allowed only from IP addresses pre-

registered with the Registry in advance.

9.2. Login Page

Upon accessing the above URL, the following screen will

appear:

Figure 31: IRI screen - Login Page

Where:

- "Registrar Code": the AR Code.

- "User Login" and "Password": Please refer to the

following section on User Management.

9.3. Users Management

At the Registry, a single principal user is defined for

each AR.


of 89

This user has the authority to independently manage

additional IRI users as needed.

The principal user's user name is managed at Registry

level. An initial password is also allocated by the

Registry. This password can be independently managed by

the user.

9.4. Main Page

Following a successful login, IRI's main page will

appear:

Figure 32: IRI screen - main page

Where:

- "Currently available credit …":

Indicates current amount available for submission of

additional Registration Actions, expressed in

Registration Units.

- "Credit assigned to pending request":

Indicates the amount deducted from the available

credit and has been allocated to Registration Actions

that are pending for processing, expressed in

Registration Units. Where a Registration Action is

denied, the credit assigned to it will 'return' to

the available credit.


of 89

- "Requests in Process":

indicates the number and type of Registration Actions

that have been submitted and are pending processing.

- "(a) Queries":

the main tool to query Domain Name Records, Contact

Objects and status of Registration Actions:

o "WHOIS Query": perform a WHOIS query of a specific Domain Name

Record or Contact Object. This is the general

WHOIS utility. Any Domain Name Record can be

queried, not only such that are managed by the AR.

This option will lead to the screen described in

sec 9.5.

o "Domains managed by [AR Name]": Query Domain Name Records managed by the AR. This

option will lead to the screen described in sec

9.6.

o "Contacts managed by [AR Name]": Query Contact Objects managed by the AR. This

option will lead to the screen described in sec

9.7.

o "Query Domain Requests": Query the status of Registration Actions

pertaining to Domain Name Records. This option

will lead to the screen described in sec 9.8.

o "Query Contact Requests": Query the status of Registration Actions

pertaining to Contact Objects. This option will

lead to the screen described in sec 9.9.

- "Credit Log":

See a complete history of AR's credit purchases. This

option will lead to the screen described in sec 9.10.

- "Purchase Credit:

Submit a request to purchase credit. This option will

lead to the screen described in sec 9.11.

- "Manage Password"

Manage the password of the current IRI user. This

option will lead to the screen described in sec 9.12.

- "Manage Authorized Users for this system"

This option is available only to the principal user

registered at the Registry. It is used to manage IRI

sub-users. This option will lead to the screen

described in sec 9.13.

- "Number of Domains":

Indicates the number of Domain Name Records currently

managed by the AR – with SLD breakdown, and total

number.


of 89

- "Log Off":

Exit the IRI system and return to the Login Page.

- Upper Navigation Menu:

Allows for quick navigation between the different

options. This menu appears in all screens.


of 89

9.5. WHOIS Query

Figure 33: IRI screen - WHOIS

Perform a standard WHOIS query on a specific Domain Name

or Contact Object.

To query a Domain Name, type a full 3rd level .il name,

e.g., "sample.co.il". To query a Contact Object, type the

Contact's Handle, e.g, "BL-AB1-IL".

No wildcards allowed in this query.

- "Back":

Return to Main screen.


of 89

9.6. Query Domain Names managed by an AR

Figure 34: IRI screen - query Domain Names

The results of the query will be only Domain Name Records

that match the search criterion entered, and are managed

by the AR.

Only one criterion should be used per query:

- "Domain Name":

A string representing a Domain Name or part of it.

The character '*' may be used as wildcard. For

example, to search for the AR's Domain Names that

start with an 'a', type: "a*".

- "Registration Period Between"; "Expiry Period

Between"; "Date of Management Between":

Dates MUST be entered in dd/MM/YYYY format.

- "Sort by":

Controls the order in which results are presented.

- "Export Table":

Export the table to a Comma Separated Values file

(.csv).


of 89

- "Submit Query":

If no query criterion is entered, all Domain Names

managed by the AR will be displayed.

- "Back":



of 89

9.7. Query Contacts Managed by an AR

Figure 35: IRI screen - query Contacts

- "Handle":

Enter a complete or part of a Handle. The character

'*' may be used as wildcard. For example, to search

for the AR's Contact whose handle starts with an 'a',

type: "[AR Code]-a*".

- "Name":

Search a Contact by name. The character '*' may be

used as wildcard. For example, to search for the AR's

Contact whose name starts with an 'a', type: "a*".

- "With Related Domain Names":

This option should be marked if the query is for

Handles that are currently registered as a Contact in

at least one Domain Name Record.

- "Only Orphan Contacts":

This option should be marked if the query is for

Handles that currently do not appear as a Contact in

any Domain Name Record.

- "Export Table":


(.csv).


of 89

- "Submit Query":



- "Back":



of 89

9.8. Query status of requests pertaining to Domain Name Records

Figure 36: IRI screen - query Domain Name requests

- "Request ID":

Locate a specific Registration Action by its Request

ID number.

- "Request Type":

A combo which allows querying for a specific type of

Registration Action (Create Domain, Update Domain,

Reassign Domain, Delete Domain, Renew Domain,

Transfer Domain).

- "Domain Name":

A string representing a Domain Name or part of it.

The character '*' may be used as wildcard. For

example, to search for the AR's Domain Names that

start with an 'a', type: "a*".

- "Submitted between", "End of process":


- "Request Status":

Possible statuses are:


of 89

o "Received" – the Registration Action had been received at the REG-REG server.

o "In Process" – the Registration Action is currently in one of the processing stages (for example, a

Transfer request waiting for the Managing AR's

response.

o "Approved" – the Registration Action was successfully processed, as requested.

o "Denied" – the Registration Action has not been processed and was denied.

- "Export Table":


(.csv).

- "Submit Query":



- "Back":


- Search criteria can be combined to make complex

queries, for example, query all Create Domain

requests submitted between date X to date Y, and

approved between date A and date B will involve 4

search criteria: Request Type (Create Domain),

Submitted Between, End of Process, and Status

(Approved).


of 89

9.9. Query status of requests pertaining to Contact Object

Figure 37: IRI screen - query Contact requests

- "Request ID":

Locate a specific Registration Action by its svTRID

number (excluding the "isocil-" and timestamp

strings) – in "isocil-12345 [timestamp]" the request

ID is the string "12345".

- "Request Type":

A combo which allows querying for a specific type of

Registration Action (Create Contact, Update Contact).

- "Contact Handle":

Enter a complete or part of a Handle. The character

'*' may be used as wildcard. For example, to search

for the AR's Contact whose handle starts with an 'a',

type: "[AR Code]-a*".

- "Submitted between", "End of process":


- "Request Status":

Possible statuses are:

o "Received" – the Registration Action had been received at the REG-REG server.


of 89

o "In Process" – the Registration Action is currently in one of the processing stages (for example, a

Transfer request waiting for the Managing AR's

response.

o "Approved" – the Registration Action was successfully processed, as requested.

o "Denied" – the Registration Action has not been processed and was denied.

- "Export Table":


(.csv).

- "Submit Query":



- "Back":


- Search criteria can be combined to make complex

queries, for example, query all Create Contact

requests submitted between date X to date Y, and

approved between date A and date B will involve 4

search criteria: Request Type (Create Contact),

Submitted Between, End of Process, and Status

(Approved).


of 89

9.10. Credit Log

Figure 38: IRI screen - Credit Log

This screen displays the history of credit purchases of

the AR.

- "Back":

To back to previous page.

- "Main Menu:"

Back to Main screen.


of 89

9.11. Purchase Credit

Figure 39: IRI screen - submit credit request

This is screen is used to submit a request to purchase

credit. The details entered in this screen will be used

to send a Pro-forma Invoice to the AR, for payment vis-à-

vis ISOC-IL's accounting department.

- "Amount":

The amount of Registration Units with regard to which

the invoice will be issued, (a drop-down menu).

- "Email":

The Email address to which the Pro-forma invoice will

be sent.

- "Remarks":

When necessary, add remarks to the attention of ISOC-

IL's accounting, in free text.

- "Process":

Submit the request.

- "Back":


Upon submitting the request, the following Pro-forma

invoice will be sent to email address specified:


of 89

Figure 40: Pro-forma


of 89

9.12. Manage Password

Figure 41: IRI screen - manage password

In this screen the IRI user can manage his/her password.

Management of user name is done at Registry level, in

case of the principal user, and at principal user level

in case of a sub-user.

- "Old Password":

The password that was used to enter the current IRI

session.

- "New Password", "Retype New Password":

Password MUST be at least 6 chars long.


of 89

9.13. Manage IRI Authorized Users

Figure 42: IRI screen - manage IRI users

This option is only accessible to the AR Principal User.

It allows for the management of the IRI users.

An IRI user can be "Active", "Locked" (i.e., an active

user temporarily blocked from accessing the IRI system).

The "Not Active" indicates a user that is permanently

blocked from accessing the IRI.

- "Add new user":

Use this option to add new IRI users to the system.

It will lead to the following screen


of 89

Figure 43: IRI screen - add IRI user

- "Name":

The new IRI user regular name (given name and

surname).

- "Active": the user can access the IRI.

- "Locked": an active user that is temporarily blocked

from accessing the IRI.

- "User Name (login)":

The new IRI user's login name, MUST be at least 4

characters long.

- "Password", "Retype Password":

Password MUST be at least 6 characters long.

- "Save":

The information MUST be saved prior to exiting the

screen, otherwise the new user will not be created.


of 89

10. Testbed Information

10.1. How to register

Send mail to: [email protected]

Subject Line: Testbed Registration Request.

Provide the following information:

(1) Testing Organization Name.

(2) Full name of contact person.

(3) Postal Address.

(4) Phone Number.

(5) Fax Number.

(6) AR Main EPP Mail Address

(7) AR Main EPP Regular Address

The applicant will be invited to ISOC-IL's offices, for

the purpose of exchanging PGP keys.

The applicant should bring to the meeting his/her

personal ID, his/her public key (only) on media, and

their PGP key ID.

The following corporate documents will be also required::

(1) Incorporation certificate (or a validated copy).

(2) Formal minutes of the corporate including:

a. A resolution to register to the test-bed.

b. Warranty that signing with the PGP key

(identified by the PGP ID) is an obliging

signature of the corporate.

c. Nomination of the person arriving to ISOC-IL's

offices as the corporate's representative for

the exchange of keys, including the

representative's identification information.

(3) Power of attorney to the representative.

10.2. Testbed URLs and addresses

Testbed REG-REG Server mail address:

[email protected]

10.3. Registry behavior simulation in testbed environment

The testbed environment is intended to provide the

testers with a tool to technically test the Clients.

In the 'real world' system, the processing of some of the

requests on the Registry's side, involves manual

handling. In such cases, the testbed system randomly

decides whether to approve or reject the request (one

request is approved the next one is denied, and so on).

Note that the randomization occurs only in requests that

are processed manually. In such cases, and additional

"Message Error ID" will be included (please refer to sec.


of 89

4.3(f)). The error message id in the testbed will always

be 400. The message id refers to denial grounds that are

outside the scope of this document (the reasons for

denial being non-technical in nature).


of 89

APPENDIX A – REG-REG Response Codes

Code Text between <msg> … </msg>

1000 Command completed successfully

1001 Submission completed successfully

2000 Unknown command

2005 Parameter value syntax error

2105 Object is not eligible for renewal

2201 Authorization error

2302 Object exists

3001 File contents do not match signature

3002 No pgp signature or file is corrupted

3003 Registrar account not active

3004 Unrecognized Regsitrar

3005 Invalid tag

3006 XML document does not match schema

3007 Invalid Domain Name

3008 TLD/SLD not supported

3009 Iinvalid characters in Domain Name

3010 Domain Name too long

3011 Nonexistent Domain Name

3012 Domain Name not managed by requesting registrar

3013 Insufficient credit for submission of request

3014 Domain Name not allowed

3015 Request has been already submitted

3016 Domain name is not yet up for renewal

3017 Domain Name is already registered

3018 Contact type must either registrant or domain

3019 Invalid email address

3020 Invalid phone number

3021 Invalid postal info

3022 Invalid contact name

3023 Invalid organization name

3024 Postal info required

3025 Invalid street address

3026 Invalid state/city

3027 Invalid country code

3028 Invalid postal code

3029 Contact info required

3030 Contact handle required

3031 Invalid contact handle

3032 Contact handle not associated with requesting registrar

3033 Contact can not be deleted

3034 Domain name not specified

3035 Domain disabled, no requests allowed

3036 Contact does not exist

3037 XML syntax error

3038 Contact type (registrant/domain) must be specified

3039 Domain contact type can be only one of: admin/tech/zone

3040 All domain contacts must be specified: admin/tech/zone

3041 Domain registrant not specified

3042 Invalid contact reference, must be "NEW"

3043 Contact reference not specified in inline contact definition

3044 Registrant inline contact definition was specified more than once


of 89

3045 At leat two inline contact definitions have same reference names

3046 Domain contact handle contains an unreferenced label

3047 Contact handle and registrant must have different references

3048 Domain contact of same type defined more than once

3049 Registrant reference name in inline definition is not the same as

in domain definition

3050 Registrant handle/reference name is the same as domain contact

handle/reference name

3051 Domain contact handle/reference name is the same as registrant

handle/reference name

3052 Specified contact is in use

3053 Registrant handle is a reference, but its contact data is not

defined inline

3054 Registrant specified is already associated with another domain

3055 Registrant email required

3056 Domain contact email required

3057 Registrant name required

3058 Domain contact name required

3059 Registrant street address required

3060 Domain contact street address required

3061 DNS server IP address required for glue record

3062 Only DNS IP address specified, DNS name required

3063 Invalid DNS info

3064 DNS IP address invalid

3065 Duplicate DNS IP address

3066 Duplicate DNS name

3067 Unreferenced contact definition

3068 Registrant handle associated with a disabled Domain Name

3069 Contact status other than when request was submitted

3070 Invalid transfer operation. Valid values:

"approve","reject","request","query"

3071 Attempt to transfer domain to same registrar

3072 Specified domain already transferred to another registrar

3073 No data was found

3074 You are NOT permited to submit requests for the specified SLD

3075 You are NOT permitted to submit requests of this type

3076 The request type specified is not allowed for specially managed

SLDs

3077 Transfer request objected by Loosing Registrar

3078 Your objection to Transfer request was recorded

3079 Contact name can not be modified

3080 Contact address not specified

3081 Deadline for this operation is over

3082 Request denied

3083 Domain transferred.

3084 Domain transferred to ISOC IL

3085 <Domain Name> transferred

3086 <Domain Name> transferred

3087 Transfer request denied

3088 Transfer request for Your domain denied upon invalid transfer

operation

3089 Use Update Domain request to change registrant information

3090 Current domain registrar is not the same as when the request had

submitted

3091 Client transaction ID (clTRID) empty

3092 Illegal format of client transaction ID (clTRID)


of 89

3093 Contact request ID not specified

3094 illegal format of contact request ID

3095 Request already in process

3096 Non existent request

3097 Request cancelled upon request

3098 Request can no longer be cancelled

3099 Domain request ID not specified

3100 Illegal format of Domain Name request ID

3101 Transfer request aborted by requesting registrar

3102 Invalidated Authentication Info

3103 Illegal value of locktransfer flag

3104 Transfer operation for this domain is locked

3105 Domain not transferred as you locked the domain for transfer

3106 Up to 10 Domain Names may be included in a checkdomain request

3107 Maximum number DNS servers exceeded

3108 DNS Server IP Address is redundant

3109 Invalid registration period

3110 Domain registration period unit is invalid

3111 Domain registration period not specified

3112 Domain registration period specified is too long

3113 Requested renewal exceeds the allowed maximal registration period

3114 Domain revoked


of 89

APPENDIX B – Mail Messages

1) Notification on Credit below certain levels.

Subject: [ILREG] IMPORTANT: Credit Alert.

Mail Body:

Dear Registrar,

This is an automatic message.

Our records indicate that your current credit level for

new submissions is <SUM> NIS.

You may want to purchase additional credit to avoid

automatic rejection of requests due to lack of sufficient

credit.

NOTE: This message relates to available credit only, and

does not include credit assigned to requests that were

pending at the time this message was sent.

Sincerely,

ISOC-IL

The .il Registry

2) Notification to a Managing Registrar on a Transfer request

submitted to a Domain Name under its management

Subject: [ILREG] <Domain Name>: Transfer request submitted by <AR>

Mail Body:

Dear Registrar,

This is an automatic message.

A request to transfer the management of the Domain Name

<Domain Name>, from <Managing AR Name> to <Acquiring AR>

has been submitted to ISOC-IL by <Acquiring AR> (request

id=<Request ID>).

Please notify ISOC-IL of your response to the request

(AGREE/OBJECT), by sending the appropriate EPP form.

Sending an AGREE response will allow the Transfer

process to complete.

Sending an OBJECT response will move the request to

manual processing by ISOC-IL. Please consult the

Accreditation Agreement regarding grounds for objection.

Lack of response within <NUM> days from the date of this

message, will be automatically regarded as an agreement

to the Transfer.

For your convenience, we have attached below an XML

message you may send:



of 89


xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance"


xmlns:dnsbe="http://www.isoc.org.il/xml/epp/isocil-

1.0"

xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0

epp-1.0.xsd


http://www.isoc.org.il/xml/epp/isocil-1.0

isocil-1.0.xsd">

<command>

<transfer op="XXXXXX">

<domain:transfer>

<domain:name><DOMAIN NAME></domain:name>

</domain:transfer>

</transfer>

<extension>

<isocil:ext>

<isocil:transfer>

<isocil:domain>

<domainrequest:id><REQUEST ID></domainrequest:id>

</isocil:domain>

</isocil:transfer>

</isocil:ext>

</extension>

<clTRID>YYYYYY</clTRID>

</command>

</epp>

Please replace XXXXXX with either reject or approve and

replace YYYYYY with a client transaction ID in a valid

format.

Sincerely,

ISOC-IL

The .il Registry

3) Notification on Invalid Signature

Subject: [ILREG] ERROR: Invalid Signature

Mail Body:

The email message you sent to the .il ccTLD

registry, was not signed with a valid signature.

Sincerely,

ISOC-IL

The .il Registry


of 89

4) Notification on revocation of Domain Name

Subject: [EPPMail] NOTIFICATION: Domain Revoked <Domain

Name>, ISOCIL-<AR-Code><Serial Number>

Mail

Body:



xmlns:xsi="http://www.w3.org/2001/XMLSchema-instanc"

xmlns:contact="urn:ietf:param

s:xml:ns:contact-1.0"


xmlns:isocil="http://www.isoc.org.il/xml/epp/isocil-

1.0

" xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0

epp-1.0.xsdurn:ietf:params:xml:ns:contact-1.0

contact-1.0.xsdurn:ietf:par

ams:xml:ns:domain-1.0 domain-


<response>

<result>

<code>3114</code>

<msg>Domain revoked</msg>

</result>

<extension>

<isocil:ext>

<isocil:revokeInfo domainName="example.co.il" />

</isocil:ext>

</extension>

<trID>

<clTRID />

<svTRID>ISOCIL-[AR Code][serial number] [time

stamp]</svTRID>

</trID>

</response>

</epp>


of 89

APPENDIX C – Error Message IDs

Code Description

101 An attempt to modify the Holder information using the

Update Domain Request instead of a Reassign Domain

Request.

102 A Reassign Domain Request that must be authorized in

writing, by the current holder of the Domain Name.

Send a formal, written letter (in case of a company - on

company letterhead), quoting the Request ID and the

Domain Name. The letter must be signed by a properly

authorized official of the current holder of this Domain

Name.

103 An attempt to update the name and/or organization of the

Domain Name Holder.

Usually, such requests are considered to be a reassign

rather than update, so this request would normally have

been rejected. However, the old information and the new

information are apparently rather similar.

If you can represent that the old and new information both

refer to the same holder (i.e. exactly the same legal

entity),

please send such documentation to ISOC-IL. You can also

send

it by fax, to +972-3-6114095.

Please note that we will need formal documentation, on

formal

letterhead (where applicable) to approve such a

modification.

104 This Delete Domain Request that must be authorized in

writing, by the current holder of the Domain Name (only!).

Please send a formal, written letter (in case of a company

- on

company letterhead), quoting the request ID above

(important) and the

Domain Name being deleted. The letter must be signed by a

properly

authorized official of the current holder of this Domain

Name.

208 The Domain Name you asked for cannot be assigned. Please

see the

Domain Name Allocation Rules at

http://www.isoc.org.il/domains

and review clause 3.4).

400 Incomplete/Invalid Holder data.

401 Incomplete/Invalid Administrative Contact data.

700 Requested documentation not provided.

Request removed from work queues, without being processed.

701 Request cancelled, by specific request, from the applicant

and/or holder to ISOC-IL.


of 89

APPENDIX D – List of Figures

Description Page Figure 1: Domain Name Record Object 9 Figure 2: Contact Object 9 Figure 3: XML File: General Structure 11 Figure 4: REG-REG Client Request: General Structure 13 Figure 5: REG-REG Server Response: General Structure 14 Figure 6: REG-REG Server Response: <resData> tag 15 Figure 7: REG-REG Server Response: notification of successful submission 16 Figure 8: Relating an existing Contact Object in a Create Domain Request 17 Figure 9: Creating a new Contact Object within a Create Domain Request 17 Figure 10: Create Domain Request 17 Figure 11: <resData> block in Server's response to Create Domain Request 17 Figure 12: Update Domain Request 17 Figure 13: Delete Domain Request 17 Figure 14: Reassign Domain Request 17 Figure 15: Renew Domain Request 17 Figure 16: <resData> block in Server's response to Renew Domain Request 17 Figure 17: Transfer Domain Request 17 Figure 18: Managing AR's Response to Transfer Request 17 Figure 19: <resData> block in Server's response to Transfer Domain Request 17 Figure 20: Create Contact Request 17 Figure 21: <resData> block in Server's response to a Create Contact Request 17 Figure 22: Update Contact Request 17 Figure 23: Delete Contact Request 17 Figure 24: Cancel Request 17 Figure 25: Info Domain Request 17 Figure 26: <resData> block in Server's response to a Info Domain Request 17 Figure 27: Info Contact Request 17 Figure 28: <resData> block in Server's response to Info Contact Request 17 Figure 29: Check Domain Request 17 Figure 30: <resData> block in Server's response to Check Domain Request 17 Figure 31: IRI screen - Login Page 17 Figure 32: IRI screen - main page 17 Figure 33: IRI screen - WHOIS 17 Figure 34: IRI screen - query Domain Names 17 Figure 35: IRI screen - query Contacts 17 Figure 36: IRI screen - query Domain Name requests 17 Figure 37: IRI screen - query Contact requests 17 Figure 38: IRI screen - Credit Log 17 Figure 39: IRI screen - submit credit request 17 Figure 40: Pro-forma 17 Figure 41: IRI screen - manage password 17 Figure 42: IRI screen - manage IRI users 17 Figure 43: IRI screen - add IRI user 17

Registry-Registrar System (1.0) REFERENCE MANUAL (1.21)€¦ · WHOIS Query 17 9.6. Query Domain...

Documents

Transcript of Registry-Registrar System (1.0) REFERENCE MANUAL (1.21)€¦ · WHOIS Query 17 9.6. Query Domain...