From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4707.txt | 2747 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2747 insertions(+) create mode 100644 doc/rfc/rfc4707.txt (limited to 'doc/rfc/rfc4707.txt') diff --git a/doc/rfc/rfc4707.txt b/doc/rfc/rfc4707.txt new file mode 100644 index 0000000..83af738 --- /dev/null +++ b/doc/rfc/rfc4707.txt @@ -0,0 +1,2747 @@ + + + + + + +Network Working Group P. Grau +Request for Comments: 4707 V. Heinau +Category: Experimental H. Schlichting + R. Schuettler + Freie Universitaet Berlin + October 2006 + + + Netnews Administration System (NAS) + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +IESG Note + + This RFC is not a candidate for any level of Internet Standard. The + IETF disclaims any knowledge of the fitness of this RFC for any + purpose, and in particular notes that the decision to publish is not + based on IETF review for such things as security, congestion control + or inappropriate interaction with deployed protocols. The RFC Editor + has chosen to publish this document at its discretion. Readers of + this document should exercise caution in evaluating its value for + implementation and deployment. + +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. + + The database is accessible by news servers, news administrators, and + 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, which provides + detailed information about groups and hierarchies to the user. + + + + + +Grau, et al. Experimental [Page 1] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Overview ........................................................4 + 3. Protocol Level ..................................................5 + 4. Description of Functions ........................................6 + 5. Definitions .....................................................7 + 6. Specification of the NAS Protocol (TCP) .........................8 + 6.1. Responses ..................................................8 + 6.1.1. Overview ............................................8 + 6.1.2. Response Code Values, Structure, and Meaning ........8 + 6.2. Connection Setup ...........................................9 + 6.3. Commands ..................................................10 + 6.3.1. Structure ..........................................10 + 6.3.2. Overview ...........................................10 + 6.3.3. Detailed Description ...............................10 + 6.3.3.1. HELP ......................................11 + 6.3.3.2. INFO ......................................12 + 6.3.3.3. DATE ......................................13 + 6.3.3.4. VERS ......................................14 + 6.3.3.5. QUIT ......................................15 + 6.3.3.6. LIST ......................................16 + 6.3.3.7. LSTR ......................................18 + 6.3.3.8. HIER ......................................19 + 6.3.3.9. DATA ......................................21 + 6.3.3.10. GETP .....................................22 + 6.3.3.11. GETA .....................................25 + 6.3.3.12. Unknown Commands and Syntax Errors .......27 + 6.3.4. Data Headers .......................................27 + 6.4. Status Indicators .........................................41 + 6.5. Newsgroup Types ...........................................41 + 6.6. Hierarchy Types ...........................................42 + 6.7. PGP Keys ..................................................42 + 7. Specification of the NAS Protocol (UDP) ........................44 + 8. IANA Considerations ............................................44 + 9. Security Considerations ........................................44 + 10. Response Codes (Overview) .....................................45 + 11. Data Headers for DATA and HIER Commands (Overview) ............45 + + + + + +Grau, et al. Experimental [Page 2] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 12. References ....................................................46 + 12.1. Normative References .....................................46 + 12.2. Informative References ...................................47 + +1. Introduction + + An 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. 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 are 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 not an active group but a + dead or invalid one. + + It is the design goal of Netnews Administration System (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 Network News Transfer Protocol + (NNTP) commands. The advantage of NAS is that it provides more + information in a more structured format than that of 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 for + transmitting information than that for control messages. + + + +Grau, et al. Experimental [Page 3] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + Furthermore, it is possible to check for changes on a regular basis + at customized intervals to keep local data up-to-date. + +2. Overview + + NAS is based on a database that contains information about certain + groups and hierarchies. This database is structured in a + hierarchical manner and distributed to various servers, and it is + able to receive queries at any time. The service is comparable to + directory services like DNS, Lightweight Directory Access Protocol + (LDAP), or Network Information Service (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 Numbers Authority + (IANA) [IANA-PN]. + + The organizational structure of NAS is hierarchical; this means that + 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 that of the current Usenet system, where some + hierarchies have a good administration with a well-defined system of + rules, and where 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 (e.g., BIG8, de.*, us.*, bln.*, fr.*, it.*). + + 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) or to use another NAS server for special + hierarchies. + + + + + + + +Grau, et al. Experimental [Page 4] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + .............. .............. ................... + . 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 and 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 that of 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 + 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 + + + +Grau, et al. Experimental [Page 5] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 an 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 makes + it possible 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, et al. Experimental [Page 6] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + ............ 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 at + another server) are accomplished in several steps: 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, et al. Experimental [Page 7] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + +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 that it should 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, et al. Experimental [Page 8] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 5xx Request is wrong (syntax error), is 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, et al. Experimental [Page 9] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + +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 uppercase, lowercase, or any mixture of + upper- and lowercase. + + 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 [RFC4234]. The definitions for 'ALPHA', + 'CRLF', 'DIGIT', 'WSP' and 'VCHAR' are taken from appendix B of + [RFC4234] and not repeated here. + + The following ABNF definitions constitute the set of NAS commands + that can be sent from the client to an NAS server. + +6.3.3. Detailed Description + + Some overall definitions follow: + + 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 + + response-code = 3DIGIT ; three digit number + + + +Grau, et al. Experimental [Page 10] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 "News + Article Format and Transmission" [SON1036]. When the document "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 + + Examples + + <-- HELP + + + +Grau, et al. Experimental [Page 11] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + --> 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 + + 400: Indicates that the server is not giving any information + + + + + +Grau, et al. Experimental [Page 12] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 + + date-answer = "511" [answertext] CRLF + text CRLF + "." CRLF + + + +Grau, et al. Experimental [Page 13] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 that 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 + + vers-answer = "202" [answertext] CRLF + level [answertext] CRLF + "." CRLF + + + + +Grau, et al. Experimental [Page 14] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 + + quit-answer = "201" [answertext] CRLF + + + + + + +Grau, et al. Experimental [Page 15] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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" / + "Unknown" / + "Unmoderated" / + "Readonly" / + + + +Grau, et al. Experimental [Page 16] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + "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, et al. Experimental [Page 17] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + +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, et al. Experimental [Page 18] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 the 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 + + Possible answers + + 401: Permission denied + + + +Grau, et al. Experimental [Page 19] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 + + . + + <-- HIER bln + --> 401 + Permission denied + . + + + +Grau, et al. Experimental [Page 20] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + <-- 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 + Status: Moderated + Serial: 20020823120312 + Description: Linux und -Distributionen. + + Charter: http://www.dana.de.example/mod/chartas/de.html + Netiquette: http://www.kirchwitz.de.example/~amk/dni/netiquette + + + +Grau, et al. Experimental [Page 21] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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. + + 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 whether 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. + + + + +Grau, et al. Experimental [Page 22] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + Timestamps set by the server must be increasing and may not be more + than 12 hours in the future. + + The data for a successful request are signed and sent in ASCII armor + according to [RFC2440], so a client can check the signature or 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 + "." CRLF + + pgp-ascii-armor-start and the pgp-ascii-armor-end are built according + to [RFC2440], Section 6.2., "Forming ASCII Armor". + + + + + +Grau, et al. Experimental [Page 23] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 + Name: humanities.classics + [...] + -----BEGIN PGP SIGNATURE----- + Version: GnuPG v1.0.7 (IRIX64) + + iD8DBQE9Zj/Wn13IYldLZg8RAhWiAJ4y7o+3FzBpRjYJj2HWwXyG2g8FoQCfeEsH + rRynPhhjveiY/XBkkrrZFho= + + + +Grau, et al. Experimental [Page 24] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + =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 to 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 that for the commands "HIER" and "LIST". + + geta-cmd = "GETA" WSP username WSP password WSP + timestamp WSP name CRLF + + 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 + + + + + +Grau, et al. Experimental [Page 25] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 + 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 + + + +Grau, et al. Experimental [Page 26] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 key words and key terms that + 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 + + 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 that 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". + + + +Grau, et al. Experimental [Page 27] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + The header used in the NAS protocol are not case sensitive. A header + may be uppercase, lowercase, or any mixture of upper- and lowercase. + It is recommended that the first letter of the header and the first + letter after a dash be uppercase and that all other characters be + 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 + + + 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 + + + + + + + +Grau, et al. Experimental [Page 28] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 + + + 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 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) + + + + + + + + + + + + + +Grau, et al. Experimental [Page 29] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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) + + + 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 + + + + + + + +Grau, et al. Experimental [Page 30] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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) + + + 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. + + + + +Grau, et al. Experimental [Page 31] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 + + + 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) + + + + + + + +Grau, et al. Experimental [Page 32] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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) + + + 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, et al. Experimental [Page 33] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 parentheses. + 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 parentheses. + Example: Language: TR + Language: DE + Language: (EN) + (for the newsgroup bln.kultur.tuerkisch) + + + 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 parentheses. + Example: Charset: ISO-8859-1 + (for the hierarchy de) + + + + + + + +Grau, et al. Experimental [Page 34] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 parentheses. + Example: Charset: ISO-8859-9 + Charset: ISO-8859-1 + (for the newsgroup bln.kultur.tuerkisch) + + + 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 parentheses. + 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 parentheses. + Example: Encoding: text/plain + + + + + + + + + + + + + + + +Grau, et al. Experimental [Page 35] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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, et al. Experimental [Page 36] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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, et al. Experimental [Page 37] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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, et al. Experimental [Page 38] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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, et al. Experimental [Page 39] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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) + + E: 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, et al. Experimental [Page 40] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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, + or some other kind. The Newsgroup Type is case insensitive. + + 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) + + + + + +Grau, et al. Experimental [Page 41] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 + *("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 + + + + +Grau, et al. Experimental [Page 42] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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- + 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----- + [...] + + . + + + + + + + +Grau, et al. Experimental [Page 43] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + +7. Specification of the NAS Protocol (UDP) + + UDP is intended for reading programs (news readers); it is not in the + scope of this document. The use of UDP for NAS will be described in + a separate paper. + +8. IANA Considerations + + The IANA has registered 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 the data is authentic and has + not been tampered with. + + Every server does have the possibility (in both server-server and + server-client communication) to deny some commands or the whole + connection according to 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 or that + the data it receives is authentic. + + A stronger authentication scheme will be provided in a higher + protocol level. + + + + + + +Grau, et al. Experimental [Page 44] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + +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) + ---- -------------------------------------------------------------- + +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 + + + +Grau, et al. Experimental [Page 45] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + 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 + +12. References + +12.1. Normative References + + [IANA-CS] IANA: Character Sets, + . + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and + Languages", BCP 18, RFC 2277, January 1998. + + + +Grau, et al. Experimental [Page 46] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + + [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, + "OpenPGP Message Format", RFC 2440, November 1998. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, + L., Leach, P., and T. Berners-Lee, "Hypertext Transfer + Protocol -- HTTP/1.1", RFC 2616, June 1999. + + [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 4234, October 2005. + +12.2. Informative References + + [IANA-MT] IANA: Media Types, . + + [IANA-PN] IANA: Assigned Port Numbers, + . + + [RFC1305] Mills, D., "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, + . + + [USEFOR] USEFOR Working Group, "News Article Format", Work in + Progress. + +Acknowledgement + + This work has been supported by the German Academic Network + Organization (DFN-Verein) with funds from the German Federal Ministry + of Education and Research (Bundesministerium fuer Bildung und + Forschung). + + + + + + + + + + + + + + + + + + +Grau, et al. Experimental [Page 47] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + +Authors' Addresses + + Philipp Grau + Vera Heinau + Heiko Schlichting + Robert Schuettler + + Freie Universitaet Berlin + ZEDAT + Fabeckstr. 32 + 14195 Berlin + Germany + + Phone: +49 30 838-74707 + Fax: +49 30 838-56721 + + EMail: nas@fu-berlin.de + URL: http://nas.fu-berlin.de/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Grau, et al. Experimental [Page 48] + +RFC 4707 Netnews Administration System (NAS) October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78 and at www.rfc-editor.org/copyright.html, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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. + +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 procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Grau, et al. Experimental [Page 49] + -- cgit v1.2.3