idnits 2.17.00 (12 Aug 2021) /tmp/idnits10557/draft-ietf-appsawg-xdash-04.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 (March 12, 2012) is 3721 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'BCP26') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1154 (Obsoleted by RFC 1505) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2426 (Obsoleted by RFC 6350) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4395 (Obsoleted by RFC 7595) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 APPSAWG P. Saint-Andre 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: BCP D. Crocker 5 Expires: September 13, 2012 Brandenburg InternetWorking 6 M. Nottingham 7 Rackspace 8 March 12, 2012 10 Deprecating the X- Prefix and Similar Constructs in Application 11 Protocols 12 draft-ietf-appsawg-xdash-04 14 Abstract 16 Historically, designers and implementers of application protocols 17 have often distinguished between "standard" and "non-standard" 18 parameters by prefixing the names of "non-standard" parameters with 19 the string "X-" or similar constructs. In practice, that convention 20 causes more problems than it solves. Therefore, this document 21 deprecates the convention for the names of newly-defined textual 22 parameters in application protocols. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 13, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Recommendations for Implementers of Application Protocols . . 3 60 3. Recommendations for Creators of New Parameters . . . . . . . . 4 61 4. Recommendations for Protocol Designers . . . . . . . . . . . . 4 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 68 Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 8 69 Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 9 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction 74 Many application protocols use parameters with textual names to 75 identify data (media types, header fields in Internet mail messages 76 and HTTP requests, vCard parameters and properties, etc.). 77 Historically, designers and implementers of application protocols 78 have often distinguished between "standard" and "non-standard" 79 parameters by prefixing the names of "non-standard" parameters with 80 the string "X-" or similar constructs (e.g., "x."), where the "X" is 81 commonly understood to stand for "eXperimental" or "eXtension". That 82 is, instead of just identifying the data, the name also embedded the 83 status of the name as "non-standard" into the name itself. 85 Although in theory the "X-" convention was a good way to avoid 86 collisions (and attendant interoperability problems) between standard 87 parameters and non-standard parameters, in practice the benefits have 88 been outweighed by the costs associated with the leakage of non- 89 standard parameters into the standards space. Therefore this 90 document deprecates the "X-" convention for named parameters in 91 application protocols and makes specific recommendations about how to 92 proceed in a world without the distinction between standard and non- 93 standard parameters. Note that this document covers only parameters 94 with textual names, not parameters that are expressed as numbers. In 95 addition, this document does not recommend against the practice of 96 private, local, preliminary, experimental, or implementation-specific 97 parameters, only against the use of "X-" and similar constructs in 98 the names of such parameters. Finally, this document makes no 99 recommendation as to whether existing "X-" parameters ought to remain 100 in use or be migrated to a format without the "X-". 102 See Appendix A for background information about the history of the 103 "X-" convention, and Appendix B for the reasoning that led to the 104 recommendations in this document. 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in 109 [RFC2119]. 111 2. Recommendations for Implementers of Application Protocols 113 Implementations of application protocols MUST NOT programatically 114 discriminate between "standard" and "non-standard" parameters based 115 solely on the names of such parameters (i.e., based solely on whether 116 the name begins with 'x-' or a similar string of characters). 118 3. Recommendations for Creators of New Parameters 120 Creators of new parameters to be used in the context of application 121 protocols: 123 1. SHOULD assume that all parameters they create might become 124 standardized, public, commonly deployed, or used across multiple 125 implementations. 127 2. SHOULD employ meaningful names that they have reason to believe 128 are currently unused (without the "X-" prefix or similar 129 constructs). 131 Note: If the relevant parameter name space has conventions about 132 associating parameter names with those who create them, a parameter 133 name could incorporate the organization's name or primary domain name 134 (see Appendix B for examples). 136 4. Recommendations for Protocol Designers 138 Designers of new application protocols that allow extensions using 139 parameters: 141 1. SHOULD establish registries with potentially unlimited value- 142 spaces, if appropriate including both permanent and provisional 143 registries. 145 2. SHOULD define simple, clear registration procedures. 147 3. SHOULD mandate registration of all non-private parameters, 148 independent of the form of the parameter names. 150 4. SHOULD NOT prohibit parameters with the "X-" prefix or similar 151 constructs from being registered with the IANA. 153 5. MUST NOT assume that a parameter with an "X-" prefix or similar 154 constructs is non-standard. 156 6. MUST NOT assume that a parameter without an "X-" prefix or 157 similar constructs is standard. 159 5. Security Considerations 161 Interoperability and migration issues with security-critical 162 parameters can result in unnecessary vulnerabilities (see Appendix B 163 for further discussion). 165 As a corollary to the recommendation provided under Section 2, 166 implementations MUST NOT assume that "standard" parameters are 167 "secure" whereas "non-standard" parameters are "insecure", based 168 solely on the names of such parameters. 170 6. IANA Considerations 172 This document does not modify registration procedures currently in 173 force for various application protocols. However, such procedures 174 might be updated in the future to incorporate the best practices 175 defined in this document. 177 7. Acknowledgements 179 Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric 180 Burger, Stuart Cheshire, Al Constanzo, Dave Cridland, Martin Duerst, 181 Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch, Randall Gellens, 182 Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Hoenes, Paul Hoffman, 183 Eric Johnson, Scott Kelly, Scott Kitterman, John Klensin, Graham 184 Klyne, Murray Kucherawy, Eliot Lear, John Levine, Bill McQuillan, 185 Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Ben Niven- 186 Jenkins, Zoltan Ordogh, Tim Petch, Dirk Pranke, Randy Presuhn, Julian 187 Reschke, Doug Royer, Andrew Sullivan, Martin Thomson, Matthew Wild, 188 Nicolas Williams, Tim Williams, Mykyta Yevstifeyev, and Kurt Zeilenga 189 for their feedback. 191 8. References 193 8.1. Normative References 195 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 196 Requirement Levels", BCP 14, RFC 2119, March 1997. 198 8.2. Informative References 200 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 201 3", BCP 9, RFC 2026, October 1996. 203 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an 204 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 205 May 2008. 207 [BCP82] Narten, T., "Assigning Experimental and Testing Numbers 208 Considered Useful", BCP 82, RFC 3692, January 2004. 210 [RFC691] Harvey, B., "One more try on the FTP", RFC 691, June 1975. 212 [RFC737] Harrenstien, K., "FTP extension: XSEN", RFC 737, 213 October 1977. 215 [RFC743] Harrenstien, K., "FTP extension: XRSQ/XRCP", RFC 743, 216 December 1977. 218 [RFC775] Mankins, D., Franklin, D., and A. Owen, "Directory 219 oriented FTP commands", RFC 775, December 1980. 221 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 222 text messages", STD 11, RFC 822, August 1982. 224 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 225 and Support", STD 3, RFC 1123, October 1989. 227 [RFC1154] Robinson, D. and R. Ullmann, "Encoding header field for 228 internet messages", RFC 1154, April 1990. 230 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 231 Extensions (MIME) Part One: Format of Internet Message 232 Bodies", RFC 2045, November 1996. 234 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 235 Extensions (MIME) Part Two: Media Types", RFC 2046, 236 November 1996. 238 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 239 Part Three: Message Header Extensions for Non-ASCII Text", 240 RFC 2047, November 1996. 242 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 243 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 244 RFC 2068, January 1997. 246 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 247 RFC 2426, September 1998. 249 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 250 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 251 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 253 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 254 April 2001. 256 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 257 of New DHCP Options and Message Types", BCP 43, RFC 2939, 258 September 2000. 260 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 261 "Uniform Resource Names (URN) Namespace Definition 262 Mechanisms", BCP 66, RFC 3406, October 2002. 264 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 265 and B. Rosen, "Change Process for the Session Initiation 266 Protocol (SIP)", RFC 3427, December 2002. 268 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 269 Procedures for Message Header Fields", BCP 90, RFC 3864, 270 September 2004. 272 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 273 Resource Identifier (URI): Generic Syntax", STD 66, 274 RFC 3986, January 2005. 276 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 277 Unique IDentifier (UUID) URN Namespace", RFC 4122, 278 July 2005. 280 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 281 Registration Procedures", BCP 13, RFC 4288, December 2005. 283 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 284 Registration Procedures for New URI Schemes", BCP 35, 285 RFC 4395, February 2006. 287 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 288 (LDAP): Directory Information Models", RFC 4512, 289 June 2006. 291 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 292 Description Protocol", RFC 4566, July 2006. 294 [RFC5064] Duerst, M., "The Archived-At Message Header Field", 295 RFC 5064, December 2007. 297 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 298 Message Authentication Status", RFC 5451, April 2009. 300 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 301 Languages", BCP 47, RFC 5646, September 2009. 303 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 304 for the Session Initiation Protocol (SIP) and the Real- 305 time Applications and Infrastructure Area", BCP 67, 306 RFC 5727, March 2010. 308 Appendix A. Background 310 The beginnings of the "X-" convention can be found in a suggestion 311 made by Brian Harvey in 1975 with regard to FTP parameters [RFC691]: 313 Thus, FTP servers which care about the distinction between Telnet 314 print and non-print could implement SRVR N and SRVR T. Ideally the 315 SRVR parameters should be registered with Jon Postel to avoid 316 conflicts, although it is not a disaster if two sites use the same 317 parameter for different things. I suggest that parameters be 318 allowed to be more than one letter, and that an initial letter X 319 be used for really local idiosyncracies. 321 This "X" prefix was subsequently used in [RFC737], [RFC743], and 322 [RFC775]. This usage was noted in [RFC1123]: 324 FTP allows "experimental" commands, whose names begin with "X". 325 If these commands are subsequently adopted as standards, there may 326 still be existing implementations using the "X" form.... All FTP 327 implementations SHOULD recognize both forms of these commands, by 328 simply equating them with extra entries in the command lookup 329 table. 331 The "X-" convention has been used for email header fields since at 332 least the publication of [RFC822] in 1982, which distinguished 333 between "Extension-fields" and "user-defined-fields" as follows: 335 The prefatory string "X-" will never be used in the names of 336 Extension-fields. This provides user-defined fields with a 337 protected set of names. 339 That rule was restated by [RFC1154] as follows: 341 Keywords beginning with "X-" are permanently reserved to 342 implementation-specific use. No standard registered encoding 343 keyword will ever begin with "X-". 345 This convention continued with various specifications for media types 346 ([RFC2045], [RFC2046], [RFC2047]), HTTP headers ([RFC2068], 347 [RFC2616]), vCard parameters and properties ([RFC2426]), Uniform 348 Resource Names ([RFC3406]), LDAP field names ([RFC4512]), and other 349 application technologies. 351 However, use of the "X-" prefix in email headers was effectively 352 deprecated between the publication of [RFC822] in 1982 and the 353 publication of [RFC2822] in 2001 by removing the distinction between 354 the "extension-field" construct and the "user-defined-field" 355 construct (a similar change happened with regard to Session 356 Initiation Protocol "P-" headers when [RFC3427] was obsoleted by 357 [RFC5727]). 359 Despite the fact that parameters containing the "X-" string have been 360 effectively deprecated in email headers, they continue to be used in 361 a wide variety of application protocols. The two primary situations 362 motivating such use are: 364 1. Experiments that are intended to possibly be standardized in the 365 future, if they are successful. 367 2. Extensions that are intended to never be standardized because 368 they are intended only for implementation-specific use or for 369 local use on private networks. 371 Use of this naming convention is not mandated by the Internet 372 Standards Process [BCP9] or IANA registration rules [BCP26]. Rather 373 it is an individual choice by each specification that references the 374 convention or each administrative process that chooses to use it. In 375 particular, some standards-track RFCs have interpreted the convention 376 in a normative way (e.g., [RFC822] and [RFC5451]). 378 Appendix B. Analysis 380 The primary problem with the "X-" convention is that non-standard 381 parameters have a tendency to leak into the protected space of 382 standard parameters (whether de jure or de facto), thus introducing 383 the need for migration from the "X-" name to the standard name. 384 Migration, in turn, introduces interoperability issues (and sometimes 385 security issues) because older implementations will support only the 386 "X-" name and newer implementations might support only the standard 387 name. To preserve interoperability, newer implementations simply 388 support the "X-" name forever, which means that the non-standard name 389 has become a de facto standard (thus obviating the need for 390 segregation of the name space into "standard" and "non-standard" 391 areas in the first place). 393 We have already seen this phenomenon at work with regard to FTP in 394 the quote from [RFC1123] in the previous section. The HTTP community 395 had the same experience with the "x-gzip" and "x-compress" media 396 types, as noted in [RFC2068]: 398 For compatibility with previous implementations of HTTP, 399 applications should consider "x-gzip" and "x-compress" to be 400 equivalent to "gzip" and "compress" respectively. 402 A similar example can be found in [RFC5064], which defined the 403 "Archived-At" message header field but also found it necessary to 404 define and register the "X-Archived-At" field: 406 For backwards compatibility, this document also describes the 407 X-Archived-At header field, a precursor of the Archived-At header 408 field. The X-Archived-At header field MAY also be parsed, but 409 SHOULD NOT be generated. 411 One of the original reasons for segregation of name spaces into 412 standard and non-standard areas was the perceived difficulty of 413 registering names. However, the solution to that problem has been 414 simpler registration rules, such as those provided by [RFC3864] and 415 [RFC4288]. As explained in [RFC4288]: 417 [W]ith the simplified registration procedures described above for 418 vendor and personal trees, it should rarely, if ever, be necessary 419 to use unregistered experimental types. Therefore, use of both 420 "x-" and "x." forms is discouraged. 422 For some name spaces, another helpful practice has been the 423 establishment of separate registries for permanent names and 424 provisional names, as in [RFC4395]. 426 Furthermore, often standardization of a non-standard parameter leads 427 to subtly different behavior (e.g., the standard version might have 428 different security properties as a result of security review provided 429 during the standardization process). If implementers treat the old, 430 non-standard parameter and the new, standard parameter as equivalent, 431 interoperability and security problems can ensue. Analysis of non- 432 standard parameters to detect and correct flaws is in general a good 433 thing and is not intended to be discouraged by the lack of 434 distinction in element names. Whenever an originally non-standard 435 parameter or protocol element is standardized and the new form has 436 differences which affect interoperability or security properties, 437 implementations MUST NOT treat the old form as identical to the new 438 form. 440 For similar considerations with regard to the "P-" convention in the 441 Session Initiation Protocol, see [RFC5727]. 443 In some situations, segregating the parameter name space used in a 444 given application protocol can be justified: 446 1. When it is extremely unlikely that some parameters will ever be 447 standardized. In this case implementation-specific and private- 448 use parameters could at least incorporate the organization's name 449 (e.g., "ExampleInc-foo" or, consistent with [RFC4288], 450 "VND.ExampleInc.foo") or primary domain name (e.g., 451 "com.example.foo" or a Uniform Resource Identifier [RFC3986] such 452 as "http://example.com/foo"). In rare cases, truly experimental 453 parameters could be given meaningless names such as nonsense 454 words, the output of a hash function, or UUIDs [RFC4122]. 456 2. When parameter names might have significant meaning. This case 457 too is rare, since implementers can almost always find a synonym 458 for an existing term (e.g., "urgency" instead of "priority") or 459 simply invent a more creative name (e.g., "get-it-there-fast"). 460 The existence of multiple similarly-named paramaters can be 461 confusing, but this is true regardless if there is an attempt to 462 segregate standard and non-standard (e.g., "X-Priority" can be 463 confused with "Urgency"). 465 3. When parameter names need to be very short (e.g., as in [RFC5646] 466 for language tags). In this case it can be more efficient to 467 assign numbers instead of human-readable names (e.g., as in 468 [RFC2939] for DCHP options) and to leave a certain numeric range 469 for implementation-specific extensions or private use (e.g., as 470 with the codec numbers used with the Session Description Protocol 471 [RFC4566]). 473 There are three primary objections to deprecating the "X-" convention 474 as a best practice for application protocols: 476 1. Implementers might mistake one parameter for another parameter 477 that has a similar name; a rigid distinction such as an "X-" 478 prefix can make this clear. However, in practice implementers 479 are forced to blur the distinction (e.g., by treating "X-foo" as 480 a de facto standard) and so it inevitably becomes meaningless. 482 2. Collisions are undesirable and it would be bad for both a 483 standard parameter "foo" and a non-standard parameter "foo" to 484 exist simultaneously. However, names are almost always cheap, so 485 an experimental, implementation-specific, or private-use name of 486 "foo" does not prevent a standards development organization from 487 issuing a similarly creative name such as "bar". 489 3. [BCP82] is entitled "Assigning Experimental and Testing Numbers 490 Considered Useful" and therefore implies that the "X-" prefix is 491 also useful for experimental parameters. However, BCP 82 492 addresses the need for protocol numbers when the pool of such 493 numbers is strictly limited (e.g., DHCP options) or when a number 494 is absolutely required even for purely experimental purposes 495 (e.g., the Protocol field of the IP header). In almost all 496 application protocols that make use of protocol parameters 497 (including email headers, media types, HTTP headers, vCard 498 parameters and properties, URNs, and LDAP field names), the name 499 space is not limited or constrained in any way, so there is no 500 need to assign a block of names for private use or experimental 501 purposes (see also [BCP26]). 503 Therefore it appears that segregating the parameter space into a 504 standard area and a non-standard area has few if any benefits, and 505 has at least one significant cost in terms of interoperability. 507 Authors' Addresses 509 Peter Saint-Andre 510 Cisco Systems, Inc. 511 1899 Wynkoop Street, Suite 600 512 Denver, CO 80202 513 USA 515 Phone: +1-303-308-3282 516 Email: psaintan@cisco.com 518 D. Crocker 519 Brandenburg InternetWorking 520 675 Spruce Dr. 521 Sunnyvale 522 USA 524 Phone: +1.408.246.8253 525 Email: dcrocker@bbiw.net 526 URI: http://bbiw.net 528 Mark Nottingham 529 Rackspace 531 Email: mnot@mnot.net 532 URI: http://www.mnot.net