Movatterモバイル変換

Network Working Group                                           T. HardieRequest for Comments: 2655                                        EquinixCategory: Experimental                                          M. Bowman                                                                 Transarc                                                                 D. Hardy                                                                 Netscape                                                              M. Schwartz                                                            Affinia, Inc.                                                               D. Wessels                                                                    NLANR                                                              August 1999CIP Index Object Format for SOIF ObjectsStatus 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 19991.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.Section3.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 templateHardie, 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 inAppendixA.  "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.  Seesection 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 inAppendix 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; seeAppendix 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 19993.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 insection 3.4.  In the examples inSection 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.  Seesection 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 19993.5   Grammar Description   URL      a Uniform Resource Locator encoded in the syntax defined byRFC1738 [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 19994.  Matching Semantics   As was discussed inSection 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 mayHardie, 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 aHardie, 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 19999.  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.netHardie, et al.                Experimental                      [Page 9]

RFC 2655        CIP Index Object Format for SOIF Objects     August 1999Appendix 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         PostScriptHardie, 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:SubjectSource-1{45}:http://nic.nasa.gov/Harvest/gatherers/Eureka/Source-2{46}:http://techreports.larc.nasa.gov/cgi-bin/NTRS/Total-Object-Count{5}:    10000Weightlist-[IMAGE:Subject]{40}:Shuttle;100, Planet;227, Moon;15, Sun;33Threshold-[IMAGE:Subject]{2}:     10Weightlist-[DOCUMENT:Author]{49}:Grizzard;12, Aldrin\, Buzz;15, Aldrin\, James;45,Threshold-[DOCMENT:Author]{1}:    5Certification-Type{13}:   PGP-SignatureCertification{51}: mQCNAzFNm5QAAEEALUBOolOWKpby+=YtmtBxUZWQgSGFyZGllIDDate{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.txtTITLE{52}:      Dublin Core Metadata for Simple Resource DescriptionCREATOR-1{9}:   S. WeibelCREATOR-2{8}:   J. KunzeCREATOR-3{9}:   C. LagozeSUBJECT{44}:    The Dublin Core Set of Elements for MetadataDESCRIPTION{46}:        Reference description of Dublin Core elements.PUBLISHER{31}:  Internet Engineering Task ForceCONTRIBUTOR-1{11}:      Nick ArnettCONTRIBUTOR-2{15}:      Eliot ChristianCONTRIBUTOR-3{14}:      Martijn KosterCONTRIBUTOR-4{18}:      Christian MogensenCONTRIBUTOR-5{14}:      Timothy NiesenCONTRIBUTOR-6{11}:      Andrew WoodCONTRIBUTOR-7{10}:      Mic BowmanCONTRIBUTOR-8{11}:      Dan ConnolyCONTRIBUTOR-9{15}:      Michael MauldinCONTRIBUTOR-10{12}:     Wick NicholsDATE{16}:       February 9, 1997TYPE{14}:       Internet draftFORMAT{4}:      TextIDENTIFIER:{21}draft-kunze-dc-00.txtSOURCE{41}:http://purl.oclc.org/metadata/dublin_coreLANGUAGE{3}:    engRELATION{24}:   Draft Reference StandardCOVERAGE{22}:   Expires August 8, 1997RIGHTS{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 199911.  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]