rfc524.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,976 行 · 第 1/5 页

   AUTHOR LIST (for a piece of Mail)

      That set of Individuals who are Author(s) of a piece of Mail.

      An Author List is represented in the Protocol as an Individual
      List of type AUTHOR.

   CATALOG (of Recorded Mail)

      A named data base containing the Citation for each member of a set
      of logically related pieces of Recorded Mail.

   CATALOG LIST (for a Piece of Recorded Mail)

      That set of Catalogs which each contain the Citation for a piece
      of Recorded Mail

      A Catalog List is represented in the Protocol as a series of
      instances (juxtaposed in the command stream) of the following
      command.  Each instance corresponds to one Catalog in the set.

         CATALOG <catalog> <CA>

   CITATION (for a piece of Recorded Mail)

      The Static and Dynamic Attributes of a piece of Recorded Mail.

   CITATION COMPONENT

      Any one of the Static or Dynamic Attributes which comprise a
      Citation.

   CITATION RETRIEVAL (for a piece of Recorded Mail)

      The act of retrieving selected Citation Component(s).

   CITATION TEMPLATE

      A specified subset of the Citation Component(s) for a piece of
      Recorded Mail.

      A Citation Template is represented in the Protocol by the command:









White                                                           [Page 8]

RFC 524                 A Proposed Mail Protocol            13 June 1973


         CITATIONTEMPLATE <citationtemp> <CA>

      The argument is a list of Citation Component(s).  In the absence
      of an explicit CITATIONTEMPLATE command (or if the argument is
      null), one specifying Content only is to be assumed.

   CLERK

      That Individual who prepares a piece of Mail for Recording,
      Distribution, or Delivery.  Conceptually, the Individual with
      proof-reading responsibility for the piece of Mail.

      A Clerk is represented in the Protocol as an Individual List of
      type CLERK and length 1.

   COMMENTS (for a piece of Mail)

      An informal, perhaps verbose description of the Content of a piece
      of Mail, or any other information the Author(s) wish to have made
      accessible to the Recipient(s) of the Mail.

      Comments are represented in the Protocol by the command:

         COMMENTS <comments> <CA2>

      In the absence of an explicit COMMENTS command, one with a null
      argument is to be assumed.

   CONTENT (of a piece of Mail)

      It's text.

      Content is represented in the protocol by either of the two
      commands below:

         FILE <CA>

            The FILE command implies that the Content of the Mail will
            be transmitted (immediately) as a file using the FTP data
            transfer commands (e.g., BYTE, SOCK, TYPE) currently in
            effect.  FILE is exactly equivalent in use to an FTP STOR
            command (in its use of data transfer commands, in its
            establishment of the data connection, etc.), except that no
            pathname is required, and the server, rather than depositing
            the transmitted file in his file system, disposes of it in a
            manner appropriate for Mail.





White                                                           [Page 9]

RFC 524                 A Proposed Mail Protocol            13 June 1973


         TEXT <string> <CA2>

            The TEXT command implies that the Content of the Mail
            follows on the TELNET connection as a series of lines, each
            delimited from the preceding one by CR LF, and terminated
            finally by a CA2.

   CONTROLLING ACCESS (to a piece of Recorded Mail)

      The right of an Individual to modify a Dynamic Attribute of a
      piece of Recorded Mail.

      Recording Agents permit an Individual to modify a Dynamic
      Attribute of a piece of Recorded Mail if and only if he can
      properly identify himself as someone having Controlling Access to
      that Mail.

   CREATION DATE (of a piece of Mail)

      The date and time at which the final draft of a piece of Mail is
      completed by the Clerk before he releases it to a Delivery,
      Distribution, or Recording Agent for further processing.  A single
      Creation Date is associated with each piece of Mail.  In general,
      this date is different from the Delivery or Recording Date, since
      Mail often must be queued (for another host to come up) within the
      Delivery, Distribution, or Recording Agent's host before Delivery
      of Recording can occur.

      A Creation Date is represented in the Protocol by the command:

         CREATIONDATE <datetime> <CA>

   CUTOFF INTERVAL (for Distribution of a piece of Mail)

      That period of time, measured from the Distribution Date, after
      which the Distribution Agent is to abandon Delivery attempts for
      those Recipient(s) to whom Delivery has not yet been effected.

      A Cutoff Interval is represented in the Protocol by the command:

         CUTOFF <interval> <CA>

      In the absence of an explicit CUTOFF command, one specifying an
      Interval of 7 days is to be assumed.







White                                                          [Page 10]

RFC 524                 A Proposed Mail Protocol            13 June 1973


   DELIVERY (of a piece of Mail)

      The act of transmitting a piece of Mail to the host of one of it's
      Recipient(s).

   DELIVERY AGENT

      A process which effects Delivery of a piece of Mail.  A
      Distribution Agent is by nature also a Delivery Agent.

   DELIVERY DATE (of a piece of Mail to one of its Recipient(s))

      The date and time at which a piece of Mail is Delivered by the
      Delivery Agent to a Recipient's system.  A multitude of Delivery
      Dates, one for each Recipient, are associated with each piece of
      Mail.

   DELIVERY STATUS (for a piece of Mail with respect to a Recipient)

      A measure of the extent to which a Delivery Agent has been
      successful, at a given point in time, in Delivering a piece of
      Mail to one of its Recipient(s).  A multitude of Delivery Status',
      one for each Recipient, are associated with each piece of Mail.

      The following Delivery Status' are defined:

         FAILED

            Delivery was rejected by the Recipient's system (e.g., the
            connection request was rejected, the Mail server process
            doesn't support Delivery, the Recipient was not recognized
            by the server).

         SUCCESSFUL

            Delivery was accomplished successfully.

         TIMED OUT

            Either the Recipient's host was disconnected from the Net at
            every Delivery attempt, or no Mail server process has ever
            responded to the connection attempt.  Hope of Delivery has
            been abandoned.








