diff options
Diffstat (limited to 'doc/rfc/rfc2655.txt')
| -rw-r--r-- | doc/rfc/rfc2655.txt | 955 |
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] + |