[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
draft-kleiner-adding-quota-command-to-nntp-00
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 30, 2007.
Abstract
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
customers.
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:
>QUOTA
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
specified.
Kleiner Expires August 5, 2007 [Page 3]
2 The QUOTA extension
This extension extends [RFC3977] by providing a new QUOTA
command.
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
2.4.1.1 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.
2.4.1.2 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.
2.4.1.3 None
No reward or penalty for exceeding quota.
2.4.1.4 Renew
Other quotas will be renewed when this goes over quota. Used for the
Period type, with automatically renewed accounts.
2.4.1.5 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
outstanding.
2.6 Examples
A nntp server which has unlimited downloads, and which renews every
30 days, 15 which have passed should return
209 QUOTA
T 2592000 1296000 RENEW
U
.
If the previous nntp server in practice limited downloads past 10gb
to 10kB/s would ideally return
209 QUOTA
T 2592000 1296000 RENEW
U
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:
209 QUOTA
B 20000000000 10000000000 END
.
If the previous nntp server allowed four simultaneous connections,
and renewal was available at http://www.example.invalid, it would
return:
209 QUOTA
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
http://www.ietf.org/ipr.
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
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
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