Subject: [weirds] Search documents

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 Mar 2013 17:51:06 -0400

I didn't actually do a hum request in the session today, but there seemed
to be warm fuzzies in the direction of combining the search drafts into a
"basic" set of capabilities and an "extended" set.

Does anyone disagree with that being a reasonable path forward?  We can
select editors and such after we figure out a path here.

-MSK

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 12 Mar 2013 23:02:53 -0400

Le 2013-03-12 à 17:51, "Murray S. Kucherawy" <[email-masked]> a écrit :

> I didn't actually do a hum request in the session today, but there seemed to be warm fuzzies in the direction of combining the search drafts into a "basic" set of capabilities and an "extended" set.
> 
> Does anyone disagree with that being a reasonable path forward? 

My take is that we already have the "weirds" specification into many drafts, so one draft about search is more than enough. It is within that draft that I would see MUST, SHOULD, MAY for any search feature that is agreeable right now: i.e. the basic which would be either MUST or SHOULD and some common optional that would be MAY. Anything optional that does not reach concensus would be put aside for an "extension" draft, where the base draft will sketch how extensions should be done.

> We can select editors and such after we figure out a path here.

happy to help in editing/reviewing/...

Marc.

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

---

From: "John Levine" <[email-masked]>
Date: 13 Mar 2013 03:59:18 -0000

>"basic" set of capabilities and an "extended" set.

With the understanding that each set is standardized, and we do not expect
each registry to go inventing its own mutant search, I agree.

A quick look suggests that the range of search supported by current
registries is semantically quite small, although there are a lot of
different ways that people spell a wildcard.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 13 Mar 2013 11:01:51 +0000

Since I presented that proposal I'm going to confirm support for it.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Tuesday, March 12, 2013 5:51 PM
To: [email-masked]
Subject: [weirds] Search documents

Does anyone disagree with that being a reasonable path forward?  We can select editors and such after we figure out a path here.
-MSK

---

From: Ning Kong <[email-masked]>
Date: Wed, 13 Mar 2013 08:32:19 -0400

Shuo Shen and I would also like to contribute to this work.

Cheers,
Ning

在 2013-3-13，上午7:01，"Hollenbeck, Scott" <[email-masked]> 写道：

> Since I presented that proposal I’m going to confirm support for it.
>  
> Scott
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 13 Mar 2013 14:11:35 -0400

Any other opinions on this?  I think the answer here depends on how big a
unified (core plus extensions) search document would be.

On Tue, Mar 12, 2013 at 11:02 PM, Marc Blanchet
<[email-masked]>wrote:

> > I didn't actually do a hum request in the session today, but there
> seemed to be warm fuzzies in the direction of combining the search drafts
> into a "basic" set of capabilities and an "extended" set.
> >
> My take is that we already have the "weirds" specification into many
> drafts, so one draft about search is more than enough. It is within that
> draft that I would see MUST, SHOULD, MAY for any search feature that is
> agreeable right now: i.e. the basic which would be either MUST or SHOULD
> and some common optional that would be MAY. Anything optional that does not
> reach concensus would be put aside for an "extension" draft, where the base
> draft will sketch how extensions should be done.
>

---

From: Joseph Yee <[email-masked]>
Date: Wed, 13 Mar 2013 14:19:35 -0400

I support for two drafts instead of one.  If the intention is to
standardize how extended search be done, there would be several MUST,
SHOULD under the 'you MAY extend your search function this way'
section.  And I recalled from previous session that most agreed that
we don't stop at 'You MAY do paging' that clients need to recognize
dozen of paging styles.

Joseph

On Wed, Mar 13, 2013 at 2:11 PM, Murray S. Kucherawy
<[email-masked]> wrote:
> On Tue, Mar 12, 2013 at 11:02 PM, Marc Blanchet <[email-masked]>
> wrote:
>>
>>
>> agreeable right now: i.e. the basic which would be either MUST or SHOULD and
>> some common optional that would be MAY. Anything optional that does not

---

From: "John Levine" <[email-masked]>
Date: 13 Mar 2013 19:38:48 -0000

>we don't stop at 'You MAY do paging' that clients need to recognize

I would disagree.  Keeping in mind that we're defining a new
machine-to-machine protocol, which is not the same as any existing
machine-to-user imeplementation, if people want an option to return
results a page at a time, we should define exactly one such option.
Then servers and clients can implement it, we can test them, and there
is a reasonable chance that they will interoperate. That would not be
the case if the clients need to add different code for dozens or
hundreds of slightly different paging setups.*

I believe that there are a lot of current paging styles, but I would
be surprised if there were a lot of semantic variation.

R's,
John

* - says the guy with a WHOIS scraper script that is 3056 lines and
growing every week.

---

From: Andy Newton <[email-masked]>
Date: Wed, 13 Mar 2013 20:52:53 +0000

>be surprised if there were a lot of semantic variation.

I think there should be two documents, and here is why:

1. If the documents are combined, the basic search features will have to
wait on the advanced search features to be defined. Wasn't one of the
worries being able to show ICANN we could get this done?
2. It's not hard to imagine advanced search features that crop up in the
future, such as server-side filtering or geo-location searches. So we
could end up with multiple documents anyway.
3. When people talk about which features they support, a lot of times they
refer to RFC numbers. Being able to say clearly that an implementation
supports RFC XXXX usually helpful.

-andy

---

From: Joseph Yee <[email-masked]>
Date: Wed, 13 Mar 2013 17:13:13 -0400

> be surprised if there were a lot of semantic variation.

Wouldn't locking it to few agreed variations from the beginning a
better approach?  Paging is just one issue we discussed from previous
session, there are likely some other issues better get it spec out
now.

Joseph

---

From: "John Levine" <[email-masked]>
Date: 13 Mar 2013 22:37:52 -0000

>worries being able to show ICANN we could get this done?

I'd rather start with one document.  If we seem to be bikeshedding about
some of the options, we can split them into another document.

>supports RFC XXXX usually helpful.

There are a lot of standards with optional parts.  Supporting it means
you support all of the mandatory parts, and maybe the optional parts.

While it is certainly possible that people will provide a zillion
kinds of extremely clever sorts, I would push back hard at any that
haven't been at least approximately implemented, since history
suggests that purely paper designs usually remain that way.

---

From: "Linlin Zhou" <[email-masked]>
Date: Thu, 14 Mar 2013 10:44:07 +0800

I'd like to continue the search work after the path settled.

Linlin

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Murray S. Kucherawy
Sent: Wednesday, March 13, 2013 5:51 AM
To: [email-masked]
Subject: [weirds] Search documents

I didn't actually do a hum request in the session today, but there seemed to
be warm fuzzies in the direction of combining the search drafts into a
"basic" set of capabilities and an "extended" set.

-MSK