INTERNET-DRAFT                                                   P. Grau
<draft-dfncis-netnews-admin-sys-07.txt>                        V. Heinau
Expires January 12, 2006                                  H. Schlichting
                                                           R. Schuettler
                                               Freie Universitaet Berlin
                                                               July 2005

                  Netnews Administration System (NAS)
                <draft-dfncis-netnews-admin-sys-07.txt>



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.


Copyright Notice

   Copyright (C) The Internet Society (2005).


Abstract

   The Netnews Administration System (NAS) is a framework to simplify
   the administration and usage of network news (also known as Netnews)
   on the Internet. Data for the administration of newsgroups and
   hierarchies are kept in a distributed hierarchical database and are
   available through a client-server-protocol.



Grau, Heinau, Schlichting, Schuettler                           [Page 1]


Internet Draft       Netnews Administration System             July 2005


   The database is accessible by news servers and news administrators as
   well as by news readers. News servers can update their configuration
   automatically; administrators are able to get the data manually. News
   reader programs are able to get certain information from an NAS
   server, automatically or at a user's discretion, to provide detailed
   information about groups and hierarchies to the user.

   NAS is usable in coexistence with the current, established process of
   control messages; an unwanted interference is impossible.
   Furthermore, NAS is able to reflect the somewhat chaotic structure of
   Usenet in a hierarchical database. NAS can be used without
   modification of existing news relay, news server or news reader
   software, however, some tasks will be better accomplished with NAS
   compliant software.





































Grau, Heinau, Schlichting, Schuettler                           [Page 2]


Internet Draft       Netnews Administration System             July 2005


                           Table of Contents

Status of this Memo ...............................................    1
Copyright Notice ..................................................    1
Abstract ..........................................................    1
1.  Introduction ..................................................    4
2.  Overview ......................................................    5
3.  Protocol Level ................................................    6
4.  Description of Functions ......................................    7
5.  Definitions ...................................................    8
6.  Specification of the NAS Protocol (TCP) .......................    9
    6.1.  Responses ...............................................    9
        6.1.1.  Overview ..........................................    9
        6.1.2.  Response Code Values, Structure and Meaning .......    9
    6.2.  Connection Setup ........................................   10
    6.3.  Commands ................................................   11
        6.3.1.  Structure .........................................   11
        6.3.2.  Overview ..........................................   11
        6.3.3.  Detailed Description ..............................   11
            6.3.3.1.  HELP ........................................   12
            6.3.3.2.  INFO ........................................   13
            6.3.3.3.  DATE ........................................   14
            6.3.3.4.  VERS ........................................   15
            6.3.3.5.  QUIT ........................................   16
            6.3.3.6.  LIST ........................................   17
            6.3.3.7.  LSTR ........................................   19
            6.3.3.8.  HIER ........................................   20
            6.3.3.9.  DATA ........................................   22
            6.3.3.10.  GETP .......................................   23
            6.3.3.11.  GETA .......................................   26
            6.3.3.12.  Unknown Commands and Syntax Errors .........   28
        6.3.4.  Data Headers ......................................   28
    6.4.  Status Indicators .......................................   44
    6.5.  Newsgroup Types .........................................   44
    6.6.  Hierarchy Types .........................................   45
    6.7.  PGP Keys ................................................   45
7.  Specification of the NAS Protocol (UDP) .......................   47
8.  IANA Considerations ...........................................   47
9.  Security Considerations .......................................   47
10.  Response Codes (Overview) ....................................   48
11.  Data Headers for DATA and HIER Commands (Overview) ...........   49
12.  References ...................................................   50
    12.1.  Normative References ...................................   50
    12.2.  Informative References .................................   50
13.  Author's Address .............................................   51
14.  Full Copyright Statement .....................................   51
15.  Intellectual Property ........................................   51




Grau, Heinau, Schlichting, Schuettler                           [Page 3]


Internet Draft       Netnews Administration System             July 2005


1.  Introduction

   The increasing number of newsgroups, hierarchies and articles has
   made the administration of news servers a complex and time consuming
   task. The tools for the administration have remained unchanged for
   ten years and are no longer appropriate. Many hierarchies are
   inconsistent, many new newsgroups are not created or only with a
   large delay, removed groups keep lurking in the configuration files
   for a long period of time. There is no administration tool that
   utilizes the power of the Internet, and it is not possible to check
   the consistency of the news server at a given point of time.

   Users find it difficult to get an overview of the newsgroups, the
   charter of a particular one, which language is preferred, or whether
   a group is moderated or not. Renaming, the status change from
   moderated to unmoderated or vice versa, and the splitting of a group
   into several others are dynamic processes. These processes are in
   common use, but it takes a long time until every news server is aware
   of these changes.

   An increasing number of faked control messages has appeared in the
   last few years. Purposely or accidentally control messages were sent
   to foreign news servers to create or remove a certain group, although
   this was not approved according to the rules of the hierarchy in
   question. Due to this fact, automatic creation and removal is
   disabled on many news servers and several dead groups have not been
   deleted. It is very difficult for users to determine the current
   status of a group, and in some cases they simply cannot tell that the
   group they are posting to is in reality not an active but a dead or
   invalid group.

   It is the design goal of NAS to provide an out-of-band system that
   helps to maintain, propagate, and deliver the required information.
   There will not be any interference with current protocols and
   standards. It is not intended to make use of control messages or some
   special NNTP commands. The advantage of NAS is that it provides more
   information in a more structured format than control messages. Not
   only news server administrators but also Usenet users can get more
   detailed information about newsgroups and hierarchies.

   Due to the fact that a client connects to a server and the server
   asks for authentication, this is a more reasonable procedure of
   transmitting information than control messages. Furthermore, it is
   possible to check for changes on a regular basis at customized
   intervals to keep local data up-to-date.






Grau, Heinau, Schlichting, Schuettler                           [Page 4]


Internet Draft       Netnews Administration System             July 2005


2.  Overview

   NAS is based on a database which contains information about certain
   groups and hierarchies. This database is structured in a hierarchical
   manner, distributed to various servers and is able to receive queries
   at any time. The service is comparable to directory services like
   DNS, LDAP or NIS. The NAS protocol is inspired by protocols like NNTP
   and SMTP. The port 991 is reserved for NAS and registered by the
   Internet Assigned Number Authority (IANA) [IANA-PN].


   The organizational structure of NAS is hierarchical, that means a NAS
   root server collects data from the sub-servers that are authoritative
   for certain hierarchies. The root server signs the data and
   distributes it authoritatively. Replication of database entries is
   possible. The hierarchical structure can consist of multiple levels.
   Usage of the database is possible for news servers, news readers and
   special client programs. The communication is based on TCP and UDP.

   Taking the real world into account, there might be some policy
   problems with a single root server. But it is possible to establish a
   structure like the current Usenet system, where some hierarchies have
   a good administration with a well-defined system of rules and some
   are not well maintained. The goal is to get as much information as
   possible under one hat, but there can be no "official" force to
   achieve this.

   During the startup phase it is quite likely that there will be a root
   server, handling just hierarchies with strict rules and accepted
   authorities (like BIG8, de.*, us.*, bln.*, fr.*, it.*, etc.).

   However, it is also imaginable to have some NAS servers providing
   data on - for example - alt.!binaries, some providing data on alt.*,
   and even some providing alt.*  following special policies or sets of
   rules.

   An administrator using NAS will have the choice to use just one root
   server (and all its data) and/or to use another NAS server for
   special hierarchies.












Grau, Heinau, Schlichting, Schuettler                           [Page 5]


Internet Draft       Netnews Administration System             July 2005



          ..............   ..............     ...................
          . NAS server .   . NAS server .     . NAS server      .
          .            .   .            .     . alt.*,          .
          . alt.*      .   . Big8       .     . !alt.binaries.* .
          ..............   ..............     ...................
          . database   .   . database   .     . database        .
          ..............   ..............     ...................
                 ^            ^      ^                  ^
                 `--+      +--'      `------+      +----'
                    |      |                |      |
                 .------------.          .------------.
                 | NAS client |          | NAS client |
                 +------------+          +------------+
                 |  netnews   |          |  netnews   |
                 |  server    |          |  server    |
                 .------------.          .------------.

                 Configuration A         Configuration B

                                 Figure 1


   NAS contains information about newsgroups as well as complete
   hierarchies. Furthermore, it contains information about the
   hierarchies' inheritable entries and default values for a single
   newsgroup.


