headers
Julien ÉLIE | 14 May 2012 23:41
Favicon

[NNTP] Errata 1707 and 1527 for RFC 3977

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 proposed standard to draft standard?

http://www.rfc-editor.org/errata_search.php?eid=1527

The new wording is better than what was originally suggested as
erratum.  **It fixes exactly the same issue.**
You can see that the current erratum about section 3.2.1 deals with
MODE-READER.  It appeared after discussing with Russ and Clive that
it was better to change section 3.4.2 (mine was just a remark
(Continue reading)

Permalink | Reply | 5 comments |
headers
Charles Lindsey | 14 May 2012 12:00
Picon
Picon

Re: [NNTP] Babble from Russ Allbery <rra <at> stanford.edu>

Russ Allbery <rra <at> stanford.edu> writes:

>Yes, please.  We would clearly want to fix this in any revision of RFC
>3977.  Personally, I would recommend that any implementor use 423 as
>described in Julien's analysis despite the wording of RFC 3977.

Yes, but a revision is unlikely in the foreseeeable future. Is there any
mechanism whereby a NOTE can be added as an erratum pointing out that
"With hindsight it might have been better to ..., and this should be
revisited in any revision of this document"? As least that would alert
people to the issue and hint that they might want to reconsider how to
cope with it in their implementation.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131            Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> 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
Permalink | Reply | 0 comments |
headers
Julien ÉLIE | 13 May 2012 21:17
Favicon

Re: [NNTP] [Errata Rejected] RFC3977 (2004)

Dear Barry Leiba,

I have just been aware that erratum 2004 was rejected.
Yet, I do not understand why.

> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3977&eid=2004
> --------------------------------------
> Status: Rejected
> Type: Technical
>
> Reported by: Julien Élie
> Date Reported: 2010-01-14
> Rejected by: Barry Leiba (IESG)

The given reason is:

> --VERIFIER NOTES-- Section 6.2.1.2 paragraph 6 says "a previously
> valid article number MAY become invalid if the article has been
> removed". Therefore the correct response in the situation being
> addressed would be 420, not 423.
>
> This could be a case that might be considered if the document is
> updated, but certainly it's not a simple error in the document.

We are not speaking about the situation you mention.  There is a 
difference between valid/invalid article numbers and valid/invalid 
*current* article numbers.
Section 6.2.1.2 speaks about valid/invalid article numbers, and in this
(Continue reading)

Permalink | Reply | 6 comments |
headers
River Tarnell | 7 Jan 2012 19:56

[NNTP] Command to list wanted groups for transit peers

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:  <at> alt.sex.*
S:  <at> *.bina*
S: de.bina*
S: !uk.test
S: .
C: CHECK <...

This would be an "extended" wildmat like INN uses; I don't think  <at>  is 
available in the RFC 3977 wildmats.

Thoughts?
(Continue reading)

Permalink | Reply | 1 comment |
headers
River Tarnell | 7 Jan 2012 18:14

[NNTP] Advertise maximum article size in CAPABILITIES


(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 <nbytes>" 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 yet; 
I'm happy to do that and write an I-D/RFC for it myself if it seems like 
a good idea.

Regards,
--

-- 
        -- river.                      | Free Usenet: http://news.rt.uk.eu.org/
Non-Reciprocal Laws of Expectations:   | PGP: 2B9CE6F2
    Negative expectations yield negative results.
(Continue reading)

Permalink | Reply | 2 comments |
headers
River Tarnell | 2 Jan 2012 03:10

[NNTP] Interesting server behaviour

(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.

--

-- 
        -- river.                      | Free Usenet: http://news.rt.uk.eu.org/
Non-Reciprocal Laws of Expectations:   | PGP: 2B9CE6F2
    Negative expectations yield negative results.
    Positive expectations yield negative results.
Permalink | Reply | 5 comments |
headers
Fabian | 9 Nov 2011 18:12
Picon

[NNTP] References Command

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 <msgid>', 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 <msgid>', 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?
Permalink | Reply | 1 comment |
headers
Sabahattin Gucukoglu | 1 May 2011 21:32

[NNTP] Article Reinstatement, Was Article Numbers Becoming Invalid (RFC 3977)

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.  The client updates its counters to indicate that article 5 was the last
article seen.  Article 1 is replaced.  Client connects, server indicates min=1 max=5 no=5.  How is the
client to ensure the retrieval of article 1?  The low watermark may certainly indicate its presence, but it
can hardly assume that an article was reinstated simply because on this occasion min=1 is the smallest
value seen; the article numbered 1 may already have been fetched under normal conditions, or the
heuristic will not work at all if group expiration on criteria other than number of articles has occurred,
for instance.

Does anybody have any ideas?

Cheers,
Sabahattin
Permalink | Reply | 7 comments |
headers
Julien ÉLIE | 15 Feb 2011 20:56
Favicon

[NNTP] Suggestion of examples for 412 semantics in RFC 3977

Just a few examples that could be added to RFC 3977.

Following a discussion with Alfred Hönes, who reported:

> (iv)  particulars of the 412 semantics
> 
> The LISTGROUP Usage (Section 6.1.2.1, on page 39) contains the note:
> 
>     [1] The 412 response can only occur if no group has been specified.
> 
> The LISTGROUP Description (Section 6.1.2.2, on mid-page 40) says:
> 
>     The LISTGROUP command selects a newsgroup in the same manner as the
>     GROUP command (see Section 6.1.1) but also provides a list of article
>     numbers in the newsgroup.  If no group is specified, the currently
>     selected newsgroup is used.
> 
> |  If the group specified is not available on the server, a 411 response
> |  MUST be returned.  If no group is specified and the currently
> |  selected newsgroup is invalid, a 412 response MUST be returned.
> 
> The second paragraph quoted could be interpreted to say, using the
> notation proposed above:
> 
>     If the group specified is not available on the server, a 411 response
> |  MUST be returned.  If no group is specified and the currently
> |  selected newsgroup is `invalid`, a 412 response MUST be returned.
> 
> And in this interpretation, it would have to be presumed that when
> (no group is specified and) the "currently selected newsgroup" has
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien ÉLIE | 15 Feb 2011 20:47
Favicon

[NNTP] Consistency in replies to 420 in RFC 3977

Following a discussion with Alfred Hönes, who reported:

> Appendix C, on page 119, says:
> 
>     Response code 412
>        Generated by: ARTICLE, BODY, GROUP, HDR, HEAD, LAST, LISTGROUP,
>        NEXT, OVER, STAT
>        Meaning: no newsgroup selected.
> 
>     Response code 420
>        Generated by: ARTICLE, BODY, HDR, HEAD, LAST, NEXT, OVER, STAT
>        Meaning: current article number is invalid.
> 
> Please be aware of the different wording used:
>        "no newsgroup selected" vs. "current article number is invalid"
> 
> These two phrases, respectively, are used in a totally consistent way,
> throughout the RFC, in the specification of possible command responses
> when it comes to referring to these two response codes.
>
> The text, "no newsgroup selected", also appears in all examples
> where response code 412 is returned by the server.
> 
> Interestingly enough, all examples in the RFC where the response
> code 420 is returned by the server consistently do *not* use the
> above quoted phrase from Appendix C, but instead say:
> 
>        [S] 420 No current article selected

Well seen :-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julien ÉLIE | 15 Feb 2011 20:45
Favicon

[NNTP] Clarification of intra-document references in RFC 3977

Following a discussion with Alfred Hönes, who reported:

 > clarification of intra-document ref.
 >
 > Within Section 2 of RFC 3977, the first paragraph on page 6 says:
 >
 >                       [...].  In some cases, however, they do assume that
 >     the currently selected newsgroup (see the GROUP command,
 >     Section 6.1.1) is invalid; when so, this is indicated at the start of
 >     the example.  [...]
 >
 > The "currently selected newsgroup" is introduced in Section 6.1 (see
 > next quotation below); as such, the clause therein,
 >
 >        (see the GROUP command, Section 6.1.1)
 >
 > should more appropriately have been replaced by:
 >
 >        (see Section 6.1)
 > or:
 >        (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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane