headers
Julien ÉLIE | 17 Nov 2009 20:12
Favicon

[NNTP] Additions to LIST commands

Hi,

I have just posted the following proposal for:

    * LIST DISTRIBUTIONS
    * LIST MODERATORS
    * LIST MOTD
    * LIST SUBSCRIPTIONS
    * new status for newsgroups returned by LIST ACTIVE

Comments are welcome!

Especially on:

    * how to advertise the meaning of new status;
    * how to write an extension of RFC 3977 without defining
      a new capability;
    * how to deal with the fact that RFC 3696 limits the local part
      of an e-mail address to 64 characters whereas USEAGE mentions
      that a newsgroup name is limited to 66 characters (therefore,
      what for the submission address of a moderated newsgroup whose
      length is 66 characters?).

Follow up on either the NNTP mailing-list or the USEFOR mailing-list,
depending on the subject you want to tackle.

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
(Continue reading)

Permalink | Reply | 25 comments |
headers
Antti-Juhani Kaijanaho | 17 Nov 2009 20:51
Picon

Re: [NNTP] Additions to LIST commands

On Tue, Nov 17, 2009 at 08:12:27PM +0100, Julien ÉLIE wrote:
> Comments are welcome!

    "j"  Articles are filed under the "junk" newsgroup.

Is there any reason to constrain the implementation so much?  It seems to me
that "j" could easily be implemented as "accept posts but do not file them",
without the use of, or existence of, a "junk" newsgroup.   Would that break
existing clients, or common usage? 

--

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/
Permalink | Reply | 9 comments |
headers
Russ Allbery | 17 Nov 2009 20:57
Picon
Favicon
Gravatar

Re: [NNTP] Additions to LIST commands

Antti-Juhani Kaijanaho <antti-juhani <at> kaijanaho.fi> writes:
> On Tue, Nov 17, 2009 at 08:12:27PM +0100, Julien ÉLIE wrote:

>> Comments are welcome!

>     "j"  Articles are filed under the "junk" newsgroup.

> Is there any reason to constrain the implementation so much?  It seems to me
> that "j" could easily be implemented as "accept posts but do not file them",
> without the use of, or existence of, a "junk" newsgroup.   Would that break
> existing clients, or common usage? 

The junk group is sometimes readable and sometimes not.  There is the
problem that if you want it to be readable, j currently tells the client
where the article can be found, whereas if it's not filed at all or in
some other newsgroup, the client can't find it that way.  But I think the
idea of reading the junk group via a regular GROUP junk command is a bit
dubious.  I'm not sure how many people would do that.

Currently in the INN implementation, j is roughly equivalent to =junk.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
Permalink | Reply | 6 comments |
headers
Julien ÉLIE | 17 Nov 2009 21:20
Favicon

Re: [NNTP] Additions to LIST commands

Hi Russ,

> But I think the
> idea of reading the junk group via a regular GROUP junk command is a bit
> dubious.  I'm not sure how many people would do that.

At least on fr.*, a few people like to add "Followup-To: junk" on certain
occasions; and read (and sometimes respond) to answers which kept that
follow up.

> Currently in the INN implementation, j is roughly equivalent to =junk.

"roughly" :)

As I wrote in news.software.nntp, if:

 - group1 is status "j",
 - group2 is status "=junk",
 - group3 is status "y",

then :

 * a local post to group1 only will be accepted (and filed into "junk")
   whereas a local post to group2 only will not be accepted;

 * a crosspost to group1,group3 will be filed into only group3 whereas
   a crosspost to group2,group3 will be rejected if it is a local post
   and filed into "junk" and group3 if it comes from a peer.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Antti-Juhani Kaijanaho | 17 Nov 2009 21:33
Picon

Re: [NNTP] Additions to LIST commands

On Tue, Nov 17, 2009 at 11:57:18AM -0800, Russ Allbery wrote:
> The junk group is sometimes readable and sometimes not.  There is the
> problem that if you want it to be readable, j currently tells the client
> where the article can be found, whereas if it's not filed at all or in
> some other newsgroup, the client can't find it that way.  But I think the
> idea of reading the junk group via a regular GROUP junk command is a bit
> dubious.  I'm not sure how many people would do that.

Sounds like a SHOULD, or even a MAY.  Certainly, the relation to the junk group
should be documented.

--

-- 
Antti-Juhani Kaijanaho, Jyväskylä, Finland
http://antti-juhani.kaijanaho.fi/newblog/
http://www.flickr.com/photos/antti-juhani/
Permalink | Reply | 4 comments |
headers
Julien ÉLIE | 17 Nov 2009 21:42
Favicon

Re: [NNTP] Additions to LIST commands

Hu Antti-Juhani,

>    "j"  Articles are filed under the "junk" newsgroup.
>
> Is there any reason to constrain the implementation so much?

I just documented what INN has always done.
Diablo and C News, to cite only them, do not use "j".

> It seems to me
> that "j" could easily be implemented as "accept posts but do not file them",
> without the use of, or existence of, a "junk" newsgroup.   Would that break
> existing clients, or common usage?

So your suggestion is to decorrelate "j" with the existence of anything
else?  I believe it is fine to do that (and what the post become is
an implementation issue -- either it is stored nowhere or somewhere,
like the junk newsgroup).

--

