At 16:05 15-07-2013, The IESG wrote:
The IESG has received a request from the Web Extensible Internet
Registration Data Service WG (weirds) to consider the following document:
- 'HTTP usage in the Registration Data Access Protocol (RDAP)'
<draft-ietf-weirds-using-http-07.txt> as Proposed Standard
The Abstract mentions that:
"This document is one of a collection that together describe the
Registration Data Access Protocol (RDAP). It describes how RDAP is
transported using the Hypertext Transfer Protocol (HTTP)."
In Section 2 it is mentioned that:
"RDAP query and response formats are described in other documents
in the collection of RDAP specifications, while this document
describes how RDAP clients and servers use HTTP to exchange
queries and responses."
I read the document and I did not find any other
information about collection of RDAP specifications.
According to Section 1:
"This document describes the usage of HTTP for Registration Data
Directory Services."
From Section 2:
"In accordance with [SAC-051], this document describes the base
behavior for a Registration Data Access Protocol (RDAP).
[SAC-051] describes a protocol profile of RDAP for Domain Name
Registries (DNRs), the Domain Name Registration Data
Access Protocol (DNRD-AP)."
The recommendation in SAC051 is to adopt the following terminology:
"Domain Name Registration Data Access Protocol (DNRD-AP).
The components of a (standard) communications exchangequeries
and responsesthat specify the access to DNRD"
I did not find any other information about the
Registration Data Access Protocol. It is weird
that the IETF is standardizing a collection of
documents which is undocumented. It is also
weird that the IETF is standardizing the
Registration Data Access Protocol when there
isn't any information about the said protocol
except for the terminology mentioned above.
From Section 1:
"A replacement protocol is expected to retain the simple transactional
nature of WHOIS, while providing a specification for queries and
responses, redirection to authoritative sources, support for
Internationalized Domain Names (IDNs, [RFC5890]), and support for
localized registration data such as addresses and organisation or
person names."
I read the draft again and I still did not know
what the replacement protocol is. I suggest
clarifying where the Registration Data Access
Protocol actually exists and where is it specified.
In Section 1:
"This is the basic usage pattern for this protocol:
1. A client issues an HTTP query using GET. As an example, a query
for the network registration 192.0.2.0 might be http://
example.com/ip/192.0.2.0.
2. If the receiving server has the information for the query, it
examines the Accept header field of the query and returns a 200
response with a response entity appropriate for the requested
format.
3. If the receiving server does not have the information for the
query but does have knowledge of where the information can be
found, it will return a redirection response (3xx) with the
Location: header field containing an HTTP(S) URL (Uniform
Resource Locator) pointing to the information or another server
known to have knowledge of the location of the information. The
client is expected to re-query using that HTTP URL.
4. If the receiving server does not have the information being
requested and does not have knowledge of where the information
can be found, it returns a 404 response.
5. If the receiving server will not answer a request for policy
reasons, it will return an error response (4xx) indicating the
reason for giving no answer."
The above is basically HTTP being given another
name. Section 3 of the draft says that:
"HTTP also benefits from widespread investment in scalability,
reliability, and performance, and widespread programmer understanding
of client behaviours for RESTful web services, reducing the cost to
deploy Registration Data Directory Services and clients."
It seems that someone decided to choose port 80
and then went to find the reasons for that
choice. Can I ask for some references for the
above? I am okay if I am told that I have to
believe that it is true because it is written in a RFC.
From Section 4.2:
"Servers MUST ignore unknown query parameters. Use of unknown query
parameters for cache-busting is described in Appendix B."
If I understood the requirement it is that the
servers must ignore unknown query parameters
while the draft documents usage of unknown query
parameters in Appendix B. This doesn't make sense to me.
From Section 5:
"While no standard HTTP response code is forbidden in usage, at a
minimum clients SHOULD understand the response codes described in
this section as they will be in common use by servers."
I don't understand the "SHOULD understand".
From the Security Considerations section:
"This document does not pose strong security requirements to the RDAP
protocol."
I read the about as meaning that the unspecified
RDAP protocol does not need strong security requirements.
"Additional security considerations to the RDAP protocol will be
covered in future RFCs documenting specific security mechanisms and
schemes."
I assumed that security considerations was about
considering security concerns and discussing
about them. The above leaves that to future RFCs.
In Section 9.1:
"Clients can use IRIs [RFC3987] for internal use as they see fit, but
MUST transform them to URIs [RFC3986] for interaction with RDAP
servers."
That means that servers do not support internationalization.
From Section 9.2:
"On the other hand, when servers return data and have knowledge
that the data is in a language or script, the data SHOULD be
annotated with language identifiers whenever they are available,
thus allowing clients to process and display the data accordingly.
The mechanism for including a language identifier in a response will
be defined in subsequent documents describing specific response
formats."
The approach adopted in this future Proposed
Standard is that everything will be defined in
some future document. This future Proposed
Standard is under-specified to the such an extent
that it would be extremely difficult to implement without insider information.
By the way, the RFC 4627 and RFC 5234 references should be normative.
Regards,
-sm