I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see ​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-ietf-weirds-using-http-07
Title:  HTTP usage in the Registration Data Access Protocol (RDAP)
Reviewer: Larry Masinter	
Review Date: 7/31/2013
IETF Last Call Date: [include if known]
IESG Telechat Date:  On agenda of 2013-08-15 IESG telechat
Summary:  The document needs quite a bit of editorial work, but the protocol itself seems OK, modulo a few questions.

Major Issues/Minor issues:   I think the document suffers enough editorial confusion that they rise to the level of "Major"

Please define what "Registration Data" is on first use.
Please define what "Registration Data Directory Services" are.
Please supply a reference for "RESTful"

Please explain what you mean by "better" in:
   "By giving the various Directory Services common
    behavior, a single client is better able to retrieve data from
    Directory Services adhering to this behavior."
Better how?

Please explain or give an example about what is insufficient in:
    "the WHOIS protocol is insufficient to
    modern registration data service requirements."


The sentence
 ” Where complexity may reside, it is the goal of this document..."
 is awkward, suggest just striking "Where complexity may
reside".


Please explain who "SSAC" is and why their opinion about WHOIS is relevant.
in " As is noted in SSAC Report ..."

Please give a reference for RDAP


Section 2 Terminology:
 "   In this document, an RDAP client is an HTTP User Agent performing an
    RDAP query, and an RDAP server is an HTTP server providing an RDAP
    response.  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  think you're defining a way of layering RDAP-like functionality using
HTTP instead of something lower level.  This doesn't seem like "terminology" --
this document defines a kind of RDAP client and a kind of RDAP server.

Section 3 "Design Intents"

Neither "design intents" or "design ctriteria" seems to fit
what you're talking about. "Design constraints"? "Design
considerations" ? Notable "design decisions" ?

I don't understand whether restricting responses to zero or one
result is a difficult or onerous constraint.

"First, each query is meant ..." Each RDAP query itself? In all RDAP
applications ever? If not, in what circumstances? Which RDAP
 queries have this constraint?

 Is it the "semantics" of the "request/response" that allows
 for future response formats? I think you're saying something
 about the protocol being extensible in the future to allow
 other formats than JSON.

Moving "including cache control, authorization, compression, and
 redirection" to after "HTTP offers a number of mechanisms" (surrounded by
 parentheses) will make the sentence clearer. 

However, I'm not convinced that you can avoid giving more
specific advice about how cache control, authorization, 
compression and redirection work with RDAP.  For example,
the cache-busting section indicates that cache control headers
aren't sufficient.

How will RDAP over HTTP work on a hotel network which redirects HTTP
requests each day at noon?

" an RDAP specific JSON media
   type, the generic JSON media type, or both."

Please be explicit  "application/json" for "the generic JSON media type"
and give an explicit example of  "an RDAP specific JSON media type"
and provide references where those are defined.

5.1 Positive Answers

can you be more explicit about what kind of response is expected?

Please address the use of HTTPS with TLS vs. HTTP.

I question the use of 404 Not Found to indicate "no information
regarding the query", since it doesn't distinguish between "no information"
and "wrong query".

Please be more explicit about "a RDAP-HTTP Server" rather than
"a server" in 5.3, 5.4 etc.

" Optionally, it MAY
   include additional information regarding the negative answer in the
   HTTP entity body."
how can this be used interoperably with such little specified?

I admit I am baffled by the Extensibility section 6, since I can't see
how it allows extensions.... for what? Under what cicumstances?
How do you distinguish between known and unknown extensions?

Section 7: Security Considerations
Normally, a security considerations section might outline threats
and mitigations for them. This section doesn't seem to.

Section 9.1 URIs and IRIs
This is confusing, of course clients can use whatever internally
they want.   

How is a "URI" used in a response? The response is RDAP information.

Transforming URIs to IRIs is a potentially buggy heuristic process
and should not be recommended here.

9.2 
"Under most scenarios" -- a few scenarios would be helpful.