-- 
Julien ÉLIE

« I don't know if it's what you want, but it's what you get. » (Larry Wall)
Permalink | Reply | 1 comment |
headers
Julien ÉLIE | 17 Nov 2009 21:46
Favicon

Re: [NNTP] Additions to LIST commands

Hi Antti-Juhani,

> On Tue, Nov 17, 2009 at 11:57:18AM -0800, Russ Allbery wrote:
>> The junk group is sometimes readable and sometimes not.  There is the
>> problem that if you want it to be readable, j currently tells the client
>> where the article can be found, whereas if it's not filed at all or in
>> some other newsgroup, the client can't find it that way.  But I think the
>> idea of reading the junk group via a regular GROUP junk command is a bit
>> dubious.  I'm not sure how many people would do that.
>
> Sounds like a SHOULD, or even a MAY.  Certainly, the relation to the junk group
> should be documented.

What do you want to document exactly?
What should be a SHOULD?

Isn't the note I put in the Internet-Draft what you were looking for?
Isn't it clear enough?  (If no, what should be changed?)

      NOTE:  The status "j" is used only by news servers on which the
      newsgroup "junk" exists.  This group has special meaning.  It
      usually contains all the postings which cannot file under a
      newsgroup name.  Instead of rejecting an article which contains an
      invalid Newsgroups header or which is posted to newsgroups it does
      not carry, a news server may accept such an article and file it
      under a generic newsgroup named "junk".  This newsgroup may be
      available to news readers and is often used by a news server as a
      way to locally store an article with the view to transmitting it
      to its peers (which may carry some of the newsgroups the article
      was posted to).
(Continue reading)

Permalink | Reply | 3 comments |
headers
Russ Allbery | 18 Nov 2009 02:27
Picon
Favicon
Gravatar

Re: [NNTP] Additions to LIST commands

Julien ÉLIE <julien <at> trigofacile.com> writes:

> I have just posted the following proposal for:

>    * LIST DISTRIBUTIONS
>    * LIST MODERATORS
>    * LIST MOTD
>    * LIST SUBSCRIPTIONS
>    * new status for newsgroups returned by LIST ACTIVE

> Comments are welcome!

> Especially on:

>    * how to advertise the meaning of new status;
>    * how to write an extension of RFC 3977 without defining
>      a new capability;
>    * how to deal with the fact that RFC 3696 limits the local part
>      of an e-mail address to 64 characters whereas USEAGE mentions
>      that a newsgroup name is limited to 66 characters (therefore,
>      what for the submission address of a moderated newsgroup whose
>      length is 66 characters?).

This looks very good.  A few comments:

      NOTE:  Periods are changed to dashes, and dashes are left alone.
      It implies that two moderated newsgroups whose names differ only
      by changing a period to a dash would go to the same address.
      Therefore, such moderated newsgroup pairs SHOULD NOT be created on
      a news server.
(Continue reading)

Permalink | Reply | 14 comments |
headers
Jeffrey M. Vinocur | 18 Nov 2009 04:01

Re: [NNTP] Additions to LIST commands

On Tue, 17 Nov 2009, Russ Allbery wrote:

> Julien ÉLIE <julien <at> trigofacile.com> writes:
> 
> >    * how to write an extension of RFC 3977 without defining
> >      a new capability;
> 
> For the new LIST ACTIVE flags, no CAPABILITIES line should be required,
> since the client doesn't need to know whether or not the server might send
> these flags before the server sends them.  That was intentional in how we
> defined LIST ACTIVE in RFC 3977:
> 
>    Other values for the status may exist; the definition of these other
>    values and the circumstances under which they are returned may be
>    specified in an extension or may be private to the server.  A client
>    SHOULD treat an unrecognized status as giving no information.

Although, what if there are two separate specifications that define a 
given flag differently?  In that case, the client will not know which 
meaning the server intends.

So perhaps it's worth having the server advertise what addon 
specifications it implements?

--

-- 
Jeffrey M. Vinocur
jeff <at> litech.org
Permalink | Reply | 1 comment |
headers
Russ Allbery | 18 Nov 2009 04:04
Picon
Favicon
Gravatar

Re: [NNTP] Additions to LIST commands

"Jeffrey M. Vinocur" <jeff <at> litech.org> writes:
> On Tue, 17 Nov 2009, Russ Allbery wrote:

>> For the new LIST ACTIVE flags, no CAPABILITIES line should be required,
>> since the client doesn't need to know whether or not the server might
>> send these flags before the server sends them.  That was intentional in
>> how we defined LIST ACTIVE in RFC 3977:

>>    Other values for the status may exist; the definition of these other
>>    values and the circumstances under which they are returned may be
>>    specified in an extension or may be private to the server.  A client
>>    SHOULD treat an unrecognized status as giving no information.

> Although, what if there are two separate specifications that define a 
> given flag differently?  In that case, the client will not know which 
> meaning the server intends.

> So perhaps it's worth having the server advertise what addon 
> specifications it implements?

Hm, yeah, that's true, but it feels like it's rather unlikely that anyone
is going to implement those flags in a way substantially different than
INN did, since they've been around forever with basically the same
meaning.  If there were existing use with different meanings, we'd need
something to clarify what the meanings are, but I think any time you see
them they're going to have basically the same meaning.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane