Subject: [weirds] Search Slides

From: Ning Kong <[email-masked]>
Date: Tue, 30 Jul 2013 23:36:12 +0200

Hi folks,

I just made the search slides for our F2F meeting based on the feedback from the mailing list. I hope we can get a consensus on #3 on the search slot.

Because we only have 10 minutes for the search topic, so I'm not going to discuss all the details of #2.

Any comments on the slides?

Cheers,
Ning

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Jul 2013 09:40:41 +0200

Hi Ning,

<co-chair>
I agree with your assessment of what you have as Question #1.  I suggest
dropping Question #1 from slide 2, and dropping slide 3 altogether, in the
interests of time compression.
</co-chair>

<participant>
Just to get my opinions out there on your remaining questions, hoping to
spark commentary tomorrow:

#2.1: I prefer either (a) selecting as searchable those properties that are
searchable now, or those that participants pledge to support, or (b) your
solution 2, where one could just try querying on any field and having some
specific response defined that means "you can't search on that".  I'm
guessing both are fairly straightforward in terms of specification and
implementation for both clients and servers.

#2.2: I don't believe I've heard of current or planned support for anything
but prefix matching, but I'm happy to be corrected.  I agree that paging
and ordering are open questions, and I believe that we should go with what
people have pledged to implement in co-ordination with what's currently
supported.

#2.3: Don't care.  Somebody pick one.

#2.4: I agree this part needs to be decided, but I have a feeling it's a
bigger issue than we'll have time for on Thursday.  This probably should be
developed on the list.

#3: The basic search function should be merged into the query and response
documents.  Advanced search can live separately, after the basic work is
done, if the WG has the energy and desire to pursue it.
</participant>

-MSK

On Tue, Jul 30, 2013 at 11:36 PM, Ning Kong <[email-masked]> wrote:

>
> Hi folks,
>
> I just made the search slides for our F2F meeting based on the feedback
> from the mailing list. I hope we can get a consensus on #3 on the search
> slot.
>
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>
>

---

From: Andy Newton <[email-masked]>
Date: Wed, 31 Jul 2013 08:24:15 +0000

Absent from this slide deck are questions about Internationalization issues and how to handle Unicode and IDN partial matching on characters that can be combined. This is a big part of search and needs to be teased out.

I'll throw in my $0.02 on the rest. Inline…

From: "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>

Just to get my opinions out there on your remaining questions, hoping to spark commentary tomorrow:

#2.1: I prefer either (a) selecting as searchable those properties that are searchable now, or those that participants pledge to support, or (b) your solution 2, where one could just try querying on any field and having some specific response defined that means "you can't search on that".  I'm guessing both are fairly straightforward in terms of specification and implementation for both clients and servers.

I don't think either a or b are mutually exclusive. I think it is best to define what is in use today but with a mechanism that is extensible for the fields we may want to add later.

#2.2: I don't believe I've heard of current or planned support for anything but prefix matching, but I'm happy to be corrected.  I agree that paging and ordering are open questions, and I believe that we should go with what people have pledged to implement in co-ordination with what's currently supported.

I agree with the planned support for prefix matching. However, we should define the syntax so that postfix and infix matching are reserved for future definition.

I consider paging and ordering to be advanced search features and they should be specified at a later date.

I much prefer the targeted path approach vs the generic path approach. It makes the syntax simpler, and it will be easier to define which fields are valid for search upon which object classes.

#2.4: I agree this part needs to be decided, but I have a feeling it's a bigger issue than we'll have time for on Thursday.  This probably should be developed on the list.

This goes along with 2.2. At present we only need to support a format for the simple functions so long as we have extensibility for the future enhanced features.

#3: The basic search function should be merged into the query and response documents.  Advanced search can live separately, after the basic work is done, if the WG has the energy and desire to pursue it.

I agree with this so long as we can come to agreement quickly on basic search. Otherwise it is holding up the work we have already done.

-andy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Jul 2013 10:34:58 +0200

On Wed, Jul 31, 2013 at 10:24 AM, Andy Newton <[email-masked]> wrote:

>
>  #3: The basic search function should be merged into the query and
> response documents.  Advanced search can live separately, after the basic
> work is done, if the WG has the energy and desire to pursue it.
>
>
>  I agree with this so long as we can come to agreement quickly on basic
> search. Otherwise it is holding up the work we have already done.
>
>
>
I'm not sure we should send up the query document without basic search in
it, and then immediately issue a document describing basic search that
amends query.  I think it's pretty integral to an overall syntax
specification.

What do others think?

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 31 Jul 2013 08:47:22 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, July 31, 2013 4:35 AM
To: Andy Newton
Cc: [email-masked]
Subject: Re: [weirds] Search Slides

On Wed, Jul 31, 2013 at 10:24 AM, Andy Newton <[email-masked]<mailto:[email-masked]>> wrote:

I'm not sure we should send up the query document without basic search in it, and then immediately issue a document describing basic search that amends query.  I think it's pretty integral to an overall syntax specification.
What do others think?

I tend to agree.

Scott

---

From: Andy Newton <[email-masked]>
Date: Wed, 31 Jul 2013 08:54:19 +0000

From: <Hollenbeck>, Scott Hollenbeck <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 31, 2013 10:47 AM
To: "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>, Andrew Newton <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [weirds] Search Slides

I tend to agree.

It extends the query syntax but does not amend it. And extensions to the query syntax are not only probable but intentional. If we are sending up the query doc as the final word on RDAP query syntax, then we have a much larger issue.

-andy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Jul 2013 11:02:09 +0200

On Wed, Jul 31, 2013 at 10:54 AM, Andy Newton <[email-masked]> wrote:

