Network Working Group                                         J. Elliott
Request for Comments: 2259                      Epic Systems Corporation
Category: Informational                                       J. Ordille
                                          Bell Labs, Lucent Technologies
                                                            January 1998

                Simple Nomenclator Query Protocol (SNQP)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


   The Simple Nomenclator Query Protocol (SNQP) allows a client to
   communicate with a descriptive name service or other relational-style
   query service.  The protocol is useful to services that search many
   data repositories for query responses.  Clients can pose queries on
   relations, list descriptions of relations, and obtain advice on
   reducing the search time and cost of their queries.  Clients are
   informed of the age of information in caches, and may request more
   recent information.  SNQP provides support for graphical user
   interfaces.  It also supports different types of comparison
   operators, so services can use SNQP with a variety of back-end
   servers, e.g. relational database servers, CCSO servers, and servers
   providing relational views of X.500.

   SNQP is an ASCII protocol in the request-reply style of SMTP.  It was
   specifically designed for use with the Nomenclator name and
   information service, and has been useful elsewhere.

1. Introduction

   The Simple Nomenclator Query Protocol (SNQP) is a protocol for
   querying servers that search collections of data repositories.  Users
   retrieve information from an SNQP server by describing attributes of
   the information.  SNQP servers contact one or many data repositories
   to retrieve the response to a user query.  If the data repositories

Elliott & Ordille            Informational                      [Page 1]
RFC 2259                          SNQP                      January 1998

   differ in protocol or data format, it is responsibility of the SNQP
   server to translate protocols and data formats to provide one,
   integrated answer to the user's query.

   SNQP servers share the protocol needs of centralized data
   repositories that answer queries with locally stored data.  SNQP
   servers also require specialized protocol features due to their
   distributed search characteristics.

   In highly distributed environments, it is unreasonable to expect all
   data repositories that need to be searched to be available when
   queries are posed.  SNQP servers require facilities for returning
   partial results in the presence of communications errors with data
   repositories.   The partial results must indicate how to resubmit the
   query only to those data repositories that are unavailable.

   In addition, users may pose queries without realizing the cost of the
   search for query responses.  SNQP provides facilities for informing
   users of query costs and advising them on limiting that cost.  Costs
   and advice are returned before queries are executed.

   Finally, SNQP servers may cache data and meta-data to speed query
   responses.  Servers can inform users of the t-bound for their query
   response.   A t-bound is the time after which changes may have
   occurred to the data that are not reflected in the query response
   [6,2].  A t-bound is the time of the oldest cache entry used to
   calculate the response.  Users can request that query responses are
   more current then a particular t-bound.  Making such a request
   flushes older items from the cache.

   SNQP provides support for graphical user interfaces.  It also
   supports different types of comparison operators, so SNQP servers can
   query a variety of back-end data repositories, e.g. relational
   databases, CCSO servers [3], and servers providing relational views
   of X.500 [10].

   SNQP is a connection-oriented protocol.  A client initiates a query
   session with an SNQP server by making a TCP connection to a well-
   known port.  The client then executes a series of SNQP commands.
   These commands are listed briefly in Table 1.  Section 2 provides
   some typical scenarios for using these commands, and Section 3
   describes the commands fully.  The server replies to each command
   using the theory of reply codes described for the Simple Mail
   Transfer Protocol (SMTP) [9]. The theory of reply codes and the
   defined reply codes are described in Section 4.

Elliott & Ordille            Informational                      [Page 2]
RFC 2259                          SNQP                      January 1998

      Command       Description
      advice        Provide advice on query costs without executing
      attributes    List the attributes for a relation.
      compare       Set type of comparison operation.
      help          Explain the SNQP commands.
      imagui        Format replies for a graphical user interface.
      next          Stop processing current query, continue with next
                    query in block.
      noadvice      Provide responses to queries.  Do not advise
                    on costs.
      noimagui      Format replies for people.
      query         Submit a block of one or more SQL query statements.
      relations     List the relations available through the SNQP
      stop          End processing of current query, and cancel any
                    queries remaining in block.
      quit          Terminate the query session.

                         Table 1: SNQP Commands


   SNQP queries are posed in SQL, a standard relational database query
   language [4,12].  Information that is obtained through SNQP servers
   is organized by type into database relations.  SQL queries may often
   have more functionality then a server supports or an application
   demands.  Moreover, advice on query costs, some types of comparison
   operations or t-bounds may not be supported by a particular server.
   SNQP defines a minimal subset of functionality for a working SNQP
   protocol.  Functionality beyond this subset is optional.  Servers
   that do not support optional functionality must return replies that
   indicate this to the user.  The required and optional features of
   SNQP are summarized in Section 5.

   SNQP was specifically designed for use with the Nomenclator name and
   information service [8,7,5].  Nomenclator produces query responses by
   integrating information from data repositories with different
   protocols and data formats.  It constrains the searches for query
   responses through a variety of distributed indexing techniques.  SNQP
   has also been found useful elsewhere, even as a query language for a
   single data repository.

   SNQP is defined for US-ASCII only, and use with other character sets
   will require further work.

Elliott & Ordille            Informational                      [Page 3]
RFC 2259                          SNQP                      January 1998

   Section 6 concludes this document with a description of security

