idnits 2.17.1 draft-ietf-acap-option-04.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 (June 2002) is 7983 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. -------------------------------------------------------------------------------- 2 Network Working Group S. Hole 3 Internet Draft: ACAP A. Melnikov 4 ACI WorldWide/MessagingDirect 5 Document: draft-ietf-acap-option-04.txt June 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 a Proposed Standard for the Internet Community. 34 Discussion and suggestions for improvement are requested. This 35 document will expire six months after publication. Distribution of 36 this draft is unlimited. 38 Copyright Notice 40 Copyright (C) The Internet Society 2002. All Rights Reserved. 42 1. Introduction 44 The Application Configuration Access Protocol (ACAP) is designed to 45 support remote storage and access of application option, 46 configuration and preference information. The generalized form of 47 this runtime configuration is called "options". Options consist of 48 any type of structured or unstructured data that an application 49 requires to operate in a user specific manner. 51 Storage of application options in an ACAP server substantially 52 solves the "kiosk user" problem for applications -- serial use of a 53 single machine by multiple users. It also solves the "nomadic 54 user" problem -- use of more than one machine on a regular basis by 55 a single user. 57 The specification defines the "option" dataset class for use with 58 ACAP. 60 2. Conventions used in this document 62 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 63 in this document are to be interpreted as described in [KEYWORDS]. 65 The attribute syntax specifications use the Augmented Backus-Naur 66 Form (ABNF) notation as specified in [ABNF]. 68 3. ACAP personal options 70 3.1. ACAP option representation 72 Individual options are represented as ACAP entries in option 73 datasets. The name of the entry, as defined by the "entry" 74 attribute for the entry, is the name of option. 76 3.2. Scalar options 78 Scalar options are ACAP entries that contain simple (unstructured) 79 data. The "option.value" attribute of the entry contains the data 80 for the option. The value can be single or multivalued. 82 Following is an example of a single and multivalued scalar option: 84 color.preferred 85 entry = "color.preferred" 86 option.value = "blue" 87 color.list 88 entry = "color.list" 89 option.value = ("red" "green" "blue" "cyan" "black") 91 Scalar options that are intended to be used by multiple applica- 92 tions should be registered as defined in section 4.4. 94 3.3. Structured options 96 Structured options are ACAP entries that contain multiple related 97 items of data in a single option. Data for the option is contained 98 in multiple named attributes collectively called "field 99 attributes". Each field attribute can be single or multivalued. 101 Following is an example of a structured option: 103 color.definition 104 entry = "color.definition" 105 option.color.definition.name = "blue" 106 option.color.definition.rgb = ("blue=255" "red=0" "green=0") 107 option.color.definition.index = "66" 109 By definition, structured options are application specific. While 110 the content of the field attributes can be obtained by any applica- 111 tion, it's intended use is open to interpretation by the applica- 112 tion. 114 3.4. ACAP option hierarchy 116 Option sets MAY be represented using ACAP hierarchy. Any entry in 117 an option dataset can also be a hierarchy node by setting the "sub- 118 dataset" attribute. Applications can model arbitrarily structured 119 configuration information using hierarchical datasets containing 120 scalar or structured options. An option subdataset of scalar 121 options models an associative list. An option subdataset of struc- 122 tured options models an array of structures. 124 3.5. ACAP option attribute formal syntax 126 The naming conventions for option entry attributes is defined by 127 the following ABNF. 129 option-value-attr = scalar-option-attr / structured-option-attr 131 scalar-option-attr = "option.value" 133 structured-option-attr = "option." name-component 134 1*("." name-component) 136 4. ACAP option namespace 138 The general ACAP namespace is organized to promote inheritance 139 between site, host, group, and user specific configuration informa- 140 tion, as defined in [ACAP]. It defines a "site", "group", "host", 141 and "user" second level hierarchy. The option dataset defines a 142 third level of hierarchy that promotes inheritance from second 143 level datasets, and isolates user and application specific 144 instances of configuration information. 146 4.1. ACAP "/option" dataset class 148 The dataset class whose name is "/option" is assumed to contain 149 option datasets as defined in this specification. 151 4.2. Third level option datasets 153 Third level option datasets break the option namespace into generic 154 and application specific option sets. This serves two purposes: 155 to promote the creation and inheritance of common options between 156 applications, and isolation of application specific configuration 157 from other applications. 159 4.2.1. The "vendor" option namespace 161 The "vendor" option namespace is a set of datasets, each named in 162 the form "vendor.", where "" is the name 163 of a specific application or application vendor. 165 The entries in the vendor namespace enumerate the applications that 166 make use of ACAP option storage at that level. Each vendor dataset 167 contains option entries and/or subdatasets for a specific vendor 168 applications. All options not in the "standard" namespace MUST be 169 in one of the "vendor" option namespaces. 171 The "vendor-name" for an application or vendor MUST be registered 172 with IANA according to the rules in section 5.1. The "ven- 173 dor.x-" namespace is reserved for temporary use by 174 vendors during product development, or for local applications that 175 are not generally distributed. 177 Vendors are free to suballocate their namespace as they see fit. 178 For example, a vendor may chose to store options for the various 179 applications that it produces in subdatasets underneath their ven- 180 dor namespace. For example, the CoolStuff software company may 181 chose to organize the option namespace for their software products 182 like 184 vendor.CoolStuff.caltool 185 vendor.CoolStuff.webtool 186 vendor.CoolStuff.mailtool 188 rather than try to register their application names as a vendor- 189 name in the vendor namespace. 191 4.2.2. The "standard" option namespace 193 The "standard" option namespace is a dataset named "standard" that 194 contains option entries that are generally applicable to a number 195 of applications. The namespace is reserved for shared options that 196 do not meet the requirements for a separate ACAP dataset class. 198 The standard option namespace is further partitioned into "standard 199 option classes" where option names are of the form ".". Standard option classes are 201 associated with a class of applications, e.g. mail user agents. The 202 "" is a registered string that 203 uniquely identifies the option class, e.g. "mua". 205 This document defines two standard option class prefixes - "common" 206 and "X". The "common" standard option class contains options that 207 are generally applicable to a large number of application classes. 208 For example, a default font or window background color. The "X" 209 namespace is reserved for temporary use by software developers dur- 210 ing product development. 212 Following are some examples of the standard option namespace: 214 standard/common.default.font 215 standard/common.default.color.background 216 standard/X.test-option 218 Option classes and names in the "standard" option namespace MUST be 219 registered with IANA according to the rules in section 5.2. Ven- 220 dors MUST NOT use the temporary namespace in products that are gen- 221 erally distributed. 223 4.3. Example option namespace 225 The following example demonstrates how the "standard" and "vendor" 226 namespaces isolate application specific and standard configuration 227 within the standard ACAP dataset namespace hierarchy. 229 /option/ 230 site/ 231 standard/ 232 vendor./ 233 vendor./ 234 ... 235 ... 236 host/ 237 / 238 standard/ 239 vendor./ 240 vendor./ 241 ... 242 ... 243 / 244 ... 245 ... 246 group/ 247 / 248 standard/ 249 vendor./ 250 vendor./ 251 ... 252 ... 253 / 254 ... 255 ... 256 user/ 257 / 258 standard/ 259 vendor./ 260 vendor./ 261 ... 262 ... 263 / 264 ... 265 ... 267 4.4. Formal Syntax for the Option Dataset Namespace 269 The naming conventions for the option dataset are defined by the 270 standard ABNF in [ACAP] for dataset namespaces, constrained and/or 271 extended by the following ABNF. 273 dname-component = 1*UTF8-CHAR 274 ;; MUST NOT begin with "." or contain "/" 276 name-component = 1*UTF8-CHAR 277 ;; MUST NOT contain ".", "/", "%", or "*" 279 option-dataset = "/option/" owner 281 option-component = standard-component / vendor-component 283 owner = owner-site / owner-host / owner-group / 284 owner-user / "~/" option-component 286 owner-group = "group/" dname-component "/" option-component 288 owner-host = "host/" dname-component "/" option-component 290 owner-site = "site/" option-component 292 owner-user = "user/" dname-component "/" option-component 294 standard-component = "standard/" standard-option-class "." 295 name-component 296 ;; The name-component MUST BE an IANA registered 297 ;; option name under the option class. 299 standard-option-class = "common" / "X" / name-component 300 ;; The name-component MUST BE an IANA registered 301 ;; option class prefix. 303 vendor-component = vendor-name "/" dname-component 305 vendor-name = vendor-token *("." name-component) 307 vendor-token = "vendor." name-component 308 ;; The name-component is the name of the 309 ;; application or vendor organization to which 310 ;; the options belong. 312 5. Namespace registration procedures 314 Some portions of the ACAP option namespace are designed to be 315 extensible within the standard. The goals for extensibility 316 include: (1) minimal process to extend the namespace within the 317 standard, (2) promote interoperability within the namespace, and 318 (3) support experimentation and development within the namespace. 320 To support these requirements, the ACAP Option dataset draws on the 321 recommendations for registration policies and procedures outlined 322 in [IANA-CONSIDERATIONS]. 324 5.1. Registering vendor names 326 The "vendor" option namespace is specifically designed to support 327 delegation of authority to individual organizations. The goal is 328 to provide a completely independent namespace for each application 329 vendor. The requirement is that each vendor namespace be uniquely 330 associated with one and only one vendor or product. 332 The "vendor" option namespace uses the identical registry as the 333 "vendor" dataset class defined in [ACAP]. Organizations that wish 334 to register a vendor name for the option namespace MUST follow the 335 procedures outlined in [ACAP]. 337 5.2. Registering standard options 339 The "standard" option namespace requires standardization procedures 340 for two different types of object: standard option class prefixes 341 and standard option names. 343 Standard option class prefixes MUST be registered with IANA. New 344 option class proposals MUST be confirmed using IETF Consensus, pri- 345 marily through consultation on the ACAP implementors mailing list. 346 Registration of an option class MUST include a review contact that 347 is responsible for approving registrations for option names regis- 348 tered in the option class. Registrations MUST provide the follow- 349 ing information when requesting a new standard option class prefix. 351 To: iana@iana.org 352 Subject: Registration of ACAP standard option class 354 Requested standard option class name: 355 Requested standard option class prefix: 356 Requested standard option class short description: 358 Approval contact: name, address, e-mail address, phone number 359 # as many contacts as appropriate - must be at least one 361 Standard option names MUST be registered with IANA using the Hier- 362 archical Allocation model described in [IANA-CONSIDERATIONS]. All 363 proposals MUST be reviewed and passed by the IANA registered con- 364 tact for the option class prior to submission. Discussion on new 365 option name proposals on the ACAP implementors mailing list is 366 strongly encouraged. Registrations MUST provide the following 367 information when requesting a new standard option name. 369 To: iana@iana.org 370 Subject: Registration of ACAP standard option 372 Containing option class: 373 Requested option name: . 374 Option short description: 375 Value semantics: # any specific semantic restrictions placed 376 on the value of the option, e.g. URL, 377 integer, ... 378 Value default: # a recommended default value for the option 380 6. Recommendations for standardization 382 There are no absolute rules for when to register a set of standard 383 options vs. defining a new dataset class. In general, one can 384 always register a standard option class and a set of option names 385 under that class. In some cases, it MAY be appropriate to define a 386 new dataset class instead of registering a set of standard options. 388 The key distinguishing feature of a dataset class definition is its 389 documentation requirements. Dataset class definitions specify the 390 semantic relationships in the dataset class. The semantic rela- 391 tionships between subdatasets, entries and attributes are fully 392 defined and part of the standard. 394 If a set of standard options has any of the following characteris- 395 tics, then it should be considered a candidate for a new dataset 396 class. 398 1. The option set consists of a list (array) of identically struc- 399 tured options. Proper representation of option sets of this type 400 require a subdataset. This is not prohibited by the standard 401 option namespace, but the list relationship of the options needs to 402 be documented. This makes it appropriate for a new dataset class. 404 2. Many or all of the options are semantically related or dependent 405 on one another. Individual options are incomplete, or not useful 406 unless evaluated in the context of the other options in the class. 407 The relationship or dependencies cannot be documented by individual 408 option registrations. 410 3. The set of options are interpreted by applications with addi- 411 tional semantic rules that apply to the set of options, and cannot 412 be documented in the registration information for individual stan- 413 dard options. 415 In summary, any standard option set that has semantic relationships 416 beyond a single option value is a candidate for a new dataset class 417 definition. Standard option sets SHOULD NOT be defined that have 418 additional semantic rules outside those of the individual options. 419 Standard option sets that acquire additional semantics over a 420 period of time, SHOULD be redefined as a dataset class using the 421 procedures and format outlined in [ACAP]. 423 Note that these considerations apply only to options in the "stan- 424 dard" option namespace. Semantic relationships in the vendor 425 namespace are at the discretion of the vendor and are not consid- 426 ered part of the extended standardization content of the ACAP 427 option namespace. 429 7. Security Considerations 431 It is important to make sure that access controls are set correctly 432 on personal options. Sensitive configuration information, includ- 433 ing application security information, should not be exposed to 434 other users without an explicit request by the user. 436 This specification does not address storing private certificates 437 and other security information in the option namespace. This may 438 be added to a future version of this specification when more exper- 439 imentation has been done. 441 8. Acknowledgments 443 Many thanks to the following people who have contributed to devel- 444 opment of the option dataset class specification: Jack DeWinter, 445 Rob Earhart, Ned Freed, Randy Gellens, John Meyers, Chris Newman, 446 Lyndon Nerenberg, John-Paul Sicotte, Matt Wall and other partici- 447 pants of the IETF ACAP working group. 449 9. References 451 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifi- 452 cations: ABNF", RFC 2234, November 1997 454 456 [ACAP] Newman, C., Myers, J. G., "Application Configuration Access 457 Protocol", RFC 2244, November 1997. 459 461 [IANA-CONSIDERATIONS] Thomas Narten, Harald Tveit Alvestrand, 462 "Guidelines for Writing an IANA Considerations Section in RFCs", 463 RFC 2434, October 1998. 465 467 [KEYWORDS] Bradner, S., "Key words for use in RFC to Indicate 468 Requirement Levels", RFC 2119, March 1997. 470 472 10. Authors' Addresses 474 Steve Hole 475 mailto:Steve.Hole@messagingdirect.com 477 Alexey Melnikov 478 mailto:Alexey.Melnikov@messagingdirect.com 480 ACI WorldWide/MessagingDirect 481 900 10117 - Jasper Ave. 482 Edmonton, Alberta, T5J 1W8, CANADA 484 11. Full Copyright Statement 486 Copyright (C) The Internet Society 2002. All Rights Reserved. 488 This document and translations of it may be copied and furnished to 489 others, and derivative works that comment on or otherwise explain 490 it or assist in its implementation may be prepared, copied, pub- 491 lished and distributed, in whole or in part, without restriction of 492 any kind, provided that the above copyright notice and this para- 493 graph are included on all such copies and derivative works. How- 494 ever, this document itself may not be modified in any way, such as 495 by removing the copyright notice or references to the Internet 496 Society or other Internet organizations, except as needed for the 497 purpose of developing Internet standards in which case the proce- 498 dures for copyrights defined in the Internet Standards process must 499 be followed, or as required to translate it into languages other 500 than English. 502 The limited permissions granted above are perpetual and will not be 503 revoked by the Internet Society or its successors or assigns. 505 This document and the information contained herein is provided on 506 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI- 507 NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 508 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 509 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR- 510 RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.