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]