idnits 2.17.00 (12 Aug 2021) /tmp/idnits37881/draft-ietf-find-soif-registry-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 331 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 17 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 228, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 232, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 235, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 239, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 242, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 245, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1738 (ref. '6') (Obsoleted by RFC 4248, RFC 4266) Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Edward Hardie 2 Expires: November XX, 1997 NASA NIC 3 5 Registration Procedures for SOIF Template Types 7 1. Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its areas, and 11 its working groups. Note that other groups may also distribute working 12 documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six months 15 and may be updated, replaced, or obsoleted by other documents at any 16 time. It is inappropriate to use Internet-Drafts as reference material 17 or to cite them other than as ``work in progress.'' 19 To learn the current status of any Internet-Draft, please check the 20 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 21 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 22 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 24 Distribution of this memo is unlimited. Please send comments to the 25 author. 27 2. Abstract 29 The Summary Object Interchange Format [Ref. 1] was first defined by 30 the Harvest Project [Ref 2.] in January 1994. SOIF was derived from 31 a combination of the Internet Anonymous FTP Archives IETF Working 32 Group (IAFA) templates [Ref 3.] and the BibTeX bibliography format 33 [Ref 4.]. The combination was originally noted for its advantages 34 of providing a convenient and intuitive way for delimiting objects 35 within a stream, and setting apart the URL for easy object access or 36 invocation, while still preserving compatibility with IAFA 37 templates. 39 SOIF uses named template types to indicate the attributes which may 40 be contained within a particular summary object. Within the context 41 of a single application, private agreement on the definition of 42 template types has been adequate. As SOIF objects are moved among 43 applications, however, the need for standard, well-specified, and 44 easily identifiable template types increases. This need is 45 particularly intense in the context of query referral, where 46 knowledge of an attribute's definition and the allowed data types 47 for specific values is crucial. For a discussion of this in the 48 context of the Common Indexing Protocol, see [Ref. 1]. 50 The registration procedure described in this document is specific to 51 SOIF template types. There is ongoing work within the IETF to 52 specify a more generic schema registration facility[Ref. 5]. It is 53 not yet clear whether the results of that work will encompass the 54 ability to register entities like SOIF template types. If it does 55 so, the registration of SOIF template types may be shifted to that 56 method and registry. Should that occur, appropriate pointers will 57 be created in cooperation with the Registrar to ensure that no 58 registrations are lost. 60 3. Registrar 62 The initial registrar of SOIF template types will be the Internet 63 Assigned Numbers Authority (IANA). 65 4. Defining Template Types 67 Each SOIF object is composed of 3 fundamental components: a template 68 type IDENTIFIER, a URL, and zero or more ATTRIBUTE-VALUE pairs. See 69 [Ref 1.] for the formal grammar of SOIF and a description of how 70 these components interrelate. As part of the registration process, 71 registrants must: propose a template type IDENTIFER; list the 72 ATTRIBUTEs which the template may contain; identify whether each 73 ATTRIBUTE is mandatory or optional; and specifiy the data type and 74 encoding appropriate for the VALUEs associated with each ATTRIBUTE. 76 4.1 The template type IDENTIFIER 78 The IDENTIFIER for the template type is assigned at registration based 79 on a proposal from the registrant. It is, however, at the sole 80 discretion of the registrars to assign specific IDENTIFIERS. While 81 they will normally assign the IDENTIFIERs proposed by registrants, 82 they may choose to modify a proposed IDENTIFIER to avoid conflict with 83 other existing or proposed template types. 85 Because of the pre-installed base of servers using privately agreed 86 upon template types, applications using SOIF need to be able to 87 ascertain whether a referenced template type has been registered. In 88 order to accomplish this, all template type IDENTIFIERS for template 89 types registered with the IANA will begin with the ASCII string 90 "IANA-". An IANA-registered template type based on the GILS 91 specification, for example, might be registered as "IANA-GILS". 92 Should other registrars emerge over time, similar strings must be 93 established and used to compose template type IDENTIFIERS which they 94 assign. 96 4.2 The URL 98 The URL associated with a particular summary object is determined by 99 the application generating the object. Applications must generate 100 valid URLs according to the rules of [Ref 6.], but there is no 101 restriction on what sorts of URLs may be associated with particular 102 template types. The use of a particular template type indicates the 103 type of information contained in the summary object, not how the 104 inital resource being summarized was accessed. This aspect of SOIF 105 summary objects is therefor not subject to registration. 107 4.3 ATTRIBUTES 109 Where an ATTRIBUTE associated with a proposed template type exactly 110 matches an ATTRIBUTE previously defined in a registered template 111 type, the proposed ATTRIBUTE should be defined by reference to the 112 existing, registered ATTRIBUTE. This allows query referral meshes to 113 easily map queries against ATTRIBUTEs derived from different 114 template types and provides an easy method for extending or 115 restricting an existing template type to match an application's 116 particular needs. In such cases, the ATTRIBUTE for the newly 117 registered template type will have the same name, description, and 118 allowed values as the ATTRIBUTE in the existing registered template 119 type. 121 Where no existing ATTRIBUTE may be referenced, registrants must 122 specify each ATTRIBUTE's name, description, and allowed values. 124 4.3.1 ATTRIBUTE names 126 To handle multiple VALUEs for the same ATTRIBUTE, SOIF uses a naming 127 convention, appending a hyphen and a positive integer to the base 128 ATTRIBUTE name to create a unique ATTRIBUTE IDENTIFIER. For 129 example, the ATTRIBUTE IDENTIFIERs "Publisher-1", "Publisher-2", and 130 "Publisher-3" can be used to associate three VALUEs with the 131 ATTRIBUTE named "Publisher". In order to provide for the unimpeded 132 operation of this convention, ATTRIBUTE names may not terminate with 133 a hyphen followed by an integer. ATTRIBUTE names are otherwise 134 restricted only by the grammar defined in [Ref. 1]. 136 In general, registrants will probably wish to propose ATTRIBUTE 137 names which are short, mnemonic, and intuitively associated with the 138 characterstic that the ATTRIBUTE describes. While these may be 139 generally laudable goals, it must be remembered that the application 140 interface need not present the raw ATTRIBUTE name to the end user; 141 indeed, in situations where the end user's language does not use the 142 ASCII character set, the interface must map the ATTRIBUTE name to an 143 appropriate local representation. Since ATTRIBUTE definitions are 144 provided as part of the registration process, registrants should 145 avoid attempting to overload the ATTRIBUTE name with information 146 which belongs in the description. 148 4.3.2 ATTRIBUTE descriptions 150 ATTRIBUTE descriptions for ATTRIBUTEs registered with the IANA must 151 be in English, though mappings to other languages may be proposed as 152 part of the ATTRIBUTE description. ATTRIBUTE descriptions should 153 propose clear criteria for establishing whether an object posseses a 154 particular ATTRIBUTE. Descriptions should also include at least two 155 examples of how each attribute relates to an object being summarized, 156 using, where possible, objects which are broadly available to a wide 157 variety of audiences. If several ATTRIBUTEs within a template type 158 inter-relate, the descriptions of each may reference the others; care 159 must be taken, however, that the resulting descriptions are not 160 circular. Where fully realized specifications of the ATTRIBUTEs have 161 been created in other contexts, the salient text from those 162 descriptions should be quoted and appropriate references cited. 164 4.3.3 Required and Optional Attributes 166 Each ATTRIBUTE registered for a template type must be marked either 167 required or optional. Note that marking an ATTRIBUTE required does 168 not imply that it may not have a null value; it implies only that it 169 must appear in all templates of that registered template type. 171 4.4 VALUES 173 For each ATTRIBUTE, the registrant must specify the data format and, 174 if appropriate, the language, character set, and encoding. Where 175 possible, the registrant should include references to a precise and 176 openly available specification of the format. The registrant must 177 also specify the appropriate matching semantics for the ATTRIBUTE if 178 these are not strictly implied by the data format and encoding. The 179 registrant must also note whether null values are permitted. 181 5. Versioning 183 Creating a revision of a template type is functionally similar to 184 creating a new template type. A Registrant may propose as a name any 185 derivative allowed under the rules of section 4.1 and [Ref. 1] to the 186 new template type. ATTRIBUTEs retained across versions without 187 modification should be referenced as described in section 4.3. 188 Modified ATTRIBUTEs must be described as if new. A registrant may 189 note a relationship between a proposed template type and an existing 190 template type as part of the registration process. The following 191 three relationships are currently defined: 193 Successor: for proposed template types intended to replace an existing 194 template type. 196 Variant: for proposed template types whose ATTRIBUTEs are either 197 a superset or a subset of an existing template type. 199 Alternate: for proposed template types which share a large number of 200 ATTRIBUTEs with an existing template type but whose ATTRIBUTEs do not 201 form a strict superset or subset of an existing template type. 203 Note that there may be relationships between ATTRIBUTEs of different 204 template types without there being a named relationship between the 205 template types themselves. 207 6. Security 209 SOIF template types which are intended for applications which 210 will pass summary objects over the global Internet should contain 211 authentication ATTRIBUTEs. SOIF summary objects lacking 212 authentication ATTRIBUTEs must be treated as unreliable 213 indicators of the referenced resource's content and should only 214 be used where other aspects of the environment provide sufficient 215 security to prevent spoofing. Given, however, that particular 216 template types may be intended for environments with such 217 security, there is no requirement that registered template types 218 contain authentication ATTRIBUTEs. The application developer 219 must select or propose a template type appropriate for the 220 intended appliation environment; if none is available with 221 suitable authentication ATTRIBUTEs, the provisions of section 4.3 222 make it easy for the developer to propose an extension to an 223 existing template type with the appropriate authentication 224 ATTRIBUTEs. 226 7. References 228 [1] CIP Index Object Format for SOIF objects 229 232 [2] The Harvest Information Discovery and Access System: 233 . 235 [3] D. Beckett, IAFA Templates in Use as Internet Metadata, 4th Int'l 236 WWW Conference, December 1995, 237 239 [4] L. Lamport, LaTeX: A Document Preparation System, Addison-Wesley, 240 Reading, Mass., 1986. 242 [5] IETF Schema Registration Working Group. 243 245 [6] T. Berners-Lee, L. Masinter, and M. McCahill, Uniform Resource 246 Locators (URL), RFC 1738, December 1994, 247 249 8. Author's Addresses 251 Edward Hardie 252 NASA Network Information Center 253 MS 204-14 254 Moffett Field, CA 94035-1000 USA 255 +1 415 604 0134 256 hardie@nasa.gov 258 Appendix A. 260 An Example Registration Form 262 1. Registrant's Name ________________________________________ 264 2. Registrant's Organization ________________________________ 266 3. Registrant's email address _______________________________ 268 4. Registrant's postal address ______________________________ 269 ______________________________ 270 ______________________________ 271 ______________________________ 273 5. Registrant's telephone number ____________________________ 275 6. Proposed Template Type IDENTIFIER: IANA-__________________ 277 7. If this Template Type relates to an existing Template Type 278 list the Template Type(s) and the relationship: 280 Template Type ___________________ Relationship ______________ 282 8. For each ATTRIBUTE in this Template type, provide the 283 following information: 285 a) NAME _____________________________________________________ 287 b) Reference Template Type __________________________________ 289 If there is no registered Template Type which has already 290 specified this attribute, provide the following information: 292 c) ATTRIBUTE Description ____________________________________ 293 ____________________________________ 294 ____________________________________ 295 ____________________________________ 296 ____________________________________ 297 ____________________________________ 298 ____________________________________ 299 ____________________________________ 300 ____________________________________ 301 ____________________________________ 302 ____________________________________ 303 ____________________________________ 304 ____________________________________ 305 ____________________________________ 307 d) Required [] or Optional []? 309 e) Data Type and ecoding for this VALUE _____________________ 310 _____________________ 311 _____________________ 313 f) If a specific language and character set are expected, list 314 them here ___________________________________________________ 316 g) Is a null value permitted? Yes [] No []