Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 2967


TISDAG - Technical Infrastructure for Swedish Directory Access Gateways

Part 4 of 5, p. 68 to 92
Prev RFC Part       Next RFC Part


prevText      Top      Up      ToC       Page 68 
6.0 Service Specifications

6.1 Overview

   To satisfy the requirements laid out for the TISDAG project, the
   software built for the DAG system must be able to meet the following
   service specifications:

   - primary designated DAG-CAPs of all types (but not necessarily
     secondary ones set up for load-balancing) must be available to
     provide service or redirect queries on a 7x24 basis.

Top      Up      ToC       Page 69 
   - in general, responses to queries should be available in under 10
     seconds; very generalized queries (i.e., when the user truly cannot
     specify enough information to focus the search) can be deferred to
     take much longer (having results is more important than having a
     quick answer)
   - the data provided from each WDSP should be updated in the DAG at
     least once every 7 days

6.2 WDSP Participation

   WDSPs who wish to participate in the DAG system do so by providing
   DAG-compatible access to their service, where DAG-compatible means:

   - access in (exactly) one of LDAPv2, LDAPv3, or Whois++
     - 7x24 service for responding to referrals generated in the DAG
     core (minimally) weekly updates of the index object describing the
     information their service indexes
     - use of USER and ROLE templates for Whois++ servers
     - use of inetorgperson and organizationalrole objectclasses for
     LDAP servers

   To participate, WDSPs must register each DAG-compliant server with
   the DAG system, providing details for each data set that it covers:

   - the host, port and protocol of the server
     - an identifier for the dataset
     - a URL for the service of preference for accessing the data
     (preferred source)
     - protocol-specific information
     - administrative contact information
     - CIP object exchange information

   Note that any WDSP wishing to make data available through the DAG
   system but unable to support these requirements may provide
   information through an agreement with a third-party which does meet
   these requirements.  Thus, data can be replicated between cooperating
   WDSPs.  The DAG referral index does not claim ownership of personal
   information; it directs queries to services that do, by whatever
   agreements with whichever relevant parties.  Note that, in this case,
   the SOURCE-URI may direct end-users to the WDSP's existing services,
   not the service of the third party.

6.3 Load Distribution

   It is anticipated that the DAG system will be quite popular, and
   measures must be available to distribute the load of answering

Top      Up      ToC       Page 70 
   The DAG system is presented as a conceptual whole, made up of several
   component parts -- DAG-CAPs, DAG-SAPs and the Referral Index.  Each
   of these component parts must be replicable, and service must be
   shared between replicas.

   It may be interesting to consider allowing large-scale service
   providers (large companies, ISPs)  the ability to mirror the Referral
   Index or provide alternate DAG-CAPs/DAG-SAPs for their
   personnel/customers.  Policies and possibilities for doing that are
   beyond the scope of this report; however, the software architecture
   has been designed to support such activity.

   Figure 6.1 shows that individual components of the DAG system may
   each run on non-co-located server hardware, connected by TCP/IP
   networks.  These components can be replicated as needed.

Top      Up      ToC       Page 71 
   |    |  DAG-CAP (Client Access Point)
   |    |
   |    |  DAG-SAP (Service Access Point)
   |    |
   HTTP   <-->|    |
              |    |                +----+
              +====+                |    |<--> Whois++
                                    |    |
                 +====+             +----+
      SMTP   <-->|    |
                 |    |          +----+
                 +====+          |    |<--> LDAPv2
                                 |    |
                    +====+       +----+
         Whois++<-->|    |
                    |    |
                    +====+             +----+
                                       |    |<--> LDAPv3
                                       |    |
                                       |    |<--> LDAPv3
                                       |    |
                                       |    |<--> LDAPv3
                                       |    |
                 +====+                +----+
      LDAPv2 <-->|    |
                 |    |
   LDAPv3 <-->|    |
              |    |
               | Referral Index         |<--> Common Indexing Protocol
               |                        |     (CIP)
         | Referral Index         |
         |                        |

   Figure 6.1 Distributable nature of DAG components

