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

From: "John R Levine" <[email-masked]>
Date: 1 Apr 2013 16:15:30 -0400

> When there is an interoperability failure between a client and server, it
> really helps to have simple browser support to determine if the fault is on
> the server or client. Visual inspection of the server response can
> determine if it is out of spec, without having to write or use debugging
> code.

Like I said:

>> PS: I'm not saying it's a bad idea to return a web page, I'm saying it's a
>> bad idea to try to specify that.

It already has a hint to developers that they return a web page to generic 
clients.  If people aren't inclined to take the hint, that's a quality of 
implementation issue.

Personally, I'd prefer that it always return JSON, since if I'm debugging a 
JSON client, I want to see what the client sees.  But I realize that tastes can 
differ.

R's,
John

---

From: Pieter Vandepitte <[email-masked]>
Date: Tue, 2 Apr 2013 16:17:03 +0200 (CEST)

A few short comments on my behalf: 

Please note that I don't want to offend anyone, but I just want to make my opinion clear... 

I fully agree: RFC 2616 indeed makes GET and HEAD mandatory and it is a bad idea to duplicate text, but: 

[1] very few standards are implemented correctly. Don't get me wrong: i would love to have every bit of code being fully compliant, but this is the reality. If we don't mention a thing on the HEAD method i don't think we can expect it will be implemented correctly. 
[2] everyone following the list is very smart and reads every single letter of an RFC (including links to others), but we cannot assume every developer will read all RFC's in the references section. Repeating will emphasise the importance of the HEAD method. 
[3] I'm working on an implementation here on Jetty and currently performing a HEAD (only implemented GET), results in a "HTTP/1.1 405 Request method 'HEAD' not supported" 
Other web apps will have similar behavior. So I would not state that "a lot of servers will probably support it for free anyway." 
I think if we don't mention it, it will never be implemented by most registries. 
[4] It's about the 'semantics' of the HEAD method. We don't really 'duplicate' text. It's more giving a meaning to the HEAD method 
[5] I think I didn't state the problem 100% clear. Domain Availability is not just [a] performing a lookup of a domain, [b] then just throw away all information and [c] return available or not. Domain availability has a very different access profile (unlimited, no content restriction) and usage profile ( > 40 times more queries per second) than WHOIS and so is implemented slightly different. It's not merely a "for free" feature by letting a web server strip off the contents 
[6] a side note on connection cost: 3205 bytes (GET) vs.208 bytes (HEAD) does make a difference under heavy traffic... 

On the other hand, if the focus of the working group is purely defining a replacement for WHOIS, then this is fine by me and I can understand the decision. I would not want to slow down any standardization process because of a tiny feature. 

Best regards, 

Pieter 

----- Original Message -----

> From: "John Levine" <[email-masked]>
> To: [email-masked]
> Sent: Friday, March 29, 2013 11:23:05 PM
> Subject: Re: [weirds] Working Group Last Call:
> draft-ietf-weirds-using-http

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

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

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