As per Relevance of the word acknowledge, we have this rfc below:
Network Working Group G.
Request for Commments: 2347 Bay
Updates: 1350 A.
Obsoletes: 1782 Hewlett Packard Co
Category: Standards Track May 1998
TFTP Option
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
The Trivial File Transfer Protocol [1] is a simple, lock-step,
transfer protocol which allows a client to get or put a file onto
remote host. This document describes a simple extension to TFTP
allow option negotiation prior to the file transfer
The option negotiation mechanism proposed in this document is
backward-compatible extension to the TFTP protocol. It allows
transfer options to be negotiated prior to the transfer using
mechanism which is consistent with TFTP's Request Packet format.
mechanism is kept simple by enforcing a request-respond-
sequence, similar to the lock-step approach taken by TFTP itself
While the option negotiation mechanism is general purpose, in
many types of options may be negotiated, it was created to
the Blocksize option defined in [2]. Additional options are
in [3].
Packet
TFTP options are appended to the Read Request and Write
packets. A new type of TFTP packet, the Option
(OACK), is used to acknowledge a client's option negotiation request
A new error code, 8, is hereby defined to indicate that a
Malkin & Harkin Standards Track [Page 1]
RFC 2347 TFTP Option Extension May 1998
should be terminated due to option negotiation
Options are appended to a TFTP Read Request or Write Request
as follows
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
| opc |filename| 0 | mode | 0 | opt1 | 0 | value1 | 0 | <
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+-->
>-------+---+---~~---+---+
< optN | 0 | valueN | 0 |
>-------+---+---~~---+---+
The opcode field contains either a 1, for Read Requests, or 2,
for Write Requests, as defined in [1].
The name of the file to be read or written, as defined in [1].
This is a NULL-terminated field
The mode of the file transfer: "netascii", "octet", or "mail",
as defined in [1]. This is a NULL-terminated field
opt
The first option, in case-insensitive ASCII (e.g., blksize).
This is a NULL-terminated field
value
The value associated with the first option, in case
insensitive ASCII. This is a NULL-terminated field
optN,
The final option/value pair. Each NULL-terminated field
specified in case-insensitive ASCII
The options and values are all NULL-terminated, in keeping with
original request format. If multiple options are to be negotiated
they are appended to each other. The order in which options
specified is not significant. The maximum size of a request
is 512 octets
The OACK packet has the following format
Malkin & Harkin Standards Track [Page 2]
RFC 2347 TFTP Option Extension May 1998
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| opc | opt1 | 0 | value1 | 0 | optN | 0 | valueN | 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
The opcode field contains a 6, for Option Acknowledgment
opt
The first option acknowledgment, copied from the
request
value
The acknowledged value associated with the first option.
and how this value may differ from the original request
detailed in the specification for the option
optN,
The final option/value acknowledgment pair
Negotiation
The client appends options at the end of the Read Request or
request packet, as shown above. Any number of options may
specified; however, an option may only be specified once. The
of the options is not significant
If the server supports option negotiation, and it recognizes one
more of the options specified in the request packet, the server
respond with an Options Acknowledgment (OACK). Each option
server recognizes, and accepts the value for, is included in
OACK. Some options may allow alternate values to be proposed,
this is an option specific feature. The server must not include
the OACK any option which had not been specifically requested by
client; that is, only the client may initiate option negotiation
Options which the server does not support should be omitted from
OACK; they should not cause an ERROR packet to be generated. If
value of a supported option is invalid, the specification for
option will indicate whether the server should simply omit the
from the OACK, respond with an alternate value, or send an
packet, with error code 8, to terminate the transfer
An option not acknowledged by the server must be ignored by
client and server as if it were never requested. If multiple
were requested, the client must use those options which
acknowledged by the server and must not use those options which
not acknowledged by the server
Malkin & Harkin Standards Track [Page 3]
RFC 2347 TFTP Option Extension May 1998
When the client appends options to the end of a Read Request packet
three possible responses may be returned by the server
OACK - acknowledge of Read Request and the options
DATA - acknowledge of Read Request, but not the options
ERROR - the request has been denied
When the client appends options to the end of a Write Request packet
three possible responses may be returned by the server
OACK - acknowledge of Write Request and the options
ACK - acknowledge of Write Request, but not the options
ERROR - the request has been denied
If a server implementation does not support option negotiation,
will likely ignore any options appended to the client's request.
this case, the server will return a DATA packet for a Read
and an ACK packet for a Write Request establishing normal TFTP
transfer. In the event that a server returns an error for a
which carries an option, the client may attempt to repeat the
without appending any options. This implementation option
handle servers which consider extraneous data in the request
to be erroneous
Depending on the original transfer request there are two ways for
client to confirm acceptance of a server's OACK. If the transfer
initiated with a Read Request, then an ACK (with the data
number set to 0) is sent by the client to confirm the values in
server's OACK packet. If the transfer was initiated with a
Request, then the client begins the transfer with the first
packet, using the negotiated values. If the client rejects the OACK
then it sends an ERROR packet, with error code 8, to the server
the transfer is terminated
Once a client acknowledges an OACK, with an appropriate non-
response, that client has agreed to use only the options and
returned by the server. Remember that the server cannot request
option; it can only respond to them. If the client receives an
containing an unrequested option, it should respond with an
packet, with error code 8, and terminate the transfer
Malkin & Harkin Standards Track [Page 4]
RFC 2347 TFTP Option Extension May 1998
Read
client
-------------------------------------------------------
|1|foofile|0|octet|0|blksize|0|1432|0| -->
<-- |6|blksize|0|1432|0|
|4|0| -->
<-- |3|1| 1432 octets of data |
|4|1| -->
<-- |3|2| 1432 octets of data |
|4|2| -->
<-- |3|3|<1432 octets of data |
|4|3| -->
Write
client
-------------------------------------------------------
|2|barfile|0|octet|0|blksize|0|2048|0| -->
<-- |6|blksize|0|2048|0|
|3|1| 2048 octets of data | -->
<-- |4|1|
|3|2| 2048 octets of data | -->
<-- |4|2|
|3|3|<2048 octets of data | -->
<-- |4|3|
Security
The basic TFTP protocol has no security mechanism. This is why
has no rename, delete, or file overwrite capabilities. This
does not add any security to TFTP; however, the specified
do not add any additional security risks
[1] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350,
October 1992.
[2] Malkin, G., and A. Harkin, "TFTP Blocksize Option", RFC 2348,
May 1998.
[3] Malkin, G., and A. Harkin, "TFTP Timeout Interval and
Size Options", RFC 2349, May 1998.
Malkin & Harkin Standards Track [Page 5]
RFC 2347 TFTP Option Extension May 1998
Authors'
Gary Scott
Bay
8 Federal
Billerica, MA 01821
Phone: (978) 916-4237
EMail: gmalkin@baynetworks.
Art
Internet Services
Information Networks
19420 Homestead Road MS 43
Cupertino, CA 95014
Phone: (408) 447-3755
EMail: ash@cup.hp.
Malkin & Harkin Standards Track [Page 6]
RFC 2347 TFTP Option Extension May 1998
Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Malkin & Harkin Standards Track [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
