From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Sun Apr 3 17:44:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28747 for ; Sun, 3 Apr 2005 17:44:35 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DID1N-0001wC-HM for nntpext-archive@ietf.org; Sun, 03 Apr 2005 17:52:43 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j33LiMwC023278; Sun, 3 Apr 2005 14:44:22 -0700 Received: (qmail 20305 invoked by uid 64013); 3 Apr 2005 21:44:21 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 3 Apr 2005 21:44:21 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 20296 invoked by uid 64013); 3 Apr 2005 21:44:19 -0000 Received: from colo.khms.westfalen.de (213.239.196.208) by lothlorien.stanford.edu with SMTP; 3 Apr 2005 21:44:19 -0000 Received: from khms.vpn ([10.172.192.2]:51864 helo=khms.westfalen.de ident=Debian-exim) by colo.khms.westfalen.de with esmtpsa (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.44) id 1DICtB-0006x7-Cn for ietf-nntp@lists.eyrie.org; Sun, 03 Apr 2005 23:44:13 +0200 Received: from root (helo=khms.westfalen.de) by khms.westfalen.de with local-bsmtp (Exim 4.44) id 1DICV1-0007dZ-P8 for ietf-nntp@lists.eyrie.org; Sun, 03 Apr 2005 23:19:15 +0200 Received: by khms.westfalen.de (CrossPoint v3.12d.kh15 R/C435); 03 Apr 2005 23:05:52 +0200 Date: 03 Apr 2005 20:10:00 +0200 From: kaih@khms.westfalen.de (Kai Henningsen) To: ietf-nntp@lists.eyrie.org Message-ID: <9UBSU5dHw-B@khms.westfalen.de> In-Reply-To: <20050329080717.GA89808@finch-staff-1.thus.net> Subject: Re: [NNTP] Future-proofing for including capabilities in responses X-Mailer: CrossPoint v3.12d.kh15 R/C435 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <87oedbkzd7.fsf@windlord.stanford.edu> <20050325123539.GG47012@finch-staff-1.thus.net> <42481768.4040203@oceana.com> <42481768.4040203@oceana.com> <20050329080717.GA89808@finch-staff-1.thus.net> X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. X-Fix-Your-Modem: +++ATS2=255&WO1 X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 clive@demon.net (Clive D.W. Feather) wrote on 29.03.05 in <20050329080717.GA89808@finch-staff-1.thus.net>: > Ken Murchison said: > > Then pick something that isn't likely to appear in the wild, e.g.: > > > > [: :] or [! !] or > > > > Using non-ASCII seems overkill. > > Seeing as non-ASCII is very unlikely to appear in the wild, and > illegal-UTF-8 even less likely, why isn't that better? I consider specifying illegal UTF-8 a shooting offense. And I expect I'm not the only one. This is a MUST NOT, as far as I'm concerned - not negotiable. I'm frankly appalled the notion has survived this long. > We're talking about tokens that the client is going to examine; it's not > that important that they be readable. In any case, they shouldn't be invisible if all the rest of the protocol is plain visible text. That's just asking for trouble. MfG Kai From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 4 04:12:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04100 for ; Mon, 4 Apr 2005 04:12:25 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DIMp2-0008E8-F2 for nntpext-archive@ietf.org; Mon, 04 Apr 2005 04:20:36 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j348CDvh030897; Mon, 4 Apr 2005 01:12:14 -0700 Received: (qmail 28077 invoked by uid 64013); 4 Apr 2005 08:12:13 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 4 Apr 2005 08:12:13 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 28068 invoked by uid 64013); 4 Apr 2005 08:12:11 -0000 Received: from krusty.dt.e-technik.uni-dortmund.de (HELO mail.dt.e-technik.uni-dortmund.de) (129.217.163.1) by lothlorien.stanford.edu with SMTP; 4 Apr 2005 08:12:11 -0000 Received: from localhost (localhost [127.0.0.1]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 1B72744006; Mon, 4 Apr 2005 10:12:10 +0200 (CEST) Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1]) by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17882-08-5; Mon, 4 Apr 2005 10:12:07 +0200 (CEST) Received: from m2a2.dyndns.org (p50915E97.dip.t-dialin.net [80.145.94.151]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 7713644003; Mon, 4 Apr 2005 10:12:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 5463D77835; Mon, 4 Apr 2005 10:12:06 +0200 (CEST) Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 09986-12-3; Mon, 4 Apr 2005 10:12:05 +0200 (CEST) Received: by merlin.emma.line.org (Postfix, from userid 500) id 14F6577D30; Mon, 4 Apr 2005 10:12:05 +0200 (CEST) From: Matthias Andree To: "Clive D.W. Feather" Subject: Re: [NNTP] Future-proofing for including capabilities in responses In-Reply-To: <20050325123539.GG47012@finch-staff-1.thus.net> (Clive D. W. Feather's message of "Fri, 25 Mar 2005 12:35:39 +0000") References: <87oedbkzd7.fsf@windlord.stanford.edu> <20050324164731.GO32089@finch-staff-1.thus.net> <87wtrwx41q.fsf@windlord.stanford.edu> <20050325123539.GG47012@finch-staff-1.thus.net> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Mon, 04 Apr 2005 10:12:05 +0200 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at dt.e-technik.uni-dortmund.de Cc: Russ Allbery , ietf-nntp@lists.eyrie.org X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 "Clive D.W. Feather" writes: > Is there really a need for this? Is the initial CAPABILITIES command really > a problem? If you do it this way, you've still got the parsing problem, > in that the line has to be parsed in a totally different manner to the > normal CAPABILITIES response, and you've also got the question of what to > do if the capabilities list is too long to fit into the initial > greeting. Right. The fewer parsers required, the better to implement. > Oh, and we haven't reserved a character that can be used to replace the > CRLF between capabilities. Finally, you're dumping a significant amount of > extra data on the client when it hasn't even asked for it. This is moot - as long as the client wasn't previously allowed to make sense of what it is given, so that NNTP-1 clients can still cope with the data, fine. > I can see lots of mess building up and I just don't see the benefits. Good point. > That's not what I'm suggesting (I agree it's far too late). I'm suggesting > a "multi-line response" extension, or - if you prefer - a "response can > include capability information" extension. But it's an *extension* that > only gets invoked when the client asks for it (and so expects it). OK, this is an important point I'd support. > Having said all that (yet again), let me point out that if you really do > want to put data in the free text, then using a delimiter like [] is a bad > idea for at least two reasons: > - it's not unlikely that it's been used already (having semantics in > natural languages); > - it leads to more questions, such as whether you can have multiple [] > clauses and, if so, which ones have meaning. These same arguments can also be used against using ANY "very unlikely" statements. These don't hold in the real world, and whenever I hear someone who appears to have grown up with English as native language talk about character sets, I'm alarmed - nothing good comes of it, usually. > A better approach is to define a character sequence WHICH IS VERY UNLIKELY > TO OCCUR IN THE WILD as an "end of free text" delimiter. No. In the first place, the sequence must be readable without special equipment. Hence, only printable (non-blank) ASCII characters are eligible. > Alternatively, say that the sequence only has special meaning at the > *start* of the free text, and then indicates that the "free text" > isn't. Which overloads "free-text" fields and makes the responses likely to appear in places where the user looks. > I would suggest that suitable choices for the delimiter would be: > - %x1C (the "field separator" control character); not printable, unlike the rest of NNTP. > - %xC0.9C (which is the same thing encoded in an invalid UFT-8 way; this > technically violates the existing syntax rules, which may or may not be > a good idea); illegal and hence not an option. The client would have to have two UTF-8 decoders, one regular, and one - along with the whole set of library functions or string operations - that treat broken data. No-one will follow suit, IOW this is going to be a still birth. > - a rare control code, such as %xC2.95 (Unicode U+0095 "Message Waiting") > or %xE2.81.A3 (U+2063 "Invisible Separator"); not printable ASCII, hence not an option. > - %xCD.B3.CE.87 (U+0373 U+0387 "erotimatiko" followed by "ano teleia", > which I picked because these characters are unlikely to occur in that > order, are only two octets in UTF-8, *and* are not preserved by any of > the four Unicode normalisation forms); Looks ugly. Probably is. And it's not printable ASCII... > - if you really feel it has to be ASCII printable text, then something > like "~fReE!" or something equally unreadable. Urgh. :-) > But I repeat that I feel it's a bad idea, and you've not justified the > need. OK. -- Matthias Andree From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Fri Apr 8 12:30:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09738 for ; Fri, 8 Apr 2005 12:30:02 -0400 (EDT) Received: from smtp2.stanford.edu ([171.67.16.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DJwVh-00070t-GF for nntpext-archive@ietf.org; Fri, 08 Apr 2005 12:39:10 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id j38GTnR6026865; Fri, 8 Apr 2005 09:29:50 -0700 Received: (qmail 5828 invoked by uid 64013); 8 Apr 2005 16:29:49 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 8 Apr 2005 16:29:49 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 5819 invoked by uid 64013); 8 Apr 2005 16:29:48 -0000 Received: from anchor-internal-1.mail.demon.net (195.173.56.100) by lothlorien.stanford.edu with SMTP; 8 Apr 2005 16:29:48 -0000 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j38GTkhq027892; Fri, 8 Apr 2005 16:29:47 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1DJwMc-0008tJ-00 for ietf-nntp@lists.eyrie.org; Fri, 08 Apr 2005 17:29:46 +0100 Date: Fri, 8 Apr 2005 17:29:46 +0100 From: "Clive D.W. Feather" To: IETF NNTP mailing list Message-ID: <20050408162946.GW94541@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: [NNTP] Internationalisation X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc First draft. Comments welcome. 10. Internationalisation Considerations 10.1 Introduction and historical situation RFC 977 [RFC977] was written at a time when internationalisation was not seen as a significant issue. As such, it was written on the assumption that all communication would be in ASCII and use only a 7-bit transport layer. Since then, Usenet and NNTP have spread throughout the world. In the absence of standards for handling the issues of language and character sets, countries, newsgroup hierarchies, and individuals have all found different solutions which work for them but are not necessarily appropriate elsewhere. For example, some have adopted a default 8-bit character set appropriate to their needs (such as ISO8859-1 in Western Europe or KOI-8 in Russia), others have used ASCII (either US-ASCII or national variants) in headers but local 16- bit character sets in article bodies, and still others have gone for a combination of MIME and UTF-8. With the increased use of MIME in email, it is becoming more common to find MIME headers identifying the character set of the body, but this is far from universal. The resulting confusion does not help interoperability. One point that has been generally accepted is that articles can contain octets with the top bit set, and NNTP is only expected to operate on 8-bit clean transport paths. 10.2 This specification Part of the role of this present specification is to eliminate this confusion and promote interoperability as far as possible. At the same time, it is necessary to accept the existence of the present situation and not gratuitously break existing implementations and arrangements, even if they are less than optimal. Therefore current practice has been taken into consideration while in producing this specification. The NNTP itself is extended from US-ASCII [ANSI1986] to UTF-8 [RFC3629] in this specification. Except in the specific areas discussed below, UTF-8 (which is a superset of ASCII) is mandatory and implementations MUST NOT use any other encoding. The major deviation from this requirement lies in the topic of articles and data derived from them. As described in Section 3.6, articles consist of a set of headers and then a body. While the names of headers (e.g. "From" or "Subject") are limited to US-ASCII, some header values (and, of course, the article body) are generated by users using software which adopts local practices; for example, it may encode all text is in ISO 8859-1 without including a MIME header to that effect. OUTSTANDING ISSUE Include references to MIME? To 8859-1? To KOI-8? In an ideal world it would be possible to declare such usage non- conforming and ignore it, but in practice any specification that attempted to do so would be ignored. Therefore this version of NNTP allows this practice. More specifically, while implementations SHOULD only allow the creation of new articles where the headers conform to UTF-8, where an article is obtained from an external source an implementation MAY pass it on, and derive data from it (such as the response to the HDR command), even though the article or the data is not valid UTF-8. Implementations MUST transfer such articles and data correctly. (Nevertheless, a client or server MAY elect not to post or forward the article if, after further examination of the article, it deems it inappropriate to do so.) This requirement affects the ARTICLE (Section 6.2.1), BODY (Section 6.2.3), HDR (Section 8.5), HEAD (Section 6.2.2), IHAVE (Section 6.3.2), OVER (Section 8.3), and POST (Section 6.3.1) commands. The second area of deviation is the newsgroups list returned by the LIST NEWSGROUPS (Section 7.6.6) command. The actual newsgroup name is required to be in UTF-8 - in practice, Usenet newsgroup names are almost all US-ASCII - but the descriptive text is normally generated according to the standards of the local hierarchy and, once again, may not conform to UTF-8. The final deviation is the HELP (Section 7.2) command. The help text that this returns is typically created by server operators and is not presented to normal users. It does not appear profitable to put restrictions on this text. 10.3 Outstanding issues 10.3.1 Article format While the primary use of NNTP is for transmitting articles that conform to RFC 1036 [RFC1036] (Netnews articles), it is also used for other formats (see Appendix A). It is therefore most appropriate that internationalisation issues related to article formats be addressed in the relevant specifications. For Netnews articles, this is any successor to RFC 1036. For email messages, it is RFC 2822 [RFC2822]. Of course, any article transmitted via NNTP needs to conform to this specification as well. 10.3.2 Newsgroup names and descriptions Newsgroup names are required by this specification to be in UTF-8 and, in practice, are almost always US-ASCII. The spread of implementations that conform to this specification should suffice to encourage the phasing out of the few non-conforming names in use. Restricting newsgroup names to UTF-8 is not a complete solution to the issues, of course. In particular, when new newsgroup names are created or a user is asked to enter a newsgroup name, some form of canonicalisation will need to take place. Newsgroup descriptions are a more difficult problem. The pressures that have restricted newsgroup names to US-ASCII - essentially that it is more likely to remain unaltered during transmission - do not apply to descriptions. More variation has therefore sprung up and there will be difficult problems involved in any transition to UTF-8. Since the primary use of NNTP is with Netnews, and since this information is normally distributed through specially formatted articles, it is recommended that these issues be addressed in any successor to RFC 1036. In the meantime: o servers SHOULD by default report to their administrator any use of character sets other than UTF-8 in the newsgroups list data (see Section 7.6.6); o administrators of Netnews hierarchies SHOULD NOT permit the creation of newsgroups with names that are not US-ASCII, as any name that does not conform to the eventual specifications in this regard is likely to be a permanent source of interoperability issues. 10.3.3 Other While the text of the HELP response remains an open issue, it is unclear whether there is benefit in attempting to solve it. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 11:58:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24425 for ; Mon, 11 Apr 2005 11:58:27 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL1SP-0004Zg-8I for nntpext-archive@ietf.org; Mon, 11 Apr 2005 12:08:14 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BFwFnL032243; Mon, 11 Apr 2005 08:58:15 -0700 Received: (qmail 26007 invoked by uid 64013); 11 Apr 2005 15:58:15 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 15:58:15 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 25992 invoked by uid 64013); 11 Apr 2005 15:58:12 -0000 Received: from anchor-internal-1.mail.demon.net (195.173.56.100) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 15:58:12 -0000 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j3BFwAu8026487; Mon, 11 Apr 2005 15:58:11 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1DL1Ig-000LfI-00 for ietf-nntp@lists.eyrie.org; Mon, 11 Apr 2005 16:58:10 +0100 Date: Mon, 11 Apr 2005 16:58:10 +0100 From: "Clive D.W. Feather" To: IETF NNTP mailing list Message-ID: <20050411155810.GP46784@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: [NNTP] Multi-line blocks X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd I received a private email the other day pointing out some wording inconsistencies in draft 25. Having thought about it, I've decided to invent a new term "multi-line data block" and rephrase other places to use it. Here's the significant diffs - scream now or forever hold your peace. [Near the end of section 3.1:] ======== Each response MUST start with a three-digit response code that is sufficient to distinguish all responses. Certain valid responses are defined to be multi-line; for all others, the response is contained - in a single line. The first or only line of the response MUST NOT - exceed 512 octets, which includes the response code and the - terminating CRLF pair; an extension MAY specify a greater maximum for - commands that it defines, but not for any other command. + in a single line. The initial line of the response MUST NOT exceed + 512 octets, which includes the response code and the terminating CRLF + pair; an extension MAY specify a greater maximum for commands that it + defines, but not for any other command. Single-line responses + consist of an initial line only. Multi-line responses consist of an + initial line followed by a multi-line data block. + An NNTP server MAY have an inactivity autologout timer. Such a timer + SHOULD be of at least three minutes duration, with the exception that + there MAY be a shorter limit on how long the server is willing to + wait for the first command from the client. The receipt of any + command from the client during the timer interval SHOULD suffice to + reset the autologout timer. Similarly, the receipt of any + significant amount of data from a client that is sending a multi-line + data block (such as during a POST or IHAVE command) SHOULD suffice to + reset the autologout timer. When the timer expires, the server + SHOULD close the connection without sending any response to the + client. + +3.1.1 Multi-line data blocks - All multi-line responses MUST adhere to the following format: + A multi-line data block is used in certain commands and responses. + It MUST adhere to the following rules: + - 1. The response consists of a sequence of one or more "lines", each + 1. The block consists of a sequence of one or more "lines", each being a stream of octets ending with a CRLF pair. Apart from those line endings, the stream MUST NOT include the octets NUL, LF, or CR. - 2. The first such line contains the response code as with a single - line response. + 2. In a multi-line response, the block immediately follows the CRLF + at the end of the initial line of the response. When used in any + other context, the specific command will define when the block is + sent. - 3. If any subsequent line begins with the "termination octet" ("." - or %x2E), that line MUST be "byte-stuffed" by pre-pending an - additional termination octet to that line of the response. + 3. If any line of the data block begins with the "termination octet" + ("." or %x2E), that line MUST be "byte-stuffed" by pre-pending an + additional termination octet to that line of the block. - 4. The lines of the response MUST be followed by a terminating line + 4. The lines of the block MUST be followed by a terminating line consisting of a single termination octet followed by a CRLF pair - in the normal way. Thus a multi-line response is always - terminated with the five octets CRLF "." CRLF (%x0D.0A.2E.0D.0A). + in the normal way. Thus a multi-line block is always terminated + with the five octets CRLF "." CRLF (%x0D.0A.2E.0D.0A). - 5. When interpreting a multi-line response, the "byte-stuffing" MUST - be undone; i.e. the client MUST ensure that, in any line + 5. When interpreting a multi-line block, the "byte-stuffing" MUST be + undone; i.e. the recipient MUST ensure that, in any line beginning with the termination octet followed by octets other than a CRLF pair, that initial termination octet is disregarded. 6. Likewise, the terminating line ("." CRLF or %x2E.0D.0A) MUST NOT - be considered part of the multi-line response; i.e. the client + be considered part of the multi-line block; i.e. the recipient MUST ensure that any line beginning with the termination octet followed immediately by a CRLF pair is disregarded; (the first CRLF pair of the terminating CRLF "." CRLF is, of course, part of - the last line of the response). + the last line of the block). Note that texts using an encoding (such as UTF-16 or UTF-32) that may contain the octets NUL, LF, or CR other than a CRLF pair cannot be reliably conveyed in the above format (that is, they violate the MUST requirement above). However, except when stated otherwise, this specification does not require the content to be UTF-8 and therefore (subject to that same requirement) it MAY include octets above and below 128 mixed arbitrarily. - This document does not place any limit on the length of a subsequent - line in a multi-line response. However, the standards that define - the format of articles may do so. + This document does not place any limit on the length of a line in a + multi-line block. However, the standards that define the format of + articles may do so. - - An NNTP server MAY have an inactivity autologout timer. Such a timer - SHOULD be of at least three minutes duration, with the exception that - there MAY be a shorter limit on how long the server is willing to - wait for the first command from the client. The receipt of any - command from the client during the timer interval SHOULD suffice to - reset the autologout timer. Similarly, the receipt of any - significant amount of data from the client while in the midst of - sending a multi-line message to the server (such as during a POST or - IHAVE command) SHOULD suffice to reset the autologout timer. When - the timer expires, the server SHOULD close the connection without - sending any response to the client. 3.2 Response Codes [...] Certain responses contain arguments such as numbers and names in addition to the status indicator. In those cases, to simplify interpretation by the client the number and type of such arguments is - fixed for each response code, as is whether or not the code - introduces a multi-line response. Any extension MUST follow this - principle as well. Note that, for historical reasons, the 211 - response code is an exception to this in that the response may be - multi-line or not depending on the command (GROUP or LISTGROUP) that + fixed for each response code, as is whether or not the code is + single-line or multi-line. Any extension MUST follow this principle + as well. Note that, for historical reasons, the 211 response code is + an exception to this in that the response may be single-line or + multi-line depending on the command (GROUP or LISTGROUP) that generated it. In all other cases, the client MUST only use the status indicator itself to determine the nature of the response. The exact response codes that can be returned by any given command are ======== Many changes along the lines of: ======== - The capability list is returned as a multi-line response following + The capability list is returned as a multi-line data block following the 101 response code. Each capability is described by a separate capability line. ======== and ======== - If the information is available, it is returned as a multi-line - response following the 225 response code and contains one line for - each article in the range that exists (note that unless the argument - is a range including a dash, there will be at most one line but it - will still be in multi-line format). The line consists of [...] + If the information is available, it is returned as a multi-line data + block following the 225 response code and contains one line for each + article in the range that exists (note that unless the argument is a + range including a dash, there will be at most one line in the data + block). The line consists of [...] ======== I've consistently used "multi-line" and not "multiline"; this has involved scattered changes. In POST: ======== - If posting is permitted, the article MUST be in the format specified - in Section 3.6 and MUST be sent by the client to the server in the - manner specified (in Section 3.1) for multi-line responses (except - that there is no initial line containing a response code). Thus a - single dot (".") on a line indicates the end of the text, and lines - starting with a dot in the original text have that dot doubled during - transmission. + If posting is permitted, the article MUST be in the format specified + in Section 3.6 and MUST be sent by the client to the server as a + multi-line data block (see Section 3.1.1). Thus a single dot (".") + on a line indicates the end of the text, and lines starting with a + dot in the original text have that dot doubled during transmission. ======== In IHAVE: ======== - If transmission of the article is requested, the client MUST send the - entire article, including headers and body, in the format defined - above (Section 3.1) for multi-line responses (except that there is no - initial line containing a response code). Thus a single dot (".") on - a line indicates the end of the text, and lines starting with a dot - in the original text have that dot doubled during transmission. The + If transmission of the article is requested, the client MUST send the + entire article, including headers and body, to the server as a multi- + line data block (see Section 3.1.1). Thus a single dot (".") on a + line indicates the end of the text, and lines starting with a dot in + the original text have that dot doubled during transmission. The server MUST return either a 235 response, indicating that the article was successfully transferred, a 436 response, indicating that the transfer failed but should be tried again later, or a 437 response, indicating that the article was rejected. ======== Formal syntax changes: ======== - encoded-article = content-lines termination + encoded-article = multi-line-data-block ; after undoing the "byte-stuffing", this MUST match
[...] - response = simple-response / multiline-response + response = simple-response / multi-line-response - simple-response = - simple-response-content [SP trailing-comment] CRLF - multiline-response = simple-response content-lines termination + simple-response = initial-response-line + multi-line-response = initial-response-line multi-line-data-block + initial-response-line = + simple-response-content [SP trailing-comment] CRLF [...] 9.3.3 Multi-line response contents - This syntax defines the content of the various multi-line responses - (more precisely, the part of the response in ), in - each case after any "byte-stuffing" has been undone. + This syntax defines the content of the various multi-line responses; + more precisely, it defines the part of the response in the multi-line + data block after any "byte-stuffing" has been undone. - multiline-response-content = article-response / + multi-line-response-content = article-response / body-response / [...] + multi-line-data-block = content-lines termination + content-lines = *([content-text] CRLF) + content-text = (".." / B-NONDOT) *B-CHAR + termination = "." CRLF + article-number = 1*16DIGIT - content-lines = *([content-text] CRLF) - content-text = (".." / B-NONDOT) *B-CHAR header-name = 1*A-NOTCOLON keyword = ALPHA 2*11(ALPHA / DIGIT / "." / "-") message-id = "<" 1*248A-NOTGT ">" newsgroup-name = 1*wildmat-exact - termination = "." CRLF token = 1*P-CHAR ======== -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 12:12:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25510 for ; Mon, 11 Apr 2005 12:12:55 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL1gH-0004yy-OS for nntpext-archive@ietf.org; Mon, 11 Apr 2005 12:22:41 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BGCcBQ005058; Mon, 11 Apr 2005 09:12:38 -0700 Received: (qmail 26949 invoked by uid 64013); 11 Apr 2005 16:12:38 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 16:12:38 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 26940 invoked by uid 64013); 11 Apr 2005 16:12:36 -0000 Received: from smtp802.mail.ukl.yahoo.com (217.12.12.139) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 16:12:36 -0000 Received: from unknown (HELO host81-144-77-126.midband.mdip.bt.net) (ietf-nntp@lists.eyrie.org@81.144.77.126 with poptime) by smtp802.mail.ukl.yahoo.com with SMTP; 11 Apr 2005 16:12:33 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j3BGCDr15269 for ietf-nntp@lists.eyrie.org; Mon, 11 Apr 2005 17:12:13 +0100 (BST) To: ietf-nntp@lists.eyrie.org Xref: clerew local.nntp:4318 Newsgroups: local.nntp Path: clerew!chl From: "Charles Lindsey" Subject: Re: [NNTP] Internationalisation Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <20050408162946.GW94541@finch-staff-1.thus.net> Date: Mon, 11 Apr 2005 11:20:55 GMT Lines: 224 X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.7 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b In <20050408162946.GW94541@finch-staff-1.thus.net> "Clive D.W. Feather" writes: >First draft. Comments welcome. I think this pudding has been somewhat over-egged :-) . Generally, the less we say on this issue, the less likely it is to come back to haunt us later. > 10. Internationalisation Considerations > 10.1 Introduction and historical situation > RFC 977 [RFC977] was written at a time when internationalisation was > not seen as a significant issue. As such, it was written on the > assumption that all communication would be in ASCII and use only a > 7-bit transport layer. Just to forestall the Bruce Lillys of this world, a parenthetical remark to the effect that all known current implementations are nevertheless 8bit clean would help. > Since then, Usenet and NNTP have spread throughout the world. In the > absence of standards for handling the issues of language and > character sets, countries, newsgroup hierarchies, and individuals > have all found different solutions which work for them but are not > necessarily appropriate elsewhere. For example, some have adopted a > default 8-bit character set appropriate to their needs (such as > ISO8859-1 in Western Europe or KOI-8 in Russia), others have used > ASCII (either US-ASCII or national variants) in headers but local 16- > bit character sets in article bodies, and still others have gone for > a combination of MIME and UTF-8. With the increased use of MIME in > email, it is becoming more common to find MIME headers identifying > the character set of the body, but this is far from universal. Again, whilst all of these deviations have been seen somewhere, they are not as common as this text would suggest. Successors to RFC 1036, such as Usefor or its proposed I18N extension, may yet decide to try and put the genii back in the bottle (or they may not, or they may weasel their way around the problem). So you need to be completely neutral regarding such possibilities, and not say anything which could be taken as encouraging (or discouraging for that matter) such deviations. In particular, I doubt any such I18N extension is going to give any comfort at all to those who would use strange charsets in bodies without proper MIME headers. > The resulting confusion does not help interoperability. > One point that has been generally accepted is that articles can > contain octets with the top bit set, and NNTP is only expected to > operate on 8-bit clean transport paths. Agreed. > 10.2 This specification > Part of the role of this present specification is to eliminate this > confusion and promote interoperability as far as possible. At the > same time, it is necessary to accept the existence of the present > situation and not gratuitously break existing implementations and > arrangements, even if they are less than optimal. Therefore current > practice has been taken into consideration while in producing this > specification. I think I would rather say: Whilst this specification has been designed to place no gratuitous obstacles to the continued transport of articles which exceed the spcifications in RFC 1036 in such ways, it should not be read as condoning such practices (which is a matter properly left to future extensions of RFC 1036). > The NNTP itself is extended from US-ASCII [ANSI1986] to UTF-8 > [RFC3629] in this specification. Except in the specific areas > discussed below, UTF-8 (which is a superset of ASCII) is mandatory > and implementations MUST NOT use any other encoding. > The major deviation from this requirement lies in the topic of > articles and data derived from them. As described in Section 3.6, > articles consist of a set of headers and then a body. While the > names of headers (e.g. "From" or "Subject") are limited to US-ASCII, > some header values (and, of course, the article body) are generated > by users using software which adopts local practices; for example, it > may encode all text is in ISO 8859-1 without including a MIME header > to that effect. ... software which may have adopted other charsets and/or practices ... > OUTSTANDING ISSUE > Include references to MIME? To 8859-1? To KOI-8? > In an ideal world it would be possible to declare such usage non- > conforming and ignore it, but in practice any specification that > attempted to do so would be ignored. Therefore this version of NNTP > allows this practice. More specifically, while implementations > SHOULD only allow the creation of new articles where the headers > conform to UTF-8, where an article is obtained from an external > source an implementation MAY pass it on, and derive data from it > (such as the response to the HDR command), even though the article or > the data is not valid UTF-8. Implementations MUST transfer such > articles and data correctly. (Nevertheless, a client or server MAY > elect not to post or forward the article if, after further > examination of the article, it deems it inappropriate to do so.) I think I would omit the first two sentences. > This requirement affects the ARTICLE (Section 6.2.1), BODY > (Section 6.2.3), HDR (Section 8.5), HEAD (Section 6.2.2), IHAVE > (Section 6.3.2), OVER (Section 8.3), and POST (Section 6.3.1) > commands. > The second area of deviation is the newsgroups list returned by the > LIST NEWSGROUPS (Section 7.6.6) command. The actual newsgroup name > is required to be in UTF-8 - in practice, Usenet newsgroup names are > almost all US-ASCII - but the descriptive text is normally generated > according to the standards of the local hierarchy and, once again, > may not conform to UTF-8. Again, you need to allow for the possibility that the I18N extension to Usefor may go in for some encoding of newsgroup-names into ASCII, rather than expressing them directly in UTF-8 (though I think you have pretty well precluded any other ways of handling them, which will not please the Chinese :-( ). At the time that Usefor decided to postpone the I18N of newsgroup-names to a future document, there were mutterings about such encodings, even involving the ghastly punycode. I am sure that you and I agree that would be a terrible approach to take, but we still need to take a neutral stance on it in this NNTP standard. > The final deviation is the HELP (Section 7.2) command. The help text > that this returns is typically created by server operators and is not > presented to normal users. It does not appear profitable to put > restrictions on this text. By which you mean that you do not care if it is in KOI-8? > 10.3 Outstanding issues > 10.3.1 Article format > While the primary use of NNTP is for transmitting articles that > conform to RFC 1036 [RFC1036] (Netnews articles), it is also used for > other formats (see Appendix A). It is therefore most appropriate > that internationalisation issues related to article formats be > addressed in the relevant specifications. For Netnews articles, this > is any successor to RFC 1036. For email messages, it is RFC 2822 > [RFC2822]. Agreed, except that there could also be extensions/successors to RFC 2822. > Of course, any article transmitted via NNTP needs to conform to this > specification as well. > 10.3.2 Newsgroup names and descriptions > Newsgroup names are required by this specification to be in UTF-8 > and, in practice, are almost always US-ASCII. The spread of > implementations that conform to this specification should suffice to > encourage the phasing out of the few non-conforming names in use. ITYM those that conform to the successors and extensions mentioned above. > Restricting newsgroup names to UTF-8 is not a complete solution to > the issues, of course. In particular, when new newsgroup names are > created or a user is asked to enter a newsgroup name, some form of > canonicalisation will need to take place. I think you need to make it clear here that implementations of this new NNTP standard MUST consider two newsgroup-names to refer to the same group IFF they are represented by the same sequence of octets. Thus such canonicalization as may be needed is the responsibility of the clients, or of the the machinery (undefined by this standard) that admits new newsgroups to the active file of the server. > Newsgroup descriptions are a more difficult problem. The pressures > that have restricted newsgroup names to US-ASCII - essentially that > it is more likely to remain unaltered during transmission - do not > apply to descriptions. More variation has therefore sprung up and > there will be difficult problems involved in any transition to UTF-8. Hmmmm! Might it not be possible to allow the lattitude you have permitted for the texts or articles to apply here also? I am not sure. You certainly need to be able to extract a valid list of newsgroup-names from a LIST NEWSGROUPS response, even if the remainder of the descriptions looks like gibberish, which pretty well limits you to UTF-8 (unless the newsgroup-names are encoded in ASCII - yech!). > Since the primary use of NNTP is with Netnews, and since this > information is normally distributed through specially formatted > articles, it is recommended that these issues be addressed in any > successor to RFC 1036. In the meantime: > o servers SHOULD by default report to their administrator any use of > character sets other than UTF-8 in the newsgroups list data (see > Section 7.6.6); > o administrators of Netnews hierarchies SHOULD NOT permit the > creation of newsgroups with names that are not US-ASCII, as any > name that does not conform to the eventual specifications in this > regard is likely to be a permanent source of interoperability > issues. Do those actually add anything to what has already been said earlier? > 10.3.3 Other > While the text of the HELP response remains an open issue, it is > unclear whether there is benefit in attempting to solve it. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 12:19:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26140 for ; Mon, 11 Apr 2005 12:19:08 -0400 (EDT) Received: from smtp2.stanford.edu ([171.67.16.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL1mP-0005BA-Al for nntpext-archive@ietf.org; Mon, 11 Apr 2005 12:28:54 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BGIwCZ008476; Mon, 11 Apr 2005 09:18:58 -0700 Received: (qmail 27162 invoked by uid 64013); 11 Apr 2005 16:18:58 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 16:18:58 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 27153 invoked by uid 64013); 11 Apr 2005 16:18:56 -0000 Received: from anchor-internal-1.mail.demon.net (195.173.56.100) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 16:18:56 -0000 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j3BGIs8C003939; Mon, 11 Apr 2005 16:18:54 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1DL1ck-000Lyj-00 for ietf-nntp@lists.eyrie.org; Mon, 11 Apr 2005 17:18:54 +0100 Date: Mon, 11 Apr 2005 17:18:54 +0100 From: "Clive D.W. Feather" To: IETF NNTP mailing list Message-ID: <20050411161854.GQ46784@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: [NNTP] Article references X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 A recent thread in news.software.nntp asks whether the same article can have two different article numbers in the same newsgroup. The requirements on arrival times means there can't be any other valid number between them, but I don't see it actually outlawed by our text. I propose modifying section 6 as follows: News reading clients have available a variety of mechanisms to retrieve articles via NNTP. The news articles are stored and indexed using three types of keys. One key is the message-id of an article. Another key is composed of the newsgroup name and the article number within that newsgroup. That key MUST be unique to a particular server (there will be only one article with that number within a particular newsgroup), but is not required to be globally unique. Additionally, because the same article can be cross-posted to multiple newsgroups, there may be multiple keys that point to the - same article on the same server. The final key is the arrival + same article on the same server; however, these keys MUST each refer + to a different newsgroup. The final key is the arrival timestamp, giving the time that the article arrived at the server. Any objections? -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 12:29:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26899 for ; Mon, 11 Apr 2005 12:29:37 -0400 (EDT) Received: from smtp2.stanford.edu ([171.67.16.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL1wV-0005T9-S4 for nntpext-archive@ietf.org; Mon, 11 Apr 2005 12:39:24 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BGTPij012379; Mon, 11 Apr 2005 09:29:25 -0700 Received: (qmail 27380 invoked by uid 64013); 11 Apr 2005 16:29:25 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 16:29:25 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 27371 invoked by uid 64013); 11 Apr 2005 16:29:23 -0000 Received: from eagle.oceana.com (208.17.123.12) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 16:29:23 -0000 Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.2/8.13.2) with ESMTP id j3BGTBYl002419 for ; Mon, 11 Apr 2005 12:29:11 -0400 (EDT) Message-ID: <425AA5B2.90202@oceana.com> Date: Mon, 11 Apr 2005 12:28:34 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: IETF NNTP mailing list Subject: Re: [NNTP] Article references References: <20050411161854.GQ46784@finch-staff-1.thus.net> In-Reply-To: <20050411161854.GQ46784@finch-staff-1.thus.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Clive D.W. Feather wrote: > A recent thread in news.software.nntp asks whether the same article can > have two different article numbers in the same newsgroup. The requirements > on arrival times means there can't be any other valid number between them, > but I don't see it actually outlawed by our text. > > I propose modifying section 6 as follows: > > News reading clients have available a variety of mechanisms to > retrieve articles via NNTP. The news articles are stored and indexed > using three types of keys. One key is the message-id of an article. > Another key is composed of the newsgroup name and the article number > within that newsgroup. That key MUST be unique to a particular > server (there will be only one article with that number within a > particular newsgroup), but is not required to be globally unique. > Additionally, because the same article can be cross-posted to > multiple newsgroups, there may be multiple keys that point to the > - same article on the same server. The final key is the arrival > + same article on the same server; however, these keys MUST each refer > + to a different newsgroup. The final key is the arrival > timestamp, giving the time that the article arrived at the server. > > Any objections? I'm fine with this. Or should we say that only one article with a given message-id can appear in any newsgroup? -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 12:34:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27231 for ; Mon, 11 Apr 2005 12:34:28 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL21G-0005cP-EB for nntpext-archive@ietf.org; Mon, 11 Apr 2005 12:44:15 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BGYK3H013630; Mon, 11 Apr 2005 09:34:20 -0700 Received: (qmail 27601 invoked by uid 64013); 11 Apr 2005 16:34:19 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 16:34:19 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 27592 invoked by uid 64013); 11 Apr 2005 16:34:17 -0000 Received: from eagle.oceana.com (208.17.123.12) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 16:34:17 -0000 Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.2/8.13.2) with ESMTP id j3BGYGrb002504 for ; Mon, 11 Apr 2005 12:34:16 -0400 (EDT) Message-ID: <425AA6E2.2000302@oceana.com> Date: Mon, 11 Apr 2005 12:33:38 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: IETF NNTP mailing list Subject: Re: [NNTP] Multi-line blocks References: <20050411155810.GP46784@finch-staff-1.thus.net> In-Reply-To: <20050411155810.GP46784@finch-staff-1.thus.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Clive D.W. Feather wrote: > I received a private email the other day pointing out some wording > inconsistencies in draft 25. Having thought about it, I've decided to > invent a new term "multi-line data block" and rephrase other places to use > it. Here's the significant diffs - scream now or forever hold your peace. I can live with these changes. If I don't see any objections over the next few days, I'll make any necessary wording changes to the extension drafts. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 14:34:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07264 for ; Mon, 11 Apr 2005 14:34:57 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3tr-0000lY-C6 for nntpext-archive@ietf.org; Mon, 11 Apr 2005 14:44:44 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BIYkpm001837; Mon, 11 Apr 2005 11:34:46 -0700 Received: (qmail 29374 invoked by uid 64013); 11 Apr 2005 18:34:46 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 18:34:46 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 29365 invoked by uid 64013); 11 Apr 2005 18:34:45 -0000 Received: from windlord.stanford.edu (171.64.19.147) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 18:34:45 -0000 Received: (qmail 32449 invoked by uid 1000); 11 Apr 2005 18:34:45 -0000 To: ietf-nntp@lists.eyrie.org Subject: [NNTP] Fwd: Internationalisation From: Russ Allbery Organization: The Eyrie Date: Mon, 11 Apr 2005 11:34:45 -0700 Message-ID: <87br8li2m2.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 I think Jeff meant to send this here. From: "Jeffrey M.Vinocur" Subject: Re: [NNTP] Internationalisation Date: Sun, 10 Apr 2005 13:19:05 -0400 To: "'inn-workers@isc.org' (E-mail)" On Apr 8, 2005, at 12:29 PM, Clive D.W. Feather wrote: > First draft. Comments welcome. I like it. > countries, newsgroup hierarchies, and individuals > have all found different solutions which ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ have found a variety of solutions that > work for them but are not ^^^^ are satisfactory (?) are adequate (?) > With the increased use of MIME in > email, it is becoming more common to find MIME headers identifying > the character set of the body, but this is far from universal. I think the mention of email makes it unclear that "body" indicates an NNTP article. Perhaps "...it is becoming more common for NNTP articles to include MIME headers..."? > One point that has been generally accepted is that articles can > contain octets with the top bit set, and NNTP is only expected to > operate on 8-bit clean transport paths. Potentially you need to mention NUL and bare CR/LF here? > and not gratuitously break existing implementations and > arrangements, even if they are less than optimal. This feels a little wordy. Something like "and not needlessly break existing functional but suboptimal implementations and arrangements?" > The NNTP itself is extended from US-ASCII [ANSI1986] to UTF-8 > [RFC3629] in this specification. Except in the specific areas > discussed below, UTF-8 (which is a superset of ASCII) is mandatory > and implementations MUST NOT use any other encoding. > > The major deviation from this requirement ^^^^^^^^^ exception? > some header values (and, of course, the article body) are generated > by users using software which adopts local practices; for example, > it > may encode all text is in ISO 8859-1 without including a MIME header > to that effect. I had trouble determining the referent of "it" in this sentence, perhaps substituting "a client" would clear it up? (Incidentally, here I see another "which" in a non-restrictive clause. Perhaps you don't believe in that grammar rule and I should stop pointing it out?) > More specifically, while implementations > SHOULD only allow the creation of new articles where the headers > conform to UTF-8, where an article is obtained from an external > source an implementation MAY pass it on, and derive data from it > (such as the response to the HDR command), even though the article > or > the data is not valid UTF-8. This should be broken into two sentences for clarity. Suggest: More specifically, implementations SHOULD only allow the creation of new articles where the headers conform to UTF-8. However, when an article is obtained from an external source, an implementation MAY pass it on, and derive data from it (such as the response to the HDR command), even though the article or the derived data may not be valid UTF-8. > Implementations MUST transfer such articles and data correctly. What does "correctly" mean here? > The second area of deviation is I guess if you like "exception" for "deviation" above, it should be changed here too. > Restricting newsgroup names to UTF-8 is not a complete solution to > the issues, of course. In particular, when new newsgroup names are > created or a user is asked to enter a newsgroup name, some form of > canonicalisation will need to take place. Probably a little more text about canonicalization would be useful here. -- Jeffrey M. Vinocur jeff@litech.org From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 14:35:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07363 for ; Mon, 11 Apr 2005 14:35:52 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3uj-0000nx-R7 for nntpext-archive@ietf.org; Mon, 11 Apr 2005 14:45:39 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BIZggX002506; Mon, 11 Apr 2005 11:35:42 -0700 Received: (qmail 29585 invoked by uid 64013); 11 Apr 2005 18:35:42 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 18:35:42 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 29576 invoked by uid 64013); 11 Apr 2005 18:35:41 -0000 Received: from windlord.stanford.edu (171.64.19.147) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 18:35:41 -0000 Received: (qmail 32477 invoked by uid 1000); 11 Apr 2005 18:35:41 -0000 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Multi-line blocks In-Reply-To: <20050411155810.GP46784@finch-staff-1.thus.net> (Clive D. W. Feather's message of "Mon, 11 Apr 2005 16:58:10 +0100") References: <20050411155810.GP46784@finch-staff-1.thus.net> From: Russ Allbery Organization: The Eyrie Date: Mon, 11 Apr 2005 11:35:41 -0700 Message-ID: <877jj9i2ki.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Clive D W Feather writes: > I received a private email the other day pointing out some wording > inconsistencies in draft 25. Having thought about it, I've decided to > invent a new term "multi-line data block" and rephrase other places to > use it. Here's the significant diffs - scream now or forever hold your > peace. I'm fine with that. -- Russ Allbery (rra@stanford.edu) From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 14:37:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07482 for ; Mon, 11 Apr 2005 14:37:03 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3vu-0000qG-19 for nntpext-archive@ietf.org; Mon, 11 Apr 2005 14:46:50 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BIatq2003178; Mon, 11 Apr 2005 11:36:55 -0700 Received: (qmail 29798 invoked by uid 64013); 11 Apr 2005 18:36:54 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 18:36:54 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 29789 invoked by uid 64013); 11 Apr 2005 18:36:53 -0000 Received: from windlord.stanford.edu (171.64.19.147) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 18:36:53 -0000 Received: (qmail 32492 invoked by uid 1000); 11 Apr 2005 18:36:53 -0000 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Article references In-Reply-To: <20050411161854.GQ46784@finch-staff-1.thus.net> (Clive D. W. Feather's message of "Mon, 11 Apr 2005 17:18:54 +0100") References: <20050411161854.GQ46784@finch-staff-1.thus.net> From: Russ Allbery Organization: The Eyrie Date: Mon, 11 Apr 2005 11:36:53 -0700 Message-ID: <873btxi2ii.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Clive D W Feather writes: > A recent thread in news.software.nntp asks whether the same article can > have two different article numbers in the same newsgroup. The > requirements on arrival times means there can't be any other valid > number between them, but I don't see it actually outlawed by our text. This looks good to me. -- Russ Allbery (rra@stanford.edu) From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 14:37:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07505 for ; Mon, 11 Apr 2005 14:37:27 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL3wH-0000qP-CH for nntpext-archive@ietf.org; Mon, 11 Apr 2005 14:47:13 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BIbHgq003501; Mon, 11 Apr 2005 11:37:17 -0700 Received: (qmail 30012 invoked by uid 64013); 11 Apr 2005 18:37:17 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 18:37:17 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 29997 invoked by uid 64013); 11 Apr 2005 18:37:15 -0000 Received: from windlord.stanford.edu (171.64.19.147) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 18:37:15 -0000 Received: (qmail 32499 invoked by uid 1000); 11 Apr 2005 18:37:15 -0000 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Article references In-Reply-To: <425AA5B2.90202@oceana.com> (Ken Murchison's message of "Mon, 11 Apr 2005 12:28:34 -0400") References: <20050411161854.GQ46784@finch-staff-1.thus.net> <425AA5B2.90202@oceana.com> From: Russ Allbery Organization: The Eyrie Date: Mon, 11 Apr 2005 11:37:15 -0700 Message-ID: <87y8bpgnxg.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Ken Murchison writes: > Clive D.W. Feather wrote: >> I propose modifying section 6 as follows: >> News reading clients have available a variety of mechanisms to >> retrieve articles via NNTP. The news articles are stored and indexed >> using three types of keys. One key is the message-id of an article. >> Another key is composed of the newsgroup name and the article number >> within that newsgroup. That key MUST be unique to a particular >> server (there will be only one article with that number within a >> particular newsgroup), but is not required to be globally unique. >> Additionally, because the same article can be cross-posted to >> multiple newsgroups, there may be multiple keys that point to the >> - same article on the same server. The final key is the arrival >> + same article on the same server; however, these keys MUST each refer >> + to a different newsgroup. The final key is the arrival >> timestamp, giving the time that the article arrived at the server. >> Any objections? > I'm fine with this. Or should we say that only one article with a given > message-id can appear in any newsgroup? I assume you mean article number? I think that's what this says, although somewhat by implication. -- Russ Allbery (rra@stanford.edu) From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 16:10:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17172 for ; Mon, 11 Apr 2005 16:10:14 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5O4-0003vU-RC for nntpext-archive@ietf.org; Mon, 11 Apr 2005 16:20:02 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BKA3kI006729; Mon, 11 Apr 2005 13:10:03 -0700 Received: (qmail 644 invoked by uid 64013); 11 Apr 2005 20:10:02 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 20:10:02 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 633 invoked by uid 64013); 11 Apr 2005 20:09:59 -0000 Received: from eagle.oceana.com (208.17.123.12) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 20:09:59 -0000 Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.2/8.13.2) with ESMTP id j3BK9vES012182 for ; Mon, 11 Apr 2005 16:09:57 -0400 (EDT) Message-ID: <425AD96F.7010305@oceana.com> Date: Mon, 11 Apr 2005 16:09:19 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Article references References: <20050411161854.GQ46784@finch-staff-1.thus.net> <425AA5B2.90202@oceana.com> <87y8bpgnxg.fsf@windlord.stanford.edu> In-Reply-To: <87y8bpgnxg.fsf@windlord.stanford.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Russ Allbery wrote: > Ken Murchison writes: > >>Clive D.W. Feather wrote: > > >>>I propose modifying section 6 as follows: > > >>> News reading clients have available a variety of mechanisms to >>> retrieve articles via NNTP. The news articles are stored and indexed >>> using three types of keys. One key is the message-id of an article. >>> Another key is composed of the newsgroup name and the article number >>> within that newsgroup. That key MUST be unique to a particular >>> server (there will be only one article with that number within a >>> particular newsgroup), but is not required to be globally unique. >>> Additionally, because the same article can be cross-posted to >>> multiple newsgroups, there may be multiple keys that point to the >>>- same article on the same server. The final key is the arrival >>>+ same article on the same server; however, these keys MUST each refer >>>+ to a different newsgroup. The final key is the arrival >>> timestamp, giving the time that the article arrived at the server. > > >>>Any objections? > > >>I'm fine with this. Or should we say that only one article with a given >>message-id can appear in any newsgroup? > > > I assume you mean article number? I think that's what this says, although > somewhat by implication. No, I don't think I was clear. My assumption is that we should never have a duplicate message-id in a single newsgroup. The text says that message-id is one key and article_number+timestamp is another key, but it seems to me that the only real key is message-id. Article number is really just a mapping IMO, but this is a different can of worms. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 16:22:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19857 for ; Mon, 11 Apr 2005 16:22:59 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL5aO-0004qp-WE for nntpext-archive@ietf.org; Mon, 11 Apr 2005 16:32:47 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BKMlrk014556; Mon, 11 Apr 2005 13:22:48 -0700 Received: (qmail 871 invoked by uid 64013); 11 Apr 2005 20:22:47 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 20:22:47 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 862 invoked by uid 64013); 11 Apr 2005 20:22:46 -0000 Received: from windlord.stanford.edu (171.64.19.147) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 20:22:46 -0000 Received: (qmail 5819 invoked by uid 1000); 11 Apr 2005 20:22:45 -0000 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Article references In-Reply-To: <425AD96F.7010305@oceana.com> (Ken Murchison's message of "Mon, 11 Apr 2005 16:09:19 -0400") References: <20050411161854.GQ46784@finch-staff-1.thus.net> <425AA5B2.90202@oceana.com> <87y8bpgnxg.fsf@windlord.stanford.edu> <425AD96F.7010305@oceana.com> From: Russ Allbery Organization: The Eyrie Date: Mon, 11 Apr 2005 13:22:45 -0700 Message-ID: <87k6n9f4h6.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Ken Murchison writes: > No, I don't think I was clear. My assumption is that we should never > have a duplicate message-id in a single newsgroup. I thought we were never allowed to have duplicate message-ids *period*. > The text says that message-id is one key and article_number+timestamp is > another key, but it seems to me that the only real key is message-id. > Article number is really just a mapping IMO, but this is a different can > of worms. Well, it depends on how one wants to define keys. Message ID, group/article number, and timestamp are all keys in the sense that clients can use them to retrieve articles (well, timestamp isn't handled in quite the same fashion). -- Russ Allbery (rra@stanford.edu) From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 16:59:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27183 for ; Mon, 11 Apr 2005 16:59:35 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL69s-0007Ff-Cb for nntpext-archive@ietf.org; Mon, 11 Apr 2005 17:09:24 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BKxPIg029560; Mon, 11 Apr 2005 13:59:26 -0700 Received: (qmail 1507 invoked by uid 64013); 11 Apr 2005 20:59:25 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 20:59:25 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 1498 invoked by uid 64013); 11 Apr 2005 20:59:23 -0000 Received: from anchor-internal-1.mail.demon.net (195.173.56.100) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 20:59:23 -0000 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j3BKxLWe003536Mon, 11 Apr 2005 20:59:21 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1DL609-0000M6-00; Mon, 11 Apr 2005 21:59:21 +0100 Date: Mon, 11 Apr 2005 21:59:21 +0100 From: "Clive D.W. Feather" To: Russ Allbery Subject: Re: [NNTP] Article references Message-ID: <20050411205921.GA1299@finch-staff-1.thus.net> References: <20050411161854.GQ46784@finch-staff-1.thus.net> <425AA5B2.90202@oceana.com> <87y8bpgnxg.fsf@windlord.stanford.edu> <425AD96F.7010305@oceana.com> <87k6n9f4h6.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k6n9f4h6.fsf@windlord.stanford.edu> User-Agent: Mutt/1.5.3i Cc: ietf-nntp@lists.eyrie.org X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Russ Allbery said: >> No, I don't think I was clear. My assumption is that we should never >> have a duplicate message-id in a single newsgroup. > I thought we were never allowed to have duplicate message-ids *period*. We're not, but ... Article arrives. The server makes it article 123 in alt.test. What stops the server *also* making it 124 in alt.test? It's not legal for the same article to be 123 and 125 in the same newsgroup if there's also an article 124, because that violates the wording about numbering articles in the order of arrival. But, as far as I can see, nothing forbids giving the same article more than one number in the same newsgroup. The purpose of the proposed wording change is to fix this. Clearly it isn't clear. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 17:03:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28096 for ; Mon, 11 Apr 2005 17:03:18 -0400 (EDT) Received: from smtp2.stanford.edu ([171.67.16.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6DQ-0007bA-FK for nntpext-archive@ietf.org; Mon, 11 Apr 2005 17:13:05 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BL37eL002934; Mon, 11 Apr 2005 14:03:07 -0700 Received: (qmail 2310 invoked by uid 64013); 11 Apr 2005 21:03:06 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 21:03:06 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 2301 invoked by uid 64013); 11 Apr 2005 21:03:04 -0000 Received: from anchor-internal-1.mail.demon.net (195.173.56.100) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 21:03:04 -0000 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j3BL33C5004427Mon, 11 Apr 2005 21:03:03 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1DL63j-0000Yf-00; Mon, 11 Apr 2005 22:03:03 +0100 Date: Mon, 11 Apr 2005 22:03:03 +0100 From: "Clive D.W. Feather" To: Ken Murchison Subject: Re: [NNTP] Article references Message-ID: <20050411210303.GB1299@finch-staff-1.thus.net> References: <20050411161854.GQ46784@finch-staff-1.thus.net> <425AA5B2.90202@oceana.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <425AA5B2.90202@oceana.com> User-Agent: Mutt/1.5.3i Cc: IETF NNTP mailing list X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Wording attempt two: I propose modifying section 6 as follows: News reading clients have available a variety of mechanisms to retrieve articles via NNTP. The news articles are stored and indexed using three types of keys. One key is the message-id of an article. Another key is composed of the newsgroup name and the article number within that newsgroup. That key MUST be unique to a particular server (there will be only one article with that number within a particular newsgroup), but is not required to be globally unique. Additionally, because the same article can be cross-posted to multiple newsgroups, there may be multiple keys that point to the - same article on the same server. The final key is the arrival + same article on the same server; nevertheless, a given article + MUST NOT have two different article numbers in any particular + newsgroup on a particular server. The final key is the arrival timestamp, giving the time that the article arrived at the server. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 17:09:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00156 for ; Mon, 11 Apr 2005 17:09:13 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6JA-0008MP-St for nntpext-archive@ietf.org; Mon, 11 Apr 2005 17:19:02 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BL94GO001482; Mon, 11 Apr 2005 14:09:04 -0700 Received: (qmail 2528 invoked by uid 64013); 11 Apr 2005 21:09:04 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 21:09:04 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 2519 invoked by uid 64013); 11 Apr 2005 21:09:01 -0000 Received: from windlord.stanford.edu (171.64.19.147) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 21:09:01 -0000 Received: (qmail 7515 invoked by uid 1000); 11 Apr 2005 21:08:50 -0000 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Article references In-Reply-To: <20050411205921.GA1299@finch-staff-1.thus.net> (Clive D. W. Feather's message of "Mon, 11 Apr 2005 21:59:21 +0100") References: <20050411161854.GQ46784@finch-staff-1.thus.net> <425AA5B2.90202@oceana.com> <87y8bpgnxg.fsf@windlord.stanford.edu> <425AD96F.7010305@oceana.com> <87k6n9f4h6.fsf@windlord.stanford.edu> <20050411205921.GA1299@finch-staff-1.thus.net> From: Russ Allbery Organization: The Eyrie Date: Mon, 11 Apr 2005 14:08:50 -0700 Message-ID: <87d5t1f2cd.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Clive D W Feather writes: > Article arrives. The server makes it article 123 in alt.test. > What stops the server *also* making it 124 in alt.test? I hadn't thought about that angle. (Although we're getting into outlawing insane behavior that no one is likely to do in practice, which can be a bit of a waste of time.) > The purpose of the proposed wording change is to fix this. Clearly it > isn't clear. The new wording works great for me; it even solves another problem as well. :) -- Russ Allbery (rra@stanford.edu) From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 17:10:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00397 for ; Mon, 11 Apr 2005 17:10:35 -0400 (EDT) Received: from smtp2.stanford.edu ([171.67.16.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6KW-0008QY-33 for nntpext-archive@ietf.org; Mon, 11 Apr 2005 17:20:24 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BLARcj006654; Mon, 11 Apr 2005 14:10:27 -0700 Received: (qmail 2744 invoked by uid 64013); 11 Apr 2005 21:10:27 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 21:10:27 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 2735 invoked by uid 64013); 11 Apr 2005 21:10:26 -0000 Received: from windlord.stanford.edu (171.64.19.147) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 21:10:26 -0000 Received: (qmail 7597 invoked by uid 1000); 11 Apr 2005 21:10:26 -0000 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Article references In-Reply-To: <20050411210303.GB1299@finch-staff-1.thus.net> (Clive D. W. Feather's message of "Mon, 11 Apr 2005 22:03:03 +0100") References: <20050411161854.GQ46784@finch-staff-1.thus.net> <425AA5B2.90202@oceana.com> <20050411210303.GB1299@finch-staff-1.thus.net> From: Russ Allbery Organization: The Eyrie Date: Mon, 11 Apr 2005 14:10:26 -0700 Message-ID: <873btxf29p.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Clive D W Feather writes: > Wording attempt two: > I propose modifying section 6 as follows: > News reading clients have available a variety of mechanisms to > retrieve articles via NNTP. The news articles are stored and indexed > using three types of keys. One key is the message-id of an article. > Another key is composed of the newsgroup name and the article number > within that newsgroup. That key MUST be unique to a particular > server (there will be only one article with that number within a > particular newsgroup), but is not required to be globally unique. > Additionally, because the same article can be cross-posted to > multiple newsgroups, there may be multiple keys that point to the > - same article on the same server. The final key is the arrival > + same article on the same server; nevertheless, a given article > + MUST NOT have two different article numbers in any particular > + newsgroup on a particular server. The final key is the arrival > timestamp, giving the time that the article arrived at the server. I'm also fine with this. -- Russ Allbery (rra@stanford.edu) From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 17:14:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01146 for ; Mon, 11 Apr 2005 17:14:37 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6OQ-0000EY-AC for nntpext-archive@ietf.org; Mon, 11 Apr 2005 17:24:26 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BLESnP001525; Mon, 11 Apr 2005 14:14:29 -0700 Received: (qmail 2958 invoked by uid 64013); 11 Apr 2005 21:14:28 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 21:14:28 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 2949 invoked by uid 64013); 11 Apr 2005 21:14:27 -0000 Received: from anchor-internal-1.mail.demon.net (195.173.56.100) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 21:14:27 -0000 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j3BLEQhx009023; Mon, 11 Apr 2005 21:14:26 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1DL6Ej-0000lV-00 for ietf-nntp@lists.eyrie.org; Mon, 11 Apr 2005 22:14:25 +0100 Date: Mon, 11 Apr 2005 22:14:25 +0100 From: "Clive D.W. Feather" To: IETF NNTP mailing list Message-ID: <20050411211425.GD1299@finch-staff-1.thus.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Subject: [NNTP] Misc changes X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 A couple of weeks ago we were discussing a number of changes, particularly to capabilities but possibly also to other things. I don't think I made any changes to the draft because I didn't think any of them had converged. So can anyone (Russ?) remember what they were and where they got to? My memory lists the following, but I don't claim it's complete: (1) Placeholder for capability information in responses. I think we settled that this can be an extension requested by the client - the only thing this loses is the ability to put capability information in the initial greeting. (2) Make POST a separate capability. I think this was agreed. (3) Make LISTGROUP a separate capability. I remember being against this. (4) A range facility for LISTGROUP. From memory there was significant disagreement as to the semantics. -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 17:16:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01815 for ; Mon, 11 Apr 2005 17:16:53 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6Qb-0000SR-RR for nntpext-archive@ietf.org; Mon, 11 Apr 2005 17:26:42 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BLGjhj002620; Mon, 11 Apr 2005 14:16:45 -0700 Received: (qmail 3168 invoked by uid 64013); 11 Apr 2005 21:16:45 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 21:16:45 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 3159 invoked by uid 64013); 11 Apr 2005 21:16:42 -0000 Received: from anchor-internal-1.mail.demon.net (195.173.56.100) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 21:16:42 -0000 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j3BLGfoU009366Mon, 11 Apr 2005 21:16:41 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1DL6Gv-0000o1-00; Mon, 11 Apr 2005 22:16:41 +0100 Date: Mon, 11 Apr 2005 22:16:41 +0100 From: "Clive D.W. Feather" To: Russ Allbery Subject: Re: [NNTP] Article references Message-ID: <20050411211641.GE1299@finch-staff-1.thus.net> References: <20050411161854.GQ46784@finch-staff-1.thus.net> <425AA5B2.90202@oceana.com> <87y8bpgnxg.fsf@windlord.stanford.edu> <425AD96F.7010305@oceana.com> <87k6n9f4h6.fsf@windlord.stanford.edu> <20050411205921.GA1299@finch-staff-1.thus.net> <87d5t1f2cd.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d5t1f2cd.fsf@windlord.stanford.edu> User-Agent: Mutt/1.5.3i Cc: ietf-nntp@lists.eyrie.org X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Russ Allbery said: >> Article arrives. The server makes it article 123 in alt.test. >> What stops the server *also* making it 124 in alt.test? > > I hadn't thought about that angle. (Although we're getting into outlawing > insane behavior that no one is likely to do in practice, which can be a > bit of a waste of time.) Um, this was triggered by a thread in news.software.nntp about a server that *was* doing this! Subject "duplicate articles". >> The purpose of the proposed wording change is to fix this. Clearly it >> isn't clear. > The new wording works great for me; it even solves another problem as > well. :) Oh? What problem. [And do you mean the old new wording or the new new wording?] -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 17:23:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02793 for ; Mon, 11 Apr 2005 17:23:47 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6XH-0000nm-Oe for nntpext-archive@ietf.org; Mon, 11 Apr 2005 17:33:36 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BLNcnE007742; Mon, 11 Apr 2005 14:23:38 -0700 Received: (qmail 3400 invoked by uid 64013); 11 Apr 2005 21:23:38 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 21:23:38 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 3391 invoked by uid 64013); 11 Apr 2005 21:23:36 -0000 Received: from windlord.stanford.edu (171.64.19.147) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 21:23:36 -0000 Received: (qmail 8465 invoked by uid 1000); 11 Apr 2005 21:23:36 -0000 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Article references In-Reply-To: <20050411211641.GE1299@finch-staff-1.thus.net> (Clive D. W. Feather's message of "Mon, 11 Apr 2005 22:16:41 +0100") References: <20050411161854.GQ46784@finch-staff-1.thus.net> <425AA5B2.90202@oceana.com> <87y8bpgnxg.fsf@windlord.stanford.edu> <425AD96F.7010305@oceana.com> <87k6n9f4h6.fsf@windlord.stanford.edu> <20050411205921.GA1299@finch-staff-1.thus.net> <87d5t1f2cd.fsf@windlord.stanford.edu> <20050411211641.GE1299@finch-staff-1.thus.net> From: Russ Allbery Organization: The Eyrie Date: Mon, 11 Apr 2005 14:23:36 -0700 Message-ID: <87hdiddn3b.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Clive D W Feather writes: > Russ Allbery said: >> I hadn't thought about that angle. (Although we're getting into >> outlawing insane behavior that no one is likely to do in practice, >> which can be a bit of a waste of time.) > Um, this was triggered by a thread in news.software.nntp about a server > that *was* doing this! Subject "duplicate articles". I think I'm just very confused. Ignore me. The new wording seems great to me. -- Russ Allbery (rra@stanford.edu) From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 17:28:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03335 for ; Mon, 11 Apr 2005 17:28:57 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL6cH-0000yT-Ht for nntpext-archive@ietf.org; Mon, 11 Apr 2005 17:38:46 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BLSmk9007669; Mon, 11 Apr 2005 14:28:48 -0700 Received: (qmail 3642 invoked by uid 64013); 11 Apr 2005 21:28:48 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 21:28:48 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 3633 invoked by uid 64013); 11 Apr 2005 21:28:46 -0000 Received: from windlord.stanford.edu (171.64.19.147) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 21:28:46 -0000 Received: (qmail 8585 invoked by uid 1000); 11 Apr 2005 21:28:46 -0000 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Misc changes In-Reply-To: <20050411211425.GD1299@finch-staff-1.thus.net> (Clive D. W. Feather's message of "Mon, 11 Apr 2005 22:14:25 +0100") References: <20050411211425.GD1299@finch-staff-1.thus.net> From: Russ Allbery Organization: The Eyrie Date: Mon, 11 Apr 2005 14:28:46 -0700 Message-ID: <87d5t1dmup.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Clive D W Feather writes: > So can anyone (Russ?) remember what they were and where they got to? My > memory lists the following, but I don't claim it's complete: > (1) Placeholder for capability information in responses. I think we > settled that this can be an extension requested by the client - the only > thing this loses is the ability to put capability information in the > initial greeting. I agree. I think we aren't going to make any changes in this area. > (2) Make POST a separate capability. I think this was agreed. Yes. > (3) Make LISTGROUP a separate capability. I remember being against this. > (4) A range facility for LISTGROUP. From memory there was significant > disagreement as to the semantics. I'm going to make one more shot at writing up a proposal for how to change LISTGROUP and see if we can get consensus. If not, we'll drop it, although I think we should still seriously consider making LISTGROUP mandatory. The other item that was raised was adding a capability for NEWNEWS. I agree with the feeling that servers should really provide it, but given the number that choose not to, maybe we shouldn't be dictating policy in the standard to quite that degree. It does have the problem that a syntactically proper NEWNEWS command can take a huge amount of resources without any realistic way of reducing those resources: NEWNEWS * 19700101 000000 GMT something that I don't believe is shared by any other mandatory command. It's not that servers won't implement it at all, but rather that they may not want to make it available to general (unautheticated, lower-paying, whatever) clients. -- Russ Allbery (rra@stanford.edu) From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 19:41:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12290 for ; Mon, 11 Apr 2005 19:41:41 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8gl-0004AM-Pq for nntpext-archive@ietf.org; Mon, 11 Apr 2005 19:51:32 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BNfWao031995; Mon, 11 Apr 2005 16:41:32 -0700 Received: (qmail 5381 invoked by uid 64013); 11 Apr 2005 23:41:32 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 23:41:32 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 5372 invoked by uid 64013); 11 Apr 2005 23:41:30 -0000 Received: from smtps-vbr2.xs4all.nl (194.109.24.18) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 23:41:30 -0000 Received: from isop10 (velvet.isolution.nl [194.109.164.102]) (authenticated bits=0) by smtps-vbr2.xs4all.nl (8.12.11/8.12.11) with ESMTP id j3BNfT4Q046024 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Apr 2005 01:41:29 +0200 (CEST) (envelope-from rvtol@isolution.nl) Message-ID: <180001c53eef$fc03a3d0$0b01a8c0@isolution.nl> From: "Ruud H.G. van Tol" To: References: <20050411161854.GQ46784@finch-staff-1.thus.net><425AA5B2.90202@oceana.com><20050411210303.GB1299@finch-staff-1.thus.net> <873btxf29p.fsf@windlord.stanford.edu> Subject: Re: [NNTP] Article references Date: Tue, 12 Apr 2005 01:41:25 +0200 Organization: Chaos rules. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Virus-Scanned: by XS4ALL Virus Scanner X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Russ Allbery: > Clive D W Feather: >> News reading clients have available a variety of mechanisms to >> retrieve articles via NNTP. The news articles are stored and indexed >> using three types of keys. One key is the message-id of an article. >> Another key is composed of the newsgroup name and the article number >> within that newsgroup. That key MUST be unique to a particular >> server (there will be only one article with that number within a >> particular newsgroup), but is not required to be globally unique. >> Additionally, because the same article can be cross-posted to >> multiple newsgroups, there may be multiple keys that point to the >> - same article on the same server. The final key is the arrival >> + same article on the same server; nevertheless, a given article >> + MUST NOT have two different article numbers in any particular >> + newsgroup on a particular server. The final key is the arrival >> timestamp, giving the time that the article arrived at the server. > I'm also fine with this. I still see some problems. The "but is not required to be globally unique" is trying to counter a popular misconception, but is not adding much information. First try: News reading clients have available a variety of mechanisms to retrieve articles via NNTP. The news articles are stored and indexed using three types of keys. The first key is the message-id of an article. The second type of key is composed of a newsgroup name and a rotation number within that newsgroup. That key is unique to a particular server. An article has (gets? is assigned?) exactly one such unique key per served newsgroup that it is posted in. (that it belongs to?) These article numbers are local to the newsgroup and to the server, so the article is likely to have different article numbers in the related newsgroups, and in the same newsgroup on different servers. The third key is the arrival timestamp, giving the time that the article arrived at the server. This key can be shared by multiple articles. -- Grtz, Ruud From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 19:54:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13326 for ; Mon, 11 Apr 2005 19:54:15 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DL8sv-0004Vn-Jx for nntpext-archive@ietf.org; Mon, 11 Apr 2005 20:04:07 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3BNs61b012776; Mon, 11 Apr 2005 16:54:06 -0700 Received: (qmail 5609 invoked by uid 64013); 11 Apr 2005 23:54:05 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 11 Apr 2005 23:54:05 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 5600 invoked by uid 64013); 11 Apr 2005 23:54:03 -0000 Received: from smtps-vbr1.xs4all.nl (194.109.24.19) by lothlorien.stanford.edu with SMTP; 11 Apr 2005 23:54:03 -0000 Received: from isop10 (velvet.isolution.nl [194.109.164.102]) (authenticated bits=0) by smtps-vbr1.xs4all.nl (8.12.11/8.12.11) with ESMTP id j3BNs1K1086437 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Apr 2005 01:54:02 +0200 (CEST) (envelope-from rvtol@isolution.nl) Message-ID: <182001c53ef1$bc950390$0b01a8c0@isolution.nl> From: "Ruud H.G. van Tol" To: References: <20050411161854.GQ46784@finch-staff-1.thus.net><425AA5B2.90202@oceana.com><20050411210303.GB1299@finch-staff-1.thus.net><873btxf29p.fsf@windlord.stanford.edu> <180001c53eef$fc03a3d0$0b01a8c0@isolution.nl> Subject: Re: [NNTP] Article references Date: Tue, 12 Apr 2005 01:53:57 +0200 Organization: Chaos rules. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Virus-Scanned: by XS4ALL Virus Scanner X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Ruud H.G. van Tol schreef: > These article numbers are local to the newsgroup and to the server, so > the article is likely to have different article numbers in the related > newsgroups, and in the same newsgroup on different servers. These article numbers are local(ly unique?) to the newsgroup and to the server, so the article is likely to have different article numbers in its newsgroups on the same server, and in any of its newsgroups on different servers. -- Grtz, Ruud From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Mon Apr 11 23:18:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27611 for ; Mon, 11 Apr 2005 23:18:11 -0400 (EDT) Received: from smtp2.stanford.edu ([171.67.16.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLC4J-0001Pm-0G for nntpext-archive@ietf.org; Mon, 11 Apr 2005 23:28:03 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3C3I2Uk030406; Mon, 11 Apr 2005 20:18:02 -0700 Received: (qmail 8665 invoked by uid 64013); 12 Apr 2005 03:18:02 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 12 Apr 2005 03:18:02 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 8656 invoked by uid 64013); 12 Apr 2005 03:18:00 -0000 Received: from trinity.ranger.supernews.net (HELO trinity.supernews.net) (216.168.1.22) by lothlorien.stanford.edu with SMTP; 12 Apr 2005 03:18:00 -0000 Received: from andrew by trinity.supernews.net with local (Exim 4.42 (FreeBSD)) id 1DLBuZ-0006h9-OW; Tue, 12 Apr 2005 03:17:59 +0000 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Article references In-Reply-To: <20050411205921.GA1299@finch-staff-1.thus.net> (Clive D. W. Feather's message of "Mon, 11 Apr 2005 21:59:21 +0100") References: <20050411161854.GQ46784@finch-staff-1.thus.net> <425AA5B2.90202@oceana.com> <87y8bpgnxg.fsf@windlord.stanford.edu> <425AD96F.7010305@oceana.com> <87k6n9f4h6.fsf@windlord.stanford.edu> <20050411205921.GA1299@finch-staff-1.thus.net> Date: Tue, 12 Apr 2005 04:17:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Andrew - Supernews" Message-Id: X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 >>>>> "Clive" == Clive D W Feather writes: Clive> Article arrives. The server makes it article 123 in Clive> alt.test. What stops the server *also* making it 124 in Clive> alt.test? Some servers are known to do exactly that if the article has Newsgroups: alt.test,alt.test But the guy in n.s.nntp probably wasn't seeing that, it is more likely that he was using a server with a very short history file, and therefore duplicate articles were being accepted that way. -- Andrew, Supernews http://www.supernews.com From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Tue Apr 12 07:12:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19690 for ; Tue, 12 Apr 2005 07:12:43 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLJTb-0005J8-FC for nntpext-archive@ietf.org; Tue, 12 Apr 2005 07:22:40 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3CBCYhU011131; Tue, 12 Apr 2005 04:12:34 -0700 Received: (qmail 14705 invoked by uid 64013); 12 Apr 2005 11:12:34 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 12 Apr 2005 11:12:34 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 14696 invoked by uid 64013); 12 Apr 2005 11:12:32 -0000 Received: from smtp811.mail.ukl.yahoo.com (217.12.12.201) by lothlorien.stanford.edu with SMTP; 12 Apr 2005 11:12:32 -0000 Received: from unknown (HELO host81-144-77-234.midband.mdip.bt.net) (ietf-nntp@lists.eyrie.org@81.144.77.234 with poptime) by smtp811.mail.ukl.yahoo.com with SMTP; 12 Apr 2005 11:12:30 -0000 Received: (from news@localhost) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) id j3CBCD921311 for ietf-nntp@lists.eyrie.org; Tue, 12 Apr 2005 12:12:13 +0100 (BST) To: ietf-nntp@lists.eyrie.org Xref: clerew local.nntp:4339 Newsgroups: local.nntp Path: clerew!chl From: "Charles Lindsey" Subject: Re: [NNTP] Article references Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <20050411161854.GQ46784@finch-staff-1.thus.net> <425AA5B2.90202@oceana.com> <20050411210303.GB1299@finch-staff-1.thus.net> Date: Tue, 12 Apr 2005 10:23:41 GMT Lines: 39 X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 In <20050411210303.GB1299@finch-staff-1.thus.net> "Clive D.W. Feather" writes: >Wording attempt two: >I propose modifying section 6 as follows: > News reading clients have available a variety of mechanisms to > retrieve articles via NNTP. The news articles are stored and indexed > using three types of keys. One key is the message-id of an article. > Another key is composed of the newsgroup name and the article number > within that newsgroup. That key MUST be unique to a particular > server (there will be only one article with that number within a > particular newsgroup), but is not required to be globally unique. > Additionally, because the same article can be cross-posted to > multiple newsgroups, there may be multiple keys that point to the >- same article on the same server. The final key is the arrival >+ same article on the same server; nevertheless, a given article >+ MUST NOT have two different article numbers in any particular >+ newsgroup on a particular server. The final key is the arrival > timestamp, giving the time that the article arrived at the server. That still contains one problem for those who read the text with malicious intent. "there may be multiple keys that point to the same article on the same server" might be taken as implying there might be two message-ids pointing to the same article, whereas it is clear that "multiple keys" is only intended to refer to keys of the second type. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Tue Apr 12 09:53:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00169 for ; Tue, 12 Apr 2005 09:53:48 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLLzT-0001JM-Id for nntpext-archive@ietf.org; Tue, 12 Apr 2005 10:03:45 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3CDrafG031441; Tue, 12 Apr 2005 06:53:36 -0700 Received: (qmail 16885 invoked by uid 64013); 12 Apr 2005 13:53:36 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 12 Apr 2005 13:53:36 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 16876 invoked by uid 64013); 12 Apr 2005 13:53:33 -0000 Received: from eagle.oceana.com (208.17.123.12) by lothlorien.stanford.edu with SMTP; 12 Apr 2005 13:53:33 -0000 Received: from [192.168.10.26] (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.13.2/8.13.2) with ESMTP id j3CDrUXw029540 for ; Tue, 12 Apr 2005 09:53:31 -0400 (EDT) Message-ID: <425BD2B4.2080209@oceana.com> Date: Tue, 12 Apr 2005 09:52:52 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en,pdf MIME-Version: 1.0 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Misc changes References: <20050411211425.GD1299@finch-staff-1.thus.net> <87d5t1dmup.fsf@windlord.stanford.edu> In-Reply-To: <87d5t1dmup.fsf@windlord.stanford.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0 (BAYES_00) X-Scanned-By: MIMEDefang 2.39 X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Russ Allbery wrote: > Clive D W Feather writes: > >>(4) A range facility for LISTGROUP. From memory there was significant >>disagreement as to the semantics. > > > I'm going to make one more shot at writing up a proposal for how to change > LISTGROUP and see if we can get consensus. If not, we'll drop it, > although I think we should still seriously consider making LISTGROUP > mandatory. > > The other item that was raised was adding a capability for NEWNEWS. I > agree with the feeling that servers should really provide it, but given > the number that choose not to, maybe we shouldn't be dictating policy in > the standard to quite that degree. It does have the problem that a > syntactically proper NEWNEWS command can take a huge amount of resources > without any realistic way of reducing those resources: > > NEWNEWS * 19700101 000000 GMT > > something that I don't believe is shared by any other mandatory command. > It's not that servers won't implement it at all, but rather that they may > not want to make it available to general (unautheticated, lower-paying, > whatever) clients. Here's my $.02: I think both of these fall into the gray area of trying to document what we feel is the proper "core" functionality vs. what is actually done in practice. In both of these cases it think we need to lean towards existing deployed behavior. IMO, both of these changes can be made without breaking existing clients. If virtually all deployed servers provide LISTGROUP then we can/should make it mandatory because virtually all clients will depend on it anyways (whether its advertised or not). With respect to LISTGROUP functionality, I think an argument can be made either way for a separate capability. Since this is v2 of NNTP we *can* mandate that a v2 server provide LISTGROUP . On the other hand, if providing this functionality will be too difficult for some server architectures, then we should make it optional. Regardless of the fact that NEWNEWS has always been mandatory, if a large portion of deployed servers/admins disable it, we should make it optional and give it its own capability. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Tue Apr 12 17:37:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14732 for ; Tue, 12 Apr 2005 17:37:39 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTER-0000gC-Ds for nntpext-archive@ietf.org; Tue, 12 Apr 2005 17:47:41 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3CLbS42006404; Tue, 12 Apr 2005 14:37:28 -0700 Received: (qmail 22772 invoked by uid 64013); 12 Apr 2005 21:37:28 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 12 Apr 2005 21:37:28 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 22763 invoked by uid 64013); 12 Apr 2005 21:37:26 -0000 Received: from anchor-internal-1.mail.demon.net (195.173.56.100) by lothlorien.stanford.edu with SMTP; 12 Apr 2005 21:37:26 -0000 Received: from finch-staff-1.server.demon.net (finch-staff-1.server.demon.net [193.195.224.1]) by anchor-internal-1.mail.demon.net with ESMTP id j3CLbN68002681Tue, 12 Apr 2005 21:37:24 GMT Received: from clive by finch-staff-1.server.demon.net with local (Exim 3.36 #1) id 1DLT4V-0003Du-00; Tue, 12 Apr 2005 22:37:23 +0100 Date: Tue, 12 Apr 2005 22:37:23 +0100 From: "Clive D.W. Feather" To: Russ Allbery Subject: Re: [NNTP] Misc changes Message-ID: <20050412213723.GE91536@finch-staff-1.thus.net> References: <20050411211425.GD1299@finch-staff-1.thus.net> <87d5t1dmup.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d5t1dmup.fsf@windlord.stanford.edu> User-Agent: Mutt/1.5.3i Cc: ietf-nntp@lists.eyrie.org X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Russ Allbery said: > I'm going to make one more shot at writing up a proposal for how to change > LISTGROUP and see if we can get consensus. If not, we'll drop it, > although I think we should still seriously consider making LISTGROUP > mandatory. Mandatory if READER is advertised, or mandatory full stop? I would be happy with the former but not the latter (it makes no sense without the rest of the READER group). -- Clive D.W. Feather | Work: | Tel: +44 20 8495 6138 Internet Expert | Home: | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Tue Apr 12 17:39:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14941 for ; Tue, 12 Apr 2005 17:39:30 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTGG-0000m4-Am for nntpext-archive@ietf.org; Tue, 12 Apr 2005 17:49:32 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3CLdMSo007316; Tue, 12 Apr 2005 14:39:23 -0700 Received: (qmail 23035 invoked by uid 64013); 12 Apr 2005 21:39:22 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 12 Apr 2005 21:39:22 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 23026 invoked by uid 64013); 12 Apr 2005 21:39:21 -0000 Received: from windlord.stanford.edu (171.64.19.147) by lothlorien.stanford.edu with SMTP; 12 Apr 2005 21:39:21 -0000 Received: (qmail 27685 invoked by uid 1000); 12 Apr 2005 21:39:20 -0000 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Misc changes In-Reply-To: <20050412213723.GE91536@finch-staff-1.thus.net> (Clive D. W. Feather's message of "Tue, 12 Apr 2005 22:37:23 +0100") References: <20050411211425.GD1299@finch-staff-1.thus.net> <87d5t1dmup.fsf@windlord.stanford.edu> <20050412213723.GE91536@finch-staff-1.thus.net> From: Russ Allbery Organization: The Eyrie Date: Tue, 12 Apr 2005 14:39:20 -0700 Message-ID: <87aco3vfnb.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Clive D W Feather writes: > Russ Allbery said: >> I'm going to make one more shot at writing up a proposal for how to >> change LISTGROUP and see if we can get consensus. If not, we'll drop >> it, although I think we should still seriously consider making >> LISTGROUP mandatory. > Mandatory if READER is advertised, or mandatory full stop? If READER is advertised. Sorry for the lack of clarity. -- Russ Allbery (rra@stanford.edu) From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Tue Apr 12 18:22:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19118 for ; Tue, 12 Apr 2005 18:22:33 -0400 (EDT) Received: from smtp1.stanford.edu ([171.67.16.123]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTvs-000270-SB for nntpext-archive@ietf.org; Tue, 12 Apr 2005 18:32:36 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp1.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3CMMMvE024559; Tue, 12 Apr 2005 15:22:22 -0700 Received: (qmail 23904 invoked by uid 64013); 12 Apr 2005 22:22:21 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 12 Apr 2005 22:22:21 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 23890 invoked by uid 64013); 12 Apr 2005 22:22:20 -0000 Received: from ptb-relay02.plus.net (212.159.14.213) by lothlorien.stanford.edu with SMTP; 12 Apr 2005 22:22:20 -0000 Received: from [80.229.20.190] (helo=[192.168.0.2]) by ptb-relay02.plus.net with esmtp (Exim) id 1DLTly-000NSR-OE for ietf-nntp@lists.eyrie.org; Tue, 12 Apr 2005 22:22:18 +0000 To: ietf-nntp@lists.eyrie.org In-Reply-To: <87d5t1dmup.fsf@windlord.stanford.edu> Subject: Re: [NNTP] Misc changes From: pmrobinson@gmx.net (Peter Robinson) Date: Tue, 12 Apr 2005 23:22:17 +0100 Message-ID: <1guxaza.1p9u9q49cvu24M%pmrobinson@gmx.net> User-Agent: MacSOUP/2.7 (Mac OS X version 10.3.8) X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Russ Allbery wrote: > Clive D W Feather writes: [snips] > > (2) Make POST a separate capability. I think this was agreed. > > Yes. Excellent. > The other item that was raised was adding a capability for NEWNEWS. I > agree with the feeling that servers should really provide it, but given > the number that choose not to, maybe we shouldn't be dictating policy in > the standard to quite that degree. My opinion is that NEWNEWS should be given its own CAPABILITY. Despite RFC977, some servers don't implement NEWNEWS because it's seen as too expensive (or for some other reason). That's not going to change just because this new spec says it should. Surely a large part of the purpose of this group is to document current behaviour, including (especially?) where it diverges from RFC977. Now we've gone to all the trouble of adding a beautiful new CAPABILITIES mechanism, it seems to me to be madness to preserve the current situation where a client author can diligently read the specs, design and test his algorithm, ship it, and only then discover that it doesn't work with N% of servers despite being completely correct wrt the specs. Regards, Peter From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Tue Apr 12 18:22:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19177 for ; Tue, 12 Apr 2005 18:22:38 -0400 (EDT) Received: from smtp3.stanford.edu ([171.67.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLTw0-00027K-9k for nntpext-archive@ietf.org; Tue, 12 Apr 2005 18:32:40 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp3.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3CMMUWn019232; Tue, 12 Apr 2005 15:22:30 -0700 Received: (qmail 24056 invoked by uid 64013); 12 Apr 2005 22:22:26 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 12 Apr 2005 22:22:26 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 23891 invoked by uid 64013); 12 Apr 2005 22:22:20 -0000 Received: from ptb-relay02.plus.net (212.159.14.213) by lothlorien.stanford.edu with SMTP; 12 Apr 2005 22:22:20 -0000 Received: from [80.229.20.190] (helo=[192.168.0.2]) by ptb-relay02.plus.net with esmtp (Exim) id 1DLTlz-000NSR-Bu for ietf-nntp@lists.eyrie.org; Tue, 12 Apr 2005 22:22:19 +0000 To: ietf-nntp@lists.eyrie.org (IETF NNTP mailing list) In-Reply-To: <20050411155810.GP46784@finch-staff-1.thus.net> Subject: Re: [NNTP] Multi-line blocks From: pmrobinson@gmx.net (Peter Robinson) Date: Tue, 12 Apr 2005 23:22:18 +0100 Message-ID: <1guxhi0.cte75o1l4qewwM%pmrobinson@gmx.net> User-Agent: MacSOUP/2.7 (Mac OS X version 10.3.8) X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Clive D.W. Feather wrote: > [...] I've decided to invent a new term "multi-line data block" and > rephrase other places to use it. Here's the significant diffs - scream now > or forever hold your peace. I'm slightly worried about making changes to the fundamentals at this stage. But it does crystallise a useful concept, so I say do it. Carefully. I've had a quick look through, and noticed one annoying nit though: > +3.1.1 Multi-line data blocks [...] > - 4. The lines of the response MUST be followed by a terminating line > + 4. The lines of the block MUST be followed by a terminating line > consisting of a single termination octet followed by a CRLF pair > - in the normal way. Thus a multi-line response is always > - terminated with the five octets CRLF "." CRLF (%x0D.0A.2E.0D.0A). > + in the normal way. Thus a multi-line block is always terminated > + with the five octets CRLF "." CRLF (%x0D.0A.2E.0D.0A). The last sentence is not strictly true since an 'empty' multi-line block consists only of the last three of those octets. > 6. Likewise, the terminating line ("." CRLF or %x2E.0D.0A) MUST NOT > - be considered part of the multi-line response; i.e. the client > + be considered part of the multi-line block; i.e. the recipient > MUST ensure that any line beginning with the termination octet > followed immediately by a CRLF pair is disregarded; (the first > CRLF pair of the terminating CRLF "." CRLF is, of course, part of > - the last line of the response). > + the last line of the block). And again, that's not strictly true for an empty block. Regards, Peter From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Tue Apr 12 22:12:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05572 for ; Tue, 12 Apr 2005 22:12:40 -0400 (EDT) Received: from smtp2.stanford.edu ([171.67.16.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLXWd-0007cT-MZ for nntpext-archive@ietf.org; Tue, 12 Apr 2005 22:22:44 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3D2CUVY011830; Tue, 12 Apr 2005 19:12:30 -0700 Received: (qmail 27231 invoked by uid 64013); 13 Apr 2005 02:12:30 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 13 Apr 2005 02:12:30 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 27222 invoked by uid 64013); 13 Apr 2005 02:12:29 -0000 Received: from smtp803.mail.ukl.yahoo.com (217.12.12.140) by lothlorien.stanford.edu with SMTP; 13 Apr 2005 02:12:29 -0000 Received: from unknown (HELO host81-144-73-208.midband.mdip.bt.net) (uri@w3.org@81.144.73.208 with poptime) by smtp803.mail.ukl.yahoo.com with SMTP; 13 Apr 2005 02:12:26 -0000 Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.11.7+Sun/8.11.7) with ESMTP id j3CHN2G23914; Tue, 12 Apr 2005 18:23:02 +0100 (BST) To: "uri@w3.org" References: <41C5AC54.6E20@xyzzy.claranet.de> <41C75B1B.6BAB@xyzzy.claranet.de> <41D56B45.6EA0@xyzzy.claranet.de> <41DAFD97.1A54@xyzzy.claranet.de> Message-ID: Date: Tue, 12 Apr 2005 18:22:56 +0100 From: "Charles Lindsey" Content-Type: multipart/mixed; boundary=----------AQkfuumIs07qsRIi735rLu MIME-Version: 1.0 In-Reply-To: User-Agent: Opera M2(BETA3)/8.0 (SunOS, build 1019) Cc: ietf-nntp@lists.eyrie.org Subject: [NNTP] Re: News and nntp URI schemes X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc ------------AQkfuumIs07qsRIi735rLu Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by smtp2.Stanford.EDU id j3D2CUVY011830 Content-Transfer-Encoding: quoted-printable On Thu, 10 Mar 2005 10:55:52 -0000, Charles Lindsey =20 wrote: > On Thu, 17 Feb 2005 16:59:48 -0000, Charles Lindsey =20 > wrote: >> [2nd alternative] >> >> newsURI =3D "news:" ( article / group ) >> article =3D [ news-server "/" ] message-id >> group =3D [ news-server "/" ] wildmat >> > There has been much discussion on the NNTP WG list about this in recent= =20 > days, mainly between myself and Russ Allbery. He has suggested various = =20 > small textual changes, which I have adopted, but more importantly he =20 > likes going for the 2nd alternative (i.e. wildmats). It seems that Lynx= , =20 > at least, already supports something pretty close to that, and it shoul= d =20 > also make Al Gilman happy. It would be useful, however, to hear of othe= r =20 > systems that will currently handle all, or most, of the examples listed= =20 > for the 2nd alternative. > > In the meantime, I intend to rewrite the text incorporating those =20 > wildmats, and I shall post it here for your consideration. > So I have now done this, and the text is attached. This is being sent to both the uri@w3.org and the =20 ietf-nntp@lists.eyrie.org lists. Ideally, it should be discussed on both lists (though it is uri@w3.org =20 that is ultimately responsible). However, keeping discussion alive on two= =20 lists is known to be a hazardous enterprise, so I shall report interestin= g =20 comments on each list to the other. --=20 Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing--= ---------------------- Tel:=A0+44=A0161=A0436=A06131=A0Fax:=A0+44=A0161=A0436=A06133=A0=A0=A0Web= :=A0http://www.cs.man.ac.uk/~chl Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A= ve,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 ------------AQkfuumIs07qsRIi735rLu Content-Disposition: attachment; filename=nntp-uri.txt Content-Type: text/plain; name=nntp-uri.txt Content-Transfer-Encoding: 8bit 2. The News URI Scheme The news URI scheme is used to refer to either news groups or individual Netnews articles, as defined in [RFC 1036]. The news URI takes the form: newsURI = "news:" ( article / collection ) article = [ news-server "/" ] message-id collection = [ news-server "/" ] wildmat / [ news-server [ "/" ] ] news-server = "//" authority message-id = printable-ascii "@" printable-ascii newsgroup-name = %x21-29 / %x2B / %x2D-3E / %x40-5A / %x5E-7E ; excludes "*" "," "?" "[" "\" "]" printable-ascii = 1*( %d33-61 / %d63-126 ) ; excludes ">" is defined in [RFC 3986], and provides for a , a (defaulting to 119 in this scheme) and possibly a . is defined in [NNTP], and provides for a single , or for a collection of s separated by ','s and using '*' and '?' for wild cards and `!` for negation. Within a or a , the characters '%', '@', '/', '?' and '#' are reserved and MUST be %-encoded if they occur. All other characters MAY be used freely to represent themselves. It is not precluded that future extensions for internationalized s may permit octets outside of the given ranges, in which case they too MUST be %-encoded (except perhaps when used in an IRI [RFC 3987]). [Issue: since '?' is used in a , maybe it shouldn't be reserved. I only put it there to allow for possible future extensions.] If no is specified, the resources are to be retrieved from whatever server has been configured for local use. 2.1 The newsURI contains an
A corresponds to the of [RFC 2822] and to the Message-ID of section 2.1.5 of [RFC 1036], but without the enclosing "<" and ">". It is intended to be the message identifier of an actual Netnews article and hence will in practice conform to the syntax defined in [RFC 1036] or in any subsequent standard for Netnews articles. Observe the delimiter "@" which enables an
to be distinguished from a . The resource retrieved by this URI is the Netnews article with the given . Message identifiers are required to be globally unique, so the same article should be obtained whatever server is accessed for that purpose (provided the server in question has that article available). 2.2 The newsURI contains a Any contained in or implied by any is intended to be that of an existing newsgroup, such as "comp.lang.perl.modules", and hence will in practice conform to the syntax defined in [RFC 1036] or in any subsequent standard for Netnews articles. If the in the consists of just a single , the resource retrieved by this URI is some means to gain access to the articles in the given that are available from the given (usually by invoking a suitable news reading agent initialized to access that group). If the in the identifies a collection of newsgroups, the resource retrieved by this URI is some means to gain access to all of those newsgroups which are available from the given (usually by invoking a suitable news reading agent). If the contains no at all, the effect is the same as that of the "*", meaning "all available newsgroups". [So we can now have the following forms: news:*.test news:* news://news.example.com/*.test news://news.example.com/* news://news.example.com/ news://news.example.com where the 2nd and the last 3 all refer to "all available news groups".] 3. The nntp URI scheme The nntp URI scheme is used to retrieve individual articles via the NNTP protocol [draft-ietf-nntpext-base-*.txt]. It is usually (but not necessarily) used in connection with Netnews articles as defined in [RFC 1036]. The nntp URI takes the form: nntpURI = "nntp" ":" news-server "/" newsgroup-name "/" range news-server = "//" authority range = article-number ["-" [article-number]] article-number = 1*DIGIT Observe, in contradistinction to the news scheme, that the is not optional here, because the mapping from to actual articles is established independently by each server. 3.1 The range is a single The resource retrieved by this URI is the Netnews article numbered by the given in the given from the given . 3.2 The range encompasses more than a single The resource retrieved by this URI is some means to gain access to the articles numbered within the given of s in the given from the given (usually by invoking a suitable news reading agent initialized to access that range). A of the form "nnnn-" provides access to all articles numbered "nnnn" and above. ------------AQkfuumIs07qsRIi735rLu-- From ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Tue Apr 12 22:24:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06025 for ; Tue, 12 Apr 2005 22:24:03 -0400 (EDT) Received: from smtp2.stanford.edu ([171.67.16.125]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DLXhe-0007qI-Hm for nntpext-archive@ietf.org; Tue, 12 Apr 2005 22:34:08 -0400 Received: from news.eyrie.org (lothlorien.Stanford.EDU [171.64.12.22]) by smtp2.Stanford.EDU (8.12.11/8.12.11) with SMTP id j3D2NrIq015111; Tue, 12 Apr 2005 19:23:53 -0700 Received: (qmail 27460 invoked by uid 64013); 13 Apr 2005 02:23:53 -0000 Received: from localhost.stanford.edu (HELO lothlorien.stanford.edu) (127.0.0.1) by localhost.stanford.edu with SMTP; 13 Apr 2005 02:23:53 -0000 Delivered-To: mailman-ietf-nntp@lists.eyrie.org Received: (qmail 27451 invoked by uid 64013); 13 Apr 2005 02:23:51 -0000 Received: from windlord.stanford.edu (171.64.19.147) by lothlorien.stanford.edu with SMTP; 13 Apr 2005 02:23:51 -0000 Received: (qmail 5132 invoked by uid 1000); 13 Apr 2005 02:23:50 -0000 To: ietf-nntp@lists.eyrie.org Subject: Re: [NNTP] Re: News and nntp URI schemes In-Reply-To: (Charles Lindsey's message of "Tue, 12 Apr 2005 18:22:56 +0100") References: <41C5AC54.6E20@xyzzy.claranet.de> <41C75B1B.6BAB@xyzzy.claranet.de> <41D56B45.6EA0@xyzzy.claranet.de> <41DAFD97.1A54@xyzzy.claranet.de> From: Russ Allbery Organization: The Eyrie Date: Tue, 12 Apr 2005 19:23:50 -0700 Message-ID: <871x9f1kjt.fsf@windlord.stanford.edu> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: ietf-nntp@lists.eyrie.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The IETF working group for the NNTP protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org Errors-To: ietf-nntp-bounces-nntpext-archive=ietf.org@lists.eyrie.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Charles Lindsey writes: > So I have now done this, and the text is attached. This looks good to me from an NNTP perspective. -- Russ Allbery (rra@stanford.edu)