3.  Protocol Level

   It is expected that the real life use of NAS will change the
   requirements for the Netnews Administration System. On the one hand
   the protocol has to be extensible and flexible in order to implement
   improvements, on the other hand it must ensure compatibility between
   different versions. A simultaneous migration of all sites using NAS
   to a new protocol version is not likely to happen. To solve this
   problem, NAS has a protocol level. This protocol level describes the
   current functionality. The protocol level, being a number between 1
   and 32767, is negotiated at connection setup. Enhancements and
   modifications must use a different protocol level than their
   predecessors. (Usually the protocol level is incremented by 1 with
   every new version of the protocol specification.) Every current or
   future implementation MUST be compatible with protocol level 1 in
   order to fall back to this level if communication on a higher level
   fails.

   An implementation of higher protocol levels should be able to emulate



Grau, Heinau, Schlichting, Schuettler                           [Page 6]


Internet Draft       Netnews Administration System             July 2005


   the behavior of lower levels, even if this implies a loss of
   features. The negotiation of the protocol level between client and
   server is described in the specification of the command VERS. If
   there is no agreement on the protocol level, only commands of the
   protocol level 1 MUST be used. Documents enhancing or modifying the
   NAS standard MUST specify on which level these changes take place and
   how the behavior should be in other protocol levels.

   This document describes protocol level 1.


4.  Description of Functions

   In order to use a NAS server, a connection must be opened by the
   client. The NAS server can be located in the same domain or somewhere
   else on the Internet.

   The NAS system is hierarchical. The idea is to have an NAS root
   server like the DNS root servers. The root server distributes the
   data collected from client NAS servers that are authoritative servers
   for their hierarchy. The maintenance of the authoritative data is
   possible on any system. The root server collects the data and makes
   them available to other servers, which can in turn distribute these
   data to other servers. The administrator has the opportunity to make
   use of either all data or only parts of the database. NAS servers can
   ask multiple NAS servers for data. An attached time stamp provides
   the possibility to distinguish between new and old data and to avoid
   loops in the propagation.

   To describe the NAS in greater detail, it is necessary to emphasize
   the hierarchical design of the NAS system. The following figure shows
   the propagation of data along the server hierarchy.

   Authoritative data for a newsgroup or a hierarchy are collected and
   written into a database. These data are available through a local NAS
   server and are collected from this authoritative server by upstream
   NAS servers.

   There may also be NAS servers that are not authoritative servers;
   these servers merely provide the information they collect from other
   NAS servers to clients such as news servers, administration programs
   and news readers.









Grau, Heinau, Schlichting, Schuettler                           [Page 7]


Internet Draft       Netnews Administration System             July 2005



         ............     collects from >
         . root NAS .-------------------------+
         . server   .----------------+        |
         ............                |        |
         . database .                |        |
         ............                |        |
               ^ v                   |   ..........................
               | |                   |   . NAS server             .
               | |distributes        |   . authoritative for de.* .
        queries| |                   |   ..........................
               | |                   |   .        database        .
               ^ v                   |   ..........................
         ..............              |
         . NAS server .              `--------+
         ..............                       |
         .  database  .                ...........................
         ..............                . NAS server              .
           ^  ^  ^                     . authoritative for bln.* .
           |  |  |  .---------.        ...........................
         q |  |  `--| netnews |        .        database         .
         u |  |     | server  |        ...........................
         e |  |     .---------.
         r |  |
         i |  |  .---------.
         e |  `--| admin   |
         s |     | program |
           |     .---------.
           |
           |  .---------.
           `--| news    |
              | reader  |
              .---------.

                                 Figure 2

   Requests to an NAS server originating at a client as well as another
   server are accomplished in several steps, as there are: Establishing
   a connection, authentication (optional), negotiating a protocol level
   (optional), queries on the database, and termination.


5.  Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].




Grau, Heinau, Schlichting, Schuettler                           [Page 8]


Internet Draft       Netnews Administration System             July 2005


6.  Specification of the NAS Protocol (TCP)

6.1.  Responses

6.1.1.  Overview

   An answer starts with a response code (a three digit number),
   optionally followed by white space and a textual message. Then the
   actual text/data follows. Text is sent as a series of successive
   lines of textual matter, each terminated with CRLF. A single line
   containing only a single period ('.') is sent to indicate the end of
   the text (i.e. the server will send a CRLF at the end of the last
   line of text, a period, and another CRLF).

   Answer = response-code [answertext] CRLF
            text CRLF
            "." CRLF

   If the original text contains a period as the first character of the
   text line, that first period is doubled. Therefore, the client must
   examine the first character of each line received, and for those
   beginning with a period, determine either that this is the end of the
   text or whether to collapse the doubled period to a single one.

   Example:

   <-- INFO
   --> 101 Information follows
       Server: nas.example.org (192.0.2.100)
       Uptime: 2 weeks, 3 days, 5 hours, 9 minutes
       Software: NAS 1.0
       Client: client.example.org (192.0.2.123)
       Connection: 9 minutes
       Highest protocol level supported: 1
       Requested protocol level: 1
       Protocol level used: 1
       .


6.1.2.  Response Code Values, Structure and Meaning

   The first digit of the response code indicates the message type,
   i.e., information, success, warning, error, or data:

   1xx Information
   2xx Request successful
   3xx Request successful, data follow
   4xx Request accepted, but no operation possible



Grau, Heinau, Schlichting, Schuettler                           [Page 9]


Internet Draft       Netnews Administration System             July 2005


   5xx Request is wrong (syntax error), not implemented, or leads to an
       internal error
   6xx Request successful, data follow until end mark

   The second digit specifies the message category:

   x0x connection related stuff
   x1x queries, answers, or data
   x2x server-server communication
   x3x authentication, authorization
   x8x non-standard extensions
   x9x debugging output

   The actual response code for a specific command is listed in the
   description of the commands. Answers of the type 1xx, 2xx, 4xx, and
   5xx can have a text after the numerical code. 3xx answers contain one
   or more parameters with data; the exact format is explained in the
   description of the commands.

   An answer to an incorrect request may be longer than one line.


6.2.  Connection Setup

   NAS typically uses port 991, which is reserved by IANA [IANA-PN]. If
   a connection is set up by the client, the server answers immediately
   (without a request) with the greeting message, which will start with
   code 200:

   --> 200 Welcome!
       nas.example.org ready
       .

   If a connection is refused because the client has no permission to
   access the server, the answer code is 434. That decision can be made
   on connection startup based on the client's IP address. When the
   server is currently out of service, the answer code is 404.

    Examples:

   --> 434 You have no permission to retrieve data. Good bye.
       .

   --> 404 Maintenance time
       .

   After sending a 404 or 434 message the connection will be closed.




Grau, Heinau, Schlichting, Schuettler                          [Page 10]


Internet Draft       Netnews Administration System             July 2005


6.3.  Commands

6.3.1.  Structure

   A command consists of a command word, sometimes followed by a
   parameter. Parameters are separated from the command word by white
   space.

   Commands used in the NAS protocol are not case sensitive. A command
   word or parameter may be upper case, lower case, or any mixture of
   upper and lower case.

   The length of a command line is not limited. If the need to limit the
   length of command lines in real life implementations arises, answer
   code 513 (line too long) should be returned.

   The protocol level described in this document uses command words with
   a length of exactly four characters each.

   In examples, octets sent to the NAS server are preceded by "<-- " and
   those sent by the NAS server by "--> ". The indicator is omitted if
   the direction of the dialog does not change.



6.3.2.  Overview

   The commands described below are defined using the Augmented Backus-
   Naur Form (ABNF) defined in [RFC2234]. The definitions for `ALPHA',
   `CRLF', `DIGIT', `WSP' and `VCHAR' are taken from appendix A of
   [RFC2234] and not repeated here.

   The following ABNF definitions comprise the set of NAS commands which
   can be sent from the client to an NAS server.

6.3.3.  Detailed Description

   Some overall definitions:

   text          = %d1-9 /           ; all octets except
                   %d11-12 /         ; US-ASCII NUL, CR and LF
                   %d14-255

   answertext    = WSP *( ALPHA / DIGIT / "+" / "-" / "/" / "_" /
                              "." / "," / ":" / "=" / "?" / "!" / SP )

   utc-time      = 14DIGIT  ; the date and time of the server in UTC
                            ; YYYYMMDDhhmmss



Grau, Heinau, Schlichting, Schuettler                          [Page 11]


Internet Draft       Netnews Administration System             July 2005


   response-code = 3DIGIT   ; three digit number

   Newsgroup names and hierarchy names are defined according to the
   following ABNF definitions. Since a hierarchy name can be the same as
   a newsgroup name (e.g., hierarchy bln.announce.fub.* and newsgroup
   name bln.announce.fub) there is no difference between the two.

   name                  =  plain-component *("." component)
   component             =  plain-component / encoded-word
   encoded-word          =  1*( lowercase / DIGIT /
                                "+" / "-" / "/" / "_" / "=" / "?" )
   plain-component       =  component-start *component-rest
   component-start       =  lowercase / DIGIT
   lowercase             =  %x61-7A ; letter a-z lowercase
   component-rest        =  component-start / "+" / "-" / "_"

