Subject: [NNTP] DATE: reader or general command

From: Ken Murchison <[email-masked]>
Date: Wed, 01 Dec 2004 13:32:25 -0500

The current pre-drafts have the DATE command listed as a reader command,
presumably because its typically used with NEWNEWS.  However, since the
command is fairly benign and may have alternative uses in the future,
wouldn't it make more sense to label it as a general command?

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Russ Allbery <[email-masked]>
Date: Wed, 01 Dec 2004 11:40:38 -0800

> wouldn't it make more sense to label it as a general command?

I think this is just an artifact of following existing practice; in INN,
DATE is a reader-only command.  I don't particularly care one way or the
other; it's simple enough to add DATE to innd, but I also can't think of a
reason why a peer would care to use it.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: "Andrew - Supernews" <[email-masked]>
Date: Wed, 01 Dec 2004 23:19:34 +0000

>>>>> "Ken" == Ken Murchison <[email-masked]> writes:

 Ken> The current pre-drafts have the DATE command listed as a reader
 Ken> command, presumably because its typically used with NEWNEWS.
 Ken> However, since the command is fairly benign and may have
 Ken> alternative uses in the future, wouldn't it make more sense to
 Ken> label it as a general command?

It's never used between transit feeders, has no particular use between
them, and essentially none of them implement it. It's a reader command.

-- 
Andrew, Supernews
http://www.supernews.com

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 08:54:33 +0000

Ken Murchison said:
> presumably because its typically used with NEWNEWS.

No, it's listed as a reader command because that's what the previous
drafts have said:

    MODE READER SHOULD be sent by any client that intends to use
    any command in this specification (including extensions)
    other than IHAVE, HEAD, STAT, LIST ACTIVE, or LIST EXTENSIONS;

except that I added QUIT for obvious reasons.

I'm happy to shift commands between the various classes based on the
consensus of the working group. Personally I'd move DATE, HELP, and
NEWNEWS to general, and I don't see the logic that says HEAD is general but
ARTICLE isn't. But I'm leaving it up to those who write split-function
servers to decide.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Dec 2004 01:08:09 -0800

> NEWNEWS to general,

innd is definitely not going to provide NEWNEWS.  NEWNEWS requires a
completely different type of database to work efficiently than innd would
otherwise need.

A case could be made for HELP, which is widely implemented in transit-only
servers.  I'd be mildly inclined to move HELP to general, yes.

> and I don't see the logic that says HEAD is general but ARTICLE
> isn't.

Because you can't actually read news with HEAD, just debug problems, and
you don't get more information from ARTICLE that's useful for debugging
problems.  It wasn't provided more as a security thing than anything else,
originally, but I think the reasoning is sound.

> But I'm leaving it up to those who write split-function servers to
> decide.

I'd just stick with what INN has always done; there isn't anything
fundamentally broken about how the division was done, and there's no real
point in worrying about it.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 2 Dec 2004 09:36:44 +0000

> completely different type of database to work efficiently than innd would

Okay. That's a good reason.

> servers.  I'd be mildly inclined to move HELP to general, yes.

Shall I do it?

> problems.

No, I don't see it. We should not be making decisions like this based on why
we think someone might be using a command, but on what the command actually
does.

I can see how a server might be able to implement STAT without access to
the newsbase, so I can see how a transit-only server might do STAT but not
ARTICLE, HEAD, and BODY. But is there really any implementation for which
the code for those three is actually significantly different? Surely they
all look basically the same:

    find_article ()
    if (not_found) return correct 4xx code and exit
    send_response (command == ARTICLE ? 220 : command == HEAD ? 221 : 222)
    bool send_line = command != BODY
    while (line = get_line_from_article ())
    {
        if (line == "" && command == HEAD)
            break;
        if (send_line)
            send_dot_stuffed_line (line);
        if (line == "")
            send_line = true;
    }
    send_trailing_dot ()

So all are equally easy to provide (unless someone did a deliberately
perverse implementation, of course).

> It wasn't provided more as a security thing than anything else,
> originally,

Huh?

> point in worrying about it.

If that's the consensus, that's also fine with me.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 02 Dec 2004 10:19:59 -0800

>> A case could be made for HELP, which is widely implemented in
>> transit-only servers.  I'd be mildly inclined to move HELP to general,
>> yes.

> Shall I do it?

It's outside the scope of the revisions that we're supposed to be doing,
kind of, but it's a pretty simple change, so yes, I think so.  I don't see
how it could hurt, and it more closely matches reality.

> Huh?

That was sort of incoherent.  Let me try that again.

I don't want to let my peers read articles off my transit server.  I
wasn't there when the original decision was made to only implement HEAD
and not ARTICLE, but I'll bet that was a consideration.

Yes, the code to support them is almost identical.

I really don't think we should list ARTICLE as a transit command, since
it's pretty much the quintessential example of a reader command.  If
anything, I'd go in the direction of *not* listing HEAD, but really I
don't see any reason to change it.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 14:20:35 +0000

Russ Allbery said:
>>> transit-only servers.

> how it could hurt, and it more closely matches reality.

Okay, it's done.

Since it's glaring me in the face, what about DATE?

> and not ARTICLE, but I'll bet that was a consideration.

Ah, I see.

> don't see any reason to change it.

Out of interest, what does transit-mode INN do with "HEAD 1234" or "STAT"
with no arguments?

---

From: Russ Allbery <[email-masked]>
Date: Fri, 03 Dec 2004 08:37:25 -0800

>> It's outside the scope of the revisions that we're supposed to be
>> doing, kind of, but it's a pretty simple change, so yes, I think so.  I
>> don't see how it could hurt, and it more closely matches reality.

> Since it's glaring me in the face, what about DATE?

Let's leave it.  It doesn't make a lot of difference, so let's go with
existing practice.

> Out of interest, what does transit-mode INN do with "HEAD 1234" or
> "STAT" with no arguments?

Um, nothing good I bet.  Let me check....

Returns a 435 error code.  Yeah, that's broken.  It should just say that
the user isn't in a group.  That's something I need to fix in INN.

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Fri, 3 Dec 2004 16:52:06 +0000

> Let's leave it.  It doesn't make a lot of difference, so let's go with

Okay.

> the user isn't in a group.

Which is 412. Right.