Subject: [weirds] Working Group Last Call: draft-ietf-weirds-using-http

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 27 Mar 2013 17:53:22 +0100

Colleagues,

We would like to initiate a two-week Working Group Last Call on
draft-ietf-weirds-http.  A version 03 was just pushed to the datatracker:

https://datatracker.ietf.org/doc/draft-ietf-weirds-using-http/

Last call will end Wednesday, April 10th.

Please review and comment on the draft, even if it is only to say on the
record "I have reviewed this document thoroughly and it looks good."  We
would like to have no fewer than five people report that they have taken a
look at the whole document and reported their findings, and will be
reticent to send it to the IESG without that.  We're also keen to hear from
people that have implemented the specification as to their views on
clarity, correctness, and completeness.

Thanks,

-MSK and Olaf, your co-chairs

---

From: "John Levine" <[email-masked]>
Date: 28 Mar 2013 04:18:05 -0000

I reread the whole think and it looks ready to ship.

I haven't implemented it, but I've done enough web applications to be
confident that when I do, it'll work.

---

From: Maarten Wullink <[email-masked]>
Date: Thu, 28 Mar 2013 22:04:24 +0000

Here's my 2 cents

Versioning:
I am missing a section about api versioning, it might be desirable for a client to signal the server which version of the api it would like to use. This would enable registries to add new features to the server code in a backwards compatible way.
 
This could be done by integrating the version in the url, like:
example.com/weirds/v1.0/domain/weird.com or by using the MIME type for this. The client could also add the version identifier to the accept header like: Accept: application/rdap+json;version=2

4.1 Accept header 
" This specification does not define the responses a server returns to
   a request with any other media types in the Accept: header, or with
   no Accept: header.  One possibility would be to return a response in
   a media type suitable for rendering in a web browser." 

It would be useful if the server always returns the result in rdap+json format if the client has not specified the requested type with the Accept header. The json reponse should be the default response type,  this way the client would not have to retry the request. This would prevent needless queries.

5.1 Positive answers
" it SHOULD encode the answer in the format most appropriate according
   to the standard and defined rules for processing the HTTP Accept
   header, and return that answer in the body of a 200 response."

I would change this to "it MUST encode the answer" 
The server MUST use the type specified by the client in the Accept header, unless the server has no support for the type.

5.2 Redirects
"If a server wishes to inform a client that the answer to a given
   query can be found elsewhere, it SHOULD return either a 301 or a 307
   response code and an HTTP URL in the Location: header.  The client is
   expected to issue a subsequent query using the given URL without any
   processing of the URL. "

The "subsequent query" implies that any query after the 301 or 307 response must be sent to the url found in the Location header. This is only the case for the original query. a subsequent query could also be an entirely different query for which this does not apply. 

I would change it to: "The query for which a 301 or 307 response has been received MUST be retried at the URL found in the Location: header."  

5.3 Negative answers
"If a server wishes to respond that it has no information regarding the query, it SHOULD return a 404 response code.  Optionally, it MAY include additional information regarding the negative answer in the HTTP entity body." 

This will introduce an ambiguous situation if the server does not add additional information to the 404 response it is not possible for the client to dermine which of the following situations applies:

a) The url for the restful resource is incorrect and the error is from the http protocol
b) the restful url is a correct url but the resource it points to does not exists in the registry database.

There are multiple ways to fix this ambiguity the simplest would be to require the server to always send additional explanatory information with a 404 response.

Therefore change "it MAY include additional information regarding the negative answer in the HTTP entity body."

To: "it MUST include additional information regarding the negative answer in the HTTP entity body."

7.1.  RDAP Extensions Registry

This would require each registry to register probably multiple json extension identifiers with iana?
Would it not be easier to create a RESTful resource for the extension used by the server, the client can then query this resource to discover the extension(s) supported by the server?

8.3.  Language Identifiers in HTTP Headers

Given the description of the use of language identifiers in Section 8.2, unless otherwise specified servers SHOULD ignore the HTTP [RFC2616] Accept-Language header when formulating responses.