Top      Up      ToC       Page 72 
   Thus, the software built to this specification must be configurable
   to permit the following actions:

   - DAG-CAP software must be able to handle or redistribute the primary
     load.  Depending on the DAG-CAP software, this may be handled by
     having multiple processes attending to incoming queries, or the
     DAG-CAP at the primary address for the protocol may be nothing more
     than a reflector that redirects incoming queries to the address of
     the least-loaded server at the moment.
   - This is particularly necessary in synchronous connection protocols,
     such as Whois++ and LDAP, where the goal is to minimize the amount
     of time a requesting client is connected to the well-advertised
     address port.
   - DAG-CAP software must be able to direct referrals to different
     DAG-SAPs of the same protocol type.
   - DAG-CAP software must be able to detect overly general queries
     (i.e., have some metric to decide that the number of referrals
     generated by the Referral Index is too great).
   - DAG-SAPs must be able to redirect DAG-CAP queries at their
     discretion, or just refuse service because of loading (therefore
     DAG-CAPs must also be able to find other DAG-SAPs)

6.4 Extensibility

   The DAG system has been designed to allow for extensibility in
   certain key areas:

   It is possible to add new DAG-CAPs and DAG-SAPs transparently.
   Beyond replicating the software of existing DAG-CAPs, new
   implementations for particular protocols (e.g., building a more
   elaborate mail-based query system), or implementations for altogether
   different protocols (e.g., PH) can be added by adhering to the basic
   principles of DAG-CAPs and DAG-SAPs defined in the software
   specification.  The new DAG-CAP is responsible for the translation of
   queries into DAG/IP (post-processing results, if necessary) and
   results in the new protocol.  No other part of the DAG system is

   More functionality may be added to the DAG system service (e.g.,
   adding security certificate references to the schema of returned
   information) by updating the DAG schema.

   Depending on how the load on the service goes, it may be interesting
   to consider reducing the number of queries that are chained for
   protocols that inherently can handle the concept of pursuing
   referrals.  Specifically, LDAPv3 and Whois++ both handle referrals,
   but the current system calls for chaining LDAPv3 (and LDAPv2)
   referrals for the Whois++ DAG-CAP, and vice versa.  Alternatively,

Top      Up      ToC       Page 73 
   "virtual" DAG-CAPs could be established for each participating WDSP
   for each protocol the WDSP doesn't support, and referrals to those
   DAG-CAPs could be given to the calling client.  For example, a
   Whois++ client would be given a Whois++ referral to the virtual
   Whois++ DAG-CAP for a WDSP that supports only LDAP.  The importance
   of having one virtual DAG-CAP per WDSP is that the point of
   connection is the only way to distinguish which WDSP the Whois++
   client thought it was connecting to.

7.0 Security

7.1 Information credibility

   Security, in the context of "read-only" directory services, is
   primarily concerned with maintaining data integrity as it passes from
   an originating server to the end-user making an inquiry.  That is,
   some server(s) hold correct user information, and a client accessing
   a directory service should be certain that whichever servers that the
   information has to pass through before reaching the client, it
   receives a true representation of the original information.

   The DAG system as such MUST be completely invisible as the mediator
   of the information from the WDSPs to the querying directory access
   client.  The only possible modifications that can appear is
   translations from one characterset into another.  Hopefully, this
   does not alter the meaning of the information.

7.2 Unauthorized access

   In keeping with the public nature of the proposed TISDAG service, the
   DAG system does not provide any access control system beyond
   components' configuration to accept connections from recognized other
   components.  For more detailed access control, it is up to the
   connected WDSPs to apply the access control.

   Since the DAG system only supports searching and retrieving
   information, no updates can occur through the DAG client access

   Security in updates (CIP index objects) is provided by encryption and
   signature of objects from registered WDSPs.

Top      Up      ToC       Page 74 
8.0 Acknowledgments

   This work came from ideas originally put forward by Patrik Faltstrom.
   The TISDAG project was supported by the Swedish KK Foundation.

   Thanks to especially to Jens Lundstrom, Thommy Eklof, Bjorn Larsson
   and Sandro Mazzucato for their comments on draft versions of this

