idnits 2.17.1 draft-ietf-schema-mime-metadata-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (31 January 1998) is 9582 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: 'RFC225X' is mentioned on line 108, but not defined == Missing Reference: 'MIMELDAP' is mentioned on line 369, but not defined == Missing Reference: 'MIMEWHOISPP' is mentioned on line 369, but not defined == Missing Reference: 'MIMEWHOIS' is mentioned on line 369, but not defined == Missing Reference: 'MIMERWHOIS' is mentioned on line 370, but not defined == Missing Reference: 'MIMEXML' is mentioned on line 370, but not defined == Unused Reference: 'RFC1766' is defined on line 1261, but no explicit reference was found in the text == Unused Reference: 'RFC2044' is defined on line 1267, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 1270, but no explicit reference was found in the text == Unused Reference: 'RFC2046' is defined on line 1274, but no explicit reference was found in the text == Unused Reference: 'RFC2047' is defined on line 1277, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FILESYN' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIMEDIR' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1766 (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) -- Duplicate reference: RFC2047, mentioned in 'RFC2047', was also mentioned in 'MIME'. Summary: 13 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT C. Apple 3 AT&T Labs 4 Expires: July 31, 1998 31 January 1998 6 Directory Schema Listing Meta Data 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 Abstract 29 This memo defines a MIME directory profile for content transfer and 30 encoding of metadata elements used for cataloging schema listings in 31 a directory schema listing service. 33 Table of Contents 35 1.0 Introduction. . . . . . . . . . . . . . . . . . . . . . . . 3 36 1.1 Terms and Definitions . . . . . . . . . . . . . . . . . . . 3 37 2.0 The "schema-metadata-0" MIME Directory Profile Registration 4 38 3.0 MIME Directory Type Registrations . . . . . . . . . . . . . 6 39 3.1 listingName . . . . . . . . . . . . . . . . . . . . . . . . 6 40 3.2 listingTitle. . . . . . . . . . . . . . . . . . . . . . . . 7 41 3.3 listingUse. . . . . . . . . . . . . . . . . . . . . . . . . 8 42 3.4 specFile. . . . . . . . . . . . . . . . . . . . . . . . . . 8 43 3.5 relatedTo . . . . . . . . . . . . . . . . . . . . . . . . . 9 44 3.6 contactLanguage . . . . . . . . . . . . . . . . . . . . . . 10 45 3.7 contactName . . . . . . . . . . . . . . . . . . . . . . . . 11 46 3.8 contactEmail. . . . . . . . . . . . . . . . . . . . . . . . 11 47 3.9 contactPhone. . . . . . . . . . . . . . . . . . . . . . . . 12 48 3.10 contactAddress . . . . . . . . . . . . . . . . . . . . . . 13 49 3.11 authLanguage . . . . . . . . . . . . . . . . . . . . . . . 13 50 3.12 authName . . . . . . . . . . . . . . . . . . . . . . . . . 14 51 3.13 authEmail. . . . . . . . . . . . . . . . . . . . . . . . . 15 52 3.14 authPhone. . . . . . . . . . . . . . . . . . . . . . . . . 16 53 3.15 authAddress. . . . . . . . . . . . . . . . . . . . . . . . 16 54 3.16 specURL. . . . . . . . . . . . . . . . . . . . . . . . . . 17 55 3.17 security . . . . . . . . . . . . . . . . . . . . . . . . . 17 56 3.18 created. . . . . . . . . . . . . . . . . . . . . . . . . . 18 57 3.19 moreInfo . . . . . . . . . . . . . . . . . . . . . . . . . 19 58 3.20 caveat . . . . . . . . . . . . . . . . . . . . . . . . . . 20 59 3.21 listingComments. . . . . . . . . . . . . . . . . . . . . . 21 60 3.22 schemaPak. . . . . . . . . . . . . . . . . . . . . . . . . 22 61 3.23 pakMember. . . . . . . . . . . . . . . . . . . . . . . . . 22 62 4.0 Examples. . . . . . . . . . . . . . . . . . . . . . . . . . 23 63 4.1 Schema Unit Listing Request Use of Profile. . . . . . . . . 23 64 4.2 Published Schema Unit Listing Use of Profile. . . . . . . . 24 65 4.3 Schema Pak Listing Request Use of Profile . . . . . . . . . 25 66 4.4 Published Schema Pak Listing Use of Profile . . . . . . . . 25 67 5.0 Security Considerations . . . . . . . . . . . . . . . . . . 26 68 6.0 Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 27 69 7.0 References. . . . . . . . . . . . . . . . . . . . . . . . . 27 70 8.0 Author's Address. . . . . . . . . . . . . . . . . . . . . . 28 72 1.0 Introduction 74 The fastest route to interoperable directory services is through 75 standard object classes and attribute types. There is a growing 76 number of places where schema for Internet Directory Services and 77 Internet Operations are being defined, with varying degrees of 78 documentation. This plethora of schema is unavoidable in the light 79 of the needs of different service communities, but it makes it 80 difficult for directory service builders to find and make use of an 81 existing schema that will serve their needs and increase 82 interoperability with other systems. A listing service providing a 83 single point of discovery for directory service schema will promote 84 schema reuse, reduce duplication of effort, and thus promote 85 directory service interoperability. Metadata will be used to catalog 86 and distinguish schema listings in this service. This document 87 defines a [MIMEDIR] profile for metadata content transfer and 88 encoding. 90 1.1 Terms and Definitions 92 Information Object - a descriptive abstraction of some real-world 93 object 95 Object Attribute - a descriptive property of an information object; 96 typically, object attributes are defined in terms of semantic and 97 syntactic definitions 99 Schema - a collection of definitions for related information objects 101 Schema Unit - a related or grouped set of object attributes that form 102 a discrete unit within the context of a schema for a particular 103 protocol; examples include an LDAP object class or a WHOIS++ template 105 Schema Pak - a related or grouped set of schema units that 106 collectively specify a schema associated with a particular protocol; 107 an example of a schema pak is the set of LDAP object classes 108 specified in [RFC225X] 110 Metadata - characteristics that differentiate one schema unit or 111 schema pak from another; used to catalog listing service content; 112 structured using a profile of [MIMEDIR]; also contains references to 113 files stored within and outside of a listing repository 115 Schema Unit Content - a formal specification of a schema unit using a 116 profile of [MIMEDIR] 118 Schema Unit Listing - the combination of a single schema unit content 119 file intended for use within the context of a particular protocol and 120 a file containing metadata describing the schema unit specified 121 within that schema unit content file 123 Schema Pak Listing - a single metadata file containing information 124 describing and referring to a set of related or grouped schema unit 125 content files 127 Repository - a database in which listings are stored 129 Listing Request - a proposed schema unit listing or schema pak 130 listing formatted using [MIME] constructs that is submitted for 131 consideration as a listing to be published in a repository 133 Operator - an organization that administers and maintains a 134 repository 136 Primary Repository - the repository that masters the schema listings 137 database 139 Shadow Repository - a repository that mirrors the primary repository 141 Contact Person - the name of the individual who holds the authority 142 to update a listing and who should be contacted if questions or 143 concerns arise related to a listing or listing request 145 Listing Authority Contact - the name of the individual who holds 146 authority to replace a contact person; can be either the contact 147 person for a listing or an alternate contact within the organization 148 to which the contact person belongs (this allows one person 149 organizations to list schema) 151 The terms for specifying requirement level defined in [RFC2119] are 152 used in this document. 154 2.0 The "schema-metadata-0" MIME Directory Profile Registration 156 This profile is identified by the following registration template 157 information. 159 To: ietf-mime-direct@imc.org 161 Subject: Registration of text/directory MIME profile 162 "schema-metadata-0" 164 Profile Name: schema-metadata-0 166 Profile Purpose: To represent metadata for a schema listing stored 167 in the repository or a schema listing request under community 168 review. 170 Profile Types: listingName, listingTitle, listingUse, specFile, 171 relatedTo, contactLanguage, contactName, contactEmail, contactPhone, 172 contactAddress, authLanguage, authName, authEmail, authPhone, 173 authAddress, specURL, security, created, moreInfo, caveat, 174 listingComments, schemaPak, pakMember 176 Profile Special Notes: 178 The charset parameter MUST be present in the MIME content header and 179 the value of this parameter MUST be "utf-8". 181 Neither the "BEGIN", "END", nor "SOURCE" type is used in the 182 contents of this profile. 184 Type grouping is not used in the contents of this profile. 186 Each MIME Directory Type Registration that follows in section 3 of 187 this document includes a specification of whether or not a 188 particular type is constrained to be single-valued or permitted to 189 be multi-valued. Types that are permitted to be multi-valued MUST 190 have at least one value, unless otherwise noted in the 'Type special 191 notes' component of a type definition. 193 Implementors should note that there will likely be values of profile 194 types in some contents much longer than 76 bytes. In addition, there 195 may be non-ASCII characters and embedded CRLFs inside of values, 196 which could require either quoting of the value or use of a content 197 transfer encoding. 199 The following types MUST be included by schema writers in schema 200 unit listing requests: listingName, listingTitle, listingUse, 201 specFile, contactLanguage, contactName, contactEmail, contactPhone, 202 contactAddress, authLanguage, authName, authEmail, authPhone, 203 authAddress, and security. 205 The following types MUST be included by schema writers in schema pak 206 listing requests: listingName, listingTitle, listingUse, specFile, 207 contactLanguage, contactName, contactEmail, contactPhone, 208 contactAddress, authLanguage, authName, authEmail, authPhone, 209 authAddress, and security. 211 The 'listingName' type value MUST be created by the primary listing 212 repository operator. 214 The 'relatedTo' type value MUST be provided by the schema writer as 215 a part of a listing request if the listing proposed in the request 216 has a relationship to published listings and/or other listing 217 requests being reviewed. 219 Values for the following types MUST be provided by the primary 220 schema listing repository operator and MUST NOT be accepted from the 221 schema writer: specURL, created, listingComments, and pakMember. 223 The schemaPak type value MAY be provided by either the primary 224 schema listing repository operator or the schema writer when 225 required. 227 The moreInfo type value is OPTIONAL, but MUST be provided by the 228 schema writer. if this metadata element is to be included in a 229 published listing. 231 Intended Usage: COMMON 233 3.0 MIME Directory Type Registrations 235 This document defines all types use in the schema-metadata-0 profile. 236 These types are intended for use in the "schema-metadata-0" profile, 237 although they may be applicable to other profiles defined in the 238 future. 240 3.1 listingName 242 To: ietf-mime-direct@imc.org 244 Subject: Registration of text/directory MIME type listingName 246 Type name: listingName 248 Type purpose: To represent a globally unique identifier for the 249 listing name. 251 Type encoding: 8bit 253 Type valuetype: text, with the following syntax (specified using the 254 BNF in [RFC822]): 256 name = oid "." sequence "." version 258 oid = oid-component *("." oid-component) 260 oid-component = 1*DIGIT 262 DIGIT = 263 sequence = NZDIGIT *DIGIT 265 NZDIGIT = 267 version = version-component *("." version-component) 269 version-component = 1*DIGIT 271 Type special notes: 273 This type MUST be single-valued. 275 A language parameter MUST NOT be used with this type. 277 For published listings and listing requests, a value of this type is 278 an OID constructed by the primary listing repository operator based 279 on a root OID administered by that operator, a listing sequence 280 number generated by that operator, a listing version number assigned 281 by that operator, and a file type indicator. 283 3.2 listingTitle 285 To: ietf-mime-direct@imc.org 287 Subject: Registration of text/directory MIME type listingTitle 289 Type name: listingTitle 291 Type purpose: To represent a real world title of a listed 292 schema unit or schema pak. 294 Type encoding: 8bit 296 Type valuetype: text, with the following syntax (specified using 297 the BNF in [RFC822]): 299 utf8-text = 1* 301 Type special notes: 303 This type MAY be multi-valued. 305 A language parameter MUST be used with this type. 307 A value of this type MAY contain local or native version numbers or 308 other version indicators for listed schema. Such schema version 309 information MUST be treated as opaque by implementors. 311 3.3 listingUse 313 To: ietf-mime-direct@imc.org 315 Subject: Registration of text/directory MIME type listingUse 317 Type name: listingUse 319 Type purpose: To represent a statement of intended use for a listing. 321 Type encoding: 8bit 323 Type valuetype: text, with the following syntax (specified using 324 the BNF in [RFC822]): 326 utf8-text = 1* 328 Type special notes: 330 This type MAY be multi-valued. 332 A language parameter MUST be used with this type. 334 A value of this type is an in-line text description of the intended 335 use of a listing and MAY include embedded CRLF characters. 337 3.4 specFile 339 To: ietf-mime-direct@imc.org 341 Subject: Registration of text/directory MIME type specFile 343 Type name: specFile 345 Type purpose: To represent a file name in the schema listing 346 repository for a schema unit content constructed 347 using an appropriate profile of [MIMEDIR]. 349 Type encoding: 8bit 351 Type valuetype: text, with the following syntax (specified using the 352 BNF in [RFC822]): 354 fname = 355 ; all [FILESYN] values except "meta-unit" and "0" 356 ; MAY be used to construct values 358 Type special notes: 360 When used in schema unit listings and schema unit listing requests, 361 this type MUST be single-valued. 363 When used in schema pak listings and schema pak listing requests, 364 this type MUST be multi-valued. 366 A language parameter MUST NOT be used with this type. 368 Currently, there are five [MIMEDIR] profiles defined for containing 369 schema unit content: [MIMELDAP], [MIMEWHOISPP], [MIMEWHOIS], 370 [MIMERWHOIS], and [MIMEXML]. Additional profiles may be defined in 371 other documents. Each of these profiles is identified by a sort 372 text string representative of the profile name. 374 3.5 relatedTo 376 To: ietf-mime-direct@imc.org 378 Subject: Registration of text/directory MIME type relatedTo 380 Type name: relatedTo 382 Type purpose: To represent an indication of a relationship of 383 a published listing or listing request with another 384 published listing or listing request. 386 Type encoding: 8bit 388 Type valuetype: text, with the following syntax (specified using the 389 BNF in [RFC822]): 391 related = md-filename *SPACE "$" *SPACE related-option 393 md-filename = 395 related-option = "obsoletes" / "obsoleted-by" / "updates" / 396 "inherits" / vendor-option 398 vendor-option = ("x-" / "X-") vendor-name "-" 399 vendor-specific-relationship 401 vendor-name = 1*TOKEN 403 vendor-specific-relationship = 1*TOKEN 405 TOKEN = 407 CHAR = 408 specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- 409 / "," / ";" / ":" / "\" / <"> ; string, to use 410 / "." / "[" / "]" ; within a word 412 <"> = 414 SPACE = 416 CRLF = CR LF 418 CR = 420 LF = 422 CTL = 424 Type special notes: 426 This type MAY be multi-valued. 428 If a listing is related to another listing, this type is REQUIRED, 429 otherwise the use of this type is OPTIONAL. 431 A language parameter MUST NOT be used with this type. 433 This type is used to indicate relationships between published 434 listings and listing requests as well as between one or more listing 435 requests being submitted for review in parallel. Examples of such 436 relationships include deprecation, revision, inheritance, and those 437 specific to a particular vendor. 439 3.6 contactLanguage 441 To: ietf-mime-direct@imc.org 443 Subject: Registration of text/directory MIME type contactLanguage 445 Type name: contactLanguage 447 Type purpose: To represent a language understood by the contact 448 person, organization, or role for a listing. 450 Type encoding: 8bit 452 Type valuetype: text, with the following syntax (specified using the 453 BNF in [RFC822]): 455 c-lang = 457 Type special notes: 459 This type MAY be multi-valued. 461 A language parameter MUST NOT be used with this type. 463 3.7 contactName 465 To: ietf-mime-direct@imc.org 467 Subject: Registration of text/directory MIME type contactName 469 Type name: contactName 471 Type purpose: To represent the name of the contact person, 472 organization, or role for a listing. 474 Type encoding: 8bit 476 Type valuetype: text, with the following syntax (specified using 477 the BNF in [RFC822]): 479 utf8-text = 1* 481 Type special notes: 483 This type MUST be single-valued. 485 A language parameter MUST NOT be used with this type. 487 3.8 contactEmail 489 To: ietf-mime-direct@imc.org 491 Subject: Registration of text/directory MIME type contactEmail 493 Type name: contactEmail 495 Type purpose: To represent the electronic mail address of the 496 contact person, organization, or role for a listing. 498 Type encoding: 8bit 500 Type valuetype: text, with the following syntax (specified using the 501 BNF in [RFC822]): 503 c-email = local-part "@" domain-part 505 domain-part = sub-domain *("." sub-domain) 507 sub-domain = 1* 509 CHAR = 511 specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- 512 / "," / ";" / ":" / "\" / <"> ; string, to use 513 / "." / "[" / "]" ; within a word 515 <"> = 517 SPACE = 519 CRLF = CR LF 521 CR = 523 LF = 525 CTL = 527 Type special notes: 529 This type MUST be single-valued. 531 A language parameter MUST NOT be used with this type. 533 3.9 contactPhone 535 To: ietf-mime-direct@imc.org 537 Subject: Registration of text/directory MIME type contactPhone 539 Type name: contactPhone 541 Type purpose: To represent the voice telephone number of the 542 contact person, organization, or role for a listing. 544 Type encoding: 8bit 546 Type valuetype: text, with the following syntax (specified using the 547 BNF in [RFC822]): 549 c-phone = 1* 550 ; MUST use full international form (e.g., +1 908 582 2409) 551 ; as specified in [E.123] 553 CHAR = 555 CRLF = CR LF 557 CR = 559 LF = 561 CTL = 563 Type special notes: 565 This type MUST be single-valued. 567 A language parameter MUST NOT be used with this type. 569 3.10 contactAddress 571 To: ietf-mime-direct@imc.org 573 Subject: Registration of text/directory MIME type contactAddress 575 Type name: contactAddress 577 Type purpose: To represent the postal address of the 578 contact person, organization, or role for a listing. 580 Type encoding: 8bit 582 Type valuetype: text, with the following syntax (specified using the 583 BNF in [RFC822]): 585 c-addr = postal-string *5(*SPACE "$" *SPACE postal-string) 587 postal-string = 1* 590 SPACE = 592 Type special notes: 594 This type MUST be single-valued. 596 A language parameter MUST NOT be used with this type. 598 3.11 authLanguage 599 To: ietf-mime-direct@imc.org 601 Subject: Registration of text/directory MIME type authLanguage 603 Type name: authLanguage 605 Type purpose: To represent the language understood by the listing 606 authority contact for a listing. 608 Type encoding: 8bit 610 Type valuetype: text, with the following syntax (specified using the 611 BNF in [RFC822]): 613 lac-lang = 615 Type special notes: 617 This type MAY be multi-valued 619 A language paramter MUST NOT be used with this type. 621 3.12 authName 623 To: ietf-mime-direct@imc.org 625 Subject: Registration of text/directory MIME type authName 627 Type name: authName 629 Type purpose: To represent the name of the listing authority contact 630 for a listing. 632 Type encoding: 8bit 634 Type valuetype: text, with the following syntax (specified using 635 the BNF in [RFC822]): 637 utf8-text = 1* 639 Type special notes: 641 This type MUST be single-valued. 643 A language parameter MUST NOT be used with this type. 645 The value of this type MAY be identical to the value of the 646 'contactName' type defined above. 648 3.13 authEmail 650 To: ietf-mime-direct@imc.org 652 Subject: Registration of text/directory MIME type authEmail 654 Type name: authEmail 656 Type purpose: To represent the electronic mail address of the listing 657 authority contact for a listing. 659 Type encoding: 8bit 661 Type valuetype: text, with the following syntax (specified using the 662 BNF in [RFC822]): 664 c-email = local-part "@" domain-part 666 domain-part = sub-domain *("." sub-domain) 668 sub-domain = 1* 670 CHAR = 672 specials = "(" / ")" / "<" / ">" / "@" ; MUST be in quoted- 673 / "," / ";" / ":" / "\" / <"> ; string, to use 674 / "." / "[" / "]" ; within a word 676 <"> = 678 SPACE = 680 CRLF = CR LF 682 CR = 684 LF = 686 CTL = 688 Type special notes: 690 This type MUST be single-valued. 692 A language parameter MUST NOT be used with this type. 694 The value of this type MAY be identical to the value of the 695 'contactEmail' type defined above. 697 3.14 authPhone 699 To: ietf-mime-direct@imc.org 701 Subject: Registration of text/directory MIME type authPhone 703 Type name: authPhone 705 Type purpose: To represent the voice telephone number of the listing 706 authority contact for a listing. 708 Type encoding: 8bit 710 Type valuetype: text, with the following syntax (specified using the 711 BNF in [RFC822]): 713 lac-phone = 1* 714 ; MUST use full international form (e.g., +1 908 582 2409) 715 ; as specified in [E.123] 717 CHAR = 719 CRLF = CR LF 721 CR = 723 LF = 725 CTL = 727 Type special notes: 729 This type MUST be single-valued. 731 A language parameter MUST NOT be used with this type. 733 The value of this type MAY be identical to the value of the 734 'contactPhone' type defined above. 736 3.15 authAddress 738 To: ietf-mime-direct@imc.org 740 Subject: Registration of text/directory MIME type authAddress 742 Type name: authAddress 744 Type purpose: To represent the postal address of the listing 745 authority contact for a listing. 747 Type encoding: 8bit 749 Type valuetype: text, with the following syntax (specified using the 750 BNF in [RFC822]): 752 lac-addr = postal-string *5(*SPACE "$" *SPACE postal-string) 754 postal-string = 1* 757 SPACE = 759 Type special notes: 761 This type MUST be single-valued. 763 A language parameter MUST NOT be used with this type. 765 The value of this type MAY be identical to the value of the 766 'contactAddr' type defined above. 768 3.16 specURL 770 To: ietf-mime-direct@imc.org 772 Subject: Registration of text/directory MIME type specURL 774 Type name: specURL 776 Type purpose: To represent a URL referring to a single schema 777 unit content file. 779 Type encoding: 8bit 781 Type valuetype: uri, formatted as a URL [RFC1738]. 783 Type special notes: 785 This type MAY be multi-valued. 787 A language parameter MUST NOT be used with this type. 789 3.17 security 791 To: ietf-mime-direct@imc.org 792 Subject: Registration of text/directory MIME type security 794 Type name: security 796 Type purpose: To represent a description of security considerations 797 for a single schema unit or schema pak. 799 Type encoding: 8bit 801 Type valuetype: text, with the following syntax (specified using 802 the BNF in [RFC822]): 804 utf8-text = 1* 806 Type special notes: 808 This type MAY be multi-valued if it is used within a schema unit 809 listing metadata file. 811 This type MUST have at least two values if present in a schema pak 812 listing file. One of these values MUST be a security considerations 813 description for the shcema pak itself. The other value MUST consist 814 of the following text: 816 Users of this schema pak listing should read the security type 817 values contained in the metadata file associated with each schema 818 unit content file referenced by a pakMember type value. 820 A language parameter MUST be used with this type. 822 A value of this type is an in-line text description of security 823 considerations and MAY include embedded CRLF characters. 825 3.18 created 827 To: ietf-mime-direct@imc.org 829 Subject: Registration of text/directory MIME type created 831 Type name: created 833 Type purpose: To represent the date and time at which a listing 834 was published. 836 Type encoding: 8bit 838 Type valuetype: date-time, with the following syntax (specified using 839 the BNF in [RFC822]): 841 created = date "T" time "Z" 843 date = 4DIGIT "-" 2DIGIT "-" 2DIGIT 844 ; year-month-day 845 ; e.g., 1997-08-27 847 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT 848 ; hh:mm:ss 849 ; e.g., 00:00:00 thru 23:59:59 850 ; MUST be based on GMT 852 DIGIT = 854 Type special notes: 856 This type MUST be single-valued. 858 A language parameter MUST NOT be used with this type. 860 3.19 moreInfo 862 To: ietf-mime-direct@imc.org 864 Subject: Registration of text/directory MIME type moreInfo 866 Type name: moreInfo 868 Type purpose: To represent a labeled reference to external 869 content (not stored in the schema listing repository) 870 related to a listing. 872 Type encoding: 8bit 874 Type valuetype: text, with the following syntax (specified using the 875 BNF in [RFC822]): 877 more = uri *SPACE "(" label ")" 878 ; MAY be multi-valued or single-valued 880 uri = 881 ; in this case the URI is constrained to 882 ; be a URL as specified in [RFC1738] 884 label = option [*SPACE "$" *SPACE checksum] 885 ; only one option is allowed per instance 886 ; of this multi-valued metadata element 888 option = "opaque-schema" / "copyright" / "licensing" / "general" 889 / "image" 890 ; this set of options is intended for use in the initial release 891 ; of the schema listing service additional options may be 892 ; defined in other documents 893 ; "opaque-schema" signifies that a file containing 894 ; a [MIMEDIR]-based schema unit content not currently 895 ; supported by the listing service or other syntax 896 ; specification for a schema unit is being referenced 898 checksum = > 901 Type special notes: 903 This type MAY be multi-valued. 905 A language parameter MUST be used with this type. 907 The use of this type is REQUIRED if a schema writer wishes to 908 include references to external content related to a listing. 909 Otherwise, this type MUST NOT be used in forming listing requests or 910 published listings. The rationale for including these external 911 references MAY be related to extensive copyright or right-to-use 912 statements, a requirement external to the schema listing service for 913 vendor branding of a listed schema, or a schema specification of a 914 form not expressable using a [MIMEDIR] profile currently supported 915 by the schema listing service. 917 3.20 caveat 919 To: ietf-mime-direct@imc.org 921 Subject: Registration of text/directory MIME type caveat 923 Type name: caveat 925 Type purpose: To represent a caveat explaining that content obtained 926 by following external references to information not stored in the 927 schema listing repository is outside of the control of the 928 repository. 930 Type encoding: 8bit 932 Type valuetype: text, consisting of the following in-line text value: 934 Information obtained by following external content 935 references expressed using the moreInfo type are 936 outside of the control of the schema listing service 937 operators. Users of this information should be aware 938 that it is possible for this information to change 939 after the referencing listing has been 940 published. 942 Type special notes: 944 This type MAY be multi-valued. 946 A language parameter MUST be used with this type. 948 The use of this type is REQUIRED if a schema writer wishes to 949 include references to external content related to a listing. 950 Otherwise, this type MUST NOT be used in forming listing requests or 951 published listings. 953 3.21 listingComments 955 To: ietf-mime-direct@imc.org 957 Subject: Registration of text/directory MIME type listingComments 959 Type name: listingComments 961 Type purpose: To represent comments which will be attached to 962 a listing. 964 Type encoding: 8bit 966 Type valuetype: text, with the following syntax (specified using the 967 BNF in [RFC822]): 969 utf8-text = 1* 971 Type special notes: 973 This type MAY be multi-valued. 975 A language parameter MUST be used with this type. 977 The use of this type is REQUIRED if during review of a listing 978 request, the primary listing repository operator is asked by the 979 reviewers to include particular comments or generic caveats with a 980 listing prior to publication. 982 Values of this type are in-line text comments or generic caveats 983 associated with a schema listing and MAY include embedded CRLF 984 characters. 986 3.22 schemaPak 988 To: ietf-mime-direct@imc.org 990 Subject: Registration of text/directory MIME type schemaPak 992 Type name: schemaPak 994 Type purpose: To represent a reference to a schema pak listing 995 of which a schema unit content file is a member. 997 Type encoding: 8bit 999 Type valuetype: text, with the following syntax (specified using the 1000 BNF in [RFC822]): 1002 pak-ref = uri *SPACE "(" label ")" ; MAY be multi-valued or 1003 ; single-valued 1005 uri = ; in this case the URI is 1006 ; constrained to be a URL as 1007 ; specified in [RFC1738] 1008 ; and corresponds to a 1009 ; pak listing file 1011 label = "ldap" / "whois++" / "rwhois" / "whois" / "xml" 1013 Type Special Notes: 1015 Only one ; in this case the URI is 1045 ; constrained to be a URL as 1046 ; specified in [RFC1738] 1047 ; and refers to a schema 1048 ; unit content file 1050 label = "ldap" / "whois++" / "rwhois" / "whois" / "xml" 1052 Type Special Notes: 1054 A schema pak MUST consist of more than one schema unit. Therefore, 1055 this element MUST be multi-valued 1057 A schema pak listing MUST only contain member references for a 1058 single protocol. Therefore, only one