At the .nl ccTLD we currently have a whois service which supports multiple languages, the client can request the desired response luangue with the accept-language header in the request.

This should be changed to something like: "The server MUST return a response encoded in the language requested by the client. Unless the server has no support for the client.

Cheers,

Maarten

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: woensdag 27 maart 2013 17:53
To: [email-masked]
Subject: [weirds] Working Group Last Call: draft-ietf-weirds-using-http

Colleagues,

We would like to initiate a two-week Working Group Last Call on draft-ietf-weirds-http.  A version 03 was just pushed to the datatracker:

Please review and comment on the draft, even if it is only to say on the record "I have reviewed this document thoroughly and it looks good."  We would like to have no fewer than five people report that they have taken a look at the whole document and reported their findings, and will be reticent to send it to the IESG without that.  We're also keen to hear from people that have implemented the specification as to their views on clarity, correctness, and completeness.

Thanks,

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 28 Mar 2013 23:33:31 +0100

And I was thinking right away of something else: wouldn't it be a good idea to introduce a HEAD method? A lot of / some registries currently have some kind of Domain Availability Service which simply returns whether the domain which is looked up, is still available (yes or no). A "HEAD /domains/example.com"  would e.g. return a "200 OK" if the domain name exists, and a "404 NOT FOUND" if the domain name is still available (i.e. the same result code as if the client performed a GET)

Okay, this could questionably be called REST, but this feature could be useful for registrars or other instances to have a uniform way to anonymously check whether a domain name is still available for different TLD's (by performing some kind of distributed query)

Just thinking out loud...

Pieter

On 28 Mar 2013, at 23:04, Maarten Wullink <[email-masked]> wrote:

> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 28 Mar 2013 23:43:53 +0100

On versioning: this is indeed something what's missing. Good point.

The option to put the version in the URL is OK only if there's a version-less URL redirecting to the latest version api: a client should not know in advance which version a server supports (in an ideal world). Let's hope newer versions will be backwards compatible ;-)

Pieter

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2013 00:38:33 -0000

Not to be unduly negative, but these are not good ideas.

>Versioning:

We're carefully making this design extensible, with ways to put added
stuff in the json and so forth.  If we fail so badly that we need to
start over with an incompatible version 2,0, I would very much prefer
that the new version uses different URLs, so the existing 1.0 clients
don't break.

>I am missing a section about api versioning, it might be desirable for a
>client to signal the server which version of the api it would like to
>use.

Good lord no.  There lies major interop failures.  We define one spec
and tell people to implement that.

>It would be useful if the server always returns the result in rdap+json
>format if the client has not specified the requested type with the
>Accept header.

No.  A client that doesn't send an Accept: header is not an rdap
client, so it makes sense to return a generic format that a generic
client (e.g. a web browser) can render.

>The "subsequent query" implies that any query after the 301 or 307
>response must be sent to the url found in the Location header. This is
>only the case for the original query. a subsequent query could also be
>an entirely different query for which this does not apply. 

This sits on top of http, that's part of the http semantics of 3xx
responses.  It is not good standards design to try to reiterate stuff
defined in another spec, since the two versions never quite match.

>5.3 Negative answers
>
>This will introduce an ambiguous situation if the server does not add
>additional information to the 404 response it is not possible for the
>client to dermine which of the following situations applies:
>

Again, see the http spec.  This is not ambiguous.  Malformed requests
get a 400 return code.

>Would it not be easier to create a RESTful resource for the extension
>used by the server, the client can then query this resource to discover
>the extension(s) supported by the server?

No. It's not a bug that it is somewhat hard to invent extensions.

etc.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Mar 2013 03:51:05 +0100

A quick note about the IANA Considerations section:

1) "COMMON" doesn't strike me as a "brief reason for a registry entry".
(Or perhaps it's overly brief.)  Either the name for that field should
change to something like "Brief description" and the example updated
accordingly, or the definition of "Intended usage" should be updated to
match the intent.  RFC6838 is the new media type registration document
which we could use as a reference here.

2) The contact person in the registration template in 7.2 appears to
include a malformed email address.  I suspect "&lt;" and "&gt;" have been
mis-rendered.

3) We are going to be asked to explain why Specification Required and not
some less stringent registry rule is being chosen.  I don't have a strong
preference for any of them at this point, but we should be sure before
sending this upwards that we really can't accept First Come First Served or
Expert Review, and be prepared to explain why.  I would even suggest
including a sentence or two defending the choice that's there if we're sure
it's right.

I'll do a more complete review soon (traveling this week) but I wanted to
get that last point out for discussion right away.

---

From: Maarten Wullink <[email-masked]>
Date: Fri, 29 Mar 2013 11:03:22 +0100

> Not to be unduly negative, but these are not good ideas.
thanks for your reply, i still have some comments/questions.

> client (e.g. a web browser) can render.
This generic format (probably html based) is described in an other 
(future) weirds document?

> defined in another spec, since the two versions never quite match.

In that case i would remove the text about what the client is expected 
to do when receiving a redirect in section "5.2.  Redirects". The 
user-agent behaviour is defined in rfc 2616.

> Again, see the http spec.  This is not ambiguous.  Malformed requests

A malformed request will get a 400 code but a request with a syntacly 
correct url for a resource will get a 404 when the resource does not 
exist on the server.

This 404 is a http protocol code which is reused in the rdap protocol.
If the server does not add additional information to the response, how 
is the client to determine the difference between

a) url does not exist on the server and response is 404 (but url has 
valid syntax, so no 400 response)
and
b) the url is valid and is accepted by the weirds application, but there 
is no data for the requested resource in the database. the response will 
be a 404.

---

From: Maarten Wullink <[email-masked]>
Date: Fri, 29 Mar 2013 11:48:02 +0100

On 03/28/2013 11:33 PM, Pieter Vandepitte wrote:
> And I was thinking right away of something else: wouldn't it be a
> good idea to introduce a HEAD method? A lot of / some registries
> currently have some kind of Domain Availability Service which
> simply returns whether the domain which is looked up, is still
> available (yes or no). A "HEAD /domains/example.com"  would e.g.
> return a "200 OK" if the domain name exists, and a "404 NOT FOUND"
> if the domain name is still available (i.e. the same result code as
> if the client performed a GET)
> 
> Okay, this could questionably be called REST, but this feature
> could be useful for registrars or other instances to have a uniform
> way to anonymously check whether a domain name is still available
> for different TLD's (by performing some kind of distributed query)
> 

Good one, at the .nl ccTLD we currently have a "lightweight" whois
(IS) service which enables a client to check if a domain exists or not.
This "IS" service is used to offload requests which would otherwise go
to the more "resource intensive" whois service. The query/response for
the IS also use much less network bandwidth.

We drafted a proposal for a RESTful EPP a while ago, in that proposal
we suggested the use of the http HEAD method to do a check if a
resource exists. The response could be as short as only a http 200.
see: http://tools.ietf.org/html/draft-wullink-restful-epp-00#section-9.4.1

This is something we would definitely require.

>> Versioning: I am missing a section about api versioning, it might
>> be desirable for a client to signal the server which version of
>> the api it would like to use. This would enable registries to add
>> new features to the server code in a backwards compatible way.
>> 
>> example.com/weirds/v1.0/domain/weird.com or by using the MIME
>> type for this. The client could also add the version identifier
>> to the accept header like: Accept:
>> application/rdap+json;version=2
>> 
>> 
>> 4.1 Accept header " This specification does not define the
>> responses a server returns to a request with any other media
>> types in the Accept: header, or with no Accept: header.  One
>> possibility would be to return a response in a media type
>> suitable for rendering in a web browser."
>> 
>> It would be useful if the server always returns the result in
>> rdap+json format if the client has not specified the requested
>> type with the Accept header. The json reponse should be the
>> default response type,  this way the client would not have to
>> retry the request. This would prevent needless queries.
>> 
>> 
>> 5.1 Positive answers " it SHOULD encode the answer in the format
>> most appropriate according to the standard and defined rules for
>> processing the HTTP Accept header, and return that answer in the
>> body of a 200 response."
>> 
>> I would change this to "it MUST encode the answer" The server
>> MUST use the type specified by the client in the Accept header,
>> unless the server has no support for the type.
>> 
>> 
>> 5.2 Redirects "If a server wishes to inform a client that the
>> answer to a given query can be found elsewhere, it SHOULD return
>> either a 301 or a 307 response code and an HTTP URL in the
>> Location: header.  The client is expected to issue a subsequent
>> query using the given URL without any processing of the URL. "
>> 
>> The "subsequent query" implies that any query after the 301 or
>> 307 response must be sent to the url found in the Location
>> header. This is only the case for the original query. a
>> subsequent query could also be an entirely different query for
>> which this does not apply.
>> 
>> I would change it to: "The query for which a 301 or 307 response
>> has been received MUST be retried at the URL found in the
>> Location: header."
>> 
>> 
>> 5.3 Negative answers "If a server wishes to respond that it has
>> no information regarding the query, it SHOULD return a 404
>> response code.  Optionally, it MAY include additional information
>> regarding the negative answer in the HTTP entity body."
>> 
>> This will introduce an ambiguous situation if the server does not
>> add additional information to the 404 response it is not possible
>> for the client to dermine which of the following situations
>> applies:
>> 
>> a) The url for the restful resource is incorrect and the error is
>> from the http protocol b) the restful url is a correct url but
>> the resource it points to does not exists in the registry
>> database.
>> 
>> There are multiple ways to fix this ambiguity the simplest would
>> be to require the server to always send additional explanatory
>> information with a 404 response.
>> 
>> Therefore change "it MAY include additional information regarding
>> the negative answer in the HTTP entity body."
>> 
>> To: "it MUST include additional information regarding the
>> negative answer in the HTTP entity body."
>> 
>> 
>> This would require each registry to register probably multiple
>> json extension identifiers with iana? Would it not be easier to
>> create a RESTful resource for the extension used by the server,
>> the client can then query this resource to discover the
>> extension(s) supported by the server?
>> 
>> 
>> Given the description of the use of language identifiers in
>> Section 8.2, unless otherwise specified servers SHOULD ignore the
>> HTTP [RFC2616] Accept-Language header when formulating
>> responses.
>> 
>> At the .nl ccTLD we currently have a whois service which supports
>> multiple languages, the client can request the desired response
>> luangue with the accept-language header in the request.
>> 
>> This should be changed to something like: "The server MUST return
>> a response encoded in the language requested by the client.
>> Unless the server has no support for the client.
>> 
>> 
>> Cheers,
>> 
>> Maarten
>> 
>> 
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Murray S. Kucherawy Sent: woensdag 27 maart 2013 17:53 
>> To: [email-masked] Subject: [weirds] Working Group Last Call:
>> draft-ietf-weirds-using-http
>> 
>> Colleagues,
>> 
>> Please review and comment on the draft, even if it is only to say
>> on the record "I have reviewed this document thoroughly and it
>> looks good."  We would like to have no fewer than five people
>> report that they have taken a look at the whole document and
>> reported their findings, and will be reticent to send it to the
>> IESG without that.  We're also keen to hear from people that have
>> implemented the specification as to their views on clarity,
>> correctness, and completeness.
>> 
>> Thanks, -MSK and Olaf, your co-chairs 
>> _______________________________________________ weirds mailing
>> list [email-masked] 
> _______________________________________________ weirds mailing
> list [email-masked] https://www.ietf.org/mailman/listinfo/weirds
> 

- -- 
Maarten Wullink MSc|Technical advisor / R&D engineer
SIDN | Meander 501 | 6825 MD | Postbus 5022 | 6802 EA | ARNHEM
T +31 (0)26 352 55 45 | M +31 (0)6 21 26 87 55 | F +31 (0)26 352 55 05
[email-masked] | www.sidn.nl

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 29 Mar 2013 13:03:48 +0000

> > And I was thinking right away of something else: wouldn't it be a good
> > idea to introduce a HEAD method? A lot of / some registries currently
> > have some kind of Domain Availability Service which simply returns
> > whether the domain which is looked up, is still available (yes or no).
> > A "HEAD /domains/example.com"  would e.g.
> > if the domain name is still available (i.e. the same result code as if
> > the client performed a GET)

[Alexander Mayrhofer] 
>From the DNR perspective, i fully agree. We (.at) have a lightweight availability check based on the "finger" protocol, and would definitely need a similar lightweight method in WIERDS if we considered the protocol for deployment. 

>From the WEIRDS/protocol perspectiv: 

RFC 2616 says that HEAD MUST be supported anyways. However, it also says that  (see section 9.4)

"The metainformation contained
   in the HTTP headers in response to a HEAD request SHOULD be identical
   to the information sent in response to a GET request"

which means that, for example if the GET response includes a Content-Length header field, the respective HEAD response should also include this header field. Which, in turn, means that the HEAD method would also need to fully evaluate the query, fetch the data, and calculate the response body, just because it needs to provide the header filed - and this would contradict the purpose of HEAD resembling a light-weight alternative to GET (at least on the server side).

Of course, we could leave out the various problematic header fields in the HEAD response, but this would stretch the purpose of SHOULD a bit. Alternatively, we could strip the headers from both the GET and HEAD responses - which probably doesn't make sense either.

Practically, i would probably simply leave out the problematic headers in the HEAD responses, and bend the HTTP specs, rather than losing the advantage of the "lightweight" method.

We can solve this in the document by simply saying that servers SHOULD also support HEAD, and leave the decision whether or not to provide GET-identical headers to the implementors.

Alex

---

From: Andy Newton <[email-masked]>
Date: Fri, 29 Mar 2013 16:25:12 +0000

>and tell people to implement that.

Just so everyone knows the history here, we had versioning in the media
type and Accept headers via the level parameter. This was taken out for
the reasons John states above. Additionally, there was concern that media
types, etc. wouldn't be expressive enough to deal with extensions.

There is versioning however, it is just in Section 5.1 of
draft-ietf-weirds-json-response
(http://tools.ietf.org/html/draft-ietf-weirds-json-response-02#section-5.1)

-andy

---

From: Andy Newton <[email-masked]>
Date: Fri, 29 Mar 2013 16:39:10 +0000

From: "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 28, 2013 10:51 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] Working Group Last Call: draft-ietf-weirds-using-http

1) "COMMON" doesn't strike me as a "brief reason for a registry entry".  (Or perhaps it's overly brief.)  Either the name for that field should change to something like "Brief description" and the example updated accordingly, or the definition of "Intended usage" should be updated to match the intent.  RFC6838 is the new media type registration document which we could use as a reference here.

>From RFC 6838:

Intended usage:

   (One of COMMON, LIMITED USE, or OBSOLETE.)

Are you saying we should use something else?

2) The contact person in the registration template in 7.2 appears to include a malformed email address.  I suspect "&lt;" and "&gt;" have been mis-rendered.

Thought I fixed that. Thanks.

3) We are going to be asked to explain why Specification Required and not some less stringent registry rule is being chosen.  I don't have a strong preference for any of them at this point, but we should be sure before sending this upwards that we really can't accept First Come First Served or Expert Review, and be prepared to explain why.  I would even suggest including a sentence or two defending the choice that's there if we're sure it's right.

I don't have a strong opinion either way, either. However, the extensions registry is a place where developers of clients will go to find extensions. Having registry publish a document describing their extensions would probably be helpful to developers, much more helpful than just a listing of the prefix value.

-andy

---

From: Andy Newton <[email-masked]>
Date: Fri, 29 Mar 2013 16:39:56 +0000

>(future) weirds document?

It is JSON, specified in draft-ietf-weirds-json-response.

-andy

---

From: Andy Newton <[email-masked]>
Date: Fri, 29 Mar 2013 16:44:54 +0000

On 3/29/13 9:03 AM, "Alexander Mayrhofer" <[email-masked]>
wrote:

>From the DNR perspective, i fully agree. We (.at) have a lightweight
>availability check based on the "finger" protocol, and would definitely
>need a similar lightweight method in WIERDS if we considered the protocol
>for deployment. 

