idnits 2.17.1 draft-kunze-erc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1198. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 a Security Considerations 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 284 has weird spacing: '...t-where h14...' == Line 288 has weird spacing: '...tory of sup...' == Line 289 has weird spacing: '...rt-when h23...' == Line 290 has weird spacing: '...t-where h24 ...' == Line 295 has weird spacing: '...a-where h34...' -- 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 (October 10, 2007) is 6036 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) -- Missing reference section? 'RFC5013' on line 1127 looks like a reference -- Missing reference section? 'DCMI' on line 1101 looks like a reference -- Missing reference section? 'RFC3986' on line 1136 looks like a reference -- Missing reference section? 'AACR2' on line 1090 looks like a reference -- Missing reference section? 'RDF' on line 1114 looks like a reference -- Missing reference section? 'XML' on line 1124 looks like a reference -- Missing reference section? 'MARC' on line 1104 looks like a reference -- Missing reference section? 'MODS' on line 1107 looks like a reference -- Missing reference section? 'ARK' on line 1097 looks like a reference -- Missing reference section? 'PREMIS' on line 1110 looks like a reference -- Missing reference section? 'TEMPER' on line 1117 looks like a reference -- Missing reference section? 'W3CDTF' on line 1121 looks like a reference -- Missing reference section? 'RFC2822' on line 1130 looks like a reference -- Missing reference section? 'ANVL' on line 1093 looks like a reference -- Missing reference section? 'RFC3629' on line 1133 looks like a reference -- Missing reference section? 'URI' on line 754 looks like a reference -- Missing reference section? 'TGN' on line 888 looks like a reference -- Missing reference section? 'MIME' on line 922 looks like a reference -- Missing reference section? 'RFC4646' on line 951 looks like a reference -- Missing reference section? 'DCTYPE' on line 1039 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 27 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Kunze 3 Internet-Draft A. Turner 4 Expires: April 12, 2008 California Digital Library 5 October 10, 2007 7 Kernel Metadata and Electronic Resource Citations (ERCs) 8 http://www.ietf.org/internet-drafts/draft-kunze-erc-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 12, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Kernel metadata is a small prescriptive vocabulary designed to 42 support highly uniform but minimal object descriptions for the 43 purpose of orderly collection management. The Kernel vocabulary, 44 based on a subset of the Dublin Core (DC) metadata element set, aims 45 to describe objects of any form or category, but its reach is limited 46 to a small number of fundamental questions such as who, what, when, 47 and where. The Electronic Resource Citation (ERC), also specified in 48 this document, is an object description that addresses those four 49 questions using Kernel and other metadata elements. 51 Table of Contents 53 1. Goals of Kernel Metadata . . . . . . . . . . . . . . . . . . . 3 54 2. The Kernel and the ERC in Context . . . . . . . . . . . . . . 4 55 3. Kernel Stories . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1. The Anchoring Story . . . . . . . . . . . . . . . . . . . 5 57 3.2. Story Summary . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Kernel Summary and Dublin Core Crosswalk . . . . . . . . . . . 8 59 5. The Kernel and the ERC . . . . . . . . . . . . . . . . . . . . 10 60 6. The ANVL/ERC Record Syntax . . . . . . . . . . . . . . . . . . 11 61 7. Kernel Label Structure . . . . . . . . . . . . . . . . . . . . 13 62 8. Kernel Sort-Friendly Values . . . . . . . . . . . . . . . . . 15 63 8.1. Initial Comma to Recover Natural Word Order . . . . . . . 15 64 9. Kernel Value Structure . . . . . . . . . . . . . . . . . . . . 17 65 9.1. Multiple Values and Subvalues . . . . . . . . . . . . . . 17 66 9.2. Kernel Initial Value Conventions . . . . . . . . . . . . . 18 67 9.3. Special Kernel Standardized Value Codes . . . . . . . . . 18 68 9.4. Kernel Date Values . . . . . . . . . . . . . . . . . . . . 19 69 9.5. Element Value Encoding . . . . . . . . . . . . . . . . . . 20 70 10. Kernel Changes New in this Specification (Sept 2007) . . . . . 23 71 11. Vocabulary of Elements and Values . . . . . . . . . . . . . . 24 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 74 Intellectual Property and Copyright Statements . . . . . . . . . . 33 76 1. Goals of Kernel Metadata 78 Kernel metadata is designed to assist orderly collection management 79 by supporting the creation of brief but highly uniform object 80 descriptions that can be listed, surveyed, and searched efficiently 81 during normal collection maintenance and trouble-shooting activities. 82 These descriptions serve as object surrogates that are convenient for 83 automated sorting and filtering operations and are also eye-readable 84 without specialized display software. The goal of Kernel metadata is 85 to balance the needs for expressive power, very simple machine 86 processing, and direct human manipulation of metadata records. 88 Kernel metadata is based on the Dublin Core (DC) metadata element set 89 [RFC5013] maintained by the Dublin Core Metadata Initiative [DCMI]. 90 Kernel elements are descriptors that identify various object 91 properties. In principle they apply to any object in the universe, 92 whether digital, physical, or abstract, following in the tradition of 93 [RFC3986]. This extreme diversity of objects is approached with the 94 hypothesis that highly variable and rich object descriptions can be 95 directly comparable at the level of about four fundamental elements 96 -- who, what, when, and where -- as applied to the _expression_ of 97 the object. This sequence is a recurring theme in the Kernel. In 98 anticipation of future extensions to "how" and "why", we refer to the 99 first four elements as "the four h's" (what they all have in common 100 is an initial aspirated "h" sound, which is also shorter to say than 101 "w"). 103 Kernel-based descriptions make it possible to compare an extremely 104 diverse set of objects. Comparison is possible even when many other 105 elements co-exist with Kernel elements, or when a minor amount of 106 information in other elements overlaps with Kernel element 107 information. Regardless of whether an object is smoked, worn, 108 navigated, or in any other way, interacted with, its Kernel based 109 description ensures the presence of a few predictable points of 110 commonality in the form of easily isolatable Kernel elements. Kernel 111 elements provide a concise intersection of interoperable (or at least 112 comparable) elements across a broad range of object descriptions. 114 2. The Kernel and the ERC in Context 116 The Kernel is a vocabulary of metadata elements, where an element 117 pairs a label with a value. As a vocabulary, the Kernel offers but 118 does not obligate the use of its terms. The Kernel specifies both 119 metadata elements and how particular data values should be structured 120 within the elements. These rules may be complemented by other 121 conventions (e.g., [AACR2]), although this is not required. As with 122 most vocabularies, ultimate responsibility for creating coherent and 123 sensible descriptions lies with the metadata creator. 125 The Electronic Resource Citation (ERC) introduced in this document is 126 a kind of object description that does obligate use of the four 127 fundamental Kernel elements. Standard encoding methods such as [RDF] 128 and [XML] may be used to format ERCs and Kernel metadata. It is also 129 possible to encode modified forms of Kernel element values using 130 other methods, such as [MARC] or [MODS], although some granularity of 131 information may be lost in the process. One important user of Kernel 132 metadata and ERC object descriptions is the [ARK] identifier scheme. 134 The practice of using non-Kernel elements along with Kernel elements 135 is normal: Kernel elements may appear in the same record with 136 metadata from other vocabularies, such as Dublin Core and [PREMIS]. 137 The requirement to use the four fundamental Kernel elements (the four 138 h's) at a minimum is imposed specifically in the context of a 139 complete ERC record, such as, 141 erc: 142 who: Gibbon, Edward 143 what: The Decline and Fall of the Roman Empire 144 when: 1781 145 where: http://www.ccel.org/g/gibbon/decline/ 147 The four h's provide an affordable set of comparable elements common 148 to a wide range of divergent metadata and object types, but do so 149 without limiting the expressive range of the records. The above 150 description, however, is minimal and therefore limited to the story 151 of an object's expression. 153 3. Kernel Stories 155 The Kernel has a concept of "story", which is an organizing principle 156 that applies the questions of who, what, when, and where to different 157 aspects of an object description. The four required Kernel elements 158 address one particular aspect -- the story of an object's expression 159 -- and in so doing form something similar to a traditional citation: 161 _who_ expressed it (from DC Creator, Contributor, and Publisher), 163 _what_ the expression was called (from DC Title), 165 _when_ it was expressed (from DC Date), and 167 _where_ the expression can be found (from DC Identifier). 169 One descriptive record may contain stories of different expressions 170 of the same object, for example, its digital and physical 171 expressions. Depending on the object type -- article, photograph, 172 dance, fossil -- an object's expression could mean quite different 173 things, such as its publication, installation, performance, or 174 discovery. One descriptive record may also contain stories of 175 several different types, such as what the object is about (its 176 "aboutness"), the origin of the record itself, and the provider's 177 organizational support for the object. More about these story types 178 is given after first describing the story that anchors a descriptive 179 record. 181 3.1. The Anchoring Story 183 Among all the stories that an object's descriptive record may 184 contain, there is one that the provider deems the most suitable basic 185 referent given its audience and application. This is called the 186 "anchoring" story. The provider has great latitude in choosing its 187 anchoring story, but usually it appears first in the record as a kind 188 of object summary that can be easily isolated by the human eye 189 (Kernel elements appearing anywhere in a record can always be easily 190 isolated by automated processes). If the record contains only one 191 story, the anchoring story is it, and the record consists of just the 192 four h's. A typical anchoring story for a born-digital document 193 would be the story of the document's release on a web site. 195 Digital objects that weren't born-digital often call for a slightly 196 more subtle approach. The anchoring story is usually a convenient 197 front door into a non-specialist experience of the object, and that 198 typically means instant access, where possible, either to the object 199 or to a reasonable facsimile. So for a physical object resulting 200 from a creative act (a book, statue, photograph, etc), the first 201 three of the four h's should be biased towards the story of the 202 original act while the location of the expression should, if 203 possible, be a machine-actionable identifier. Even though such an 204 identifier leads to a derivative object, automated access is often 205 deemed important enough to the initial experience to be included in 206 the anchoring story. 208 The complete and pure stories of both the derivative and original 209 objects can be told, if necessary, elsewhere in the record. 210 Meanwhile, the chance to anchor the object description in a hybrid 211 story that describes the original work but favors electronic access 212 is consistent with the 'E' (for electronic) in ERC. Above, for 213 example, a URL to the online version of the book written in 1781 is 214 given in preference to its shelf location in a library. 216 An anchoring story need not be the central descriptive goal of an ERC 217 (or any other) record. For example, a museum provider may create an 218 ERC for a digitized photograph of a painting but choose to anchor it 219 in the story of the original painting instead of the story of the 220 electronic likeness; although the ERC may through other stories prove 221 to be centrally concerned with describing the electronic likeness, 222 the provider may have chosen this particular anchoring story in order 223 to make the ERC visible in a way that is most natural to patrons (who 224 would find the Mona Lisa under da Vinci sooner than they would find 225 it under the name of the person who snapped the photograph or scanned 226 the image). In another example, a provider that creates an ERC for a 227 dramatic play as an abstract work has the task of describing a piece 228 of intangible intellectual property. To anchor this abstract object 229 in the concrete world, if only through a derivative expression, it 230 makes sense for the provider to choose a suitable printed edition of 231 the play as the anchoring object expression (to describe in the 232 anchoring story) of the ERC. 234 3.2. Story Summary 236 This section contains the list of currently defined story types, with 237 additional story types under development. As shown below, similarly 238 named elements are used in the Kernel to address the stories of an 239 object's content, its support, the provenance of the metadata record 240 itself, etc. Only one story is required of a complete (non-stub) 241 ERC, and only four of its elements must be present. 243 who: a responsible person or party (required) 244 what: a name or other human-oriented identifier (required) 245 when: a date important in the object's lifecycle (required) 246 where: a location or system-oriented identifier (required) 247 how: (under construction) a formal type designator 248 about-who: a person or party figuring in the information content 249 about-what: a subject or topic figuring in the information content 250 about-when: a time period covered by the information content 251 about-where: a location or region covered by the information content 252 about-how: a description of the information content 254 meta-who: a person or party responsible for the record 255 meta-what: a short form of the identifier for the record 256 meta-when: the last modification date of the record 257 meta-where: a location of the fullest form of the record 259 support-who: a person or party responsible for the object 260 support-what: a short form of the commitment made to the object 261 support-when: the last modification date of the commitment 262 support-where: a location of the fullest form of the commitment 264 4. Kernel Summary and Dublin Core Crosswalk 266 Each Kernel element label has a coded synonym (the SYN column below) 267 that consists of the letter 'h' followed by a number, such as h1, h2, 268 h3, etc. The following table, organized by "story", summarizes the 269 rough correspondence between Kernel elements and Dublin Core 270 elements; the vocabulary section of this document details the true 271 correspondence and element restrictions. 273 STORY KERNEL LABEL SYN DUBLIN CORE APPROXIMATION 275 erc: * who h1 Creator/Contributor/Publisher 276 The story of * what h2 Title 277 an object's * when h3 Date 278 expression. * where h4 Identifier (permanent) 279 how h5 (reserved Type restriction**) 281 about-erc: about-who h11 Subject (personage) 282 The story of about-what h12 Subject 283 an object's about-when h13 Coverage (temporal) 284 content. about-where h14 Coverage (spatial) 285 about-how h15 Description 287 support-erc: support-who h21 (no equivalent) 288 The story of support-what h22 (no equivalent) 289 an object's support-when h23 (no equivalent) 290 support. support-where h24 (no equivalent) 292 meta-erc: meta-who h31 (no equivalent) 293 The story of meta-what h32 (no equivalent) 294 this record's meta-when h33 (no equivalent) 295 expression. meta-where h34 (no equivalent) 297 * A complete ERC requires a non-missing value for this element. 298 ** Under development. 300 Where Kernel elements map to Dublin Core (DC) elements, the map is 301 roughly one-to-one, but with a few notable exceptions. 303 1. "who" maps to DC Creator, but if no Creator use Publisher, and if 304 no Publisher, use Contributor; "who" resembles what was once 305 considered in DCMI to be an "agent" element 307 2. "about-when" maps to the temporal aspect of DC Coverage and 308 "about-where" maps to the spatial aspect of DC Coverage. 310 3. The Kernel assumes that most values, especially personal names 311 given in "who", will be given in "sort-friendly" manner, for 312 example, "lastname, firstname" for western names and natural word 313 order for Chinese names. 315 4. The Kernel assumes [TEMPER] format for dates in order to express 316 date ranges, lists, approximate dates, and BC dates (not 317 possible, for example, with [W3CDTF]). 319 5. The Kernel and the ERC 321 This table illustrates the strong connection between the story 322 concept in the Kernel and the ERC. While the Kernel is a vocabulary, 323 it is the ERC that brings the assumptions about required elements. 324 An ERC that does not contain all four h's is still a useful 325 container, as when a description is being constructed, but it is 326 classified as a "stub ERC". In the case of a stub, such as, 328 erc: 329 what: The Digital Dilemma 330 where: http://books.nap.edu/html/digital%5Fdilemma 332 the "erc:" label indicates that Kernel vocabulary elements are 333 expected, and later inspection discloses that this ERC is incomplete. 335 An abbreviated form of any story can be given using the story label 336 as an element label, and then constructing one long value by listing 337 each of the story elements' values, in the order shown above, 338 separated by a solidus ("|"). Because this composite value drops the 339 constituent value labels, the ordering must be strictly observed so 340 that the corresponding elements can be accurately identified. The 341 abbreviated form of the example from section 2 is: 343 erc: Gibbon, Edward | The Decline and Fall of the Roman Empire 344 | 1781 | http://www.ccel.org/g/gibbon/decline/ 346 A story label appearing with no value may be useful in visually 347 setting off a region of a record but otherwise has no significance. 348 The one exception is that the "erc" label, with or without an 349 accompanying value, serves as a kind of record label that declares an 350 object description to be an ERC. 352 Any story label can introduce an abbreviated story form, such as, 354 meta-erc: NLM | pm9546494 | 19980418 355 | http://ark.nlm.nih.gov/12025/pm9546494?? 356 about-erc: | Bispectrum ; Nonlinearity ; Epilepsy 357 ; Cooperativity ; Subdural ; Hippocampus 359 There is no general requirement concerning missing values for these 360 story labels (as for the "erc" label). It is common for composite 361 Kernel elements to be constructed with subelement ordering that 362 echoes the familiar who, what, when, where pattern. 364 Future versions of the Kernel may extend the four h's with two 365 additional but non-required elements: how and why. These element 366 names are reserved but under construction. 368 6. The ANVL/ERC Record Syntax 370 One way to represent an ERC is to use ANVL (A Name-Value Language), a 371 simple text-based record syntax in the tradition of classic internet 372 protocols such as [RFC2822]. Here is an example of an ERC as an ANVL 373 record: 375 erc: 376 who: Lederberg, Joshua 377 what: Studies of Human Families for Genetic Linkage 378 when: 1974 379 where: http://profiles.nlm.nih.gov/BB/AA/TT/tt.pdf 380 note: This is an arbitrary note inside a 381 small descriptive record. 383 What makes this ANVL record a complete ERC record is the "erc:" label 384 and the presence of the four required elements. 386 It should be possible to represent an ERC in many different encodings 387 (e.g., XML with a specific schema), provided the Kernel rules for 388 element labels and values are followed. The Kernel rules coincide 389 with rules for ANVL labels and values. Because ANVL is concise and 390 easy to read, we will continue to use it in examples throughout this 391 document. 393 As an ANVL record, the ERC is a sequence of elements beginning with 394 "erc::" and ending in a blank line (who newlines in a row). While 395 the ERC will look different in other encodings, in ANVL, 397 1. The record begins with "erc:" and ends at the first blank line. 399 2. Each element consists of a label, a colon, and an optional value. 401 3. A long value may be folded (continued) onto the next line by 402 inserting a newline and indenting the next line. 404 4. A line beginning with a number sign ("#") is to be treated by 405 recipients as if it were not present (in programmer terms, this 406 would be called a _comment_ line). 408 A value can thus be folded across multiple lines. An element value 409 folded across several lines is treated as if the lines were joined 410 together on one long line; thus the "note" element above is 411 considered the same as 413 note: This is an arbitrary note inside a small descriptive record. 415 That is all that this document has to say about ANVL, a complete 416 description of which is detailed in the ANVL specification [ANVL]. 418 Independent of ANVL or any other encoding, there are rules for 419 encoding ERCs in any concrete syntax. Inside Kernel element labels 420 and values these rules happen to coincide with the ANVL element 421 rules. The basic features of any format holding Kernel elements are: 423 1. An element consists of a value paired with a non-empty label. 425 2. In general, a record may contain any number of element instances 426 bearing the same label. 428 3. Element order is preserved. 430 In addition to these element rules, an ERC is considered complete 431 only if all four elements "who", "what", "when", and "where" are 432 present with no missing values; these four h's each have the coded 433 synonyms h1, h2, h3, and h4, respectively. If a best effort to 434 supply a value fails, in its place must be given a standardized value 435 (below) indicating the reason for the missing value. 437 As mentioned, the Kernel is just a vocabulary and it is the ERC that 438 imposes assumptions about required elements. The four h's may be 439 supplied with implicit labels by using the abbreviated-form ERC. In 440 this case, element ordering must be strictly observed, as in 442 erc: Lederberg, Joshua 443 | Studies of Human Families for Genetic Linkage | 1974 444 http://profiles.nlm.nih.gov/BB/AA/TT/tt.pdf 445 note: This is an arbitrary note inside a 446 small descriptive record. 448 A record that does not have all four h's is considered a "stub ERC". 449 Stubs may be especially useful for holding records that are under 450 construction or are subject to an automated completion process. 452 While the ERC is a general-purpose container for exchange of resource 453 descriptions, it does not dictate how records must be internally 454 stored, laid out, or assembled by data providers or recipients. 455 Arbitrary internal descriptive frameworks can support ERCs simply by 456 mapping (e.g., on demand) local records to an ERC container and 457 making them available for export. Therefore, to support ERCs there 458 is no need for a data provider to convert internal data to be stored 459 in an ERC format. 461 7. Kernel Label Structure 463 The rest of this document is concerned with Kernel metadata 464 independent of the ERC. Nonetheless, examples will continue to be 465 given using the ANVL/ERC format. 467 Kernel element labels are strings beginning with a letter that may 468 contain any combination of letters, numbers, hyphens, and underscores 469 ("_"). Element labels are therefore fairly consistent with the rules 470 for [XML]. An inconsistency is that Kernel labels may be entered 471 with spaces; in this case all sequences of spaces are considered 472 equivalent to a single space, and that space in turn is then 473 considered (for matching and for export to XML) to be equivalent to 474 an underscore. Any initial and final spaces are stripped away before 475 processing a label. 477 For comparison purposes, element labels are also considered case- 478 insensitive; in other words, labels may be entered and displayed with 479 case differences, but there is no possibility of conflict behind the 480 scenes when spaces and upper case are normalized to underscore and 481 lower case. For example, these rules prevent any future version of 482 the Kernel from ever having these as two distinct elements, 484 marc_856 485 MARC 856 487 For display purposes, element labels are considered case-sensitive; 488 in other words, upper- and lower-case distinctions should be 489 preserved upon display. 491 An element label may also be accompanied by its coded synonym. In 492 ANVL the synonym follows the label and is enclosed in parentheses 493 (whereis in XML, for example, the synonym might be an XML attribute). 494 In fact, if the official coded synonym is present, the label itself 495 may be represented in any UTF-8 [RFC3629] form (e.g., in a local 496 translation) that is convenient for the record's local audience, as 497 in, 499 erc: 500 wer(h1): Miller, Alice 501 was(h2): Am Anfang war Erziehung 502 wann(h3): 1983 503 wo(h4): http://www.amazon.com/exec/obidos/ASIN%{ 504 /0374522693/thenaturalchildp %} 505 Titel(h501): (en) For your Own Good: Hidden Cruelty 506 in Child-Rearing and the Roots of Violence 508 In this example, the labels are intended for local audiences and the 509 coded synonyms allow for unambiguous interpretation by software that 510 can display labels translated for other audiences. 512 8. Kernel Sort-Friendly Values 514 To keep records easy to sort and survey, it helps if element values 515 are somewhat comparable. To this end the Kernel strongly encourages 516 values that are "sort-friendly". In this way, applications have a 517 reasonable chance of successfully presenting a set of given records 518 sorted according to specific element values, such as date or author 519 name, with only general-purpose software that need not make special 520 assumptions about the structure and form of the values. It is 521 therefore standard to assume that the creator of Kernel metadata has 522 made a best effort to enter dates, titles, and names in a sort- 523 friendly manner. For example, these values are easy for non-special- 524 purpose sorting software to handle, 526 who: Khan, Hashim 527 when: 19580924 529 while these values are not sort-friendly, 531 who: Hashim Khan 532 when: Sep 24, 1958 534 8.1. Initial Comma to Recover Natural Word Order 536 Sometimes the desire to create sort-friendly values conflicts with 537 natural word order, such as with Western-style personal names. To 538 mitigate this concern, a value may optionally begin with a "," 539 (comma) to indicate how to recover natural word order; the way it 540 works is, if other commas are present in the value, they mark 541 inversion points that software (or the human eye) can use to re-order 542 words in the value. For example, 544 who:, van Gogh, Vincent 545 who:, Howell, III, PhD, 1922-1987, Thurston 546 who:, Acme Rocket Factory, Inc., The 547 who:, Mao Tse Tung 549 Natural word order can be restored by taking the last non-empty part 550 of the value set off by an internal comma and placing it at the 551 beginning. At times a secondary sort point (such as a name given 552 within a family) would be useful but is blocked because that position 553 in the value is taken by an insignificant word (such as "Dr" or 554 "Mr"). The remedy is to bracket the insignificant word with commas 555 and place it at the end where naive sorting software would then treat 556 it with minimum significance. For example, in these cases, 557 who:, McCartney, Pat, Ms, 558 who:, McCartney, Paul, Sir, 559 who:, McCartney, Petra, Dr, 560 what:, Health and Human Services, United States Government 561 Department of, The, 563 natural word order is restored by first pulling off any final value 564 part bracketed by commas, applying the previous rule, and then adding 565 back that final part to the beginning. The values from the above two 566 sets of examples have the following natural word orders. 568 Vincent van Gogh 569 Thurston Howell, III, PhD, 1922-1987 570 The Acme Rocket Factory, Inc. 571 Mao Tse Tung 572 Ms Pat McCartney 573 Sir Paul McCartney 574 Dr Petra McCartney 575 The United States Government Department of Health and Human Services 577 This feature is typically used to express Western-style personal 578 names in family-name-given-name order. As the last line above shows, 579 it can also be used wherever natural word order might not work with 580 naive sorting software, such as when data contains titles or 581 corporate names. 583 While Kernel metadata creators should make a best-effort to produce 584 values that are sort-friendly when compared with the same element in 585 other records, the consequences of deviating from this need not be 586 serious. For instance, it is usually more useful to supply a value 587 for an element than to suppress it merely because it won't 588 necessarily sort well when records appear in groups. 590 9. Kernel Value Structure 592 With sort-friendliness as a secondary criterion, in general Kernel 593 values consist of free text. Exceptions are triggered by structuring 594 markers that may occur either anywhere inside a value or only at the 595 beginning of a value. 597 Markers that may occur anywhere in a value: 599 ";" for _multiple values_ and 601 "|" for _subvalues_ 603 Markers that may occur only at the beginning of a value: 605 "(: ... )" for special _value indicators_ or 607 one of the characters ";", "|", or "," explained later. 609 These structuring markers are explained next. 611 9.1. Multiple Values and Subvalues 613 The semi-colon (";") is used to separate multiple "peer" values that 614 could equivalently be represented as multiple elements with the label 615 repeated for each separate value; in programmer terms, the ";" is a 616 kind of _array_ element separator. For example, 618 who: Smith, J; Wong, D; Khan, H 620 is a shorter way of representing 622 who: Smith, J 623 who: Wong, D 624 who: Khan, H 626 The solidus ("|") is used to separate component subvalues with 627 different types of "non-peer" contribution to the overall value; this 628 supports an element that has sub-structure. For example, 630 in: EEG Clin Neurophysiol | v103, i6, p661-678 | 19971200 632 If used together, ";" holds its neighbors more tightly (has higher 633 grouping precedence) than "|". For example, in this "erc" element 635 erc: Smith, J; Wong, D; Khan, H 636 | Cocktail Napkin Drawing #2 | 1969 637 | (:unav) destroyed during spill of 19690401 639 there are four sub-elements, the first of which has three repeated 640 values. 642 9.2. Kernel Initial Value Conventions 644 Kernel values usually start with free text, but exceptions are made 645 when the first character of a value begins with one of the single 646 action characters ";", "|", or ",". When one of the single 647 characters is recognized at the start of a value, the appropriate 648 action is taken, the character is effectively removed, and processing 649 continues on the remainder until a character that is not one of these 650 three is seen. For example, once a SPACE character or a "(: ... )" 651 construct (a special value indicator) has been recognized, no further 652 initial single character processing occurs. 654 When a value or subvalue starts with ";", it "quotes" any internal 655 occurrences of ";", in other words, it turns off the special ability 656 of ";" to divide a value or subvalue into multiple values. When a 657 value starts with "|", it "quotes" any internal occurrences of "|", 658 in other words, it turns off the special ability of "|" to divide a 659 value into subvalues. 661 When a value or subvalue starts with ",", it indicates a way to 662 recover natural word order, as explained previously. 664 9.3. Special Kernel Standardized Value Codes 666 A value starting with "(: ... )" indicates a standardized 667 (controlled) value code, usually short and precise, that is designed 668 to be readable by software. Such a value code often forms only part 669 of the value. More than one value code may appear at the beginning 670 of a value. 672 Special value codes serve different purposes. A code can indicate a 673 single specific value, with the remaining value text offering a 674 human-readable equivalent; for example, 676 who: (:unkn) anonymous 678 tells software that the element value is officially unknown and the 679 other text tells the same thing to a human reader of English that may 680 be expecting the name of an author. A code can also indicate that 681 the value is at a location given by the remaining text (which should 682 be an actionable identifier such as a URL) and is not otherwise 683 present; for example, 685 who: Wong, D 686 who: (:at) http://example.org/abc/def/ghi.txt 687 rights: (:at) http://example.com/rights/123.html 689 could be used to indicate a first author, sixty-five co-authors 690 listed in a separate file, and a copyright statement posted on a 691 corporate website. 693 Some special value codes are summarized here. All but the last four 694 indicate different kinds of "missing value": 696 (:unac) temporarily inaccessible 698 (:unal) unallowed, suppressed intentionally 700 (:unap) not applicable, makes no sense 702 (:unas) value unassigned (e.g., Untitled) 704 (:unav) value unavailable, possibly unknown 706 (:unkn) known to be unknown (e.g., Anonymous, Inconnue) 708 (:none) never had a value, never will 710 (:null) explicitly and meaningfully empty 712 (:tba) to be assigned or announced later 714 (:etal) too numerous to list (et alia). 716 (:at) the real value is at the given URL or identifier. 718 9.4. Kernel Date Values 720 A commonly recurring value type is a date, which may be followed by a 721 time. The [TEMPER] format is preferred to the [W3CDTF] format, which 722 has limitations in expressing ranges, lists, approximate, and BC 723 dates. Kernel dates may take one of the following forms: 725 1999 (four digit year) 726 20001229 (year, month, day) 727 20001229235955 (year, month, day, hour, minute, second) 729 Hyphens and commas are reserved to create date ranges and lists, for 730 example, 731 1996-2000 (a range of four years) 732 1952, 1957, 1969 (a list of three years) 733 1952, 1958-1967, 1985 (a mixed list of dates and ranges) 734 20001229-20001231 (a range of three days) 736 Approximate and BCE dates can also be expressed, as in, 738 1850~ (around the year 1850) 739 BCE1212 (death of Rameses the Great) 740 BCE0551 (birth of Confucius) 742 Note that BCE dates inherently sort in reverse order. But because 743 "BCE" appears first in the TEMPER value, naive sorting software first 744 places all BCE dates together as a group, after which the simple 745 intervention of reversing the order of the group achieves correct 746 chronological order. 748 9.5. Element Value Encoding 750 Some characters that need to appear in element values might conflict 751 with special characters used for structuring values, so there needs 752 to be a way to include them as literal characters that are protected 753 from special interpretation. This is accomplished through an 754 encoding mechanism that resembles the %-encoding familiar to [URI] 755 handlers. 757 The value encoding mechanism also uses `%', but instead of taking two 758 following hexadecimal digits, it takes two alphabetic characters that 759 cannot be mistaken for hex digits or one non-alphanumeric character. 760 It is designed not to be confused with normal web-style %-encoding. 761 In particular it can be decoded without risking unintended decoding 762 of normal %-encoded data (which would introduce errors). Here are 763 the extended Kernel encoding extensions, the middle column giving the 764 equivalent and usual hexadecimal encoding. 766 Code Hex Purpose 767 ---- --- ---------------------------------------------- 768 %sp %20 decodes to space 769 %ex %21 decodes to ! 770 %dq %22 decodes to " 771 %ns %23 decodes to # 772 %do %24 decodes to $ 773 %pe %25 decodes to % 774 %am %26 decodes to & 775 %sq %27 decodes to ' 776 %op %28 decodes to ( 777 %cp %29 decodes to ) 778 %as %2a decodes to * 779 %pl %2b decodes to + 780 %co %2c decodes to , 781 %sl %2f decodes to / 782 %cn %3a decodes to : 783 %sc %3b decodes to ; 784 %lt %3c decodes to < 785 %eq %3d decodes to = 786 %gt %3e decodes to > 787 %qu %3f decodes to ? 788 %at %40 decodes to @ 789 %ox %5b decodes to [ 790 %ls %5c decodes to \ 791 %cx %5d decodes to ] 792 %vb %7c decodes to | 793 %nu %00 decodes to null 794 %% %25 decodes to % 795 %_ n/a a non-character used as a syntax shim 796 %{ n/a a non-character that begins an expansion block 797 %} n/a a non-character that ends an expansion block 799 One particularly useful construct in an element values is the pair of 800 special encoding markers ("%{" and "%}") that indicates a "expansion" 801 block. Whatever string of characters they enclose will be treated as 802 if none of the contained whitespace (SPACEs, TABs, Newlines) were 803 present. This comes in handy for writing long, multi-part URLs in a 804 readable way. For example, the value in 806 where: http://foo.bar.org/node%{ 807 ? db = foo 808 & start = 1 809 & end = 5 810 & buf = 2 811 & query = foo + bar + zaf 812 %} 814 is decoded into an equivalent element, but with a correct and intact 815 URL: 817 where: 818 http://foo.bar.org/node?db=foo&start=1&end=5&buf=2&query=foo+bar+zaf 820 10. Kernel Changes New in this Specification (Sept 2007) 822 1. editorial changes based on feedback from DC 2007 and discussion 823 in the Kernel Application Profile task group 825 2. coined a URI base (currently not actionable) as a unique 826 reference for each vocabulary term, partly in order to prepare a 827 DCMI Kernel Application Profile 829 3. added reference to ARK persistent identifier scheme, which uses 830 Kernel/ERC 832 4. addition of "(:" and ")" in relevant vocabulary entries 834 5. eliminated unneeded initial character escaping ambiguity; to 835 prevent initial single-character processing of ",", ";", and "|", 836 it is sufficient to begin a subvalue with a SPACE 838 11. Vocabulary of Elements and Values 840 This vocabulary includes a mixture of Kernel elements, values, and 841 concepts. In the definitions below, the term "resource" is 842 synonymous with "object". Each vocabulary element label has a short, 843 coded synonym that consists of the letter 'h' followed by a number, 844 such as h1, h2, h3, etc. Each vocabulary element also has a long, 845 globally unique identifier that is a URI composed of 846 http://n2t.info/ark:/99152/ followed by the short synonym; for 847 example, 849 about-when(h13) --> http://n2t.info/ark:/99152/h13 851 At the price of some redundancy, it also includes the basic 15 Dublin 852 Core (DC) element definitions because (a) DC elements can be used 853 without namespace qualification in ERC records and (b) the Kernel 854 assigns them coded synonyms (h501-h515). 856 about-erc (h10): A composite element, structured according to the 857 four h's, that describes the content of the object. Without a 858 value, it is a label for visually setting off a region in a 859 record. 861 about-what (h12): A topic of the resource. DC Mapping: Subject 863 about-when (h13): A temporal topic of the resource. DC Mapping: 864 Coverage (temporal) 866 about-where (h14): A spatial topic of the resource. DC Mapping: 867 Coverage (spatial) 869 about-who (h11): A name of a personage that is a topic of resource. 871 about-how (h15): An account of the resource. DC Mapping: 872 Description 874 contributor (h506): An entity responsible for making contributions 875 to the resource. Examples of a Contributor include a person, an 876 organization, or a service. Typically, the name of a Contributor 877 should be used to indicate the entity. 879 coverage (h514): The spatial or temporal topic of the resource, the 880 spatial applicability of the resource, or the jurisdiction under 881 which the resource is relevant. Spatial topic and spatial 882 applicability may be a named place or a location specified by its 883 geographic coordinates. Temporal topic may be a named period, 884 date, or date range. A jurisdiction may be a named administrative 885 entity or a geographic place to which the resource applies. 887 Recommended best practice is to use a controlled vocabulary such 888 as the Thesaurus of Geographic Names [TGN]. Where appropriate, 889 named places or time periods can be used in preference to numeric 890 identifiers such as sets of coordinates or date ranges. 892 creator (h502): An entity primarily responsible for making the 893 resource. Examples of a Creator include a person, an 894 organization, or a service. Typically, the name of a Creator 895 should be used to indicate the entity. 897 date (h507): A point or period of time associated with an event in 898 the lifecycle of the resource. Date may be used to express 899 temporal information at any level of granularity. Recommended 900 best practice is to use an encoding scheme, such as the W3CDTF 901 profile of ISO 8601 [W3CDTF]. 903 description (h504): An account of the resource. Description may 904 include but is not limited to: an abstract, a table of contents, a 905 graphical representation, or a free-text account of the resource. 907 ERC Electronic Resource Citation, an object description that uses, 908 at a minimum, the fundamental Kernel elements, who, what, when, 909 and where addressing the expression of the object. 911 erc (h0): A composite element, structured according to the four h's, 912 that describes the expression of the resource. Without a value, 913 it is a label declaring a record to be an ERC, a complete instance 914 of which requires non-missing values for each of the four h's. 916 (:etal) A null element term explaining that the value is a stand-in 917 for other values too numerous to list (et alia). 919 format (h509): The file format, physical medium, or dimensions of 920 the resource. Examples of dimensions include size and duration. 921 Recommended best practice is to use a controlled vocabulary such 922 as the list of Internet Media Types [MIME]. 924 four h's The four fundamental Kernel elements -- who, what, when, 925 where -- commonly used to structure composite Kernel elements. To 926 say "structured according to the four h's" indicates a sub-element 927 sequence suggesting this particular sequence; this serves as an 928 important memory aid with abbreviated form elements in which 929 explicit labels are absent. The literal form of these labels, by 930 themselves, address the story of the expression of an object, and 931 in that form they are required of every complete ERC. Future 932 versions of the Kernel may extend the sequencing of four h's with 933 non-required elements "how" and "why". 935 identifier (h510): An unambiguous reference to the resource within a 936 given context. Recommended best practice is to identify the 937 resource by means of a string conforming to a formal 938 identification system. 940 in (h602): (under construction) Reserved for a composite element 941 referencing a serial publication in which the described object 942 appears. This element is structured in a manner loosely 943 reminiscent of the four h's, indicating serial name, volume/issue/ 944 page, date, and issue URL. DC Mapping: Relation 946 how (h5): (under construction) Reserved for a coded value indicating 947 how the object was expressed. 949 language (h512): A language of the resource. Recommended best 950 practice is to use a controlled vocabulary such as RFC 4646 951 [RFC4646]. 953 metadata Structured data, generally descriptive of or associated 954 with a given object or resource. Structured data at a minimum has 955 evident start and end points and may have evident labels. 957 meta-erc (h30): A composite element, structured according to the 958 four h's, that describes the expression of this (the containing) 959 record. Without a value, it is a label for visually setting off a 960 region in a record. 962 meta-what (h32): A short form of the identifier for the record. 964 meta-when (h33): The last modification or review date of the record. 966 meta-where (h34): A location of the fullest form of the record. 968 meta-who (h31): A person or party responsible for the record. 970 (:none) A null element term explaining that the element never had a 971 value and never will. This is a stronger form of :unas. 973 note (h601): A free text note about the record. 975 (:null) A null element term explaining that the value is explicitly 976 empty, where an empty value has a well-defined meaning in contexts 977 (not necessarily evident) in which the element is used. 979 object Anything to which metadata may be applied. Synonym: 980 "resource" 982 publisher (h505): An entity responsible for making the resource 983 available. Examples of a Publisher include a person, an 984 organization, or a service. Typically, the name of a Publisher 985 should be used to indicate the entity. 987 resource Anything to which metadata may be applied. Synonym: 988 "object" 990 relation (h513): A related resource. Recommended best practice is 991 to identify the related resource by means of a string conforming 992 to a formal identification system. 994 rights (h515): Information about rights held in and over the 995 resource. Typically, rights information includes a statement 996 about various property rights associated with the resource, 997 including intellectual property rights. 999 source (h511): A related resource from which the described resource 1000 is derived. The described resource may be derived from the 1001 related resource in whole or in part. Recommended best practice 1002 is to identify the related resource by means of a string 1003 conforming to a formal identification system. 1005 subject (h503): The topic of the resource. Typically, the subject 1006 will be represented using keywords, key phrases, or classification 1007 codes. Recommended best practice is to use a controlled 1008 vocabulary. To describe the spatial or temporal topic of the 1009 resource, use the Coverage element. 1011 support-erc (h20): A composite element, structured according to the 1012 four h's, that describes the support commitment a provider makes 1013 to the object. Without a value, it is a label for visually 1014 setting off a region in a record. 1016 support-what (h22): A short form of the commitment made to the 1017 object. 1019 support-when (h23): The last modification or review date of the 1020 commitment made to the object. 1022 support-where (h24): A location of the fullest form of the 1023 commitment made to the object. 1025 support-who (h21): A person or party responsible for the object, 1026 such as the provider of preservation or access services. 1028 stub ERC An incomplete ERC record. To be incomplete it is 1029 sufficient for one or more of the four h's (the elements who, 1030 what, when, and where) to be missing or to have a missing value. 1032 (:tba) A null element term explaining that the value is to be 1033 assigned or announced later. 1035 title (h501): A name given to the resource. 1037 type (h508): The nature or genre of the resource. Recommended best 1038 practice is to use a controlled vocabulary such as the DCMI Type 1039 Vocabulary [DCTYPE]. To describe the file format, physical 1040 medium, or dimensions of the resource, use the Format element. 1042 (:unac) A null element term explaining that the value is temporarily 1043 inaccessible. This might be due, for example, to a system outage. 1045 (:unal) A null element term explaining that the value is unallowed 1046 or suppressed intentionally. 1048 (:unap) A null element term explaining that no value is applicable 1049 or makes no sense. 1051 (:unas) A null element term explaining that a value was never 1052 assigned. An untitled painting is an example. 1054 (:unav) A null element term explaining that the value is unavailable 1055 for some reason. Compared to :unkn, this term conveys no 1056 particular confidence about the non-existence of the value. It 1057 may originate in collections that have not yet conducted a 1058 thorough investigation or it may arise in intermediate systems 1059 that repackage received records having missing elements. 1061 (:unkn) A null element term explaining that the value is unknown. 1062 Compared to :unav, this term conveys greater confidence and 1063 authority that an appropriate value is unknown to anyone for the 1064 object described. An example is an expert assessment of 1065 "anonymous" concerning authorship. 1067 what (h2): A human-oriented name given to the resource, or what this 1068 expression of the resource was called. Compared to the "where" 1069 element, which is also a kind of name, the "what" element tends to 1070 be more suitable for human consumption. DC Mapping: Title 1072 when (h3): A point or period of time associated with an event in the 1073 lifecycle of the resource, often when it was expressed, created or 1074 made available. DC Mapping: Date 1076 where (h4): An access-oriented name given to the resource, or where 1077 this resource was expressed. is to identify the resource by means 1078 of a string or number conforming to a formal identification 1079 system. Compared to the "what" element, which is also a kind of 1080 name, the "where" element tends to be more suitable for automated 1081 access. DC Mapping: Identifier 1083 who (h1): An entity responsible for expressing the object, such as 1084 creating it or making it available. Examples of "who" include a 1085 person, an organization, or a service. DC Mapping: Creator, but 1086 if no Creator use Publisher, and if no Publisher, use Contributor 1088 12. References 1090 [AACR2] American Library Association, "Anglo-American Cataloguing 1091 Rules", 2007, . 1093 [ANVL] Kunze, J. and Kahle, B., "A Name-Value Language", 1094 February 2005, 1095 . 1097 [ARK] Kunze, J. and R. Rodgers, "The ARK Persistent Identifier 1098 Scheme", July 2007, 1099 . 1101 [DCMI] Dublin Core Metadata Initiative, "DCMI Metadata Terms", 1102 . 1104 [MARC] Library of Congress, "Machine Readable Cataloguing", 2007, 1105 . 1107 [MODS] Library of Congress, "Metadata Object Description Schema", 1108 June 2006, . 1110 [PREMIS] OCLC and RLG, "PREMIS Data Dictionary, version 1.0", 2005, 1111 . 1114 [RDF] W3C, "Resource Description Framework", 1115 . 1117 [TEMPER] Blair, C. and J. Kunze, "Temporal Enumerated Ranges", 1118 August 2007, 1119 . 1121 [W3CDTF] "Date and Time Formats (W3C profile of ISO8601)", 1122 . 1124 [XML] W3C, "Extensible Markup Language (XML) 1.0 (Fourth 1125 Edition)", August 2006, . 1127 [RFC5013] Kunze, J. and T. Baker, "The Dublin Core Metadata Element 1128 Set", RFC 5013, August 2007. 1130 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 1131 April 2001. 1133 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1134 10646", STD 63, RFC 3629, November 2003. 1136 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1137 Resource Identifier (URI): Generic Syntax", STD 66, 1138 RFC 3986, January 2005. 1140 Authors' Addresses 1142 John A. Kunze 1143 California Digital Library 1144 415 20th St, 4th Floor 1145 Oakland, CA 94612 1146 US 1148 Fax: +1 510-893-5212 1149 Email: jak@ucop.edu 1151 Adrian Turner 1152 California Digital Library 1153 415 20th St, 4th Floor 1154 Oakland, CA 94612 1155 US 1157 Fax: +1 503-234-3581 1158 Email: adrian.turner@ucop.edu 1160 Full Copyright Statement 1162 Copyright (C) The IETF Trust (2007). 1164 This document is subject to the rights, licenses and restrictions 1165 contained in BCP 78, and except as set forth therein, the authors 1166 retain all their rights. 1168 This document and the information contained herein are provided on an 1169 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1170 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1171 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1172 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1173 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1174 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1176 Intellectual Property 1178 The IETF takes no position regarding the validity or scope of any 1179 Intellectual Property Rights or other rights that might be claimed to 1180 pertain to the implementation or use of the technology described in 1181 this document or the extent to which any license under such rights 1182 might or might not be available; nor does it represent that it has 1183 made any independent effort to identify any such rights. Information 1184 on the procedures with respect to rights in RFC documents can be 1185 found in BCP 78 and BCP 79. 1187 Copies of IPR disclosures made to the IETF Secretariat and any 1188 assurances of licenses to be made available, or the result of an 1189 attempt made to obtain a general license or permission for the use of 1190 such proprietary rights by implementers or users of this 1191 specification can be obtained from the IETF on-line IPR repository at 1192 http://www.ietf.org/ipr. 1194 The IETF invites any interested party to bring to its attention any 1195 copyrights, patents or patent applications, or other proprietary 1196 rights that may cover technology that may be required to implement 1197 this standard. Please address the information to the IETF at 1198 ietf-ipr@ietf.org. 1200 Acknowledgment 1202 Funding for the RFC Editor function is provided by the IETF 1203 Administrative Support Activity (IASA).