Top      Up      ToC       Page 75 
Appendix A - DAG Schema Definitions

   The DAG makes use of 2 information schemas -- the DAGPERSON schema
   for information about specific people, and the DAGORGROLE schema for
   organizational roles that may or may not be job positions occupied by
   people at any given time (e.g., an organization's president, customer
   service desk, etc).

   This appendix defines the schemas in terms of the attributes used
   within the DAG/IP.  Mappings to the standard LDAP and Whois++ object
   classes and templates (respectively) are described in Appendix B.

   Because the role of the DAG schemas is to act as an intermediary
   between information provided in different access protocols, with
   different underlying schema paradigms, the attributes in the schema
   are identified as being required or optional.  The required
   attributes are so designated because they are involved in the DAG
   search types and/or the minimal returned response.  They have defined
   mappings in the selected access protocols.  The optional attributes
   have proposed mappings in those protocols.

   It is important to note that the DAG/IP is constructed to carry any
   alternative attribute information that may be provided by a given
   WDSP; individual DAG-SAPs and DAG-CAPs may choose to pass along,
   interpret, or ignore any attributes not defined in this appendix.

   Additionally, note that the order of attributes in the DAG/IP is
   significant, which means that it is possible to use one attribute to
   carry the information describing the type of subsequent ones (e.g.,
   see the "ADR-TYPE" attribute below).

   Finally, attributes may be repeated.  For example, this schema
   structure can carry  multiple phone numbers of different types for
   one person.

Top      Up      ToC       Page 76 
A.1 DAG Personal Information Schema (DAGPERSON Schema)

   Attribute    Designation   Specific Description
   ---------    -----------   -------------------------------------
   FN           Required      Free-text representation of full name
   EMAIL        Required      Internet e-mail address
   LOC          Required      Locality -- geographic region
   ORG          Required      Person's organization
   ADR-TYPE     Optional      Type of address that follows
                              ("org", "home", "org-postal",
                              "home-postal", "unqualified")
   ADR          Optional      Full address
   ADR-STREET   Optional      Street address component
   ADR-ROOM     Optional      Suite or room number component
   ADR-CITY     Optional      City name
   ADR-STATE    Optional      Region of address
   ADR-COUNTRY  Optional      Country
   ADR-CODE     Optional      Postal code component
   TEL-TYPE     Optional      Type of telephone number (
                              "work",  "home", "mobile",
                              "fax" ,"pager", "unqualified")
                              in the following attribute
   TEL          Optional      A phone number for the person
   SOURCE       Optional      The WDSP's preferred  access to
                              their service -- a URL
   DN           Optional      Entry's "distinguished name"
                              (for LDAP)

      Table A.1 DAGPERSON schema attributes

Top      Up      ToC       Page 77 
A.2 DAG Organizational Role Information Schema (DAGORGROLE Schema)

   Attribute   Designation     Specific Description
   ---------   -----------     ---------------------
   ROLE        Required        Name of organizational role
   EMAIL       Required        E-mail address associated with role
   ORG         Required        Name of organization
   LOC         Required        Locality -- geographic region
   TEL-TYPE    Optional        Type of telephone number
                               in the TEL attribute immediately
                               following("org" or "fax")
   TEL         Optional        Phone number

   FN          Optional        Full name of current role occupant
   SOURCE      Optional        The WDSP's preferred  access to their
                                service -- a URL
   DN          Optional        Entry's "distinguished name" (for LDAP)

   Table A.2 DAGORGROLE schema attributes

Appendix B - Schema Mappings for Whois++ and LDAP

   The DAG/IP makes use of two specific schemas, as defined above.
   However, schemas particular to access protocols need to be handled in
   order to appropriately address incoming user queries, and chaining
   queries to WDSPs.  The recognized standard schemas are:

   - the USER template for Whois++ ([8])
   - the ORGROLE template for Whois++ ([8])
   - the inetOrgperson objectclass for LDAP ([16])
   - the organizationalrole objectclass for LDAP ([18])

   The DAG/IP schemas were developed based on the information that the
   TISDAG project requirements wish to return in results, in conjunction
   with information about standard schemas used in the basic WDSP access
   protocols (LDAPv2/v3 and Whois++).  However, particularly in the case
   of address information, the schemas used for those protocols allow
   for considerable scope of information representation.  In practice,
   this means that different WDSPs may choose to use different sub-parts
   of the schema, or even implement local customizations.

   Therefore, Appendix A outlines a very basic schema that can carry all
   the necessary information.  The basic DAG-CAPs and DAG-SAPs are
   designed to work to that information structure.  This appendix
   outlines the expected behaviour for DAG-SAPs mapping into the DAG/IP
   schema, and DAG-CAPs extracting information to pass along to client
   software after a chaining operation has returned results.

