[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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-

4.  Command Descriptions

4.1.  GET command


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

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

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

S: 209 OK

Hernacki                                                        [Page 3]

INTERNET-DRAFT                                              Jan 15, 1997


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,

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

     Network News Transfer Protocol.  B. Kantor, Phil  Lapsley,  Request
     for Comment (RFC) 977, February 1986.

Hernacki                                                        [Page 4]

INTERNET-DRAFT                                              Jan 15, 1997

     Standard for Interchange of USENET Messages.  M. Horton, R.  Adams,
     Request for Comment (RFC) 1036, December 1987.

     Network News Transfer Protocol.  S.  Barber  INTERNET  DRAFT,  Sep-
     tember 1996.

     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

   Phone: +1 415-937-6738
   Email: bhern@netscape.com

                  This Internet Draft expires  Jan 15, 1997.

Hernacki                                                        [Page 5]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/