idnits 2.17.1 draft-ietf-acap-dewinter-dtype-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-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. ** 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 1 longer page, the longest (page 1) being 372 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction 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.) ** There are 102 instances of too long lines in the document, the longest one being 15 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 25, 1997) is 9863 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) -- Missing reference section? 'ACAP' on line 346 looks like a reference -- Missing reference section? 'ABNF' on line 189 looks like a reference -- Missing reference section? 'SIEVE' on line 221 looks like a reference -- Missing reference section? 'MIME-1' on line 351 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. De Winter 2 Internet Draft: ACAP-DISCOVER Wildbear Consulting 3 Document: draft-ietf-acap-dewinter-dtype-00.txt April 25, 1997 4 Expires: Oceober 31, 1997 6 ACAP Datatyping and Datatyping Discovery 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 other documents at any time. It is not appropriate to use Internet 18 Drafts as reference material or to cite them other than as a 19 ``working draft'' or ``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 ds.internic.net, nic.nordu.net, ftp.isi.edu, or 24 munnari.oz.au. 26 This document suggests a proposed protocol for the Internet 27 community, and requests discussion and suggestions for improvements. 28 Distribution of this draft is unlimited. 30 The protocol discussed in this document is experimental and subject 31 to change. Persons planning on either implementing or using this 32 protocol are STRONGLY URGED to get in touch with the author before 33 embarking on such a project. 35 1.0 Abstract 37 The Application Configuration Access Protocol (ACAP) is designed to 38 support remote storage and access of program option, configuration 39 and preference information. In certain circumstances, it is desirable 40 or necessary to deal with information that has a limit imposed on it. 41 While the general ACAP specification does provide for a (SYNTAX) alert 42 to inform the submittor that the stored information was not in a valid 43 syntax for that field, there is no generic method to discover that syntax. 45 There is strong feeling in the ACAP working group that variable length 46 strings should be used for data where possible, but there is also the 47 knowledge that ACAP will be used to configure and access existing systems 48 where the use of such variable length strings may be difficult or impossible. 50 2.0 Specification 52 The DISCOVER extension may be used with any ACAP server which returns 53 "DISCOVER" as one of the supported capabilities in the initial untagged 54 ACAP response. The decision on whether or not to preload certain information 55 for datasets is left to the client implementation. It should be noted 56 however that most of the discvoery information in a large number of the 57 datasets is consistant accross all instances of that dataset, and caching 58 could provide a substantial savings. 60 2.1 Referencing 62 Each of the datasets contain a given set of entries. The Discover extension 63 extends each of these entries to provide an in-situ method of discovering 64 their type information. This information is only provided if asked for, so 65 a client implementation that does not support the DISCOVER extension will not 66 be affected. 68 Every entry in every dataset will include all of the mandatory elements 69 described below, and may include the optional elements. Please note that 70 a given type of field may also mandate one of the optional elements to 71 provide more information on that field. 73 Each of the accesses within the datasets to this extended information will 74 be prefixed by "Extension.Type". For example, to find the type of a given 75 addressbook item "EMail", a client would request information about 76 "EMail.Extension.Type." where is the desired piece of type information. 77 If all of the type information is desired, the "Extension.Type" can be used 78 by itself to return all of the type information for that item. 80 For the purpose of quota information, none of this dataset discovery information 81 should be accounted for towards any quota count, as it is server supplied 82 information the client does not have any control over. 84 2.2 Mandatory Elements 86 2.2.1 Extension.Type.Cache 88 This field is assigned a value of 'yes' or 'no' and specifies if the discovery 89 information for this field is for the dataset or for this specific instance of 90 the dataset. Caching of disocvery information over a dataset is encouraged, but 91 it is understood that certain enties may mandate dynamic information. 93 2.2.2 Extension.Type.Description 95 This field is assigned a string of no more that 512 characters that describes 96 the field itself. This description should take into account any character sets 97 selected and offer a base description in English. 99 2.2.3 Extension.Type.Type 101 This field is assigned a value that denotes what kind of data it will contain. 102 This list shall be considered to be set unless ammended by a standards track 103 document. If ammended, an addition extension tag should be used to advertise 104 the additional dataset ability. 106 Additional elements to be used with the typing are provided as elements that 107 occur after the type declaration itself. In the case of a type that does not 108 have any additional elements, the type is returned as is. Otherwise, the type 109 is followed by a SPACE character and a SPACE separated list of elements. 111 2.2.3.1 Extension.Type.Type = "vstring" 113 The variable length string (hence referred to as vstring) is used to store an 114 arbitrarily long string of information. This information should be stored as 115 per the instructions in the [ACAP] document. There is no additional information 116 that needs to be provided with this type. 118 2.2.3.2 Extension.Type.Type = "bstring" 120 The bounded length string (hence referred to as bstring) is used to store a 121 fixed number of characters. This type is primarily for fields where there 122 are strong constraints on the number of characters needed to fulfil this item. 123 The minimum and maximum elements define the lower and upper bounds 124 on the string. The default values for those elements are 0 and 254, effectively 125 making them the same as the string type defined below. 127 2.2.3.3 Extension.Type.Type = "string" 129 The string is defined as a short string containing from 0 to 254 characters, 130 not including any implementation specific terminating characters. This is a 131 subset of the 'bstring' type described above, where the minimum is 0 and the 132 maximum is 254. 134 2.2.3.4 Extension.Type.Type = "whole" 136 The string is defined to consist of a sequence of numeric characters that 137 comprise an unsigned 32 bit value. The optional base element denotes 138 the numeric base of the whole number, and defaults to base 10 if not present. 139 The grammar in section 3.0 provides a BNF description of how the whole number 140 can be expressed. 142 2.2.3.5 Extension.Type.Type = "bwhole" 144 The string represents a bounded whole number (hence refered to as bwhole). This 145 is a number that falls within the same constraints as the whole type, but with 146 the upper and lower bound of the number specified by the optional minimum and 147 maximum elements. If not present, the default values for the minimum and maximum 148 elements are 0 and 100 respectively. 150 2.2.3.6 Extension.Type.Type = "integer" 152 The string is defined to consist of a sequence of numeric characters plus the 153 prefix unary minus character, and is used to comprise a signed 32 bit value 154 in base 10. 156 2.2.3.7 Extension.Type.Type = "binteger" 158 The string represents a bounded integer number (hence refered to as binteger). This 159 is a number that falls within the same constraints as the integer type, but with 160 the upper and lower bound of the number specified by the optional minimum and 161 maximum elements. If not present, the default values for the minimum and maximum 162 elements are 0 and 100 respectively. 164 2.2.3.8 Extension.Type.Type = "boolean" 166 The string represents a true or false value. The true value may be represented by 167 the strings "1", "yes", or "true". The false value may be represented by the 168 strings "0", "no", or "false". The server should be consistant in its setting of 169 the given field to a given pair of these values. 171 2.2.3.9 Extension.Type.Type = "date" 173 The string represents a time in "yyyy/mm/dd" format. 175 2.2.3.10 Extension.Type.Type = "time" 177 The string repsents a time in "hh:mm:ss" format, assuming GMT. 179 2.2.3.11 Extension.Type.Type = "datetime" 181 The string represents a combined date and time, assuming GMT, of 182 "yyyy/mm/dd hh:mm:ss". 184 2.2.3.12 Extension.Type.Type = "fstring" 186 The string represents a formatted string (hence referred to as fstring). 187 If the first character is a '[', then the format in the Dataset.Format 188 element is an ABNF construct, with the rules for the ABNF contained within 189 [ABNF]. See section XXXX for a listing of the built-in constructs that the 190 ABNF parser can assume unless otherwise specified. 192 If the format string is empty, then the fstring is assumed to behave like 193 a vstring. Otherwise, the format is assumed to be a simple format string, 194 using the '*' and '?' characters to replace one or more characters and a 195 single character. The '*' and '?' characters can be used by escaping them 196 with a '\' character before them, and the '\' character must be escaped 197 itself as well. 199 2.2.3.13 Extension.Type.Type = "select" 201 The string represents a given entry from a list of acceptable entries. The 202 list of acceptible entries is denoted by the list element, and by default 203 contains a single element consisting of the empty string. 205 2.2.3.14 Extension.Type.Type = "mime" 207 The string represents a mime object. The constrains on the type of MIME object 208 allowed for this field are specified with the optional MimeDataType element. 209 The default for the mime_list element is "(*/*)". 211 [Open Issue: Need to talk to RobE regarding storing of mime information and make 212 sure that things sync up.] 214 2.2.3.15 Extension.Type.Type = "complex" 216 The string represents a complex data type, as it may be desirable in some cases 217 to pass the string to a backend process for validation or compilation. In this 218 case, if a (SYNTAX) response is generated, then the human readable section of the 219 response will reflect the error that occured during submission. 221 Example: storing a [SIEVE] script using ACAP with a server implementation that 222 compiles the script and validates the script before it accepts it. 224 [Open Issue: Is is possible to return more than one error string?] 226 2.3 Optional Elements 228 2.3.1 Dataset.Hint 230 This string represents a hint of no more that 512 character than can assist 231 a client program in providing the user with a hint on what type of data is 232 expected for this field. 234 2.3.7 Dataset.Hide 236 This element may be used with any of the given types to ask the client program 237 to try and hide the value from the user. This is primarily for fields such as 238 passwords and password validation where displaying of the password itself is 239 not desired. Note that with some fields, operating system constraints may not 240 allow the given display to hide the value in question. (e.g. multiple select 241 list box) 243 2.3.8 Dataset.ForceUpper and Dataset.ForceLower 245 These elements are used with the string types to provide a way to force an 246 entry to be in upper or lower case. 247 [Open Issue: How would this apply to other charsets?] 249 2.4 Error detection 251 If the dataset in question supports any of the data types other than the 252 vstring data type, it is possible to return an error to the client, indicating 253 the unsuitability of the data. In this case, the server will return an 254 extended response code of "SYNTAX" with the human readable text possibly giving 255 more information on the nature of the syntactical error reported. For the 256 datatype "complex", it is highly recommended that the human readable text 257 reflect as much information as possible to the client. 259 3.0 Syntax 261 This syntax is expressed using BNF, except that the # constructor for list 262 uses a SPACE character as a separator, rather than a comma. Any text provided 263 as part of the grammar should be considered case-insensitive. 265 digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 267 digit ::= "0" / digit_nz 269 number ::= digit_nz *digit / digit 270 ; 32 bit unsigned number with no leading zeros 271 ; 0 <= n < 4,294,967,296 273 minimum ::= number 275 maximum ::= number 277 whole ::= number 279 integer ::= [ "-" ] digit_nz *digit / digit 280 ; 32 bit signed number with no leading zeros 281 ; -2,147,483,647 <= n < 2,147,483,648 283 boolean_true ::= "true" / "yes" / "1" 285 boolean_false ::= "false" / "no" / "0" 287 boolean ::= boolean_true / boolean_false 289 base ::= "2" / "8" / "10" / "16" 291 date_year ::= 4digit 293 date_month ::= 2digit 295 date_day ::= 2digit 296 ; Note: day of the month 298 date ::= date_year "/" date_month "/" date_day 300 time_hour ::= 2digit 301 ; 0 <= n <= 23 303 time_minute ::= 2digit 304 ; 0 <= n <= 59 306 time_second ::= 2digit 307 ; 0 <= n <= 59 309 time_zone ::= ( "+" / "-" ) 4digit 311 time ::= time_hour ":" time_minute ":" time_second SPACE time_zone 313 datetime ::= date SPACE time 315 abnf_build ::= to be added 317 glob_char ::= CHAR8 except "*", "?", and "\\" 319 glob_build ::= *( "*" / "?" / "\*" / "\?" / "\\" / glob_char ) 321 quoted_char ::= CHAR8 except "\" and <"> 323 quoted-string ::= <"> *( <\"> / "\\" / quoted-char ) <"> 325 list ::= "(" #quoted-string ")" 327 mime_item ::= "*" / CHAR8 329 mime_subtype ::= mime_item 331 mime_type ::= mime_item 333 mime_list ::= "(" #( mime_type "/" mime_subtype ) ")" 334 ; note that if the mime_type is "*", the mime_subtype must be "*" 336 type ::= "vstring" / "bstring" [ SPACE minimum SPACE maximum ] / 337 "fstring" [ SPACE ( abnf_build / glob_build )] / 338 "string" / "whole" [ SPACE base ] / 339 "bwhole" [ SPACE minimum SPACE maximum [ SPACE base ]] / 340 "integer" / "binteger" [ SPACE minimum SPACE maximum ] / 341 "boolean" / "date" / "time" / "datetime" / 342 "select" [ SPACE list ] / "mime" [ SPACE mime_list ] / 343 "complex" 345 3.0 References 346 [ACAP] Myers, J., and Newman, C., "Application Configuration Access 347 Protocol (ACAP)", Work in Progress of the IETF ACAP WG, 348 draft-ietf-acap-spec-??.txt. Check Internet Drafts listing for 349 latest version. 351 [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet 352 Mail Extensions) Part One: Mechanisms for Specifying and Describing 353 the Format of Internet Message Bodies", RFC 1521. 355 4.0 Security Considerations 357 There are no known security issues with this extension. 359 5.0 Author's Addresses 361 Jack De Winter 362 Wildbear Consulting, Inc. 363 17 Brock Street 364 Kitchener, Ontario N2M 1X2 365 Canada 367 Email: jack@wildbear.on.ca