Selected Books:


Buy this book!




Buy this book!




Buy this book!




Buy this book!




Buy this book!



German speakers - order books from amazon.de!

Books to UK - order books from amazon.co.uk!

The Online Requests For Comments - RFCs

Home | Books | Bookmark! | Link to Us | Help

RFC 2259 


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.

Abstract

   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
                    query.
      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
                    server.
      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
   considerations.

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 nomen.research.bell-labs.com 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 nomen.research.bell-labs.com 4224
      Trying 135.104.70.9...
      Connected to nomen.research.bell-labs.com.
      Escape character is '^]'.
      220 nomen.research.bell-labs.com Nomenclator Query Service ready

      relations
      211-There is 1 relation defined:
      211 People

      attributes People
      212-There are 20 attributes in relation "People":
      212-Given_Name
      212-Middle_Name
      212-Surname
      212-Name_Suffix
      212-Title
      212-Organization
      212-Division
      212-Department
      212-Building
      212-Street
      212-City
      212-State_or_Province
      212-Postal_Code
      212-Country
      212-Phone
      212-Fax
      212-Email
      212-MHSmail
      212-Last_Modified
      212 Source


                       Figure 1a: New User Queries Server

   ---------------------------------------------------------------------












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


   ---------------------------------------------------------------------

      query
      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
      Email: joann@bell-labs.com
      Source: nomen://bell-labs.com:17036/email=joann@bell-labs.com

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

      quit
      221 nomen.research.bell-labs.com closing transmission channel

      Connection closed by foreign host.


                      Figure 1b: New User Queries Server
                                 (continued)

   ---------------------------------------------------------------------

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
      Email: joann@bell-labs.com

      .
      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
   3.

   ---------------------------------------------------------------------

      imagui
      214 GUI responses enabled

      query
      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.

      query
      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 



RFC Search. Copyright ©1999 by Dodoland Co.
Web design ©1999 by WebYou.com


Selected Books:


Buy this book!



    
Buy this book!



    
Buy this book!



    
Buy this book!



    
Buy this book!