>   From: <Hollenbeck>, Scott Hollenbeck <[email-masked]>
> To: "Murray S. Kucherawy" <[email-masked]>, Andrew Newton <
> [email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>     I'm not sure we should send up the query document without basic
> search in it, and then immediately issue a document describing basic search
> that amends query.  I think it's pretty integral to an overall syntax
> specification.
>
> ****
>
> What do others think? ****
>
> ** **
>
> I tend to agree.
>
>
>  It extends the query syntax but does not amend it. And extensions to the
> query syntax are not only probable but intentional. If we are sending up
> the query doc as the final word on RDAP query syntax, then we have a much
> larger issue.
>
>  -andy
>

I realize it's an extension to something extensible (and something that's
technically overdue, though that's not a major point).  That's actually an
attractive aspect to separating them: It becomes an exemplar of how to
extend the basic query document.  However, the more important question to
me is really whether the work to extend rdap-query to add basic search is
so big as to be a setback on the order of months.  I don't believe it is,
but I also realize I say that as one of the people not doing the editing
work.  :-)

Also, there's a real possibility that if the query document goes out with
not even a hint of search, then that will be the common implementation.
This is especially true if, say, ICANN points only to the query document in
its own materials.  If we want to make sure search is at least visible as
an option to new implementers, hooking it into the base specification is an
important consideration.

-MSK, participatin'

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 31 Jul 2013 09:18:19 +0000

From: Andy Newton [mailto:[email-masked]]
Sent: Wednesday, July 31, 2013 4:54 AM
To: Hollenbeck, Scott; Murray S. Kucherawy
Cc: [email-masked]
Subject: Re: [weirds] Search Slides

I tend to agree.

Also agreed (sorry, I missed Murray's use of "amends"). We need to agree on where the line for the core minimum exists. I'd be OK with excluding simple search from rdap-query if we can agree on another way to document it.

Scott

---

From: Ning Kong <[email-masked]>
Date: Wed, 31 Jul 2013 14:00:11 +0200

Please find the modified version based on Murray's comments.

Ning

> Hi Ning,
> 
> <co-chair>
> I agree with your assessment of what you have as Question #1.  I suggest dropping Question #1 from slide 2, and dropping slide 3 altogether, in the interests of time compression.
> </co-chair>
> 
> <participant>

---

From: Ning Kong <[email-masked]>
Date: Wed, 31 Jul 2013 14:35:49 +0200

Hi Andy,

> Absent from this slide deck are questions about Internationalization issues and how to handle Unicode and IDN partial matching on characters that can be combined. This is a big part of search and n…
I agree that i18n issues are very important for search. Because of the 10 minutes limitation, I delete not only this part but also the security part from the search slides. If you or others strongly support discussing this part in tomorrow search slot, I'd like to add it into the slides. But I'm afraid we do not have enough time to focus on it.

> I consider paging and ordering to be advanced search features and they should be specified at a later date.
IMHO, ordering may be advanced. But I'm still not sure whether paging is advanced or basic. Let's assume paging is advanced and not supported by the first bundle of WG products, so I'm afraid that each RDAP server complying with RDAP core protocols has to provision a full answer within a single response even if the number of matched results is huge. Based on this scenario, I think paging or other function such as response number limit is necessary and should be basic.

Cheers,
Ning

---

From: Andy Newton <[email-masked]>
Date: Wed, 31 Jul 2013 12:50:35 +0000

From: Ning Kong <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, July 31, 2013 2:35 PM
To: Andrew Newton <[email-masked]<mailto:[email-masked]>>
Cc: "Murray S. Kucherawy" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [weirds] Search Slides

Hi Andy,

Given the past discussions on internationalization issues in this working group, I think it is a mistake to not make use of our face-to-face time to sort these matters out. If are this time constrained on issues that require high bandwidth interaction, the chairs should ask for another slot now.

That's a good use case, but in practical terms I doubt any server operator is willing to allow streaming of data so large as to enable data mining. So there is no real need for paging.

-andy

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 31 Jul 2013 13:00:29 +0000

Ning, none of the gTLDs I looked at this morning (com/net, org, biz) provide any kind of paging support. Do you know any registry operator that does? Does CNNIC? I can see suggesting a response limit, but if no one is doing paging now it’s more difficult for me to believe that it’s a much-needed core service.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ning Kong
Sent: Wednesday, July 31, 2013 8:36 AM
To: Andy Newton
Cc: [email-masked]
Subject: Re: [weirds] Search Slides

Hi Andy,

Cheers,
Ning

---

From: Andy Newton <[email-masked]>
Date: Wed, 31 Jul 2013 13:22:27 +0000

From:  <Hollenbeck>, Scott Hollenbeck <[email-masked]>
Date:  Wednesday, July 31, 2013 3:00 PM
To:  Ning Kong <[email-masked]>, Andrew Newton <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  RE: [weirds] Search Slides

>Ning, none of the gTLDs I looked at this morning (com/net, org, biz)
>provide any kind of paging support. Do you know any registry operator
>that does? Does CNNIC? I can see suggesting
> a response limit, but if no one is doing paging now it¹s more difficult
>for me to believe that it¹s a much-needed core service.
> 
>Scott
>

With regard to a response limit, I see value in a boolean noting that the
response has been limited in that a client can signal that it has
happened. Anything fancier will require a human to understand and such
text can simply be put into a notice (already defined in the current round
of drafts).

-andy

---

From: Ning Kong <[email-masked]>
Date: Wed, 31 Jul 2013 19:40:55 +0200

> Ning, none of the gTLDs I looked at this morning (com/net, org, biz) provide any kind of paging support. Do you know any registry operator that does? Does CNNIC? I can see suggesting a response lim…
No, I don't know either. CNNIC doesn't support such function.
I just think maybe there is a potential need for paging or response limit when more and more RDAP implementors coming up.

Cheers,
Ning