headers
Russ Allbery | 1 Apr 2002 03:28
Picon
Favicon
Gravatar

ietf-nntp POST SHOULD return an accurate response

I'm currently reviewing -15 against my saved notes and will hopefully have
a new set of open issues available shortly, along with my promised but
much-delayed new text for HDR (which remains a right mess, and didn't get
any cleaner from looking at it with new eyes, unfortunately).

This bit was buried in other threads and doesn't seem to have made it into
-15, but I also didn't see any additional responses to it.  Given that,
I'm reproposing it; please let me know if there's some reason you object
to this text.

With IHAVE, generally the other server doesn't particularly care whether
or not the article was posted, but with POST, it's actually important to
let the client know that the article is invalid.  The exception is
generally only for dealing with spam, where the intention is to make the
server be deceptive to try to fool a spammer.

This sounds like a textbook example of a case where SHOULD is the
appropriate term, since there are reasons why a server may not want to
follow the constraint.  I propose adding to the end of the third
paragraph of 9.3.1 after:

    Note that response codes 340 and 440 are used in direct response to
    the POST command. Others are returned following the sending of the
    article.

the following new text (perhaps as a separate paragraph):

    A response of 240 SHOULD indicate that barring unforseen server errors
    the posted article will be made available on the server and/or
    transferred to other servers as appropriate.  In other words, articles
(Continue reading)

Permalink | Reply | 1 comment |
headers
Russ Allbery | 1 Apr 2002 03:38
Picon
Favicon
Gravatar

Re: ietf-nntp 221 response

Clive D W Feather <clive <at> demon.net> writes:

> I've just noticed that the 221 response has two different formats.
> For HEAD, it has two parameters and is followed by the header of a single
> article.

> For HDR, it has no parameters and is followed by a list of number+text
> pairs.

> Because of this inconsistency (which breaks the last paragraph of page 6)
> and because HDR is a new invention of our own, can we please change its
> success response to 225 ?

I second this.  Since it's a new command, now's the time to make these
changes.  Let's not create another wart like the GROUP/LISTGROUP conflict.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Apr 2002 03:40
Picon
Favicon
Gravatar

Re: ietf-nntp Initial connection examples

I also agree with this proposed rewording.  I find it easier to
understand.

Clive D W Feather <clive <at> demon.net> writes:

> I found this section very hard to read, especially since there are no
> blank lines in it. Can I propose a rewording:

>   7.1.2  Initial Connection Example

>      Example of a normal connection from an authorized client
>      which then jumps directly to the conclusion step (see section 10):

>           [Initial TCP connection setup completed.]
>           [S] 200 NNTP Service Ready, posting permitted
>           [C] QUIT
>           [S] 205 NNTP Service exits normally
>           [Server closes connection.]

>      Example of a normal connection from an authorized client that
>      is not permitted to post; it also jumps directly to the conclusion
>      step:

>           [Initial TCP connection setup completed.]
>           [S] 201 NNTP Service Ready, posting prohibited
>           [C] QUIT
>           [S] 205 NNTP Service exits normally
>           [Server closes connection.]

>      Example of a connection from an unauthorized client
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Apr 2002 03:45
Picon
Favicon
Gravatar

Re: ietf-nntp Command description layout

Clive D W Feather <clive <at> demon.net> writes:

> I think it would aid the eventual user of this document if there was a
> slightly more formal structure. What I'm thinking of is that every
> command has three numbered subsections:

As someone who's looking at the prospects of needing to write up a bunch
of command descriptions for all of the extensions that INN implements at
present, I think a more formal structure is an excellent idea.  I'd love
to have a standard layout for describing NNTP commands that can be used
for all subsequent extensions.

I only have one problem to point out:

>     X.1 Description
>         Gives an informal description of the command and its specific
>         responses. Certain specifics would be deferred to X.2.
>     X.2 Usage
>         Gives the formal syntax, lists all the responses, defines the
>         meaning of any parameters for both command and response, and
>         notes when the command is not streamable.

I think it would make it unnecessarily hard to write the description if
one couldn't easily reference the parameters of the command (since that
was deferred to the Usage section).  Perhaps it would be better to put the
Usage section first?  It's fairly short and provides a decent summary of
what's going on, and that way the description could reference all of the
details of the usage.

This (usage first, including responses, then description, then examples)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Apr 2002 03:48
Picon
Favicon
Gravatar

Re: ietf-nntp Additional arguments

Clive D W Feather <clive <at> demon.net> writes:

> Section 4 reads in part:
>     Commands ... MAY be followed by one or more arguments.

> Is it permitted, or is it an error, to provide more arguments than required
> by the command ? For example, given:

>     GROUP misc.test demon.service

> which of the following applies ?

> (1) The server MUST give the 501 syntax error generic response.

I think the server MUST reject such commands with a syntax error.  Even if
that's not existing practice for AUTHINFO, I think it's very much worth
doing.  It's *mostly* existing practice, enough so that I highly doubt
there are any clients relying on the other behavior, and I think we should
clearly pick one approach.

> I would think that (1) applies, but I can find no wording to say so. If
> people agree, the best place to do this would be section 4.1.1:

>     If there is a syntax error in the arguments of a recognised
> !   command, including the case where more arguments are provided
> !   than the command specifies,
>     the response code 501 MUST be returned.

I agree with this change.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Apr 2002 03:49
Picon
Favicon
Gravatar

Re: ietf-nntp Generic responses

Clive D W Feather <clive <at> demon.net> writes:

> Looking again at the generic responses, it strikes me that almost all of
> them can occur for any command. It would therefore be best if clients
> were prepared for this.

> Therefore I suggest we add the following paragraph to 4.1.1:

>     With the exception of 500 for mandatory commands, the client MUST
>     be prepared to receive these responses for any command.

That sounds like a good idea to me.

> If we do this, do we need to list the generic responses as part of each
> command's description ?

This may obviate the need for the separate listing of generic responses
for each command, which would be a good thing just in terms of reducing
the amount of detail that can be accidentally transcribed wrong or be
missed in proofreading.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Apr 2002 03:51
Picon
Favicon
Gravatar

Re: ietf-nntp POST/IHAVE

Clive D W Feather <clive <at> demon.net> writes:

> The last three paragraphs of 9.3.2 (IHAVE) really apply to both
> commands.  Should they move to the general section (9.3) ? Some
> rewording would be necessary.

I don't agree that they do.  See my other separate proposal for wording to
add to the POST command.  In particular, while it's normal for servers to
give successful responses to the IHAVE command and then later throw away
the article, this is a SHOULD NOT for POST because that information is
rather important to a posting client (whereas a peer news server almost
certainly doesn't care).

So the only paragraph that's actually mostly common is the bit about not
assuming that the article was successfully transferred unless one receives
an affirmative response, and with POST there are some additional
considerations that should be taken into account there.

--

-- 
Russ Allbery (rra <at> stanford.edu)             <http://www.eyrie.org/~eagle/>
_______________________________________________
ietf-nntp mailing list
ietf-nntp <at> academ.com
https://www.academ.com/mailman/listinfo/ietf-nntp
Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Apr 2002 03:59
Picon
Favicon
Gravatar

Re: ietf-nntp Mandatory and optional commands

Clive D W Feather <clive <at> demon.net> writes:

> I am under the impression that all commands in draft15, except those in
> the extensions (section 9.5) are mandatory. Is that correct ?

No.  Many of the LIST commands need not be implemented; in particular, all
of LIST {ACTIVE.TIMES,DISTRIBUTIONS,NEWSGROUPS,DISTRIB.PATS} are optional
and can return 501.

> LIST EXTENSIONS has a 500 response listed. That is surely wrong, even if
> the command isn't provided. Or is it intended ?

500 is incorrect.  The correct error response if LIST EXTENSIONS isn't
provided is 501.  The following changes should be made to 8.1.1:

Remove "500  Unknown command" from the table of responses.

Remove "a 500 (unknown command) or" from the text of that paragraph.

> Some LIST sub-commands, such as LIST ACTIVE.TIMES, need not return valid
> data if the server doesn't maintain it. This is what the 403 and 503
> responses are for, right ? Or do we really intend to allow 501 for this ?

501 is existing practice.  It's actually a form of extension mechanism,
albeit not a very good one, but it's been in NNTP for a while.  Basically,
you can tack on additional LIST FOO commands all you want and let clients
just try them, and your error if they don't work is 501.  This works
fairly well with existing servers that don't understand your commands.

INN supports a number of additional LIST commands not mentioned in the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Apr 2002 04:28
Picon
Favicon
Gravatar

Re: ietf-nntp 502 response

Andrew Gierth <andrew <at> erlenstar.demon.co.uk> writes:
>>>>>> "Clive" == Clive D W Feather <clive <at> demon.net> writes:

>  >>>> on connect, or after a failed AUTHINFO exchange, nowhere else.
> 
>  Clive> Is that your server, or can you really speak for all common
>  Clive> servers ?
> 
> I have checked INN and the Diablo reader in addition to my own server.
> I can't speak for Typhoon or DNews (one known issue with Typhoon is
> that it does not close the connection after a 502 response to AUTHINFO)

INN returns 502 in response to ARTICLE (including HEAD, BODY, and STAT)
when retrieving by message ID if the article is in a newsgroup that the
client doesn't have permission to read.  It also returns 502 to the
ARTICLE, HEAD, BODY, STAT, NEXT, LAST, XOVER, XPAT, and XHDR commands if
the client doesn't have permission to read articles.

>  Clive> Hmm. We've documented 503 as "I don't support this and I don't
>  Clive> plan to".

> RFC 977 defined 503 as "program fault - command not performed". INN
> returns it for a number of unexpected error conditions (failure to
> initialise the storage manager, failure to execute the external
> authenticator, failure of some of the LIST commands due to missing
> files, etc.)

The current description of 502 looks correct to me.

I believe the following changes should be made to clarify when 502 is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russ Allbery | 1 Apr 2002 05:05
Picon
Favicon
Gravatar

Re: ietf-nntp Re: OVER extension

I agree with this proposed OVER text and would like to see it adopted,
with the caveats noted below:

Clive D W Feather <clive <at> demon.net> writes:

> (1) Allow (but don't require) a server to treat lone LF as CRLF.

Ugh, no.  Pick one or the other, but whatever we do, we cannot offer the
server a choice.  The goal is to get to the point where, for a given
article, every conforming server will produce exactly the same overview
information.

I see no reason for special treatment of a lone LF, so I prefer the text
without this change.  I'm not strongly opposed to mandating special
treatment of lone LF, although I don't see much point.  I am strongly
opposed to offering the implementor a choice.

> (2) In LIST OVERVIEW.FMT, choose between "Bytes:", "Bytes", or either
>     with the latter preferred [and ditto "Lines".]

Andrew argued that LIST OVERVIEW.FMT should be able to return exactly the
same as it currently does.  I don't consider the command useful enough to
warrant fiddling with it when there's a possibility that it could confuse
existing clients (and leaving off a syntactic element is the sort of
change that I could see doing that, for a poorly written client).

> There was a suggestion that OVER could take a message-ID. This would
> need to be optional; to allow it, include the lines prefixed with $,
> while to forbid it exclude those lines.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane