Subject: [weirds] FW: I-D Action: draft-hollenbeck-weirds-rdap-search-00.txt

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 25 Jan 2013 15:01:46 +0000

This draft should be of interest to working group members. This is a first attempt by me and Andy to document a search specification. The i18n considerations section is essentially blank right now. We are looking for discussion on the approach and suggestions for the i18n section.

Note that this approach means that I also need to update the query draft WRT IDNs. It currently says a-labels only", but to make it consistent with this search spec we should also allow u-labels.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, January 25, 2013 9:58 AM
To: [email-masked]
Subject: I-D Action: draft-hollenbeck-weirds-rdap-search-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Registration Data Access Protocol Search Processing
	Author(s)       : Scott Hollenbeck
                          Andrew Lee Newton
	Filename        : draft-hollenbeck-weirds-rdap-search-00.txt
	Pages           : 8
	Date            : 2013-01-25

Abstract:
   This document describes path segments and query parameters needed to
   construct HTTP URLs that may be used to search for and retrieve
   registration information from registries (including both Regional
   Internet Registries (RIRs) and Domain Name Registries (DNRs)) using
   "RESTful" web access patterns.  It also describes a method of
   encoding responses using Javascript Object Notation (JSON).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hollenbeck-weirds-rdap-search

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hollenbeck-weirds-rdap-search-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Gavin Brown <[email-masked]>
Date: Mon, 28 Jan 2013 10:58:16 +0000

I've just skimmed the draft and it looks like a good start.

The first issue I came across was Section 4, Search Processing:

"If a server receives a search request but cannot process the request
because it does not support a particular style of partial match
searching, it SHOULD return an HTTP 500 error."

Shouldn't this be 400 instead of 500?

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Ltd
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 28 Jan 2013 12:06:59 +0000

> From: Gavin Brown [mailto:[email-masked]]
> Sent: Monday, January 28, 2013 5:58 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> Subject: Re: [weirds] FW: I-D Action: draft-hollenbeck-weirds-rdap-
> search-00.txt
> 

From the W3C and RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html):

400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

500 Internal Server Error

The server encountered an unexpected condition which prevented it from fulfilling the request.

501 Not Implemented

The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.

Now that I look at it again I like the 501 error better.

Scott

---

From: Gavin Brown <[email-masked]>
Date: Mon, 28 Jan 2013 12:08:29 +0000

> Now that I look at it again I like the 501 error better.

Agreed.

G.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Jan 2013 13:13:00 +0100

>>From the W3C and RFC 2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html):

You really should look at the HTTPbis drafts 
(<http://trac.tools.ietf.org/wg/httpbis/trac/wiki>)

> The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

It seems to be a client error, to I'd recommend a 4xx.

> Now that I look at it again I like the 501 error better.

Nope. 501 is about HTTP *methods* not being implemented.

Best regards, Julian

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 28 Jan 2013 12:26:03 +0000

Save us both some time, please, and suggest the proper response code.

> From: Julian Reschke [mailto:[email-masked]]
> Sent: Monday, January 28, 2013 7:13 AM
> To: Hollenbeck, Scott
> Cc: Gavin Brown; [email-masked]
> >>From the W3C and RFC 2616
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html):
> 
> > The request could not be understood by the server due to malformed
> syntax. The client SHOULD NOT repeat the request without modifications.
> 
> > The server does not support the functionality required to fulfill the
> request. This is the appropriate response when the server does not
> recognize the request method and is not capable of supporting it for
> any resource.
> >

That's certainly not what the text says. Could you save us both some time, please, and suggest an appropriate 4xx response code if you disagree with 501?

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 28 Jan 2013 12:38:29 +0000

> (<http://trac.tools.ietf.org/wg/httpbis/trac/wiki>)

OK, done. From section 7.6 (Server Error 5xx) of draft-ietf-httpbis-p2-semantics:

"Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred _or is incapable of performing the request_." (Emphasis mine)

and

"These response codes are applicable to any request method."

7.6.2.  501 Not Implemented:

"The server does not support the functionality required to fulfill the request.  This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource."

This certainly sounds like the search scenario described above. The server does not support the requested search functionality and is not capable of supporting it. Which 4xx response would be more appropriate? 400 or 405 seem to come closest, but this isn't a syntax error (400) and I don't understand how the server could return a list of valid methods as required for a 405 response.

Scott

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Jan 2013 13:50:50 +0100

On 2013-01-28 13:38, Hollenbeck, Scott wrote:
> ...

400 isn't just for syntax errors; so if there's nothing more specific, 
you could use that. You could also have a look at 422.

Best regards, Julian

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 28 Jan 2013 14:38:21 +0000

> Sent: Monday, January 28, 2013 7:51 AM
> To: Hollenbeck, Scott
> Cc: [email-masked]
> > "Response status codes beginning with the digit "5" indicate cases in
> > which the server is aware that it has erred _or is incapable of
> > performing the request_." (Emphasis mine)
> >
> > and
> >
> > "The server does not support the functionality required to fulfill
> the request.  This is the appropriate response when the server does not
> any resource."
> > This certainly sounds like the search scenario described above. The
> server does not support the requested search functionality and is not
> capable of supporting it. Which 4xx response would be more appropriate?
> 400 or 405 seem to come closest, but this isn't a syntax error (400)
> and I don't understand how the server could return a list of valid
> methods as required for a 405 response.
> >
> > Scott
> > ...
> 

For those following along 422 is described in RFC 4918: "The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415(Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions."

RDAP clients send "Accept: application/rdap". The server understands the content type, so perhaps 422 could work. Before I concede the point I'd like to better understand the distinction you're making between 4xx and 5xx response codes. draft-ietf-httpbis-p2-semantics again says this:

o  4xx (Client Error): The request contains bad syntax or cannot be fulfilled

o  5xx (Server Error): The server failed to fulfill an apparently valid request

So who made the error in this case? This isn't a case of server failure, it's a case of a client asking for an unsupported service. That sounds more like a 4xx "cannot be fulfilled" than a 5xx "server failed to fulfill". Was that your point?

Andy, what's your take? 400, 422, 500, 501? With the clarifications in the httpbis drafts I'm leaning more towards 400 or 422.

Scott

---

From: Julian Reschke <[email-masked]>
Date: Mon, 28 Jan 2013 15:45:40 +0100

> So who made the error in this case? This isn't a case of server failure, it's a case of a client asking for an unsupported service. That sounds more like a 4xx "cannot be fulfilled" than a 5xx "ser…

Yes!

Best regards, Julian

---

From: Andy Newton <[email-masked]>
Date: Mon, 28 Jan 2013 17:55:38 +0000

On 1/28/13 9:38 AM, "Hollenbeck, Scott" <[email-masked]> wrote:

>So who made the error in this case? This isn't a case of server failure,
>it's a case of a client asking for an unsupported service. That sounds
>more like a 4xx "cannot be fulfilled" than a 5xx "server failed to
>fulfill". Was that your point?
>
>Andy, what's your take? 400, 422, 500, 501? With the clarifications in
>the httpbis drafts I'm leaning more towards 400 or 422.

I'm of the same opinion. 422 sounds the most right. Though it would be
nice if the httpbis draft were clearer about this point.

-andy

---

From: "Linlin Zhou" <[email-masked]>
Date: Fri, 1 Feb 2013 14:17:40 +0800

Thanks Scott. I have two questions.
1. Since there are 5 types of queries defined in the query draft, such as
IP, AS number, domain, name server and entity. Are there any other types of
search except domain and entity? 
2. Do you take any consideration about the combination of search parameters
and Boolean search function described in AGB?

Regards,
Linlin

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Hollenbeck, Scott
> Sent: Friday, January 25, 2013 11:02 PM
> To: [email-masked]
> Subject: [weirds] FW: I-D Action:
draft-hollenbeck-weirds-rdap-search-00.txt
> 
> This draft should be of interest to working group members. This is a first
attempt
> by me and Andy to document a search specification. The i18n considerations
> section is essentially blank right now. We are looking for discussion on
the
> approach and suggestions for the i18n section.
> 
> Note that this approach means that I also need to update the query draft
WRT
> IDNs. It currently says a-labels only", but to make it consistent with
this search
> spec we should also allow u-labels.
> 
> Scott
> 
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds