Subject: [Ietf-not43] IRIS general attribute searching and fetching

From: ehall at ehsco.com (Eric A. Hall)
Date: Sat Aug 30 09:49:47 2003

IRIS seems to only provide pre-defined 'named' searches, and does not
appear to provide a generalized "search this attribute for this value"
syntax. Is this correct? EG, ~finding all entries with a particular Post
Office Box as the registrant address is not possible unless and until a
'named' search for that is defined, and the nodes are extended to support
that search-type.

If this is correct, then searches for dynamic schema won't be feasible.
For example, a registrar cannot unilaterally offer value-added data until
everybody agrees on the 'named' searches that should be supported for the
class of data (even if the schema were extended, the data could not be
searched, so what's the point). This would be a fairly strict imposition,
since it would effectively prohibit registrars and registries (not to
mention resource operators) from offering their own sub-schema.

Also, IRIS does not appear to provide any syntax for a client to identify
a specific subset of attributes that should be returned in an answer set.
All answer data must always be provided, so there is no for (EG) a
government flunky to request ~only the domain name and email address for
all operators in Sweden.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Sat Aug 30 16:01:33 2003

> 'named' search for that is defined, and the nodes are extended to support

This is correct.  IRIS does not support a general query syntax.  That is 
not to say it cannot support a general query syntax, it is just that 
none has been defined.

Now for the philosophy:  most of th reasons why IRIS takes the approach 
it does are laid out in Appendix C. of the IRIS Core draft.  But here's 
the condensed version: 1) generalized query languages lend themselves to 
abuse and server operators tend to severly restrict which part of the 
language will be accepted and which will not, and 2) clients created for 
the specific problem domain often end up doing a considerable amount of 
translation between the user interface and the lowest-common denominator 
effect of a general query language.  This is laid out better in Appendix C.

> mention resource operators) from offering their own sub-schema.

It is always possible that if they were to define their own new schema, 
they could also define their own new searches taylored to their own set 
of problems.

Is this a strict imposition?  I can create a draft describing a 
generalized registry and we can see if there is demand for it.

> government flunky to request ~only the domain name and email address for

If the working group feels that such a feature is needed, it could 
easily be added.

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Sun Aug 31 00:12:28 2003

on 8/30/2003 3:01 PM Andrew Newton wrote:

> language will be accepted and which will not,

It's a lot easier to put limitations on the end-points than to remove
limitations from the protocol after-the-fact.

> and 2) clients created for 
> effect of a general query language.

Provide a default query for simple clients to use, like a default "find
domain-by-name" (or whatever), and let the power tools worry about the
complex syntax stuff. Difficulty can be selective.

> they could also define their own new searches taylored to their own set 

And then what? I don't see any text on how clients and servers would
negotiate over the extension queries. If you're really serious about a
query-service-that-isn't-really-a-query-service you'll need to provide
mechanisms for extension negotiation.

Then you'll need to convince client developers that it's in their best
interest to follow the development cycle at all ~250 top-level registries,
and that every named query should have a local implementation that is only
enabled when the associated TLD is hit. Don't forget the 2LDs!

OTOH, you could remove the arbitrary limitations and allow the nodes to
negotiate the supported syntax. If you were pursuing efficiency, that
would lead you to the CAPABILITIES model you dislike, but still, that's
more efficient than having each provider and server use different queries
and making clients track each of them separately.

Another concern that is probably more applicable to the folks who are
actually here is that the deployment difficulties make deployment a waste
of effort. Assume that some providers wants to provide something like an
expiration date attribute (or anything that isn't part of the core schema
anyway). If nobody can search against that data, then by definition the
data is only useful as supplementary information, and any value it does
end up having will be entirely accidental. That's no business case for
schema extension as a competitive tool.

This topic becomes much uglier once you get into other services. We know
that some domain/ip registries have different requirements (and will want
to maximize them) but this difference is nothing compared to the other
(potential) layered services. Who's going to work on directory-based
blacklists that can't be searched?

> If the working group feels that such a feature is needed, it could 

I guess it depends on what you think the value proposition is with XML.
>From a client perspective, the value is supposedly about the benefits that
are yielded from being able to integrate disparate data sources through a
(relatively) common syntax. Being able to limit query output to a few
precise columns and rows would further that benefit, in that it would be
easier to integrate the resulting data. From a provider perspective, using
the same tools is the value, but that doesn't demonstrably benefit the
user. I've said this before: the focus on short-term provider benefit is
ultimately the wrong area.

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Sun Aug 31 05:56:54 2003

> complex syntax stuff. Difficulty can be selective.

Like I said: I can create a proposal for a general query syntax and we 
can see if there is demand for it.

> mechanisms for extension negotiation.

Schema versions are negotiated via BEEP profiles.

> and making clients track each of them separately.

A capabilities list is not enough.  It will not provide a client the 
proper knowledge to rearrange dialog boxes or retool command line 
switches.  At best it will just allow them to grey-out entire categories 
of queries.

-andy

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Sun Aug 31 12:48:22 2003

> Schema versions are negotiated via BEEP profiles.

We're talking about extension negotiation, which is different from the
schema-version negotiation, and which is not discussed in the specs. You
are advocating the position that each server "can" define its own
searches, but you haven't described how clients are supposed to discover
the availability of these extensions on a per-partition or (more
importantly) a per-server basis.