idnits 2.17.1 draft-hamilton-dcxl-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-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 5 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 (November 1996) is 10017 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 May 1997 Renato Iannella 5 DSTC Pty Ltd 6 Jon Knight 7 Loughborough University 8 November 1996 10 Representing the Dublin Core within X.500, LDAP and CLDAP 12 Filename: draft-hamilton-dcxl-00.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 thirteen 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: dcSubject, dcTitle, dcAuthor, dcPublisher, 59 dcOtherAgent, dcDate, dcObjectType, 60 dcForm, dcIdentifer, dcRelation, dcSource, 61 dcLanguage, dcCoverage 63 Attribute definitions for the individual Dublin Core elements: 65 Name: dcSubject 66 Description: The topic addressed by the work 67 OID: lutAttributeType.1 (1.3.6.1.4.1.1828.1.1) 68 Syntax: DirectoryString 69 SizeRestriction: None 70 SingleValued: False 72 Name: dcTitle 73 Description: The name of the object 74 OID: lutAttributeType.2 (1.3.6.1.4.1.1828.1.2) 75 Syntax: DirectoryString 76 SizeRestriction: None 77 SingleValued: False 79 Name: dcAuthor 80 Description: The person(s) primarily responsible for the 81 intellectual content of the object 82 OID: lutAttributeType.3 (1.3.6.1.4.1.1828.1.3) 83 Syntax: DirectoryString 84 SizeRestriction: None 85 SingleValued: False 87 Name: dcPublisher 88 Description: The agent or agency responsible for making the 89 object available 90 OID: lutAttributeType.4 (1.3.6.1.4.1.1828.1.4) 91 Syntax: DirectoryString 92 SizeRestriction: None 93 SingleValued: False 94 Name: dcOtherAgent 95 Description: The person(s), such as editors and transcribers, who 96 have made other significant intellectual 97 contributions to the work 98 OID: lutAttributeType.5 (1.3.6.1.4.1.1828.1.5) 99 Syntax: DirectoryString 100 SizeRestriction: None 101 SingleValued: False 103 Name: dcDate 104 Description: The date of publication 105 OID: lutAttributeType.6 (1.3.6.1.4.1.1828.1.6) 106 Syntax: DirectoryString 107 SizeRestriction: None 108 SingleValued: False 110 Name: dcObjectType 111 Description: The genre of the object, such as novel, poem, or 112 dictionary 113 OID: lutAttributeType.7 (1.3.6.1.4.1.1828.1.7) 114 Syntax: DirectoryString 115 SizeRestriction: None 116 SingleValued: False 118 Name: dcForm 119 Description: The physical manifestation of the object, such as 120 Postscript file or Windows executable file 121 OID: lutAttributeType.8 (1.3.6.1.4.1.1828.1.8) 122 Syntax: DirectoryString 123 SizeRestriction: None 124 SingleValued: False 126 Name: dcIdentifier 127 Description: String or number used to uniquely identify the object 128 OID: lutAttributeType.9 (1.3.6.1.4.1.1828.1.9) 129 Syntax: DirectoryString 130 SizeRestriction: None 131 SingleValued: False 133 Name: dcRelation 134 Description: Relationship to other objects 135 OID: lutAttributeType.10 (1.3.6.1.4.1.1828.1.10) 136 Syntax: DirectoryString 137 SizeRestriction: None 138 SingleValued: False 140 Name: dcSource 141 Description: Objects, either print or electronic, from which this 142 object is derived, if applicable 143 OID: lutAttributeType.11 (1.3.6.1.4.1.1828.1.11) 144 Syntax: DirectoryString 145 SizeRestriction: None 146 SingleValued: False 148 Name: dcLanguage 149 Description: Language of the intellectual content 150 OID: lutAttributeType.12 (1.3.6.1.4.1.1828.1.12) 151 Syntax: DirectoryString 152 SizeRestriction: None 153 SingleValued: False 155 Name: dcCoverage 156 Description: The spatial locations and temporal durations 157 characteristic of the object 158 OID: lutAttributeType.13 (1.3.6.1.4.1.1828.1.13) 159 Syntax: DirectoryString 160 SizeRestriction: None 161 SingleValued: False 163 2. Examples and implementation considerations 165 For example, using Quipu [5] EDB notation, a Dublin Core "Title" 166 element which had the value "Cities of The Red Night" would be 167 represented as the attribute/value pair: 169 dcTitle= Cities of The Red Night 171 One aspect of the Dublin Core does not translate directly to X.500 172 and LDAP - each element may have additional qualifying "scheme" and 173 "type" information attached to it. This gives the creator of the 174 record a way of indicating additional semantics, e.g. the 175 classification scheme being used in the "Subject" element. 177 Since X.500 and LDAP are, like most Internet based search and 178 retrieval protocols, attribute/value oriented, it is necessary to 179 find a place to put this extra information. We propose that, given 180 the difficulty of incorporating this model within the X.500/LDAP 181 paradigm, a simple but sub-optimal approach be taken - with any 182 qualifying information being placed at the beginning of the value 183 part of the attribute/value pair, delimited using round brackets, and 184 with any additional qualifiers following using comma separation. 186 For example, if the subject classification for the above book were 187 813 in the Dewey Decimal system, the resulting Dublin Core record 188 expressed as an X.500 EDB entry would look like this: 190 dcSubject= (scheme=DDC) 813 192 and a sample "Relation" element, with a "type" qualifier, would look 193 like this: 195 dcRelation= (scheme=URI, type=isParentOf) http://www.w3.org/ 197 3. Extensibility 199 It is important to note that the Dublin Core element set is intended 200 for use in describing document-like objects, and not as a means of 201 describing arbitrary objects. Furthermore, the number of elements is 202 strictly limited in the interests of interoperability. 204 Work is ongoing on the Warwick Framework [6], which attempts to 205 provide a mechanism for packaging together collections of descriptive 206 information. It is envisaged that this would be used in cases where 207 the Dublin Core element set did not provide enough descriptive 208 capability. This is a subject for further study. 210 4. Security considerations 212 This proposal does not introduce any new security related issues. 214 One of the main uses to which the Dublin Core is expected to be put 215 is in the generation of author supplied cataloguing information for 216 on-line resources. Implementations which manipulate externally 217 produced data should treat it with caution - for example, to avoid 218 buffer overrun problems and unexpected evaluation of metacharacters. 220 5. Conclusions 222 This document has shown how the X.500 protocol, and the related LDAP 223 and CLDAP protocols, may be used as carriers for the abstract 224 resource descriptions of the Dublin Core proposal. 226 It should be apparent that a little care is necessary when delivering 227 this information via these protocols, but that this does not imply 228 any great additional implementation complexity. 230 6. Acknowledgements 232 Thanks to Hoylen Sue, CiTR Pty Ltd (Australia), Rachel Heery and 233 Lorcan Dempsey for their comments on draft versions of this document. 235 This work was supported by UK Electronic Libraries Programme (eLib) 236 grant 12/39/01, the European Commission's Telematics for Research 237 Programme, grant RE 1004, and the Cooperative Research Centres 238 Program, through the Department of the Prime Minister and Cabinet of 239 Australia. 241 7. References 243 [1] S. Weibel. "Metadata: The Foundations of Resource 244 Description", D-Lib Magazine, July 1995. 245 246 248 [2] C. Weider, J. Reynolds, S. Heker. "Technical Overview 249 of Directory Services Using the X.500 Protocol", RFC 250 1309. March 1992. 251 253 [3] W. Yeong, T. Howes & S. Kille. "Lightweight Directory 254 Access Protocol", RFC 1777. March 1995. 255 257 [4] A. Young. "Connection-less Lightweight Directory 258 Access Protocol", RFC 1798. June 1995. 259 261 [5] S.E. Kille. "Implementing X.400 and X.500: the PP and 262 QUIPU systems", Artech House, 1991. 264 [6] L. Dempsey, S. Weibel. "The Warwick Metadata Workshop: 265 A Framework for the Deployment of Resource Descrip- 266 tion", D-Lib Magazine, July/August 1996. 267 268 270 8. Authors' addresses 272 Martin Hamilton 273 Department of Computer Studies 274 Loughborough University of Technology 275 Leics. LE11 3TU, UK 277 Email: m.t.hamilton@lut.ac.uk 278 Renato Iannella 279 Research Data Network CRC 280 DSTC Pty Ltd 281 Gehrmann Laboratories 282 University of Queensland 283 Australia 285 Email: renato@dstc.edu.au 287 Jon Knight 288 Department of Computer Studies 289 Loughborough University of Technology 290 Leics. LE11 3TU, UK 292 Email: j.p.knight@lut.ac.uk