NOTE: This definition of newsgroup name is in reference to
son-of-1036-draft [SON1036]. When the current draft "News Article
Format" [USEFOR] is established as an RFC, its definitions should be
integrated into a higher protocol level of NAS.


6.3.3.1.  HELP

   Description

   This command prints a short help text on a given command. If called
   without parameters, it will display a complete list of commands.

   help-cmd =  "HELP" [WSP commandname] CRLF

   commandname =  "DATA" / "DATE" / "GETP" / "GETA" /
                  "HELP" / "HIER" / "INFO" / "LIST" /
                  "LSTR" / "QUIT" / "VERS"

   Possible answers

   100: Command overview, command description
   410: Indicates that the server is not giving any information


   help-answer =  "410" [answertext] CRLF
                  text CRLF
                  "." CRLF
   help-answer =/ "100" [answertext] CRLF
                  text CRLF
                  "." CRLF




Grau, Heinau, Schlichting, Schuettler                          [Page 12]


Internet Draft       Netnews Administration System             July 2005


   Examples

   <-- HELP
   --> 100 NAS server nas.example.org - Version 1.0

       Supported commands:
       DATA - data for a newsgroup
       DATE - show time of server in UTC
       GETP - get package
       GETA - get data from an authoritative server
       HELP - show this help
       HIER - data for a hierarchy
       INFO - show info on current connection
       LIST - list newsgroups or hierarchies
       LSTR - recursive list newsgroups or hierarchies
       QUIT - close the connection
       VERS - show or set current protocol level

       Contact address nas@example.org
       .

   <-- HELP LIST
   --> 100 LIST
       LIST - list newsgroups or hierarchies
       Syntax: LIST hierarchy ...
       Get a list of newsgroups and sub-hierarchies
       directly under the parameter hierarchy
       .

   <-- HELP NOOP
   --> 410
       unknown command "NOOP"
       .


6.3.3.2.  INFO

   Description

   Prints information about the current connection, the server, and the
   client.

   info-cmd =  "INFO" CRLF

   Possible answers

   101: Normal answer, prints some information about client
        and server



Grau, Heinau, Schlichting, Schuettler                          [Page 13]


Internet Draft       Netnews Administration System             July 2005


   400: Indicates that the server is not giving any information


   info-answer =  "400" [answertext] CRLF
                  text CRLF
                  "." CRLF
   info-answer =/ "101" [answertext] CRLF
                  text CRLF
                  "." CRLF

   Examples

   <-- INFO
   --> 101 Information follows
       Server: nas.example.org (192.0.2.100)
       Uptime: 2 weeks, 3 days, 5 hours, 9 minutes
       Software: NAS 1.0
       Client: client.example.org (192.0.2.123)
       Connection: 9 minutes
       Highest protocol level supported: 1
       Requested protocol level: 1
       Protocol level used: 1

       End
       .

   <-- INFO
   --> 400
       No information available.
       .


6.3.3.3.  DATE

   Description

   Prints the current time of the server in UTC (Universal Coordinated
   Time) in the format YYYYMMDDhhmmss, followed by an optional comment.
   The DATE command is only for informational use and to check the
   server time. For regular transmission of time over the network, the
   Network Time Protocol (NTP) [RFC1305] should be used.

   date-cmd =  "DATE" CRLF

   Possible answers

   300: Print the UTC time in specified format, see below
   511: Error, print an error message



Grau, Heinau, Schlichting, Schuettler                          [Page 14]


Internet Draft       Netnews Administration System             July 2005


   date-answer =  "511" [answertext] CRLF
                  text CRLF
                  "." CRLF
   date-answer =/ "300" [answertext] CRLF
                  utc-time [answertext] CRLF
                  "." CRLF

   Examples

   <-- DATE
   --> 300
       19990427135230 UTC
       .

   <-- DATE
   --> 511
       Time is unknown
       .


6.3.3.4.  VERS

   Description

   The VERS command is used to determine the protocol level to use
   between client and server. The parameter is a protocol level that the
   client supports and wants to use. The server will respond with the
   highest level accepted. This version number MUST not be higher than
   requested by the client. Client and server MUST only use commands
   from the level that the server has confirmed. It is possible, but
   seldom necessary, to change the protocol level during a session by
   client request (VERS [protocol level]). When no option is given, the
   current protocol level will be printed. When no protocol level is
   negotiated, the protocol level 1 will be used. Commands of a higher
   level are not allowed without successful negotiation. The protocol
   level can be followed by an optional comment.

   vers-cmd =  "VERS" [WSP level] CRLF

   level = 1*5DIGIT ; the valid range is 1 - 32767

   Possible answers

   202: Returns current protocol level
   302: Requested level accepted
   402: Requested level too high, falling back to lower level
   510: Syntax error




Grau, Heinau, Schlichting, Schuettler                          [Page 15]


Internet Draft       Netnews Administration System             July 2005


   vers-answer =  "202" [answertext] CRLF
                  level [answertext] CRLF
                  "." CRLF
   vers-answer =/ "302" [answertext] CRLF
                  level [answertext] WSP level CRLF
                  "." CRLF
   vers-answer =/ "402" [answertext] CRLF
                  level [answertext] WSP level CRLF
                  "." CRLF
   vers-answer =/ "510" [answertext] CRLF
                  level [answertext] CRLF
                  "." CRLF

   Examples

   <-- VERS
   --> 202
       2 Current protocol level is 2
       .

   <-- VERS 2
   --> 302
       2 My max protocol level is 10
       .

   <-- VERS 11
   --> 402
       10 Falling back to level 10
       .

   <-- VERS BAL
   --> 510
       1 Syntax error
       .


6.3.3.5.  QUIT

   Description

   Terminates the connection.

   quit-cmd =  "QUIT" CRLF

   Possible answers

   201: Termination of the connection




Grau, Heinau, Schlichting, Schuettler                          [Page 16]


Internet Draft       Netnews Administration System             July 2005


   quit-answer = "201" [answertext] CRLF

   Example

   <-- QUIT
   --> 201 Closing connection. Bye.


6.3.3.6.  LIST

   Description

   To obtain a list of newsgroups and sub-hierarchies in the requested
   hierarchies the command LIST is used. The status of the hierarchies
   is also given. The highest level consists of all top-level
   hierarchies and is labeled "*". It can be obtained this way, too.

   The data consist of a newsgroup- or hierarchy-name/status indicator
   pair per line. Name and status indicator must be separated by at
   least one white space. The status indicator is a single word (see
   section 6.4). The interpretation is not case sensitive.

   list-cmd =  "LIST" ( WSP "*" / 1*(WSP name)) CRLF

   Possible answers

   401: Permission denied
   510: Syntax error
   610: Normal response with all requested data

   list-answer =  "610" [answertext] CRLF
                  *(listdata CRLF)
                  "." CRLF
   list-answer =/ "401" [answertext] CRLF
                  text CRLF
                  "." CRLF
   list-answer =/ "510" [answertext] CRLF
                   text CRLF
                   "." CRLF

   listdata    =  name WSP list-status

   The list-status is the status of a newsgroup or hierarchy according
   to section 6.4.

   list-status =  "Complete"    /
                  "Incomplete"  /
                  "Obsolete"    /



Grau, Heinau, Schlichting, Schuettler                          [Page 17]


Internet Draft       Netnews Administration System             July 2005


                  "Unknown"     /
                  "Unmoderated" /
                  "Readonly"    /
                  "Moderated"   /
                  "Removed"        ; list-status is case-insensitive

   Examples

   <-- LIST *
   --> 610 data follow
       alt Incomplete
       comp Complete
       de Incomplete
       rec Complete
       sub Obsolete
       .

   <-- LIST de
   --> 610 data follow
       de.admin Complete
       de.alt Incomplete
       de.comm Complete
       de.comp Complete
       de.etc Complete
       de.markt Complete
       de.newusers Complete
       de.org Complete
       de.rec Complete
       de.sci Complete
       de.soc Complete
       de.answers Moderated
       de.test Unmoderated
       .

   <-- LIST foo
   --> 610 data follow
       foo Unknown
       .

   <-- LIST
   --> 510 Syntax error
       missing parameter hierarchy
       .

   <-- LIST de
   --> 401 Something is wrong
       Permission denied
       .



Grau, Heinau, Schlichting, Schuettler                          [Page 18]


Internet Draft       Netnews Administration System             July 2005


