idnits 2.17.1 draft-ietf-acap-option-05.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 12 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 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (December 2002) is 7796 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) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hole 3 Internet Draft: ACAP A. Melnikov 4 ACI WorldWide/MessagingDirect 5 Document: draft-ietf-acap-option-05.txt December 2002 6 Expires in 6 months 8 ACAP Application Options Dataset Class 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 29 The list of Internet-Draft Shadow Directories can be accessed at 30 . 32 A version of this draft document is intended for submission to the 33 RFC editor as an Experimental document. Discussion and suggestions 34 for improvement are requested. This document will expire six months 35 after publication. Distribution of this draft is unlimited. 37 Abstract 39 The Application Configuration Access Protocol (ACAP) is designed to 40 support remote storage and access of application option, configura- 41 tion and preference information. The generalized form of this run- 42 time configuration is called "options". Options consist of any 43 type of structured or unstructured data that an application 44 requires to operate in a user specific manner. 46 Storage of application options in an ACAP server substantially 47 solves the "kiosk user" problem for applications -- serial use of a 48 single machine by multiple users. It also solves the "nomadic 49 user" problem -- use of more than one machine on a regular basis by 50 a single user. 52 Copyright Notice 54 Copyright (C) The Internet Society 2002. All Rights Reserved. 56 1. Introduction 58 The Application Configuration Access Protocol (ACAP) is designed to 59 support remote storage and access of application option, configura- 60 tion and preference information. The generalized form of this run- 61 time configuration is called "options". Options consist of any 62 type of structured or unstructured data that an application 63 requires to operate in a user specific manner. 65 Storage of application options in an ACAP server substantially 66 solves the "kiosk user" problem for applications -- serial use of a 67 single machine by multiple users. It also solves the "nomadic 68 user" problem -- use of more than one machine on a regular basis by 69 a single user. 71 The specification defines the "option" dataset class for use with 72 ACAP. 74 2. Conventions used in this document 76 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 77 in this document are to be interpreted as described in [KEYWORDS]. 79 The attribute syntax specifications use the Augmented Backus-Naur 80 Form (ABNF) notation as specified in [ABNF]. 82 3. ACAP personal options 84 3.1. ACAP option representation 86 Individual options are represented as ACAP entries in option 87 datasets. The name of the entry, as defined by the "entry" 88 attribute for the entry, is the name of option. 90 3.2. Scalar options 92 Scalar options are ACAP entries that contain simple (unstructured) 93 data. The "option.value" attribute of the entry contains the data 94 for the option. The value can be single or multivalued. 96 Following is an example of a single and multivalued scalar option: 98 color.preferred 99 entry = "color.preferred" 100 option.value = "blue" 101 color.list 102 entry = "color.list" 103 option.value = ("red" "green" "blue" "cyan" "black") 105 Scalar options that are intended to be used by multiple applica- 106 tions should be registered as defined in section 4.4. 108 3.3. Structured options 110 Structured options are ACAP entries that contain multiple related 111 items of data in a single option. Data for the option is contained 112 in multiple named attributes collectively called "field 113 attributes". Each field attribute can be single or multivalued. 115 Following is an example of a structured option: 117 color.definition 118 entry = "color.definition" 119 option.color.definition.name = "blue" 120 option.color.definition.rgb = ("blue=255" "red=0" "green=0") 121 option.color.definition.index = "66" 123 By definition, structured options are application specific. While 124 the content of the field attributes can be obtained by any applica- 125 tion, it's intended use is open to interpretation by the applica- 126 tion. 128 3.4. ACAP option hierarchy 130 Option sets MAY be represented using ACAP hierarchy. Any entry in 131 an option dataset can also be a hierarchy node by setting the "sub- 132 dataset" attribute. Applications can model arbitrarily structured 133 configuration information using hierarchical datasets containing 134 scalar or structured options. An option subdataset of scalar 135 options models an associative list. An option subdataset of struc- 136 tured options models an array of structures. 138 3.5. ACAP option attribute formal syntax 140 The naming conventions for option entry attributes is defined by 141 the following ABNF. 143 option-value-attr = scalar-option-attr / structured-option-attr 145 scalar-option-attr = "option.value" 147 structured-option-attr = "option." name-component 148 1*("." name-component) 150 4. ACAP option namespace 152 The general ACAP namespace is organized to promote inheritance 153 between site, host, group, and user specific configuration informa- 154 tion, as defined in [ACAP]. It defines a "site", "group", "host", 155 and "user" second level hierarchy. The option dataset defines a 156 third level of hierarchy that promotes inheritance from second 157 level datasets, and isolates user and application specific 158 instances of configuration information. 160 4.1. ACAP "/option" dataset class 162 The dataset class whose name is "/option" is assumed to contain 163 option datasets as defined in this specification. 165 4.2. Third level option datasets 167 Third level option datasets break the option namespace into generic 168 and application specific option sets. This serves two purposes: 169 to promote the creation and inheritance of common options between 170 applications, and isolation of application specific configuration 171 from other applications. 173 4.2.1. The "vendor" option namespace 175 The "vendor" option namespace is a set of datasets, each named in 176 the form "vendor.", where "" is the name 177 of a specific application or application vendor. 179 The entries in the vendor namespace enumerate the applications that 180 make use of ACAP option storage at that level. Each vendor dataset 181 contains option entries and/or subdatasets for a specific vendor 182 applications. All options not in the "standard" namespace MUST be 183 in one of the "vendor" option namespaces. 185 The "vendor-name" for an application or vendor MUST be registered 186 with IANA according to the rules in section 5.1. The "ven- 187 dor.x-" namespace is reserved for temporary use by 188 vendors during product development, or for local applications that 189 are not generally distributed. 191 Vendors are free to suballocate their namespace as they see fit. 192 For example, a vendor may chose to store options for the various 193 applications that it produces in subdatasets underneath their ven- 194 dor namespace. For example, the CoolStuff software company may 195 chose to organize the option namespace for their software products 196 like 198 vendor.CoolStuff.caltool 199 vendor.CoolStuff.webtool 200 vendor.CoolStuff.mailtool 202 rather than try to register their application names as a vendor- 203 name in the vendor namespace. 205 4.2.2. The "standard" option namespace 207 The "standard" option namespace is a dataset named "standard" that 208 contains option entries that are generally applicable to a number 209 of applications. The namespace is reserved for shared options that 210 do not meet the requirements for a separate ACAP dataset class. 212 The standard option namespace is further partitioned into "standard 213 option classes" where option names are of the form ".". Standard option classes are 215 associated with a class of applications, e.g. mail user agents. The 216 "" is a registered string that 217 uniquely identifies the option class, e.g. "mua". 219 This document defines two standard option class prefixes - "common" 220 and "X". The "common" standard option class contains options that 221 are generally applicable to a large number of application classes. 222 For example, a default font or window background color. The "X" 223 namespace is reserved for temporary use by software developers dur- 224 ing product development. 226 Following are some examples of the standard option namespace: 228 standard/common.default.font 229 standard/common.default.color.background 230 standard/X.test-option 232 Option classes and names in the "standard" option namespace MUST be 233 registered with IANA according to the rules in section 5.2. Ven- 234 dors MUST NOT use the temporary namespace in products that are gen- 235 erally distributed. 237 4.3. Example option namespace 239 The following example demonstrates how the "standard" and "vendor" 240 namespaces isolate application specific and standard configuration 241 within the standard ACAP dataset namespace hierarchy. 243 /option/ 244 site/ 245 standard/ 246 vendor./ 247 vendor./ 248 ... 249 ... 250 host/ 251 / 252 standard/ 253 vendor./ 254 vendor./ 255 ... 256 ... 257 / 258 ... 259 ... 260 group/ 261 / 262 standard/ 263 vendor./ 264 vendor./ 265 ... 266 ... 267 / 268 ... 269 ... 270 user/ 271 / 272 standard/ 273 vendor./ 274 vendor./ 275 ... 276 ... 277 / 278 ... 279 ... 281 4.4. Formal Syntax for the Option Dataset Namespace 283 The naming conventions for the option dataset are defined by the 284 standard ABNF in [ACAP] for dataset namespaces, constrained and/or 285 extended by the following ABNF. 287 dname-component = 1*UTF8-CHAR 288 ;; MUST NOT begin with "." or contain "/" 290 name-component = 1*UTF8-CHAR 291 ;; MUST NOT contain ".", "/", "%", or "*" 293 option-dataset = "/option/" owner 295 option-component = standard-component / vendor-component 297 owner = owner-site / owner-host / owner-group / 298 owner-user / "~/" option-component 300 owner-group = "group/" dname-component "/" option-component 302 owner-host = "host/" dname-component "/" option-component 304 owner-site = "site/" option-component 306 owner-user = "user/" dname-component "/" option-component 308 standard-component = "standard/" standard-option-class "." 309 name-component 310 ;; The name-component MUST BE an IANA registered 311 ;; option name under the option class. 313 standard-option-class = "common" / "X" / name-component 314 ;; The name-component MUST BE an IANA registered 315 ;; option class prefix. 317 vendor-component = vendor-name "/" dname-component 319 vendor-name = vendor-token *("." name-component) 321 vendor-token = "vendor." name-component 322 ;; The name-component is the name of the 323 ;; application or vendor organization to which 324 ;; the options belong. 326 5. IANA Considerations 328 Some portions of the ACAP option namespace are designed to be 329 extensible within the standard. The goals for extensibility 330 include: (1) minimal process to extend the namespace within the 331 standard, (2) promote interoperability within the namespace, and 332 (3) support experimentation and development within the namespace. 334 This section defines IANA registration templates for standard ACAP 335 options and standard ACAP option classes. 337 5.1. Registering vendor names 339 The "vendor" option namespace is specifically designed to support 340 delegation of authority to individual organizations. The goal is 341 to provide a completely independent namespace for each application 342 vendor. The requirement is that each vendor namespace be uniquely 343 associated with one and only one vendor or product. 345 The "vendor" option namespace uses the identical registry as the 346 "vendor" dataset class defined in [ACAP]. Organizations that wish 347 to register a vendor name for the option namespace MUST follow the 348 procedures outlined in [ACAP]. 350 5.2. Registering standard options 352 The "standard" option namespace requires standardization procedures 353 for two different types of object: standard option class prefixes 354 and standard option names. 356 Standard option class prefixes MUST be registered with IANA. New 357 option class proposals MUST be confirmed using IETF Consensus, pri- 358 marily through consultation on the ACAP implementors mailing list. 359 Registration of an option class MUST include a review contact that 360 is responsible for approving registrations for option names regis- 361 tered in the option class. Registrations MUST provide the follow- 362 ing information when requesting a new standard option class prefix. 364 To: iana@iana.org 365 Subject: Registration of ACAP standard option class 367 Requested standard option class name: 368 Requested standard option class prefix: 369 Requested standard option class short description: 371 Approval contact: name, e-mail address, address, phone number 372 # as many contacts as appropriate - must include email address 374 Standard option names MUST be registered with IANA using the tem- 375 plate provided below. All proposals MUST be reviewed and passed by 376 the IANA registered contact for the option class prior to submis- 377 sion. Discussion on new option name proposals on the ACAP imple- 378 mentors mailing list is strongly encouraged. Registrations MUST 379 provide the following information when requesting a new standard 380 option name. 382 To: iana@iana.org 383 Subject: Registration of ACAP standard option 385 Containing option class: 386 Requested option name: . 387 Option short description: 388 Value semantics: # any specific semantic restrictions placed 389 on the value of the option, e.g. URL, 390 integer, ... 391 Value default: # a recommended default value for the option 393 6. Recommendations for standardization 395 There are no absolute rules for when to register a set of standard 396 options vs. defining a new dataset class. In general, one can 397 always register a standard option class and a set of option names 398 under that class. In some cases, it MAY be appropriate to define a 399 new dataset class instead of registering a set of standard options. 401 The key distinguishing feature of a dataset class definition is its 402 documentation requirements. Dataset class definitions specify the 403 semantic relationships in the dataset class. The semantic rela- 404 tionships between subdatasets, entries and attributes are fully 405 defined and part of the standard. 407 If a set of standard options has any of the following characteris- 408 tics, then it should be considered a candidate for a new dataset 409 class. 411 1. The option set consists of a list (array) of identically struc- 412 tured options. Proper representation of option sets of this type 413 require a subdataset. This is not prohibited by the standard 414 option namespace, but the list relationship of the options needs to 415 be documented. This makes it appropriate for a new dataset class. 417 2. Many or all of the options are semantically related or dependent 418 on one another. Individual options are incomplete, or not useful 419 unless evaluated in the context of the other options in the class. 421 The relationship or dependencies cannot be documented by individual 422 option registrations. 424 3. The set of options are interpreted by applications with addi- 425 tional semantic rules that apply to the set of options, and cannot 426 be documented in the registration information for individual stan- 427 dard options. 429 In summary, any standard option set that has semantic relationships 430 beyond a single option value is a candidate for a new dataset class 431 definition. Standard option sets SHOULD NOT be defined that have 432 additional semantic rules outside those of the individual options. 433 Standard option sets that acquire additional semantics over a 434 period of time, SHOULD be redefined as a dataset class using the 435 procedures and format outlined in [ACAP]. 437 Note that these considerations apply only to options in the "stan- 438 dard" option namespace. Semantic relationships in the vendor 439 namespace are at the discretion of the vendor and are not consid- 440 ered part of the extended standardization content of the ACAP 441 option namespace. 443 7. Security Considerations 445 It is important to make sure that access controls are set correctly 446 on personal options. Sensitive configuration information, includ- 447 ing application security information, should not be exposed to 448 other users without an explicit request by the user. 450 This specification does not address storing private certificates 451 and other security information in the option namespace. This may 452 be added to a future version of this specification when more exper- 453 imentation has been done. 455 8. Acknowledgments 457 Many thanks to the following people who have contributed to devel- 458 opment of the option dataset class specification: Jack DeWinter, 459 Rob Earhart, Ned Freed, Randy Gellens, John Meyers, Chris Newman, 460 Lyndon Nerenberg, John-Paul Sicotte, Matt Wall and other partici- 461 pants of the IETF ACAP working group. 463 9. Normative references 465 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifi- 466 cations: ABNF", RFC 2234, November 1997 468 470 [ACAP] Newman, C., Myers, J. G., "Application Configuration Access 471 Protocol", RFC 2244, November 1997. 473 475 [KEYWORDS] Bradner, S., "Key words for use in RFC to Indicate 476 Requirement Levels", RFC 2119, March 1997. 478 480 10. Authors' Addresses 482 Steve Hole 483 mailto:Steve.Hole@messagingdirect.com 485 ACI WorldWide/MessagingDirect 486 900 10117 - Jasper Ave. 487 Edmonton, Alberta, T5J 1W8, CANADA 489 Alexey Melnikov 490 mailto:Alexey.Melnikov@messagingdirect.com 492 ACI WorldWide/MessagingDirect 493 59 Clarendon Road, Watford, Hertfordshire, 494 United Kingdom, WD17 1FQ 496 11. Full Copyright Statement 498 Copyright (C) The Internet Society 2002. All Rights Reserved. 500 This document and translations of it may be copied and furnished to 501 others, and derivative works that comment on or otherwise explain 502 it or assist in its implementation may be prepared, copied, pub- 503 lished and distributed, in whole or in part, without restriction of 504 any kind, provided that the above copyright notice and this para- 505 graph are included on all such copies and derivative works. How- 506 ever, this document itself may not be modified in any way, such as 507 by removing the copyright notice or references to the Internet 508 Society or other Internet organizations, except as needed for the 509 purpose of developing Internet standards in which case the proce- 510 dures for copyrights defined in the Internet Standards process must 511 be followed, or as required to translate it into languages other 512 than English. 514 The limited permissions granted above are perpetual and will not be 515 revoked by the Internet Society or its successors or assigns. 517 This document and the information contained herein is provided on 518 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI- 519 NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 520 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 521 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR- 522 RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.