idnits 2.17.1 draft-dfncis-netnews-admin-sys-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 2120 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 1214 instances of lines with control characters in the document. == There are 35 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1151 has weird spacing: '...ver and of th...' == Line 1809 has weird spacing: '...erarchy auth...' == Line 1810 has weird spacing: '...erarchy not ...' == Line 1811 has weird spacing: '...erarchy obso...' == Line 1813 has weird spacing: '...erarchy no i...' == (12 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The VERS command is used to determine the protocol level to use between client and server. The parameter is a protocol level that the client supports and wants to use. The server will respond with the highest level accepted. This version number MUST not be higher than requested by the client. Client and server MUST only use commands from the level that the server has confirmed. It is possible, but seldom necessary, to change the protocol level during a session by client request (VERS [protocol level]). When no option is given, the current protocol level will be printed. When no protocol level is negotiated, the protocol level 1 will be used. Commands of a higher level are not allowed without successful negotiation. The protocol level can be followed by an optional comment. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2005) is 6860 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ISC-INN' is defined on line 2090, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-CS' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2440 (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Unexpected draft version: The latest known version of draft-ietf-usefor-article is -13, but you're referring to -14. Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT P. Grau 3 V. Heinau 4 Expires January 12, 2006 H. Schlichting 5 R. Schuettler 6 Freie Universitaet Berlin 7 July 2005 9 Netnews Administration System (NAS) 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 The Netnews Administration System (NAS) is a framework to simplify 41 the administration and usage of network news (also known as Netnews) 42 on the Internet. Data for the administration of newsgroups and 43 hierarchies are kept in a distributed hierarchical database and are 44 available through a client-server-protocol. 46 The database is accessible by news servers and news administrators as 47 well as by news readers. News servers can update their configuration 48 automatically; administrators are able to get the data manually. News 49 reader programs are able to get certain information from an NAS 50 server, automatically or at a user's discretion, to provide detailed 51 information about groups and hierarchies to the user. 53 NAS is usable in coexistence with the current, established process of 54 control messages; an unwanted interference is impossible. 55 Furthermore, NAS is able to reflect the somewhat chaotic structure of 56 Usenet in a hierarchical database. NAS can be used without 57 modification of existing news relay, news server or news reader 58 software, however, some tasks will be better accomplished with NAS 59 compliant software. 61 Table of Contents 63 Status of this Memo ............................................... 1 64 Copyright Notice .................................................. 1 65 Abstract .......................................................... 1 66 1. Introduction .................................................. 4 67 2. Overview ...................................................... 5 68 3. Protocol Level ................................................ 6 69 4. Description of Functions ...................................... 7 70 5. Definitions ................................................... 8 71 6. Specification of the NAS Protocol (TCP) ....................... 9 72 6.1. Responses ............................................... 9 73 6.1.1. Overview .......................................... 9 74 6.1.2. Response Code Values, Structure and Meaning ....... 9 75 6.2. Connection Setup ........................................ 10 76 6.3. Commands ................................................ 11 77 6.3.1. Structure ......................................... 11 78 6.3.2. Overview .......................................... 11 79 6.3.3. Detailed Description .............................. 11 80 6.3.3.1. HELP ........................................ 12 81 6.3.3.2. INFO ........................................ 13 82 6.3.3.3. DATE ........................................ 14 83 6.3.3.4. VERS ........................................ 15 84 6.3.3.5. QUIT ........................................ 16 85 6.3.3.6. LIST ........................................ 17 86 6.3.3.7. LSTR ........................................ 19 87 6.3.3.8. HIER ........................................ 20 88 6.3.3.9. DATA ........................................ 22 89 6.3.3.10. GETP ....................................... 23 90 6.3.3.11. GETA ....................................... 26 91 6.3.3.12. Unknown Commands and Syntax Errors ......... 28 92 6.3.4. Data Headers ...................................... 28 93 6.4. Status Indicators ....................................... 44 94 6.5. Newsgroup Types ......................................... 44 95 6.6. Hierarchy Types ......................................... 45 96 6.7. PGP Keys ................................................ 45 97 7. Specification of the NAS Protocol (UDP) ....................... 47 98 8. IANA Considerations ........................................... 47 99 9. Security Considerations ....................................... 47 100 10. Response Codes (Overview) .................................... 48 101 11. Data Headers for DATA and HIER Commands (Overview) ........... 49 102 12. References ................................................... 50 103 12.1. Normative References ................................... 50 104 12.2. Informative References ................................. 50 105 13. Author's Address ............................................. 51 106 14. Full Copyright Statement ..................................... 51 107 15. Intellectual Property ........................................ 51 108 1. Introduction 110 The increasing number of newsgroups, hierarchies and articles has 111 made the administration of news servers a complex and time consuming 112 task. The tools for the administration have remained unchanged for 113 ten years and are no longer appropriate. Many hierarchies are 114 inconsistent, many new newsgroups are not created or only with a 115 large delay, removed groups keep lurking in the configuration files 116 for a long period of time. There is no administration tool that 117 utilizes the power of the Internet, and it is not possible to check 118 the consistency of the news server at a given point of time. 120 Users find it difficult to get an overview of the newsgroups, the 121 charter of a particular one, which language is preferred, or whether 122 a group is moderated or not. Renaming, the status change from 123 moderated to unmoderated or vice versa, and the splitting of a group 124 into several others are dynamic processes. These processes are in 125 common use, but it takes a long time until every news server is aware 126 of these changes. 128 An increasing number of faked control messages has appeared in the 129 last few years. Purposely or accidentally control messages were sent 130 to foreign news servers to create or remove a certain group, although 131 this was not approved according to the rules of the hierarchy in 132 question. Due to this fact, automatic creation and removal is 133 disabled on many news servers and several dead groups have not been 134 deleted. It is very difficult for users to determine the current 135 status of a group, and in some cases they simply cannot tell that the 136 group they are posting to is in reality not an active but a dead or 137 invalid group. 139 It is the design goal of NAS to provide an out-of-band system that 140 helps to maintain, propagate, and deliver the required information. 141 There will not be any interference with current protocols and 142 standards. It is not intended to make use of control messages or some 143 special NNTP commands. The advantage of NAS is that it provides more 144 information in a more structured format than control messages. Not 145 only news server administrators but also Usenet users can get more 146 detailed information about newsgroups and hierarchies. 148 Due to the fact that a client connects to a server and the server 149 asks for authentication, this is a more reasonable procedure of 150 transmitting information than control messages. Furthermore, it is 151 possible to check for changes on a regular basis at customized 152 intervals to keep local data up-to-date. 154 2. Overview 156 NAS is based on a database which contains information about certain 157 groups and hierarchies. This database is structured in a hierarchical 158 manner, distributed to various servers and is able to receive queries 159 at any time. The service is comparable to directory services like 160 DNS, LDAP or NIS. The NAS protocol is inspired by protocols like NNTP 161 and SMTP. The port 991 is reserved for NAS and registered by the 162 Internet Assigned Number Authority (IANA) [IANA-PN]. 164 The organizational structure of NAS is hierarchical, that means a NAS 165 root server collects data from the sub-servers that are authoritative 166 for certain hierarchies. The root server signs the data and 167 distributes it authoritatively. Replication of database entries is 168 possible. The hierarchical structure can consist of multiple levels. 169 Usage of the database is possible for news servers, news readers and 170 special client programs. The communication is based on TCP and UDP. 172 Taking the real world into account, there might be some policy 173 problems with a single root server. But it is possible to establish a 174 structure like the current Usenet system, where some hierarchies have 175 a good administration with a well-defined system of rules and some 176 are not well maintained. The goal is to get as much information as 177 possible under one hat, but there can be no "official" force to 178 achieve this. 180 During the startup phase it is quite likely that there will be a root 181 server, handling just hierarchies with strict rules and accepted 182 authorities (like BIG8, de.*, us.*, bln.*, fr.*, it.*, etc.). 184 However, it is also imaginable to have some NAS servers providing 185 data on - for example - alt.!binaries, some providing data on alt.*, 186 and even some providing alt.* following special policies or sets of 187 rules. 189 An administrator using NAS will have the choice to use just one root 190 server (and all its data) and/or to use another NAS server for 191 special hierarchies. 193 .............. .............. ................... 194 . NAS server . . NAS server . . NAS server . 195 . . . . . alt.*, . 196 . alt.* . . Big8 . . !alt.binaries.* . 197 .............. .............. ................... 198 . database . . database . . database . 199 .............. .............. ................... 200 ^ ^ ^ ^ 201 `--+ +--' `------+ +----' 202 | | | | 203 .------------. .------------. 204 | NAS client | | NAS client | 205 +------------+ +------------+ 206 | netnews | | netnews | 207 | server | | server | 208 .------------. .------------. 210 Configuration A Configuration B 212 Figure 1 214 NAS contains information about newsgroups as well as complete 215 hierarchies. Furthermore, it contains information about the 216 hierarchies' inheritable entries and default values for a single 217 newsgroup. 219 3. Protocol Level 221 It is expected that the real life use of NAS will change the 222 requirements for the Netnews Administration System. On the one hand 223 the protocol has to be extensible and flexible in order to implement 224 improvements, on the other hand it must ensure compatibility between 225 different versions. A simultaneous migration of all sites using NAS 226 to a new protocol version is not likely to happen. To solve this 227 problem, NAS has a protocol level. This protocol level describes the 228 current functionality. The protocol level, being a number between 1 229 and 32767, is negotiated at connection setup. Enhancements and 230 modifications must use a different protocol level than their 231 predecessors. (Usually the protocol level is incremented by 1 with 232 every new version of the protocol specification.) Every current or 233 future implementation MUST be compatible with protocol level 1 in 234 order to fall back to this level if communication on a higher level 235 fails. 237 An implementation of higher protocol levels should be able to emulate 238 the behavior of lower levels, even if this implies a loss of 239 features. The negotiation of the protocol level between client and 240 server is described in the specification of the command VERS. If 241 there is no agreement on the protocol level, only commands of the 242 protocol level 1 MUST be used. Documents enhancing or modifying the 243 NAS standard MUST specify on which level these changes take place and 244 how the behavior should be in other protocol levels. 246 This document describes protocol level 1. 248 4. Description of Functions 250 In order to use a NAS server, a connection must be opened by the 251 client. The NAS server can be located in the same domain or somewhere 252 else on the Internet. 254 The NAS system is hierarchical. The idea is to have an NAS root 255 server like the DNS root servers. The root server distributes the 256 data collected from client NAS servers that are authoritative servers 257 for their hierarchy. The maintenance of the authoritative data is 258 possible on any system. The root server collects the data and makes 259 them available to other servers, which can in turn distribute these 260 data to other servers. The administrator has the opportunity to make 261 use of either all data or only parts of the database. NAS servers can 262 ask multiple NAS servers for data. An attached time stamp provides 263 the possibility to distinguish between new and old data and to avoid 264 loops in the propagation. 266 To describe the NAS in greater detail, it is necessary to emphasize 267 the hierarchical design of the NAS system. The following figure shows 268 the propagation of data along the server hierarchy. 270 Authoritative data for a newsgroup or a hierarchy are collected and 271 written into a database. These data are available through a local NAS 272 server and are collected from this authoritative server by upstream 273 NAS servers. 275 There may also be NAS servers that are not authoritative servers; 276 these servers merely provide the information they collect from other 277 NAS servers to clients such as news servers, administration programs 278 and news readers. 280 ............ collects from > 281 . root NAS .-------------------------+ 282 . server .----------------+ | 283 ............ | | 284 . database . | | 285 ............ | | 286 ^ v | .......................... 287 | | | . NAS server . 288 | |distributes | . authoritative for de.* . 289 queries| | | .......................... 290 | | | . database . 291 ^ v | .......................... 292 .............. | 293 . NAS server . `--------+ 294 .............. | 295 . database . ........................... 296 .............. . NAS server . 297 ^ ^ ^ . authoritative for bln.* . 298 | | | .---------. ........................... 299 q | | `--| netnews | . database . 300 u | | | server | ........................... 301 e | | .---------. 302 r | | 303 i | | .---------. 304 e | `--| admin | 305 s | | program | 306 | .---------. 307 | 308 | .---------. 309 `--| news | 310 | reader | 311 .---------. 313 Figure 2 315 Requests to an NAS server originating at a client as well as another 316 server are accomplished in several steps, as there are: Establishing 317 a connection, authentication (optional), negotiating a protocol level 318 (optional), queries on the database, and termination. 320 5. Definitions 322 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 323 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 324 document are to be interpreted as described in [RFC2119]. 326 6. Specification of the NAS Protocol (TCP) 328 6.1. Responses 330 6.1.1. Overview 332 An answer starts with a response code (a three digit number), 333 optionally followed by white space and a textual message. Then the 334 actual text/data follows. Text is sent as a series of successive 335 lines of textual matter, each terminated with CRLF. A single line 336 containing only a single period ('.') is sent to indicate the end of 337 the text (i.e. the server will send a CRLF at the end of the last 338 line of text, a period, and another CRLF). 340 Answer = response-code [answertext] CRLF 341 text CRLF 342 "." CRLF 344 If the original text contains a period as the first character of the 345 text line, that first period is doubled. Therefore, the client must 346 examine the first character of each line received, and for those 347 beginning with a period, determine either that this is the end of the 348 text or whether to collapse the doubled period to a single one. 350 Example: 352 <-- INFO 353 --> 101 Information follows 354 Server: nas.example.org (192.0.2.100) 355 Uptime: 2 weeks, 3 days, 5 hours, 9 minutes 356 Software: NAS 1.0 357 Client: client.example.org (192.0.2.123) 358 Connection: 9 minutes 359 Highest protocol level supported: 1 360 Requested protocol level: 1 361 Protocol level used: 1 362 . 364 6.1.2. Response Code Values, Structure and Meaning 366 The first digit of the response code indicates the message type, 367 i.e., information, success, warning, error, or data: 369 1xx Information 370 2xx Request successful 371 3xx Request successful, data follow 372 4xx Request accepted, but no operation possible 373 5xx Request is wrong (syntax error), not implemented, or leads to an 374 internal error 375 6xx Request successful, data follow until end mark 377 The second digit specifies the message category: 379 x0x connection related stuff 380 x1x queries, answers, or data 381 x2x server-server communication 382 x3x authentication, authorization 383 x8x non-standard extensions 384 x9x debugging output 386 The actual response code for a specific command is listed in the 387 description of the commands. Answers of the type 1xx, 2xx, 4xx, and 388 5xx can have a text after the numerical code. 3xx answers contain one 389 or more parameters with data; the exact format is explained in the 390 description of the commands. 392 An answer to an incorrect request may be longer than one line. 394 6.2. Connection Setup 396 NAS typically uses port 991, which is reserved by IANA [IANA-PN]. If 397 a connection is set up by the client, the server answers immediately 398 (without a request) with the greeting message, which will start with 399 code 200: 401 --> 200 Welcome! 402 nas.example.org ready 403 . 405 If a connection is refused because the client has no permission to 406 access the server, the answer code is 434. That decision can be made 407 on connection startup based on the client's IP address. When the 408 server is currently out of service, the answer code is 404. 410 Examples: 412 --> 434 You have no permission to retrieve data. Good bye. 413 . 415 --> 404 Maintenance time 416 . 418 After sending a 404 or 434 message the connection will be closed. 420 6.3. Commands 422 6.3.1. Structure 424 A command consists of a command word, sometimes followed by a 425 parameter. Parameters are separated from the command word by white 426 space. 428 Commands used in the NAS protocol are not case sensitive. A command 429 word or parameter may be upper case, lower case, or any mixture of 430 upper and lower case. 432 The length of a command line is not limited. If the need to limit the 433 length of command lines in real life implementations arises, answer 434 code 513 (line too long) should be returned. 436 The protocol level described in this document uses command words with 437 a length of exactly four characters each. 439 In examples, octets sent to the NAS server are preceded by "<-- " and 440 those sent by the NAS server by "--> ". The indicator is omitted if 441 the direction of the dialog does not change. 443 6.3.2. Overview 445 The commands described below are defined using the Augmented Backus- 446 Naur Form (ABNF) defined in [RFC2234]. The definitions for `ALPHA', 447 `CRLF', `DIGIT', `WSP' and `VCHAR' are taken from appendix A of 448 [RFC2234] and not repeated here. 450 The following ABNF definitions comprise the set of NAS commands which 451 can be sent from the client to an NAS server. 453 6.3.3. Detailed Description 455 Some overall definitions: 457 text = %d1-9 / ; all octets except 458 %d11-12 / ; US-ASCII NUL, CR and LF 459 %d14-255 461 answertext = WSP *( ALPHA / DIGIT / "+" / "-" / "/" / "_" / 462 "." / "," / ":" / "=" / "?" / "!" / SP ) 464 utc-time = 14DIGIT ; the date and time of the server in UTC 465 ; YYYYMMDDhhmmss 466 response-code = 3DIGIT ; three digit number 468 Newsgroup names and hierarchy names are defined according to the 469 following ABNF definitions. Since a hierarchy name can be the same as 470 a newsgroup name (e.g., hierarchy bln.announce.fub.* and newsgroup 471 name bln.announce.fub) there is no difference between the two. 473 name = plain-component *("." component) 474 component = plain-component / encoded-word 475 encoded-word = 1*( lowercase / DIGIT / 476 "+" / "-" / "/" / "_" / "=" / "?" ) 477 plain-component = component-start *component-rest 478 component-start = lowercase / DIGIT 479 lowercase = %x61-7A ; letter a-z lowercase 480 component-rest = component-start / "+" / "-" / "_" 482 NOTE: This definition of newsgroup name is in reference to 483 son-of-1036-draft [SON1036]. When the current draft "News Article 484 Format" [USEFOR] is established as an RFC, its definitions should be 485 integrated into a higher protocol level of NAS. 487 6.3.3.1. HELP 489 Description 491 This command prints a short help text on a given command. If called 492 without parameters, it will display a complete list of commands. 494 help-cmd = "HELP" [WSP commandname] CRLF 496 commandname = "DATA" / "DATE" / "GETP" / "GETA" / 497 "HELP" / "HIER" / "INFO" / "LIST" / 498 "LSTR" / "QUIT" / "VERS" 500 Possible answers 502 100: Command overview, command description 503 410: Indicates that the server is not giving any information 505 help-answer = "410" [answertext] CRLF 506 text CRLF 507 "." CRLF 508 help-answer =/ "100" [answertext] CRLF 509 text CRLF 510 "." CRLF 511 Examples 513 <-- HELP 514 --> 100 NAS server nas.example.org - Version 1.0 516 Supported commands: 517 DATA - data for a newsgroup 518 DATE - show time of server in UTC 519 GETP - get package 520 GETA - get data from an authoritative server 521 HELP - show this help 522 HIER - data for a hierarchy 523 INFO - show info on current connection 524 LIST - list newsgroups or hierarchies 525 LSTR - recursive list newsgroups or hierarchies 526 QUIT - close the connection 527 VERS - show or set current protocol level 529 Contact address nas@example.org 530 . 532 <-- HELP LIST 533 --> 100 LIST 534 LIST - list newsgroups or hierarchies 535 Syntax: LIST hierarchy ... 536 Get a list of newsgroups and sub-hierarchies 537 directly under the parameter hierarchy 538 . 540 <-- HELP NOOP 541 --> 410 542 unknown command "NOOP" 543 . 545 6.3.3.2. INFO 547 Description 549 Prints information about the current connection, the server, and the 550 client. 552 info-cmd = "INFO" CRLF 554 Possible answers 556 101: Normal answer, prints some information about client 557 and server 558 400: Indicates that the server is not giving any information 560 info-answer = "400" [answertext] CRLF 561 text CRLF 562 "." CRLF 563 info-answer =/ "101" [answertext] CRLF 564 text CRLF 565 "." CRLF 567 Examples 569 <-- INFO 570 --> 101 Information follows 571 Server: nas.example.org (192.0.2.100) 572 Uptime: 2 weeks, 3 days, 5 hours, 9 minutes 573 Software: NAS 1.0 574 Client: client.example.org (192.0.2.123) 575 Connection: 9 minutes 576 Highest protocol level supported: 1 577 Requested protocol level: 1 578 Protocol level used: 1 580 End 581 . 583 <-- INFO 584 --> 400 585 No information available. 586 . 588 6.3.3.3. DATE 590 Description 592 Prints the current time of the server in UTC (Universal Coordinated 593 Time) in the format YYYYMMDDhhmmss, followed by an optional comment. 594 The DATE command is only for informational use and to check the 595 server time. For regular transmission of time over the network, the 596 Network Time Protocol (NTP) [RFC1305] should be used. 598 date-cmd = "DATE" CRLF 600 Possible answers 602 300: Print the UTC time in specified format, see below 603 511: Error, print an error message 604 date-answer = "511" [answertext] CRLF 605 text CRLF 606 "." CRLF 607 date-answer =/ "300" [answertext] CRLF 608 utc-time [answertext] CRLF 609 "." CRLF 611 Examples 613 <-- DATE 614 --> 300 615 19990427135230 UTC 616 . 618 <-- DATE 619 --> 511 620 Time is unknown 621 . 623 6.3.3.4. VERS 625 Description 627 The VERS command is used to determine the protocol level to use 628 between client and server. The parameter is a protocol level that the 629 client supports and wants to use. The server will respond with the 630 highest level accepted. This version number MUST not be higher than 631 requested by the client. Client and server MUST only use commands 632 from the level that the server has confirmed. It is possible, but 633 seldom necessary, to change the protocol level during a session by 634 client request (VERS [protocol level]). When no option is given, the 635 current protocol level will be printed. When no protocol level is 636 negotiated, the protocol level 1 will be used. Commands of a higher 637 level are not allowed without successful negotiation. The protocol 638 level can be followed by an optional comment. 640 vers-cmd = "VERS" [WSP level] CRLF 642 level = 1*5DIGIT ; the valid range is 1 - 32767 644 Possible answers 646 202: Returns current protocol level 647 302: Requested level accepted 648 402: Requested level too high, falling back to lower level 649 510: Syntax error 650 vers-answer = "202" [answertext] CRLF 651 level [answertext] CRLF 652 "." CRLF 653 vers-answer =/ "302" [answertext] CRLF 654 level [answertext] WSP level CRLF 655 "." CRLF 656 vers-answer =/ "402" [answertext] CRLF 657 level [answertext] WSP level CRLF 658 "." CRLF 659 vers-answer =/ "510" [answertext] CRLF 660 level [answertext] CRLF 661 "." CRLF 663 Examples 665 <-- VERS 666 --> 202 667 2 Current protocol level is 2 668 . 670 <-- VERS 2 671 --> 302 672 2 My max protocol level is 10 673 . 675 <-- VERS 11 676 --> 402 677 10 Falling back to level 10 678 . 680 <-- VERS BAL 681 --> 510 682 1 Syntax error 683 . 685 6.3.3.5. QUIT 687 Description 689 Terminates the connection. 691 quit-cmd = "QUIT" CRLF 693 Possible answers 695 201: Termination of the connection 696 quit-answer = "201" [answertext] CRLF 698 Example 700 <-- QUIT 701 --> 201 Closing connection. Bye. 703 6.3.3.6. LIST 705 Description 707 To obtain a list of newsgroups and sub-hierarchies in the requested 708 hierarchies the command LIST is used. The status of the hierarchies 709 is also given. The highest level consists of all top-level 710 hierarchies and is labeled "*". It can be obtained this way, too. 712 The data consist of a newsgroup- or hierarchy-name/status indicator 713 pair per line. Name and status indicator must be separated by at 714 least one white space. The status indicator is a single word (see 715 section 6.4). The interpretation is not case sensitive. 717 list-cmd = "LIST" ( WSP "*" / 1*(WSP name)) CRLF 719 Possible answers 721 401: Permission denied 722 510: Syntax error 723 610: Normal response with all requested data 725 list-answer = "610" [answertext] CRLF 726 *(listdata CRLF) 727 "." CRLF 728 list-answer =/ "401" [answertext] CRLF 729 text CRLF 730 "." CRLF 731 list-answer =/ "510" [answertext] CRLF 732 text CRLF 733 "." CRLF 735 listdata = name WSP list-status 737 The list-status is the status of a newsgroup or hierarchy according 738 to section 6.4. 740 list-status = "Complete" / 741 "Incomplete" / 742 "Obsolete" / 743 "Unknown" / 744 "Unmoderated" / 745 "Readonly" / 746 "Moderated" / 747 "Removed" ; list-status is case-insensitive 749 Examples 751 <-- LIST * 752 --> 610 data follow 753 alt Incomplete 754 comp Complete 755 de Incomplete 756 rec Complete 757 sub Obsolete 758 . 760 <-- LIST de 761 --> 610 data follow 762 de.admin Complete 763 de.alt Incomplete 764 de.comm Complete 765 de.comp Complete 766 de.etc Complete 767 de.markt Complete 768 de.newusers Complete 769 de.org Complete 770 de.rec Complete 771 de.sci Complete 772 de.soc Complete 773 de.answers Moderated 774 de.test Unmoderated 775 . 777 <-- LIST foo 778 --> 610 data follow 779 foo Unknown 780 . 782 <-- LIST 783 --> 510 Syntax error 784 missing parameter hierarchy 785 . 787 <-- LIST de 788 --> 401 Something is wrong 789 Permission denied 790 . 792 6.3.3.7. LSTR 794 Description 796 To obtain a recursive list of newsgroups and sub-hierarchies in the 797 named hierarchy, the command LSTR is used. The status of the 798 hierarchies is also given. The highest level consists of all top- 799 level hierarchies and is labeled "*". It can be obtained this way, 800 too. 802 The use of "*" as a wildcard pattern following the beginning of a 803 hierarchy name is also possible; so a "LSTR de.a*" would return a 804 list of all newsgroups and hierarchies starting with "de.a". 806 lstr-cmd = "LSTR" ( WSP "*" / 1*(WSP name ["*" / ".*"]) ) CRLF 808 Possible answers 810 401: Permission denied 811 510: Syntax error 812 610: Normal answer with all requested data 814 lstr-answer = "610" [answertext] CRLF 815 *(listdata CRLF) 816 "." CRLF 817 lstr-answer =/ "401" [answertext] CRLF 818 text CRLF 819 "." CRLF 820 lstr-answer =/ "510" [answertext] CRLF 821 text CRLF 822 "." CRLF 824 listdata = name WSP list-status 826 The list-status is the status of a newsgroup or hierarchy according 827 to section 6.4. 829 list-status = "Complete" / 830 "Incomplete" / 831 "Obsolete" / 832 "Unknown" / 833 "Unmoderated" / 834 "Readonly" / 835 "Moderated" / 836 "Removed" ; list-status is case-insensitive 837 Example 839 <-- LSTR de.admin 840 --> 610 recursive mode 841 de.admin Complete 842 de.admin.infos Moderated 843 de.admin.lists Moderated 844 de.admin.misc Unmoderated 845 de.admin.net-abuse Complete 846 de.admin.net-abuse.announce Moderated 847 de.admin.net-abuse.mail Unmoderated 848 de.admin.net-abuse.misc Unmoderated 849 de.admin.net-abuse.news Unmoderated 850 de.admin.news Complete 851 de.admin.news.announce Moderated 852 de.admin.news.groups Unmoderated 853 de.admin.news.misc Unmoderated 854 de.admin.news.nocem Unmoderated 855 de.admin.news.regeln Unmoderated 856 . 858 6.3.3.8. HIER 860 Description 862 The command HIER lists all information available about the hierarchy. 863 With data header "Name" a new data block for each hierarchy is 864 started. The header "Name" gives the name of the hierarchy. The data 865 headers are described in section 6.3.4. The default is to transmit 866 all available information. It can be limited to a list of desired 867 headers ("Name" and "Status" are always given). A set of comma 868 separated headers, as an option to the HIER command, will return the 869 requested header fields. 871 hier-cmd = "HIER" 1*(WSP name) [WSP selection] CRLF 873 selection = *( "," header ) ; Describes the data fields 874 ; that are requested 875 header = ALPHA *( ALPHA / "-" ) ; According to section 6.3.4 877 Example for selection: 879 ,Followup,Description : for all entries list Name, Status, Followup 880 and Description 881 Possible answers 883 401: Permission denied 884 510: Syntax error 885 611: Regular answer with all requested data 887 hier-answer = "611" [answertext] CRLF 888 *(hierdata CRLF) 889 "." CRLF 890 hier-answer =/ "510" [answertext] CRLF 891 *(text CRLF) 892 "." CRLF 893 hier-answer =/ "401" [answertext] CRLF 894 *(text CRLF) 895 "." CRLF 897 hierdata = "Name:" WSP text CRLF 898 "Status:" WSP text CRLF 899 *(header ":" WSP text CRLF) 900 [("Ctl-PGP-Key:" CRLF PGP-answer / 901 "Mod-PGP-Key:" CRLF PGP-answer)] 903 PGP-answer: The exact format is described in section 6.7 905 Examples 907 <-- HIER de 908 --> 611 Data coming 909 Name: de 910 Status: Complete 911 Serial: 20020823120306 912 Description: Internationale deutschsprachige Newsgruppen 913 Netiquette: http://www.kirchwitz.de.example/~amk/dni/netiquette 914 FAQ: http://www.kirchwitz.de.example/~amk/dai/einrichtung 915 Ctl-Send-Adr: moderator@dana.de.example 916 Ctl-Newsgroup: de.admin.news.announce 917 Mod-Wildcard: %s@moderators.dana.de.example 918 Language: DE 919 Charset: ISO-8859-1 920 Encoding: text/plain 921 Newsgroup-Type: Discussion 922 Hier-Type: Global 923 Comp-Length: 14 924 Date-Create: 19920106000000 926 . 928 <-- HIER bln 929 --> 401 930 Permission denied 931 . 933 <-- HIER 934 --> 510 Syntax error 935 missing parameter hierarchy 936 . 938 6.3.3.9. DATA 940 Description 942 The DATA command corresponds to the HIER command as explained in 943 6.3.3.8, but it is used for information about a newsgroup. A summary 944 of codes can be found in section 6.3.4. 946 data-cmd = "DATA" 1*(WSP name) [WSP selection] CRLF 948 Possible answers 950 401: Permission denied 951 510: Syntax error 952 612: Regular answer with all requested data 954 data-answer = "612" [answertext] CRLF 955 *(datadata CRLF) 956 "." CRLF 957 data-answer =/ "510" [answertext] CRLF 958 text CRLF 959 "." CRLF 960 data-answer =/ "401" [answertext] CRLF 961 text CRLF 962 "." CRLF 964 datadata = "Name:" WSP text CRLF 965 "Status:" WSP text CRLF 966 *(header ":" WSP text CRLF) 967 [("Ctl-PGP-Key:" CRLF PGP-answer / 968 "Mod-PGP-Key:" CRLF PGP-answer)] 970 Examples 972 <-- DATA de.comp.os.unix.linux.moderated 973 --> 612 data follow 974 Name: de.comp.os.unix.linux.moderated 975 Status: Moderated 976 Serial: 20020823120312 977 Description: Linux und -Distributionen. 978 979 Charter: http://www.dana.de.example/mod/chartas/de.html 980 Netiquette: http://www.kirchwitz.de.example/~amk/dni/netiquette 981 Netiquette: ftp://ftp.fu-berlin.de.example/doc/usenet/german 982 /Netiquette 983 Mod-Sub-Adr: dcoulm-moderators@linux-config.de.example 984 Mod-Group-Info: http://wpxx02.toxi.uni-wuerzburg.de.example 985 /~dcoulmod/ 986 Newsgroup-Type: Discussion 988 . 990 <-- DATA de.foo 991 --> 612 data follow 992 Name: de.foo 993 Status: Unknown 995 . 997 <-- DATA de 998 --> 401 999 Permission denied 1000 . 1002 <-- DATA 1003 --> 510 Syntax error 1004 missing parameter newsgroup 1005 . 1007 6.3.3.10. GETP 1009 Description 1011 GETP is used for server-server communication. It requests the data 1012 for the hierarchy specified by the parameter "name". The format of 1013 the data is the same as for the commands "HIER" and "LIST". If "*" is 1014 given as hierarchy name, all data the server is offering will be 1015 transmitted. 1017 The "timestamp" attached to a package consists of the date and time 1018 that the package was created. The timestamp for a package is 1019 transmitted together with the package data by the server and marks a 1020 specific revision for the package data. 1022 When a client requests a package with GETP, it transmits the 1023 timestamp attached to the package in its database so that the server 1024 can check if the data on the client side is still valid or if it is 1025 too old. If the data on the client side is still valid a 213 answer 1026 is sent, so the client knows that its data is OK. If the timestamp is 1027 "0", the server is forced to transmit the data. Timestamps set by the 1028 server must be increasing and may not be more that 12 hours in the 1029 future. 1031 The data for a successful request are signed and sent in ASCII armor 1032 according to [RFC2440], so a client has the possibility to check the 1033 signature or to ignore it. The actual data will be surrounded by the 1034 armor start and end sections according to section 6.2 of [RFC2440]. 1036 getp-cmd = "GETP" WSP username WSP password WSP timestamp 1037 WSP ( name / "*" ) CRLF 1039 username = *1( VCHAR ) / "0" ; Length of VCHAR >= 1 1041 password = *1( VCHAR ) / "0" ; Length of VCHAR >= 1 1043 timestamp = utc-time / ; date and time of the last retrieval 1044 "0" ; force the transmission of data 1046 Possible answers 1048 213: Current data at the client side 1049 411: No hierarchy with that name 1050 430: Permission denied 1051 510: Syntax error 1052 613: Hierarchy data 1054 getp-answer = "613" [answertext] CRLF 1055 pgp-ascii-armor-start ; this is according to [RFC2440] 1056 *(getpdata CRLF) 1057 pgp-ascii-armor-end ; this is according to [RFC2440] 1058 "." CRLF 1059 getp-answer =/ "213" [answertext] CRLF 1060 text CRLF 1061 "." CRLF 1062 getp-answer =/ "430" [answertext] CRLF 1063 text CRLF 1064 "." CRLF 1065 getp-answer =/ "411" [answertext] CRLF 1066 text CRLF 1067 "." CRLF 1068 getp-answer =/ "510" [answertext] CRLF 1069 text CRLF 1070 "." CRLF 1072 pgp-ascii-armor-start and the pgp-ascii-armor-end are built according 1073 to [RFC2440], Section 6.2., "Forming ASCII Armor". 1075 getpdata = "Name:" WSP text CRLF 1076 "Status:" WSP text CRLF 1077 "Serial:" WSP timestamp CRLF 1078 *(header ":" WSP text CRLF) 1079 [("Ctl-PGP-Key:" CRLF PGP-answer / 1080 "Mod-PGP-Key:" CRLF PGP-answer)] 1082 Examples 1084 <-- GETP 0 0 0 humanities 1085 --> 615 data follow 1086 -----BEGIN PGP SIGNED MESSAGE----- 1087 Hash: SHA1 1089 Name: humanities 1090 Status: Complete 1091 Serial: 20020821094529 1092 Description: branches of learning that investigate human 1093 constructs and concerns as opposed to natural processes 1094 Netiquette: ftp://rtfm.mit.edu.example/pub/usenet 1095 /news.announce.newusers 1096 /A_Primer_on_How_to_Work_With_the_Usenet_Community 1097 Rules: http://www.uvv.org.example/docs/howto.txt 1098 Ctl-Send-Adr: group-admin@isc.org.example 1099 Ctl-Newsgroup: news.announce.newgroup 1100 Language: EN 1101 Charset: US-ASCII 1102 Encoding: text/plain 1103 Newsgroup-Type: Discussion 1104 Hier-Type: Global 1105 Comp-Length: 14 1106 Date-Create: 19950417143009 1108 Name: humanities.answers 1109 Status: Moderated 1110 Serial: 20020821094533 1111 Description: Repository for periodic USENET articles. (Moderated) 1112 Mod-Sub-Adr: news-answers@mit.edu.example 1113 Mod-Adm-Adr: news-answers-request@mit.edu.example 1114 Newsgroup-Type: Announce 1115 Date-Create: 19950725182040 1116 Name: humanities.classics 1117 [...] 1118 -----BEGIN PGP SIGNATURE----- 1119 Version: GnuPG v1.0.7 (IRIX64) 1121 iD8DBQE9Zj/Wn13IYldLZg8RAhWiAJ4y7o+3FzBpRjYJj2HWwXyG2g8FoQCfeEsH 1122 rRynPhhjveiY/XBkkrrZFho= 1123 =muK4 1124 -----END PGP SIGNATURE----- 1125 . 1127 <-- GETP 0 0 19990909101000 de 1128 --> 213 1129 You are up-to-date 1130 . 1132 <-- GETP foo 1133 --> 510 Syntax error 1134 Missing parameters 1135 . 1137 <-- GETP guest test 0 de 1138 --> 430 1139 You have no permission to retrieve the data 1140 . 1142 6.3.3.11. GETA 1144 Description 1146 The GETA command is used for server-server communication; it is used 1147 to collect authoritative data and will request packages that the 1148 server is authoritative for. A package is the authoritative data 1149 either for a newsgroup or a hierarchy. Each package has a "timestamp" 1150 attached to mark the revision of the package. This timestamp is set 1151 by the server and of the date of the last modification of the 1152 package data in UTC format. A timestamp of "0" indicates that the 1153 package MUST be retrieved. If the retrieving client has a recent 1154 package (i.e. no modification on the authoritative server), the 1155 server sends only a 215 response. The format of the data is the same 1156 as for the commands "HIER" and "LIST". 1158 geta-cmd = "GETA" WSP username WSP password WSP 1159 timestamp WSP name CRLF 1160 Possible answers 1162 215: The client already has the current data 1163 430: Permission denied 1164 411: No hierarchy with that name 1165 510: Syntax error 1166 615: Regular answer with all requested data 1168 geta-answer = "615" [answertext] CRLF 1169 pgp-ascii-armor-start ; this is according to [RFC2440] 1170 *(getadata CRLF) 1171 pgp-ascii-armor-end ; this is according to [RFC2440] 1172 "." CRLF 1173 geta-answer =/ "215" [answertext] CRLF 1174 text CRLF 1175 "." CRLF 1176 geta-answer =/ "430" [answertext] CRLF 1177 text CRLF 1178 "." CRLF 1179 geta-answer =/ "411" [answertext] CRLF 1180 text CRLF 1181 "." CRLF 1182 geta-answer =/ "510" [answertext] CRLF 1183 text CRLF 1184 "." CRLF 1186 getadata = "Name:" WSP text CRLF 1187 "Status:" WSP text CRLF 1188 "Serial:" WSP timestamp CRLF 1189 *(header ":" WSP text CRLF) 1190 [("Ctl-PGP-Key:" CRLF PGP-answer/ 1191 "Mod-PGP-Key:" CRLF PGP-answer)] 1193 Example 1195 <-- GETA 0 0 0 humanities 1196 --> 613 data follow 1197 -----BEGIN PGP SIGNED MESSAGE----- 1198 Hash: SHA1 1200 Name: humanities 1201 Status: Complete 1202 Serial: 20020821094529 1203 Description: branches of learning that investigate human 1204 constructs and concerns as opposed to natural processes 1205 Netiquette: ftp://rtfm.mit.edu.example/pub/usenet 1206 /news.announce.newusers 1207 /A_Primer_on_How_to_Work_With_the_Usenet_Community 1208 Rules: http://www.uvv.org.example/docs/howto.txt 1209 Ctl-Send-Adr: group-admin@isc.org.example 1210 Ctl-Newsgroup: news.announce.newgroup 1211 Language: EN 1212 Charset: US-ASCII 1213 Encoding: text/plain 1214 Newsgroup-Type: Discussion 1215 Hier-Type: Global 1216 Comp-Length: 14 1217 Date-Create: 19950417143009 1219 Name: humanities.answers 1220 Status: Moderated 1221 Serial: 20020821094533 1222 Description: Repository for periodic USENET articles. (Moderated) 1223 Mod-Sub-Adr: news-answers@mit.edu.example 1224 Mod-Adm-Adr: news-answers-request@mit.edu.example 1225 Newsgroup-Type: Announce 1226 Date-Create: 19950725182040 1228 Name: humanities.classics 1229 [...] 1230 -----BEGIN PGP SIGNATURE----- 1231 Version: GnuPG v1.0.7 (IRIX64) 1233 iD8DBQE9Zj/Wn13IYldLZg8RAhWiAJ4y7o+3FzBpRjYJj2HWwXyG2g8FoQCfeEsH 1234 rRynPhhjveiY/XBkkrrZFho= 1235 =muK4 1236 -----END PGP SIGNATURE----- 1237 . 1239 6.3.3.12. Unknown Commands and Syntax Errors 1241 If a command is recognized as unknown, a 519 return code (unknown 1242 command) is given. If an error occurs after the command string (e.g. 1243 a missing parameter) a 510 return code (Syntax error: Missing 1244 parameter) is given. 1246 6.3.4. Data Headers 1248 The following paragraphs describe keywords and key terms which 1249 support retrieval and storing of information. Every header has a 1250 unique English name. 1252 The content of a header is inheritable within a hierarchy, as long as 1253 the header is marked as inheritable. The content is the default value 1254 for all downstream newsgroups and sub-hierarchies. For example in the 1255 hierarchy "de", the language header has the value "DE" (German), 1256 therefore this value is "DE" for all newsgroups in this hierarchy, 1257 except for those which explicitly define a language code of their 1258 own. 1260 Hierarchies and newsgroups must have at least values for the headers 1261 "Name" and "Status". Unknown hierarchies or groups get the status 1262 "Unknown". 1264 The header used in the NAS protocol are not case sensitive. A header 1265 may be upper case, lower case, or any mixture of upper and lower 1266 case. It is recommended that the first letter of the header and the 1267 first letter after a dash are uppercase while all other characters 1268 are lowercase. 1270 Name 1272 Header: Name 1274 Used for: hierarchy 1275 Mandatory: yes 1276 Inheritable: no 1277 Repeatable: no 1278 Description: Name of a hierarchy 1279 Comment: Start of a new data block 1280 Example: Name: comp 1282 Used for: newsgroup 1283 Mandatory: yes 1284 Repeatable: no 1285 Description: Name of a newsgroup 1286 Comment: Start of a new data block 1287 Example: Name: de.admin.news.announce 1288 Status 1290 Header: Status 1292 Used for: hierarchy 1293 Mandatory: yes 1294 Inheritable: no 1295 Repeatable: no 1296 Description: Status of a hierarchy 1297 Comment: For a detailed description see section 6.4. 1298 Example: Status: Hierarchy-Complete 1300 Used for: newsgroup 1301 Mandatory: yes 1302 Repeatable: no 1303 Description: Status of a newsgroup 1304 Comment: For a detailed description see section 6.4. 1305 Example: Status: Group-Moderated 1307 Serial 1309 Header: Serial 1311 Used for: hierarchy 1312 Mandatory: no 1313 Inheritable: no 1314 Repeatable: no 1315 Description: Timestamp for hierarchy data 1316 Comment: For a detailed description see section 6.4. 1317 Example: Serial: 20020821102413 1319 Used for: newsgroup 1320 Mandatory: no 1321 Inheritable: no 1322 Repeatable: no 1323 Description: Timestamp for newsgroup data 1324 Comment: For a detailed description see section 6.4. 1325 Example: Serial: 20020821102413 1326 Group for followup 1328 Header: Followup 1330 Used for: newsgroup 1331 Mandatory: no 1332 Repeatable: no 1333 Description: Name of the newsgroup that will take the followup 1334 postings of a moderated group. 1335 Comment: The value can be used as default value for the 1336 "Followup-To:" header on postings to a moderated group. 1337 This value is only useful on groups that which are moderated 1338 (Status Group-Moderated) and have a dedicated discussion group. 1339 Example: Followup: bln.announce.fub.zedat.d 1340 (for the moderated group bln.announce.fub.zedat) 1342 Short description 1344 Header: Description 1346 Used for: hierarchy 1347 Mandatory: no 1348 Inheritable: no 1349 Repeatable: no 1350 Description: Short description of a hierarchy 1351 Example: Description: Angelegenheiten, die den Grossraum Berlin 1352 betreffen 1353 (for the hierarchy bln) 1355 Used for: newsgroup 1356 Mandatory: no 1357 Repeatable: no 1358 Description: Short description of a newsgroup 1359 Comment: This information is often presented to the news reader 1360 upon selection of the newsgroup, and it should be a 1361 brief but meaningful description of the topic 1362 Example: Description: Technisches zur Newssoftware 1363 (for de.admin.news.software) 1364 Charter-URL 1366 Header: Charter 1368 Used for: hierarchy 1369 Mandatory: no 1370 Inheritable: no 1371 Repeatable: yes 1372 Description: URL that points to the charter of a hierarchy 1373 Example: Charter: ftp://ftp.fu-berlin.de.example/doc/news/bln/bln 1374 (for the hierarchy bln) 1376 Used for: newsgroup 1377 Mandatory: no 1378 Repeatable: yes 1379 Description: URL that points to the charter of a newsgroup 1380 Comment: This information should be presented to the 1381 news reader upon selection of the newsgroup. 1382 Example: Charter: ftp://ftp.fu-berlin.de.example/doc/news/bln 1383 /bln.markt.arbeit 1385 Netiquette-URL 1387 Header: Netiquette 1389 Used for: hierarchy 1390 Mandatory: no 1391 Inheritable: yes 1392 Repeatable: yes 1393 Description: URL that points to the netiquette of a hierarchy. 1394 Comment: Since the netiquettes are often valid for 1395 a complete hierarchy this is inheritable. 1396 Example: Netiquette: http://www.kirchwitz.de.example/~amk/dni/netiquette 1398 Used for: newsgroup 1399 Mandatory: no 1400 Repeatable: yes 1401 Description: URL for Netiquette 1402 Comment: If a group has some special rules, this is the 1403 pointer to these rules. 1404 Example: Netiquette: http://go.to.example/bln.markt 1405 (for bln.markt) 1406 Frequently Asked Questions (FAQ) 1408 Header: FAQ 1410 Used for: Newsgroup 1411 Mandatory: no 1412 Repeatable: yes 1413 Description: URL for the FAQ of a newsgroup 1414 Example: FAQ: http://www.dard.de.example/ 1416 Administration rules 1418 Header: Rules 1420 Used for: hierarchy 1421 Mandatory: no 1422 Inheritable: yes 1423 Repeatable: yes 1424 Description: URL pointing to a document that describes the rules for 1425 creating, deleting or renaming newsgroups in this 1426 hierarchy. 1427 Comment: Normally inherited from the toplevel hierarchy 1428 Example: Rules: http://www.kirchwitz.de.example/~amk/dai 1429 /einrichtung 1431 Control Email 1433 Header: Ctl-Send-Adr 1435 Used for: hierarchy 1436 Mandatory: no 1437 Inheritable: yes 1438 Repeatable: yes 1439 Description: Email address of the sender of control messages 1440 Comment: Multiple addresses are valid 1441 Example: Ctl-Send-Adr: group-admin@isc.org.example 1442 Control newsgroup 1444 Header: Ctl-Newsgroup 1446 Used for: hierarchy 1447 Mandatory: no 1448 Inheritable: yes 1449 Repeatable: yes 1450 Description: Name of the newsgroup that will get the postings for 1451 checkgroups, rmgroup and newsgroup control messages. 1452 Example: Ctl-Newsgroup: de.admin.news.groups 1454 Moderators 1456 Header: Mod-Wildcard 1458 Used for: hierarchy 1459 Mandatory: no 1460 Inheritable: yes 1461 Repeatable: no 1462 Description: Moderator wildcard for this hierarchy. 1463 Comment: This information can be used for the configuration of the 1464 news software, for example, to configure the moderators 1465 file in INN. 1466 Example: Mod-Wildcard: %s@moderators.dana.de.example 1467 (for the hierarchy de) 1469 Submission address 1471 Header: Mod-Sub-Adr 1473 Used for: newsgroup 1474 Mandatory: no 1475 Repeatable: yes 1476 Description: Email address for submissions to the newsgroup. 1477 Comment: If there is no "Mod-Sub-Adr" for a moderated newsgroup, 1478 "Mod-Wildcard" of the hierarchy is used. This is useful 1479 only for moderated groups (Status Group-Moderated). 1480 Example: Mod-Sub-Adr: news-answers@mit.edu.example 1481 (for the newsgroup news.answers) 1482 Moderator's address (email) 1484 Header: Mod-Adm-Adr 1486 Used for: newsgroup 1487 Mandatory: no 1488 Repeatable: yes 1489 Description: Email address of the moderator of the newsgroup. 1490 Comment: If there is no code "Mod-Adm-Adr" for a moderated 1491 newsgroup, "Mod-Wildcard" of the hierarchy is used. 1492 This is useful only for moderated groups 1493 (Status Group-Moderated). 1494 Example: Mod-Adm-Adr: news-answers-request@mit.edu.example 1495 (for the newsgroup news.answers) 1497 Info-URL 1499 Header: Mod-Group-Info 1501 Used for: newsgroup 1502 Mandatory: no 1503 Repeatable: yes 1504 Description: URL that points to a document where the moderator 1505 presents information about the newsgroup and the 1506 submission of articles. 1507 Example: Mod-Group-Info: http://www.example.org/cola-submit.html 1508 (for comp.os.linux.announce) 1509 Language 1511 Header: Language 1513 Used for: hierarchy 1514 Mandatory: no 1515 Inheritable: yes 1516 Repeatable: yes 1517 Description: The language that will normally be used in postings 1518 Comment: The notation is according to the "Content-Language" 1519 field of [RFC2616]. The languages not 1520 preferred are enclosed in parenthesis. 1521 Example: Language: DE 1522 (for the hierarchy de) 1524 Used for: newsgroup 1525 Mandatory: no 1526 Repeatable: yes 1527 Description: The language that will normally be used in postings. 1528 Comment: The notation is according to the "Content-Language" 1529 field of [RFC2616]. The languages not 1530 preferred are enclosed in parenthesis. 1531 Example: Language: TR 1532 Language: DE 1533 Language: (EN) 1534 (for the newsgroup bln.kultur.tuerkisch) 1535 Charset 1537 Header: Charset 1539 Used for: hierarchy 1540 Mandatory: no 1541 Inheritable: yes 1542 Repeatable: yes 1543 Description: Charset that will normally be used in postings in this 1544 hierarchy 1545 Comment: The complete set of charset names is defined by 1546 [RFC2277] and the IANA Character Set registry [IANA-CS]. 1547 The charsets that are not the preferred charsets are 1548 enclosed in parenthesis. 1549 Example: Charset: ISO-8859-1 1550 (for the hierarchy de) 1552 Used for: newsgroup 1553 Mandatory: no 1554 Repeatable: yes 1555 Description: Charset that will normally be used in 1556 postings in this group 1557 Comment: The complete set of charset names is defined by 1558 [RFC2277] and the IANA Character Set registry 1559 [IANA-CS]. The charsets that are not the preferred 1560 charsets are enclosed in parenthesis. 1561 Example: Charset: ISO-8859-9 1562 Charset: ISO-8859-1 1563 (for the newsgroup bln.kultur.tuerkisch) 1564 Encoding 1566 Header: Encoding 1568 Used for: hierarchy 1569 Mandatory: no 1570 Inheritable: yes 1571 Repeatable: yes 1572 Description: Encoding for this hierarchy according to MIME [RFC2045] 1573 Comment: This is the media type used in this hierarchy, a list of 1574 registered media types can be found at [IANA-MT]. The 1575 encodings not preferred are 1576 enclosed in parenthesis. 1577 Example: Encoding text/plain 1579 Used for: newsgroup 1580 Mandatory: no 1581 Repeatable: yes 1582 Description: Encoding for this newsgroup according to MIME [RFC2045] 1583 Comment This is the media type used in this newsgroup, a list of 1584 registered media types can be found at [IANA-MT]. The 1585 encodings not preferred are 1586 enclosed in parenthesis. 1587 Example: Encoding: text/plain 1588 Type of newsgroup 1590 Header: Newsgroup-Type 1592 Used for: hierarchy 1593 Mandatory: no 1594 Inheritable: yes 1595 Repeatable: yes 1596 Description: Default newsgroup type in this hierarchy 1597 Comment: This header has no concrete meaning for a hierarchy but 1598 is used for the inheritance to newsgroups in the 1599 hierarchy. 1600 Specification of the types can be found in section 6.5 1601 Example: Newsgroup-Type: Discussion 1602 (for the hierarchy de) 1604 Used for: newsgroup 1605 Mandatory: no 1606 Repeatable: yes 1607 Description: Type of newsgroup 1608 Comment: Specification of the types can be found in section 6.5 1609 Example: Newsgroup-Type: Announce 1610 (for de.admin.news.announce) 1612 Type of hierarchy 1614 Header: Hier-Type 1616 Used for: hierarchy 1617 Mandatory: no 1618 Inheritable: yes 1619 Repeatable: yes 1620 Description: Type of hierarchy 1621 Comment: Specification of the types can be found in section 6.6 1622 Example: Hier-Type: Regional 1623 (for hierarchy bln) 1624 Regional or Organizational Area 1626 Header: Area 1628 Used for: hierarchy 1629 Mandatory: no 1630 Inheritable: yes 1631 Repeatable: yes 1632 Description: Description of the geographical region or organization 1633 of this hierarchy 1634 Comment: This code is useful when the hierarchy type 1635 (Hier-Type) is "Regional" or "Organization". 1636 Example: Area: Grossraum Berlin 1637 (for the hierarchy bln) 1639 Name length of group names 1641 Header: Name-Length 1643 Used for: hierarchy 1644 Mandatory: no 1645 Inheritable: yes 1646 Repeatable: no 1647 Description: Maximum length of a newsgroup name 1648 Example: Name-Length: 72 1649 (for the hierarchy bln) 1651 Component length of group names 1653 Header: Comp-Length 1655 Used for: hierarchy 1656 Mandatory: no 1657 Inheritable: yes 1658 Repeatable: no 1659 Description: Maximum length of a single component in the newsgroup 1660 name 1661 Example: Comp-Length: 14 1662 (for the hierarchy de) 1663 Article length 1665 Header: Article-Length 1667 Used for: hierarchy 1668 Mandatory: no 1669 Inheritable: yes 1670 Repeatable: no 1671 Description: Maximum length of an article in bytes 1672 Comment: This header has no concrete meaning for a hierarchy, but 1673 is used for the inheritance to newsgroups in the 1674 hierarchy. 1675 Example: Article-Length: 50000 1677 Used for: newsgroup 1678 Mandatory: no 1679 Repeatable: no 1680 Description: Maximum length of an article in bytes 1681 Example: Article-Length: 50000 1683 Date of creation 1685 Header: Date-Create 1687 Used for: hierarchy 1688 Mandatory: no 1689 Inheritable: yes 1690 Repeatable: no 1691 Description: Creation date of a hierarchy, can even be in the future. 1692 Comment: The format is the same as in the DATE command. 1693 Example: Date-Create: 19970330101514 1695 Used for: newsgroup 1696 Mandatory: no 1697 Repeatable: no 1698 Description: Creation date of a newsgroup, can even be in the future. 1699 Comment: The format is the same as in the DATE command. 1700 Example: Date-Create: 19970330101514 1701 Date of removal 1703 Header: Date-Delete 1705 Used for: hierarchy 1706 Mandatory: no 1707 Inheritable: yes 1708 Repeatable: no 1709 Description: Date of removal of a hierarchy, can even be in the 1710 future. 1711 Comment: The format is the same as in the DATE command. 1712 Example: Date-Delete: 19970330101514 1714 Used for: newsgroup 1715 Mandatory: no 1716 Repeatable: no 1717 Description: Date of removal of a newsgroup, can even be in the 1718 future. 1719 Comment: The format is the same as in the DATE command. 1720 Example: Date-Delete: 19970330101514 1722 Successor 1724 Header: Replacement 1726 Used for: hierarchy 1727 Mandatory: no 1728 Inheritable: no 1729 Repeatable: yes 1730 Description: Name of the hierarchy that replaced a removed hierarchy 1731 if status is "Hierarchy-Obsolete" or will replace a 1732 hierarchy if the date of removal is in the future. 1733 Example: Replacement: de 1734 (for the hierarchy sub) 1736 Used for: newsgroup 1737 Mandatory: no 1738 Repeatable: yes 1739 Description: Name of the newsgroup or newsgroups that will replace a 1740 removed newsgroup if status is "Group-Removed" or will 1741 replace the newsgroup if the date of removal is in the 1742 future. 1743 Example: Replacement: bln.markt.arbeit 1744 (for bln.jobs) 1745 Source 1747 Header: Source 1749 Used for: hierarchy 1750 Mandatory: no 1751 Inheritable: yes 1752 Repeatable: no 1753 Description: Pointer to an organization or person responsible 1754 for this hierarchy. SHOULD be a URL or an email address. 1755 Example: Source: http://www.dana.de.example/mod/ 1756 (for the hierarchy de) 1758 NOTE: This is for tracking the maintainer of a hierarchy 1760 Control PGP key 1762 Header: Ctl-PGP-Key 1764 Used for: hierarchy 1765 Mandatory: no 1766 Inheritable: yes 1767 Repeatable: yes 1768 Description: PGP key (with additional information: key owner, key-id, 1769 etc.) of the sender of control messages in this 1770 hierarchy. 1771 Comment: The exact format is described in section 6.7. 1772 Example: Ctl-PGP-Key: 1773 U de.admin.news.announce 1774 B 1024 1775 I D3033C99 1776 L http://www.dana.de.example/mod/pgp/dana.asc 1777 L ftp://ftp.isc.org.example/pub/pgpcontrol/PGPKEYS.gz 1778 F 5B B0 52 88 BF 55 19 4F 66 7D C2 AE 16 26 28 25 1779 V 2.6.3ia 1780 K------BEGIN PGP PUBLIC KEY BLOCK----- 1781 K-Version: 2.6.3ia 1782 K- 1783 K-mQCNEALZ+Xfm/WDCEMXM48gK1PlKG6TkV3SLbXt4CnzpGM0tOMa 1784 K-HjlHqM1wEGUHD5hw/BL/heR5Tq+C5IEyXQQmYwkrgeVFMOz/rAQ 1785 [...] 1786 K-SDw+iQgAAtN6zrYOhHFBp+ 1787 K-VpvRovMz+lSOy9Zcsbs+5t8Pj9ZVAQyfxBkqD5A= 1788 K-=Xwgc 1789 K -----END PGP PUBLIC KEY BLOCK----- 1790 Moderator's PGP key 1792 Header: Mod-PGP-Key 1794 Used for: newsgroup 1795 Mandatory: no 1796 Repeatable: yes 1797 Description: Public PGP key (with additional information: key owner, 1798 key-id, etc) of this newsgroup's moderator. 1799 Comment: The exact format is described in section 6.7 1800 Example: see section 6.7 1802 6.4. Status Indicators 1804 The status indicator uniquely determines the status of a hierarchy or 1805 newsgroup. The indicator is case-insensitive. 1807 Indicator Type Description 1808 ----------- --------- ------------------------------------------- 1809 Complete hierarchy authorized, complete known hierarchy 1810 Incomplete hierarchy not completely known hierarchy (like free.*) 1811 Obsolete hierarchy obsolete hierarchy, should contain only 1812 newsgroups with status "Removed" 1813 Unknown hierarchy no information available, unknown hierarchy 1814 Unmoderated newsgroup posting allowed, unmoderated 1815 Readonly newsgroup posting not allowed 1816 Moderated newsgroup moderated group, articles must be sent to 1817 the moderator 1818 Removed newsgroup deleted or renamed newsgroup, no posting or 1819 transport 1820 Unknown newsgroup unknown group, no information available 1821 ----------- --------- ------------------------------------------- 1823 6.5. Newsgroup Types 1825 A Newsgroup Type is a comprehensive overview about some 1826 characteristics of a newsgroup, being a test group, a binary group 1827 and so on. The Newsgroup Type is case-insensitive. 1829 Type Meaning 1830 ----------- ------------------------------------------------------ 1831 Discussion discussion (text postings) 1832 Binary (encoded) binary postings 1833 Sources source postings (e.g., comp.unix.sources) 1834 Announce announcements, press releases, RfD/CfV 1835 Test test postings, sometimes reflectors (e.g., de.test) 1836 Robots automatic postings (like the former comp.mail.maps) 1837 Experiment experimental, other 1838 ----------- ------------------------------------------------------ 1840 6.6. Hierarchy Types 1842 To describe a hierarchy the following Hierarchy Types are used. These 1843 Types are used to mark some properties of a news hierarchy. They are 1844 case-insensitive. 1846 Type Meaning 1847 -------------- --------------------------------------------------- 1848 Global international, global hierarchy 1849 (e.g., the hierarchies comp, de, rec) 1850 Regional regional hierarchy 1851 (e.g., the hierarchies ba, bln, tor) 1852 Alt alternative hierarchy, simpler rules for 1853 creating a group, no formal structure 1854 (e.g., the hierarchy alt) 1855 Non-Commercial only for personal use, commercial use is prohibited 1856 (e.g., the hierarchy de) 1857 Commercial commercial use permitted (e.g., the hierarchy biz) 1858 Organization hierarchy bound to an organization 1859 (e.g., the hierarchy gnu) 1860 -------------- --------------------------------------------------- 1862 6.7. PGP Keys 1864 PGP keys for Ctrl-PGP-Key and Mod-PGP-Key are transmitted in the 1865 following structure: 1867 PGP-answer = "V" SP Version CRLF 1868 "U" SP User-ID CRLF 1869 "B" SP Bits CRLF 1870 "I" SP Key-ID CRLF 1871 "F" SP Finger CRLF 1872 *("L" SP Location CRLF) 1873 *("K-" Keyblock CRLF) 1874 "K" SP Keyblock CRLF 1876 Version = text 1877 User-ID = text 1878 Bits = text 1879 Key-ID = text 1880 Finger = text 1881 Location = text 1882 Keyblock = text 1884 Key Name Mandatory Description 1885 --- --------- --------- -------------------------------------- 1886 K Keyblock yes public key block in ASCII armor format 1887 [RFC2440] 1888 V Version yes PGP-Version 1889 U User-ID no key user id 1890 B Bits no number of bits 1891 I Key-ID no key id, without leading "0x" 1892 F Finger no fingerprint 1893 L Location no URL that points to the public key 1894 --- --------- --------- -------------------------------------- 1896 A hyphen following the code indicates that the block is continued on 1897 the next line. In the last message row, there MUST be white space 1898 after the code; this is also true for a single line code. 1900 Example 1902 <-- HIER de 1903 --> 611 Data coming 1904 Name: de 1905 Status: Hierarchy 1906 [...] 1907 Ctl-PGP-Key: 1908 U de.admin.news.announce 1909 B 1024 1910 I D3033C99 1911 L http://www.dana.de.example/mod/pgp/dana.asc 1912 L ftp://ftp.fu-berlin.de.example/unix/news/pgpcontrol/PGPKEYS.gz 1913 F 5B B0 52 88 BF 55 19 4F 66 7D C2 AE 16 26 28 25 1914 V 2.6.3ia 1915 K------BEGIN PGP PUBLIC KEY BLOCK----- 1916 K-Version: 2.6.3ia 1917 K- 1918 K-mQCNAzGeB/YAAAEEALZ+Xfm/WDCEMXM48gK1PlKG6TkV3SLbXt4CnzpGMtOM 1919 K-HjlHaU6Xco5ijAuqM1wEGUHD5hw/BL/heR5Tq+C5IEyXQQmYwkrgeVFMO/rA 1920 [...] 1921 K-SDw+Id0JPFO9AWOiQgAAtN6zrYOhHFBp+68h9k674Yg9IHqj3BWdRjJF6PKo 1922 K-VpvRovMz+lSOy9Zcsbs+5t8Pj9ZVAQyfxBkqD5A= 1923 K-=Xwgc 1924 K -----END PGP PUBLIC KEY BLOCK----- 1925 [...] 1927 . 1929 7. Specification of the NAS Protocol (UDP) 1931 UDP is intended for reading programs (news readers), it is not in the 1932 scope of this document, and the use of UDP for NAS will be described 1933 in a separate paper. 1935 8. IANA Considerations 1937 IANA is asked to register the application/nasdata media type as 1938 defined by the following information: 1940 Media type name: application 1941 Media subtype name: nasdata 1942 Required parameters: none 1943 Optional parameters: level 1945 The NAS protocol level number for the enclosed NAS 1946 data package. If not present, the protocol level 1947 defaults to 1. 1949 Encoding scheme: NAS data is plain text; no special encodings are needed. 1951 Security considerations: see below 1953 9. Security Considerations 1955 Security issues are only addressed in respect to server-server 1956 communication in this protocol level. Username and password 1957 combinations in the GETA and GETP commands can be used to make sure 1958 that connections are only accepted from authorized clients. PGP keys 1959 according to [RFC2440] are used to sign NAS data in server-server 1960 communication in order to validate that data is authentic and has not 1961 been tampered with. 1963 Every server does have the possibility (in both server-server and 1964 server-client communication) to deny some commands or the whole 1965 connection based on the client's IP number. 1967 No mechanisms are defined in the current protocol level to allow a 1968 client to validate that it is talking to a legitimate server and/or 1969 that the data it receives is authentic. 1971 A stronger authentication scheme will be provided in a higher 1972 protocol level. 1974 10. Response Codes (Overview) 1976 Code Description 1977 ---- -------------------------------------------------------------- 1978 100 Command overview, Information, command description (HELP) 1979 101 Information about connection, client and server (INFO) 1980 200 Greeting message (Connection Setup) 1981 201 Termination of the connection (QUIT) 1982 202 Returns current protocol level (VERS) 1983 213 Valid data at the client side (GETP) 1984 215 The client already has the current data (GETA) 1985 300 Time in UTC (DATE) 1986 302 Answer to a successful request (VERS) 1987 400 Indicates that the server is not giving any information (INFO) 1988 401 Permission denied (LIST, LSTR, HIER, DATA) 1989 402 Requested level too high, falling back to lower level (VERS) 1990 404 Server currently out of service (Connection Setup) 1991 410 Indicates that the server is not giving any information (HELP) 1992 411 No hierarchy with that name (GETP, GETA) 1993 430 Permission denied (GETP, GETA) 1994 434 Client has no permission to talk to server (Connection Setup) 1995 510 Syntax error 1996 511 Internal error (TIME) 1997 513 Line too long 1998 519 Unknown command 1999 610 Regular answer with all requested data (LIST, LSTR) 2000 611 Regular answer with all requested data (HIER) 2001 612 Regular answer with all requested data (DATA) 2002 613 hierarchy data (GETP) 2003 615 Regular answer with all requested data (GETA) 2004 ---- -------------------------------------------------------------- 2006 11. Data Headers for DATA and HIER Commands (Overview) 2008 Header Mandatory Use Multiple Description 2009 ------------- --------- --- -------- --------------------- 2010 Name yes H/N no Name of a hierarchy 2011 or newsgroup (Start 2012 of a new data block) 2013 Status yes H/N no Status of hierarchy 2014 or newsgroup 2015 Serial no H/N no Revision of hierarchy 2016 / newsgroup data 2017 Followup no N no Group for followup 2018 Description no H/N no Short description of 2019 a hierarchy/newsgroup 2020 Charter no H/N yes Charter-URL 2021 Netiquette no H/N yes Netiquette-URL 2022 FAQ no N yes FAQ-URL 2023 Rules no H yes Administration rules 2024 URL 2025 Ctl-Send-Adr no H yes Control email 2026 Ctl-Newsgroup no H yes Control newsgroup 2027 Mod-Wildcard no H no Moderator wildcard 2028 Mod-Sub-Adr no N no Submission address 2029 Mod-Adm-Adr no N yes Moderator's address 2030 (email) 2031 Mod-Group-Info no N yes Info-URL 2032 Language no H/N yes Language 2033 Charset no H/N yes Charset 2034 Encoding no H/N yes Encoding 2035 Newsgroup-Type no H/N yes Type of newsgroup 2036 Hier-Type no H yes Type of hierarchy 2037 Area no H yes Regional or 2038 organizational area 2039 Name-Length no H no Total length of group 2040 names 2041 Comp-Length no H no Component length of 2042 group names 2043 Article-Length no H no Article length 2044 Date-Create no H/N no Date of creation 2045 Date-Delete no H/N no Date of removal 2046 Replacement no H/N yes Successor 2047 Source no H yes Source of data 2048 Ctl-PGP-Key no H yes Control PGP key 2049 Mod-PGP-Key no N yes Moderator's PGP key 2050 ------------- --------- --- -------- --------------------- 2052 N: Newsgroup, H: Hierarchy 2054 12. References 2056 12.1. Normative References 2058 [IANA-CS] IANA: Character Sets, 2059 http://www.iana.org/assignments/character-sets 2061 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 2062 Extensions (MIME) Part One: Format of Internet Message 2063 Bodies.", RFC 2045, Innosoft/First Virtual, November 1996. 2065 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 2066 Requirement Levels", RFC 2119, Harvard University, 2067 March 1997. 2069 [RFC2234] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax 2070 Specifications: ABNF", RFC 2234, November 1997. 2072 [RFC2277] H. Alvestrand, "IETF Policy on Character Sets and 2073 Languages", RFC 2277, January 1998. 2075 [RFC2440] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, 2076 "OpenPGP Message Format", RFC 2440, November 1998. 2078 [RFC2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, 2079 P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol -- 2080 HTTP/1.1", RFC 2616, June 1999. 2082 12.2. Informative References 2084 [IANA-MT] IANA: Media Types, 2085 http://www.iana.org/assignments/ 2087 [IANA-PN] IANA: Assigned Port Numbers, 2088 http://www.iana.org/assignments/port-numbers 2090 [ISC-INN] ISC: Internet Software Consortium, 2091 ftp://ftp.isc.org/isc/inn/ 2093 [RFC1305] D.L. Mills, "Network Time Protocol", RFC 1305, 2094 University of Delaware, March 1992. 2096 [SON1036] H. Spencer, "News Article Format and Transmission", 2097 A Draft for an RFC 1036 Successor, 2098 ftp://zoo.toronto.edu/pub/news.txt.Z. 2100 [USEFOR] USEFOR Working Group, "News Article Format", 2101 draft-ietf-usefor-article-14. 2103 13. Author's Address 2105 Philipp Grau, Vera Heinau, Heiko Schlichting, Robert Schuettler 2106 Freie Universitaet Berlin 2107 ZEDAT, DFN-CIS 2108 Fabeckstr. 32 2109 14195 Berlin 2110 Germany 2112 Phone: +49 30 838-56583 2113 Fax: +49 30 838-56721 2115 Email: nas@fu-berlin.de 2116 WWW: http://nas.fu-berlin.de/ 2118 14. Full Copyright Statement 2120 Copyright (C) The Internet Society (2005). 2122 This document is subject to the rights, licenses and restrictions 2123 contained in BCP 78, and except as set forth therein, the authors 2124 retain all their rights. 2126 This document and the information contained herein are provided on an 2127 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE 2128 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2129 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2130 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2131 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2132 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2134 15. Intellectual Property 2136 The IETF takes no position regarding the validity or scope of any 2137 Intellectual Property Rights or other rights that might be claimed to 2138 pertain to the implementation or use of the technology described in 2139 this document or the extent to which any license under such rights 2140 might or might not be available; nor does it represent that it has 2141 made any independent effort to identify any such rights. Information 2142 on the ISOC's procedures with respect to rights in ISOC Documents can 2143 be found in BCP 78 and BCP 79. 2145 Copies of IPR disclosures made to the IETF Secretariat and any 2146 assurances of licenses to be made available, or the result of an 2147 attempt made to obtain a general license or permission for the use of 2148 such proprietary rights by implementers or users of this 2149 specification can be obtained from the IETF on-line IPR repository at 2150 http://www.ietf.org/ipr. 2152 The IETF invites any interested party to bring to its attention any 2153 copyrights, patents or patent applications, or other proprietary 2154 rights that may cover technology that may be required to implement 2155 this standard. Please address the information to the IETF at ietf- 2156 ipr@ietf.org. 2158 Expires January 12, 2006