RFC937 日本語訳
0937 Post Office Protocol: Version 2. M. Butler, J. Postel, D. Chase,J. Goldberger, J.K. Reynolds. February 1985. (Format: TXT=42370 bytes) (Obsoletes RFC0918) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Butler
Request for Comments: 937 J. Postel
D. Chase
J. Goldberger
J. K. Reynolds
Obsoletes: RFC 918 ISI
February 1985
コメントを求めるワーキンググループM.バトラー要求をネットワークでつないでください: 937 J.ポステル・D.チェイス・J.Goldberger J.K.レイノルズは以下を時代遅れにします。 RFC918ISI1985年2月
POST OFFICE PROTOCOL - VERSION 2
POP--バージョン2
Status of this Memo
このMemoの状態
This RFC suggests a simple method for workstations to dynamically access mail from a mailbox server. This RFC specifies a proposed protocol for the ARPA-Internet community, and requests discussion and suggestions for improvement. This memo is a revision of RFC 918. Distribution of this memo is unlimited.
このRFCはワークステーションがメールボックスサーバからメールにダイナミックにアクセスする簡単なメソッドを勧めます。このRFCはARPA-インターネットコミュニティ、要求議論、および改善提案に提案されたプロトコルを指定します。 このメモはRFC918の改正です。 このメモの分配は無制限です。
Introduction
序論
The intent of the Post Office Protocol Version 2 (POP2) is to allow a user's workstation to access mail from a mailbox server. It is expected that mail will be posted from the workstation to the mailbox server via the Simple Mail Transfer Protocol (SMTP). For further information see RFC-821 [1] and RFC-822 [2].
ポストオフィスプロトコルバージョン2(POP2)の意図はユーザのワークステーションがメールボックスサーバからメールにアクセスするのを許容することです。シンプルメールトランスファプロトコル(SMTP)でメールがワークステーションからメールボックスサーバまで掲示されると予想されます。 詳細に関しては、RFC-821[1]とRFC-822[2]を見てください。
This protocol assumes a reliable data stream such as provided by TCP or any similar protocol. When TCP is used, the POP2 server listens on port 109 [4].
このプロトコルはTCPかどんな同様のプロトコルでも提供するように確実な資料ストリームを仮定します。 TCPが使用されているとき、POP2サーバはポートの上で109[4]を聴きます。
System Model and Philosophy
システムモデルと哲学
While we view the workstation as an Internet host in the sense that it implements IP, we do not expect the workstation to contain the user's mailbox. We expect the mailbox to be on a server machine.
インターネット・ホストとしてIPを実装するという意味でワークステーションを見なしている間、私たちは、ワークステーションがユーザのメールボックスを含むと予想しません。 私たちは、サーバマシンの上にメールボックスがあると予想します。
We believe it is important for the mailbox to be on an "always up" machine and that a workstation may be frequently powered down, or otherwise unavailable as an SMTP server.
私たちは、ワークステーションがメールボックスが「上にいつも」というマシンとそれにあるように、SMTPサーバーとして頻繁に動力付きである、またはそうでなければ、入手できないのが、重要であると信じています。
POP2 is designed for an environment of workstations and servers on a low-delay, high-throughput, local networks (such as Ethernets). POP2 may be useful in other environments as well, but if the environment is substantially different, a different division of labor between the client and server may be appropriate, and a different protocol required.
POP2はワークステーションとサーバの環境のために低い遅れ、高いスループットの、そして、ローカルのネットワーク(Ethernetsなどの)で設計されています。 またが、環境が実質的に異なるなら、POP2は他の環境で役に立つかもしれません、そして、クライアントとサーバの間の異なった分業は適切であるかもしれません、そして、異なったプロトコルが必要です。
Suppose the user's real name is John Smith, the user's machine is called FIDO, and that the mailbox server is called DOG-HOUSE. Then
ユーザの本名がジョン・スミス、ユーザのマシンがFIDOと呼ばれて、メールボックスサーバがDOG-下院と呼ばれるということであると仮定してください。 その時
Butler, et. al. [Page 1]
etバトラー、アル。 [1ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
we expect the user's mail to be addressed to JSmith@DOG-HOUSE.ARPA (not JSmith@FIDO.ARPA).
私たちは、ユーザのメールが JSmith@DOG-HOUSE.ARPA ( JSmith@FIDO.ARPA でない)に扱われると予想します。
That is, the destination of the mail is the mailbox on the server machine. The POP2 protocol and the workstation are merely a mechanism for viewing the messages in the mailbox.
すなわち、メールの目的地はサーバマシンの上のメールボックスです。 POP2プロトコルとワークステーションは、単にメールボックスの中にメッセージを見るためのメカニズムです。
The user is not tied to any particular workstation for accessing his mail. The workstation does not appear as any part of the mailbox address.
ユーザは彼のメールにアクセスするためのどんな特定のワークステーションにもつながれません。 ワークステーションはメールボックスアドレスのどんな部分としても現れません。
This is a very simple protocol. This is not a user interface. We expect that there is a program in the workstation that is friendly to the user. This protocol is not "user friendly". One basic rule of this protocol is "if anything goes wrong close the connection". Another basic rule is to have few options.
これは非常に簡単なプロトコルです。 これはユーザーインタフェースではありません。 私たちは、プログラムがユーザにとって、好意的なワークステーションにあると予想します。 このプロトコルは「ユーザフレンドリーではありません」。 このプロトコルの1つの基本的な規則は「何でも接続を終えに悪く行くかどうか」ということです。 別の基本的な規則はわずかなオプションしか持たないことです。
POP2 does not parse messages in any way. It does not analyze message headers (Date:, From:, To:, Cc:, or Subject:). POP2 simply transmits whole messages from a mailbox server to a client workstation.
POP2は何らかの方法でメッセージを分析しません。 それはメッセージヘッダー(日付:、From:、To:、Cc:、またはSubject:)を分析しません。 POP2はメールボックスサーバからクライアントワークステーションまで単に全体のメッセージを送ります。
The Protocol
プロトコル
The POP2 protocol is a sequence of commands and replies. The design draws from many previous protocols of the ARPA-Internet community.
POP2プロトコルはコマンドと回答の系列です。 デザインはARPA-インターネットコミュニティの前の多くのプロトコルから描かれます。
The server must be listening for a connection. When a connection
is opened the server sends a greeting message and waits for
commands. When commands are received the server acts on them and
responds with replies.
サーバは接続の聞こうとしなければなりません。 接続が開かれるとき、サーバは、あいさつメッセージを送って、コマンドを待っています。 コマンドが受け取られているとき、サーバは、それらに影響して、回答で反応します。
The client opens a connection, waits for the greeting, then sends
the HELO command with the user name and password arguments to
establish authorization to access mailboxes. The server returns
the number of messages in the default mailbox.
クライアントは、接続を開いて、挨拶を待っていて、次に、メールボックスにアクセスするために承認を証明するためにユーザ名とパスワード議論と共にHELOコマンドを送ります。 サーバはデフォルトメールボックスの中のメッセージの数を返します。
The client may read the default mailbox associated with the user
name or may select another mailbox by using the FOLD command. The
server returns the number of messages in the mailbox selected.
クライアントは、ユーザ名に関連しているデフォルトメールボックスを読むか、またはFOLDコマンドを使用することによって、別のメールボックスを選択するかもしれません。 サーバは選択されたメールボックスの中のメッセージの数を返します。
The client begins a message reading transaction with a READ
command. The read command may optionally indicate which message
number to read, the default is the current message (incremented
when a message is read and set to one when a new folder is
selected). The server returns the number of characters in the
message.
クライアントはREADコマンドでメッセージ読書トランザクションを始めます。 読みコマンドは、どのメッセージ番号を読んだらよいかを任意に示すかもしれなくて、デフォルトは現在のメッセージ(メッセージが読まれるとき、増加されて、新しいフォルダーが選択されるとき、1つに設定される)です。 サーバはメッセージのキャラクタの数を返します。
Butler, et. al. [Page 2]
etバトラー、アル。 [2ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
The client asks for the content of the message to be sent with the
RETR command. The server sends the message data.
クライアントはRETRコマンドと共に送られるべきメッセージの内容を求めます。 サーバはメッセージデータを送ります。
When all the data has been received the client sends an
acknowledgment command. This is one of ACKS, ACKD, and NACK.
すべてのデータを受け取ったとき、クライアントは承認命令を送ります。 これはACKS、ACKD、およびナックのひとりです。
ACKS means "I've received the message successfully and please
keep it in the mailbox".
ACKSは、「私は、首尾よくメッセージを受け取って、メールボックスの中にそれを保ってください。」と意味します。
ACKD means "I've received the message successfully and please
delete it from the mailbox".
ACKDは、「私は、首尾よくメッセージを受け取って、メールボックスからそれを削除してください。」と意味します。
NACK means "I did not receive the message and please keep it in
the mailbox".
「私は、メッセージを受け取って、メールボックスの中にそれを保たないでください、そうした。」と、ナックは言っています。
In the case of ACKS or ACKD the server increments the current
message indicator. In the case of NACK the current message
indicator stays the same.
ACKSかACKDの場合では、サーバは現在のメッセージインディケータを増加します。 ナックの場合では、現在のメッセージインディケータは同じ状態で残っています。
In all cases the server returns the number of characters in the
(now) current message.
すべての場合では、サーバは(現在、)現在のメッセージのキャラクタの数を返します。
The client terminates the session with the QUIT command. The
server returns an ok.
クライアントはQUITコマンドとのセッションを終えます。 サーバはOKを返します。
Butler, et. al. [Page 3]
etバトラー、アル。 [3ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
The Normal Scenario
正常なシナリオ
Client Server
------ ------
Wait for Connection
Open Connection -->
<-- + POP2 Server Ready
Wait for Command
HELO Fred Secret -->
<-- #13 messages for you
Wait for Command
READ 13 -->
<-- =537 characters in that message
Wait for Command
RETR -->
<-- (send the message data)
Wait for Command
ACKS -->
<-- =0 no more messages
Wait for Command
QUIT -->
<-- + OK
Close connection --> <-- Close connection
Wait for Connection (go back to start)
クライアントサーバ------ ------ Command ACKS(><)がCommand QUIT--><--+のために、より多くのメッセージの0ノーWaitと等しいので、ConnectionオープンConnectionのための待ち--><--+ Command HELOフレッドSecretのためのPOP2 Server Ready Wait--><--あなたのためのCommand RETR(><)のためのそのメッセージWait(メッセージデータを送る)の537のCommand READ13(><)のためのWait=キャラクタが待つ#13メッセージはConnectionのためにClose接続--><--浅からぬ関係Waitを承認します。(始まるように、戻ります)
Conventions
コンベンション
Arguments
議論
These arguments have system specific definitions.
これらの議論には、システムの特定の定義があります。
user - A login account name.
ユーザ--ログインアカウント名。
password - The password for the login account.
パスワード--ログインアカウントのためのパスワード。
mailbox - A mailbox name (also called a mail folder).
メールボックス--メールボックス名(また、メール・フォルダと呼ばれます)。
Butler, et. al. [Page 4]
etバトラー、アル。 [4ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Default Mailboxes
デフォルトメールボックス
TOPS-20
先端-20
MAIL.TXT.1 - from login directory
ログインディレクトリからのMAIL.TXT.1
UNIX
UNIX
both
/usr/spool/mail/user
and
/usr/user/Mail/inbox/*
/usr/spool/mail/userと/usr/user/Mail/inbox/*の両方
where "user" is the user value supplied in the HELO command.
「ユーザ」が値がHELOで供給したユーザであるところでは、命令してください。
End of Line
行末
End of Line is Carriage Return (CR) followed by Line Feed (LF).
This sequence is indicated by "CRLF" in this document. This end
of line convention must be used for commands and replies.
線の端は線Feed(LF)によっていうことになられたCarriage Return(CR)です。 この系列は"CRLF"によって本書では示されます。 コマンドと回答にこの行末コンベンションを使用しなければなりません。
Message Length
メッセージ長
The reply to the READ command or an acknowledgment command (ACKS,
ACKD, NACK) is the length (a character count) of the next message
to be transmitted. This includes all the characters in the data
transmitted. CRLF counts as two characters. A length of zero
means the message does not exist or is empty. A request to
transmit a message of zero length will result in the server
closing the connection. The message is transmitted in the
standard internet format described in RFC-822 [2] and NVT-ASCII.
This may be different from the storage format and may make
computing the message length from the stored message non-trivial.
READコマンドか承認命令(ACKS、ACKD、ナック)に関する回答は次の伝えられるべきメッセージの長さ(キャラクタカウント)です。 これはデータのキャラクタが伝えたすべてを含んでいます。 CRLFは2つのキャラクタにみなします。 ゼロの長さは、メッセージが存在していないか、または空であることを意味します。 ゼロ・レングスに関するメッセージを送るという要求は接続を終えるサーバをもたらすでしょう。 メッセージはRFC-822[2]とNVT-ASCIIで説明された標準のインターネット形式で送られます。 これで、ストレージ形式と異なるかもしれなくて、保存されたメッセージからメッセージ長を計算するのは重要になるかもしれません。
Message Numbers
メッセージ番号
The reply to the HELO and FOLD commands is a count of the number
of messages in a the selected mailbox. The READ command has a
message number as an optional argument. These numbers are
decimal, start at one, and computed with respect to the current
mailbox. That is, the first message in a mailbox is message
number 1.
HELOとFOLDコマンドに関する回答が中のメッセージの数のカウントである、選択されたメールボックス READコマンドには、任意の議論としてメッセージ番号があります。 これらの数は小数、1つであり、現在のメールボックスに関して計算されるところの始めです。 すなわち、メールボックスにおける最初のメッセージはメッセージ番号1です。
Numbers
数
All numbers in this memo and protocol are decimal.
このメモとプロトコルのすべての数が10進です。
Butler, et. al. [Page 5]
etバトラー、アル。 [5ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Quoting
引用
In a few cases, there may be a need to have a special character in
an argument (user, password, or mailbox) that is not allowed by
the syntax. For example, a space in a password. To allow for
this, a quoting convention is defined. Unfortunately, such
quoting conventions "use up" another otherwise uninteresting
character. In this protocol the back slash "\" is used as the
quote character. To include a space in an argument the two
character sequence "back-slash, space" is transmitted. To include
a back-slash in an argument the two character sequence
"back-slash, back-slash" is transmitted. This quoting convention
is used in the command arguments only, it is not used in the mail
data transmitted in response to a RETR command.
いくつかの場合には、構文で許されていない主張(ユーザ、パスワード、またはメールボックス)には特殊文字を持つ必要があるかもしれません。 例えば、パスワードのスペース。 これを考慮するために、引用コンベンションは定義されます。 残念ながら、そのような引用コンベンションは別のそうでなければ、おもしろくないキャラクタを「使いきります」。 このプロトコルでは、逆スラッシュ「\」は引用文字として使用されます。 2キャラクタが配列する議論にスペースを含むように、「バックスラッシュ、スペース」は伝えられます。 2キャラクタが配列する議論にバックスラッシュを含むように、「バックスラッシュ、バックスラッシュ」は伝えられます。 これが、コンベンションがコマンド議論だけに使用されるのを引用して、それはRETRコマンドに対応して送られたメールデータで使用されません。
Reply Strings
回答ストリング
The first character is required to be as specified (i.e.,
"+", "-", "=", "#"). The optional strings that follow can be
whatever the implementer thinks is appropriate.
指定(すなわち、「+」、「-」、「=」、「#」)にされるとして最初のキャラクタがなければなりません。 続く任意のストリングはimplementerが適切であると考えることなら何でもであることができます。
Definitions of Commands and Replies
コマンドと回答の定義
Summary of Commands and Replies
コマンドと回答の概要
Commands Replies
-------- -------
HELO user password + OK
FOLD mailbox - Error
READ [n] #xxx
RETR =yyy
ACKS
ACKD
NACK
QUIT
回答を命令します。-------- ------- HELOユーザパスワード+OK FOLDメールボックス--誤りREAD[n]#xxx RETR =yyy ACKS ACKD NACK QUIT
Butler, et. al. [Page 6]
etバトラー、アル。 [6ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Commands
コマンド
HELO user password
HELOユーザパスワード
The Hello command identifies the user to the server and carries
the password authenticating this user. This information is
used by the server to control access to the mailboxes. The
Hello command is the "HELO" keyword, followed by the user
argument, followed by the password argument, followed by CRLF.
Helloコマンドは、サーバにユーザを特定して、このユーザを認証しながら、パスワードを運びます。 この情報はサーバによって使用されて、メールボックスへのアクセスを制御します。 HelloコマンドはCRLFによって続かれたパスワード議論があとに続いたユーザ議論がいうことになった"HELO"キーワードです。
Possible responses:
可能な応答:
"#nnn"
「#nnn」
where nnn is the number of messages in the default
mailbox,"
「nnnがデフォルトメールボックスの中のメッセージの数であるところ」
"- error report" and Close the connection.
「--誤りは報告し」て、Closeは接続を報告します。
FOLD mailbox
FOLDメールボックス
The Folder command selects another mailbox or mail folder. The
server must check that the user is permitted read access to
this mailbox. If the mailbox is empty or does not exist, the
number of messages reported is zero. The Folder command is the
"FOLD" keyword, followed by the mailbox argument, followed by
CRLF.
Folderコマンドは別のメールボックスかメール・フォルダを選択します。 サーバは、このメールボックスへのアクセスが読まれて、ユーザが受入れられるのをチェックしなければなりません。 メールボックスが空であるか、または存在していないなら、報告されたメッセージの数はゼロです。 FolderコマンドはCRLFによって続かれたメールボックス議論がいうことになった「折り目」キーワードです。
Possible responses:
可能な応答:
"#nnn"
「#nnn」
where nnn is the number of messages in this mailbox.
nnnがこのメールボックスの中のメッセージの数であるところ。
READ [nnn]
読んでください。[nnn]
The Read command begins a message reading transaction. If the
Read command is given without an argument the current message
is implied (the current message indicator is incremented by
the ACKS or ACKD commands). If an argument is used with the
Read command it is the message number to be read, and this
command sets the current message indicator to that value. The
server returns the count of characters in the message to be
transmitted. If there is no message to be read, the count of
zero is returned. If the message was previously deleted with
the ACKD command, the count of zero is returned. The Read
command is followed by the RETR command, the READ command, the
FOLD command, or the QUIT command. Do not attempt to RETR a
Readコマンドはメッセージ読書トランザクションを始めます。 議論なしでReadコマンドを与えるなら、現在のメッセージを含意します(現在のメッセージインディケータはACKSかACKDコマンドで増加されます)。 議論がReadコマンドと共に使用されるなら、それは読まれるメッセージ番号です、そして、このコマンドは現在のメッセージインディケータをその値に設定します。 サーバは伝えられるべきメッセージにおける、キャラクタのカウントを返します。 読まれるべきメッセージが全くなければ、ゼロのカウントを返します。 以前にACKDコマンドでメッセージを削除したなら、ゼロのカウントを返します。 RETRコマンド、READコマンド、FOLDコマンド、またはQUITコマンドがReadコマンドのあとに続いています。 RETRにaを試みないでください。
Butler, et. al. [Page 7]
etバトラー、アル。 [7ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
message of zero characters. The Read command is the "READ"
keyword, optionally followed by the message number argument,
followed by CRLF.
キャラクタがないメッセージ。 Readコマンドは「読んでください」というCRLFによって続かれたメッセージ番号議論が任意にいうことになったキーワードです。
Possible responses:
可能な応答:
"=ccc"
「cccと等しいです」
where ccc is the number of characters in this message.
cccがこのメッセージのキャラクタの数であるところ。
RETR
RETR
The Retrieve command confirms that the client is ready to
receive the mail data. It must be followed by an
acknowledgment command. The server will close the connection
if asked to transmit a message of zero characters (i.e.,
transmit a non-existent message). The message is transmitted
according to the Internet mail format standard RFC-822 [2] in
NVT-ASCII. The Retrieve command is the "RETR" keyword,
followed by CRLF.
Retrieveコマンドは、クライアントをメールデータを受け取る準備ができていると確認します。 承認命令はそれのあとに続かなければなりません。 キャラクタがないメッセージを送るように頼まれると、サーバは接続を終えるでしょう(すなわち、実在しないメッセージを送ってください)。 インターネットメール書式の標準のRFC-822[2]に応じて、メッセージはNVT-ASCIIで送られます。 RetrieveコマンドはCRLFによっていうことになられた"RETR"キーワードです。
Possible responses:
可能な応答:
the message data
メッセージデータ
Close the connection
接続を終えてください。
ACKS
ACKS
The Acknowledge and Save command confirms that the client has
received and accepted the message. The ACKS command ends the
message reading transaction. The message is kept in the
mailbox. The current message indicator is incremented. The
server returns the count of characters in the now current
message to be transmitted. If there is no message to be read
or the message is marked deleted, the count of zero is
returned. The Acknowledge and Save command is the "ACKS"
keyword, followed by CRLF.
Acknowledgeと上書き保存コマンドは、クライアントがメッセージを受け取って、受け入れたと確認します。 ACKSコマンドはメッセージ読書トランザクションを終わらせます。 メッセージはメールボックスの中に保たれます。 現在のメッセージインディケータは増加されています。 サーバは伝えられるべき現在、現在のメッセージにおける、キャラクタのカウントを返します。 読まれるべきメッセージが全くないか、または削除されているとメッセージをマークするなら、ゼロのカウントを返します。 Acknowledgeと上書き保存コマンドはCRLFによっていうことになられた「ACKS」キーワードです。
Possible responses:
可能な応答:
"=ccc"
「cccと等しいです」
where ccc is the number of characters in the next
message.
cccが次のメッセージのキャラクタの数であるところ。
Butler, et. al. [Page 8]
etバトラー、アル。 [8ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
ACKD
ACKD
The Acknowledge and Delete command confirms that the client has
received and accepted the message. The ACKD command ends the
message reading transaction. If the user is authorized to have
write access to the mailbox, the message is deleted from the
mailbox. Actually, the message is only marked for deletion.
The actual change is made when the mailbox is released at the
end of the session or when the client selects another mailbox
with the FOLD command. The messages are not renumbered until
the mailbox is released. If the user does not have write
access to the mailbox no change is made to the mailbox. The
response is the same whether or not the message was actually
deleted. The current message indicator is incremented. The
server returns the count of characters in the now current
message to be transmitted. If there is no message to be read
or the message is marked deleted, the count of zero is
returned. The Acknowledge and Delete command is the "ACKD"
keyword, followed by CRLF.
AcknowledgeとDeleteコマンドは、クライアントがメッセージを受け取って、受け入れたと確認します。 ACKDコマンドはメッセージ読書トランザクションを終わらせます。 ユーザがメールボックスへのアクセスを書かせるために認可されているなら、メッセージはメールボックスから削除されます。 実際に、メッセージは削除のためにマークされるだけです。 メールボックスが終わりにセッションかクライアントがFOLDコマンドがある別のメールボックスを選択するときに時リリースされるのに、実際の変更は行われます。 メールボックスがリリースされるまで、メッセージは番号を付け替えられません。 ユーザは変更が全くされないメールボックスへのアクセスをメールボックスに書かせません。 メッセージが実際に削除されたか否かに関係なく、応答は同じです。 現在のメッセージインディケータは増加されています。 サーバは伝えられるべき現在、現在のメッセージにおける、キャラクタのカウントを返します。 読まれるべきメッセージが全くないか、または削除されているとメッセージをマークするなら、ゼロのカウントを返します。 AcknowledgeとDeleteコマンドはCRLFによっていうことになられた"ACKD"キーワードです。
Possible responses:
可能な応答:
"=ccc"
「cccと等しいです」
where ccc is the number of characters in the next
message.
cccが次のメッセージのキャラクタの数であるところ。
NACK
ナック
The Negative Acknowledge command reports that the client did
not receive the message. The NACK command ends the message
reading transaction. The message is kept in the mailbox. The
current message indicator remains the same. The server returns
the count of characters in the current message. Since the
count to be returned is for the message just transmitted it the
message must exist and not be marked deleted, and the count
must be positive (non-zero). The Negative Acknowledge command
is the "NACK" keyword, followed by CRLF.
Negative Acknowledgeはクライアントがメッセージを受け取らなかったというレポートを命令します。 ナックコマンドはメッセージ読書トランザクションを終わらせます。 メッセージはメールボックスの中に保たれます。 現在のメッセージインディケータは同じままで残っています。 サーバは現在のメッセージにおける、キャラクタのカウントを返します。 返されるカウントがメッセージがただそれを伝えたからであるメッセージは、存在していて、削除されているとマークされてはいけません、そして、カウントは確信しているに違いありません(非ゼロの)。 Negative AcknowledgeコマンドはCRLFによっていうことになられた「ナック」キーワードです。
Possible responses:
可能な応答:
"=ccc"
「cccと等しいです」
where ccc is the number of characters in this message.
cccがこのメッセージのキャラクタの数であるところ。
Butler, et. al. [Page 9]
etバトラー、アル。 [9ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
QUIT
やめてください。
The Quit command indicates the client is done with the session.
The server sends an OK response and then closes the connection.
The Quit command is the "QUIT" keyword, followed by CRLF.
Quitコマンドは、クライアントがセッションを終えているのを示します。 サーバは、OK応答を送って、次に、接続を終えます。 Quitコマンドは「やめてください」というCRLFによっていうことになられたキーワードです。
Possible responses:
可能な応答:
"+ OK" and Close the connection
「+ OK」と接続のClose
Replies
返信
Greeting
挨拶
The greeting is sent by the server as soon as the connection is
established. The greeting is a plus sign, followed by the
protocol name ("POP2"), followed by the server host name,
optionally followed by text, and ending with a CRLF.
接続が確立されるとすぐに、サーバは挨拶を送ります。 挨拶がプロトコル名がいうことになったプラスサインである、(「POP2") サーバホスト名があとに続いていて、テキストが任意にあとに続いていて、CRLFと共に終わること」。
+
+
The success or plus sign response indicates successful
completion of the operation specified in the command. The
success response is a plus sign, optionally followed by text,
and ending with a CRLF.
成功かプラスサイン応答が、操作の無事終了がコマンドで指定したのを示します。 テキストが任意にあとに続いていて、CRLFと共に終わって、成功応答はプラスサインです。
-
-
The failure or minus sign response indicates the failure of the
operation specified in the command. The failure response is a
minus sign, optionally followed by text, and ending with a
CRLF.
失敗かマイナス記号応答が、操作の失敗がコマンドで指定したのを示します。 テキストが任意にあとに続いていて、CRLFと共に終わって、失敗応答はマイナス記号です。
=
=
The length or equal sign response tells the length in
characters of the message referenced by the command. The
length response is a equal sign, followed by a number,
optionally followed by text, and ending with a CRLF.
長さか等号応答がコマンドで参照をつけられるメッセージのキャラクタの長さを言います。 数があとに続いていて、テキストが任意にあとに続いていて、CRLFと共に終わって、長さの応答は等号です。
#
#
The count or number sign response tells the number of messages
in a folder or mailbox referenced by the command. The count
response is a number sign, followed by a number, optionally
followed by text, and ending with a CRLF.
カウントかナンバー記号応答がコマンドで参照をつけられるフォルダーかメールボックスの中のメッセージの数を言います。 数があとに続いていて、テキストが任意にあとに続いていて、CRLFと共に終わって、カウント応答はナンバー記号です。
Butler, et. al. [Page 10]
etバトラー、アル。 [10ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Timeouts
タイムアウト
In any protocol of this type there have to be timeouts. Neither
side wants to get stuck waiting forever for the other side
(particularly is the other side has gone crazy or crashed).
このタイプのどんなプロトコルにも、タイムアウトがなければなりません。 もう片方がいつまでも待ちながら立ち往生するどちらのサイド必需品も面がありません(特に、反対側が気が狂っているか、またはダウンしたということです)。
The client expects a reply to a command fairly quickly and so
should have a short timeout for this. This timeout is called T1.
クライアントには、かなりすぐにコマンドに回答を予想するので、短いタイムアウトがこれのためにあるべきです。 このタイムアウトはT1と呼ばれます。
For some servers, it may take some processing to compute the
number of messages in a mailbox, or the length of a message, or
to reformat a stored message for transmission, so this time out
has to allow for such processing time. Also care must be taken
not to timeout waiting for the completion of a RETR reply while
a long message is in fact being transfered.
いくつかのサーバに関しては、メールボックスの中のメッセージの数、メッセージの長さ、またはトランスミッションのための再フォーマットへの保存されたメッセージを計算するのに何らかの処理を要するかもしれないので、このタイムアウトはそのような処理時間を考慮しなければなりません。 また、事実上、長いメッセージがtransferedされている間にRETR回答の完成を待つどんなタイムアウトにも注意してはいけません。
The server expects the session to progress with some but not
excessive delay between commands and so should have a long timeout
waiting for the next command. This time out is T2.
サーバには、セッションが過度の遅れではなく、コマンドの間のいくつかで進歩すると予想するので、次のコマンドを待つ長いタイムアウトがあるべきです。 このタイムアウトはT2です。
One model of use of this protocol is that any number of
different types of clients can be built with different ways of
interacting with the human user and the server, but still
expecting the client to open the connection to the server,
present a sequence of commands, and close the connection,
without waiting for intervention by the human user. With such
client implementations, it is reasonable for the server to have
a fairly small value for timeout T2.
このプロトコルで役に立つ1つのモデルは人間のユーザとサーバと対話する異なった方法でいろいろな異なったタイプのクライアントを建てることができるということですが、人間のユーザによる介入を待たないで、クライアントがサーバに接続を開くとまだ予想していて、コマンドの系列を提示してください、そして、接続を終えてください。 そのようなクライアント実装に、サーバにはタイムアウトT2のためのかなり小さい値があるのは、妥当です。
On the other hand, one could easily have the client be very
human user directed with the user making decisions between
commands. This would cause arbitrary delays between client
commands to the server, and require the value of timeout T2 to
be quite large.
他方では、1つは、クライアントがユーザがコマンドの間で決定をしていて指示された非常に人間のユーザであることを容易に持っているかもしれません。 これは、クライアントコマンドの間の任意の遅れをサーバに引き起こして、タイムアウトT2の値がかなり大きいのを必要とするでしょう。
Implementation Discussion
実装議論
Comments on a Server on TOPS-20
先端-20に関するサーバのコメント
On TOPS-20, a mailbox is a single file. New messages are appended
to the file. There is a separator line between messages.
TOPS-20の上では、メールボックスは一列です。 新しいメッセージをファイルに追加します。 メッセージの間には、区切り線があります。
The tricky part of implementing a POP2 server on TOPS-20 is to
provide for deleting messages. This only has to be done for the
mailboxes (files) for which the user has write access. The
problem is to avoid both (1) preventing other users from accessing
or updating the mailbox for long periods, and (2) accidentally
deleting a message the user has not seen.
TOPS-20でPOP2サーバを実装する油断のならない部分はメッセージを削除するのに提供することです。 ユーザが持っているものがアクセサリーを書くので、メールボックス(ファイル)のためにこれをするだけでよいです。 問題が(1) 他のユーザが長期の間、メールボックスをアクセスするか、またはアップデートするのを防ぎながら両方を避けることであり、(2) 偶然メッセージを削除して、ユーザは見ていません。
Butler, et. al. [Page 11]
etバトラー、アル。 [11ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
One suggestion is as follows:
1つの提案は以下の通りです:
When a mailbox is first selected, if the user has write access,
rename the mailbox file to some temporary name. Thus new
messages will be placed in a new instance of the mailbox file.
Conduct all POP2 operation on the temporary mailbox file
(including deleting messages). When the POP2 session is over
or another mailbox is selected, prepend any messages left
undeleted in the temporary file to the new instance of the
mailbox file.
ユーザがそうしたなら、メールボックスが最初に選択されたらアクセスを書いてください、そして、何らかの一時的な名前にメールボックスファイルを改名してください。 したがって、新しいメッセージはメールボックスファイルの新しいインスタンスに置かれるでしょう。 一時的なメールボックスファイルの上ですべてのPOP2操作を行ってください(メッセージを削除するのを含んでいて)。 POP2セッションがいつ、終わっているか、そして、別のメールボックスが選択されます、どんなメッセージも一時ファイルで非削除するようにメールボックスファイルの新しいインスタンスに残したprepend。
Sizes
サイズ
The maximum length of a command line is 512 characters (including
the command word and the CRLF).
コマンドラインの最大の長さは512のキャラクタ(コマンド単語とCRLFを含んでいて)です。
The maximum length of a reply line is 512 characters (including
the success indicator (+, -, =, #) and the CRLF).
そして、回答系列の最大の長さが512のキャラクタである、(成功インディケータを含んでいる、(+、-、=、#)、CRLF)
The maximum length of a text line is 1000 characters (including
CRLF).
テキスト系列の最大の長さは1000のキャラクタ(CRLFを含んでいて)です。
ISI has developed a POP2 server for TOPS-20 and for Berkeley 4.2 Unix, and a POP2 client for an IBM-PC and for Berkeley 4.2 Unix.
ISIはPOP2サーバがTOPS-20とバークレー4.2Unixのために開発されて、IBM-PCとバークレー4.2UnixのためにPOP2クライアントを開発されました。
Extensions Not Supported
サポートされなかった拡大
POP2 does not examine the internal data of messages. In particular, the server does not parse message headers.
POP2はメッセージの内部のデータを調べません。 特に、サーバはメッセージヘッダーを分析しません。
The server doesn't have any state information (i.e., it doesn't know from one session to the next what has happened). For example, the server doesn't know which messages were received since the last time the user used POP2, so it can't send just the "new" messages.
サーバには、少しの州の情報もありません(すなわち、それは、何が起こったかを1つのセッションから次まで知りません)。 例えば、サーバは、したがって、ユーザが前回POP2を使用したときまさしく「新しい」メッセージを送ることができないのでどのメッセージが受け取られたかを知りません。
Butler, et. al. [Page 12]
etバトラー、アル。 [12ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Examples
例
Example 1:
例1:
Client Server
------ ------
Wait for connection
Open connection -->
<-- + POP2 USC-ISIF.ARPA Server
HELO POSTEL SECRET -->
<-- #2 messages in your mailbox
READ -->
<-- =537 characters in message 1
RETR -->
<-- [data of message 1]
ACKD -->
<-- =234 characters in message 2
RETR -->
<-- [data of message 2]
ACKD -->
<-- =0 no more messages
QUIT -->
<-- + OK, bye, bye
Close connection --> <-- Close connection
Go back to start
クライアントサーバ------ ------ 接続オープン接続--><--+ POP2 USC-ISIF.ARPA Server HELO POSTEL SECRETのための待ち--><--#537のREAD(><)=キャラクタが中で1RETR--><--データを通信させるあなたのメールボックスの中の2つのメッセージが1ACKDを通信させます--><; 2RETR--><--2ACKD(><)が、より多くのメッセージの0ノーQUITと等しいというメッセージに関するデータ--><--+ OK、さようなら、さようなら、Close接続--><--浅からぬ関係Goが始まるように支持するメッセージの234のキャラクタと等しいです。
Butler, et. al. [Page 13]
etバトラー、アル。 [13ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Example 2:
例2:
Client Server
------ ------
Wait for connection
Open connection -->
<-- + POP2 ISI-VAXA.ARPA server here
HELO smith secret -->
<-- #35 messages
FOLD /usr/spool/mail/smith -->
<-- #27 messages
READ 27 -->
<-- =10123 characters in that message
RETR -->
<-- [data of message 27]
ACKS -->
<-- =0 no more messages
QUIT -->
<-- + bye, call again sometime.
Close connection --> <-- Close connection
Go back to start
クライアントサーバ------ ------ より多くのメッセージの0そのメッセージRETRの10123のREAD27(><)=キャラクタ--><--接続オープン接続--><--+ ここのHELO鍛冶屋秘密--><--#35メッセージFOLD/usr/が/鍛冶屋にスプールするか、または郵送するPOP2 ISI-VAXA.ARPAサーバ--><--#27メッセージ[メッセージ27に関するデータ]ACKS(><)=ノーQUIT--><--+ さようならを待ってください、そして、いつか、もう一度電話をしてください。 始まるように接続--><--浅からぬ関係Go後部を閉じてください。
Example 3:
例3:
Client Server
------ ------
Wait for connection
Open connection -->
<-- + POP2 ISI-VAXA.ARPA server here
HELO Jones secret -->
<-- #0 messages
READ -->
<-- Close connection
Close connection -->
Go back to start
クライアントサーバ------ ------ 待ち、接続オープン接続--><--+ ここのPOP2 ISI-VAXA.ARPAサーバのために、HELOジョーンズ秘密--><--#0、はREADを通信させます--><--浅からぬ関係Close接続-->Goは、始まるのを支持します。
Butler, et. al. [Page 14]
etバトラー、アル。 [14ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Formal Syntax
正式な構文
<digit> = 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<ケタ>=0| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
<letter> = A | B | C | ... | Z
a | b | c | ... | z
<手紙>=A| B| C| ... | Z a| b| c| ... | z
<punct> = ! | " | # | $ | % | & | ' | ( | ) | * |
+ | , | - | / | : | < | = | > | ? | @ |
[ | ] | ^ | _ | ` | { | | | } | ~
<punct>=!| " | # | $ | % | & | ' | ( | ) | * | + | , | - | / | : | <| =| >|、--| @ | [ | ] | ^ | _ | ` | { | | | } | ~
<quote> = \
<引用文の>は\と等しいです。
<any> = any one of the 128 ASCII codes
128ASCIIのどんな>も=いずれもコード化する<。
<CR> = carriage return, code 10
<CR>は復帰、コード10と等しいです。
<LF> = line feed, code 13
<LF>は改行、コード13と等しいです。
<SP> = space, code 32
<SP>はスペース、コード32と等しいです。
<CRLF> = <CR> <LF>
<CRLF>は<CR><LF>と等しいです。
<print> = <letter> | <digit> | <punct> | <quote> <any>
<印刷>は<手紙>と等しいです。| <ケタ>。| <punct>。| <引用文の><はあらゆる>です。
<char> = <print> | <SP>
<炭の>は<印刷>と等しいです。| <SP>。
<word> = <print> | <print> <word>
<単語>は<印刷>と等しいです。| <印刷><単語>。
<string> = <char> | <char> <string>
<ストリング>は<炭の>と等しいです。| <炭の><ストリング>。
<ld> = <letter> | <digit>
<ld>は<手紙>と等しいです。| <ケタ>。
<ldh> = <letter> | <digit> | -
<ldh>は<手紙>と等しいです。| <ケタ>。| -
<ldhs> = <ldh> | <ldh> <ldhs>
<ldhs>は<ldh>と等しいです。| <ldh><ldhs>。
<name> = <letter> [ [ <ldhs> ] <ld> ]
<名前>は<手紙>と等しいです。[[<ldhs>]<ld>]
<host> = <name> | <name> . <host>
<ホスト>は<名前>と等しいです。| <名前><ホスト>。
<user> = <word>
<ユーザ>=<単語>。
<password> = <word>
<パスワード>=<単語>。
<mailbox> = <string>
<メールボックス>=<ストリング>。
<number> = <digit> | <digit> <number>
<番号>は<ケタ>と等しいです。| <ケタ><番号>。
Butler, et. al. [Page 15]
etバトラー、アル。 [15ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
<helo> = HELO <SP> <user> <SP> <password> <CRLF>
<helo>はHELO<SP><ユーザ><SP><パスワード><CRLF>と等しいです。
<fold> = FOLD <SP> <mailbox> <CRLF>
<折り目の>は折り目の<SP><メールボックス><CRLF>と等しいです。
<read> = READ [<SP> <number>] <CRLF>
<CRLF>が読まれた[<SP><番号>]>=が読まれた<。
<retr> = RETR <CRLF>
<retr>はRETR<CRLF>と等しいです。
<acks> = ACKS <CRLF>
<acks>はACKS<CRLF>と等しいです。
<ackd> = ACKD <CRLF>
<ackd>はACKD<CRLF>と等しいです。
<nack> = NACK <CRLF>
<nack>はナック<CRLF>と等しいです。
<quit> = QUIT <CRLF>
<、やめられて、>=は<CRLF>をやめました。
<ok> = + [<SP> <string>] <CRLF>
<の間違いない>は+ [<SP><ストリング>]<CRLF>と等しいです。
<err> = - [<SP> <string>] <CRLF>
<が間違える、>=--、[<SP><ストリング>]<CRLF>。
<count> = # <number> [<SP> <string>] <CRLF>
<カウント>は#<番号>[<SP><ストリング>]<CRLF>と等しいです。
<greet> = + <SP> POP2 <SP> <host> [<SP> <string>] <CRLF>
<は>=+<SP>POP2<SP><ホスト>[<SP><ストリング>]<CRLF>に挨拶します。
<length> = = <number> [<SP> <string>] <CRLF>
<長さの>=は<番号>[<SP><ストリング>]<CRLF>と等しいです。
<command> = <helo> | <fold> | <read> | <retr> |
<acks> | <ackd> | <nack> | <quit>
<コマンド>は<helo>と等しいです。| <折り目の>。| >が読まれた<。| <retr>。| <acks>。| <ackd>。| <nack>。| <は>をやめました。
<reply> = <ok> | <err> | <count> | <length> | <greet>
<回答>は<の間違いない>と等しいです。| <が間違える、>。| <カウント>。| <の長さの>。| <は>に挨拶します。
Butler, et. al. [Page 16]
etバトラー、アル。 [16ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Client State Diagram
属国ダイヤグラム
| ^ + BYE
| Open | -----
| Greet | Close
V ----- |
+-------+ QUIT +-------+
| CALL |-------------->| EXIT |
+-------+ +-------+
| ^
| Greet |
| ----- |
| HELO |
+---->+ | |
#NNN ^ | | #NNN |
---- | V V ---- |
FOLD | +-------+ QUIT |
+<---| NMBR |--------------------->+
+-------+ ^
^ | |
| | #NNN |
| | ---- |
=CCC | | READ |
---- | | |
FOLD | | =CCC |
| V ---- |
=CCC +--->+-------+ QUIT |
---- ^ | SIZE |--------------------->+
READ +<---+-------+
^ |
| | =CCC
data | | ----
---- | | RETR
ack | |
| V
+-------+
| XFER |
+-------+
| ^ + BYE | 開いてください。| ----- | 挨拶します。| Vを閉じてください。----- | +-------+は+をやめます。-------+ | 呼び出し|、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 出口| +-------+ +-------+ | ^ | 挨拶します。| | ----- | | HELO| +---->+| | #NNN^| | #NNN| ---- | V V---- | 折り目| +-------やめられた+| + <。---| NMBR|--------------------->++-------+ ^ ^ | | | | #NNN| | | ---- | =CCC| | 読んでください。| ---- | | | 折り目| | =CCC| | V---- | =CCC+--->+-------やめられた+| ---- ^ | サイズ|---------------------+が+ <を読み込んだ>。---+-------+ ^ | | | =CCCデータ| | ---- ---- | | RETR ack| | | +に対して-------+ | XFER| +-------+
Butler, et. al. [Page 17]
etバトラー、アル。 [17ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Server State Diagram
サーバ州のダイヤグラム
+<----------------------+ Close
| | -----
Listen | | Close
V |
+-------+ +-------+
| LSTN | | DONE |
+-------+ +-------+
| ^
| Open |
| ----- |
| Greet |
| |
| QUIT |
V ----- |
+-------+ + BYE |
| AUTH |--------------------->+
+-------+ ^
| |
| HELO |
| ---- |
| #NNN |
| |
| QUIT |
V ----- |
FOLD +--->+-------+ + BYE |
---- ^ | MBOX |--------------------->+
#NNN +<---+-------+ ^
^ | |
| | READ |
FOLD | | ---- |
---- | | =CCC |
#NNN | | QUIT |
| V ----- |
READ +--->+-------+ + BYE |
---- ^ | ITEM |--------------------->+
=CCC +<---+-------+
^ |
| | RETR
ack | | ----
---- | | data
=CCC | |
| V
+-------+
| NEXT |
+-------+
+ <。----------------------+ 近く| | ----- 聴いてください。| | Vを閉じてください。| +-------+ +-------+ | LSTN| | します。| +-------+ +-------+ | ^ | 開いてください。| | ----- | | 挨拶します。| | | | やめてください。| V----- | +-------+ + さようなら| | AUTH|--------------------->++-------+ ^ | | | HELO| | ---- | | #NNN| | | | やめてください。| V----- | 折り目+--->+-------+ + さようなら| ---- ^ | MBOX|--------------------->+#NNN+<。---+-------+ ^ ^ | | | | 読んでください。| 折り目| | ---- | ---- | | =CCC| #NNN| | やめてください。| | V----- | +を読んでください。--->+-------+ + さようなら| ---- ^ | 項目|--------------------->+=CCC+<。---+-------+ ^ | | | RETR ack| | ---- ---- | | データ=CCC| | | +に対して-------+ | 次へ| +-------+
Butler, et. al. [Page 18]
etバトラー、アル。 [18ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Combined Flow Diagram
結合したフローチャート
+----+
|CALL|<------------------------------------------------------------+
|LSTN| ^
+----+ |
| Greet |
| |
| +----------------------------------------------------->+ |
| ^ QUIT | |
V | V |
+----+ +----+ +----+ |
|CALL| HELO |NMBR| |EXIT| |
|AUTH|------->|AUTH| |AUTH| |
+----+ +----+ +----+ |
| #NNN + Bye | |
| | |
| +------------------------------------>+ | |
| ^ QUIT | | |
V | V | |
+--->+----+ +----+ +----+ | |
FOLD ^ |NMBR| READ |SIZE| |EXIT| | |
---- | |MBOX|------->|MBOX| |MBOX| | |
#NNN +<---+----+ +----+ +----+ | |
^ | =CCC + Bye | | |
| | | | |
FOLD +<--------+ | +------------------->+ | | |
---- ^ | ^ QUIT | | | |
#NNN | V | V | | |
+--->+-----+ +----+ +----+ | | |
READ ^ |SIZE | RETR |XFER| |EXIT| | | |
---- | | ITEM|------->|ITEM| |ITEM| | | |
=CCC +<---+-----+ +----+ +----+ | | |
^ | data | | | |
| | | | | |
=CCC | V + Bye | | | |
+----+ +----+ | | | |
|SIZE| Ack |XFER| | | | |
|NEXT|<-------|NEXT| | | | |
+----+ +----+ | | | |
| | | |
| | | |
V V V |
+-------+ |
| EXIT |-->+
| DONE |
+-------+
+----+ |呼び出し|<------------------------------------------------------------+ |LSTN| ^ +----+ | | 挨拶します。| | | | +----------------------------------------------------->+| | ^やめてください。| | V| V| +----+ +----+ +----+ | |呼び出し| HELO|NMBR| |出口| | |AUTH|、-、-、-、-、-、--、>|AUTH| |AUTH| | +----+ +----+ +----+ | | #NNN+さようなら| | | | | | +------------------------------------>+| | | ^やめてください。| | | V| V| | +--->+----+ +----+ +----+ | | 折り目の^|NMBR| 読んでください。|サイズ| |出口| | | ---- | |MBOX|、-、-、-、-、-、--、>|MBOX| |MBOX| | | #NNN+<。---+----+ +----+ +----+ | | ^ | =CCC+さようなら| | | | | | | | 折り目+<。--------+ | +------------------->+| | | ---- ^ | ^やめてください。| | | | #NNN| V| V| | | +--->+-----+ +----+ +----+ | | | ^を読んでください。|サイズ| RETR|XFER| |出口| | | | ---- | | 項目|、-、-、-、-、-、--、>|項目| |項目| | | | =CCC+<。---+-----+ +----+ +----+ | | | ^ | データ| | | | | | | | | | =CCC| V+さようなら| | | | +----+ +----+ | | | | |サイズ| Ack|XFER| | | | | |次へ| <、-、-、-、-、-、--、|次へ| | | | | +----+ +----+ | | | | | | | | | | | | V V V| +-------+ | | 出口|-->+| します。| +-------+
Butler, et. al. [Page 19]
etバトラー、アル。 [19ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Client Decision Table
クライアント決定表
| STATE |
-------+----------------------------------|
INPUT | CALL | NMBR | SIZE | XFER | EXIT |
-------+----------------------------------|
Greet | 2 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
#NNN | 1 | 3 | 1 | 1 | 6 |
-------+----------------------------------|
=CCC | 1 | 1 | 4 | 1 | 6 |
-------+----------------------------------|
data | 1 | 1 | 1 | 5 | 6 |
-------+----------------------------------|
+ Bye | 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
Close | 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
other | 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
Timeout| 1 | 1 | 1 | 1 | 6 |
-------+----------------------------------|
| 状態| -------+----------------------------------| 入力| 呼び出し| NMBR| サイズ| XFER| 出口| -------+----------------------------------| 挨拶します。| 2 | 1 | 1 | 1 | 6 | -------+----------------------------------| #NNN| 1 | 3 | 1 | 1 | 6 | -------+----------------------------------| =CCC| 1 | 1 | 4 | 1 | 6 | -------+----------------------------------| データ| 1 | 1 | 1 | 5 | 6 | -------+----------------------------------| + さようなら| 1 | 1 | 1 | 1 | 6 | -------+----------------------------------| 閉鎖| 1 | 1 | 1 | 1 | 6 | -------+----------------------------------| 他| 1 | 1 | 1 | 1 | 6 | -------+----------------------------------| タイムアウト| 1 | 1 | 1 | 1 | 6 | -------+----------------------------------|
Butler, et. al. [Page 20]
etバトラー、アル。 [20ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Actions:
動作:
1. This is garbage. Send "QUIT", and go to EXIT state.
1. これはゴミです。 「やめてください」を送ってください、そして、状態を出に行ってください。
2. (a) If the greeting is right then send "HELO"
and go to NMBR state,
(b) Else send "QUIT" and go to EXIT state.
2. (a) 挨拶が正しいなら、"HELO"を送ってください、そして、「やめてください」を送るように(b) ほかにNMBRに述べて、状態を出に行きに行ってください。
3. (a) If user wants this folder and NNN > 0
then send "READ" and go to SIZE state,
(b) If user wants a this folder and NNN = 0
then send "QUIT" and go to EXIT state,
(c) If user wants a different folder
then send "FOLD" and go to NMBR state.
3. (a) 次にこのフォルダーとNNN>0が送るユーザ必需品が「読ん」で、サイズ状態に行くなら、(b) 次にこのフォルダーとNNN=0が送るユーザ必需品が「やめ」て、状態を出に行くなら、(c) ユーザが異なったフォルダーが欲しいなら、「折り目」を送ってください、そして、NMBR状態に行ってください。
4. (a) If user wants this message and CCC > 0
then send "RETR" and go to XFER state,
(b) If user wants a this message and CCC = 0
then send "QUIT" and go to EXIT state,
(c) If user wants a different message
then send "READ" and go to SIZE state.
4. (a) ユーザがこのメッセージとCCC>0が欲しいなら、"RETR"を送ってください、そして、XFER状態に行ってください、そして、(b) 次にこのメッセージとCCC=0が送るユーザ必需品が「やめ」て、状態を出に行くなら、(c) ユーザが異なったメッセージが欲しいなら、「読んでください」を送ってください、そして、サイズ状態に行ってください。
5. (a) If user wants this message kept
then send "ACKS" and go to SIZE state,
(b) If user wants a this message deleted
then send "ACKD" and go to SIZE state,
(c) If user wants a this message again
then send "NACK" and go to SIZE state.
5. (a) このメッセージがその時保ったユーザ必需品が「ACKS」を送って、サイズ状態に行くなら、削除されたこのメッセージでは、(b) ユーザがaが欲しいなら、サイズ状態、(c) ユーザがaが欲しいなら、このメッセージが次に、再び「ナック」を送って、サイズ状態に行くと次に、"ACKD"を送って、言われています。
6. Close the connection.
6. 接続を終えてください。
Butler, et. al. [Page 21]
etバトラー、アル。 [21ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Server Decision Table
サーバ決定表
| STATE
-------+-----------------------------------------
INPUT | LSTN | AUTH | MBOX | ITEM | NEXT | DONE |
-------+-----------------------------------------|
Open | 2 | 1 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|
HELO | 1 | 3 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|
FOLD | 1 | 1 | 5 | 5 | 1 | 1 |
-------+-----------------------------------------|
READ | 1 | 1 | 6 | 6 | 1 | 1 |
-------+-----------------------------------------|
RETR | 1 | 1 | 1 | 7 | 1 | 1 |
-------+-----------------------------------------|
ACKS | 1 | 1 | 1 | 1 | 8 | 1 |
-------+-----------------------------------------|
ACKD | 1 | 1 | 1 | 1 | 8 | 1 |
-------+-----------------------------------------|
NACK | 1 | 1 | 1 | 1 | 8 | 1 |
-------+-----------------------------------------|
QUIT | 1 | 4 | 4 | 4 | 1 | 1 |
-------+-----------------------------------------|
Close | 1 | 1 | 1 | 1 | 1 | 9 |
-------+-----------------------------------------|
other | 1 | 1 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|
Timeout| | 1 | 1 | 1 | 1 | 1 |
-------+-----------------------------------------|
| 状態-------+----------------------------------------- 入力| LSTN| AUTH| MBOX| 項目| 次へ| します。| -------+-----------------------------------------| 開いてください。| 2 | 1 | 1 | 1 | 1 | 1 | -------+-----------------------------------------| HELO| 1 | 3 | 1 | 1 | 1 | 1 | -------+-----------------------------------------| 折り目| 1 | 1 | 5 | 5 | 1 | 1 | -------+-----------------------------------------| 読んでください。| 1 | 1 | 6 | 6 | 1 | 1 | -------+-----------------------------------------| RETR| 1 | 1 | 1 | 7 | 1 | 1 | -------+-----------------------------------------| ACKS| 1 | 1 | 1 | 1 | 8 | 1 | -------+-----------------------------------------| ACKD| 1 | 1 | 1 | 1 | 8 | 1 | -------+-----------------------------------------| ナック| 1 | 1 | 1 | 1 | 8 | 1 | -------+-----------------------------------------| やめてください。| 1 | 4 | 4 | 4 | 1 | 1 | -------+-----------------------------------------| 閉鎖| 1 | 1 | 1 | 1 | 1 | 9 | -------+-----------------------------------------| 他| 1 | 1 | 1 | 1 | 1 | 1 | -------+-----------------------------------------| タイムアウト| | 1 | 1 | 1 | 1 | 1 | -------+-----------------------------------------|
Butler, et. al. [Page 22]
etバトラー、アル。 [22ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Actions:
動作:
1. This is garbage. Send "- error", and Close the connection.
1. これはゴミです。 発信、「-、誤り、」 接続のClose。
2. Send the greeting. Go to AUTH state.
2. 挨拶を送ってください。 AUTH状態に行ってください。
3. (a) If authorized user then send "#NNN" and go tp MBOX state,
(b) Else send "- error" and Close the connection.
3. (a) ほかの「認定ユーザであるなら、」 #NNNを送ってください」と碁のtp MBOX状態、(b)が発信する、「-、誤り、」 接続を終えてください。
4. Send "+ Bye" and go to DONE state.
4. 「」 +にさようならを送ってください」、DONE状態に行ってください。
5. Send "+NNN" and go to MBOX state.
5. 「」 + NNNを送ってください」、MBOX状態に行ってください。
6. Send "=CCC" and go to ITEM state.
6. 「=CCC」を送ってください、そして、項目状態に行ってください。
7. If message exists then send the data and got to NEXT state,
Else Close the connection.
7. メッセージが存在しているなら、その時は、データを送って、ネクスト状態、Else Closeに接続を得ました。
8. Do what ACKS/ACKD/NACK require and go to ITEM state.
8. ACKS/ACKD/ナックが必要とすることをしてください、そして、ITEM状態に行ってください。
9. Close the connection.
9. 接続を終えてください。
Butler, et. al. [Page 23]
etバトラー、アル。 [23ページ]
RFC 937 February 1985 Post Office Protocol
RFC937 1985年2月のPOP
Acknowledgment
承認
We would like to acknowledge the helpful comments that we received on the first version of POP described in RFC 918, and the draft of POP2 distributed to interested parties.
私たちがRFC918で説明された、POPの最初のバージョン、および利害関係者に広げられたPOP2の草稿のときに受信したという役立っているコメントを承諾したいと思います。
References
参照
[1] Postel, J., "Simple Mail Transfer Protocol", RFC 821, USC/Information Sciences Institute, August 1982.
[1] ポステル、J.、「簡単なメール転送プロトコル」、RFC821、科学が1982年8月に設けるUSC/情報。
[2] Crocker, D., "Standard for the Format of ARPA-Internet Text Messages", RFC 822, University of Delaware, August 1982.
[2] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、RFC822、デラウエア大学、1982年8月。
[3] Reynolds, J.K., "Post Office Protocol", RFC 918, USC/Information Sciences Institute, October 1984.
[3] レイノルズ、J.K.、「POP」、RFC918、科学が1984年10月に設けるUSC/情報。
[4] Reynolds, J.K., and J. Postel, "Assigned Numbers", RFC 923, USC/Information Sciences Institute, October 1984.
[4] USC/情報科学が1984年10月に設けるレイノルズ、J.K.、およびJ.ポステル、「規定番号」、RFC923。
Butler, et. al. [Page 24]
etバトラー、アル。 [24ページ]
一覧
スポンサーリンク