6.3.3.7.  LSTR

   Description

   To obtain a recursive list of newsgroups and sub-hierarchies in the
   named hierarchy, the command LSTR is used. The status of the
   hierarchies is also given. The highest level consists of all top-
   level hierarchies and is labeled "*". It can be obtained this way,
   too.

   The use of "*" as a wildcard pattern following the beginning of a
   hierarchy name is also possible; so a "LSTR de.a*" would return a
   list of all newsgroups and hierarchies starting with "de.a".

   lstr-cmd = "LSTR" ( WSP "*" / 1*(WSP name ["*" / ".*"]) ) CRLF

   Possible answers

   401: Permission denied
   510: Syntax error
   610: Normal answer with all requested data

   lstr-answer =  "610" [answertext] CRLF
                  *(listdata CRLF)
                  "." CRLF
   lstr-answer =/ "401" [answertext] CRLF
                  text CRLF
                  "." CRLF
   lstr-answer =/ "510" [answertext] CRLF
                  text CRLF
                  "." CRLF

   listdata    =  name WSP list-status

   The list-status is the status of a newsgroup or hierarchy according
   to section 6.4.

   list-status =  "Complete"    /
                  "Incomplete"  /
                  "Obsolete"    /
                  "Unknown"     /
                  "Unmoderated" /
                  "Readonly"    /
                  "Moderated"   /
                  "Removed"        ; list-status is case-insensitive






Grau, Heinau, Schlichting, Schuettler                          [Page 19]


Internet Draft       Netnews Administration System             July 2005


   Example

   <-- LSTR de.admin
   --> 610 recursive mode
       de.admin Complete
       de.admin.infos Moderated
       de.admin.lists Moderated
       de.admin.misc Unmoderated
       de.admin.net-abuse Complete
       de.admin.net-abuse.announce Moderated
       de.admin.net-abuse.mail Unmoderated
       de.admin.net-abuse.misc Unmoderated
       de.admin.net-abuse.news Unmoderated
       de.admin.news Complete
       de.admin.news.announce Moderated
       de.admin.news.groups Unmoderated
       de.admin.news.misc Unmoderated
       de.admin.news.nocem Unmoderated
       de.admin.news.regeln Unmoderated
       .


6.3.3.8.  HIER

   Description

   The command HIER lists all information available about the hierarchy.
   With data header "Name" a new data block for each hierarchy is
   started.  The header "Name" gives the name of the hierarchy. The data
   headers are described in section 6.3.4. The default is to transmit
   all available information. It can be limited to a list of desired
   headers ("Name" and "Status" are always given). A set of comma
   separated headers, as an option to the HIER command, will return the
   requested header fields.

   hier-cmd  = "HIER" 1*(WSP name) [WSP selection] CRLF

   selection = *( "," header )        ; Describes the data fields
                                      ; that are requested
   header    = ALPHA *( ALPHA / "-" ) ; According to section 6.3.4

   Example for selection:

   ,Followup,Description : for all entries list Name, Status, Followup
                           and Description






Grau, Heinau, Schlichting, Schuettler                          [Page 20]


Internet Draft       Netnews Administration System             July 2005


   Possible answers

   401: Permission denied
   510: Syntax error
   611: Regular answer with all requested data

   hier-answer =  "611" [answertext] CRLF
                  *(hierdata CRLF)
                  "." CRLF
   hier-answer =/ "510" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF
   hier-answer =/ "401" [answertext] CRLF
                  *(text CRLF)
                  "." CRLF

   hierdata    =  "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

   PGP-answer: The exact format is described in section 6.7

   Examples

   <-- HIER de
   --> 611 Data coming
       Name: de
       Status: Complete
       Serial: 20020823120306
       Description: Internationale deutschsprachige Newsgruppen
       Netiquette: http://www.kirchwitz.de.example/~amk/dni/netiquette
       FAQ: http://www.kirchwitz.de.example/~amk/dai/einrichtung
       Ctl-Send-Adr: moderator@dana.de.example
       Ctl-Newsgroup: de.admin.news.announce
       Mod-Wildcard: %s@moderators.dana.de.example
       Language: DE
       Charset: ISO-8859-1
       Encoding: text/plain
       Newsgroup-Type: Discussion
       Hier-Type: Global
       Comp-Length: 14
       Date-Create: 19920106000000

       .





Grau, Heinau, Schlichting, Schuettler                          [Page 21]


Internet Draft       Netnews Administration System             July 2005


   <-- HIER bln
   --> 401
       Permission denied
       .

   <-- HIER
   --> 510 Syntax error
       missing parameter hierarchy
       .


6.3.3.9.  DATA

   Description

   The DATA command corresponds to the HIER command as explained in
   6.3.3.8, but it is used for information about a newsgroup. A summary
   of codes can be found in section 6.3.4.

   data-cmd  = "DATA" 1*(WSP name) [WSP selection] CRLF

   Possible answers

   401: Permission denied
   510: Syntax error
   612: Regular answer with all requested data

   data-answer =  "612" [answertext] CRLF
                  *(datadata CRLF)
                  "." CRLF
   data-answer =/ "510" [answertext] CRLF
                  text CRLF
                  "." CRLF
   data-answer =/ "401" [answertext] CRLF
                  text CRLF
                  "." CRLF

   datadata    =  "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

   Examples

   <-- DATA de.comp.os.unix.linux.moderated
   --> 612 data follow
       Name: de.comp.os.unix.linux.moderated



Grau, Heinau, Schlichting, Schuettler                          [Page 22]


Internet Draft       Netnews Administration System             July 2005


       Status: Moderated
       Serial: 20020823120312
       Description: Linux und -Distributionen.
                                <dcoulm-moderators@linux-config.de.example>
       Charter: http://www.dana.de.example/mod/chartas/de.html
       Netiquette: http://www.kirchwitz.de.example/~amk/dni/netiquette
       Netiquette: ftp://ftp.fu-berlin.de.example/doc/usenet/german
                                                     /Netiquette
       Mod-Sub-Adr: dcoulm-moderators@linux-config.de.example
       Mod-Group-Info: http://wpxx02.toxi.uni-wuerzburg.de.example
                                                          /~dcoulmod/
       Newsgroup-Type: Discussion

       .

   <-- DATA de.foo
   --> 612 data follow
       Name: de.foo
       Status: Unknown

       .

   <-- DATA de
   --> 401
       Permission denied
       .

   <-- DATA
   --> 510 Syntax error
       missing parameter newsgroup
       .


6.3.3.10.  GETP

   Description

   GETP is used for server-server communication. It requests the data
   for the hierarchy specified by the parameter "name". The format of
   the data is the same as for the commands "HIER" and "LIST". If "*" is
   given as hierarchy name, all data the server is offering will be
   transmitted.

   The "timestamp" attached to a package consists of the date and time
   that the package was created. The timestamp for a package is
   transmitted together with the package data by the server and marks a
   specific revision for the package data.




Grau, Heinau, Schlichting, Schuettler                          [Page 23]


Internet Draft       Netnews Administration System             July 2005


   When a client requests a package with GETP, it transmits the
   timestamp attached to the package in its database so that the server
   can check if the data on the client side is still valid or if it is
   too old. If the data on the client side is still valid a 213 answer
   is sent, so the client knows that its data is OK. If the timestamp is
   "0", the server is forced to transmit the data. Timestamps set by the
   server must be increasing and may not be more that 12 hours in the
   future.

   The data for a successful request are signed and sent in ASCII armor
   according to [RFC2440], so a client has the possibility to check the
   signature or to ignore it. The actual data will be surrounded by the
   armor start and end sections according to section 6.2 of [RFC2440].

   getp-cmd =  "GETP" WSP username WSP password WSP timestamp
               WSP ( name / "*" ) CRLF

   username =  *1( VCHAR ) / "0" ; Length of VCHAR >= 1

   password =  *1( VCHAR ) / "0" ; Length of VCHAR >= 1

   timestamp   =  utc-time / ; date and time of the last retrieval
                  "0"        ; force the transmission of data

   Possible answers

   213: Current data at the client side
   411: No hierarchy with that name
   430: Permission denied
   510: Syntax error
   613: Hierarchy data

   getp-answer =  "613" [answertext] CRLF
                  pgp-ascii-armor-start ; this is according to [RFC2440]
                  *(getpdata CRLF)
                  pgp-ascii-armor-end   ; this is according to [RFC2440]
                  "." CRLF
   getp-answer =/ "213" [answertext] CRLF
                  text CRLF
                  "." CRLF
   getp-answer =/ "430" [answertext] CRLF
                  text CRLF
                  "." CRLF
   getp-answer =/ "411" [answertext] CRLF
                  text CRLF
                  "." CRLF
   getp-answer =/ "510" [answertext] CRLF
                  text CRLF



Grau, Heinau, Schlichting, Schuettler                          [Page 24]


Internet Draft       Netnews Administration System             July 2005


                  "." CRLF

   pgp-ascii-armor-start and the pgp-ascii-armor-end are built according
   to [RFC2440], Section 6.2., "Forming ASCII Armor".

   getpdata   =   "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  "Serial:" WSP timestamp CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer /
                    "Mod-PGP-Key:" CRLF PGP-answer)]

   Examples

   <-- GETP 0 0 0 humanities
   --> 615 data follow
       -----BEGIN PGP SIGNED MESSAGE-----
       Hash: SHA1

       Name: humanities
       Status: Complete
       Serial: 20020821094529
       Description: branches of learning that investigate human
                 constructs and concerns as opposed to natural processes
       Netiquette: ftp://rtfm.mit.edu.example/pub/usenet
                       /news.announce.newusers
                       /A_Primer_on_How_to_Work_With_the_Usenet_Community
       Rules: http://www.uvv.org.example/docs/howto.txt
       Ctl-Send-Adr: group-admin@isc.org.example
       Ctl-Newsgroup: news.announce.newgroup
       Language: EN
       Charset: US-ASCII
       Encoding: text/plain
       Newsgroup-Type: Discussion
       Hier-Type: Global
       Comp-Length: 14
       Date-Create: 19950417143009

       Name:  humanities.answers
       Status: Moderated
       Serial: 20020821094533
       Description: Repository for periodic USENET articles. (Moderated)
       Mod-Sub-Adr: news-answers@mit.edu.example
       Mod-Adm-Adr: news-answers-request@mit.edu.example
       Newsgroup-Type: Announce
       Date-Create: 19950725182040





Grau, Heinau, Schlichting, Schuettler                          [Page 25]


Internet Draft       Netnews Administration System             July 2005


       Name: humanities.classics
       [...]
       -----BEGIN PGP SIGNATURE-----
       Version: GnuPG v1.0.7 (IRIX64)

       iD8DBQE9Zj/Wn13IYldLZg8RAhWiAJ4y7o+3FzBpRjYJj2HWwXyG2g8FoQCfeEsH
       rRynPhhjveiY/XBkkrrZFho=
       =muK4
       -----END PGP SIGNATURE-----
       .

   <-- GETP 0 0 19990909101000 de
   --> 213
       You are up-to-date
       .

   <-- GETP foo
   --> 510 Syntax error
       Missing parameters
       .


   <-- GETP guest test 0 de
   --> 430
       You have no permission to retrieve the data
       .


6.3.3.11.  GETA

   Description

   The GETA command is used for server-server communication; it is used
   to collect authoritative data and will request packages that the
   server is authoritative for. A package is the authoritative data
   either for a newsgroup or a hierarchy. Each package has a "timestamp"
   attached to mark the revision of the package. This timestamp is set
   by the server and  of the date of the last modification of the
   package data in UTC format. A timestamp of "0" indicates that the
   package MUST be retrieved. If the retrieving client has a recent
   package (i.e. no modification on the authoritative server), the
   server sends only a 215 response. The format of the data is the same
   as for the commands "HIER" and "LIST".

   geta-cmd =  "GETA" WSP username WSP password WSP
               timestamp WSP name CRLF





Grau, Heinau, Schlichting, Schuettler                          [Page 26]


Internet Draft       Netnews Administration System             July 2005


   Possible answers

   215: The client already has the current data
   430: Permission denied
   411: No hierarchy with that name
   510: Syntax error
   615: Regular answer with all requested data

   geta-answer =  "615" [answertext] CRLF
                  pgp-ascii-armor-start ; this is according to [RFC2440]
                  *(getadata CRLF)
                  pgp-ascii-armor-end   ; this is according to [RFC2440]
                  "." CRLF
   geta-answer =/ "215" [answertext] CRLF
                   text CRLF
                   "." CRLF
   geta-answer =/ "430" [answertext] CRLF
                  text CRLF
                  "." CRLF
   geta-answer =/ "411" [answertext] CRLF
                  text CRLF
                  "." CRLF
   geta-answer =/ "510" [answertext] CRLF
                  text CRLF
                  "." CRLF

   getadata   =   "Name:" WSP text CRLF
                  "Status:" WSP text CRLF
                  "Serial:" WSP timestamp CRLF
                  *(header ":" WSP text CRLF)
                  [("Ctl-PGP-Key:" CRLF PGP-answer/
                    "Mod-PGP-Key:" CRLF PGP-answer)]

   Example

   <-- GETA 0 0 0 humanities
   --> 613 data follow
       -----BEGIN PGP SIGNED MESSAGE-----
       Hash: SHA1

       Name: humanities
       Status: Complete
       Serial: 20020821094529
       Description: branches of learning that investigate human
                 constructs and concerns as opposed to natural processes
       Netiquette: ftp://rtfm.mit.edu.example/pub/usenet
                       /news.announce.newusers
                       /A_Primer_on_How_to_Work_With_the_Usenet_Community



Grau, Heinau, Schlichting, Schuettler                          [Page 27]


Internet Draft       Netnews Administration System             July 2005


       Rules: http://www.uvv.org.example/docs/howto.txt
       Ctl-Send-Adr: group-admin@isc.org.example
       Ctl-Newsgroup: news.announce.newgroup
       Language: EN
       Charset: US-ASCII
       Encoding: text/plain
       Newsgroup-Type: Discussion
       Hier-Type: Global
       Comp-Length: 14
       Date-Create: 19950417143009

       Name:  humanities.answers
       Status: Moderated
       Serial: 20020821094533
       Description: Repository for periodic USENET articles. (Moderated)
       Mod-Sub-Adr: news-answers@mit.edu.example
       Mod-Adm-Adr: news-answers-request@mit.edu.example
       Newsgroup-Type: Announce
       Date-Create: 19950725182040

       Name: humanities.classics
       [...]
       -----BEGIN PGP SIGNATURE-----
       Version: GnuPG v1.0.7 (IRIX64)

       iD8DBQE9Zj/Wn13IYldLZg8RAhWiAJ4y7o+3FzBpRjYJj2HWwXyG2g8FoQCfeEsH
       rRynPhhjveiY/XBkkrrZFho=
       =muK4
       -----END PGP SIGNATURE-----
       .


6.3.3.12.  Unknown Commands and Syntax Errors

   If a command is recognized as unknown, a 519 return code (unknown
   command) is given. If an error occurs after the command string (e.g.
   a missing parameter) a 510 return code (Syntax error: Missing
   parameter) is given.



6.3.4.  Data Headers

   The following paragraphs describe keywords and key terms which
   support retrieval and storing of information. Every header has a
   unique English name.

   The content of a header is inheritable within a hierarchy, as long as



Grau, Heinau, Schlichting, Schuettler                          [Page 28]


Internet Draft       Netnews Administration System             July 2005


   the header is marked as inheritable. The content is the default value
   for all downstream newsgroups and sub-hierarchies. For example in the
   hierarchy "de", the language header has the value "DE" (German),
   therefore this value is "DE" for all newsgroups in this hierarchy,
   except for those which explicitly define a language code of their
   own.

   Hierarchies and newsgroups must have at least values for the headers
   "Name" and "Status". Unknown hierarchies or groups get the status
   "Unknown".

   The header used in the NAS protocol are not case sensitive. A header
   may be upper case, lower case, or any mixture of upper and lower
   case. It is recommended that the first letter of the header and the
   first letter after a dash are uppercase while all other characters
   are lowercase.

   Name

   Header:      Name

   Used for:    hierarchy
   Mandatory:   yes
   Inheritable: no
   Repeatable:  no
   Description: Name of a hierarchy
   Comment:     Start of a new data block
   Example:     Name: comp

   Used for:    newsgroup
   Mandatory:   yes
   Repeatable:  no
   Description: Name of a newsgroup
   Comment:     Start of a new data block
   Example:     Name: de.admin.news.announce
















Grau, Heinau, Schlichting, Schuettler                          [Page 29]


Internet Draft       Netnews Administration System             July 2005


   Status

   Header:      Status

   Used for:    hierarchy
   Mandatory:   yes
   Inheritable: no
   Repeatable:  no
   Description: Status of a hierarchy
   Comment:     For a detailed description see section 6.4.
   Example:     Status: Hierarchy-Complete

   Used for:    newsgroup
   Mandatory:   yes
   Repeatable:  no
   Description: Status of a newsgroup
   Comment:     For a detailed description see section 6.4.
   Example:     Status: Group-Moderated


   Serial

   Header:      Serial

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: no
   Repeatable:  no
   Description: Timestamp for hierarchy data
   Comment:     For a detailed description see section 6.4.
   Example:     Serial: 20020821102413

   Used for:    newsgroup
   Mandatory:   no
   Inheritable: no
   Repeatable:  no
   Description: Timestamp for newsgroup data
   Comment:     For a detailed description see section 6.4.
   Example:     Serial: 20020821102413












