gmane.ietf.nntp

Re: [NNTP] Advertise maximum article size in CAPABILITIES

Julien ÉLIE — 2012-12-09T14:06:35

Hi River,


I also believe it is a good idea.
Other kinds of parameters related to a feed should be taken care of
at the same time (for instance contents of Distribution: headers, 
minimal article size, maximum number of newsgroups in crosspost...). 
Maybe the feed-related parameters known by innfeed.conf, newsfeeds and 
cleanfeed could be a good start.

Re: [NNTP] Command to list wanted groups for transit peers

Julien ÉLIE — 2012-12-09T13:59:08

Hi River,

I do not know whether you have advanced a bit on that topic since last year.
Anyway, here are a few links...



Though not the same, but could be used in a similar way, a draft
for Dynamic Feed Adjustment was published a decade ago:
    http://www.eyrie.org/~eagle/nntp/drafts/draft-court-dynfeed-01.txt



It would also need adding the maximum article size or things like that,
possibly related to each line returned by the command.



It could also be a new keyword to the LIST command.

In case it could help, here is a thread we had in December 2009
in news.software.nntp:

    https://groups.google.com/forum/?hl=fr&fromgroups=#!topic/news.software.nntp/fgX4tUk0tGM

"Proposal for a standardized LIST MOTD command"
Message-ID: <he74ps$58i$1< at >news.trigofacile.com>
Message-ID: <hh4vs5$o2$1< at >speranza.aioe.org>
...



[Paolo Amori]
LIST MOTD (without argument)

