Dismiss
InnovationQ/InnovationQ Plus content will be updated on Sunday, June 25, 10am ET, with new patent and non-patent literature collections. Click here to learn more.
Browse Prior Art Database

How to Interact with a Whois++ Mesh (RFC1914)

IP.com Disclosure Number: IPCOM000004232D
Original Publication Date: 1996-Feb-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 8 page(s) / 16K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P. Faltstrom: AUTHOR [+2]

Abstract

Status of this Memo

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 18% of the total text.

Network Working Group P. Faltstrom

Request for Comments: 1914 Bunyip Information Systems, Inc.

Category: Standards Track R. Schoultz

KTHNOC

C. Weider

Bunyip Information Systems, Inc.

February 1996

How to Interact with a Whois++ Mesh

Status of this Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

1. Overview

In the Whois++ architecture [Deutsch94],[Weider94], mesh traversal is

done by the client, since each server 'refers' the client to the next

appropriate server(s). The protocol is simple. The client opens a

connection to a server, sends a query, receives a reply, closes the

connection, and after parsing the response the client decides which

server to contact next, if necessary.

So, the client needs to have an algorithm to follow when it interacts

with the Whois++ mesh so that referral loops can be detected, cost is

minimised, and appropriate servers are rapidly and effectively

contacted.

2. Basic functionality

Each Whois++ client should be configured to automatically send

queries to a specific Whois++ server. The deault Whois++ server can

vary depending on which template is desired, and the location of the

client with respect to the WHOIS++ index mesh, but as a rule the

server should be as local as possible.

A

/ \

B C

/ \ \

Z -----> D E F

/ \

G H

Fig 1: The client Z is configured to first query server D

After getting responses from a server, the client can act in several

ways. If the number of hits is greater than zero, the response is

just presented to the user. If the client gets one or many servers-

to-ask answers, the client should be able to automatically resolve

these pointers, i.e. query these servers in turn.

A

/ \

B C

/ \ \

Z <----- D E F

\ / \

--> G H

Fig 2: The client Z gets a "servers-to-ask G" response from D and

therefore may automatically queries server G.

3. How to navigate in the mesh

A client can use several different strategies when traversing or

navigating around in the mesh. The automatic way of doing this is to

just "expand the search" (described in 3.1) and a second meth...