Network Working Group N. Soriano Internet-Draft AAMSX Expires: April 1, 2005 October 1, 2004 Simple Partition Transfer Protocol (SPTP) draft-nsoriano-sptp-00 Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 1, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document presents a protocol intended to transfer the whole contents of a disk partition (or the whole directory tree placed under a given directory on the disk) to a backup server. The protocol lies on top of TCP or other stream-oriented transport protocol, and is based on the exchange of messages between the client (the host sending data) and the server (the host storing the received data). Soriano Expires April 1, 2005 [Page 1] Internet-Draft Simple Partition Transfer Protocol October 2004 IANA considerations This protocol requires a well-known TCP port on which SPTP servers accept connections from SPTP clients. This document specifies 115 as a provisional value for this port number; this is currently reserved for the Simple File Transfer Protocol (SFTP, RFC913), which has been marked as historical, so it is not expected that any host will have this port in use nowadays. However, in the event that SPTP becomes of public interest and evolves to a RFC, IANA should officially assign a new, definitive TCP port number for the SPTP service. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Protocol overview and features . . . . . . . . . . . . . . 4 1.3 Keywords used in this document . . . . . . . . . . . . . . 5 2. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 6 2.1 General operation . . . . . . . . . . . . . . . . . . . . 6 2.2 Messages summary . . . . . . . . . . . . . . . . . . . . . 7 2.3 The semantics of DSTA, FILE and DEND . . . . . . . . . . . 9 2.4 The semantics of CRST and SRST . . . . . . . . . . . . . . 11 2.5 The semantics of CBYE and SBYE . . . . . . . . . . . . . . 11 2.6 Storage strategy . . . . . . . . . . . . . . . . . . . . . 12 2.7 The "server silent unless error arises" strategy . . . . . 13 2.8 Authentication . . . . . . . . . . . . . . . . . . . . . . 14 2.9 Protocol extensions . . . . . . . . . . . . . . . . . . . 15 3. Protocol specification . . . . . . . . . . . . . . . . . . . . 18 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2 Client protocol . . . . . . . . . . . . . . . . . . . . . 18 3.3 Server protocol . . . . . . . . . . . . . . . . . . . . . 21 3.4 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.5 Message format . . . . . . . . . . . . . . . . . . . . . . 25 4. Security considerations . . . . . . . . . . . . . . . . . . . 32 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1 Normative references . . . . . . . . . . . . . . . . . . . . 33 5.2 Informative references . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 33 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 Intellectual Property and Copyright Statements . . . . . . . . 35 Soriano Expires April 1, 2005 [Page 2] Internet-Draft Simple Partition Transfer Protocol October 2004 1. Introduction 1.1 Motivation Recently, an Ethernet card has been produced for MSX computers, and a TCP/IP stack has been developed to take profit of this card (see author's home page). MSX are Z80 based computers which usually run MSX-DOS, an MS-DOS-like operating system whose only supported file system is FAT12 (see for more information on MSX computers). Most MSX users have plugged SCSI or IDE cards to their computers, which allow them to use hard disks and other similar massive storage devices. It is frequent that these users have also a more powerful, general-purpose computer (the term "PC" will be used hereinafter to refer them; we are speaking about IBM PC compatibles, Macintosh, Amiga, etc) and it is a good idea to use these computers to store a backup of the MSX hard disk; this makes sense since modern PCs have hard disk capacities on the order of thousands of gigabytes, whilst MSX hard disks usually have only a few 32MB partitions (this is the maximum partition size supported by the FAT12 file system), not to mention that at present it is not possible to burn CD/DVD-ROM with a MSX computer. Until now the solutions to transfer files from a MSX to a PC were not practical: either diskettes had to be used, or the hard disk had to be removed from the MSX and inserted on the PC (assuming that the PC would recognize -and not smash!- the FAT12 partitions), or a terminal program had to be used to transfer single files via RS232 null cable and a protocol like XMODEM (at present there is no USB interface available for MSX computers, so pen drives and other similar storage devices can't be used for this purpose). The appearance of a network interface and a TCP/IP stack for MSX opens a new spread of possibilities; existing protocols like FTP [6] and TFTP [7] may be used to transfer files to a PC attached to a local network or placed anywhere on the internet. However, these protocols are only useful to transfer single files (FTP) or multiple files that are placed on the same directory on the disk (FTP). Therefore, a new protocol specifically designed to transfer whole disk partitions (or the whole directory tree placed under a given directory on the disk) has been designed: SPTP, Simple Partition Transfer Protocol. The goal was to have a protocol that is not as simple as TFTP but not as complex as FTP, and whose intended use would be to backup complete disk partitions to a backup server. Soriano Expires April 1, 2005 [Page 3] Internet-Draft Simple Partition Transfer Protocol October 2004 1.2 Protocol overview and features SPTP was designed having in mind the fact that MSX computers were the main implementation targets; these computers have poor processing capabilities and are usually programmed using the assembler language, so the protocol had to be as simple as possible (but complete enough to be really useful). Despite this, the resulting protocol may be useful to transfer data between any sort of computers, since directories and files are treated in a generic way by the protocol and none of the features specific to the FAT12 file system are used (except for the file attributes, but this could be solved with the future definition of a protocol extension, as discussed in Section 2.9). SPTP is a one-way transfer protocol: the client only sends files, and the server only receives these files and stores them. When communication in the opposite direction is desired, then the client must assume the role of the server, and vice versa. SPTP lies on top of a stream-oriented transport protocol (TCP will be assumed to be the used protocol hereinafter), and the protocol operation is based on the exchange of binary messages between client and server; these messages are embedded in the TCP data flow and they consist of a mixture of fixed-length fields and variable-length strings whose length is specified in advance, so it is always possible to exactly know where a message starts and ends. The contents of the files to be transferred is part of one of these messages. Despite its name, SPTP can be used to transfer not only complete disk partitions, but also single directories; the point here is that all files and sub-directories placed under the "main" directory being transferred are transferred as well, and the complete path of each file of directory is preserved (as well as the file creation date/time and optionally the file attributes). In this document, the term "partition transfer" will be used with the meaning of "transfer of the whole contents of a disk partition or all the files and sub-directories placed under a given directory". The length of single directory and file names may be up to 255 bytes (this will be 255 characters or less depending on the character set used); there is no limit for the length of the complete pathname of a file, since only single directory and file names are actually transferred. An incremental system is used to indicate that a new sub-directory is about to be transferred. Provision is made for client authentication, and for specifying the character set in which directory and file names and texts for the Soriano Expires April 1, 2005 [Page 4] Internet-Draft Simple Partition Transfer Protocol October 2004 user are encoded (for text strings sent by the server, the language can also be specified). Also, a protocol extension mechanism is provided to add new features (or modify existing features) to the protocol in the future. 1.3 Keywords used in this document The capitalized keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY" and "OPTIONAL" used in this document are to be interpreted as specified in RFC2119 [3]. US-ASCII is the character set specified in RFC20 [5]. Soriano Expires April 1, 2005 [Page 5] Internet-Draft Simple Partition Transfer Protocol October 2004 2. Protocol operation 2.1 General operation A SPTP session starts when a client opens a connection to the SPTP server port (115 when using TCP -- this is a provisional value, see "IANA considerations" section). The server sends a WELC message indicating the authentication methods it supports, the name of the character set and language it will use to encode the text strings it transfers, and the supported protocol extensions. The client replies with a HELO message containing authentication information, the name of the character set it will use to encode the directory and file names it transfers, and the protocol extensions it is willing to use. If this message is acceptable to the server, then it sends a SGOK message and both parts enter the INITIAL state (there are separate protocol automatons for client and server, but both have an INITIAL state). If the client does not recognize the authentication method indicated in the WELC message, then it sends a CBYE message and closes the TCP connection (if the client does not recognize the character set indicated in the WELC message, it may choose to close the connection or to continue the session initiation and ignore any text string sent by the server). If the server does not recognize the character set indicated in the HELO message, or if the authentication information is wrong, then it sends a SBYE message and closes the TCP connection. The client and the server MUST recognize at least the US-ASCII character set. Once in the INITAL state, the client performs zero or more partition transfers, after which it closes the TCP connection having previously sent a CBYE message. A partition transfer starts when the client sends a PSTA (partition start) message to the server; this message includes the name of the partition and its maximum size, that is, the maximum combined size of all the files to be transferred. If the server cannot store this partition, because it has not enough free disk space or for any other reason, then it sends a SRST message and both parts return to the INITIAL state. If the server agrees on storing the partition data, then it sends a SGOK or a PEXS message, then enters the RECEIVING state. Both messages are equivalent, except that by sending PEXS the server is warning the client of the fact that data for a partition with the specified name already exists, and that by proceeding with the transfer, the existing data will be erased. If the client receives PEXS and does not want to overwrite the existing data, then it sends Soriano Expires April 1, 2005 [Page 6] Internet-Draft Simple Partition Transfer Protocol October 2004 a SRST message and both parts return to the INITIAL state. If the client agrees to overwrite the existing data, or if it received a SGOK message, then it enters the SENDING message. Once the server is in the RECEIVING state and the client is in the SENDING state, data transfer can start. Data transfer is achieved by sending DSTA (directory start), FILE (file data) and DEND (directory end) messages. The server receives the files and directories and stores them, not sending any message if no errors arise. In case of error, the server asynchronously sends a SRST message and enters the ABORTING state; it then ignores all the received data until a CRST message arrives from the client, meaning that the client acknowledges the transfer abort. While sending data, the client must periodically check if a message has been received from the server. Once all the partition data has been transferred, the client sends a PEND (partition end) message and waits for a SGOK (partition transfer completed successfully) or SRST (an error occurred) message to be received from the server, then both parts return to the INITIAL state. On any state, the reception of an unexpected SRST (server reset) or CRST (client reset) message by the client or the server, respectively, causes the recipient to send a CRST or SRST message in response and both parts return to the INITIAL state. Reception or other unexpected message, or reception of an unknown message, causes the TCP connection to be immediately closed, previously sending a SBYE or a CBYE message. At any time, both parts can send a SBYE or CBYE message and close the TCP connection, if by any circumstance they cannot continue sending or receiving data (for example, if the system is going to be shut down immediately). A client must not assume that a partition has been successfully transferred until it receives a SGOK message in response to a PEND message. 2.2 Messages summary The list of all the SPTP messages and the purpose of each one is given below; the number of each message in the list is also the message code. The exact format of each message is given in Section 3.5. 1. WELC: Welcome Sent by server immediately after accepting a connection from a client. Contains information about the character set and language that the server will use for the strings it sends, the Soriano Expires April 1, 2005 [Page 7] Internet-Draft Simple Partition Transfer Protocol October 2004 supported authentication methods, and the list of supported extensions. 2. HELO: Hello Sent by client in response to a WELC message. Contains information about the character set that the client will use for the strings it sends, as well as authentication data if necessary and the list of accepted extensions. 3. SBYE: Server bye Sent by server when it is about to close the connection by any reason other than receiving a CBYE message. 4. CBYE: Client bye Sent by client when it is about to close the connection by any reason other than receiving a SBYE message. 5. SRST: Server reset Sent by server when it wants to reject or abort a partition transfer, or to return to the INITIAL state for any other reason. 6. CRST: Client reset Sent by client when it wants to force or acknowledge a partition transfer abort, or to return to the INITIAL state for any other reason. 7. PSTA: Partition start Sent by client to request beginning the transmission of a partition. 8. SGOK: Server generic OK Sent by server to positively acknowledge a previously received PSTA, HELO or PEND message. 9. PEXS: Partition exists Sent by server in response to a previously received PSTA message, indicates that the partition data already exists in the server, and that the existing data will be erased if the client proceeds with the transfer. Soriano Expires April 1, 2005 [Page 8] 10. DSTA: Directory start Sent by client to indicate that a new directory starts in the directory hierarchy of the partition being sent, and that files and directories sent from that moment pertain to that directory. 11. FILE: File data Sent by client, contains the data for one of the files to be stored by the server. 12. DEND: Directory end Sent by client, indicates that files sent from that moment pertain to the parent directory relative to the current directory in the hierarchy of the partition being sent. 13. PEND: Partition end Sent by client, indicates that the partition transfer has finished. 2.3 The semantics of DSTA, FILE and DEND A partition transfer is achieved by sending DSTA (directory start), FILE (file data) and DEND (directory end) messages from the client to the server. These messages are sent in the appropriate order and reflect the directory hierarchy of the partition being transferred. The client starts sending the files in the root directory of the partition by using FILE messages; each FILE message contains the file name, creation date and time, and attributes, as well as the file contents itself. When the client finds a sub-directory to be transferred, then it sends a DSTA message; a DSTA message contains the directory name, creation date and time, and attributes. After sending DSTA, the client sends the files present in this directory with FILE messages. If again a sub-directory is found inside the sub-directory, then again a DSTA message is sent and the contents of this new sub-directory are sent from that moment. When all the contents of the current sub-directory have been sent, the client sends a DEND message. This indicates to the server that the client is going back one level in the directory hierarchy, or in other words, it is switching to the parent directory of the current directory. So using the Unix shell analogy, DSTA "directory" equivals to "mkdir directory && cd directory", FILE "file" equivals to "cp file .", and Soriano Expires April 1, 2005 [Page 9] Internet-Draft Simple Partition Transfer Protocol October 2004 DEND equivals to "cd ..". For example, assume that a partition with the following contents is to be transferred: /file1 /file2 /directory1/file3 /directory1/file4 /directory1/directory2/file5 /directory1/directory2/file6 /directory1/directory3/file7 /directory1/directory3/file8 /directory1/file9 then the sequence of messages that the client would send to the server is as follows (assuming that it is already in the INITIAL state): PSTA "My partition" FILE "file1" FILE "file2" DSTA "directory1" FILE "file3" FILE "file4" DSTA "directory2" FILE "file5" FILE "file6" DEND DSTA "directory3" FILE "file7" FILE "file8" DEND FILE "file9" PEND Notice that it is not mandatory that every DSTA message be coupled with a DEND message; the PEND message has implied all the pending DEND messages. However, the client MUST NOT send more DEND that DSTA messages, since it is not possible to go up from the root directory. In the event of receiving a DEND message when processing the root directory, the server has the right to abort the transfer. It is possible to enter the same directory more than once; that is, the sequence DSTA "directory" - DEND - DSTA "directory" is perfectly legal. A server receiving a DSTA message for an existing directory MUST simply switch to the directory without trying to create it again. Soriano Expires April 1, 2005 [Page 10] Internet-Draft Simple Partition Transfer Protocol October 2004 2.4 The semantics of CRST and SRST SRST (server reset) and CRST (client reset) are two special messages which are used in various circumstances, but they have always the same effect: to make both client and server to return to the INITIAL state. These messages may be sent at any time. Sometimes the use of these messages is part of the normal protocol operation, and then the actions to be performed upon its reception are fully specified. When these messages are received unexpectedly, then the default action is to send a reply (CRST in reply to SRST, and vice versa) and return to the INITIAL state. If CRST were always sent in reply to SRST and vice versa, an infinite loop of xRST messages exchange would arise. To prevent this, the protocol specifies that reset messages are to be ignored when received in the INITIAL state. Server sends SRST messages in response to a PSTA message when the involved partition cannot be stored, for example if the declared partition size is larger than the free disk space or the user disk quota, if such quota exists; or when a partition transfer in progress cannot continue (for example because and invalid file name or size was specified in the last received FILE message). Client sends CRST after receiving a PEXS message if the existing partition data is not to be erased, and to confirm the reception of a SRST message during a partition transfer. Client can also send CRST to abort a partition transfer in progress, although this should happen rarely. If a server cannot continue serving the client at all (not only with regard to the partition transfer in progress), it is better to send SBYE instead of SRST, and to close the TCP connection immediately. The same applies to a client not willing to start new partition transfers when aborting the transfer in progress. 2.5 The semantics of CBYE and SBYE SBYE (server bye) and CBYE (client bye) are more drastical than SRST and CRST: after sending SBYE or CBYE, the server or the client, respectively, closes the TCP connection immediately; the recipient of the message must in turn close immediately the connection. Under normal circumstances, there are only three cases in which these messages are used: Soriano Expires April 1, 2005 [Page 11] Internet-Draft Simple Partition Transfer Protocol October 2004 1. When no more partitions are to be transferred, the client being in the INITIAL state uses CBYE to finish the SPTP session in an ordered way. 2. Upon receipt of a WELC message, the client sends CBYE if none of the authentication methods supported by the server is supported, or if the character set specified by the server is not recognized (an alternative in the latter case is to continue the session initiation and ignore any further text string received from the server). 3. Upon receipt of a HELO message, the server sends SBYE if the character set specified by the client is not recognized, or if the authentication information provided by the client is wrong. Despite this, the fact is that SBYE and CBYE messages may be sent anytime during a SPTP session. However they should not be used unless strictly necessary; for example if the server is to be shut down immediately, then the only thing it can do is to send SBYE and close the connection. But whenever possible, the use of SRST and CRST is preferred. 2.6 Storage strategy SPTP only specifies how the partition data is transferred; how the server stores the information is a local issue, as long as the path, name, contents and date/time of all the files and directories are preserved (preserving the attribute information is optional). However, a reasonable and simple storage approach for the server could be as follows: 1. The server has a base directory to store all the data received via SPTP. 2. Inside the base directory, there is a directory for each user. 3. Inside the directory for a given user, there is a directory for each partition transferred by that user. 4. Inside the directory for a given partition, the partition data is stored using the file system of the server itself; that is, a real directory is created for each transferred directory, and a real file is created for each transferred file. Optionally, a disk quota could be imposed for each user, to limit the amount of disk space used to store partitions. A PSTA message specifying a partition size larger than the available quota MAY be Soriano Expires April 1, 2005 [Page 12] Internet-Draft Simple Partition Transfer Protocol October 2004 rejected with a SRST message. The server may choose to compress or to otherwise process the received partition data as it wishes. However these manipulations are always opaque to the client, as long as the data is preserved. When an error occurs that implies aborting a partition transfer, the server is not required to store the partial partition contents that had been able to store before the error arose. These partial contents may be deleted, and the client MUST act as if no data were transferred at all. The client may assume that a partition has been successfully transferred ONLY if it receives a SGOK message after having sent a PEND message in the SENDING state. 2.7 The "server silent unless error arises" strategy During a partition transfer process, the client sends DSTA, FILE and DEND messages, and if everything is ok, the server stores the information and does not send any message. Only in the event of an error that impedes one of the directories or files (or any subsequent directory or file) to be stored, the server sends asynchronously a SRST message and enters the ABORTING state. All the DSTA, FILE and DEND messages received in this state are ignored. The client, in turn, must periodically check if a message has arrived from the server while transferring data. Currently, the protocol specifies that this checking must be performed: o After sending a DSTA message, or o After having sent 4K of file data (as part of a FILE message) or after having finished sending a FILE message, whatever happens first. However, unless a SBYE message is received, the FILE messages are always sent complete. For example, if after sending 30KB of a 50KB file the client realizes that a SRST message has arrived, it MUST send the remaining 20KB, even if it is known in advance that the server will ignore this data. Only after the complete message has been sent, an acknowledging CRST message is sent, and the client returns to the INITIAL state. The rationale beyond this strategy against the typical "send message and wait reply" scheme is that, although it is clearly inefficient in case of error, it is very efficient when no errors arise (especially when many small files are to be transferred), which will be the most common case if both the client and the server operate properly. The only error condition that is likely to occur is the server running Soriano Expires April 1, 2005 [Page 13] Internet-Draft Simple Partition Transfer Protocol October 2004 out of disk space, but this should never occur since the client must announce the size of the partition in the PSTA message, and the server can then reject the partition transfer if there is not enough disk space or user disk quota to store the partition data. Of course other errors may arise, for example the reception of a badly formatted message or a physical error in the server disk. The first type of errors should never occur when both the client and the server strictly observe the protocol, and about the second type, these unavoidable errors are expected to occur only rarely. However, future research may show that indeed, a typical send message-wait reply scheme could be more convenient, either in some circumstances only or in any event. If this happens, a protocol extension could be defined by which both parts agree to follow any such alternative scheme instead of the one specified in this document. 2.8 Authentication SPTP provides support for client authentication. When the server desires the client to authenticate itself, it sets the "auth" field of the initial WELC message appropriately according to the authentication methods it supports; setting the "auth" field to zero means that the server does not require the client to authenticate, and will ignore any authentication information sent by the client. When receiving a WELC message whose "auth" field is nonzero, the client MUST include authentication information in the HELO message sent in response. The client is free to choose any of the authentication methods supported by the server, but SHOULD choose the securest method it supports. If the client does not want to authenticate, or does not recognize any of the authentication methods supported by the server, then it MUST send a CBYE message and close the connection. A "challenge" field is included in the WELC message. It is a binary string to be used by the client only if the chosen authentication method involves a challenge-response mechanism. If more than one of such authentication methods are supported by the server, then the same challenge string is specified for all of them; if this is undesirable, then a protocol extension should be defined to improve the authentication mechanism described here. The authentication information sent in the HELO message involves two fields: "user", which contains the user name as an US-ASCII case-sensitive string; and "pass", which is either the password as an US-ASCII case-sensitive string, or a binary string containing the Soriano Expires April 1, 2005 [Page 14] Internet-Draft Simple Partition Transfer Protocol October 2004 response to the challenge, depending on the chosen authentication method. Currently, two authentication methods are defined: 1. Plain The password is sent in the clear in the "pass" field of the HELO message, without any sort of encoding. The server simply compares this string against the user information it has stored locally to decide whether the authentication is acceptable or not. 2. HMAC-MD5 The client must build a string composed by the concatenation of the user name, a zero byte, the password, and a zero byte, in that order. Using this string as the "key", and the challenge sent by the server as the "text", the HMAC-MD5 digest as defined in RFC1321 [1] and RFC2104 [2] is calculated. The resulting 16-byte digest is put directly in the "pass" field of the HELO message, without any further encoding (that is, the "pass" field will transport a 16-byte binary string). The server must perform the same operation upon receipt of the HELO message, based on the user information it has stored locally; if the digests are equal, then the user is considered to be successfully authenticated. Note that whatever method is used, the "pass" field of the HELO message is always a string, so it must be prepended by a length byte as specified in Section 3.5. The "auth" field is one byte, of which one bit is reserved for each authentication method. This means that there is room to specify six more authentication methods in the future. If more methods are to be defined, then protocol extensions should be used for this purpose. 2.9 Protocol extensions The SPTP protocol as described here is quite complete and serves perfectly for its original purpose, that is, transferring whole disk partitions from a MSX computer (or any other low-end computer) to a PC acting as backup server. However, it may be desirable to extend or modify the protocol in the future, either because of special requirements for a particular computer or file system, or because any of the protocol features is demonstrated to be problematic or simply can be improved. For example, the way in which the file/directory attributes are Soriano Expires April 1, 2005 [Page 15] Internet-Draft Simple Partition Transfer Protocol October 2004 indicated in the FILE and DSTA messages is clearly insufficient: only the four attributes supported by MSX-DOS can be specified; other operating systems or file systems have a more complex attributes/permissions system (notably Unix) and thus cannot transfer or store the complete file/directory metadata. To handle these issues, SPTP provides a mechanism by which client and server can negotiate any protocol extension that is developed in the future. Such extensions can define new messages, modify the format of existing messages (except WELC and HELO), and/or alter the server o client automaton behaviour. The protocol extensions mechanism works as follows. Each extension must have an associated keyword, which is a short case-insensitive US-ASCII string. The "extensions" field of the WELC message contains the keywords for all the extensions supported by the server, listed in no particular order, and followed by an empty string to indicate the end of the list. Upon receipt of the WELC message, the client examinates its "extensions" field and decides which extensions it recognizes and wants to use. These acceptable extensions are put in the "extensions" field of the HELO message sent in response; this way, the client is indicating to the server its agreement to use some, or all, of the extensions offered. For example, assume that the server supports two extensions, named 'FOO' and 'BAR'. Then the extensions field of the WELC message would be as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 |'F'|'O'|'O'| 3 |'B'|'A'|'R'| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the client recognizes and agrees to use the 'BAR' extension, but does not recognize or does not want to use the 'FOO' extension, then the extensions field of the HELO message would be: +-+-+-+-+-+-+-+-+-+-+ | 3 |'B'|'A'|'R'| 0 | +-+-+-+-+-+-+-+-+-+-+ If the server does not support any protocol extensions at all, then it MUST send an empty string as the "extensions" field of the WELC message. If the client does not understand, or does not want to use, any of the protocol extensions supported by the server, then it MUST send an empty string as the "extensions" field of the HELO message. If the "extensions" field of the HELO message is empty, then both the Soriano Expires April 1, 2005 [Page 16] Internet-Draft Simple Partition Transfer Protocol October 2004 server and the client MUST stick to the protocol specification described in this document (or any other document that obsoletes this one). Supporting any existing protocol extension is in principle optional, but see Section 4. This document describes no protocol extensions, but we envision that the following features are good candidates for developing such extensions: o A more complex, or one or more file system-dependant, way to specify the file/directory attributes. o A way to negotiate (not to simply announce) the character sets and/or the language to be used for strings. o A method to acknowledge the correct receipt of files during a partition transfer process (that is, an alternative to the "server silent unless error arises" strategy). o A more complex authentication system. o A method to encrypt the data to be transferred. o A method to transfer strings that are larger than 255 bytes. Any document specifying a protocol extension for SPTP should include the following information: 1. The name and description of the extension. 2. The keyword to be used on the "extensions" field of WELC and HELO messages. 3. How the existing messages are modified (it is not allowed to modify the WELC and HELO messages, since the option negotiation process is not complete until both have been sent). 4. Which new messages are defined. 5. How the server and client automatons are modified. 6. Whether supporting this extension is mandatory or optional (see Section 4). Soriano Expires April 1, 2005 [Page 17] Internet-Draft Simple Partition Transfer Protocol October 2004 3. Protocol specification 3.1 Overview This section specifies the algorithm that must be followed by the SPTP client and server automatons, as well as the exact format of the SPTP messages. There are two separate automatons, one for the server and one for the client; each one having its own set of states and its own algorithm. The states for the client automaton are CONNECTING, AUTHENTICATING, INITIAL, REQUESTING, SENDING and FINISHING. The states for the server automaton are AUTHENTICATION, INITIAL, RECEIVING and ABORTING. The automatons are explained in two ways: with a descriptive automaton algorithm, and with a state diagram. The algorithms, together with the protocol operation details given in Section 2, should be used as the base for actual protocol implementations; the state diagrams should be used only to obtain a general idea about how the automatons work. The state transitions in the state diagrams are represented in the form of "input/output", where the input usually refers to the receipt of a given message but may be anything else, for example an error; and the output is a message to be sent. "X_ok" and "X_bad" mean "receipt of an acceptable X message" and "receipt of a NOT acceptable X message", respectively. "!X" means "receipt of any message except X". "/X" means that a X message is sent not in response to any particular event (for example /WELC or /FILE). Note that the state diagrams do not include the transitions triggered by the receipt of unexpected or unknown messages. 3.2 Client protocol 3.2.1 Automaton algorithm * Start Open a connection to the server and enter the CONNECTING state. * CONNECTING state Receive WELC: Do we understand any of the announced authentication methods? No: Send CBYE and close the connection. END. Do we understand the announced character set? Yes: Send HELO and enter the AUTHENTICATING state. Soriano Expires April 1, 2005 [Page 18] Internet-Draft Simple Partition Transfer Protocol October 2004 No: Choose one of: - Send CBYE and close the connection. END. - Send HELO and enter the AUTHENTICATING state, but ignore any further text string received from the server. (Do NOT close the connection if we do not understand the announced language but everything else is OK) Receive anything else: Close the connection. END. * AUTHENTICATING state Receive SGOK: Enter the INITIAL state. Receive SBYE: Close the connection. END. * INITIAL state Receive SRST: Ignore it. To start a partition transfer: Send PSTA and enter the REQUESTING state. To terminate the session: Send CBYE and close the connection. END. * REQUESTING state Receive SGOK: Enter the SENDING state. Receive PEXS: Do we want to overwrite the partition data? Yes: Enter the SENDING state. No: Send CRST and enter the INITIAL state. Receive SRST: Enter the INITIAL state. * SENDING state Receive SRST: Send CRST and enter the INITIAL state. For each directory/file to transfer: Send DSTA, DEND and FILE as appropriate. Check for an incoming message from the server: - After sending a DSTA message. - After having sent 4KByte of file contents or after having sent a complete FILE message, whatever happens first. After having transferred the last directory/file: Soriano Expires April 1, 2005 [Page 19] Internet-Draft Simple Partition Transfer Protocol October 2004 Send PEND and enter the FINISHING state. * FINISHING state Receive SGOK or SRST: Enter the INITIAL state. * All states: Receive SBYE: Close the connection. END. Receive unexpected SRST: Send CRST and enter the INITIAL state. Receive unexpected message (except SBYE and SRST) or unknown message: Send CBYE and close the connection. END. Soriano Expires April 1, 2005 [Page 20] Internet-Draft Simple Partition Transfer Protocol October 2004 3.2.2 State diagram Open connection | v WELC_ok/ SBYE, +------------+ HELO +----------------+ Other/CBYE | CONNECTING |----------->| AUTHENTICATING |-------+ +------------+ +----------------+ | | | | | !WELC, | SGOK v | WELC_bad/CBYE | Close v | connection Close connection | | +---------------------+ | SRST | SRST or PEXS_bad/CRST +--+ | ----------------------+ | | | | | | v v v | +-----------+ /PSTA +--------------+ | INITIAL |--------->| REQUESTING | +-----------+ +--------------+ ^ ^ | | | | SGOK,PEXS_ok | | v | | SRST/CRST +--------------+ | +----------------| SENDING |---+ | +--------------+ | | +-----------+ | ^ | +--| FINISHING |<-------+ +-----+ SGOK, +-----------+ Completed/ /DSTA,/DEND,/FILE SRST PEND 3.3 Server protocol 3.3.1 Automaton algorithm * Start (connection established by the client) Send WELC and enter the AUTHENTICATION state. * AUTHENTICATION state Receive HELO: Are the character set and the authentication information acceptable, and all the announced extensions Soriano Expires April 1, 2005 [Page 21] Internet-Draft Simple Partition Transfer Protocol October 2004 were previously announced by us in the WELC message? Yes: Send SGOK and enter the INITIAL state. No: Send SBYE and close connection. END. Receive anything else: Close connection. END. * INITIAL state Receive CRST: Ignore it. Receive PSTA: Is it acceptable? Yes: Send PACK or PEXS and enter the SENDING state. No: Send SRST. * RECEIVING state Receive DSTA, DEND, FILE: Create the directories and store the files. Receive PEND: All the received data was successfully stored? Yes: Send SGOK. No: Send SRST. Enter the INITIAL state. If an error occurs at any time: It is an unrecoverable error? Yes: Send SBYE and close connection. END. No: Send SRST and enter the ABORTING state. * ABORTING state: Receive DSTA, DEND, FILE: Ignore them. Receive CRST: Enter the INITIAL state. * All states: Receive CBYE: Close the connection. END. Receive unexpected CRST: Send SRST and enter the INITIAL state. Receive unexpected message (except CBYE and CRST) or unknown message: Send SBYE and close the connection. END. Soriano Expires April 1, 2005 [Page 22] Internet-Draft Simple Partition Transfer Protocol October 2004 3.3.2 State diagram HELO_bad/SBYE, Receive /WELC +----------------+ !HELO connection -------->| AUTHENTICATION |--------+ +----------------+ | | | CRST, | HELO_ok v PSTA_bad/SRST | Close ------+ ------------+ connection | | | ^ v | v | +-------------+ PSTA_ok/PACK or PEXS | | INITIAL |-----------------------+ | +-------------+ | | ^ ^ | | Error/SBYE | | | | | | CRST Error/ v | | +----------+ SRST +-------------+ | | ABORTING |<----------| RECEIVING |---+ | +----------+ +-------------+ | | ^ | DSTA,DEND,FILE | ^ | | | | | | | | ----+ | +-----+ +--------------------------+ DSTA,DEND,FILE PEND/SGOK or CRST 3.3.3 Server behaviour in the RECEIVING state The server MUST preserve the file name and date/time information of the received files. If no date/time information is sent by the client (see the FILE message format in Section 3.5), then the server may set any date/time information for the file; for example the current date/time, or a generic "null" date/time (like 1/1/1970 0:00:00 or something similar). The server SHOULD preserve the attributes information sent by the client, however this is not always possible, depending on the file system used by the server (see Section 2.9). If the server receives a file with invalid date/time information, it MAY abort the transfer or MAY act as if no date/time information had been specified by the client. If the combined size of the files received by the server surpasses the maximum partition size announced in the PSTA message that initiated the transfer, the server MAY abort the transfer or MAY Soriano Expires April 1, 2005 [Page 23] Internet-Draft Simple Partition Transfer Protocol October 2004 continue storing the received files if there is still enough disk space/user quota. If the server cannot store one of the received directories or files (because of an invalid file name or size, too deep directory recursion, out of disk space/user quota, or any other reason), then it MUST abort the transfer. If the server receives more DEND than DSTA messages (that is, if a DEND message is received when the root directory of the partition is being processed), it MAY abort the transfer or MAY ignore the invalid DSTA message. In all cases, aborting the transfer means sending a SRST message and entering the ABORTING state. 3.4 Timeouts The following timeouts are defined to avoid the client or the server to lock due to a defective implementation or to network problems. In the event of a timeout expiration, the session MUST be terminated via a SBYE or CBYE message. If different timeout values are desirable, then the appropriate protocol extensions should be defined to negotiate or announce them. o Client waiting the WELC message in CONNECTING state: 1 minute o Server waiting the HELO message in AUTHENTICATION state: 2 minutes o Client waiting the SGOK message in AUTHENTICATING state: 2 minutes o Client waiting the SGOK or PEXS message in REQUESTING state: 1 minute o Server waiting for DSTA, FILE or DEND messages in RECEIVING state: 3 minutes o Server waiting the CRST message in ABORTING state (if no file is being transferred): 1 minute o Client waiting the SGOK or SRST messages in FINISHING state: 5 minutes o Server waiting for a PSTA or CBYE message in the INITIAL state: 10 minutes Soriano Expires April 1, 2005 [Page 24] Internet-Draft Simple Partition Transfer Protocol October 2004 3.5 Message format Every SPTP message consists of a one-byte code indicating the message type, followed by message-specific information; there is no maximum size defined for any message. There are some messages that consist of the message type code only. The data fields in the messages are either fixed-length numeric data (for example the size of the partition in the PSTA message), or variable-length strings. The strings consist of one byte indicating the string length in bytes, followed by the string itself; no termination character is added to strings. All strings except those described as "binary strings" MUST be properly encoded according to the character set announced in the initial WELC or HELO message, as appropriate. Binary strings may contain any byte, from 0 to 255. The (non-binary) strings sent by the server are informative messages intended for human consumption; for this reason, a "language" field is provided in the WELC message in addition to the "character set" field. The client SHOULD either display these messages to the user or store them in a log file if at least the character set is recognized. If the client does not recognize the character set indicated by the server (as announced in the WELC message), it MAY close the connection or MAY continue the session initiation and ignore any non-binary string sent by the server. The client SHOULD NOT close the connection simply because it does not recognize the language announced by the server. All fields of all messages are mandatory, but in many cases the strings are allowed to be empty (an empty string consists of one single zero byte), when no useful information is to be transmitted; for example, user name and password of an HELO message may be empty strings when the server did not require authentication in the WELC message. The exception to the above scheme is the file data part of the FILE message. It is a variable-length binary field whose length is indicated by the "Size" field of the message; when the value of this field is zero, then the file data part simply does not exist on the message. Below is the detailed description of all the messages used by SPTP. - Welcome (WELC) Soriano Expires April 1, 2005 [Page 25] Internet-Draft Simple Partition Transfer Protocol October 2004 +-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+- | Info ... +-+-+-+-+-+-+-+-+-+- | Charset ... +-+-+-+-+-+-+-+-+-+- | Lang ... +-+-+-+-+-+-+-+-+-+- | Auth | +-+-+-+-+-+-+-+-+-+- | Challenge ... +-+-+-+-+-+-+-+-+-+- | Extensions ... +-+-+-+-+-+-+-+-+-+- Info: String containing server identification or just a welcome text for the user. May be empty. Charset: Name of the character set in which the strings sent by the server will be encoded (except binary strings). May be an empty string, in which case US-ASCII is assumed. This string is always encoded in US-ASCII and is not case sensitive. Lang: Language of the text strings sent by the server (that is, all the strings except binary ones), this is a string that follows the rules of RFC3066 [4]. An empty string SHOULD NOT be placed here, as it means that no language information is announced. Auth: One byte that indicates which authentication methods are supported by the server. One bit is reserved for each method, being one when the method is supported: Bit 0: Plain Bit 1: HMAC-MD5 Bits 2 to 7: Currently unused, MUST be zero More than one bit may be set to one, in which case the server MUST accept the client to authenticate by any of the announced methods (but the client SHOULD choose the securest method it supports). When the server does not require authentication, all bits must be zero. Challenge: When at least one of the supported authentication methods is based on a challenge-response method (for example HMAC-MD5), then this is a binary string containing the challenge. Otherwise, it may be anything, usually an empty string. Soriano Expires April 1, 2005 [Page 26] Internet-Draft Simple Partition Transfer Protocol October 2004 Extensions: Names of the extensions supported by the server. Each extension is an US-ASCII case-insensitive string, and as many extensions as desired may be included. An empty string indicates the end of this field. If the server does not support any extension at all, then this field is simply an empty string. - Hello (HELO) +-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+- | Charset ... +-+-+-+-+-+-+-+-+-+- | Auth | +-+-+-+-+-+-+-+-+-+- | User ... +-+-+-+-+-+-+-+-+-+- | Password ... +-+-+-+-+-+-+-+-+-+- | Extensions ... +-+-+-+-+-+-+-+-+-+- Charset: Name of the character set in which the strings sent by the client will be encoded (except binary strings). May be an empty string, in which case US-ASCII is assumed. This string is always encoded in US-ASCII and is not case sensitive. Auth: One byte that indicates which method will be used for authentication. It MUST either have exactly one bit set to one, in the appropriate position for the selected method as announced by the server; or have all bits to zero if the server did not require authentication. User: String with the user name. MUST be a case-sensitive US-ASCII string. If the server does not require authentication, it may be anything (usually an empty string). Password: String with the password for the specified user (case-sensitive US-ASCII string), or a binary string with the response to the challenge, depending on the authentication method used. If the server does not require authentication, it may be anything (usually an empty string). Extensions: Names of the extensions supported by the server that the client supports and wants to use. Each extension is an US-ASCII case-insensitive string, and as many extensions as desired may be included, but the client MUST NOT include any extension name that was not listed in the WELC message. An empty string indicates the Soriano Expires April 1, 2005 [Page 27] Internet-Draft Simple Partition Transfer Protocol October 2004 end of this field. If the client does not support or does not want to use any extension at all, then this field is simply an empty string. - Server close (SBYE) +-+-+-+-+-+-+-+-+ | 3 | +-+-+-+-+-+-+-+-+-+- | Reason ... +-+-+-+-+-+-+-+-+-+- Reason: String explaining the reason for closing the connection. May be empty. - Client close (CBYE) +-+-+-+-+-+-+-+-+ | 4 | +-+-+-+-+-+-+-+-+ - Server reset (SRST) +-+-+-+-+-+-+-+-+ | 5 | +-+-+-+-+-+-+-+-+-+- | Reason ... +-+-+-+-+-+-+-+-+-+- Reason: String explaining the reason for aborting or rejecting the partition transfer, or otherwise the reason for sending this message. May be empty. - Client reset (CRST) +-+-+-+-+-+-+-+-+ | 6 | +-+-+-+-+-+-+-+-+ - Partition start (PSTA) +-+-+-+-+-+-+-+-+ | 7 | +-+-+-+-+-+-+-+-+-+- | Size ... +-+-+-+-+-+-+-+-+-+- | Name ... +-+-+-+-+-+-+-+-+-+- Soriano Expires April 1, 2005 [Page 28] Internet-Draft Simple Partition Transfer Protocol October 2004 Size: Maximum partition size in bytes. It is a 4-byte or 8-byte positive number stored in network byte order (most significant byte first), that MUST be equal to or greater than the combined size of all the files that will be transferred. To distinguish whether a 4-byte number or an 8-byte number is transferred in this field, the most significant bit of the most significant byte is used as a flag. When this bit is zero, then 4 bytes are used for this field. When this bit is one, then 8 bytes are used for this field, and the flag bit itself must be reset to zero before processing the number (since this field is always a positive number). It is allowed (but a waste of bandwidth) to use 8 bytes to specify a number that fits on 4 bytes or less. Name: String with the name of the partition. - Server general OK (SGOK) +-+-+-+-+-+-+-+-+ | 8 | +-+-+-+-+-+-+-+-+-+- | Message ... +-+-+-+-+-+-+-+-+-+- Message: String with information for the user. May be empty. - Partition exists (PEXS) +-+-+-+-+-+-+-+-+ | 9 | +-+-+-+-+-+-+-+-+-+- | Message ... +-+-+-+-+-+-+-+-+-+- Message: String with information for the user. May be empty. - Directory start (DSTA) +-+-+-+-+-+-+-+-+ | 10 | +-+-+-+-+-+-+-+-+-+- | Name ... +-+-+-+-+-+-+-+-+-+- | Date ... +-+-+-+-+-+-+-+-+-+- | Attributes | +-+-+-+-+-+-+-+-+ Soriano Expires April 1, 2005 [Page 29] Internet-Draft Simple Partition Transfer Protocol October 2004 Name: String with the directory name. Date: Six bytes containing the directory creation date and time with the following format: Byte 0: Year minus 1970 Byte 1: Month Byte 2: Day of month Byte 3: Hour Byte 4: Minute Byte 5: Second This field MUST either contain a valid date, or to be all zeros, meaning then that no date information is available for that directory. The server may insert any date information for the stored directory when no date information is included in this field. Attributes: One byte indicating the attributes of the directory, one bit per attribute: Bit 7: Read only Bit 6: Hidden Bit 5: System Bit 4: Archive Bits 3 to 0: Currently unused, MUST be zero - File data (FILE) +-+-+-+-+-+-+-+-+ | 11 | +-+-+-+-+-+-+-+-+-+- | Size ... +-+-+-+-+-+-+-+-+-+- | Name ... +-+-+-+-+-+-+-+-+-+- | Date ... +-+-+-+-+-+-+-+-+-+- | Attributes | +-+-+-+-+-+-+-+-+-+- | Contents ... +-+-+-+-+-+-+-+-+-+- Size: File size in bytes. It is a 4-byte or 8-byte positive number stored in network byte order (most significant byte first). To distinguish whether a 4-byte number or a 8-byte number is transferred in this field, the same method as in the PSTA message is used. Soriano Expires April 1, 2005 [Page 30] Name: String with the name of the file. Date: Six bytes containing the file last modification date and time, in the same format as in the DSTA message. This field MUST either contain a valid date, or to be all zeros, meaning then that no date information is available for that file. The server may insert any date information on the stored file when no date information is included in this field. Attributes: One byte indicating the attributes of the file, in the same format as in the DSTA message. Contents: The raw contents of the file. The length of this field MUST be exactly the same as the size indicated in the "Size" field. If the file size is zero, then this field is not transmitted at all. - Directory end (DEND) +-+-+-+-+-+-+-+-+ | 12 | +-+-+-+-+-+-+-+-+ - Partition end (PEND) +-+-+-+-+-+-+-+-+ | 13 | +-+-+-+-+-+-+-+-+ Soriano Expires April 1, 2005 [Page 31] Internet-Draft Simple Partition Transfer Protocol October 2004 4. Security considerations The server is not required (and usually not expected) to perform any processing on the received files other than storing them and possibly compressing them. Therefore, the receipt of possibly malicious executable files by the server is not really a concern. The only feasible attack against a SPTP server (apart from DoS and other attacks that are inherent to any service offered via TCP) is trying to make it to run out of disk space by sending lots of dummy data. However the server has full control about the data it stores, and may abort the transfer at any time; furthermore, the data resulting from a partial partition transfer can be deleted immediately, so transfer errors or attacks will not cause the free disk space of the server to shrink. If sending the partition data in the clear to the network is a concern because of confidential or otherwise sensible data being transferred, then a protocol extension should be defined to apply any sort of encryption to the data before transferring it and/or before storing it on the server. All the protocol extensions defined in the future are in principle optional, and any server should be able to interoperate with any client, regardless of the extensions they support or do not support. However, if any extension is defined that solves a severe security and/or interoperation problem found on the protocol, the server MAY deny to offer service to a client not supporting that extension; the appropriate explanatory message SHOULD then be included in the SBYE message used to close the connection. Similarly, the client MAY close the connection if the WELC message it receives do not include any of such critical extension in its "extensions" field. Soriano Expires April 1, 2005 [Page 32] Internet-Draft Simple Partition Transfer Protocol October 2004 5. References 5.1 Normative references [1] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [2] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [4] Alvestrand, H., "Tags for the Identification of Languages", RFC 3066, BCP 47, January 2001. 5.2 Informative references [5] Cerf, V., "ASCII Format for Network Interchange", RFC 20, October 1969. [6] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", RFC 959, STD 9, October 1985. [7] Sollins, K., "The TFTP protocol (Revision 2)", July 1992. Author's Address Nestor Soriano Vilchez Asociacion de Amigos del MSX EMail: konamiman@konamiman.com URI: http://www.konamiman.com Soriano Expires April 1, 2005 [Page 33] Internet-Draft Simple Partition Transfer Protocol October 2004 Appendix A. Acknowledgments This document was written in XML format using the technique described in RFC2629 ("Writing I-Ds and RFCs using XML"), and converted to a text file using the online version of the "xml2rfc" tool available at . These resources proved to be extremely useful so the author wishes to acknowledge the work done by its authors. Soriano Expires April 1, 2005 [Page 34] Internet-Draft Simple Partition Transfer Protocol October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Soriano Expires April 1, 2005 [Page 35]