[gtld-tech] gTLD RDAP Profile discussion at Yokohama

Francisco Arias francisco.arias at icann.org
Wed Nov 4 13:38:10 UTC 2015


Colleagues,

I’ve attached the slides from today’s (4-Nov) session on the gTLD RDAP
profile. Thank you all of you that attended either in person or remotely.
Please see below my notes and let me know if I missed or misrepresented
something.

We agreed to:

A.1 Change 1.3.2 to have HTTPS as a MUST and as requirement in the
bootstraping, but allow HTTP as optional
A.2 Clarify requirement in 2.8.3 re: bootstrapping and 1.3.6 re:
requirement for IPv4 and IPv6 transport
A.3 Change 1.4.1 to allow queries with mixed A-label and U-label IDNs
A.4 Remove requirements in 1.4.4 and 1.4.5 about blank spaces and newlines
A.5 Keep the requirement in 2.8.2 regarding caching or issue re: change of
the bootstrapping entry
A.6 Keep requirement in 1.3.4 to register RDAP extensions before using them
A.7 Keep requirement in 1.4.3 to maintain the case of the data as received
in EPP
A.8 Keep the "last update DB" item described in 1.4.12 as a new event type
A.9 Keep the requirement in 1.5.2 to include U-label format of IDN in
response
A.10 Fix requirements regarding thin registry's for fields to be included
in 1.5.8 and through the profile
A.11 Keep the requirement in 1.5.14 to show the registrar expiration date
A.12 Clarify language in 1.5.17 regarding requirement to show only
allocated variants
A.13 Keep requirement in section 1.5.18 to use a remarks member with title
"EPP Status Codes"
A.14 Clarify requirement in 1.5.19 regarding the secureDNS member to be
shown if stored by the registry or registrar
A.15 Remove the requirement for Boolean search capabilitiesout until there
is an RFC. Once there is an RFC, ICANN should be able to require
implementation using existing contractual mechanism (Francisco to confirm)
A.16 The behavior for responses for multiple host objects (section 2.3)
should be specified in a RDAP extension
A.17 Keep the re:related mechanism in section 2.4 for the registry to
refer to the registrar (no need to specify it in a RDAP extension)
A.18 Clarify text in 2.9.1 as requested
A.19 Have the EPP status "ok" mapped to "active" in the profile

We have the following open issues:

I.1 What requirements should be for the CA to be used in TLS or whether to
use DANE
I.2 Whether registrars that are queried for a name they don't sponsor
should respond with HTTP 404 as a MUST or have the option to redirect
(section 3.1.2)
I.3 Whether registrars have to implement a RDAP service
I.4 Whether to require implementation of differentiated access in RDAP for
registries


Other pending issues:

P.1. Francisco to check if we can already include the requirements from
the Translation & Transliteration PDP in the profile
P.2. Francisco to check on the timeline of the requirement for registrars
to provide the registrar expiration date to registries

P.3. Francisco to check if ICANN would be able to require implementation
of the Boolean search capabilities using existing contractual mechanism

Regards,

-- 
Francisco.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gTLD-RDAP-Profile-Yokohama-20151104.pdf
Type: application/pdf
Size: 1435657 bytes
Desc: gTLD-RDAP-Profile-Yokohama-20151104.pdf
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20151104/66983469/gTLD-RDAP-Profile-Yokohama-20151104-0001.pdf>


More information about the gtld-tech mailing list