This working group is chartered for a replacement of Whois, not the
standardization of a lightweight domain name availability check.  That
being said, we probably should support HEAD and if it solves the problem
then so be it. :)

>which means that, for example if the GET response includes a
>Content-Length header field, the respective HEAD response should also
>include this header field. Which, in turn, means that the HEAD method
>would also need to fully evaluate the query, fetch the data, and
>calculate the response body, just because it needs to provide the header
>filed - and this would contradict the purpose of HEAD resembling a
>light-weight alternative to GET (at least on the server side).
>
>Of course, we could leave out the various problematic header fields in
>the HEAD response, but this would stretch the purpose of SHOULD a bit.
>Alternatively, we could strip the headers from both the GET and HEAD
>responses - which probably doesn't make sense either.
>
>Practically, i would probably simply leave out the problematic headers in
>the HEAD responses, and bend the HTTP specs, rather than losing the
>advantage of the "lightweight" method.
>
>We can solve this in the document by simply saying that servers SHOULD
>also support HEAD, and leave the decision whether or not to provide
>GET-identical headers to the implementors.

I agree. We should just say that HEAD should be supported. Now is that a
SHOULD or a MUST. I think MUST given 2616's language.

-andy

---

From: "John R Levine" <[email-masked]>
Date: 29 Mar 2013 12:50:08 -0400

> It is JSON, specified in draft-ietf-weirds-json-response.

Other way around.  An rdap client asks for a json response, and gets a 
json response.

A non-rdap client asks for something else.  Since it's not rdap, the 
server can return whatever it wants.  This is not an interoperability 
issue, so there's no reason to define it further.

The non-normative note suggests that since the non-rdap clients is likely 
to be a web browser, something a browser could render would be nice. 
This is in fact what Andy's protoype does.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Andy Newton <[email-masked]>
Date: Fri, 29 Mar 2013 17:07:11 +0000

>Other way around.  An rdap client asks for a json response, and gets a

Sorry. I misread. You are right.

-andy

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2013 17:17:07 -0000

>being said, we probably should support HEAD and if it solves the problem

I agree, HEAD is harmless and a lot of servers will probably support
it for free anyway.

On the other hand, from the point of view of network traffic, there's
no interesting difference between a finger request and an http GET.
Each opens a TCP circuit, sends some text for the request, gets back a
chunk of text in the response, and closes the circuit.  The amount of
text in a GET is larger, but we're not using 1200 bps modems any more,
and the request and response can both likely fit in a single packet
with typical MTUs.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 29 Mar 2013 20:42:45 +0100

On Fri, Mar 29, 2013 at 5:39 PM, Andy Newton <[email-masked]> wrote:

>   From: "Murray S. Kucherawy" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
>     1) "COMMON" doesn't strike me as a "brief reason for a registry
> entry".  (Or perhaps it's overly brief.)  Either the name for that field
> should change to something like "Brief description" and the example updated

I think the sample is fine, but the description (above that in the same
section) is bogus.

I think Specification Required is fine, personally.  I just know that this
is a current pet peeve of at least one current IESG member, so I want us to
be prepared if the question comes.  I can't think of any specific text
other than perhaps your own text just now that we could add to get out in
front of the question.

-MSK

---

From: Alexander Mayrhofer <[email-masked]>
Date: Fri, 29 Mar 2013 21:50:35 +0000

> SHOULD or a MUST. I think MUST given 2616's language.

[Alexander Mayrhofer] 
I think it's a MUST. However, we might want to clarify it comes from the HTTP specs, rather than from the RDAP specs. Maybe something along the lines of :  "GET and HEAD are REQUIRED methods in HTTP. Therefore, RDAP servers MUST implement at least those two methods". 

Alex

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2013 22:23:05 -0000

>I think it's a MUST. However, we might want to clarify it comes from the HTTP specs, rather than
>from the RDAP specs. Maybe something along the lines of :  "GET and HEAD are REQUIRED methods in
>HTTP. Therefore, RDAP servers MUST implement at least those two methods". 

