draft-ietf-secsh-filexfer-10.txt   draft-ietf-secsh-filexfer-11.txt 
Secure Shell Working Group J. Galbraith Secure Shell Working Group J. Galbraith
Internet-Draft VanDyke Software Internet-Draft VanDyke Software
Expires: December 3, 2005 O. Saarenmaa Expires: July 21, 2006 O. Saarenmaa
F-Secure F-Secure
June 2005 January 17, 2006
SSH File Transfer Protocol SSH File Transfer Protocol
draft-ietf-secsh-filexfer-10.txt draft-ietf-secsh-filexfer-11.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 3, 2005. This Internet-Draft will expire on July 21, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The SSH File Transfer Protocol provides secure file transfer The SSH File Transfer Protocol provides secure file transfer
functionality over any reliable data stream. It is the standard file functionality over any reliable data stream. It is the standard file
transfer protocol for use with the SSH2 protocol. This document transfer protocol for use with the SSH2 protocol. This document
describes the file transfer protocol and its interface to the SSH2 describes the file transfer protocol and its interface to the SSH2
protocol suite. protocol suite.
Table of Contents Table of Contents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
4.1. Request Synchronization and Reordering . . . . . . . . . . 6 4.1. Request Synchronization and Reordering . . . . . . . . . . 6
4.2. New data types defined by this document . . . . . . . . . 7 4.2. New data types defined by this document . . . . . . . . . 7
4.3. Packet Types . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Packet Types . . . . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Initialization . . . . . . . . . . . . . . . . . . . 9 5. Protocol Initialization . . . . . . . . . . . . . . . . . . . 9
5.1. Client Initialization . . . . . . . . . . . . . . . . . . 9 5.1. Client Initialization . . . . . . . . . . . . . . . . . . 9
5.2. Server Initialization . . . . . . . . . . . . . . . . . . 9 5.2. Server Initialization . . . . . . . . . . . . . . . . . . 9
5.3. Determining Server Newline Convention . . . . . . . . . . 10 5.3. Determining Server Newline Convention . . . . . . . . . . 10
5.4. Supported Features . . . . . . . . . . . . . . . . . . . . 10 5.4. Supported Features . . . . . . . . . . . . . . . . . . . . 10
5.5. Version re-negotiation . . . . . . . . . . . . . . . . . . 13 5.5. Version re-negotiation . . . . . . . . . . . . . . . . . . 13
6. File Names . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. File Names . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 15 7. File Attributes . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. valid-attribute-flags . . . . . . . . . . . . . . . . . . 16 7.1. valid-attribute-flags . . . . . . . . . . . . . . . . . . 17
7.2. Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3. Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.4. allocation-size . . . . . . . . . . . . . . . . . . . . . 18 7.4. allocation-size . . . . . . . . . . . . . . . . . . . . . 19
7.5. Owner and Group . . . . . . . . . . . . . . . . . . . . . 18 7.5. Owner and Group . . . . . . . . . . . . . . . . . . . . . 19
7.6. Permissions . . . . . . . . . . . . . . . . . . . . . . . 19 7.6. Permissions . . . . . . . . . . . . . . . . . . . . . . . 20
7.7. Times . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.7. Times . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.8. ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.8. ACL . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.9. attrib-bits and attrib-bits-valid . . . . . . . . . . . . 21 7.9. attrib-bits and attrib-bits-valid . . . . . . . . . . . . 24
7.10. text-hint . . . . . . . . . . . . . . . . . . . . . . . . 24 7.10. text-hint . . . . . . . . . . . . . . . . . . . . . . . . 27
7.11. mime-type . . . . . . . . . . . . . . . . . . . . . . . . 24 7.11. mime-type . . . . . . . . . . . . . . . . . . . . . . . . 27
7.12. link-count . . . . . . . . . . . . . . . . . . . . . . . . 25 7.12. link-count . . . . . . . . . . . . . . . . . . . . . . . . 27
7.13. untranslated-name . . . . . . . . . . . . . . . . . . . . 25 7.13. untranslated-name . . . . . . . . . . . . . . . . . . . . 28
7.14. Extended Attributes . . . . . . . . . . . . . . . . . . . 25 7.14. Extended Attributes . . . . . . . . . . . . . . . . . . . 28
8. Requests From the Client to the Server . . . . . . . . . . . . 25 8. Requests From the Client to the Server . . . . . . . . . . . . 28
8.1. Opening and Closing Files and Directories . . . . . . . . 25 8.1. Opening and Closing Files and Directories . . . . . . . . 28
8.1.1. Opening a File . . . . . . . . . . . . . . . . . . . . 26 8.1.1. Opening a File . . . . . . . . . . . . . . . . . . . . 29
8.1.2. Opening a Directory . . . . . . . . . . . . . . . . . 31 8.1.2. Opening a Directory . . . . . . . . . . . . . . . . . 35
8.1.3. Closing Handles . . . . . . . . . . . . . . . . . . . 32 8.1.3. Closing Handles . . . . . . . . . . . . . . . . . . . 35
8.2. Reading and Writing . . . . . . . . . . . . . . . . . . . 32 8.2. Reading and Writing . . . . . . . . . . . . . . . . . . . 36
8.2.1. Reading Files . . . . . . . . . . . . . . . . . . . . 32 8.2.1. Reading Files . . . . . . . . . . . . . . . . . . . . 36
8.2.2. Reading Directories . . . . . . . . . . . . . . . . . 33 8.2.2. Reading Directories . . . . . . . . . . . . . . . . . 37
8.2.3. Writing Files . . . . . . . . . . . . . . . . . . . . 34 8.2.3. Writing Files . . . . . . . . . . . . . . . . . . . . 37
8.3. Removing and Renaming Files . . . . . . . . . . . . . . . 34 8.3. Removing and Renaming Files . . . . . . . . . . . . . . . 38
8.4. Creating and Deleting Directories . . . . . . . . . . . . 36 8.4. Creating and Deleting Directories . . . . . . . . . . . . 39
8.5. Retrieving File Attributes . . . . . . . . . . . . . . . . 36 8.5. Retrieving File Attributes . . . . . . . . . . . . . . . . 40
8.6. Setting File Attributes . . . . . . . . . . . . . . . . . 37 8.6. Setting File Attributes . . . . . . . . . . . . . . . . . 41
8.7. Dealing with Links . . . . . . . . . . . . . . . . . . . . 38 8.7. Dealing with Links . . . . . . . . . . . . . . . . . . . . 42
8.8. Byte-range locks . . . . . . . . . . . . . . . . . . . . . 39 8.8. Byte-range locks . . . . . . . . . . . . . . . . . . . . . 43
8.9. Canonicalizing the Server-Side Path Name . . . . . . . . . 40 8.9. Canonicalizing the Server-Side Path Name . . . . . . . . . 44
8.9.1. Best Practice for Dealing with Paths . . . . . . . . . 42 8.9.1. Best Practice for Dealing with Paths . . . . . . . . . 46
9. Responses from the Server to the Client . . . . . . . . . . . 43 9. Responses from the Server to the Client . . . . . . . . . . . 47
9.1. Status Response . . . . . . . . . . . . . . . . . . . . . 43 9.1. Status Response . . . . . . . . . . . . . . . . . . . . . 47
9.2. Handle Response . . . . . . . . . . . . . . . . . . . . . 48 9.2. Handle Response . . . . . . . . . . . . . . . . . . . . . 51
9.3. Data Response . . . . . . . . . . . . . . . . . . . . . . 48 9.3. Data Response . . . . . . . . . . . . . . . . . . . . . . 52
9.4. Name Response . . . . . . . . . . . . . . . . . . . . . . 49 9.4. Name Response . . . . . . . . . . . . . . . . . . . . . . 52
9.5. Attrs Response . . . . . . . . . . . . . . . . . . . . . . 50 9.5. Attrs Response . . . . . . . . . . . . . . . . . . . . . . 53
10. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 50 10. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 53
11. Implementation Considerations . . . . . . . . . . . . . . . . 51 11. Implementation Considerations . . . . . . . . . . . . . . . . 54
12. Security Considerations . . . . . . . . . . . . . . . . . . . 51 12. Security Considerations . . . . . . . . . . . . . . . . . . . 55
13. Changes from Previous Protocol Versions . . . . . . . . . . . 53 13. Changes from Previous Protocol Versions . . . . . . . . . . . 56
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
14.1. Normative References . . . . . . . . . . . . . . . . . . . 53 14.1. Normative References . . . . . . . . . . . . . . . . . . . 56
14.2. Informative References . . . . . . . . . . . . . . . . . . 53 14.2. Informative References . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
Intellectual Property and Copyright Statements . . . . . . . . . . 56 Intellectual Property and Copyright Statements . . . . . . . . . . 59
1. Introduction 1. Introduction
This protocol provides secure file transfer (and more generally file This protocol provides secure file transfer (and more generally file
system access.) It is designed so that it could be used to implement system access.) It is designed so that it could be used to implement
a secure remote file system service, as well as a secure file a secure remote file system service, as well as a secure file
transfer service. transfer service.
This protocol assumes that it runs over a secure channel, such as a This protocol assumes that it runs over a secure channel, such as a
channel in [I-D.ietf-secsh-architecture], and that the server has channel in [RFC4251], and that the server has already authenticated
already authenticated the client, and that the identity of the client the client, and that the identity of the client user is available to
user is available to the protocol. the protocol.
In general, this protocol follows a simple request-response model. In general, this protocol follows a simple request-response model.
Each request and response contains a sequence number and multiple Each request and response contains a sequence number and multiple
requests may be pending simultaneously. There are a relatively large requests may be pending simultaneously. There are a relatively large
number of different request messages, but a small number of possible number of different request messages, but a small number of possible
response messages. Each request has one or more response messages response messages. Each request has one or more response messages
that may be returned in result (e.g., a read either returns data or that may be returned in result (e.g., a read either returns data or
reports error status). reports error status).
The packet format descriptions in this specification follow the The packet format descriptions in this specification follow the
notation presented in [I-D.ietf-secsh-architecture]. notation presented in [RFC4251].
Even though this protocol is described in the context of the SSH2 Even though this protocol is described in the context of the SSH2
protocol, this protocol is general and independent of the rest of the protocol, this protocol is general and independent of the rest of the
SSH2 protocol suite. It could be used in a number of different SSH2 protocol suite. It could be used in a number of different
applications, such as secure file transfer over TLS [RFC2246] and applications, such as secure file transfer over TLS [RFC2246] and
transfer of management information in VPN applications. transfer of management information in VPN applications.
2. Acknowledgements 2. Acknowledgements
This document owes it's initial creation and protocol design to Tatu This document owes it's initial creation and protocol design to Tatu
Ylonen and Sami Lehtinen of SSH Communications Security Corp. Ylonen and Sami Lehtinen of SSH Communications Security Corp.
We express our gratitude to them for their initial work on this We express our gratitude to them for their initial work on this
protocol. protocol.
3. Use with the SSH Connection Protocol 3. Use with the SSH Connection Protocol
When used with the SSH2 Protocol suite, this protocol is intended to When used with the SSH2 Protocol suite, this protocol is intended to
be used as a subsystem as described in [I-D.ietf-secsh-connect] in be used as a subsystem as described in [RFC4254] in the section
the section "Starting a Shell or a Command". The subsystem name used "Starting a Shell or a Command". The subsystem name used with this
with this protocol is "sftp". protocol is "sftp".
3.1. The Use of 'stderr' in the server 3.1. The Use of 'stderr' in the server
This protocol uses stdout and stdin to transmit binary protocol data. This protocol uses stdout and stdin to transmit binary protocol data.
The "session" channel ([I-D.ietf-secsh-connect]), which is used by The "session" channel ([RFC4254]), which is used by the subsystem,
the subsystem, also supports the use of stderr. also supports the use of stderr.
Data sent on stderr by the server SHOULD be considered free format Data sent on stderr by the server SHOULD be considered free format
debug or supplemental error information, and MAY be displayed to the debug or supplemental error information, and MAY be displayed to the
user. user.
For example, during initialization, there is no client request For example, during initialization, there is no client request
active, so errors or warning information cannot be sent to the client active, so errors or warning information cannot be sent to the client
as part of the SFTP protocol at this early stage. However, the as part of the SFTP protocol at this early stage. However, the
errors or warnings MAY be sent as stderr text. errors or warnings MAY be sent as stderr text.
skipping to change at page 5, line 35 skipping to change at page 5, line 35
uint32 length uint32 length
byte type byte type
uint32 request-id uint32 request-id
... type specific fields ... ... type specific fields ...
'length' 'length'
The length of the entire packet, excluding the length field The length of the entire packet, excluding the length field
itself, such that, for example, for a packet type containing no itself, such that, for example, for a packet type containing no
type specific fields, the length field would be 5, and 9 bytes of type specific fields, the length field would be 5, and 9 bytes of
data would be sent on the wire. (This is the packet format used data would be sent on the wire. (This is the packet format used
in [I-D.ietf-secsh-transport].) in [RFC4253].)
All packet descriptions in this document omit the length field for All packet descriptions in this document omit the length field for
brevity; the length field MUST be included in any case. brevity; the length field MUST be included in any case.
The maximum size of a packet is in practice determined by the The maximum size of a packet is in practice determined by the
client (the maximum size of read or write requests that it sends, client (the maximum size of read or write requests that it sends,
plus a few bytes of packet overhead). All servers SHOULD support plus a few bytes of packet overhead). All servers SHOULD support
packets of at least 34000 bytes (where the packet size refers to packets of at least 34000 bytes (where the packet size refers to
the full length, including the header above). This should allow the full length, including the header above). This should allow
for reads and writes of at most 32768 bytes. for reads and writes of at most 32768 bytes.
skipping to change at page 6, line 23 skipping to change at page 6, line 23
There are two packets, INIT and VERSION, which do not use the There are two packets, INIT and VERSION, which do not use the
request-id. request-id.
Packet descriptions in this document will contain the 'request-id' Packet descriptions in this document will contain the 'request-id'
field, but will not redefine it. field, but will not redefine it.
Implementations MUST ignore excess data at the end of an otherwise Implementations MUST ignore excess data at the end of an otherwise
valid packet. Implementations MUST respond to unrecognized packet valid packet. Implementations MUST respond to unrecognized packet
types with an SSH_FX_OP_UNSUPPORTED error. This will allow the types with an SSH_FX_OP_UNSUPPORTED error. This will allow the
protocol to be extended in a backwards compatible way as needed. protocol to be extended in a backwards compatible way as needed.
Additionally, when a packet has two or more optional fields, and an
implementation wishes to use the i-th optional field, all fields from
1 to i MUST be present. In other words, only fields after the last
field the implementation wishes to send are actually options.
There is no limit on the number of outstanding (non-acknowledged) There is no limit on the number of outstanding (non-acknowledged)
requests that the client may send to the server. In practice this is requests that the client may send to the server. In practice this is
limited by the buffering available on the data stream and the queuing limited by the buffering available on the data stream and the queuing
performed by the server. If the server's queues are full, it should performed by the server. If the server's queues are full, it should
not read any more data from the stream, and flow control will prevent not read any more data from the stream, and flow control will prevent
the client from sending more requests. Note, however, that while the client from sending more requests. Note, however, that while
there is no restriction on the protocol level, the client's API may there is no restriction on the protocol level, the client's API may
provide a limit in order to prevent infinite queuing of outgoing provide a limit in order to prevent infinite queuing of outgoing
requests at the client. requests at the client.
skipping to change at page 7, line 12 skipping to change at page 7, line 18
request will be indefinitely delayed even if the client is sending request will be indefinitely delayed even if the client is sending
other requests so that there are multiple outstanding requests all other requests so that there are multiple outstanding requests all
the time. the time.
A client MUST be prepared to receive responses to multiple overlapped A client MUST be prepared to receive responses to multiple overlapped
requests out of order. requests out of order.
4.2. New data types defined by this document 4.2. New data types defined by this document
This document defines these data types in addition to those defined This document defines these data types in addition to those defined
in [I-D.ietf-secsh-architecture]. in [RFC4251].
uint16 uint16
Represents a 16-bit unsigned integer. Stored as 2 bytes in the Represents a 16-bit unsigned integer. Stored as 2 bytes in the
order of decreasing significance (network byte order). order of decreasing significance (network byte order).
int64 int64
Represents a 64-bit signed integer. Stored using two's Represents a 64-bit signed integer. Stored using two's
complement, as eight bytes in the order of decreasing significance complement, as eight bytes in the order of decreasing significance
(network byte order). (network byte order).
extension-pair extension-pair
string extension-name string extension-name
string extension-data string extension-data
'extension-name' is the name of a protocol extension. Extensions 'extension-name' is the name of a protocol extension. Extensions
not defined by IETF CONSENSUS MUST follow the the DNS not defined by IETF CONSENSUS MUST follow the the DNS
extensibility naming convention outlined in [I-D.ietf-secsh- extensibility naming convention outlined in [RFC4251].
architecture].
'extension-data' is any data specific to the extension, and MAY be 'extension-data' is any data specific to the extension, and MAY be
zero length if the extension has no data. zero length if the extension has no data.
4.3. Packet Types 4.3. Packet Types
The following values are defined for packet types. The following values are defined for packet types.
SSH_FXP_INIT 1 SSH_FXP_INIT 1
SSH_FXP_VERSION 2 SSH_FXP_VERSION 2
skipping to change at page 10, line 15 skipping to change at page 10, line 15
'extensions' is 0 or more extension-pairs (Section 4.2). 'extensions' is 0 or more extension-pairs (Section 4.2).
Implementations MUST silently ignore any extensions whose names they Implementations MUST silently ignore any extensions whose names they
do not recognize. do not recognize.
5.3. Determining Server Newline Convention 5.3. Determining Server Newline Convention
In order to correctly process text files in a cross platform In order to correctly process text files in a cross platform
compatible way, newline sequences must be converted between client compatible way, newline sequences must be converted between client
and server conventions. and server conventions.
The SSH_FXF_ACCESS_TEXT_MODE file open flag (Section 8.1.1) makes it The SSH_FXF_TEXT_MODE file open flag (Section 8.1.1) makes it
possible to request that the server translate a file to a 'canonical' possible to request that the server translate a file to a 'canonical'
wire format. This format uses CRLF as the line separator. wire format. This format uses CRLF as the line separator.
Servers for systems using other conventions MUST translate to and Servers for systems using other conventions MUST translate to and
from the canonical form. from the canonical form.
However, to ease the burden of implementation on servers that use a However, to ease the burden of implementation on servers that use a
single, simple, separator sequence the following extension allows the single, simple, separator sequence the following extension allows the
canonical format to be changed. canonical format to be changed.
skipping to change at page 12, line 17 skipping to change at page 12, line 17
than or equal to the value, unless it encounters EOF or an ERROR. than or equal to the value, unless it encounters EOF or an ERROR.
The server MAY use this value to express that it is willing to The server MAY use this value to express that it is willing to
handle very large read requests, in excess of the standard 34000 handle very large read requests, in excess of the standard 34000
bytes specified in Section 4. bytes specified in Section 4.
supported-open-block-vector supported-open-block-vector
supported-block-vector supported-block-vector
16-bit masks specifying which combinations of blocking flags are 16-bit masks specifying which combinations of blocking flags are
supported. Each bit corresponds to one combination of the supported. Each bit corresponds to one combination of the
SSH_FXF_ACCESS_BLOCK_READ, SSH_FXF_ACCESS_BLOCK_WRITE, SSH_FXF_BLOCK_READ, SSH_FXF_BLOCK_WRITE, SSH_FXF_BLOCK_DELETE, and
SSH_FXF_ACCESS_BLOCK_DELETE, and SSH_FXF_ACCESS_BLOCK_ADVISORY SSH_FXF_BLOCK_ADVISORY bits from Section 7.1.1.3, with a set bit
bits from Section 7.1.1.3, with a set bit corresponding to a corresponding to a supported combination and a clear bit an
supported combination and a clear bit an unsupported combination. unsupported combination. The index of a bit, bit zero being the
The index of a bit, bit zero being the least significant bit, least significant bit, viewed as a four-bit number, corresponds to
viewed as a four-bit number, corresponds to a combination of flag a combination of flag bits, shifted right so that BLOCK_READ is
bits, shifted right so that BLOCK_READ is the least significant the least significant bit. The combination `no blocking flags'
bit. The combination `no blocking flags' MUST be supported, so MUST be supported, so the low bit will always be set.
the low bit will always be set.
For example, a server supporting only the classic advisory read For example, a server supporting only the classic advisory read
(shared) and write (exclusive) locks would set the bits (shared) and write (exclusive) locks would set the bits
corresponding to READ+WRITE+ADVISORY, 0b1011, and WRITE+ADVISORY, corresponding to READ+WRITE+ADVISORY, 0b1011, and WRITE+ADVISORY,
0b1010, plus the always-set bit 0b0000, giving a mask value of 0b1010, plus the always-set bit 0b0000, giving a mask value of
0b0000110000000001, or 0x0c01; a server supporting no locking at 0b0000110000000001, or 0x0c01; a server supporting no locking at
all would set only bit zero, giving 0x0001. all would set only bit zero, giving 0x0001.
'supported-open-block-masks' applies to the SSH_FXP_OPEN 'supported-open-block-masks' applies to the SSH_FXP_OPEN
(Section 8.1.1) flags field. 'supported-block-masks' applies to (Section 8.1.1) flags field. 'supported-block-masks' applies to
skipping to change at page 13, line 17 skipping to change at page 13, line 15
either not allow the bit to be masked off, or MUST fail the operation either not allow the bit to be masked off, or MUST fail the operation
gracefully without sending the request to the server. gracefully without sending the request to the server.
The client MAY send requests that are not supported by the server; The client MAY send requests that are not supported by the server;
however, it is not normally expected to be productive to do so. The however, it is not normally expected to be productive to do so. The
client SHOULD apply the mask even to attrib structures received from client SHOULD apply the mask even to attrib structures received from
the server. The server MAY include attributes or attrib-bits that the server. The server MAY include attributes or attrib-bits that
are not included in the mask. Such attributes or attrib-bits are are not included in the mask. Such attributes or attrib-bits are
effectively read-only. effectively read-only.
The supported capabilities of the acl attribute are sent using the
following extension.
string "acl-supported"
string supported-structure
uint32 capabilities
'capabilities' is a combination of the following bits:
SSH_ACL_CAP_ALLOW 0x00000001
SSH_ACL_CAP_DENY 0x00000002
SSH_ACL_CAP_AUDIT 0x00000004
SSH_ACL_CAP_ALARM 0x00000008
SSH_ACL_CAP_INHERIT_ACCESS 0x00000010
SSH_ACL_CAP_INHERIT_AUDIT_ALARM 0x00000020
SSH_ACL_CAP_ALLOW
SSH_ACL_CAP_DENY
SSH_ACL_CAP_AUDIT
SSH_ACL_CAP_ALARM
The server supports the associated ACL ACE type.
SSH_ACL_CAP_INHERIT_ACCESS
The server can control whether a ACL will inherit DENY and ALLOW
ACEs that are marked inheritable from it's parent object.
SSH_ACL_CAP_INHERIT_AUDIT_ALARM
The server can control whether a ACL will inherit AUDIT or ALARM
ACEs that are marked inheritable from it's parent object.
5.5. Version re-negotiation 5.5. Version re-negotiation
If the server supports other versions than what was negotiated, it If the server supports other versions than what was negotiated, it
may wish to send the 'versions' extension to inform the client of may wish to send the 'versions' extension to inform the client of
this fact. The client may then optionally choose to use one of the this fact. The client may then optionally choose to use one of the
other versions supported. other versions supported.
string "versions" string "versions"
string comma-separated-versions string comma-separated-versions
'comma-separated-versions' is a string of comma separated version 'comma-separated-versions' is a string of comma separated version
numbers. Defined versions are: "2", "3", "4", "5", "6". Any other numbers. Defined versions are: "2", "3", "4", "5", "6". Any other
version advertised by the server must follow the DNS extensibility version advertised by the server must follow the DNS extensibility
naming convention outlined in [I-D.ietf-secsh-architecture]. naming convention outlined in [RFC4251].
For example: "2,3,6,private@example.com". For example: "2,3,6,private@example.com".
If the client and server have negotiated a a version greater than or If the client and server have negotiated a a version greater than or
equal to version '3' (the version at which SSH_FXP_EXTENDED was equal to version '3' (the version at which SSH_FXP_EXTENDED was
introduced) in the initial VERSION/INIT exchange, the client may introduced) in the initial VERSION/INIT exchange, the client may
select a new version to use from the list the server provided using select a new version to use from the list the server provided using
the following SSH_FXP_EXTENDED request. the following SSH_FXP_EXTENDED request.
string "version-select" string "version-select"
skipping to change at page 18, line 10 skipping to change at page 19, line 5
7.3. Size 7.3. Size
The 'size' field specifies the number of bytes that can be read from The 'size' field specifies the number of bytes that can be read from
the file, or in other words, the location of the end-of-file. This the file, or in other words, the location of the end-of-file. This
attribute MUST NOT be present during file creation. attribute MUST NOT be present during file creation.
If this field is present during a setstat operation, the file MUST be If this field is present during a setstat operation, the file MUST be
extended or truncated to the specified size. extended or truncated to the specified size.
Files opened with the SSH_FXF_ACCESS_TEXT flag may have a size that Files opened with the SSH_FXF_TEXT flag may have a size that is
is greater or less than the value of the size field. The server MAY greater or less than the value of the size field. The server MAY
fail setstat operations specifying size for files opened with the fail setstat operations specifying size for files opened with the
SSH_FXF_ACCESS_TEXT flag. SSH_FXF_TEXT flag.
7.4. allocation-size 7.4. allocation-size
The 'allocation-size' field specifies the number of bytes that the The 'allocation-size' field specifies the number of bytes that the
file consumes on disk. This field MAY be less than the 'size' field file consumes on disk. This field MAY be less than the 'size' field
if the file is 'sparse' (Section 7.9). if the file is 'sparse' (Section 7.9).
When present during file creation, the file SHOULD be created and the When present during file creation, the file SHOULD be created and the
specified number of bytes preallocated. If the preallocation fails, specified number of bytes preallocated. If the preallocation fails,
the file should be removed (if it was created) and an error returned. the file should be removed (if it was created) and an error returned.
skipping to change at page 20, line 27 skipping to change at page 21, line 20
half second before 0 hour January 1, 1970, the seconds field would half second before 0 hour January 1, 1970, the seconds field would
have a value of negative one (-1) and the nseconds fields would have have a value of negative one (-1) and the nseconds fields would have
a value of one-half second (500000000). Values greater than a value of one-half second (500000000). Values greater than
999,999,999 for nseconds are considered invalid. 999,999,999 for nseconds are considered invalid.
7.8. ACL 7.8. ACL
The 'ACL' field contains an ACL similar to that defined in section The 'ACL' field contains an ACL similar to that defined in section
5.9 of NFS version 4 Protocol [RFC3010]. 5.9 of NFS version 4 Protocol [RFC3010].
The structure of the ACL is:
uint32 acl-flags
uint32 ace-count uint32 ace-count
ACE ace[ace-count]
The ACE data structure is composes as follows:
repeated ace-count times:
uint32 ace-type uint32 ace-type
uint32 ace-flag uint32 ace-flag
uint32 ace-mask uint32 ace-mask
string who [UTF-8] string who [UTF-8]
ace-type is one of the following four values (taken from NFS Version acl-flags
4 Protocol [RFC3010]:
SFX_ACL_CONTROL_INCLUDED 0x00000001
SFX_ACL_CONTROL_PRESENT 0x00000002
SFX_ACL_CONTROL_INHERITED 0x00000004
SFX_ACL_AUDIT_ALARM_INCLUDED 0x00000010
SFX_ACL_AUDIT_ALARM_INHERITED 0x00000020
SFX_ACL_CONTROL_INCLUDED
SFX_ACL_CONTROL_PRESENT
SFX_ACL_CONTROL_INHERITED
If INCLUDED is set during a setstat operation, then the client
intends to modify the ALLOWED/DENIED entries of the ACL.
Otherwise, the client intends for these entries to be
preserved.
If the PRESENT bit is not set, then the client wishes to remove
control entries. If the server doesn't support separate
control and audit information, the client MUST not clear this
bit without also clearing the AUDIT_ALARM_PRESENT bit.
If the PRESENT bit is clear, then control of the file MAY be
through the permissions mask. The server MAY also grant full
access to the file.
If the both the INCLUDE and the PRESENT bit are set, but their
are no ALLOW/DENY entries in the list, the client wishes to
deny all access to the file or directory. The server may have
to transform this into a ACL with a deny entry to implement it.
If INHERITED is set, then ALLOW/DENY ACEs MAY be inherited from
the parent directory. If it is off, then they MUST not be
INHERITED. If the server does not support controlling
inheritance, then the client MUST clear this bit; in this case
the inheritance properties of the server are undefined.
SFX_ACL_AUDIT_ALARM_INCLUDED
SFX_ACL_AUDIT_ALARM_INHERITED
If INCLUDE is set during a setstat operation, then the client
intends to modify the AUDIT/ALARM entries of the ACL.
Otherwise, the client intends for these entries to be
preserved.
If INHERITED is set, then AUDIT/ALARM ACEs MAY be inherited
from the parent directory. If it is off, then they MUST not be
INHERITED. If the server does not support controlling
inheritance, then the client MUST clear this bit; in this case
the inheritance properties of the server are undefined.
Because some server require special permissions / privileges in
order to modify the AUDIT/ALARM entries in the ACL, it is
important to communicate to the server the clients intent to
modify these entries. The client MUST both use the
ACCESS_AUDIT_ALARM_ATTRIBUTES bit in the desired attribute of the
open request and must set the SFX_ACL_AUDIT_ALARM_INCLUDED during
the setstat operation.
Clients that do not intend specifically to modify the AUDIT or
ALARM entries SHOULD NOT set SSH_FXF_ACCESS_AUDIT_ALARM_INFO in
the open-flags and SHOULD NOT set the SFX_ACL_AUDIT_ALARM_INCLUDED
bit because these operations are often privileged and will fail.
If the SFX_ACL_AUDIT_ALARM_INCLUDED is set, and the requested
change can not be made, the server MUST fail the request.
Servers that do not seperate control and audit/alarm information
may have to read the existing ACL and merge in enteries not
included by the client. The server must take this into account
when opening files with the ACE4_WRITE_ACL permission requested.
ace-type
one of the following four values (taken from NFS Version 4
Protocol [RFC3010]:
ACE4_ACCESS_ALLOWED_ACE_TYPE 0x00000000 ACE4_ACCESS_ALLOWED_ACE_TYPE 0x00000000
ACE4_ACCESS_DENIED_ACE_TYPE 0x00000001 ACE4_ACCESS_DENIED_ACE_TYPE 0x00000001
ACE4_SYSTEM_AUDIT_ACE_TYPE 0x00000002 ACE4_SYSTEM_AUDIT_ACE_TYPE 0x00000002
ACE4_SYSTEM_ALARM_ACE_TYPE 0x00000003 ACE4_SYSTEM_ALARM_ACE_TYPE 0x00000003
ace-flag is a combination of the following flag values. See NFS ace-flag
Version 4 Protocol [RFC3010] section 5.9.2: A combination of the following flag values. See NFS Version 4
Protocol [RFC3010] section 5.9.2:
ACE4_FILE_INHERIT_ACE 0x00000001 ACE4_FILE_INHERIT_ACE 0x00000001
ACE4_DIRECTORY_INHERIT_ACE 0x00000002 ACE4_DIRECTORY_INHERIT_ACE 0x00000002
ACE4_NO_PROPAGATE_INHERIT_ACE 0x00000004 ACE4_NO_PROPAGATE_INHERIT_ACE 0x00000004
ACE4_INHERIT_ONLY_ACE 0x00000008 ACE4_INHERIT_ONLY_ACE 0x00000008
ACE4_SUCCESSFUL_ACCESS_ACE_FLAG 0x00000010 ACE4_SUCCESSFUL_ACCESS_ACE_FLAG 0x00000010
ACE4_FAILED_ACCESS_ACE_FLAG 0x00000020 ACE4_FAILED_ACCESS_ACE_FLAG 0x00000020
ACE4_IDENTIFIER_GROUP 0x00000040 ACE4_IDENTIFIER_GROUP 0x00000040
ace-mask is any combination of the following flags (taken from
[RFC3010], section 5.9.3. The semantic meaning of these flags is ace-mask
also given in [RFC3010]. Combination of the following flags (taken from [RFC3010], section
5.9.3. The semantic meaning of these flags is also given in
[RFC3010].
ACE4_READ_DATA 0x00000001 ACE4_READ_DATA 0x00000001
ACE4_LIST_DIRECTORY 0x00000001 ACE4_LIST_DIRECTORY 0x00000001
ACE4_WRITE_DATA 0x00000002 ACE4_WRITE_DATA 0x00000002
ACE4_ADD_FILE 0x00000002 ACE4_ADD_FILE 0x00000002
ACE4_APPEND_DATA 0x00000004 ACE4_APPEND_DATA 0x00000004
ACE4_ADD_SUBDIRECTORY 0x00000004 ACE4_ADD_SUBDIRECTORY 0x00000004
ACE4_READ_NAMED_ATTRS 0x00000008 ACE4_READ_NAMED_ATTRS 0x00000008
ACE4_WRITE_NAMED_ATTRS 0x00000010 ACE4_WRITE_NAMED_ATTRS 0x00000010
ACE4_EXECUTE 0x00000020 ACE4_EXECUTE 0x00000020
ACE4_DELETE_CHILD 0x00000040 ACE4_DELETE_CHILD 0x00000040
ACE4_READ_ATTRIBUTES 0x00000080 ACE4_READ_ATTRIBUTES 0x00000080
ACE4_WRITE_ATTRIBUTES 0x00000100 ACE4_WRITE_ATTRIBUTES 0x00000100
ACE4_DELETE 0x00010000 ACE4_DELETE 0x00010000
ACE4_READ_ACL 0x00020000 ACE4_READ_ACL 0x00020000
ACE4_WRITE_ACL 0x00040000 ACE4_WRITE_ACL 0x00040000
ACE4_WRITE_OWNER 0x00080000 ACE4_WRITE_OWNER 0x00080000
ACE4_SYNCHRONIZE 0x00100000 ACE4_SYNCHRONIZE 0x00100000
who is a UTF-8 string of the form described in 'Owner and Group' who
UTF-8 string of the form described in 'Owner and Group'
(Section 7.5) (Section 7.5)
Also, as per '5.9.4 ACE who' [RFC3010] there are several
Also, as per '5.9.4 ACE who' [RFC3010] there are several identifiers identifiers that need to be understood universally. Some of these
that need to be understood universally. Some of these identifiers identifiers cannot be understood when an client access the server,
cannot be understood when an client access the server, but have but have meaning when a local process accesses the file. The
meaning when a local process accesses the file. The ability to ability to display and modify these permissions is permitted over
display and modify these permissions is permitted over SFTP. SFTP.
OWNER The owner of the file. OWNER The owner of the file.
GROUP The group associated with the file. GROUP The group associated with the file.
EVERYONE The world. EVERYONE The world.
INTERACTIVE Accessed from an interactive terminal. INTERACTIVE Accessed from an interactive terminal.
NETWORK Accessed via the network. NETWORK Accessed via the network.
DIALUP Accessed as a dialup user to the server. DIALUP Accessed as a dialup user to the server.
BATCH Accessed from a batch job. BATCH Accessed from a batch job.
ANONYMOUS Accessed without any authentication. ANONYMOUS Accessed without any authentication.
AUTHENTICATED Any authenticated user (opposite of ANONYMOUS). AUTHENTICATED Any authenticated user (opposite of ANONYMOUS).
skipping to change at page 23, line 35 skipping to change at page 26, line 33
if a client writes a buffer at 10 M from the beginning of the if a client writes a buffer at 10 M from the beginning of the
file, the blocks between the previous EOF marker and the 10 M file, the blocks between the previous EOF marker and the 10 M
offset would not consume physical disk space. offset would not consume physical disk space.
Some servers may store all files as sparse files, in which case Some servers may store all files as sparse files, in which case
this bit will be unconditionally set. Other servers may not have this bit will be unconditionally set. Other servers may not have
a mechanism for determining if the file is sparse, and so the file a mechanism for determining if the file is sparse, and so the file
MAY be stored sparse even if this flag is not set. MAY be stored sparse even if this flag is not set.
SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY SSH_FILEXFER_ATTR_FLAGS_APPEND_ONLY
Opening the file without either the SSH_FXF_ACCESS_APPEND_DATA or Opening the file without either the SSH_FXF_APPEND_DATA or the
the SSH_FXF_ACCESS_APPEND_DATA_ATOMIC flag (Section 8.1.1.3) MUST SSH_FXF_APPEND_DATA_ATOMIC flag (Section 8.1.1.3) MUST result in
result in an SSH_FX_INVALID_PARAMETER error. an SSH_FX_INVALID_PARAMETER error.
SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE SSH_FILEXFER_ATTR_FLAGS_IMMUTABLE
The file cannot be deleted or renamed, no hard link can be created The file cannot be deleted or renamed, no hard link can be created
to this file, and no data can be written to the file. to this file, and no data can be written to the file.
This bit implies a stronger level of protection than This bit implies a stronger level of protection than
SSH_FILEXFER_ATTR_FLAGS_READONLY, the file permission mask or SSH_FILEXFER_ATTR_FLAGS_READONLY, the file permission mask or
ACLs. Typically even the superuser cannot write to immutable ACLs. Typically even the superuser cannot write to immutable
files, and only the superuser can set or remove the bit. files, and only the superuser can set or remove the bit.
skipping to change at page 24, line 27 skipping to change at page 27, line 23
The value is one of the following enumerations, and indicates what The value is one of the following enumerations, and indicates what
the server knows about the content of the file. the server knows about the content of the file.
SSH_FILEXFER_ATTR_KNOWN_TEXT 0x00 SSH_FILEXFER_ATTR_KNOWN_TEXT 0x00
SSH_FILEXFER_ATTR_GUESSED_TEXT 0x01 SSH_FILEXFER_ATTR_GUESSED_TEXT 0x01
SSH_FILEXFER_ATTR_KNOWN_BINARY 0x02 SSH_FILEXFER_ATTR_KNOWN_BINARY 0x02
SSH_FILEXFER_ATTR_GUESSED_BINARY 0x03 SSH_FILEXFER_ATTR_GUESSED_BINARY 0x03
SSH_FILEXFER_ATTR_KNOWN_TEXT SSH_FILEXFER_ATTR_KNOWN_TEXT
The server knows the file is a text file, and should be opened The server knows the file is a text file, and should be opened
using the SSH_FXF_ACCESS_TEXT_MODE flag. using the SSH_FXF_TEXT_MODE flag.
SSH_FILEXFER_ATTR_GUESSED_TEXT SSH_FILEXFER_ATTR_GUESSED_TEXT
The server has applied a heuristic or other mechanism and believes The server has applied a heuristic or other mechanism and believes
that the file should be opened with the SSH_FXF_ACCESS_TEXT_MODE that the file should be opened with the SSH_FXF_TEXT_MODE flag.
flag.
SSH_FILEXFER_ATTR_KNOWN_BINARY SSH_FILEXFER_ATTR_KNOWN_BINARY
The server knows the file has binary content. The server knows the file has binary content.
SSH_FILEXFER_ATTR_GUESSED_BINARY SSH_FILEXFER_ATTR_GUESSED_BINARY
The server has applied a heuristic or other mechanism and believes The server has applied a heuristic or other mechanism and believes
has binary content, and should not be opened with the has binary content, and should not be opened with the
SSH_FXF_ACCESS_TEXT_MODE flag. SSH_FXF_TEXT_MODE flag.
This flag MUST NOT be present during either a setstat or a fsetstat This flag MUST NOT be present during either a setstat or a fsetstat
operation. operation.
7.11. mime-type 7.11. mime-type
The 'mime-type' field contains the mime-type [RFC1521] string. Most The 'mime-type' field contains the mime-type [RFC1521] string. Most
servers will not know this information and should not set the bit in servers will not know this information and should not set the bit in
their supported-attribute-mask. their supported-attribute-mask.
skipping to change at page 27, line 23 skipping to change at page 30, line 19
desired. desired.
The following 'flags' are defined: The following 'flags' are defined:
SSH_FXF_ACCESS_DISPOSITION = 0x00000007 SSH_FXF_ACCESS_DISPOSITION = 0x00000007
SSH_FXF_CREATE_NEW = 0x00000000 SSH_FXF_CREATE_NEW = 0x00000000
SSH_FXF_CREATE_TRUNCATE = 0x00000001 SSH_FXF_CREATE_TRUNCATE = 0x00000001
SSH_FXF_OPEN_EXISTING = 0x00000002 SSH_FXF_OPEN_EXISTING = 0x00000002
SSH_FXF_OPEN_OR_CREATE = 0x00000003 SSH_FXF_OPEN_OR_CREATE = 0x00000003
SSH_FXF_TRUNCATE_EXISTING = 0x00000004 SSH_FXF_TRUNCATE_EXISTING = 0x00000004
SSH_FXF_ACCESS_APPEND_DATA = 0x00000008 SSH_FXF_APPEND_DATA = 0x00000008
SSH_FXF_ACCESS_APPEND_DATA_ATOMIC = 0x00000010 SSH_FXF_APPEND_DATA_ATOMIC = 0x00000010
SSH_FXF_ACCESS_TEXT_MODE = 0x00000020 SSH_FXF_TEXT_MODE = 0x00000020
SSH_FXF_ACCESS_BLOCK_READ = 0x00000040 SSH_FXF_BLOCK_READ = 0x00000040
SSH_FXF_ACCESS_BLOCK_WRITE = 0x00000080 SSH_FXF_BLOCK_WRITE = 0x00000080
SSH_FXF_ACCESS_BLOCK_DELETE = 0x00000100 SSH_FXF_BLOCK_DELETE = 0x00000100
SSH_FXF_ACCESS_BLOCK_ADVISORY = 0x00000200 SSH_FXF_BLOCK_ADVISORY = 0x00000200
SSH_FXF_ACCESS_NOFOLLOW = 0x00000400 SSH_FXF_NOFOLLOW = 0x00000400
SSH_FXF_ACCESS_DELETE_ON_CLOSE = 0x00000800 SSH_FXF_DELETE_ON_CLOSE = 0x00000800
SSH_FXF_ACCESS_AUDIT_ALARM_INFO = 0x00001000
SSH_FXF_ACCESS_BACKUP = 0x00002000
SSH_FXF_BACKUP_STREAM = 0x00004000
SSH_FXF_OVERRIDE_OWNER = 0x00008000
SSH_FXF_ACCESS_DISPOSITION SSH_FXF_ACCESS_DISPOSITION
Disposition is a 3 bit field that controls how the file is opened. Disposition is a 3 bit field that controls how the file is opened.
The server MUST support these bits. Any one of the following The server MUST support these bits. Any one of the following
enumeration is allowed: enumeration is allowed:
SSH_FXF_CREATE_NEW SSH_FXF_CREATE_NEW
A new file is created; if the file already exists, the server A new file is created; if the file already exists, the server
MUST return status SSH_FX_FILE_ALREADY_EXISTS. MUST return status SSH_FX_FILE_ALREADY_EXISTS.
skipping to change at page 28, line 14 skipping to change at page 31, line 14
SSH_FXF_OPEN_OR_CREATE SSH_FXF_OPEN_OR_CREATE
If the file exists, it is opened. If the file does not exist, If the file exists, it is opened. If the file does not exist,
it is created. it is created.
SSH_FXF_TRUNCATE_EXISTING SSH_FXF_TRUNCATE_EXISTING
An existing file is opened and truncated. If the file does not An existing file is opened and truncated. If the file does not
exist, the server MUST return the same error codes as defined exist, the server MUST return the same error codes as defined
for SSH_FXF_OPEN_EXISTING. for SSH_FXF_OPEN_EXISTING.
SSH_FXF_ACCESS_APPEND_DATA SSH_FXF_APPEND_DATA
Data is always written at the end of the file. The offset field Data is always written at the end of the file. The offset field
of the SSH_FXP_WRITE requests are ignored. of the SSH_FXP_WRITE requests are ignored.
Data is not required to be appended atomically. This means that Data is not required to be appended atomically. This means that
if multiple writers attempt to append data simultaneously, data if multiple writers attempt to append data simultaneously, data
from the first may be lost. However, data MAY be appended from the first may be lost. However, data MAY be appended
atomically. atomically.
SSH_FXF_ACCESS_APPEND_DATA_ATOMIC SSH_FXF_APPEND_DATA_ATOMIC
Data is always written at the end of the file. The offset field Data is always written at the end of the file. The offset field
of the SSH_FXP_WRITE requests are ignored. of the SSH_FXP_WRITE requests are ignored.
Data MUST be written atomically so that there is no chance that Data MUST be written atomically so that there is no chance that
multiple appenders can collide and result in data being lost. multiple appenders can collide and result in data being lost.
If both append flags are specified, the server SHOULD use atomic If both append flags are specified, the server SHOULD use atomic
append if it is available, but SHOULD use non-atomic appends append if it is available, but SHOULD use non-atomic appends
otherwise. The server SHOULD NOT fail the request in this case. otherwise. The server SHOULD NOT fail the request in this case.
SSH_FXF_ACCESS_TEXT_MODE SSH_FXF_TEXT_MODE
Indicates that the server should treat the file as text and Indicates that the server should treat the file as text and
convert it to the canonical newline convention in use. (See convert it to the canonical newline convention in use. (See
Determining Server Newline Convention. (Section 5.3) Determining Server Newline Convention. (Section 5.3)
When a file is opened with this flag, the offset field in the read When a file is opened with this flag, the offset field in the read
and write functions is ignored. and write functions is ignored.
Servers MUST process multiple, parallel reads and writes correctly Servers MUST process multiple, parallel reads and writes correctly
in this mode. Naturally, it is permissible for them to do this by in this mode. Naturally, it is permissible for them to do this by
serializing the requests. serializing the requests.
Clients SHOULD use the SSH_FXF_ACCESS_APPEND_DATA flag to append Clients SHOULD use the SSH_FXF_APPEND_DATA flag to append data to
data to a text file rather then using write with a calculated a text file rather then using write with a calculated offset.
offset.
To support seeks on text files the following SSH_FXP_EXTENDED To support seeks on text files the following SSH_FXP_EXTENDED
packet is defined. packet is defined.
string "text-seek" string "text-seek"
string file-handle string file-handle
uint64 line-number uint64 line-number
line-number is the index of the line number to seek to, where byte line-number is the index of the line number to seek to, where byte
0 in the file is line number 0, and the byte directly following 0 in the file is line number 0, and the byte directly following
skipping to change at page 29, line 27 skipping to change at page 32, line 27
message. message.
An attempt to seek past the end-of-file should result in a An attempt to seek past the end-of-file should result in a
SSH_FX_EOF status. SSH_FX_EOF status.
Servers SHOULD support at least one "text-seek" in order to Servers SHOULD support at least one "text-seek" in order to
support resume. However, a client MUST be prepared to receive support resume. However, a client MUST be prepared to receive
SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation. SSH_FX_OP_UNSUPPORTED when attempting a "text-seek" operation.
The client can then try a fall-back strategy, if it has one. The client can then try a fall-back strategy, if it has one.
SSH_FXF_ACCESS_BLOCK_READ SSH_FXF_BLOCK_READ
The server MUST guarantee that no other handle has been opened The server MUST guarantee that no other handle has been opened
with ACE4_READ_DATA access, and that no other handle will be with ACE4_READ_DATA access, and that no other handle will be
opened with ACE4_READ_DATA access until the client closes the opened with ACE4_READ_DATA access until the client closes the
handle. (This MUST apply both to other clients and to other handle. (This MUST apply both to other clients and to other
processes on the server.) processes on the server.)
If there is a conflicting lock the server MUST return If there is a conflicting lock the server MUST return
SSH_FX_LOCK_CONFLICT. If the server cannot make the locking SSH_FX_LOCK_CONFLICT. If the server cannot make the locking
guarantee, it MUST return SSH_FX_OP_UNSUPPORTED. guarantee, it MUST return SSH_FX_OP_UNSUPPORTED.
Other handles MAY be opened for ACE4_WRITE_DATA or any other Other handles MAY be opened for ACE4_WRITE_DATA or any other
combination of accesses, as long as ACE4_READ_DATA is not included combination of accesses, as long as ACE4_READ_DATA is not included
in the mask. in the mask.
SSH_FXF_ACCESS_BLOCK_WRITE SSH_FXF_BLOCK_WRITE
The server MUST guarantee that no other handle has been opened The server MUST guarantee that no other handle has been opened
with ACE4_WRITE_DATA or ACE4_APPEND_DATA access, and that no other with ACE4_WRITE_DATA or ACE4_APPEND_DATA access, and that no other
handle will be opened with ACE4_WRITE_DATA or ACE4_APPEND_DATA handle will be opened with ACE4_WRITE_DATA or ACE4_APPEND_DATA
access until the client closes the handle. (This MUST apply both access until the client closes the handle. (This MUST apply both
to other clients and to other processes on the server.) to other clients and to other processes on the server.)
If there is a conflicting lock the server MUST return If there is a conflicting lock the server MUST return
SSH_FX_LOCK_CONFLICT. If the server cannot make the locking SSH_FX_LOCK_CONFLICT. If the server cannot make the locking
guarantee, it MUST return SSH_FX_OP_UNSUPPORTED. guarantee, it MUST return SSH_FX_OP_UNSUPPORTED.
Other handles MAY be opened for ACE4_READ_DATA or any other Other handles MAY be opened for ACE4_READ_DATA or any other
combination of accesses, as long as neither ACE4_WRITE_DATA nor combination of accesses, as long as neither ACE4_WRITE_DATA nor
ACE4_APPEND_DATA are included in the mask. ACE4_APPEND_DATA are included in the mask.
SSH_FXF_ACCESS_BLOCK_DELETE SSH_FXF_BLOCK_DELETE
The server MUST guarantee that no other handle has been opened The server MUST guarantee that no other handle has been opened
with ACE4_DELETE access, opened with the with ACE4_DELETE access, opened with the SSH_FXF_DELETE_ON_CLOSE
SSH_FXF_ACCESS_DELETE_ON_CLOSE flag set, and that no other handle flag set, and that no other handle will be opened with ACE4_DELETE
will be opened with ACE4_DELETE access or with the access or with the SSH_FXF_DELETE_ON_CLOSE flag set, and that the
SSH_FXF_ACCESS_DELETE_ON_CLOSE flag set, and that the file itself file itself is not deleted in any other way until the client
is not deleted in any other way until the client closes the closes the handle.
handle.
If there is a conflicting lock the server MUST return If there is a conflicting lock the server MUST return
SSH_FX_LOCK_CONFLICT. If the server cannot make the locking SSH_FX_LOCK_CONFLICT. If the server cannot make the locking
guarantee, it MUST return SSH_FX_OP_UNSUPPORTED. guarantee, it MUST return SSH_FX_OP_UNSUPPORTED.
SSH_FXF_ACCESS_BLOCK_ADVISORY SSH_FXF_BLOCK_ADVISORY
If this bit is set, the above BLOCK modes are advisory. In If this bit is set, the above BLOCK modes are advisory. In
advisory mode, only other accesses that specify a BLOCK mode need advisory mode, only other accesses that specify a BLOCK mode need
be considered when determining whether the BLOCK can be granted, be considered when determining whether the BLOCK can be granted,
and the server need not prevent I/O operations that violate the and the server need not prevent I/O operations that violate the
block mode. block mode.
The server MAY perform mandatory locking even if the The server MAY perform mandatory locking even if the
BLOCK_ADVISORY bit is set. BLOCK_ADVISORY bit is set.
SSH_FXF_ACCESS_NOFOLLOW SSH_FXF_NOFOLLOW
If the final component of the path is a symlink, then the open If the final component of the path is a symlink, then the open
MUST fail, and the error SSH_FX_LINK_LOOP MUST be returned. MUST fail, and the error SSH_FX_LINK_LOOP MUST be returned.
SSH_FXF_ACCESS_DELETE_ON_CLOSE SSH_FXF_DELETE_ON_CLOSE
The file should be deleted when the last handle to it is closed. The file should be deleted when the last handle to it is closed.
(The last handle may not be an sftp-handle.) This MAY be emulated (The last handle may not be an sftp-handle.) This MAY be emulated
by a server if the OS doesn't support it by deleting the file when by a server if the OS doesn't support it by deleting the file when
this handle is closed. this handle is closed.
It is implementation specific whether the directory entry is It is implementation specific whether the directory entry is
removed immediately or when the handle is closed. removed immediately or when the handle is closed.
SSH_FXF_ACCESS_AUDIT_ALARM_INFO
The client wishes the server to enable any privileges or extra
capabilities that the user may have in to allow the reading and
writing of AUDIT or ALARM access control entries.
SSH_FXF_ACCESS_BACKUP
The client wishes the server to enable any privileges or extra
capabilities that the user may have in order to bypass normal
access checks for the purpose of backing up or restoring files.
SSH_FXF_BACKUP_STREAM
This bit indicates that the client wishes to read or write a
backup stream. A backup stream is a system dependent structured
data stream that encodes all the information that must be
preserved in order to restore the file from backup medium.
The only well defined use for backup stream data read in this
fashion is to write it to the same server to a file also opened
using the BACKUP_STREAM flag. However, if the server has a well
defined backup stream format, their may be other uses for this
data outside the scope of this protocol.
ACCESS_OVERRIDE_OWNER
This bit indicates that the client wishes the server to enable any
privileges or extra capabilities that the user may have in order
to gain access to the file with WRITE_OWNER permission.
This bit MUST always be specified in combination with
ACE4_WRITE_OWNER.
The 'attrs' field specifies the initial attributes for the file. The 'attrs' field specifies the initial attributes for the file.
Default values MUST be supplied by the server for those attributes Default values MUST be supplied by the server for those attributes
that are not specified. See Section ''File Attributes'' for more that are not specified. See Section ''File Attributes'' for more
information. information.
The 'attrs' field is ignored if an existing file is opened. The 'attrs' field is ignored if an existing file is opened.
The following table is provided to assist in mapping POSIX semantics The following table is provided to assist in mapping POSIX semantics
to equivalent SFTP file open parameters: to equivalent SFTP file open parameters:
O_RDONLY O_RDONLY
skipping to change at page 31, line 19 skipping to change at page 35, line 4
to equivalent SFTP file open parameters: to equivalent SFTP file open parameters:
O_RDONLY O_RDONLY
desired-access = READ_DATA|READ_ATTRIBUTES desired-access = READ_DATA|READ_ATTRIBUTES
O_WRONLY O_WRONLY
desired-access = WRITE_DATA|WRITE_ATTRIBUTES desired-access = WRITE_DATA|WRITE_ATTRIBUTES
O_RDWR O_RDWR
desired-access = READ_DATA|READ_ATTRIBUTES|WRITE_DATA| desired-access = READ_DATA|READ_ATTRIBUTES|WRITE_DATA|
WRITE_ATTRIBUTES WRITE_ATTRIBUTES
O_APPEND O_APPEND
desired-access = WRITE_DATA|WRITE_ATTRIBUTES|APPEND_DATA desired-access = WRITE_DATA|WRITE_ATTRIBUTES|APPEND_DATA
flags = SSH_FXF_ACCESS_APPEND_DATA and or flags = SSH_FXF_APPEND_DATA and or SSH_FXF_APPEND_DATA_ATOMIC
SSH_FXF_ACCESS_APPEND_DATA_ATOMIC
O_CREAT O_CREAT
flags = SSH_FXF_OPEN_OR_CREATE flags = SSH_FXF_OPEN_OR_CREATE
O_TRUNC O_TRUNC
flags = SSH_FXF_TRUNCATE_EXISTING flags = SSH_FXF_TRUNCATE_EXISTING
O_TRUNC|O_CREATE O_TRUNC|O_CREATE
flags = SSH_FXF_CREATE_TRUNCATE flags = SSH_FXF_CREATE_TRUNCATE
skipping to change at page 33, line 4 skipping to change at page 36, line 29
8.2.1. Reading Files 8.2.1. Reading Files
The following request can be used to read file data: The following request can be used to read file data:
byte SSH_FXP_READ byte SSH_FXP_READ
uint32 request-id uint32 request-id
string handle string handle
uint64 offset uint64 offset
uint32 length uint32 length
handle handle
'handle' is an open file handle returned by SSH_FXP_OPEN. If 'handle' is an open file handle returned by SSH_FXP_OPEN. If
'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST
return SSH_FX_INVALID_HANDLE. return SSH_FX_INVALID_HANDLE.
offset offset
The offset (in bytes) relative to the beginning of the file that The offset (in bytes) relative to the beginning of the file that
the read MUST start at. This field is ignored if the read MUST start at. This field is ignored if
SSH_FXF_ACCESS_TEXT_MODE was specified during the open. SSH_FXF_TEXT_MODE was specified during the open.
length length
'length' is the maximum number of bytes to read. 'length' is the maximum number of bytes to read.
The server MUST not respond with more data than is specified by The server MUST not respond with more data than is specified by
the 'length' parameter. However, the server MAY respond with less the 'length' parameter. However, the server MAY respond with less
data if EOF is reached, an error is encountered, or the servers data if EOF is reached, an error is encountered, or the servers
internal buffers can not handle such a large request. internal buffers can not handle such a large request.
If the server specified a non-zero 'max-read-size' in its If the server specified a non-zero 'max-read-size' in its
skipping to change at page 34, line 23 skipping to change at page 37, line 47
string data string data
handle handle
'handle' is an open file handle returned by SSH_FXP_OPEN. If 'handle' is an open file handle returned by SSH_FXP_OPEN. If
'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST 'handle' is not a handle returned by SSH_FXP_OPEN, the server MUST
return SSH_FX_INVALID_HANDLE. return SSH_FX_INVALID_HANDLE.
offset offset
The offset (in bytes) relative to the beginning of the file that The offset (in bytes) relative to the beginning of the file that
the write MUST start at. This field is ignored if the write MUST start at. This field is ignored if
SSH_FXF_ACCESS_TEXT_MODE was specified during the open. SSH_FXF_TEXT_MODE was specified during the open.
The write will extend the file if writing beyond the end of the The write will extend the file if writing beyond the end of the
file. It is legal to write to an offset that extends beyond the file. It is legal to write to an offset that extends beyond the
end of the file; the semantics are to write the byte value 0x00 end of the file; the semantics are to write the byte value 0x00
from the end of the file to the specified offset and then the from the end of the file to the specified offset and then the
data. On most operating systems, such writes do not allocate disk data. On most operating systems, such writes do not allocate disk
space but instead create a sparse file. space but instead create a sparse file.
data data
The data to write to the file. The data to write to the file.
skipping to change at page 35, line 5 skipping to change at page 38, line 29
The following request can be used to remove a file: The following request can be used to remove a file:
byte SSH_FXP_REMOVE byte SSH_FXP_REMOVE
uint32 request-id uint32 request-id
string filename [UTF-8] string filename [UTF-8]
filename filename
'filename' is the name of the file to be removed. See Section 'filename' is the name of the file to be removed. See Section
'File Names' for more information. 'File Names' for more information.
If 'filename' is a symbolic link, the link is removed, not the
file it points to.
This request cannot be used to remove directories. The server This request cannot be used to remove directories. The server
MUST return SSH_FX_FILE_IS_A_DIRECTORY in this case. MUST return SSH_FX_FILE_IS_A_DIRECTORY in this case.
The server will respond to this request with a SSH_FXP_STATUS The server will respond to this request with a SSH_FXP_STATUS
message. message.
Files (and directories) can be renamed using the SSH_FXP_RENAME Files (and directories) can be renamed using the SSH_FXP_RENAME
message. message.
byte SSH_FXP_RENAME byte SSH_FXP_RENAME
skipping to change at page 40, line 25 skipping to change at page 44, line 13
handle is a directory handle. handle is a directory handle.
offset offset
Beginning of the byte-range to lock. Beginning of the byte-range to lock.
length length
Number of bytes in the range to lock. The special value 0 means Number of bytes in the range to lock. The special value 0 means
lock from 'offset' to the end of the file. lock from 'offset' to the end of the file.
uLockMask uLockMask
A bit mask of SSH_FXF_ACCESS_BLOCK_* values; the meanings are A bit mask of SSH_FXF_BLOCK_* values; the meanings are described
described in Section 8.1.1.3. in Section 8.1.1.3.
SSH_FXP_UNBLOCK removes a previously acquired byte-range lock on the SSH_FXP_UNBLOCK removes a previously acquired byte-range lock on the
specified handle. specified handle.
The result is a SSH_FXP_STATUS return. The result is a SSH_FXP_STATUS return.
byte SSH_FXP_UNBLOCK byte SSH_FXP_UNBLOCK
uint32 request-id uint32 request-id
string handle string handle
uint64 offset uint64 offset
skipping to change at page 41, line 31 skipping to change at page 45, line 20
SSH_FXP_REALPATH_NO_CHECK 0x00000001 SSH_FXP_REALPATH_NO_CHECK 0x00000001
SSH_FXP_REALPATH_STAT_IF 0x00000002 SSH_FXP_REALPATH_STAT_IF 0x00000002
SSH_FXP_REALPATH_STAT_ALWAYS 0x00000003 SSH_FXP_REALPATH_STAT_ALWAYS 0x00000003
This field is optional, and if it is not present in the packet, it This field is optional, and if it is not present in the packet, it
is assumed to be SSH_FXP_REALPATH_NO_CHECK. is assumed to be SSH_FXP_REALPATH_NO_CHECK.
If SSH_FXP_REALPATH_NO_CHECK is specified, the server MUST NOT If SSH_FXP_REALPATH_NO_CHECK is specified, the server MUST NOT
fail the request if the path does not exist, is hidden, or the fail the request if the path does not exist, is hidden, or the
user does not have access to the path or some component thereof. user does not have access to the path or some component thereof.
However, the path MAY NOT be completely resolved to it's component In addition, the path MUST NOT resolve symbolic links. This
form. For example, symlinks may not be followed in this case. allows paths to be composed for the SSH_FXP_REMOVE command to
remove symbolic links.
The server MAY fail the request if the path is not syntactically The server MAY fail the request if the path is not syntactically
valid, or for other reasons. valid, or for other reasons.
If SSH_FXP_REALPATH_STAT_IF is specified, the server MUST stat the If SSH_FXP_REALPATH_STAT_IF is specified, the server MUST stat the
path if it exists and is accessible to the client. However, if path if it exists and is accessible to the client. However, if
the path does not exist, isn't visible, or isn't accessible, the the path does not exist, isn't visible, or isn't accessible, the
server MUST NOT fail the request. If the stat failed, the file server MUST NOT fail the request. If the stat failed, the file
type will be SSH_FILEXFER_TYPE_UNKNOWN. If the client needs to type will be SSH_FILEXFER_TYPE_UNKNOWN. If the client needs to
distinguish between files that are actually distinguish between files that are actually
SSH_FILEXFER_TYPE_UNKNOWN and paths that don't exist, it will have SSH_FILEXFER_TYPE_UNKNOWN and paths that don't exist, it will have
skipping to change at page 49, line 43 skipping to change at page 53, line 15
filename filename
A file name being returned (for SSH_FXP_READDIR, it will be a A file name being returned (for SSH_FXP_READDIR, it will be a
relative name within the directory, without any path components; relative name within the directory, without any path components;
for SSH_FXP_REALPATH it will be an absolute path name.) for SSH_FXP_REALPATH it will be an absolute path name.)
attrs attrs
The attributes of the file as described in Section ''File The attributes of the file as described in Section ''File
Attributes''. Attributes''.
end-of-list end-of-list
This field is optional. If present in the packet, it MUST be If this field is present and true, there are no more entries to be
true, and indicates that there are no more entries to be read. read.
This can save the client a round trip to determine if there are
more entries to be read.
9.5. Attrs Response 9.5. Attrs Response
The SSH_FXP_ATTRS response has the following format: The SSH_FXP_ATTRS response has the following format:
byte SSH_FXP_ATTRS byte SSH_FXP_ATTRS
uint32 request-id uint32 request-id
ATTRS attrs ATTRS attrs
attrs attrs
skipping to change at page 50, line 32 skipping to change at page 53, line 45
byte SSH_FXP_EXTENDED byte SSH_FXP_EXTENDED
uint32 request-id uint32 request-id
string extended-request string extended-request
... any request-specific data ... ... any request-specific data ...
request-id request-id
Identifier to be returned from the server with the response. Identifier to be returned from the server with the response.
extended-request extended-request
A string naming the extension, following the the DNS extensibility A string naming the extension, following the the DNS extensibility
naming convention outlined in [I-D.ietf-secsh-architecture], or naming convention outlined in [RFC4251], or defined by IETF
defined by IETF consensus. consensus.
request-specific data request-specific data
The rest of the request is defined by the extension; servers The rest of the request is defined by the extension; servers
SHOULD NOT attempt to interpret it if they do not recognize the SHOULD NOT attempt to interpret it if they do not recognize the
'extended-request' name. 'extended-request' name.
The server may respond to such requests using any of the response The server may respond to such requests using any of the response
packets defined in Section ''Responses from the Server to the packets defined in Section ''Responses from the Server to the
Client''. Additionally, the server may also respond with a Client''. Additionally, the server may also respond with a
SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does SSH_FXP_EXTENDED_REPLY packet, as defined below. If the server does
skipping to change at page 52, line 10 skipping to change at page 55, line 26
features. Such security issues are left to the underlying transport features. Such security issues are left to the underlying transport
protocol, except to note that if this is not the case, an attacker protocol, except to note that if this is not the case, an attacker
could manipulate files on the server at will and thus wholly could manipulate files on the server at will and thus wholly
compromise the server. compromise the server.
This protocol provides file system access to arbitrary files on the This protocol provides file system access to arbitrary files on the
server (constrained only by the server implementation). It is the server (constrained only by the server implementation). It is the
responsibility of the server implementation to enforce any access responsibility of the server implementation to enforce any access
controls that may be required to limit the access allowed for any controls that may be required to limit the access allowed for any
particular user (the user being authenticated externally to this particular user (the user being authenticated externally to this
protocol, typically using [I-D.ietf-secsh-userauth]. protocol, typically using [RFC4252].
Extreme care must be used when interpreting file handle strings. In Extreme care must be used when interpreting file handle strings. In
particular, care must be taken that a file handle string is valid in particular, care must be taken that a file handle string is valid in
the context of a given 'file-share' session. For example, the 'file- the context of a given 'file-share' session. For example, the 'file-
share' server daemon may have files which it has opened for its own share' server daemon may have files which it has opened for its own
purposes, and the client must not be able to access these files by purposes, and the client must not be able to access these files by
specifying an arbitrary file handle string. specifying an arbitrary file handle string.
The permission field of the attrib structure (Section 7.6) may The permission field of the attrib structure (Section 7.6) may
include the SUID, SGID, and SVTX (sticky) bits. Clients should use include the SUID, SGID, and SVTX (sticky) bits. Clients should use
skipping to change at page 53, line 24 skipping to change at page 56, line 40
RFC EDITOR: END PLEASE REMOVE ENTIRE SECTION BEFORE PUBLISHING RFC EDITOR: END PLEASE REMOVE ENTIRE SECTION BEFORE PUBLISHING
14. References 14. References
14.1. Normative References 14.1. Normative References
[RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., [RFC3010] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R.,
Beame, C., Eisler, M., and D. Noveck, "NFS version 4 Beame, C., Eisler, M., and D. Noveck, "NFS version 4
Protocol", RFC 3010, December 2000. Protocol", RFC 3010, December 2000.
[I-D.ietf-secsh-architecture] [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Ylonen, T. and C. Lonvick, "SSH Protocol Architecture", Protocol Architecture", RFC 4251, January 2006.
draft-ietf-secsh-architecture-22 (work in progress),
March 2005.
[I-D.ietf-secsh-transport] [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Lonvick, C., "SSH Transport Layer Protocol", Transport Layer Protocol", RFC 4253, January 2006.
draft-ietf-secsh-transport-24 (work in progress),
March 2005.
[I-D.ietf-secsh-connect] [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Lonvick, C. and T. Ylonen, "SSH Connection Protocol", Connection Protocol", RFC 4254, January 2006.
draft-ietf-secsh-connect-25 (work in progress),
March 2005.
[IEEE.1003-1.1996] [IEEE.1003-1.1996]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Information Technology - Portable Operating System "Information Technology - Portable Operating System
Interface (POSIX) - Part 1: System Application Program Interface (POSIX) - Part 1: System Application Program
Interface (API) [C Language]", IEEE Standard 1003.2, 1996. Interface (API) [C Language]", IEEE Standard 1003.2, 1996.
14.2. Informative References 14.2. Informative References
[RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet [RFC1521] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
Mail Extensions) Part One: Mechanisms for Specifying and Mail Extensions) Part One: Mechanisms for Specifying and
Describing the Format of Internet Message Bodies", Describing the Format of Internet Message Bodies",
RFC 1521, September 1993. RFC 1521, September 1993.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[I-D.ietf-secsh-userauth] [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
Lonvick, C. and T. Ylonen, "SSH Authentication Protocol", Authentication Protocol", RFC 4252, January 2006.
draft-ietf-secsh-userauth-27 (work in progress),
March 2005.
Trademark notice Trademark notice
"ssh" is a registered trademark in the United States and/or other "ssh" is a registered trademark in the United States and/or other
countries. countries.
Authors' Addresses Authors' Addresses
Joseph Galbraith Joseph Galbraith
VanDyke Software VanDyke Software
skipping to change at page 56, line 41 skipping to change at page 59, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 61 change blocks. 
161 lines changed or deleted 298 lines changed or added

This html diff was produced by rfcdiff 1.28, available from http://www.levkowetz.com/ietf/tools/rfcdiff/