idnits 2.17.1 draft-iannella-admin-00.txt: 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 (2024-03-28) 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) 2024 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 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 363 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 292 has weird spacing: '...e) Fund alloc...' -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2413 (ref. '2') (Obsoleted by RFC 5013) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1766 (ref. '5') (Obsoleted by RFC 3066, RFC 3282) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 822 (ref. '7') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft R. Iannella 3 draft-iannella-admin-00.txt DSTC 4 08 September 1998 D. Campbell 5 Expires in six months NLA 7 Admin Core - Administrative Container Metadata 9 1. Status of this Document 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 "work in progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 26 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 27 (US West Coast). 29 Distribution of this document is unlimited. Please send comments 30 to and . 32 2. Introduction 34 Administrative metadata - referred to as 'Admin Core' - is useful to 35 designate information about the creation and availability of other sets 36 of metadata. The objective of Admin Core is to provide simple 37 authentication to verify the integrity and provenance of information 38 retrieved from networked resources. The Admin Core elements are utilised 39 to associate date and creator information about metadata. It is 40 important to recognise that Admin Core is a "container" metadata element 41 set as opposed to a "content" metadata element set - its purpose is to 42 describe metadata instances. 44 The Admin Core, as with other metadata elements sets, is a "core" set. 45 That is, it is extensible by allowing the addition of new elements that 46 are specific to a community's needs. This is similar to the model 47 presented by the Dublin Core Metadata Element Set [2]. 49 Admin Core is not useful by itself. It must be used in association with 50 at least one other metadata element set. For example, Dublin Core [2], or 51 Privacy [3] metadata. This amalgamation of different metadata sets is 52 supported by a number of metadata encoding systems, such as the Resource 53 Description Framework [1] and the HTML META tag [6]. Examples are given 54 in Section 5. 56 Admin Core metadata will be used by systems and users to determine the 57 currency of metadata, expired metadata, and how to contact creators of 58 metadata. 60 3. Description of Admin Core Elements 62 The following is the reference definition of the Admin Core Metadata 63 Element Set. The evolving reference description can be found at: 65 http://metadata.net/admin 67 In the element descriptions below, each element has a descriptive name 68 intended to convey a common semantic understanding of the element, as 69 well as a formal single-word label intended to make the syntactic 70 specification of elements simpler for encoding schemes. The recommended 71 best practice is to be case-sensitive to avoid complications in 72 case-sensitive environments such as RDF [1]. 74 The element descriptions also indicate the obligations, encoding, and 75 repeatability characteristics for each Admin Core element in accordance 76 with the ISO Standard 11179 [8]. 78 3.1 Personal Creator 80 Name: CreatorPersonal 82 Definition: The person responsible for creating or modifying the 83 metadata pertaining to a resource. 85 Obligation: Conditional. Either "Personal Creator" or "Corporate 86 Creator" element must appear, or both. 88 Datatype: Character String 90 Maximum 91 Occurrence: Unlimited 93 Comment: If possible, the comma (,) is used to separate the 94 surname first followed by firstname. For example; 95 "Crystal, Mary" 97 3.2 Corporate Creator 99 Name: CreatorCorporate 101 Definition: The name of the organisation by which the metadata 102 creator is employed. 104 Obligation: Conditional. Either "Personal Creator" or "Corporate 105 Creator" element must appear or both. 107 Datatype: Character String 109 Maximum 110 Occurrence: Unlimited 112 Comment: The organisation may be a trusted third party for the 113 source of the metadata. The organisation is not 114 necessarily the entity making the resource available. 116 3.3 Creator Email Address 118 Name: CreatorEmail 120 Definition: The email address of the metadata Creator. 122 Obligation: Mandatory 124 Datatype: Character String. Encoded to be consistent with Internet 125 Address standard RFC822 [7] 127 Maximum 128 Occurrence: Unlimited. 130 Comment: None 132 3.4 Creator Contact Information 134 Name: CreatorContact 136 Definition: Information on how to contact the creator. 138 Obligation: Optional 140 Datatype: Character String 142 Maximum 143 Occurrence: Unlimited 145 Comment: The information should be one or more of: a street or 146 postal address, a telephone number, a facsimile number, 147 and the homepage address of the creator. This provides 148 additional evidence for the existence of a trusted third 149 party. 151 3.5 Date Created 153 Name: DateCreated 155 Definition: The date/time the metadata was created by the Personal 156 or Corporate Creator. 158 Obligation: Mandatory 160 Datatype: Character String. Encoded to Date and Time Format 161 ISO 8601 [4] 163 Maximum 164 Occurrence: Unlimited 166 Comment: None 168 3.6 Date Modified 170 Name: DateModified 172 Definition: The date/time the metadata was most recently modified 173 by the Personal or Corporate Creator. 175 Obligation: Optional 177 Datatype: Character String. Encoded to Date and Time Format 178 ISO 8601 [4]. 180 Maximum 181 Occurrence: Unlimited 183 Comment: None 185 3.7 Date Valid From 187 Name: DateValidFrom 189 Definition: The commencing date of the validity of the metadata 190 description. 192 Obligation: Conditional. Single occurrence only is permissible 193 otherwise must appear in pairs with "Date Valid To" 194 element. 196 Datatype: Character String. Encoded to Date and Time Format 197 ISO 8601 [4]. 199 Maximum 200 Occurrence: Unlimited 202 Comment: Non-administrative metadata accessed before this date 203 should be considered to be invalid. 205 3.8 Date Valid To 207 Name: DateValidTo 209 Definition: The end date of the validity of the metadata 210 description. 212 Obligation: Conditional. Single occurrence only is permissible 213 otherwise must appear in pairs with "Date Valid From" 214 element. 216 Datatype: Character String. Encoded to Date and Time Format 217 ISO 8601 [4]. 219 Maximum 220 Occurrence: Unlimited. 222 Comment: Non-administrative metadata accessed after this date 223 should be considered to be invalid. 225 4. Internationalisation 227 All the Admin Core elements can be associated with language information 228 using RFC 1766 [5]. The Admin Core labels are used in the communication 229 of metadata between systems, with human-readable names being available 230 in multiple languages for client systems. 232 5. Admin Core Examples 234 5.1 HTML META Syntax 236 Below is an example of the use of the Admin Core metadata elements 237 with the bibliographic style Dublin Core metadata elements. This example 238 shows the HTML META syntax [6]. Admin Core elements will be assigned the 239 namespace of "ADMIN" for the META tag syntax encodings. 241 243 244 245 248 249 250 252 5.2 RDF/XML Syntax 254 Below is another example of the use of Admin Core metadata elements with 255 the bibliographic style Dublin Core metadata elements. This example 256 shows the use of RDF syntax [1]. The RDF XML Namespace for Admin Core 257 will be defined as: 259 260 264 266 Admin Core Metadata Element Specification 267 Crystal, Jacky 268 1998-01-01 270 Rubble Corp 271 info@rubble.com 272 1998-01-15 273 1998-02-01 274 1999-02-01 275 276 278 6. Security Considerations 280 The Admin Core element set poses no risk to computers and networks. 281 Human clients who obtain metadata that has been incorrectly 282 described (by humans) may face minimal risk in determining the 283 correctness of the metadata. The application of Digital Signature 284 technology is recommended by systems requiring high levels of 285 authentication. 287 7. Acknowledgements 289 The work reported in this paper has been funded in part by the 290 Cooperative Research Centres Program through the Department of the 291 Prime Minister and Cabinet of Australia and from the National Priority 292 (Reserve) Fund allocation for Improved Library Infrastructure 293 administered by the AV-CC Standing Committee on Information Resources. 295 8. References 297 [1] Resource Description Framework (RDF) Model and Syntax 298 300 [2] RFC 2413, Dublin Core Metadata for Resource Discovery 301 303 [3] Platform for Privacy Preferences Metadata 304 306 [4] Date and Time Formats (based on ISO 8601), W3C Technical Note 307 309 [5] RFC 1766, Tags for the Identification of Languages 310 312 [6] A Proposed Convention for Embedding Metadata in HTML 313 315 [7] RFC822 Standard for the Format of ARPA Internet Text Messages 316 318 [8] ISO 11179 Parts 1-6, Specification and Standardization of Data 319 Elements 321 9. Authors' Addresses 323 Renato Iannella 324 DSTC Pty Ltd 325 The University of Queensland 326 Qld, 4072, AUSTRALIA 327 Email: renato@dstc.edu.au 328 Voice: +61 7 3365 4310 329 Fax: +61 7 3365 4311 331 Debbie Campbell 332 National Library of Australia 333 Canberra 334 ACT, 2600, AUSTRALIA 335 Email: dcampbel@nla.gov.au 336 Voice: +61 2 6262 1673 337 Fax: +61 2 6273 4535