http://blog.gmane.org/gmane.ietf.nntp hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.nntp/3797 <pre>Hi Barry, As I see that you are currently pretty active on errata for RFC 3977, I believe it could be time to properly close the two remaining subjects that weren't updated two years ago. * Could the following rationale be added to erratum 1707 for RFC 3977 so as to explain the reason of the reject? http://www.rfc-editor.org/errata_search.php?eid=1707 The high water mark is one less than the low water mark for empty newsgroups. A major reason for doing it this way was to deal with clusters of servers. If they're not perfectly synchronized, then a cancel might be visible on one and not another. So if you connect to the second one, it looks as if the article has been reinstated. Wording it like this meant we didn't need special treatment of such clusters. The low water mark cannot decrease. [Clive D.W. Feather] * Could erratum 1527 for RFC 3977 be updated and its status changed to "VERIFIED" so that it could be properly reviewed when the NNTP protocol moves from p</pre> Julien ÉLIE 2012-05-14T21:41:35 http://comments.gmane.org/gmane.ietf.nntp/3790 <pre>Hi, So, most (at least non-binary) peering arrangements include a list of groups the server wants to accept. Usually this is configured by hand, but there are automated out-of-band methods to do it automatically (e.g. GUP, the Group Update Protocol). I think a better way to do it would be a new command, which would list the groups the server wants to accept as a wildmat. For instance: S: 200 Server ready. C: CAPABILITIES S: 101 Capabilities list follows. S: WANTGROUPS S: ... S: . C: WANTGROUPS S: 2xx List of groups follows. S: * S: &lt; at &gt;alt.sex.* S: &lt; at &gt;*.bina* S: de.bina* S: !uk.test S: . C: CHECK &lt;... This would be an "extended" wildmat like INN uses; I don't think &lt; at &gt; is available in the RFC 3977 wildmats. Thoughts? Regards, </pre> River Tarnell 2012-01-07T18:56:11 http://comments.gmane.org/gmane.ietf.nntp/3788 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Re-sending this because it didn't appear again; I know I'm subscribed this time, so I think the S/MIME signature must be the problem.) Hi, I propose an extension to the NNTP protocol: a server should advertise the maximum article size it is willing to accept in CAPABILITIES, via a new "SIZE &lt;nbytes&gt;" capability. A client should not offer any article (via POST, IHAVE, CHECK or TAKETHIS) which is larger than that size. Rationale: no need to configure maximum article size to send to every peer; allows peers to change the maximum article size they want to accept without having to contact all their peers to change the config; allows clients posting multi-part messages (i.e., binaries) to split messages based on the server-suggested size. Real-world use: I can allow articles up to 1MB from a text-only peer, while restricting articles from a peer that carries unfiltered binaries to 32KB. I haven't implemented this or done any interoperability checking </pre> River Tarnell 2012-01-07T17:14:17 http://comments.gmane.org/gmane.ietf.nntp/3790 <pre>Hi, So, most (at least non-binary) peering arrangements include a list of groups the server wants to accept. Usually this is configured by hand, but there are automated out-of-band methods to do it automatically (e.g. GUP, the Group Update Protocol). I think a better way to do it would be a new command, which would list the groups the server wants to accept as a wildmat. For instance: S: 200 Server ready. C: CAPABILITIES S: 101 Capabilities list follows. S: WANTGROUPS S: ... S: . C: WANTGROUPS S: 2xx List of groups follows. S: * S: &lt; at &gt;alt.sex.* S: &lt; at &gt;*.bina* S: de.bina* S: !uk.test S: . C: CHECK &lt;... This would be an "extended" wildmat like INN uses; I don't think &lt; at &gt; is available in the RFC 3977 wildmats. Thoughts? Regards, </pre> River Tarnell 2012-01-07T18:56:11 http://comments.gmane.org/gmane.ietf.nntp/3788 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Re-sending this because it didn't appear again; I know I'm subscribed this time, so I think the S/MIME signature must be the problem.) Hi, I propose an extension to the NNTP protocol: a server should advertise the maximum article size it is willing to accept in CAPABILITIES, via a new "SIZE &lt;nbytes&gt;" capability. A client should not offer any article (via POST, IHAVE, CHECK or TAKETHIS) which is larger than that size. Rationale: no need to configure maximum article size to send to every peer; allows peers to change the maximum article size they want to accept without having to contact all their peers to change the config; allows clients posting multi-part messages (i.e., binaries) to split messages based on the server-suggested size. Real-world use: I can allow articles up to 1MB from a text-only peer, while restricting articles from a peer that carries unfiltered binaries to 32KB. I haven't implemented this or done any interoperability checking </pre> River Tarnell 2012-01-07T17:14:17 http://comments.gmane.org/gmane.ietf.nntp/3790 <pre>Hi, So, most (at least non-binary) peering arrangements include a list of groups the server wants to accept. Usually this is configured by hand, but there are automated out-of-band methods to do it automatically (e.g. GUP, the Group Update Protocol). I think a better way to do it would be a new command, which would list the groups the server wants to accept as a wildmat. For instance: S: 200 Server ready. C: CAPABILITIES S: 101 Capabilities list follows. S: WANTGROUPS S: ... S: . C: WANTGROUPS S: 2xx List of groups follows. S: * S: &lt; at &gt;alt.sex.* S: &lt; at &gt;*.bina* S: de.bina* S: !uk.test S: . C: CHECK &lt;... This would be an "extended" wildmat like INN uses; I don't think &lt; at &gt; is available in the RFC 3977 wildmats. Thoughts? Regards, </pre> River Tarnell 2012-01-07T18:56:11 http://comments.gmane.org/gmane.ietf.nntp/3788 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (Re-sending this because it didn't appear again; I know I'm subscribed this time, so I think the S/MIME signature must be the problem.) Hi, I propose an extension to the NNTP protocol: a server should advertise the maximum article size it is willing to accept in CAPABILITIES, via a new "SIZE &lt;nbytes&gt;" capability. A client should not offer any article (via POST, IHAVE, CHECK or TAKETHIS) which is larger than that size. Rationale: no need to configure maximum article size to send to every peer; allows peers to change the maximum article size they want to accept without having to contact all their peers to change the config; allows clients posting multi-part messages (i.e., binaries) to split messages based on the server-suggested size. Real-world use: I can allow articles up to 1MB from a text-only peer, while restricting articles from a peer that carries unfiltered binaries to 32KB. I haven't implemented this or done any interoperability checking </pre> River Tarnell 2012-01-07T17:14:17 http://comments.gmane.org/gmane.ietf.nntp/3782 <pre>(Re-sending because my first message didn't appear -- sorry if this shows up twice.) I just noticed the following rather unfortunate behaviour from one widely-used NNTP server: % telnet 69.16.177.254 nntp Trying 69.16.177.254... Connected to voer-me.highwinds-media.com. Escape character is '^]'. 200 (cyclone01.ams2) -- Welcome (Cyclone v2.4.1.749-3) CAPABILITIES 500 Syntax Error or Unknown Command Connection closed by foreign host. So 6 years after RFC 3799 was published, it's still impossible in practice to use CAPABILITIES to discover streaming. I don't have anything in particular to say about this, but I thought I'd note it for the list archives if nothing else. </pre> River Tarnell 2012-01-02T02:10:00 http://comments.gmane.org/gmane.ietf.nntp/3780 <pre>Is there a simple way to return a list of articles referencing a certain article? Currently, when I receive an article number, and want to fetch the articles referencing it, I have to do a full XOVER on all groups that may possibly contain a reply to that article. It's very inefficient, but it seems the only way. The only alternative would be: 'XPAT References &lt;msgid&gt;', but a very large percentage of the newsservers don't support XPAT because it uses too much CPU. If there was a command like 'REFERENCES &lt;msgid&gt;', servers could implement it much more efficiently than XPAT, since wildcards (*) aren't allowed, so all it needs is a single hash-table. Is there a specific reason why such a command doesn't exist? Or is it very unusual for replies to be posted to a different group than the original article? </pre> Fabian 2011-11-09T17:12:44 http://comments.gmane.org/gmane.ietf.nntp/3772 <pre>Okay, so I *finally* read through all the postings for the thread which I started. Sorry about that! Now I am happy with the outcome, it confirms my understanding of the specification, and all the errata are good. But as far as I can see there is still one more problem ... Article reinstatement, besides the stated uses of gradual cluster-wide synchronisation (which makes perfect sense) poses a small problem for many clients using articles as intended, monotonically increasing unique per-server references to articles. If a client should not be aware that an article has been removed pending reinstatement, it has no reason to suspect that the low watermark will ever decrease. Even if it wanted to, it could not straightforwardly obtain any articles that were added, and then removed pending reinstatement, both in the client's absence, when they were finally reinstated. Example: news.test has 5 messages, min=1 max=5. Article 1 is removed. Server indicates on group entry to news.test, min=2 max=5 no=4. Th</pre> Sabahattin Gucukoglu 2011-05-01T19:32:15 http://comments.gmane.org/gmane.ietf.nntp/3771 <pre>Just a few examples that could be added to RFC 3977. Following a discussion with Alfred Hönes, who reported: Interesting scenario. Here is what INN 2.5 answers: [No trigofacile.abc group] LISTGROUP trigofacile.abc 411 No such group trigofacile.abc [I create the group] LISTGROUP trigofacile.abc 211 0 1 0 trigofacile.abc . [I remove the group] LISTGROUP 411 No such group trigofacile.abc LISTGROUP trigofacile.abc 411 No such group trigofacile.abc OVER 420 Current article number 0 is invalid XOVER 420 Current article number 0 is invalid OVER 1 423 No articles in 1 XOVER 1 224 No articles in 1 . [I recreate the group] LISTGROUP 211 0 1 0 trigofacile.abc . As far as I can see, when the group is selected, we are inside it, with article number set to the first article (here, it is empty, so the article number is 0 -- but it could have been 7 or any other number). I think the behaviour is consistent. Not available =&gt; 411 412 would be for an invalid currently selected newsgroup. Yet, the currently sel</pre> Julien ÉLIE 2011-02-15T19:56:04 http://comments.gmane.org/gmane.ietf.nntp/3770 <pre>Following a discussion with Alfred Hönes, who reported: Well seen :-) Yet, the comment after the response code is only informative. A news server can put anything it wants. Even nothing. I bet the wording "no current article selected" is more user-friendly than "current article number is invalid". The meaning in Appendix C can be worded differently. I do not see a problem here. No need for an erratum. The question could of course be risen if RFC 3977 is moved to Draft Standard. To the working group: Where nits like these one should be kept for future reference? (Errata?) </pre> Julien ÉLIE 2011-02-15T19:47:49 http://comments.gmane.org/gmane.ietf.nntp/3769 <pre>Following a discussion with Alfred Hönes, who reported: &gt; clarification of intra-document ref. &gt; &gt; Within Section 2 of RFC 3977, the first paragraph on page 6 says: &gt; &gt; [...]. In some cases, however, they do assume that &gt; the currently selected newsgroup (see the GROUP command, &gt; Section 6.1.1) is invalid; when so, this is indicated at the start of &gt; the example. [...] &gt; &gt; The "currently selected newsgroup" is introduced in Section 6.1 (see &gt; next quotation below); as such, the clause therein, &gt; &gt; (see the GROUP command, Section 6.1.1) &gt; &gt; should more appropriately have been replaced by: &gt; &gt; (see Section 6.1) &gt; or: &gt; (see Section 6.1 ff.) I do not know well what to do with that. Here is my answer to Alfred: I do not think the text should be changed this way. In Section 6.1.1, we have: The GROUP command selects a newsgroup as the currently selected newsgroup and returns summary information about it. [...] When a valid</pre> Julien ÉLIE 2011-02-15T19:45:35 http://comments.gmane.org/gmane.ietf.nntp/3768 <pre>Following a discussion with Alfred Hönes, who reported: I believe this one is pretty clear and without any ambiguity. Let's deal with the other uses below. I think it is OK. [...] Maybe it should be explained. I do not know what is the best thing to do here. It is true that "valid" here means it is selectable by a GROUP/LISTGROUP command and will lead to a valid currently selected newsgroup. (A suggestion was to use "undefined" instead of "invalid". Or to use typographical enhancement to spell it: `invalid' with surrounding single back-quotes.) You're right. That is a very unfortunate use of "valid"/"invalid". Taken into account in erratum 2037: http://www.rfc-editor.org/errata_search.php?eid=2037 New wording used: Note that a previously valid article number MAY cease to refer to any article if that article has been removed, in which case use of that article number (explicitly or implicitly) will cause a 423 response. A previously removed article may be reinstated (</pre> Julien ÉLIE 2011-02-15T19:44:45 http://comments.gmane.org/gmane.ietf.nntp/3767 <pre>Following a discussion with Alfred Hönes, who reported: What annoys me most here is that RFC 3977 is not clear enough when it describes status field values. "Posting" means "Injection" (USEPRO [RFC 5537] terminology). We have in RFC 3977: 3.4.1. Reading and Transit Servers NNTP is traditionally used in two different ways. The first use is "reading", where the client fetches articles from a large store maintained by the server for immediate or later presentation to a user and sends articles created by that user back to the server (an action called "posting") to be stored and distributed to other stores and users. The second use is for the bulk transfer of articles from one store to another. Since the hosts making this transfer tend to be peers in a network that transmit articles among one another, and not end-user systems, this process is called "peering" or "transit". (Even so, one host is still the client and the other is the server). So basically, "Posting is not per</pre> Julien ÉLIE 2011-02-15T19:44:20 http://comments.gmane.org/gmane.ietf.nntp/3760 <pre>Hi all, "NNTP Additions to LIST Command" will be published as RFC 6048 and is now in AUTH48. Do not hesitate to speak up in case you wish to adjust something. http://www.rfc-editor.org/auth48/rfc6048 http://www.rfc-editor.org/authors/rfc6048.txt * The RFC Editor renamed [I-D.ietf-usefor-useage] this way: [USENET_BP] Lindsey, C., "Usenet Best Practice", Work in Progress, March 2005. Do you think it is OK and better than [USEAGE], as it is worded in RFCs 5536 and 5537? I believe it would be more consistent with [USEAGE]. That is what I will ask unless someone replies to explain why [USENET_BP] should be kept. [NNTP_LIST] seems fine for [I-D.draft-hernacki-nntplist]. * The RFC Editor changed a few "status" into "status fields". Well, I think she is right. And it also highlights other places where it should be changed... In Section 1: The ACTIVE variant was formalized in [RFC3977], but the meanings of only three status fields in LIST ACTIVE responses have be</pre> Julien ÉLIE 2010-10-18T20:13:18 http://comments.gmane.org/gmane.ietf.nntp/3760 <pre>Hi all, "NNTP Additions to LIST Command" will be published as RFC 6048 and is now in AUTH48. Do not hesitate to speak up in case you wish to adjust something. http://www.rfc-editor.org/auth48/rfc6048 http://www.rfc-editor.org/authors/rfc6048.txt * The RFC Editor renamed [I-D.ietf-usefor-useage] this way: [USENET_BP] Lindsey, C., "Usenet Best Practice", Work in Progress, March 2005. Do you think it is OK and better than [USEAGE], as it is worded in RFCs 5536 and 5537? I believe it would be more consistent with [USEAGE]. That is what I will ask unless someone replies to explain why [USENET_BP] should be kept. [NNTP_LIST] seems fine for [I-D.draft-hernacki-nntplist]. * The RFC Editor changed a few "status" into "status fields". Well, I think she is right. And it also highlights other places where it should be changed... In Section 1: The ACTIVE variant was formalized in [RFC3977], but the meanings of only three status fields in LIST ACTIVE responses have be</pre> Julien ÉLIE 2010-10-18T20:13:18 http://comments.gmane.org/gmane.ietf.nntp/3759 <pre>Hi all, We had a question on inn-workers about the response code a news server should give to a GROUP command for an existing newsgroup to which the client does not have access: https://lists.isc.org/pipermail/inn-workers/2010-September/017275.html It appears that INN answers 480/502 (depending on the state of authentication) but a few news clients (amongst them are tin and Thunderbird) immediately close the connection. As a matter of fact, according to RFC 3977: 502: It is necessary to terminate the connection and to start a new ^^^^^^^^^^^^^^^^^^^^^^^^ one with the appropriate authority before the command can be used. So... what are clients and servers expected to do? Suppose we have three groups on a news server : * group.public, readable by everybody * group.auth1, readable by user1 * group.auth2, readable by user2 Are the following answers the right ones? 200 Hello! LIST ACTIVE 215 Newsgroups in form "group high low status" group.public 00000</pre> Julien ÉLIE 2010-09-23T19:02:50 http://comments.gmane.org/gmane.ietf.nntp/3750 <pre>Hi, Section 3.3.3 of RFC 3977 says that the definition of an extension must include the following: o Any new arguments the extension associates with any other pre-existing NNTP commands. However, RFC 4642, 4643 and 4644 say: o This extension does not associate any new responses with pre- existing NNTP commands. There is a mismatch here. What is the right wording? Isn't it "responses" instead of "arguments" in RFC 3977? Or maybe both responses and arguments? </pre> Julien ÉLIE 2010-06-24T14:05:44 http://comments.gmane.org/gmane.ietf.nntp/3748 <pre>Hi all, The draft specifying the COUNTS, DISTRIBUTIONS, MODERATORS, MOTD, and SUBSCRIPTIONS variants to the LIST command, as well as additional 'j', 'x' and '=' status for a newsgroup, is currently in Last Call. If you have any comments, do not hesitate to tell before July, 16th 2010. Thanks, </pre> Julien ÉLIE 2010-06-24T13:44:07 http://comments.gmane.org/gmane.ietf.nntp/3746 <pre>Hi all, For OVER: If the information is available, it is returned as a multi-line data block following the 224 response code and contains one line per article, sorted in numerical order of article number. For HDR: 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. The notion of numerical order is not present in RFC 3977 for HDR. Is it normal? Is it then allowed (and expected by clients) to send HDR answers in a random order? </pre> Julien ÉLIE 2010-05-21T12:56:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.nntp