Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000, and a web-‐based Directory Service at <whois.nic.TLD> providing free public query-‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry. 1.1. The format of responses shall follow a semi-‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database. 1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value. 1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together. 1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 1282 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000, and a web-‐based web-based Directory Service at <whois.nic.TLD> providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.. Query format: whois EXAMPLE.TLD
Appears in 815 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000RFC 3912, and a web-‐based Directory Service at <whois.nic.TLD> providing free public query-‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 372 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000RFC 3912, and a web-‐based web-based Directory Service at <whois.nic.TLD> providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.. Query format: whois EXAMPLE.TLD
Appears in 364 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000, and a web-‐based Directory Service at <whois.nic.TLD> providing free public query-‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 265 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000, and a web-‐based web-based Directory Service at <whois.nic.TLD> providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 74 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000RFC 3912, and a web-‐based Directory Service at <whois.nic.TLD> providing free public query-‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 70 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX RFC 0000, and xxd a web-‐based Directory Service at <whois.nic.TLD> providing free public query-‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 20 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX RFX 0000, and a web-‐based Directory Service at <whois.nic.TLD> providing free public query-‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 15 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000, and a web-‐based web‐based Directory Service at <whois.nic.TLD> providing free public query-‐based query‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 14 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000RFC 3912, and a web-‐based web-based Directory Service at <whois.nic.TLD> providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 13 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX RFC 0000, and xxd a web-‐based web-based Directory Service at <whois.nic.TLD> providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.. Query format: whois EXAMPLE.TLD
Appears in 11 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX RFX 0000, and a web-‐based Directory Service at <whois.nic.TLD> providing free public query-‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 9 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX RFX 0000, and a web-‐based web-based Directory Service at <whois.nic.TLD> providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.. Query format: whois EXAMPLE.TLD
Appears in 6 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000, and a web-‐based web-based Directory Service at <whois.nic.TLD> providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 4 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000RFC 3912 at xxxxx.xxxxxxxx.xxx, and a web-‐based web-based Directory Service at <whois.nic.TLD> xxx.xxxxxxxx.xxx/xxxxx providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 3 contracts
Samples: Registry Agreement (Verisign Inc/Ca), Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX RFC 0000, and xxd a web-‐based Directory Service at <whois.nic.TLD> providing free public query-‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 3 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000RFC 3912, and a web-‐based web‐based Directory Service at <whois.nic.TLD> providing free public query-‐based query‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty‐five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 3 contracts
Samples: Registry Agreement, Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000RFC 3912, and a web-‐based web-based Directory Service at <whois.nic.TLD> providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.. Domain Name Data: Query format: whois EXAMPLE.TLD Response format: Domain Name: EXAMPLE.TLD Domain ID: D1234567-TLD WHOIS Server: whois.example.tld Referral URL: xxxx://xxx.xxxxxxx.xxx Updated Date: 2009-05-29T20:13:00Z Creation Date: 2000-10-08T00:45:00Z Registry Expiry Date: 2010-10-08T00:44:59Z Sponsoring Registrar: EXAMPLE REGISTRAR LLC Sponsoring Registrar IANA ID: 5555555
Appears in 2 contracts
Samples: Registry Agreement, Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000RFC 3912 at xxxxx.xxxxxxxx.xxx, and a web-‐based web-based Directory Service at <whois.nic.TLD> xxx.xxxxxxxx.xxx/xxxxx providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.. Domain Name Data: Query format: whois EXAMPLE.TLD Response format: Domain Name: EXAMPLE.TLD Domain ID: D1234567-TLD WHOIS Server: whois.example.tld Referral URL: xxxx://xxx.xxxxxxx.xxx Updated Date: 2009-05-29T20:13:00Z Creation Date: 2000-10-08T00:45:00Z Registry Expiry Date: 2010-10-08T00:44:59Z Sponsoring Registrar: EXAMPLE REGISTRAR LLC Sponsoring Registrar IANA ID: 5555555
Appears in 1 contract
Samples: Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000, and a web-‐based Directory Service at <whois.nic.TLD> providing free public query-‐based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-‐ five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 1 contract
Samples: Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000RFC 3912, and a web-‐based web-based Directory Service at <whois.nic.TLD> providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
1.5. Domain Name Data:
1.5.1 Query format: whois EXAMPLE.TLD
1.5.2 Response format: Domain Name: EXAMPLE.TLD Domain ID: D1234567-TLD WHOIS Server: whois.example.tld Referral URL: xxxx://xxx.xxxxxxx.xxx Updated Date: 2009-05-29T20:13:00Z Creation Date: 2000-10-08T00:45:00Z Registry Expiry Date: 2010-10-08T00:44:59Z Sponsoring Registrar: EXAMPLE REGISTRAR LLC Sponsoring Registrar IANA ID: 5555555 Domain Status: clientDeleteProhibited Domain Status: clientRenewProhibited Domain Status: clientTransferProhibited Domain Status: serverUpdateProhibited Registrant ID: 5372808-ERL Registrant Name: EXAMPLE REGISTRANT Registrant Organization: EXAMPLE ORGANIZATION Registrant Street: 123 EXAMPLE STREET Registrant City: ANYTOWN Registrant State/Province: AP Registrant Postal Code: A1A1A1 Registrant Country: EX
Appears in 1 contract
Samples: Registry Agreement
Registration Data Directory Services. Until ICANN requires a different protocoldifferentprotocol, Registry Operator will operate a WHOIS service available via port 43 in accordance with XXX 0000, and a web-‐based web-based Directory Service at <whois.nic.TLD> providing free public query-‐based query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable. Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-‐five thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.
1.1. The format of responses shall follow a semi-‐free semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.2. Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.
1.3. For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.
1.4. The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.
Appears in 1 contract
Samples: Registry Agreement