2. Scenarios

   This section illustrates the basic SNQP commands by presenting
   several client scenarios.  The scenarios include a new user, a user
   who prefers CCSO style comparisons and more current responses, a
   graphical user interface program, a user with a change of mind, and a
   user worried about costs.  Although SNQP will work for a human client
   on a bare connection (like one provided by telnet), it also works for
   client programs.  Several of these programs have been written and
   provide enhanced interfaces.

2.1 New User

   A new SNQP user will first make a tcp connection to an SNQP server.
   For purposes of illustration, we will assume that the user makes the
   connection with the Unix telnet command, and that the server is
   located at on port 4224. The user enters
   a relation command to discover what relations are available, and an
   attributes command to discover the attributes for a particular
   relation.  The user eventually asks for people with a given name of
   "J*" and a surname of "Ordille" who work for "Lucent Tech*". The
   response is current through June 11, 1996 at 11 p.m. EDT.  Figure 1a
   and Figure 1b provide this scenario.

Elliott & Ordille            Informational                      [Page 4]
RFC 2259                          SNQP                      January 1998


      > telnet 4224
      Connected to
      Escape character is '^]'.
      220 Nomenclator Query Service ready

      211-There is 1 relation defined:
      211 People

      attributes People
      212-There are 20 attributes in relation "People":
      212 Source

                       Figure 1a: New User Queries Server


Elliott & Ordille            Informational                      [Page 5]
RFC 2259                          SNQP                      January 1998


      350 Send the query text, end with .

      select * from People where
             given_name = "J*" and surname = "Ordille" and
             organization = "Lucent Tech*";
      351 Partial response follows, ended with .

      Given_Name: Joann
      Middle_Name: J.
      Surname: Ordille
      Title: MTS
      Organization: Lucent Technologies
      Division: Bell Laboratories
      Department: Computing Sciences Research Center
      Building: 2C-301
      Street: 700 Mountain Avenue
      City: Murray Hill
      State_or_Province: New Jersey
      Postal_Code: 07974
      Country: United States
      Phone: +1 908 582 7114
      Source: nomen://

      250 All queries processed.  Current through 11-Jun-1996 23:00 EDT.

      221 closing transmission channel

      Connection closed by foreign host.

                      Figure 1b: New User Queries Server


2.2 User with CCSO and Currentness Preferences

   A user who is accustomed to CCSO name servers prefers CCSO word-based
   matching within attribute strings.  Each word in the query string for
   an attribute must appear in some order in the response string.  The
   wildcard "*" matches any substring within a word.  The default

Elliott & Ordille            Informational                      [Page 6]
RFC 2259                          SNQP                      January 1998

   matching, illustrated in Figure 1b, is exact matching of a query
   string.  The query string may include "*" wildcards which match any
   substring within the response string.  Both types of matching are
   case insensitive.

   In Figure 2, the CCSO-style user connects to the SNQP server, enables
   csso matching, and requests some information about Ordille who works
   in research at a lab division of some company.  The request asks for
   information that is more current than June 11, 1996 at 11 p.m. if it
   is available.


      compare ccso
      213 Performing ccso equality comparisons

      query 11-Jun-1996 23:00
      350 Send the query text, end with .

      select given_name, surname, organization, division, department,
             email from People
             where surname = "Ordille" and department = "research"
             and division = "lab*";

      351 Partial response follows, ended with .

      Given_Name: Joann
      Surname: Ordille
      Organization: Lucent Technologies
      Division: Bell Laboratories
      Department: Computing Sciences Research Center

      250 All queries processed.  Current through 12-Jun-1996 22:35 EDT.

             Figure 2: User with CCSO Preferences Queries Server


2.3 Graphical User Interface Program

   A user designs a Windows program as a front end to the SNQP server.
   In Figure 3, the program requests replies formatted for a graphical
   user interface program.  The program submits two SQL queries, and

Elliott & Ordille            Informational                      [Page 7]
RFC 2259                          SNQP                      January 1998

   receives detailed responses that indicate the type and position of
   errors.  The error messages are discussed in more detail in Section


      214 GUI responses enabled

      350 Send the query text, end with .

      select * from Peple where name = "Elliott";
      735 00000001a000015 e Unknown relation, "Peple"

      735 00000001a000027 e Attribute "name" not found in any relation used.

      250 All queries processed.  Current through 12-Jun-1996 22:35 EDT.

      350 Send the query text, end with .

      select * from People wher surname = "Elliott";
      730 00000001a000022 e syntax error

      730 00000001a000027 e syntax error

      730 00000001a000037 e syntax error

      730 00000001a000039 e syntax error

      250 All queries processed

       Figure 3: Graphical User Interface Program Queries Server


2.4 User Changes Mind

   An exuberant user decides to search everywhere for family members,
   then look up a friend who works at Epic Systems, and finally search
   everywhere for an old school friend.  Once the query set starts, the
   user realizes the folly of searching everywhere, stops the first

Elliott & Ordille            Informational                      [Page 8]
RFC 2259                          SNQP                      January 1998

   query, executes the second query and then stops executing the query
   block.  This scenario is illustrated in Figure 4.  The t-bound is
   represented by