rfc555.txt

RFC 相关的技术文档

               JUST Content (and none of the other Static Attributes),
               and that the Server must retrieve the file (which may be
               a temporary file created by the user process) in real
               time, i.e. BEFORE it sends its response to the FILE
               command.

               This alternative eliminates the need to borrow the BYTE,
               SOCK, PASV, TYPE, STRU, MODE, REST, and SITE commands
               from FTP (JEW RFC 524 -- 17140,7c1:gy).  It also allows
               the user process the flexibility of specifying a file at
               a host other than his own.

               After some thought, I think I agree with Crocker and
               Postel that theirs is the better implementation.

                  As they point out, however, this implementation
                  introduces the problem of somehow reconciling the
                  desire to permit (in general) the transfer of mail
                  files without requiring a login, with a server's
                  inability to distinguish that case from the general
                  case of file retrieval (for which many hosts will
                  require a login).





White                                                           [Page 6]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973


   USE OF THE DATE FORM 1/2/73 (JAN 2 OR FEB 1?)

      References:
         (RCC -- 17822,1b)
      Discussion:
         Agreed.

   ORDER OF PARAMETER SPECIFICATION

      References:

         (DHC JBP RFC 539 -- 17644,31:gy)

      Discussion:

         The Protocol does not, as Crocker and Postel state, impose an
         order upon command specification within a function (see for
         example, JEW RFC 524 -- 17140,5f1b:gy).

         Having considered their suggestion only briefly, it does seem
         to me appropriate to impose some constraints on the order of
         parameter specification by the user.  Off hand, the order
         suggested -- Dynamic, Optional, Static -- seems good.

III.  SUGGESTED ADDITIONS

   FORWARDING AT DELIVERY TIME

      References:

         (DHC JBP 539 -- 17644,4b:g)

      Discussion:

      Including provision for the forwarding of mail at Delivery Time,
      in contrast to sometime after Delivery in response to a specific
      Forward request (i.e., function), seems to me a useful addition to
      the Protocol.

      As Crocker and Postel note, only one of the three mechanisms for
      such forwarding bears upon the Protocol (although the Protocol
      might mention the other two and either encourage or discourage
      their use).

      I suggest the following reply format, however, rather than the one
      suggested by Crocker and Postel (DHC JBP RFC 539 --
      17644,4b3c2:gy):




White                                                           [Page 7]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973


         476 <localname> -- is his location.

   DEFAULT SIGNATURE SHOULD BE THE AUTHOR

      References:
         (DHC JBP 539 -- 17644,3c:gy)
      Discussion:
         Agreed.

   LEVELS OF INTERRUPT

      References:

      (DHC JBP 539 -- 17644,3d:gy)

   Discussion:

         I see no value to defining numeric shades of urgency,
         unless the Protocol suggests some particular action the
         server might take in response to each one.

         The whole notion of flagging some pieces of mail as
         urgent seems to me useless unless the MP server process
         (not the human recipient) takes some kind of special
         action for urgent mail, BEFORE the human recipient
         would otherwise be apt to read the mail.  If one
         accepts that argument, there's clearly no point to
         defining shades of urgency if they have meaning only to
         the human recipient.  True, any pair of human users
         could privately agree on meanings, but it seems to me
         preferable to define those meanings formally or not at
         all.

   WARNING THE SERVER OF THE SIZE OF MAIL

      References:
         (DHC JBP RFC 539 -- 17644,3f:gy)
      Discussion:
         Agreed.  Further suggestions as to the implementation?

   DISCOURAGING SERVERS FROM REQUIRING LOGINS

      References:
         (DHC JBP RFC 539 -- 17644,3j:gy)
      Discussion:
         Agreed.  This is not a new issue.





White                                                           [Page 8]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973


