internetdraft/README at master · antbryan/internetdraft · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
this is a collection of IETF Internet Drafts for Metalink/XML clients/publishers/caches, FTP HASH, RANGe, and LOCK.
(IDs are RFCs in progress.)

some of these were the product of the FTPEXT2 Working Group at the IETF.

various authors: Ant Bryan [ http://www.metalinker.org/ ]
                 Tim Kosse [ http://filezilla-project.org/ ]
                 Daniel Stenberg [ http://www.haxx.se/ ]
                 Tatsuhiro Tsujikawa [ http://aria2.sourceforge.net/ ]
				 Neil McNab [ http://www.nabber.org/ ]
				 Peter Poeml [ http://mirrorbrain.org/~poeml/ ]


Metalink/XML Clients, Publishers, and Caches
http://tools.ietf.org/html/draft-bryan-metalink-client
Authors:  A. Bryan, T. Tsujikawa, N. McNab, P. Poeml

Abstract

   This document specifies behavior for Metalink/XML clients,
   publishers, and proxy caches. way to get information that is usually
   contained in the Metalink XML-based download description format.
   Metalink XML files contain multiple download locations (mirrors and
   Peer-to-Peer), cryptographic hashes, digital signatures, and other
   information.  Metalink clients can use this information to make file
   transfers more robust and reliable.  Normative requirements for
   Metalink/XML clients, publishers, and proxy caches are described
   here.

FTP HASH Command for Cryptographic Hashes
http://tools.ietf.org/html/draft-bryan-ftpext-hash
Authors: A. Bryan, T. Kosse, D. Stenberg

Abstract

   The File Transfer Protocol does not offer any method to verify the
   integrity of a transferred file, nor can two files be compared
   against each other without actually transferring them first.
   Cryptographic hashes are a possible solution to this problem.  In the
   past, several attempts have been made to add commands to obtain
   checksums and hashes, however none have been formally specified,
   leading to non-interoperability and confusion.  To solve these
   issues, this document specifies a new FTP command to be used by
   clients to request cryptographic hashes of files.

---
FTP RANG Command for Octet Ranges
http://tools.ietf.org/html/draft-bryan-ftp-range
Authors: A. Bryan, T. Tsujikawa, D. Stenberg

Abstract

   The File Transfer Protocol offers the REST command to designate a
   starting point for a transfer, but does not currently offer any
   method to specify an end point.  This document specifies a new FTP
   RANG command to be used by clients to designate a start and end point
   to permit restarts and repairs of interrupted data transfers in
   STREAM mode.

---
FTP LOCK Command for Using a Single Port
http://tools.ietf.org/html/draft-bryan-ftp-lock
Authors: A. Bryan, D. Stenberg, T. Tsujikawa


Abstract

   One of the biggest hurdles for FTP in real life usage is its use of
   two connections.  First, it uses a primary connection to send control
   commands on, and when it sends or receives data, it opens a second
   TCP stream for that purpose.  This document specifies a new FTP LOCK
   command to be used by clients to request the server to use the
   control connection for data transfers, using a single port instead of
   two.