Annotation of 43BSD/contrib/nntp/doc/reply, revision 1.1

1.1     ! root        1: Brian,
        !             2: 
        !             3:      Here are the differences I see between your and my server.
        !             4: I've included proposed changes, some to yours, some to mine.  If
        !             5: we could get agreed on a standard by this weekend, which may be
        !             6: ambitious, it would be really good.
        !             7: 
        !             8:      BTW, is the stuff I'm ">" including the current version?
        !             9: 
        !            10:                                                Phil
        !            11: 
        !            12: 
        !            13: > The whole idea is to keep the server as small and (computationally)
        !            14: > inexpensive as possible.  Reading news on our system is not a super
        !            15: > popular pastime, but a central machine could still get rather heavily
        !            16: > loaded if 5 people per system were to decide that it was time to catch
        !            17: > up on the latest happenings.
        !            18: 
        !            19: Agreed.  This is, I feel, an implementation detail, although it
        !            20: should be reflected in the protcol -- i.e., the protocol should
        !            21: not be bulky or hard to implement.  I don't think we suffer from
        !            22: this problem.
        !            23: 
        !            24: > No doubt I'll refine it further as I try to interface more client stuff
        !            25: > to it.  Right now it seems to have enough to start making a version of
        !            26: > 'readnews' work with it.
        !            27: 
        !            28: This is a matter of philosophy: I feel it's very important to make the
        !            29: server as easy to interface with existing programs as possible, but
        !            30: still be general enough to provide for future service.
        !            31: 
        !            32: General differences:  Let's try to make this as SMTP-like as
        !            33: possible.  One thing I noticed is that you put "."'s in front of
        !            34: your reply codes.  SMTP doesn't do this, and I can't think of
        !            35: why you do it.  Am I missing something? 
        !            36: 
        !            37: As far as variable length messages go, there are two possibilities:
        !            38: The one I am using currently is the
        !            39: 
        !            40:        xxx-Start of text, look out /* assumed to be one line */
        !            41:        xxx-blah blah
        !            42:        xxx-blah blah
        !            43:        xxx-blah blah
        !            44:        xxx-blah blah
        !            45:        xxx end of text (no dash)
        !            46: 
        !            47: I don't really like this, since it means we strip off four characters per
        !            48: line, which slows things down that much.
        !            49: 
        !            50: The second possibility is that we say
        !            51: 
        !            52:        xxx-Start of text, look out     /* again, a one liner */
        !            53:        Text goes
        !            54:        here,
        !            55:        with a period on a
        !            56:        line by itself, just
        !            57:        like SMTP.
        !            58:        .
        !            59:        xxx End of text         /* Maybe we don't need this message */
        !            60: 
        !            61: As usual, any line in the message which starts with a period we
        !            62: simply duplicate -- that it, we put an extra period in front,
        !            63: and then the client strips it off.  If there is only one period,
        !            64: it must be EOF.
        !            65: 
        !            66: How say you to this?
        !            67: 
        !            68: >      Commands consist of an UPPERCASE command word, some  of
        !            69: > which  are  followed  by parameters.  All input is in ASCII,
        !            70: > terminated in CR-LF.
        !            71: 
        !            72: Very much agreed, especially the CF-LF stuff.  It's fairly
        !            73: trivial to accept lower case, I think you already have hacked
        !            74: your daemon to do this.  But the std should probably call for
        !            75: upper case.
        !            76: 
        !            77: > BODY      No parameters.  Displays the body  (text)  of  the
        !            78: >           current article.
        !            79: 
        !            80: Same here, except we differ on arguments.  All of my commands
        !            81: like BODY, HEADER, etc. require an article number as an argument.
        !            82: I think this is better because it's more what readnews/rn will
        !            83: want: They have an "open article" function, with a numeric
        !            84: argument.  I don't think we need the "next" function, since it
        !            85: hides the article numbers from the client, and the client, if
        !            86: it is an existing program, will want to worry about article numbers.
        !            87: 
        !            88: > GET nnn   (nnn) is the numeric  id  of  an  article  in  the
        !            89: >           current  newsgroup.   It  must  be chosen from the
        !            90: >           range of articles provided when the newsgroup  was
        !            91: >           selected.
        !            92: 
        !            93: This is my "ARTICLE" command.
        !            94: 
        !            95: > GROUP ggg (ggg) is the name of the newsgroup to be selected.
        !            96: 
        !            97: Same here.
        !            98: 
        !            99: > HEAD      No parameters.  Displays the header lines  of  the
        !           100: >           current article.
        !           101: 
        !           102: Same here, but with parameters.
        !           103: 
        !           104: > LAST      No parameters.  Backs up to the  previous  article
        !           105: >           in  the  current newsgroup.  If already positioned
        !           106: >           at  the  beginning  of  the  newsgroup,  an  error
        !           107: >           results.
        !           108: 
        !           109: No equivalent here.  Do we need this?  Again, rn/readnews will
        !           110: take care of this internally.
        !           111: 
        !           112: > NEXT      No parameters.  Advances to the  next  article  in
        !           113: >           the current newsgroup.  If no more articles remain
        !           114: >           in the current group, an error results.
        !           115: 
        !           116: Same comment as for LAST.
        !           117: 
        !           118: > QUIT      No  parameters.   The  server  process  exits  and
        !           119: >           closes the connection to the client.
        !           120: 
        !           121: Great minds think alike.
        !           122: 
        !           123: Some commands I didn't see in yours:
        !           124: 
        !           125: ACTIVE - transmit the active file in normal format.  By normal,
        !           126:          I mean normal, 4.2 UNIX active file format.
        !           127: 
        !           128: POST   - User sends an article, followed by a period on a line
        !           129:          by itself.  This is passed to inews, which deals with
        !           130:          it.  After inews has dealt with it, daemon returns
        !           131:          a reply code.
        !           132: 
        !           133: NEWSINCE "date"  List the new articles, since "date", where
        !           134:         date is a long integer containing the number of seconds
        !           135:         since Jan 1, 1970.  Should this be GMT?
        !           136: 
        !           137: BOUNDS - Show high and low message number in current newsgroup.
        !           138:          You provide this with your "GROUP" command, and I should
        !           139:          too.
        !           140: 
        !           141: >      Responses are of two kinds.   Command/status  responses
        !           142: > are distinguished by having a single period (.) as the first
        !           143: > character of the line.  Text lines have no period, or if the
        !           144: > text contained a period in the original, that period is dou-
        !           145: > bled.  The intention is that text messages will be displayed
        !           146: > directly  on  the  user's  terminal  (or  processed  through
        !           147: > 'more'), whereas command/status  responses  will  be  inter-
        !           148: > preted  by the client program before any possible display is
        !           149: > done.
        !           150: 
        !           151: As I said above, I move we go to this sort of thing, but
        !           152: have a single period, so as to be like SMTP.  I love conformity.
        !           153: 
        !           154: >      Response codes are returned in a command/status  return
        !           155: > line  (i.e.,  they  are  prefixed  with a period). These are
        !           156: > status reports or command  responses  from  the  daemon  and
        !           157: > indicate  the response to the last command received from the
        !           158: > client.
        !           159: 
        !           160: You have your status messages much more thought out than I
        !           161: do, since I sort of assigned them randomly/sequentially.
        !           162: Also, has it been your experience that only 200/500 series gets used?
        !           163: 
        !           164: > 1xx  Informative  messages  -  no  significance  except   to
        !           165: >      humans.   Probably  these  should  be  displayed to the
        !           166: >      user.
        !           167: > 
        !           168: > 2xx  Last command was ok and  is  being  performed.   Mostly
        !           169: >      just indicate that you asked the daemon to do something
        !           170: >      reasonable and it did it.
        !           171: > 
        !           172: > 3xx  Continue with the  command.   (used  on  commands  that
        !           173: >      expect  to  receive more data) You should then send the
        !           174: >      rest of the data.
        !           175: > 
        !           176: > 4xx  Couldn't do your  last  command.   Perhaps  you  simply
        !           177: >      specified a non-existing article or something.
        !           178: > 
        !           179: > 5xx  Couldn't do your last command.   Serious  error  -  the
        !           180: >      command  was invalid, or was missing parameters, or the
        !           181: >      daemon program faulted. This means that  something  was
        !           182: >      wrong  enough  with your command that current status is
        !           183: >      in  doubt.  Perhaps  one  or  more  pointers  has  been
        !           184: >      changed.  Don't  proceed  until you have re-established
        !           185: >      the  environment  (newgroup/article  selection).    (An
        !           186: >      exception  is  the  "500  bad  command" response - your
        !           187: >      entire command was flushed and ignored.)
        !           188: > 
        !           189: > The next digit in the code indicates the  function  response
        !           190: > category.
        !           191: > 
        !           192: > x0x  Client setup and miscellaneous messages
        !           193: > 
        !           194: > x1x  Newsgroup selection
        !           195: > 
        !           196: > x2x  Article selection
        !           197: > 
        !           198: > x3x  Article display
        !           199: > 
        !           200: > x4x  <reserved>
        !           201: > 
        !           202: > x5x  Posting
        !           203: > 
        !           204: > 
        !           205: > 
        !           206: > The following response codes are to be expected.
        !           207: 
        !           208: Following SMTP, it should be possible to write a "dumb" client which
        !           209: doesn't look for a "211", but rather, a "2" in response to a
        !           210: "GROUP" command, and it knows what order the arguments are in.
        !           211: 
        !           212: >         200 news server ready
        !           213: >         201 news server closing connection
        !           214: >         211 %d %d %d %s
        !           215: >                 (number of articles in group,
        !           216: >                 first article number in the group,
        !           217: >                 last article number in the group,
        !           218: >                 name of the group.
        !           219: >         215 active start
        !           220: >         216 active end
        !           221: >         221 %d %d %d %d %s article retrieved
        !           222: >                 (article number,
        !           223: >                 first article number in the group,
        !           224: >                 last article number in the group,
        !           225: >                 unique article id (usually the inode number)
        !           226: >         230 head start
        !           227: >         231 head end
        !           228: >         235 body start
        !           229: >         236 body end
        !           230: >         250 article posted ok
        !           231: >         354 send article to be posted. End with <CRLF>.<CRLF>
        !           232: >         411 no such news group
        !           233: >         412 empty newsgroup
        !           234: >         413 more than MAXART articles; others suppressed
        !           235: >         415 no active file
        !           236: >         421 No next article in this group
        !           237: >         422 No previous article in this group
        !           238: >         422 no such article number in this group
        !           239: >         431 no file
        !           240: >         432 no file
        !           241: >         500 bad command
        !           242: >         521 article file missing
        !           243: >         522 article file missing - unable to stat
        !           244: >         550 can't start inews for posting
        !           245: > 

unix.superglobalmegacorp.com

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.