IV.  META-COMMENTS

   SIZE OF THE PROTOCOL DOCUMENT

      References:

         (RCC -- 17822,1e:gy)

      Discussion:

         I offer an apology for the format of the the Protocol document.
         It differs radically from that of previous Protocol documents
         (e.g., FTP, RJE), and is certainly not tutorial in its
         orientation.  The glossary is a device I found useful in
         designing the Protocol.  If the substance of the Protocol were
         agreed upon, then friendlier documentation would have to be
         written.  The choice of approach was greatly affected by my own
         time constraints.

         As I find time, I would like to define the minimum
         implementation subsets that Clements requests.  For the moment,
         consider the command breakdown below.  It represents the case
         where the server permits only the function by which mail is
         delivered to users in his host.  It has the following
         attributes:

            (1) It supports all of the functions of the current FTP mail
            protocol.  In addition,

            (2) It makes specification of author and title explicit,
            avoiding the current problem of multiple headers (one
            supplied by the server, the other embedded by the user in
            the text of the message),

            (3) It allows the text of the message to reside at a third
            host, and

            (4) It permits multiple recipients.

         The breakdown is the following:

            COMMANDS THAT MUST BE IMPLEMENTED
            (Author and Title could be treated as NOPs)

               To enter the Mail subsystem:
                  MAIL <CA>
               To invoke the Delivery function:
                  DELIVER <CA>



White                                                           [Page 9]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973


               To specify the text of the message:
                  FILE <CA>
                  LOCATION <fileaddr> <CA>
                  TEXT <string> <CA2>
               To identify author(s), recipient(s), and title:
                  AUTHOR <individual> <CA>
                  RECIPIENT <individual> <CA>
                  TITLE <title> <CA>
               To exit the function or subsystem:
                  ABORT <CA>
                  EXIT <CA>

            COMMANDS THAT CAN BE TREATED AS NOPS
            (they can legally appear in the Delivery function)

               ACCESS <individual> <CA>
               ACCESSTYPES <accesstypes> <CA>
               CATALOG <catalog> <CA>
               CLERK <individual> <CA>
               COMMENTS <comments> <CA2>
               CREATIONDATE <datetime> <CA>
               DELIVERYTYPE <deliverytype> <CA>
               DISPOSITION <disposition> <CA>
               GENERALDELIVERY <CA>
               GREETING <greeting> <CA>
               ID <id> <CA>
               REFERENCESERIAL <serialnumber> <CA>
               SERIAL <serialnumber> <CA>
               SIGNATURE <signature> <CA>

            COMMANDS THAT NEEDN'T BE RECOGNIZED
            (they cannot legally appear in the Delivery function)

            Commands that invoke unsupported functions:

               DISTRIBUTE <CA>
               FORWARD <CA>
               RECORD <CA>
               RETRIEVE <CA>
               UPDATE <CA>
               VERIFY <CA>

            Miscellaneous parameter specification commands:

               ACKCONDITION <ackcondition> <CA>
               ACKTYPE <acktype> <CA>
               CITATIONTEMPLATE <citationtemp> <CA>
               CUTOFF <interval> <CA>



White                                                          [Page 10]

RFC 555     Response to Critiques of Proposed Mail Protocol    July 1973


               FORWARDEE <individual> <CA>
               MONITOR <individual> <CA>
               PATHNAME <pathname> <CA>
               REPORTINTERVAL <interval> <CA>
               REQUESTOR <individual> <CA>
               UPDATETYPE <updatetype> <CA>

   CA AND CA2 NOT EXPLAINED SOON ENOUGH

      References:
         (DHC JBP RFC 539 -- 17644,3a:gy)
      Discussion:
         Agreed.

   CHANGE 'INTERRUPT' TO 'URGENT' OR 'PRIORITY'

      References:
         (DHC JBP RFC 539 -- 17644,3e:gy)
      Discussion:
         Agreed.
         How about 'URGENT'.

   CARRY STATIC/DYNAMIC ATTRIBUTE DISTINCTION INTO FORMAL SYNTAX

      References:
         (DHC JBP RFC 539 -- 17644,3i:gy)
      Discussion:
         Agreed.

   CRYPTIC DEFAULT DESCRIPTIONS

      References:
         (DHC JBP RFC 539 -- 17644,3k:gy)
      Discussion:
         Agreed.


       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Sergio Kleiman  12/99 ]












White                                                          [Page 11]