Internet Draft S. Ramaswamy Document: draft-ramaswamy-version-control-00.txt Cisco Systems, Inc. February 1999 Expires August 1999 Version Control Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. 1. Abstract Version control has a wide range applications starting from a simple ASCII text file management to a complex software source management. This document discusses the basic requirement and framework for an open interface for Version Control System. Such an open interface would bring platform independence as well as flexibility and extensibility. S. Ramaswamy [Page 1] Internet DRAFT Implementation Recommendations February 1999 2. Conventions used in this document In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 3. Architecture This version control architecture consists of clients and servers. The client provides an interface to the user while the server manages one or more source repositories. A client may associate itself with multiple servers if the repositories are distributed. 3.1. Projects A Project is a logical unit of work. It is identified by a name and that becomes the root of its source tree. Typically a VCP server would manage one or more projects. A project could be made distributed across more than one server, esp., the sub projects. 3.2. Sub-Projects A project might contain sub-projects within it. It is possible that more than one project would refer a particular project as their sub-project. Idea behind having sub-projects is to provide relationships among projects. In the following sections whatever is mentioned about a project is also applicable to sub-project equally. 3.3. Elements A project consists of a tree of Elements. An element is a basic unit of operation. It is similar to the file or directory of a file system. Elements can be of the following types: Directory Text File Binary File The source control operations are basically defined for an element or group of elements. S. Ramaswamy [Page 2] Internet DRAFT Implementation Recommendations February 1999 4. Version Control 4.1. Checkout and Checkin Checkout and checkin are the two basic operations in the version control. A checkout operation allows the element to be modified by the user who performed the checkout. When an element is checked out other users cannot checkout but only see the latest revision that was checked in before the checkout. 4.2. Revisions Revisions are created on an element as new revisions of it are checkedin. Revisions are identified by numbers, starting from 1. When an element is created first it is marked as revision 1. It can go up to a maximum of 65536. A specific revision of an element can referred to by the element name followed by the character '%', followed by the revision number. 4.3. Branching and Merging Branching is done to create a temporary path for revision control for a specific task or purpose. A branch can be created on any element. When a branch is created on an element, all elements under this element are also implicitly branched. A branch can be created on an element that is already branched. Each branch is identified by a name. Whenever a branch is created on an element the revision number is set to 1 under that branch. New revisions could be created on that branch which will result in increments of revision number. A specific revision in a specific branch can be identified by the element name followed by the character '%', followed by branch names separated by '/' characters, followed by another '/' character and the revision number. For example, hello.c%INTEGRATION/ALPHA/15 identifies the 15th revision of element hello.c under the branch ALPHA which is under the branch INTEGRATION. Once the task or purpose is accomplished the branch may be merged with the main trunk. Merging to the branch from which it was branched is equivalent to creating the next revision in the parent branch. Once a branch is merged with its parent it is considered closed which means no further modifications can be done there. S. Ramaswamy [Page 3] Internet DRAFT Implementation Recommendations February 1999 4.4. Naming Each element is associated with a revision specifier which identifies a specific branch and revision. The revision specifier is defined as: RevisionSpec ::= OCTET STRING The format of the revision specifier string is: [ / ]... / All project and element names must start with an alphabet followed by alphabets, numbers, or symbols '.', '-', '_'. The names can be of a maximum length of 256. 5. Connection This section describes the connection establishment and termination procedures between the client and the server. 5.1. Connection Establishment The server listens on a well-known TCP port for incoming connections from the client. The server administrator may override the default TCP port number. The client makes a connection request to the server using TCP which the server may accept or refuse. Once the connection is established the client can do the transactions such as check-out or check-in a source element. 5.2. Connection Termination At the end the client closes the connection. However, if for some reason the server decides, it may choose to close the connection by itself. 5.3. Access Control The source repository should be protected using proper access control mechanism. When the client establishes a connection to the server, it needs to authenticate to the server by providing a password. The server performs the authentication and replies (either allowing or denying access) to the client. The password is sent cleartext. S. Ramaswamy [Page 4] Internet DRAFT Implementation Recommendations February 1999 An Element and all elements under this element can be protected (recursively) by means of an access-list. The access list consists of a sequence of access control entries. Each access control entry either grants or revokes a set of rights for a specific user or group to the element and all sub elements, again recursively. 5.3.1 Users and Groups The definition of user and group are outside the scope of this protocol. The server host must contain the necessary implementation of user and group mechanism. However, the VCP protocol restricts the user and group names as in the following definition: PrincipalName ::= OCTET STRING (SIZE (256)) 5.3.2 Access Lists The access list is defined as follows: AccessList ::= SEQUENCE OF AccessControlEntry AccessControlEntry ::= SEQUENCE { principal PrincipalName, action INTEGER { deny (0) permit (1), } rights RightsMask } The RightsMask is a 16-bit rights mask and is defined as follows. RightsMask ::= OCTET STRING (SIZE (2)) Bit # Right ----- ----- 0 Create 1 Delete 2 Read 3 Write 4 List 5-15 Reserved The Read and List rights are recursive in nature. That means, if any of these rights are denied for a principal for an element, the same rights are denied for all sub elements. S. Ramaswamy [Page 5] Internet DRAFT Implementation Recommendations February 1999 5.4. Location The resource at the server is located by means of an URL. The URL format is given below: vcp://[:]/[/]...[] The denotes a valid server name or an IP address. The is optional, so if it is not present then the well-known port is assumed. The specifies the name of the project to work with. The project name may be followed by a sequence of specifiers. Optionally an element specifier path can be used to name a specific element. The URL specifies the root or context for the operations. 6. Command and Data Exchange The client and the server communicate by sending and receiving commands and acknowledgements between them. Data is transferred between the client and the server by using files as basic units. The LDAP protocol is described using Abstract Syntax Notation 1 (ASN.1) [ASN1], and is typically transferred using a subset of ASN.1 Basic Encoding Rules [BER]. In order to support future extensions to this protocol, clients and servers MUST ignore elements of SEQUENCE encodings whose tags they do not recognize. 6.1. Commands Commands and acknowledgements are basically messages exchanged between the client and the server. Commands are called Requests and acknowledgements are called Responses in this document. The client initiates a connection using connection request message and the server replies with the response (acknowledgement) message. From then on, various types of messages are exchanged between the client and the server. Messages can be classified into Request and Response messages. Following is the list of messages: Connection Messages Connect Request Connect Response SetState Request GetState Request S. Ramaswamy [Page 6] Internet DRAFT Implementation Recommendations February 1999 State Response Disconnect Request Disconnect Response Project Management Messages Create Project/Sub-project Request Delete Project/Sub-project Request Modify Project/Sub-project Request Create Branch/Label Request Delete Branch/Label Request Project Response Element Management Messages Create Element Request Delete Element Request Modify Element Request Find Element Request Find Element Response Search Element Request Search Element Response Checkout Request Checkin Request Label Request Branch Request Merge Request Diff Request Diff Response History Request History Response Reserve/Unreserve Request Element Response All these messages would be encapsulated into a higher level message called VCPMessage. VCPMessage ::= [APPLICATION 0] SEQUENCE { messageID MessageID, message CHOICE { connectRequest ConnectRequest, connectResponse ConnectResponse, setStateRequest SetStateRequest, getStateRequest GetStateRequest, S. Ramaswamy [Page 7] Internet DRAFT Implementation Recommendations February 1999 stateResponse StateResponse, disconnectRequest DisconnectRequest, disconnectResponse DisconnectResponse, createProjectRequest CreateProjectRequest, deleteProjectRequest DeleteProjectRequest, modifyProjectRequest ModifyProjectRequest, createBranchLabelRequest CreateBranchLabelRequest, deleteBranchLabelRequest DeleteBranchLabelRequest, projectResponse ProjectResponse, createElementRequest CreateElementRequest, deleteElementRequest DeleteElementRequest, modifyElementRequest ModifyElementRequest, findElementRequest FindElementRequest, findElementResponse FindElementResponse, searchElementsRequest SearchElementsRequest, searchElementsResponse SearchElementsResponse, checkoutRequest CheckoutRequest, checkinRequest CheckinRequest, labelRequest LabelRequest, branchRequest BranchRequest, mergeRequest MergeRequest, diffRequest DiffRequest, diffResponse DiffResponse, historyRequest HistoryRequest, historyResponse HistoryResponse, S. Ramaswamy [Page 8] Internet DRAFT Implementation Recommendations February 1999 reserveRequest ReserveRequest, elementResponse ElementResponse } } 6.1.1. Connection Messages 6.1.1.1. Connect Request The Connect request is the first message sent by the client once the connection is established. The version number should be set 1. The project name identifies the root of the source tree. A branch name may be specified, if not the main branch is assumed. Also, a startDirectory can be specified so that subsequent messages need only to specify paths relative to this directory. This message also identifies the user who is making the request. The accessType specifies the level of access requested. Some users may have only read access to a repository. The authentication data contains a unencrypted password. ConnectRequest ::= [APPLICATION 10] SEQUENCE { version INTEGER (0 .. 127), projectName OCTET STRING (SIZE (128)), branch OCTET STRING (SIZE (256)), startDirectory OCTET STRING (SIZE (128)), userID OCTET STRING (SIZE (64)), accessType INTEGER { read-only (0), read-write (1), write-only (2) }, authData AuthenticationData } AuthenticationData ::= OCTET STRING (SIZE (256)) 6.1.1.2. Connect Response This message is sent by the server in response to the Connect request message. It contains a status code indicating the reply. S. Ramaswamy [Page 9] Internet DRAFT Implementation Recommendations February 1999 If the status is anything other than connected (0) the connection is closed by the server. ConnectResponse ::= [APPLICATION 11] SEQUENCE { statusCode INTEGER { connected (0), no-such-project (1), no-such-branch (2), no-such-directory (3), auth-failed (4) } } 6.1.1.3. SetState Request This message is sent by the client to use new values for default branch and startDirectory. The request contains a new branch and new start directory. If any of these new values are empty then the old values are left untouched. This message is acknowledged by the server using StateResponse message. The response message will indicate whether the requested operation succeeded or not. SetStateRequest ::= [APPLICATION 12] SEQUENCE { newBranchName OCTET STRING (SIZE (64)), newStartDirectory OCTET STRING (SIZE (64)) } 6.1.1.4. GetState Request This message is sent by the client to request the current state variables, namely, the default branch and the start directory. The message is acknowledged by the server using StateResponse message which contains the value of those state variables. GetStateRequest ::= [APPLICATION 13] SEQUENCE { } S. Ramaswamy [Page 10] Internet DRAFT Implementation Recommendations February 1999 6.1.1.5. State Response This message is sent by the server to client in response to the GetState or SetState request messages. StateResponse ::= [APPLICATION 14] SEQUENCE { status INTEGER { success (0), failure (1) } branchName OCTET STRING (SIZE (64)), startDirectory OCTET STRING (SIZE (64)) } 6.1.1.6. Disconnect Request This message is sent by the client if it wishes to disconnect. A request code is sent which indicates a normal or abort disconnect. If the request code is 'normal', the server does all the cleaning work and then close its side of the connection. If the request code is 'abort' then the server closes the connection first and then does any cleaning work. DisconnectRequest ::= [APPLICATION 15] SEQUENCE { requestCode INTEGER { normal (0), abort (1) } } 6.1.1.7. Disconnect Response This message is sent by the server as an acknowledgement to Disconnect request. Upon receipt of this message the client closes the connection. The client need not interpret the status code. DisconnectResponse ::= [APPLICATION 16] SEQUENCE { statusCode INTEGER { success (0) } } S. Ramaswamy [Page 11] Internet DRAFT Implementation Recommendations February 1999 6.1.2. Project Management Messages 6.1.2.1. Create Project/Sub-project Request This message is sent by the client to create a new project. Apart from the project name, a description, a ownerID and an access list must be present in this message. This request should be acknowledged by the ProjectResponse message. CreateProjectRequest ::= [APPLICATION 17] SEQUENCE { projectName OCTET STRING (SIZE (128)), description OCTET STRING (SIZE (512)), ownerID PrincipalName, accessList AccessList } 6.1.2.2. Delete Project/Sub-project Request This message is sent by the client to delete a project identified by the projectName. All the version control data as well as history are deleted. This request should be acknowledged by the ProjectResponse message. DeleteProjectRequest ::= [APPLICATION 18] SEQUENCE { projectName OCTET STRING (SIZE (128)), comment OCTET STRING (SIZE (512)) } 6.1.2.3. Modify Project/Sub-project Request This message is sent by the client to modify the attributes of project, namely, the project name, description, ownerID or the access list. This request should be acknowledged by the ProjectResponse message. ModifyProjectRequest ::= [APPLICATION 19] SEQUENCE { projectName OCTET STRING (SIZE (128)), comment CommentString, modifications CHOICE { projectName OCTET STRING (SIZE (128)), description OCTET STRING (SIZE (512)), S. Ramaswamy [Page 12] Internet DRAFT Implementation Recommendations February 1999 ownerID PrincipalName, accessList AccessList } } 6.1.2.4. Create Branch/Label This message is sent by the client to create or register a branch or label name. The names have to be unique in a project. This message is acknowledged by the ProjectResponse message. CreateBranchLabelRequest ::= [APPLICATION 20] SEQUENCE { projectName OCTET STRING (SIZE (128)), comment CommentString, name CHOICE { branchName OCTET STRING (SIZE (256)), labelName OCTET STRING (SIZE (256)) } } 6.1.2.5. Delete Branch/Label This message is sent by the client to delete or deregister a branch or label name. Deleting a branch name or a label name does not affect any elements belonging to that branch or carrying that label. This message is acknowledged by the ProjectResponse message. DeleteBranchLabelRequest ::= [APPLICATION 21] SEQUENCE { projectName OCTET STRING (SIZE (128)), comment CommentString, name CHOICE { branchName OCTET STRING (SIZE (256)), labelName OCTET STRING (SIZE (256)) } } 6.1.2.6. Project Response This message is sent by the server as an acknowledgement to the Project request messages. The status code indicates the result of the operation. S. Ramaswamy [Page 13] Internet DRAFT Implementation Recommendations February 1999 ProjectResponse ::= [APPLICATION 22] SEQUENCE { statusCode INTEGER { success (0), no-such-project (1), no-such-directory (2), invalid-project (3), invalid-acl (4) } } 6.1.3. Element Management Messages 6.1.3.1. Create Element Request This message is sent by the client to create an element. The element could be an ASCII file, a binary file or a directory. If no access list is specified in this message, it is inherited from the project. When the server receives this message, it creates the requested element. If the element is a file, it then responds with the GetFileData message, asking for the file. The client then transmits the file by sending a sequence of VCPData messages. After receiving the file the server acknowledges the file by using an ElementResponse message. CreateElementRequest ::= [APPLICATION 23] SEQUENCE { elementName OCTET STRING (SIZE (64)), elementType INTEGER { ascii-file (0), binary-file (1), directory (2) }, description OCTET STRING (SIZE (512)), acl AccessList } 6.1.3.2. Delete Element Request This message is sent by the client to delete an element. Checked out elements cannot be deleted. The server acknowledges this message by sending back an ElementResponse message. If no revision is specified then all the revisions of this element are deleted. S. Ramaswamy [Page 14] Internet DRAFT Implementation Recommendations February 1999 DeleteElementRequest ::= [APPLICATION 24] SEQUENCE { elementName OCTET STRING (SIZE (64)), revision RevisionSpec, comment CommentString, acl AccessList } 6.1.3.3. Modify Element Request This message is sent by the client to modify an element's name or access list. The new access list can either be used to overwrite or overlay on top of the existing list. The modification is applicable to all revisions of the element. This message is acknowledged by the server by sending the ElementResponse message reply. The element can also be moved to a different location (directory) in the tree by giving the appropriate prefix in the newName. ModifyElementRequest ::= [APPLICATION 25] SEQUENCE { elementName OCTET STRING (SIZE (64)), modification CHOICE { newName OCTET STRING (SIZE (64)), newAcl SEQUENCE { overwrite Boolean, acl AccessList } }, comment CommentString, } 6.1.3.4. Find Element Request This message is sent by the client to find an element under a root. The search string might contain wildcard ('*') characters. This server sends a reply in the form of a FindElementResponse message which contains the find result. If root string is empty, then either the startDirectory or current project root directory, in that order, is assumed. S. Ramaswamy [Page 15] Internet DRAFT Implementation Recommendations February 1999 FindElementRequest ::= [APPLICATION 26] SEQUENCE { findRoot OCTET STRING (SIZE (128)), findString OCTET STRING (SIZE (256)) } 6.1.3.5. Find Element Response This message is sent by the server to client in response to a FileElementRequest message. It contains the list of matched element names. The list will be empty if there are no matches. FindElementResponse ::= [APPLICATION 27] SEQUENCE { elementNames SEQUENCE OF OCTET STRING (SIZE (64)) } 6.1.3.6. Search Elements Request This message is sent by the client to search the elements for a regular expression pattern. The elementSpecList contains a list of element name expressions, which may contain wild cards. At a minimum the following wild card characters '*', '.', '+', '[', '-', ']', '^', '$' must be supported by the server. The server responds with SearchElementsResponse message. SearchElementsRequest ::= [APPLICATION 28] SEQUENCE { elementSpecList SEQUENCE OF OCTET STRING (SIZE (64)), searchString OCTET STRING (SIZE (256)) } 6.1.3.7. Search Elements Response The message is sent by the server containing the search results as a response to SearchElementsRequest message. The result is a list of text lines, along with the element name and the line number. The elementName may be empty if the search request specified exactly one element. S. Ramaswamy [Page 16] Internet DRAFT Implementation Recommendations February 1999 SearchElementsResponse ::= [APPLICATION 29] SEQUENCE OF { elementName OCTET STRING (SIZE (64)), lineNumber INTEGER, text OCTET STRING } 6.1.3.8. Checkout Request This message is sent by the client to checkout an element. Only the latest revision can be checked out. If the element is a directory and recursive is true then all the sub elements are recursively checked out. If the element is a file it is transferred to the client. The file transfer protocol is described later. After completing this operation the server sends an acknowledgement in the form of an ElementResponse message. CheckOutElementRequest ::= [APPLICATION 30] SEQUENCE { elementName OCTET STRING (SIZE (64)), comment CommentString, recursive Boolean } 6.1.3.9. Checkin Request This message is sent by the client to checkin an element. If the element is a file then the file is transferred to the server and checked in. The file transfer protocol is described later. After completing this operation the server sends an acknowledgement in the form of an ElementResponse message. CheckInElementRequest ::= [APPLICATION 31] SEQUENCE { elementName OCTET STRING (SIZE (64)), comment CommentString } S. Ramaswamy [Page 17] Internet DRAFT Implementation Recommendations February 1999 6.1.3.10. Label Request This message is sent by the client to label an element. A specific revision may be specified. The label must have already been created. If recursive flag is set all the sub elements (if any) are also labeled. This message is acknowledged by the server by using ElementResponse message. LabelElementRequest ::= [APPLICATION 32] SEQUENCE { elementName OCTET STRING (SIZE (64)), revision RevisionSpec, label OCTET STRING (SIZE (256)), recursive Boolean } 6.1.3.11. Branch Request This message is sent by the client to branch an element. A specific revision may be specified. The branch must have already been created. If recursive flag is set all the sub elements (if any) are also branched. This message is acknowledged by the server by using ElementResponse message. BranchElementRequest ::= [APPLICATION 33] SEQUENCE { elementName OCTET STRING (SIZE (64)), revision RevisionSpec, comment CommentString, branchName OCTET STRING (SIZE (256)), recursive Boolean } 6.1.3.12. Merge Request This message is sent by the client to merge an element to its parent branch. Only the latest revision in the current branch could be merged. After the merge the current branch is considered closed for this element. This message is acknowledged by the server by using ElementResponse message. MergeElementRequest ::= [APPLICATION 34] SEQUENCE { elementName OCTET STRING (SIZE (64)), comment CommentString } S. Ramaswamy [Page 18] Internet DRAFT Implementation Recommendations February 1999 6.1.3.13. Diff Request This message is sent by the client to find the difference between two elements. This is applicable only for ascii file elements. The server returns a sequence of diff records in the form of DiffElementResponse message. A specific revision may be specified for either of the element names. If revision is empty, latest revision is assumed. If the second element is empty, the preceding revision of the first element is assumed. The client may request that the white space difference be ignored. DiffElementRequest ::= [APPLICATION 35] SEQUENCE { elementName OCTET STRING (SIZE (64)), revision RevisionSpec, elementName2 OCTET STRING (SIZE (64)), revision2 RevisionSpec, ignoreWhiteSpace Boolean } 6.1.3.14. Diff Response This message is sent by the server in response to DiffElementRequest message from the client. It contains a sequence of diff records. Each diff record contains the differing texts, information on type of difference and line numbers. DiffElementResponse ::= [APPLICATION 36] SEQUENCE { records SEQUENCE OF DiffRecord } DiffRecord ::= [APPLICATION 37] SEQUENCE { type INTEGER { changed (0), deleted (1), inserted (2), moved (3) } text1 OCTET STRING, beginLine1 INTEGER, S. Ramaswamy [Page 19] Internet DRAFT Implementation Recommendations February 1999 endLine1 INTEGER, text2 OCTET STRING beginLine2 INTEGER, endLine2 INTEGER } 6.1.3.15. History Request This message is sent by the client to list the history of activities on an element in reverse chronological order. The activities include creation, branching, labeling, checkouts, checkins, etc. The client may request only a limited number of records. This message is acknowledged by the server in the form of HistoryResponse message which contains the history data. HistoryElementRequest ::= [APPLICATION 38] SEQUENCE { elementName OCTET STRING (SIZE (64)), limit INTEGER } 6.1.3.16. History Response This message is sent by the server in response to HistoryRequest message from the client. It contains a sequence of history records. HistoryElementResponse ::= [APPLICATION 39] SEQUENCE { records SEQUENCE OF HistoryRecord } HistoryRecord ::= OCTET STRING 6.1.3.17. Reserve/Unreserve Request This message is sent by the client to either reserve or unreserve an element. This operation is permitted only for the owner of the element. Reserving a elements prevents other who have the necessary permission from checking out. This message is acknowledged by the server by using the ElementResponse message. S. Ramaswamy [Page 20] Internet DRAFT Implementation Recommendations February 1999 ReserveElementRequest ::= [APPLICATION 40] SEQUENCE { elementName OCTET STRING (SIZE (64)), reserve Boolean } 6.1.3.18. Element Response This is a generic acknowledgement message used by various element request messages. It indicates to the client whether the requested operation succeeded or not. ElementResponse ::= [APPLICATION 41] SEQUENCE { statusCode INTEGER { success (0), failure (1) } } 6.2. Data Exchange The data consist of files being version controlled. The files are transferred inline between the client and the server when certain messages are processed by the server. Only block mode of file transfer is supported. This means EOF is explicitly indicated in the message. The request for receiving a file either by the client or by the server is done by using the following message: GetFileData ::= [APPLICATION 1] SEQUENCE { fileName OCTET STRING } The request for sending a file either by the client or by the server is done by using the following message: PutFileData ::= [APPLICATION 2] SEQUENCE { fileName OCTET STRING } S. Ramaswamy [Page 21] Internet DRAFT Implementation Recommendations February 1999 The data is encapsulated in the following message: VCPData ::= [APPLICATION 2] SEQUENCE { more Boolean, data OCTET STRING } The receiver keeps receiving the data until the more flag is reset. Files could be transferred in ASCII, Binary or Continuous modes [SFTP]. 6.2.1. ASCII Mode File Transfer The ASCII bytes are taken from the file in the source system, transmitted over the connection, and stored in the file in the destination system. The data is the 7-bit ASCII codes, transmitted in the low-order 7 bits of 8-bit bytes. The high-order bit of the transmission byte must be zero, and need not be stored in the file. The data is "NETASCII" and is to follow the same rules as data sent on Telnet connections. The key requirement here is that the local end of line is to be converted to the pair of ASCII characters CR and LF when transmitted on the connection. 6.2.2. Binary Mode File Transfer The 8-bit bytes are taken from the file in the source system, transmitted over the connection, and stored in the file in the destination system. The data is in 8-bit units. In systems with word sizes which are not a multiple of 8, some bits of the word will not be transmitted. 6.2.3. Continuous Mode File Transfer The bits are taken from the file in the source system continuously, ignoring word boundaries, and sent over the connection packed into 8-bit bytes. The destination system stores the bits received into the file continuously, ignoring word boundaries. For systems on machines with a word size that is a multiple of 8 bits, the implementation of binary and continuous modes should be identical. S. Ramaswamy [Page 22] Internet DRAFT Implementation Recommendations February 1999 7. References [SFTP], Lottor, M., "Simple File Transfer Protocol", RFC 913, September 1984. [ASN1] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", 1994. [BER] ITU-T Rec. X.690, "Specification of ASN.1 encoding rules: Basic, Canonical, and Distinguished Encoding Rules", 1994. 8. Author's Address Saravanan Ramaswamy Cisco Systems, Inc. Mail stop: SJC 1/3 3850 Zanker Rd San Jose CA 95134 Phone: 1-408-526-6140 Email: rsaravan@cisco.com S. Ramaswamy [Page 23]