doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc2655.txt b/doc/rfc/rfc2655.txt
new file mode 100644
index 0000000..e39ba34
--- /dev/null
+++ b/doc/rfc/rfc2655.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                           T. Hardie
+Request for Comments: 2655                                        Equinix
+Category: Experimental                                          M. Bowman
+                                                                 Transarc
+                                                                 D. Hardy
+                                                                 Netscape
+                                                              M. Schwartz
+                                                            Affinia, Inc.
+                                                               D. Wessels
+                                                                    NLANR
+                                                              August 1999
+
+                CIP Index Object Format for SOIF Objects
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1.  Abstract
+
+   The Common Indexing Protocol (CIP) allows servers to form a referral
+   mesh for query handling by defining a mechanism by which cooperating
+   servers exchange hints about the searchable indices they maintain.
+   The structure and transport of CIP are described in (Ref. 1), as are
+   general rules for the definition of index object types.  This
+   document describes SOIF, the Summary Object Interchange Format, as an
+   index object type in the context of the CIP framework.  SOIF is a
+   machine-readable syntax for transmitting structured summary objects,
+   currently used primarily in the context of the World Wide Web.
+
+   Query referral has often been dismissed as an ineffective strategy
+   for handling searches of Web resources, and Web resources certainly
+   present challenges not present in structured directory services like
+   Rwhois.  In situations where a keyword-based free text search is
+   desired, query referral is not likely to be effective because the
+   query will probably be routed to every server participating in the
+   referral mesh.  Where a search can be limited by reference to a
+   specific resource attribute, however, query referral is an effective
+   tool.  SOIF can be used to create such a known-attribute query mesh
+   because it provides a method for associating attributes with net-
+   addressable resources.
+
+
+
+Hardie, et al.                Experimental                      [Page 1]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+1.1 History
+
+   SOIF was first defined by the Harvest project [Ref 2.] in January
+   1994.  SOIF was derived from a combination of the Internet Anonymous
+   FTP Archives IETF Working Group (IAFA) templates [Ref 3.] and the
+   BibTeX bibliography format [Ref 4.].  The combination was originally
+   noted for its advantages of providing a convenient and intuitive way
+   for delimiting objects within a stream, and setting apart the URL for
+   easy object access or invocation, while still preserving
+   compatibility with IAFA templates.
+
+   Mic Bowman, Darren Hardy, Mike Schwartz, and Duane Wessels each
+   contributed to the creation of the SOIF format as part of the Harvest
+   Project; later work took place as part of the FIND working group.
+
+2.  Name
+
+   The index object described below will have the MIME type of
+   application/index.obj.HARVEST-SOIF-1.
+
+3.  Payload Format
+
+   Each summary object has 3 fundamental components: a template type, a
+   URL, and zero or more ATTRIBUTE-VALUE pairs.  Because the VALUEs in
+   the ATTRIBUTE-VALUE pairs may contain arbitrary data (cf. Section
+   3.5), SOIF objects should be encoded in Base64 unless the template
+   type unambiguously establishes that the VALUEs do not contain binary
+   data.
+
+3.1  Template Type
+
+   The Template type is used to identify the set of ATTRIBUTEs contained
+   within a particular SOIF object.  SOIF does not define the template
+   types themselves; it only provides a way to associate the summary
+   object with a predefined template type name.  Template types may be
+   registered or unregistered.  Unregistered template types provide an
+   indication of available ATTRIBUTE-VALUE pairs, but these may vary
+   both according to the original resource and the method by which the
+   summary object was generated.  Registered template types must refer
+   to a formally specified description of all mandatory and optional
+   ATTRIBUTE-VALUE pairs available for that type.  See [10] for a
+   description of the process of registering template types with the
+   IANA.
+
+   Historically, the template types used by SOIF were derived from IAFA
+   template types (Ref. 3). SOIF objects generated by the Harvest system
+   have a "FILE" template type; in current practice this is the most
+   common template type.  The "FILE" template type is a generic template
+
+
+
+Hardie, et al.                Experimental                      [Page 2]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+   type meant to handle a large variety of web-based resources.  No
+   formal specification of it is available, though a list of ATTRIBUTE-
+   VALUE pairs common to the "FILE" template type is found in Appendix
+   A.  "DOCUMENT" and "OBJECT" are other generic template-types.
+
+   The use of unregistered template types obviously presents some
+   problems to the correct operation of query referral.  Two efforts
+   have been mounted to allow peer-to-peer agreement on the association
+   of template types with specific attribute sets: Netscape's RDM (Ref.
+   6) and the STARTS project (Ref. 7).  Initially, CIP meshes based on
+   systems which use unregisterested template types may need to use
+   these or similar methods to associate template types with specific
+   attribute sets.
+
+   Mesh operators are strongly encouraged, however, to migrate to
+   registered template types as soon as is practical.  Registered
+   template types allow CIP meshes to derive the definitions of
+   attributes, which enables multiple-language interfaces to the base
+   attributes.  In addition, registered template types allow CIP meshes
+   and other users of SOIF to establish the permitted data types and
+   encodings of the VALUEs associated with each ATTRIBUTE.  This makes
+   deriving the appropriate matching semantics for a particular VALUE
+   much more straightforward and eliminates the limitations of the
+   default octet-by-octet matching (cf. Section 4.).
+
+3.2  URL
+
+   Uniform Resource Locators (URLs) (Ref 5.) are used by SOIF as object
+   IDENTIFIERs.  SOIF associates its summary objects with net-
+   addressable resources by using the URL by which the resource was
+   addressed as the initial field of the object body.  See section 3.4
+   for the formal grammar associated with SOIF objects.
+
+   This association allows the same resource to have multiple summary
+   objects, differentiated only by the URL by which the resource was
+   accessed.  This possibility does not, however, impact the usability
+   of the URL as an object IDENTIFIER. Furthermore, since it can be
+   argued that the net address is a salient part of the metadata, there
+   may be compensating benefits to using the URL as an object
+   IDENTIFIER.
+
+   As noted in Appendix A, the Harvest project used several additional
+   identity attributes ("Gatherer-Name", "Gatherer-Host", "Gatherer-
+   Port" and "Gatherer-Version") to further identify the provenance of a
+   particular object.  Within the context of CIP, it may be useful to
+   identify the base sources of particular index objects; see Appendix B
+   for one example of how a SOIF-based CIP hint could use the base
+   source URL.
+
+
+
+Hardie, et al.                Experimental                      [Page 3]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+3.3  ATTRIBUTE-VALUE pairs.
+
+   Each summary object has zero or more ATTRIBUTE-VALUE pairs, which
+   contain metadata about the net-addressable resource referenced by the
+   URL.  Pairs are composed of an ATTRIBUTE IDENTIFIER, the length of
+   the VALUE, a delimeter, and the VALUE.  It should be stressed that
+   ATTRIBUTE VALUE pairs are not CR/LF terminated, but parsed according
+   to grammar set out in section 3.4.  In the examples in Section 3.6
+   and in many other representations of SOIF objects, ATTRIBUTE-VALUE
+   pairs are represented on individual lines to enhance readability.
+   VALUEs may contain CR/LF, however, and implementors must be careful
+   to parse the full VALUE.  Implementors of SOIF parsers MUST ignore
+   <CR>,<LF>,<TAB>,<SPACE>, or other whitespace found between the VALUE
+   of an ATTRIBUTE-VALUE pair and the ATTRIBUTE-IDENTIFIER of the
+   subsequent pair.
+
+   The SOIF syntax does not explicitly allow for a single ATTRIBUTE to
+   have multiple VALUEs.  To handle multiple VALUEs for the same
+   ATTRIBUTE, SOIF uses an ATTRIBUTE naming convention; a hyphen and
+   positive integer are appended to the ATTRIBUTE name to create an
+   ATTRIBUTE IDENTIFIER VALUE associated with a specific ATTRIBUTE.  For
+   example, the ATTRIBUTE IDENTIFIERs "Author-1", "Author-2", and
+   "Author-3" can be used to represent three VALUEs associated with the
+   ATTRIBUTE "Author" where a specific resource has three authors.  See
+   section 4 for the implications of this strategy on matching
+   semantics.
+
+3.4  SOIF Grammar
+
+   The SOIF syntax is defined by the following grammar:
+
+      SOIF            ::=  OBJECT SOIF |
+                           OBJECT
+      OBJECT          ::=  @ TEMPLATE-TYPE { URL ATTRIBUTE-LIST }
+      TEMPLATE-TYPE   ::=  IDENTIFIER
+      ATTRIBUTE-LIST  ::=  ATTRIBUTE ATTRIBUTE-LIST |
+                           ATTRIBUTE |
+                           NULL
+      ATTRIBUTE       ::=  IDENTIFIER {VALUE-SIZE} DELIMITER VALUE
+      URL             ::=  RFC1738-URL-Syntax | "-"
+      IDENTIFIER      ::=  ALPHA-NUMERIC-STRING
+      VALUE           ::=  ARBITRARY-DATA
+      VALUE-SIZE      ::=  NUMERIC-STRING
+      DELIMITER       ::=  ":<TAB>"
+
+
+
+
+
+
+
+Hardie, et al.                Experimental                      [Page 4]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+3.5   Grammar Description
+
+   URL
+      a Uniform Resource Locator encoded in the syntax defined by RFC
+      1738 [3].  If the summary object has no URL associated with it,
+      then a Latin-1 hyphen (octal \055) is used instead.
+
+   IDENTIFIER
+      an ASCII character string that only contains alphanumeric
+      characters and hyphens or underscores.  IDENTIFIERs should avoid
+      including hyphens followed by positive integers except when
+      constructing multiple-VALUE ATTRIBUTE IDENTIFIERs.
+
+   VALUE
+      a buffer of VALUE-SIZE octets containing the VALUE.  The VALUE may
+      contain data in arbitrary formats or encodings, which recipients
+      recognize based on Template-Type.
+
+   VALUE-SIZE
+      a non-negative integer encoded as an ASCII character string.  The
+      integer indicates how many octets the VALUE occupies after the
+      DELIMITER.
+
+   DELIMITER
+      a two octet delimiter which is a Latin-1 colon (:) and a tab (\t),
+      (octal \072\011).
+
+   { }  the Latin-1 curly braces (octal \173 and \175) are used to wrap
+      the VALUE-SIZE (no spaces) as well as the URL and ATTRIBUTE-LIST
+      combination.
+
+   @TEMPLATE-TYPE
+      the Latin-1 @ (octal \100) and TEMPLATE-TYPE (no space between
+      them) is used to mark the beginning of the SOIF object.
+
+   NUMERIC-STRING
+      Zero or more ASCII numerals.
+
+   ALPHA-NUMERIC-STRING
+      Zero or more ASCII letters or numerals, plus hyphens or
+      underscore.  [a-z,A-Z,0-9,- and _].
+
+   ARBITRARY-DATA
+      Octets of data in arbitrary formats or encodings.
+
+
+
+
+
+
+
+Hardie, et al.                Experimental                      [Page 5]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+4.  Matching Semantics
+
+   As was discussed in Section 1, query referral of SOIF objects will be
+   most effective when a query identifies a particular ATTRIBUTE or set
+   of ATTRIBUTEs as the target of the query match.  A query-identified
+   ATTRIBUTE should be considered to match a SOIF ATTRIBUTE when a
+   case-insentive character-by-character comparison matches that portion
+   of the ATTRIBUTE IDENTIFIER prior to any hyphen-integer suffix.  For
+   example, a query which asks for a match on the ATTRIBUTE "author"
+   should match the IDENTIFIERs "author", "Author", "AUTHOR", and
+   "Author-1".  [10] discourages the registration of template types
+   containing ATTRIBUTEs which have previously been registered with
+   substantially different definitions.  This will help eliminate mis-
+   referral, but a CIP mesh may nonetheless need to maintain a thesaurus
+   matching ATTRIBUTEs from particular template-types to those of other,
+   especially unregistered, template-types.
+
+   The matching semantics appropriate for a particular VALUE are derived
+   from its data type and encoding.  For VALUEs associated with
+   ATTRIBUTEs which are part of a registered template type, the data
+   type and encoding are readily available.  For VALUEs associated with
+   ATTRIBUTES associated with unregistered template-types, an octet-by-
+   octet comparison is the default.  In cases where previous experience
+   has demonstrated that a particular ATTRIBUTE contains string data, a
+   case-insensitive substring match may be used.  For example, in a
+   query against the "AUTHOR" ATTRIBUTE of the generic "DOCUMENT"
+   template type, the query VALUE "Garcia" should match the SOIF VALUEs
+   "Garcia", "GARCIA", and "Jose Garcia y Montes".
+
+   Over time, there may well emerge an understanding of which attributes
+   tend to produce correct query referrals within a mesh.  As such
+   understandings emerge, mesh maintainers may wish to define a
+   particular SOIF TEMPLATE-TYPE which restricts included ATTRIBUTES to
+   those likely to foster correct referrals.
+
+5.  Internationalization
+
+   The internationalization of SOIF depends on the registration of
+   template-types.  Since TEMPLATE-TYPEs and ATTRIBUTE IDENTIFIERs must
+   be in ASCII characters, only languages which use the ASCII character
+   set are fully supported for unregistered TEMPLATE-TYPEs.  For
+   registered template types, in contrast, the specification of an
+   ATTRIBUTE's definition will allow UI designers to present a native-
+   language mapping of the ATTRIBUTE to the end user.  Further, the
+   inclusion of data type and encoding information in the description of
+   VALUEs means that any language encoding or character set required by
+   a particular application may be supported.  For unregistered template
+   types, the ability of peer servers to pass schema definitions may
+
+
+
+Hardie, et al.                Experimental                      [Page 6]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+   provide a form of "private registration" which could provide some of
+   the facilities for internationalization available to registered
+   template types.  (See above, section 3.1 and Refs. 6 and 7.)
+
+6.  Example Summary Objects
+
+   The appendices contain example summary objects encoded using specific
+   template types.  The following are some example summary objects using
+   the generic "DOCUMENT" SOIF template-type:
+
+   @DOCUMENT { http://home.netscape.com:80/
+   Title{19}:  Welcome to Netscape
+   Content-Type{9}:    text/html
+   Content-Length{5}:  33262
+   }
+
+   @DOCUMENT { http://home.netscape.com/eng/ssl3/ssl-toc.html
+   Title{19}:  SSL Protocol V. 3.0
+   Content-Type{9}:    text/html
+   Content-Length{5}:  5870
+   Author-1{14}:   Alan O. Freier
+   Author-2{14}:   Philip Karlton
+   Author-3{14}:   Paul C. Kocher
+   Abstract{318}:  This document specifies Version 3.0 of the
+   <B>Secure Sockets Layer (SSL V3.0)</B> protocol, a security
+   protocol that provides communications privacy over the Internet.
+   The protocol allows client/server applications to communicate in
+   a way that is designed to prevent eavesdropping, tampering, or
+   message forgery.
+   }
+
+   @DOCUMENT { http://www.nissanmotors.com/1996/300ZX/pictures/300zx.jpg
+   Content-Type{10}:    image/jpeg
+   Content-Length{5}:  25940
+   Last-Modified{31}:  Tuesday, 11-Jun-96 19:18:44 GMT
+   Thumbnail{259}:     ..................
+   }
+
+7.  Security
+
+   Please see (Ref. 1) for a general discussion of Security concerns for
+   the CIP framework.
+
+   SOIF currently contains no requirement that any template type contain
+   an authentication ATTRIBUTE.  SOIF summary objects lacking
+   authentication ATTRIBUTEs must, therefore, be treated as unreliable
+   indicators of the referenced resource's content.  A hostile party
+   could create a summary object which significantly misrepresented a
+
+
+
+Hardie, et al.                Experimental                      [Page 7]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+   resource's content.  As part of a CIP mesh, this data could either
+   channel a large number of requestors to a resource (possibly
+   resulting in a denial of service) or away from a resource (possibly
+   resulting in a loss of appropriate visibility).
+
+8.  References
+
+   [1]  Allen, J. and M. Mealling, "The Architecture of the Common
+        Indexing Protocol (CIP)", RFC 2651, August 1999.
+
+   [2]  The Harvest Information Discovery and Access System:
+        <URL:http://harvest.transarc.com/>.
+
+   [3]  D. Beckett, IAFA Templates in Use as Internet Metadata, 4th
+        Int'l WWW Conference, December 1995,
+        <URL:http://www.hensa.ac.uk/tools/www/iafatools/>
+
+   [4]  L. Lamport, LaTeX: A Document Preparation System, Addison-
+        Wesley, Reading, Mass., 1986.
+
+   [5]  Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
+        Locators (URL)", RFC 1738, December 1994.
+
+   [6]  D. Hardey, Resource Description Messages (RDM), W3C Note-rdm-
+        960724, July 24, 1996, <URL:http://www.w3.org/pub/WWW/TR/NOTE-
+        rdm.html>
+
+   [7]  L. Gravano, K. Chang, H. Garcia-Molina, C. Lagoze, A. Paepcke,
+        STARTS: Stanford Protocol Proposal for Internet Retrieval and
+        Search, January 1997, <URL:http://www-
+        db.stanford.edu/~gravano/starts.html>
+
+   [8]  S. Weibel, J. Kunze, C. Lagoze, Dublin Core Metadata for Simple
+        Resource Description, Work in Progress.
+
+   [9]  E. Miller, Dublin Core Element Set Crosswalk, January 1997,
+        <URL:http://www.oclc.org:5046/~emiller/DC/crosswalk.html>
+
+   [10] Hardie, T., "Registration Procedures for SOIF Template Types",
+        RFC 2656, August 1999.
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.                Experimental                      [Page 8]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+9.  Authors' Addresses
+
+   Ted Hardie
+   Equinix
+   901 Marshall Street
+   Redwood City, CA 94063 USA
+
+   EMail: hardie@equinix.com
+
+
+   Mic Bowman
+   Transarc Corporation
+   The Gulf Tower
+   707 Grant Street
+   Pittsburgh, PA 15219 USA
+
+   Phone: +1 412 338 4400
+   EMail: mic@transarc.com
+
+
+   Darren Hardy
+   Netscape Communications Corp.
+   685 E. Middlefield Road
+   Mountain View, CA 94043 USA
+
+   Phone: +1 415 937 2555
+   EMail: dhardy@netscape.com
+
+
+   Mike Schwartz
+   Affinia, Inc.
+   621 17th Street, Suite 1700
+   Denver, CO 80293
+
+   Phone: +1 (303) 292-4818
+   E-mail: mfs@affinia.net
+
+
+   Duane Wessels
+   National Laboratory for Applied Network Research
+
+   Phone: +1 303 497 1822
+   EMail: wessels@nlanr.net
+
+
+
+
+
+
+
+
+Hardie, et al.                Experimental                      [Page 9]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+Appendix A.
+
+   Common Attributes for "FILE" Template-type Summary Objects created by
+   Harvest:
+
+   Abstract
+      Brief abstract about the object.
+
+   Author
+      Author(s) of the object.
+
+   Description
+      Brief description about the object.
+
+   File-Size
+      Number of bytes in the object.
+
+   Full-Text
+      Entire contents of the object.
+
+   Gatherer-Host
+      Host on which the Gatherer ran to extract information from the
+      object.
+
+   Gatherer-Name
+      Name of the Gatherer that extracted information from the object.
+      (eg. Full-Text, Selected-Text, or Terse).
+
+   Gatherer-Port
+      Port number on the Gatherer-Host that serves the Gatherer's
+      information.
+
+   Gatherer-Version
+      Version number of the Gatherer.
+
+   Update-Time
+      The time that Gatherer updated the content summary for the object.
+
+   Keywords
+      Searchable keywords extracted from the object.
+
+   Last-Modification-Time
+      The time that the object was last modified.
+
+   MD5
+      MD5 16-byte checksum of the object.
+
+
+
+
+
+Hardie, et al.                Experimental                     [Page 10]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+   Refresh-Rate
+      The number of seconds after Update-Time when the summary object is
+      to be re-generated.  Defaults to 1 month.
+
+   Time-to-Live
+      The number of seconds after Update-Time when the summary object is
+      no longer valid.  Defaults to 6 months.
+
+   Title
+      Title of the object.
+
+   Type The object's type. Some example types are:
+
+         Archive
+         Audio
+         Awk
+         Backup
+         Binary
+         C
+         CHeader
+         Command
+         Compressed
+         CompressedTar
+         Configuration
+         Data
+         Directory
+         DotFile
+         Dvi
+         FAQ
+         FYI
+         Font
+         FormattedText
+         GDBM
+         GNUCompressed
+         GNUCompressedTar
+         HTML
+         Image
+         Internet-Draft
+         MacCompressed
+         Mail
+         Makefile
+         ManPage
+         Object
+         OtherCode
+         PCCompressed
+         Patch
+         Perl
+         PostScript
+
+
+
+Hardie, et al.                Experimental                     [Page 11]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+         RCS
+         README
+         RFC
+         SCCS
+         ShellArchive
+         Tar
+         Tcl
+         Tex
+         Text
+         Troff
+         Uuencoded
+         WaisSource
+
+   Update-Time
+      The time that the summary object was last updated.  REQUIRED
+      field, no default.
+
+   URL-References
+      Any URL references present within HTML objects.
+
+Appendix B.
+
+   Proposed Attributes for a "CIP-HINT" Template Type
+
+   Attribute-Identifier-List
+      A comma-delimited list whose entries take the form Template-
+      Type:Attribute .  This list identifies the attributes against
+      which queries are supported.  Because of the current limitation on
+      Identifiers, this list must be in ASCII.
+
+   Source
+      The URI of the service which created some or all of the index
+      objects to which this hint applies.  Note that this service may be
+      and often is distinct from the server which provides query access
+      to those objects.
+
+   Total-Object-Count
+      The total number of index objects in the collection for which the
+      Hint applies.  This should be a positive integer.
+
+   Weightlist-[Attribute-Identifier]
+      This construction allows the HINT to contain a weighted list of
+      values for a specific Attribute-Identifier.  There may be as many
+      Weightlist entries as there Attribute-Identifiers in the
+      Attribute-Identifier-List.  Each Weightlist entry takes the form
+      of Value;Object-Count, where the object count is a positive
+      integer representing the number of objects within the collection
+      which contain that value. Weightlists are comma- delimited.
+
+
+
+Hardie, et al.                Experimental                     [Page 12]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+      Should a Value contain a comma, it should be escaped when
+      incorporated into the weightlist.
+
+   Threshold-[Attribute-Identifier]
+      If a server wishes not to report infrequently occurring Values in
+      a specific Weightlist, it may declare a threshold under which it
+      will not report Values.
+
+   Certification-Type
+      The type of Certification used for this object
+
+   Certification
+      The Value of the Certification.
+
+   Date
+      The Date at which the hint was generated
+
+   Example:
+
+@CIP-HINT{ http://nic.nasa.gov:80/Harvest/brokers/NASA/
+Attribute-Identifier-list{49}:
+DOCUMENT:Author, DOCUMENT:Keywords, IMAGE:Subject
+Source-1{45}: http://nic.nasa.gov/Harvest/gatherers/Eureka/
+Source-2{46}: http://techreports.larc.nasa.gov/cgi-bin/NTRS/
+Total-Object-Count{5}:    10000
+Weightlist-[IMAGE:Subject]{40}:
+Shuttle;100, Planet;227, Moon;15, Sun;33
+Threshold-[IMAGE:Subject]{2}:     10
+Weightlist-[DOCUMENT:Author]{49}:
+Grizzard;12, Aldrin\, Buzz;15, Aldrin\, James;45,
+Threshold-[DOCMENT:Author]{1}:    5
+Certification-Type{13}:   PGP-Signature
+Certification{51}: mQCNAzFNm5QAAEEALUBOolOWKpby+=YtmtBxUZWQgSGFyZGllID
+Date{29}:  Sun, 05 Jan 1997 08:33:33 GMT
+}
+
+Appendix C.
+
+   A "Dublin-Core" Template Type [Ref. 8,9]
+
+   TITLE
+      The name given to the resource by the CREATOR or PUBLISHER.
+
+   CREATOR
+      The person(s) or organization(s) primarily responsible for the
+      intellectual content of the resource.  For example, authors in the
+      case of written documents, artists, photographers, or illustrators
+      in the case of visual resources.
+
+
+
+Hardie, et al.                Experimental                     [Page 13]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+   SUBJECT
+      The topic of the resource, or keywords or phrases that describe
+      the subject or content of the resource.  The intent of the
+      specification of this element is to promote the use of controlled
+      vocabularies and keywords.  This element might well include
+      scheme-qualified classification data (for example, Library of
+      Congress Classification Numbers or Dewey Decimal numbers) or
+      scheme-qualified controlled vocabularies (such as Medical Subject
+      Headings or Art and Architecture Thesaurus descriptors) as well.
+
+   DESCRIPTION
+      A textual description of the content of the resource, including
+      abstracts in the case of document-like objects or content
+      descriptions in the case of visual resources.  Future metadata
+      collections might well include computational content description
+      (spectral analysis of a visual resource, for example) that may not
+      be embeddable in current network systems.  In such a case this
+      field might contain a link to such a description rather than the
+      description itself.
+
+   PUBLISHER
+      The entity responsible for making the resource available in its
+      present form, such as a publisher, a university department, or a
+      corporate entity.   The intent of specifying this field is to
+      identify the entity that provides access to the resource.
+
+   CONTRIBUTOR
+      Person(s) or organization(s) in addition to those specified in the
+      CREATOR element who have made significant intellectual
+      contributions to the resource but whose contribution is secondary
+      to the individuals or entities specifed in the CREATOR element
+      (for example, editors, transcribers, illustrators, and convenors).
+
+   DATE
+      The date the resource was made available in its present form.  The
+      recommended best practice is an 8 digit number in the form
+      YYYYMMDD as defined by ANSI X3.30-1985. In this scheme, the date
+      element for the day this is written would be 19961203, or December
+      3, 1996.  Many other schema are possible, but if used, they should
+      be identified in an unambiguous manner.
+
+   TYPE
+      The category of the resource, such as home page, novel, poem,
+      working paper, technical report, essay, dictionary.  It is
+      expected that RESOURCE TYPE will be chosen from an enumerated list
+      of types.
+
+
+
+
+
+Hardie, et al.                Experimental                     [Page 14]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+   FORMAT
+      The data representation of the resource, such as text/html, ASCII,
+      Postscript file,  executable application, or JPEG image.  The
+      intent of specifying this element is to provide information
+      necessary to allow people or machines to make decisions about the
+      usability of the encoded data (what hardware and software might be
+      required to display or execute it, for example).  As with RESOURCE
+      TYPE, FORMAT will be assigned from enumerated lists such as
+      registered Internet Media Types (MIME types).  In principal,
+      formats can include physical media such as books, serials, or
+      other non-electronic media.
+
+   IDENTIFIER
+      String or number used to uniquely identify the resource.  Examples
+      for networked resources include URLs and URNs (when implemented).
+      Other globally-unique identifiers,such as International Standard
+      Book Numbers (ISBN) or other formal names would also be candidates
+      for this element.
+
+   SOURCE
+      The work, either print or electronic, from which this resource is
+      derived, if applicable. For example, an html encoding of a
+      Shakespearean sonnet might identify the paper version of the
+      sonnet from which the electronic version was transcribed.
+
+   LANGUAGE
+      Language(s) of the intellectual content of the resource.  Where
+      practical, the content of this field should coincide with the NISO
+      Z39.53 three character codes for written languages.
+
+   RELATION
+      Relationship to other resources.  The intent of specifying this
+      element is to provide a means to express relationships among
+      resources that have formal relationships to others, but exist as
+      discrete resources themselves.  For example, images in a document,
+      chapters in a book, or items in a collection.  A formal
+      specification of RELATION is currently under development.  Users
+      and developers should understand that use of this element should
+      be currently considered experimental.
+
+   COVERAGE
+      The spatial locations and temporal durations characteristic of the
+      resource.    Formal specification of COVERAGE is currently under
+      development. Users and developers should understand that use of
+      this element should be currently considered experimental.
+
+
+
+
+
+
+Hardie, et al.                Experimental                     [Page 15]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+   RIGHTS
+      The content of this element is intended to be a link (a URL or
+      other suitable URI as appropriate) to a copyright notice, a
+      rights-management statement, or perhaps a server that would
+      provide such information in a dynamic way.  The intent of
+      specifying this field is to allow providers a means to associate
+      terms and conditions or copyright statements with a resource or
+      collection of resources.   No assumptions should be made by users
+      if such a field is empty or not present.
+
+   Example:
+
+@Dublin-Core-1 { ftp://ds.internic.net/internet-drafts/
+                 draft-kunze-dc-00.txt
+TITLE{52}:      Dublin Core Metadata for Simple Resource Description
+CREATOR-1{9}:   S. Weibel
+CREATOR-2{8}:   J. Kunze
+CREATOR-3{9}:   C. Lagoze
+SUBJECT{44}:    The Dublin Core Set of Elements for Metadata
+DESCRIPTION{46}:        Reference description of Dublin Core elements.
+PUBLISHER{31}:  Internet Engineering Task Force
+CONTRIBUTOR-1{11}:      Nick Arnett
+CONTRIBUTOR-2{15}:      Eliot Christian
+CONTRIBUTOR-3{14}:      Martijn Koster
+CONTRIBUTOR-4{18}:      Christian Mogensen
+CONTRIBUTOR-5{14}:      Timothy Niesen
+CONTRIBUTOR-6{11}:      Andrew Wood
+CONTRIBUTOR-7{10}:      Mic Bowman
+CONTRIBUTOR-8{11}:      Dan Connoly
+CONTRIBUTOR-9{15}:      Michael Mauldin
+CONTRIBUTOR-10{12}:     Wick Nichols
+DATE{16}:       February 9, 1997
+TYPE{14}:       Internet draft
+FORMAT{4}:      Text
+IDENTIFIER:{21} draft-kunze-dc-00.txt
+SOURCE{41}:     http://purl.oclc.org/metadata/dublin_core
+LANGUAGE{3}:    eng
+RELATION{24}:   Draft Reference Standard
+COVERAGE{22}:   Expires August 8, 1997
+RIGHTS{58}:     Unlimited Distribution;
+                readers must not cite as standard.
+}
+
+
+
+
+
+
+
+
+
+Hardie, et al.                Experimental                     [Page 16]
+
+RFC 2655        CIP Index Object Format for SOIF Objects     August 1999
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie, et al.                Experimental                     [Page 17]
+