この標準情報(TR)は, 1998年9月にInternet Engineering Task Force (IETF)から公表されたRFC 2425, A MIME Content-Type for Directory Informationを翻訳し, 技術的内容を変更することなく作成した標準情報(TR)である。
この規定は，ディレクトリ情報を保持するためのMIME内容型を定義する。この定義は，特定のディレクトリサービス又はプロトコルから独立とする。text/directory内容型は，例えば，名前，電子メール用番地，ロゴなどの，様々なディレクトリ情報を保持するために定義される。text/directory内容型は，より複雑な状況を操作するためにmultipart/related内容型のルート本体部分として使うこともできる。特に，例えば，写真又は音といったMIME表現をもつ非テキスト情報が表現される場合に適用できる。
text/directoryは，単純な"型：値"の形式でディレクトリ情報を保持するための一般的なフレームワーク及びフォーマットを定義する。"型"は，値が関連付けられている特性又は属性を意味する。代替となる言語，符号化及びその他のメタ情報を指定するために，幾つかの機構を定義する。この規定は，text/directory内容型内にアプリケーション特有の情報を運ぶために，プロファイルと呼ばれる特定のフォーマットを定義し登録することが可能な手続き，及びそれらのフォーマットが従わなければならない規約も定義する。 例えば電話帳などの様々なアプリケーションのために，これらのフォーマットを定義する他の文書が作成されることが期待される。
原規定において，"MUST"，"MUST NOT"，"REQUIRED"，"SHOULD"，"SHOULD NOT"，"RECOMMENDED"，"MAY"及び"OPTIONAL"が用いられている場合，[RFC2119]に規定するとおりに解釈する。
参考1 この標準情報(TR)では，これらに対応する用語として次を用いる。
"MUST"及び"REQUIRED"に対応して，"…(し)なければならない。"，"…する。"，"…とする。"，"…による。"又は"必す(須)"を使用する。"MUST NOT"に対応して，"…(し)てはならない。"又は"…(し)ない。"を使用する。"SHOULD"及び"RECOMMENDED"に対応して，"…することが望ましい。"又は"…するのがよい。"を使用する。"SHOULD NOT"に対応して，"…しないほうがよい。"を使用する。"MAY"に対応して，"…(し)てもよい。"又は"…差し支えない。"を使用する。"OPTIONAL"に対応して，"オプション(の)"を使用する。
参考2 この標準情報(TR)での逆スラッシュ(backslash)記号は，日本語環境では，しばしば円記号('\')として表示されることがある点に注意すること。
参考3 この標準情報(TR)の，9, 11，13及び15の各節で示される登録テンプレート及び登録内容は，実際の登録時には英語で行うことが必要とされる。それぞれの節に，原規定の英語による登録テンプレートを備考として示す。
この規定の目的のためには，ディレクトリとは，型付けされた情報を含む特定の目的のデータベースとする。ディレクトリは，通常，含まれる情報の読込み及び検索の両方をサポートし，情報の生成及び修正も同様にサポート可能とする。ディレクトリ情報は，通常，更新されるよりもはるかに多くアクセスされる。ディレクトリの適用範囲は，局所的又は大域的とする。ディレクトリは，分散することも，集中することもできる。ディレクトリが含む情報は，弱い又は強い一貫性の要件のもとに，複製できる。
インタネットメールの利用者がディレクトリ情報を交換したいと思う状況が幾つかある。例えば，"名刺"交換の電子メール版，インタネットへ電子メールだけでアクセスする利用者へのディレクトリ情報の交付，インタネット上で品物又はサービスを購入する場合の機械解析可能なアドレス情報の提供などである。MIME[RFC-2045，RFC-2046]が，(ほとんど場合HTTPだが)他のプロトコルによって徐々に使われるようになるにつれて，これらプロトコルがMIMEフォーマットでディレクトリ情報を運ぶことも有用になる。例えば，これらフォーマットは，WWWの資源に関するURC(uniform resource characteristics，統一資源特徴)情報を表現したり，HTTP上で基本的なディレクトリ情報を提供するために使用できる。
MIME内容型でディレクトリ情報を表現するためにこの規定で定義されるスキーマは，二つの部分から成る。まず，単一の本体部分内にディレクトリ情報を保持するという利用のために，text/directoryの内容型が定義される。これには，例えば，名前，タイトル又は電子メールアドレスがある。その最も簡単な形式では，フォーマットに"型：値"の手法を使うが，これは，簡単に既存のMIME実装で構文解析可能で，利用者にも理解可能であることが望ましい。さらに複雑な状況も表現可能とする。すなわち，この規定は，その内容型における情報がもつことが望ましい一般的な形式を定義し，特別なアプリケーションに対して特別な型及び値(すなわち，特性)を定義できる手続きを定義する。そのフレームワークは，LDAP[RFC-1777, RFC-1778], WHOIS++ [RFC-1835]及びX.500 [X500]を含む，任意個の末端デイレクトリサービスからの情報を取り扱うのに十分なほど一般的とする。
ディレクトリエントリは，テキスト情報だけでなくそれ以外の多くのものを含むことができる。画像，音などの幾つかの情報は，定義済みのMIME内容型と重複する。これらの場合には，よく知られているMIMEフォーマットでその情報を含めることが望ましい。この状況は，[RFC-2112]に定義されるとおりのmultipart/related内容型を使うことで取り扱われる。この型のルート構成要素は，あらゆる行内情報を指定し，他の内容型に含まれる情報に対しては，それら内容型の部分の(URI形式での)内容識別子を指定するtext/directory本体部分とする。
幾つかのアプリケーションでは，ディレクトリ情報自体よりはむしろ，その情報へのポインタ(例えば，URI)を含むほうが有用になる。この規定では，これを達成するための一般的な機構を定義する。
text/directory内容型は，基本的なディレクトリ情報を保持し，さらに，画像又は音といった補足的な又は非テキストの情報をもつ他のMIME本体部分を含む，他の情報のURI参照を保持するために使用する。これは，[RFC-2048]で規定されるMIMEメディア型登録テンプレートを使って次のとおりに定義される。
宛先: ietf-types@uninett.no 件名: MIMEメディア型text/directoryの登録
MIMEメディア型名: text
MIME下位型名: directory
必す(須)パラメタ: charset
"charset"パラメタは，他の本体部分のために[RFC-2046]で定義されるとおりとする。これは，本体部分内で使われるデフォルトの文字集合を識別するために使用する。
オプションパラメタ: profile
"profile"パラメタは，ディレクトリ情報が属している実体の型，及びその実体に関連する情報の可能な集合を運ぶために使用する。本体部分内に含まれる情報を解釈するアプリケ−ションへの指針とすることだけが意図されている。プロファイル定義がこの振る舞いを特に要求しない場合，情報の特定の断片を排除又は要求するために使うことは望ましくない。特定のプロファイル定義によって特に禁止されていない場合には，text/directory内容型は，任意の属性及び値の対を含むことができる。
"profile"パラメタの値は，次のとおりに定義される。プロファイル名は，大文字と小文字とを区別しない。例えば，プロファイル名"vCard"は，"VCARD"，"vcard"及び"vcArD"と同じとする。
profile = x-name / iana-token x-name = "x-" 1*(ALPHA / DIGIT / "-") ; "x-"又は"X-"で始まる名前は，製品としての出荷を ; 意図していない実験的な使用のために，又は双方の ; 合意での使用のために予約される。 iana-token = <この規定の9.で指定されるとおりに，IANAで登録された， 公的に定義された拡張トークン。>
デフォルトの符号化は，8ビットとする。そうでない場合には，Content-Transfer-Encodingヘッダフィールドによって指定されるとおりとする。
ディレクトリ情報は公開可能か，又は無許可のアクセスからその情報が存在するディレクトリサービスによって保護可能とする。一度，情報がその元のサービスから分離すると，その情報を扱うすべてのサービスによって同じ注意がなされるという保証は存在しない。さらに，この規定は，情報が保護可能となる，又はアクセス制御情報が伝達可能となるアクセス制御機構を定義しない。text/directory本体部分の完全性及びプライバシは，適切なMIMEに基づくセキュリティ機構の内部にその本体部分を囲い込むことによって保護可能となる点に注意すること。
ディレクトリ情報を理解するために，アプリケーションは，内容型内に含まれる情報型(ディレクトリスキーマ)の共通理解を共有しなければならない。このスキーマ情報は，この規定では定義されないが，この規定で指定される要件に従う関連規定(例えば，[MIME-VCARD])において，又は通信する両者の間の双方向の合意において定義される。
text/directory内容型は，ディレクトリ情報を含む。これは，典型的には，単一のディレクトリ実体又は実体のグループに属するものとする。その内容は，5.8で与えられるフォーマットの一つ以上の行から成る。
MIME text/directory内容型の本体の内部の個々の行は，CRLFという列(ASCIIの10進表現で13及び10と続くもの)である[RFC-822]行切りによって区切られる。テキストの長い論理行は，次の行継続技法を使って，複数の物理行表現に分けることができる。
論理行は，一つのCRLFのすぐ後に単一の空白文字(ASCIIの10進表現で32のスペース又はASCIIの10進表現で9の水平タブ)を続けたものを挿入することによって，二つの文字間の任意の場所で次の物理行に継続してよい。少なくとも一つの文字が，継続された行に表れなければならない。CRLFのすぐ後に単一の空白文字を続けた列は，内容型を処理する場合には，無視され，取り除かれる。次に例を示す。
DESCRIPTION:This is a long description that exists on a long line.これは，次のとおりに表現できる。
DESCRIPTION:This is a long description that exists on a long line.次のとおりにも表現できる。
DESCRIPTION:This is a long descrip tion that exists o n a long line.
型定義のこの継続された複数行表現から単一の行表現へと変える処理を，行非継続と呼ぶ。行非継続は，CRLFのすぐ後に空白文字(すなわち，ASCIIの10進表現で9のHTAB又はASCIIの10進表現で32のSPACE)を何も文字がないのと等価とみなすことで達成される。すなわち，CRLF及び単一の空白文字は，取り除かれる。
次のABNFは，RFC2234の記法を使う。RFC2234は，CRLF，WSP，DQUOTE，VCHAR，ALPHA及びDIGITも定義する。5.8.1で示したとおりに，継続された行を行非継続とした後，この内容型の行の構文は，次のとおりとなる。
contentline = [group "."] name *(";" param) ":" value CRLF
; 内容行を構文解析する場合，継続された行は，最初に，
; 5.1.8に示した行非継続の手続きに従い，行非継続と
; しなければならない。
; 内容行を生成する場合，75文字よりも長い行は，
; 5.1.8に示した行継続手続きに従い，行継続することが
; 望ましい。
group = 1*(ALPHA / DIGIT / "-")
name = x-name / iana-token
iana-token = 1*(ALPHA / DIGIT / "-")
; IANAに登録された識別子。
x-name = "x-" 1*(ALPHA / DIGIT / "-")
; "x-"又は"X-"で始まる名前は，製品としての出荷を
; 意図していない実験的な使用のために，又は双方の
; 合意での使用のために予約される。
param = param-name "=" param-value *("," param-value)
param-name = x-name / iana-token
param-value = ptext / quoted-string
ptext = *SAFE-CHAR
value = *VALUE-CHAR
/ valuespec ; 5.8.4で定義されるvaluespec。
quoted-string = DQUOTE *QSAFE-CHAR DQUOTE
NON-ASCII = %x80-FF
; 外側のMIMEオブジェクト上のcharsetパラメタ
; によって制限される使用(UTF-8が望ましい。)。
QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-ASCII
; CTLs及びDQUOTEを除く任意の文字。
SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-ASCII
; CTLs, DQUOTE, ";", ":",及び","を除く任意の文字。
VALUE-CHAR = WSP / VCHAR / NON-ASCII
; 任意のテキスト文字。
一つの空白文字で始まる行は，5.1.8で示したとおり，その前の行の継続とする。空白文字及びそれのすぐ前にあるCRLFは，元の行を再構築する場合には，捨てられることが望ましい。この行継続規約は，RFC822にあるものとは異なることに注意すること。RFC822では，内容の任意の場所にある列 様々な型の名前及びその対応する値のフォーマットは，11.に指定されるとおりに定義される。デフォルトでは何も要求しないが，各種規定が，本体部分内の型構成要素に順番を課してもよい。様々なx-name構成要素は，双方で合意した型名，パラメタ名及びパラメタ値のために，又は実験的な使用のために使用される。
型名及びパラメタ名は，大文字と小文字とを区別しない。例えば，型名"fn"は，"FN"及び"Fn"と同じとする。パラメタ値は，その定義に依存して，大文字と小文字との区別をしてもしなくてもよい。
グループ構成要素は，関連する属性を一緒にグループ化するために使用する。グループ名は，アプリケーションが表示する場合，同じグループ名で始まるすべての型名を一緒にグループ化するのが望ましいことを示すために使用する，構文的な規約とする。グループ名には，それ以上の重要性はない。グループ化を理解もサポートもしない実装は，単純に，型名の左にある"."の前の任意のテキストを取り去り，通常のとおりに型名及び値を表示してよい。
text/directory本体で定義される各属性は，その属性が使われるプロファイル定義で許される場合には，複数の値をもってもよい。複数の値の項目を符号化するための一般的な規則は，型名を含む各値に対して新しい内容行を単に生成することとする。しかし，幾つかの値型(value
type。5.8.3，5.8.4などを参照。)が，コンマ","で値を分離することで単一の内容行に複数の値を符号化することをサポートする点には注意することが望ましい。この手法は，空白の節約を理由として，以降で定義する幾つかの内容型(date，time，integer及びfloat)に用いられる。
次のパラメタ及び値型は，一般的使用のために定義される。 "language"型パラメタは，複数の言語でのデータを識別するために使われる。存在している任意の"Content-Language"
MIMEヘッダパラメタによって指定されるとおりとすることを除いて，"デフォルト"言語の概念は存在しない。"Language"型パラメタの値は，[RFC-1766]の2.で定義されるとおりの言語タグとする。
"context"型パラメタは，値を解釈する際に使われる文脈(例えば，プロトコル)を識別するために使われる。例えば，これは，6.1で定義する"source"型で使われる。
"encoding"型パラメタは，値に対して代替の符号化を指定するために使われる。値がCRLFを含む場合，CRLFは内容型自体の行を分離するために使われるので，符号化されなければならない。現在，"b"符号化だけがサポートされている。
"b"符号化は，バイナリ値(例えば，証明証)を，本体部分の他のテキスト情報と混在させるためにも役に立つ。この場合，値ごとに"b"符号化を使うことで，他の情報をより読みやすいフォームにすることができる。符号化されたbase
64値は，5.8.1の行継続技法を使うことで，内容型の複数の物理行にまたがって分割できる。
Content-Transfer-Encodingヘッダフィールドは，本体部分全体のために使われる符号化を指定するのに使用する。"encoding"型パラメタは，証明証などの特別な値の符号化を指定するために使用する。この場合，Content-Transfer-Encodingヘッダは"8bit"を指定するかもしれないが，その一方で，一つの証明証の値は"encoding=b"の型パラメタを通じて"b"符号化を指定するかもしれない。
Content-Transfer-Encodingと"encoding"型パラメタによって与えられる個々の型の符号化とは，お互いに独立とする。転送のためにtext/directory本体部分を符号化する場合，個々の型の符号化が最初に実行され，次に，本体部分全体がContent-Transfer-Encodingに従って符号化される。text/directory本体部分を復号する場合，Content-Transfer-Encodingが最初に復号され，次に"encoding"型パラメタをもつ個々の型が復号される。
"value"パラメタはオプションであって，値型(データ型)及び値のフォーマットを識別するために使われる。これら定義済みフォーマットの使用は，値パラメタが明示的に使われない場合でも推奨される。値型の標準的な集合及びそのフォーマットを定義することによって，既存の構文解析系及び処理系が利用できる。
各々の特性の一部として値型が明示的に含まれることによって，構文解析を簡単にし，より汎用的なアプリケーションをサポートするための付加的なヒントが与えられる。例えば，検索エンジンは，それが検索している項目すべてのために特定の値型を知る必要がなくなる。値型は定義の中に明示的に存在するので，検索エンジンは，任意の項目の型の日付を探すことができ，解釈可能な結果を与えることができる。
5.8.3で与えられる定義済み値型(valuetype)の規定に対応する値のフォーマットを，次に定義する。 値型及びフォーマットの特別な備考を次に示す。 MIMEメディア型を使うアプリケーション: Various(様々なものが許される。) 追加情報: none 意図する使用法: COMMON 6.で示す型は，実行されているプロファイルにかかわらず一般に有用であって，この規定の11.1で定義されるtext/directory
MIME型登録テンプレートを使って定義される。これらの型は，明示的にプロファイル定義で禁止されない場合は，あらゆるプロファイルに含まれてよい。 宛先: ietf-mime-direct@imc.org 型の特別な備考:
SOURCE型は，与えられたディレクトリサービスプロトコルにおける知識処理可能なアプリケーションが，付加的な情報又はより最近の情報をディレクトリサービスから取得可能な方法を提供するために使用する。この型は，[RFC-1738]で定義されたとおりの，その情報に関係するディレクトリ実体を参照するURI及び/又はその他の情報を含む。ディレクトリ情報が二つ以上のソースから利用可能な場合，送信実体はそれ自体が最良のソースと考えるものを選択できるか，又は複数のSOURCE型を取り込むことができる。一つのSOURCE型に対する値の解釈は，CONTEXT型パラメタの設定に依存可能とする。CONTEXT型パラメタは，uri接頭辞の値と互換性がなければならない。
型の例: 宛先: ietf-mime-direct@imc.org 型の特別な備考: NAME型は，ディレクトリ情報が関係する実体の表示名を運ぶために使用する。 型の例: 宛先: ietf-mime-direct@imc.org 型の特別な備考:
PROFILE型は，本体部分の残りのディレクトリ情報が関係する実体の型を運ぶために使用する。これは，"profile"ヘッダパラメタが存在する場合には，それと同じとすることが望ましい。
型の例: 宛先: ietf-mime-direct@imc.org 型の特別な備考:
BEGIN型は，text/directory内容型内の特性の関係する集合を含むプロファイルを区切るために，END型と一緒に使用する。この構成要素は，付加的なMIMEヘッダ内部の異なる情報の集合を包み込む代わりに，又は包み込むことに付加して，使用できる。これは，同じtext/directory内容型内に複数の実体を包含できる内容を定義することを望む，又はMIME環境の外部で識別可能な内容を定義することを望むアプリケーションに対して提供される。
型の例: 宛先: ietf-mime-direct@imc.org 型の特別な備考:
END型は，text/directory内容型内の特性の関係する集合を含むプロファイルを区切るために，BEGIN型と一緒に使用する。この構成要素は，付加的なMIMEヘッダ内部の異なる情報の集合を包み込む代わりに，又は包み込むことに付加して，使用できる。これは，同じtext/directory内容型内に複数の実体を包含できる内容を定義することを望む，又はMIME環境の外部で識別可能な内容を定義することを望むアプリケーションに対して提供される。
型の例: multipart/related内容型は，テキスト及び非テキストの両方の情報から成るディレクトリ情報を保持する，又は既に自然なMIME表現をもっているディレクトリ情報を保持するために使用できる。multipart/related本体部分内のルート本体部分は，"start"パラメタによって[RFC-2112]で定義されるとおりに指定されるか，又はそのようなパラメタが存在しない場合には最初の本体部分とする。ルート本体部分は，"text/directory"の内容型をもたなければならない。この部分は，行内情報を保持し，5.で示されるとおりのContent-ID
URI経由で，付加的なテキスト又は非テキストのディレクトリ情報を保持する後続の本体部分を参照する。 参照される本体部分は，ルート本体部分に対してここで注意した以外には，特定の順番に並んでいる必要はない。 次の例は，例示のためだけに示すのであって，定義の一部ではない。 最初に，text/directory内容型の簡単な使用例を示す。"profile"パラメタが与えられていないことに注意すること。そこで，アプリケーションは，情報がどの種類のディレクトリ実体に適用されるか分からないかもしれない。仮定的及び公的であって，双方で合意された型の使用にも注意すること。
次の例は，返却される情報に非ASCII文字を含んでいるので[RFC
2045]で定義されたQuoated-Printable転送符号化を使用し，オプションの"name"型及び"source"型を使用する場合を示す。この例は，証明証の値を"b"(binary)で符号化するための"encoding"型パラメタの使い方も示す。"vCard"プロファイル[MIME-VCARD]が，例に対して使用されている。
次の例は，複数の値をもつ型パラメタ，"language"型パラメタ，"value"型パラメタ，長い行の行継続，フォーマット付けされた行に対する\n符号化，属性のグループ化，及び行内"b"符号化の使用を示す。"vCard"プロファイル[MIME-VCARD]が，例に対して使用されている。
最後の例は，同じメッセージ内の他の本体部分又は外部の値を参照する目的で，"uri"符号化を経由して非テキストのディレクトリデータを取り込むためにmultipart/related内容型を使用する場合を示す。"profile"パラメタは与えられていないことに注意すること。そのため，アプリケーションは，情報をどの種類のディレクトリ実体に適用するのか分からないかもしれない。仮定的及び公的であって，双方で合意された型の使用にも注意すること。
9.では，新しいプロファイルをIANAに登録し，インタネットコミュニティで利用可能とする手続きを定義する。非IANAプロファイルは，関連するプロファイル名が5.で定義した"X-"規約に従う条件のもとで，双方の合意によって使用できる点に注意すること。
9.で定義する手続きは，新しいプロファイルの定義への制限を少しだけ課すものの，新しいプロファイルの公開コメント及び審議が可能となることを目的として設計されている。
新しいプロファイルの登録は，次の段階を踏むことで達成される。 プロファイルは，次のテンプレートを完成することによって定義する。 備考 英語によるプロファイルの定義のテンプレートを次に示す。 テンプレートの各フィールドで行う記述の説明を次に示す。 プロファイル記述は，新しいプロファイルの議論用のメーリングリスト ietf-mime-direct@imc.org に送信しなければならない。 新しいプロファイルの議論は，最低2週間は，メーリングリスト上で行うことが許可されていなければならない。9.4で示す段階に進む前に，プロファイルについての合意が得られていなければならない。
2週間のコメント期間が経過し，提案者がプロファイルについての合意が得られたと確信した場合には，承認のために登録申請をプロファイル審査者に提出することが望ましい。プロファイル審査者は，アプリケーション分野統括責任者によって任命され，プロファイル登録を承認又は拒否することができる。承認された登録は，IANAの公式プロファイル登録簿に含めるために，プロファイル審査者からIANAへと渡される。登録は，次のいずれかの理由のために拒否されることがある。
既存のプロファイルは，それを登録したのと同じ処理を使用して変更することができる。 プロファイルの原作成者又は任意の他の関心ある団体は，既存のプロファイルへの変更を提案できるが，その変更は，公開された規定に重大な脱落又はエラーがある場合にだけ，提案されることが望ましい点に注意すること。プロファイル審査者は，変更が後方互換でない場合には，変更に異議を唱えることができる。ただし，後方互換となることは必す(須)ではない。
プロファイル定義は，IANA登録簿から削除されることはない。ただし，もはや有用ではないと判断されるプロファイルは，"意図する使用法(intended
use)"フィールドへの変更によって，OBSOLETE(推奨しない)，と宣言することができる。 11.では，新しい型をIANAに登録する手続きを定義する。非IANAの型は，関連する型名が5.で定義した"X-"規約に従う条件のもとで，双方の合意によって使用できる点に注意すること。
11.で定義する手続きは，新しい型の定義への制限を少しだけ課すものの，新しい型の公開コメント及び審議が可能となることを目的として設計されている。 新しい型の登録は，次の段階を踏むことで達成される。 型は，次のテンプレートを完成することによって定義する。 備考 英語による型の定義のテンプレートを次に示す。 テンプレートの各フィールドで行う記述の説明を次に示す。 型記述は，新しい型の議論用のメーリングリスト ietf-mime-direct@imc.org に送信しなければならない。 新しい型の議論は，最低2週間は，メーリングリスト上で行うことが許可されていなければならない。11.4で示す段階に進む前に，型についての合意が得られていなければならない。
2週間のコメント期間が経過し，提案者が型についての合意が得られたと確信した場合には，承認のために登録申請をプロファイル審査者に提出することが望ましい。プロファイル審査者は，アプリケーション分野統括責任者によって任命され，型登録を承認又は拒否することができる。承認された登録は，IANAの公式プロファイル登録簿に含めるために，プロファイル審査者によってIANAへと渡される。登録は，次のいずれかの理由のために拒否されることがある。
既存の型は，それを登録したのと同じ処理を使用して変更することができる。 型の原作成者又は任意の他の関心ある団体は，既存の型への変更を提案できるが，その変更は，公開された規定に重大な脱落又はエラーがある場合にだけ，提案されることが望ましい点に注意すること。プロファイル審査者は，変更が後方互換でない場合には，変更に異議を唱えることができる。ただし，後方互換となることは必す(須)ではない。
型定義は，IANA登録簿から削除されることはない。ただし，もはや有用ではないと判断される型は，"意図する使用法(intended use)"フィールドへの変更によって，OBSOLETE(推奨しない)，と宣言することができる。 13.では，新しいパラメタをIANAに登録し，インタネットコミュニティで利用可能とする手続きを定義する。非IANAパラメタは，関連するパラメタ名が5.で定義した"X-"規約に従う条件のもとで，双方の合意によって使用できる点に注意すること。
13.で定義する手続きは，新しいパラメタの定義への制限を少しだけ課すものの，新しいパラメタの公開コメント及び審議が可能となることを目的として設計されている。
新しいパラメタの登録は，次の段階を踏むことで達成される。 パラメタは，次のテンプレートを完成することによって定義する。 備考 英語によるパラメタの定義のテンプレートを次に示す。 テンプレートの各フィールドで行う記述の説明を次に示す。 パラメタ記述は，新しいパラメタの議論用のメーリングリスト ietf-mime-direct@imc.org に送信しなければならない。 新しいパラメタの議論は，最低2週間は，メーリングリスト上で行うことが許可されていなければならない。13.4で示す段階に進む前に，パラメタについての合意が得られていなければならない。
2週間のコメント期間が経過し，提案者がパラメタについての合意が得られたと確信した場合には，承認のために登録申請をプロファイル審査者に提出することが望ましい。プロファイル審査者は，アプリケーション分野統括責任者によって任命され，パラメタ登録を承認又は拒否することができる。承認された登録は，IANAの公式パラメタ登録簿に含めるために，プロファイル審査者からIANAへと渡される。登録は，次のいずれかの理由のために拒否されることがある。
既存のパラメタは，それを登録したのと同じ処理を使用して変更することができる。 パラメタの原作成者又は任意の他の関心ある団体は，既存のパラメタへの変更を提案できるが，その変更は，公開された規定に重大な脱落又はエラーがある場合にだけ，提案されることが望ましい点に注意すること。プロファイル審査者は，変更が後方互換でない場合には，変更に異議を唱えることができる。ただし，後方互換となることは必す(須)ではない。
パラメタ定義は，IANA登録簿から削除されることはない。ただし，もはや有用ではないと判断されるパラメタは，"意図する使用法(intended use)"フィールドへの変更によって，OBSOLETE(推奨しない)，と宣言することができる。 15.では，新しいプロファイルをIANAに登録し，インタネットコミュニティで利用可能とする手続きを定義する。非IANA値型は，関連するプロファイル名が5.で定義した"X-"規約に従う条件のもとで，双方の合意によって使用できる点に注意すること。
15.で定義する手続きは，新しい値型の定義への制限を少しだけ課すものの，新しい値型の公開コメント及び審議が可能となることを目的として設計されている。
新しい値型の登録は，次の段階を踏むことで達成される。 値型は，次のテンプレートを完成することによって定義する。 備考 英語による値型の定義のテンプレートを次に示す。 テンプレートの各フィールドで行う記述の説明を次に示す。 値型の記述は，新しい値型の議論用のメーリングリスト ietf-mime-direct@imc.org に送信しなければならない。 新しい値型の議論は，最低2週間は，メーリングリスト上で行うことが許可されていなければならない。15.4で示す段階に進む前に，値型についての合意が得られていなければならない。
2週間のコメント期間が経過し，提案者が値型についての合意が得られたと確信した場合には，承認のために登録申請をプロファイル審査者に提出することが望ましい。プロファイル審査者は，アプリケーション分野統括責任者によって任命され，値型の登録を承認又は拒否することができる。承認された登録は，IANAの公式値型登録簿に含めるために，プロファイル審査者からIANAへと渡される。登録は，次のいずれかの理由のために拒否されることがある。
インタネットメールは，監視，再生及び偽造を含む，多くのよく知られたセキュリティ攻撃の対象となっている。ディレクトリサービスは，情報をディレクトリサービスそれ自体の有効範囲外に置く可能性があることに注意することが望ましい。その有効範囲外では，いかなるアクセス制御も保証されない。アプリケーションも，(例えば,
PostScript値の型などの)"安全な"環境でディレクトリデータを表示することに注意するほうがよい。 この規定が定義する登録手続きは，MIME登録RFCから引用した。
IETF ASID作業グループのメンバが寄与した多くの価値あるコメント，それはVersit
Consortiumからの寄与なのだが，それに大いに感謝する。Chris Newmanは，ABNFの複雑な議論をたどる上で特に助けになってくれた。 Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist in its
implementation may be prepared, copied, published and distributed, in whole or
in part, without restriction of any kind, provided that the above copyright
notice and this paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing Internet
standards in which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS"
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS
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. 参考 著作権表示の訳を次に示す。 (原規定に関する)著作権(1998)は，すべてInternet Societyに帰属する。 この著作権表示及びこの段落がすべての複製及び派生物に記載されていれば，この文書(原規定)及びその翻訳は，複製し他に供給してよく，この文書(原規定)にコメントする派生物，この文書(原規定)に他の説明をする派生物又はこの文書(原規定)の実装を支援する派生物は，あらゆる制約なしに，全体又は部分を準備し，複製し，出版し，配布してよい。しかし，この文書(原規定)それ自体は，どのような方法でも，例えば，著作権表示を削除したり，Internet
Society又は他のインタネット機関への参照を削除することによって，改変してはならない。ただし，次の場合を除く。Internet
standardを開発するために必要な場合(この場合には，Internet
standardプロセスにおいて定義された著作権の手続きに従わなければならない。)，又は英語以外の言語に翻訳するために必要な場合。 この限定許可は無期限であって，Internet Society，その後継者又は譲渡人によって取り消されることはない。 この文書(原規定)及びそこに含まれる情報は，“そのまま”の状態で提供される。Internet Society及びInternet Engineering
Task
Forceは，ここに示す情報の利用が，商業化又は特定目的への適合のあらゆる権利又はあらゆる暗黙の保証を侵害しないという保証を含んだ，ただしそれに限定されない，すべての明示的な又は暗黙的な保証を行わない。
5.8.3 定義済みパラメタ
predefined-param = encodingparm
/ valuetypeparm
/ languageparm
/ contextparm
encodingparm = "encoding" "=" encodingtype
encodingtype = "b" ; RFC 2047から。
/ iana-token ; この規定の15.で示されるとおりに登録されたもの。
valuetypeparm = "value" "=" valuetype
valuetype = "uri" ; RFC 1738の5.からのgenericurl。
/ "text"
/ "date"
/ "time"
/ "date-time" ; 日時。
/ "integer"
/ "boolean"
/ "float"
/ x-name
/ iana-token ; この規定の15.で示されるとおりに登録されたもの。
languageparm = "language" "=" Language-Tag
; Language-Tagは，RFC 1766の2.で定義される。
contextparm = "context" "=" context
context = x-name
/ iana-token
5.8.4 定義済み値型
valuespec = text-list
/ genericurl ；RFC1738の5.によるもの。
/ date-list
/ time-list
/ date-time-list
/ boolean
/ integer-list
/ float-list
/ iana-valuespec
text-list = *TEXT-LIST-CHAR *("," *TEXT-LIST-CHAR)
TEXT-LIST-CHAR = "\\" / "\," / "\n"
/ <任意のVALUE-CHAR。ただし，","，"\"又は改行は除く。>
; 逆スラッシュ，改行及びコンマは，符号化されなければならない。
; \n 又は \N は，改行を符号化するために使用できる。
date-list = date *("," date)
time-list = time *("," time)
date-time-list = date "T" time *("," date "T" time)
boolean = "TRUE" / "FALSE"
integer-list = integer *("," integer)
integer = [sign] 1*DIGIT
float-list = float *("," float)
float = [sign] 1*DIGIT ["." 1*DIGIT]
sign = "+" / "-"
date = date-fullyear ["-"] date-month ["-"] date-mday
date-fullyear = 4 DIGIT
date-month = 2 DIGIT ; 01-12
date-mday = 2 DIGIT ; 01-28, 01-29, 01-30, 01-31
; 値の範囲は，月及び年に基づく。
time = time-hour [":"] time-minute [":"] time-second [time-secfrac]
[time-zone]
time-hour = 2 DIGIT ; 00-23
time-minute = 2 DIGIT ; 00-59
time-second = 2 DIGIT ; 00-60 [うるう(閏)秒を含む。]
time-secfrac = "," 1*DIGIT
time-zone = "Z" / time-numzone
time-numzome = sign time-hour [":"] time-minute
iana-valuespec = <この規定の15.で定義されるとおりに，IANAで登録済みの，
公的に定義されている値型のフォーマット。>
"text"の例：
this is a text value
this is one value,this is another
this is a single value\, with a comma encoded
テキスト値型でフォーマット化されたテキストの行切りは，ラテン小文字n(ASCIIの10進表現で110)又はラテン大文字N(ASCIIの10進表現で78)が後ろに続く\(ASCIIの10進表現で92)として，表現されなければならない。すなわち，"\n"又は"\N"とする。
例えば，次の複数行
Mythical Manager
Hyjinx Software Division
BabsCo, Inc.
のDESCRIPTION値は，次のとおりに表現できる。 DESCRIPTION:Mythical Manager\nHyjinx Software Division\n
BabsCo\, Inc.\n
この例は，\nリテラルのフォーマット化された行切り技法，CRLFの後に空白が続く行継続技法，及び逆スラッシュエスケープ技法を示している。
"uri"の例：
http://www.foobar.com/my/picture.jpg
ldap://ldap.foobar.com/cn=babs%20jensen
"date"の例：
1985-04-12
1996-08-05,1996-11-11
19850412
"time"の例：
10:22:00
102200
10:22:00.33
10:22:00.33Z
10:22:33,11:22:00
10:22:00-08:00
"date-time"の例：
1996-10-22T14:00:00Z
1996-08-11T12:34:56Z
19960811T123456Z
1996-10-22T14:00:00Z,1996-08-11T12:34:56Z
例：
TRUE
false
True
例：
1234567890
-1234556790
+1234556790,432109876
例: 20.30
1000000.0000001
1.333,3.14
5.9 MIMEメディア型を使用するアプリケーション
5.10 追加情報
5.11 詳細情報を得るための連絡先
Tim Howes
Netscape Communications Corp.
501 East Middlefield Rd.
Mountain View, CA 94041
USA
howes@netscape.com
+1 415 937 3419
5.12 意図する使用法
5.13 著者及び変更の管理者
Tim Howes
Netscape Communications Corp.
501 East Middlefield Rd.
Mountain View, CA 94041
USA
howes@netscape.com
+1 415 937 3419
Mark Smith
Netscape Communications Corp.
501 East Middlefield Rd.
Mountain View, CA 94041
USA
mcs@netscape.com
+1 415 937 3477
Frank Dawson
Lotus Development Corporation
6544 Battleford Drive
Raleigh, NC 27613-3502
USA
frank_dawson@lotus.com
+1-919-676-9515
6. 定義済み型
6.1 SOURCE型定義
件名: text/directory MIME型SOURCEの登録
型名: SOURCE
型の目的: 内容型に含まれるディレクトリ情報のソースを識別する。
型の符号化: 8bit
型の値型: uri
SOURCE;CONTEXT=LDAP:ldap://ldap.host/cn=Babs%20Jensen,%20o=Babsco,%20c=US 6.2 NAME型定義
件名: text/directory MIME型NAMEの登録
型名:
NAME
型の目的: 内容型における情報に関係するディレクトリ実体の表示可能な名前を識別する。
型の符号化: 8bit
型の値型: text
NAME:Babs Jensen's
Contact Information
6.3 PROFILE型定義
件名: text/directory MIME型PROFILEの登録
型名: PROFILE
型の目的: 内容型における情報に関係するディレクトリ実体の型を識別する。
型の符号化:
8bit
型の値型: この規定の9.で示されるとおりに登録された，又は5.で示されるとおりに双方で合意された，プロファイル名。
PROFILE:vCard 6.4 BEGIN型定義
件名: text/directory MIME型BEGINの登録
型名:
BEGIN
型の目的: text/directory内容型内の構文的な実体の開始を示す。
型の符号化: 8bit
型の値型: この規定の9.で示されるとおりに登録された，又は5.で示されるとおりに双方で合意されたものであって，プロファイル名を含むテキスト。
BEGIN:VCARD 6.5 END型定義
件名: text/directory MIME型ENDの登録
型名:
END
型の目的: text/directory内容型内の構文的な実体の終了を示す。
型の符号化: 8bit
型の値型: この規定の9.で示されるとおりに登録された，又は5.で示されるとおりに双方で合意されたものであって，プロファイル名を含むテキスト。
END: VCARD 7. multipart/related内容型の利用
8. 例
8.1 例1
From: Whomever@wherever.com
To: Someone@somewhere.com
Subject: whatever
MIME-Version: 1.0
Message-ID:
8.2 例2
Content-Type: text/directory;
charset="iso-8859-1";
profile="vCard"
Content-ID:
8.3 例3
Content-Type: text/directory; profile="vcard"; charset=iso-8859-1
Content-ID:
8.4 例4
Content-Type: multipart/related;
boundary=woof;
type="text/directory";
start="
9. 新しいプロファイルの登録
9.1 プロファイルの定義
宛先: ietf-mime-direct@imc.org
件名: text/directory MIME プロファイルXXXの登録
プロファイル名:
プロファイルの目的:
プロファイルの型:
プロファイルの特別な備考(オプション):
意図する使用法: (COMMON, LIMITED USE又はOBSOLETEのうちの一つ。)
To: ietf-mime-direct@imc.org
Subject: Registration of text/directory MIME profile XXX
Profile name:
Profile purpose:
Profile types:
Profile special notes (optional):
Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
9.2 プロファイル定義の送信
9.3 コメント期間の許可
9.4 承認のためのプロファイルの提出
プロファイル審査者のプロファイルの拒否決定を，提案者はIESGに控訴できる。提案者は，挙げられた拒否理由を解決する努力をし，プロファイルを再提出することもできる。
10. プロファイル変更の管理
変更の定義
変更の送信
コメント期間の許可
承認のための変更されたプロファイルの提出
11. 新しい型の登録
11.1 型の定義
宛先: ietf-mime-direct@imc.org
件名: text/directory MIME 型XXXの登録
型名:
型の目的:
型の符号化:
型の値型:
型の特別な備考(オプション):
意図する使用法: (COMMON, LIMITED USE又はOBSOLETEのうちの一つ。)
To: ietf-mime-direct@imc.org
Subject: Registration of text/directory MIME type XXX
Type name:
Type purpose:
Type encoding:
Type valuetype:
Type special notes (optional):
Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
11.2 型定義の送信
11.3 コメント期間の許可
11.4 承認のための型の提出
プロファイル審査者の型の拒否決定を，提案者はIESGに控訴できる。提案者は，挙げられた拒否理由を解決する努力をし，プロファイルを再提出することもできる。
12. 型変更の管理
変更の定義
変更の送信
コメント期間の許可
承認のための型の提出
13. 新しいパラメタの登録
13.1 パラメタの定義
宛先: ietf-mime-direct@imc.org
件名: text/directory MIME 型パラメタXXXの登録
パラメタ名:
パラメタの目的:
パラメタの値:
パラメタの特別な備考(オプション):
意図する使用法: (COMMON, LIMITED USE又はOBSOLETEのうちの一つ。)
To: ietf-mime-direct@imc.org
Subject: Registration of text/directory MIME type parameter XXX
Parameter name:
Parameter purpose:
Parameter values:
Parameter special notes (optional):
Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
13.2 パラメタ定義の送信
13.3 コメント期間の許可
13.4 承認のためのパラメタの提出
プロファイル審査者のパラメタの拒否決定を，提案者はIESGに控訴できる。提案者は，挙げられた拒否理由を解決する努力をし，パラメタ登録を再提出することもできる。
14. パラメタ変更の管理
変更の定義
変更の送信
コメント期間の許可
承認のためのパラメタの提出
15. 新しい値型の登録
15.1 値型の定義
宛先: ietf-mime-direct@imc.org
件名: text/directory MIME 値型XXXの登録
値型名:
値型の目的:
値型のフォーマット:
値型の特別な備考(オプション):
意図する使用法: (COMMON, LIMITED USE又はOBSOLETEのうちの一つ。)
To: ietf-mime-direct@imc.org
Subject: Registration of text/directory MIME value type XXX
value type name:
value type purpose:
value type format:
value type special notes (optional):
Intended usage: (one of COMMON, LIMITED USE or OBSOLETE)
15.2 値型定義の送信
15.3 コメント期間の許可
15.4 承認のための値型の提出
プロファイル審査者の値型の拒否決定を，提案者はIESGに控訴できる。提案者は，挙げられた拒否理由を解決する努力をし，値型登録を再提出することもできる。
16. セキュリティへの考慮
17. 貢献者
18. 引用規定
[RFC-1777] Yeong, W., Howes, T., and S. Kille, "Lightweight
Directory Access Protocol", RFC 1777, March 1995.
[RFC-1778] Howes, T., Kille, S., Yeong, W., and C. Robbins, "The
String Representation of Standard Attribute Syntaxes",
RFC 1778, March 1995.
[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, August 1982.
[RFC-2045] Borenstein, N., and N. Freed, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC-2046] Moore, K., "Multipurpose Internet Mail Extensions (MIME)
Part Two: Media Types", RFC 2046, November 1996.
[RFC-2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) Part Four: Registration
Procedures", RFC 2048, November 1996.
[RFC-1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.
[RFC-2112] Levinson, E., "The MIME Multipart/Related Content-type",
RFC 2112, March 1997.
[X500] "Information Processing Systems - Open Systems
Interconnection - The Directory: Overview of Concepts,
Models and Services", ISO/IEC JTC 1/SC21, International
Standard 9594-1, 1988.
[RFC-1835] Deutsch, P., Schoultz, R., Faltstrom, P., and C. Weider,
"Architecture of the WHOIS++ service", RFC 1835, August
1995.
[RFC-1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[MIME-VCARD] Dawson, F., and T. Howes, "VCard MIME Directory
Profile", RFC 2426, September 1998.
[VCARD] Internet Mail Consortium, "vCard - The Electronic
Business Card", Version 2.1,
http://www.imc.com/pdi/vcard-21.txt, September, 1996.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
19. 著者の連絡先
Tim Howes
Netscape Communications Corp.
501 East Middlefield Rd.
Mountain View, CA 94041
USA
Phone: +1.415.937.3419
EMail: howes@netscape.com
Mark Smith
Netscape Communications Corp.
501 East Middlefield Rd.
Mountain View, CA 94041
USA
Phone: +1.415.937.3477
EMail: mcs@netscape.com
Frank Dawson
Lotus Development Corporation
6544 Battleford Drive
Raleigh, NC 27613
USA
Phone: +1-919-676-9515
EMail: frank_dawson@lotus.com
20. 著作権表示