idnits 2.17.1 draft-preston-ftpext-deflate-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 32. -- Found old boilerplate from RFC 3978, Section 5.5 on line 547. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 10 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 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. 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. (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 (January 2005) is 7041 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) == Unused Reference: '6' is defined on line 506, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Downref: Normative reference to an Informational RFC: RFC 1950 (ref. '5') ** Downref: Normative reference to an Informational RFC: RFC 1951 (ref. '6') ** Downref: Normative reference to an Informational RFC: RFC 2577 (ref. '9') Summary: 15 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 J. Preston 2 Internet Draft NSC 3 Document: draft-preston-ftpext-deflate-03.txt TJ Saunders 4 Expires: June 2005 January 2005 6 Deflate transmission mode for FTP 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all 11 provisions of Section 10 of RFC 2026. 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 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 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 By submitting this Internet-Draft, I certify that any applicable 30 patent or other IPR claims of which I am aware have been 31 disclosed, or will be disclosed, and any of which I become aware 32 will be disclosed, in accordance with RFC 3668. 34 Abstract 36 This document defines an optional extension to RFC 959, "FILE 37 TRANSFER PROTOCOL (FTP)" (October 1985). It specifies a new 38 "deflate" transmission mode designed to increase network bandwidth 39 by compressing data using existing techniques. 41 Table of Contents 43 1. Introduction...................................................2 44 2. Document Conventions...........................................2 45 2.1 Basic Tokens...............................................3 46 3. Deflate Transmission Mode......................................4 47 3.1 Client-server Interaction..................................4 48 3.2 Overview...................................................4 49 3.3 Compression Engine.........................................4 50 3.3.1 ZLIB Compression Engine..............................5 51 3.4 Syntax.....................................................5 52 3.5 FEAT Response..............................................6 53 3.5.1 FEAT Examples........................................6 54 3.6 OPTS Features..............................................7 55 3.6.1 Standard Opt-names...................................8 56 3.6.1.1 ENGINE Syntax..................................8 57 3.6.1.2 METHOD Syntax..................................8 58 3.6.1.3 LEVEL Syntax...................................8 59 3.6.1.4 EXTRA Syntax...................................9 60 3.6.1.5 BLOCKSIZE Syntax...............................9 61 3.6.2 OPTS Examples........................................9 62 3.7 Error Recovery and Restart................................10 63 4. Security Considerations.......................................10 64 5. References....................................................11 65 6. Copyright.....................................................11 66 7. Authors' Addresses............................................12 68 1. Introduction 70 As the Internet grows, modern devices and networking environments 71 create new performance challenges for the File Transfer Protocol 72 (FTP) [1]. One solution to this problem, which is addressed in the 73 FTP "compress" transmission mode, is to compress file and system 74 data to maximize network resources. However, the original system is 75 designed to reduce ASCII text with repetitive characters and is 76 unsuitable in many applications because it can add significant 77 network overhead to binary transfers. This document enhances the 78 capabilities of FTP by introducing a new "deflate" transmission mode 79 that: 81 * increases network throughput and decreases transfer time 83 * effectively compresses ASCII and binary data 85 * requires a minimum amount of control information 87 * provides error recovery and data integrity options 89 * includes a mechanism to negotiate compression parameters to 90 balance CPU, memory and data requirements 92 * is extensible to accommodate future compression techniques 94 2. Document Conventions 96 This document makes use of the conventions defined in BCP 14 [2] 97 which includes the explanation of capitalized imperative words MUST, 98 SHOULD, MAY, SHOULD NOT and MUST NOT. Any syntax is defined using 99 Augmented BNF (ABNF) as specified in RFC 2234 [3]. 101 The terms "reply", "user", "file", "pathname", "FTP commands", 102 "DTP", "user-FTP process", "user-PI", "user-DTP", "server-FTP 103 process", "server-PI", "server-DTP", "mode", "type", "NVT", 104 "control connection", "data connection", "transmission mode", 105 "binary" and "ASCII" are all used here as defined in STD 9 [1]. 107 In addition, this specification makes use of the terms "compression 108 engine" and "compression method." A compression engine is a 109 hardware or software component that implements a compression method. 110 The compression method is a process that reduces the size of 111 computer data. 113 2.1 Basic Tokens 115 This document imports the core definitions given in Appendix A of 116 RFC 2234 [3] which includes the ABNF elements like ALPHA, DIGIT, SP, 117 etc. The following terms are added for use in this document: 119 TCHAR = VCHAR / SP / HTAB ; visible plus white space 120 RCHAR = ALPHA / DIGIT / "," / "." / ":" / "!" / 121 "@" / "#" / "$" / "%" / "^" / 122 "&" / "(" / ")" / "-" / "_" / 123 "+" / "?" / "/" / "\" / "'" / 124 DQUOTE ; <"> -- double quote character (%x22) 125 SCHAR = RCHAR / "=" ; 127 The VCHAR (from [3]), RCHAR, SCHAR, and TCHAR types give basic 128 character types from varying sub-sets of the ASCII character set for 129 use in various commands and responses. 131 token = 1*RCHAR 133 A "token" is a string whose precise meaning depends upon the context 134 in which it is used. In some cases it will be a value from a set of 135 possible values and in others it might be a string invented by one 136 party for an FTP conversation. 138 Note that in ABNF, string literals are case insensitive. That 139 convention is preserved in this document, and implies that FTP 140 commands added by this specification have names that can be 141 represented in any case. For example, "MODE" is the same as "mode" 142 and "Mode". However, ALPHA characters are case sensitive which 143 implies a token can have an exact value. That implication is 144 correct, except where explicitly stated to the contrary in this 145 document, or in some other specification which defines the values 146 this document specifies be used in a particular context. 148 3. Deflate Transmission Mode 150 The deflate extension introduces a fourth transmission mode to FTP 151 by updating the transfer mode (MODE) command. It employs general 152 purpose compression methods to reduce data for efficient transfers. 154 The following codes are assigned for transfer modes: 156 S � Stream 157 B � Block 158 C � Compressed 159 Z � Deflate 161 The default transfer mode remains Stream. 163 3.1 Client-server Interaction 165 The user-FTP process sends the MODE Z command to request compressed 166 data transfers. If the server-FTP process accepts the request, then 167 deflate transmission mode will be used for all data transfers until 168 the client switches to another mode. 170 3.2 Overview 172 In deflate transmission mode, data is compressed and transmitted as 173 a stream of octets (8 bit bytes). The sender and receiver rely on a 174 compression engine to perform compression operations 175 (deflate/inflate) and maintain state. There is no restriction on 176 the representation type used; record structures are allowed. 178 Since there is no fixed compression format, both FTP hosts MUST 179 process data until the compression engine reports an end-of-file 180 (EOF) state or data error. Closing the data connection is not a 181 sufficient method to end transfers because there may be pending 182 information. 184 If an FTP process encounters an error while compressing or 185 decompressing the data stream, it SHOULD discard all information 186 after that point and cancel the transfer using the procedures 187 described in STD 9 [1]. 189 3.3 Compression Engine 191 Each compression engine generates a unique data stream that MAY 192 consist of the following parts: header and control information, 193 compressed data, integrity checkpoints and end-of-file (EOF) 194 markers. The compression engine MUST support an EOF mechanism and 195 MUST NOT send non-essential structures like version headers. 197 3.3.1 ZLIB Compression Engine 199 All FTP processes that support deflate transmission mode MUST 200 support the ZLIB compressed data format specified in RFC 1950 [5]. 201 The ZLIB compression method, an LZ77 variant called deflation, 202 provides a lossless compressed data format that: 204 * is independent of CPU type, operating system, file system 205 and character set and is therefore ideal for network 206 communications 208 * provides a number of different compression settings 209 (ratios are in the order of 2:1 to 5:1) that accommodates 210 a wide range of CPU, memory and data requirements 212 * minimizes control data overhead (approximately 0.02% for 213 large data streams) 215 * provides integrity checks 217 * can be implemented readily in a manner not covered by 218 patents, and hence can be practiced freely 220 In the worst case, ZLIB reverts to stored (uncompressed) blocks 221 making the deflate data stream analogous to STREAM transmission 222 mode. 224 By default, compliant FTP processes MUST support compression method 225 8 and transmit the CMF, FLG and ADLER32 information in the data 226 stream. If bandwidth or processing requirements are a concern, 227 these restrictions can be negotiated with the OPTS command. 229 3.4 Syntax 231 The deflate extension modifies the MODE command by adding the 232 parameter "Z": 234 Request: 236 mode = "MODE" SP "Z" CRLF 238 Response: 240 mode-response = mode-good / mode-bad 241 mode-good = "200" SP response-message CRLF 242 mode-bad = "451" SP response-message CRLF / 243 = "501" SP response-message CRLF 244 response-message = *TCHAR 246 A "mode-good" response (200 reply) MUST be sent when the "Z" 247 parameter is recognized and the current compression settings are 248 appropriate. An "mode-bad" response is sent in other cases. The 249 451 reply should be used when the current compression settings or 250 some other temporary condition at the server prevent the command 251 from being accepted; but a changed environment for the server-FTP 252 process may permit the command to succeed. A 501 reply is 253 appropriate for a permanent error. 255 3.5 FEAT Response 257 If the server-FTP process supports the feature (FEAT) command 258 specified in RFC 2389 [4], then it MUST include a "MODE Z" feature 259 line. This string indicates required support for the extension and 260 lists the names of additional compression engines: 262 mode-feat = SP "MODE" SP "Z" [SP eng-list] CRLF 263 eng-list = *(eng-desc ",") 264 eng-desc = 1*(eng-name eng-opts) 265 eng-name = ALPHA*(ALPHA / DIGIT / "-" / ".") 266 eng-opts = *("(" opts-list ")") 267 opts-list = 1*(opt-name ",") 268 opt-name = ALPHA*(ALPHA / DIGIT) 270 If eng-list is not present, then the server-FTP process is informing 271 the client that ZLIB is the only engine available. 273 The "MODE Z" feature line string is not case sensitive, but SHOULD 274 be transmitted in upper case. 276 In the case where the server-FTP process does not support the FEAT 277 command, the user-FTP can negotiate the deflate extension by sending 278 the "MODE Z" request. The server would respond with a positive 279 (200) reply and the default compression settings would be effective. 281 3.5.1 FEAT Examples 283 The following examples contrast three servers with deflate support. 284 The first server advertises ZLIB and BZIP2 capabilities, while the 285 second indicates the required ZLIB engine and the third implements 286 ZLIB and a proprietary compression engine. 288 C> FEAT 289 S> 211-Extensions supported: 290 S> � 291 S> MODE Z BZIP2(LEVEL,BLOCKSIZE) 292 S> � 293 S> 211 End. 295 and 297 C> FEAT 298 S> 211-Extensions supported: 299 S> � 300 S> MODE Z 301 S> � 302 S> 211 End. 304 and 306 C> FEAT 307 S> 211-Extensions supported: 308 S> � 309 S> MODE Z ENG(SETTING1,SETTING2) 310 S> � 311 S> 211 End. 313 The ellipses indicate place holders where other features may be 314 included, and are not required. A one space indentation of the 315 feature line is mandatory [4]. 317 3.6 OPTS Features 319 The user-FTP process may specify alternate compression settings with 320 the OPTS command [4]. All subsequent transfers will use these 321 settings until another OPTS request is sent. The format is 322 specified by: 324 opts = "OPTS" SP "MODE" SP "Z" [ SP 1*(name SP value ",") ] 325 name = ALPHA*(ALPHA / DIGIT) 326 value = 1*RCHAR 328 When the client sends an "OPTS MODE Z" command, the server will 329 examine each opt-name and opt-value pair and update the compression 330 engine. An OPTS request with no parameters will cause the server- 331 FTP process to revert to the default compression settings outlined 332 in this document. If the server encounters an invalid or 333 unsupported opt-name or opt-value the OPTS request will be rejected. 335 Note the server-FTP process MUST reject any MODE Z requests during 336 data transfers. 338 If the server-FTP process accepts an OPTS request, it MUST respond 339 with a positive (200) reply. Otherwise, a negative (501) response 340 should be sent. 342 The deflate extension does not require the server to support all of 343 the opt-name and opt-value parameters defined in this documented. 344 If the server-FTP process encounters an invalid or unsupported 345 option, it SHOULD return the opt-name in the error reply. In the 346 worst case, where all OPTS requests are rejected, the FTP processes 347 revert to the default compression settings. 349 If new opt-name parameters are required, the server-FTP process MUST 350 include the labels in the feature string enclosed in brackets and 351 separated by commas. For example, "MODE Z ENG(SETTING1,SETTING2)." 352 The apparatus defined in this specification should be able to handle 353 any routine compression setting. 355 3.6.1 Standard Opt-names 357 This document defines a standard set of opt-names as follows: 358 ENGINE, METHOD, LEVEL, EXTRA and BLOCKSIZE. Each opt-name is case 359 insensitive, or in other words, "ENGINE" is the same as "Engine" and 360 "engine". 362 3.6.1.1 ENGINE Syntax 364 The syntax of the ENGINE option follows: 366 eng-option = eng-label SP eng-value 367 eng-label = "ENGINE" 368 eng-value = ALPHA*(ALPHA / DIGIT / "-" / ".") 370 3.6.1.2 METHOD Syntax 372 The METHOD option allows the FTP processes to negotiate the 373 compression method. The syntax of the METHOD option follows: 375 mth-option = mth-label SP mth-value 376 mth-label = "METHOD" 377 mth-value = 1*DIGIT 379 3.6.1.3 LEVEL Syntax 381 The LEVEL option allows the FTP processes to negotiate the 382 compression level. It will influence the processing requirements 383 and length of the compressed stream. The syntax of the LEVEL option 384 follows: 386 lvl-option = lvl-label SP lvl-value 387 lvl-label = "LEVEL" 388 lvl-value = 1*DIGIT 390 3.6.1.4 EXTRA Syntax 392 The EXTRA option allows the FTP processes to negotiate the 393 transmission of non-essential compression information (like version 394 headers and trailers). This option does not apply to all compression 395 engines. The syntax of the EXTRA option follows: 397 ext-option = ext-label SP ext-value 398 ext-label = "EXTRA" 399 ext-value = ext-enable / ext-disable 400 ext-enable = "ON" 401 ext-disable = "OFF" 403 3.6.1.5 BLOCKSIZE Syntax 405 The BLOCKSIZE option is for compression engines that use block 406 sorting algorithms. It influences the compression ratio and 407 processing requirements. The syntax of the BLOCKSIZE option 408 follows: 410 blk-option = blk-label SP blk-value 411 blk-label = "BLOCKSIZE" 412 blk-value = 1*DIGIT 414 The blk-value is specified in octets. 416 3.6.2 OPTS Examples 418 The following examples illustrate how a client would change the ZLIB 419 compression options and configure a new compression engine. 421 C> OPTS MODE Z LEVEL 9 422 S> 200 MODE Z LEVEL set to 9. 423 C> OPTS MODE Z BLOCKSIZE 8192 424 S> 501 MODE Z BLOCKSIZE is not available. 425 C> OPTS MODE Z METHOD 9 426 S> 501 MODE Z METHOD 9 is invalid. 427 C> OPTS MODE Z ENGINE ZLIB LEVEL 9 EXTRA OFF 428 S> 200- MODE Z ENGINE set to ZLIB. 429 S> 200- MODE Z LEVEL set to 9. 430 S> 200 MODE Z EXTRA set to OFF. 431 C> OPTS MODE Z ENGINE ZLIB LEVEL 9 METHOD 15 432 S> 501 MODE Z METHOD 15 is invalid. 434 and 436 C> OPTS MODE Z ENGINE BZIP2 BLOCKSIZE 8192 437 S> 200- MODE Z ENGINE set to BZIP2. 438 S> 200 MODE Z BLOCKSIZE set to 8192. 440 C> OPTS MODE Z ENGINE ZLIB BLOCKSIZE 8192 441 S> 501 MODE Z BLOCKSIZE is not available. 443 3.7 Error Recovery and Restart 445 In deflate transmission mode, it is not possible to insert restart 446 markers into the data stream because they would be indistinguishable 447 from compressed data, and the user-FTP can alter the data 448 representation by changing compression settings between transfers. 449 However, it is possible to define a restart mechanism by specifying 450 a byte offset into the uncompressed data stream. 452 The logic for this system is similar to the restart mechanisms 453 specified in RFC 1123 [7] and other Internet Drafts [8] for STREAM 454 transmission mode with the following addendum. In a compressed data 455 stream, the output will always be exactly the same as the input, 456 thus an offset will always represent the same position within a 457 file. 459 If the user-FTP process plans to restart a retrieve (RETR) request, 460 it will directly calculate the restart marker, and send the 461 uncompressed offset in the restart (REST) command. The server will 462 skip to the specified file position. When the transfer continues, 463 both FTP processes will operate with a new compressed data stream. 465 The store (STOR) process works in the same manner as the retrieve 466 system. However, the sender must determine how much data was 467 previously received and expanded, with the SIZE [8] command or an 468 alternate method, before resuming the transfer. 470 4. Security Considerations 472 The deflate extension does not introduce any protocol related 473 security issues. However, some compression settings may impose a 474 considerable load on the FTP server, which could lead to denial of 475 service attacks, and compression engines not described in this 476 document may contain security vulnerabilities. If these operational 477 risks are a concern, then implementers should consider limiting 478 server resources or denying problematic settings. 480 In some cases, deflate transmission mode can reduce the demands on 481 the server. For example, in a secure FTP session, the combined 482 process of compressing and encrypting data is less expensive than 483 sending raw encrypted data; and fewer secure renegotiations are 484 required because of the shorter transfer times. 486 A general discussion of issues related to the security of FTP can be 487 found in RFC 2577 [9]. 489 5. References 491 [1] Postel, J., Reynolds, J., "File Transfer Protocol (FTP)", STD 9, 492 RFC 959, October 1985 494 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 495 Levels", BCP 14, RFC 2119, March 1997 497 [3] Crocker, D., Overell, P., "Augmented BNF for Syntax 498 Specifications: ABNF", RFC 2234, November 1997 500 [4] Hethmon, P., Elz, R., "Feature negotiation mechanism for the 501 File Transfer Protocol", RFC 2389, August 1998 503 [5] Deutsch, P., "ZLIB Compressed Data Format Specification version 504 3.3", RFC 1950, May 1996 506 [6] Deutsch, P., "DEFLATE Compressed Data Format Specification 507 version 1.3", RFC 1951, May 1996 509 [7] Braden, R., "Requirements for Internet Hosts -- Application and 510 Support", RFC 1123, October 1989 512 [8] P., Elz, R., Hethmon, "Extensions to FTP", Internet Draft 513 (draft-ietf-ftpext-mlst-16), September 2002 515 [9] Allman, M., Ostermann, S., "FTP Security Considerations", RFC 516 2577, May 1999 518 6. Copyright 520 Copyright (C) The Internet Society (2005). This document is subject 521 to the rights, licenses and restrictions contained in BCP 78, and 522 except as set forth therein, the authors retain all their rights. 524 This document and translations of it may be copied and furnished to 525 others, and derivative works that comment on or otherwise explain it 526 or assist in its implementation may be prepared, copied, published 527 and distributed, in whole or in part, without restriction of any 528 kind, provided that the above copyright notice and this paragraph 529 are included on all such copies and derivative works. However, this 530 document itself may not be modified in any way, such as by removing 531 the copyright notice or references to the Internet Society or other 532 Internet organizations, except as needed for the purpose of 533 developing Internet standards in which case the procedures for 534 copyrights defined in the Internet Standards process must be 535 followed, or as required to translate it into languages other than 536 English. 538 The limited permissions granted above are perpetual and will not be 539 revoked by the Internet Society or its successors or assigns. 541 This document and the information contained herein are provided on 542 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 543 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 544 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 545 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 546 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 547 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 7. Authors' Addresses 551 Jeff Preston 552 NSC 553 23 Fielding Drive 554 Aurora, Ontario. L4G 4Z4 556 EMail: jpreston@nsctech.com 558 TJ Saunders 559 23525 24th Ave W 560 Brier, WA 98036 562 EMail: tj@castaglia.org