As per Relevance of the word standards, we have this rfc below:
Network Working Group G.
Request for Commments: 2349 Bay
Updates: 1350 A.
Obsoletes: 1784 Hewlett Packard Co
Category: Standards Track May 1998
TFTP Timeout Interval and Transfer Size
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 two TFTP options. The first allows the
and server to negotiate the Timeout Interval. The second allows
side receiving the file to determine the ultimate size of
transfer before it begins. The TFTP Option Extension mechanism
described in [2].
Timeout Interval Option
The TFTP Read Request or Write Request packet is modified to
the timeout option as follows
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| opc |filename| 0 | mode | 0 | timeout| 0 | #secs | 0 |
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
The opcode field contains either a 1, for Read Requests, or 2,
for Write Requests, as defined in [1].
Malkin & Harkin Standards Track [Page 1]
RFC 2349 TFTP Timeout Interval and Transfer Size Options May 1998
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
The Timeout Interval option, "timeout" (case in-sensitive).
This is a NULL-terminated field
#
The number of seconds to wait before retransmitting,
in ASCII. Valid values range between "1" and "255" seconds
inclusive. This is a NULL-terminated field
For example
+-------+--------+---+--------+---+--------+---+-------+---+
| 1 | foobar | 0 | octet | 0 | timeout| 0 | 1 | 0 |
+-------+--------+---+--------+---+--------+---+-------+---+
is a Read Request, for the file named "foobar", in octet (binary
transfer mode, with a timeout interval of 1 second
If the server is willing to accept the timeout option, it sends
Option Acknowledgment (OACK) to the client. The specified
value must match the value specified by the client
Transfer Size Option
The TFTP Read Request or Write Request packet is modified to
the tsize option as follows
+-------+---~~---+---+---~~---+---+---~~---+---+---~~---+---+
| opc |filename| 0 | mode | 0 | tsize | 0 | size | 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
Malkin & Harkin Standards Track [Page 2]
RFC 2349 TFTP Timeout Interval and Transfer Size Options May 1998
The mode of the file transfer: "netascii", "octet", or "mail",
as defined in [1]. This is a NULL-terminated field
The Transfer Size option, "tsize" (case in-sensitive). This
a NULL-terminated field
The size of the file to be transfered. This is a NULL
terminated field
For example
+-------+--------+---+--------+---+--------+---+--------+---+
| 2 | foobar | 0 | octet | 0 | tsize | 0 | 673312 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+
is a Write Request, with the 673312-octet file named "foobar",
octet (binary) transfer mode
In Read Request packets, a size of "0" is specified in the
and the size of the file, in octets, is returned in the OACK. If
file is too large for the client to handle, it may abort the
with an Error packet (error code 3). In Write Request packets,
size of the file, in octets, is specified in the request and
back in the OACK. If the file is too large for the server to handle
it may abort the transfer with an Error packet (error code 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 92.
[2] Malkin, G., and A. Harkin, "TFTP Option Extension", RFC 2347,
May 1998.
Malkin & Harkin Standards Track [Page 3]
RFC 2349 TFTP Timeout Interval and Transfer Size Options 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 4]
RFC 2349 TFTP Timeout Interval and Transfer Size Options 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 5]
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
