idnits 2.17.1 draft-ietf-asid-mime-centroid-00.txt: ** The Abstract section seems to be numbered 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-20) 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 == The page length should not exceed 58 lines per page, but there was 7 longer pages, the longest (page 2) being 59 lines 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.) ** There are 63 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 10 has weird spacing: '...fts are worki...' == Line 11 has weird spacing: '...ments of the ...' == Line 12 has weird spacing: '...t other group...' == Line 16 has weird spacing: '...and may be ...' == Line 20 has weird spacing: '...atus of any ...' == (58 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? 'MIME-DIR' on line 120 looks like a reference -- Missing reference section? 'RFC-822' on line 313 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Tim Howes 3 INTERNET DRAFT Mark Smith 4 draft-ietf-asid-mime-centroid-00.txt University of Michigan 6 An Application/Directory MIME Content-Type Centroid Profile 8 1. Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working docu- 11 ments of the Internet Engineering Task Force (IETF), its areas, and its 12 working groups. Note that other groups may also distribute working 13 documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet- Drafts as reference material 18 or to cite them other than as ``work in progress.'' 20 To learn the current status of any Internet-Draft, please check the 21 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 2. Abstract 28 This memo defines an directory profile for carrying centroid or other 29 indexing information pertaining to one or more directory entities within 30 an application/directory MIME Content-Type. The profile consists of type 31 definitions, what the types are allowed to contain, and rules for their 32 use and interpretation within the application/directory body part. 34 The scheme is fairly general and with a few extensions could be used to 35 handle directory modification information pertaining to a single entity, 36 or sets of modifications pertaining to many entries, in addition to 37 updates to centroid or other index information that apply to many enti- 38 ties. 40 3. Overview 42 The application/directory MIME Content-Type defined in [MIME-DIR] is 43 used for representing directory information in MIME format. It defines a 44 general framework for carrying "type: value"-style information in the 45 body part, but does not define specific types or values. This document 46 defines a profile containing the types and corresponding value formats 47 Expires July 1996 INTERNET DRAFT 49 for representing centroid or other directory indexing information. 51 The goal of this scheme is to represent changes to directory information 52 to support indexing. In this scheme, a directory server might send a 53 MIME message containing centroid or other indexing information to one or 54 more other servers providing wide-area search service. The wide-area 55 search server can use the index information to provide efficient 56 searches over many servers, contacting only those servers likely to be 57 able to answer a query. 59 The scheme described here defines types and profiles for representing 60 changes to centroid or other indexing information within an 61 application/directory MIME content type. Types are defined for 62 representing the type of update and the specific update to be performed. 64 4. The Centroid Profile 66 This profile is used to represent a change to a directory centroid or 67 other collection of index information. The profile is defined as fol- 68 lows, using the profile registration template from Section 8 of [MIME- 69 DIR]. 71 4.1. Centroid Profile Definition 73 To: ietf-mime-direct@umich.edu 74 Subject: Registration of application/directory MIME profile centroid 76 Profile name: centroid 78 Profile purpose: to hold information about a change to a centroid or 79 other collection of index information 81 Profile types: time, changetype, indextype, indexparm 83 Profile special notes: 85 The types used in the centroid profile must adhere to a specific 86 ordering. If given, the "time" line must come first, followed by 87 one or more "changetype" lines. The ordering is given by the fol- 88 lowing grammar. 90 changelist := changelist changes | changes 92 changes := [ time CRLF ] [ indextype CRLF ] 93 [ indexparm CRLF ] 1*( change CRLF ) 95 time := "time" ":" date-time ; from Section 5.1 of [RFC-822] (see below) 97 Expires July 1996 INTERNET DRAFT 99 indextype := "indextype" ":" ( "word" / "value" / x-token ) 101 indexparm := "indexparm" ":" ( "weights" / x-token ) 103 change := "changetype" ":" changeinfo 105 changeinfo := "add" CRLF mods 106 / "delete" CRLF [ mods ] 107 / "replace" CRLF mods 109 mods := content ; from Section 5 of [MIME-DIR] 111 Changes to multiple index entities may be included in the same 112 MIME message by specifying multiple application/directory body 113 parts wrapped inside a multipart/parallel body part. 115 The name and source of the centroid can optionally be taken from 116 the application/directory MIME Content-Type "name" and "source" 117 header parameters. 119 The associated type definitions follow, using the type registration tem- 120 plate from Section 9 of [MIME-DIR]. 122 4.2. Time Type Definition 124 To: ietf-mime-direct@umich.edu 125 Subject: Registration of application/directory MIME type time 127 Type name: time 129 Type purpose: to hold a time. 131 Type encoding: a string containing a time as defined in section 5.1 132 of [RFC-822] for "date-time". 134 4.3. Changetype Type Definition 136 To: ietf-mime-direct@umich.edu 137 Subject: Registration of application/directory MIME type changetype 139 Type name: changetype 141 Type purpose: to hold the type of change to make to the named direc- 142 tory entity 144 Type encoding: one of the strings "add", "delete", or "replace". 146 Type special notes: 148 Expires July 1996 INTERNET DRAFT 150 The changetypes have the following meanings, which pertain to sub- 151 sequent information in the application/directory body part. Also 152 given are the subsequent information the body part must contain to 153 accomplish the change. 155 add Add additional index information, or create the informa- 156 tion if none yet exists. The "changetype: add" line is 157 followed by one or more "type: value" lines indicating 158 the information to add. 160 delete Delete existing index information. If the "changetype: 161 delete" line is not followed by any additional parame- 162 ters (i.e., the end of the body part, or the next change 163 record comes next), the entire set of index information 164 is to be deleted. Otherwise, additional "type: value" 165 lines follow indicating the index values to be removed 166 from the index information. 168 replace Change an existing set of index information by replacing 169 any information currently in the index, or creating a 170 new index if none yet exists. The "changetype: replace" 171 line is followed by one or more "type: value" lines 172 indicating the information that should be placed in the 173 index in place of any existing information with the same 174 type name. Types that are not mentioned are not changed. 176 4.4. Indextype Type Definition 178 To: ietf-mime-direct@umich.edu 179 Subject: Registration of application/directory MIME type indextype 181 Type name: indextype 183 Type purpose: to hold the type of index information contained in the 184 body part 186 Type encoding: a string defined as follows. 188 indextype := x-token / "word" / "value" 190 x-token := 193 The "x-token" indextype construct is to be used for bilaterally 194 agreed upon types of index information. 196 Type special notes: 198 Expires July 1996 INTERNET DRAFT 200 The "indextype" line is used to indicate the type of index infor- 201 mation contained in the body part. A value of "word" indicates 202 that values are LWSP-delimited words. A value of "value" indicates 203 that values are entire values. Future versions of this document 204 may define other values for this parameter. 206 4.5. Indexparm Type Definition 208 To: ietf-mime-direct@umich.edu 209 Subject: Registration of application/directory MIME type indexparm 211 Type name: indexparm 213 Type purpose: to hold additional parameters describing the type of 214 index information contained in the body part. 216 Type encoding: a string defined as follows. 218 indexparm := x-token / "weights" 220 x-token := 223 The "x-token" indexparm construct is to be used for bilaterally agree 224 upon types of index information. 226 Type special notes: 228 The "indexparm" line is used to indicate any additional informa- 229 tion transmitted with the index. A value of "weights" indicates 230 that values are accompanied by weights indicating their relative 231 frequencies in the source data. A future version of this document 232 may define additional values of this parameter and will define the 233 use of the "weights" parameter in more detail. 235 5. Centroid Examples 237 The following example illustrates simple use of the 238 application/directory MIME Content-Type with the "centroid" profile, for 239 value-based index information. Note the use of the "changetype: add" 240 line to indicate that the index information is an update to existing 241 information. 243 From: Whomever 244 To: Someone 245 Subject: whatever 246 MIME-Version: 1.0 247 Message-ID: 249 Expires July 1996 INTERNET DRAFT 251 Content-Type: application/directory; 252 profile="centroid"; 253 source="ldap://ldap.itd.umich.edu/o=U%20of%20M" 254 Content-ID: 256 time: Wed, 10 Jan 1996 09:45:38 EST 257 indextype: value 258 changetype: add 259 cn: Babs Jensen 260 cn: Barbara Jensen 261 cn: Bjorn Jensen 262 cn: Bob Jensen 264 The next example illustrates the use of the "centroid" profile for 265 word-based index information. Note the use of the "defaulttype" parame- 266 ter to avoid duplicating type names, and the "changetype: replace" line 267 to indicate the index information should be replaced, instead of 268 updated. 270 From: Whomever 271 To: Someone 272 Subject: whatever 273 MIME-Version: 1.0 274 Message-ID: 275 Content-Type: application/directory; 276 profile="centroid"; 277 source="ldap://ldap.itd.umich.edu/o=U%20of%20M"; 278 defaulttype="cn" 279 Content-ID: 281 time: Wed, 10 Jan 1996 09:45:38 EST 282 indextype: value 283 changetype: replace 284 : Jensen 285 : Babs 286 : Barbara 287 : Bjorn 288 : Bob 290 6. Security Considerations 292 Internet mail is subject to many well known security attacks, including 293 monitoring, replay, and forgery. Applications should also be aware that 294 there may be privacy and security implications associated with releasing 295 index information. 297 Expires July 1996 INTERNET DRAFT 299 7. Acknowledgements 301 This material is based upon work supported by the National Science Foun- 302 dation under Grant No. NCR-9416667. 304 8. Bibliography 306 [RFC-1777]Yeong, W., Howes, T., Kille, S., "Lightweight Directory Access 307 Protocol", Request for Comment (RFC) 1777, March 1995. 309 [RFC-1778]Howes, T., Kille, S., Yeong, W., Robbins, C.J., "The String 310 Representation of Standard Attribute Syntaxes", Request for 311 Comment (RFC) 1778, March 1995. 313 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 314 Messages", STD 11, RFC 822, August 1982. 316 [RFC-1521]Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail 317 Extensions) Part One: Mechanisms for Specifying and Describing 318 the Format of Internet Message Bodies", RFC 1521, September 319 1993. 321 [RFC-1522]Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 322 Two: Message Header Extensions for Non-ASCII Text", RFC 1522, 323 September 1993. 325 [x500] "Information Processing Systems - Open Systems Interconnection 326 - The Directory: Overview of Concepts, Models and Services", 327 ISO/IEC JTC 1/SC21, International Standard 9594-1, 1988. 329 [RFC-1835]Deutsch, P., Schoultz, R., Faltstrom, P., Weider, C., "Archi- 330 tecture of the WHOIS++ service", August 1995. 332 [MIME-DIR]Howes, T., Smith, M., "A MIME Content-Type for Directory 333 Information," Internet-Draft draft-ietf-asid-mime-direct- 334 01.txt, January, 1996. 336 [RFC-1738]Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource 337 Locators (URL)", RFC 1738, December 1994. 339 9. Author's Address 341 Tim Howes 342 University of Michigan 343 535 W William St. 344 Ann Arbor, MI 48103-4943 345 USA 346 +1 313 747-4454 348 Expires July 1996 INTERNET DRAFT 350 tim@umich.edu 352 Mark Smith 353 University of Michigan 354 535 W William St. 355 Ann Arbor, MI 48103-4943 356 USA 357 +1 313 764-2277 358 mcs@umich.edu