Grau, Heinau, Schlichting, Schuettler                          [Page 30]


Internet Draft       Netnews Administration System             July 2005


   Group for followup

   Header:      Followup

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  no
   Description: Name of the newsgroup that will take the followup
                postings of a moderated group.
   Comment:     The value can be used as default value for the
                "Followup-To:" header on postings to a moderated group.
                This value is only useful on groups that which are moderated
                (Status Group-Moderated) and have a dedicated discussion group.
   Example:     Followup: bln.announce.fub.zedat.d
                (for the moderated group bln.announce.fub.zedat)


   Short description

   Header:      Description

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: no
   Repeatable:  no
   Description: Short description of a hierarchy
   Example:     Description: Angelegenheiten, die den Grossraum Berlin
                                                             betreffen
                (for the hierarchy bln)

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  no
   Description: Short description of a newsgroup
   Comment:     This information is often presented to the news reader
                upon selection of the newsgroup, and it should be a
                brief but meaningful description of the topic
   Example:     Description: Technisches zur Newssoftware
                (for de.admin.news.software)












Grau, Heinau, Schlichting, Schuettler                          [Page 31]


Internet Draft       Netnews Administration System             July 2005


   Charter-URL

   Header:      Charter

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: no
   Repeatable:  yes
   Description: URL that points to the charter of a hierarchy
   Example:     Charter: ftp://ftp.fu-berlin.de.example/doc/news/bln/bln
                (for the hierarchy bln)

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: URL that points to the charter of a newsgroup
   Comment:     This information should be presented to the
                news reader upon selection of the newsgroup.
   Example:     Charter: ftp://ftp.fu-berlin.de.example/doc/news/bln
                                                    /bln.markt.arbeit


   Netiquette-URL

   Header:      Netiquette

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes
   Description: URL that points to the netiquette of a hierarchy.
   Comment:     Since the netiquettes are often valid for
                a complete hierarchy this is inheritable.
   Example:     Netiquette: http://www.kirchwitz.de.example/~amk/dni/netiquette

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: URL for Netiquette
   Comment:     If a group has some special rules, this is the
                pointer to these rules.
   Example:     Netiquette: http://go.to.example/bln.markt
                (for bln.markt)








Grau, Heinau, Schlichting, Schuettler                          [Page 32]


Internet Draft       Netnews Administration System             July 2005


   Frequently Asked Questions (FAQ)

   Header:      FAQ

   Used for:    Newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: URL for the FAQ of a newsgroup
   Example:     FAQ: http://www.dard.de.example/


   Administration rules

   Header:      Rules

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes
   Description: URL pointing to a document that describes the rules for
                creating, deleting or renaming newsgroups in this
                hierarchy.
   Comment:     Normally inherited from the toplevel hierarchy
   Example:     Rules: http://www.kirchwitz.de.example/~amk/dai
                                                           /einrichtung


   Control Email

   Header:      Ctl-Send-Adr

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes
   Description: Email address of the sender of control messages
   Comment:     Multiple addresses are valid
   Example:     Ctl-Send-Adr: group-admin@isc.org.example













Grau, Heinau, Schlichting, Schuettler                          [Page 33]


Internet Draft       Netnews Administration System             July 2005


   Control newsgroup

   Header:      Ctl-Newsgroup

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes
   Description: Name of the newsgroup that will get the postings for
                checkgroups, rmgroup and newsgroup control messages.
   Example:     Ctl-Newsgroup: de.admin.news.groups


   Moderators

   Header:      Mod-Wildcard

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  no
   Description: Moderator wildcard for this hierarchy.
   Comment:     This information can be used for the configuration of the
                news software, for example, to configure the moderators
                file in INN.
   Example:     Mod-Wildcard: %s@moderators.dana.de.example
                (for the hierarchy de)


   Submission address

   Header:      Mod-Sub-Adr

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: Email address for submissions to the newsgroup.
   Comment:     If there is no "Mod-Sub-Adr" for a moderated newsgroup,
                "Mod-Wildcard" of the hierarchy is used. This is useful
                only for moderated groups (Status Group-Moderated).
   Example:     Mod-Sub-Adr: news-answers@mit.edu.example
                (for the newsgroup news.answers)









Grau, Heinau, Schlichting, Schuettler                          [Page 34]


Internet Draft       Netnews Administration System             July 2005


   Moderator's address (email)

   Header:      Mod-Adm-Adr

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: Email address of the moderator of the newsgroup.
   Comment:     If there is no code "Mod-Adm-Adr" for a moderated
                newsgroup, "Mod-Wildcard" of the hierarchy is used.
                This is useful only for moderated groups
                (Status Group-Moderated).
   Example:     Mod-Adm-Adr: news-answers-request@mit.edu.example
                (for the newsgroup news.answers)


   Info-URL

   Header:      Mod-Group-Info

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: URL that points to a document where the moderator
                presents information about the newsgroup and the
                submission of articles.
   Example:     Mod-Group-Info: http://www.example.org/cola-submit.html
                (for comp.os.linux.announce)























Grau, Heinau, Schlichting, Schuettler                          [Page 35]


Internet Draft       Netnews Administration System             July 2005


   Language

   Header:      Language

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes
   Description: The language that will normally be used in postings
   Comment:     The notation is according to the "Content-Language"
                field of [RFC2616]. The languages not
                preferred are enclosed in parenthesis.
   Example:     Language: DE
                (for the hierarchy de)

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: The language that will normally be used in postings.
   Comment:     The notation is according to the "Content-Language"
                field of [RFC2616]. The languages not
                preferred are enclosed in parenthesis.
   Example:     Language: TR
                Language: DE
                Language: (EN)
                (for the newsgroup bln.kultur.tuerkisch)

























Grau, Heinau, Schlichting, Schuettler                          [Page 36]


Internet Draft       Netnews Administration System             July 2005


   Charset

   Header:      Charset

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes
   Description: Charset that will normally be used in postings in this
                hierarchy
   Comment:     The complete set of charset names is defined by
                [RFC2277] and the IANA Character Set registry [IANA-CS].
                The charsets that are not the preferred charsets are
                enclosed in parenthesis.
   Example:     Charset: ISO-8859-1
                (for the hierarchy de)

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: Charset that will normally be used in
                postings in this group
   Comment:     The complete set of charset names is defined by
                [RFC2277] and the IANA Character Set registry
                [IANA-CS]. The charsets that are not the preferred
                charsets are enclosed in parenthesis.
   Example:     Charset: ISO-8859-9
                Charset: ISO-8859-1
                (for the newsgroup bln.kultur.tuerkisch)






















Grau, Heinau, Schlichting, Schuettler                          [Page 37]


Internet Draft       Netnews Administration System             July 2005


   Encoding

   Header:      Encoding

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes
   Description: Encoding for this hierarchy according to MIME [RFC2045]
   Comment:     This is the media type used in this hierarchy, a list of
                registered media types can be found at [IANA-MT]. The
                encodings not preferred are
                enclosed in parenthesis.
   Example:     Encoding text/plain

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: Encoding for this newsgroup according to MIME [RFC2045]
   Comment      This is the media type used in this newsgroup, a list of
                registered media types can be found at [IANA-MT]. The
                encodings not preferred are
                enclosed in parenthesis.
   Example:     Encoding: text/plain



























Grau, Heinau, Schlichting, Schuettler                          [Page 38]


Internet Draft       Netnews Administration System             July 2005


   Type of newsgroup

   Header:      Newsgroup-Type

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes
   Description: Default newsgroup type in this hierarchy
   Comment:     This header has no concrete meaning for a hierarchy but
                is used for the inheritance to newsgroups in the
                hierarchy.
                Specification of the types can be found in section 6.5
   Example:     Newsgroup-Type: Discussion
                (for the hierarchy de)

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: Type of newsgroup
   Comment:     Specification of the types can be found in section 6.5
   Example:     Newsgroup-Type: Announce
                (for de.admin.news.announce)


   Type of hierarchy

   Header:      Hier-Type

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes
   Description: Type of hierarchy
   Comment:     Specification of the types can be found in section 6.6
   Example:     Hier-Type: Regional
                (for hierarchy bln)














Grau, Heinau, Schlichting, Schuettler                          [Page 39]


