Subject: [weirds] Search documents

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 28 Mar 2013 03:57:52 +0100

The Orlando minutes reflect that we batted around some ideas about how to
move forward with documents covering the topic of search, but the issue
wasn't formally resolved.  I'd like to take a moment to have that
discussion now.

The idea I thought had general support based on the working group and some
hallway chatter afterwards is the notion of creating two search documents,
one covering basic or core search syntax and capabilities, and one covering
extended search.  John Levine remarked that the former would generally try
to match the search capabilities that WHOIS servers offer now while the
latter would cover things we'd like to see, and there would be some
pressure to have implementation experience with the proposals of the latter
before we let the document proceed.

Can we get some indications of support or objection to proceeding that way?

-MSK

---

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

>Can we get some indications of support or objection to proceeding that way?

Steve Sheng and I have an informal work item to survey the existing
WHOIS servers to see what core search would involve.

I've been looking at some ccTLDs and for the few I've found that
provide any search at all, it's pretty simple. You give it a string
and an entity type (domain, nameserver, registrar, etc.) and it tells
you the entities whose names that start with the string, limited to a
small number of results if your string matches a lot of names.

R's,
John

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 28 Mar 2013 14:12:17 +0000

I support proceeding this way.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, March 27, 2013 10:58 PM
To: [email-masked]
Subject: [weirds] Search documents

The Orlando minutes reflect that we batted around some ideas about how to move forward with documents covering the topic of search, but the issue wasn't formally resolved.  I'd like to take a moment to have that discussion now.
The idea I thought had general support based on the working group and some hallway chatter afterwards is the notion of creating two search documents, one covering basic or core search syntax and capabilities, and one covering extended search.  John Levine remarked that the former would generally try to match the search capabilities that WHOIS servers offer now while the latter would cover things we'd like to see, and there would be some pressure to have implementation experience with the proposals of the latter before we let the document proceed.
Can we get some indications of support or objection to proceeding that way?
-MSK

---

From: Arturo Servin <[email-masked]>
Date: Thu, 28 Mar 2013 11:34:49 -0400

I support this way forward.

Regards,
as

On 3/27/13 10:57 PM, Murray S. Kucherawy wrote:
> The Orlando minutes reflect that we batted around some ideas about how
> to move forward with documents covering the topic of search, but the
> issue wasn't formally resolved.  I'd like to take a moment to have that
> discussion now.
> 
> The idea I thought had general support based on the working group and
> some hallway chatter afterwards is the notion of creating two search
> documents, one covering basic or core search syntax and capabilities,
> and one covering extended search.  John Levine remarked that the former
> would generally try to match the search capabilities that WHOIS servers
> offer now while the latter would cover things we'd like to see, and
> there would be some pressure to have implementation experience with the
> proposals of the latter before we let the document proceed.
> 
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>

---

From: Kaveh Ranjbar <[email-masked]>
Date: Thu, 28 Mar 2013 16:42:03 +0100

I support the proposed path forward.

Regards,
Kaveh.

---

From: Alan Maitland <[email-masked]>
Date: Thu, 28 Mar 2013 13:11:13 -0600

This appears to make good sense.

> Can we get some indications of support or objection to proceeding that way?

Could or should the registries then choose to implement their wierds 
systems in a phased approach?

In other words, if registries were to roll wierds using the two document 
strategy, then the whois functionality gets replaced and people can 
begin to develop and test implementations of the "whois like" wierds 
client code, which presumably would be a bit easier to implement.

This strategy might suggest a first document being a wierds v1.0 spec 
with the second being a wierds v1.1 spec, but releasing both specs 
pretty much in coterminous manner and referencing each other, with the 
understanding that implementers are not fully wierds compliant unless 
and until they have rolled out their v1.1 service. Is that the idea?

Alan

---

From: Andy Newton <[email-masked]>
Date: Thu, 28 Mar 2013 21:29:52 +0000

From: "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 27, 2013 10:57 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [weirds] Search documents

-MSK

I'm support having two documents, one for basic/core search and one for advanced/extended search.

-andy

---

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

Alan,

Just to be clear, the core search document is not the entire WEIRDS
specification.  There are currently a set of five documents in total that
describe WEIRDS.  The two we're talking about here only describe the search
capability which is part of a larger whole.  I believe the intent would be
that all WEIRDS implementations would have to comply with the core search
document (in addition to the others already in the set), and then could
optionally also implement what the extended search document describes.

Someone should yell now if that doesn't match what everyone else is
thinking.

-MSK

On Thu, Mar 28, 2013 at 8:11 PM, Alan Maitland <[email-masked]>wrote:

> strategy, then the whois functionality gets replaced and people can begin
> to develop and test implementations of the "whois like" wierds client code,
> which presumably would be a bit easier to implement.
>
> This strategy might suggest a first document being a wierds v1.0 spec with
> the second being a wierds v1.1 spec, but releasing both specs pretty much
> in coterminous manner and referencing each other, with the understanding
> that implementers are not fully wierds compliant unless and until they have
> rolled out their v1.1 service. Is that the idea?
>
> Alan
>
>
>
> ______________________________**_________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/weirds<https://www.ietf.org/mailman/listinfo/weirds>
>

