RFC 2967
TISDAG - Technical Infrastructure for Swedish Directory Access Gateways
Pages: 105
Informational
Informational
Part 4 of 5 – Pages 68 to 92
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.
- 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
queries.
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.
+====+
| | 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
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
affected.
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,
"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 points. Security in updates (CIP index objects) is provided by encryption and signature of objects from registered WDSPs.
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 document.
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.
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
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 attributesAppendix 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.
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 client). DAGPERSON Attribute LDAP inetorgPerson attribute ------------------- ---------------------------- FN cn EMAIL mail LOC l ORG o ADR-TYPE=org ADR-STREET street ADR-ROOM roomNumber ADR-STATE st ADR-COUNTRY c ADR-TYPE=org-postal ADR postalAddress ADR-ROOM postOfficeBox ADR-CODE postalCode
ADR-TYPE=home-postal ADR homePostalAddress TEL-TYPE=work TEL telephoneNumber TEL-TYPE=home TEL homePhone TEL-TYPE=fax TEL facsimileTelephoneNumber TEL-TYPE=mobile TEL mobile TEL-TYPE=pager TEL pager DN dn SOURCE labeledURI Table B.1 Canonical DAGPERSON schema & LDAP inetorgPerson attributes DAGROLE Attribute LDAP organizationalRole attribute ----------------------- --------------------------------- ADR-TYPE=unqualified ADR street ADR-STREET street ADR-ROOM room ADR-STATE st ADR-COUNTRY c TEL-TYPE=unqualified TEL telephoneNumber Table B.2 Reasonable Approximations for LDAP organizationalRole attributes
For example, consider the following LDAP record information, in LDIF [11] format: dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US 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, c=US 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.
DAGORGROLE Attribute LDAP organizationalRole attribute -------------------- --------------------------------- ROLE cn EMAIL mail ORG o LOC l TEL-TYPE=org TEL telephoneNumber TEL-TYPE=fax TEL facsimileNumber FN roleOccupant DN dn SOURCE labeledURI Table B.3 Canonical mappings for LDAP organizationalRole attributesB.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-TYPE=unqualified ADR address ADR-TYPE=org 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
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-TYPE=fax TEL fax TEL-TYPE=mobile TEL cellular TEL-TYPE=pager 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-TYPE=org TEL phone TEL-TYPE=fax TEL fax Table B.5 Canonical mappings for Whois++ ORGROLE attributesAppendix 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]).
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 queries - 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 digger-info@bunyip.com 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 information.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].
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- expr) 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) sap-basic-expr = ["not" 1*sp] sap-term / ( "(" sap-terms ")" )
sap-term = ( generalterm / specificterm / combinedterm)
localcnstrnts
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="
sap-casevalue]
localcnstrnt = "search=" sap-searchvalue / "case="
sap-casevalue
;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
; 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
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
1*fulldata
"# 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 services.bunyip.com 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
server-to-askdata
"# END" system-nl
fulldata = " " attributename ": " attributevalue
system-nl
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
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]
byemessage
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
% 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. successfully 203 Bye Server is closing connection
204 Overgeneralized The server could not exactly
match the DAG query into its
native access protocol. The
resulting native query was
"looser".
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
mining.
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
<token>.
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 page on part 5)