should/must include several data about the server (ie. Tech Contact, Legal 
Contact (the was requested me by the italian police: how can i find the o

Re: [NNTP] Errata 1707 and 1527 for RFC 3977

Julien ÉLIE — 2012-05-15T21:35:31

Hi Barry,


Many thanks to you!
And sorry for pushing a bit to hard...



Thanks !



OK, I understand that the status should remain the same.
My concern was that we found out the wording to use for Section 3.4.2 
and two examples for Section 5.3.3 so as to fix the issue, and I do not 
know how not to lose the work done.  (No need to do the work twice, 
especially when the exact update is already known.)

Re: [NNTP] Interoperability with 502 answer to GROUP command

Julien ÉLIE — 2012-05-15T21:27:02

Hi Clive,


Understood, and agreed.  Many thanks for your answer.
It is up to the implementation to decide how it wants to handle the case.

Re: [NNTP] Interoperability with 502 answer to GROUP command

Russ Allbery — 2012-05-15T17:00:10



No, you can't; see RFC 4643:

   After a successful authentication, the client MUST NOT issue another
   AUTHINFO command in the same session.  A server MUST NOT return the
   AUTHINFO capability in response to a CAPABILITIES command, and a
   server MUST reject any subsequent AUTHINFO commands with a 502
   response.

After you've authenticated, if you still can't read the group but the
group is not hidden, "permission denied" is the correct error code so far
as I can see.

Re: [NNTP] Errata 1707 and 1527 for RFC 3977

Barry Leiba — 2012-05-15T16:34:42

Well, I've been trying to address "reported" errata that haven't been
classified, not trying to spin up more work.  :-)  But still....


I have asked the RFC Editor to help me with this, off list.  We'll get
it sorted out.


No, I'm afraid this isn't what errata are for.  The IESG reserves
"Verified" for this:

1. The report is correct, AND
2. the error would have been considered an error in the original
document, had it been noticed then (that is, this didn't come up
because things have changed since then, or "we don't really do it that
way in practice"), AND
3. implementors or deployers MUST see the correction, or they will
face implementation/deployment problems.

See the IESG statement on errata handling for more information:
http://www.ietf.org/iesg/statement/errata-processing.html

This one appears to be exactly what "held for document update" is for:
It's flagged for review if/when the document is ever updated or
advanced on the standards track.  That seems to be just what you want
anyway, so there's

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

Clive D.W. Feather — 2012-05-15T13:08:02

Barry Leiba said:

To be honest, I'd forgotten that earlier discussion.


I think we've all now agreed this is the right approach.

Re: [NNTP] Errata 1522 and 2719 for RFC 3977

Clive D.W. Feather — 2012-05-15T12:41:26

Barry Leiba said:

Okay.

Re: [NNTP] Errata 1522 and 2719 for RFC 3977

Barry Leiba — 2012-05-15T12:38:01

Hi, Clive.


See the IESG statement on processing of errata:
https://www.ietf.org/iesg/statement/errata-processing.html

In particular:


...and...


So Lisa and Peter, respectively, were correct in their handling of those two.

Barry

[NNTP] Errata 1522 and 2719 for RFC 3977

Clive D.W. Feather — 2012-05-15T12:04:14

I'm not clear why these are Held for Document Update - they should be
Verified.

Re: [NNTP] Interoperability with 502 answer to GROUP command

Clive D.W. Feather — 2012-05-15T11:07:42

Julien LIE said:

Hi,

Found this while looking into the errata.


That's for a *command*, not for a specific set of parameters.


Whether you list group.auth[12] depends on whether you want to publish the
fact of existence to people who don't have authority to read it. There
isn't a "right" answer.


Correct.


Fine.


No, this should be another 480. After all, in principle you could
reauthenticate as user2.


If you want to hide the presence of group.auth2 entirely from people who
don't have access to it, you could use a 411. But then why did you return
480 to group.auth1?

You need to decide one of:
(1) People can know about groups they don't have access to. They appear
in LIST ACTIVE. You return 480 to any attempt to get at the group with
authority.
(2) People can't know about groups they don't have access to. They don't
appear in LIST ACTIVE and you return 411 to attempts to get them. The user
has to know that she needs to authenticate and they will magically appear.
(3) Any mix of the above.

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

Alice Russo — 2012-05-14T13:15:59

Barry,

The status has been changed as requested:
http://www.rfc-editor.org/errata_search.php?eid=2004

Thank you.
RFC Editor/ar

On May 14, 2012, at 7:26 AM, Barry Leiba wrote:

[NNTP] Errata 1707 and 1527 for RFC 3977

Julien ÉLIE — 2012-05-14T21:41:35

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

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

Julien ÉLIE — 2012-05-14T21:28:39

Hi all,

[Russ]

[Barry]

[Alice]

And also [Clive] of course, thanks to all of you!
The "hold for document update" status is pretty fine.



[Charles]

I do not believe such a mechanism exists.  Unfortunately.
One has to go to the HTML version of the IETF site:
     http://tools.ietf.org/html/rfc3977
and pay attention to the two red words "Errata Exist".  Then, carefully 
read through all the submitted errata.

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

Barry Leiba — 2012-05-14T11:26:02

OK, that works for me.

RFC Editor, will you please switch errata #2004 from "rejected" to
"hold for document update"?  Thanks.

Barry

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

Charles Lindsey — 2012-05-14T10:00:17


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.

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

Russ Allbery — 2012-05-14T00:09:08


I reluctantly agree.  I believe this is quite obviously an error in RFC
3977, but RFC 3977 is also quite explicit that 423 is not a permissible
response code for ARTICLE without an argument.  My understanding is that
errata can't be used to correct the clear statement of the specification,
even if that clear statement is wrong based on existing deployed code and
consistency of semantics through the specification.


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.

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

Barry Leiba — 2012-05-13T22:16:40

Well, the response in the rejection reason is taken directly from an
exchange I had with Clive.  Now, he did also suggest that I might pass
it by Russ Allbery, which I have not yet done.  Since he's copied on
this exchange, he can comment.  Clive's point wasn't meant to say that
your suggestion in the errata report wasn't good, but that it's not
bringing up an *error* in the original spec.  If what you suggest is
an appropriate change, it might be considered if there's work done to
revise the document.

I'd be happy, if Clive, Russ, and Julien all think it's the right
approach, to change the erratum to "hold for document update".  Russ
Allbery, do you have a comment on this?

Barry Leiba, Applications Area Director

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

Julien ÉLIE — 2012-05-13T19:17:24

Dear Barry Leiba,

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




The given reason is:


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 
situation, we are in the *second* form (article number specified) of the 
ARTICLE command.  The possible answers are:

    Second form (article number specified)
      220 n message-id      Article follows (multi-line)
      412                   No newsgroup selected
      423                   No article with that number

The 423 response code is therefore sent here, for the second form.

In Section 6.2.1.3:

    Example of an unsuccessful retrieval of an article by number:

       [C] GROUP misc.test
       [S] 211 1234 3000234 3002322 news.groups
       [C] ARTICLE 300256
       [S] 423 No article with that number




The erratum I filled is rela

[NNTP] Command to list wanted groups for transit peers

River Tarnell — 2012-01-07T18:56:11

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?

Regards,

Re: [NNTP] Advertise maximum article size in CAPABILITIES

Russ Allbery — 2012-01-07T17:21:57


Gah.  Yes.  I'm sorry.  This is fixed now.  I was looking in the wrong
place in the list configuration.

I'e just removed all the restrictions on MIME types.  There shouldn't be
any need for that.


I like this idea.