Re: [weirds] Lookups vs Searches (was Re: I-D Action: draft-hollenbeck-dnrd-ap-query-00.txt)

In the .CL case, we as a registry allow approximate search queries in
the domain name, and were thinking in something like

 /dnrd-ap/search/domain/by?name=<query>;match=begining

as we have 3 types of matching: begining (^query*), ending (*query$)
and in-between (*query*).

We know this is something unusual, so it's something we can cope with
a protocol extension.

Hugo

On 05/03/2012 08:29 PM, Francisco Arias wrote:
> In the context of queries, the complexity starts when we talk about
> searches as opposed to lookups. Perhaps we should separate those in two
> different drafts.
> 
> The lookup specification (draft-hollenbeck-dnrd-ap-query) already
> specifies a simple lookup mechanism for each object. I think it should
> stay that way.
> 
> The search specification (no I-D yet) would specify how to do searches
> that involve multiple search parameters and returns multiple objects
> (perhaps it should return references to objects). For example we could
> have something like:
> 
> /dnrd-ap/search/host/by?ip=1.2.3.4
> /dnrd-ap/search/domain/by?registrant_id=ABC123&nameserver=ns.foo.bar
> 
> What search parameters a registry/registrar supports over each object, or
> whether it implements searches at all, will be a registry/registrar's
> policy-maker decision.
> 
> Thoughts?
> 
> 
> __
> 
> Francisco.
> 
> 
> 
> 
> 
> On 5/1/12 10:19 AM, "Andy Newton" <andy@hxr.us> wrote:
> 
>>
>> On May 1, 2012, at 12:22 PM, Dave Piscitello wrote:
>>
>>> So we're clear, this increases the likelihood that other
>>> implementations than registry/registrar might extend the protocol in
>>> non-uniform manners. Would be nice to avoid but I'm not going to fall on
>>> my sword on this issue in this working group.
>>
>> Nobody knows if it increases the likelihood, but the probability of
>> protocol extensions is there any way. If we attempt to throw every
>> feature into the protocol now in fear of not being able to add extensions
>> later, then it is gonna be really difficult to get the first revision out
>> the door and thus will validate the fears of some of the critics of this
>> work.
>>
>> Maybe we should keep a list of features desired but not for the first
>> pass. Often the more complex use cases are clarified after an initial go
>> round with the base features.
>>
>> -andy
>> _______________________________________________
>> weirds mailing list
>> weirds@ietf.org
>> https://www.ietf.org/mailman/listinfo/weirds
> 
> _______________________________________________
> weirds mailing list
> weirds@ietf.org
> https://www.ietf.org/mailman/listinfo/weirds
> 