idnits 2.17.1 draft-jennings-senml-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 11, 2011) is 4672 days in the past. Is this intentional? 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 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4288 (Obsoleted by RFC 6838) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.754.1985' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-04 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco 4 Intended status: Standards Track July 11, 2011 5 Expires: January 12, 2012 7 Media Type for Sensor Markup Language (SENML) 8 draft-jennings-senml-06 10 Abstract 12 This specification defines media types for representing simple sensor 13 measurements in JSON. A simple sensor, such as a temperature sensor, 14 could use this media type in protocols such as HTTP to transport the 15 values of a sensor. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 12, 2012. 34 Copyright Notice 36 Copyright (c) 2011 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 3 53 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5.1. Simple Example . . . . . . . . . . . . . . . . . . . . . . 6 57 5.2. Complex Example . . . . . . . . . . . . . . . . . . . . . 6 58 6. Usage Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 7.1. Units Registry . . . . . . . . . . . . . . . . . . . . . . 8 61 7.2. Media Type Registration . . . . . . . . . . . . . . . . . 11 62 7.2.1. senml+json Media Type Registration . . . . . . . . . . 11 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 64 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12 65 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 67 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 68 11.2. Informative References . . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 1. Overview 73 Connecting sensors to the internet is not new, and there have been 74 many protocols designed to facilitate it. This specification defines 75 new media types for carrying simple sensor information in a protocol 76 such as HTTP or CoAP[I-D.ietf-core-coap]. This format was designed 77 so that processors with very limited capabilities could easily encode 78 a sensor reading into the media type, while at the same time a server 79 parsing the data could relatively efficiently collect a large number 80 of sensor readings. There are many types of more complex 81 measurements and readings that this media type would not be suitable 82 for. A decision was made not to carry most of the meta data about 83 the sensor in this media type to help reduce the size of the data and 84 improve efficiency in decoding. 86 JSON[RFC4627] was selected as a basis for the encoding as it 87 represents a widely understood way of encoding data that is popular 88 in current web based APIs and represents reasonable trade-offs 89 between extensibility, simplicity, and efficiency. 91 The data is structured as a single JSON object (with attributes) that 92 contains an array of measurements. Each measurement is a JSON object 93 that has attributes such as a unique identifier for the sensor, the 94 time the measurement was made, and the current value. For example, 95 the following shows a measurement from a temperature gauge in JSON 96 syntax. 98 {"m":[{ "n": "0017f202a5c5-Temp", "v":23.5, "u":"degC" }]} 100 In the example above, the array in the object has a single 101 measurement for a sensor named "0017f202a5c5-Temp" with a temperature 102 of 23.5 degrees Celsius. 104 2. Requirements and Design Goals 106 The design goal is to be able to send simple sensor measurements in 107 small packets on mesh networks from large numbers of constrained 108 devices. Keeping the total size under 80 bytes makes this easy to 109 use on a wireless mesh network. It is always difficult to define 110 what small code is, but there is a desire to be able to implement 111 this in roughly 1 KB of flash on a 8 bit microprocessor. Experience 112 with Google power meter and other large scale deployments has 113 indicated strongly that the solution needs to support allowing 114 multiple measurements to be batched into a single HTTP request. This 115 "batch" upload capability allows the server side to efficiently 116 support a large number of devices. The multiple measurements could 117 be from multiple related sensors or from the same sensor but at 118 different times. 120 3. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 4. Semantics 128 Each media type caries a single JSON object that represents a set of 129 measurements. This object contains several optional attributes 130 described below and a mandatory array of one or more measurements. 132 bn: This is a base name string that is perpended to the names found 133 in the measurements. This attribute is optional. 134 bt: A base time that is added to the time found in a measurement. 135 This attribute is optional. 136 ver: Version number of media type format. This attribute is 137 optional positive integer and defaults to 1 if not present. 138 m: Array of measurements. Mandatory and there must be at least one 139 measurement in the array. 141 Each measurement contains several attributes, some of which are 142 optional and some of which are mandatory. 144 n: Name of sensor. When appended to the "bn" attribute, this must 145 result in a globally unique identifier for the sensor. 146 u: Units for the sensor value. Optional. Acceptable values are 147 specified in Section 7.1 148 v: Value of the sensor. Optional if an s value is present, otherwise 149 required. 150 s: Integrated sum of the sensor values over time. Optional. This 151 attribute is in the units specified in the u value multiplied by 152 seconds. 153 t: Time when measurement was made. Optional. 154 unc: The uncertainty in the measurement, that uses the same units as 155 the base; if absent, the value is unknown (i.e., don't assume that 156 this is zero). Optional. 157 c: The confidence of the measurement, as a probability between 0.0 158 and 1.0; if absent, this can be considered to be 0.95. Optional. 159 ut Update time. A time in seconds that represents the maximum time 160 before this sensor will provide an updated reading. This can be 161 used to detect the failure of sensors or communications path from 162 the sensor. Optional. 163 The bt, v, s, and t attributes are floating point numbers. Systems 164 receiving measurements MUST be able to process the range of numbers 165 that are representable as an IEEE double-precision floating-point 166 numbers [IEEE.754.1985]. The number of significant digits in any 167 measurement is not relevant, so a reading of 1.1 has exactly the same 168 semantic meaning as 1.10. If the value has an exponent, the "e" MUST 169 be in lower case. The mantissa SHOULD be less than 19 characters 170 long and the exponent SHOULD be less than 5 characters long. This 171 allows time values to have better than micro second precision over 172 the next 100 years. 174 Systems reading one of the JSON objects MUST check for the ver 175 attribute. If this value is a version number larger than the version 176 which system understands, the system SHOULD NOT use this JSON object. 177 This allows the version number to indicate that the object contains 178 mandatory to understand attributes. New version numbers can only be 179 defined in RFC which updates this specification or it successors. 181 The n value is concatenated to the bn value to get the name of the 182 sensor. The resulting name needs to uniquely identity and 183 differentiate the sensor from all others. If the name contains 48 184 bits of random material, or 48 bits of material that is procedurally 185 assigned in a unique way, it is considered to be good enough 186 uniqueness. One way to achieve this uniqueness is to include a 187 EUI-48 identifier (A MAC address) or some other 48 bit identifier 188 that is guaranteed uniqueness (such as a 1-wire address) that is 189 assigned to the device. UUIDs [RFC4122] are another way to generate 190 a unique name. 192 The resulting concatenated name MUST consist only of characters out 193 of the set "A" to "Z", "a" to "z", "0" to "9", "-", ":", ".", or "_" 194 and it MUST start with a character out of the set "A" to "Z", "a" to 195 "z", or "0" to "9". This restricted character set was chosen so that 196 these names can be directly used as in other types of URI including 197 segments of an HTTP path with no special encoding. [RFC5952] 198 contains advice on encoding an IPv6 address in a name. 200 If either the bt or t value is missing, the missing attribute is 201 considered to have a value of zero. The bt and t values are added 202 together to get the time of measurement. A time of zero indicates 203 that the sensor does not know the absolute time and the measurement 204 was made roughly "now". A negative value is used to indicate seconds 205 in the past from roughly "now". A positive value is used to indicate 206 the number of seconds, excluding leap seconds, since the start of the 207 year 1970 in UTC . 209 Representing the statistical characteristics of measurements can be 210 very complex. This specification only provides a very course grain 211 description in the c and unc attributes. Future specification may 212 add new attributes to provide better information about the 213 statistical properties of the measurement. For example, attributes 214 to specify a distribution and it's parameters could be added or a 215 attributes to carry additional properties such as the estimated root 216 mean square error. 218 5. Syntax 220 All of the data is UTF-8, but since this is for machine to machine 221 communications on constrained systems, only characters with code 222 points between U+0001 and U+007F are allowed which corresponds to the 223 ASCII[RFC0020] subset of UTF-8. 225 The contents MUST consist of exactly one JSON object as specified by 226 [RFC4627]. This object MAY contain a "bn" attribute with a value of 227 type string. This object MAY contain a "bt" attribute with a value 228 of type number. The object MAY contain other attribute value pairs. 229 The object MUST contain exactly one "m" attribute with a value of 230 type array. The array MUST have one or more measurement objects. 232 Inside each measurement object the "n" and "u" attribute are of type 233 string and the "t", "v", and "s" attributes are of type number. 235 5.1. Simple Example 237 The following shows a temperature reading taken approximately "now" 238 by a 1-wire sensor device that was assigned the unique 1-wire address 239 of 0x000801EF221E: 240 {"m":[{ "n": "000801EF221E-Temp", "v":23.5 }]} 242 5.2. Complex Example 244 The following example show the voltage at Tue Jun 8 18:01:16 UTC 2010 245 along with the current at that time and at each second for the 246 previous 5 seconds. The device has a MAC address of 0017f202b5c4. 248 {"m":[ 249 { "n": "voltage", "u": "V", 250 "v": 120.1, "anExtension": 0.0 }, 251 { "n": "current", "t": -5, "v": 1.2 }, 252 { "n": "current", "t": -4, "v": 1.30 }, 253 { "n": "current", "t": -3, "v": 0.14e1 }, 254 { "n": "current", "t": -2, "v": 1.5 }, 255 { "n": "current", "t": -1, "v": 1.6 }, 256 { "n": "current", "t": 0, "v": 1.7 } 257 ], 258 "bn": "0017f202a5c4-", 259 "bt": 1276020076, 260 "someExtensions": "a value" 261 } 263 6. Usage Considerations 265 The measurements support sending both the current value of a sensor 266 as well as the an integrated sum. For many types of measurements, 267 the sum is more useful than the current value. For example, an 268 electrical meter that measures the energy a given computer uses will 269 typically want to measure the cumulative amount of energy used. This 270 is less prone to error than reporting the power each second and 271 trying to have something on the server side sum together all the 272 power measurements. If the network between the sensor and the meter 273 goes down over some period of time, when it comes back up, the 274 cumulative sum helps reflect what happened while the network was 275 down. A meter like this would typically report a measurement with 276 the units set to watts, but it would put the sum of energy used in 277 the "s" attribute of the measurement. It might optionally include 278 the current power in the "v" attribute. 280 While the benefit of using the integrated sum is fairly clear for 281 measurements like power and energy, it is less obvious for something 282 like temperature. Reporting the sum of the temperature makes it easy 283 to compute averages even when the individual temperature values are 284 not reported frequently enough to compute accurate averages. 285 Implementors are encouraged to report the cumulative sum as well as 286 the raw value of a given sensor. 288 Applications that use the cumulative sum values need to understand 289 they are very loosely defined by this specification, and depending on 290 the particular sensor implementation may behave in unexpected ways. 291 Applications should be able to deal with the following issues: 293 1. Many sensors will allow the cumulative sums to "wrap" back to 294 zero after the value gets sufficiently large. 295 2. Some sensors will reset the cumulative sum back to zero when the 296 device is reset, loses power, or is replaced with a different 297 sensor. 298 3. Applications cannot make assumptions about when the device 299 started accumulating values into the sum. 301 Typically applications can make some assumptions about specific 302 sensors that will allow them to deal with these problems. A common 303 assumption is that for sensors whose measurement values are always 304 positive, the sum should never get smaller; so if the sum does get 305 smaller, the application will know that one of the situations listed 306 above has happened. 308 7. IANA Considerations 310 Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 311 with the RFC number of this specification. 313 7.1. Units Registry 315 IANA will create a registry of unit symbols. The primary purpose of 316 this registry is to make sure that symbols uniquely map to give type 317 of measurement. Definitions for many of these units can be found in 318 [NIST822] and [BIPM]. 320 +--------+----------------------------------------------+-----------+ 321 | Symbol | Description | Reference | 322 +--------+----------------------------------------------+-----------+ 323 | m | meter | RFC-AAAA | 324 | kg | kilogram | RFC-AAAA | 325 | s | second | RFC-AAAA | 326 | A | ampere | RFC-AAAA | 327 | K | kelvin | RFC-AAAA | 328 | cd | candela | RFC-AAAA | 329 | mol | mole | RFC-AAAA | 330 | Hz | hertz | RFC-AAAA | 331 | rad | radian | RFC-AAAA | 332 | sr | steradian | RFC-AAAA | 333 | N | newton | RFC-AAAA | 334 | Pa | pascal | RFC-AAAA | 335 | J | joule | RFC-AAAA | 336 | W | watt | RFC-AAAA | 337 | C | coulomb | RFC-AAAA | 338 | V | volt | RFC-AAAA | 339 | F | farad | RFC-AAAA | 340 | Ohm | ohm | RFC-AAAA | 341 | S | siemens | RFC-AAAA | 342 | Wb | weber | RFC-AAAA | 343 | T | tesla | RFC-AAAA | 344 | H | henry | RFC-AAAA | 345 | degC | degrees Celsius | RFC-AAAA | 346 | lm | lumen | RFC-AAAA | 347 | lx | lux | RFC-AAAA | 348 | Bq | becquerel | RFC-AAAA | 349 | Gy | gray | RFC-AAAA | 350 | Sv | sievert | RFC-AAAA | 351 | kat | katal | RFC-AAAA | 352 | pH | pH acidity | RFC-AAAA | 353 | % | Value of a switch. A value of 0.0 indicates | RFC-AAAA | 354 | | the switch is off while 100.0 indicates on. | | 355 | count | counter value | RFC-AAAA | 356 | %RH | Relative Humidity | RFC-AAAA | 357 | m2 | area | RFC-AAAA | 358 | l | volume in liters | RFC-AAAA | 359 | m/s | velocity | RFC-AAAA | 360 | m/s2 | acceleration | RFC-AAAA | 361 | l/s | flow rate in liters per second | RFC-AAAA | 362 | W/m2 | irradiance | RFC-AAAA | 363 | cd/m2 | luminance | RFC-AAAA | 364 | Bspl | bel sound pressure level | RFC-AAAA | 365 | bit/s | bits per second | RFC-AAAA | 366 | lat | degrees latitude. Assumed to be in WGS84 | RFC-AAAA | 367 | | unless another reference frame is known for | | 368 | | the sensor. | | 369 | lon | degrees longitude. Assumed to be in WGS84 | RFC-AAAA | 370 | | unless another reference frame is known for | | 371 | | the sensor. | | 372 +--------+----------------------------------------------+-----------+ 374 New entries can be added to the registration by either Expert Review 375 or IESG Approval as defined in [RFC5226]. Experts should exercise 376 their own good judgement but need to consider the following 377 guidelines: 379 1. There needs to be a real and compelling use for any new unit to 380 be added. 381 2. Units should define the semantic information and be chosen 382 carefully. Implementors need to remember that the same word may 383 be used in different real-life contexts. For example, degrees 384 when measuring latitude have no semantic relation to degrees 385 when measuring temperature; thus two different units are needed. 386 3. These measurements are produced by computers for consumption by 387 computers. The principle is that conversion has to be easily be 388 done when both reading and writing the media type. The value of 389 a single canonical representation outweighs the convenience of 390 easy human representations or loss of precision in a conversion. 391 4. Use of SI prefixes such as "k" before the unit is not allowed. 392 Instead one can represent the value using scientific notation 393 such a 1.2e3. 394 5. For a given type of measurement, there will only be one unit 395 type defined. So for length, meters are defined and other 396 lengths such as mile, foot, light year are not allowed. For 397 most cases, the SI unit is preferred. 398 6. Symbol names that could be easily confused with existing common 399 units or units combined with prefixes should be avoided. For 400 example, selecting a unit name of "mph" to indicate something 401 that had nothing to do with velocity would be a bad choice, as 402 "mph" is commonly used to mean miles per hour. 403 7. The following should not be used because the are common SI 404 prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, n, u, p, f, a, 405 z, y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, Yi. 406 8. The following units should not be used as they are commonly used 407 to represent other measurements Ky, Gal, dyn, etg, P, St, Mx, G, 408 Oe, Gb, sb, Lmb, ph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, 409 BTU, HP, pH, B/s, psi, Torr, atm, at, bar, kWh. 410 9. The unit names are case sensitive and the correct case needs to 411 be used, but symbols that differ only in case should not be 412 allocated. 414 10. A number after a unit typically indicates the previous unit 415 raised to that power, and the / indicates that the units that 416 follow are the reciprocal. A unit should have only one / in the 417 name. 419 7.2. Media Type Registration 421 The following registrations are done following the procedure 422 specified in [RFC4288] and [RFC3023]. 424 Note to RFC Editor: Please replace all occurrences of "RFC-AAAA" 425 with the RFC number of this specification. 427 7.2.1. senml+json Media Type Registration 429 To: ietf-types@iana.org 431 Subject: Registration of media type application/senml+json 433 Type name: application 435 Subtype name: senml+json 437 Required parameters: none 439 Optional parameters: none 441 Encoding considerations: Must be encoded as using a subset of the 442 encoding allowed in [RFC4627]. Specifically, only the ASCII[RFC0020] 443 subset of the UTF-8 characters are allowed. This simplifies 444 implementation of very simple system and does not impose any 445 significant limitations as all this data is meant for machine to 446 machine communications and is not meant to be human readable. 448 Security considerations: Sensor data can contain a wide range of 449 information ranging from information that is very public, such the 450 outside temperature in a given city, to very private information that 451 requires integrity and confidentiality protection, such as patient 452 health information. This format does not provide any security and 453 instead relies on the transport protocol that carries it to provide 454 security. Given applications need to look at the overall context of 455 how this media type will be used to decide if the security is 456 adequate. 458 Interoperability considerations: Applications should ignore any JSON 459 key value pairs that they do not understand. This allows backwards 460 compatibility extensions to this specification. The "ver" field can 461 be used to ensure the receiver supports a minimal level of 462 functionality needed by the creator of the JSON object. 464 Published specification: RFC-AAAA 466 Applications that use this media type: The type is used by systems 467 that report electrical power usage and environmental information such 468 as temperature and humidity. It can be used for a wide range of 469 sensor reporting systems. 471 Additional information: 473 Magic number(s): none 475 File extension(s): senml 477 Macintosh file type code(s): none 479 Person & email address to contact for further information: Cullen 480 Jennings 482 Intended usage: COMMON 484 Restrictions on usage: None 486 Author: Cullen Jennings 488 Change controller: IESG 490 8. Security Considerations 492 See Section 9.Further discussion of security proprieties can be found 493 in Section 7.2. 495 9. Privacy Considerations 497 Sensor data can range from information with almost no security 498 considerations, such as the current temperature in a given city, to 499 highly sensitive medical or location data. This specification 500 provides no security protection for the data but is meant to be used 501 inside another container or transport protocol such as S/MIME or HTTP 502 with TLS that can provide integrity, confidentiality, and 503 authentication information about the source of the data. 505 10. Acknowledgement 507 I would like to thank Lisa Dusseault, Joe Hildebrand, Lyndsay 508 Campbell, Martin Thomson, John Klensin, Bjoern Hoehrmann, and Carsten 509 Bormann for their review comments. 511 11. References 513 11.1. Normative References 515 [RFC4627] Crockford, D., "The application/json Media Type for 516 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 518 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 519 Types", RFC 3023, January 2001. 521 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 522 Registration Procedures", BCP 13, RFC 4288, December 2005. 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [IEEE.754.1985] 528 Institute of Electrical and Electronics Engineers, 529 "Standard for Binary Floating-Point Arithmetic", 530 IEEE Standard 754, August 1985. 532 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 533 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 534 May 2008. 536 11.2. Informative References 538 [I-D.ietf-core-coap] 539 Shelby, Z., Frank, B., and D. Sturek, "Constrained 540 Application Protocol (CoAP)", draft-ietf-core-coap-04 541 (work in progress), January 2011. 543 [BIPM] Bureau International des Poids et Mesures, "The 544 International System of Units (SI)", 8th edition, 2006 . 546 [NIST822] Thompson, A. and B. Taylor, "Guide for the Use of the 547 International System of Units (SI)", NIST Special 548 Publication 811, 2008 Edition . 550 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 551 Address Text Representation", RFC 5952, August 2010. 553 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 554 Unique IDentifier (UUID) URN Namespace", RFC 4122, 555 July 2005. 557 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 558 October 1969. 560 Author's Address 562 Cullen Jennings 563 Cisco 564 170 West Tasman Drive 565 San Jose, CA 95134 566 USA 568 Phone: +1 408 421-9990 569 Email: fluffy@cisco.com