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

From: James Mitchell <[email-masked]>
Date: Wed, 3 Apr 2013 02:00:04 +1100

Alex,

A domain name may be unavailable because:
- the name is in use (HTTP 200)
- the name is valid but has not been registered (HTTP 404 optionally with
content)
- the name is reserved/withheld from registration (HTTP 404 optionally
with content?)
- the name contains disallowed characters e.g. "one&two.example" or
"<smiley-face-symbol>.example" (HTTP 404 optionally with content?)
- the name could not possibly be a domain name "<64 characters>.example"
(HTTP 404 optionally with content?)
- etc..

How does a client identify the valid unregistered domain name? If we want
a standardised DAC over HTTP service then some content is required either
in the using-http document through different response codes, or a WEIRDS
DAC document. I think I'd prefer the latter.

Regards,
James

On 30/03/13 12:03 AM, "Alexander Mayrhofer" <[email-masked]>
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)
>
>[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
>
>_______________________________________________
>weirds mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/weirds

---

From: Andy Newton <[email-masked]>
Date: Tue, 2 Apr 2013 15:35:26 +0000

>DAC document. I think I'd prefer the latter.

James,

This is very well said. I don't think this should go into using-http as
that refers to RDAP. The semantics you have outlined are different enough
that DAC is really a separate thing from RDAP. However it is very close
both in protocol operation and in subject area, so I think it is
reasonable that if a couple of people were to put this in I-D form we
could seek it as a working group item even if we had to ask the IESG to
modify the charter ever so slightly. It would seem a shame to spin up yet
another working group just to handle DAC since it so closely related to
RDAP.

-andy

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 3 Apr 2013 07:00:45 +0000

> >(HTTP 404 optionally with content?)

[Alexander Mayrhofer] 
Agreed. Essentially, the way we see our current WHOIS service is that it provides information about registered names. Nothing more. Particularly, it does not perform any policy checks on the string that was queried for. It's like the phone book - just because there's no entry for 123 in the phone book doesn't mean you can get that number.

> >How does a client identify the valid unregistered domain name? If we
> >want a standardised DAC over HTTP service then some content is required
> >either in the using-http document through different response codes, or
> >a WEIRDS DAC document. I think I'd prefer the latter.

[Alexander Mayrhofer] 
Agreed, again. DAC doesn't fit the "information directory" model very well - the DAC should be a seperate document. 

> This is very well said. I don't think this should go into using-http as that refers
> to RDAP. The semantics you have outlined are different enough that DAC is
> really a separate thing from RDAP. However it is very close both in protocol
> operation and in subject area, so I think it is reasonable that if a couple of
> people were to put this in I-D form we could seek it as a working group item
> even if we had to ask the IESG to modify the charter ever so slightly. It would
> seem a shame to spin up yet another working group just to handle DAC since
> it so closely related to RDAP.

[Alexander Mayrhofer] 
Agreed, again. Resource concerns aside, i'm happy to collaborate with others to create a DAC draft, in case there's significant interest in that.

Alex