RFC5092 日本語訳
5092 IMAP URL Scheme. A. Melnikov, Ed., C. Newman. November 2007. (Format: TXT=65197 bytes) (Obsoletes RFC2192) (Updates RFC4467) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Melnikov, Ed. Request for Comments: 5092 Isode Ltd. Obsoletes: 2192 C. Newman Updates: 4467 Sun Microsystems Category: Standards Track November 2007
ワーキンググループのA.メリニコフ、エドをネットワークでつないでください。コメントのために以下を要求してください。 5092Isode Ltd.は以下を時代遅れにします。 2192のC.ニューマンアップデート: 4467年のサン・マイクロシステムズカテゴリ: 標準化過程2007年11月
IMAP URL Scheme
IMAP URL体系
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
IMAP (RFC 3501) is a rich protocol for accessing remote message stores. It provides an ideal mechanism for accessing public mailing list archives as well as private and shared message stores. This document defines a URL scheme for referencing objects on an IMAP server.
IMAP(RFC3501)は、遠く離れたメッセージ店にアクセスするための豊かなプロトコルです。 それは個人的で共有されたメッセージ店と同様に公共のメーリングリストアーカイブにアクセスするのに理想的なメカニズムを提供します。 このドキュメントはIMAPサーバでオブジェクトに参照をつけることのURL体系を定義します。
This document obsoletes RFC 2192. It also updates RFC 4467.
このドキュメントはRFC2192を時代遅れにします。 また、それはRFC4467をアップデートします。
Melnikov & Newman Standards Track [Page 1] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. IMAP userinfo Component (iuserinfo) .............................4
3.1. IMAP Mailbox Naming Scope ..................................4
3.2. IMAP User Name and Authentication Mechanism ................4
3.3. Limitations of enc-user ....................................6
4. IMAP Server .....................................................7
5. Lists of Messages ...............................................7
6. A Specific Message or Message Part ..............................8
6.1. URLAUTH Authorized URL .....................................9
6.1.1. Concepts ............................................9
6.1.1.1. URLAUTH ....................................9
6.1.1.2. Mailbox Access Key .........................9
6.1.1.3. Authorized Access Identifier ...............9
6.1.1.4. Authorization Mechanism ...................10
6.1.1.5. Authorization Token .......................10
6.1.2. URLAUTH Extensions to IMAP URL .....................10
7. Relative IMAP URLs .............................................11
7.1. absolute-path References ..................................12
7.2. relative-path References ..................................12
8. Internationalization Considerations ............................13
9. Examples .......................................................13
9.1. Examples of Relative URLs .................................16
10. Security Considerations .......................................16
10.1. Security Considerations Specific to URLAUTH Authorized
URL ......................................................17
11. ABNF for IMAP URL Scheme ......................................17
12. IANA Considerations ...........................................21
12.1. IANA Registration of imap: URI Scheme ....................21
13. References ....................................................22
13.1. Normative References .....................................22
13.2. Informative References ...................................23
Appendix A. Sample Code............................................24
Appendix B. List of Changes since RFC 2192.........................30
Appendix C. List of Changes since RFC 4467.........................31
Appendix D. Acknowledgments........................................31
1. 序論…2 2. このドキュメントで中古のコンベンション…3 3. IMAP userinfo Component(iuserinfo)…4 3.1. IMAPメールボックス命名範囲…4 3.2. IMAPユーザ名と認証メカニズム…4 3.3. enc-ユーザの制限…6 4. IMAPサーバ…7 5. メッセージのリスト…7 6. 特定のメッセージかメッセージ部分…8 6.1. URLAUTHはURLを認可しました…9 6.1.1. 概念…9 6.1.1.1. URLAUTH…9 6.1.1.2. メールボックスアクセスキー…9 6.1.1.3. アクセス識別子を認可します…9 6.1.1.4. 承認メカニズム…10 6.1.1.5. 承認トークン…10 6.1.2. IMAP URLへのURLAUTH拡張子…10 7. 相対的なIMAP URL…11 7.1絶対パスReferences…12 7.2相対パスReferences…12 8. 国際化問題…13 9. 例…13 9.1. 相対的なURLに関する例…16 10. セキュリティ問題…16 10.1. URLAUTHに特定のセキュリティ問題はURLを認可しました…17 11. IMAP URLのためのABNFは計画します…17 12. IANA問題…21 12.1. imapのIANA Registration: URI体系…21 13. 参照…22 13.1. 標準の参照…22 13.2. 有益な参照…23付録A.はコードを抽出します…RFC2192以来の変化の24付録B.リスト…RFC4467以来の変化の30付録C.リスト…31 付録D.承認…31
1. Introduction
1. 序論
The IMAP URL scheme is used to designate IMAP servers, mailboxes, messages, MIME bodies [MIME], and search programs on Internet hosts accessible using the IMAP protocol over TCP.
IMAP URL体系は、インターネット・ホストの上でTCPの上でIMAPプロトコルを使用することでアクセスしやすい状態でIMAPサーバ、メールボックス、メッセージ、MIME本体[MIME]、および検索プログラムを指定するのに使用されます。
The IMAP URL follows the common Internet scheme syntax as defined in [URI-GEN]. If :<port> is omitted, the port defaults to 143 (as defined in Section 2.1 of [IMAP4]).
IMAP URLは[URI-GEN]で定義されるように一般的なインターネット体系構文に従います。 : <ポート>が省略されるなら、ポートは143をデフォルトとします([IMAP4]のセクション2.1で定義されるように)。
Melnikov & Newman Standards Track [Page 2] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[2ページ]。
An absolute IMAP URL takes one of the following forms:
絶対IMAP URLは以下のフォームの1つを取ります:
imap://<iserver>[/]
imap://<iserver>。[/]
imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]
imap://<iserver<enc>/メールボックス>[<uidvalidity>][<enc-検索>]
imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>
[<isection>][<ipartial>][<iurlauth>]
imap://<iserver<enc>/メールボックス>[<uidvalidity>]<iuid>[<isection>][<ipartial>][<iurlauth>]
The first form is used to refer to an IMAP server (see Section 4), the second form refers to the contents of a mailbox or a set of messages resulting from a search (see Section 5), and the final form refers to a specific message or message part, and possibly a byte range in that part (see Section 6). If [URLAUTH] extension is supported, then the final form can have the <iurlauth> component (see Section 6.1 for more details).
最初のフォームはIMAPサーバを示すのに使用されます、そして、(セクション4を見てください)2番目のフォームはメールボックスのコンテンツか検索から生じる1セットのメッセージを示します、そして、(セクション5を見てください)最終形態は特定のメッセージかメッセージ部分と、ことによるとその部分のバイト範囲を示します(セクション6を見てください)。 [URLAUTH]拡大がサポートされるなら、最終形態は<iurlauth>の部品を持つことができます(その他の詳細に関してセクション6.1を見てください)。
The <iserver> component common to all types of absolute IMAP URLs has the following syntax expressed in ABNF [ABNF]:
すべてのタイプの絶対IMAP URLに共通の<iserver>の部品で、ABNF[ABNF]に以下の構文を表します:
[iuserinfo "@"] host [ ":" port ]
[iuserinfo"@"] ホスト[「:」 ポート]
The <iserver> component is the same as "authority" defined in
[URI-GEN]. The syntax and uses of the <iuserinfo> ("IMAP userinfo
component") are described in detail in Section 3. The syntax of
<host> and <port> is described in [URI-GEN].
<iserver>の部品は[URI-GEN]で定義された「権威」と同じです。 <iuserinfo>(「IMAP userinfoの部品」)の構文と用途はセクション3で詳細に説明されます。 <ホスト>と<ポート>の構文は[URI-GEN]で説明されます。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?
This document references many productions from [URI-GEN]. When the document needs to emphasize IMAP URI-specific differences from [URI- GEN] (i.e., for parts of IMAP URIs that have more restricted syntax than generic URIs), it uses a non-terminal i<foo> to define an IMAP- specific version of the non-terminal <foo> from [URI-GEN].
このドキュメントは[URI-GEN]からの多くの創作に参照をつけます。 ドキュメントが、[URI GEN](すなわち、ジェネリックURIより多くの制限された構文を持っているIMAP URIの部品への)からIMAP URI-種差を強調する必要があると、それは、[URI-GEN]から非端末の<foo>のIMAPの特定のバージョンを定義するのに非端末i<foo>を使用します。
Note that the ABNF syntax shown in Section 11 is normative. Sections 2-6 may use a less formal syntax that does not necessarily match the normative ABNF shown in Section 11. If there are any differences between the syntax shown in Sections 2-6 and Section 11, then the syntax shown in Section 11 must be treated as authoritative. Non- syntax requirements included in Sections 2-6 are, of course, normative.
セクション11に示されたABNF構文が規範的であることに注意してください。 セクション2-6は必ずセクション11で見せられた標準のABNFに合っているというわけではないそれほど正式でない構文を使用するかもしれません。 セクション2-6とセクション11に示された構文の間には、何か違いがあれば、正式であるとしてセクション11に示された構文を扱わなければなりません。 セクション2-6に含まれていた非構文の要件はもちろん規範的です。
Melnikov & Newman Standards Track [Page 3] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[3ページ]。
3. IMAP userinfo Component (iuserinfo)
3. IMAP userinfo Component(iuserinfo)
The <iuserinfo> component conforms to the generic syntax of <userinfo> defined in [URI-GEN]. It has the following syntax expressed in ABNF [ABNF]:
<iuserinfo>の部品は[URI-GEN]で定義された<userinfo>のジェネリック構文に一致しています。 それで、ABNF[ABNF]に以下の構文を表します:
enc-user [iauth] / [enc-user] iauth
enc-ユーザ[iauth]/[encユーザ]iauth
The meaning of the different parts is described in subsections of this section.
異なった部品の意味はこのセクションの小区分で説明されます。
3.1. IMAP Mailbox Naming Scope
3.1. IMAPメールボックス命名範囲
The "enc-user" part of the "iuserinfo" component, if present, denotes mailbox naming scope. If it is absent, the IMAP URL can only reference mailboxes with globally unique names, i.e., mailboxes with names that don't change depending on the user the client authenticated as to the IMAP server. Note that not all IMAP implementations support globally unique names.
存在しているなら、"iuserinfo"コンポーネントの「enc-ユーザ」部分はメールボックス命名範囲を指示します。 それが欠けるなら、IMAP URLはすなわち、グローバルにユニークな名前がある参照メールボックスだけ、クライアントがIMAPサーバに関して認証したユーザに頼っていて、変化しない名前があるメールボックスに欠けることができます。すべてのIMAP実装がグローバルにユニークな名前をサポートするというわけではないことに注意してください。
For example, a personal mailbox described by the following URL <imap://michael@example.org/INBOX> is most likely different from a personal mailbox described by <imap://bester@example.org/INBOX>, even though both URLs use the same mailbox name.
例えば、個人的なメールボックスが以下のURL<imap: //michael@example.org/INBOX で説明した、gt;、たぶん<imap: //bester@example.org/INBOX によって説明された個人的なメールボックスと異なる、gt;、両方のURLは同じメールボックス名を使用しますが。
3.2. IMAP User Name and Authentication Mechanism
3.2. IMAPユーザ名と認証機構
The userinfo component (see [URI-GEN]) of an IMAP URI may contain an IMAP user name (a.k.a. authorization identity [SASL], "enc-user") and/or an authentication mechanism. (Note that the "enc-user" also defines a mailbox naming scope as described in Section 3.1). The IMAP user name and the authentication mechanism are used in the "LOGIN" or "AUTHENTICATE" commands after making the connection to the IMAP server.
IMAP URIのuserinfoの部品([URI-GEN]を見る)はIMAPユーザ名(通称承認のアイデンティティ[SASL]、「enc-ユーザ」)、そして/または、認証機構を含むかもしれません。 (セクション3.1で説明されるようにまた、「enc-ユーザ」が範囲を命名するメールボックスを定義することに注意します。) IMAPユーザ名と認証機構は、「ログイン」に使用されるか、または接続をIMAPサーバにした後に、コマンドを「認証します」。
If no user name and no authentication mechanism are supplied, the client MUST authenticate as anonymous to the server. If the server advertises AUTH=ANONYMOUS IMAP capability, the client MUST use the AUTHENTICATE command with ANONYMOUS [ANONYMOUS] SASL mechanism. If SASL ANONYMOUS is not available, the (case-insensitive) user name "anonymous" is used with the "LOGIN" command and the Internet email address of the end user accessing the resource is supplied as the password. The latter option is given in order to provide for interoperability with deployed servers.
ユーザ名がなくて認証機構を全く提供しないなら、クライアントはサーバへの匿名として認証しなければなりません。サーバがANONYMOUS IMAP AUTH=能力の広告を出すなら、クライアントは更生会[更生会]SASLメカニズムによるAUTHENTICATEコマンドを使用しなければなりません。 SASL更生会が利用可能でないなら、「ログイン」コマンドと共に「匿名」という(大文字と小文字を区別しない)のユーザ名を使用します、そして、パスワードとしてリソースにアクセスするエンドユーザのインターネットEメールアドレスを提供します。 配布しているサーバで相互運用性に備えるために後者のオプションを与えます。
Note that, as described in RFC 3501, the "LOGIN" command MUST NOT be used when the IMAP server advertises the LOGINDISABLED capability.
IMAPサーバがLOGINDISABLED能力の広告を出すとき、RFC3501で説明されるように「ログイン」コマンドを使用してはいけないことに注意してください。
Melnikov & Newman Standards Track [Page 4] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[4ページ]。
An authentication mechanism (as used by the IMAP AUTHENTICATE command) can be expressed by adding ";AUTH=<enc-auth-type>" to the end of the user name in an IMAP URL. When such an <enc-auth-type> is indicated, the client SHOULD request appropriate credentials from that mechanism and use the "AUTHENTICATE" command instead of the "LOGIN" command. If no user name is specified, one MUST be obtained from the mechanism or requested from the user/configuration as appropriate.
「加えることによって、認証機構(IMAP AUTHENTICATEコマンドで使用されるように)を表すことができる」; AUTHは<enc-auth-タイプ>と等しいです。」 IMAP URLのユーザ名の終わりまで。 そのような<enc-auth-タイプであるときに、>が示されて、クライアントSHOULDはそのメカニズムから適切な資格証明書を要求して、「ログイン」コマンドの代わりに「認証」コマンドを使用します。 ユーザ名を全く指定しないなら、メカニズムから得なければならないか、またはユーザ/構成から適宜要求しなければなりません。
The string ";AUTH=*" indicates that the client SHOULD select an appropriate authentication mechanism. (Though the '*' character in this usage is not strictly a delimiter, it is being treated like a sub-delim [URI-GEN] in this instance. It MUST NOT be percent-encoded in this usage, as ";AUTH=%2A" will not match this production.) It MAY use any mechanism listed in the response to the CAPABILITY command (or CAPABILITY response code) or use an out-of-band security service resulting in a PREAUTH connection. If no user name is specified and no appropriate authentication mechanisms are available, the client SHOULD fall back to anonymous login as described above. The behavior prescribed in this section allows a URL that grants read-write access to authorized users and read-only anonymous access to other users.
AUTHは*と等しいです。「ストリング」; 」 クライアントが適切な認証機構を選択するべきであるのを示します。 (この用法による'*'キャラクタは厳密にそうではありませんが、デリミタでありそれはサブdelimのように扱われています[URI-GEN]。この場合。 AUTHは%2Aと等しいです。「それがパーセントによってこの用法でコード化されているはずがない、」、;、」 この生産に合わないでしょう。) それは、CAPABILITYコマンド(または、CAPABILITY応答コード)への応答で記載されたどんなメカニズムも使用するか、またはPREAUTH接続をもたらすバンドで出ているセキュリティー・サービスを使用するかもしれません。 ユーザ名が全く指定されないで、またどんな適切な認証機構も利用可能でないなら、クライアントSHOULDは上で説明されるように匿名のログインへ後ろへ下がります。 このセクションに定められた振舞いは他のユーザへの認定ユーザへのアクセスと読書唯一の匿名のアクセスを交付金が読書して書くURLに許します。
If a user name is included with no authentication mechanism, then ";AUTH=*" is assumed.
「次に、ユーザ名が認証機構なしで含まれているなら」; AUTHは*と等しいです。」 想定されます。
Clients must take care when resolving a URL that requires or requests any sort of authentication, since URLs can easily come from untrusted sources. Supplying authentication credentials to the wrong server may compromise the security of the user's account; therefore, the program resolving the URL should meet at least one of the following criteria in this case:
どんな種類の認証も必要である、または要求するURLを決議するとき、クライアントは注意しなければなりません、URLが信頼できないソースから容易に来ることができるので。 認証資格証明書を間違ったサーバに供給すると、ユーザのアカウントのセキュリティは感染するかもしれません。 したがって、URLを決議するプログラムはこの場合少なくとも以下の評価基準の1つに会うはずです:
1) The URL comes from a trusted source, such as a referral server
that the client has validated and trusts according to site policy.
Note that user entry of the URL may or may not count as a trusted
source, depending on the experience level of the user and site
policy.
1) URLは信頼できるソースから来ます、サイト方針に従ったクライアントが有効にした紹介サーバや受託のように。 URLのユーザエントリーが信頼できるソースにみなすかもしれないことに注意してください、ユーザとサイト方針の経験レベルによって。
2) Explicit local site policy permits the client to connect to the
server in the URL. For example, a company example.com may have a
site policy to trust all IMAP server names ending in example.com,
whereas such a policy would be unwise for example.edu where random
students can set up IMAP servers.
2) 明白なローカル・サイト方針は、クライアントがURLでサーバに接続することを許可します。 例えば、会社のexample.comはexample.comに終わりながら、すべてのIMAPサーバが命名する信頼にサイト方針を持っているかもしれませんが、そのような方針は無作為の学生がIMAPサーバをセットアップできる賢明でないfor example.eduでしょう。
3) The user confirms that connecting to that domain name with the
specified credentials and/or mechanism is permitted. For example,
when using "LOGIN" or SASL PLAIN with Transport Layer Security
3) ユーザは、指定された資格証明書、そして/または、メカニズムでそのドメイン名に接続するのが受入れられると確認します。 例えば、簡単な輸送と共に「ログイン」かSASLを使用するときには、セキュリティを層にしてください。
Melnikov & Newman Standards Track [Page 5] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[5ページ]。
(TLS), the IMAP URL client presents a dialog box "Is it OK to send
your password to server "example.com"? Please be aware the owners
of example.com will be able to reuse your password to connect to
other servers on your behalf".
(TLS)、IMAP URLクライアントは「サーバ"example.com"にあなたのパスワードを送るのはOKですか?」をダイアログボックスに提示します。 「example.comの所有者があなたに代わって他のサーバに接続するためにパスワードを再利用できるのを意識してください。」
4) A mechanism is used that validates the server before passing
potentially compromising client credentials. For example, a site
has a designated TLS certificate used to certify site-trusted IMAP
server certificates, and this has been configured explicitly into
the IMAP URL client. Another example is use of a Simple
Authentication and Security Layer (SASL) mechanism such as
DIGEST-MD5 [DIGEST-MD5], which supports mutual authentication.
4) 潜在的に評判を落とすようなクライアント資格証明書を通過する前にサーバを有効にする使用されるメカニズム。 例えば、サイトで信じられたIMAPサーバ証明書を公認するのにサイトで指定されたTLS証明書を使用します、そして、これは明らかにIMAP URLクライアントに構成されました。 別の例はDIGEST-MD5[DIGEST-MD5]などのSimple AuthenticationとSecurity Layer(SASL)メカニズムの使用です。(DIGEST-MD5は互いの認証をサポートします)。
5) An authentication mechanism is used that will not reveal any
information to the server that could be used to compromise future
connections. Examples are SASL ANONYMOUS [ANONYMOUS] or GSSAPI
[GSSAPI].
5) 今後の接続に感染するのに使用できたサーバに少しの情報も明らかにしない使用される認証機構。 例は、SASL ANONYMOUS[更生会]かGSSAPI[GSSAPI]です。
URLs that do not include a user name but include an authentication
mechanism (";AUTH=<mech>") must be treated with extra care, since for
some <mech>s they are more likely to compromise the user's primary
account. A URL containing ";AUTH=*" must also be treated with extra
care since it might fall back on a weaker security mechanism.
Finally, clients are discouraged from using a plaintext password as a
fallback with ";AUTH=*" unless the connection has strong encryption.
付加的な注意でユーザ名を含んでいるのではなく、認証機構を含んでいる(「;AUTHが<mech>と等しい 」)URLを扱わなければなりません、それらがいくらかの<mech>sに関してユーザのプライマリアカウントにより感染しそうであるので。 AUTHは*と等しいです。「URL含有」; 」 また、より弱いセキュリティー対策の上に後ろへ下がるかもしれないので、付加的な注意で扱わなければなりません。 AUTHは*と等しいです。「最終的に、後退としての平文パスワードを使用クライアントが落胆しているする」、; 」 接続に強い暗号化がない場合。
A program interpreting IMAP URLs MAY cache open connections to an IMAP server for later reuse. If a URL contains a user name, only connections authenticated as that user may be reused. If a URL does not contain a user name or authentication mechanism, then only an anonymous connection may be reused.
IMAP URLを解釈するプログラムは後の再利用のためのIMAPサーバにオープンな接続をキャッシュするかもしれません。 URLがユーザ名を含んでいるなら、そのユーザとして認証された接続だけを再利用してもよいです。 URLがユーザ名か認証機構を含んでいないなら、匿名の接続だけを再利用してもよいです。
Note that if unsafe or reserved characters such as " " (space) or ";" are present in the user name or authentication mechanism, they MUST be percent-encoded as described in [URI-GEN].
または、危険であるならそれに注意するか、またはキャラクタを予約する、「「(スペース)、」、」、。 ユーザ名か認証機構に存在していて、それらは中で説明されるとしてパーセントでコード化していなければなりません[URI-GEN]。
3.3. Limitations of enc-user
3.3. enc-ユーザの制限
As per Sections 3.1 and 3.2 of this document, the IMAP URI enc-user has two purposes:
このドキュメントのセクション3.1と3.2に従って、IMAP URI enc-ユーザには、2つの目的があります:
1) It provides context for user-specific mailbox paths such as
"INBOX" (Section 3.1).
1) それは「受信トレイ」(セクション3.1)などのユーザ特有のメールボックス経路に文脈を提供します。
2) It specifies that resolution of the URL requires logging in as
that user and limits use of that URL to only that user (Section
3.2).
2) それは、URLの決議が、そのユーザとしてログインするのを必要とすると指定して、そのURLの使用をそのユーザ(セクション3.2)だけに制限します。
Melnikov & Newman Standards Track [Page 6] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[6ページ]。
An obvious limitation of using the same field for both purposes is that the URL can be resolved only by the mailbox owner. In order to avoid this restriction, implementations should use globally unique mailbox names (see Section 3.1) whenever possible.
両方の目的に同じ分野を使用する明白な制限は単にメールボックス所有者がURLを決議できるということです。 この制限を避けるために、可能であるときはいつも、実装はグローバルにユニークなメールボックス名(セクション3.1を見る)を使用するべきです。
Note: There is currently no general way in IMAP of learning a
globally unique name for a mailbox. However, by looking at the
NAMESPACE [NAMESPACE] command result, it is possible to determine
whether or not a mailbox name is globally unique.
以下に注意してください。 どんな一般的な道も現在、メールボックスのためにグローバルにユニークな名前について知るIMAPにありません。 しかしながら、NAMESPACE[NAMESPACE]コマンド結果を見ることによって、メールボックス名がグローバルにユニークであるかどうか決定するのは可能です。
The URLAUTH component overrides the second purpose of the enc-user in the IMAP URI and by default permits the URI to be resolved by any user permitted by the <access> identifier. URLAUTH and <access> identifier are described in Section 6.1.
URLAUTHの部品は、IMAP URIでenc-ユーザの2番目の目的をくつがえして、デフォルトでURIが<アクセス>識別子によって受入れられたどんなユーザによっても決議されるのを可能にします。 URLAUTHと<アクセス>識別子はセクション6.1で説明されます。
4. IMAP Server
4. IMAPサーバ
An IMAP URL referring to an IMAP server has the following form:
IMAPサーバを示すIMAP URLは以下を形成させられます:
imap://<iserver>[/]
imap://<iserver>。[/]
This URL type is frequently used to describe a location of an IMAP server, both in referrals and in configuration. It may optionally contain the <iuserinfo> component (see Sections 3 and 11). A program interpreting this URL would issue the standard set of commands it uses to present a view of the content of the IMAP server, as visible to the user described by the "enc-user" part of the <iuserinfo> component, if the "enc-user" part is specified.
このURLタイプは、IMAPサーバの位置について説明するのに紹介と構成に頻繁に使用されます。 それは任意に<iuserinfo>の部品を含むかもしれません(セクション3と11を見てください)。 このURLを解釈するプログラムはそれがIMAPサーバの内容の視点を提示するのに使用するコマンドの標準セットを発行するでしょう、<iuserinfo>の部品の「enc-ユーザ」部分によって説明されたユーザにとって目に見えるとして、「enc-ユーザ」部分が指定されるなら。
5. Lists of Messages
5. メッセージのリスト
An IMAP URL referring to a list of messages has the following form:
メッセージのリストを示すIMAP URLは以下を形成させられます:
imap://<iserver>/<enc-mailbox>[<uidvalidity>][?<enc-search>]
imap://<iserver<enc>/メールボックス>[<uidvalidity>][<enc-検索>]
The <enc-mailbox> field is used as the argument to the IMAP4 "SELECT" or "EXAMINE" command. Note that if unsafe or reserved characters such as " " (space), ";", or "?" are present in <enc-mailbox>, they MUST be percent-encoded as described in [URI-GEN].
IMAP4への議論がコマンドを「選択する」か、または「調べる」とき、>がさばく<enc-メールボックスは使用されています。 危険であるならそれに注意するか、またはキャラクタを予約する、「「(スペース)、」 ; 」 “?"が<のencメールボックスの>に存在している、彼らは中で説明されるとしてパーセントでコード化していなければなりません[URIで情報を得ます]。
The <uidvalidity> field is optional. If it is present, it MUST be the same as the value of IMAP4 UIDVALIDITY response code at the time the URL was created. This MUST be used by the program interpreting the IMAP URL to determine if the URL is stale. If the IMAP URL is stale, then the program should behave as if the corresponding mailbox doesn't exist.
<uidvalidity>分野は任意です。 それが存在しているなら、URLが作成されたとき、IMAP4 UIDVALIDITY応答コードの値と同じであるに違いありません。 URLが聞き古したであるかどうか決定するためにIMAP URLを解釈するプログラムでこれを使用しなければなりません。 IMAP URLが聞き古したである、まるで対応するメールボックスが存在していないかのようにプログラムは反応するはずです。
Melnikov & Newman Standards Track [Page 7] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[7ページ]。
Note that the <uidvalidity> field is a modifier to the <enc-mailbox>, i.e., it is considered a part of the last "component" (as used in [URI-GEN]) of the <enc-mailbox>. This is significant during relative URI resolution.
<uidvalidity>分野が<enc-メールボックス>への修飾語であるというメモ、すなわち、それは<enc-メールボックス>の最後の「コンポーネント」([URI-GEN]で使用されるように)の一部であると考えられます。 これは相対的なURI解決の間、重要です。
The "?<enc-search>" field is optional. If it is not present, the program interpreting the URL will present the entire content of the mailbox.
」 <は>をenc捜します。「」 分野は任意です。 それが存在していないと、URLを解釈するプログラムはメールボックスの全体の中身を提示するでしょう。
If the "?<enc-search>" field is present, the program interpreting the URL should use the contents of this field as arguments following an IMAP4 SEARCH command. These arguments are likely to contain unsafe characters such as " " (space) (which are likely to be present in the <enc-search>). If unsafe characters are present, they MUST be percent-encoded as described in [URI-GEN].
」 <は>をenc捜します。「」 分野が存在している、IMAP4 SEARCHコマンドに続いて、URLを解釈するプログラムは議論としてこの分野のコンテンツを使用するはずです。 これらの議論が危険なキャラクタを含みそうである、「「(スペース)(<のenc検索>で存在している傾向があります)。」 危険なキャラクタが出席しているなら、彼らは[URI-GEN]で説明されるようにパーセントでコード化していなければなりません。
Note that quoted strings and non-synchronizing literals [LITERAL+] are allowed in the <enc-search> content; however, synchronizing literals are not allowed, as their presence would effectively mean that the agent interpreting IMAP URLs needs to parse an <enc-search> content, find all synchronizing literals, and perform proper command continuation request handling (see Sections 4.3 and 7 of [IMAP4]).
引用文字列と非連動リテラル[LITERAL+]が<enc-検索>で満足していた状態で許容されていることに注意してください。 しかしながら、連動リテラルは許容されていません、それらの存在が、<を分析するエージェントの解釈しているIMAP URLの必要性が>内容をenc捜して、すべての連動にリテラルを見つけて、適切なコマンド継続要求取り扱いを実行することを事実上意味するだろうというとき([IMAP4]のセクション4.3と7を見てください)。
6. A Specific Message or Message Part
6. 特定のメッセージかメッセージ部分
An IMAP URL referring to a specific message or message part has the following form:
特定のメッセージかメッセージ部分を示すIMAP URLは以下を形成させられます:
imap://<iserver>/<enc-mailbox>[<uidvalidity>]<iuid>
[<isection>][<ipartial>][<iurlauth>]
imap://<iserver<enc>/メールボックス>[<uidvalidity>]<iuid>[<isection>][<ipartial>][<iurlauth>]
The <enc-mailbox> and [uidvalidity] are as defined in Section 5 above.
<enc-メールボックス>と[uidvalidity]が上のセクション5で定義されるようにあります。
If <uidvalidity> is present in this form, it SHOULD be used by the program interpreting the URL to determine if the URL is stale.
>は<uidvalidityであるならこのフォームに存在していて、それはSHOULDです。プログラムで、URLが聞き古したであるかどうか決定するためにURLを解釈しながら、使用されてください。
The <iuid> refers to an IMAP4 message Unique Identifier (UID), and it SHOULD be used as the <set> argument to the IMAP4 "UID FETCH" command.
<iuid>がIMAP4メッセージUnique Identifier(UID)、およびそれについて言及する、SHOULD、<がIMAP4「UIDフェッチ」コマンドに>議論を設定したので、使用されてください。
The <isection> field is optional. If not present, the URL refers to the entire Internet message as returned by the IMAP command "UID FETCH <uid> BODY.PEEK[]". If present, the URL refers to the object returned by a "UID FETCH <uid> BODY.PEEK[<section>]" command. The type of the object may be determined by using a "UID FETCH <uid> BODYSTRUCTURE" command and locating the appropriate part in the
<isection>分野は任意です。 まして、プレゼント、URLはIMAPコマンド「UID FETCH<uid>BODY.PEEK[]」によって返される全体のインターネットメッセージを示します。 存在しているなら、URLは「UID FETCH<uid>BODY.PEEK[<部の>]」コマンドで返されたオブジェクトについて言及します。 「UID FETCH<uid>BODYSTRUCTURE」コマンドを使用して、適切な部分の場所を見つけることによってオブジェクトのタイプが決定しているかもしれない。
Melnikov & Newman Standards Track [Page 8] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[8ページ]。
resulting BODYSTRUCTURE. Note that unsafe characters in [isection] MUST be percent-encoded as described in [URI-GEN].
結果として起こるBODYSTRUCTURE。 [URI-GEN]で説明されるように[isection]の危険なキャラクタがパーセントでコード化していなければならないことに注意してください。
The <ipartial> field is optional. If present, it effectively appends "<<partial-range>>" to the end of the UID FETCH BODY.PEEK[<section>] command constructed as described in the previous paragraph. In other words, it allows the client to request a byte range of the message/message part.
<ipartial>分野は任意です。 存在しているなら、事実上、前のパラグラフで説明されるように構成されたUID FETCH BODY.PEEK[<部の>]コマンドの終わりに「<の<の部分的な範囲の>>」を追加します。 言い換えれば、それで、クライアントはメッセージ/メッセージ部分のバイト範囲を要求できます。
The <iurlauth> field is described in detail in Section 6.1.
<iurlauth>分野はセクション6.1で詳細に説明されます。
6.1. URLAUTH Authorized URL
6.1. URLAUTHはURLを認可しました。
URLAUTH authorized URLs are only supported by an IMAP server advertising the URLAUTH IMAP capability [URLAUTH].
URLAUTHの認可されたURLはURLAUTH IMAP能力[URLAUTH]の広告を出すIMAPサーバによってサポートされるだけです。
6.1.1. Concepts
6.1.1. 概念
6.1.1.1. URLAUTH
6.1.1.1. URLAUTH
URLAUTH is a component, appended at the end of a URL, that conveys authorization to access the data addressed by that URL. It contains an authorized access identifier, an authorization mechanism name, and an authorization token. The authorization token is generated from the URL, the authorized access identifier, authorization mechanism name, and a mailbox access key.
URLAUTHはそのURLによって扱われたデータにアクセスするために承認を伝える1つのURLの端で追加されたコンポーネントです。 それは認可されたアクセス識別子、承認メカニズム名、および承認トークンを含んでいます。 承認トークンはURL、認可されたアクセス識別子、承認メカニズム名、およびメールボックスアクセスキーから生成されます。
Note: This specification only allows for the URLAUTH component in
IMAP URLs describing a message or its part.
以下に注意してください。 この仕様はメッセージについて説明するIMAP URLかその部分でURLAUTHの部品を考慮するだけです。
6.1.1.2. Mailbox Access Key
6.1.1.2. メールボックスアクセスキー
The mailbox access key is an unpredictable, random string. To ensure unpredictability, the random string with at least 128 bits of entropy is generated by software or hardware (not by the human user).
メールボックスアクセスキーは予測できないで、無作為のストリングです。 予測不可能性を確実にするために、ソフトウェアかハードウェア(人間のユーザでないのによる)によってエントロピーの少なくとも128ビットがある無作為のストリングは生成されます。
Each user has a table of mailboxes and an associated mailbox access key for each mailbox. Consequently, the mailbox access key is per- user and per-mailbox. In other words, two users sharing the same mailbox each have a different mailbox access key for that mailbox, and each mailbox accessed by a single user also has a different mailbox access key.
各ユーザには、メールボックスのテーブルと各メールボックスのための関連メールボックスアクセスキーがあります。 その結果、メールボックスアクセスキーがそうである、-、ユーザとメールボックス。 言い換えれば、同じメールボックスを共有している2人のユーザがそれぞれそのメールボックスのための異なったメールボックスアクセスキーを持っています、そして、また、シングルユーザーによってアクセスされた各メールボックスは異なったメールボックスアクセスキーを持っています。
6.1.1.3. Authorized Access Identifier
6.1.1.3. 認可されたアクセス識別子
The authorized <access> identifier restricts use of the URLAUTH authorized URL to certain users authorized on the server, as described in Section 6.1.2.
認可された<アクセス>識別子はURLAUTHの認可されたURLの使用をサーバで権限を与えられた確信しているユーザに制限します、セクション6.1.2で説明されるように。
Melnikov & Newman Standards Track [Page 9] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[9ページ]。
6.1.1.4. Authorization Mechanism
6.1.1.4. 承認メカニズム
The authorization mechanism is the algorithm by which the URLAUTH is generated and subsequently verified, using the mailbox access key.
承認メカニズムはメールボックスアクセスキーを使用して、URLAUTHが生成されて、次に確かめられるアルゴリズムです。
6.1.1.5. Authorization Token
6.1.1.5. 承認トークン
The authorization token is a deterministic string of at least 128 bits that an entity with knowledge of the secret mailbox access key and URL authorization mechanism can use to verify the URL.
承認トークンは秘密のメールボックスアクセスキーとURL承認メカニズムに関する知識がある実体がURLについて確かめるのに使用できる少なくとも128ビットの決定論的なストリングです。
6.1.2. URLAUTH Extensions to IMAP URL
6.1.2. IMAP URLへのURLAUTH拡張子
A specific message or message part IMAP URL can optionally contain ";EXPIRE=<datetime>" and/or ";URLAUTH=<access>:<mech>:<token>".
「パートIMAP URLが任意に含むことができる特定のメッセージかメッセージ」; =<datetime>を吐き出してください。」 」 ; URLAUTHは<アクセス>: <mech>と等しいです:、<トークン>、」
When ";EXPIRE=<datetime>" is used, this indicates the latest date and time that the URL is valid. After that date and time, the URL has expired and server implementations MUST reject the URL. If ";EXPIRE=<datetime>" is not used, the URL has no expiration, but can still be revoked using the RESETKEY command [URLAUTH].
「いつ」; =<datetime>を吐き出してくださいか、」、使用されていて、これはURLが有効であることの最新の日時を示します。 その日時以降、URLは期限が切れています、そして、サーバ実装はURLを拒絶しなければなりません。 =<datetime>を吐き出してください。「」、;、」 使用されないで、URLには満了が全くないということですが、RESETKEYコマンド[URLAUTH]を使用することでまだ取り消すことができます。
The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>", and it MUST be at the end of the URL. It is composed of three parts. The <access> portion provides the authorized access identifiers that may constrain the operations and users that are permitted to use this URL. The <mech> portion provides the authorization mechanism used by the IMAP server to generate the authorization token that follows. The <token> portion provides the authorization token, which can be generated using the GENURLAUTH command [URLAUTH].
「URLAUTHは形を取る」; URLAUTHはURLの端で」 それが<アクセス>: <mech>: <トークン>でなければならないのと等しいです。 それは3つの部品で構成されます。 <アクセス>部分は操作を抑制するかもしれない認可されたアクセス識別子とこのURLを使用することが許可されているユーザを提供します。 <mech>部分はIMAPサーバによって使用される、続く承認トークンを生成する承認メカニズムを提供します。 <トークン>部分は承認トークンを提供します。(GENURLAUTHコマンド[URLAUTH]を使用することでそれを生成することができます)。
The "submit+" <access> identifier prefix, followed by a userid, indicates that only a userid authorized as a message submission entity on behalf of the specified userid is permitted to use this URL. The IMAP server does not validate the specified userid but does validate that the IMAP session has an authorization identity that is authorized as a message submission entity. The authorized message submission entity MUST validate the userid prior to contacting the IMAP server.
ユーザIDがあとに続いた「+を提出してください」<アクセス>識別子接頭語は、メッセージ服従実体として指定されたユーザIDを代表して認可されたユーザIDだけがこのURLを使用することが許可されているのを示します。 IMAPサーバは、指定されたユーザIDを有効にしませんが、それを有効にします。IMAPセッションには、メッセージ服従実体として認可される承認のアイデンティティがあります。 IMAPサーバに連絡する前に、認可されたメッセージ服従実体はユーザIDを有効にしなければなりません。
The "user+" <access> identifier prefix, followed by a userid, indicates that use of this URL is limited to IMAP sessions that are logged in as the specified userid (that is, have authorization identity as that userid).
ユーザIDがあとに続いた「ユーザ+」<アクセス>識別子接頭語は、このURLの使用が指定されたユーザID(すなわち、そのユーザIDとして承認のアイデンティティを持っている)としてログインされるIMAPセッションまで制限されるのを示します。
Note: If a SASL mechanism that provides both authorization and
authentication identifiers is used to authenticate to the IMAP
server, the "user+" <access> identifier MUST match the
以下に注意してください。 承認と認証識別子の両方を提供するSASLメカニズムがIMAPサーバに認証するのにおいて使用されているなら、「ユーザ+」<アクセス>識別子は合わなければなりません。
Melnikov & Newman Standards Track [Page 10] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[10ページ]。
authorization identifier. If the SASL mechanism can't transport
the authorization identifier, the "user+" <access> identifier MUST
match the authorization identifier derived from the authentication
identifier (see [SASL]).
承認識別子。 SASLメカニズムが承認識別子を輸送できないなら、「ユーザ+」<アクセス>識別子は認証識別子から得られた承認識別子に合わなければなりません([SASL]を見てください)。
The "authuser" <access> identifier indicates that use of this URL is limited to authenticated IMAP sessions that are logged in as any non-anonymous user (that is, have authorization identity as a non- anonymous user) of that IMAP server. To restate this: use of this type of URL is prohibited to anonymous IMAP sessions, i.e., any URLFETCH command containing this type of URL issued in an anonymous session MUST return NIL in the URLFETCH response.
このURLの使用が識別子が示す>ですが、そのどんな非匿名のユーザ(すなわち、非匿名のユーザとして承認のアイデンティティを持っている)としてもログインされる認証されたIMAPセッションまで制限されて、<がアクセスする"authuser"IMAPサーバこれを言い直すために: このタイプのURLの使用は匿名のIMAPセッションまで禁止されています、すなわち、匿名のセッションのときに発行されたこのタイプのURLを含むどんなURLFETCHコマンドもURLFETCH応答でNILを返さなければなりません。
The "anonymous" <access> identifier indicates that use of this URL is not restricted by session authorization identity; that is, any IMAP session in authenticated or selected state (as defined in [IMAP4]), including anonymous sessions, may issue a URLFETCH [URLAUTH] using this URL.
「匿名」の<アクセス>識別子は、このURLの使用がセッション承認のアイデンティティによって制限されないのを示します。 すなわち、匿名のセッションを含む認証されたか選択された州([IMAP4]で定義されるように)でのどんなIMAPセッションも、このURLを使用することでURLFETCH[URLAUTH]を発行するかもしれません。
The authorization token is represented as an ASCII-encoded hexadecimal string, which is used to authorize the URL. The length and the calculation of the authorization token depend upon the mechanism used, but in all cases, the authorization token is at least 128 bits (and therefore at least 32 hexadecimal digits).
承認トークンはASCIIによってコード化された16進ストリングとして表されます。(それは、URLを認可するのに使用されます)。 承認トークンの長さと計算を使用されるメカニズムに依存しますが、すべての場合では、承認トークンは少なくとも128ビット(そして、したがって、少なくとも32の16進数字)です。
Example:
例:
<imap://joe@example.com/INBOX/;uid=20/;section=1.2;urlauth=
submit+fred:internal:91354a473744909de610943775f92038>
<imap: //joe@example.com/INBOX/;uid は20/と等しいです; =1.2 ; セクションurlauth=は+ fred:インターナル:91354a473744909de610943775f92038>を提出します。
7. Relative IMAP URLs
7. 相対的なIMAP URL
Relative IMAP URLs are permitted and are resolved according to the rules defined in [URI-GEN]. In particular, in IMAP URLs parameters (such as ";uid=" or ";section=") are treated as part of the normal path with respect to relative URL resolution.
相対的なIMAP URLは、受入れられて、[URI-GEN]で定義された規則に従って、決議されています。 「特定IMAP URLパラメタ、(」、; uid=、」、」、; セクション=、」、)、相対的なURL解決に関して正常な経路の一部として扱われます。
[URI-GEN] defines four forms of relative URLs: <inetwork-path>, <iabsolute-path>, <irelative-path>, and <ipath-empty>. Their syntax is defined in Section 11.
[URI-GEN]は4つのフォームの相対的なURLを定義します: <inetwork-経路>、<iabsolute-経路>、<「不-絶対最上級」-経路>、および<のipath空の>。 それらの構文はセクション11で定義されます。
A relative reference that begins with two slash characters is termed a network-path reference (<inetwork-path>); such references are rarely used, because in most cases they can be replaced with an equivalent absolute URL. A relative reference that begins with a single slash character is termed an absolute-path reference (<iabsolute-path>; see also Section 7.1). A relative reference that does not begin with a slash character is termed a relative-path
2つのスラッシュキャラクタと共に始まる相対参照はネットワーク経路参照(<inetwork-経路>)と呼ばれます。 そのような参照は、多くの場合それらを同等な絶対URLに取り替えることができるので、めったに使用されません。 単独のスラッシュキャラクタと共に始まる相対参照は絶対パス参照と呼ばれます(<iabsolute-経路>; また、セクション7.1を見てください)。 スラッシュキャラクタと共に始まらない相対参照は相対パスと呼ばれます。
Melnikov & Newman Standards Track [Page 11] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[11ページ]。
reference (<irelative-path>; see also Section 7.2). The final form is <ipath-empty>, which is "same-document reference" (see Section 4.4 of [URI-GEN]).
参照(<「不-絶対最上級」-経路>; また、セクション7.2を見てください)。 最終形態は<ipath空の>([URI-GEN]のセクション4.4を見る)です。(その>は「同じドキュメント参照」です)。
The following observations about relative URLs are important:
相対的なURLに関する以下の観測は重要です:
The <iauth> grammar element (which is a part of <iuserinfo>, which is, in turn, a part of <iserver>; see Section 3) is considered part of the user name for purposes of resolving relative IMAP URLs. This means that unless a new user name/server specification is included in the relative URL, the authentication mechanism is inherited from the base IMAP URL.
<iauth>文法要素(<iuserinfo>の一部である)は相対的なIMAP URLを決議する目的のためのユーザ名の一部であると考えられます。<iserver>の一部; 順番に、>はセクション3を見ます。 これは、新しいユーザ名前/サーバ仕様が相対的なURLに含まれていない場合、認証機構がベースIMAP URLから引き継がれることを意味します。
URLs always use "/" as the hierarchy delimiter for the purpose of resolving paths in relative URLs. IMAP4 permits the use of any hierarchy delimiter in mailbox names. For this reason, relative mailbox paths will only work if the mailbox uses "/" as the hierarchy delimiter. Relative URLs may be used on mailboxes that use other delimiters, but in that case, the entire mailbox name MUST be specified in the relative URL or inherited as a whole from the base URL.
相対的なURLの経路を決議する目的のための階層構造デリミタとして「URLはいつも」 /を使用します」。 IMAP4はメールボックス名におけるどんな階層構造デリミタの使用も可能にします。 階層構造デリミタとして「この理由で、メールボックスが」 /を使用する場合にだけ、相対的なメールボックス経路は働くでしょう」。 相対的なURLが他のデリミタを使用するメールボックスの上に使用されるかもしれませんが、その場合、全体のメールボックス名を相対的なURLで指定されなければならないか、またはベースURLから全体で受け継がなければなりません。
If an IMAP server allows for mailbox names starting with "./" or "../", ending with "/." or "/..", or containing sequences "/../" or "/./", then such mailbox names MUST be percent-encoded as described in [URI-GEN]. Otherwise, they would be misinterpreted as dot- segments (see Section 3.3 of [URI-GEN]), which are processed specially during the relative path resolution process.
または、「」 . /から始めて、IMAPサーバはメールボックス名を考慮する」、」「/」. 」 」 /が」 /で終わりであり、, または、「含有は」 /を配列します。」 /「/」か/、」、そして、そのようなメールボックス名は中で説明されるとしてパーセントでコード化していなければなりません[URIで情報を得ます]。 さもなければ、それらはドットセグメント([URI-GEN]のセクション3.3を見る)として誤解されるでしょう。(特に、セグメントは相対パス解決プロセスの間、処理されます)。
7.1. absolute-path References
7.1. 絶対パスReferences
A relative reference that begins with a single slash character is termed an absolute-path reference (see Section 4.2 of [URI-GEN]). If an IMAP server permits mailbox names with a leading "/", then the leading "/" MUST be percent-encoded as described in [URI-GEN]. Otherwise, the produced absolute-path reference URI will be misinterpreted as a network-path reference [URI-GEN] described by the <inetwork-path> non-terminal.
単独のスラッシュキャラクタと共に始まる相対参照は絶対パス参照と呼ばれます([URI-GEN]のセクション4.2を見てください)。 「IMAPサーバが」 /を導くaのメールボックス名を可能にするなら」、そして」 /を導いて、」 必須は中[URIで情報を得る]で説明されるようにパーセントによってコード化されています。 さもなければ、生産された絶対パス参照URIは参照[URI-GEN]が<inetwork-経路で説明したネットワーク経路>非端末として誤解されるでしょう。
7.2. relative-path References
7.2. 相対パスReferences
A relative reference that does not begin with a slash character is termed a relative-path reference [URI-GEN]. Implementations MUST NOT generate or accept relative-path IMAP references.
スラッシュキャラクタと共に始まらない相対参照は相対パス参照[URI-GEN]と呼ばれます。 実装は、相対パスIMAP参照を生成してはいけませんし、また受け入れてはいけません。
See also Section 4.2 of [URI-GEN] for restrictions on relative-path references.
また、制限に関して[URI-GEN]のセクション4.2を相対パス参照に見てください。
Melnikov & Newman Standards Track [Page 12] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[12ページ]。
8. Internationalization Considerations
8. 国際化問題
IMAP4, Section 5.1.3 [IMAP4] includes a convention for encoding non- US-ASCII characters in IMAP mailbox names. Because this convention is private to IMAP, it is necessary to convert IMAP's encoding to one that can be more easily interpreted by a URL display program. For this reason, IMAP's modified UTF-7 encoding for mailboxes MUST be converted to UTF-8 [UTF-8]. Since 8-bit octets are not permitted in URLs, the UTF-8 octets are percent-encoded as required by the URL specification [URI-GEN], Section 2.1. Sample code is included in Appendix A to demonstrate this conversion.
IMAP4、セクション5.1.3[IMAP4]はIMAPメールボックス名で米国の非ASCII文字をコード化するためのコンベンションを含んでいます。 このコンベンションがIMAPに私設であるので、IMAPがそれを1つにコード化するのを変換するのがURLディスプレイプログラムでさらに容易に解釈できるのが必要です。 この理由で、メールボックスのためのIMAPの変更されたUTF-7コード化をUTF-8[UTF-8]に変換しなければなりません。 8ビット・オクテットがURLで受入れられないので、UTF-8八重奏は必要に応じてパーセントによってコード化されています。URL仕様[URI-GEN]、セクション2.1で。 サンプルコードは、この変換を示すためにAppendix Aに含まれています。
IMAP user names are UTF-8 strings and MUST be percent-encoded as required by the URL specification [URI-GEN], Section 2.1.
IMAPユーザ名はURL仕様[URI-GEN]で、UTF-8が結んで、必要に応じてパーセントでコード化していなければならないということであり、セクションは2.1です。
Also note that IMAP SEARCH criteria can contain non-US-ASCII characters. 8-bit octets in those strings MUST be percent-encoded as required by the URL specification [URI-GEN], Section 2.1.
また、IMAP SEARCH評価基準が非米国のASCII文字を含むことができることに注意してください。 それらのストリングにおける8ビット・オクテットは必要に応じてパーセントでコード化していなければなりません。URL仕様[URI-GEN]、セクション2.1で。
9. Examples
9. 例
The following examples demonstrate how an IMAP4 client program might translate various IMAP4 URLs into a series of IMAP4 commands. Commands sent from the client to the server are prefixed with "C:", and responses sent from the server to the client are prefixed with "S:".
以下の例はIMAP4クライアントプログラムがどう様々なIMAP4URLを一連のIMAP4コマンドに翻訳するかもしれないかを示します。 クライアントからサーバに送られたコマンドが前に置かれている、「C: 」 サーバからクライアントに送られた応答が前に置かれている、「S:」
The URL:
URL:
<imap://minbari.example.org/gray-council;UIDVALIDITY=385759045/;
UID=20/;PARTIAL=0.1024>
<のグレーのimap://minbari.example.org/協議会; UIDVALIDITY=385759045/。 UID=20/; 部分的な=0.1024>。
may result in the following client commands and server responses:
以下のクライアントコマンドとサーバ応答をもたらすかもしれません:
<connect to minbari.example.org, port 143>
S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=ANONYMOUS] Welcome
C: A001 AUTHENTICATE ANONYMOUS
S: +
C: c2hlcmlkYW5AYmFieWxvbjUuZXhhbXBsZS5vcmc=
S: A001 OK Welcome sheridan@babylon5.example.org
C: A002 SELECT gray-council
<client verifies the UIDVALIDITY matches>
C: A003 UID FETCH 20 BODY.PEEK[]<0.1024>
<はminbari.example.org、ポート143>Sに接続します: * [能力IMAP4rev1 STARTTLS AUTH=匿名]の歓迎Cを承認してください: A001は匿名のSを認証します: + C: c2hlcmlkYW5AYmFieWxvbjUuZXhhbXBsZS5vcmcはSと等しいです: A001は歓迎された sheridan@babylon5.example.org Cを承認します: A002 SELECTグレーの協議会の<クライアントはUIDVALIDITYマッチ>Cについて確かめます: A003 UIDフェッチ20BODY.PEEK[]<0.1024>。
The URL:
URL:
<imap://psicorp.example.org/~peter/%E6%97%A5%E6%9C%AC%E8%AA%9E/
%E5%8F%B0%E5%8C%97>
<のimap://psicorp.example.org/~、が尽きる、/%E A5 6%97%%E6%9C%交流%E AA8%%9E/%E5%8F%B0%E5%8C%97>。
Melnikov & Newman Standards Track [Page 13] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[13ページ]。
may result in the following client commands:
以下のクライアントコマンドをもたらすかもしれません:
<connect to psicorp.example.org, port 143>
S: * OK [CAPABILITY IMAP4rev1 STARTTLS AUTH=CRAM-MD5] Welcome
C: A001 LOGIN ANONYMOUS bester@psycop.psicorp.example.org
C: A002 SELECT ~peter/&ZeVnLIqe-/&U,BTFw-
<commands the client uses for viewing the contents of
the mailbox>
<はpsicorp.example.org、ポート143>Sに接続します: * 歓迎Cを承認してください[能力IMAP4rev1 STARTTLS AUTHは一夜漬け-MD5と等しいです]: A001のログインの匿名の bester@psycop.psicorp.example.org C: A002 SELECT~が尽きる、/とZeVnLIqe-/とU、クライアントがメールボックス>のコンテンツを見るのに使用するBTFw<コマンド
The URL:
URL:
<imap://;AUTH=GSSAPI@minbari.example.org/gray-council/;uid=20/
;section=1.2>
<imap://; AUTHは GSSAPI@minbari.example.org/gray-council/;uid =20/と等しいです; セクションは1.2>と等しいです。
may result in the following client commands:
以下のクライアントコマンドをもたらすかもしれません:
<connect to minbari.example.org, port 143>
S: * OK Greetings
C: A000 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
S: A000 OK
C: A001 AUTHENTICATE GSSAPI
<authentication exchange>
C: A002 SELECT gray-council
C: A003 UID FETCH 20 BODY.PEEK[1.2]
<はminbari.example.org、ポート143>Sに接続します: * 挨拶Cを承認してください: A000能力S: * 能力IMAP4rev1 STARTTLS AUTH=GSSAPI S: A000はCを承認します: A001 AUTHENTICATE GSSAPI<認証交換>C: A002 SELECTグレーの協議会C: A003 UIDフェッチ20BODY.PEEK[1.2]
If the following relative URL is located in that body part:
以下の相対的なURLがそのボディーに位置しているなら、離れてください:
<;section=1.4>
<; セクションは1.4>と等しいです。
this could result in the following client commands:
これは以下のクライアントコマンドをもたらすかもしれません:
C: A004 UID FETCH 20 (BODY.PEEK[1.2.MIME]
BODY.PEEK[1.MIME]
BODY.PEEK[HEADER.FIELDS (Content-Location)])
<Client looks for Content-Location headers in
result. If no such headers, then it does the following>
C: A005 UID FETCH 20 BODY.PEEK[1.4]
C: A004 UID FETCH20(BODY.PEEK[1.2.MIME]BODY.PEEK[1.MIME]BODY.PEEK[HEADER.FIELDS(満足している位置)])<Clientは結果でContent-位置のヘッダーを探します。 そのようなヘッダーでないなら、以下の>Cをします: A005 UIDフェッチ20BODY.PEEK[1.4]
The URL:
URL:
<imap://;AUTH=*@minbari.example.org/gray%20council?
SUBJECT%20shadows>
<imap://; AUTHは *@minbari.example.org/gray%20council? と等しいです。 対象の%20shadows>。
Melnikov & Newman Standards Track [Page 14] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[14ページ]。
could result in the following:
以下をもたらすことができました:
<connect to minbari.example.org, port 143>
S: * OK Welcome
C: A001 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=DIGEST-MD5
S: A001 OK
C: A002 AUTHENTICATE DIGEST-MD5
<authentication exchange>
S: A002 OK user lennier authenticated
C: A003 SELECT "gray council"
...
C: A004 SEARCH SUBJECT shadows
S: * SEARCH 8 10 13 14 15 16
S: A004 OK SEARCH completed
C: A005 FETCH 8,10,13:16 ALL
...
<はminbari.example.org、ポート143>Sに接続します: * 歓迎Cを承認してください: A001能力S: * 能力IMAP4rev1 AUTHはダイジェスト-MD5 Sと等しいです: A001はCを承認します: A002 AUTHENTICATE DIGEST-MD5<認証交換>S: A002 OKユーザlennierはCを認証しました: A003 SELECTは「協議会を灰色にします」… C: A004 SEARCH SUBJECT影S: * 16秒間の検索8 10 13 14 15: A004 OK SEARCHはCを完成しました: A005フェッチ8、10、13: 16 すべて…
In the example above, the client has implementation-dependent choices. The authentication mechanism could be anything, including PREAUTH. The final FETCH command could fetch more or less information about the messages, depending on what it wishes to display to the user.
例では、上では、クライアントが実装依存する選択を持っています。 認証機構はPREAUTHを含む何かであるかもしれません。 最終的なFETCHコマンドは多少メッセージの情報をとって来るかもしれません、それがユーザに表示したがっているものによって。
The URL:
URL:
<imap://john;AUTH=*@minbari.example.org/babylon5/personel?
charset%20UTF-8%20SUBJECT%20%7B14+%7D%0D%0A%D0%98%D0%B2%
D0%B0%D0%BD%D0%BE%D0%B2%D0%B0>
<imap://john; *@minbari.example.org/babylon5/personel? charset AUTH=%20UTF-8%20SUBJECT%20%の7B14+%7D%0D%0A%D0%98%のD0%B2%D0%B0%D0%BD%D0、%、%D0%B2%D0%B0>になってください。
shows that 8-bit data can be sent using non-synchronizing literals [LITERAL+]. This could result in the following:
8ビットのデータを送ることができる非連動リテラル[LITERAL+]を使用するショー。 これは以下をもたらすかもしれません:
<connect to minbari.example.org, port 143>
S: * OK Hi there
C: A001 CAPABILITY
S: * CAPABILITY IMAP4rev1 LITERAL+ AUTH=DIGEST-MD5
S: A001 OK
C: A002 AUTHENTICATE DIGEST-MD5
<authentication exchange>
S: A002 OK user john authenticated
C: A003 SELECT babylon5/personel
...
C: A004 SEARCH CHARSET UTF-8 SUBJECT {14+}
C: XXXXXXXXXXXXXX
S: * SEARCH 7 10 12
S: A004 OK SEARCH completed
C: A005 FETCH 7,10,12 ALL
<はminbari.example.org、ポート143>Sに接続します: * そこでHiを承認してください、C: A001能力S: * 能力IMAP4rev1リテラル+AUTHはダイジェスト-MD5 Sと等しいです: A001はCを承認します: A002 AUTHENTICATE DIGEST-MD5<認証交換>S: A002 OKユーザjohnはCを認証しました: A003 SELECT babylon5/personel… C: A004がCHARSET UTF-8対象の14+を捜す、C: XXXXXXXXXXXXXX S: * 12秒間の検索7 10: A004 OK SEARCHはCを完成しました: A005フェッチ7、10、12、すべて
Melnikov & Newman Standards Track [Page 15] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[15ページ]。
...
...
where XXXXXXXXXXXXXX is 14 bytes of UTF-8 encoded data as specified in the URL above.
XXXXXXXXXXXXXXが14歳であるところでは、バイトのUTF-8は上のURLの指定されるとしてのデータをコード化しました。
9.1. Examples of Relative URLs
9.1. 相対的なURLに関する例
The following absolute-path reference
以下の絶対パス参照
</foo/;UID=20/..>
</foo/; UID=20/>。
is the same as
同じ
</foo>
</foo>。
That is, both of them reference the mailbox "foo" located on the IMAP server described by the corresponding Base URI.
それはそうであり、それらの両方はメールボックス"foo"が対応する基地のURIによって説明されたIMAPサーバで場所を見つけた参照です。
The following relative-path reference
以下の相対パス参照
<;UID=20>
<; UID=20>。
references a message with UID in the mailbox specified by the Base URI.
メールボックスの中にUIDがあるメッセージが基地のURIで指定した参照。
The following edge case example demonstrates that the ;UIDVALIDITY= modifier is a part of the mailbox name as far as relative URI resolution is concerned:
以下の縁の事例がそれを示す、; 相対的なURI解決に関する限り、UIDVALIDITY=修飾語はメールボックス名の一部です:
<..;UIDVALIDITY=385759045/;UID=20>
<。; UIDVALIDITY=385759045/; UID=20>。
In this example, ".." is not a dot-segment [URI-GEN].
「この例」. . 」 aはドットセグメント[URIで情報を得る]ではありませんか?
10. Security Considerations
10. セキュリティ問題
Security considerations discussed in the IMAP specification [IMAP4] and the URI specification [URI-GEN] are relevant. Security considerations related to authenticated URLs are discussed in Section 3.2 of this document.
IMAP仕様[IMAP4]とURI仕様[URI-GEN]で議論したセキュリティ問題は関連しています。 このドキュメントのセクション3.2で認証されたURLに関連するセキュリティ問題について議論します。
Many email clients store the plaintext password for later use after logging into an IMAP server. Such clients MUST NOT use a stored password in response to an IMAP URL without explicit permission from the user to supply that password to the specified host name.
IMAPサーバにログインした後に、多くのメールクライアントが後の使用のための平文パスワードを保存します。そのようなクライアントは、そのパスワードを指定されたホスト名に供給するのに明白な許可のないIMAP URLに対応してユーザから保存されたパスワードを使用してはいけません。
Clients resolving IMAP URLs that wish to achieve data confidentiality and/or integrity SHOULD use the STARTTLS command (if supported by the
IMAP URLのデータの機密性を達成するというその願望、そして/または、保全SHOULDを決議するクライアントがSTARTTLSコマンドを使用する、(サポートされます。
Melnikov & Newman Standards Track [Page 16] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[16ページ]。
server) before starting authentication, or use a SASL mechanism, such as GSSAPI, that provides a confidentiality security layer.
サーバ) SASLメカニズムの、そして、GSSAPIとしてそのような認証、または使用を始める前に、それは秘密性セキュリティ層を提供します。
10.1. Security Consideration Specific to URLAUTH Authorized URL
10.1. URLAUTHに特定の警備上の配慮はURLを認可しました。
The "user+<userid>" <access> identifier limits resolution of that URL to a particular userid, whereas the "submit+<userid>" <access> identifier is more general and simply requires that the session be authorized by a user that has been granted a "submit" role within the authentication system. Use of either of these mechanisms limits the scope of the URL. An attacker who cannot authenticate using the appropriate credentials cannot make use of the URL.
「ユーザ+<ユーザID>」<アクセス>識別子はそのURLの解決を特定のユーザIDに制限します、「+ <ユーザID>を提出してください」<アクセス>識別子は、より一般的であり、セッションが「提出してください」という役割が認証システムの中で与えられたユーザによって認可されるのを単に必要としますが。 これらのメカニズムのどちらかの使用はURLの範囲を制限します。 適切な資格証明書がURLの使用をすることができない使用を認証できない攻撃者。
The "authuser" and "anonymous" <access> identifiers do not have this level of protection. These access identifiers are primarily useful for public export of data from an IMAP server, without requiring that it be copied to a web or anonymous FTP server.
"authuser"と「匿名」の<アクセス>識別子には、このレベルの保護がありません。 これらのアクセス識別子は主としてIMAPサーバからのデータの公共の輸出の役に立ちます、それがウェブか公開FTPサーバにコピーされる必要でない。
The decision to use the "authuser" <access> identifier should be made with caution. An "authuser" <access> identifier can be used by any authorized user of the IMAP server; therefore, use of this access identifier should be limited to content that may be disclosed to any authorized user of the IMAP server.
慎重に、"authuser"<アクセス>識別子を使用するという決定をするべきです。 IMAPサーバのどんな認定ユーザも"authuser"<アクセス>識別子を使用できます。 したがって、このアクセス識別子の使用はIMAPサーバのどんな認定ユーザにも明らかにされるかもしれない内容に制限されるべきです。
The decision to use the "anonymous" <access> identifier should be made with extreme caution. An "anonymous" <access> identifier can be used by anyone; therefore, use of this access identifier should be limited to content that may be disclosed to anyone.
細心の注意を払って、「匿名」の<アクセス>識別子を使用するという決定をするべきです。 だれでも「匿名」の<アクセス>識別子を使用できます。 したがって、このアクセス識別子の使用はだれにも明らかにされるかもしれない内容に制限されるべきです。
11. ABNF for IMAP URL Scheme
11. IMAP URL体系のためのABNF
Formal syntax is defined using ABNF [ABNF], extending the ABNF rules in Section 9 of [IMAP4]. Elements not defined here can be found in [ABNF], [IMAP4], [IMAPABNF], or [URI-GEN]. Strings are not case sensitive, and free insertion of linear white space is not permitted.
[IMAP4]のセクション9のABNF規則を広げていて、正式な構文は、ABNF[ABNF]を使用することで定義されます。 [ABNF]、[IMAP4]、[IMAPABNF]、または[URI-GEN]でここで定義されなかった要素は見つけることができます。 ストリングは大文字と小文字を区別していません、そして、直線的な余白の無料の挿入は受入れられません。
sub-delims-sh = "!" / "$" / "'" / "(" / ")" /
"*" / "+" / ","
;; Same as [URI-GEN] sub-delims,
;; but without ";", "&" and "=".
サブdelims-shは“!"と等しいです。 / "$" / "'" / "(" / ")" / "*" / "+" / "," ;; [URI-GEN]サブdelimsと同じである、。 しかし、「」、;、」、“&"と「=。」
uchar = unreserved / sub-delims-sh / pct-encoded
ucharはコード化された予約していない/サブdelims-sh / pctと等しいです。
achar = uchar / "&" / "="
;; Same as [URI-GEN] 'unreserved / sub-delims /
;; pct-encoded', but ";" is disallowed.
acharはuchar/“&"/「=」と等しいです。 [URI-GEN]'無遠慮であるかサブdelimsの/'と同じ。 「しかし、'pctコード化'」、;、」 禁じられます。
bchar = achar / ":" / "@" / "/"
「bcharはachar/と等しい」:、」 / "@" / "/"
Melnikov & Newman Standards Track [Page 17] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[17ページ]。
enc-auth-type = 1*achar
; %-encoded version of [IMAP4] "auth-type"
enc-auth-タイプは1*acharと等しいです。 [IMAP4]「auth-タイプ」の%でコード化されたバージョン
enc-mailbox = 1*bchar
; %-encoded version of [IMAP4] "mailbox"
enc-メールボックスは1*bcharと等しいです。 [IMAP4]「メールボックス」の%でコード化されたバージョン
enc-search = 1*bchar
; %-encoded version of [IMAPABNF]
; "search-program". Note that IMAP4
; literals may not be used in
; a "search-program", i.e., only
; quoted or non-synchronizing
; literals (if the server supports
; LITERAL+ [LITERAL+]) are allowed.
enc-検索は1*bcharと等しいです。 [IMAPABNF]の%でコード化されたバージョン。 「検索してプログラムを作ってください。」 そのIMAP4に注意してください。 リテラルは中で使用されないかもしれません。 「検索プログラム」で、すなわち、唯一。 引用されるか非連動。 リテラル(サーバサポート; LITERAL+である[LITERAL+]なら)は許容されています。
enc-section = 1*bchar
; %-encoded version of [IMAP4] "section-spec"
enc-セクションは1*bcharと等しいです。 [IMAP4]「セクション仕様」の%でコード化されたバージョン
enc-user = 1*achar
; %-encoded version of [IMAP4] authorization
; identity or "userid".
enc-ユーザは1*acharと等しいです。 [IMAP4]承認の%でコード化されたバージョン。 アイデンティティか「ユーザID。」
imapurl = "imap://" iserver ipath-query
; Defines an absolute IMAP URL
imapurlは「imap://」iserver ipath-質問と等しいです。 絶対IMAP URLを定義します。
ipath-query = ["/" [ icommand ]]
; Corresponds to "path-abempty [ "?" query ]"
; in [URI-GEN]
ipath-質問=[「/」[icommand]]。 「経路-abempty[“?"質問]」に対応しています。 コネ[URIで情報を得ます]
Generic syntax for relative URLs is defined in Section 4.2 of [URI-GEN]. For ease of implementation, the relative IMAP URL syntax is defined below:
相対的なURLのためのジェネリック構文は[URI-GEN]のセクション4.2で定義されます。 実装の容易さにおいて、相対的なIMAP URL構文は以下で定義されます:
imapurl-rel = inetwork-path
imapurl-relはinetwork-経路と等しいです。
/ iabsolute-path
/ irelative-path
/ ipath-empty
ipath「不-絶対最上級」/iabsolute-経路/経路/空です。
inetwork-path = "//" iserver ipath-query
; Corresponds to '"//" authority path-abempty
; [ "?" query ]' in [URI-GEN]
「inetwork-経路は」 //と等しい」というiserver ipath-質問。 '「//」権威経路-abempty'に対応しています。 '[“?"質問]'中[URIで情報を得ます]
iabsolute-path = "/" [ icommand ]
; icommand, if present, MUST NOT start with '/'.
;
; Corresponds to 'path-absolute [ "?" query ]'
; in [URI-GEN]
「iabsolute-経路は」 /と等しい」[icommand]。 '存在しているなら、icommandは'/'から始めてはいけません。 ; ; '経路絶対[“?"質問]'に対応しています。 コネ[URIで情報を得ます]
Melnikov & Newman Standards Track [Page 18] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[18ページ]。
irelative-path = imessagelist /
imsg-or-part
; Corresponds to 'path-noscheme [ "?" query ]'
; in [URI-GEN]
「不-絶対最上級」-経路はimessagelist / imsgか部分と等しいです。 '経路-noscheme[“?"質問]'に対応しています。 コネ[URIで情報を得ます]
imsg-or-part = ( imailbox-ref "/" iuid-only ["/" isection-only]
["/" ipartial-only] ) /
( iuid-only ["/" isection-only]
["/" ipartial-only] ) /
( isection-only ["/" ipartial-only] ) /
ipartial-only
「imsgか部分が等しい、(imailbox-審判」 /」 iuid[「/」isection専用]だけ[「/」ipartial専用)/(iuidに唯一[「/」isection専用][「/」ipartial専用]の)/(isection[「/」ipartial専用]専用)/ipartial専用
ipath-empty = 0<pchar>
; Zero characters.
; The same-document reference.
ipath空の=0<pchar>。 キャラクタのゼロを合わせてください。 ; 同じドキュメント参照。
The following three rules are only used in the presence of the IMAP [URLAUTH] extension:
以下の3つの規則しかIMAP[URLAUTH]拡張子があるとき使用されません:
authimapurl = "imap://" iserver "/" imessagepart
; Same as "imapurl" when "[icommand]" is
; "imessagepart"
」 「authimapurlは「imap://」iserverと等しく」/imessagepart。 「[icommand]」であるときに、"imapurl"と同じことがあります。 "imessagepart"
authimapurlfull = authimapurl iurlauth
; Same as "imapurl" when "[icommand]" is
; "imessagepart iurlauth"
authimapurlfullはauthimapurl iurlauthと等しいです。 「[icommand]」であるときに、"imapurl"と同じことがあります。 "imessagepart iurlauth"
authimapurlrump = authimapurl iurlauth-rump
authimapurlrumpはauthimapurl iurlauth-臀部と等しいです。
enc-urlauth = 32*HEXDIG
enc-urlauthは32*HEXDIGと等しいです。
iurlauth = iurlauth-rump iua-verifier
iurlauthはiurlauth-臀部iua-検証と等しいです。
iua-verifier = ":" uauth-mechanism ":" enc-urlauth
「iua-検証=」:、」 「uauth-メカニズム」:、」 enc-urlauth
iurlauth-rump = [expire] ";URLAUTH=" access
「iurlauth-臀部=[吐き出す]」; URLAUTHは」 アクセスと等しいです。
access = ("submit+" enc-user) / ("user+" enc-user) /
"authuser" / "anonymous"
アクセスは(「+を提出してください」というenc-ユーザ)/(「ユーザ+」encユーザ)/"authuser"/「匿名」と等しいです。
expire = ";EXPIRE=" date-time
; date-time is defined in [DATETIME]
」日付「=を吐き出してください」; 期限が切れる=時間。 日付-時間は中で定義されます。[DATETIME]
uauth-mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
; Case-insensitive.
; New mechanisms MUST be registered with IANA.
「uauth-メカニズム=「インターナル」/1*、(アルファ/ケタ/「-」/、」、」、)、。 大文字と小文字を区別しない。 ; 新しいメカニズムをIANAに登録しなければなりません。
Melnikov & Newman Standards Track [Page 19] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[19ページ]。
iauth = ";AUTH=" ( "*" / enc-auth-type )
「iauth=」 ; AUTH=、」(enc-auth「*」/タイプ)
icommand = imessagelist /
imessagepart [iurlauth]
icommandはimessagelist / imessagepartと等しいです。[iurlauth]
imailbox-ref = enc-mailbox [uidvalidity]
imailbox-審判=enc-メールボックス[uidvalidity]
imessagelist = imailbox-ref [ "?" enc-search ]
; "enc-search" is [URI-GEN] "query".
imessagelistはimailbox-審判[“?" enc-検索]と等しいです。 「enc-検索」は[URI-GEN]「質問」です。
imessagepart = imailbox-ref iuid [isection] [ipartial]
imessagepartはimailbox-審判iuidと等しいです[isection]。[ipartial]
ipartial = "/" ipartial-only
「ipartialは」 /と等しく」ipartial専用
ipartial-only = ";PARTIAL=" partial-range
部分的な「ipartialだけ=」;=、」 部分的な範囲
isection = "/" isection-only
「isectionは」 /と等しく」isection専用
isection-only = ";SECTION=" enc-section
「isectionだけ=」; セクションは」 enc-セクションと等しいです。
iserver = [iuserinfo "@"] host [ ":" port ]
; This is the same as "authority" defined
; in [URI-GEN]. See [URI-GEN] for "host"
; and "port" definitions.
iserverはホスト[「:」 ポート]と等しいです[iuserinfo"@"]。 これは定義された「権威」と同じです。 [URIで情報を得ます]で。 「ホスト」のために見てください[URIで情報を得ます]。 そして、「ポート」定義。
iuid = "/" iuid-only
「iuidは」 /と等しく」iuid専用
iuid-only = ";UID=" nz-number
; See [IMAP4] for "nz-number" definition
「iuidだけ=」; UIDは」 nz-数と等しいです。 「nz-数」定義に関して[IMAP4]を見てください。
iuserinfo = enc-user [iauth] / [enc-user] iauth
; conforms to the generic syntax of
; "userinfo" as defined in [URI-GEN].
iuserinfoはenc-ユーザ[iauth]/[encユーザ]iauthと等しいです。 ジェネリック構文に従う、。 [URI-GEN]で定義される"userinfo"。
partial-range = number ["." nz-number]
; partial FETCH. The first number is
; the offset of the first byte,
; the second number is the length of
; the fragment.
部分的な範囲=番号、[「. 」 nz-数、]、。 部分的なFETCH。 最初の数はそうです。 最初のバイトのオフセット。 2番目の数が長さである、。 断片。
uidvalidity = ";UIDVALIDITY=" nz-number
; See [IMAP4] for "nz-number" definition
「uidvalidity=」; UIDVALIDITYは」 nz-数と等しいです。 「nz-数」定義に関して[IMAP4]を見てください。
Melnikov & Newman Standards Track [Page 20] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[20ページ]。
12. IANA Considerations
12. IANA問題
IANA has updated the "imap" definition in the "Uniform Resource Identifier scheme registry" to point to this document.
IANAは、このドキュメントを示すために「Uniform Resource Identifier体系登録」との"imap"定義をアップデートしました。
The registration template (as per [URI-REG]) is specified in Section 12.1 of this document.
登録テンプレート([URI-REG]に従って)はこのドキュメントのセクション12.1で指定されます。
12.1. IANA Registration of imap: URI Scheme
12.1. imapのIANA Registration: URI体系
This section provides the information required to register the imap: URI scheme.
このセクションはimapを登録するのに必要である情報を提供します: URI体系。
URI scheme name: imap
URI体系名: imap
Status: permanent
状態: 永久的
URI scheme syntax:
URI体系構文:
See Section 11 of [RFC5092].
[RFC5092]のセクション11を見てください。
URI scheme semantics:
URI体系意味論:
The imap: URI scheme is used to designate IMAP servers, mailboxes,
messages, MIME bodies [MIME] and their parts, and search programs
on Internet hosts accessible using the IMAP protocol.
imap: URI体系は、インターネット・ホストの上でIMAPプロトコルを使用することでアクセスしやすい状態でIMAPサーバ、メールボックス、メッセージ、MIME本体[MIME]、彼らの部品、および検索プログラムを指定するのに使用されます。
There is no MIME type associated with this URI.
このURIに関連しているどんなMIMEの種類もありません。
Encoding considerations:
問題をコード化します:
See Section 8 of [RFC5092].
[RFC5092]のセクション8を見てください。
Applications/protocols that use this URI scheme name:
このURI体系を使用するアプリケーション/プロトコルが以下を命名します。
The imap: URI is intended to be used by applications that might
need access to an IMAP mailstore. Such applications may include
(but are not limited to) IMAP-capable web browsers; IMAP clients
that wish to access a mailbox, message, or edit a message on the
server using [CATENATE]; [SUBMIT] clients and servers that are
requested to assemble a complete message on submission using
[BURL].
imap: IMAP mailstoreへのアクセスを必要とするかもしれないアプリケーションでURIが使用されることを意図します。 しかし、そのようなアプリケーションが含むかもしれない、(制限されない、)、IMAP有能なウェブブラウザ。 メールボックス、メッセージにアクセスしたいか、または[CATENATE]を使用することでサーバに関するメッセージを編集したがっているIMAPクライアント。 [SUBMIT] [BURL]を使用することで服従に関する完全なメッセージを組み立てるよう要求されているクライアントとサーバ。
Interoperability considerations:
相互運用性問題:
A widely deployed IMAP client Netscape Mail (and possibly
Mozilla/Thunderbird/Seamonkey) uses a different imap: scheme
internally.
広く配布しているIMAPクライアントNetscapeメール(そして、ことによるとMozilla/カミナリ鳥/Seamonkey)は異なったimapを使用します: 内部的に計画してください。
Melnikov & Newman Standards Track [Page 21] RFC 5092 IMAP URL Scheme November 2007
メリニコフとニューマンStandardsはIMAP URL体系2007年11月にRFC5092を追跡します[21ページ]。
Security considerations:
セキュリティ問題:
See Security Considerations (Section 10) of [RFC5092].
[RFC5092]のセキュリティ問題(セクション10)を見てください。
Contact:
接触:
Alexey Melnikov <alexey.melnikov@isode.com>
Alexey Melnikov <alexey.melnikov@isode.com 、gt。
Author/Change controller:
コントローラを書くか、または変えてください:
IESG
IESG
References:
参照:
[RFC5092] and [IMAP4].
[RFC5092]と[IMAP4。]
13. References
13. 参照
13.1. Normative References
13.1. 引用規格
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to
IMAP4 ABNF", RFC 4466, April 2006.
[IMAPABNF] メリニコフとA.とC.Daboo、「IMAP4 ABNFへの集まっている拡大」、RFC4466、2006年4月。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
解放された[MIME]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。
[URI-GEN] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[URIで情報を得ます] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
May 1998.
[名前空間] Gahrns、M.、およびC.ニューマン(「IMAP4名前空間」、RFC2342)は1998がそうするかもしれません。
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
January 1997.
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088, January 1997.
Melnikov & Newman Standards Track [Page 22] RFC 5092 IMAP URL Scheme November 2007
Melnikov & Newman Standards Track [Page 22] RFC 5092 IMAP URL Scheme November 2007
[ANONYMOUS] Zeilenga, K., "Anonymous Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4505, June 2006.
[ANONYMOUS] Zeilenga, K., "Anonymous Simple Authentication and Security Layer (SASL) Mechanism", RFC 4505, June 2006.
[DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002.
[DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) -
URLAUTH Extension", RFC 4467, May 2006.
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - URLAUTH Extension", RFC 4467, May 2006.
13.2. Informative References
13.2. Informative References
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for
Mail", RFC 4409, April 2006.
[SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[BURL] Newman, C., "Message Submission BURL Extension", RFC
4468, May 2006.
[BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP)
CATENATE Extension", RFC 4469, April 2006.
[CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) CATENATE Extension", RFC 4469, April 2006.
[SASL] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
June 2006.
[SASL] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[GSSAPI] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple
Authentication and Security Layer (SASL) Mechanism", RFC
4752, November 2006.
[GSSAPI] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as
a SASL Mechanism", RFC 2831, May 2000.
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[URI-REG] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006.
[URI-REG] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 115, RFC 4395, February 2006.
Melnikov & Newman Standards Track [Page 23] RFC 5092 IMAP URL Scheme November 2007
Melnikov & Newman Standards Track [Page 23] RFC 5092 IMAP URL Scheme November 2007
Appendix A. Sample Code
Appendix A. Sample Code
Here is sample C source code to convert between URL paths and IMAP mailbox names, taking into account mapping between IMAP's modified UTF-7 [IMAP4] and hex-encoded UTF-8, which is more appropriate for URLs. This code has not been rigorously tested nor does it necessarily behave reasonably with invalid input, but it should serve as a useful example. This code just converts the mailbox portion of the URL and does not deal with parameters, query, or server components of the URL.
Here is sample C source code to convert between URL paths and IMAP mailbox names, taking into account mapping between IMAP's modified UTF-7 [IMAP4] and hex-encoded UTF-8, which is more appropriate for URLs. This code has not been rigorously tested nor does it necessarily behave reasonably with invalid input, but it should serve as a useful example. This code just converts the mailbox portion of the URL and does not deal with parameters, query, or server components of the URL.
/* Copyright (C) The IETF Trust (2007). This version of sample C code is part of RFC XXXX; see the RFC itself for full legal notices.
/* Copyright (C) The IETF Trust (2007). This version of sample C code is part of RFC XXXX; see the RFC itself for full legal notices.
Regarding this sample C code (or any portion of it), the authors make no guarantees and are not responsible for any damage resulting from its use. The authors grant irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information.
Regarding this sample C code (or any portion of it), the authors make no guarantees and are not responsible for any damage resulting from its use. The authors grant irrevocable permission to anyone to use, modify, and distribute it in any way that does not diminish the rights of anyone else to use, modify, and distribute it, provided that redistributed derivative works do not contain misleading author or version information.
Derivative works need not be licensed under similar terms. */
Derivative works need not be licensed under similar terms. */
#include <stdio.h> #include <string.h>
#include <stdio.h> #include <string.h>
/* hexadecimal lookup table */ static const char hex[] = "0123456789ABCDEF";
/* hexadecimal lookup table */ static const char hex[] = "0123456789ABCDEF";
#define XX 127
/*
* Table for decoding hexadecimal in %encoding
*/
static const char index_hex[256] = {
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9,XX,XX, XX,XX,XX,XX,
XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
#define XX 127 /* * Table for decoding hexadecimal in %encoding */ static const char index_hex[256] = { XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9,XX,XX, XX,XX,XX,XX, XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,10,11,12, 13,14,15,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
Melnikov & Newman Standards Track [Page 24] RFC 5092 IMAP URL Scheme November 2007
Melnikov & Newman Standards Track [Page 24] RFC 5092 IMAP URL Scheme November 2007
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX,
};
#define HEXCHAR(c) (index_hex[(unsigned char)(c)])
XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, XX,XX,XX,XX, }; #define HEXCHAR(c) (index_hex[(unsigned char)(c)])
/* "gen-delims" excluding "/" but including "%" */ #define GENERAL_DELIMS_NO_SLASH ":?#[]@" "%"
/* "gen-delims" excluding "/" but including "%" */ #define GENERAL_DELIMS_NO_SLASH ":?#[]@" "%"
/* "gen-delims" (excluding "/", but including "%")
plus subset of "sub-delims" */
#define GENERAL_UNSAFE_NO_SLASH GENERAL_DELIMS_NO_SLASH ";&=+"
#define OTHER_UNSAFE " \"<>\\^`{|}"
/* "gen-delims" (excluding "/", but including "%") plus subset of "sub-delims" */ #define GENERAL_UNSAFE_NO_SLASH GENERAL_DELIMS_NO_SLASH ";&=+" #define OTHER_UNSAFE " \"<>\\^`{|}"
/* URL unsafe printable characters */
static const char mailbox_url_unsafe[] = GENERAL_UNSAFE_NO_SLASH
OTHER_UNSAFE;
/* URL unsafe printable characters */ static const char mailbox_url_unsafe[] = GENERAL_UNSAFE_NO_SLASH OTHER_UNSAFE;
/* UTF7 modified base64 alphabet */ static const char base64chars[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,";
/* UTF7 modified base64 alphabet */ static const char base64chars[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+,";
#define UNDEFINED 64
#define UNDEFINED 64
/* UTF16 definitions */ #define UTF16MASK 0x03FFUL #define UTF16SHIFT 10 #define UTF16BASE 0x10000UL #define UTF16HIGHSTART 0xD800UL #define UTF16HIGHEND 0xDBFFUL #define UTF16LOSTART 0xDC00UL #define UTF16LOEND 0xDFFFUL
/* UTF16 definitions */ #define UTF16MASK 0x03FFUL #define UTF16SHIFT 10 #define UTF16BASE 0x10000UL #define UTF16HIGHSTART 0xD800UL #define UTF16HIGHEND 0xDBFFUL #define UTF16LOSTART 0xDC00UL #define UTF16LOEND 0xDFFFUL
/* Convert an IMAP mailbox to a URL path
* dst needs to have roughly 4 times the storage space of src
* Hex encoding can triple the size of the input
* UTF-7 can be slightly denser than UTF-8
* (worst case: 8 octets UTF-7 becomes 9 octets UTF-8)
*/
void MailboxToURL(char *dst, char *src)
{
unsigned char c, i, bitcount;
unsigned long ucs4, utf16, bitbuf;
unsigned char base64[256], utf8[6];
/* Convert an IMAP mailbox to a URL path * dst needs to have roughly 4 times the storage space of src * Hex encoding can triple the size of the input * UTF-7 can be slightly denser than UTF-8 * (worst case: 8 octets UTF-7 becomes 9 octets UTF-8) */ void MailboxToURL(char *dst, char *src) { unsigned char c, i, bitcount; unsigned long ucs4, utf16, bitbuf; unsigned char base64[256], utf8[6];
/* initialize modified base64 decoding table */
/* initialize modified base64 decoding table */
Melnikov & Newman Standards Track [Page 25] RFC 5092 IMAP URL Scheme November 2007
Melnikov & Newman Standards Track [Page 25] RFC 5092 IMAP URL Scheme November 2007
memset(base64, UNDEFINED, sizeof (base64));
for (i = 0; i < sizeof (base64chars); ++i) {
base64[(int) base64chars[i]] = i;
}
memset(base64, UNDEFINED, sizeof (base64)); for (i = 0; i < sizeof (base64chars); ++i) { base64[(int) base64chars[i]] = i; }
/* loop until end of string */
while (*src != '%%BODY%%') {
c = *src++;
/* deal with literal characters and &- */
if (c != '&' || *src == '-') {
/* NB: There are no "URL safe" characters after the '~' */
if (c < ' ' || c > '~' ||
strchr(mailbox_url_unsafe, c) != NULL) {
/* hex encode if necessary */
dst[0] = '%';
dst[1] = hex[c >> 4];
dst[2] = hex[c & 0x0f];
dst += 3;
} else {
/* encode literally */
*dst++ = c;
}
/* skip over the '-' if this is an &- sequence */
if (c == '&') ++src;
/* loop until end of string */ while (*src != '%%BODY%%') { c = *src++; /* deal with literal characters and &- */ if (c != '&' || *src == '-') { /* NB: There are no "URL safe" characters after the '~' */ if (c < ' ' || c > '~' || strchr(mailbox_url_unsafe, c) != NULL) { /* hex encode if necessary */ dst[0] = '%'; dst[1] = hex[c >> 4]; dst[2] = hex[c & 0x0f]; dst += 3; } else { /* encode literally */ *dst++ = c; } /* skip over the '-' if this is an &- sequence */ if (c == '&') ++src;
} else {
/* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */
bitbuf = 0;
bitcount = 0;
ucs4 = 0;
while ((c = base64[(unsigned char) *src]) != UNDEFINED) {
++src;
bitbuf = (bitbuf << 6) | c;
bitcount += 6;
/* enough bits for a UTF-16 character? */
if (bitcount >= 16) {
bitcount -= 16;
utf16 = (bitcount ? bitbuf >> bitcount
: bitbuf) & 0xffff;
/* convert UTF16 to UCS4 */
if
(utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) {
ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT;
continue;
} else if
(utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) {
ucs4 += utf16 - UTF16LOSTART + UTF16BASE;
} else {
} else { /* convert modified UTF-7 -> UTF-16 -> UCS-4 -> UTF-8 -> HEX */ bitbuf = 0; bitcount = 0; ucs4 = 0; while ((c = base64[(unsigned char) *src]) != UNDEFINED) { ++src; bitbuf = (bitbuf << 6) | c; bitcount += 6; /* enough bits for a UTF-16 character? */ if (bitcount >= 16) { bitcount -= 16; utf16 = (bitcount ? bitbuf >> bitcount : bitbuf) & 0xffff; /* convert UTF16 to UCS4 */ if (utf16 >= UTF16HIGHSTART && utf16 <= UTF16HIGHEND) { ucs4 = (utf16 - UTF16HIGHSTART) << UTF16SHIFT; continue; } else if (utf16 >= UTF16LOSTART && utf16 <= UTF16LOEND) { ucs4 += utf16 - UTF16LOSTART + UTF16BASE; } else {
Melnikov & Newman Standards Track [Page 26] RFC 5092 IMAP URL Scheme November 2007
Melnikov & Newman Standards Track [Page 26] RFC 5092 IMAP URL Scheme November 2007
ucs4 = utf16;
}
/* convert UTF-16 range of UCS4 to UTF-8 */
if (ucs4 <= 0x7fUL) {
utf8[0] = (unsigned char) ucs4;
i = 1;
} else if (ucs4 <= 0x7ffUL) {
utf8[0] = 0xc0 | (unsigned char) (ucs4 >> 6);
utf8[1] = 0x80 | (unsigned char) (ucs4 & 0x3f);
i = 2;
} else if (ucs4 <= 0xffffUL) {
utf8[0] = 0xe0 | (unsigned char) (ucs4 >> 12);
utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f);
utf8[2] = 0x80 | (unsigned char) (ucs4 & 0x3f);
i = 3;
} else {
utf8[0] = 0xf0 | (unsigned char) (ucs4 >> 18);
utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 12) & 0x3f);
utf8[2] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f);
utf8[3] = 0x80 | (unsigned char) (ucs4 & 0x3f);
i = 4;
}
/* convert utf8 to hex */
for (c = 0; c < i; ++c) {
dst[0] = '%';
dst[1] = hex[utf8[c] >> 4];
dst[2] = hex[utf8[c] & 0x0f];
dst += 3;
}
}
}
/* skip over trailing '-' in modified UTF-7 encoding */
if (*src == '-') ++src;
}
}
/* terminate destination string */
*dst = '%%BODY%%';
}
ucs4 = utf16; } /* convert UTF-16 range of UCS4 to UTF-8 */ if (ucs4 <= 0x7fUL) { utf8[0] = (unsigned char) ucs4; i = 1; } else if (ucs4 <= 0x7ffUL) { utf8[0] = 0xc0 | (unsigned char) (ucs4 >> 6); utf8[1] = 0x80 | (unsigned char) (ucs4 & 0x3f); i = 2; } else if (ucs4 <= 0xffffUL) { utf8[0] = 0xe0 | (unsigned char) (ucs4 >> 12); utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f); utf8[2] = 0x80 | (unsigned char) (ucs4 & 0x3f); i = 3; } else { utf8[0] = 0xf0 | (unsigned char) (ucs4 >> 18); utf8[1] = 0x80 | (unsigned char) ((ucs4 >> 12) & 0x3f); utf8[2] = 0x80 | (unsigned char) ((ucs4 >> 6) & 0x3f); utf8[3] = 0x80 | (unsigned char) (ucs4 & 0x3f); i = 4; } /* convert utf8 to hex */ for (c = 0; c < i; ++c) { dst[0] = '%'; dst[1] = hex[utf8[c] >> 4]; dst[2] = hex[utf8[c] & 0x0f]; dst += 3; } } } /* skip over trailing '-' in modified UTF-7 encoding */ if (*src == '-') ++src; } } /* terminate destination string */ *dst = '%%BODY%%'; }
/* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox
* dst should be about twice the length of src to deal with non-hex
* coded URLs
*/
int URLtoMailbox(char *dst, char *src)
{
unsigned int utf8pos = 0;
unsigned int utf8total, i, c, utf7mode, bitstogo, utf16flag;
unsigned long ucs4 = 0, bitbuf = 0;
/* Convert hex coded UTF-8 URL path to modified UTF-7 IMAP mailbox * dst should be about twice the length of src to deal with non-hex * coded URLs */ int URLtoMailbox(char *dst, char *src) { unsigned int utf8pos = 0; unsigned int utf8total, i, c, utf7mode, bitstogo, utf16flag; unsigned long ucs4 = 0, bitbuf = 0;
Melnikov & Newman Standards Track [Page 27] RFC 5092 IMAP URL Scheme November 2007
Melnikov & Newman Standards Track [Page 27] RFC 5092 IMAP URL Scheme November 2007
utf7mode = 0; /* is the output UTF7 currently in base64 mode? */
utf8total = 0; /* how many octets is the current input UTF-8 char;
0 == between characters */
bitstogo = 0; /* bits that need to be encoded into base64; if
bitstogo != 0 then utf7mode == 1 */
while ((c = (unsigned char)*src) != '%%BODY%%') {
++src;
/* undo hex-encoding */
if (c == '%' && src[0] != '%%BODY%%' && src[1] != '%%BODY%%') {
c = HEXCHAR(src[0]);
i = HEXCHAR(src[1]);
if (c == XX || i == XX) {
return 0;
} else {
c = (char)((c << 4) | i);
}
src += 2;
}
/* normal character? */
if (c >= ' ' && c <= '~') {
/* switch out of UTF-7 mode */
if (utf7mode) {
if (bitstogo) {
*dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
}
*dst++ = '-';
utf7mode = 0;
bitstogo = bitbuf = 0;
}
*dst++ = c;
/* encode '&' as '&-' */
if (c == '&') {
*dst++ = '-';
}
continue;
}
/* switch to UTF-7 mode */
if (!utf7mode) {
*dst++ = '&';
utf7mode = 1;
}
/* Encode US-ASCII characters as themselves */
if (c < 0x80) {
ucs4 = c;
utf8total = 1;
} else if (utf8total) {
/* this is a subsequent octet of a multi-octet character */
/* save UTF8 bits into UCS4 */
utf7mode = 0; /* is the output UTF7 currently in base64 mode? */ utf8total = 0; /* how many octets is the current input UTF-8 char; 0 == between characters */ bitstogo = 0; /* bits that need to be encoded into base64; if bitstogo != 0 then utf7mode == 1 */ while ((c = (unsigned char)*src) != '%%BODY%%') { ++src; /* undo hex-encoding */ if (c == '%' && src[0] != '%%BODY%%' && src[1] != '%%BODY%%') { c = HEXCHAR(src[0]); i = HEXCHAR(src[1]); if (c == XX || i == XX) { return 0; } else { c = (char)((c << 4) | i); } src += 2; } /* normal character? */ if (c >= ' ' && c <= '~') { /* switch out of UTF-7 mode */ if (utf7mode) { if (bitstogo) { *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; } *dst++ = '-'; utf7mode = 0; bitstogo = bitbuf = 0; } *dst++ = c; /* encode '&' as '&-' */ if (c == '&') { *dst++ = '-'; } continue; } /* switch to UTF-7 mode */ if (!utf7mode) { *dst++ = '&'; utf7mode = 1; } /* Encode US-ASCII characters as themselves */ if (c < 0x80) { ucs4 = c; utf8total = 1; } else if (utf8total) { /* this is a subsequent octet of a multi-octet character */ /* save UTF8 bits into UCS4 */
Melnikov & Newman Standards Track [Page 28] RFC 5092 IMAP URL Scheme November 2007
Melnikov & Newman Standards Track [Page 28] RFC 5092 IMAP URL Scheme November 2007
ucs4 = (ucs4 << 6) | (c & 0x3FUL);
if (++utf8pos < utf8total) {
continue;
}
} else {
/* this is the first octet of a multi-octet character */
utf8pos = 1;
if (c < 0xE0) {
utf8total = 2;
ucs4 = c & 0x1F;
} else if (c < 0xF0) {
utf8total = 3;
ucs4 = c & 0x0F;
} else {
/* NOTE: can't convert UTF8 sequences longer than 4 */
utf8total = 4;
ucs4 = c & 0x03;
}
continue;
}
/* Finished with UTF-8 character. Make sure it isn't an
overlong sequence. If it is, return failure. */
if ((ucs4 < 0x80 && utf8total > 1) ||
(ucs4 < 0x0800 && utf8total > 2) ||
(ucs4 < 0x00010000 && utf8total > 3) ||
(ucs4 < 0x00200000 && utf8total > 4) ||
(ucs4 < 0x04000000 && utf8total > 5) ||
(ucs4 < 0x80000000 && utf8total > 6)) {
return 0;
}
/* loop to split ucs4 into two utf16 chars if necessary */
utf8total = 0;
do {
if (ucs4 >= UTF16BASE) {
ucs4 -= UTF16BASE;
bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT)
+ UTF16HIGHSTART);
ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART;
utf16flag = 1;
} else {
bitbuf = (bitbuf << 16) | ucs4;
utf16flag = 0;
}
bitstogo += 16;
/* spew out base64 */
while (bitstogo >= 6) {
bitstogo -= 6;
*dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo)
ucs4 = (ucs4 << 6) | (c & 0x3FUL); if (++utf8pos < utf8total) { continue; } } else { /* this is the first octet of a multi-octet character */ utf8pos = 1; if (c < 0xE0) { utf8total = 2; ucs4 = c & 0x1F; } else if (c < 0xF0) { utf8total = 3; ucs4 = c & 0x0F; } else { /* NOTE: can't convert UTF8 sequences longer than 4 */ utf8total = 4; ucs4 = c & 0x03; } continue; } /* Finished with UTF-8 character. Make sure it isn't an overlong sequence. If it is, return failure. */ if ((ucs4 < 0x80 && utf8total > 1) || (ucs4 < 0x0800 && utf8total > 2) || (ucs4 < 0x00010000 && utf8total > 3) || (ucs4 < 0x00200000 && utf8total > 4) || (ucs4 < 0x04000000 && utf8total > 5) || (ucs4 < 0x80000000 && utf8total > 6)) { return 0; } /* loop to split ucs4 into two utf16 chars if necessary */ utf8total = 0; do { if (ucs4 >= UTF16BASE) { ucs4 -= UTF16BASE; bitbuf = (bitbuf << 16) | ((ucs4 >> UTF16SHIFT) + UTF16HIGHSTART); ucs4 = (ucs4 & UTF16MASK) + UTF16LOSTART; utf16flag = 1; } else { bitbuf = (bitbuf << 16) | ucs4; utf16flag = 0; } bitstogo += 16; /* spew out base64 */ while (bitstogo >= 6) { bitstogo -= 6; *dst++ = base64chars[(bitstogo ? (bitbuf >> bitstogo)
Melnikov & Newman Standards Track [Page 29] RFC 5092 IMAP URL Scheme November 2007
Melnikov & Newman Standards Track [Page 29] RFC 5092 IMAP URL Scheme November 2007
: bitbuf)
& 0x3F];
}
} while (utf16flag);
}
/* if in UTF-7 mode, finish in ASCII */
if (utf7mode) {
if (bitstogo) {
*dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F];
}
*dst++ = '-';
}
/* tie off string */
*dst = '%%BODY%%';
return 1;
}
: bitbuf) & 0x3F]; } } while (utf16flag); } /* if in UTF-7 mode, finish in ASCII */ if (utf7mode) { if (bitstogo) { *dst++ = base64chars[(bitbuf << (6 - bitstogo)) & 0x3F]; } *dst++ = '-'; } /* tie off string */ *dst = '%%BODY%%'; return 1; }
Appendix B. List of Changes since RFC 2192
Appendix B. List of Changes since RFC 2192
Updated boilerplate, list of editor's, etc. Updated references. Updated ABNF not to use _, to use SP instead of SPACE, etc. Updated example domains to use example.org. Fixed ABNF error in "imessagelist" non-terminal. Updated ABNF, due to changes in RFC 3501, RFC 4466, and RFC 3986. Renamed "iuserauth" non-terminal to <iuserinfo>. Clarified that the userinfo component describes both authorization identity and mailbox naming scope. Allow for non-synchronizing literals in "enc-search". Added "ipartial" specifier that denotes a partial FETCH. Moved URLAUTH text from RFC 4467 to this document. Updated ABNF for the whole server to allow missing trailing "/" (e.g., "imap://imap.example.com" is now valid and is the same as "imap://imap.example.com/"). Clarified how relative-path references are constructed. Added more examples demonstrating relative-path references. Added rules for relative URLs and restructured ABNF as the result. Removed text on use of relative URLs in MHTML. Added examples demonstrating security considerations when resolving URLs. Recommend usage of STARTTLS/SASL security layer to protect confidential data. Removed some advices about connection reuse that were incorrect. Removed URLs referencing a list of mailboxes, as this feature hasn't seen any deployments. Clarified that user name "anonymous" is case-insensitive.
Updated boilerplate, list of editor's, etc. Updated references. Updated ABNF not to use _, to use SP instead of SPACE, etc. Updated example domains to use example.org. Fixed ABNF error in "imessagelist" non-terminal. Updated ABNF, due to changes in RFC 3501, RFC 4466, and RFC 3986. Renamed "iuserauth" non-terminal to <iuserinfo>. Clarified that the userinfo component describes both authorization identity and mailbox naming scope. Allow for non-synchronizing literals in "enc-search". Added "ipartial" specifier that denotes a partial FETCH. Moved URLAUTH text from RFC 4467 to this document. Updated ABNF for the whole server to allow missing trailing "/" (e.g., "imap://imap.example.com" is now valid and is the same as "imap://imap.example.com/"). Clarified how relative-path references are constructed. Added more examples demonstrating relative-path references. Added rules for relative URLs and restructured ABNF as the result. Removed text on use of relative URLs in MHTML. Added examples demonstrating security considerations when resolving URLs. Recommend usage of STARTTLS/SASL security layer to protect confidential data. Removed some advices about connection reuse that were incorrect. Removed URLs referencing a list of mailboxes, as this feature hasn't seen any deployments. Clarified that user name "anonymous" is case-insensitive.
Melnikov & Newman Standards Track [Page 30] RFC 5092 IMAP URL Scheme November 2007
Melnikov & Newman Standards Track [Page 30] RFC 5092 IMAP URL Scheme November 2007
Appendix C. List of Changes since RFC 4467
Appendix C. List of Changes since RFC 4467
Renamed <mechanism> to <uauth-mechanism>. Restructured ABNF.
Renamed <mechanism> to <uauth-mechanism>. Restructured ABNF.
Appendix D. Acknowledgments
Appendix D. Acknowledgments
Text describing URLAUTH was lifted from [URLAUTH] by Mark Crispin.
Text describing URLAUTH was lifted from [URLAUTH] by Mark Crispin.
Stephane H. Maes contributed some ideas to this document; he also co-edited early versions of this document.
Stephane H. Maes contributed some ideas to this document; he also co-edited early versions of this document.
The editors would like to thank Mark Crispin, Ken Murchison, Ted Hardie, Zoltan Ordogh, Dave Cridland, Kjetil Torgrim Homme, Lisa Dusseault, Spencer Dawkins, Filip Navara, Shawn M. Emery, Sam Hartman, Russ Housley, and Lars Eggert for the time they devoted to reviewing this document and/or for the comments received.
The editors would like to thank Mark Crispin, Ken Murchison, Ted Hardie, Zoltan Ordogh, Dave Cridland, Kjetil Torgrim Homme, Lisa Dusseault, Spencer Dawkins, Filip Navara, Shawn M. Emery, Sam Hartman, Russ Housley, and Lars Eggert for the time they devoted to reviewing this document and/or for the comments received.
Authors' Addresses
Authors' Addresses
Chris Newman (Author/Editor) Sun Microsystems 3401 Centrelake Dr., Suite 410 Ontario, CA 91761 EMail: chris.newman@sun.com
Chris Newman (Author/Editor) Sun Microsystems 3401 Centrelake Dr., Suite 410 Ontario, CA 91761 EMail: chris.newman@sun.com
Alexey Melnikov (Editor) Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX, UK EMail: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/
Alexey Melnikov (Editor) Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX, UK EMail: Alexey.Melnikov@isode.com URI: http://www.melnikov.ca/
Melnikov & Newman Standards Track [Page 31] RFC 5092 IMAP URL Scheme November 2007
Melnikov & Newman Standards Track [Page 31] RFC 5092 IMAP URL Scheme November 2007
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Melnikov & Newman Standards Track [Page 32]
Melnikov & Newman Standards Track [Page 32]
一覧
スポンサーリンク
