idnits 2.17.1 draft-ietf-acap-option-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (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 (April 2000) is 8771 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Hole 2 Internet Draft: ACAP A. Melnikov 3 MessagingDirect Ltd. 4 Document: draft-ietf-acap-option-03.txt April 2000 5 Expires in 6 months 7 ACAP Application Options Dataset Class 9 Status of this memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 28 The list of Internet-Draft Shadow Directories can be accessed at 29 . 31 A version of this draft document is intended for submission to the 32 RFC editor as a Proposed Standard for the Internet Community. 33 Discussion and suggestions for improvement are requested. This 34 document will expire six months after publication. Distribution of 35 this draft is unlimited. 37 Copyright Notice 39 Copyright (C) The Internet Society 2000. All Rights Reserved. 41 1. Introduction 43 The Application Configuration Access Protocol (ACAP) is designed to 44 support remote storage and access of application option, 45 configuration and preference information. The generalized form of 46 this runtime configuration is called "options". Options consist of 47 any type of structured or unstructured data that an application 48 requires to operate in a user specific manner. 50 Storage of application options in an ACAP server substantially 51 solves the "kiosk user" problem for applications -- serial use of a 52 single machine by multiple users. It also solves the "nomadic 53 user" problem -- use of more than one machine on a regular basis by 54 a single user. 56 The specification defines the "option" dataset class for use with 57 ACAP. 59 2. Conventions used in this document 61 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 62 in this document are to be interpreted as described in [KEYWORDS]. 64 The attribute syntax specifications use the Augmented Backus-Naur 65 Form (ABNF) notation as specified in [ABNF]. 67 3. ACAP personal options 69 3.1. ACAP option representation 71 Individual options are represented as ACAP entries in option 72 datasets. The name of the entry, as defined by the "entry" 73 attribute for the entry, is the name of option. 75 3.2. Scalar options 77 Scalar options are ACAP entries that contain simple (unstructured) 78 data. The "option.value" attribute of the entry contains the data 79 for the option. The value can be single or multivalued. 81 Following is an example of a single and multivalued scalar option: 83 color.preferred 84 entry = "color.preferred" 85 option.value = "blue" 86 color.list 87 entry = "color.list" 88 option.value = ("red" "green" "blue" "cyan" "black") 90 Scalar options that are intended to be used by multiple applica- 91 tions should be registered as defined in section 4.4. 93 3.3. Structured options 95 Structured options are ACAP entries that contain multiple related 96 items of data in a single option. Data for the option is contained 97 in multiple named attributes collectively called "field 98 attributes". Each field attribute can be single or multivalued. 100 Following is an example of a structured option: 102 color.definition 103 entry = "color.definition" 104 option.color.definition.name = "blue" 105 option.color.definition.rgb = ("blue=255" "red=0" "green=0") 106 option.color.definition.index = "66" 108 By definition, structured options are application specific. While 109 the content of the field attributes can be obtained by any applica- 110 tion, it's intended use is open to interpretation by the applica- 111 tion. 113 3.4. ACAP option hierarchy 115 Option sets MAY be represented using ACAP hierarchy. Any entry in 116 an option dataset can also be a hierarchy node by setting the "sub- 117 dataset" attribute. Applications can model arbitrarily structured 118 configuration information using hierarchical datasets containing 119 scalar or structured options. An option subdataset of scalar 120 options models an associative list. An option subdataset of struc- 121 tured options models an array of structures. 123 3.5. ACAP option attribute formal syntax 125 The naming conventions for option entry attributes is defined by 126 the following ABNF. 128 option-value-attr = scalar-option-attr / structured-option-attr 130 scalar-option-attr = "option.value" 132 structured-option-attr = "option." name-component 133 1*("." name-component) 135 4. ACAP option namespace 137 The general ACAP namespace is organized to promote inheritance 138 between site, host, group, and user specific configuration informa- 139 tion, as defined in [ACAP]. It defines a "site", "group", "host", 140 and "user" second level hierarchy. The option dataset defines a 141 third level of hierarchy that promotes inheritance from second 142 level datasets, and isolates user and application specific 143 instances of configuration information. 145 4.1. ACAP "/option" dataset class 147 The dataset class whose name is "/option" is assumed to contain 148 option datasets as defined in this specification. 150 4.2. Third level option datasets 152 Third level option datasets break the option namespace into generic 153 and application specific option sets. This serves two purposes: 154 to promote the creation and inheritance of common options between 155 applications, and isolation of application specific configuration 156 from other applications. 158 4.2.1. The "vendor" option namespace 160 The "vendor" option namespace is a set of datasets, each named in 161 the form "vendor.", where "" is the name 162 of a specific application or application vendor. 164 The entries in the vendor namespace enumerate the applications that 165 make use of ACAP option storage at that level. Each vendor dataset 166 contains option entries and/or subdatasets for a specific vendor 167 applications. All options not in the "standard" namespace MUST be 168 in one of the "vendor" option namespaces. 170 The "vendor-name" for an application or vendor MUST be registered 171 with IANA according to the rules in section 5.1. The "ven- 172 dor.x-" namespace is reserved for temporary use by 173 vendors during product development, or for local applications that 174 are not generally distributed. 176 Vendors are free to suballocate their namespace as they see fit. 177 For example, a vendor may chose to store options for the various 178 applications that it produces in subdatasets underneath their ven- 179 dor namespace. For example, the CoolStuff software company may 180 chose to organize the option namespace for their software products 181 like 183 vendor.CoolStuff.caltool 184 vendor.CoolStuff.webtool 185 vendor.CoolStuff.mailtool 187 rather than try to register their application names as a vendor- 188 name in the vendor namespace. 190 4.2.2. The "standard" option namespace 192 The "standard" option namespace is a dataset named "standard" that 193 contains option entries that are generally applicable to a number 194 of applications. The namespace is reserved for shared options that 195 do not meet the requirements for a separate ACAP dataset class. 197 The standard option namespace is further partitioned into "standard 198 option classes" where option names are of the form ".". Standard option classes are 200 associated with a class of applications, e.g. mail user agents. The 201 "" is a registered string that 202 uniquely identifies the option class, e.g. "mua". 204 This document defines two standard option class prefixes - "common" 205 and "X". The "common" standard option class contains options that 206 are generally applicable to a large number of application classes. 207 For example, a default font or window background color. The "X" 208 namespace is reserved for temporary use by software developers dur- 209 ing product development. 211 Following are some examples of the standard option namespace: 213 standard/common.default.font 214 standard/common.default.color.background 215 standard/X.test-option 217 Option classes and names in the "standard" option namespace MUST be 218 registered with IANA according to the rules in section 5.2. Ven- 219 dors MUST NOT use the temporary namespace in products that are gen- 220 erally distributed. 222 4.3. Example option namespace 224 The following example demonstrates how the "standard" and "vendor" 225 namespaces isolate application specific and standard configuration 226 within the standard ACAP dataset namespace hierarchy. 228 /option/ 229 site/ 230 standard/ 231 vendor./ 232 vendor./ 233 ... 234 ... 235 host/ 236 / 237 standard/ 238 vendor./ 239 vendor./ 240 ... 241 ... 242 / 243 ... 244 ... 245 group/ 246 / 247 standard/ 248 vendor./ 249 vendor./ 250 ... 251 ... 252 / 253 ... 254 ... 255 user/ 256 / 257 standard/ 258 vendor./ 259 vendor./ 260 ... 261 ... 262 / 263 ... 264 ... 266 4.4. Formal Syntax for the Option Dataset Namespace 268 The naming conventions for the option dataset are defined by the 269 standard ABNF in [ACAP] for dataset namespaces, constrained and/or 270 extended by the following ABNF. 272 dname-component = 1*UTF8-CHAR 273 ;; MUST NOT begin with "." or contain "/" 275 name-component = 1*UTF8-CHAR 276 ;; MUST NOT contain ".", "/", "%", or "*" 278 option-dataset = "/option/" owner 280 option-component = standard-component / vendor-component 282 owner = owner-site / owner-host / owner-group / 283 owner-user / "~/" option-component 285 owner-group = "group/" dname-component "/" option-component 287 owner-host = "host/" dname-component "/" option-component 289 owner-site = "site/" option-component 291 owner-user = "user/" dname-component "/" option-component 293 standard-component = "standard/" standard-option-class "." 294 name-component 295 ;; The name-component MUST BE an IANA registered 296 ;; option name under the option class. 298 standard-option-class = "common" / "X" / name-component 299 ;; The name-component MUST BE an IANA registered 300 ;; option class prefix. 302 vendor-component = vendor-name "/" dname-component 304 vendor-name = vendor-token *("." name-component) 306 vendor-token = "vendor." name-component 307 ;; The name-component is the name of the 308 ;; application or vendor organization to which 309 ;; the options belong. 311 5. Namespace registration procedures 313 Some portions of the ACAP option namespace are designed to be 314 extensible within the standard. The goals for extensibility 315 include: (1) minimal process to extend the namespace within the 316 standard, (2) promote interoperability within the namespace, and 317 (3) support experimentation and development within the namespace. 319 To support these requirements, the ACAP Option dataset draws on the 320 recommendations for registration policies and procedures outlined 321 in [IANA-CONSIDERATIONS]. 323 5.1. Registering vendor names 325 The "vendor" option namespace is specifically designed to support 326 delegation of authority to individual organizations. The goal is 327 to provide a completely independent namespace for each application 328 vendor. The requirement is that each vendor namespace be uniquely 329 associated with one and only one vendor or product. 331 The "vendor" option namespace uses the identical registry as the 332 "vendor" dataset class defined in [ACAP]. Organizations that wish 333 to register a vendor name for the option namespace MUST follow the 334 procedures outlined in [ACAP]. 336 5.2. Registering standard options 338 The "standard" option namespace requires standardization procedures 339 for two different types of object: standard option class prefixes 340 and standard option names. 342 Standard option class prefixes MUST be registered with IANA. New 343 option class proposals MUST be confirmed using IETF Consensus, pri- 344 marily through consultation on the ACAP implementors mailing list. 345 Registration of an option class MUST include a review contact that 346 is responsible for approving registrations for option names regis- 347 tered in the option class. Registrations MUST provide the follow- 348 ing information when requesting a new standard option class prefix. 350 To: iana@iana.org 351 Subject: Registration of ACAP standard option class 353 Requested standard option class name: 354 Requested standard option class prefix: 355 Requested standard option class short description: 357 Approval contact: name, address, e-mail address, phone number 358 # as many contacts as appropriate - must be at least one 360 Standard option names MUST be registered with IANA using the Hier- 361 archical Allocation model described in [IANA-CONSIDERATIONS]. All 362 proposals MUST be reviewed and passed by the IANA registered con- 363 tact for the option class prior to submission. Discussion on new 364 option name proposals on the ACAP implementors mailing list is 365 strongly encouraged. Registrations MUST provide the following 366 information when requesting a new standard option name. 368 To: iana@iana.org 369 Subject: Registration of ACAP standard option 371 Containing option class: 372 Requested option name: . 373 Option short description: 374 Value semantics: # any specific semantic restrictions placed 375 on the value of the option, e.g. URL, 376 integer, ... 377 Value default: # a recommended default value for the option 379 6. Recommendations for standardization 381 There are no absolute rules for when to register a set of standard 382 options vs. defining a new dataset class. In general, one can 383 always register a standard option class and a set of option names 384 under that class. In some cases, it MAY be appropriate to define a 385 new dataset class instead of registering a set of standard options. 387 The key distinguishing feature of a dataset class definition is its 388 documentation requirements. Dataset class definitions specify the 389 semantic relationships in the dataset class. The semantic rela- 390 tionships between subdatasets, entries and attributes are fully 391 defined and part of the standard. 393 If a set of standard options has any of the following characteris- 394 tics, then it should be considered a candidate for a new dataset 395 class. 397 1. The option set consists of a list (array) of identically struc- 398 tured options. Proper representation of option sets of this type 399 require a subdataset. This is not prohibited by the standard 400 option namespace, but the list relationship of the options needs to 401 be documented. This makes it appropriate for a new dataset class. 403 2. Many or all of the options are semantically related or dependent 404 on one another. Individual options are incomplete, or not useful 405 unless evaluated in the context of the other options in the class. 406 The relationship or dependencies cannot be documented by individual 407 option registrations. 409 3. The set of options are interpreted by applications with addi- 410 tional semantic rules that apply to the set of options, and cannot 411 be documented in the registration information for individual stan- 412 dard options. 414 In summary, any standard option set that has semantic relationships 415 beyond a single option value is a candidate for a new dataset class 416 definition. Standard option sets SHOULD NOT be defined that have 417 additional semantic rules outside those of the individual options. 418 Standard option sets that acquire additional semantics over a 419 period of time, SHOULD be redefined as a dataset class using the 420 procedures and format outlined in [ACAP]. 422 Note that these considerations apply only to options in the "stan- 423 dard" option namespace. Semantic relationships in the vendor 424 namespace are at the discretion of the vendor and are not consid- 425 ered part of the extended standardization content of the ACAP 426 option namespace. 428 7. Security Considerations 430 It is important to make sure that access controls are set correctly 431 on personal options. Sensitive configuration information, includ- 432 ing application security information, should not be exposed to 433 other users without an explicit request by the user. 435 This specification does not address storing private certificates 436 and other security information in the option namespace. This may 437 be added to a future version of this specification when more exper- 438 imentation has been done. 440 8. Acknowledgments 442 Many thanks to the following people who have contributed to devel- 443 opment of the option dataset class specification: Jack DeWinter, 444 Rob Earhart, Ned Freed, Randy Gellens, John Meyers, Chris Newman, 445 Lyndon Nerenberg, John-Paul Sicotte, Matt Wall and other partici- 446 pants of the IETF ACAP working group. 448 9. References 450 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifi- 451 cations: ABNF", RFC 2234, November 1997 453 455 [ACAP] Newman, C., Myers, J. G., "Application Configuration Access 456 Protocol", RFC 2244, November 1997. 458 460 [IANA-CONSIDERATIONS] Thomas Narten, Harald Tveit Alvestrand, 461 "Guidelines for Writing an IANA Considerations Section in RFCs", 462 RFC 2434, October 1998. 464 466 [KEYWORDS] Bradner, S., "Key words for use in RFC to Indicate 467 Requirement Levels", RFC 2119, March 1997. 469 471 10. Authors' Addresses 473 Steve Hole 474 mailto:Steve.Hole@messagingdirect.com 476 Alexey Melnikov 477 mailto:Alexey.Melnikov@messagingdirect.com 479 MessagingDirect Ltd. 480 900 10117 - Jasper Ave. 481 Edmonton, Alberta, T5J 1W8, CANADA 483 11. Full Copyright Statement 485 Copyright (C) The Internet Society 2000. All Rights Reserved. 487 This document and translations of it may be copied and furnished to 488 others, and derivative works that comment on or otherwise explain 489 it or assist in its implementation may be prepared, copied, pub- 490 lished and distributed, in whole or in part, without restriction of 491 any kind, provided that the above copyright notice and this para- 492 graph are included on all such copies and derivative works. How- 493 ever, this document itself may not be modified in any way, such as 494 by removing the copyright notice or references to the Internet 495 Society or other Internet organizations, except as needed for the 496 purpose of developing Internet standards in which case the proce- 497 dures for copyrights defined in the Internet Standards process must 498 be followed, or as required to translate it into languages other 499 than English. 501 The limited permissions granted above are perpetual and will not be 502 revoked by the Internet Society or its successors or assigns. 504 This document and the information contained herein is provided on 505 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI- 506 NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 507 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 508 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR- 509 RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.