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).