Since RFC 2616 already makes GET and HEAD mandatory, the correct thing
for us to say about that is nothing.  It is rarely a good idea for one
standards document to restate bits of another document, since the two
statements never quite say the same thing.

R's,
John

---

From: SM <[email-masked]>
Date: Fri, 29 Mar 2013 23:44:02 -0700

>draft-ietf-weirds-http.  A version 03 was just pushed to the datatracker:

Please note that I am commenting as an individual.

The Abstract mentions that:

   "This document describes the usage of the Registration Data Access
    Protocol (RDAP) using HTTP."

The Introduction Section mentions that:

   "This document describes the usage of HTTP for Registration Data
    Directory Services running on RESTful web servers."

I guess that the Abstract needs to be updated.

In the Introduction Section:

  "In designing these common usage patterns, this draft endeavours to
   satisfy requirements for a Registration Data Access Protocol (RDAP)."

As a nit, "draft".

I read the Introduction Section and I did not find anything explicit 
about the Registration Data Access Protocol.  There is however an 
example which tries to explain how this protocol works.  Where is 
this Registration Data Access Protocol specified?

In Section 2:

   "[SAC-051] describes a protocol profile of RDAP for Domain Name
    Registries (DNRs), DNRD-AP."

Please "expand on first use".

   "This document and others from the IETF WEIRDS working group describe
    a single protocol, RDAP, for access to the data of both DNRs and
    Regional Internet Registries (RIRs)."

What does this have to do with terminology?

   "RIRs are also often referred to as number resource registries and
    are responsible for the registration of IP address networks and
    autonomous system numbers."

What does this have to do with terminology?

In Section 3:

   "Third, HTTP offers a number of transport protocol mechanisms not
    described further in this document.  Operators are able to make use
    of these mechanisms according to their local policy, including cache
    control, authorization, compression, and redirection."

Hmm, that does not sound like transport protocol mechanisms to me.

   "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."

I heard that one before. :-)  Section 3 starts with "query" and ends 
with HTTP for the naive programmer argument.  I suggest reordering 
the design intent starting from the "top".

In Section 4.1:

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

What are RDAP clients?  I guess that the problem is that the draft 
explains it by example (Section 1) instead of specifying it.

In Section 4.2:

   "Servers SHOULD ignore unknown query parameters.  Use of unknown query
    parameters for cache-busting is described in Appendix A."

Why is there a "MAY" in the Appendix?  When should servers not ignore 
"unknown query parameters"?  What are "servers"?

In 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."

Why is this a SHOULD?

In Section 5.1:

   "If a server has the information requested by the client and wishes to
    respond to the client with the information according to its policies,
    it SHOULD encode the answer in the format most appropriate according
    to the standard and defined rules for processing the HTTP Accept
    header, and return that answer in the body of a 200 response."

I can understand that this working group feels strongly about 
policy.  The question of whether the server is willing to provide the 
information is irrelevant.  If the server is providing the 
information, it returns a body with a 200 response code.  The 
specification does not have to put policy in every place.

In Section 5.2:

   "If a server wishes to inform a client that the answer to a given
    query can be found elsewhere, it SHOULD return either a 301 or a 307
    response code and an HTTP URL in the Location: header."

I see two response codes in the above?  I see a "SHOULD".  I suggest 
being clear or else it will lead to diverging implementations.  The 
above can be restated in terms of what the response code means.

   "A server SHOULD use a 301 response to inform the client of a
    permanent move and a 307 response otherwise."

This makes it two SHOULDs.  Why can't that be explained with one SHOULD?

In Section 5.3:

   "If a server wishes to respond that it has no information regarding
    the query, it SHOULD return a 404 response code."

Why is this a SHOULD?

In Section 5.4:

   "If a server receives a query which it cannot understand, it SHOULD
    return a 400 response code."

Why is this a SHOULD?  By the way, on reading of the sentence only I 
would say that the 400 response code is not appropriate.

In Section 5.5:

   "When a server declines to answer a query due to rate limits,
    it MAY return a 429 response code as described in [RFC6585]."

Why is this a MAY?

In Section 6:

   "First, client implementers using modern programming languages such
    as Ruby or Java may use libraries that automatically promote JSON
    names to first order object attributes or members."

