rfc524.txt
来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,976 行 · 第 1/5 页
TXT
1,976 行
The act of verifying an ID as that of a specified Individual. USER VERIFICATION AGENT A Mail server process which performs User VerificationMP FUNCTIONS A MP function is the request by a Mail user process and the subsequent performance by a server, of a major task related to the management of Mail. The following functions are defined: RECORDING DELIVERY DISTRIBUTION FORWARDING CITATION RETRIEVAL UPDATE CITATION USER VERIFICATION One might expect that within the Network there would be just a few Recording Agents (who implement the Recording, Citation Retrieval, and Update Citation functions); a few Distribution Agents (who implement the Distribution function); one or two User Verification Agents (who implement the User Verification Function); and many hosts who implement the Delivery and Forwarding functions. In general, a host is free to implement any, all, or none of the functions defined by the Protocol; and a host is free to require a login (for purposes of accounting) before permitting a user process access to any of the function(s) it has implemented. An FTP server process who chooses to not implement MP or a particular MP function simply rejects the command that requests the unimplemented server with the reply: 400 Function not implemented. A server who chooses to require login before allowing access to the MP subsystem or to an MP function, simply rejects the command that requests the charged-for service with the reply:White [Page 22] RFC 524 A Proposed Mail Protocol 13 June 1973 332 Login first, please. The functions defined in MP are: RECORDING The Recording function is invoked with the command: RECORD <CA> Once this command is given, the user process shall provide the following (in any order that suits it): (1) Any Static Attributes desired. Content and Clerk are required. Defaults for other Static Attributes (applied by the server if the appropriate commands don't appear) are as follows: Title or Comments as specified in the glossary. Author to the Clerk. Creation Date to the Recording Date. (2) Initial values for any Dynamic Attributes desired. Defaults (applied by the server if the appropriate commands don't appear) are as follows: Distribution and Catalog Lists to null. Access List as specified in the glossary. The Recording function is terminated with either of the commands: EXIT <CA> or ABORT <CA> EXIT represents normal termination, and causes the server to perform the Recording function for which parameters have just been given. ABORT represents abnormal termination and effects exit from the function with no action having been taken by the server; the whole command exchange, beginning with RECORD, is therefore a NOP.White [Page 23] RFC 524 A Proposed Mail Protocol 13 June 1973 DELIVERY The Delivery function is invoked with the command: DELIVER <CA> Once this command is given, the user process shall provide the following (in any order that suits it): (1) Any Static Attributes desired. Content is required. Defaults for other Static Attributes (applied by the server if the appropriate commands don't appear) are as follows: Title or Comments as specified in the glossary. Clerk to null Author to the Clerk. Creation Date to the Delivery Date. (2) Any Dynamic Attributes desired. Distribution List is required. Defaults (applied by the server if the appropriate commands don't appear) are as follows: Catalog List to null Access List as specified in the glossary. Both of these attributes are for the Recipient's information only when presented in the context of Delivery, so defaulting them to null simply implies that the Clerk doesn't desire that they be communicated to the Recipient. (3) Any or all of the following optional parameters: (a) Delivery TypeWhite [Page 24] RFC 524 A Proposed Mail Protocol 13 June 1973 (b) Acknowledgment Type The specification of this parameter is appropriate if and only if the Delivery Type is POSITIVE or NEGATIVE ACKNOWLEDGMENT or PROGRESS REPORT. In this context, Acknowledgment Type tells the server how to interpret the Content of the Acknowledgment. (c) Serial Number The Serial Number assigned to the piece of Mail being Delivered. This parameter is inappropriate unless the Delivery type is FORWARD (in which case the Serial Number is the one preserved from the previous Delivery), MAIL, or REPLY. (d) Reference Serial Number The Serial Number assigned to the piece of Mail to which the current piece of Mail is either an Acknowledgment, Progress Report, or Reply. The specification of this parameter is therefore inappropriate if the Delivery Type is MAIL. The Delivery function is terminated with either of the commands: EXIT <CA> or ABORT <CA> EXIT represents normal termination, and causes the server to perform the Delivery function for which parameters have just been given. ABORT represents abnormal termination and effects exit from the function with no action having been taken by the server; the whole command exchange, beginning with DELIVER, is therefore a NOP. DISTRIBUTION The Distribution function is invoked with the command: DISTRIBUTE <CA> Once this command is given, the user process shall provide the following (in any order that suits it): (1) Any Static Attributes desired.White [Page 25] RFC 524 A Proposed Mail Protocol 13 June 1973 Content is required. Defaults for other Static Attributes (applied by the server if the appropriate commands don't appear) are as follows: Title or Comments as specified in the glossary. Clerk to null Author to the Clerk. Creation Date to the Delivery Date. (2) Any Dynamic Attributes desired. Distribution List is required. Defaults (applied by the server if the appropriate commands don't appear) are as follows: Catalog List to null Access List as specified in the glossary. Both of these attributes are for the Recipient(s) information only when presented in the context of Distribution, so defaulting them to null simply implies that the Clerk doesn't desire that they be communicated to the Recipient(s). (3) Any or all of the following optional parameters: (a) Delivery Type MAIL, FORWARD, or REPLY only. (b) Serial Number The Serial Number of the Mail being Distributed. The Distribution Agent will relay this Serial Number to each Recipient at Delivery. (c) Reference Serial Number The Serial Number of the piece of Mail to which the current piece of Mail is a Reply. The Distribution Agent will relay this Serial Number to each Recipient at Delivery. The specification of this parameter is appropriate if and only if the Delivery Type is REPLY.White [Page 26] RFC 524 A Proposed Mail Protocol 13 June 1973 (d) Acknowledgment Condition An Acknowledgment is requested from the Distribution Agent if and only if the Acknowledgment Condition is other than NEVER. (e) Acknowledgment Type (f) Cutoff Interval (g) Report Interval Progress Reports are requested from the Distribution Agent if and only if this parameter is specified explicitly. (h) Monitor This parameter is ignored unless either an Acknowledgment or Progress Reports (or both) are requested. The Distribution function is terminated with either of the commands: EXIT <CA> or ABORT <CA> EXIT represents normal termination, and causes the server to perform the Distribution function for which parameters have just been given. ABORT represents abnormal termination and effects exit from the function with no action having been taken by the server; the whole command exchange, beginning with DISTRIBUTE, is therefore a NOP. FORWARDING The Forwarding function is invoked with the command: FORWARD <CA> Once this command is given, the user process shall provide the following (in any order that suits it): (1) ForwardeeWhite [Page 27] RFC 524 A Proposed Mail Protocol 13 June 1973 (2) Distribution list This is the set of Individual(s) to whom the Mail is to be Forwarded. The Forwarding function is terminated with either of the commands: EXIT <CA> or ABORT <CA> EXIT represents normal termination, and causes the server to perform the Forwarding function for which parameters have just been given. ABORT represents abnormal termination and effects exit from the function with no action having been taken by the server; the whole command exchange, beginning with FORWARD, is therefore a NOP. CITATION RETRIEVAL The Citation Retrieval function is invoked with the command: RETRIEVE <CA> Once this command is given, the user process shall provide the following (in any order that suits it): (1) The pathname of the piece of Mail whose Citation is to be retrieved: PATHNAME <pathname> <CA> (2) Any or all of the following optional parameters: (a) Citation Template (b) Requestor This parameter is required if and only if Content is requested and Read Access happens not to be granted to All, in which case the server verifies that the Requestor has Read Access to the piece of Mail. (c) FILE <CA> This command is appropriate if and only if Content is requested. The presence of this command implies that the Content of the Mail is to be returned to the user process (following the return on the TELNET connectionWhite [Page 28] RFC 524 A Proposed Mail Protocol 13 June 1973 of any other Citation Component(s) requested) as a file using the FTP data transfer commands (e.g., BYTE, SOCK, TYPE) currently in effect. FILE is exactly equivalent in effect to an FTP RETR command (in its use of data transfer commands, in its establishment of the data connection etc.) except that no pathname is required. In the absence of a FILE command, Content is returned on the TELNET connection like any other Citation⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?