idnits 2.17.1 draft-wood-ldapext-float-00.txt: ** The Abstract section seems to be numbered -(225): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** 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? == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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 are 10 instances of lines with control characters in the document. 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.) -- 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) -- Looks like a reference, but probably isn't: 'RFC 2251' on line 47 -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Doug Wood 2 Tivoli Systems Inc 3 December, 1999 4 Expires: June 2000 6 Directory string representation for floating point values 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Distribution of this memo is unlimited. It is filed as , and expires on June, 2000. 31 Please send comments to the authors. 33 1. Abstract 35 This draft defines a way that floating point values may be 36 represented as directory (ASCII) strings such that standard ordering 37 rules can be used to sort the strings into the correct collating 38 sequence for their numeric value. The representation is intended 39 for use in X.500 like directories, and has been developed to support 40 mapping of the DMTF Common Information Model. 42 2. Introduction 44 X.500 directories provide for use definable syntaxes, matching and 45 ordering rules. This provides for the definition of schema 46 supporting any type and structure of data. The definition of the 47 LDAP protocol [RFC 2251] has encouraged the creation new generation 48 of directories that support the X.500 structure, but don�t support 49 some of X.500�s more heavy weight feature. Among the unsupported 50 feature are user definable syntaxes. This restricts schema designers 51 to syntaxes provided by the directory vendor. These typical do not 52 include a syntax for floating point values. 54 This draft defines a an ASCII format for floating point values that 55 allow them to be stored in attributes with Directory String syntax. 56 And allows the standard case insensitive ordering rule to sort them 57 in the correct collating sequence for their numeric value. In 58 addition, attributes are defined which can be used for values stored 59 in the format described below, or as superiors for user defined 60 attributes. The attributes are provided both as a convenience, and 61 as a method to document the storage format used. 63 The format is defined specifically to support mapping the DMTF 64 Common Information Model to directory schema, but also has general 65 applicability. 67 3. String format 69 Because string comparison is positional, it is necessary to define a 70 fix format for representing the mantissa, and the exponent. Because 71 the collating sequence for string comparison is left to right, the 72 most significant portion of the representation must be on the left. 73 There are four separate cases that must be handled. 75 o Negative mantissa and positive exponent 76 o Negative mantissa and negative exponent 77 o Positive mantissa and negative exponent 78 o Positive mantissa, and positive exponent 80 The above list is ordered by the desired collating sequence from 81 smallest value to largest value. A single representation does not 82 provide the correct collating sequence for all cases. Therefor it 83 is necessary to sort by case, and then to sort within each case. To 84 accomplish this, the cases are number from 1 to 5 as follows: 86 1. Negative mantissa and positive exponent 87 2. Negative mantissa and negative exponent 88 3. Zero 89 4. Positive mantissa and negative exponent 90 5. Positive mantissa, and positive exponent 92 For symmetry, zero is treated as its own case instead of a special 93 sub-case of case 4. 95 A 64 bit float has a range of 1.7976931348623158e+308 to 96 2.2250738585072014e-308[1]. To represent this as a string, three 97 digits are required for the exponent, and 17 for the mantissa not 98 including the decimal point. The directory representation is fixed 99 format, zero padded, blank separated, with the most significant 100 fields on the left. The first character in the string is the case 101 number. For readability, it is followed by a blank. Next is a 3 102 digit exponent, again followed by a blank. Next are a single digit, 103 a decimal point, and 16 digits of decimal. 105 +-+-+---+-+-+-+----------------+ 106 | | |Exp| | | |16 digits | 107 +-+-+---+-+-+-+----------------+ 108 |c| |nnn| |n|.|nnnnnnnnnnnnnnnn| 109 +-+-+---+-+-+-+----------------+ 111 The way each of the fields is interpreted varies with the case. 112 The cases are examined in reverse order so the simplest may be 113 examined first. 115 3.1 Positive mantissa and positive exponent (case 5) 117 This is relatively straightforward. The exponent field has the 118 exponent value expressed as a 3-digit integer string. It is zero 119 padded to the left if necessary. The mantissa field as a seventeen- 120 digit decimal string with exactly 1 digit to the left of the decimal 121 point for a total of 18 characters. It is zero padded to the right 122 if necessary. 124 Notes: 125 - The first digit is a 5 to indicate the case 126 - There is exactly one digit to the left of the decimal place. It 127 is always non zero. 128 - Positions 2 through 4 have the exponent. It is right justified, 129 and zero padded to the left if it is less than three digits 130 - Spaces are added to aid human readability 131 - No signs are required for the exponent or the mantissa because 132 they are expressed in the case number 134 3.2 Positive mantissa and negative exponent (case 4) 136 When the exponent is negative, larger whole number values for the 137 exponent produce smaller actual values. For this case, a string 138 comparison of the numeric representation of the exponent yields the 139 reverse of the desired collating sequence. To flip the collating 140 sequence, the value of the exponent is added to 999, and the result 141 stored as the exponent. No sign is stored. The sign of both the 142 exponent and mantissa are indicated by the case character. 144 3.3 Zero (case 3) 146 The case number is sufficient to insure the correct collating 147 sequence. To insure equality comparisons work correctly, all 148 remaining digits are zero. 150 3.4 Negative mantissa and negative exponent (case 2) 152 When both the exponent and the mantissa are negative, the collating 153 order for the exponent is correct. A larger exponent yields a 154 number that is closer to zero and therefor larger. However, the 155 collating sequence for the mantissa is reversed. To flip the 156 collating sequence for the mantissa it is added to 10, and the 157 result stored. 159 3.5 Negative mantissa and positive exponent (case 1) 161 When both the exponent and the mantissa are negative, the collating 162 sequence is flipped for both of them. This is achieved by adding 163 the exponent to 999, and the mantissa to 10. 165 4. Examples 167 +----------+--------------------------+ 168 | Value | Representation | 169 +----------+--------------------------+ 170 | 3.25e5 | 5 005 3.2500000000000000 | 171 +----------+--------------------------+ 172 | 8.4e-5 | 4 994 8.4000000000000000 | 173 +----------+--------------------------+ 174 | 8.4e-7 | 4 992 8.4000000000000000 | 175 +----------+--------------------------+ 176 | 7.23e-7 | 4 992 7.2300000000000000 | 177 +----------+--------------------------+ 178 | 0.0e0 | 3 000 0.0000000000000000 | 179 +----------+--------------------------+ 180 | -4.25e-4 | 2 004 5.7500000000000000 | 181 +----------+--------------------------+ 182 | -6.35e-4 | 2 004 3.6500000000000000 | 183 +----------+--------------------------+ 184 | -6.35e-3 | 2 003 3.6500000000000000 | 185 +----------+--------------------------+ 186 | -4.0e104 | 1 895 6.0000000000000000 | 187 +----------+--------------------------+ 188 | -4.0e105 | 1 894 6.0000000000000000 | 189 +----------+--------------------------+ 190 | -6.0e105 | 1 894 4.0000000000000000 | 191 +----------+--------------------------+ 193 5. 32 bit vs. 64 bit values 195 Both 32 and 64 bit floating point values are in common usage. To 196 allow comparisons between the two, both are stored in the 64-bit 197 format described above. This implies a greater degree of precision 198 than is actually available for 32-bit values. The directory mapping 199 described below provides implicit documentation of the actual 200 precision of a value. 202 6. Directory mapping 204 The intent of the mapping is to simulate a new syntax. The 205 advantage of this approach is it may be utilized without any changes 206 to existing directory servers. To foster that illusion, and to aid 207 in documentation, two new attributes are defined. cimFloat32, and 208 cimFloat64. All floating-point attributes are derived from one of 209 these. They are defined as: 211 cimFloat32 212 { 213 ; Need OID assigned 214 NAME �cimFloat32� 215 DESC '32 bit float encoded as sortable float format' 216 EQUALITY caseIgnoreeMatch 217 ORDERING caseIgnoreOrderingMatch 218 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 219 ) 221 cimFloat64 222 ( 223 ; Need OID assigned 224 NAME �cimFloat64� 225 DESC '�64 bit float encoded as sortable float format� 226 EQUALITY caseIgnoreeMatch 227 ORDERING caseIgnoreOrderingMatch 228 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 229 ) 231 7. References 233 [1] From sys/limits.h on AIX 4.3 235 8. Acknowledgement 237 This work is a product of the DMTF LDAP Mapping Working Group and 238 has benefited from many comments and discussions during this groups 239 meetings. 241 9. Authors' Addresses 243 Doug Wood 244 Tivoli Systems 245 9025 North River Rd. 246 Indianapolis, IN 46240-7622 247 Dawood@Tivoli.com 249 Expires June 2000