summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2656.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2656.txt')
-rw-r--r--doc/rfc/rfc2656.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc2656.txt b/doc/rfc/rfc2656.txt
new file mode 100644
index 0000000..f3f1106
--- /dev/null
+++ b/doc/rfc/rfc2656.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group T. Hardie
+Request For Comments: 2656 Equinix
+Category: Experimental August 1999
+
+ Registration Procedures for SOIF Template Types
+
+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.
+
+Abstract
+
+ The Summary Object Interchange Format [Ref. 1] 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.
+
+ SOIF uses named template types to indicate the attributes which may
+ be contained within a particular summary object. Within the context
+ of a single application, private agreement on the definition of
+ template types has been adequate. As SOIF objects are moved among
+ applications, however, the need for standard, well-specified, and
+ easily identifiable template types increases. This need is
+ particularly intense in the context of query referral, where
+ knowledge of an attribute's definition and the allowed data types for
+ specific values is crucial. For a discussion of this in the context
+ of the Common Indexing Protocol, see [Ref. 1].
+
+ The registration procedure described in this document is specific to
+ SOIF template types. There is ongoing work within the IETF to
+ specify a more generic schema registration facility[Ref. 5]. It is
+ not yet clear whether the results of that work will encompass the
+ ability to register entities like SOIF template types. If it does
+ so, the registration of SOIF template types may be shifted to that
+ method and registry. Should that occur, appropriate pointers will be
+ created in cooperation with the Registrar to ensure that no
+ registrations are lost.
+
+
+
+Hardie Experimental [Page 1]
+
+RFC 2656 Registration Procedures for SOIF August 1999
+
+
+1. Registrar
+
+ The initial registrar of SOIF template types will be the Internet
+ Assigned Numbers Authority (IANA).
+
+2. Defining Template Types
+
+ Each SOIF object is composed of 3 fundamental components: a template
+ type IDENTIFIER, a URL, and zero or more ATTRIBUTE-VALUE pairs. See
+ [Ref 1.] for the formal grammar of SOIF and a description of how
+ these components interrelate. As part of the registration process,
+ registrants must: propose a template type IDENTIFER; list the
+ ATTRIBUTEs which the template may contain; identify whether each
+ ATTRIBUTE is mandatory or optional; and specifiy the data type and
+ encoding appropriate for the VALUEs associated with each ATTRIBUTE.
+
+2.1 The template type IDENTIFIER
+
+ The IDENTIFIER for the template type is assigned at registration
+ based on a proposal from the registrant. It is, however, at the sole
+ discretion of the registrars to assign specific IDENTIFIERS. While
+ they will normally assign the IDENTIFIERs proposed by registrants,
+ they may choose to modify a proposed IDENTIFIER to avoid conflict
+ with other existing or proposed template types.
+
+ Because of the pre-installed base of servers using privately agreed
+ upon template types, applications using SOIF need to be able to
+ ascertain whether a referenced template type has been registered. In
+ order to accomplish this, all template type IDENTIFIERS for template
+ types registered with the IANA will begin with the ASCII string
+ "IANA-". An IANA-registered template type based on the GILS
+ specification, for example, might be registered as "IANA-GILS".
+ Should other registrars emerge over time, similar strings must be
+ established and used to compose template type IDENTIFIERS which they
+ assign.
+
+2.2 The URL
+
+ The URL associated with a particular summary object is determined by
+ the application generating the object. Applications must generate
+ valid URLs according to the rules of [Ref 6.], but there is no
+ restriction on what sorts of URLs may be associated with particular
+ template types. The use of a particular template type indicates the
+ type of information contained in the summary object, not how the
+ inital resource being summarized was accessed. This aspect of SOIF
+ summary objects is therefor not subject to registration.
+
+
+
+
+
+Hardie Experimental [Page 2]
+
+RFC 2656 Registration Procedures for SOIF August 1999
+
+
+2.3 ATTRIBUTES
+
+ Where an ATTRIBUTE associated with a proposed template type exactly
+ matches an ATTRIBUTE previously defined in a registered template
+ type, the proposed ATTRIBUTE should be defined by reference to the
+ existing, registered ATTRIBUTE. This allows query referral meshes to
+ easily map queries against ATTRIBUTEs derived from different template
+ types and provides an easy method for extending or restricting an
+ existing template type to match an application's particular needs.
+ In such cases, the ATTRIBUTE for the newly registered template type
+ will have the same name, description, and allowed values as the
+ ATTRIBUTE in the existing registered template type.
+
+ Where no existing ATTRIBUTE may be referenced, registrants must
+ specify each ATTRIBUTE's name, description, and allowed values.
+
+2.3.1 ATTRIBUTE names
+
+ To handle multiple VALUEs for the same ATTRIBUTE, SOIF uses a naming
+ convention, appending a hyphen and a positive integer to the base
+ ATTRIBUTE name to create a unique ATTRIBUTE IDENTIFIER. For example,
+ the ATTRIBUTE IDENTIFIERs "Publisher-1", "Publisher-2", and
+ "Publisher-3" can be used to associate three VALUEs with the
+ ATTRIBUTE named "Publisher". In order to provide for the unimpeded
+ operation of this convention, ATTRIBUTE names may not terminate with
+ a hyphen followed by an integer. ATTRIBUTE names are otherwise
+ restricted only by the grammar defined in [Ref. 1].
+
+ In general, registrants will probably wish to propose ATTRIBUTE names
+ which are short, mnemonic, and intuitively associated with the
+ characterstic that the ATTRIBUTE describes. While these may be
+ generally laudable goals, it must be remembered that the application
+ interface need not present the raw ATTRIBUTE name to the end user;
+ indeed, in situations where the end user's language does not use the
+ ASCII character set, the interface must map the ATTRIBUTE name to an
+ appropriate local representation. Since ATTRIBUTE definitions are
+ provided as part of the registration process, registrants should
+ avoid attempting to overload the ATTRIBUTE name with information
+ which belongs in the description.
+
+2.3.2 ATTRIBUTE descriptions
+
+ ATTRIBUTE descriptions for ATTRIBUTEs registered with the IANA must
+ be in English, though mappings to other languages may be proposed as
+ part of the ATTRIBUTE description. ATTRIBUTE descriptions should
+ propose clear criteria for establishing whether an object posseses a
+ particular ATTRIBUTE. Descriptions should also include at least two
+ examples of how each attribute relates to an object being summarized,
+
+
+
+Hardie Experimental [Page 3]
+
+RFC 2656 Registration Procedures for SOIF August 1999
+
+
+ using, where possible, objects which are broadly available to a wide
+ variety of audiences. If several ATTRIBUTEs within a template type
+ inter-relate, the descriptions of each may reference the others; care
+ must be taken, however, that the resulting descriptions are not
+ circular. Where fully realized specifications of the ATTRIBUTEs have
+ been created in other contexts, the salient text from those
+ descriptions should be quoted and appropriate references cited.
+
+2.3.3 Required and Optional Attributes
+
+ Each ATTRIBUTE registered for a template type must be marked either
+ required or optional. Note that marking an ATTRIBUTE required does
+ not imply that it may not have a null value; it implies only that it
+ must appear in all templates of that registered template type.
+
+2.4 VALUES
+
+ For each ATTRIBUTE, the registrant must specify the data format and,
+ if appropriate, the language, character set, and encoding. Where
+ possible, the registrant should include references to a precise and
+ openly available specification of the format. The registrant must
+ also specify the appropriate matching semantics for the ATTRIBUTE if
+ these are not strictly implied by the data format and encoding. The
+ registrant must also note whether null values are permitted.
+
+3. Versioning
+
+ Creating a revision of a template type is functionally similar to
+ creating a new template type. A Registrant may propose as a name any
+ derivative allowed under the rules of section 4.1 and [Ref. 1] to the
+ new template type. ATTRIBUTEs retained across versions without
+ modification should be referenced as described in section 4.3.
+ Modified ATTRIBUTEs must be described as if new. A registrant may
+ note a relationship between a proposed template type and an existing
+ template type as part of the registration process. The following
+ three relationships are currently defined:
+
+ Successor: for proposed template types intended to replace an
+ existing template type.
+
+ Variant: for proposed template types whose ATTRIBUTEs are either a
+ superset or a subset of an existing template type.
+
+ Alternate: for proposed template types which share a large number of
+ ATTRIBUTEs with an existing template type but whose ATTRIBUTEs do not
+ form a strict superset or subset of an existing template type.
+
+
+
+
+
+Hardie Experimental [Page 4]
+
+RFC 2656 Registration Procedures for SOIF August 1999
+
+
+ Note that there may be relationships between ATTRIBUTEs of different
+ template types without there being a named relationship between the
+ template types themselves.
+
+4. Security
+
+ SOIF template types which are intended for applications which will
+ pass summary objects over the global Internet should contain
+ authentication ATTRIBUTEs. SOIF summary objects lacking
+ authentication ATTRIBUTEs must be treated as unreliable indicators of
+ the referenced resource's content and should only be used where other
+ aspects of the environment provide sufficient security to prevent
+ spoofing. Given, however, that particular template types may be
+ intended for environments with such security, there is no requirement
+ that registered template types contain authentication ATTRIBUTEs.
+ The application developer must select or propose a template type
+ appropriate for the intended appliation environment; if none is
+ available with suitable authentication ATTRIBUTEs, the provisions of
+ section 4.3 make it easy for the developer to propose an extension to
+ an existing template type with the appropriate authentication
+ ATTRIBUTEs.
+
+5. References
+
+ [1] Hardie, T., Bowman, M., Hardy, D., Schwartz, M. and D. Wessels,
+ "CIP Index Object Format for SOIF Objects", RFC 2655, 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] IETF Schema Registration Working Group.
+ <URL:http://www.ietf.org/html.charters/wg.dir#Applications_Area>
+
+ [6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
+ Locators (URL)", RFC 1738, December 1994.
+
+
+
+
+
+
+
+
+Hardie Experimental [Page 5]
+
+RFC 2656 Registration Procedures for SOIF August 1999
+
+
+6. Author's Address
+
+ Ted Hardie
+ Equinix
+ 901 Marshall Street
+ Redwood City, CA 94063 USA
+
+ EMail: hardie@equinix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie Experimental [Page 6]
+
+RFC 2656 Registration Procedures for SOIF August 1999
+
+
+Appendix A.
+
+ An Example Registration Form
+
+ 1. Registrant's Name ________________________________________
+
+ 2. Registrant's Organization ________________________________
+
+ 3. Registrant's email address _______________________________
+
+ 4. Registrant's postal address ______________________________
+ ______________________________
+ ______________________________
+ ______________________________
+
+ 5. Registrant's telephone number ____________________________
+
+ 6. Proposed Template Type IDENTIFIER: IANA-__________________
+
+ 7. If this Template Type relates to an existing Template Type
+ list the Template Type(s) and the relationship:
+
+ Template Type ___________________ Relationship ______________
+
+ 8. For each ATTRIBUTE in this Template type, provide the
+ following information:
+
+ a) NAME _____________________________________________________
+
+ b) Reference Template Type __________________________________
+
+ If there is no registered Template Type which has already
+ specified this attribute, provide the following information:
+
+ c) ATTRIBUTE Description ____________________________________
+ ____________________________________
+ ____________________________________
+ ____________________________________
+ ____________________________________
+ ____________________________________
+ ____________________________________
+ ____________________________________
+ ____________________________________
+ ____________________________________
+ ____________________________________
+ ____________________________________
+ ____________________________________
+ ____________________________________
+
+
+
+Hardie Experimental [Page 7]
+
+RFC 2656 Registration Procedures for SOIF August 1999
+
+
+ d) Required [] or Optional []?
+
+ e) Data Type and ecoding for this VALUE _____________________
+ _____________________
+ _____________________
+
+ f) If a specific language and character set are expected, list
+ them here ___________________________________________________
+
+ g) Is a null value permitted? Yes [] No []
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie Experimental [Page 8]
+
+RFC 2656 Registration Procedures for SOIF August 1999
+
+
+7. 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 Experimental [Page 9]
+