Internet DRAFT - draft-hernacki-nntpget
draft-hernacki-nntpget
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:21:26 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Tue, 17 Mar 1998 16:30:00 GMT
ETag: "2e9b16-1d8a-350ea508"
Accept-Ranges: bytes
Content-Length: 7562
Connection: close
Content-Type: text/plain
INTERNET-DRAFT B. Hernacki
Expires: Jan 15, 1997 Netscape Communications, Inc.
<draft-hernacki-nntpget-00.txt> July 15, 1997
NNTP Generic Data Extensions
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working docu-
ments 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
2. Abstract
This document describes a set of enhancements to the Network News Tran-
sport Protocol [NNTP-977] that provide a generic mechanism by which
clients and servers can exchange configuration information. It was ori-
ginally designed as a method by which an NNTP client could request URLs
from the server in order to access out-of-band information. It is not
however limited to URLs and may be used to communicate such things as
language settings, client prefences, formatting information, etc. The
protocol additions are designed in a manner which allows the client and
server to exchange key/data pairs of arbitrary text strings.
The availability of the extensions described here will be advertised by
the server using the extension negotiation-mechanism described in the
new NNTP protocol specification currently being developed [NNTP-NEW].
Hernacki [Page 1]
INTERNET-DRAFT Jan 15, 1997
3. Introduction
3.1. New Commands
There are two new NNTP commands.
* GET
* SET
GET allows the client to retreive a value based on a supplied key. SET
allows the client to comminucate a value for a given key to the server.
3.2. Use of NNTP Extension Mechanism
The NNTP extension mechanism allows a server to describe its capabili-
ties. The following extensions are used to describe the capabilities
described in this document.
3.3. SETGET Extension
The SETGET extension means that the server supports the SET and GET com-
mands.
4. Command Descriptions
4.1. GET command
GET [ATTRIBUTE [ATTRIBUTE]...]
GET allows the client to retrieve session-specific state information
from the server.
The only characters allowed in attributes or values are uppercase and
lowercase letters, numbers, and the characters "-_:". Case is not signi-
ficant in the attribute names. This information must not be preserved
by the client across server sessions.
If no ATTRIBUTE is specified, all of the attributes are returned by the
server.
4.2. Responses
The server will either return the values (209), indicate a syntax error
Hernacki [Page 2]
INTERNET-DRAFT Jan 15, 1997
(501), or indicate that the attribute was not recognized (409).
209 values follow
501 command syntax error
409 unknown attribute
502 no permission
4.3. Example
C: GET
S: 209 values follow
S: FAQURL http://www.faqhome.com/faq?group=[ngc]
S: MODURL http://www.news.com/moderate.html
S: .
4.4. SET command
SET ATTRIBUTE <value> [ATTRIBUTE <value> ...]
SET allows the client to set session specific state information. This
might include things like what language it wants to use, what version of
the protocol it wants, what type of authentication it will be using, or
optional article compressions. The only characters allowed in attri-
butes or values are upper and lower case letter, number, and the charac-
ters "-_:". Case is not significant in the attribute names. This infor-
mation must not be preserved by the server across client sessions.
If multiple attributes are specified and the server does not recognize
one or more of them, it must return an error and not set any of them.
4.5. Responses
The server will either return that it set the value (209), return a syn-
tax error (501), or indicate that one or more of the attributes was not
recognized (409).
209 OK
501 command syntax error
409 unknown attribute
502 no permission
4.6. Example
C: SET LANG USEnglish
S: 209 OK
Hernacki [Page 3]
INTERNET-DRAFT Jan 15, 1997
4.7.
5. URL strings
A very useful application of this extension is the exchanging of URLs to
enable out-of-band communication without additional protocol extensions.
URLs are used here as they are intended to be uniform resource loca-
tions. While they may be HTTP URLs, they may also be NNTP, IMAP, FTP,
etc.
In specifying these URLs however it will be useful for a client to be
able to provide common information such as newsgroup name, message-id,
etc in the URL. To do so, this document defines tags which may exist in
the URLs returned by the server. These tag must be replaced with valid
information before being used by the client. A tag in a URL is any value
enclose by brackets ([]). The tag name is a single string composed only
of us-ascii alphabetic characters and is case-insensitive.
5.1. Defined tags are
* [ngc]
This defines a newsgroup component. Generally this is a newsgroup name
such as comp.lang.c. However it may also be a partial newsgroup name
which specifies a heirarchy level such as rec.arts. Clients should
replace [ngc] with the newsgroup component to which they are referring.
* [msgid]
This defines the message-ID of an articles. Clients should replace
[msgid] with the message-ID to which they are referring.
6. Security Considerations
These commands do not introduce any new security concerns themselves. If
a server is to add some key/data value which might provide restricted
information, they will need to provide access control.
7. Bibliography
[NNTP-977]
Network News Transfer Protocol. B. Kantor, Phil Lapsley, Request
for Comment (RFC) 977, February 1986.
Hernacki [Page 4]
INTERNET-DRAFT Jan 15, 1997
[NNTP-1036]
Standard for Interchange of USENET Messages. M. Horton, R. Adams,
Request for Comment (RFC) 1036, December 1987.
[NNTP-NEW]
Network News Transfer Protocol. S. Barber INTERNET DRAFT, Sep-
tember 1996.
[MIME-2]
Moore, K., MIME (Multipurpose Internet Mail Extensions) Part Two:
Message Header Extensions for Non-ASCII Text, RFC 1522, University
of Tennessee, September 1993.
8. Author's Address
Brian Hernacki
Netscape Communications, Inc.
685 W. Middlefield Road
Mountain View, CA 94043
USA
Phone: +1 415-937-6738
Email: bhern@netscape.com
This Internet Draft expires Jan 15, 1997.
Hernacki [Page 5]
