Network Information Query Server 2.0 Protocol

Last Modified: $Date: 2001/04/19 19:22:39 $
ID: $Id: NIQSProtocol_2_0.html,v 1.4 2001/04/19 19:22:39 alainc Exp $
Author: Dan Kha Pham (danp@zeroknowledge.com)
Maintainer Dan Kha Pham (danp@zeroknowledge.com)
Reviewers: Daniel Faguy (danielf@zeroknowledge.com)
Revision History: October 18th, 2000: Creation

Contents

   1. INTRODUCTION
   2. COMMANDS AND MESSAGE FORMAT
   3. REFERENCES TO IMPLEMENTATIONS AND API
   4. KNOWN ISSUES


1. INTRODUCTION

1.1 PURPOSE

The main purpose of this document is to describe the Network Information Query Server (NIQS) 2.0 protocol.


1.2 SCOPE

This document covers a description of the NIQS protocol, the format of the messages, the commands and some known issues. It does NOT cover the implementation of this protocol.


1.3 OVERVIEW

The NIQS 2.0 protocol is a connection-oriented application level protocol which lies on top of (uses) the Zero-Knowledge Interactive Protocol (ZKIP). All NIQS responses are signed by the NIQS's key.


2. COMMANDS AND MESSAGE FORMAT


The following commands from the NIQS 1.0 Protocol are no longer part of the preferred set of commands in the NIQS 2.0 protocol; although still part of the NIQS 2.0 protocol, they might not be included in the next version:
 - List
 - Available
 - Status
 - Query
 - AccessCtrlList


2.1 Welcome Banner

  2.1.1 Description
  The welcome banner is the message which confirms the initialization of the connection/session to the NIQS. All further responses from the server will contain information as in the Network Information Database (NIDB) at the connection time, and are associated with a cache data version (CDV) bumber.

  2.1.2 Response
  0 0.1.0 220 NODATA BINARY 0 "Zero-Knowledge Network Information Query Server (NIQS) (date, time)"\r\n


2.2 MxQuery

  2.2.1 Description
  The MxQuery command queries for a list of description of entities within the NIDB. It is functionally equivalent to the combination of a LIST (protocol V1.0) command followed by a serie of QUERY DESCRIPTION (protocol V1.0) commands for each element of what result from the previous LIST command. The resulting information is packed and returned within a single response, either compressed or not.

  2.2.2 Command
  0 7.1.0 mxquery nodata binary 0 description 0 none|bzip2 [entity_list]\r\n

  2.2.3 Response
  0 7.1.0 220 NODATA BINARY 2210 "MxQuery Response" mxquery_response\r\n.\r\n


2.3 Cache Data Version

  2.3.1 Description
  The CDV command queries for the cache data version as is in the NIDB at the connection time. This version number tags and identifies the information returned during this particular session. The NIQS returns pre-signed responses from its cache till the CDV is manually changed in the NIDB.

  2.3.2 Command
  0 7.1.0 cacheversion nodata binary 0\r\n

  2.3.3 Response
  0 7.1.0 220 CACHEDATAVERSION NONE size "version" cdv_response\r\n.\r\n


2.4 Client Information

  2.4.1 Description
  ClientInfo queries for information needed by the Freedom client including: the message of the day (MOTD), the time (UTC), the Freedom client time to expiry, the expiry date, the domain, the upgrade-ready flag, the upgrade url, the serial number server url, the support email address, the author of the Freedom client, and the NIQS update period.

  2.4.2 Command
  1 7.1.0 clientinfo nodata binary 0 clientid\r\n

  2.4.3 Response
  1 7.1.0 220 NODATA BINARY size "clientid" ci_response\r\n.\r\n


2.5 Token Information

  2.5.1 Description
  This command gets the information about the token types, including the following fields: Label, Duration, Reserved, AccessLevel, EmailDomain, EmailLimit, maxlife, Flags, CrossPostLimit, and serial-id.

  2.5.2 Command
  0 7.1.0 tokeninfo nodata binary 0\r\n

  2.5.3 Response
  0 7.1.0 220 NODATA BINARY size "Token info" tokeninfo_response\r\n.\r\n


2.6 Quit

  2.6.1 Description
  Last message sent to the NIQS to end the session and close the connection.

  2.6.2 Command
  0 0.1.0 quit nodata none 0\r\n

  2.6.3 Response
  0 7.1.0 220 NODATA BINARY 0 "Server closing connection"\r\n


3. REFERENCES TO IMPLEMENTATIONS AND API


Soon.


4. KNOWN PROBLEMS


The following known problems are related to the NIQS 2.0 protocol:
  - Because the NIQS 2.0 implementation is a multiple children server and that they all share the same cache, one or more child may run into a possible race condition. The result of this is that non-up-to-date CDV may be returned to the NIQS client with up-to-date information.




Copyright © 2000 Zero-Knowledge Systems Inc.
All Rights Reserved.