It's not the purpose of this working group to be the marketing arm of 
Java or Ruby. :-)

In Section 7.1:

   "In accordance with RFC5226, the IANA policy for assigning new values
    shall be Specification Required: values and their meanings must be
    documented in an RFC or in some other permanent and readily available
    reference, in sufficient detail that interoperability between
    independent implementations is possible."

Note that this is IANA considerations.  I suggest not calling it 
"IANA policy".  I suggest not restating what is in RFC 5226 as it may 
end up being problematic in future (nothing to do with the working 
group).  Why is the policy "specification required"?

In Section 8.2:

   "Depending on the data format of the response, servers MAY include
    data in character sets other than ASCII and languages other than
    English (the data format will most likely be in Unicode and almost
    certainly languages other than English will be encountered)."

This comes out as hand-waving the internationalization 
question.  From the charter:

   "WHOIS has never been internationalized.  In the absence of formal
    specification, ad hoc solutions to signal internationalized
    registration data have been adopted and deployed.  Providing a
    standards-based solution that scales well could minimize further
    proliferation of ad hoc solutions."

It seems to me that the working group has been working on Whois over 
HTTP instead of internationalization.

draft-ietf-weirds-using-http-03 is well-written.  My reading of it is 
that it is under-specified.  I suggest framing the draft in terms of 
HTTP.  It will give everyone what he or she wants while disguising 
the draft as an IETF specification. :-)  There isn't a Security 
Considerations section in the draft.  My hypothesis [1] is that a 
draft intended to be published on the Standards Track to make it 
there is very low if there isn't any consideration to security.

Regards,
-sm

1. http://www.madamandeve.co.za/cartoons/me005105.jpg

---

From: "John Levine" <[email-masked]>
Date: 30 Mar 2013 17:21:57 -0000

>    it MAY return a 429 response code as described in [RFC6585]."

Servers aren't required to disclose their rate limiting rules to
hostile clients.  It might return 503 or just reject the connection.

>question.  From the charter:

I agree that we should either say UTF-8 or nothing.  This isn't a policy
issue, it's an interop issue.

R's,
John

---

From: SM <[email-masked]>
Date: Sat, 30 Mar 2013 18:05:56 -0700

Hi John,
>hostile clients.  It might return 503 or just reject the connection.

Using a MAY takes the discussion into the internals on the server 
side.  The text can be restated in terms of what the status code 
means.  The server does not have to disclosure its rate limiting 
rules.  For what it is worth RFC 6585 explains that nicely.  I'll 
elaborate if what I wrote is not clear.

>issue, it's an interop issue.

Yes.

Here's some text from Section 8.1:

   "Clients MAY use IRIs 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 clients MAY transform these URIs to IRIs."

By the way there isn't any definition for IRIs in the draft.

As there are several implementations of 
draft-ietf-weirds-using-http-03 maybe the individuals who have 
written the code could explain how they interpreted the above.

Regards,
-sm

---

From: "John R Levine" <[email-masked]>
Date: 30 Mar 2013 21:29:31 -0400

> Using a MAY takes the discussion into the internals on the server side.  The 
> text can be restated in terms of what the status code means.  The server does 
> not have to disclosure its rate limiting rules.  For what it is worth RFC 
> 6585 explains that nicely.  I'll elaborate if what I wrote is not clear.

RFC 6585 says in the introduction that everything in it is optional.  MAY 
is correct here.

Regards,

---

From: SM <[email-masked]>
Date: Sat, 30 Mar 2013 19:21:07 -0700

Hi John,
At 18:29 30-03-2013, John R Levine wrote:
>RFC 6585 says in the introduction that everything in it is 
>optional.  MAY is correct here.

The point is that optional does not help from status code 
perspective.  If my client receives a 429 I take it that I am 
rate-limited.  The intent is clearly conveyed.  If I look at this 
from the server side I can send any status code I wish instead of 
telling the client that it is rate-limited.  My reading of RFC 6585 
is that is the angle it discusses about (I agree that the code is optional).

Regards,
-sm