---

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

From: "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, March 28, 2013 10:28 PM
To: Alan Maitland <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] Search documents

I believe the intent would be that all WEIRDS implementations would have to comply with the core search document (in addition to the others already in the set), and then could optionally also implement what the extended search document describes.

I think we need to be careful with the first part of you sentence. Not all searches apply equally across the space so "comply" might have multiple meanings to multiple people. For example, a partial word match for domain names makes a lot of sense in the DNR area as they deal with forward DNS, but it doesn't seem particularly interesting in the RIR area with reverse DNS. No matter basic or advanced search, there needs to be proper signaling from a server to a client say "I don't support that".

-andy

---

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

>I believe the intent would be that all WEIRDS implementations would have to comply
>with the core search document (in addition to the others already in the set), and
>then could optionally also implement what the extended search document describes.

So long as comply with means understand the syntax of rather than
implement the semantics of, I think we're OK.

There are plenty of ccTLD WHOIS servers that provide no search at all,
and I don't expect that to change.  An implementation that returned
"403 No search for you" to any search request would comply.

---

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

Thanks for the corrections.  I think we're still in the ballpark I was
intending; a base WEIRDS implementation would have to do what the basic
search document says even if that means a way to reply "I don't support
that search", while the same implementation could completely ignore the
extended search document's ideas.  We might want to have the capability to
ask a WEIRDS server for a capabilities list.  Would that be hard to add to
the documents we have now, or is it already in there someplace?

-MSK

---

From: Andy Newton <[email-masked]>
Date: Fri, 29 Mar 2013 20:19:05 +0000

From: "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>
Date: Friday, March 29, 2013 3:29 PM
To: John Levine <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] Search documents

Thanks for the corrections.  I think we're still in the ballpark I was intending; a base WEIRDS implementation would have to do what the basic search document says even if that means a way to reply "I don't support that search", while the same implementation could completely ignore the extended search document's ideas.  We might want to have the capability to ask a WEIRDS server for a capabilities list.  Would that be hard to add to the documents we have now, or is it already in there someplace?

No, there is no capabilities query. It is easy enough to add with a new path in the unified-queries document and a simple JSON object containing only the rdapConformance structure would satisfy it.

However, how granular do you want to go with this? Should support for each query path be listed? With regards to search, should partial matching on prefixes be listed separately from partial matching on suffixes? How complicated do we want to get with it?

Also, what does a client really do with this information? Do we envision the client asking for capabilities first and the making a yes/no decision about issuing a query? I would think the interaction pattern would actually be that the client issues the query regardless, and if it gets back an "I don't do that" message it reports that back. Fewer round trips and less logic.

It also strikes me that if we don't have a clear idea of what we want with a capabilities query, we can always add it later when we have a much better idea.

On Fri, Mar 29, 2013 at 6:27 PM, John Levine <[email-masked]<mailto:[email-masked]>> wrote:

[..snip..]

Do we need to add this to draft-ietf-weirds-using-http? Even with lookups it is unlikely that DNRs will support IP address and ASN lookups.

-andy

---

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

> Also, what does a client really do with this information? Do we envision 
> the client asking for capabilities first and the making a yes/no 
> decision about issuing a query? I would think the interaction pattern 
> would actually be that the client issues the query regardless, and if it 
> gets back an "I don't do that" message it reports that back. Fewer round 
> trips and less logic.

That was my thought.  I really don't want WEIRDS to end up as complicated 
as IMAP, or even as POP.  Ask a question, either you get the answer or you 
don't, and a relatively smart client might remember not to ask the kinds 
of questions that have gotten rejected before.

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

---

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

> >I believe the intent would be that all WEIRDS implementations would
> >have to comply with the core search document (in addition to the others
> >already in the set), and then could optionally also implement what the
> extended search document describes.
> 
> There are plenty of ccTLD WHOIS servers that provide no search at all, and I
> don't expect that to change.  An implementation that returned

[Alexander Mayrhofer] 
I think we need to go one step further - *any* type of search needs to be OPTIONAL (allowing servers to return eg. 404 for the respective path, rather than 403) in order to gain broad adoption. 403 could be interpreted as "oh, i just need a different identity or trust relation with the operator in order to gain access", which could be dangerously misleading. 

Alex

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2013 21:50:44 -0000

>I think we need to go one step further - *any* type of search needs to be OPTIONAL (allowing
>servers to return eg. 404 for the respective path, rather than 403) in order to gain broad
>adoption. 403 could be interpreted as "oh, i just need a different identity or trust relation with
>the operator in order to gain access", which could be dangerously misleading. 

>From RFC 2616:

 10.4.4 403 Forbidden

   The server understood the request, but is refusing to fulfill it.
   Authorization will not help and the request SHOULD NOT be repeated.

There are HTTP codes that mean you can get the answer with more
authority, but 403 is not one of them.