Top      Up      ToC       Page 78 
B.1 LDAP and the DAG Schemas

   The only time information is carried in the DAG schemas is when a
   DAG-SAP is returning information (obtained from  WDSPs' servers) to a
   DAG-CAP using the DAG/IP.  The "canonical" mappings between standard
   LDAP object classes (inetorgPerson, defined in [16] and
   organizationalRole, defined in [18] and the DAGPERSON schema and
   DAGORGROLE schema are defined such that information passed from an
   LDAP DAG-SAP to an LDAP DAG-CAP (e.g., in the case of an LDAPv3 DAG-
   SAP returning information chained for an LDAPv2 DAG-CAP) will be
   mapped into the same attributes as it was extracted.

   However, the representation of some attributes (such as address) is
   truly widely varied between protocol paradigms.  The goal with the
   "reasonable approximation" mappings that are provided is to give
   DAG-CAPs a basic mechanism for communicating information drawn from
   non-LDAP DAG-SAP sources.  The mappings may not be perfect, but they
   will convey the information to the end-user in some LDAP-
   understandable fashion, which is the goal of this project's effort.

   The canonical mappings for the LDAP inetorgPerson object class and
   the DAGPERSON schema are given in Table B.1.  A few reasonable
   approximation mappings follow in Table B.2.  Beyond that, DAG-SAPs
   may pass along any additional attributes in the DAG/IP, and DAG-CAPs
   may elect to forward or interpret any that are recognizable (e.g.,
   the sn ("surname") attribute is not listed here, but a DAG-SAP might
   return that in the DAG/IP, and a DAG-CAP, recognizing the string
   representation, could elect to include it in its LDAP response to the

   DAGPERSON Attribute     LDAP inetorgPerson attribute
   -------------------     ----------------------------
   FN                      cn
   EMAIL                   mail
   LOC                     l
   ORG                     o

   ADR-STREET              street
   ADR-ROOM                roomNumber
   ADR-STATE               st
   ADR-COUNTRY             c

   ADR                     postalAddress
   ADR-ROOM                postOfficeBox
   ADR-CODE                postalCode

Top      Up      ToC       Page 79 
   ADR                     homePostalAddress

   TEL                     telephoneNumber

   TEL                     homePhone

   TEL                     facsimileTelephoneNumber

   TEL                     mobile

   TEL                     pager

   DN                      dn
   SOURCE                  labeledURI

   Table B.1 Canonical DAGPERSON schema & LDAP inetorgPerson attributes

   DAGROLE Attribute        LDAP organizationalRole attribute
   -----------------------  ---------------------------------
   ADR                      street
   ADR-STREET               street
   ADR-ROOM                 room
   ADR-STATE                st
   ADR-COUNTRY              c

   TEL                      telephoneNumber

   Table B.2 Reasonable Approximations for LDAP organizationalRole

Top      Up      ToC       Page 80 
   For example, consider the following LDAP record information, in LDIF
   [11] format:

   dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry,
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   objectclass: inetorgperson
   cn: Barbara Jensen
   cn: Barbara J Jensen
   cn: Babs Jensen
   sn: Jensen
   uid: bjensen
   telephonenumber: +1 408 5551212
   description:  A big sailing fan

   This would validly be carried in the DAGPERSON schema as follows:

   DN: cn=Barbara Jensen, ou=Product Development, o=Ace Industry,
   FN: Barbara Jensen
   FN: Barbara J Jensen
   FN: Babs Jensen
   SN: Jensen
   TEL-TYPE: work
   TEL:  +1 408 5551212

   The canonical mappings for the LDAP organizationalRole object class
   and the DAGORGROLE schema are given in Table B.3 .Beyond that, DAG-
   SAPs may elect to send along any attributes, and DAG-CAPs may
   interpret any that are recognizable.  N.B., the organizationalRole
   class does not include provision for inclusion of an e-mail address.
   This mapping rather blithely assumes the availability of the mail
   attribute as defined for inetorgPerson.

Top      Up      ToC       Page 81 
   DAGORGROLE Attribute   LDAP organizationalRole attribute
   --------------------   ---------------------------------
   ROLE                   cn
   EMAIL                  mail
   ORG                    o
   LOC                    l

   TEL                    telephoneNumber

   TEL                    facsimileNumber

   FN                     roleOccupant
   DN                     dn
   SOURCE                 labeledURI

   Table B.3 Canonical mappings for LDAP organizationalRole attributes

B.2 Whois++ and the DAG Schemas

   The "canonical" mappings between standard Whois++ templates as
   defined in [8] and the DAGPERSON schema and DAGORGROLE schema are
   defined in Tables B.4 and B.5.  Beyond that, DAG-SAPs may pass along
   any additional attributes in the DAG/IP, and DAG-CAPs may elect to
   forward or interpret any that are recognizable.

   DAGPERSON Attribute   Whois++ USER template attribute
   -------------------   -------------------------------
   FN                    name
   EMAIL                 email
   LOC                   address-locality
   ORG                   organization-name

   ADR                   address

   ADR                   organization-address
   ADR-STREET            organization-address-street
   ADR-ROOM              organization-address-room
   ADR-CITY              organization-address-city
   ADR-STATE             organization-address-state
   ADR-COUNTRY           organization-address-country
   ADR-CODE              organization-address-zip-code

Top      Up      ToC       Page 82 
   ADR-TYPE=home         address-type=home
   ADR                   address
   ADR-STREET            address-street
   ADR-ROOM              address-room
   ADR-CITY              address-city
   ADR-STATE             address-state
   ADR-COUNTRY           address-country
   ADR-CODE              address-zip-code

   TEL-TYPE=work         phone-type=work
   TEL                   phone

   TEL-TYPE=home         phone-type=home
   TEL                   phone

   TEL                   fax

   TEL                   cellular

   TEL                   pager

   Table B.4 Canonical DAGPERSON schema & Whois++ USER attributes

   DAGORGROLE Attribute       Whois++ ORGROLE attribute
   --------------------       -------------------------
   ROLE                       org-role
   EMAIL                      email
   ORG                        organization-name
   LOC                        organization-address-locality
   FN                         name

   TEL                        phone

   TEL                        fax

   Table B.5 Canonical mappings for Whois++ ORGROLE attributes

Appendix C - DAG-Internal Protocol (DAG/IP)

   The DAG-Internal Protocol (DAG/IP) is currently defined as a
   derivative of the query-interaction protocol of Whois++ as laid out
   in RFC1835 ([6]).

Top      Up      ToC       Page 83 
C.1 A word on the choice of DAG/IP

   The use of the DAG/IP is strictly internal to the DAG system.  In
   that regard, it is possible make use of any query language, or define
   a new one.

   The Whois++ protocol was selected as the basis of the DAG/IP for
   several reasons:

   - it has the power and flexibility to convey all necessary queries
   - it is a simple, text-based protocol; clients need not implement the
     full functionality of the protocol in order to carry out minimal
   - the power of the full-fledge directory service query protocol will
     give DAG-CAP writers the ability to express more sophisticated
     queries if desired (e.g., to produce more intricate "intelligent"
     matching of spellings, common character substitutions, etc).
   - the text-based, delimited attribute results expression facilitates
     optional inclusion of  extra data supplied by WDSPs -- DAG-CAPs can
     easily ignore any unknown information and continue to interpret the
     rest of the result information.

   Also, the use of an existing protocol leverages the experience and
   time of the creators of the protocol -- hammering out such elusive
   and yet necessary details as handling line-endings, quoting special
   characters, etc.

   There is a freely-available test suite of tools for testing servers'
   Whois++ protocol conformance (for the Referral Index, and for DAG-
   SAPs).  Send mail to for further information.

C.2 DAG/IP Input and Output -- Overview

   Input interactions in DAG/IP are as defined in RFC1835, "Architecture
   of the WHOIS++ service" ([6]), sections 2.2 and 2.3.  Section C.3 of
   this document adapts the grammar used in more recent descriptions of
   the Whois++ protocol to illustrate the syntax of the DAG/IP.

   DAG/IP output will be a subset of what is defined in RFC1835, section
   2.4, except that referral responses ("SERVER-TO-ASK") contain more

C.3 BNF for DAG/IP input and output

   The following sections are adapted from the Whois++ grammar.  For
   discussion of the semantic intent of the query protocol, and other
   matters, see Whois++ RFC 1835 [6].

Top      Up      ToC       Page 84 
C.3.1 The DAG/IP Input Grammar

   The following grammar, which uses the Augmented BNF (ABNF) notation
   as defined in [5], defines the set of acceptable DAG/IP input.

   N.B.:  As outlined in the ABNF definition, rule names and string
   literals are in the US-ASCII character set, and are case-insensitive.
   Also,  when a character is written explicitly in the grammar, as for
   example ";", it represents the byte value of that character in all of
   the allowed character sets in their encodings used in this protocol.
   Specifically in UNICODE, ";" means the character U+003B, which when
   encoding the character in UTF-8 will generate the byte value 0x3B
   which is then used in the DAG/IP protocol.

   dagip-command   = ( system-command [":" "hold"]
                 / ri-query
                 / sap-query ) nl

   ri-query        =   ri-terms [":" globalcnstrnts]

   sap-query       =   sap-terms [":" [sapcnstrnts][ ":" wdspinfo]]

   system-command =   "constraints"
                   / "describe"
                   / "commands"
                   / "polled-by"
                   / "polled-for"
                   / "version"
                   / "list"
                   / "show" [1*sp datastring]
                   / "help" [1*sp datastring]
                   / "<NL>" [string]

   ri-terms       =   ri-and-expr *(1*sp "or" 1*sp ri-and-expr)

   ri-and-expr    =   ri-basic-expr *(1*sp "and" 1*sp ri-basic-

   ri-basic-expr  =   ["not" 1*sp] ri-term / ( "(" ri-terms ")" )

   ri-term        =   generalterm / specificterm / combinedterm

   sap-terms       =   sap-and-expr *(1*sp "or" 1*sp sap-and-expr)

   sap-and-expr    =   sap-basic-expr *(1*sp "and" 1*sp

   sap-basic-expr  =   ["not" 1*sp] sap-term / ( "(" sap-terms ")" )

Top      Up      ToC       Page 85 
   sap-term        =   ( generalterm / specificterm / combinedterm)

   generalterm     =   datastring

      TISDAG: Since the DAG system only supports certain attribute
      combinations in its queries, (Table 3.1).  The use of generalterm
      may lead to unexpected behaviour and is therefore deprecated.
      CAPs should therefore not use it even if it is in the protocol.

   specificterm    =   specificname "=" datastring

   specificname    =   "handle" / "value"

   combinedterm    =   attributename "=" datastring

   sapcnstrnts     =   sapcnstrnt *(";" sapcnstrnt)

   sapcnstrnt      =   localcnstrnt / globalcnstrnt

   localcnstrnts   =   [";search=" sap-searchvalue] [";case="

   localcnstrnt    =   "search=" sap-searchvalue / "case="

      ;N.B.:  in the case where local and global constraints
      ;       conflict, local constraints take precedence
      ;       and overrides the global constraint

   sap-searchvalue =   "tstring" / searchvalue

   sap-casevalue   =   "consider" / "ignore"

   globalcnstrnts  =   globalcnstrnt *(";" globalcnstrnt)

   globalcnstrnt   =   "search" "=" searchvalue
                    / opt-globalcnst

   opt-globalcnst  =   "hold"
                    / "case" "=" casevalue
                    / "maxfull" "=" 1*digit
                    / "maxhits" "=" 1*digit
                    / "language" "=" language
                    / "incharset" "=" characterset
                    / "ignore" "=" attributename
                    / "include" "=" attributename

Top      Up      ToC       Page 86 
   ; N.B.: If an attribute is named both with the "include" and "ignore"
   ; constraints, the attribute is to be included in the result, but the
   ; system message must be "% 112 Requested constraint not fulfilled".

   language        = <The language code defined in RFC1766>

   characterset    =   "UNICODE-2-0-UTF-8"

   searchvalue     =   "exact" / "substring" / "lstring"

   casevalue       =   "ignore" / "consider"

   wdspinfo        =   attrValAss *( ";" attrValAss )

   attrValAss      =   attributename "=" datastring

      TISDAG: Within the boundaries of the TISDAG project it has been
      decided that the only permitted attributes for wdspinfo are
      "host","port","server-info" and "charset".  Regarding "charset"
      the values for this attribute are defined to be one of "UTF-8",
      "ISO8859-1","T\.61" or "US-ASCII".

   datastring      =   1*data-elt

   attributename   =   1*(<%d32-126 except specialbyte>)
                         ; omit 127, which is DEL

   data-elt        =   "\" specialbyte / normalbyte

   normalbyte      =   <%d32-255, except specialbyte>

   specialbyte     =   " " / tab / "=" / "," / ":" / ";" / "\" /
                    "*" / "." / "(" / ")" / "[" / "]" / "^" /
                    "$" / "!" / "<NL>"

   number          =   1*digit

   digit           =   "0" / "1" / "2" / "3" / "4" /
                    "5" / "6" / "7" / "8" / "9"

   tab             =   %d09
   sp              =   %d32                ; space
   nl              =   %d13 %d10           ; CR LF

Top      Up      ToC       Page 87 
   NOTE: Spaces (sp) that are significant to a query must be escaped.
   The following characters, when significant to the query, may  be
   preceded and/or followed by a single space:
     : ; , ( ) = !

C.3.2 The DAG/IP Response Grammar

   The following grammar, which uses the Augmented BNF (ABNF) notation
   as defined in RFC2234 (see [5]),

   N.B.:  As outlined in the ABNF definition, rule names and string
   literals are in the US-ASCII character set, and are case-insensitive.
   Also,  when a character is written explicitely in the grammar, as for
   example ";", it represents the byte value of that character in all of
   the allowed character sets in their encodings used in this protocol.
   Specifically in UNICODE, ";" means the character U+003B which when
   encoding the character in UTF-8 will generate the byte value 0x3B
   which is then used in the DAG/IP protocol.

   server-resp     =   goodmessage mnl output mnl endmessage
                    / badmessage nl endmessageclose

   output          =   0*(full-record / server-to-ask)

   full-record     =   "# FULL " template " " serverhandle " "
                          localhandle system-nl
                     "# END" system-nl

      TISDAG: serverhandle is:

      - Whois++, whatever the server-handle on the record returned by
        the WDSP.
      - LDAP, <hostname-without-periods><port> (because server DN's are
        not enforceably unique).  E.g., a server on
        7778 would become servicesbunyipcom7778.

      localhandle is:
      - Whois++:  the localhandle on the record returned by the WDSP
      - LDAP, it is the RDN (relative  distinguished name), with spaces
        replaced by "_".  E.g., cn=leslie_daigle

   server-to-ask   =   "# SERVER-TO-ASK " serverhandle system-nl
                    "# END" system-nl

   fulldata        =   " " attributename ": " attributevalue

Top      Up      ToC       Page 88 
   server-to-ask-data = " Server-Info: " serverinfo system-nl
                     " Host-Name: " hostname system-nl
                     " Host-Port: " number system-nl
                     " Protocol: " prot system-nl
                     " Source-URI: " source system-nl
                     " Charset: " characterset system-nl

   attributename   =   r-string

   attributevalue  =   longstring

   template        =   <%d32-%d255 except specialbyte>

   serverhandle    =   <%d32-%d255 except specialbyte>

   localhandle     =   <%d32-%d255 except specialbyte>

   serverinfo      =   string

   hostname        =   string

   prot            =   string ; currently one of "ldapv2"
                           ; "ldapv3" "whois++"

   characterset    =   "UTF-8" / "T.61" / "ISO8859-1" / "US-ASCII"

   source          =   string

   longstring      =   string 0*( nl ( "+" / "-" ) string )

   string          =   0*(%d32-255)

   r-string        =   0*(<%d32-126 except specialbyte>)
                        ; omit 127 which is DEL

   specialbyte     =   ":" / " "

   mnl             =   1*system-nl

   system-nl       =   nl [ 1*(message nl) ]

   nl              =   %d13 %d10    ; CR and LF

   message         =   [1*( messagestart "-" string nl)]
                    messagestart " " string nl

   messagestart    =   "% " digit digit digit

Top      Up      ToC       Page 89 
   goodmessage     =   [1*( goodmessagestart "-" string nl)]
                    goodmessagestart " " string nl

   goodmessagestart=   "% 200"

   badmessage      =   [1*( badmessagestart "-" string nl)]
                    badmessagestart " " string nl

   badmessagestart =   "% 5" digit digit

   endmessage      =   endmessageclose / endmessagecont

   endmessageclose =   [endmessagestart " " string nl]

   endmessagecont  =   endmessagestart " " string nl

   endmessagestart =   "% 226"

   byemessage      =   byemessagestart " " string nl

   byemessagestart =   "% 203"

   number          =   1*( digit )

   digit           =   "0" / "1" / "2" / "3" / "4" / "5" / "6" /
                    "7" / "8" / "9"

C.4 DAG/IP Response Messages

   The following list and discussion of response codes is derived from
   the Whois++ protocol definition, RFC1835 ([6]).

   A system message begins with a '%', followed by a space and a three
   digit number, a space, and an optional text message.  The line
   message must be no more than 81 bytes long, including the terminating
   CR LF pair.  There is no limit to the number of system messages that
   may be generated.

   A multiline system message have a hyphen instead of a space in column
   6, immediately after the numeric response code in all lines, except
   the last one, where the space is used.

   Example 1

   % 200 Command okay

   Example 2

Top      Up      ToC       Page 90 
   % 220-Welcome to
   % 220-the Whois++ server
   % 220 at ACME inc.

   The client is not expected to parse the text part of the response
   message except when receiving reply 600 or 601, in which case the
   text part is in the former case the name of a character set that will
   be used by the server in the rest of the response, and in the latter
   case when it specifies what language the attribute value is in.  The
   valid values for characters sets is specified in the "characterset"
   list in the BNF listing in Appendix C.

   The theory of reply codes is described in Appendix E in STD 10,
   RFC821 ([15]).

   System response code           Description

   ----------------------------   ------------------------------
   110 Too many hits              The number of matches exceeded
                                  the value specified by the
                                  maxhits constraint.  Server
                                  will still reply with as many
                                  records as "maxhits" allows.

   111 Requested constraint not   One or more constraints in query
       supported                  is not implemented, but the
                                  search is still done.

   112 Requested constraint not   One or more constraints in query
       fulfilled                  has unacceptable value and was
                                  therefore not used, but the
                                  search is still done.

   200 Command Ok                 Command accepted and executed.
                                  The client must wait for a
                                  transaction end system message.

   201 Command Completed          Command accepted and executed.

   203 Bye                        Server is closing connection

Top      Up      ToC       Page 91 
   204 Overgeneralized            The server could not exactly
                                  match the DAG query into its
                                  native access protocol.  The
                                  resulting native query was

   220 Service Ready              Greeting message.  Server is
                                  accepting commands.

   226 Transaction complete       End of data.  All responses to
                                  query are sent.

   401 Service not available

   402 Search expression
       too complicated

   403 Information Unavailable    When a remote service is not
                                  (currently) available.

   404 Time out

   500 Syntax error

   502 Search expression too      This message is sent when the
       complicated                server is not able to resolve a
                                  query (i.e. when a client sent a
                                  regular expression that is too
                                  deeply nested).

   503 Query to general           This is like the "too many hits"
                                  situation, but the server does
                                  not send along any results.  This
                                  message is used to deflect data

   505 Operations error           Permanent operations error

   600 <token>                    Subsequent attribute values are
                                  encoded in the character set
                                  specified by <token>.

   601 <token>                    Subsequent attribute values are
                                  in the language specified by

Top      Up      ToC       Page 92 
   601 DEF                        Subsequent attribute values are
                                  default values, i.e. they should
                                  be used for all languages not
                                  specified by "601 <token>" since
                                  last "601 ANY" message.

   601 ANY                        Subsequent attribute values are
                                  for all languages.

   Table C.1 List of system response codes

Next RFC Part