Internet Draft       Netnews Administration System             July 2005


   Regional or Organizational Area

   Header:      Area

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes
   Description: Description of the geographical region or organization
                of this hierarchy
   Comment:     This code is useful when the hierarchy type
                (Hier-Type) is "Regional" or "Organization".
   Example:     Area: Grossraum Berlin
                (for the hierarchy bln)


   Name length of group names

   Header:      Name-Length

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  no
   Description: Maximum length of a newsgroup name
   Example:     Name-Length: 72
                (for the hierarchy bln)


   Component length of group names

   Header:      Comp-Length

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  no
   Description: Maximum length of a single component in the newsgroup
                name
   Example:     Comp-Length: 14
                (for the hierarchy de)










Grau, Heinau, Schlichting, Schuettler                          [Page 40]


Internet Draft       Netnews Administration System             July 2005


   Article length

   Header:      Article-Length

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  no
   Description: Maximum length of an article in bytes
   Comment:     This header has no concrete meaning for a hierarchy, but
                is used for the inheritance to newsgroups in the
                hierarchy.
   Example:     Article-Length: 50000

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  no
   Description: Maximum length of an article in bytes
   Example:     Article-Length: 50000


   Date of creation

   Header:      Date-Create

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  no
   Description: Creation date of a hierarchy, can even be in the future.
   Comment:     The format is the same as in the DATE command.
   Example:     Date-Create: 19970330101514

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  no
   Description: Creation date of a newsgroup, can even be in the future.
   Comment:     The format is the same as in the DATE command.
   Example:     Date-Create: 19970330101514












Grau, Heinau, Schlichting, Schuettler                          [Page 41]


Internet Draft       Netnews Administration System             July 2005


   Date of removal

   Header:      Date-Delete

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  no
   Description: Date of removal of a hierarchy, can even be in the
                future.
   Comment:     The format is the same as in the DATE command.
   Example:     Date-Delete: 19970330101514

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  no
   Description: Date of removal of a newsgroup, can even be in the
                future.
   Comment:     The format is the same as in the DATE command.
   Example:     Date-Delete: 19970330101514


   Successor

   Header:      Replacement

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: no
   Repeatable:  yes
   Description: Name of the hierarchy that replaced a removed hierarchy
                if status is "Hierarchy-Obsolete" or will replace a
                hierarchy if the date of removal is in the future.
   Example:     Replacement: de
                (for the hierarchy sub)

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: Name of the newsgroup or newsgroups that will replace a
                removed newsgroup if status is  "Group-Removed" or will
                replace the newsgroup if the date of removal is in the
                future.
   Example:     Replacement: bln.markt.arbeit
                (for bln.jobs)






Grau, Heinau, Schlichting, Schuettler                          [Page 42]


Internet Draft       Netnews Administration System             July 2005


   Source

   Header: Source

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  no
   Description: Pointer to an organization or person responsible
                for this hierarchy. SHOULD be a URL or an email address.
   Example:     Source: http://www.dana.de.example/mod/
                (for the hierarchy de)

NOTE: This is for tracking the maintainer of a hierarchy


   Control PGP key

   Header:      Ctl-PGP-Key

   Used for:    hierarchy
   Mandatory:   no
   Inheritable: yes
   Repeatable:  yes
   Description: PGP key (with additional information: key owner, key-id,
                etc.) of the sender of control messages in this
                hierarchy.
   Comment:     The exact format is described in section 6.7.
   Example:     Ctl-PGP-Key:
                U de.admin.news.announce
                B 1024
                I D3033C99
                L http://www.dana.de.example/mod/pgp/dana.asc
                L ftp://ftp.isc.org.example/pub/pgpcontrol/PGPKEYS.gz
                F 5B B0 52 88 BF 55 19 4F  66 7D C2 AE 16 26 28 25
                V 2.6.3ia
                K------BEGIN PGP PUBLIC KEY BLOCK-----
                K-Version: 2.6.3ia
                K-
                K-mQCNEALZ+Xfm/WDCEMXM48gK1PlKG6TkV3SLbXt4CnzpGM0tOMa
                K-HjlHqM1wEGUHD5hw/BL/heR5Tq+C5IEyXQQmYwkrgeVFMOz/rAQ
                [...]
                K-SDw+iQgAAtN6zrYOhHFBp+
                K-VpvRovMz+lSOy9Zcsbs+5t8Pj9ZVAQyfxBkqD5A=
                K-=Xwgc
                K -----END PGP PUBLIC KEY BLOCK-----





Grau, Heinau, Schlichting, Schuettler                          [Page 43]


Internet Draft       Netnews Administration System             July 2005


   Moderator's PGP key

   Header:      Mod-PGP-Key

   Used for:    newsgroup
   Mandatory:   no
   Repeatable:  yes
   Description: Public PGP key (with additional information: key owner,
                key-id, etc) of this newsgroup's moderator.
   Comment:     The exact format is described in section 6.7
   Example:     see section 6.7


6.4.  Status Indicators

   The status indicator uniquely determines the status of a hierarchy or
   newsgroup. The indicator is case-insensitive.

  Indicator     Type        Description
  -----------   ---------   -------------------------------------------
  Complete      hierarchy   authorized, complete known hierarchy
  Incomplete    hierarchy   not completely known hierarchy (like free.*)
  Obsolete      hierarchy   obsolete  hierarchy,  should  contain   only
                            newsgroups with status "Removed"
  Unknown       hierarchy   no information available, unknown hierarchy
  Unmoderated   newsgroup   posting allowed, unmoderated
  Readonly      newsgroup   posting not allowed
  Moderated     newsgroup   moderated group, articles must  be  sent  to
                            the moderator
  Removed       newsgroup   deleted or renamed newsgroup, no posting  or
                            transport
  Unknown       newsgroup   unknown group, no information available
  -----------   ---------   -------------------------------------------



6.5.  Newsgroup Types

   A Newsgroup Type is a comprehensive overview about some
   characteristics of a newsgroup, being a test group, a binary group
   and so on. The Newsgroup Type is case-insensitive.










Grau, Heinau, Schlichting, Schuettler                          [Page 44]


Internet Draft       Netnews Administration System             July 2005



   Type          Meaning
   -----------   ------------------------------------------------------
   Discussion    discussion (text postings)
   Binary        (encoded) binary postings
   Sources       source postings (e.g., comp.unix.sources)
   Announce      announcements, press releases, RfD/CfV
   Test          test postings, sometimes reflectors (e.g., de.test)
   Robots        automatic postings (like the former comp.mail.maps)
   Experiment    experimental, other
   -----------   ------------------------------------------------------



6.6.  Hierarchy Types

   To describe a hierarchy the following Hierarchy Types are used. These
   Types are used to mark some properties of a news hierarchy. They are
   case-insensitive.

   Type             Meaning
   --------------   ---------------------------------------------------
   Global           international, global hierarchy
                    (e.g., the hierarchies comp, de, rec)
   Regional         regional hierarchy
                    (e.g., the hierarchies ba, bln, tor)
   Alt              alternative hierarchy, simpler rules for
                    creating a group, no formal structure
                    (e.g., the hierarchy alt)
   Non-Commercial   only for personal use, commercial use is prohibited
                    (e.g., the hierarchy de)
   Commercial       commercial use permitted (e.g., the hierarchy biz)
   Organization     hierarchy bound to an organization
                    (e.g., the hierarchy gnu)
   --------------   ---------------------------------------------------



6.7.  PGP Keys

   PGP keys for Ctrl-PGP-Key and Mod-PGP-Key are transmitted in the
   following structure:

   PGP-answer = "V" SP Version CRLF
                "U" SP User-ID CRLF
                "B" SP Bits CRLF
                "I" SP Key-ID CRLF
                "F" SP Finger CRLF



Grau, Heinau, Schlichting, Schuettler                          [Page 45]


Internet Draft       Netnews Administration System             July 2005


                *("L" SP Location CRLF)
                *("K-" Keyblock CRLF)
                "K" SP Keyblock CRLF

   Version  = text
   User-ID  = text
   Bits     = text
   Key-ID   = text
   Finger   = text
   Location = text
   Keyblock = text


   Key   Name        Mandatory   Description
   ---   ---------   ---------   --------------------------------------
   K     Keyblock    yes         public key block in ASCII armor format
                                 [RFC2440]
   V     Version     yes         PGP-Version
   U     User-ID     no          key user id
   B     Bits        no          number of bits
   I     Key-ID      no          key id, without leading "0x"
   F     Finger      no          fingerprint
   L     Location    no          URL that points to the public key
   ---   ---------   ---------   --------------------------------------


   A hyphen following the code indicates that the block is continued on
   the next line. In the last message row, there MUST be white space
   after the code; this is also true for a single line code.

    Example

   <-- HIER de
   --> 611 Data coming
       Name: de
       Status: Hierarchy
       [...]
       Ctl-PGP-Key:
       U de.admin.news.announce
       B 1024
       I D3033C99
       L http://www.dana.de.example/mod/pgp/dana.asc
       L ftp://ftp.fu-berlin.de.example/unix/news/pgpcontrol/PGPKEYS.gz
       F 5B B0 52 88 BF 55 19 4F  66 7D C2 AE 16 26 28 25
       V 2.6.3ia
       K------BEGIN PGP PUBLIC KEY BLOCK-----
       K-Version: 2.6.3ia
       K-



Grau, Heinau, Schlichting, Schuettler                          [Page 46]


Internet Draft       Netnews Administration System             July 2005


       K-mQCNAzGeB/YAAAEEALZ+Xfm/WDCEMXM48gK1PlKG6TkV3SLbXt4CnzpGMtOM
       K-HjlHaU6Xco5ijAuqM1wEGUHD5hw/BL/heR5Tq+C5IEyXQQmYwkrgeVFMO/rA
       [...]
       K-SDw+Id0JPFO9AWOiQgAAtN6zrYOhHFBp+68h9k674Yg9IHqj3BWdRjJF6PKo
       K-VpvRovMz+lSOy9Zcsbs+5t8Pj9ZVAQyfxBkqD5A=
       K-=Xwgc
       K -----END PGP PUBLIC KEY BLOCK-----
       [...]

       .



7.  Specification of the NAS Protocol (UDP)

   UDP is intended for reading programs (news readers), it is not in the
   scope of this document, and the use of UDP for NAS will be described
   in a separate paper.


8.  IANA Considerations

   IANA is asked to register the application/nasdata media type as
   defined by the following information:

   Media type name:     application
   Media subtype name:  nasdata
   Required parameters: none
   Optional parameters: level

                        The NAS protocol level number for the enclosed NAS
                        data package. If not present, the protocol level
                        defaults to 1.

   Encoding scheme: NAS data is plain text; no special encodings are needed.

   Security considerations: see below


9.  Security Considerations

   Security issues are only addressed in respect to server-server
   communication in this protocol level. Username and password
   combinations in the GETA and GETP commands can be used to make sure
   that connections are only accepted from authorized clients. PGP keys
   according to [RFC2440] are used to sign NAS data in server-server
   communication in order to validate that data is authentic and has not
   been tampered with.



Grau, Heinau, Schlichting, Schuettler                          [Page 47]


Internet Draft       Netnews Administration System             July 2005


   Every server does have the possibility (in both server-server and
   server-client communication) to deny some commands or the whole
   connection based on the client's IP number.

   No mechanisms are defined in the current protocol level to allow a
   client to validate that it is talking to a legitimate server and/or
   that the data it receives is authentic.

   A stronger authentication scheme will be provided in a higher
   protocol level.



10.  Response Codes (Overview)

   Code   Description
   ----   --------------------------------------------------------------
   100    Command overview, Information, command description (HELP)
   101    Information about connection, client and server (INFO)
   200    Greeting message (Connection Setup)
   201    Termination of the connection (QUIT)
   202    Returns current protocol level (VERS)
   213    Valid data at the client side (GETP)
   215    The client already has the current data (GETA)
   300    Time in UTC (DATE)
   302    Answer to a successful request (VERS)
   400    Indicates that the server is not giving any information (INFO)
   401    Permission denied (LIST, LSTR, HIER, DATA)
   402    Requested level too high, falling back to lower level (VERS)
   404    Server currently out of service (Connection Setup)
   410    Indicates that the server is not giving any information (HELP)
   411    No hierarchy with that name (GETP, GETA)
   430    Permission denied (GETP, GETA)
   434    Client has no permission to talk to server (Connection Setup)
   510    Syntax error
   511    Internal error (TIME)
   513    Line too long
   519    Unknown command
   610    Regular answer with all requested data (LIST, LSTR)
   611    Regular answer with all requested data (HIER)
   612    Regular answer with all requested data (DATA)
   613    hierarchy data (GETP)
   615    Regular answer with all requested data (GETA)
   ----   --------------------------------------------------------------







Grau, Heinau, Schlichting, Schuettler                          [Page 48]


Internet Draft       Netnews Administration System             July 2005


11.  Data Headers for DATA and HIER Commands (Overview)

    Header           Mandatory   Use   Multiple   Description
    -------------    ---------   ---   --------   ---------------------
    Name             yes         H/N   no         Name of a hierarchy
                                                  or newsgroup (Start
                                                  of a new data block)
    Status           yes         H/N   no         Status of hierarchy
                                                  or newsgroup
    Serial           no          H/N   no         Revision of hierarchy
                                                  / newsgroup data
    Followup         no           N    no         Group for followup
    Description      no          H/N   no         Short description of
                                                  a hierarchy/newsgroup
    Charter          no          H/N   yes        Charter-URL
    Netiquette       no          H/N   yes        Netiquette-URL
    FAQ              no           N    yes        FAQ-URL
    Rules            no           H    yes        Administration rules
                                                  URL
    Ctl-Send-Adr     no           H    yes        Control email
    Ctl-Newsgroup    no           H    yes        Control newsgroup
    Mod-Wildcard     no           H    no         Moderator wildcard
    Mod-Sub-Adr      no           N    no         Submission address
    Mod-Adm-Adr      no           N    yes        Moderator's address
                                                  (email)
    Mod-Group-Info   no           N    yes        Info-URL
    Language         no          H/N   yes        Language
    Charset          no          H/N   yes        Charset
    Encoding         no          H/N   yes        Encoding
    Newsgroup-Type   no          H/N   yes        Type of newsgroup
    Hier-Type        no           H    yes        Type of hierarchy
    Area             no           H    yes        Regional or
                                                  organizational area
    Name-Length      no           H    no         Total length of group
                                                  names
    Comp-Length      no           H    no         Component length of
                                                  group names
    Article-Length   no           H    no         Article length
    Date-Create      no          H/N   no         Date of creation
    Date-Delete      no          H/N   no         Date of removal
    Replacement      no          H/N   yes        Successor
    Source           no           H    yes        Source of data
    Ctl-PGP-Key      no           H    yes        Control PGP key
    Mod-PGP-Key      no           N    yes        Moderator's PGP key
    -------------    ---------   ---   --------   ---------------------

   N: Newsgroup, H: Hierarchy




Grau, Heinau, Schlichting, Schuettler                          [Page 49]


Internet Draft       Netnews Administration System             July 2005


12.  References


12.1.  Normative References

   [IANA-CS] IANA: Character Sets,
             http://www.iana.org/assignments/character-sets

   [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail
             Extensions (MIME) Part One: Format of Internet Message
             Bodies.", RFC 2045, Innosoft/First Virtual, November 1996.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, Harvard University,
             March 1997.

   [RFC2234] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
             Specifications: ABNF", RFC 2234, November 1997.

   [RFC2277] H. Alvestrand, "IETF Policy on Character Sets and
             Languages", RFC 2277, January 1998.

   [RFC2440] J. Callas, L. Donnerhacke, H. Finney, R. Thayer,
             "OpenPGP Message Format", RFC 2440, November 1998.

   [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,
             P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol --
             HTTP/1.1", RFC 2616, June 1999.


12.2.  Informative References

   [IANA-MT] IANA: Media Types,
             http://www.iana.org/assignments/

   [IANA-PN] IANA: Assigned Port Numbers,
             http://www.iana.org/assignments/port-numbers

   [ISC-INN] ISC: Internet Software Consortium,
             ftp://ftp.isc.org/isc/inn/

   [RFC1305] D.L. Mills, "Network Time Protocol", RFC 1305,
             University of Delaware, March 1992.

   [SON1036] H. Spencer, "News Article Format and Transmission",
             A Draft for an RFC 1036 Successor,
             ftp://zoo.toronto.edu/pub/news.txt.Z.




Grau, Heinau, Schlichting, Schuettler                          [Page 50]


Internet Draft       Netnews Administration System             July 2005


   [USEFOR]  USEFOR Working Group, "News Article Format",
             draft-ietf-usefor-article-14.


13.  Author's Address

   Philipp Grau, Vera Heinau, Heiko Schlichting, Robert Schuettler
   Freie Universitaet Berlin
   ZEDAT, DFN-CIS
   Fabeckstr. 32
   14195 Berlin
   Germany

   Phone: +49 30 838-56583
   Fax:   +49 30 838-56721

   Email: nas@fu-berlin.de
   WWW: http://nas.fu-berlin.de/


14.  Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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/S HE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.


15.  Intellectual Property

   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 ISOC's procedures with respect to rights in ISOC Documents can
   be found in BCP 78 and BCP 79.




Grau, Heinau, Schlichting, Schuettler                          [Page 51]


Internet Draft       Netnews Administration System             July 2005


   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.

   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@ietf.org.

   Expires January 12, 2006





































Grau, Heinau, Schlichting, Schuettler                          [Page 52]