White                                                          [Page 11]

RFC 524                 A Proposed Mail Protocol            13 June 1973


         WAITING

            Either the Recipient's host has been disconnected from the
            Net at every Delivery attempt, or no Mail server process has
            yet responded to the connection attempt.  Delivery attempts
            are continuing periodically.

         UNATTEMPTED

            No delivery attempt has yet been made.

   DELIVERY TYPE (for a Delivery)

      The nature of the piece of Mail being delivered.

      The following Delivery Types are defined:

         FORWARD

            A Delivery of type FORWARD represents a piece of Recorded or
            Unrecorded Mail which is being Forwarded.

         MAIL

            A Delivery of type MAIL represents a piece of Recorded or
            Unrecorded Mail whose ultimate source is an Individual.
            This is the "normal" Delivery type.

         NEGATIVE ACKNOWLEDGMENT

            A Delivery of type NEGATIVE ACKNOWLEDGMENT represents a
            piece of Unrecorded Mail generated by a Distribution Agent
            and acknowledging unsuccessful or partially unsuccessful
            Delivery of a previous piece of Mail (identified by
            Reference Serial Number) to it's Recipient(s).  The
            Recipient for this piece of "system" Mail is the Monitor for
            the previous piece of Mail.

         POSITIVE ACKNOWLEDGMENT

            A Delivery of type POSITIVE ACKNOWLEDGMENT represents a
            piece of Unrecorded Mail generated by a Distribution Agent
            and acknowledging successful Delivery of a previous piece of
            Mail (identified by Reference Serial Number) to it's
            Recipient(s).  The Recipient for this piece of "system" Mail
            is the Monitor for the previous piece of Mail.





White                                                          [Page 12]

RFC 524                 A Proposed Mail Protocol            13 June 1973


         PROGRESS REPORT

            A Delivery of type PROGRESS REPORT represents a piece of
            Unrecorded Mail generated by a Distribution Agent and
            reporting the Delivery of a previous piece of Mail
            (identified by Reference Serial Number) to it's
            recipient(s).  The Recipient for this piece of "system" Mail
            is the Monitor for the previous piece of Mail.

         REPLY

            A Delivery of type REPLY represents a piece of Recorded or
            Unrecorded Mail generated in reply (or pertaining) to a
            previous piece of Mail (identified by Reference Serial
            Number).

      Delivery Type is represented in the Protocol by the command:

         DELIVERYTYPE <deliverytype> <CA>

      In the absence of an explicit DELIVERYTYPE command, one with
      argument of MAIL is to be assumed.

   DISTRIBUTE DATE (for a piece of Mail)

      The date and time at which a piece of Mail is presented to a
      Distribution Agent for Distribution.

   DISTRIBUTION (of a piece of Mail)

      The act of Delivering a piece of Mail to its Recipient(s).
      Distribution can be effected by either the Clerk's Delivery Agent,
      or by a Distribution Agent acting on his behalf.

   DISTRIBUTION AGENT

      A Mail server process which acts as intermediary in the delivery
      process by accepting Mail for Recipient(s) in hosts other than its
      own, and then assuming responsibility for Delivering the Mail to
      them and returning Acknowledgment to the appointed Monitor.

   DISTRIBUTION LIST

      In the Delivery or Distribution of a piece of Mail, that set of
      Individuals who are to receive Delivery of the Mail.






White                                                          [Page 13]

RFC 524                 A Proposed Mail Protocol            13 June 1973


      In the Recording of Mail, that set of Individuals who have
      received formal and authorized Delivery of a piece of Mail.  The
      list is kept current by Distribution Agents.  Of course, any
      Individual with Read Access to the Mail can himself Deliver it
      informally to anyone he chooses without that fact's being
      reflected in the Distribution list.

      A Distribution List is represented in the Protocol as a series of
      command quintuplets (juxtaposed in the command stream), each
      quintuplet consisting of a RECIPIENT command, followed immediately
      (and optionally) by any or all of the following in the order
      given: a GENERALDELIVERY, a GREETING, a SIGNATURE, and a
      DISPOSITION command.

      Each quintuplet corresponds to one individual in the set.

         RECIPIENT <individual> <CA>

         GENERALDELIVERY <CA>

            This command is appropriate only in the context of the
            Delivery function.  If the previous RECIPIENT command
            illicits the reply:

               474 Recipient unrecognized: is General Delivery
            OK?

            the issuance of the GENERALDELIVERY command constitutes
            consent to proceed with General Delivery to that Recipient.
            If no such consent is given, the RECIPIENT command stands
            rejected.  Unsolicited (i.e., unprompted for) GENERAL
            DELIVERY commands in the Distribution List are treated by
            the server as NOPs.

         GREETING <greeting> <CA>

            The GREETING command specifies the Greeting to be seen by
            the Recipient.

            If the first quintuplet in the list contains no GREETING
            command, one with a null argument is assumed.  Thereafter,
            in the absence of an explicit GREETING command, one
            identical to that for the previous quintuplet is assumed.

         SIGNATURE <signature> <CA>

            The SIGNATURE command specifies the Signature to be seen by
            the Recipient.



White                                                          [Page 14]

RFC 524                 A Proposed Mail Protocol            13 June 1973


            If the first quintuplet in the list contains no SIGNATURE
            command, one with a null argument is assumed.  Thereafter,