Subject: [weirds] AD Evaluation of draft-ietf-weirds-using-http-05

From: Pete Resnick <[email-masked]>
Date: Wed, 29 May 2013 10:04:20 -0500

(Directly Cc'ing Olaf at his request.)

Greetings all,

Below is my AD Evaluation of -using-http-05. I have tried to do this 
review as "blind" as possible, coming to it as an implementer who has 
not seen the discussion in the WG. Hopefully I've made some useful catches.

Might I suggest that the authors and/or Olaf do the initial responding 
before others pile on. If you have something to add after the authors 
get a chance to respond, that's fine. I just don't want the list (or my 
Inbox) to explode on something for which the authors can just pat me on 
the head and say, "No, Pete, you blew it."

So, here's my review. Once we clear these issues up, I'll issue the IETF 
Last Call.

----

Section 3 says:

    Second, multiple response formats are supported by this protocol.  At
    present the IETF Web Extensible Internet Data Service (WEIRDS)
    working group is defining only a JSON [RFC4627] response format, but
    server operators may use other data formats when those formats are
    requested.

However, section 4.1 says:

    RDAP clients MUST include an Accept: header field specifying
    application/rdap+json, application/json, or both.  Servers receiving
    an RDAP request MUST return an entity with Content-Type application/
    rdap+json.

Why are those two not contradictory?

Section 5.1:

    it encodes the answer in the format most appropriate according to the
    standard and defined rules for processing the HTTP Accept header
    field, and return that answer in the body of a 200 response.

The first part is a little convoluted. Does it simply mean, "it encodes 
the answer appropriately based on the HTTP Accept header field"? Also, 
grammatical nit: s/return/returns.

Section 5.2:

    If a server wishes to inform a client that the answer to a given
    query can be found elsewhere, it MUST return a 301 response code to
    indicate a permanent move, or a 307 response code to indicate a non-
    permanent redirection, and include an HTTP(s) URL in the Location:
    header field.

Is that MUST there for interoperability reasons? That is, is it 
plausible that a server might choose something other than 301 or 307 and 
this document is specifically limiting the server to only choose 301 or 
307? The same question for including the URL in the Location header 
field. If it *is* a specific limitation, I suggest a minor rewording to 
make it clearer:

    If a server wishes to inform a client that the answer to a given
    query can be found elsewhere, it MUST return either a 301 response
    code to indicate a permanent move, or a 307 response code to indicate
    a non- permanent redirection, and it MUST include an HTTP(s) URL in
    the Location: header field.

If it is not a limitation, but rather just a statement of what the 
server does, I suggest:

    If a server wishes to inform a client that the answer to a given
    query can be found elsewhere, it returns a 301 response code to
    indicate a permanent move, or a 307 response code to indicate a non-
    permanent redirection, and includes an HTTP(s) URL in the Location:
    header field.

I have similar questions for the MUSTs in 5.3 and 5.4 and the SHOULD in 5.5.

Section 6:

I'd like to understand the exceptions that exist that justify 
SHOULD/SHOULD NOT instead of MUST/MUST NOT for the name syntax.

The syntax itself allows a name of "X______". It also imposes no length 
limit. Is that OK?

Section 8.2: Shouldn't this registration go in 
draft-ietf-weirds-json-response? Also, the reference to 6839 is 
Informative, not Normative, as far as I can tell.

Section 9.1: I think the MAYs in there could turn out badly. Might I 
suggest instead:

    Clients can use IRIs [RFC3987] for internal use as they see fit, but
    MUST transform them to URIs [RFC3986] for interaction with RDAP
    servers.  RDAP servers MUST use URIs in all responses, and again
    clients can transform these URIs to IRIs for internal use as they see
    fit.

The MAYs seem to imply that there are places in the protocol where they 
MAY use IRIs, and AFAICT that's not true.

Appendix B: s/MAY/can. You're not really specifying a protocol option here.

Appendix C: A note in here for the RFC Editor to remove this section 
would be useful.

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478