RFC 2655
CIP Index Object Format for SOIF Objects
RFC 2655: CIP Index Object Format for SOIF Objects 💖
okay bestie, let's get into RFC 2655 🎀 It's an Experimental doc (so it's not a standard, just a proposal people can poke at), written by T. Hardie (Equinix), M. Bowman (Transarc), D. Hardy (Netscape), M. Schwartz (Affinia, Inc.) and D. Wessels (NLANR), dated August 1999. The title block doesn't list anything it obsoletes or updates 🦋
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 🌸
okay so the Common Indexing Protocol (CIP) lets servers form a referral mesh for handling queries 🕸️ It does this by giving cooperating servers a way to swap hints about the searchable indices they keep. How CIP is structured and transported is covered in (Ref. 1), and so are the general rules for defining index object types. This document is about SOIF, the Summary Object Interchange Format, which is an index object type used within the CIP framework. SOIF is a machine-readable syntax for sending structured summary objects, and it's mostly used around the World Wide Web right now 🌈
ngl, query referral gets dismissed a lot as a bad strategy for searching Web resources. Web resources are honestly tricky in ways that structured directory services like Rwhois just aren't 😭 If you want a keyword-based free text search, referral isn't likely to work well, because the query will probably get routed to every single server in the mesh. But if the search can be narrowed by a specific resource attribute, referral becomes a really effective tool ✨ That's where SOIF comes in, because it gives a way to attach attributes to net-addressable resources, so you can build a known-attribute query mesh. iconic 👑
1.1 History 🧚
SOIF was first defined by the Harvest project [Ref 2.] in January 1994. It was derived from a mix of the Internet Anonymous FTP Archives IETF Working Group (IAFA) templates [Ref 3.] and the BibTeX bibliography format [Ref 4.]. The mix was originally loved for being a convenient, intuitive way to delimit objects inside a stream, and to set apart the URL for easy object access or invocation, all while staying compatible with IAFA templates 🍓
Mic Bowman, Darren Hardy, Mike Schwartz, and Duane Wessels each helped create the SOIF format as part of the Harvest Project. Later work happened under the FIND working group 💜
2. Name 🦋
The index object described below has the MIME type 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. The VALUEs in those pairs can hold arbitrary data (cf. Section 3.5), so 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 identifies the set of ATTRIBUTEs inside a particular SOIF object. SOIF doesn't define the template types themselves. It just gives a way to link the summary object to a predefined template type name 🧚 Template types can be registered or unregistered. Unregistered ones give you an idea of which ATTRIBUTE-VALUE pairs are available, but those can vary depending on the original resource and on how the summary object got generated. Registered template types have to point to a formally specified description of all the mandatory and optional ATTRIBUTE-VALUE pairs for that type. See [10] for how to register template types with the IANA ✨
Historically, SOIF's template types came from IAFA template types (Ref. 3). SOIF objects generated by the Harvest system have a "FILE" template type, and in current practice that's the most common one. "FILE" is a generic template type meant to handle a big variety of web-based resources. There's no formal specification for it, but you can find a list of the ATTRIBUTE-VALUE pairs commonly used with "FILE" in Appendix A. "DOCUMENT" and "OBJECT" are other generic template types 🍓
Using unregistered template types definitely creates problems for query referral working correctly. Two efforts have tried to get peer-to-peer agreement on linking template types to specific attribute sets: Netscape's RDM (Ref. 6) and the STARTS project (Ref. 7). At first, CIP meshes built on systems that use unregistered template types may need to use these or similar methods to link template types to specific attribute sets 💜
Mesh operators are strongly encouraged, though, to move to registered template types as soon as it's practical. Registered template types let CIP meshes derive the definitions of attributes, which enables multiple-language interfaces to the base attributes 🌈 They also let CIP meshes and other SOIF users set the permitted data types and encodings for the VALUEs tied to each ATTRIBUTE. That makes working out the right matching semantics for a particular VALUE way more straightforward, and it gets rid of the limits of the default octet-by-octet matching (cf. Section 4.) 🫶
3.2 URL 🌈
Uniform Resource Locators (URLs) (Ref 5.) are what SOIF uses as object IDENTIFIERs. SOIF links its summary objects to net-addressable resources by putting the URL the resource was addressed by into the first field of the object body. The formal grammar for SOIF objects is in section 3.4 ✨
This means the same resource can have multiple summary objects, told apart only by the URL it was accessed through. That doesn't hurt the URL's usefulness as an object IDENTIFIER, though. Also, since you could argue the net address is a salient part of the metadata, there may be good perks to using the URL as an object IDENTIFIER 🧚
The Harvest project used some extra identity attributes ("Gatherer-Name", "Gatherer-Host", "Gatherer-Port" and "Gatherer-Version") to track down where a particular object came from, as noted in Appendix A. In the CIP context, it can be useful to identify the base sources of particular index objects. Appendix B shows one example of how a SOIF-based CIP hint could use the base source URL 🦋
3.3 ATTRIBUTE-VALUE pairs. 🍓
Each summary object has zero or more ATTRIBUTE-VALUE pairs, which hold metadata about the net-addressable resource the URL points to. A pair is made of an ATTRIBUTE IDENTIFIER, the length of the VALUE, a delimiter, and the VALUE itself. Important: ATTRIBUTE-VALUE pairs are not CR/LF terminated. They get parsed according to the grammar in section 3.4 💅
In the examples in Section 3.6 and in lots of other representations of SOIF objects, ATTRIBUTE-VALUE pairs are shown on separate lines so they're easier to read 🌸 But VALUEs can contain CR/LF, so implementors have to be careful to parse the whole 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 next pair 🔥
SOIF doesn't explicitly allow a single ATTRIBUTE to have multiple VALUEs. To handle that, SOIF uses a naming convention: a hyphen and a positive integer get appended to the ATTRIBUTE name to make an ATTRIBUTE IDENTIFIER that's tied to one specific ATTRIBUTE 🧚 For example, the ATTRIBUTE IDENTIFIERs "Author-1", "Author-2", and "Author-3" can represent three VALUEs for the ATTRIBUTE "Author" when a resource has three authors. See section 4 for what this strategy means for 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>"3.5 Grammar Description 💖
Here's what each piece of that grammar means, bestie 🧚
- URL: a Uniform Resource Locator encoded in the syntax defined by RFC 1738 [3]. If the summary object has no URL, a Latin-1 hyphen (octal
\055) is used instead. - IDENTIFIER: an ASCII character string that only contains alphanumeric characters, 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 says how many octets the VALUE occupies after the DELIMITER.
- DELIMITER: a two octet delimiter made of a Latin-1 colon (:) and a tab (
\t), (octal\072\011). - { }: the Latin-1 curly braces (octal
\173and\175) 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) 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 underscores:
[a-z,A-Z,0-9,- and _]. - ARBITRARY-DATA: Octets of data in arbitrary formats or encodings.
4. Matching Semantics ✨
okay so, we already talked about this in Section 1 🦋 Query referral of SOIF objects works best when a query names a particular ATTRIBUTE (or a whole set of them) as the thing it's matching on 💅 A query-identified ATTRIBUTE should be considered to match a SOIF ATTRIBUTE when a case-insensitive, character-by-character comparison lines up on the part of the ATTRIBUTE IDENTIFIER that comes before any hyphen-integer suffix. So a query asking about "author" should match "author", "Author", "AUTHOR", and "Author-1" 🎀
[10] discourages registering template types that contain ATTRIBUTEs previously registered with substantially different definitions. This helps stop mis-referral, but a CIP mesh may still need to keep a thesaurus that maps ATTRIBUTEs from certain template types onto those of other template types, especially unregistered ones 🧚
The matching semantics for a particular VALUE come from its data type and encoding 🔥 For VALUEs tied to ATTRIBUTEs that belong to a registered template type, the data type and encoding are easy to find. For VALUEs tied to ATTRIBUTEs of unregistered template types, an octet-by-octet comparison is the default. If experience has shown that a particular ATTRIBUTE holds string data, a case-insensitive substring match may be used. For example, a query against the "AUTHOR" ATTRIBUTE of the generic "DOCUMENT" template type with the VALUE "Garcia" should match the SOIF VALUEs "Garcia", "GARCIA", and "Jose Garcia y Montes" 🌸
Over time, we might figure out which attributes tend to produce correct query referrals within a mesh 👑 Once those patterns show up, mesh maintainers may wish to define a particular SOIF TEMPLATE-TYPE that only allows ATTRIBUTEs likely to foster correct referrals. Main character planning 💖
5. Internationalization 🌈
Internationalization of SOIF depends on registering template types 💅 Since TEMPLATE-TYPEs and ATTRIBUTE IDENTIFIERs must be in ASCII characters, only languages that use the ASCII character set are fully supported for unregistered TEMPLATE-TYPEs. For registered template types, it's a different story ✨ The specification of an ATTRIBUTE's definition lets UI designers show the end user a native-language mapping of that ATTRIBUTE. Also, because data type and encoding info is included in the description of VALUEs, any language encoding or character set an application needs can be supported 🦋 For unregistered template types, the ability of peer servers to pass schema definitions may act as a form of "private registration," which could give some of the internationalization perks that registered template types get 🫶 (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. Here are a few 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 🔒
⚠️ Serious business alert, bestie! Read this part carefully 💀
Please see (Ref. 1) for a general discussion of Security concerns for the CIP framework 🧠
SOIF currently has no requirement that any template type contain an authentication ATTRIBUTE. That means SOIF summary objects that lack authentication ATTRIBUTEs must be treated as unreliable indicators of the referenced resource's content 😭 A hostile party could make a summary object that badly misrepresents a resource's content. As part of a CIP mesh, that data could either channel a huge number of requestors to a resource (possibly causing a denial of service) or steer them away from a resource (possibly causing a loss of appropriate visibility). It's giving chaos, no cap 🙈
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.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.netAppendix 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.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
RCS
README
RFC
SCCS
ShellArchive
Tar
Tcl
Tex
Text
Troff
Uuencoded
WaisSourceUpdate-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.
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] 🎀
okay bestie, this appendix is basically a metadata cheat sheet 📚✨ it lists the Dublin Core template fields, what each one is for, and then shows a full example you can copy.
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.
SUBJECT 🧠
The topic of the resource, or keywords or phrases that describe the subject or content of the resource. The point of this element is to encourage controlled vocabularies and keywords 💅. It might also 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) 🔥.
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 include computational content description (spectral analysis of a visual resource, for example) that may not be embeddable in current network systems 🤓. In that 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 point of 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 schemas 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 📋.
FORMAT 💾
The data representation of the resource, such as text/html, ASCII, Postscript file, executable application, or JPEG image. The point of this element is to give people or machines the info they need to decide whether the encoded data is usable (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 🪪
A 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 point of specifying this element is 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 🧪.
RELATION is still experimental, so treat it as a work in progress 🙈.
COVERAGE 🌏
The spatial locations and temporal durations characteristic of the resource. A formal specification of COVERAGE is currently under development. Users and developers should understand that use of this element should be currently considered experimental 🧪.
COVERAGE is also still experimental 🙈.
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 point of specifying this field is to let providers 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.
}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 🌈.
📦 where this page comes from
- ietf: rfc2655 1999-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms