From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Oct 1 18:32:27 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07410 for ; Tue, 1 Oct 2002 18:32:26 -0400 (EDT) Received: (qmail 17649 invoked by uid 605); 1 Oct 2002 22:34:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17640 invoked from network); 1 Oct 2002 22:34:13 -0000 Received: from 216-239-45-4.google.com (216.239.45.4) by mail.netbsd.org with SMTP; 1 Oct 2002 22:34:13 -0000 Received: from moma.corp.google.com (moma.corp.google.com [10.3.0.12]) by 216-239-45-4.google.com (8.12.3/8.12.3) with ESMTP id g91MY9DD020759; Tue, 1 Oct 2002 15:34:09 -0700 Received: from vger.corp.google.com (vger.corp.google.com [10.3.4.85]) by moma.corp.google.com (8.12.3/8.12.3) with ESMTP id g91MY9Zg031503; Tue, 1 Oct 2002 15:34:09 -0700 Received: (from frank@localhost) by vger.corp.google.com (8.10.2/8.10.2) id g91MY8W25206; Tue, 1 Oct 2002 15:34:08 -0700 Date: Tue, 1 Oct 2002 15:34:08 -0700 From: Frank Cusack To: internet-drafts@ietf.org Cc: ietf-ssh@netbsd.org Subject: draft-ietf-secsh-auth-kbdinteract-04.txt Message-ID: <20021001153408.O21904@google.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: ietf-ssh-owner@netbsd.org Precedence: list --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Capitalization (must->MUST) and updated refs are the only changes. --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="pwplus.txt" Network Working Group F. Cusack INTERNET-DRAFT Google, Inc. Expires April 2, 2003 M. Forssen Appgate AB October 2, 2002 Generic Message Exchange Authentication For SSH Status of this Memo This document is an Internet-Draft and is subject to 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 . The list of Internet-Draft Shadow Directories can be accessed at . This Internet-Draft will expire on April 2, 2003. Abstract SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). F. Cusack, M. Forssen Expires April 2, 2003 [Page 1] Internet Draft SSH Generic Interactive Authentication October 2, 2002 1. Introduction The SSH authentication protocol is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. The protocol assumes that the underlying protocols provide integrity and confidentiality protection. This document describes a general purpose authentication method for the SSH protocol. This method is suitable for interactive authentication methods which do not need any special software support on the client side. Instead all authentication data should be entered via the keyboard. The major goal of this method is to allow the SSH client to have little or no knowledge of the specifics of the underlying authentication mechanism(s) used by the SSH server. This will allow the server to arbitrarily select or change the underlying authentication mechanism(s) without having to update client code. The name for this authentication method is "keyboard-interactive". This document should be read only after reading the SSH architecture document [SSH-ARCH] and the SSH authentication document [SSH-USERAUTH]. This document freely uses terminology and notation from both documents without reference or further explanation. This document also describes some of the client interaction with the user in obtaining the authentication information. While this is somewhat out of the scope of a protocol specification, it is still described here since some aspects of the protocol are specifically designed based on user interface issues, and omitting this information may lead to incompatible or awkward implementations. 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. 2. Rationale Currently defined authentication methods for SSH are tightly coupled with the underlying authentication mechanism. This makes it difficult to add new mechanisms for authentication as all clients must be updated to support the new mechanism. With the generic method defined here, clients will not require code changes to support new authentication mechanisms, and if a separate authentication layer is used, such as [PAM], then the server may not need any code changes either. This presents a significant advantage to other methods, such as the F. Cusack, M. Forssen Expires April 2, 2003 [Page 2] Internet Draft SSH Generic Interactive Authentication October 2, 2002 "password" method (defined in [SSH-USERAUTH]), as new (presumably stronger) methods may be added "at will" and system security can be transparently enhanced. Challenge-response and One Time Password mechanisms are also easily supported with this authentication method. This authentication method is however limited to authentication mechanisms which do not require any special code, such as hardware drivers or password mangling, on the client. 3. Protocol Exchanges The client initiates the authentication with a SSH_MSG_USERAUTH_REQUEST message. The server then requests authentication information from the client with a SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the information from the user and then responds with a SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the answer from the client. 3.1 Initial Exchange The authentication starts with the client sending the following packet: byte SSH_MSG_USERAUTH_REQUEST string user name (ISO-10646 UTF-8) string service name (US-ASCII) string "keyboard-interactive" (US-ASCII) string language tag (as defined in [RFC-3066]) string submethods (ISO-10646 UTF-8) The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. The server SHOULD instead select the language used based on the tags communicated during key exchange [SSH-TRANS]. If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. The language to be used if the server does not support the requested language is implementation-dependent. The submethods field is included so the user can give a hint of which actual methods he wants to use. It is a a comma-separated list of F. Cusack, M. Forssen Expires April 2, 2003 [Page 3] Internet Draft SSH Generic Interactive Authentication October 2, 2002 authentication submethods (software or hardware) which the user prefers. If the client has knowledge of the submethods preferred by the user, presumably through a configuration setting, it MAY use the submethods field to pass this information to the server. Otherwise it MUST send the empty string. The actual names of the submethods is something which the user and the server needs to agree upon. Server interpretation of the submethods field is implementation- dependent. One possible implementation strategy of the submethods field on the server is that, unless the user may use multiple different submethods, the server ignores this field. If the user may authenticate using one of several different submethods the server should treat the submethods field as a hint on which submethod the user wants to use this time. Note that when this message is sent to the server, the client has not yet prompted the user for a password, and so that information is NOT included with this initial message (unlike the "password" method). The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message. The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message if the failure is based on the user name or service name; instead it SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just like the one(s) which would have been sent in cases where authentication should proceed, and then send the failure message (after a suitable delay, as described below). The goal is to make it impossible to find valid usernames by just comparing the results when authenticating as different users. 3.2 Information Requests Requests are generated from the server using the SSH_MSG_USERAUTH_INFO_REQUEST message. The server may send as many requests as are necessary to authenticate the client; the client MUST be prepared to handle multiple exchanges. However the server MUST NOT ever have more than one SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may not send another request before the client has answered. F. Cusack, M. Forssen Expires April 2, 2003 [Page 4] Internet Draft SSH Generic Interactive Authentication October 2, 2002 The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows: byte SSH_MSG_USERAUTH_INFO_REQUEST string name (ISO-10646 UTF-8) string instruction (ISO-10646 UTF-8) string language tag (as defined in [RFC-3066]) int num-prompts string prompt[1] (ISO-10646 UTF-8) boolean echo[1] ... string prompt[num-prompts] (ISO-10646 UTF-8) boolean echo[num-prompts] The server SHOULD take into consideration that some clients may not be able to properly display a long name or prompt field (see next section), and limit the lengths of those fields if possible. For example, instead of an instruction field of "Enter Password" and a prompt field of "Password for user23@host.domain: ", a better choice might be an instruction field of "Password authentication for user23@host.domain" and a prompt field of "Password: ". It is expected that this authentication method would typically be backended by [PAM] and so such choices would not be possible. The name and instruction fields MAY be empty strings, the client MUST be prepared to handle this correctly. The prompt field(s) MUST NOT be empty strings. The language tag SHOULD describe the language used in the textual fields. If the server does not know the language used, or if multiple languages are used, the language tag MUST be the empty string. The num-prompts field may be `0', in which case there will be no prompt/echo fields in the message, but the client SHOULD still display the name and instruction fields (as described below). 3.3 User Interface Upon receiving a request message, the client SHOULD prompt the user as follows: A command line interface (CLI) client SHOULD print the name and instruction (if non-empty), adding newlines. Then for each prompt in turn, the client SHOULD display the prompt and read the user input. A graphical user interface (GUI) client has many choices on how to prompt the user. One possibility is to use the name field (possibly F. Cusack, M. Forssen Expires April 2, 2003 [Page 5] Internet Draft SSH Generic Interactive Authentication October 2, 2002 prefixed with the application's name) as the title of a dialog window in which the prompt(s) are presented. In that dialog window, the instruction field would be a text message, and the prompts would be labels for text entry fields. All fields SHOULD be presented to the user, for example an implementation SHOULD NOT discard the name field because its windows lack titles; it SHOULD instead find another way to display this information. If prompts are presented in a dialog window, then the client SHOULD NOT present each prompt in a separate window. All clients MUST properly handle an instruction field with embedded newlines. They SHOULD also be able to display at least 30 characters for the name and prompts. If the server presents names or prompts longer than 30 characters, the client MAY truncate these fields to the length it can display. If the client does truncate any fields, there MUST be an obvious indication that such truncation has occured. The instruction field SHOULD NOT be truncated. Clients SHOULD use control character filtering as discussed in [SSH-ARCH] to avoid attacks by including terminal control characters in the fields to be displayed. For each prompt, the corresponding echo field indicates whether or not the user input should be echoed as characters are typed. Clients SHOULD correctly echo/mask user input for each prompt independently of other prompts in the request message. If a client does not honor the echo field for whatever reason, then the client MUST err on the side of masking input. A GUI client might like to have a checkbox toggling echo/mask. Clients SHOULD NOT add any additional characters to the prompt such as ": " (colon-space); the server is responsible for supplying all text to be displayed to the user. Clients MUST also accept empty responses from the user and pass them on as empty strings. 3.4 Information Responses After obtaining the requested information from the user, the client MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message. The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as follows: byte SSH_MSG_USERAUTH_INFO_RESPONSE int num-responses string response[1] (ISO-10646 UTF-8) ... string response[num-responses] (ISO-10646 UTF-8) F. Cusack, M. Forssen Expires April 2, 2003 [Page 6] Internet Draft SSH Generic Interactive Authentication October 2, 2002 Note that the responses are encoded in ISO-10646 UTF-8. It is up to the server how it interprets the responses and validates them. However, if the client reads the responses in some other encoding (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 before transmitting. If the num-responses field does not match the num-prompts field in the request message, the server MUST send a failure message. In the case that the server sends a `0' num-prompts field in the request message, the client MUST send a response message with a `0' num-responses field. The responses MUST be ordered as the prompts were ordered. That is, response[n] MUST be the answer to prompt[n]. After receiving the response, the server MUST send either a SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_INFO_REQUEST message. If the server fails to authenticate the user (through the underlying authentication mechanism(s)), it SHOULD NOT send another request message(s) in an attempt to obtain new authentication data, instead it SHOULD send a failure message. The only time the server should send multiple request messages is if additional authentication data is needed (i.e., because there are multiple underlying authentication mechanisms that must be used to authenticate the user). If the server intends to respond with a failure message, it MAY delay for an implementation-dependent time before sending to the client. It is suspected that implementations are likely to make the time delay a configurable, a suggested default is 2 seconds. 4. Authentication Examples Here are two example exchanges between a client and server. The first is an example of a challenge/response implementation. This is an authentication that is not otherwise possible with other authentication methods. C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "" C: string "" F. Cusack, M. Forssen Expires April 2, 2003 [Page 7] Internet Draft SSH Generic Interactive Authentication October 2, 2002 S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "CRYPTOCard Authentication" S: string "The challenge is '14315716'" S: string "en-US" S: int 1 S: string "Response: " S: boolean TRUE [Client prompts user for password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "6d757575" S: byte SSH_MSG_USERAUTH_SUCCESS The second example is of a standard password authentication, in this case the user's password is expired. C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "en-US" C: string "" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password Authentication" S: string "" S: string "en-US" S: int 1 S: string "Password: " S: boolean FALSE [Client prompts user for password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "password" F. Cusack, M. Forssen Expires April 2, 2003 [Page 8] Internet Draft SSH Generic Interactive Authentication October 2, 2002 S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password Expired" S: string "Your password has expired." S: string "en-US" S: int 2 S: string "Enter new password: " S: boolean FALSE S: string "Enter it again: " S: boolean FALSE [Client prompts user for new password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 2 C: string "newpass" C: string "newpass" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password changed" S: string "Password successfully changed for user23." S: string "en-US" S: int 0 [Client displays message to user] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 0 S: byte SSH_MSG_USERAUTH_SUCCESS 5. Protocol constants The following method-specific constants are used with this authentication method: SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_RESPONSE 61 6. References [PAM] Samar, V., Schemers, R., "Unified Login With Pluggable Authentication Modules (PAM)", OSF RFC 86.0, October 1995 F. Cusack, M. Forssen Expires April 2, 2003 [Page 9] Internet Draft SSH Generic Interactive Authentication October 2, 2002 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC-2279] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, October 1996. [RFC-3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [SSH-ARCH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Protocol Architecture", work in progress, draft-ietf-secsh-architecture-13.txt, September, 2002. [SSH-CONNECT] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Connection Protocol", work in progress, draft-ietf-secsh-connect-16.txt, September, 2002. [SSH-TRANS] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Transport Layer Protocol", work in progress, draft-ietf-secsh-transport-15.txt, September, 2002. [SSH-USERAUTH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Authentication Protocol", work in progress, draft-ietf-secsh-userauth-16.txt, September, 2002. F. Cusack, M. Forssen Expires April 2, 2003 [Page 10] Internet Draft SSH Generic Interactive Authentication October 2, 2002 7. Author's Addresses Frank Cusack Google, Inc. 2400 Bayshore Parkway Mountain View, CA 94043 Email: frank@google.com Martin Forssen Appgate AB Stora Badhusgatan 18-20 SE-411 21 Gothenburg SWEDEN Email: maf@appgate.com F. Cusack, M. Forssen Expires April 2, 2003 [Page 11] --PNTmBPCT7hxwcZjr-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Oct 3 07:12:19 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02033 for ; Thu, 3 Oct 2002 07:12:19 -0400 (EDT) Received: (qmail 17949 invoked by uid 605); 3 Oct 2002 11:14:11 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17942 invoked from network); 3 Oct 2002 11:14:10 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 3 Oct 2002 11:14:10 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02006; Thu, 3 Oct 2002 07:12:09 -0400 (EDT) Message-Id: <200210031112.HAA02006@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-auth-kbdinteract-04.txt Date: Thu, 03 Oct 2002 07:12:09 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : Generic Message Exchange Authentication For SSH Author(s) : M. Forssen, F. Cusack Filename : draft-ietf-secsh-auth-kbdinteract-04.txt Pages : 11 Date : 2002-10-2 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-auth-kbdinteract-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-auth-kbdinteract-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-2132944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-auth-kbdinteract-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-auth-kbdinteract-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-2132944.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 07:18:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA13619 for ; Mon, 7 Oct 2002 07:18:01 -0400 (EDT) Received: (qmail 11268 invoked by uid 605); 7 Oct 2002 11:19:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 11261 invoked from network); 7 Oct 2002 11:19:58 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 7 Oct 2002 11:19:58 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13606; Mon, 7 Oct 2002 07:17:52 -0400 (EDT) Message-Id: <200210071117.HAA13606@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-assignednumbers-01.txt Date: Mon, 07 Oct 2002 07:17:52 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH Protocol Assigned Numbers Author(s) : S. Lehtinen, D. Moffat Filename : draft-ietf-secsh-assignednumbers-01.txt Pages : 10 Date : 2002-10-4 This document defines the initial state of the IANA assigned numbers for the SSH protocol as defined in [SSH-ARCH], [SSH-TRANS], [SSH- CONNECT], [SSH-USERAUTH]. This document does not define any new protocols or any number ranges not already defined in the above referenced documents. It is intended only for initalization of the IANA databases referenced in those documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-assignednumbers-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-assignednumbers-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-assignednumbers-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-4124602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-assignednumbers-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-assignednumbers-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-4124602.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:05:42 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17154 for ; Mon, 7 Oct 2002 09:05:41 -0400 (EDT) Received: (qmail 7239 invoked by uid 605); 7 Oct 2002 13:07:15 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7229 invoked from network); 7 Oct 2002 13:07:13 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 7 Oct 2002 13:07:13 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N4H17>; Mon, 7 Oct 2002 09:07:12 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA70D@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" Cc: "'ietf-ssh@netbsd.org'" Subject: RE: Draft draft of coming sftp revision... Date: Mon, 7 Oct 2002 09:07:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list Is there a good reason for changing the relative order of times and permissions in the file attributes? The change makes it harder to program a client/server that can handle either. draft-02: uint32 flags uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE uint32 uid present only if flag SSH_FILEXFER_ATTR_UIDGID uint32 gid present only if flag SSH_FILEXFER_ATTR_UIDGID uint32 permissions present only if flag SSH_FILEXFER_ATTR_PERMISSIONS uint32 atime present only if flag SSH_FILEXFER_ACMODTIME uint32 mtime present only if flag SSH_FILEXFER_ACMODTIME uint32 extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED string extended_type string extended_data ... more extended data (extended_type - extended_data pairs), so that number of pairs equals extended_count draft-draft: uint32 flags byte type always present uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE string owner present only if flag SSH_FILEXFER_ATTR_OWNERGROUP string group present only if flag SSH_FILEXFER_ATTR_OWNERGROUP uint32 atime present only if flag SSH_FILEXFER_ACMODATIME uint32 ctime present only if flag SSH_FILEXFER_ACMODCTIME uint32 mtime present only if flag SSH_FILEXFER_ACMODMTIME uint32 permissions present only if flag SSH_FILEXFER_ATTR_PERMISSIONS string acl present only if flag SSH_FILEXFER_ATTR_ACL uint32 extended_count present only if flag SSH_FILEXFER_ATTR_EXTENDED string extended_type string extended_data ... more extended data (extended_type - extended_data pairs), so that number of pairs equals extended_count From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:18:15 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17473 for ; Mon, 7 Oct 2002 09:18:15 -0400 (EDT) Received: (qmail 14860 invoked by uid 605); 7 Oct 2002 13:20:14 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14853 invoked from network); 7 Oct 2002 13:20:14 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 13:20:14 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959181; Mon, 07 Oct 2002 07:20:12 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 07:20:12 -0600 (Mountain Daylight Time) Message-ID: <003201c26e04$18b42960$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Richard Whalen" Cc: References: <63D30D6E10CFD11190A90000F805FE86040AA6F2@lespaul.process.com> Subject: Re: Questions on reading a writing of text files.... Date: Mon, 7 Oct 2002 07:18:58 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > The draft draft contains the following: > > 6.4 Reading and Writing > > Once a file has been opened, it can be read using the SSH_FXP_READ > message, which has the following format: > > uint32 id > string handle > uint64 offset > uint32 len > > where `id' is the request identifier, `handle' is an open file handle > returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative > to the beginning of the file from where to start reading, and `len' > is the maximum number of bytes to read. > > In response to this request, the server will read as many bytes as it > can from the file (up to `len'), and return them in a SSH_FXP_DATA > message. If an error occurs or EOF is encountered before reading any > data, the server will respond with SSH_FXP_STATUS. For normal disk > files, it is guaranteed that this will read the specified number of > bytes, or up to end of file. For e.g. device files this may return > fewer bytes than requested. > > Writing to a file is achieved using the SSH_FXP_WRITE message, which > has the following format: > > uint32 id > string handle > uint64 offset > string data > > where `id' is a request identifier, `handle' is a file handle > returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the > beginning of the file where to start writing, and `data' is the data > to be written. > > The write will extend the file if writing beyond the end of the file. > It is legal to write way beyond the end of the file; the semantics > are to write zeroes from the end of the file to the specified offset > and then the data. On most operating systems, such writes do not > allocate disk space but instead leave "holes" in the file. > > The server responds to a write request with a SSH_FXP_STATUS message. > > > When operating in text mode, should a read just return one line (with the > appropriate end of line sequence), or should it fill the buffer, separating > each line with the end of line sequence. What if a line has more characters > than are available in the buffer, should the portion that fits be returned > and the remainder saved for the next read? > > There are fewer questions about writes, but what should be done with a write > that does not end in the end of line sequence? Should it wait for another > write that contains the sequence and the two be appended? Good questions. I was assuming the operating characteristics of read and write would not change, which means partial lines could be both read and written. This is definitely the simplest way to go in terms of the amount of verbiage needed for the draft. (For example, line is too big for buffer question just goes away.) Is it too onerous to implement, do you think? - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:21:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17552 for ; Mon, 7 Oct 2002 09:21:30 -0400 (EDT) Received: (qmail 16325 invoked by uid 605); 7 Oct 2002 13:23:28 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16299 invoked from network); 7 Oct 2002 13:23:28 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 13:23:28 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959186; Mon, 07 Oct 2002 07:23:27 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 07:23:27 -0600 (Mountain Daylight Time) Message-ID: <003a01c26e04$8d033f40$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Richard Whalen" Cc: References: <63D30D6E10CFD11190A90000F805FE86040AA70D@lespaul.process.com> Subject: Re: Draft draft of coming sftp revision... Date: Mon, 7 Oct 2002 07:22:13 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Good catch. I've reordered them. See my next message for more about times. - Joseph > Is there a good reason for changing the relative order of times and > permissions in the file attributes? The change makes it harder to program a > client/server that can handle either. > > draft-02: > > uint32 flags > uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE > uint32 uid present only if flag > SSH_FILEXFER_ATTR_UIDGID > uint32 gid present only if flag > SSH_FILEXFER_ATTR_UIDGID > uint32 permissions present only if flag > SSH_FILEXFER_ATTR_PERMISSIONS > uint32 atime present only if flag SSH_FILEXFER_ACMODTIME > uint32 mtime present only if flag SSH_FILEXFER_ACMODTIME > uint32 extended_count present only if flag > SSH_FILEXFER_ATTR_EXTENDED > string extended_type > string extended_data > ... more extended data (extended_type - extended_data pairs), > so that number of pairs equals extended_count > > > draft-draft: > uint32 flags > byte type always present > uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE > string owner present only if flag > SSH_FILEXFER_ATTR_OWNERGROUP > string group present only if flag > SSH_FILEXFER_ATTR_OWNERGROUP > uint32 atime present only if flag SSH_FILEXFER_ACMODATIME > uint32 ctime present only if flag SSH_FILEXFER_ACMODCTIME > uint32 mtime present only if flag SSH_FILEXFER_ACMODMTIME > uint32 permissions present only if flag > SSH_FILEXFER_ATTR_PERMISSIONS > string acl present only if flag SSH_FILEXFER_ATTR_ACL > uint32 extended_count present only if flag > SSH_FILEXFER_ATTR_EXTENDED > string extended_type > string extended_data > ... more extended data (extended_type - extended_data pairs), > so that number of pairs equals extended_count > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:30:45 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17905 for ; Mon, 7 Oct 2002 09:30:45 -0400 (EDT) Received: (qmail 22199 invoked by uid 605); 7 Oct 2002 13:32:45 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22192 invoked from network); 7 Oct 2002 13:32:44 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 13:32:44 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959192 for ietf-ssh@netbsd.org; Mon, 07 Oct 2002 07:32:43 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 07:32:43 -0600 (Mountain Daylight Time) Message-ID: <004001c26e05$d8bb2370$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Subject: ctime vs. Create Time Date: Mon, 7 Oct 2002 07:31:30 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Hi all, In the 'draft-draft' version of the sftp draft, I added a ctime field. Then, in the course of some other work I was doing, I actually looked at what the ctime field meant. Here is the text describing both the ctime and mtime fields from the linux man page: The field st_mtime is changed by file modifications, e.g. by mknod(2), truncate(2), utime(2) and write(2) (of more than zero bytes). Moreover, st_mtime of a directory is changed by the creation or deletion of files in that directory. The st_mtime field is not changed for changes in owner, group, hard link count, or mode. The field st_ctime is changed by writing or by setting inode information (i.e., owner, group, link count, mode, etc.). Now, thats not what I thought at all! I thought the 'c' in ctime stood for create. (You may even notice that in the paragraph describing 'atime', 'ctime', and 'mtime', I said that ctime was 'creation' time. Under windows, the creation time of a file is stored, and I was looking for the ability to perserve that value. So, in my working copy I've changed ctime into 'createtime'. I'm not sure I see a need for both mtime and ctime. Do people think we need both? What do people think about create time? - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:37:40 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18060 for ; Mon, 7 Oct 2002 09:37:39 -0400 (EDT) Received: (qmail 26374 invoked by uid 605); 7 Oct 2002 13:39:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26367 invoked from network); 7 Oct 2002 13:39:39 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 7 Oct 2002 13:39:39 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N4HG4>; Mon, 7 Oct 2002 09:39:38 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA70E@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" Cc: ietf-ssh@netbsd.org Subject: RE: Questions on reading a writing of text files.... Date: Mon, 7 Oct 2002 09:39:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > When operating in text mode, should a read just return one line (with the > appropriate end of line sequence), or should it fill the buffer, separating > each line with the end of line sequence. What if a line has more characters > than are available in the buffer, should the portion that fits be returned > and the remainder saved for the next read? > > There are fewer questions about writes, but what should be done with a write > that does not end in the end of line sequence? Should it wait for another > write that contains the sequence and the two be appended? Good questions. I was assuming the operating characteristics of read and write would not change, which means partial lines could be both read and written. This is definitely the simplest way to go in terms of the amount of verbiage needed for the draft. (For example, line is too big for buffer question just goes away.) Is it too onerous to implement, do you think? - Joseph Partial reads are not difficult to implement. Partial writes could be difficult to implement, depending upon VMS file organization and whether or not the write is at the end of the file. I think that a line stating "All end of line sequences are explicit when operating on a file in text mode." would eliminate any confusion. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:40:00 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18155 for ; Mon, 7 Oct 2002 09:40:00 -0400 (EDT) Received: (qmail 27795 invoked by uid 605); 7 Oct 2002 13:42:00 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27785 invoked from network); 7 Oct 2002 13:41:58 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 7 Oct 2002 13:41:58 -0000 Received: from danlaptop.process.com ([198.115.142.137]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KNDJCH5FFO8WWDI5@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Mon, 07 Oct 2002 07:41:56 -0700 (MST) Date: Mon, 07 Oct 2002 07:40:56 -0600 From: "Dan O'Reilly" Subject: Re: ctime vs. Create Time In-reply-to: <004001c26e05$d8bb2370$4d00a8c0@galb.vandyke.com> X-Sender: oreilly@raptor.psccos.com To: Joseph Galbraith Cc: ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20021007073744.00abf5e8@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii Sender: ietf-ssh-owner@netbsd.org Precedence: list I would much prefer that both creation and modification times be preserved. If we're talking about copying a file intact between systems, inevitably, there will be somebody who will have that requirement. If the field is common (or at least reasonably so), I always vote to preserve it if at all possible. For example, in VMS there are even more time fields kept for a file, although I don't expect this standard to address those (unless you're feeling particularly amicable today ). At 07:31 AM 10/7/2002, Joseph Galbraith wrote: >Hi all, > >In the 'draft-draft' version of the sftp draft, >I added a ctime field. Then, in the course of >some other work I was doing, I actually looked >at what the ctime field meant. > >Here is the text describing both the ctime and >mtime fields from the linux man page: > > The field st_mtime is changed by file modifications, e.g. > by mknod(2), truncate(2), utime(2) and write(2) (of more > than zero bytes). Moreover, st_mtime of a directory is > changed by the creation or deletion of files in that > directory. The st_mtime field is not changed for changes > in owner, group, hard link count, or mode. > > The field st_ctime is changed by writing or by setting > inode information (i.e., owner, group, link count, mode, > etc.). > >Now, thats not what I thought at all! I thought the 'c' in >ctime stood for create. (You may even notice that in the >paragraph describing 'atime', 'ctime', and 'mtime', I said >that ctime was 'creation' time. > >Under windows, the creation time of a file is stored, and I >was looking for the ability to perserve that value. > >So, in my working copy I've changed ctime into 'createtime'. > >I'm not sure I see a need for both mtime and ctime. Do people >think we need both? > >What do people think about create time? > >- Joseph ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:40:46 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18185 for ; Mon, 7 Oct 2002 09:40:45 -0400 (EDT) Received: (qmail 28567 invoked by uid 605); 7 Oct 2002 13:42:44 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28559 invoked from network); 7 Oct 2002 13:42:44 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 13:42:44 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959208; Mon, 07 Oct 2002 07:42:43 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 07:42:43 -0600 (Mountain Daylight Time) Message-ID: <005401c26e07$3deb4350$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Richard Whalen" Cc: References: <63D30D6E10CFD11190A90000F805FE86040AA70E@lespaul.process.com> Subject: Re: Questions on reading a writing of text files.... Date: Mon, 7 Oct 2002 07:41:29 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > When operating in text mode, should a read just return one line (with the > > appropriate end of line sequence), or should it fill the buffer, > separating > > each line with the end of line sequence. What if a line has more > characters > > than are available in the buffer, should the portion that fits be returned > > and the remainder saved for the next read? > > > > There are fewer questions about writes, but what should be done with a > write > > that does not end in the end of line sequence? Should it wait for another > > write that contains the sequence and the two be appended? > > Good questions. I was assuming the operating characteristics of read and > write would not change, which means partial lines could be both read and > written. This is definitely the simplest way to go in terms of the amount > of verbiage needed for the draft. (For example, line is too big for buffer > question just goes away.) > > Is it too onerous to implement, do you think? > > - Joseph > > Partial reads are not difficult to implement. > > Partial writes could be difficult to implement, depending upon VMS file > organization and whether or not the write is at the end of the file. > > I think that a line stating "All end of line sequences are explicit when > operating on a file in text mode." would eliminate any confusion. I'm not sure where this text would go? Is this more along the lines of 'partial eol sequences should be ignored'? I currently have some text in there about that (added after posting draft-draft in response to someones feedback. Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:49:31 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18629 for ; Mon, 7 Oct 2002 09:49:30 -0400 (EDT) Received: (qmail 2663 invoked by uid 605); 7 Oct 2002 13:51:24 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 2524 invoked from network); 7 Oct 2002 13:51:16 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 13:51:16 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959217 for ietf-ssh@netbsd.org; Mon, 07 Oct 2002 07:51:15 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 07:51:15 -0600 (Mountain Daylight Time) Message-ID: <005c01c26e08$6f709c80$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Subject: sftp changes... Date: Mon, 7 Oct 2002 07:50:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit One important thing to note is the change to the way version information is sent. I talked to many of the implementation authors directly about this change at connectathon, but realized it had been brought up here on the list. Previously, when the server sent its version packet, it sent the lower of its version and the clients version (so if the client supported a lesser version, it echoed the clients version.) In the current draft, the server responds with its protocol version, and then both the client and server use the lower of the two version numbers sent on the wire. This is mostly useful for debugging, where knowing what the servers version is might be useful. (Though I will admit, it is a bug in our implementation as well...) Is this going to cause problems for implmentators? Do currently shipping clients check the server response to make sure it isn't higher than what they sent? Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:49:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18649 for ; Mon, 7 Oct 2002 09:49:48 -0400 (EDT) Received: (qmail 3408 invoked by uid 605); 7 Oct 2002 13:51:48 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3401 invoked from network); 7 Oct 2002 13:51:47 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 13:51:47 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959221; Mon, 07 Oct 2002 07:51:47 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 07:51:47 -0600 (Mountain Daylight Time) Message-ID: <005d01c26e08$82158f80$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Dan O'Reilly" Cc: References: <5.1.0.14.2.20021007073744.00abf5e8@raptor.psccos.com> Subject: Re: ctime vs. Create Time Date: Mon, 7 Oct 2002 07:50:33 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > I would much prefer that both creation and modification times be preserved. > If we're talking about copying a file intact between systems, inevitably, > there will be somebody who will have that requirement. If the field is > common (or at least reasonably so), I always vote to preserve it if at all > possible. > > For example, in VMS there are even more time fields kept for a file, although > I don't expect this standard to address those (unless you're feeling > particularly amicable today ). Well, I might be :-) I don't remember what they are though; my VMS experience is about 10 years ago, so it is growing dimmer and dimmer. I was trying to remember if VMS did create time and thought that it did. What other time fields does VMS keep? Do you think the draft should address them? Do you think they are useful, even if not generally implementable? - Joseph > > > At 07:31 AM 10/7/2002, Joseph Galbraith wrote: > >Hi all, > > > >In the 'draft-draft' version of the sftp draft, > >I added a ctime field. Then, in the course of > >some other work I was doing, I actually looked > >at what the ctime field meant. > > > >Here is the text describing both the ctime and > >mtime fields from the linux man page: > > > > The field st_mtime is changed by file modifications, e.g. > > by mknod(2), truncate(2), utime(2) and write(2) (of more > > than zero bytes). Moreover, st_mtime of a directory is > > changed by the creation or deletion of files in that > > directory. The st_mtime field is not changed for changes > > in owner, group, hard link count, or mode. > > > > The field st_ctime is changed by writing or by setting > > inode information (i.e., owner, group, link count, mode, > > etc.). > > > >Now, thats not what I thought at all! I thought the 'c' in > >ctime stood for create. (You may even notice that in the > >paragraph describing 'atime', 'ctime', and 'mtime', I said > >that ctime was 'creation' time. > > > >Under windows, the creation time of a file is stored, and I > >was looking for the ability to perserve that value. > > > >So, in my working copy I've changed ctime into 'createtime'. > > > >I'm not sure I see a need for both mtime and ctime. Do people > >think we need both? > > > >What do people think about create time? > > > >- Joseph > > ------ > +-------------------------------+----------------------------------------+ > | Dan O'Reilly | "There are 10 types of people in this | > | Principal Engineer | world: those who understand binary | > | Process Software | and those who don't." | > | http://www.process.com | | > +-------------------------------+----------------------------------------+ > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:50:33 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18676 for ; Mon, 7 Oct 2002 09:50:33 -0400 (EDT) Received: (qmail 4135 invoked by uid 605); 7 Oct 2002 13:52:33 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4127 invoked from network); 7 Oct 2002 13:52:32 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 7 Oct 2002 13:52:32 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N4HHS>; Mon, 7 Oct 2002 09:52:32 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA70F@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , ietf-ssh@netbsd.org Subject: RE: ctime vs. Create Time Date: Mon, 7 Oct 2002 09:52:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Monday, October 07, 2002 9:32 AM > To: ietf-ssh@netbsd.org > Subject: ctime vs. Create Time > > > Hi all, > > In the 'draft-draft' version of the sftp draft, > I added a ctime field. Then, in the course of > some other work I was doing, I actually looked > at what the ctime field meant. > > Here is the text describing both the ctime and > mtime fields from the linux man page: > > The field st_mtime is changed by file modifications, e.g. > by mknod(2), truncate(2), utime(2) and write(2) (of more > than zero bytes). Moreover, st_mtime of a directory is > changed by the creation or deletion of files in that > directory. The st_mtime field is not changed for changes > in owner, group, hard link count, or mode. > > The field st_ctime is changed by writing or by setting > inode information (i.e., owner, group, link count, mode, > etc.). > > Now, thats not what I thought at all! I thought the 'c' in > ctime stood for create. (You may even notice that in the > paragraph describing 'atime', 'ctime', and 'mtime', I said > that ctime was 'creation' time. > > Under windows, the creation time of a file is stored, and I > was looking for the ability to perserve that value. > > So, in my working copy I've changed ctime into 'createtime'. > > I'm not sure I see a need for both mtime and ctime. Do people > think we need both? > > What do people think about create time? > > - Joseph > The compiler I use didn't like ctime, so I ended up changing the field name to be creation_time. I like the idea of having creation time available (as a true creation time), as it allows a method of determining whether a file with a particular name and a change in modification time means that a file was modified, or whether it is an entirely new file with the same name as a previous file. Some systems may not be able to report some times - VMS does not generally record read-only access to a file, so there is no difference between atime and mtime. If your question is about "needing" a "ctime" in the linux concept of "ctime", then I agree that there is no need for both "ctime" and "mtime". ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:51:49 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18711 for ; Mon, 7 Oct 2002 09:51:48 -0400 (EDT) Received: (qmail 4897 invoked by uid 605); 7 Oct 2002 13:53:49 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4890 invoked from network); 7 Oct 2002 13:53:48 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 13:53:48 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959234; Mon, 07 Oct 2002 07:53:47 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 07:53:47 -0600 (Mountain Daylight Time) Message-ID: <006401c26e08$c9b82f00$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Richard Whalen" , References: <63D30D6E10CFD11190A90000F805FE86040AA70F@lespaul.process.com> Subject: Re: ctime vs. Create Time Date: Mon, 7 Oct 2002 07:52:33 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > If your question is about "needing" a "ctime" in the linux concept of > "ctime", then I agree that there is no need for both "ctime" and "mtime". Yes, that was my question. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:57:21 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18976 for ; Mon, 7 Oct 2002 09:57:21 -0400 (EDT) Received: (qmail 8384 invoked by uid 605); 7 Oct 2002 13:59:22 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8377 invoked from network); 7 Oct 2002 13:59:21 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 7 Oct 2002 13:59:21 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N4H2N>; Mon, 7 Oct 2002 09:59:20 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA710@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , ietf-ssh@netbsd.org Subject: RE: sftp changes... Date: Mon, 7 Oct 2002 09:59:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > > Is this going to cause problems for implmentators? Do > currently shipping clients check the server response > to make sure it isn't higher than what they sent? > > Thanks, > > - Joseph > The F-Secure 3.1.0 code base (which Process Software built on for its VMS implementation) uses lower of the version number received and its own. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 09:58:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19050 for ; Mon, 7 Oct 2002 09:58:27 -0400 (EDT) Received: (qmail 9833 invoked by uid 605); 7 Oct 2002 14:00:26 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9825 invoked from network); 7 Oct 2002 14:00:25 -0000 Received: from raptor.psccos.com (207.225.29.51) by mail.netbsd.org with SMTP; 7 Oct 2002 14:00:25 -0000 Received: from danlaptop.process.com ([198.115.142.137]) by RAPTOR.PSCCOS.COM (PMDF V6.1 #36649) with ESMTPA id <01KNDK08MSK48WWDI5@RAPTOR.PSCCOS.COM> for ietf-ssh@netbsd.org; Mon, 07 Oct 2002 08:00:23 -0700 (MST) Date: Mon, 07 Oct 2002 07:59:18 -0600 From: "Dan O'Reilly" Subject: Re: ctime vs. Create Time In-reply-to: <005d01c26e08$82158f80$4d00a8c0@galb.vandyke.com> X-Sender: oreilly@raptor.psccos.com To: Joseph Galbraith Cc: ietf-ssh@netbsd.org Message-id: <5.1.0.14.2.20021007075645.00ac8c88@raptor.psccos.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Content-type: text/plain; format=flowed; charset=us-ascii References: <5.1.0.14.2.20021007073744.00abf5e8@raptor.psccos.com> Sender: ietf-ssh-owner@netbsd.org Precedence: list At 07:50 AM 10/7/2002, Joseph Galbraith wrote: > > I would much prefer that both creation and modification times be >preserved. > > If we're talking about copying a file intact between systems, inevitably, > > there will be somebody who will have that requirement. If the field is > > common (or at least reasonably so), I always vote to preserve it if at all > > possible. > > > > For example, in VMS there are even more time fields kept for a file, >although > > I don't expect this standard to address those (unless you're feeling > > particularly amicable today ). > >Well, I might be :-) > >I don't remember what they are though; my VMS experience is >about 10 years ago, so it is growing dimmer and dimmer. >I was trying to remember if VMS did create time and thought >that it did. What other time fields does VMS keep? If memory serves (I'm not near a VMS system at this point), there is a backup date and a "shelving" date (when the file was copied to other media, not as a backup). I don't know that either would be of any specific value to keep, however, as those are pretty much specific within the context of an individual system, and I would think they would tend to lose meaning when copied to another system. >Do you think the draft should address them? Do you think >they are useful, even if not generally implementable? > >- Joseph ------ +-------------------------------+----------------------------------------+ | Dan O'Reilly | "There are 10 types of people in this | | Principal Engineer | world: those who understand binary | | Process Software | and those who don't." | | http://www.process.com | | +-------------------------------+----------------------------------------+ From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 10:02:37 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19581 for ; Mon, 7 Oct 2002 10:02:36 -0400 (EDT) Received: (qmail 12848 invoked by uid 605); 7 Oct 2002 14:04:37 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12841 invoked from network); 7 Oct 2002 14:04:37 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 14:04:37 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959242; Mon, 07 Oct 2002 08:04:36 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 08:04:36 -0600 (Mountain Daylight Time) Message-ID: <007301c26e0a$4c87ed20$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Richard Whalen" , References: <63D30D6E10CFD11190A90000F805FE86040AA710@lespaul.process.com> Subject: Re: sftp changes... Date: Mon, 7 Oct 2002 08:03:22 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > > Is this going to cause problems for implmentators? Do > > currently shipping clients check the server response > > to make sure it isn't higher than what they sent? > > > > Thanks, > > > > - Joseph > > > > The F-Secure 3.1.0 code base (which Process Software built on for its VMS > implementation) uses lower of the version number received and its own. Excellent! That implies that they read the draft the same we we did, and that the draft has now been corrected to match both our implementations :-) That is on the client side right? The change basically makes it symetrical (both client and server do what you've described.) Previously, only server had to do it. Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 10:10:59 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19930 for ; Mon, 7 Oct 2002 10:10:58 -0400 (EDT) Received: (qmail 17029 invoked by uid 605); 7 Oct 2002 14:12:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 17022 invoked from network); 7 Oct 2002 14:12:57 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 7 Oct 2002 14:12:57 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N4HJL>; Mon, 7 Oct 2002 10:12:56 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA711@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , ietf-ssh@netbsd.org Subject: RE: sftp changes... Date: Mon, 7 Oct 2002 10:12:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Monday, October 07, 2002 10:03 AM > To: Richard Whalen; ietf-ssh@netbsd.org > Subject: Re: sftp changes... > > > > > Is this going to cause problems for implmentators? Do > > > currently shipping clients check the server response > > > to make sure it isn't higher than what they sent? > > > > > > Thanks, > > > > > > - Joseph > > > > > > > The F-Secure 3.1.0 code base (which Process Software built > on for its VMS > > implementation) uses lower of the version number received > and its own. > > Excellent! That implies that they read the > draft the same we we did, and that the draft > has now been corrected to match both our > implementations :-) > > That is on the client side right? The change basically > makes it symetrical (both client and server do what you've > described.) Previously, only server had to do it. > > Thanks, > > - Joseph > The server returns the lower of its version and the version sent in the SSH_FXP_INIT packet. The client uses the lower of its version and the version received in the SSH_FXP_VERSION packet. So, a change to the server code would be needed to return the highest version that it can operate at, rather than the version that the client has requested it to operate at. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 10:23:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20367 for ; Mon, 7 Oct 2002 10:23:01 -0400 (EDT) Received: (qmail 23830 invoked by uid 605); 7 Oct 2002 14:24:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23823 invoked from network); 7 Oct 2002 14:24:58 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 7 Oct 2002 14:24:58 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N4HKH>; Mon, 7 Oct 2002 10:24:57 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA712@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" Cc: ietf-ssh@netbsd.org Subject: RE: Questions on reading a writing of text files.... Date: Mon, 7 Oct 2002 10:24:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list > > I think that a line stating "All end of line sequences are > explicit when > > operating on a file in text mode." would eliminate any confusion. > > I'm not sure where this text would go? Is this more along the lines > of 'partial eol sequences should be ignored'? I currently have some > text in there about that (added after posting draft-draft in response > to someones feedback. > > Thanks, > > - Joseph > > I think that it may be covered by your text that states that partial eol sequences should be ignored. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 10:26:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20432 for ; Mon, 7 Oct 2002 10:26:09 -0400 (EDT) Received: (qmail 26258 invoked by uid 605); 7 Oct 2002 14:27:57 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26251 invoked from network); 7 Oct 2002 14:27:53 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 14:27:53 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959330 for ietf-ssh@netbsd.org; Mon, 07 Oct 2002 08:27:52 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 08:27:52 -0600 (Mountain Daylight Time) Message-ID: <009401c26e0d$8ccb2930$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Subject: Latest sftp draft-draft... Date: Mon, 7 Oct 2002 08:26:39 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0091_01C26DDB.4200F6A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list This is a multi-part message in MIME format. ------=_NextPart_000_0091_01C26DDB.4200F6A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit I believe we are getting close to submitting. Changes since the previous draft-draft: o Change ctime to create-time. o Reorder permissions and time fields back to their original order in attribute packet. o Clarify that partial new-line sequences should be ignored. o Clarify that size field represents that size of the file on disk, and for text mode operations, it does not necessarily represent the size of the file on the wire. o Clarify that the offset parameter to write will be ignored when FXF_APPEND is specified. o Introduce 'text-seek' extension request, and specify that offset fields in read and write packets are to be ignored when FXF_TEXT is specified. o Add clarifying text indicating that 'parallel' read and write operations must be processed successfully on FXF_TEXT files. o Clean up formatting and break up description of parameters for MKDIR & RMDIR. Also, revise text describing when a RMDIR can fail. o Run through spell checker. - Joseph ------=_NextPart_000_0091_01C26DDB.4200F6A0 Content-Type: text/plain; name="draft-ietf-secsh-filexfer.txt" Content-Disposition: attachment; filename="draft-ietf-secsh-filexfer.txt" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= Secure Shell Working Group J. Galbraith=0A= Internet-Draft VanDyke Software=0A= Expires: April 7, 2003 T. Ylonen=0A= S. Lehtinen=0A= SSH Communications Security Corp=0A= October 7, 2002=0A= =0A= =0A= SSH File Transfer Protocol=0A= draft-ietf-secsh-filexfer-04.txt=0A= =0A= Status of this Memo=0A= =0A= This document is an Internet-Draft and is in full conformance with=0A= all provisions of Section 10 of RFC2026.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at http://=0A= www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on April 7, 2003.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The Internet Society (2002). All Rights Reserved.=0A= =0A= Abstract=0A= =0A= The SSH File Transfer Protocol provides secure file transfer=0A= functionality over any reliable data stream. It is the standard file=0A= transfer protocol for use with the SSH2 protocol. This document=0A= describes the file transfer protocol and its interface to the SSH2=0A= protocol suite.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 1]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. Use with the SSH Connection Protocol . . . . . . . . . . . 4=0A= 3. General Packet Format . . . . . . . . . . . . . . . . . . 5=0A= 4. Protocol Initialization . . . . . . . . . . . . . . . . . 7=0A= 4.1 Client Initialization . . . . . . . . . . . . . . . . . . 7=0A= 4.2 Server Initialization . . . . . . . . . . . . . . . . . . 7=0A= 4.3 Determining Server Newline Convention . . . . . . . . . . 8=0A= 5. File Attributes . . . . . . . . . . . . . . . . . . . . . 9=0A= 5.1 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9=0A= 5.2 Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 10=0A= 5.3 Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 10=0A= 5.4 Owner and Group . . . . . . . . . . . . . . . . . . . . . 10=0A= 5.5 Permissions . . . . . . . . . . . . . . . . . . . . . . . 10=0A= 5.6 Times . . . . . . . . . . . . . . . . . . . . . . . . . . 11=0A= 5.7 ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 11=0A= 5.8 Extended attributes . . . . . . . . . . . . . . . . . . . 12=0A= 6. Requests From the Client to the Server . . . . . . . . . . 13=0A= 6.1 Request Synchronization and Reordering . . . . . . . . . . 13=0A= 6.2 File Names . . . . . . . . . . . . . . . . . . . . . . . . 14=0A= 6.3 Opening, Creating, and Closing Files . . . . . . . . . . . 14=0A= 6.4 Reading and Writing . . . . . . . . . . . . . . . . . . . 17=0A= 6.5 Removing and Renaming Files . . . . . . . . . . . . . . . 18=0A= 6.6 Creating and Deleting Directories . . . . . . . . . . . . 18=0A= 6.7 Scanning Directories . . . . . . . . . . . . . . . . . . . 19=0A= 6.8 Retrieving File Attributes . . . . . . . . . . . . . . . . 20=0A= 6.9 Setting File Attributes . . . . . . . . . . . . . . . . . 21=0A= 6.10 Dealing with Symbolic links . . . . . . . . . . . . . . . 22=0A= 6.11 Canonicalizing the Server-Side Path Name . . . . . . . . . 23=0A= 6.11.1 Best practice for dealing with paths . . . . . . . . . . . 23=0A= 7. Responses from the Server to the Client . . . . . . . . . 24=0A= 8. Vendor-Specific Extensions . . . . . . . . . . . . . . . . 28=0A= 9. Security Considerations . . . . . . . . . . . . . . . . . 29=0A= 10. Changes from previous protocol versions . . . . . . . . . 30=0A= 10.1 Changes between versions 4 and 3 . . . . . . . . . . . . . 30=0A= 10.2 Changes between versions 3 and 2 . . . . . . . . . . . . . 31=0A= 10.3 Changes between versions 2 and 1 . . . . . . . . . . . . . 31=0A= 10.4 Changes between versions 1 and 0 . . . . . . . . . . . . . 31=0A= 11. Trademark Issues . . . . . . . . . . . . . . . . . . . . . 32=0A= References . . . . . . . . . . . . . . . . . . . . . . . . 33=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . 33=0A= Full Copyright Statement . . . . . . . . . . . . . . . . . 35=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 2]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 1. Introduction=0A= =0A= This protocol provides secure file transfer (and more generally file=0A= system access) functionality over a reliable data stream, such as a=0A= channel in the SSH2 protocol [5].=0A= =0A= This protocol is designed so that it could be used to implement a=0A= secure remote file system service, as well as a secure file transfer=0A= service.=0A= =0A= This protocol assumes that it runs over a secure channel, and that=0A= the server has already authenticated the user at the client end, and=0A= that the identity of the client user is externally available to the=0A= server implementation.=0A= =0A= In general, this protocol follows a simple request-response model.=0A= Each request and response contains a sequence number and multiple=0A= requests may be pending simultaneously. There are a relatively large=0A= number of different request messages, but a small number of possible=0A= response messages. Each request has one or more response messages=0A= that may be returned in result (e.g., a read either returns data or=0A= reports error status).=0A= =0A= The packet format descriptions in this specification follow the=0A= notation presented in the secsh architecture draft. [5]=0A= =0A= Even though this protocol is described in the context of the SSH2=0A= protocol, this protocol is general and independent of the rest of the=0A= SSH2 protocol suite. It could be used in a number of different=0A= applications, such as secure file transfer over TLS RFC 2246 [1] and=0A= transfer of management information in VPN applications.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 3]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 2. Use with the SSH Connection Protocol=0A= =0A= When used with the SSH2 Protocol suite, this protocol is intended to=0A= be used from the SSH Connection Protocol [7] as a subsystem, as=0A= described in section ``Starting a Shell or a Command''. The=0A= subsystem name used with this protocol is "sftp".=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 4]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 3. General Packet Format=0A= =0A= All packets transmitted over the secure connection are of the=0A= following format:=0A= =0A= uint32 length=0A= byte type=0A= byte[length - 1] data payload=0A= =0A= That is, they are just data preceded by 32-bit length and 8-bit type=0A= fields. The `length' is the length of the data area, and does not=0A= include the `length' field itself. The format and interpretation of=0A= the data area depends on the packet type.=0A= =0A= All packet descriptions below only specify the packet type and the=0A= data that goes into the data field. Thus, they should be prefixed by=0A= the `length' and `type' fields.=0A= =0A= The maximum size of a packet is in practice determined by the client=0A= (the maximum size of read or write requests that it sends, plus a few=0A= bytes of packet overhead). All servers SHOULD support packets of at=0A= least 34000 bytes (where the packet size refers to the full length,=0A= including the header above). This should allow for reads and writes=0A= of at most 32768 bytes.=0A= =0A= There is no limit on the number of outstanding (non-acknowledged)=0A= requests that the client may send to the server. In practice this is=0A= limited by the buffering available on the data stream and the queuing=0A= performed by the server. If the server's queues are full, it should=0A= not read any more data from the stream, and flow control will prevent=0A= the client from sending more requests. Note, however, that while=0A= there is no restriction on the protocol level, the client's API may=0A= provide a limit in order to prevent infinite queuing of outgoing=0A= requests at the client.=0A= =0A= The following values are defined for packet types.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 5]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= #define SSH_FXP_INIT 1=0A= #define SSH_FXP_VERSION 2=0A= #define SSH_FXP_OPEN 3=0A= #define SSH_FXP_CLOSE 4=0A= #define SSH_FXP_READ 5=0A= #define SSH_FXP_WRITE 6=0A= #define SSH_FXP_LSTAT 7=0A= #define SSH_FXP_FSTAT 8=0A= #define SSH_FXP_SETSTAT 9=0A= #define SSH_FXP_FSETSTAT 10=0A= #define SSH_FXP_OPENDIR 11=0A= #define SSH_FXP_READDIR 12=0A= #define SSH_FXP_REMOVE 13=0A= #define SSH_FXP_MKDIR 14=0A= #define SSH_FXP_RMDIR 15=0A= #define SSH_FXP_REALPATH 16=0A= #define SSH_FXP_STAT 17=0A= #define SSH_FXP_RENAME 18=0A= #define SSH_FXP_READLINK 19=0A= #define SSH_FXP_SYMLINK 20=0A= =0A= #define SSH_FXP_STATUS 101=0A= #define SSH_FXP_HANDLE 102=0A= #define SSH_FXP_DATA 103=0A= #define SSH_FXP_NAME 104=0A= #define SSH_FXP_ATTRS 105=0A= =0A= #define SSH_FXP_EXTENDED 200=0A= #define SSH_FXP_EXTENDED_REPLY 201=0A= =0A= RESERVED_FOR_EXTENSIONS 210-255=0A= =0A= Additional packet types should only be defined if the protocol=0A= version number (see Section ``Protocol Initialization'') is=0A= incremented, and their use MUST be negotiated using the version=0A= number. However, the SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY=0A= packets can be used to implement vendor-specific extensions. See=0A= Section ``Vendor-Specific-Extensions'' for more details.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 6]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 4. Protocol Initialization=0A= =0A= When the file transfer protocol starts, the client first sends a=0A= SSH_FXP_INIT (including its version number) packet to the server.=0A= The server responds with a SSH_FXP_VERSION packet, supplying the=0A= version of the protocol it supports. The version number used for=0A= this session is the lower of the two version numbers.=0A= =0A= The version number of the protocol specified in this document is 4.=0A= The version number should be incremented for each incompatible=0A= revision of this protocol.=0A= =0A= 4.1 Client Initialization=0A= =0A= The SSH_FXP_INIT packet (from client to server) has the following=0A= data:=0A= =0A= uint32 version=0A= =0A= Version 3 of this protocol allowed clients to include extensions in=0A= the SSH_FXP_INIT packet; however, this can cause interoperability=0A= problems with version 1 and version 2 servers because the client must=0A= send this packet before knowing the servers version.=0A= =0A= In this version of the protocol, clients MUST use the=0A= SSH_FXP_EXTENDED packet to send extensions to the server after=0A= version exchange has completed. Clients MUST NOT include extensions=0A= in the version packet. This will prevent interoperability problems=0A= with older servers=0A= =0A= 4.2 Server Initialization=0A= =0A= The SSH_FXP_VERSION packet (from server to client) has the following=0A= data:=0A= =0A= uint32 version=0A= =0A= =0A= The extension data may be empty, or may be a sequence of=0A= =0A= string extension_name=0A= string extension_data=0A= =0A= pairs (both strings MUST always be present if one is, but the=0A= `extension_data' string may be of zero length). If present, these=0A= strings indicate extensions to the baseline protocol. The=0A= `extension_name' field(s) identify the name of the extension. The=0A= name should be of the form "name@domain", where the domain is the DNS=0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 7]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= domain name of the organization defining the extension. Additional=0A= names that are not of this format may be defined later by the IETF.=0A= Implementations MUST silently ignore any extensions whose name they=0A= do not recognize.=0A= =0A= 4.3 Determining Server Newline Convention=0A= =0A= In order to correctly process text files in a cross platform=0A= compatible way, the newline convention must be converted from that of=0A= the server to that of the client, or, during an upload, from that of=0A= the client to that of the server.=0A= =0A= Versions 3 and prior of this protocol made no provisions for=0A= processing text files. Many clients implemented some sort of=0A= conversion algorithm, but without either a 'canonical' on the wire=0A= format or knowledge of the servers newline convention, correct=0A= conversion was not always possible.=0A= =0A= Starting with Version 4, the SSH_FXF_TEXT file open flag (Section=0A= 6.3) makes it possible to request that the server translate a file to=0A= a 'canonical' on the wire format. This format uses \r\n as the line=0A= separator.=0A= =0A= Servers for systems using multiple newline characters (for example,=0A= Mac OS X or VMS) or systems using counted records, MUST translate to=0A= the canonical form.=0A= =0A= However, to ease the burden of implementation on servers that use a=0A= single, simple separator sequence, the following extension allows the=0A= canonical format to be changed.=0A= =0A= string "newline"=0A= string new-canonical-separator (usually "\r" or "\n" or "\r\n")=0A= =0A= All clients MUST support this extension.=0A= =0A= When processing text files, clients SHOULD NOT translate any=0A= character or sequence that is not an exact match of the servers=0A= newline separator.=0A= =0A= In particular, if the newline sequence being used is the canonical=0A= "\r\n" sequence, a lone \r or a lone \n SHOULD be written through=0A= without change.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 8]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 5. File Attributes=0A= =0A= A new compound data type is defined for encoding file attributes.=0A= The same encoding is used both when returning file attributes from=0A= the server and when sending file attributes to the server. When=0A= sending it to the server, the flags field specifies which attributes=0A= are included, and the server will use default values for the=0A= remaining attributes (or will not modify the values of remaining=0A= attributes). When receiving attributes from the server, the flags=0A= specify which attributes are included in the returned data. The=0A= server normally returns all attributes it knows about.=0A= =0A= uint32 flags=0A= byte type always present=0A= uint64 size present only if flag SSH_FILEXFER_ATTR_SIZE=0A= string owner present only if flag = SSH_FILEXFER_ATTR_OWNERGROUP=0A= string group present only if flag = SSH_FILEXFER_ATTR_OWNERGROUP=0A= uint32 permissions present only if flag = SSH_FILEXFER_ATTR_PERMISSIONS=0A= uint32 atime present only if flag SSH_FILEXFER_ACMODATIME=0A= uint32 createtime present only if flag = SSH_FILEXFER_ACMODCREATE_TIME=0A= uint32 mtime present only if flag SSH_FILEXFER_ACMODMTIME=0A= string acl present only if flag SSH_FILEXFER_ATTR_ACL=0A= uint32 extended_count present only if flag = SSH_FILEXFER_ATTR_EXTENDED=0A= string extended_type=0A= string extended_data=0A= ... more extended data (extended_type - extended_data pairs),=0A= so that number of pairs equals extended_count=0A= =0A= =0A= 5.1 Flags=0A= =0A= The `flags' specify which of the fields are present. Those fields=0A= for which the corresponding flag is not set are not present (not=0A= included in the packet). New flags can only be added by incrementing=0A= the protocol version number (or by using the extension mechanism=0A= described below).=0A= =0A= The flags bits are defined to have the following values:=0A= =0A= #define SSH_FILEXFER_ATTR_SIZE 0x00000001=0A= #define SSH_FILEXFER_ATTR_OWNERGROUP 0x00000002=0A= #define SSH_FILEXFER_ATTR_PERMISSIONS 0x00000004=0A= #define SSH_FILEXFER_ATTR_ACMODATIME 0x00000008=0A= #define SSH_FILEXFER_ATTR_ACMODCREATETIME 0x00000010=0A= #define SSH_FILEXFER_ATTR_ACMODMTIME 0x00000020=0A= #define SSH_FILEXFER_ATTR_ACL 0x00000040=0A= #define SSH_FILEXFER_ATTR_EXTENDED 0x80000000=0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 9]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 5.2 Type=0A= =0A= The type field is always present. The following types are defined:=0A= =0A= #define SSH_FILEXFER_TYPE_REGULAR 1=0A= #define SSH_FILEXFER_TYPE_DIRECTORY 2=0A= #define SSH_FILEXFER_TYPE_SYMLINK 3=0A= #define SSH_FILEXFER_TYPE_SPECIAL 4=0A= #define SSH_FILEXFER_TYPE_UNKNOWN 5=0A= =0A= On a POSIX system, these values would be derived from the permission=0A= field.=0A= =0A= 5.3 Size=0A= =0A= The `size' field specifies the size of the file on disk, in bytes.=0A= If it is present during file creation, it should be considered a hint=0A= as to the files eventual size.=0A= =0A= Files opened with the SSH_FXF_TEXT flag may have a size that is=0A= greater or less than the value of the size field.=0A= =0A= 5.4 Owner and Group=0A= =0A= The `owner' and `group' fields are represented as UTF-8 strings; this=0A= is the form used by NFS v4. See NFS version 4 Protocol. [3] The=0A= following text is selected quotations from section 5.6.=0A= =0A= To avoid a representation that is tied to a particular underlying=0A= implementation at the client or server, the use of UTF-8 strings has=0A= been chosen. The string should be of the form user@dns_domain".=0A= This will allow for a client and server that do not use the same=0A= local representation the ability to translate to a common syntax that=0A= can be interpreted by both. In the case where there is no=0A= translation available to the client or server, the attribute value=0A= must be constructed without the "@". Therefore, the absence of the @=0A= from the owner or owner_group attribute signifies that no translation=0A= was available and the receiver of the attribute should not place any=0A= special meaning with the attribute value. Even though the attribute=0A= value can not be translated, it may still be useful. In the case of=0A= a client, the attribute string may be used for local display of=0A= ownership.=0A= =0A= 5.5 Permissions=0A= =0A= The `permissions' field contains a bit mask of file permissions as=0A= defined by POSIX [1].=0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 10]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 5.6 Times=0A= =0A= The 'atime', 'createtime', and 'mtime' contain the access, creation,=0A= and modification times of the files, respectively. They are=0A= represented as seconds from Jan 1, 1970 in UTC.=0A= =0A= 5.7 ACL=0A= =0A= The 'ACL' field contains an ACL similar to that defined in section=0A= 5.9 of NFS version 4 Protocol [3].=0A= =0A= uint32 ace-count=0A= =0A= repeated ace-count time:=0A= uint32 ace-type=0A= uint32 ace-flag=0A= uint32 ace-mask=0A= string who [UTF-8]=0A= =0A= ace-type is one of the following four values (taken from NFS Version=0A= 4 Protocol [3]:=0A= =0A= const ACE4_ACCESS_ALLOWED_ACE_TYPE =3D 0x00000000;=0A= const ACE4_ACCESS_DENIED_ACE_TYPE =3D 0x00000001;=0A= const ACE4_SYSTEM_AUDIT_ACE_TYPE =3D 0x00000002;=0A= const ACE4_SYSTEM_ALARM_ACE_TYPE =3D 0x00000003;=0A= =0A= ace-flag is a combination of the following flag values. See NFS=0A= Version 4 Protocol [3] section 5.9.2:=0A= =0A= const ACE4_FILE_INHERIT_ACE =3D 0x00000001;=0A= const ACE4_DIRECTORY_INHERIT_ACE =3D 0x00000002;=0A= const ACE4_NO_PROPAGATE_INHERIT_ACE =3D 0x00000004;=0A= const ACE4_INHERIT_ONLY_ACE =3D 0x00000008;=0A= const ACE4_SUCCESSFUL_ACCESS_ACE_FLAG =3D 0x00000010;=0A= const ACE4_FAILED_ACCESS_ACE_FLAG =3D 0x00000020;=0A= const ACE4_IDENTIFIER_GROUP =3D 0x00000040;=0A= =0A= ace-mask is any combination of the following flags (taken from NFS=0A= Version 4 Protocol [3] section 5.9.3:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 11]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= const ACE4_READ_DATA =3D 0x00000001;=0A= const ACE4_LIST_DIRECTORY =3D 0x00000001;=0A= const ACE4_WRITE_DATA =3D 0x00000002;=0A= const ACE4_ADD_FILE =3D 0x00000002;=0A= const ACE4_APPEND_DATA =3D 0x00000004;=0A= const ACE4_ADD_SUBDIRECTORY =3D 0x00000004;=0A= const ACE4_READ_NAMED_ATTRS =3D 0x00000008;=0A= const ACE4_WRITE_NAMED_ATTRS =3D 0x00000010;=0A= const ACE4_EXECUTE =3D 0x00000020;=0A= const ACE4_DELETE_CHILD =3D 0x00000040;=0A= const ACE4_READ_ATTRIBUTES =3D 0x00000080;=0A= const ACE4_WRITE_ATTRIBUTES =3D 0x00000100;=0A= const ACE4_DELETE =3D 0x00010000;=0A= const ACE4_READ_ACL =3D 0x00020000;=0A= const ACE4_WRITE_ACL =3D 0x00040000;=0A= const ACE4_WRITE_OWNER =3D 0x00080000;=0A= const ACE4_SYNCHRONIZE =3D 0x00100000;=0A= =0A= who is a UTF-8 string of the form described in 'Owner and Group'=0A= (Section 5.4)=0A= =0A= 5.8 Extended attributes=0A= =0A= The SSH_FILEXFER_ATTR_EXTENDED flag provides a general extension=0A= mechanism for vendor-specific extensions. If the flag is specified,=0A= then the `extended_count' field is present. It specifies the number=0A= of extended_type-extended_data pairs that follow. Each of these=0A= pairs specifies an extended attribute. For each of the attributes,=0A= the extended_type field should be a string of the format=0A= "name@domain", where "domain" is a valid, registered domain name and=0A= "name" identifies the method. The IETF may later standardize certain=0A= names that deviate from this format (e.g., that do not contain the=0A= "@" sign). The interpretation of `extended_data' depends on the=0A= type. Implementations SHOULD ignore extended data fields that they=0A= do not understand.=0A= =0A= Additional fields can be added to the attributes by either defining=0A= additional bits to the flags field to indicate their presence, or by=0A= defining extended attributes for them. The extended attributes=0A= mechanism is recommended for most purposes; additional flags bits=0A= should only be defined by an IETF standards action that also=0A= increments the protocol version number. The use of such new fields=0A= MUST be negotiated by the version number in the protocol exchange.=0A= It is a protocol error if a packet with unsupported protocol bits is=0A= received.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 12]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 6. Requests From the Client to the Server=0A= =0A= Requests from the client to the server represent the various file=0A= system operations. Each request begins with an `id' field, which is=0A= a 32-bit identifier identifying the request (selected by the client).=0A= The same identifier will be returned in the response to the request.=0A= One possible implementation is a monotonically increasing request=0A= sequence number (modulo 2^32).=0A= =0A= Many operations in the protocol operate on open files. The=0A= SSH_FXP_OPEN request can return a file handle (which is an opaque=0A= variable-length string) which may be used to access the file later=0A= (e.g. in a read operation). The client MUST NOT send requests the=0A= server with bogus or closed handles. However, the server MUST=0A= perform adequate checks on the handle in order to avoid security=0A= risks due to fabricated handles.=0A= =0A= This design allows either stateful and stateless server=0A= implementation, as well as an implementation which caches state=0A= between requests but may also flush it. The contents of the file=0A= handle string are entirely up to the server and its design. The=0A= client should not modify or attempt to interpret the file handle=0A= strings.=0A= =0A= The file handle strings MUST NOT be longer than 256 bytes.=0A= =0A= 6.1 Request Synchronization and Reordering=0A= =0A= The protocol and implementations MUST process requests relating to=0A= the same file in the order in which they are received. In other=0A= words, if an application submits multiple requests to the server, the=0A= results in the responses will be the same as if it had sent the=0A= requests one at a time and waited for the response in each case. For=0A= example, the server may process non-overlapping read/write requests=0A= to the same file in parallel, but overlapping reads and writes cannot=0A= be reordered or parallelized. However, there are no ordering=0A= restrictions on the server for processing requests from two different=0A= file transfer connections. The server may interleave and parallelize=0A= them at will.=0A= =0A= There are no restrictions on the order in which responses to=0A= outstanding requests are delivered to the client, except that the=0A= server must ensure fairness in the sense that processing of no=0A= request will be indefinitely delayed even if the client is sending=0A= other requests so that there are multiple outstanding requests all=0A= the time.=0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 13]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 6.2 File Names=0A= =0A= This protocol represents file names as strings. File names are=0A= assumed to use the slash ('/') character as a directory separator.=0A= =0A= File names starting with a slash are "absolute", and are relative to=0A= the root of the file system. Names starting with any other character=0A= are relative to the user's default directory (home directory). Note=0A= that identifying the user is assumed to take place outside of this=0A= protocol.=0A= =0A= Servers SHOULD interpret a path name component ".." as referring to=0A= the parent directory, and "." as referring to the current directory.=0A= If the server implementation limits access to certain parts of the=0A= file system, it must be extra careful in parsing file names when=0A= enforcing such restrictions. There have been numerous reported=0A= security bugs where a ".." in a path name has allowed access outside=0A= the intended area.=0A= =0A= An empty path name is valid, and it refers to the user's default=0A= directory (usually the user's home directory).=0A= =0A= Otherwise, no syntax is defined for file names by this specification.=0A= Clients should not make any other assumptions; however, they can=0A= splice path name components returned by SSH_FXP_READDIR together=0A= using a slash ('/') as the separator, and that will work as expected.=0A= =0A= In order to comply with IETF Policy on Character Sets and Languages=0A= [2], all filenames are to be encoded in UTF-8. The shortest valid=0A= UTF-8 encoding of the UNICODE data MUST be used. The server is=0A= responsible for converting the UNICODE data to whatever canonical=0A= form it requires.=0A= =0A= For example, if the server requires that precomposed characters=0A= always be used, the server MUST NOT assume the filename as sent by=0A= the client has this attribute, but must do this normalization itself.=0A= =0A= It is understood that the lack of well-defined semantics for file=0A= names may cause interoperability problems between clients and servers=0A= using radically different operating systems. However, this approach=0A= is known to work acceptably with most systems, and alternative=0A= approaches that e.g. treat file names as sequences of structured=0A= components are quite complicated.=0A= =0A= 6.3 Opening, Creating, and Closing Files=0A= =0A= Files are opened and created using the SSH_FXP_OPEN message, whose=0A= data part is as follows:=0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 14]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= uint32 id=0A= string filename [UTF-8]=0A= uint32 pflags=0A= ATTRS attrs=0A= =0A= The `id' field is the request identifier as for all requests.=0A= =0A= The `filename' field specifies the file name. See Section ``File=0A= Names'' for more information.=0A= =0A= The `pflags' field is a bitmask. The following bits have been=0A= defined.=0A= =0A= #define SSH_FXF_READ 0x00000001=0A= #define SSH_FXF_WRITE 0x00000002=0A= #define SSH_FXF_APPEND 0x00000004=0A= #define SSH_FXF_CREAT 0x00000008=0A= #define SSH_FXF_TRUNC 0x00000010=0A= #define SSH_FXF_EXCL 0x00000020=0A= #define SSH_FXF_TEXT 0x00000040=0A= =0A= These have the following meanings:=0A= =0A= SSH_FXF_READ=0A= Open the file for reading.=0A= =0A= SSH_FXF_WRITE=0A= Open the file for writing. If both this and SSH_FXF_READ are=0A= specified, the file is opened for both reading and writing.=0A= =0A= SSH_FXF_APPEND=0A= Force all writes to append data at the end of the file. The=0A= offset parameter to write will be ignored.=0A= =0A= SSH_FXF_CREAT=0A= If this flag is specified, then a new file will be created if one=0A= does not already exist (if O_TRUNC is specified, the new file will=0A= be truncated to zero length if it previously exists).=0A= =0A= SSH_FXF_TRUNC=0A= Forces an existing file with the same name to be truncated to zero=0A= length when creating a file by specifying SSH_FXF_CREAT.=0A= SSH_FXF_CREAT MUST also be specified if this flag is used.=0A= =0A= SSH_FXF_EXCL=0A= Causes the request to fail if the named file already exists.=0A= SSH_FXF_CREAT MUST also be specified if this flag is used.=0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 15]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= SSH_FXF_TEXT=0A= Indicates that the server should treat the file as text and=0A= convert it to the canonical newline convention in use. (See=0A= Determining Server Newline Convention. (Section 4.3)=0A= =0A= When a file is opened with the FXF_TEXT flag, the offset field in=0A= both the read and write function are ignored.=0A= =0A= Servers MUST correctly process multiple parallel reads and writes=0A= correctly in this mode. Naturally, it is permissible for them to=0A= do this by serializing the requests. It would not be possible for=0A= a client to reliably detect a server that does not implement=0A= parallel writes in time to prevent damage.=0A= =0A= Clients SHOULD use the SSH_FXF_APPEND flag to append data to a=0A= text file rather then using write with a calculated offset.=0A= =0A= To support seeks on text file the following SSH_FXP_EXTENDED=0A= packet is defined.=0A= =0A= =0A= =0A= string "text-seek"=0A= string file-handle=0A= uint64 line-number=0A= =0A= line-number is the index of the line number to seek to, where byte=0A= 0 in the file is line number 0, and the byte directly following=0A= the first newline sequence in the file is line number 1 and so on.=0A= =0A= Servers SHOULD support at least one "text-seek" in order to=0A= support resume. However, a client MUST be prepared to receive=0A= SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation.=0A= The client can then try a fall-back strategy, if it has one.=0A= =0A= Clients MUST be prepared to handle SSH_FX_OP_UNSUPPORTED returned=0A= for read or write operations that are not sequential.=0A= =0A= The `attrs' field specifies the initial attributes for the file.=0A= Default values will be used for those attributes that are not=0A= specified. See Section ``File Attributes'' for more information.=0A= =0A= The response to this message will be either SSH_FXP_HANDLE (if the=0A= operation is successful) or SSH_FXP_STATUS (if the operation fails).=0A= =0A= A file is closed by using the SSH_FXP_CLOSE request. Its data field=0A= has the following format:=0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 16]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= uint32 id=0A= string handle=0A= =0A= where `id' is the request identifier, and `handle' is a handle=0A= previously returned in the response to SSH_FXP_OPEN or=0A= SSH_FXP_OPENDIR. The handle becomes invalid immediately after this=0A= request has been sent.=0A= =0A= The response to this request will be a SSH_FXP_STATUS message. One=0A= should note that on some server platforms even a close can fail.=0A= This can happen e.g. if the server operating system caches writes,=0A= and an error occurs while flushing cached writes during the close.=0A= =0A= 6.4 Reading and Writing=0A= =0A= Once a file has been opened, it can be read using the SSH_FXP_READ=0A= message, which has the following format:=0A= =0A= uint32 id=0A= string handle=0A= uint64 offset=0A= uint32 len=0A= =0A= where `id' is the request identifier, `handle' is an open file handle=0A= returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) relative=0A= to the beginning of the file from where to start reading, and `len'=0A= is the maximum number of bytes to read.=0A= =0A= In response to this request, the server will read as many bytes as it=0A= can from the file (up to `len'), and return them in a SSH_FXP_DATA=0A= message. If an error occurs or EOF is encountered before reading any=0A= data, the server will respond with SSH_FXP_STATUS. For normal disk=0A= files, it is guaranteed that this will read the specified number of=0A= bytes, or up to end of file. For e.g. device files this may return=0A= fewer bytes than requested.=0A= =0A= Writing to a file is achieved using the SSH_FXP_WRITE message, which=0A= has the following format:=0A= =0A= uint32 id=0A= string handle=0A= uint64 offset=0A= string data=0A= =0A= where `id' is a request identifier, `handle' is a file handle=0A= returned by SSH_FXP_OPEN, `offset' is the offset (in bytes) from the=0A= beginning of the file where to start writing, and `data' is the data=0A= to be written.=0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 17]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= The write will extend the file if writing beyond the end of the file.=0A= It is legal to write way beyond the end of the file; the semantics=0A= are to write zeroes from the end of the file to the specified offset=0A= and then the data. On most operating systems, such writes do not=0A= allocate disk space but instead leave "holes" in the file.=0A= =0A= The server responds to a write request with a SSH_FXP_STATUS message.=0A= =0A= 6.5 Removing and Renaming Files=0A= =0A= Files can be removed using the SSH_FXP_REMOVE message. It has the=0A= following format:=0A= =0A= uint32 id=0A= string filename [UTF-8]=0A= =0A= where `id' is the request identifier and `filename' is the name of=0A= the file to be removed. See Section ``File Names'' for more=0A= information. This request cannot be used to remove directories.=0A= =0A= The server will respond to this request with a SSH_FXP_STATUS=0A= message.=0A= =0A= Files (and directories) can be renamed using the SSH_FXP_RENAME=0A= message. Its data is as follows:=0A= =0A= uint32 id=0A= string oldpath [UTF-8]=0A= string newpath [UTF-8]=0A= =0A= where `id' is the request identifier, `oldpath' is the name of an=0A= existing file or directory, and `newpath' is the new name for the=0A= file or directory. It is an error if there already exists a file=0A= with the name specified by newpath. The server may also fail rename=0A= requests in other situations, for example if `oldpath' and `newpath'=0A= point to different file systems on the server.=0A= =0A= The server will respond to this request with a SSH_FXP_STATUS=0A= message.=0A= =0A= 6.6 Creating and Deleting Directories=0A= =0A= New directories can be created using the SSH_FXP_MKDIR request. It=0A= has the following format:=0A= =0A= uint32 id=0A= string path [UTF-8]=0A= ATTRS attrs=0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 18]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= where `id' is the request identifier.=0A= =0A= `path' specifies the directory to be created. See Section ``File=0A= Names'' for more information on file names.=0A= =0A= `attrs' specifies the attributes that should be applied to it upon=0A= creation. Attributes are discussed in more detail in Section ``File=0A= Attributes''.=0A= =0A= The server will respond to this request with a SSH_FXP_STATUS=0A= message. If a file or directory with the specified path already=0A= exists, an error will be returned.=0A= =0A= Directories can be removed using the SSH_FXP_RMDIR request, which has=0A= the following format:=0A= =0A= uint32 id=0A= string path [UTF-8]=0A= =0A= where `id' is the request identifier, and `path' specifies the=0A= directory to be removed. See Section ``File Names'' for more=0A= information on file names.=0A= =0A= The server responds to this request with a SSH_FXP_STATUS message.=0A= Errors may be returned from this operation for various reasons,=0A= including, but not limited to, the path does not exist, the path does=0A= not refer to a directory object, the directory is not empty, or the=0A= user has insufficient access or permission to perform the requested=0A= operation.=0A= =0A= 6.7 Scanning Directories=0A= =0A= The files in a directory can be listed using the SSH_FXP_OPENDIR and=0A= SSH_FXP_READDIR requests. Each SSH_FXP_READDIR request returns one=0A= or more file names with full file attributes for each file. The=0A= client should call SSH_FXP_READDIR repeatedly until it has found the=0A= file it is looking for or until the server responds with a=0A= SSH_FXP_STATUS message indicating an error (normally SSH_FX_EOF if=0A= there are no more files in the directory). The client should then=0A= close the handle using the SSH_FXP_CLOSE request.=0A= =0A= The SSH_FXP_OPENDIR opens a directory for reading. It has the=0A= following format:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 19]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= uint32 id=0A= string path [UTF-8]=0A= =0A= where `id' is the request identifier and `path' is the path name of=0A= the directory to be listed (without any trailing slash). See Section=0A= ``File Names'' for more information on file names. This will return=0A= an error if the path does not specify a directory or if the directory=0A= is not readable. The server will respond to this request with either=0A= a SSH_FXP_HANDLE or a SSH_FXP_STATUS message.=0A= =0A= Once the directory has been successfully opened, files (and=0A= directories) contained in it can be listed using SSH_FXP_READDIR=0A= requests. These are of the format=0A= =0A= uint32 id=0A= string handle=0A= =0A= where `id' is the request identifier, and `handle' is a handle=0A= returned by SSH_FXP_OPENDIR. (It is a protocol error to attempt to=0A= use an ordinary file handle returned by SSH_FXP_OPEN.)=0A= =0A= The server responds to this request with either a SSH_FXP_NAME or a=0A= SSH_FXP_STATUS message. One or more names may be returned at a time.=0A= Full status information is returned for each name in order to speed=0A= up typical directory listings.=0A= =0A= If there are no more names available to be read, the server MUST=0A= respond with a SSH_FXP_STATUS message with error code of SSH_FX_EOF.=0A= =0A= When the client no longer wishes to read more names from the=0A= directory, it SHOULD call SSH_FXP_CLOSE for the handle. The handle=0A= should be closed regardless of whether an error has occurred or not.=0A= =0A= 6.8 Retrieving File Attributes=0A= =0A= Very often, file attributes are automatically returned by=0A= SSH_FXP_READDIR. However, sometimes there is need to specifically=0A= retrieve the attributes for a named file. This can be done using the=0A= SSH_FXP_STAT, SSH_FXP_LSTAT and SSH_FXP_FSTAT requests.=0A= =0A= SSH_FXP_STAT and SSH_FXP_LSTAT only differ in that SSH_FXP_STAT=0A= follows symbolic links on the server, whereas SSH_FXP_LSTAT does not=0A= follow symbolic links. Both have the same format:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 20]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= uint32 id=0A= string path [UTF-8]=0A= uint32 flags=0A= =0A= where `id' is the request identifier, and `path' specifies the file=0A= system object for which status is to be returned. The server=0A= responds to this request with either SSH_FXP_ATTRS or SSH_FXP_STATUS.=0A= =0A= The flags field specify the attribute flags in which the client has=0A= particular interest. This is a hint to the server. For example,=0A= because retrieving owner / group and acl information can be an=0A= expensive operation under some operating systems, the server may=0A= choose not to retrieve this information unless the client expresses a=0A= specific interest in it.=0A= =0A= The client has no guarantee the server will provide all the fields=0A= that it has expressed an interest in.=0A= =0A= SSH_FXP_FSTAT differs from the others in that it returns status=0A= information for an open file (identified by the file handle). Its=0A= format is as follows:=0A= =0A= uint32 id=0A= string handle=0A= uint32 flags=0A= =0A= where `id' is the request identifier and `handle' is a file handle=0A= returned by SSH_FXP_OPEN. The server responds to this request with=0A= SSH_FXP_ATTRS or SSH_FXP_STATUS.=0A= =0A= 6.9 Setting File Attributes=0A= =0A= File attributes may be modified using the SSH_FXP_SETSTAT and=0A= SSH_FXP_FSETSTAT requests. These requests are used for operations=0A= such as changing the ownership, permissions or access times, as well=0A= as for truncating a file.=0A= =0A= The SSH_FXP_SETSTAT request is of the following format:=0A= =0A= uint32 id=0A= string path [UTF-8]=0A= ATTRS attrs=0A= =0A= where `id' is the request identifier, `path' specifies the file=0A= system object (e.g. file or directory) whose attributes are to be=0A= modified, and `attrs' specifies the modifications to be made to its=0A= attributes. Attributes are discussed in more detail in Section=0A= ``File Attributes''.=0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 21]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= An error will be returned if the specified file system object does=0A= not exist or the user does not have sufficient rights to modify the=0A= specified attributes. The server responds to this request with a=0A= SSH_FXP_STATUS message.=0A= =0A= The SSH_FXP_FSETSTAT request modifies the attributes of a file which=0A= is already open. It has the following format:=0A= =0A= uint32 id=0A= string handle=0A= ATTRS attrs=0A= =0A= where `id' is the request identifier, `handle' (MUST be returned by=0A= SSH_FXP_OPEN) identifies the file whose attributes are to be=0A= modified, and `attrs' specifies the modifications to be made to its=0A= attributes. Attributes are discussed in more detail in Section=0A= ``File Attributes''. The server will respond to this request with=0A= SSH_FXP_STATUS.=0A= =0A= 6.10 Dealing with Symbolic links=0A= =0A= The SSH_FXP_READLINK request may be used to read the target of a=0A= symbolic link. It would have a data part as follows:=0A= =0A= uint32 id=0A= string path [UTF-8]=0A= =0A= where `id' is the request identifier and `path' specifies the path=0A= name of the symlink to be read.=0A= =0A= The server will respond with a SSH_FXP_NAME packet containing only=0A= one name and a dummy attributes value. The name in the returned=0A= packet contains the target of the link. If an error occurs, the=0A= server may respond with SSH_FXP_STATUS.=0A= =0A= The SSH_FXP_SYMLINK request will create a symbolic link on the=0A= server. It is of the following format=0A= =0A= uint32 id=0A= string linkpath [UTF-8]=0A= string targetpath [UTF-8]=0A= =0A= where `id' is the request identifier, `linkpath' specifies the path=0A= name of the symlink to be created and `targetpath' specifies the=0A= target of the symlink. The server shall respond with a=0A= SSH_FXP_STATUS indicating either success (SSH_FX_OK) or an error=0A= condition.=0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 22]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 6.11 Canonicalizing the Server-Side Path Name=0A= =0A= The SSH_FXP_REALPATH request can be used to have the server=0A= canonicalize any given path name to an absolute path. This is useful=0A= for converting path names containing ".." components or relative=0A= pathnames without a leading slash into absolute paths. The format of=0A= the request is as follows:=0A= =0A= uint32 id=0A= string path [UTF-8]=0A= =0A= where `id' is the request identifier and `path' specifies the path=0A= name to be canonicalized. The server will respond with a=0A= SSH_FXP_NAME packet containing the name in canonical form and a dummy=0A= attributes value. If an error occurs, the server may also respond=0A= with SSH_FXP_STATUS.=0A= =0A= 6.11.1 Best practice for dealing with paths=0A= =0A= The client SHOULD treat the results of SSH_FXP_REALPATH as a=0A= canonical absolute path, even if the path does not appear to be=0A= absolute. A client that use REALPATH(".") and treats the result as=0A= absolute, even if there is no leading slash, will continue to=0A= function correctly, even when talking to a Windows NT or VMS style=0A= system, where absolute paths may not begin with a slash.=0A= =0A= For example, if the client wishes to change directory up, and the=0A= server has returned "c:/x/y/z" from REALPATH, the client SHOULD use=0A= "c:/x/y/z/..".=0A= =0A= As a second example, if the client wishes to open the file "x.txt" in=0A= the current directory, and server has returned "dka100:/x/y/z" as the=0A= canonical path of the directory, the client SHOULD open "dka100:/x/y/=0A= z/x.txt"=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 23]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 7. Responses from the Server to the Client=0A= =0A= The server responds to the client using one of a few response=0A= packets. All requests can return a SSH_FXP_STATUS response upon=0A= failure. When the operation is successful, any of the responses may=0A= be returned (depending on the operation). If no data needs to be=0A= returned to the client, the SSH_FXP_STATUS response with SSH_FX_OK=0A= status is appropriate. Otherwise, the SSH_FXP_HANDLE message is used=0A= to return a file handle (for SSH_FXP_OPEN and SSH_FXP_OPENDIR=0A= requests), SSH_FXP_DATA is used to return data from SSH_FXP_READ,=0A= SSH_FXP_NAME is used to return one or more file names from a=0A= SSH_FXP_READDIR or SSH_FXP_REALPATH request, and SSH_FXP_ATTRS is=0A= used to return file attributes from SSH_FXP_STAT, SSH_FXP_LSTAT, and=0A= SSH_FXP_FSTAT requests.=0A= =0A= Exactly one response will be returned for each request. Each=0A= response packet contains a request identifier which can be used to=0A= match each response with the corresponding request. Note that it is=0A= legal to have several requests outstanding simultaneously, and the=0A= server is allowed to send responses to them in a different order from=0A= the order in which the requests were sent (the result of their=0A= execution, however, is guaranteed to be as if they had been processed=0A= one at a time in the order in which the requests were sent).=0A= =0A= Response packets are of the same general format as request packets.=0A= Each response packet begins with the request identifier.=0A= =0A= The format of the data portion of the SSH_FXP_STATUS response is as=0A= follows:=0A= =0A= uint32 id=0A= uint32 error/status code=0A= string error message (ISO-10646 UTF-8 [RFC-2279])=0A= string language tag (as defined in [RFC-1766])=0A= =0A= where `id' is the request identifier, and `error/status code'=0A= indicates the result of the requested operation. The value SSH_FX_OK=0A= indicates success, and all other values indicate failure.=0A= =0A= Currently, the following values are defined (other values may be=0A= defined by future versions of this protocol):=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 24]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= #define SSH_FX_OK 0=0A= #define SSH_FX_EOF 1=0A= #define SSH_FX_NO_SUCH_FILE 2=0A= #define SSH_FX_PERMISSION_DENIED 3=0A= #define SSH_FX_FAILURE 4=0A= #define SSH_FX_BAD_MESSAGE 5=0A= #define SSH_FX_NO_CONNECTION 6=0A= #define SSH_FX_CONNECTION_LOST 7=0A= #define SSH_FX_OP_UNSUPPORTED 8=0A= #define SSH_FX_INVALID_HANDLE 9=0A= #define SSH_FX_NO_SUCH_PATH 10=0A= #define SSH_FX_FILE_ALREADY_EXISTS 11=0A= #define SSH_FX_WRITE_PROTECT 12=0A= =0A= SSH_FX_OK=0A= Indicates successful completion of the operation.=0A= =0A= SSH_FX_EOF=0A= indicates end-of-file condition; for SSH_FX_READ it means that no=0A= more data is available in the file, and for SSH_FX_READDIR it=0A= indicates that no more files are contained in the directory.=0A= =0A= SSH_FX_NO_SUCH_FILE=0A= is returned when a reference is made to a file which does not=0A= exist.=0A= =0A= SSH_FX_PERMISSION_DENIED=0A= is returned when the authenticated user does not have sufficient=0A= permissions to perform the operation.=0A= =0A= SSH_FX_FAILURE=0A= is a generic catch-all error message; it should be returned if an=0A= error occurs for which there is no more specific error code=0A= defined.=0A= =0A= SSH_FX_BAD_MESSAGE=0A= may be returned if a badly formatted packet or protocol=0A= incompatibility is detected.=0A= =0A= SSH_FX_NO_CONNECTION=0A= is a pseudo-error which indicates that the client has no=0A= connection to the server (it can only be generated locally by the=0A= client, and MUST NOT be returned by servers).=0A= =0A= SSH_FX_CONNECTION_LOST=0A= is a pseudo-error which indicates that the connection to the=0A= server has been lost (it can only be generated locally by the=0A= client, and MUST NOT be returned by servers).=0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 25]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= SSH_FX_OP_UNSUPPORTED=0A= indicates that an attempt was made to perform an operation which=0A= is not supported for the server (it may be generated locally by=0A= the client if e.g. the version number exchange indicates that a=0A= required feature is not supported by the server, or it may be=0A= returned by the server if the server does not implement an=0A= operation).=0A= =0A= SSH_FX_INVALID_HANDLE=0A= The handle value was invalid.=0A= =0A= SSH_FX_NO_SUCH_PATH=0A= The file path does not exist or is invalid.=0A= =0A= SSH_FX_FILE_ALREADY_EXISTS=0A= The file already exists.=0A= =0A= SSH_FX_WRITE_PROTECT=0A= The file is on read only media, or the media is write protected.=0A= =0A= The SSH_FXP_HANDLE response has the following format:=0A= =0A= uint32 id=0A= string handle=0A= =0A= where `id' is the request identifier, and `handle' is an arbitrary=0A= string that identifies an open file or directory on the server. The=0A= handle is opaque to the client; the client MUST NOT attempt to=0A= interpret or modify it in any way. The length of the handle string=0A= MUST NOT exceed 256 data bytes.=0A= =0A= The SSH_FXP_DATA response has the following format:=0A= =0A= uint32 id=0A= string data=0A= =0A= where `id' is the request identifier, and `data' is an arbitrary byte=0A= string containing the requested data. The data string may be at most=0A= the number of bytes requested in a SSH_FXP_READ request, but may also=0A= be shorter if end of file is reached or if the read is from something=0A= other than a regular file.=0A= =0A= The SSH_FXP_NAME response has the following format:=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 26]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= uint32 id=0A= uint32 count=0A= repeats count times:=0A= string filename [UTF-8]=0A= ATTRS attrs=0A= =0A= where `id' is the request identifier, `count' is the number of names=0A= returned in this response, and the remaining fields repeat `count'=0A= times (so that all three fields are first included for the first=0A= file, then for the second file, etc). In the repeated part,=0A= `filename' is a file name being returned (for SSH_FXP_READDIR, it=0A= will be a relative name within the directory, without any path=0A= components; for SSH_FXP_REALPATH it will be an absolute path name),=0A= and `attrs' is the attributes of the file as described in Section=0A= ``File Attributes''.=0A= =0A= The SSH_FXP_ATTRS response has the following format:=0A= =0A= uint32 id=0A= ATTRS attrs=0A= =0A= where `id' is the request identifier, and `attrs' is the returned=0A= file attributes as described in Section ``File Attributes''.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 27]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 8. Vendor-Specific Extensions=0A= =0A= The SSH_FXP_EXTENDED request provides a generic extension mechanism=0A= for adding vendor-specific commands. The request has the following=0A= format:=0A= =0A= uint32 id=0A= string extended-request=0A= ... any request-specific data ...=0A= =0A= where `id' is the request identifier, and `extended-request' is a=0A= string of the format "name@domain", where domain is an internet=0A= domain name of the vendor defining the request. The rest of the=0A= request is completely vendor-specific, and servers should only=0A= attempt to interpret it if they recognize the `extended-request'=0A= name.=0A= =0A= The server may respond to such requests using any of the response=0A= packets defined in Section ``Responses from the Server to the=0A= Client''. Additionally, the server may also respond with a=0A= SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does=0A= not recognize the `extended-request' name, then the server MUST=0A= respond with SSH_FXP_STATUS with error/status set to=0A= SSH_FX_OP_UNSUPPORTED.=0A= =0A= The SSH_FXP_EXTENDED_REPLY packet can be used to carry arbitrary=0A= extension-specific data from the server to the client. It is of the=0A= following format:=0A= =0A= uint32 id=0A= ... any request-specific data ...=0A= =0A= There is a range of packet types reserved for use by extensions. In=0A= order to avoid collision, extensions that turn on the use of=0A= additional packet types should determine those numbers dynamically.=0A= =0A= The suggested way of doing this is have an extension request from the=0A= client to the server that enables the extension; the extension=0A= response from the server to the client would specify the actual type=0A= values to use, in additional to any other data.=0A= =0A= Extension authors should be mindful of the limited range of packet=0A= types available (there are only 45 values available) and avoid=0A= requiring a new packet type where possible.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 28]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 9. Security Considerations=0A= =0A= This protocol assumes that it is run over a secure channel and that=0A= the endpoints of the channel have been authenticated. Thus, this=0A= protocol assumes that it is externally protected from network-level=0A= attacks.=0A= =0A= This protocol provides file system access to arbitrary files on the=0A= server (only constrained by the server implementation). It is the=0A= responsibility of the server implementation to enforce any access=0A= controls that may be required to limit the access allowed for any=0A= particular user (the user being authenticated externally to this=0A= protocol, typically using the SSH User Authentication Protocol [8].=0A= =0A= Care must be taken in the server implementation to check the validity=0A= of received file handle strings. The server should not rely on them=0A= directly; it MUST check the validity of each handle before relying on=0A= it.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 29]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 10. Changes from previous protocol versions=0A= =0A= The SSH File Transfer Protocol has changed over time, before it's=0A= standardization. The following is a description of the incompatible=0A= changes between different versions.=0A= =0A= 10.1 Changes between versions 4 and 3=0A= =0A= Many of the changes between version 4 and version 3 are to the=0A= attribute structure to make it more flexible for non-unix platforms.=0A= =0A= o Make all filenames UTF-8.=0A= =0A= o Added 'newline' extension.=0A= =0A= o Made file attribute owner and group strings so they can actually=0A= be used on disparate systems.=0A= =0A= o Added createtime field, and added separate flags for atime,=0A= createtime, and mtime so they can be set separately.=0A= =0A= o Split the file type out of the permissions field and into it's own=0A= field (which is always present.)=0A= =0A= o Added acl attribute.=0A= =0A= o Added SSH_FXF_TEXT file open flag.=0A= =0A= o Added flags field to the get stat commands so that the client can=0A= specifically request information the server might not normally=0A= included for performance reasons.=0A= =0A= o Removed the long filename from the names structure-- it can now be=0A= built from information available in the attrs structure.=0A= =0A= o Added reserved range of packet numbers for extensions.=0A= =0A= o Added several additional error codes.=0A= =0A= o Change the way version negotiate works slightly. Previously, if=0A= the client version were higher than the server version, the server=0A= was supposed to 'echo back' the clients version. The server now=0A= sends it's own version and the lower of the two is considered to=0A= be the one in use.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 30]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 10.2 Changes between versions 3 and 2=0A= =0A= o The SSH_FXP_READLINK and SSH_FXP_SYMLINK messages were added.=0A= =0A= o The SSH_FXP_EXTENDED and SSH_FXP_EXTENDED_REPLY messages were=0A= added.=0A= =0A= o The SSH_FXP_STATUS message was changed to include fields `error=0A= message' and `language tag'.=0A= =0A= =0A= 10.3 Changes between versions 2 and 1=0A= =0A= o The SSH_FXP_RENAME message was added.=0A= =0A= =0A= 10.4 Changes between versions 1 and 0=0A= =0A= o Implementation changes, no actual protocol changes.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 31]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= 11. Trademark Issues=0A= =0A= "ssh" is a registered trademark of SSH Communications Security Corp=0A= in the United States and/or other countries.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 32]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= References=0A= =0A= [1] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and=0A= P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January=0A= 1999.=0A= =0A= [2] Alvestrand, H., "IETF Policy on Character Sets and Languages",=0A= BCP 18, RFC 2277, January 1998.=0A= =0A= [3] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame,=0A= C., Eisler, M. and D. Noveck, "NFS version 4 Protocol", RFC=0A= 3010, December 2000.=0A= =0A= [4] Institute of Electrical and Electronics Engineers, "Information=0A= Technology - Portable Operating System Interface (POSIX) - Part=0A= 1: System Application Program Interface (API) [C Language]",=0A= IEEE Standard 1003.2, 1996.=0A= =0A= [5] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.=0A= Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-=0A= architecture-09 (work in progress), July 2001.=0A= =0A= [6] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.=0A= Lehtinen, "SSH Protocol Transport Protocol", draft-ietf-secsh-=0A= architecture-09 (work in progress), July 2001.=0A= =0A= [7] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.=0A= Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-11=0A= (work in progress), July 2001.=0A= =0A= [8] Rinne, T., Ylonen, T., Kivinen, T., Saarinen, M. and S.=0A= Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh-=0A= userauth-11 (work in progress), July 2001.=0A= =0A= =0A= Authors' Addresses=0A= =0A= Joseph Galbraith=0A= VanDyke Software=0A= 4848 Tramway Ridge Blvd=0A= Suite 101=0A= Albuquerque, NM 87111=0A= US=0A= =0A= Phone: +1 505 332 5700=0A= EMail: galb-list@vandyke.com=0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 33]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= Tatu Ylonen=0A= SSH Communications Security Corp=0A= Fredrikinkatu 42=0A= HELSINKI FIN-00100=0A= Finland=0A= =0A= EMail: ylo@ssh.com=0A= =0A= =0A= Sami Lehtinen=0A= SSH Communications Security Corp=0A= Fredrikinkatu 42=0A= HELSINKI FIN-00100=0A= Finland=0A= =0A= EMail: sjl@ssh.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 34]=0A= =0C=0A= Internet-Draft SSH File Transfer Protocol October 2002=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The Internet Society (2002). All Rights Reserved.=0A= =0A= This document and translations of it may be copied and furnished to=0A= others, and derivative works that comment on or otherwise explain it=0A= or assist in its implementation may be prepared, copied, published=0A= and distributed, in whole or in part, without restriction of any=0A= kind, provided that the above copyright notice and this paragraph are=0A= included on all such copies and derivative works. However, this=0A= document itself may not be modified in any way, such as by removing=0A= the copyright notice or references to the Internet Society or other=0A= Internet organizations, except as needed for the purpose of=0A= developing Internet standards in which case the procedures for=0A= copyrights defined in the Internet Standards process must be=0A= followed, or as required to translate it into languages other than=0A= English.=0A= =0A= The limited permissions granted above are perpetual and will not be=0A= revoked by the Internet Society or its successors or assigns.=0A= =0A= This document and the information contained herein is provided on an=0A= "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING=0A= TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING=0A= BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=0A= HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF=0A= MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= Acknowledgement=0A= =0A= Funding for the RFC Editor function is currently provided by the=0A= Internet Society.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Galbraith, et al. Expires April 7, 2003 [Page 35]=0A= =0C=0A= =0A= ------=_NextPart_000_0091_01C26DDB.4200F6A0-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 10:28:13 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20569 for ; Mon, 7 Oct 2002 10:28:11 -0400 (EDT) Received: (qmail 27670 invoked by uid 605); 7 Oct 2002 14:30:09 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 27663 invoked from network); 7 Oct 2002 14:30:08 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 7 Oct 2002 14:30:08 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 17yYtM-00021Q-00; Mon, 07 Oct 2002 15:29:52 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham To: ietf-ssh@netbsd.org In-Reply-To: <005c01c26e08$6f709c80$4d00a8c0@galb.vandyke.com> Subject: Re: sftp changes... Message-Id: Date: Mon, 07 Oct 2002 15:29:52 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list Joseph Galbraith wrote: > Is this going to cause problems for implmentators? Do > currently shipping clients check the server response > to make sure it isn't higher than what they sent? PuTTY does, at the moment. Cheers, Simon -- Simon Tatham "That all men should be brothers is a dream of people who have no brothers." From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 10:33:51 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21002 for ; Mon, 7 Oct 2002 10:33:49 -0400 (EDT) Received: (qmail 653 invoked by uid 605); 7 Oct 2002 14:35:07 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 631 invoked from network); 7 Oct 2002 14:35:06 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 14:35:06 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959347; Mon, 07 Oct 2002 08:35:05 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 08:35:05 -0600 (Mountain Daylight Time) Message-ID: <00a201c26e0e$8ea60e40$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Simon Tatham" , References: Subject: Re: sftp changes... Date: Mon, 7 Oct 2002 08:33:51 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Well, perhaps we should back out this change then. If I understand you correctly, an old putty would disconnect or otherwise misbehave with a server implementing the new draft, because the server would send '4' instead of putty's version? If this is the case (which is perfectly reasonable, since the old draft specified that the server should return putty's version in this case), I think we should not make this change. I mostly wanted to make it because it seemed more useful to me for the client to know the version the server implements (for debugging, or, for example to issue a warning to the user.) Thanks, - Joseph ----- Original Message ----- From: "Simon Tatham" To: Sent: Monday, October 07, 2002 08:29 Subject: Re: sftp changes... > Joseph Galbraith wrote: > > Is this going to cause problems for implmentators? Do > > currently shipping clients check the server response > > to make sure it isn't higher than what they sent? > > PuTTY does, at the moment. > > Cheers, > Simon > -- > Simon Tatham "That all men should be brothers is a > dream of people who have no brothers." > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 10:40:07 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21394 for ; Mon, 7 Oct 2002 10:40:06 -0400 (EDT) Received: (qmail 5748 invoked by uid 605); 7 Oct 2002 14:42:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 5739 invoked from network); 7 Oct 2002 14:42:06 -0000 Received: from ixion.tartarus.org (195.149.39.210) by mail.netbsd.org with SMTP; 7 Oct 2002 14:42:06 -0000 Received: from simon by ixion.tartarus.org with local (Exim 3.35 #1 (Debian)) id 17yZ50-00028L-00; Mon, 07 Oct 2002 15:41:54 +0100 X-Mailer: Jed/Timber v0.2 From: Simon Tatham In-Reply-To: <00a201c26e0e$8ea60e40$4d00a8c0@galb.vandyke.com> To: "Joseph Galbraith" Cc: Subject: Re: sftp changes... Message-Id: Date: Mon, 07 Oct 2002 15:41:54 +0100 Sender: ietf-ssh-owner@netbsd.org Precedence: list "Joseph Galbraith" wrote: > If I understand you correctly, an old putty would disconnect or > otherwise misbehave with a server implementing the new draft, > because the server would send '4' instead of putty's version? Yes. It should disconnect cleanly, giving the user an error message `remote protocol is more advanced than we support'. Cheers, Simon -- Simon Tatham What do we want? ROT13! When do we want it? ABJ! From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 10:44:53 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21700 for ; Mon, 7 Oct 2002 10:44:52 -0400 (EDT) Received: (qmail 8864 invoked by uid 605); 7 Oct 2002 14:46:52 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8857 invoked from network); 7 Oct 2002 14:46:51 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 14:46:51 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959391; Mon, 07 Oct 2002 08:46:50 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 08:46:01 -0600 (Mountain Daylight Time) Message-ID: <00ac01c26e10$15e2ea80$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Simon Tatham" Cc: References: Subject: Re: sftp changes... Date: Mon, 7 Oct 2002 08:44:48 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit All right, I will revert this change. Thanks, Joseph ----- Original Message ----- From: "Simon Tatham" To: "Joseph Galbraith" Cc: Sent: Monday, October 07, 2002 08:41 Subject: Re: sftp changes... > "Joseph Galbraith" wrote: > > > If I understand you correctly, an old putty would disconnect or > > otherwise misbehave with a server implementing the new draft, > > because the server would send '4' instead of putty's version? > > Yes. It should disconnect cleanly, giving the user an error message > `remote protocol is more advanced than we support'. > > Cheers, > Simon > -- > Simon Tatham What do we want? ROT13! > When do we want it? ABJ! > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 11:03:38 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22204 for ; Mon, 7 Oct 2002 11:03:38 -0400 (EDT) Received: (qmail 22325 invoked by uid 605); 7 Oct 2002 15:05:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22318 invoked from network); 7 Oct 2002 15:05:37 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 7 Oct 2002 15:05:37 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N4H3C>; Mon, 7 Oct 2002 11:05:37 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA717@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , ietf-ssh@netbsd.org Subject: RE: Latest sftp draft-draft... Date: Mon, 7 Oct 2002 11:05:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list I suspect that the name of the flag for the times in previous version was designed to convey that the ACcess and MODification times were present. Since there are now separate flags, plus an additional flag for create time, how about a renaming of them to make them more readable: #define SSH_FILEXFER_ATTR_ACCESSTIME 0x00000008 #define SSH_FILEXFER_ATTR_CREATETIME 0x00000010 #define SSH_FILEXFER_ATTR_MODIFYTIME 0x00000020 From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 11:24:03 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22824 for ; Mon, 7 Oct 2002 11:24:02 -0400 (EDT) Received: (qmail 4476 invoked by uid 605); 7 Oct 2002 15:26:02 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4469 invoked from network); 7 Oct 2002 15:26:01 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 7 Oct 2002 15:26:01 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N4HP5>; Mon, 7 Oct 2002 11:26:00 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA718@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , ietf-ssh@netbsd.org Subject: RE: Latest sftp draft-draft... Date: Mon, 7 Oct 2002 11:25:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list I like the new text names for OWNER and GROUP, but I don't think that we should reuse the old UIDGID flag value since the representation of the data present has changed significantly. I think a better choice would be to deprecate the UIDGID bit and use a previously unused on for OWNERGROUP. ---------------------- Richard Whalen Process Software From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 11:34:36 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23246 for ; Mon, 7 Oct 2002 11:34:35 -0400 (EDT) Received: (qmail 9784 invoked by uid 605); 7 Oct 2002 15:36:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 9774 invoked from network); 7 Oct 2002 15:36:34 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 15:36:34 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959533; Mon, 07 Oct 2002 09:36:33 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 09:36:33 -0600 (Mountain Daylight Time) Message-ID: <00ea01c26e17$2514d2a0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Richard Whalen" , References: <63D30D6E10CFD11190A90000F805FE86040AA718@lespaul.process.com> Subject: Re: Latest sftp draft-draft... Date: Mon, 7 Oct 2002 09:35:20 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I suppose it might make implemenation easier. It isn't really depreciated though, because using it undefined. (There is no specification of what the structure would look like if it was specified.) What I have done is move OWNERGROUP to the end and give it value 0x0000080, which leaves 0x00000002 undefined. I added the following paragraph: In previous versions of this protocol flags value 0x00000002 was SSH_FILEXFER_ATTR_UIDGID. This value is now unused, and OWNERGROUP was given a new value in order to ease implementation burden. 0x00000002 MUST NOT appear in the mask. Some future version of this protocol may reuse flag 0x00000002. Does this work for you? Thanks, - Joseph ----- Original Message ----- From: "Richard Whalen" To: "'Joseph Galbraith'" ; Sent: Monday, October 07, 2002 09:25 Subject: RE: Latest sftp draft-draft... > I like the new text names for OWNER and GROUP, but I don't think that we > should reuse the old UIDGID flag value since the representation of the data > present has changed significantly. I think a better choice would be to > deprecate the UIDGID bit and use a previously unused on for OWNERGROUP. > > ---------------------- > Richard Whalen > Process Software > > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 11:36:11 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23292 for ; Mon, 7 Oct 2002 11:36:09 -0400 (EDT) Received: (qmail 10548 invoked by uid 605); 7 Oct 2002 15:38:08 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 10541 invoked from network); 7 Oct 2002 15:38:07 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 7 Oct 2002 15:38:07 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N4HRZ>; Mon, 7 Oct 2002 11:38:06 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA719@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , ietf-ssh@netbsd.org Subject: RE: Latest sftp draft-draft... Date: Mon, 7 Oct 2002 11:38:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list I think that's good. > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Monday, October 07, 2002 11:35 AM > To: Richard Whalen; ietf-ssh@netbsd.org > Subject: Re: Latest sftp draft-draft... > > > I suppose it might make implemenation easier. It > isn't really depreciated though, because using it > undefined. (There is no specification of what the > structure would look like if it was specified.) > > What I have done is move OWNERGROUP to the > end and give it value 0x0000080, which leaves > 0x00000002 undefined. I added the following > paragraph: > > In previous versions of this protocol flags value > 0x00000002 was SSH_FILEXFER_ATTR_UIDGID. This value > is now unused, and OWNERGROUP was given a new value > in order to ease implementation burden. 0x00000002 > MUST NOT appear in the mask. Some future version of > this protocol may reuse flag 0x00000002. > > > Does this work for you? > > Thanks, > > - Joseph > > ----- Original Message ----- > From: "Richard Whalen" > To: "'Joseph Galbraith'" ; > > Sent: Monday, October 07, 2002 09:25 > Subject: RE: Latest sftp draft-draft... > > > > I like the new text names for OWNER and GROUP, but I don't > think that we > > should reuse the old UIDGID flag value since the > representation of the > data > > present has changed significantly. I think a better choice > would be to > > deprecate the UIDGID bit and use a previously unused on for > OWNERGROUP. > > > > ---------------------- > > Richard Whalen > > Process Software > > > > > > > > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 11:42:40 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23689 for ; Mon, 7 Oct 2002 11:42:39 -0400 (EDT) Received: (qmail 14347 invoked by uid 605); 7 Oct 2002 15:44:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14340 invoked from network); 7 Oct 2002 15:44:39 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 15:44:39 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959553 for ietf-ssh@netbsd.org; Mon, 07 Oct 2002 09:44:39 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 09:41:55 -0600 (Mountain Daylight Time) Message-ID: <00f301c26e17$e4bfe680$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Subject: terminal server draft Date: Mon, 7 Oct 2002 09:40:41 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I think I'm on tap for a terminal server draft (I think this is Console Server options in the last WG status message.) I wrote something, but the more I thought about it, the more I realized I didn't have a clue what I was supposed to be writing. This was naturally the cause for some consternation and dismay on my part and also the cause of a missing draft :-) So, here is my understanding of the way a terminal server works. You connect to it using telnet / SSH1 / SSH2. Then, using TS's command line interface, you configure a given port and then connect to it. If this is accurate, what draft do we need? Now, there might be another draft that could be written, that would allow the client and server to communicate about changes in the tty configuration after pty creation. For example: server->client: I just entered raw mode server->client: I just entered line mode server->client: Echo was turned off client->server: Change the tty type to vt220 client->server: Change the erase character to 'del' The client might use the raw mode / line mode / echo mode to decide to use a local line mode buffer that would perfrom better under high latency situations (satellite link) Or to enchance security by buffering characters in no-echo/line mode until a newline is sent. But, this is not the terminal server draft :-) So, the big question is, what is the terminal server draft suppose to do? Thanks, - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 12:00:35 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24506 for ; Mon, 7 Oct 2002 12:00:35 -0400 (EDT) Received: (qmail 26640 invoked by uid 605); 7 Oct 2002 16:02:35 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 26413 invoked from network); 7 Oct 2002 16:02:30 -0000 Received: from watsun.cc.columbia.edu (128.59.39.2) by mail.netbsd.org with SMTP; 7 Oct 2002 16:02:30 -0000 Received: (from jaltman@localhost) by watsun.cc.columbia.edu (8.8.5/8.8.5) id MAA18349; Mon, 7 Oct 2002 12:01:02 -0400 (EDT) Date: Mon, 7 Oct 2002 12:01:00 EDT From: Jeffrey Altman Reply-To: jaltman@columbia.edu To: "Joseph Galbraith" Cc: Subject: Re: terminal server draft In-Reply-To: Your message of Mon, 7 Oct 2002 09:40:41 -0600 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list Are you referring to reverse terminal servers? network client to serial port with mode if so, you need to provide support equivalent to RFC 2217 > I think I'm on tap for a terminal server draft > (I think this is Console Server options in the > last WG status message.) > > I wrote something, but the more I thought about it, > the more I realized I didn't have a clue what I was > supposed to be writing. This was naturally the cause > for some consternation and dismay on my part and also > the cause of a missing draft :-) > > So, here is my understanding of the way a terminal server > works. > > You connect to it using telnet / SSH1 / SSH2. Then, > using TS's command line interface, you configure a > given port and then connect to it. > > If this is accurate, what draft do we need? > > Now, there might be another draft that could be written, > that would allow the client and server to communicate > about changes in the tty configuration after pty > creation. > > For example: > > server->client: I just entered raw mode > server->client: I just entered line mode > server->client: Echo was turned off > client->server: Change the tty type to vt220 > client->server: Change the erase character to 'del' > > The client might use the raw mode / line mode / echo mode > to decide to use a local line mode buffer that would > perfrom better under high latency situations (satellite link) > Or to enchance security by buffering characters in > no-echo/line mode until a newline is sent. > > But, this is not the terminal server draft :-) > > So, the big question is, what is the terminal server draft > suppose to do? > > Thanks, > > - Joseph > Jeffrey Altman * Sr.Software Designer Kermit 95 2.0 GUI available now!!! The Kermit Project @ Columbia University SSH, Secure Telnet, Secure FTP, HTTP http://www.kermit-project.org/ Secured with MIT Kerberos, SRP, and kermit-support@columbia.edu OpenSSL. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 13:05:54 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27148 for ; Mon, 7 Oct 2002 13:05:54 -0400 (EDT) Received: (qmail 14957 invoked by uid 605); 7 Oct 2002 17:07:55 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 14950 invoked from network); 7 Oct 2002 17:07:54 -0000 Received: from nwkea-mail-2.sun.com (192.18.42.14) by mail.netbsd.org with SMTP; 7 Oct 2002 17:07:54 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03649; Mon, 7 Oct 2002 10:07:36 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18949; Mon, 7 Oct 2002 13:07:35 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g97H7Zgu024079; Mon, 7 Oct 2002 13:07:35 -0400 (EDT) Message-Id: <200210071707.g97H7Zgu024079@thunk.east.sun.com> From: Bill Sommerfeld To: jaltman@columbia.edu cc: "Joseph Galbraith" , ietf-ssh@netbsd.org Subject: Re: terminal server draft In-Reply-To: Your message of "Mon, 07 Oct 2002 12:01:00 EDT." Reply-to: sommerfeld@east.sun.com Date: Mon, 07 Oct 2002 13:07:35 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list > if so, you need to provide support equivalent to RFC 2217 yes, this looks like the right base feature set. Besides outbound modem connection, the other important application is remote access to serial consoles, where receipt of a BREAK is often interpreted as an out-of-band interrupt signal. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 13:14:14 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27406 for ; Mon, 7 Oct 2002 13:14:14 -0400 (EDT) Received: (qmail 20700 invoked by uid 605); 7 Oct 2002 17:16:16 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 20690 invoked from network); 7 Oct 2002 17:16:16 -0000 Received: from nwkea-mail-1.sun.com (192.18.42.13) by mail.netbsd.org with SMTP; 7 Oct 2002 17:16:16 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15277; Mon, 7 Oct 2002 10:15:59 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20869; Mon, 7 Oct 2002 13:15:59 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g97HFxgu024161; Mon, 7 Oct 2002 13:15:59 -0400 (EDT) Message-Id: <200210071715.g97HFxgu024161@thunk.east.sun.com> From: Bill Sommerfeld To: "Joseph Galbraith" cc: ietf-ssh@netbsd.org Subject: Re: ctime vs. Create Time In-Reply-To: Your message of "Mon, 07 Oct 2002 07:31:30 MDT." <004001c26e05$d8bb2370$4d00a8c0@galb.vandyke.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 07 Oct 2002 13:15:58 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list unix doesn't have a concept of "creation time". within the posix "stat" API, "ctime" is the "last metadata change" time whereas "mtime" is "last contents change"; "atime" is "last access time". Note that update of atimes is commonly disabled for performance reasons. If you are aiming for "least common denominator", the best you can do is a single timestamp for the mtime value. If you are aiming for "model every known filesystem feature relating to dates", then we'll be here for a while... - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 13:29:26 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27914 for ; Mon, 7 Oct 2002 13:29:26 -0400 (EDT) Received: (qmail 3780 invoked by uid 605); 7 Oct 2002 17:31:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 3773 invoked from network); 7 Oct 2002 17:31:26 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 7 Oct 2002 17:31:26 -0000 Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 19F0267103 for ; Mon, 7 Oct 2002 09:46:24 -0400 (EDT) Date: Mon, 7 Oct 2002 13:31:00 -0400 Subject: Re: ctime vs. Create Time Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: RJ Atkinson To: ietf-ssh@netbsd.org Content-Transfer-Encoding: 7bit In-Reply-To: <200210071715.g97HFxgu024161@thunk.east.sun.com> Message-Id: <8BE1CC92-DA1A-11D6-A91E-00039357A82A@extremenetworks.com> X-Mailer: Apple Mail (2.546) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit IMHO, we ought to be designing any file times with specific reference to the IEEE POSIX.1 standard && we should avoid creating a new file timestamp definition having semantics different from each of the POSIX timestamp definitions. On Monday, Oct 7, 2002, at 13:15 America/Montreal, Bill Sommerfeld wrote: > unix doesn't have a concept of "creation time". within the posix > "stat" API, "ctime" is the "last metadata change" time whereas "mtime" > is "last contents change"; "atime" is "last access time". > > Note that update of atimes is commonly disabled for performance > reasons. > > If you are aiming for "least common denominator", the best you can do > is a single timestamp for the mtime value. > > If you are aiming for "model every known filesystem feature relating > to dates", then we'll be here for a while... > > - Bill > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 14:04:58 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28876 for ; Mon, 7 Oct 2002 14:04:57 -0400 (EDT) Received: (qmail 214 invoked by uid 605); 7 Oct 2002 18:06:59 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 207 invoked from network); 7 Oct 2002 18:06:58 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 18:06:58 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 959862; Mon, 07 Oct 2002 12:06:57 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 12:06:57 -0600 (Mountain Daylight Time) Message-ID: <011801c26e2c$27b0cdb0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Cc: References: <200210071715.g97HFxgu024161@thunk.east.sun.com> Subject: Re: ctime vs. Create Time Date: Mon, 7 Oct 2002 12:05:43 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > unix doesn't have a concept of "creation time". within the posix > "stat" API, "ctime" is the "last metadata change" time whereas "mtime" > is "last contents change"; "atime" is "last access time". > > Note that update of atimes is commonly disabled for performance > reasons. > > If you are aiming for "least common denominator", the best you can do > is a single timestamp for the mtime value. > > If you are aiming for "model every known filesystem feature relating > to dates", then we'll be here for a while... What I'm really aiming for is "model the most commonly available and used filesystem features relating to dates." Both Windows and VMS store creation dates. Windows and unix optionally store acces time, but it is commonly disabled for performance. (I think VMS also can record access time, but usually does not.) So I would argue that Creation time is part of the "medium common denominator" What I wasn't sure of is if "metadata change" as seperate from "content change" is interesting. Windows does not track that data. I don't know if VMS does. I don't know if people use that data when operating on files. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 14:42:28 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00285 for ; Mon, 7 Oct 2002 14:42:28 -0400 (EDT) Received: (qmail 22192 invoked by uid 605); 7 Oct 2002 18:44:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 22185 invoked from network); 7 Oct 2002 18:44:27 -0000 Received: from firebird.cisco.com (HELO fire.cisco.com) (171.68.227.73) by mail.netbsd.org with SMTP; 7 Oct 2002 18:44:27 -0000 Received: from REMAKERW2K (remaker-w2k.cisco.com [171.69.103.93]) by fire.cisco.com (8.11.6+Sun/8.8.8) with SMTP id g97Iak011843; Mon, 7 Oct 2002 11:36:46 -0700 (PDT) Message-ID: <014e01c26e30$7de65d90$5d6745ab@amer.cisco.com> From: "Phillip Remaker" To: "Joseph Galbraith" , References: <00f301c26e17$e4bfe680$4d00a8c0@galb.vandyke.com> Subject: Re: terminal server draft Date: Mon, 7 Oct 2002 11:36:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > I think I'm on tap for a terminal server draft > (I think this is Console Server options in the > last WG status message.) I'm extremely interested in helping 8-) You may want to look at www.conserver.com/consoles for ideas. > You connect to it using telnet / SSH1 / SSH2. Then, > using TS's command line interface, you configure a > given port and then connect to it. > > If this is accurate, what draft do we need? - Control of the attributes of the serial port a-la RFC 2217 - Ability to pass a BREAK signal (similar to telnet IAC break) - EOL/Duplex/Echo handling (How is that handled today?) > Now, there might be another draft that could be written, > that would allow the client and server to communicate > about changes in the tty configuration after pty > creation. > > For example: > > server->client: I just entered raw mode > server->client: I just entered line mode > server->client: Echo was turned off > client->server: Change the tty type to vt220 > client->server: Change the erase character to 'del' > > The client might use the raw mode / line mode / echo mode > to decide to use a local line mode buffer that would > perfrom better under high latency situations (satellite link) > Or to enchance security by buffering characters in > no-echo/line mode until a newline is sent. > > But, this is not the terminal server draft :-) > > So, the big question is, what is the terminal server draft > suppose to do? Minimally break handling and RFC2217. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 15:10:41 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01542 for ; Mon, 7 Oct 2002 15:10:40 -0400 (EDT) Received: (qmail 8101 invoked by uid 605); 7 Oct 2002 19:12:40 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 8046 invoked from network); 7 Oct 2002 19:12:39 -0000 Received: from gnat.inet.org (63.108.254.91) by mail.netbsd.org with SMTP; 7 Oct 2002 19:12:39 -0000 Received: from extremenetworks.com (unknown [10.18.3.103]) by gnat.inet.org (Postfix) with ESMTP id 9CF1E67103; Mon, 7 Oct 2002 11:28:02 -0400 (EDT) Date: Mon, 7 Oct 2002 15:12:38 -0400 Subject: Re: ctime vs. Create Time Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: , To: "Joseph Galbraith" From: RJ Atkinson In-Reply-To: <011801c26e2c$27b0cdb0$4d00a8c0@galb.vandyke.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit On Monday, Oct 7, 2002, at 14:05 America/Montreal, Joseph Galbraith wrote: > What I'm really aiming for is "model the most commonly available > and used filesystem features relating to dates." The right target is to be consistent with other IETF standards (e.g. NFS). Those standards are based upon POSIX.1 timestamps, not proprietary (e.g. Microsoft, VMS) timestamps. > Both Windows and VMS store creation dates. Windows and unix > optionally store acces time, but it is commonly disabled for > performance. (I think VMS also can record access time, > but usually does not.) UNIX does not commonly disable access time. Windows varies with which flavour of which version of which kind of Windows one has. As noted above, in an IETF standards context the right target is to be compliant with (one of the) POSIX.1 timestamps. Ran From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 15:59:22 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03354 for ; Mon, 7 Oct 2002 15:59:21 -0400 (EDT) Received: (qmail 7094 invoked by uid 605); 7 Oct 2002 20:01:20 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6996 invoked from network); 7 Oct 2002 20:01:14 -0000 Received: from pheriche.sun.com (192.18.98.34) by mail.netbsd.org with SMTP; 7 Oct 2002 20:01:14 -0000 Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09543 for ; Mon, 7 Oct 2002 14:01:13 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA02395 for ; Mon, 7 Oct 2002 16:01:12 -0400 (EDT) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g97K1Cgu026427 for ; Mon, 7 Oct 2002 16:01:12 -0400 (EDT) Message-Id: <200210072001.g97K1Cgu026427@thunk.east.sun.com> From: Bill Sommerfeld To: ietf-ssh@netbsd.org Subject: new text in drafts regarding IPR claims. Reply-to: sommerfeld@east.sun.com Date: Mon, 07 Oct 2002 16:01:12 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list I've gotten a couple queries regarding the new text in the drafts: The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. This is the new stock boilerplate and was inserted by request of the IESG, and is specifically intended to refer to the trademark dispute. In the interest of getting things moving again, we were specifically told to not wait for anything to appear on the IPR page before submitting the documents. Sorry for the confusion. - Bill From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 16:17:26 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04042 for ; Mon, 7 Oct 2002 16:17:25 -0400 (EDT) Received: (qmail 21298 invoked by uid 605); 7 Oct 2002 20:19:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 21291 invoked from network); 7 Oct 2002 20:19:25 -0000 Received: from cypher.cisco.com (HELO cisco.com) (171.69.11.143) by mail.netbsd.org with SMTP; 7 Oct 2002 20:19:25 -0000 Received: (from billw@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA26408; Mon, 7 Oct 2002 13:15:30 -0700 (PDT) Date: Mon, 7 Oct 2002 13:15:29 PDT From: William "Chops" Westfield Reply-To: Bill Westfield To: "Phillip Remaker" Cc: "Joseph Galbraith" , Subject: Re: terminal server draft In-Reply-To: Your message of Mon, 7 Oct 2002 11:36:46 -0700 Message-ID: Sender: ietf-ssh-owner@netbsd.org Precedence: list While I'm not a huge fan of telnet as a protocol, perhaps it would be easiest to figure out a way to send any telnet command (including special characters and negotiations) on an SSH connection... BillW From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 16:20:24 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04113 for ; Mon, 7 Oct 2002 16:20:24 -0400 (EDT) Received: (qmail 23009 invoked by uid 605); 7 Oct 2002 20:22:25 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23002 invoked from network); 7 Oct 2002 20:22:24 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 20:22:24 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 960081; Mon, 07 Oct 2002 14:22:23 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 14:22:23 -0600 (Mountain Daylight Time) Message-ID: <013e01c26e3f$12db6b80$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "RJ Atkinson" Cc: , References: Subject: Re: ctime vs. Create Time Date: Mon, 7 Oct 2002 14:21:09 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit > On Monday, Oct 7, 2002, at 14:05 America/Montreal, Joseph Galbraith > wrote: > > What I'm really aiming for is "model the most commonly available > > and used filesystem features relating to dates." > > The right target is to be consistent with other IETF standards > (e.g. NFS). Those standards are based upon POSIX.1 timestamps, > not proprietary (e.g. Microsoft, VMS) timestamps. I agree that being consistent with other IETF standards is a good goal. I've actually looked at NFS several times and borrowed from it where appropriate. NFS defines the following time fields as recommended attributes (RFC 3010): time_access time_backup time_create time_metadata (unix ctime) time_modify In fact, reviewing NFS with regard to time values, I think we should change our time values to be uint64. I'd rather not go out the door with a 2038 (or whenever) bug. I'll be retired (maybe), but I know people who won't be :-) The create time is also defined by FTP MLST extensions. Access time is not; I'd be willing to remove access time before create time-- a Windows user can added the create time to their file listing view with two mouse clicks -- access time doesn't appear to be exposed in the UI. But I think we should keep all three. The people who are actually doing VMS (where there is a backup time) didn't seem to think it needed to be in the protocol. Though now that they know it is in NFS, maybe they are changing their minds :-) I think people doing unix implementations should say whether or not they want a time_metadata. To my mind, they are the ones that have to live with the consequences of such a decision, and they are the ones that have to deal with customers that may or may not be concerned over the preservation of that file attribute. The thing I think I've been hearing is that they don't need to preserve this time stamp. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 17:14:40 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06269 for ; Mon, 7 Oct 2002 17:14:39 -0400 (EDT) Received: (qmail 25319 invoked by uid 605); 7 Oct 2002 21:16:39 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 25259 invoked from network); 7 Oct 2002 21:16:38 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 7 Oct 2002 21:16:38 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N42JM>; Mon, 7 Oct 2002 17:16:37 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA71A@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , ietf-ssh@netbsd.org Subject: RE: Latest sftp draft-draft... Date: Mon, 7 Oct 2002 17:16:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list The response to the "newline" extension is not defined. Clearly, an implementation that doesn't include this will respond with SSH_FXP_STATUS of SSH_FX_OP_UNSUPPORTED, but should an implementation that supports it respond with SSH_FXP_STATUS of SSH_FX_OK, or SSH_FXP_EXTENDED_REPLY plus some undefined request-specific data. 4.3 Determining Server Newline Convention In order to correctly process text files in a cross platform compatible way, the newline convention must be converted from that of the server to that of the client, or, during an upload, from that of the client to that of the server. Versions 3 and prior of this protocol made no provisions for processing text files. Many clients implemented some sort of conversion algorithm, but without either a 'canonical' on the wire format or knowledge of the servers newline convention, correct conversion was not always possible. Starting with Version 4, the SSH_FXF_TEXT file open flag (Section 6.3) makes it possible to request that the server translate a file to a 'canonical' on the wire format. This format uses \r\n as the line separator. Servers for systems using multiple newline characters (for example, Mac OS X or VMS) or systems using counted records, MUST translate to the canonical form. However, to ease the burden of implementation on servers that use a single, simple separator sequence, the following extension allows the canonical format to be changed. string "newline" string new-canonical-separator (usually "\r" or "\n" or "\r\n") All clients MUST support this extension. When processing text files, clients SHOULD NOT translate any character or sequence that is not an exact match of the servers newline separator. In particular, if the newline sequence being used is the canonical "\r\n" sequence, a lone \r or a lone \n SHOULD be written through without change. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Mon Oct 7 17:34:04 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07041 for ; Mon, 7 Oct 2002 17:34:03 -0400 (EDT) Received: (qmail 7614 invoked by uid 605); 7 Oct 2002 21:36:04 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 7603 invoked from network); 7 Oct 2002 21:36:03 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 7 Oct 2002 21:36:03 -0000 Received: from [127.0.0.1] (HELO mail) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with ESMTP id 961426; Mon, 07 Oct 2002 15:35:26 -0600 Received: from dogfood.vandyke.com ([192.168.0.3]) by mail (MailMonitor for SMTP v1.1.0 ) ; Mon, 7 Oct 2002 15:35:26 -0600 (Mountain Daylight Time) Message-ID: <014301c26e49$477604e0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Richard Whalen" , References: <63D30D6E10CFD11190A90000F805FE86040AA71A@lespaul.process.com> Subject: Re: Latest sftp draft-draft... Date: Mon, 7 Oct 2002 15:34:12 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Since the "newline" extension is sent as part of the servers version packet to the client, there is not response. Since it is sent to the client, there is no request id to put in a status or SSH_FXP_EXTENDED_REPLY. So basically, extensions sent as part of the server version packet are always "informational". Any other extension must be initiated by the client. (Well, excpect ATTR extensions.) - Joseph ----- Original Message ----- From: "Richard Whalen" To: "'Joseph Galbraith'" ; Sent: Monday, October 07, 2002 15:16 Subject: RE: Latest sftp draft-draft... > The response to the "newline" extension is not defined. > > Clearly, an implementation that doesn't include this will respond with > SSH_FXP_STATUS of SSH_FX_OP_UNSUPPORTED, but should an implementation that > supports it respond with SSH_FXP_STATUS of SSH_FX_OK, or > SSH_FXP_EXTENDED_REPLY plus some undefined request-specific data. > > 4.3 Determining Server Newline Convention > > In order to correctly process text files in a cross platform > compatible way, the newline convention must be converted from that of > the server to that of the client, or, during an upload, from that of > the client to that of the server. > > Versions 3 and prior of this protocol made no provisions for > processing text files. Many clients implemented some sort of > conversion algorithm, but without either a 'canonical' on the wire > format or knowledge of the servers newline convention, correct > conversion was not always possible. > > Starting with Version 4, the SSH_FXF_TEXT file open flag (Section > 6.3) makes it possible to request that the server translate a file to > a 'canonical' on the wire format. This format uses \r\n as the line > separator. > > Servers for systems using multiple newline characters (for example, > Mac OS X or VMS) or systems using counted records, MUST translate to > the canonical form. > > However, to ease the burden of implementation on servers that use a > single, simple separator sequence, the following extension allows the > canonical format to be changed. > > string "newline" > string new-canonical-separator (usually "\r" or "\n" or "\r\n") > > All clients MUST support this extension. > > When processing text files, clients SHOULD NOT translate any > character or sequence that is not an exact match of the servers > newline separator. > > In particular, if the newline sequence being used is the canonical > "\r\n" sequence, a lone \r or a lone \n SHOULD be written through > without change. > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Oct 8 09:38:23 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11954 for ; Tue, 8 Oct 2002 09:38:23 -0400 (EDT) Received: (qmail 6111 invoked by uid 605); 8 Oct 2002 13:40:10 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 6083 invoked from network); 8 Oct 2002 13:40:09 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 8 Oct 2002 13:40:09 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N4JKJ>; Tue, 8 Oct 2002 09:40:08 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA71C@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , ietf-ssh@netbsd.org Subject: RE: Latest sftp draft-draft... Date: Tue, 8 Oct 2002 09:40:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list I had misinterpreted it as an extended command, rather than as information from server to client. > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Monday, October 07, 2002 5:34 PM > To: Richard Whalen; ietf-ssh@netbsd.org > Subject: Re: Latest sftp draft-draft... > > > Since the "newline" extension is sent as part of the > servers version packet to the client, there is not > response. > > Since it is sent to the client, there is no request > id to put in a status or SSH_FXP_EXTENDED_REPLY. > > So basically, extensions sent as part of the > server version packet are always "informational". > > Any other extension must be initiated by the client. > (Well, excpect ATTR extensions.) > > - Joseph > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Oct 11 11:52:35 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26082 for ; Fri, 11 Oct 2002 11:52:35 -0400 (EDT) Received: (qmail 28220 invoked by uid 605); 11 Oct 2002 15:54:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 28145 invoked from network); 11 Oct 2002 15:54:36 -0000 Received: from xanthine.gratuitous.org (199.232.39.35) by mail.netbsd.org with SMTP; 11 Oct 2002 15:54:36 -0000 Received: from nemo by xanthine.gratuitous.org with local; Fri, 11 Oct 2002 11:54:35 -0400 From: "Joel N. Weber II" To: ietf-ssh@netbsd.org Subject: semantics of pgp-sign-rsa and pgp-sign-dss with subkeys Message-Id: Date: Fri, 11 Oct 2002 11:54:35 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list When using the pgp-sign-rsa and pgp-sign-dss methods as specified in draft-ietf-secsh-transport-15, it seems pretty obvious whether to use pgp-sign-rsa or pgp-sign-dss if you're using the primary public key to make the signature that verifies that the host knows the private key. However, GPG also supports using subkeys to make signatures, and GPG doesn't require that the subkey be of the same type as the primary key. (Whether the commercial PGP also has this property, I'm not sure.) It seems that one possible interpretation of the current internet draft is that if you have a primary public key of one type, and a subkey of another type, that whether you use pgp-sign-rsa or pgp-sign-dss is determined entirely by the type of the subkey. The argument here would be that the primary public key is just a part of the certificate which certifies the signing key that ssh is using. But I think the crucial question is whether the key type exists to provide compatibility information, or to provide information about what exactly the signature actually is, or both. ssh-rsa and ssh-dss need to be distinct types, because an ssh-rsa or ssh-dss signature doesn't embed information about its key type. On the other hand, all OpenPGP format signatures do embed information about the key type, so an implementation which supported both RSA and DSS OpenPGP keys would be able to do the right thing even if the ssh standard had been defined as having only a pgp-sign type which was used for both key types. For the purpose of indicating compatibility, there are really three distinct possibilities: someone might in theory be using an early version of GPG, which would only support DSS (in pratice, I'm not sure this is likely, since to my knowlege, GPG supported RSA as well long before anyone wrote GPG support in any SSH implementation); there may be older versions of PGP which only support RSA which could be used with SSH; and there are modern implementations which support both. I do think I want to see ssh allow a subkey of a type which is different than the type of the primary signing key. The web of trust among people in the world I happen to live in is sufficiently mixed that I can't imagine an OpenPGP implementation actually being useful unless it supported both. On the other hand, I can imagine that some people might live in a world where only one key type needs to work, and letting them express that sort of compatibility in the ssh protoctol is reasonable. So I think I would like to see some new types added. A first attempt at defining them would be to keep: The "pgp-sign-rsa" method indicates the certificates, the public key, and the signature are in OpenPGP compatible binary format ([RFC2440]). This method indicates that the key is an RSA-key. The "pgp-sign-dss". As above, but indicates that the key is a DSS- key. and then add: The "pgp-sign-rsa-dss". As above, but indicates that the key is a DSS- subkey of an RSA key. The "pgp-sign-dss-rsa". As above, but indicates that the key is a RSA- subkey of an DSS-key. (It is also probably tangentially relevant to point out that I've written code to make openssh use GPG host keys; one version of the code, which certainly does not get subkeys right, and may well have other problems, is available at http://www.red-bean.com/~nemo/openssh-gpg/ I am continuing to work on improving the code.) From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Oct 15 13:47:55 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09323 for ; Tue, 15 Oct 2002 13:47:55 -0400 (EDT) Received: (qmail 1495 invoked by uid 605); 15 Oct 2002 17:49:58 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 1488 invoked from network); 15 Oct 2002 17:49:57 -0000 Received: from lespaul.process.com (192.42.95.27) by mail.netbsd.org with SMTP; 15 Oct 2002 17:49:57 -0000 Received: by lespaul.process.com with Internet Mail Service (5.5.2653.19) id <423N4V52>; Tue, 15 Oct 2002 13:49:55 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE86040AA73A@lespaul.process.com> From: Richard Whalen To: "'Joseph Galbraith'" , ietf-ssh@netbsd.org Subject: RE: Latest sftp draft-draft... Date: Tue, 15 Oct 2002 13:49:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: ietf-ssh-owner@netbsd.org Precedence: list The response message to a "text-seek" is not specified. A SSH_FXP_STATUS message with SSH_FX_OK or SSH_FX_OP_UNSUPPORTED seems like the appropriate response. -----Original Message----- From: Joseph Galbraith [mailto:galb-list@vandyke.com] Sent: Monday, October 07, 2002 10:27 AM To: ietf-ssh@netbsd.org Subject: Latest sftp draft-draft... I believe we are getting close to submitting. Changes since the previous draft-draft: o Change ctime to create-time. o Reorder permissions and time fields back to their original order in attribute packet. o Clarify that partial new-line sequences should be ignored. o Clarify that size field represents that size of the file on disk, and for text mode operations, it does not necessarily represent the size of the file on the wire. o Clarify that the offset parameter to write will be ignored when FXF_APPEND is specified. o Introduce 'text-seek' extension request, and specify that offset fields in read and write packets are to be ignored when FXF_TEXT is specified. o Add clarifying text indicating that 'parallel' read and write operations must be processed successfully on FXF_TEXT files. o Clean up formatting and break up description of parameters for MKDIR & RMDIR. Also, revise text describing when a RMDIR can fail. o Run through spell checker. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Oct 16 18:25:01 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13837 for ; Wed, 16 Oct 2002 18:25:00 -0400 (EDT) Received: (qmail 4483 invoked by uid 605); 16 Oct 2002 22:27:06 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 4471 invoked from network); 16 Oct 2002 22:27:05 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 16 Oct 2002 22:27:05 -0000 Received: from [127.0.0.1] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 976607; Wed, 16 Oct 2002 16:27:04 -0600 Message-ID: <026c01c27562$f5ca0ee0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: "Richard Whalen" , References: <63D30D6E10CFD11190A90000F805FE86040AA73A@lespaul.process.com> Subject: Re: Latest sftp draft-draft... Date: Wed, 16 Oct 2002 16:25:40 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I've included the following text: The response to a "text-seek" request is an SSH_FXP_STATUS message. An attempt to seek past the end-of-file should result in a SSH_FX_EOF status. - Joseph ----- Original Message ----- From: "Richard Whalen" To: "'Joseph Galbraith'" ; Sent: Tuesday, October 15, 2002 11:49 Subject: RE: Latest sftp draft-draft... > The response message to a "text-seek" is not specified. > A SSH_FXP_STATUS message with SSH_FX_OK or SSH_FX_OP_UNSUPPORTED seems like > the appropriate response. > > -----Original Message----- > From: Joseph Galbraith [mailto:galb-list@vandyke.com] > Sent: Monday, October 07, 2002 10:27 AM > To: ietf-ssh@netbsd.org > Subject: Latest sftp draft-draft... > > > I believe we are getting close to submitting. > > Changes since the previous draft-draft: > > o Change ctime to create-time. > o Reorder permissions and time fields back to their > original order in attribute packet. > o Clarify that partial new-line sequences should > be ignored. > o Clarify that size field represents that size > of the file on disk, and for text mode operations, > it does not necessarily represent the size of the > file on the wire. > o Clarify that the offset parameter to write > will be ignored when FXF_APPEND is specified. > o Introduce 'text-seek' extension request, and specify > that offset fields in read and write packets are to > be ignored when FXF_TEXT is specified. > o Add clarifying text indicating that 'parallel' read and > write operations must be processed successfully > on FXF_TEXT files. > o Clean up formatting and break up description of parameters > for MKDIR & RMDIR. Also, revise text describing when > a RMDIR can fail. > o Run through spell checker. > > - Joseph > > > From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Oct 16 18:38:25 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14118 for ; Wed, 16 Oct 2002 18:38:25 -0400 (EDT) Received: (qmail 12986 invoked by uid 605); 16 Oct 2002 22:40:32 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12979 invoked from network); 16 Oct 2002 22:40:31 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 16 Oct 2002 22:40:31 -0000 Received: from [127.0.0.1] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 976639 for ietf-ssh@netbsd.org; Wed, 16 Oct 2002 16:40:31 -0600 Message-ID: <027f01c27564$d6d703b0$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Subject: new drafts on their way... Date: Wed, 16 Oct 2002 16:39:07 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit I've submitted both the publickeyfile draft (with no material changes -- changed secsh to ssh as per Bill's request) and the sftp draft, as posted here + mods discussed. I don't know how long they'll take to clear but they should be showing up soon. - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Oct 18 07:30:29 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21459 for ; Fri, 18 Oct 2002 07:30:29 -0400 (EDT) Received: (qmail 12240 invoked by uid 605); 18 Oct 2002 11:32:38 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12233 invoked from network); 18 Oct 2002 11:32:37 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 18 Oct 2002 11:32:37 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21428; Fri, 18 Oct 2002 07:30:22 -0400 (EDT) Message-Id: <200210181130.HAA21428@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-publickeyfile-03.txt Date: Fri, 18 Oct 2002 07:30:22 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SECSH Public Key File Format Author(s) : J. Galbraith, R. Thayer Filename : draft-ietf-secsh-publickeyfile-03.txt Pages : 9 Date : 2002-10-17 This document formally documents the existing public key file format in use for exchanging public keys between different SECSH implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-publickeyfile-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-publickeyfile-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-publickeyfile-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-17150031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-publickeyfile-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-publickeyfile-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-17150031.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Fri Oct 18 07:30:43 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21516 for ; Fri, 18 Oct 2002 07:30:42 -0400 (EDT) Received: (qmail 12433 invoked by uid 605); 18 Oct 2002 11:32:43 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 12394 invoked from network); 18 Oct 2002 11:32:42 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by mail.netbsd.org with SMTP; 18 Oct 2002 11:32:42 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21446; Fri, 18 Oct 2002 07:30:27 -0400 (EDT) Message-Id: <200210181130.HAA21446@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ssh@netbsd.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-secsh-filexfer-03.txt Date: Fri, 18 Oct 2002 07:30:26 -0400 Sender: ietf-ssh-owner@netbsd.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Shell Working Group of the IETF. Title : SSH File Transfer Protocol Author(s) : J. Galbraith, T. Ylonen, S. Lehtinen Filename : draft-ietf-secsh-filexfer-03.txt Pages : 35 Date : 2002-10-17 The SSH File Transfer Protocol provides secure file transfer functionality over any reliable data stream. It is the standard file transfer protocol for use with the SSH2 protocol. This document describes the file transfer protocol and its interface to the SSH2 protocol suite. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-secsh-filexfer-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-secsh-filexfer-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-secsh-filexfer-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-10-17150040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-secsh-filexfer-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-secsh-filexfer-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-17150040.I-D@ietf.org> --OtherAccess-- --NextPart-- From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Tue Oct 22 10:47:16 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19880 for ; Tue, 22 Oct 2002 10:47:15 -0400 (EDT) Received: (qmail 23819 invoked by uid 605); 22 Oct 2002 14:49:27 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 23812 invoked from network); 22 Oct 2002 14:49:26 -0000 Received: from mail.vandyke.com (HELO vandyke.com) (204.134.9.1) by mail.netbsd.org with SMTP; 22 Oct 2002 14:49:26 -0000 Received: from [127.0.0.1] (HELO CHAOS) by vandyke.com (CommuniGate Pro SMTP 3.4.7) with SMTP id 983500 for ietf-ssh@netbsd.org; Tue, 22 Oct 2002 08:49:25 -0600 Message-ID: <009a01c279da$022a6740$4d00a8c0@galb.vandyke.com> From: "Joseph Galbraith" To: Subject: Meeting in Atlanta... Date: Tue, 22 Oct 2002 08:47:56 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit Are we planning on meeting in Atlanta? - Joseph From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Wed Oct 23 15:11:18 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00562 for ; Wed, 23 Oct 2002 15:11:17 -0400 (EDT) Received: (qmail 16103 invoked by uid 605); 23 Oct 2002 19:13:31 -0000 Delivered-To: ietf-ssh@netbsd.org Received: (qmail 16096 invoked from network); 23 Oct 2002 19:13:30 -0000 Received: from taka.swcp.com (198.59.115.12) by mail.netbsd.org with SMTP; 23 Oct 2002 19:13:30 -0000 Received: from BLUETAIL (inago.swcp.com [198.59.115.17]) by taka.swcp.com (8.12.3/8.12.3) with SMTP id g9NJDOZe027579 for ; Wed, 23 Oct 2002 13:13:25 -0600 (MDT) Message-ID: <000e01c27ac8$0c2c8f90$4900a8c0@BLUETAIL> From: "Brent McClure" To: Subject: Public-key subsystem draft submitted Date: Wed, 23 Oct 2002 13:11:52 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Status: No, hits=0.0 required=10.0 tests=none X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: ietf-ssh-owner@netbsd.org Precedence: list Content-Transfer-Encoding: 7bit We have submitted the following draft of the "Secure Shell Public-Key Subsystem" as an individual submission to the Secure Shell Working Group: http://www.ietf.org/internet-drafts/draft-galb-secsh-publickey-subsystem-00.txt The public-key subsystem allows clients to upload, list and manage public keys in an implementation-independent fashion. This draft is similar to a draft that we submitted in November 2000. At the time there was a fair amount of interest in the draft, but in general the consensus seemed to be that this public-key management should be defined as a subsystem instead of as a channel as it had been in that draft. We have implemented this subsystem in our products, and we've created a patch to the OpenSSH distribution that implements it in that server as well. We've seen a fair amount of interest in this. Is this something that the working group would be interested in taking up? I've included the abstract of the draft below. thanks, Brent McClure bdm@vandyke.com ---- Abstract SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in Section ``Starting a Shell or a Command''. The subsystem name used with this protocol is "publickey@vandyke.com". The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with a mandatory command. From ietf-ssh-owner-secsh-archive=odin.ietf.org@netbsd.org Thu Oct 31 22:38:21 2002 Received: from mail.netbsd.org (mail.netbsd.org [155.53.1.253]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26043 for ; Thu, 31 Oct 2002 22:38:20 -0500 (EST) Received: (qmail 18423 invoked by uid 605); 1 Nov 2002 03:40:40 -0000 Delivered-To: ietf-ssh@netbsd.org Message-ID: <20021101034040.18422.qmail@mail.netbsd.org> Received: (qmail 18416 invoked from network); 1 Nov 2002 03:40:38 -0000 Received: from unknown (HELO w0q7s5) (218.20.191.59) by mail.netbsd.org with SMTP; 1 Nov 2002 03:40:38 -0000 From: "guest" Subject: uncertainty principle is untenable !!! To: ietf-ssh@netbsd.org Content-Type: text/plain; charset="GB2312" Date: Sun, 4 Aug 2002 11:41:41 +0800 X-Priority: 3 X-Mailer: jpfree Group Mail Express V1.0 Sender: ietf-ssh-owner@netbsd.org Precedence: list please reply to hdgbyi@public.guangzhou.gd.cn or bfpgong@hotmail.com, thank you. UNCERTAINTY PRINCIPLE IS UNTENABLE By reanalysing the experiment of Heisenberg Gamma-Ray Microscope and one of ideal experiment from which uncertainty principle is derived , it is found that actually uncertainty principle can not be obtained from these two ideal experiments . And it is found that uncertainty principle is untenable. Key words : uncertainty principle; experiment of Heisenberg Gamma-Ray Microscope; ideal experiment Ideal Experiment 1 Experiment of Heisenberg Gamma-Ray Microscope A free electron sits directly beneath the center of the microscope's lens (see the picture below or AIP page: http://www.aip.org/history/heisenberg/p08b.htm). The circular lens forms a cone of angle 2A from the electron. The electron is then illuminated from the left by gamma rays--high energy light which has the shortest wavelength. These yield the highest resolution, for according to a principle of wave optics, the microscope can resolve (that is, "see" or distinguish) objects to a size of dx, which is related to and to the wavelength L of the gamma ray, by the expression: dx = L/(2sinA) (1) However, in quantum mechanics, where a light wave can act like a particle, a gamma ray striking an electron gives it a kick. At the moment the light is diffracted by the electron into the microscope lens, the electron is thrust to the right. To be observed by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A. In quantum mechanics, the gamma ray carries momentum, as if it were a particle. The total momentum p is related to the wavelength by the formula p = h / L, where h is Planck's constant. (2) In the extreme case of diffraction of the gamma ray to the right edge of the lens, the total momentum in the x direction would be the sum of the electron's momentum P'x in the x direction and the gamma ray's momentum in the x direction: P'x + (h sinA) / L', where L' is the wavelength of the deflected gamma ray. In the other extreme, the observed gamma ray recoils backward, just hitting the left edge of the lens. In this case, the total momentum in the x direction is: P''x - (h sinA) / L''. The final x momentum in each case must equal the initial x momentum, since momentum is never lost (it is conserved). Therefore, the final x momenta are equal to each other: P'x + (h sinA) / L' = P''x - (h sinA) / L'' (3) If A is small, then the wavelengths are approximately the same, L' ~ L" ~ L. So we have P''x - P'x = dPx ~ 2h sinA / L (4) Since dx = L/(2 sinA), we obtain a reciprocal relationship between the minimum uncertainty in the measured position,dx, of the electron along the x axis and the uncertainty in its momentum, dPx, in the x direction: dPx ~ h / dx or dPx dx ~ h. (5) For more than minimum uncertainty, the "greater than" sign may added. Except for the factor of 4pi and an equal sign, this is Heisenberg's uncertainty relation for the simultaneous measurement of the position and momentum of an object . Reanalysis To be seen by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A. The microscope can resolve (that is, "see" or distinguish) objects to a size of dx, which is related to and to the wavelength L of the gamma ray, by the expression: dx = L/(2sinA) (1) It is the resolving limit of the microscope, and it is the uncertain quantity of the object's position. Microscope can not see the object which the size is smaller than its resolving limit dx. Therefore, to be seen by the microscope, the size of the electron must be larger than the resolving limit dx or equal to the resolving limit dx. But if the size of the electron is larger than or equal to the resolving limit dx, electron will not be in the range dx. dx can not be deemed to be the uncertain quantity of the electron's position which can be seen by microscope, dx can be deemed to be the uncertain quantity of the electron's position which can not be seen by microscope only. dx is the position's uncertain quantity of the electron which can not be seen by microscope To be seen by the microscope, the gamma ray must be scattered into any angle within the cone of angle 2A, so we can measure the momentum of the electron. dPx is the momentum's uncertain quantity of the electron which can be seen by microscope. What relates to dx is the electron which the size is smaller than the resolving limit .The electron is in the range dx, it can not be seen by the microscope, so its position is uncertain. What relates to dPx is the electron which the size is larger than or equal to the resolving limit .The electron is not in the range dx, it can be seen by the microscope, so its position is certain. Therefore, the electron which relate to dx and dPx respectively is not the same. What we can see is the electron which the size is larger than or equal to the resolving limit dx and has certain position, dx = 0.. Quantum mechanics does not relate to the size of the object. but on the Experiment Of Heisenberg Gamma-Ray Microscope, the using of the microscope must relate to the size of the object, the size of the object which can be seen by the microscope must be larger than or equal to the resolving limit dx of the microscope, thus it does not exist alleged the uncertain quantity of the electron's position dx. To be seen by the microscope, none but the size of the electron is larger than or equal to the resolving limit dx, the gamma ray which diffracted by the electron can be scattered into any angle within the cone of angle 2A, we can measure the momentum of the electron. What we can see is the electron which has certain position, dx = 0, so that none but dx = 0£¬we can measure the momentum of the electron. In Quantum mechanics, the momentum of the electron can be measured accurately when we measure the momentum of the electron only, therefore, we can gained dPx = 0. Therefore , dPx dx =0. (6) Ideal experiment 2 Experiment of single slit diffraction Supposing a particle moves in Y direction originally and then passes a slit with width dx . So the uncertain quantity of the particle position in X direction is dx (see the picture below) , and interference occurs at the back slit . According to Wave Optics , the angle where No.1 min of interference pattern is , can be calculated by following formula : sinA=L/2dx (1) and L=h/p where h is Planck¡¯s constant. (2) So uncertainty principle can be obtained dPx dx ~ h (5) Reanalysis According to Newton first law , if the external force at the X direction does not affect particle ,the particle will keep the uniform straight line Motion State or Static State , and the motion at the Y direction unchangeable .Therefore , we can lead its position in the slit form its starting point . The particle can have the certain position in the slit, and the uncertain quantity of the position dx =0 . According to Newton first law , if the external force at the X direction does not affect particle,and the original motion at the Y direction is unchangeable , the momentum of the particle at the X direction will be Px=0 , and the uncertain quantity of the momentum will be dPx =0. Get: dPx dx =0. (6) It has not any experiment to negate NEWTON FIRST LAW, in spite of quantum mechanics or classical mechanics, NEWTON FIRST LAW can be the same with the microcosmic world. Under the above ideal experiment , it considered that slit¡¯s width is the uncertain quantity of the particle¡¯s position. But there is no reason for us to consider that the particle in the above experiment have position¡¯s uncertain quantity certainly, and no reason for us to consider that the slit¡¯s width is the uncertain quantity of the particle¡¯s position. Therefore, uncertainty principle dPx dx ~ h (5) which is derived from the above experiment is unreasonable . Concluson From the above reanalysis , it is realized that the ideal experiment demonstration for uncertainty principle is untenable . uncertainty principle is untenable. . Reference book : 1. Max Jammer. (1974) The philosophy of quantum mechanics (John wiley & sons , Inc New York ) Page 65 2. Max Jammer. (1974) The philosophy of quantum mechanics (John wiley & sons , Inc New York ) Page 67 http://www.aip.org/history/heisenberg/p08b.htm Author : Gong BingXin Address : P.O.Box A111 YongFa XiaoQu XinHua HuaDu GuangZhou 510800 P.R.China E-mail : hdgbyi@public.guangzhou.gd.cn Tel: 86¡ª20---86856616