Metad BOF Tues 1:00, chair: Michael Mealling
Today talk was about problem space for the protocol then discuss interest in who
wants to work on protocol, with the intent to form a WG.
Trying to solve a range of problems using tools that we know work in certain areas.
First, a brief bit of background and discussion of the problem space:
For example, we've learned that objects can't be named by the same thing that use to
route to them via the query. This is an error in RWhois since we want objects to exist
in different hierarchies.
Both RWhois and Whois++ needed things from each other and both needed things the
other didn't have, e.g. integrating new features such as URIs as identifies, MIME,
XML, MIME-DIR.
Current view: a lightweight, generic, query protocol for as many different applications
as possible.
Lightweight =maintaining the feature of connecting to a port and typing a query and
receiving a reply.
Example applications: gateways to existing indexes, TF-CHIC, Harvest, Z39.50; status
server (weather), metadata server.
Data/Query Requirements:
- Template-oriented and complex format representation for the data
- Ability to support but not require hierarchical data
- Support for query routing in loosely federated systems
- Full-query searching
- Support for std security, authentication, and updates.
Some basic requirements:
- Protocol should be internationally applicable (e.g. support multiple char sets)
- Security should support some subset of authentication, ACLs, encryption, etc.
- Scalable to the Internet. Able to use off the shelf software.
Nothing currently gives us all these requirements in the same protocol. So, we need
something new. Today we decide if we should have a WG to come up with something
to meet these requirements.
Want to use programs that already exist, but want to avoid becoming a dumping
ground for everyone's wish list. Should include extensibility so new features can be
included later.
Question regarding why LDAP doesn't meet the needs. Basically, LDAP tackles
specific problems, but not all the ones this group would address. For example, we
expect new protocol to be able to integrate Harvest servers and other gateways into
the same system without or with few changes to the underlying protocol. So we want
to support a larger group of info services that would not be adaptable to LDAPs focus
on traditional directory-types of info rather than just general information services.
What does text-based protocols mean? Means can telnet to the port and use ASCII to
query and then get the results.
Seems to relate to pipr group. Chair will scope that out too. And also one group that
there is much in common with is DASL. But DASL is not looking at server to server
communication but there is synergy there. Check out
http://www.ics.uci.edu/pub/ietf/dasl/.
Question: why not put up a web page directing to proper search server if the client
would be so simple?
Client is small, but service in general means creating an application that would allow
integration of a simple client interface (possibly in parallel with a richer client as well).
Examples of real world scenarios?
The client isn't always a human. The client is just something that talks to a remote
service to get an answer and the answer may be almost any type of information. For
example, you may query for status information relevant to an application to frame
interactions with a remote info server. Can create a standardized framework for
expressing queries and getting information back. Also, protocol would not just be
client to server but also server to server. Check out CIP RFCs, etc.
Could DASL be used as a superset of this new protocol? Seems DASL is not talking
about server to server. New protocol could be used to talking to multiple DASL
servers. Not sure of the exact relationship between the two, but will continue the
conversations between the two.
Do you anticipate the protocol handling updates? That goes back to event notification.
Probably no limitations on that, but protocol should be able to handle updates in some
capacity.
Comment: Problem with scope of problem space. Seems to overlap with LDAP and
ACAP. Point is, you can access directory info through this, but more interesting in
backend access and routing the information. Comment: you need to be clear as to
what kind of data objects you will be accessing. Reply: looking at dealing with
objects in the directory being more like web objects than white pages objects.
Comments: use different word than 'directory'. Oy, rat hole.
Given metadata, what do you do with it? How do you pass it around? What are the
server-to-server semantics? These questions are not yet answered by other groups, and
must be scoped before this group could address them. Need some terminology for
expressing these semantics clearly.
Transport problem: how get queries between thing.
Schema problem: how code schema queries. And some way of getting data back.
Third problem: how do you route queries? This group seems to be trying to tackle all of
these. Each problem has pieces that exist, but they are separable. (Chair disagrees.)
Overloading the problem space. Reply is that the solutions may be separable, but the
requirements are not orthogonal. The solutions may look separate, but the reason for
choosing particular solutions over others depends on how the problems are related.
However, separating things makes them easier to work on, e.g. separating transport
and content is valuable. Yes, true, but things do need to be linked to make sure the
solutions are adequate for the entire problem space.
Do we need data descriptions? This is a huge problem space. Part of it is a follow-up
to CIP, but adds mesh traversal. This solution would benefit other efforts as well, so
possibly narrow the problem to something like that. So do groups as serial entities to
solve parts of the problem one at a time. Reply makes the point that we are not starting
from scratch; many parts already exist. Based on experience we have and changes that
have just come about throughout the Internet, solutions are possible today that were not
possible before. The scope of the problem is large, but much of the solution components
are already there.
Is there enough interest to form a working group? Do people think this should be a
WG? Can the scope be clearly defined at this point? Seems that there is work to be
done before the scope is really clear. What did audience want from session? What
would they see as useful? One perception is that few people have a clear grasp of this
problem. So one option is to get the results of Finding Stuff, which can be done
quickly, and would help clarify the issues for others, which would help this group get
the base of clarity it needs. Finding Stuff will publish taxonomy as probably a BCP.
InterNIC: at one point there will be no central NIC. All registries are being distributed,
which makes it hard to find anything in particular. Wanted is a seamless way to
navigate hierarchies so end user can find and display info easily.
One point: this may be too late.
What next?
Chair suggestion: have mailing list: metad@bunyip.com. Please join and bash out
the scope. Join via metad-request@bunyip.com ( a majordomo list). However, don't
want to talk about feature bashing, want to think about the scope. Possibly get a draft
and problem description done by next IETF and do another BOF or WG. Cannot do a
WG right now. Many feel that there is an important problem (given a show of hands)
that should be tackled by IETF, although the problem is not clear. About the same
number are willing to devote time to solving the problem. 'Time' is weekly
teleconferences for editors. AD agrees must narrow scope, probably by cutting out
features, even if that cuts the interest of some people. May or may not have another
BOF, depends on getting a clearer, narrower scope.
None Received