diff -Nru /tmp/8fRmF1gy4s/dante-1.1.18/debian/changelog /tmp/urHUlwBEQ7/dante-1.1.18.dfsg/debian/changelog
--- /tmp/8fRmF1gy4s/dante-1.1.18/debian/changelog	2007-09-04 04:15:57.000000000 +0200
+++ /tmp/urHUlwBEQ7/dante-1.1.18.dfsg/debian/changelog	2007-09-04 04:15:57.000000000 +0200
@@ -1,3 +1,11 @@
+dante (1.1.18.dfsg-0.1) unstable; urgency=low
+
+  * Non-maintainer upload with maintainer approval.
+  * Remove non-free RFC 1928 and 1929 from the upstream tarball
+    (closes: #393361).
+
+ -- Julien Cristau <jcristau@debian.org>  Tue, 04 Sep 2007 04:11:23 +0200
+
 dante (1.1.18-2.1) unstable; urgency=high
 
   * Non-maintainer upload for RC bug.
diff -Nru /tmp/8fRmF1gy4s/dante-1.1.18/doc/rfc1928.txt /tmp/urHUlwBEQ7/dante-1.1.18.dfsg/doc/rfc1928.txt
--- /tmp/8fRmF1gy4s/dante-1.1.18/doc/rfc1928.txt	1999-04-22 18:48:11.000000000 +0200
+++ /tmp/urHUlwBEQ7/dante-1.1.18.dfsg/doc/rfc1928.txt	1970-01-01 01:00:00.000000000 +0100
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           M. Leech
-Request for Comments: 1928                    Bell-Northern Research Ltd
-Category: Standards Track                                       M. Ganis
-                                         International Business Machines
-                                                                  Y. Lee
-                                                  NEC Systems Laboratory
-                                                                R. Kuris
-                                                       Unify Corporation
-                                                               D. Koblas
-                                                  Independent Consultant
-                                                                L. Jones
-                                                 Hewlett-Packard Company
-                                                              March 1996
-
-
-                        SOCKS Protocol Version 5
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-Acknowledgments
-
-   This memo describes a protocol that is an evolution of the previous
-   version of the protocol, version 4 [1]. This new protocol stems from
-   active discussions and prototype implementations.  The key
-   contributors are: Marcus Leech: Bell-Northern Research, David Koblas:
-   Independent Consultant, Ying-Da Lee: NEC Systems Laboratory, LaMont
-   Jones: Hewlett-Packard Company, Ron Kuris: Unify Corporation, Matt
-   Ganis: International Business Machines.
-
-1.  Introduction
-
-   The use of network firewalls, systems that effectively isolate an
-   organizations internal network structure from an exterior network,
-   such as the INTERNET is becoming increasingly popular.  These
-   firewall systems typically act as application-layer gateways between
-   networks, usually offering controlled TELNET, FTP, and SMTP access.
-   With the emergence of more sophisticated application layer protocols
-   designed to facilitate global information discovery, there exists a
-   need to provide a general framework for these protocols to
-   transparently and securely traverse a firewall.
-
-
-
-
-
-Leech, et al                Standards Track                     [Page 1]
-
-RFC 1928                SOCKS Protocol Version 5              March 1996
-
-
-   There exists, also, a need for strong authentication of such
-   traversal in as fine-grained a manner as is practical. This
-   requirement stems from the realization that client-server
-   relationships emerge between the networks of various organizations,
-   and that such relationships need to be controlled and often strongly
-   authenticated.
-
-   The protocol described here is designed to provide a framework for
-   client-server applications in both the TCP and UDP domains to
-   conveniently and securely use the services of a network firewall.
-   The protocol is conceptually a "shim-layer" between the application
-   layer and the transport layer, and as such does not provide network-
-   layer gateway services, such as forwarding of ICMP messages.
-
-2.  Existing practice
-
-   There currently exists a protocol, SOCKS Version 4, that provides for
-   unsecured firewall traversal for TCP-based client-server
-   applications, including TELNET, FTP and the popular information-
-   discovery protocols such as HTTP, WAIS and GOPHER.
-
-   This new protocol extends the SOCKS Version 4 model to include UDP,
-   and extends the framework to include provisions for generalized
-   strong authentication schemes, and extends the addressing scheme to
-   encompass domain-name and V6 IP addresses.
-
-   The implementation of the SOCKS protocol typically involves the
-   recompilation or relinking of TCP-based client applications to use
-   the appropriate encapsulation routines in the SOCKS library.
-
-Note:
-
-   Unless otherwise noted, the decimal numbers appearing in packet-
-   format diagrams represent the length of the corresponding field, in
-   octets.  Where a given octet must take on a specific value, the
-   syntax X'hh' is used to denote the value of the single octet in that
-   field. When the word 'Variable' is used, it indicates that the
-   corresponding field has a variable length defined either by an
-   associated (one or two octet) length field, or by a data type field.
-
-3.  Procedure for TCP-based clients
-
-   When a TCP-based client wishes to establish a connection to an object
-   that is reachable only via a firewall (such determination is left up
-   to the implementation), it must open a TCP connection to the
-   appropriate SOCKS port on the SOCKS server system.  The SOCKS service
-   is conventionally located on TCP port 1080.  If the connection
-   request succeeds, the client enters a negotiation for the
-
-
-
-Leech, et al                Standards Track                     [Page 2]
-
-RFC 1928                SOCKS Protocol Version 5              March 1996
-
-
-   authentication method to be used, authenticates with the chosen
-   method, then sends a relay request.  The SOCKS server evaluates the
-   request, and either establishes the appropriate connection or denies
-   it.
-
-   Unless otherwise noted, the decimal numbers appearing in packet-
-   format diagrams represent the length of the corresponding field, in
-   octets.  Where a given octet must take on a specific value, the
-   syntax X'hh' is used to denote the value of the single octet in that
-   field. When the word 'Variable' is used, it indicates that the
-   corresponding field has a variable length defined either by an
-   associated (one or two octet) length field, or by a data type field.
-
-   The client connects to the server, and sends a version
-   identifier/method selection message:
-
-                   +----+----------+----------+
-                   |VER | NMETHODS | METHODS  |
-                   +----+----------+----------+
-                   | 1  |    1     | 1 to 255 |
-                   +----+----------+----------+
-
-   The VER field is set to X'05' for this version of the protocol.  The
-   NMETHODS field contains the number of method identifier octets that
-   appear in the METHODS field.
-
-   The server selects from one of the methods given in METHODS, and
-   sends a METHOD selection message:
-
-                         +----+--------+
-                         |VER | METHOD |
-                         +----+--------+
-                         | 1  |   1    |
-                         +----+--------+
-
-   If the selected METHOD is X'FF', none of the methods listed by the
-   client are acceptable, and the client MUST close the connection.
-
-   The values currently defined for METHOD are:
-
-          o  X'00' NO AUTHENTICATION REQUIRED
-          o  X'01' GSSAPI
-          o  X'02' USERNAME/PASSWORD
-          o  X'03' to X'7F' IANA ASSIGNED
-          o  X'80' to X'FE' RESERVED FOR PRIVATE METHODS
-          o  X'FF' NO ACCEPTABLE METHODS
-
-   The client and server then enter a method-specific sub-negotiation.
-
-
-
-Leech, et al                Standards Track                     [Page 3]
-
-RFC 1928                SOCKS Protocol Version 5              March 1996
-
-
-   Descriptions of the method-dependent sub-negotiations appear in
-   separate memos.
-
-   Developers of new METHOD support for this protocol should contact
-   IANA for a METHOD number.  The ASSIGNED NUMBERS document should be
-   referred to for a current list of METHOD numbers and their
-   corresponding protocols.
-
-   Compliant implementations MUST support GSSAPI and SHOULD support
-   USERNAME/PASSWORD authentication methods.
-
-4.  Requests
-
-   Once the method-dependent subnegotiation has completed, the client
-   sends the request details.  If the negotiated method includes
-   encapsulation for purposes of integrity checking and/or
-   confidentiality, these requests MUST be encapsulated in the method-
-   dependent encapsulation.
-
-   The SOCKS request is formed as follows:
-
-        +----+-----+-------+------+----------+----------+
-        |VER | CMD |  RSV  | ATYP | DST.ADDR | DST.PORT |
-        +----+-----+-------+------+----------+----------+
-        | 1  |  1  | X'00' |  1   | Variable |    2     |
-        +----+-----+-------+------+----------+----------+
-
-     Where:
-
-          o  VER    protocol version: X'05'
-          o  CMD
-             o  CONNECT X'01'
-             o  BIND X'02'
-             o  UDP ASSOCIATE X'03'
-          o  RSV    RESERVED
-          o  ATYP   address type of following address
-             o  IP V4 address: X'01'
-             o  DOMAINNAME: X'03'
-             o  IP V6 address: X'04'
-          o  DST.ADDR       desired destination address
-          o  DST.PORT desired destination port in network octet
-             order
-
-   The SOCKS server will typically evaluate the request based on source
-   and destination addresses, and return one or more reply messages, as
-   appropriate for the request type.
-
-
-
-
-
-Leech, et al                Standards Track                     [Page 4]
-
-RFC 1928                SOCKS Protocol Version 5              March 1996
-
-
-5.  Addressing
-
-   In an address field (DST.ADDR, BND.ADDR), the ATYP field specifies
-   the type of address contained within the field:
-
-          o  X'01'
-
-   the address is a version-4 IP address, with a length of 4 octets
-
-          o  X'03'
-
-   the address field contains a fully-qualified domain name.  The first
-   octet of the address field contains the number of octets of name that
-   follow, there is no terminating NUL octet.
-
-          o  X'04'
-
-   the address is a version-6 IP address, with a length of 16 octets.
-
-6.  Replies
-
-   The SOCKS request information is sent by the client as soon as it has
-   established a connection to the SOCKS server, and completed the
-   authentication negotiations.  The server evaluates the request, and
-   returns a reply formed as follows:
-
-        +----+-----+-------+------+----------+----------+
-        |VER | REP |  RSV  | ATYP | BND.ADDR | BND.PORT |
-        +----+-----+-------+------+----------+----------+
-        | 1  |  1  | X'00' |  1   | Variable |    2     |
-        +----+-----+-------+------+----------+----------+
-
-     Where:
-
-          o  VER    protocol version: X'05'
-          o  REP    Reply field:
-             o  X'00' succeeded
-             o  X'01' general SOCKS server failure
-             o  X'02' connection not allowed by ruleset
-             o  X'03' Network unreachable
-             o  X'04' Host unreachable
-             o  X'05' Connection refused
-             o  X'06' TTL expired
-             o  X'07' Command not supported
-             o  X'08' Address type not supported
-             o  X'09' to X'FF' unassigned
-          o  RSV    RESERVED
-          o  ATYP   address type of following address
-
-
-
-Leech, et al                Standards Track                     [Page 5]
-
-RFC 1928                SOCKS Protocol Version 5              March 1996
-
-
-             o  IP V4 address: X'01'
-             o  DOMAINNAME: X'03'
-             o  IP V6 address: X'04'
-          o  BND.ADDR       server bound address
-          o  BND.PORT       server bound port in network octet order
-
-   Fields marked RESERVED (RSV) must be set to X'00'.
-
-   If the chosen method includes encapsulation for purposes of
-   authentication, integrity and/or confidentiality, the replies are
-   encapsulated in the method-dependent encapsulation.
-
-CONNECT
-
-   In the reply to a CONNECT, BND.PORT contains the port number that the
-   server assigned to connect to the target host, while BND.ADDR
-   contains the associated IP address.  The supplied BND.ADDR is often
-   different from the IP address that the client uses to reach the SOCKS
-   server, since such servers are often multi-homed.  It is expected
-   that the SOCKS server will use DST.ADDR and DST.PORT, and the
-   client-side source address and port in evaluating the CONNECT
-   request.
-
-BIND
-
-   The BIND request is used in protocols which require the client to
-   accept connections from the server.  FTP is a well-known example,
-   which uses the primary client-to-server connection for commands and
-   status reports, but may use a server-to-client connection for
-   transferring data on demand (e.g. LS, GET, PUT).
-
-   It is expected that the client side of an application protocol will
-   use the BIND request only to establish secondary connections after a
-   primary connection is established using CONNECT.  In is expected that
-   a SOCKS server will use DST.ADDR and DST.PORT in evaluating the BIND
-   request.
-
-   Two replies are sent from the SOCKS server to the client during a
-   BIND operation.  The first is sent after the server creates and binds
-   a new socket.  The BND.PORT field contains the port number that the
-   SOCKS server assigned to listen for an incoming connection.  The
-   BND.ADDR field contains the associated IP address.  The client will
-   typically use these pieces of information to notify (via the primary
-   or control connection) the application server of the rendezvous
-   address.  The second reply occurs only after the anticipated incoming
-   connection succeeds or fails.
-
-
-
-
-
-Leech, et al                Standards Track                     [Page 6]
-
-RFC 1928                SOCKS Protocol Version 5              March 1996
-
-
-   In the second reply, the BND.PORT and BND.ADDR fields contain the
-   address and port number of the connecting host.
-
-UDP ASSOCIATE
-
-   The UDP ASSOCIATE request is used to establish an association within
-   the UDP relay process to handle UDP datagrams.  The DST.ADDR and
-   DST.PORT fields contain the address and port that the client expects
-   to use to send UDP datagrams on for the association.  The server MAY
-   use this information to limit access to the association.  If the
-   client is not in possesion of the information at the time of the UDP
-   ASSOCIATE, the client MUST use a port number and address of all
-   zeros.
-
-   A UDP association terminates when the TCP connection that the UDP
-   ASSOCIATE request arrived on terminates.
-
-   In the reply to a UDP ASSOCIATE request, the BND.PORT and BND.ADDR
-   fields indicate the port number/address where the client MUST send
-   UDP request messages to be relayed.
-
-Reply Processing
-
-   When a reply (REP value other than X'00') indicates a failure, the
-   SOCKS server MUST terminate the TCP connection shortly after sending
-   the reply.  This must be no more than 10 seconds after detecting the
-   condition that caused a failure.
-
-   If the reply code (REP value of X'00') indicates a success, and the
-   request was either a BIND or a CONNECT, the client may now start
-   passing data.  If the selected authentication method supports
-   encapsulation for the purposes of integrity, authentication and/or
-   confidentiality, the data are encapsulated using the method-dependent
-   encapsulation.  Similarly, when data arrives at the SOCKS server for
-   the client, the server MUST encapsulate the data as appropriate for
-   the authentication method in use.
-
-7.  Procedure for UDP-based clients
-
-   A UDP-based client MUST send its datagrams to the UDP relay server at
-   the UDP port indicated by BND.PORT in the reply to the UDP ASSOCIATE
-   request.  If the selected authentication method provides
-   encapsulation for the purposes of authenticity, integrity, and/or
-   confidentiality, the datagram MUST be encapsulated using the
-   appropriate encapsulation.  Each UDP datagram carries a UDP request
-   header with it:
-
-
-
-
-
-Leech, et al                Standards Track                     [Page 7]
-
-RFC 1928                SOCKS Protocol Version 5              March 1996
-
-
-      +----+------+------+----------+----------+----------+
-      |RSV | FRAG | ATYP | DST.ADDR | DST.PORT |   DATA   |
-      +----+------+------+----------+----------+----------+
-      | 2  |  1   |  1   | Variable |    2     | Variable |
-      +----+------+------+----------+----------+----------+
-
-     The fields in the UDP request header are:
-
-          o  RSV  Reserved X'0000'
-          o  FRAG    Current fragment number
-          o  ATYP    address type of following addresses:
-             o  IP V4 address: X'01'
-             o  DOMAINNAME: X'03'
-             o  IP V6 address: X'04'
-          o  DST.ADDR       desired destination address
-          o  DST.PORT       desired destination port
-          o  DATA     user data
-
-   When a UDP relay server decides to relay a UDP datagram, it does so
-   silently, without any notification to the requesting client.
-   Similarly, it will drop datagrams it cannot or will not relay.  When
-   a UDP relay server receives a reply datagram from a remote host, it
-   MUST encapsulate that datagram using the above UDP request header,
-   and any authentication-method-dependent encapsulation.
-
-   The UDP relay server MUST acquire from the SOCKS server the expected
-   IP address of the client that will send datagrams to the BND.PORT
-   given in the reply to UDP ASSOCIATE.  It MUST drop any datagrams
-   arriving from any source IP address other than the one recorded for
-   the particular association.
-
-   The FRAG field indicates whether or not this datagram is one of a
-   number of fragments.  If implemented, the high-order bit indicates
-   end-of-fragment sequence, while a value of X'00' indicates that this
-   datagram is standalone.  Values between 1 and 127 indicate the
-   fragment position within a fragment sequence.  Each receiver will
-   have a REASSEMBLY QUEUE and a REASSEMBLY TIMER associated with these
-   fragments.  The reassembly queue must be reinitialized and the
-   associated fragments abandoned whenever the REASSEMBLY TIMER expires,
-   or a new datagram arrives carrying a FRAG field whose value is less
-   than the highest FRAG value processed for this fragment sequence.
-   The reassembly timer MUST be no less than 5 seconds.  It is
-   recommended that fragmentation be avoided by applications wherever
-   possible.
-
-   Implementation of fragmentation is optional; an implementation that
-   does not support fragmentation MUST drop any datagram whose FRAG
-   field is other than X'00'.
-
-
-
-Leech, et al                Standards Track                     [Page 8]
-
-RFC 1928                SOCKS Protocol Version 5              March 1996
-
-
-   The programming interface for a SOCKS-aware UDP MUST report an
-   available buffer space for UDP datagrams that is smaller than the
-   actual space provided by the operating system:
-
-          o  if ATYP is X'01' - 10+method_dependent octets smaller
-          o  if ATYP is X'03' - 262+method_dependent octets smaller
-          o  if ATYP is X'04' - 20+method_dependent octets smaller
-
-8.  Security Considerations
-
-   This document describes a protocol for the application-layer
-   traversal of IP network firewalls.  The security of such traversal is
-   highly dependent on the particular authentication and encapsulation
-   methods provided in a particular implementation, and selected during
-   negotiation between SOCKS client and SOCKS server.
-
-   Careful consideration should be given by the administrator to the
-   selection of authentication methods.
-
-9.  References
-
-   [1] Koblas, D., "SOCKS", Proceedings: 1992 Usenix Security Symposium.
-
-Author's Address
-
-       Marcus Leech
-       Bell-Northern Research Ltd
-       P.O. Box 3511, Stn. C,
-       Ottawa, ON
-       CANADA K1Y 4H7
-
-       Phone: (613) 763-9145
-       EMail: mleech@bnr.ca
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leech, et al                Standards Track                     [Page 9]
-
diff -Nru /tmp/8fRmF1gy4s/dante-1.1.18/doc/rfc1929.txt /tmp/urHUlwBEQ7/dante-1.1.18.dfsg/doc/rfc1929.txt
--- /tmp/8fRmF1gy4s/dante-1.1.18/doc/rfc1929.txt	1999-04-22 18:48:12.000000000 +0200
+++ /tmp/urHUlwBEQ7/dante-1.1.18.dfsg/doc/rfc1929.txt	1970-01-01 01:00:00.000000000 +0100
@@ -1,115 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           M. Leech
-Request for Comments: 1929                    Bell-Northern Research Ltd
-Category: Standards Track                                     March 1996
-
-
-             Username/Password Authentication for SOCKS V5
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-1.  Introduction
-
-   The protocol specification for SOCKS Version 5 specifies a
-   generalized framework for the use of arbitrary authentication
-   protocols in the initial socks connection setup. This document
-   describes one of those protocols, as it fits into the SOCKS Version 5
-   authentication "subnegotiation".
-
-Note:
-
-   Unless otherwise noted, the decimal numbers appearing in packet-
-   format diagrams represent the length of the corresponding field, in
-   octets.  Where a given octet must take on a specific value, the
-   syntax X'hh' is used to denote the value of the single octet in that
-   field. When the word 'Variable' is used, it indicates that the
-   corresponding field has a variable length defined either by an
-   associated (one or two octet) length field, or by a data type field.
-
-2.  Initial negotiation
-
-   Once the SOCKS V5 server has started, and the client has selected the
-   Username/Password Authentication protocol, the Username/Password
-   subnegotiation begins.  This begins with the client producing a
-   Username/Password request:
-
-           +----+------+----------+------+----------+
-           |VER | ULEN |  UNAME   | PLEN |  PASSWD  |
-           +----+------+----------+------+----------+
-           | 1  |  1   | 1 to 255 |  1   | 1 to 255 |
-           +----+------+----------+------+----------+
-
-
-
-
-
-
-Leech                       Standards Track                     [Page 1]
-
-RFC 1929          Username Authentication for SOCKS V5        March 1996
-
-
-   The VER field contains the current version of the subnegotiation,
-   which is X'01'. The ULEN field contains the length of the UNAME field
-   that follows. The UNAME field contains the username as known to the
-   source operating system. The PLEN field contains the length of the
-   PASSWD field that follows. The PASSWD field contains the password
-   association with the given UNAME.
-
-   The server verifies the supplied UNAME and PASSWD, and sends the
-   following response:
-
-                        +----+--------+
-                        |VER | STATUS |
-                        +----+--------+
-                        | 1  |   1    |
-                        +----+--------+
-
-   A STATUS field of X'00' indicates success. If the server returns a
-   `failure' (STATUS value other than X'00') status, it MUST close the
-   connection.
-
-3.  Security Considerations
-
-   This document describes a subnegotiation that provides authentication
-   services to the SOCKS protocol. Since the request carries the
-   password in cleartext, this subnegotiation is not recommended for
-   environments where "sniffing" is possible and practical.
-
-4.  Author's Address
-
-   Marcus Leech
-   Bell-Northern Research Ltd
-   P.O. Box 3511, Station C
-   Ottawa, ON
-   CANADA K1Y 4H7
-
-   Phone: +1 613 763 9145
-   EMail: mleech@bnr.ca
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Leech                       Standards Track                     [Page 2]
-
