idnits 2.17.1 draft-hamilton-dcxl-02.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-04-19) 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 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 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 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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.) -- The document date (July 1997) is 9775 days in the past. Is this intentional? 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' ** Downref: Normative reference to an Informational RFC: RFC 1309 (ref. '2') ** Obsolete normative reference: RFC 1777 (ref. '3') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1798 (ref. '4') (Obsoleted by RFC 3352) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Martin Hamilton 3 INTERNET-DRAFT Loughborough University 4 Expires January 1998 Renato Iannella 5 DSTC Pty Ltd 6 Jon Knight 7 Loughborough University 8 July 1997 10 Representing the Dublin Core within X.500, LDAP and CLDAP 12 Filename: draft-hamilton-dcxl-02.txt 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 areas, and its working groups. Note that other groups may also 19 distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- 24 Drafts as reference material or to cite them other than as ``work 25 in progress.'' 27 To learn the current status of any Internet-Draft, please check 28 the ``1id-abstracts.txt'' listing contained in the Internet- 29 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 30 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 31 Coast), or ftp.isi.edu (US West Coast). 33 Distribution of this document is unlimited. 35 Abstract 37 The Dublin Core is a simple resource description format which arose 38 out of a loose grouping of "librarians, archivists, humanities 39 scholars and geographers, as well as standards makers in the 40 Internet, Z39.50 and Standard Generalized Markup Language (SGML) 41 communities" [1]. 43 This document describes a mapping from the abstract model of the 44 Dublin Core to the X.500 [2], LDAP [3], and CLDAP [4] directory 45 service protocols. 47 1. The Dublin Core in X.500, LDAP and CLDAP 49 We propose that each of the fifteen elements of the Dublin Core be 50 made into an X.500/[C]LDAP attribute, and that these attributes be 51 gathered together in an object class: 53 Name: dcObject 54 Description: object containing the Dublin Core attributes 55 OID: lutObjectClass.1 (1.3.6.1.4.1.1828.2.1) 56 SubclassOf: top 57 MustContain: 58 MayContain: dcTitle, dcCreator, dcSubject, dcDescription, 59 dcPublisher, dcContributors, dcDate, 60 dcType, dcFormat, dcIdentifer, dcSource, 61 dcLanguage, dcRelation, dcCoverage, dcRights 63 Attribute definitions for the individual Dublin Core elements: 65 Name: dcTitle 66 Description: The name of the resource 67 OID: lutAttributeType.1 (1.3.6.1.4.1.1828.1.1) 68 Syntax: DirectoryString 69 SizeRestriction: None 70 SingleValued: False 72 Name: dcCreator 73 Description: The person(s) primarily responsible for the 74 intellectual content of the resource 75 OID: lutAttributeType.2 (1.3.6.1.4.1.1828.1.2) 76 Syntax: DirectoryString 77 SizeRestriction: None 78 SingleValued: False 80 Name: dcSubject 81 Description: The topic addressed by the resource, or a 82 set of appropriate keywords 83 OID: lutAttributeType.3 (1.3.6.1.4.1.1828.1.3) 84 Syntax: DirectoryString 85 SizeRestriction: None 86 SingleValued: False 88 Name: dcDescription 89 Description: A plain text description or abstract about 90 the resource. 91 OID: lutAttributeType.4 (1.3.6.1.4.1.1828.1.4) 92 Syntax: DirectoryString 93 SizeRestriction: None 94 SingleValued: False 95 Name: dcPublisher 96 Description: The agent or agency responsible for making the 97 resource available 98 OID: lutAttributeType.5 (1.3.6.1.4.1.1828.1.5) 99 Syntax: DirectoryString 100 SizeRestriction: None 101 SingleValued: False 103 Name: dcContributors 104 Description: The person(s), such as editors and transcribers, who 105 have made other significant intellectual 106 contributions to the work 107 OID: lutAttributeType.6 (1.3.6.1.4.1.1828.1.6) 108 Syntax: DirectoryString 109 SizeRestriction: None 110 SingleValued: False 112 Name: dcDate 113 Description: The date of publication 114 OID: lutAttributeType.7 (1.3.6.1.4.1.1828.1.7) 115 Syntax: DirectoryString 116 SizeRestriction: None 117 SingleValued: False 119 Name: dcType 120 Description: The genre of the resource, such as novel, poem, or 121 dictionary 122 OID: lutAttributeType.8 (1.3.6.1.4.1.1828.1.8) 123 Syntax: DirectoryString 124 SizeRestriction: None 125 SingleValued: False 127 Name: dcFormat 128 Description: The physical manifestation of the resource, such as 129 Postscript file or Windows executable file 130 OID: lutAttributeType.9 (1.3.6.1.4.1.1828.1.9) 131 Syntax: DirectoryString 132 SizeRestriction: None 133 SingleValued: False 135 Name: dcIdentifier 136 Description: String or number used to uniquely identify the 137 resource 138 OID: lutAttributeType.10 (1.3.6.1.4.1.1828.1.10) 139 Syntax: DirectoryString 140 SizeRestriction: None 141 SingleValued: False 142 Name: dcSource 143 Description: Resources, either print or electronic, from which 144 this resource is derived, if applicable 145 OID: lutAttributeType.11 (1.3.6.1.4.1.1828.1.11) 146 Syntax: DirectoryString 147 SizeRestriction: None 148 SingleValued: False 150 Name: dcLanguage 151 Description: Language of the intellectual content 152 OID: lutAttributeType.12 (1.3.6.1.4.1.1828.1.12) 153 Syntax: DirectoryString 154 SizeRestriction: None 155 SingleValued: False 157 Name: dcRelation 158 Description: Relationship to other resources 159 OID: lutAttributeType.13 (1.3.6.1.4.1.1828.1.13) 160 Syntax: DirectoryString 161 SizeRestriction: None 162 SingleValued: False 164 Name: dcCoverage 165 Description: The spatial locations and temporal durations 166 characteristic of the resource 167 OID: lutAttributeType.14 (1.3.6.1.4.1.1828.1.14) 168 Syntax: DirectoryString 169 SizeRestriction: None 170 SingleValued: False 172 Name: dcRights 173 Description: Information concerning the intellectual property 174 rights that are being exercised over the 175 resource (including access terms) 176 OID: lutAttributeType.15 (1.3.6.1.4.1.1828.1.15) 177 Syntax: DirectoryString 178 SizeRestriction: None 179 SingleValued: False 181 2. Examples and implementation considerations 183 For example, using Quipu [5] EDB notation, a Dublin Core "Title" 184 element which had the value "Cities of The Red Night" would be 185 represented as the attribute/value pair: 187 dcTitle= Cities of The Red Night 189 One aspect of the Dublin Core does not translate directly to X.500 190 and LDAP - each element may have additional qualifying information 191 attached to it. This gives the creator of the record a way of 192 indicating additional semantics, e.g. the classification scheme being 193 used in the "Subject" element. 195 Since X.500 and LDAP are, like most Internet based search and 196 retrieval protocols, attribute/value oriented, it is necessary to 197 find a place to put this extra information. We propose that, given 198 the difficulty of incorporating this model within the X.500/LDAP 199 paradigm, a simple but sub-optimal approach be taken - with any 200 qualifying information being placed at the beginning of the value 201 part of the attribute/value pair, delimited using round brackets, and 202 with any additional qualifiers following using comma separation. 204 For example, if the subject classification for the above book were 205 813 in the Dewey Decimal system, the resulting Dublin Core record 206 expressed as an X.500 EDB entry would look like this: 208 dcSubject= (scheme=DDC) 813 210 3. Extensibility 212 It is important to note that the Dublin Core element set is intended 213 for use in describing document-like objects, and not as a means of 214 describing arbitrary objects. Furthermore, the number of elements is 215 strictly limited in the interests of interoperability. 217 Work is ongoing on the Warwick Framework [6], which attempts to 218 provide a mechanism for packaging together collections of descriptive 219 information. It is envisaged that this would be used in cases where 220 the Dublin Core element set did not provide enough descriptive 221 capability. This is a subject for further study. 223 4. Security considerations 225 This proposal does not introduce any new security related issues. 227 One of the main uses to which the Dublin Core is expected to be put 228 is in the generation of author supplied cataloguing information for 229 on-line resources. Implementations which manipulate externally 230 produced data should treat it with caution - for example, to avoid 231 buffer overrun problems and unexpected evaluation of metacharacters. 233 5. Conclusions 235 This document has shown how the X.500 protocol, and the related LDAP 236 and CLDAP protocols, may be used as carriers for the abstract 237 resource descriptions of the Dublin Core proposal. 239 It should be apparent that a little care is necessary when delivering 240 this information via these protocols, but that this does not imply 241 any great additional implementation complexity. 243 6. Acknowledgements 245 Thanks to Hoylen Sue, CiTR Pty Ltd (Australia), Rachel Heery and 246 Lorcan Dempsey for their comments on draft versions of this document. 248 This work was supported by UK Electronic Libraries Programme (eLib) 249 grant 12/39/01, the European Commission's Telematics for Research 250 Programme, grant RE 1004, and the Cooperative Research Centres 251 Program, through the Department of the Prime Minister and Cabinet of 252 Australia. 254 7. References 256 [1] S. Weibel. "Metadata: The Foundations of Resource 257 Description", D-Lib Magazine, July 1995. 258 259 261 [2] C. Weider, J. Reynolds, S. Heker. "Technical Overview 262 of Directory Services Using the X.500 Protocol", RFC 263 1309. March 1992. 264 266 [3] W. Yeong, T. Howes & S. Kille. "Lightweight Directory 267 Access Protocol", RFC 1777. March 1995. 268 270 [4] A. Young. "Connection-less Lightweight Directory 271 Access Protocol", RFC 1798. June 1995. 272 274 [5] S.E. Kille. "Implementing X.400 and X.500: the PP and 275 QUIPU systems", Artech House, 1991. 277 [6] L. Dempsey, S. Weibel. "The Warwick Metadata Workshop: 278 A Framework for the Deployment of Resource Descrip- 279 tion", D-Lib Magazine, July/August 1996. 280 281 283 8. Authors' addresses 285 Martin Hamilton 286 Department of Computer Studies 287 Loughborough University of Technology 288 Leics. LE11 3TU, UK 290 Email: m.t.hamilton@lut.ac.uk 292 Renato Iannella 293 Research Data Network CRC 294 DSTC Pty Ltd 295 Gehrmann Laboratories 296 University of Queensland 297 Australia 299 Email: renato@dstc.edu.au 301 Jon Knight 302 Department of Computer Studies 303 Loughborough University of Technology 304 Leics. LE11 3TU, UK 306 Email: j.p.knight@lut.ac.uk