RFC 4707
Netnews Administration System (NAS)
RFC 4707: Netnews Administration System (NAS) 💖
okay bestie, this is the RFC for NAS, the Netnews Administration System 🌸 It was written by P. Grau, V. Heinau, H. Schlichting, and R. Schuettler from Freie Universitaet Berlin and published in October 2006 ✨
It's in the Experimental category 🧪, which means it's a proposal to try out, not an Internet standard. It doesn't obsolete or update any other RFCs (its title block has no Obsoletes or Updates line) 🦋
Status of This Memo ✨
ok so this memo defines an Experimental Protocol for the Internet community 🧪 It is not an Internet standard of any kind. The authors are asking for discussion and suggestions to make it better 🫶 Distribution of this memo is unlimited 🌈
Copyright Notice 💜
Copyright (C) The Internet Society (2006). 📜
IESG Note 🙈
ngl this one needs a big warning label 💀 This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of how fit this RFC is for any purpose. In particular, the decision to publish was not based on IETF review for things like security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor chose to publish it at their own discretion. Readers should be careful about how much they trust it before implementing or deploying anything 😭
Abstract 🍓
so NAS is a framework that makes it easier to administer and use network news (aka Netnews) on the Internet 🧚 The data for managing newsgroups and hierarchies lives in a distributed hierarchical database and you can reach it through a client-server protocol 🔥
The database can be accessed by news servers, news admins, and news readers 👑 News servers can update their configuration automatically, while admins can grab the data manually 💅 News reader programs can pull certain info from a NAS server, either automatically or whenever the user wants, which gives users detailed info about groups and hierarchies ✨
NAS can coexist with the current, established process of control messages, and an unwanted interference is impossible 🛡️ It also reflects the somewhat chaotic structure of Usenet inside a hierarchical database, which is so iconic 🦋 NAS can be used without modification of existing news relay, news server, or news reader software, but some tasks will be better handled 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
12. References ....................................................46
12.1. Normative References .....................................46
12.2. Informative References ...................................471. Introduction 🌷
okay so the number of newsgroups, hierarchies, and articles keeps growing, and that has made running news servers a seriously complex and time-consuming job 😩 The admin tools have stayed exactly the same for ten years and are no longer appropriate 💀 A lot of hierarchies are inconsistent 🙃 New newsgroups often don't get created, or get created with a huge delay, and removed groups just keep lurking in the config files for ages 👻 There's no admin tool that actually uses the power of the Internet, and you can't check whether a news server is consistent at any given point in time 🫠
users also struggle to get an overview of newsgroups 🥺 They want to know a group's charter, which language is preferred, or whether it's moderated 📚 Renaming a group, switching between moderated and unmoderated (or back), and splitting one group into several others are all dynamic processes 🦋 They're common, but it takes a long time before every news server knows about these changes ⏳
Lately there's been an increase in faked control messages 🚨 Whether on purpose or by accident, control messages got sent to foreign news servers to create or remove a group, even though the hierarchy's rules didn't approve it 🙅♀️ Because of this, automatic creation and removal got disabled on many news servers, and plenty of dead groups never got deleted 💔 Users often can't tell what state a group is in, and sometimes they have no idea that the group they're posting to is dead or invalid 😱
NAS is designed as an out-of-band system that helps maintain, propagate, and deliver the required information 🧚 It won't interfere with current protocols and standards 🫶 It isn't meant to use control messages or any special Network News Transfer Protocol (NNTP) commands 🙅♀️ The big win is that NAS gives more information in a more structured format than control messages do 💅 Both news server admins and regular Usenet users can get more detailed info about newsgroups and hierarchies 🌈
Because a client connects to a server and the server asks for authentication, this is a much more reasonable way to transmit information than control messages 🔐 NAS also lets you check for changes on a regular basis at customized intervals, so local data stays up-to-date ⭐
2. Overview 🦋
NAS is built on a database that holds information about certain groups and hierarchies 📚 The database is structured hierarchically, it's distributed across various servers, and it can receive queries at any time 🌸 It's 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 🧚 Port 991 is reserved for NAS and registered by the Internet Assigned Numbers Authority (IANA) [IANA-PN] 🎀
The organizational structure of NAS is hierarchical, which 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 hierarchy can have multiple levels 🌈 The database can be used by news servers, news readers, and special client programs 💅 The communication is based on TCP and UDP ✨
Taking the real world into account, a single root server might cause some policy problems 😬 But it's possible to set up a structure like the current Usenet system, where some hierarchies are well administered with a well-defined set of rules, and others aren't well maintained 🫠 The goal is to get as much information as possible under one hat, but there can be no "official" force to make that happen 🙈
During the startup phase, it's pretty likely there will be a root server handling just hierarchies with strict rules and accepted authorities (e.g., BIG8, de., us., bln., fr., it.*) 🇪🇺
It's 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 can choose to use just one root server (and all of its data), or to use another NAS server for special hierarchies 🧚
.............. .............. ...................
. 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 1NAS contains information about newsgroups and complete hierarchies 📚 It also contains information about the hierarchies' inheritable entries and default values for a single newsgroup 💜
Part 1 of 8 done 🎀 Next up: Section 3, Protocol Level 🦋
3. Protocol Level ✨
okay so here's the thing bestie 🫶 NAS is gonna get used in real life, and real life changes everything. The requirements are gonna shift, so the protocol has to be extensible and flexible enough to level up 📈, BUT it also has to stay compatible between versions so older sites don't get left behind 😭. And like, nobody is migrating every single NAS site to a new version at the same time. That's not happening 💀
So NAS has a protocol level 👑. It describes the functionality you're currently working with. It's a number from 1 to 32767, and it gets negotiated when the connection is set up. Any enhancement or modification has to use a different protocol level than its predecessor (usually you just bump it by 1 every time there's a new version of the spec 🎀). And every current or future implementation MUST be compatible with protocol level 1, so it can fall back to that level if talking on a higher one fails. Non-negotiable, periodt 💅
An implementation of a higher protocol level should be able to emulate the behavior of lower levels, even if that means losing some features 🦋. How the client and server negotiate the level is described under the VERS command. If they can't agree on a protocol level, only commands from protocol level 1 MUST be used 🌸. And any documents that enhance or modify the NAS standard MUST say which level the changes happen on, and how things should behave on the other levels 📝. That's the rule, no cap.
This document describes protocol level 1 🍓.
4. Description of Functions 🧚
okay so to use an NAS server, the client has to open a connection first 🔌. The NAS server can live in the same domain or somewhere else out on the Internet 🌈.
NAS is hierarchical, which is giving DNS vibes 💜. The dream is an NAS root server, kind of like the DNS root servers 👑. The root server passes along data collected from client NAS servers that are authoritative for their part of the hierarchy. Maintaining that authoritative data can happen on any system 🫶. The root server gathers everything up and makes it available to other servers, and those servers can pass it along to even more servers 🦋. The administrator gets to pick whether they want all the data or just some of it ✨. NAS servers can ask multiple NAS servers for data too. And there's an attached time stamp so you can tell new data from old data, and so the same info doesn't loop around forever in the propagation 🔁. Smart, right? 🎀
Okay, so to really get the hierarchy, you need to see how the data flows 🌸. Here's the propagation picture:
Authoritative data for a newsgroup or a hierarchy gets collected and written into a database 🗂️. That data is available through a local NAS server, and upstream NAS servers collect it from that authoritative server 💖.
There can also be NAS servers that aren't authoritative 🙈. They just pass along the info they've collected from other NAS servers to clients like news servers, admin programs, and news readers 📰.
............ 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 2Requests to an NAS server that come from a client (or from another server too 🤝) happen in several steps: setting up a connection, authentication (optional) 🔐, negotiating a protocol level (optional) 🤝, queries on the database 🔍, and then 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]. 💅
6. Specification of the NAS Protocol (TCP) 💜
6.1. Responses 💬
6.1.1. Overview 🌸
okay so an answer starts with a response code (a three-digit number) 🔢. It can optionally be followed by white space and a textual message. Then the actual text or data comes after that 📦. Text gets sent as a bunch of lines, and each line ends with CRLF ✨. A single line with nothing but a period ('.') marks the end of the text. So the server sends a CRLF at the end of the last line of text, then a period, then another CRLF 🎀.
Answer = response-code [answertext] CRLF
text CRLF
"." CRLFNow here's the tea ☕. If the original text has a period as the first character of a text line, that first period gets doubled 👯. So the client has to look at the first character of every line it receives. For the lines that start with a period, it has to figure out whether that's the end of the text, or whether it should collapse the doubled period down 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 tells you the message type (information, success, warning, error, or data) 🚦:
1xx Information
2xx Request successful
3xx Request successful, data follow
4xx Request accepted, but no operation possible
5xx Request is wrong (syntax error), is not implemented, or leads to
an internal error
6xx Request successful, data follow until end markThe second digit tells you 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 outputThe actual response code for a specific command is listed in the description of that command 📋. Answers of the type 1xx, 2xx, 4xx, and 5xx can have text after the numerical code 💬. 3xx answers have one or more parameters with data, and the exact format gets explained in the command descriptions 🧾.
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 the client sets up the connection, the server answers right away (without a request first) with the greeting message, which starts with code 200 👋:
--> 200 Welcome!
nas.example.org ready
.If a connection gets refused because the client doesn't have permission to access the server, the answer code is 434 🚫. That decision can be made at connection startup based on the client's IP address 📍. When the server is out of service for now, 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 gets closed 💀.
6.3. Commands 🧚♀️
6.3.1. Structure 🧩
A command is made up of a command word, sometimes followed by a parameter 💖. Parameters are separated from the command word by white space ✨.
Commands in the NAS protocol are not case sensitive 🙌. A command word or parameter can be uppercase, lowercase, or any mixture of the two 🎀.
The length of a command line is not limited 🌈. If real-life implementations ever need to limit command line length, answer code 513 (line too long) should be returned 📏.
The protocol level described in this document uses command words that are exactly four characters long each 🍓.
In examples, octets sent to the NAS server are marked with "<-- " and octets sent by the NAS server are marked with "--> " 👀. The indicator gets left out if the direction of the dialog doesn't change 🦋.
6.3.2. Overview 🌸
The commands below are defined using the Augmented Backus-Naur Form (ABNF) from [RFC4234] 📐. The definitions for 'ALPHA', 'CRLF', 'DIGIT', 'WSP' and 'VCHAR' come from appendix B of [RFC4234] and aren't repeated here 🔁.
The following ABNF definitions make up the set of NAS commands that a client can send to an NAS server 💌.
6.3.3. Detailed Description 💜
Some overall definitions come first ✨:
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 numberNewsgroup names and hierarchy names are defined by the following ABNF definitions 🗺️. A hierarchy name can be the same as a newsgroup name (for example, hierarchy bln.announce.fub.* and newsgroup name bln.announce.fub), so there's 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 comes from "News Article Format and Transmission" [SON1036] 📚. When the document "News Article Format" [USEFOR] becomes an RFC, its definitions should be integrated into a higher protocol level of NAS 🚀.
6.3.3.1. HELP ✨
Description 📝
okay so HELP is the server's cheat sheet 🧚 It prints a short help text on a given command. If you call it with no parameters, you get the whole list of commands, which is so convenient ngl 💖
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
"." CRLFExamples 🎀
<-- 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. It's like the server doing a little mirror check on everyone involved 🪞✨
info-cmd = "INFO" CRLFPossible answers 🌸
- 101: Normal answer; prints some information about client and server
- 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
"." CRLFExamples 🎀
<-- 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
okay the DATE command is giving very "ask the server what time it is" 💖 It prints the current time of the server in UTC (Universal Coordinated Time), in the format YYYYMMDDhhmmss, followed by an optional comment. It's only for informational use and for checking the server time. For regular transmission of time over the network, the Network Time Protocol (NTP) [RFC1305] should be used, so don't use DATE for that bestie 🙈
date-cmd = "DATE" CRLFPossible 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
date-answer =/ "300" [answertext] CRLF
utc-time [answertext] CRLF
"." CRLFExamples 🧚
<-- DATE
--> 300
19990427135230 UTC
.
<-- DATE
--> 511
Time is unknown
.6.3.3.4. VERS 👑
Description
The VERS command is how the client and server figure out which protocol level to use together 🫶 The parameter is a protocol level that the client supports and wants to use. The server responds with the highest level it accepts. 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's 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 is printed. When no protocol level is negotiated, protocol level 1 is 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 - 32767Possible 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
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
"." CRLFExamples 💜
<-- 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. Bye bestie 🥺💅
quit-cmd = "QUIT" CRLFPossible answers
- 201: Termination of the connection
quit-answer = "201" [answertext] CRLFExample 🌈
<-- QUIT
--> 201 Closing connection. Bye.6.3.3.6. LIST 📋
Description
To get a list of newsgroups and sub-hierarchies in the requested hierarchies, you use the LIST command 🌷 The status of the hierarchies is also given. The highest level consists of all top-level hierarchies and is labeled "*". You can get that one this way too.
The data consists of a newsgroup- or hierarchy-name/status indicator pair per line. The 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, so no stress 🫧
list-cmd = "LIST" ( WSP "*" / 1*(WSP name)) CRLFPossible 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-statusThe list-status is the status of a newsgroup or hierarchy according to Section 6.4. It's giving categories, honestly 💀
list-status = "Complete" /
"Incomplete" /
"Obsolete" /
"Unknown" /
"Unmoderated" /
"Readonly" /
"Moderated" /
"Removed" ; list-status is case-insensitiveExamples 🎀
<-- 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
.6.3.3.7. LSTR 🦋
Description
LSTR is the recursive version of LIST and it's lowkey iconic 🌸 To get a recursive list of newsgroups and sub-hierarchies in the named hierarchy, you use the LSTR command. The status of the hierarchies is also given. The highest level consists of all top-level hierarchies and is labeled "*", and you can get it this way too.
You can also use "" as a wildcard pattern after the beginning of a hierarchy name. 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 ["*" / ".*"]) ) CRLFPossible 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-statusThe 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-insensitiveExample 🌈
<-- 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
okay so HIER is the command that lists everything we know about a hierarchy 🌳 each hierarchy gets its own fresh data block, started by the "Name" header, which tells you the hierarchy's name 💖 the data headers are explained in Section 6.3.4, bestie. by default you get all the info, but you can ask for only certain headers. just add a comma-separated list after the name and you'll get exactly those fields. "Name" and "Status" are always included no matter what, so they're basically the main characters 👑
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.4Example for selection
,Followup,Description : For all entries list Name, Status, Followup
and DescriptionPossible answers
401: Permission denied
510: Syntax error
611: Regular answer with all requested datahier-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
.<-- HIER
--> 510 Syntax error
missing parameter hierarchy
.6.3.3.9. DATA 🎀
Description
DATA is basically HIER's little sister 🧚 it works the same way, as explained in 6.3.3.8, except it's for info about a newsgroup instead of a hierarchy. you can find a summary of the codes in Section 6.3.4 💅
data-cmd = "DATA" 1*(WSP name) [WSP selection] CRLFPossible answers
401: Permission denied
510: Syntax error
612: Regular answer with all requested datadata-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.
<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 the one servers use to talk to each other 🤝 it asks for the data of the hierarchy named in the "name" parameter. the format is the same as for "HIER" and "LIST". and if you send "*" as the hierarchy name, the server sends back everything it's offering. iconic behaviour 🔥
every package has a "timestamp" attached, which is the date and time the package was created. the server sends that timestamp along with the package data, and it marks a specific revision of that package's data 📅
when a client asks for a package with GETP, it sends along the timestamp it has stored in its own database. that lets the server check whether the client's copy is still valid or whether it's too old. if the client's data is still valid, the server sends back a 213 answer, so the client knows its data is OK ✨ and if the timestamp is "0", the server is forced to send the data no matter what 💀
timestamps set by the server must be increasing and may not be more than 12 hours in the future. okay, that's a rule with teeth 😤
the data for a successful request is signed and sent in ASCII armor according to [RFC2440], so a client can check the signature or just ignore it. the actual data is 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 dataPossible answers
213: Current data at the client side
411: No hierarchy with that name
430: Permission denied
510: Syntax error
613: Hierarchy datagetp-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
"." CRLFpgp-ascii-armor-start and 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
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 ✨
Okay so GETA is the server-to-server command 💅. A server uses it to collect authoritative data, which means it asks for the packages it's the authority for. A package is the authoritative data for either a newsgroup or a hierarchy 🌸.
Every package has a "timestamp" that marks its revision. The server sets it to the date of the package data's last modification, in UTC format. A timestamp of "0" means the package MUST be retrieved 😭. If the client already has a recent package (meaning nothing has changed on the authoritative server), the server only sends back a 215 response 🫶. The data format is the same as for the "HIER" and "LIST" commands.
Grammar
geta-cmd = "GETA" WSP username WSP password WSP
timestamp WSP name CRLFPossible answers
215: The client already has the current data430: Permission denied411: No hierarchy with that name510: Syntax error615: 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
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, you get a 519 return code (unknown command) 💀. If something goes wrong after the command string, like a missing parameter, you get a 510 return code (Syntax error: Missing parameter) 😅.
6.3.4. Data Headers 🌈
These paragraphs cover the key words and key terms that help with retrieving and storing info. Every header has a unique English name 💜.
The content of a header can be inherited within a hierarchy, as long as the header is marked as inheritable 🧚. That 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). So that value is "DE" for every newsgroup in this hierarchy, except for any 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" 🔥.
The headers used in the NAS protocol are not case sensitive. A header can be uppercase, lowercase, or any mix of the two ✨. 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.announceStatus 🌸
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-ModeratedSerial 🧁
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: 20020821102413Group 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)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.arbeitNetiquette-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.
Example: Rules: http://www.kirchwitz.de.example/~amk/dai
/einrichtungControl 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.exampleControl 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.groupsModerators 👑
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)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-InfoOkay so the Mod-Group-Info header wraps up here, and it's giving "tell everyone where to submit" 📮✨
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)Language 🌸
Bestie, this one is about which language people will normally write in. Here's the full field list for the hierarchy version:
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)So the language notation follows the "Content-Language" field from [RFC2616] 🌍, and any languages that aren't preferred get wrapped in parentheses. The example is DE for the de hierarchy, which is so on brand 🇩🇪
The newsgroup version is the same vibe, just scoped to a single group and not inheritable:
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)Here you can stack multiple Language lines, and the one in parentheses is the not-preferred one. In the example, TR and DE are the main languages and EN is the lowkey backup 🫶
Charset 🎀
Charset is the character set people will normally use in postings. The full list of charset names lives in [RFC2277] and the IANA Character Set registry [IANA-CS] 📚
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)
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)Same deal as Language: the non-preferred charsets go in parentheses 💅 Multiple lines are allowed, and the group example shows ISO-8859-9 and ISO-8859-1 together.
Encoding 🦋
This one tells you the MIME media type for the hierarchy or group, as described in [RFC2045] 💜 You can find the registered media types over at [IANA-MT].
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/plainNotice the newsgroup version keeps the non-preferred encodings in parentheses, same as always. The example is text/plain, the most classic of looks 📝
Type of newsgroup 💖
This is the default newsgroup type for a hierarchy. It has no real meaning on its own, but it gets passed down to the groups inside it through inheritance ✨ The actual types are covered in Section 6.5.
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)For a single group, it just says what kind of group it is, and the list of types is still in Section 6.5 🎉
Type of hierarchy 👑
This one says what kind of hierarchy it is. The types are defined in Section 6.6 💅
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)Regional or Organizational Area 🌈
This describes the geographical region or organization behind the hierarchy. The Comment says it's especially useful when Hier-Type is "Regional" or "Organization" 🗺️
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 📏
This is the maximum length of a newsgroup name. Inheritable, but not repeatable, so you only get one value 🧚
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 🍓
This one is the maximum length of a single component in the newsgroup name, so it's about each dotted chunk, not the whole name. Same rules: inheritable, not repeatable ✨
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)Article length 📦
This is the maximum length of an article, measured in bytes. For a hierarchy it has no concrete meaning, but it's passed down to the newsgroups inside it 💜
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: 50000Date of creation 🎂
These dates use the same format as the DATE command. Both the hierarchy and newsgroup versions can be set to a date in the future, which is kind of iconic 🔮
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: 19970330101514Date of removal 🥀
Same energy as creation, but for when a hierarchy or newsgroup gets removed. It can also be in the future, so you can plan ahead 🗓️
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: 19970330101514Successor 🦢
Replacement names the hierarchy or newsgroup that takes over. For a hierarchy, it's used when the hierarchy has status "Hierarchy-Obsolete" (the one that replaced the removed one) or when the removal date is in the future. For a newsgroup, it's used with status "Group-Removed," or when the removal date is still coming up. It's repeatable, so you can list more than one newsgroup 🫶 It is not inherited, so each hierarchy has to say its own piece.
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)Source 🔎
This is for tracking the maintainer of a hierarchy, which means who's actually responsible for it 👀 It's not repeatable, and it's inherited.
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 🔐
This is the PGP key for whoever sends control messages in the hierarchy. It holds extra info like the key owner and key-id. It's inheritable and repeatable, and the exact format is spelled out in Section 6.7 💖
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-----Look at that example, it's giving full key-drop energy 🗝️ The fields are the owner (U), the key-id (I), the links to the key (L), the fingerprint (F), the version (V), and the armored key block (K).
Moderator's PGP key 🛡️
This is the public PGP key of a newsgroup's moderator, including the extra stuff like the key owner and key-id. It's repeatable, and the format is the same as in Section 6.7 💅
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 🚦
Bestie, the status indicator is the one thing that tells you exactly what state a hierarchy or newsgroup is in. It's case insensitive, so "complete" and "COMPLETE" are the same mood 💜
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
----------- --------- -------------------------------------------So a hierarchy can be Complete, Incomplete, Obsolete, or Unknown 🌸 A newsgroup can be Unmoderated, Readonly, Moderated, Removed, or Unknown. Moderated groups need articles sent to the moderator, and Removed groups allow no posting or transport 💀
6.5. Newsgroup Types 🌟
A Newsgroup Type is basically a big-picture label for what a group is about, like whether it's a test group, a binary group, or something else entirely. Also 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)
Robots Automatic postings (like the former comp.mail.maps)
Experiment Experimental, other
----------- ------------------------------------------------------6.6. Hierarchy Types ✨
okay so, to describe a hierarchy you use these Hierarchy Types 🌈 they mark some properties of a news hierarchy, and they're case insensitive, so no stress about capitals 💅
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 🔐
ok this part is giving cryptography realness 🫶 PGP keys for Ctrl-PGP-Key and Mod-PGP-Key get sent in this exact structure, so the shape matters a lot 😭
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 = textKey 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 after the code means the block keeps going on the next line 🦋 and in the last message row there MUST be white space after the code, which is also true for a single line code. no skipping that, bestie 🚨
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-----
[...]
.7. Specification of the NAS Protocol (UDP) 🦋
not gonna lie, UDP is not the vibe for this doc 🙈 it's meant for reading programs (news readers), so it's out of scope here. the way UDP gets used for NAS will be covered in a separate paper, so stay tuned ✨
8. IANA Considerations 🌸
so the IANA has registered the application/nasdata media type with this info 💖
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 below9. Security Considerations 🚨
okay this is the serious part, bestie, so pay attention 🥺 security is only handled for server-server communication at this protocol level. username and password combos in the GETA and GETP commands can make sure only authorized clients get connections. PGP keys according to [RFC2440] sign the NAS data in server-server communication so you can check that it's authentic and hasn't been messed with 🔥
every server has the option (in both server-server and server-client communication) to deny some commands or the whole connection based on the client's IP number 🛡️
and here's the tea 😭 the current protocol level doesn't define any mechanism for a client to check that it's talking to a legit server, or that the data it gets is authentic. not ideal, not ideal 💀
a stronger authentication scheme will show up in a higher protocol level, so hold on for that one 👑
10. Response Codes (Overview) 🍓
here's the whole list of response codes, bestie, it's a lot but it's iconic 💅
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) 🎀
these are the data headers for DATA and HIER commands, and the table tells you which ones are mandatory, where they're used, and whether you can repeat them 🧚
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
12. References 📚
12.1. Normative References
[IANA-CS] IANA: Character Sets,
<http://www.iana.org/assignments/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.
[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, <http://www.iana.org/assignments/>.
[IANA-PN] IANA: Assigned Port Numbers,
<http://www.iana.org/assignments/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,
<ftp://zoo.toronto.edu/pub/news.txt.Z>.
[USEFOR] USEFOR Working Group, "News Article Format", Work in
Progress.Acknowledgement 💜
this work got support from the German Academic Network Organization (DFN-Verein), with funds from the German Federal Ministry of Education and Research (Bundesministerium fuer Bildung und Forschung) 🇩🇪✨
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/Full Copyright Statement 💖
Copyright (C) The Internet Society (2006). 🎀
This document is subject to the rights, licenses and restrictions in BCP 78, which you can read at www.rfc-editor.org/copyright.html. Apart from what that BCP says, the authors keep all of their rights. ✨
The legal fine print is next, and it's not the fun part, but it matters 😭. This document and everything in it is provided AS IS, with no guarantees. The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim every warranty, whether stated or implied. That includes any promise that using the information won't infringe anyone's rights, and any implied promise that it's merchantable or fit for a particular purpose. 💅
Intellectual Property 🦋
Okay so the IETF is not picking a side on whether any intellectual property rights apply to the technology in this document, or on how far any license to use those rights might extend. It also doesn't claim to have searched for those rights on its own 🙈. If you want to know how rights work for RFC documents, check out BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat are available from the IETF online IPR repository at http://www.ietf.org/ipr. The same goes for any assurances that licenses will be made available, and for the results of anyone trying to get a general license or permission to use those proprietary rights for implementing or using this specification. 🌸
Last but not least, the IETF is inviting anyone to tell it about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send those details to ietf-ipr@ietf.org 🫶.
📦 where this page comes from
- ietf: rfc4707 2006-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms