[NNTP] Adding A Quota Command to NNTP (internet-draft)

Samuel Kleiner ulterior.org at gmail.com
Mon Feb 5 20:14:35 PST 2007

Internet-Draft                               S. Kleiner,sam at ulterior.org
Intended status: Standards Track                      February 5th, 2007
Expires: August 5th, 2007

                    Adding A Quota Command to NNTP

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 30, 2007.


   This document describes a multicapable quota command for NNTP,
   specifically designed for binary downloading applications. This
   document extends [RFC3977].

Kleiner                Expires August 5, 2007                  [Page 1]

1.1. Introduction

   Today, many users of the NNTP protocol use it for the transfer and
   exchange of 'binaries'-- non-textual files, primarily in the
   alt.binaries.* hierarchy.  Most modern NNTP providers therefore
   either set a limit on the number of bytes per month or forbid all
   binary downloads by banning the *.binaries.* hierarchies completely.

   There is currently no way for the NNTP provider to directly inform
   the customer and application of the amount downloaded or that the
   owner of the account has used too much of its quota, or how many
   connections are allowed. All current providers use other channels,
   such as dynamically updating web pages. The design of these web pages
   vary from provider to provider, and is thus not useful to the
   specially designed binary downloading applications used by many

   We therefore propose the addition of a QUOTA command to the NNTP
   protocol as defined in [RFC3977].

   As defined in this DRAFT, an ordinary binary news server account
   granting six gigabytes of downloads, fifteen days from renewal, where
   the user had used three gigabytes, with three allowed simultaneous
   connections, would work as follows:

   209 QUOTA
   B 60000000000 30000000000 HOLD
   T 2592000 1296000 RENEW
   C 3

Kleiner                Expires August 5, 2007                  [Page 2]

1.2 Objections

1.2.1 User applications can feature the same functionality

   User applications may have their own counters for these quotas, but:

   Many providers have their own standard as to which parts of
   downloads "count" for the purpose of download quotas.

   Many providers make it easy to pay extra for one's quota to be reset,
   and this would not be shown.

   User applications may be reset due to program or user error.

   User applications would be unable to keep track, should the user
   connect from multiple locations.

1.2.2 Would require changes to customized servers

   Implementing this extension would require custom changes to the
   server, but:

   NNTP providers who have the greatest amount of custom code are the
   ones who are most interested in serving large amounts of binaries,
   and they are expected to be the ones most interested in implementing
   this extension.

1.2.3 Most significant to users who download binaries

   The advantages of implementing this extension would be most
   significant for users who download binaries (which may today be a
   minority of those today using nntp clients).

   It is, however, in the interest of all NNTP users that binaries
   downloads from servers that serve both binaries users and
   non-binaries users should be limited.

1.3 Terminology

1.3.1 General Terminology

   General terminology is as defined in [RFC3977] unless otherwise

Kleiner                Expires August 5, 2007                  [Page 3]

2 The QUOTA extension

   This extension extends [RFC3977] by providing a new QUOTA

2.1. Advertising the QUOTA Extension

   A server supporting the QUOTA command as defined in this document
   should advertise the QUOTA" capability in response to the
   CAPABILITIES command defined in [RFC3977].

2.2. Response Formal Syntax (As [RFC4234])

   return-string = ok [ byte ] [ period ] [ rate ] [ time ] [ info ]
                   [ unlimited ] [ message ] [ url ] [ connections ]
                   "." CR LF / notsupported
   ok            = "209 QUOTA" CR LF
   notsupported  = "509 QUOTA NOT SUPPORTED" CR LF
   byte          = "B " byte-quota " " byte-used " " consequence CR LF
   period        = "P " period-quota " " period-used " "
                      consequence  CR LF
   time          = "T " time-quota " " time-used " " consequence CR LF
   rate          = "R " byte-rate CR LF
   unlimited     = "U" CR LF
   information   = "I " byte-used period-used CR LF
   message       = "M " 0*80msgchr CR LF
   uri           = "W " URI
   connections   = "C " connections
   msgchr        = VCHAR / SP
   consequence   = "HOLD" / "RATE" / "NONE" / "RENEW" / "END"
   time-quota    = 1*DIGIT
   time-used     = 1*DIGIT
   connections   = 1*DIGIT
   period-quota  = 1*DIGIT
   period-used   = 1*DIGIT
   byte-quota    = 1*DIGIT
   byte-used     = 1*DIGIT
   byte-rate     = 1*DIGIT

Kleiner                Expires August 5, 2007                  [Page 4]

2.3.1 Ranges

   All numbers, including time-quota, period-quota, and byte-quota
   numbers should be zero or any higher natural number.

2.4. Intended meanings of the response string

2.4.1 Intended meanings of the consequence keyword Hold

   Account has been put on hold and no downloading will be allowed, and
   won't allow more of the specified quota action until another quota
   undergoes a "RENEW" consequence. Rate

   Downloading is allowed only at the specified rate. If there is
   another passed quota which has RATE as consequence, and this is also
   specified, this limit is to be understood to disappear when a renew
   consequence happens. If the server allows multiple connections, the
   value of this should be the maximum rate for one connection. None

   No reward or penalty for exceeding quota. Renew

   Other quotas will be renewed when this goes over quota. Used for the
   Period type, with automatically renewed accounts. End

   Account is put on hold and no downloading is allowed. No renewal
   action is expected.

2.4.2 Byte quota ("B")

   This is the number of bytes that may be downloaded, followed by the
   number of bytes downloaded, followed by the consequence should the
   user download more than the quota.

Kleiner                Expires August 5, 2007                  [Page 5]

2.4.3 Period quota ("P")

   This is the integer number of seconds in the current quota time
   period that the server may be used in, followed by the number of
   seconds used. The latter number increases even when the user is not
   logged into the server, or downloading. This is followed by the
   consequence should the user download more than the quota.

2.4.4 Time quota ("T")

   This is the integer number of seconds that the server may be used,
   followed by the number of seconds used. This is followed by the
   consequence should the user download more than that limit.

2.4.5 Rate ("R")

   This is the integer number of bytes per second allowed to be
   downloaded from the server.

2.4.6 Unlimited ("U")

   This server doesn't use a byte quota, or any bytes per second
   limitation, beyond that imposed by the underlying hardware capacity.
   It is expected that some services may for commercial reasons report
   themselves as theoretically unlimited but in practice limited to
   some specific very high number of bytes. Such services are expected
   to use this response code, but in the interest of customer clarity,
   once this hidden quota is passed, report this, by returning either
   "B ... ... HOLD", or "B ... ... LIMIT", or  "R ...", or a "M"
   message to this effect.

2.4.7 Information ("I")

   This server doesn't use a byte quota, but wants to inform you of
   bytes downloaded despite this. Suggested use is in systems limited by
   bytes per second. The second number is the number of seconds since
   the first byte was downloaded.

2.4.8 Message ("M")

   Message to be displayed in adjunct with quota graphic or text in
   binary downloading applications. This should be UTF-8 in the default
   language of the server owner.

2.4.10 URI ("W")

   Activateable link titled, "Renew", graphical button, or similar
   localized string should be displayed in adjunct to the quota
   information. This URI should point to a location where the user can
   renew quotas.  "URI" is to be understood as the ABNF keyword
   defined in [RFC3986], page 26.

2.4.11 Connections ("C")

   Number of simultaneous connections allowed to the server.

Kleiner                Expires August 5, 2007                  [Page 6]

2.5 Pipelining

   This command may be pipelined. Returned values should be valid at
   some time thoughout the span of time that the command was

2.6 Examples

   A nntp server which has unlimited downloads, and which renews every
   30 days, 15 which have passed should return

T 2592000 1296000 RENEW

   If the previous nntp server in practice limited downloads past 10gb
   to 10kB/s would ideally return

T 2592000 1296000 RENEW
R 10000
M Downloads limited due to excessive downloading

   A nntp server from which you had bought 20GB of downloads(half
   used) without any any automatic renewal would return:

B 20000000000 10000000000 END

   If the previous nntp server allowed four simultaneous connections,
   and renewal was available at http://www.example.invalid, it would

B 20000000000 10000000000 END
W http://www.example.invalid
C 4
Kleiner                Expires August 5, 2007                  [Page 7]

3 Comments, etc.

   Comments are solicited and should be addressed to the author at
   sam at ulterior.org, or possibly, the working group's mailing list at
   ietf-nntp at lists.eyrie.org.

4 IETF Checklist

4.1 Authors' Addresses

   Kleiner sam at ulterior.org

4.1.1  Significant contributions by

   BitBucket(34575), minato(56515), inpheaux(24336) & Z-Bo(81095)
   Username(UID) on http://forums.somethingawful.com

4.2 Security Considerations

   This extension should not have any security considerations beyond
   those in NNTP, but may have additional confidentiality implications.

4.3 IANA Considerations

   This document has no actions for IANA.

4.4 Intellectual Property

Kleiner                Expires August 5, 2007                  [Page 8]

4.4.1 IPR Disclosure Acknowledgment (RFC 3979 Sec. 5 para 1)

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

4.4.2 IPR Disclosure Acknowledgment (RFC 3979 Sec. 5 para 2)

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

4.4.3 Disclosure Invitation (RFC 3979 Sec. 5 para 3)

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr at ietf.org.

4.4.4 Copyright

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on
Kleiner                Expires August 5, 2007                  [Page 9]

5. References

5.1 Normative References

  [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for
             Syntax Specifications: ABNF", RFC 4234, October 2005.

  [RFC3977]  Feather, D. "Network News Transfer Protocol (NNTP)",
             December 2006.

  [RFC3986]  Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
             Resource Identifiers (URI): Generic Syntax", August 1998.
-------------- next part --------------
(reposted due to wrong e-mail signup)

More information about the ietf-nntp mailing list