Text 392, 812 rader
Skriven 2005-06-29 07:02:58 av Scott Little
Ärende: 2 FRL-1006.001 RC1
==========================
| | |-------------+----------+--------+--------|
| | |Got other |Report |RxDone |Failure |
| | |known frame |unexpected| | |
| | | |frame | | |
| | |-------------+----------+--------+--------|
| | |Got unknown |ignore |RxWaitF |OK |
| | |frame | | | |
|--------+-------------+-------------+----------+--------+--------|
|RxAccF |Decide how to|Accept from |Report |RxReceD |OK |
| |accept |beginning |receiving | | |
| |Incoming File| |file | | |
| | |-------------+----------+--------+--------|
| | |Accept from |Send M_GET|RxReceD |OK |
| | |offset (we do|Report | | |
| | |already have |receiving | | |
| | |a part of |file, | | |
| | |file) |requested | | |
| | | |offest | | |
| | |-------------+----------+--------+--------|
| | |Accept later |Send |RxWaitF |OK |
| | |(or failed to|M_SKIP | | |
| | |create file) |Report we | | |
| | | |will | | |
| | | |accept | | |
| | | |file | | |
| | | |later, not| | |
| | | |in current| | |
| | | |session | | |
| | |-------------+----------+--------+--------|
| | |Refuse |Send M_GOT|RxWaitF |OK |
| | |(delete on |Report we | | |
| | |remote) |do not | | |
| | | |accept | | |
| | | |file | | |
|--------+-------------+-------------+----------+--------+--------|
|RxReceD |Get a frame |Didn't got a |none |RxReceD |OK |
| |from Input |complete | | | |
| |Buffer |frame yet | | | |
| | |-------------+----------+--------+--------|
| | |Got Data |none |RxWriteD|continue|
| | |frame | | | |
| | |-------------+----------+--------+--------|
| | |Got M_ERR |Report |RxDone |Failure |
| | | |Error | | |
| | |-------------+----------+--------+--------|
| | |Got M_GET / |Add frame |RxReceD |OK |
| | |M_GOT / |to The | | |
| | |M_SKIP |Queue | | |
| | |-------------+----------+--------+--------|
| | |Got M_NUL |Log |RxReceD |OK |
| | |-------------+----------+--------+--------|
| | |Got M_FILE |Report |RxAccF |Continue|
| | | |partially | | |
| | | |received | | |
| | | |file | | |
| | |-------------+----------+--------+--------|
| | |Got other |Report |RxDone |Failure |
| | |known frame |unexpected| | |
| | | |frame | | |
| | |-------------+----------+--------+--------|
| | |Got unknown |ignore |RxReceD |OK |
| | |frame | | | |
|--------+-------------+-------------+----------+--------+--------|
|RxWriteD|Write data to|Write Failed |Report |RxDone |Failure |
| |file | |error | | |
| | |-------------+----------+--------+--------|
| | |File Pos > |Report |RxDone |Failure |
| | |Reported |write | | |
| | | |beyond EOF| | |
| | |-------------+----------+--------+--------|
| | |File Pos = |Close File|RxWaitF |OK |
| | |Reported |Send M_GOT| | |
| | | |Report | | |
| | | |File | | |
| | | |Received | | |
| | |-------------+----------+--------+--------|
| | |File Pos < |none |RxReceD |OK |
| | |Reported | | | |
|--------+-------------+-------------+----------+--------+--------|
|RxEOB |Get a frame |Didn't get a |none |RxEOB |OK |
| |from Input |complete | | | |
| |Buffer |frame yet or | | | |
| | |TxState is | | | |
| | |not TxDone | | | |
| | |-------------+----------+--------+--------|
| | |Got M_ERR |Report |RxDone |Failure |
| | | |Error | | |
| | |-------------+----------+--------+--------|
| | |Got M_GET / |Add frame |RxEOB |OK |
| | |M_GOT / |to The | | |
| | |M_SKIP |Queue | | |
| | |-------------+----------+--------+--------|
| | |Got M_NUL |Log |RxEOB |OK |
| | |-------------+----------+--------+--------|
| | |Got other |Report |RxDone |Failure |
| | |known frame |unexpected| | |
| | |or data frame|frame | | |
| | |-------------+----------+--------+--------|
| | |Got unknown |ignore |RxEOB |OK |
| | |frame | | | |
|--------+-------------+-------------+----------+--------+--------|
|RxDone |none |none |none |RxDone |OK |
+-----------------------------------------------------------------+
We define the list called "PendingFiles". After we put the last
byte of file into output buffer, we cannot yet consider the file as
being successfully transmitted, thus we have to add the file to
this list and then look for corresponding incoming M_GET / M_GOT /
M_SKIP frames to remove the file from the list and decide whether
the file was indeed received by remote or remote will accept this
file later, or something else. After we have sent M_EOB frame, we
must wait until PendingFiles list gets empty before disconnecting.
If the connection accidentally breaks, all the files left in
PendingFiles are considered unsent and will be re-transmitted in
the next session. If the connection breaks when the remote did
actually receive the file (but the corresponded confirmation frame
(M_GOT) didn't came back to us) and we are resending this file
again in the next session, remote may get two copies of the same
file (file dupe). Binkp allows to reduce or totally suppress such
dupes (at a cost of performance, of course), see Non-Reliable mode
and "No Dupes" protocol extension (to be found in a separate
document at a later date).
Table 5: Transmit Routine
+-----------------------------------------------------------------+
|TxState|Predicate(s)|Condition(s) |Actions(s) |Next |Return |
|-------+------------+--------------+------------+-------+--------|
|TxGNF |Open next |File opened OK|Send M_FILE |TxTryR |continue|
| |file from | |Report | | |
| |outgoing | |sending file| | |
| |queue |--------------+------------+-------+--------|
| | |Failed to open|Report |TxDone |Failure |
| | |file |failure | | |
| | |--------------+------------+-------+--------|
| | |No more files |Send M_EOB |TxWLA |continue|
| | | |Report end | | |
| | | |of batch | | |
|-------+------------+--------------+------------+-------+--------|
|TxTryR |Check |TheQueue is |none |TxReadS|continue|
| |TheQueue |empty | | | |
| | |--------------+--------------------+--------|
| | |TheQueue is |call ProcessTheQueue|continue|
| | |not empty | | |
|-------+------------+--------------+--------------------+--------|
|TxReadS|Read data |Read failed |Report Error|TxDone |Failure |
| |block from |--------------+------------+-------+--------|
| |file |Read OK, |Send data |TxGNF |OK |
| | |Reached EOF |block frame | | |
| | | |Close | | |
| | | |current file| | |
| | | |Add current | | |
| | | |file to | | |
| | | |PendingFiles| | |
| | |--------------+------------+-------+--------|
| | |Read OK, not |Send data |TxTryR |OK |
| | |reached EOF |block frame | | |
|-------+------------+--------------+------------+-------+--------|
|TxWLA |Check |TheQueue is |none |TxDone |OK |
| |TheQueue |empty and | | | |
| | |RxState >= | | | |
| | |RxEOB | | | |
| | |--------------+------------+-------+--------|
| | |TheQueue is |none |TxWLA |OK |
| | |empty and | | | |
| | |RxState < | | | |
| | |RxEOB | | | |
| | |--------------+--------------------+--------|
| | |TheQueue is |call ProcessTheQueue|continue|
| | |not empty | | |
|-------+------------+--------------+--------------------+--------|
|TxDone |none |none |none |TxDone |OK |
+-----------------------------------------------------------------+
We define a list called KnownFiles. This list contains files that
can be requested by the remote using M_GET command. This list shall
at least contain all the files that are part of the PendingFiles
list.
Table 6: ProcessTheQueue routine
+-----------------------------------------------------------------+
| Predicate(s) | Condition(s) | Actions(s) |
|--------------------+--------------------+-----------------------|
| M_GET received | requested file is | Report unknown file |
| | not in the | |
| | KnownFiles list | |
|--------------------+--------------------+-----------------------|
| M_GET received for | Requested pos is | Close and finalize |
| a known file | FileSize | file. |
| | | Report that remote |
| | | refused file being |
| | | transmitted. |
| | | Set TxState to |
| | | TxGetNextFile. |
| |--------------------+-----------------------|
| | Requested pos is | Set file pointer to |
| | less than FileSize | requested pos. |
| | | Report that remote |
| | | requested offset. |
| | | Set TxState to |
| | | TxReadSend. |
| |--------------------+-----------------------|
| | Requested pos is | Ignore frame |
| | greater than | |
| | FileSize | |
|--------------------+--------------------+-----------------------|
| M_GOT file that is | none | Close and finalize |
| currently | | file |
| transmitting | | Report Remote refused |
| | | file being |
| | | transmitted |
| | | Set TxState to TxGNF |
|--------------------+--------------------+-----------------------|
| M_GOT file that is | File is in | Finalize file |
| not currently | PendingFiles list | Report file has been |
| transmitting | | sent |
| | | Remove file from the |
| | | PendingFiles list |
| |--------------------+-----------------------|
| | File is not in | Ignore frame |
| | PendingFiles | |
|--------------------+--------------------+-----------------------|
| M_SKIP file that | none | Close file (do not |
| is currently | | finalize, we will |
| transmitting | | send it later, not in |
| | | current session) |
| | | Report remote will |
| | | accept this file |
| | | later |
| | | Set TxState to TxGNF |
|--------------------+--------------------+-----------------------|
| M_SKIP file that | none | Report remote will |
| is not currently | | accept this file |
| transmitting | | later |
| | | Remove file from |
| | | PendingPiles, if |
| | | exists there |
+-----------------------------------------------------------------+
6.3 Session Termination
-----------------------
A session may be terminated in any of the following cases:
should be deemed aborted due to a fatal error.
should be deemed aborted due to non-fatal error typically
because of temporary lack of resources to proceed with the
session.
* all the files have been sent
* we have received M_EOB from the remote side (there are no
more files for us),
* we have received acknowledgements for all the files sent,
* we have received all the files re-requested by M_GET,
In this case, the session should be deemed successfully
completed.
A session termination itself is not a protocol stage. Mailer may
terminate a session at any time simply by issuing disconnect
(shutdown) command to the underlying transport layer, provided any
of the three conditions above are met. Mailer MUST take all proper
steps to provide a graceful shutdown of the transport layer, as it
is the transport layer that is responsible for all the data
transmitted by one side to be received by another before
disconnection, provided that shutdown of the transport layer
protocol was successful.
7. Recommended Protocol Extensions
----------------------------------
This section documents already implemented and proposed extensions
for the binkp/1.0. These extensions are purely optional and are
included here for the sake of compatibility with future
implementations.
Sides indicate supported protocol extensions by sending M_NUL
frame(s) with "OPT list_of_extensions" string, where
list_of_extensions is a space separated list of supported protocol
extensions. Whenever multiple M_NUL "OPT ..." frames are received
during the session, they SHOULD augment the current list of
extensions rather than replace it, unless specifically stated
otherwise for a particular option.
Mailer SHOULD NOT use any extension unless exactly sure that this
extension is supported by the remote. Mailer SHOULD use M_NUL "OPT
..." to indicate supported options. Other methods for indicating
supported extensions are allowed as long as the provide full
backwards compatibility.
7.1 Non-reliable Mode
---------------------
Non-reliable mode solves the problem with frequently aborted
connections when the sides can not successfully complete file
transfer before connection is broken. In this case, if the
transmitting side starts retransmission from offset 0, performance
degrades as by the time it receives M_GET from the remote, network
buffers are already full and by the time they are freed for
retransmission from requested offset, the connection might go down
again.
In order to circumvent this problem, a mailer can request the
remote to enter non-reliable mode by sending a M_NUL "OPT NR" frame
at any time during the session. After the remote acknowledges it by
sending an M_NUL "OPT NR" frame indicating that the option is
supported, both sides can assume that they are in non-reliable
mode.
When session is in non-reliable mode, the transmitting side may
send -1 for the offset value in M_FILE command. If it does so, it
should wait for the M_GET frame from the receiving side that
explicitly specifies file offset and start transmitting file data
from this offset. If the receiving side has indicated that it
supports non-reliable mode by sending M_NUL "OPT NR" frame, it must
recognize -1 as the file offset in M_FILE command as an explicit
request for the file offset and transmit an appropriate M_GET frame
as soon as possible.
It should be understood that this option degrades performance over
regular quality connections and it should be used only if
absolutely necessary.
7.2 Multiple Batch Mode
-----------------------
The session is in MB mode if both sides set "MB" flag in any of
M_NUL "OPT" packets exchanged before sending of M_OK/M_PWD packets.
In MB mode both sides restart session from RxDone into InitTransfer
state if there were any command packets sent or received by any
side between starting at InitTransfer and exchanging of M_EOB by
the sides (RxDone state). Otherwise, the session terminates as
usual.
Multiple batches mode is intended to handle WaZOO [FTS-0006] file
requests. If there were any WaZOO request files transferred in a
batch, sides MAY process them and send resulting files in the next
batch. Mailers MAY also generate list of files to send in
additional batches by other techniques -- including rescanning of
their spools or processing of other magic files transferred before
in the same session.
7.3 Multiple Passwords Mode
---------------------------
Multiple password mode allows to specify different passwords for
the different addresses of the remote.
Originating side identifies it's multipassword capabilities by
sending M_NUL "OPT MPWD" during session setup stage before sending
any M_ADR commands and waits for response from the answering side.
If answering side responds with the M_NUL "OPT MPWD", then it
supports multiply passwords too. Answering side also always
responds with it's own address list: M_ADR "adr1 adr2 adr3 ...". If
M_NUL "OPT MPWD" was not received prior to the first M_ADR command,
originating side should assume that the remote does not support
multiple password mode and send a single password (if any) for one
of the addresses of the remote.
If the MPWD option was indicated by the answering side, originating
side now may send M_PWD "pwd1 pwd2 pwd3 ..." with the number of
entries in space separated password list equivalent to the number
of addresses presented by the answering side. If there is no
password for a particular address, it must send '-' character as a
placeholder.
If the passwords presented are consistent, answering side must
acknowledge successful authentication by sending M_OK command.
7.4 Keyed Hashing Challenge-Response Authentication Mechanism
-------------------------------------------------------------
7.4.1 Overview
--------------
Challenge-Response Authentication Mechanism (CRAM) allows to avoid
passing cleartext, reusable passwords across the network. Since it
utilizes Keyed-Hashing digests [Keyed], it does not require
password to be stored in the clear on the Mailer's media, allowing
storage of the intermediate results which are known as "contexts".
Providing binkp-mailer is capable of [Keyed] digest calculation and
conversion of a byte array to a hexadecimal string and back,
implementation of CRAM is easily achieved by slightly modifying the
state machine.
7.4.2 Sequence of Steps
-----------------------
CRAM adds an additional synchronization step to binkp protocol. The
description of this step follows:
the Originating side, encoded to a hexadecimal string.
hexadecimal string, and a password to produce a digest by
applying the keyed Hashing algorithm from [Keyed] where the key
is the password and the digested text is the challenge data.
digest provided. If the digest is correct, the answering side
should consider the Originating side authenticated and responds
appropriately.
Similar technique is used in [IMAP-AUTH].
7.4.3 Generating and Transmitting Challenge Data
------------------------------------------------
Size and contents of challenge data are implementation-dependent,
but it SHOULD be no smaller than 8 bytes and no bigger than 64
bytes. Answering side SHOULD never generate the same challenge
data.
Instead of generating a long challenge data, answering side MAY use
a hash function to shorten it. In calculation of a challenge data
answering side MAY also use connection/line number, caller's IP
address, current time, etc.
Answering side transmits challenge data in the very first M_NUL
message, in the following way:
M_NUL "OPT [othropt] CRAM-lsthf-cde [othropt]"
lsthf is a list of aliases of supported hash functions, delimited
by slash characters. The list begins with alias of the most
preferred and ends with alias of the least preferred hash function.
Currently defined aliases are: MD5 for [MD5] and SHA1 for [SHA-1].
cde is the challenge data encoded to hexadecimal string, Lower-case
ASCII characters MUST be used for encoding, but Mailer SHOULD also
accept upper-case characters. The length of the string MUST be
even, and the leading zeros MUST NOT be trimmed.
7.4.4 Producing and Transmitting a Digest
-----------------------------------------
Originating side responds with:
M_PWD "CRAM-chosenhf-khde [othropt]"
where chosenhf is the alias of the chosen hash function and khde is
the keyed hashed digest, encoded to a hexadecimal string.
According to [IMAP-AUTH], keyed hashed digest is produced by
calculating
HASH((secret XOR opad), HASH((secret XOR ipad), challengedata))
where HASH is chosen hash function, ipad and opad are 36 hex and 5C
hex (as defined in [Keyed]) and secret is a password null-padded to
a length of 64 bytes. If the password is longer than 64 bytes, the
hash-function digest of the password is used as an input (16-byte
for [MD5] and 20-byte for [SHA-1]) to the keyed hashed calculation.
7.4.6 Indicating CRAM Capabilities
----------------------------------
Answering side MUST send
M_NUL "OPT [othropt] CRAM-lsthf-cde [othropt]"
as a very first M_NUL message if it supports CRAM.
It MAY send other non-M_NUL messages before though. Current
specification doesn't define any such non-M_NUL message, they are
reserved for protocol extension.
Originating side MUST be ready to receive non-M_NUL before M_NUL in
a CRAM session. Binkp state machine MUST ignore any received
message of unknown type in order to be compatible with future
extensions.
If an originating side receives a first message that is a M_ADR or
a M_NUL message that is not
M_NUL "OPT [othropt] CRAM-lsthf-cde [othropt]"
it MUST decide that the answering side doesn't support CRAM and MAY
either disconnect or use old password exchange. If the sides have
no any compatible hash function, originator may also either
disconnect or use old password exchange. If an originating side
decides to disconnect, it SHOULD send M_ERR frame with a proper
explanation before disconnecting.
When parsing M_NUL "OPT ..." string (coming from the answering
side), originating side first splits it by using space delimiter to
get a list of options, and then if an option begins with
"CRAM-lsthf-", takes the remaining substring as a
hexadecimal-encoded challenge data.
7.4.7 Example of Frame Exchange During CRAM Authentication
----------------------------------------------------------
(Password here is tanstaaftanstaaf)
Originating :
send M_NUL messages
and M_ADR
wait for first M_NUL message
Answering :
send M_NUL "OPT ND CRAM-SHA1/MD5-f0315b074d728d483d6887d0182fc328"
and other messages
wait for M_PWD
Originating :
M_PWD "CRAM-MD5-56be002162a4a15ba7a9064f0c93fd00"
Answering :
M_OK and continue session
7.4.8 Notes on Hash Function Algorithms
---------------------------------------
[MD5] and [SHA-1] are the most widely used cryptographic hash
functions. [MD5] has been shown to be vulnerable to collision
search attacks [Dobb]. This attack and other currently known
weaknesses of [MD5] do not compromise the use of [MD5] within CRAM
as specified in this document (see [Dobb]); however, [SHA-1]
appears to be a cryptographically stronger function. To this date,
[MD5] can be considered for use in CRAM for applications where the
superior performance of [MD5] is critical. In any case,
implementors and users need to be aware of possible cryptanalytic
developments regarding any of these cryptographic hash functions,
and the eventual need to replace the underlying hash function.
8. License
----------
You can implement binkp protocol in your software as long as you
agree to the following conditions:
other way. You shall include the author(s) of the protocol in
your copyright statement for the software.
versions. Binkp allows development of the new capabilities
without compromising interoperability with previous versions.
Therefore, it is important that future developments of the
protocol are not pursued in different directions by different
people. If you have any suggestions regarding future
developments of the protocol, make a reasonable effort to
contact the author(s), so that the development efforts can
coordinated in a way advantageous for everybody.
future binkp specifications, you shall reference to it as a
"binkp variation" or "binkp derived".
Remember that you may use, implement or utilize binkp, it's
description or any other associated texts or documentations at your
own risk, without any warranty, without even the implied warranty
of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
Binkp author: Dima Maloff.
9. Glossary
-----------
Many entries in this glossary are provided courtesy of Butterfly
Glossary of Internet and Data Communication terms and RFC-1983.
connection-oriented
Data communication method in which communication proceeds
through three well-defined phases: connection
establishment, data transfer, connection release. TCP is a
connection-oriented protocol.
data link layer
The OSI layer that is responsible for data transfer across
a single physical connection, or series of bridged
connections, between two Network entities.
flow control
A technique for ensuring that a transmitting entity does
not overwhelm a receiving entity.
HDLC
(High level Data Link Control). Popular ISO standard
bit-oriented, data link layer protocol derived from SDLC.
HDLC specifies an encapsulated method of data on
synchronous serial data links.
IP
(Internet Protocol). The Internet Protocol, defined in STD
5, RFC 791, is the network layer for the TCP/IP Protocol
Suite. It is a connectionless, best-effort packet switching
protocol.
network layer
Layer 3 of the OSI reference model. Layer 3 is the layer at
which routing, addressing and connection management take
place.
OSI (Open Systems Interconnection) Reference Model
A seven-layer structure designed to describe computer
network architectures and the way that data passes through
them. This model was developed by the ISO (International
Organization for Standardization) in 1978 to clearly define
the interfaces in multivendor networks, and to provide
users of those networks with conceptual guidelines in the
construction of such networks.
port
A port is a transport layer demultiplexing value. Each
application has a unique port identifier associated with
it.
physical layer
The OSI layer that provides the means to activate and use
physical connections for bit transmission. In plain terms,
the Physical Layer provides the procedures for transferring
a single bit across a Physical Media.
Quality of Service
(Also QoS). A measure of performance for a transmission
system that reflects its transmission quality and
availability of service.
reliable transmission
a type of transport service that:
* recovers from errors by retransmitting errored frames
* delivers frames in correct sequence (also known as
stream-oriented)
* usually is used in connection-oriented mode
session layer
Layer 5 of the OSI reference model. Coordinates session
activity between applications, including application-layer
error control, dialog control, and remote procedure calls.
sliding window flow control
Method of flow control in which a receiver gives
transmitter permission to transmit data until a window is
full. When the window is full, the transmitter must stop
transmitting until the receiver advertises a larger window.
socket
Software structure operating as a communications and point
within a network device.
TCP
Transmission Control Protocol. An Internet Standard
transport layer reliable protocol defined in STD 7, RFC
793. It is connection-oriented and stream-oriented.
TCP/IP protocol suite
Transmission Control Protocol over Internet Protocol. This
is a common shorthand which refers to the suite of
transport and application protocols which runs over IP.
transport layer
Layer 4 of the OSI reference model. The transport layer is
responsible for reliable network communication between end
nodes. It implements flow and error control and often uses
virtual circuits to ensure reliable data delivery.
unixtime
number of seconds elapsed since 00:00:00 UTC, Jan. 1, 1970.
10. References
--------------
[FTS-0001]
A Basic FidoNet(r) Technical Standard, Revision 16. Randy
Bush, Pacific Systems Group, September 30, 1995. FTS-0001.
[FTS-0006]
YOOHOO and YOOHOO/2U2. The netmail handshake used by
Opus-CBCS and other intelligent Fidonet mail handling
packages. Version 002, Vince Perriello. 30-Nov-1991.
FTS-0006.
[FSC-0039]
M.Howard, A type-2 packet extension proposal, FSC-0039
Version 4, 29-Sep-1990. FSC-0039.
[FSC-0045]
T.Henderson, Proposed new packet header, Version 1,
17-Apr-1990. FSC-0045.
[FSC-0048]
J.Vroonhof, Proposed type-2 packet extension, Version 2,
21-Oct-1990. FSC-0048.
[FSC-0081]
M.Staldal, A type-3 packet proposal, Version 1,
01-Mar-1995. FSC-0081.
[EMSI]
Joaquim H. Homrighausen, EMSI/IEMSI protocol definition.
May 3, 1991. FSC-0056.
[FTA-1006]
Key words to indicate requirement levels, Fidonet Technical
Standards Committee administrative. FTA-1006.
[Halsall95]
Data Communications, Computer Networks and Open Systems, F.
Halsall, 4th ed., Addison-Wesley, 1995, ISBN 0-201-42293-X.
[Dobb]
H. Dobbertin, "The Status of MD5 After a Recent Attack",
RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
[MD5]
Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[SHA-1]
NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
[Keyed]
Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for
Message Authentication", RFC 2104, February 1997.
[IMAP-AUTH]
Klensin, "IMAP/POP AUTHorize Extension for Simple
Challenge/Response", RFC 2195, September, 1997
[RFC822]
Standard for the format of ARPA Internet text messages. D.
Crocker. Aug-13-1982. RFC 822, STD0011.
[UTF8]
UTF-8, a transformation format of ISO 10646. F. Yergeau.
January 1998, RFC 2279.
[ISO10646]
ISO/IEC 10646-1:1993. International Standard -- Information
technology -- Universal Multiple-Octet Coded Character Set
(UCS) -- Part 1: Architecture and Basic Multilingual Plane.
Five amendments and a technical corrigendum have been
published up to now. UTF-8 is described in Annex R,
published as Amendment 2.
11. Acknowledgements
--------------------
This document is partially based on extracts from RFCs and FTSC
publications too numerous to be acknowledged individually.
The authors would like to thank Joaquim Homrighausen, Kim 'B'
Heino, Rune Johansen and many others for fruitful discussions and
suggestions regarding protocol design and specifications.
A. Author Contact Data
-----------------------
Dima Maloff
Fidonet: 2:5020/128
E-mail: maloff@corbina.net
WWW: http://www.corbina.net/~maloff/
Maxim Masiutin
Fidonet: 2:469/84
E-mail: max@ritlabs.com
WWW: http://www.ritlabs.com/
Nick Soveiko
Fidonet: 2:5030/23.101
E-mail: nsoveiko@doe.carleton.ca
WWW: http://www.doe.carleton.ca/~nsoveiko/
B. History
----------
Rev.1, 19990611:
First release
Rev.2, 19991008:
* Added new topic: "Definitions";
* clarified the following topics: "Frame Format",
"Protocol Commands and Their Arguments", "Keyed
Hashing Challenge-Response Authentication Mechanism";
* added "unixtime" item to Glossary topic;
* corrected links in References topic.
Rev.3, 20000731:
* Table 6 in section 6.2, File transfer stage has been
rewritten: TheListOfSendFiles replaced by PendingFiles
which was defined earlier. introduced definition of
KnownFiles list. new ProcessTheQueue routine w/respect
to handling M_GET command
* Section 5.2, File Name Issues was rewritten to clearly
define safe and unsafe characters in filenames.
* Section 5.3, Non-ASCII Characters was rewritten to
clarify Unicode usage.
* Expanded descriptions for M_NUL "TIME ...", M_NUL "TRF
...", added description of M_NUL "PHN ..." and M_NUL
"OPM ..." frames in section 5.4 Binkp Commands.
* IANA port number added to section 3, Protocol
Overview.
* M_GET description in section 5.4, Binkp Commands was
rewritten for clarity.
* M_BSY "RETRY ..." option documented.
* Minor edits throughout the document to improve
readability.
------ 20050708:
* Reassigned to FRL-1006.001
**********************************************************************
-- Scott Little [fidonet#3:712/848 / sysgod@sysgod.org]
--- GoldED+/W32 1.1.5-31012
* Origin: Cyberia: 100% Grade "A" mansteak baby. (3:712/848)
|