メインコンテンツまでスキップ

4. データ形式 (Data Formats)

アトム (atom) は, 1 つ以上の非特殊文字で構成される.

4.2. 数値 (Number)​

数値 (number) は, 1 つ以上の数字文字で構成され, 数値を表す.

4.3. 文字列 (String)​

文字列 (string) は, リテラル (literal) と引用符付き文字列 (quoted string) の 2 つの形式のいずれかである. リテラル形式は文字列の一般的な形式である. 引用符付き文字列形式は, 使用できる文字の制限を代償として, リテラルの処理のオーバーヘッドを回避する代替形式である.

リテラルは, ゼロ個以上のオクテット (CR と LF を含む) のシーケンスであり, 左中括弧 ("\{"), オクテット数, 右中括弧 ("\}"), CRLF の形式でオクテット数が前置引用される. サーバーからクライアントに送信されるリテラルの場合, CRLF の直後にオクテットデータが続く. クライアントからサーバーに送信されるリテラルの場合, クライアントは, オクテットデータ (およびコマンドの残り) を送信する前に, コマンド継続リクエスト (この文書で後述) を受信するまで待たなければならない (MUST).

引用符付き文字列は, CR と LF を除くゼロ個以上の 7-bit 文字のシーケンスであり, 両端に二重引用符 (<">) 文字が付く.

空文字列は, "" (二重引用符の間にゼロ文字の引用符付き文字列) または \{0\} の後に CRLF (オクテット数が 0 のリテラル) として表される.

 注記: オクテット数が 0 の場合でも, リテラルを送信するクライアントは, コマンド継続リクエストを受信するまで待たなければならない (MUST).

RFC 3501 IMAPv4 March 2003

4.3.1. 8-bit およびバイナリ文字列 (8-bit and Binary Strings)​

8-bit テキストおよびバイナリメールは, [MIME-IMB] コンテンツ転送エンコーディングの使用を通じてサポートされる. IMAP4rev1 実装は, リテラル内で 8-bit またはマルチオクテット文字を送信してもよい (MAY) が, [CHARSET] が識別されている場合にのみ行うべきである (SHOULD).

バイナリボディエンコーディングが定義されているが, エンコードされていないバイナリ文字列は許可されない. 「バイナリ文字列 (binary string)」とは, NUL 文字を含む任意の文字列である. 実装は, データを送信する前に, バイナリデータを BASE64 などのテキスト形式にエンコードしなければならない (MUST). CTL 文字が過剰に含まれる文字列も, バイナリと見なしてもよい (MAY).

4.4. 括弧付きリスト (Parenthesized List)​

データ構造は「括弧付きリスト (parenthesized list)」として表される: スペースで区切られ, 両端が括弧で囲まれたデータ項目のシーケンスである. 括弧付きリストは, 複数レベルの括弧を使用してネストを示す, 他の括弧付きリストを含むことができる.

空のリストは () -- メンバーのない括弧付きリストとして表される.

4.5. NIL​

特殊形式「NIL」は, 文字列または括弧付きリストとして表される特定のデータ項目の非存在を表し, 空文字列 "" や空の括弧付きリスト () とは区別される.

    注記: NIL は, アトムの形式を取るデータ項目には決して使用されない. 例えば, 「NIL」というメールボックス名は, 存在しないメールボックス名ではなく, NIL という名前のメールボックスである. これは, メールボックスがアトムまたは文字列である「astring」構文を使用するためである. 逆に, NIL の addr-name は存在しない個人名である. これは, addr-name が NIL または文字列であるが, 決してアトムではない「nstring」構文を使用するためである.

RFC 3501 IMAPv4 March 2003

  1.  運用上の考慮事項 (Operational Considerations)

    以下の規則は, すべての IMAP4rev1 実装が適切に相互運用できるようにするためにここに列挙されている.

5.1. メールボックス命名 (Mailbox Naming)​

メールボックス名は 7-bit である. クライアント実装は 8-bit のメールボックス名を作成しようとしてはならず (MUST NOT), LIST または LSUB によって返された 8-bit のメールボックス名を UTF-8 として解釈すべきである (SHOULD). サーバー実装は 8-bit のメールボックス名の作成を禁止すべきであり (SHOULD), LIST または LSUB で 8-bit のメールボックス名を返すべきではない (SHOULD NOT). 非 ASCII のメールボックス名を表現する方法の詳細については, セクション 5.1.3 を参照のこと.

    注記: 8-bit のメールボックス名は, このプロトコルの初期バージョンでは未定義だった. 一部のサイトでは, 非 ASCII のメールボックス名を表現するためにローカルな 8-bit 文字セットを使用していた. そのような使用法は相互運用できず, 現在は正式に非推奨となっている.

大文字と小文字を区別しないメールボックス名 INBOX は, 「このユーザーのこのサーバー上のプライマリメールボックス」を意味するために予約された特別な名前である. その他すべての名前の解釈は実装依存である.

特に, この仕様は, INBOX 以外のメールボックス名の大文字と小文字の区別については立場を取らない. 一部のサーバー実装は完全に大文字と小文字を区別する. 他の実装は, 新しく作成された名前の大文字と小文字を保持するが, その他は大文字と小文字を区別しない. さらに他の実装は, 名前を特定の大文字と小文字に強制する. クライアント実装は, これらのいずれとも相互運用しなければならない (MUST). サーバー実装が INBOX 以外のメールボックス名を大文字と小文字を区別しないものとして解釈する場合, セクション 5.1.3 で説明されているように, 国際命名規則を使用する名前を特別に扱わなければならない (MUST).

新しいメールボックス名を作成する際のクライアントの考慮事項がいくつかある:

  1. アトム特殊文字 (atom-specials) (正式構文 (Formal Syntax) を参照) のいずれかである文字は, メールボックス名を引用符付き文字列またはリテラルとして表現することを要求する.