/ "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
Appendix D - DAG/IP Response Messages Mapping
LDAPv2/v3 DAG/IP
--------------------------------------- ---------------------
success (0) v2&v3 200 Command Ok
operationsError (1) v2&v3 505 Operations error
protocolError (2) v2&v3 505 Operations error
timeLimitExceeded (3) v2&v3 404 Timeout
sizeLimitExceeded (4) v2&v3 110 To many hits
compareFalse (5) v2&v3 200 OK
compareTrue (6) v2&v3 200 OK
authMethodNotSupported (7) v2&v3 505 Operations error
strongAuthRequired (8) v2&v3 505 Operations error
referral (10) v3 200 OK
adminLimitExceeded (11) v3 110 Too many hits
unavailableCriticalExtension (12) v3 505 Operations error
confidentialityRequired (13) v3 505 Operations error
saslBindInProgress (14) v3 N.A.
noSuchAttribute (16) v2&v3 200 OK
undefinedAttributeType (17) v2&v3 500 Syntax error
inappropriateMatching (18) v2&v3 500 Syntax error
constraintViolation (19) v2&v3 111 Requested constraint
not supported
attributeOrValueExists (20) v2&v3 200 OK
invalidAttributeSyntax (21) v2&v3 500 Syntax error
noSuchObject (32) v2&v3 200 OK
aliasProblem (33) v2&v3 505 Operations error
invalidDNSyntax (34) v2&v3 500 Syntax error
isLeaf (35) v2 N.A.
aliasDereferencingProblem (36) v2&v3 505 Operations error
inappropriateAuthentication (48) v2&v3 500 Syntax error
invalidCredentials (49) v2&v3 403 Information Unavailable
insufficientAccessRights (50) v2&v3 403 Information Unavailable
busy (51) v2&v3 403 Information Unavailable
unavailable (52) v2&v3 401 Service not available
unwillingToPerform (53) v2&v3 505 Operations error
loopDetect (54) v2&v3 505 Operations error
namingViolation (64) v2&v3 N.A.
objectClassViolation (65) v2&v3 N.A.
notAllowedOnNonLeaf (66) v2&v3 N.A.
notAllowedOnRDN (67) v2&v3 N.A.
entryAlreadyExists (68) v2&v3 N.A.
objectClassModsProhibited (69) v2&v3 N.A.
affectsMultipleDSAs (71) v3 N.A.
other (80) v2&v3 403 Information Unavailable
Table D.1 LDAPv2/v3 resultcodes to DAG/IP response codes
mapping
DAG/IP LDAP v2/v3
--------------------------------------- --------------------------
110 Too many hits sizeLimitExceeded (4)
111 Requested constraint not supported constraintViolation (19)
112 Requested constraint not fullfilled constraintViolation (19)
200 Command Ok Success (0)
201 Command Completed successfully N.A.
203 Bye N.A.
204 Overgeneralized N.A.
220 Service Ready N.A.
226 Transaction complete N.A.
401 Service not available unavailable (52)
402 Search expression too complicated unwillingToPerform (53)
403 Information Unavailable busy (51)
404 Time out timeLimitExceeded (3)
405 Operations error operationsError (1)
500 Syntax error protocolError (2)
502 Search expression too complicated unwillingToPerform (53)
503 Query to general unwillingToPerform (53)
505 Operations error operationsError (1)
600 <token> N.A.
601 <token> N.A.
601 DEF N.A.
601 ANY N.A.
Table D.2 Mapping from DAG/IP response codes to LDAPv2/v3 resultcodes
DAG/IP Whois++
-------------------------------------- -----------------------------
110 Too Many hits 110 Too Many hits
111 Requested constraint not supported 111 Requested constraint not
supported
112 Requested constraint not fullfilled 112 Requested constraint not
fullfilled
200 Command Ok 200 Command Ok
201 Command Completed successfully 201 Command Completed
successfully
401 Service not available 401 Service not available
403 Information Unavailable 403 Information not available
404 Timeout 404 Timeout
405 Operations error 405 Operations error
500 Syntax error 500 Syntax error
502 Search expression too complicated 502 Search expression too
complicated
503 Query to general 506 Query to general
505 Operations error 505 Operations error
Table D.3 Mapping between DAG/IP and Whois++ response codes
Appendix E - DAG CIP Usage
E.1 CIP Index Object
The CIP object used by the DAG system is based on the Tagged Index
Object as defined in [12]. The grammar, adapted from that Work in
Progress, for the specific object used by the DAG is as follows:
index-object = 0*(io-part SEP) io-part
io-part = header SEP schema-spec SEP index-info
header = version-spec SEP update-type SEP this-update SEP
last-update context-size
version-spec = "version:" *SPACE "x-tagged-index-1"
update-type = "updatetype:" *SPACE ( "total" |
( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ])
this-update = "thisupdate:" *SPACE TIMESTAMP
last-update = [ "lastupdate:" *SPACE TIMESTAMP SEP]
context-size = [ "contextsize:" *SPACE 1*DIGIT SEP]
schema-spec = "BEGIN IO-Schema" SEP 1*(schema-line SEP)
"END IO-Schema"
schema-line = attribute-name ":" token-type
token-type = "TOKEN"
index-info = full-index | incremental-index
full-index = "BEGIN Index-Info" SEP 1*(index-block SEP)
"END Index-Info"
incremental-index = 1*(add-block | delete-block | update-block)
add-block = "BEGIN Add Block" SEP 1*(index-block SEP)
"END Add Block"
delete-block = "BEGIN Delete Block" SEP 1*(index-block SEP)
"END Delete Block"
update-block = "BEGIN Update Block" SEP
0*(old-index-block SEP)
1*(new-index-block SEP)
"END Update Block"
old-index-block = "BEGIN Old" SEP 1*(index-block SEP)
"END Old"
new-index-block = "BEGIN New" SEP 1*(index-block SEP)
"END New"
index-block = first-line 0*(SEP cont-line)
first-line = attr-name ":" *SPACE taglist "/" attr-value
cont-line = "-" taglist "/" attr-value
taglist = tag 0*("," tag) | "*"
tag = 1*DIGIT ["-" 1*DIGIT]
attr-value = 1*(UTF8)
attr-name = dag-searchattr / "objectclass"
dag-searchattr = "FN" / "LOC" / "ROLE" / "ORG"
TIMESTAMP = 1*DIGIT
NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
SPACE = <ASCII space, %x20>;
SEP = (CR LF) | LF
CR = <ASCII CR, carriage return, %x0D>;
LF = <ASCII LF, line feed, %x0A>;
DIGIT = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
UPPER = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
"I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
"Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
"Y" | "Z"
LOWER = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
"y" | "z"
US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-7F
;; US-ASCII except CR, LF, NUL
UTF8 = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
/ UTF8-4 / UTF8-5
UTF8-CONT = %x80-BF
UTF8-1 = %xC0-DF UTF8-CONT
UTF8-2 = %xE0-EF 2UTF8-CONT
UTF8-3 = %xF0-F7 3UTF8-CONT
UTF8-4 = %xF8-FB 4UTF8-CONT
UTF8-5 = %xFC-FD 5UTF8-CONT
N.B.: The only tokenization type permitted is "TOKEN". While the
Tagged Index Object memo permits the use of "FULL" (i.e., the entire
value of the attribute is preserved as a single token), that has the
danger of yielding a unique token for every record. Studies in the
growth of centroid sizes as a function of number of records (see
[14]) demonstrate that such unique tokens (e.g., phone numbers) are
to be avoided. While storing tag information requires some number of
extra bytes of storage per token index entry, using unique tokens
causes the number of token entries in the index to continue to grow
linearly with the number of records, thereby affecting search
efficiency.
Note also that tags are to be applied to the data on a per entry
level. Thus, if two index lines in the same index object contain the
same tag, then it is always the case that those two lines refer back
to the same "record" in the directory. In LDAP terminology, the two
lines would refer back to the same directory object.
Additionally if two index lines in the same index object contain
different tags, then it is always the case that those two lines refer
back to different records in the directory.
The attribute "objectclass" is used to denote the record/object types
in the data summarized in this index object.
Values for the objectclass attribute should be restricted to:
dagperson or dagrole, the two DAG schema object types.
E.2 CIP Index Object Creation
WDSPs are expected to create index objects following the general
principles outlined in the Whois++ protocol documentation (creation
of centroids) and the Tagged Index Object documentation ([12]).
Following the syntax described above, the index object contains token
information for each attribute in the DAGSchema:
- a list of all the unique tokens (strings delimited by the specified
characters) that appear in the WDSP database for the attribute
- for each token in that list, which records the token appears in
So, for example,
Record #1:
FN: Foo Bar
ORG: The Snack Bar
Record #2:
FN: Bar Smith
ORG: Snack Shack
yields (conceptually) the following information for the attribute FN:
Foo (1), Bar (1,2), Smith (2)
and the following information for the attribute ORG:
The (1), Snack (1, 2), Bar (1), Shack (2)
Note that the record numbers here are used simply as tags or virtual
record identifiers to indicate when 2 tokens appear in the same
record. The record identifiers are not used for any part of any
query to the WDSP.
There is some discussion as to whether the use of the same record tag
for all attributes makes it too easy to "decompile" the index object;
i.e., reconstruct a WDSPs data based on re-ordering the tokens
associated with each attribute and tag number. However, we are
dealing only with the search attributes here, which is a minimal
subset of the quantity of data held by the WDSP. The conclusion is
then that the improved efficiency given by using the same tag numbers
across attributes outweighs the (remote) possibility of information
reconstruction.
This would yield the index object:
version: x-tagged-index-1
update-type: total
this-update: 855938804
last-update:
context-size:
BEGIN IO-Schema
objectclass: TOKEN
FN: TOKEN
ORG: TOKEN
END IO-Schema
BEGIN Index-Info
objectclass: */dagperson
FN: 1/Foo
-1,2/Bar
-2/Smith
ORG: 1/The
-1,2/Snack
-1/Bar
-2/Shack
End Index-Info
TISDAG: Within the project it has been decided to base consistency
between updates on consistent tags. This means that if the
update-type is "incremental" the specifier must be "tagbased".
E.3 CIP Index Object Sharing
E.3.1 Registration of Servers
It is beyond the scope of this document to define how WDSP servers
shall be registered with the DAG Referral Index. Such a procedure
must be defined, and the following information established for each
WDSP dataset (adapted from the Tagged Index Object specification,
[12]):
dsi: An OID which uniquely identifies the subtree and scope of the
dataset for which the index object is created.
base-uri: One or more URI's which will form the base of any referrals
created based upon the index object that is governed by this
agreement. For example, for LDAP the base-uri would specify (among
other items): the LDAP host, the base object to which this index
object refers (e.g., c=SE), and the scope of the index object
(e.g., single container).
supplier: The hostname and listening port number of the supplier
server, as well as any alternative servers holding that same naming
contexts, in case the supplier is unavailable.
source-uri: The URI of the WDSP's preferred source of directory
service information. This might be, for instance, an HTTP-based
service.
consumeraddr: This is a URI of the "mailto:" form, with the RFC822
email address of the consumer server.
updateinterval: The maximum duration in seconds between occurrences
of the supplier server generating an update. If the consumer
server has not received an update from the supplier server after
waiting this long since the previous update, it is likely that the
index information is now out of date. A typical value for a server
with frequent updates would be 604800 seconds, or every week.
attributeNamespace: Every set of index servers that together wants to
support a specific usage of indices, has to agree on which
attributenames to use in the index objects. The participating
directory servers also has to agree on the mapping from local
attributenames to the attributenames used in the index. Since one
specific index server might be involved in several such sets, it
has to have some way to connect a update to the proper set of
indexes. One possible solution to this would be to use different
DSIs.
consistencybase: How consistency of the index is maintained over
incremental updates:
complete - every change or delete concerning one object has to
contain all tokens connected to that object. This method must be
supported by any server who wants to comply with this standard
tagbased - starting at a full update every incremental update
referring back to this full updated has to maintain state-
information regarding tags, such that a object within the
original database is assigned the same tagnumber every time.
This method is optional.
uniqueID - every object in the Dataset has to have a unique value
for a specific attribute in the index. A example of such a
attribute could be the distinguishedName attribute. This method
is also optional.
securityoption: Whether and how the supplier server should sign and
encrypt the update before sending it to the consumer server.
Options for this version of the DAG service are "none": the update
is sent in plaintext "PGP/MIME": the update is digitally signed and
encrypted using PGP (see [7]). PGP/MIME is recommended.
security credentials: The long-term cryptographic credentials used
for key exchange and authentication of the consumer and supplier
servers, if a security option was selected. For "PGP/MIME", this
will be the trusted public keys of both servers.
E.3.2 Transmission of Objects
CIP Index Objects are sent to the DAG Referral Index by MIME-encoded
SMTP, following the Common Indexing Protocol specification (see [2]
and [3]).
Appendix F - Summary of Technical Survey Results
As part of the TISDAG project, a technical survey was carried out --
announced on the tisdag@swip.net mailing list, all Swedish WDSPs (and
potential WDSPs) were encouraged to fill out and submit the WWW-based
survey form (see http://tisdag.sunet.se/tisdag-survey.html).
The survey was carried out in May, 1997. Response was not as good as
had been hoped -- in the end, 5 WDSPs participated. We had hoped for
more responses than this, in order to have a concrete sense of
directory service providers' current and planned status. However,
informal "hallway" conversations with a few people at
Interoperabilitet'97 in Sollentuna suggest that, while people see the
TISDAG project as an important and timely step, they don't
necessarily have an immediate understanding of how it will impact
them, and what they can/should contribute. So, the results can be
seen as informational, though not a definitive statement of the whole
directory service picture in Sweden.
Interesting things to note from these results include the fact that,
although there were only 5 respondents, these are clearly significant
players -- 4 expect to have more than 100 000 records to contribute
by 12 months from now. There were no real surprises in terms of the
supported protocols or search types.
Table E.1 summarizes information from the survey concerning types of
queries currently supported by WDSPs, and planned for the next 12
months. Note that, at the time of the survey, the requirement of
searching by ROLE had not been proposed, so the survey did not
specifically ask if WDSPs supported both the DAGPERSON schema
protocol-equivalents (i.e., USER template in Whois++ and
inetorgperson objectclass in LDAP). In the table, the column
"Complete info?" describes whether or not the WDSP currently returns
at least as much information as is required for a DAG reply.
Resp Search Types Complete info? Access Protocols Access Protocols
(now) (12 months)
---- ------------ -------------- ---------------- ----------------
1 NOL Except ROLE Whois++ Whois++
2 N,NO,NL,NOL Except ROLE LDAPv2,DAP,PH, LDAPv2,LDAPv3,DAP,
HTTP,Gopher PH,HTTP,Gopher
3 N,NL,NOL Except ROLE LDAPv2,DAP,HTTP LDAPv2,LDAPv3,DAP,
HTTP
4 N,NO,NL,NOL Except ROLE Whois++,HTTP LDAPv3,Whois++,
HTTP,E-mail
5 N,NO,NL,NOL Except ROLE LDAPv2,Whois LDAPv2,LDAPv3,
Whois++,HTTP Whois,Whois++,PH,
Finger,HTTP
Table F.1 Summary of TISDAG Survey Results: Queries
Resp # of Records (now) # of Records (12 months) Character Sets
----- ------------------ ------------------------ --------------
1 94 280 120 000 - 130 000 ISO-8859-1
2 88 000 100 000 ISO-8859-1
3 N/A 100 000 T.61 (Telex)
4 150 000 250 000 ISO-8859-1
UTF-8 UNICODE
5 4 300 10 000 ISO-8859-1
Table F.2 Summary of TISDAG Survey Results: Operational Information
Appendix G - Useful References
N.B.: The following is a collection of Internet standards documents
(RFCs) and Internet-Drafts from which the material in this report was
drawn. Internet-Drafts are works-in-progress, and are not meant to
be cited. Where they are used in this document, references are to
the text contained in the Internet-Draft; i.e., they are not meant to
imply standards, so much as useful starting points for the work of
this project.
Electronic copies of the version of the Internet-Drafts documents
that were used in preparing this report are available from the
project web page, http://tisdag.sunet.se.
Bibliography
[1] Allen, J. and M. Mealling, "The Architecture of the Common
Indexing Protocol", RFC2651, August 1999.
[2] Allen, J. and M. Mealing, "MIME Object Definitions for the
Common Indexing Protocol (CIP)", RFC2652, August 1999.
[3] Allen, J. and P. Leach, "CIP Transport Protocols", RFC2653,
August 1999.
[4] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC822, August 1982.
[5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
RFC2234, November 1997.
[6] Deutsch, P., Schoultz, R., Falstrom, P. and C. Weider,
"Architecture of the WHOIS++ Service", RFC1835, July 1995.
[7] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
2015, October 1996.
[8] Patrik Faltstrom, Martin Hamilton, Leslie L. Daigle, "WHOIS++
templates", Work in Progress.
[9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Interent Message Bodies",
RFC2045, November 1996.
[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC2046, November
1996.
[11] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical
Specification", RFC2849, June 2000.
[12] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged
Index Object for use in the Common Indexing Protocol", RFC2654,
August 1999.
[13] Howes, R., "A String Representation of LDAP Search Filters", RFC
1960, June 1996.
[14] Paul Panotzki, "Complexity of the Common Indexing Protocol:
Predicting Search Times in Index Server Meshes", Master's
Thesis, KTH, September 1996.
[15] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821,
August 1982.
[16] Smith, M., "Definition of the inetOrgPerson Object Class", RFC
2798, April 2000.
[17] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC2251, December 1997.
[18] Wahl, M., "A summary of the X.500(96) User Schema for use with
LDAPv3", RFC2256, December 1997.
[19] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", RFC1777, March 1995.
[20] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[21] The Unicode Consortium, "The Unicode Standard -- Version 2.0",
Addison-Wesley, 1996.
Authors' Addresses
Leslie L. Daigle
Thinking Cat Enterprises
EMail: leslie@thinkingcat.com
Roland Hedberg
Catalogix
Jegerveien 25
0777 Oslo
Norway
Phone: +47 23 08 29 96
EMail: Roland@catalogix.se
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.