Subject: Re: [weirds] WEIRDS inactivity, and issues raised in London - handles

From: Ernie Dainow <[email-masked]>
Date: Wed, 04 Jun 2014 12:07:23 -0400

On 2014-05-12 12:53 PM, Hollenbeck, Scott wrote:
> 10. Handle Search (http://trac.tools.ietf.org/wg/weirds/trac/ticket/10#)
>
> I vaguely recall Ernie Dainow suggesting that this search was useful, but I'm inclined to remove it per Andy's suggestion
>

I suggested that handles should be removed altogether from all RDAP 
queries and responses, both lookup and search.

draft-ietf-weirds-json-response specifies that
     Each object class contains a "links" array ... (section 6. Object 
Classes)
A link is a more convenient way to get the details of say an entity than 
having to do a lookup by handle. Handles are leftover from WHOIS which 
needs them since links are not provided.

If we are to have handles in RDAP for consistency with WHOIS, then we 
should have search by handles, which is supported by WHOIS.

-Ernie

---

From: Ernie Dainow <[email-masked]>
Date: Wed, 04 Jun 2014 12:09:55 -0400

On 2014-05-12 12:53 PM, Hollenbeck, Scott wrote:
> 25. Clarify what is done with unsupported queries (http://trac.tools.ietf.org/wg/weirds/trac/ticket/25#)
>
> Text will be added to say that the server should return a 400 (Bad Request) error code.
>
>

This is already covered in draft-ietf-weirds-using-http-08
    5.4 Malformed Queries
    If a server receives a query which it cannot interpret as an RDAP
    query, it returns a 400 response code.  Optionally, it MAY include
    additional information regarding this negative answer in the HTTP
    entity body.

I'm not sure we should repeat the same requirement in another document. 
However, it would be worth expanding on this in the query doc by showing 
that

/domains?name=XXXX
returns a 404 if XXXX does not exist in the registry, but

/domains?names=XXXX
returns 400, since it has an invalid query parameter.

-Ernie

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 4 Jun 2014 16:20:09 +0000

> -----Original Message-----
> From: Ernie Dainow [mailto:[email-masked]]
> Sent: Wednesday, June 04, 2014 12:10 PM
> To: Hollenbeck, Scott; [email-masked]
> Subject: Re: [weirds] WEIRDS inactivity, and issues raised in London
> 
> 
> > 25. Clarify what is done with unsupported queries
> (http://trac.tools.ietf.org/wg/weirds/trac/ticket/25#)
> >

Agreed. I was planning to cite the using-http text to avoid replication.

> returns 400, since it has an invalid query parameter.

Describing a subset of the possible error conditions will only lead to questions about the errors we don't explicitly identify. I'd rather not do this.

Scott

---

From: Andy Newton <[email-masked]>
Date: Tue, 10 Jun 2014 15:37:10 +0000

On Jun 4, 2014, at 1:07 PM, Ernie Dainow <[email-masked]> wrote:

> I suggested that handles should be removed altogether from all RDAP queries and responses, both lookup and search.
> 

I strongly disagree.  Handles are identifiers found in many registries used a surrogate keys where a natural key does not make sense. I realize that for DNRs they seem less important, but they have important significance in the RIR world.

>    Each object class contains a "links" array ... (section 6. Object Classes)
> A link is a more convenient way to get the details of say an entity than having to do a lookup by handle. Handles are leftover from WHOIS which needs them since links are not provided.

I don’t see the point here. Handles are, in many cases, the identifier that will be used to construct the links.

> If we are to have handles in RDAP for consistency with WHOIS, then we should have search by handles, which is supported by WHOIS.

Lookups by handles are perfectly reasonable, but searches by handle do not make much sense as there is no defined structure for a handle other than they are suppose to be unique per registry. We shouldn’t use consistency as a reason to drop data registries currently have or to carry forward something that doesn’t make sense.

-andy

---

From: Andy Newton <[email-masked]>
Date: Tue, 10 Jun 2014 15:41:00 +0000

On Jun 4, 2014, at 1:20 PM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

However, it would be worth expanding on this in the query doc by
showing
that
/domains?name=XXXX
returns a 404 if XXXX does not exist in the registry, but

/domains?names=XXXX

I agree with Scott on this.

-andy

---

From: JF Tremblay <[email-masked]>
Date: Tue, 10 Jun 2014 15:36:40 -0400

> I strongly disagree.  Handles are identifiers found in many registries used a surrogate keys where a natural key does not make sense. I realize that for DNRs they seem less important, but they have…

Speaking as the former “registry-guy” at a large ISP (ARIN region), handle lookups and searches have been very useful to me in the past to track the tree structure of different ORG-IDs and resources. We had multiple organization handles from legacy (merger and al) and a fair number of POCs assigned to different internal groups. 

I second Andy in voicing support for handle queries, both lookup and searches. 

> Lookups by handles are perfectly reasonable, but searches by handle do not make much sense as there is no defined structure for a handle other than they are suppose to be unique per registry. We sh…

Although there isn’t a mandated structure in handles, wildcard searches are sometimes useful when memory fails and you only remember the beginning of a handle, or when it wasn’t noted properly in an external system such as an IP management software (speaking of experience).  

JF Tremblay
Viagénie

---

From: Naoki Kambe <[email-masked]>
Date: Wed, 11 Jun 2014 11:19:23 +0900 (JST)

From: Andy Newton <[email-masked]>
Date: Tue, 10 Jun 2014 15:41:00 +0000

> I agree with Scott on this.

I'm not sure this is directly related to this topic, but I have a
further question.

If it receives a query like the followings:

  /domains?name=example1.tld&name=example2.com&name=example3.com ..

  /nameservers?name=ns.example1.com&name=ns.example2.com&ip=192.0.2.1&ip=192.0.2.2 ..

should it return all matching results or a 400 error?

If the former case is correct, should it return results matching any
of the conditions or matching all of the conditions?

And should we explicitly document something about it?

Regards,

Naoki Kambe

---

From: 贾硕 <[email-masked]>
Date: Wed, 11 Jun 2014 10:57:08 +0800

I think we should only handle the first parameter, and ignore other
parameters.
If we really need more complex condition, it may be better by extending
search pattern, such as add 'OR' in conditions: 
	/domains?name=example1*.com OR example2*.com

Regards 
jiashuo

-----邮件原件-----
发件人: weirds [mailto:[email-masked]] 代表 Naoki Kambe
发送时间: 2014年6月11日 10:19
收件人: [email-masked]
主题: Re: [weirds] WEIRDS inactivity, and issues raised in London

> 
> On Jun 4, 2014, at 1:20 PM, Hollenbeck, Scott
<[email-masked]<mailto:[email-masked]>> wrote:
> showing that /domains?name=XXXX returns a 404 if XXXX does not exist 
> in the registry, but
> 
> /domains?names=XXXX
> Describing a subset of the possible error conditions will only lead to
questions about the errors we don't explicitly identify. I'd rather not do
this.
> I agree with Scott on this.

I'm not sure this is directly related to this topic, but I have a further
question.

/nameservers?name=ns.example1.com&name=ns.example2.com&ip=192.0.2.1&ip=192.0
.2.2 ..

If the former case is correct, should it return results matching any of the
conditions or matching all of the conditions?

Regards,

Naoki Kambe

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

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 11 Jun 2014 11:54:10 +0800

I think this a case of unknown parameters described in section 4.2 of http draft. 
The first parameter can be identified and other unknown parameters should be ignored.

Regards,

Linlin Zhou
 
From: Naoki Kambe
Date: 2014-06-11 10:19
To: weirds

 

 

 
Regards,
 
Naoki Kambe

---

From: Andy Newton <[email-masked]>
Date: Wed, 11 Jun 2014 13:01:40 +0000

On Jun 10, 2014, at 4:36 PM, JF Tremblay <[email-masked]<mailto:[email-masked]>> wrote:

Ok. That is a use case I had not thought imagined. Thanks. :)

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 11 Jun 2014 13:31:38 +0000

From: weirds [mailto:[email-masked]] On Behalf Of Andy Newton
Sent: Wednesday, June 11, 2014 9:02 AM
To: JF Tremblay
Cc: [email-masked]
Subject: Re: [weirds] WEIRDS inactivity, and issues raised in London - handles

Although there isn't a mandated structure in handles, wildcard searches are sometimes useful when memory fails and you only remember the beginning of a handle, or when it wasn't noted properly in an external system such as an IP management software (speaking of experience).

[SAH] So do you think this is something we should add, Andy?
Scott

---

From: Andy Newton <[email-masked]>
Date: Wed, 11 Jun 2014 17:05:30 +0000

On Jun 11, 2014, at 10:31 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

From: weirds [mailto:[email-masked]] On Behalf Of Andy Newton
Sent: Wednesday, June 11, 2014 9:02 AM
To: JF Tremblay
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [weirds] WEIRDS inactivity, and issues raised in London - handles

Or more specifically, leave it in. We already have entity searches by handle.

-andy

---

From: Ernie Dainow <[email-masked]>
Date: Fri, 13 Jun 2014 06:17:32 -0400

On 2014-06-10 11:41 AM, Andy Newton wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> Describing a subset of the possible error conditions will only lead 
>> to questions about the errors we don't explicitly identify. I'd 
>> rather not do this.
>

The argument to avoid "describing a subset of the possible error 
conditions" is contradicted by what is already in 
draft-ietf-weirds-using-http. Section 5 contains several sections 
covering a subset of HTTP errors, including 400 and 404.

Without further guidelines, there will be a lot of inconsistencies 
between implementations. In the last inter-op test there were a number 
of cases where XXXX was an invalid name (such as example...com) or an 
invalid UTF-8 representation. Some believed that 400 should be returned, 
others interpreted 404 as the proper error.

I suggest a statement to the effect that if the error is related to an 
invalid value of the parameter, 404 should be returned; but if the error 
is syntax or semantic (such as an invalid parameter), then 400 is returned.

If 400/404 are used consistently, this provides useful feedback to help 
diagnose the problem. 404 is due to the user input, whereas 400 is 
generally a fault in the client implementation.

-Ernie

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 13 Jun 2014 10:58:13 +0000

From: Ernie Dainow [mailto:[email-masked]]
Sent: Friday, June 13, 2014 6:18 AM
To: Andy Newton; Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [weirds] WEIRDS inactivity, and issues raised in London

/domains?names=XXXX

The argument to avoid "describing a subset of the possible error conditions" is contradicted by what is already in draft-ietf-weirds-using-http. Section 5 contains several sections covering a subset of HTTP errors, including 400 and 404.

Without further guidelines, there will be a lot of inconsistencies between implementations. In the last inter-op test there were a number of cases where XXXX was an invalid name (such as example...com) or an invalid UTF-8 representation. Some believed that 400 should be returned, others interpreted 404 as the proper error.

I suggest a statement to the effect that if the error is related to an invalid value of the parameter, 404 should be returned; but if the error is syntax or semantic (such as an invalid parameter), then 400 is returned.

If 400/404 are used consistently, this provides useful feedback to help diagnose the problem. 404 is due to the user input, whereas 400 is generally a fault in the client implementation.

[SAH] Then maybe this is an action for using-http, and not rdap-query.
Scott

---

From: Andy Newton <[email-masked]>
Date: Mon, 16 Jun 2014 12:30:09 +0000

On Jun 13, 2014, at 7:58 AM, Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:

Then maybe this is an action for using-http, and not rdap-query.

I’m fine with that. But as the text in using-http regarding this issue has been wordsmithed over and over again, I’m gonna request a “send text” for any mods to that draft.

-andy

---

From: Ernie Dainow <[email-masked]>
Date: Mon, 16 Jun 2014 11:36:10 -0400

Here is suggested wording for Section 5.4 containing one added paragraph.

5.4.  Malformed Queries

If a server receives a query which it cannot interpret as an RDAP query, it
returns a 400 response code.  Optionally, it MAY include additional
information regarding this negative answer in the HTTP entity body.

A 400 response code is returned to indicate a syntax or semantic error in
the query, such as an invalid parameter.  If the error is related to an
invalid value of a parameter, such as an invalid DNS name, 404 is returned.

-Ernie

On Mon, Jun 16, 2014 at 8:30 AM, Andy Newton <[email-masked]> wrote:

>
>  On Jun 13, 2014, at 7:58 AM, Hollenbeck, Scott <[email-masked]>
> wrote:
>
>  I’m fine with that. But as the text in using-http regarding this issue
> has been wordsmithed over and over again, I’m gonna request a “send text”
> for any mods to that draft.
>
>  -andy
>

---

From: Tom Harrison <[email-masked]>
Date: Mon, 23 Jun 2014 09:03:00 +1000

On Fri, Jun 13, 2014 at 06:17:32AM -0400, Ernie Dainow wrote:
> The argument to avoid "describing a subset of the possible error conditions"
> is contradicted by what is already in draft-ietf-weirds-using-http. Section
> 5 contains several sections covering a subset of HTTP errors, including 400
> and 404.
> 
> Without further guidelines, there will be a lot of inconsistencies between
> implementations. In the last inter-op test there were a number of cases
> where XXXX was an invalid name (such as example...com) or an invalid UTF-8
> representation. Some believed that 400 should be returned, others
> interpreted 404 as the proper error.
> 
> invalid value of the parameter, 404 should be returned; but if the error is
> syntax or semantic (such as an invalid parameter), then 400 is returned.
> 
> diagnose the problem. 404 is due to the user input, whereas 400 is generally
> a fault in the client implementation.

I think using 400 for all client errors is the better approach. Most
servers will return a description of the error in the body of the
response (as per json-response), so the interactive use case is
covered regardless of the error code, since the client program can
display that error description to the user. However, in the case where
the access is scripted/automated, or any other situation where the
only thing from the response that can be depended on is the status
code, it's more useful for 404 to be limited to the "valid query but
there's no record" scenario. 

For example, a user might have a scheduled script that fetches a
series of domain names, some being non-IDNs and some being IDNs. If
the script is not encoding the IDNs properly, then all of the IDN
requests would yield "not found", which would be quite a different
meaning in this case from any "not found" returned for a non-IDN. More
insidious would be a change in how the server processes queries on the
server side, such that a previously-valid request, returning a "not
found 404" or a successful response, starts returning a "client error
404".

-Tom