RFC1778 日本語訳
1778 The String Representation of Standard Attribute Syntaxes. T.Howes, S. Kille, W. Yeong, C. Robbins. March 1995. (Format: TXT=19053 bytes) (Obsoletes RFC1488) (Obsoleted by RFC3494) (Updated by RFC2559) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Howes Request for Comments: 1778 University of Michigan Obsoletes: 1488 S. Kille Category: Standards Track ISODE Consortium W. Yeong Performance Systems International C. Robbins NeXor Ltd. March 1995
コメントを求めるワーキンググループT.ハウズの要求をネットワークでつないでください: 1778年のミシガン大学は以下を時代遅れにします。 1488秒間Killeカテゴリ: 1995年のC.ロビンスNeXor株式会社行進の国際の標準化過程ISODE共同体W.Yeong言語運用機構
The String Representation of Standard Attribute Syntaxes
標準の属性構文のストリング表現
Status of this Memo
この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
要約
The Lightweight Directory Access Protocol (LDAP) [9] requires that the contents of AttributeValue fields in protocol elements be octet strings. This document defines the requirements that must be satisfied by encoding rules used to render X.500 Directory attribute syntaxes into a form suitable for use in the LDAP, then goes on to define the encoding rules for the standard set of attribute syntaxes defined in [1,2] and [3].
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[9]は、プロトコル要素のAttributeValue分野のコンテンツが八重奏ストリングであることを必要とします。 このドキュメントは、LDAPでX.500ディレクトリ属性構文を使用に適したフォームに翻訳するのに使用される符号化規則で満たさなければならない要件を定義して、次に、[1、2]で定義された属性構文と[3]の標準セットのために符号化規則を定義し続けます。
1. Attribute Syntax Encoding Requirements.
1. 要件をコード化する構文を結果と考えてください。
This section defines general requirements for lightweight directory protocol attribute syntax encodings. All documents defining attribute syntax encodings for use by the lightweight directory protocols are expected to conform to these requirements.
このセクションは軽量のディレクトリプロトコル属性構文encodingsのための一般的な要件を定義します。 使用のために軽量のディレクトリプロトコルで属性構文encodingsを定義するすべてのドキュメントがこれらの要件に従うと予想されます。
The encoding rules defined for a given attribute syntax must produce octet strings. To the greatest extent possible, encoded octet strings should be usable in their native encoded form for display purposes. In particular, encoding rules for attribute syntaxes defining non-binary values should produce strings that can be displayed with little or no translation by clients implementing the lightweight directory protocols.
与えられた属性構文のために定義された符号化規則は八重奏ストリングを作り出さなければなりません。 可能な最大限まで、コード化された八重奏ストリングはディスプレイ目的のためのそれらのネイティブのコード化されたフォームで使用可能であるべきです。 特に、非バイナリー値を定義する属性構文のための符号化規則はクライアントによる翻訳がまず軽量のディレクトリプロトコルを実装していなく表示できるストリングを作り出すべきです。
Howes, Kille, Yeong & Robbins [Page 1] RFC 1778 Syntax Encoding March 1995
ハウズ、Kille、1995年3月をコード化するYeongとロビンス[1ページ]RFC1778構文
2. Standard Attribute Syntax Encodings
2. 標準の属性構文Encodings
For the purposes of defining the encoding rules for the standard attribute syntaxes, the following auxiliary BNF definitions will be used:
標準の属性構文のために符号化規則を定義する目的のために、以下の補助のBNF定義は使用されるでしょう:
<a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' | 'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' | 's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' | 'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' | 'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' | 'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
<a>:、:= 'a'| 'b'| 'c'| '、'であるだろう| 'e'| 'f'| 'g'| 'h'| 'i'| 'j'| 'k'| 'l'| '存在'| '、'| 'o'| 'p'| 'q'| 'r'| 's'| '、'| 'u'| 'v'| 'w'| 'x'| 'y'| 'z'| 'A'| 'B'| 'C'| '、'であるだろう| 'E'| 'F'| 'G'| 'H'| '私'| 'J'| 'K'| 'L'| '存在'| '、'| '○'| 'P'| 'Q'| 'R'| 's'| '、'| 'U'| 'V'| 'W'| 'X'| 'Y'| 'Z'
<d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
<d>:、:= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
<hex-digit> ::= <d> | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'A' | 'B' | 'C' | 'D' | 'E' | 'F'
<十六進法ケタ>:、:= <d>。| 'a'| 'b'| 'c'| '、'であるだろう| 'e'| 'f'| 'A'| 'B'| 'C'| '、'であるだろう| 'E'| 'F'
<k> ::= <a> | <d> | '-'
<k>:、:= <は>です。| <d>。| '-'
<p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' | '/' | ':' | '?' | ' '
<p>:、:= <は>です。| <d>。| ''' | '(' | ')' | '+' | ',' | '-' | '.' | '/' | ':' | '?' | ' '
<CRLF> ::= The ASCII newline character with hexadecimal value 0x0A
<CRLF>:、:= 16進価値の0x0AがあるASCIIニューラインキャラクタ
<letterstring> ::= <a> | <a> <letterstring>
>をletterstringする<:、:= <は>です。| <は>をletterstringする><です。
<numericstring> ::= <d> | <d> <numericstring>
>をnumericstringする<:、:= <d>。| >をnumericstringする<d><。
<keystring> ::= <a> | <a> <anhstring>
>をkeystringする<:、:= <は>です。| <は>をanhstringする><です。
<anhstring> ::= <k> | <k> <anhstring>
>をanhstringする<:、:= <k>。| >をanhstringする<k><。
<printablestring> ::= <p> | <p> <printablestring>
>をprintablestringする<:、:= <p>。| >をprintablestringする<p><。
<space> ::= ' ' | ' ' <space>
<スペース>:、:= ' ' | ''<スペース>'
2.1. Undefined
2.1. 未定義
Values of type Undefined are encoded as if they were values of type Octet String, with the string value being the BER-encoded version of the value.
タイプUndefinedの値はまるでそれらがタイプOctet Stringの値であるかのようにコード化されます、価値のBERによってコード化されたバージョンであるストリング値で。
2.2. Case Ignore String
2.2. ケースはストリングを無視します。
A string of type caseIgnoreStringSyntax is encoded as the string value itself.
タイプcaseIgnoreStringSyntaxの五弦はストリング値自体としてコード化されます。
Howes, Kille, Yeong & Robbins [Page 2] RFC 1778 Syntax Encoding March 1995
ハウズ、Kille、1995年3月をコード化するYeongとロビンス[2ページ]RFC1778構文
2.3. Case Exact String
2.3. 正確なストリングをケースに入れてください。
The encoding of a string of type caseExactStringSyntax is the string value itself.
タイプcaseExactStringSyntaxのストリングのコード化はストリング値自体です。
2.4. Printable String
2.4. 印刷可能なストリング
The encoding of a string of type printableStringSyntax is the string value itself.
タイプprintableStringSyntaxのストリングのコード化はストリング値自体です。
2.5. Numeric String
2.5. 数値ストリング
The encoding of a string of type numericStringSyntax is the string value itself.
タイプnumericStringSyntaxのストリングのコード化はストリング値自体です。
2.6. Octet String
2.6. 八重奏ストリング
The encoding of a string of type octetStringSyntax is the string value itself.
タイプoctetStringSyntaxのストリングのコード化はストリング値自体です。
2.7. Case Ignore IA5 String
2.7. ケースはIA5ストリングを無視します。
The encoding of a string of type caseIgnoreIA5String is the string value itself.
タイプcaseIgnoreIA5Stringのストリングのコード化はストリング値自体です。
2.8. IA5 String
2.8. IA5ストリング
The encoding of a string of type iA5StringSyntax is the string value itself.
タイプiA5StringSyntaxのストリングのコード化はストリング値自体です。
2.9. T61 String
2.9. T61ストリング
The encoding of a string of type t61StringSyntax is the string value itself.
タイプt61StringSyntaxのストリングのコード化はストリング値自体です。
2.10. Case Ignore List
2.10. ケースはリストを無視します。
Values of type caseIgnoreListSyntax are encoded according to the following BNF:
以下のBNFによると、タイプcaseIgnoreListSyntaxの値はコード化されます:
<caseignorelist> ::= <caseignorestring> | <caseignorestring> '$' <caseignorelist>
<caseignorelist>:、:= >をcaseignorestringする<。| >'$'<caseignorelist>をcaseignorestringする<。
<caseignorestring> ::= a string encoded according to the rules for Case Ignore String as above.
>をcaseignorestringする<:、:= Case Ignore Stringのための上の規則に従ってコード化されたストリング。
Howes, Kille, Yeong & Robbins [Page 3] RFC 1778 Syntax Encoding March 1995
ハウズ、Kille、1995年3月をコード化するYeongとロビンス[3ページ]RFC1778構文
2.11. Case Exact List
2.11. 正確なリストをケースに入れてください。
Values of type caseExactListSyntax are encoded according to the following BNF:
以下のBNFによると、タイプcaseExactListSyntaxの値はコード化されます:
<caseexactlist> ::= <caseexactstring> | <caseexactstring> '$' <caseexactlist>
<caseexactlist>:、:= >をcaseexactstringする<。| >'$'<caseexactlist>をcaseexactstringする<。
<caseexactstring> ::= a string encoded according to the rules for Case Exact String as above.
>をcaseexactstringする<:、:= Case Exact Stringのための上の規則に従ってコード化されたストリング。
2.12. Distinguished Name
2.12. 分類名
Values of type distinguishedNameSyntax are encoded to have the representation defined in [5].
タイプdistinguishedNameSyntaxの値は、[5]で定義された表現を持つためにコード化されます。
2.13. Boolean
2.13. 論理演算子
Values of type booleanSyntax are encoded according to the following BNF:
以下のBNFによると、タイプbooleanSyntaxの値はコード化されます:
<boolean> ::= "TRUE" | "FALSE"
<論理演算子>:、:= 「本当に」| 「虚偽」
Boolean values have an encoding of "TRUE" if they are logically true, and have an encoding of "FALSE" otherwise.
ブール値には、論理的に本当であり、そうでなければ、「誤ること」のコード化を持っているなら、「本当」のコード化があります。
2.14. Integer
2.14. 整数
Values of type integerSyntax are encoded as the decimal representation of their values, with each decimal digit represented by the its character equivalent. So the digit 1 is represented by the character
タイプintegerSyntaxの値はそれらの値の10進表現としてコード化されます、各10進数字が表してそのキャラクタ同等物。 ケタ1がキャラクタによって表されて
2.15. Object Identifier
2.15. オブジェクト識別子
Values of type objectIdentifierSyntax are encoded according to the following BNF:
以下のBNFによると、タイプobjectIdentifierSyntaxの値はコード化されます:
<oid> ::= <descr> | <descr> '.' <numericoid> | <numericoid>
<oid>:、:= <descr>。| '<descr>''<numericoid>。| <numericoid>。
<descr> ::= <keystring>
<descr>:、:= >をkeystringする<。
<numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
<numericoid>:、:= >をnumericstringする<。| '<numericstring>''<numericoid>。
In the above BNF, <descr> is the syntactic representation of an object descriptor. When encoding values of type objectIdentifierSyntax, the first encoding option should be used in preference to the second, which should be used in preference to the
上のBNFでは、<descr>はオブジェクト記述子の統語表示です。 に優先してタイプobjectIdentifierSyntaxの値をコード化するとき、最初のコード化オプションが2番目に優先して使用されるべきである。2番目は使用されるべきです。
Howes, Kille, Yeong & Robbins [Page 4] RFC 1778 Syntax Encoding March 1995
ハウズ、Kille、1995年3月をコード化するYeongとロビンス[4ページ]RFC1778構文
third wherever possible. That is, in encoding object identifiers, object descriptors (where assigned and known by the implementation) should be used in preference to numeric oids to the greatest extent possible. For example, in encoding the object identifier representing an organizationName, the descriptor "organizationName" is preferable to "ds.4.10", which is in turn preferable to the string "2.5.4.10".
3番目、可能であるどこ。 すなわち、オブジェクト識別子をコード化する際に、数値oidsに優先してオブジェクト記述子(実装によって割り当てられて、知られているところで)は可能な最大限まで使用されるべきです。 例えば、"organizationName"というorganizationNameを表すオブジェクト識別子をコード化することにおける記述子が望ましい、「ds、.4、0.1インチ、どれが順番にそうであるか、ストリングより望ましい、「2.5 .4 0.1インチ、」
2.16. Telephone Number
2.16. 電話番号
Values of type telephoneNumberSyntax are encoded as if they were Printable String types.
タイプtelephoneNumberSyntaxの値はまるでそれらがPrintable Stringタイプであるかのようにコード化されます。
2.17. Telex Number
2.17. テレックス番号
Values of type telexNumberSyntax are encoded according to the following BNF:
以下のBNFによると、タイプtelexNumberSyntaxの値はコード化されます:
<telex-number> ::= <actual-number> '$' <country> '$' <answerback>
<テレックス番号>:、:= <実数>'$'<国の>'$'<アンサーバック>。
<actual-number> ::= <printablestring>
<実数>:、:= >をprintablestringする<。
<country> ::= <printablestring>
<国の>:、:= >をprintablestringする<。
<answerback> ::= <printablestring>
<アンサーバック>:、:= >をprintablestringする<。
In the above, <actual-number> is the syntactic representation of the number portion of the TELEX number being encoded, <country> is the TELEX country code, and <answerback> is the answerback code of a TELEX terminal.
上記では、<実数>はコード化されるTELEX番号の数の部分の統語表示です、そして、<国の>はTELEX国名略号です、そして、<アンサーバック>はTELEX端末のアンサーバックコードです。
2.18. Teletex Terminal Identifier
2.18. テレテックス端末識別子
Values of type teletexTerminalIdentifier are encoded according to the following BNF:
以下のBNFによると、タイプteletexTerminalIdentifierの値はコード化されます:
<teletex-id> ::= <printablestring> 0*('$' <ttx-parm>)
<テレテックスイド>:、:= >0*をprintablestringする<。('$'<ttx-parm>)
<ttx-param> ::= <ttx-key> ':' <ttx-value>
<ttx-param>:、:= '<ttx主要な>': '<ttx-価値の>。
<ttx-key> ::= 'graphic' | 'control' | 'misc' | 'page' | 'private'
<ttx主要な>:、:= 'グラフィックです'。| 'コントロール'| '雑ネタ'| 'ページ'| '個人的です'。
<ttx-value> ::= <octetstring>
<ttx-価値の>:、:= >をoctetstringする<。
In the above, the first <printablestring> is the encoding of the first portion of the teletex terminal identifier to be encoded, and the subsequent 0 or more <printablestrings> are subsequent portions of the teletex terminal identifier.
上記では、>をprintablestringする最初の<はテレテックス端末識別子のコード化されるべき最初の部分のコード化です、そして、その後の0以上<printablestrings>はテレテックス端末識別子のその後の部分です。
Howes, Kille, Yeong & Robbins [Page 5] RFC 1778 Syntax Encoding March 1995
ハウズ、Kille、1995年3月をコード化するYeongとロビンス[5ページ]RFC1778構文
2.19. Facsimile Telephone Number
2.19. ファクシミリ電話番号
Values of type FacsimileTelephoneNumber are encoded according to the following BNF:
以下のBNFによると、タイプFacsimileTelephoneNumberの値はコード化されます:
<fax-number> ::= <printablestring> [ '$' <faxparameters> ]
<ファックス番号>:、:= >をprintablestringする<。['$'<faxparameters>]
<faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
<faxparameters>:、:= <faxparm>。| <faxparm>'$'<faxparameters>。
<faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' | 'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
<faxparm>:、:= 'twoDimensional'| 'fineResolution'| 'unlimitedLength'| 'b4Length'| 'a3Width'| 'b4Width'| '解凍されます'。
In the above, the first <printablestring> is the actual fax number, and the <faxparm> tokens represent fax parameters.
上記では、>をprintablestringする最初の<は実際のファックス番号です、そして、<faxparm>トークンはファックスパラメタを表します。
2.20. Presentation Address
2.20. プレゼンテーションアドレス
Values of type PresentationAddress are encoded to have the representation described in [6].
タイプPresentationAddressの値は、[6]で説明された表現を持つためにコード化されます。
2.21. UTC Time
2.21. UTC時間
Values of type uTCTimeSyntax are encoded as if they were Printable Strings with the strings containing a UTCTime value.
タイプuTCTimeSyntaxの値はまるでそれらがストリングがUTCTime値を含んでいるPrintable Stringsであるかのようにコード化されます。
2.22. Guide (search guide)
2.22. ガイド(検索ガイド)
Values of type Guide, such as values of the searchGuide attribute, are encoded according to the following BNF:
以下のBNFによると、タイプガイドのsearchGuide属性の値などの値はコード化されます:
<guide-value> ::= [ <object-class> '#' ] <criteria>
<ガイド価値の>:、:= [<は>'#'をオブジェクトで分類します] <評価基準>。
<object-class> ::= an encoded value of type objectIdentifierSyntax
<オブジェクトクラス>:、:= タイプobjectIdentifierSyntaxのコード化された値
<criteria> ::= <criteria-item> | <criteria-set> | '!' <criteria>
<評価基準>:、:= <評価基準項目>。| <評価基準セット>。| '!'<評価基準>。
<criteria-set> ::= [ '(' ] <criteria> '&' <criteria-set> [ ')' ] | [ '(' ] <criteria> '|' <criteria-set> [ ')' ]
<評価基準セット>:、:= ['、('、]、<評価基準>'&'<評価基準セット>[')']、'| ['、('、]、'|'<が評価基準で設定した<評価基準>、>、'[ ')' ]
<criteria-item> ::= [ '(' ] <attributetype> '$' <match-type> [ ')' ]
<評価基準項目>:、:= ['、('、]、<attributetype>'$'タイプを合わせている<>'[ ')' ]
<match-type> ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX"
<マッチタイプ>:、:= "EQ"| "SUBSTR"| 「ゲー」| "LE"| 「約」
Howes, Kille, Yeong & Robbins [Page 6] RFC 1778 Syntax Encoding March 1995
ハウズ、Kille、1995年3月をコード化するYeongとロビンス[6ページ]RFC1778構文
2.23. Postal Address
2.23. 郵便の宛先
Values of type PostalAddress are encoded according to the following BNF:
以下のBNFによると、タイプPostalAddressの値はコード化されます:
<postal-address> ::= <t61string> | <t61string> '$' <postal-address>
<郵便の宛先>:、:= <t61string>。| <t61string>'$'<郵便の宛先>。
In the above, each <t61string> component of a postal address value is encoded as a value of type t61StringSyntax.
上記では、郵便の宛先価値のそれぞれの<t61string>の部品はタイプt61StringSyntaxの値としてコード化されます。
2.24. User Password
2.24. ユーザパスワード
Values of type userPasswordSyntax are encoded as if they were of type octetStringSyntax.
まるでタイプoctetStringSyntaxにはそれらがあるかのようにタイプuserPasswordSyntaxの値はコード化されます。
2.25. User Certificate
2.25. ユーザー証明書
Values of type userCertificate are encoded according to the following BNF:
以下のBNFによると、タイプuserCertificateの値はコード化されます:
<certificate> ::= <version> '#' <serial> '#' <signature-algorithm-id> '#' <issuer> '#' <validity> '#' <subject> '#' <public-key-info> '#' <encrypted-sign-value>
<証明書>:、:= <のバージョンの>'#'<の連続の>'#'<署名アルゴリズムイド>'#'<発行人>'#'<正当性>'#'<の対象の>'#'<公開鍵インフォメーション>'#'<の暗号化されたサイン価値の>。
<version> ::= <integervalue>
<バージョン>:、:= <integervalue>。
<serial> ::= <integervalue>
<の連続の>:、:= <integervalue>。
<signature-algorithm-id> ::= <algorithm-id>
<署名アルゴリズムイド>:、:= <アルゴリズムイド>。
<issuer> ::= an encoded Distinguished Name
<発行人>:、:= コード化されたDistinguished Name
<validity> ::= <not-before-time> '#' <not-after-time>
<の正当性>:、:= <、-時間>'#'の前に、<は後に>を調節しません。
<not-before-time> ::= <utc-time>
<、-、時間>の前で:、:= <utc-時間>。
<not-after-time> ::= <utc-time>
<は後に>を調節しません:、:= <utc-時間>。
<algorithm-parameters> ::= <null> | <integervalue> | '{ASN}' <hex-string>
<アルゴリズムパラメタ>:、:= <のヌル>。| <integervalue>。| 'ASN、'<16進数列>。
<subject> ::= an encoded Distinguished Name
<の対象の>:、:= コード化されたDistinguished Name
<public-key-info> ::= <algorithm-id> '#' <encrypted-sign-value>
<公開鍵インフォメーション>:、:= <アルゴリズムイド>'#'<の暗号化されたサイン価値の>。
<encrypted-sign-value> ::= <hex-string> | <hex-string> '-' <d>
<の暗号化されたサイン価値の>:、:= <16進数列>。| <16進数列>'--'<d>。
<algorithm-id> ::= <oid> '#' <algorithm-parameters>
<アルゴリズムイド>:、:= <oid>'#'<アルゴリズムパラメタ>。
Howes, Kille, Yeong & Robbins [Page 7] RFC 1778 Syntax Encoding March 1995
ハウズ、Kille、1995年3月をコード化するYeongとロビンス[7ページ]RFC1778構文
<utc-time> ::= an encoded UTCTime value
<utc-時間>:、:= コード化されたUTCTime値
<hex-string> ::= <hex-digit> | <hex-digit> <hex-string>
<16進数列>:、:= <十六進法ケタ>。| <十六進法ケタ><16進数列>。
2.26. CA Certificate
2.26. カリフォルニア証明書
Values of type cACertificate are encoded as if the values were of type userCertificate.
まるでタイプuserCertificateには値があるかのようにタイプcACertificateの値はコード化されます。
2.27. Authority Revocation List
2.27. 権威取消しリスト
Values of type authorityRevocationList are encoded according to the following BNF:
以下のBNFによると、タイプauthorityRevocationListの値はコード化されます:
<certificate-list> ::= <signature-algorithm-id> '#' <issuer> '#' <utc-time> [ '#' <revoked-certificates> ] '#' <signature-algorithm-id> '#' <encrypted-sign-value>
<証明書リスト>:、:= <署名アルゴリズムイド>'#'<発行人>'#'<utc-時間>['#'<の取り消された証明書の>]'#'<署名アルゴリズムイド>'#'<の暗号化されたサイン価値の>。
<revoked-certificates> ::= 1*( '#' <revoked-certificate> ) <signature-algorithm-id> '#' <encrypted-sign-value>
<の取り消された証明書の>:、:= 1つの*('#'<の取り消された証明書の>)<署名アルゴリズムイド>'#'<の暗号化されたサイン価値の>。
<revoked-certificate> ::= <signature-algorithm-id> '#' <issuer> '#' <serial> '#' <utc-time>
<の取り消された証明書の>:、:= <署名アルゴリズムイド>'#'<発行人>'#'<の連続の>'#'<utc-時間>。
The syntactic components <signature-algorithm-id>, <issuer>, <encrypted-sign-value>, <utc-time>, <subject> and <serial> have the same definitions as in the BNF for the userCertificate attribute syntax.
統語部門<署名アルゴリズムイド>(>、<の暗号化されたサイン価値の>、<utc-時間>、<の対象の>、および<の連続の>がuserCertificate属性構文のためのBNFに同じ定義を持っている<発行人)。
2.28. Certificate Revocation List
2.28. 証明書失効リスト
Values of type certificateRevocationList are encoded as if the values were of type authorityRevocationList.
まるでタイプauthorityRevocationListには値があるかのようにタイプcertificateRevocationListの値はコード化されます。
2.29. Cross Certificate Pair
2.29. 交差している証明書組
Values of type crossCertificatePair are encoded according to the following BNF:
以下のBNFによると、タイプcrossCertificatePairの値はコード化されます:
<certificate-pair> ::= <forward> '#' <reverse> | <forward> | <reverse>
<証明書組>:、:= <の前進の>'#'<の逆の>。| <の前進の>。| <の逆の>。
<forward> ::= 'forward:' <certificate>
<の前進の>:、:= 'フォワード:'<証明書>。
<reverse> ::= 'reverse:' <certificate>
<の逆の>:、:= '逆:'<証明書>。
Howes, Kille, Yeong & Robbins [Page 8] RFC 1778 Syntax Encoding March 1995
ハウズ、Kille、1995年3月をコード化するYeongとロビンス[8ページ]RFC1778構文
The syntactic component <certificate> has the same definition as in the BNF for the userCertificate attribute syntax.
>がuserCertificate属性構文のためのBNFに同じ定義を持っている統語部門<証明書。
2.30. Delivery Method
2.30. 発送方法
Values of type deliveryMethod are encoded according to the following BNF:
以下のBNFによると、タイプdeliveryMethodの値はコード化されます:
<delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>
<配送価値の>:、:= <pdm>。| <pdm>'$'<配送価値の>。
<pdm> ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' | 'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone'
<pdm>:、:= 'いくらか'| 'mhs'| '物理的です'。| 'テレックス'| 'テレテックス'| 'g3fax'| 'g4fax'| 'ia5'| 'ビデオテックス'| '電話'
2.31. Other Mailbox
2.31. 他のメールボックス
Values of the type otherMailboxSyntax are encoded according to the following BNF:
以下のBNFによると、タイプotherMailboxSyntaxの値はコード化されます:
<otherMailbox> ::= <mailbox-type> '$' <mailbox>
<otherMailbox>:、:= <メールボックスタイプ>'$'<メールボックス>。
<mailbox-type> ::= an encoded Printable String
<メールボックスタイプ>:、:= コード化されたPrintable String
<mailbox> ::= an encoded IA5 String
<メールボックス>:、:= コード化されたIA5 String
In the above, <mailbox-type> represents the type of mail system in which the mailbox resides, for example "Internet" or "MCIMail"; and <mailbox> is the actual mailbox in the mail system defined by <mailbox-type>.
上記では、<メールボックスタイプ>はメールボックスが住んでいるシステム、例えば、「インターネット」というメールのタイプか"MCIMail"の代理をします。 そして、<メールボックス>は<メールボックスタイプ>によって定義されたメールシステムの実際のメールボックスです。
2.32. Mail Preference
2.32. 好みを郵送してください。
Values of type mailPreferenceOption are encoded according to the following BNF:
以下のBNFによると、タイプmailPreferenceOptionの値はコード化されます:
<mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"
<メール好みの>:、:= 「リストがありません」| 「何でも記載してください」| 「プロのリスト」
2.33. MHS OR Address
2.33. MHSかアドレス
Values of type MHS OR Address are encoded as strings, according to the format defined in [10].
[10]で定義された書式によると、タイプMHS OR Addressの値はストリングとしてコード化されます。
Howes, Kille, Yeong & Robbins [Page 9] RFC 1778 Syntax Encoding March 1995
ハウズ、Kille、1995年3月をコード化するYeongとロビンス[9ページ]RFC1778構文
2.34. Distribution List Submit Permission
2.34. 発送先リストは許可を提出します。
Values of type DLSubmitPermission are encoded as strings, according to the following BNF:
以下のBNFによると、タイプDLSubmitPermissionの値はストリングとしてコード化されます:
<dlsubmit-perm> ::= <dlgroup_label> ':' <dlgroup-value> | <dl-label> ':' <dl-value>
<dlsubmit-パーマ>:、:= '<dlgroup_ラベル>': '<dlgroup-価値の>。| '<dlラベル>': '<dl価値の>。
<dlgroup-label> ::= 'group_member'
<dlgroup-ラベル>:、:= 'グループ_メンバー'
<dlgroup-value> ::= <name>
<dlgroup-価値の>:、:= <名前>。
<name> ::= an encoded Distinguished Name
<名前>:、:= コード化されたDistinguished Name
<dl-label> ::= 'individual' | 'dl_member' | 'pattern'
<dlラベル>:、:= '個々です'。| 'dl_メンバー'| '型に基づいて作ってください'
<dl-value> ::= <orname>
<dl価値の>:、:= <orname>。
<orname> ::= <address> '#' <dn> | <address>
<orname>:、:= <アドレス>'#'<dn>。| <アドレス>。
<address> ::= <add-label> ':' <oraddress>
<アドレス>:、:= 'ラベルを加えている<>': '<oraddress>。
<dn> ::= <dn-label> ':' <name>
<dn>:、:= '<dn-ラベル>': '<名前>。
<add-label> = 'X400'
ラベル>=を加えている<'X400'
<dn-label> = 'X500'
<dn-ラベル>は'X500'と等しいです。
where <oraddress> is as defined in RFC 1327.
<oraddress>がRFC1327で定義されるようにあるところで。
2.35. Photo
2.35. 写真
Values of type Photo are encoded as if they were octet strings containing JPEG images in the JPEG File Interchange Format (JFIF), as described in [8].
タイプPhotoの値はまるでそれらがJPEG File Interchange Format(JFIF)にJPEGイメージを含む八重奏ストリングであるかのようにコード化されます、[8]で説明されるように。
2.36. Fax
2.36. ファックス
Values of type Fax are encoded as if they were octet strings containing Group 3 Fax images as defined in [7].
タイプファックスの値はまるでそれらが[7]で定義されるようにGroup3ファックスイメージを含む八重奏ストリングであるかのようにコード化されます。
Howes, Kille, Yeong & Robbins [Page 10] RFC 1778 Syntax Encoding March 1995
ハウズ、Kille、1995年3月をコード化するYeongとロビンス[10ページ]RFC1778構文
3. Security Considerations
3. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
4. Acknowledgements
4. 承認
Many of the attribute syntax encodings defined in this document are adapted from those used in the QUIPU X.500 implementation. The contributions of the authors of the QUIPU implementation in the specification of the QUIPU syntaxes [4] are gratefully acknowledged.
encodingsが定義した属性構文の多くがQUIPU X.500実現に使用されるものから本書では適合させられます。 QUIPU構文[4]の仕様に基づく、QUIPU実現の作者の投稿は感謝して承諾されます。
5. Bibliography
5. 図書目録
[1] The Directory: Selected Attribute Syntaxes. CCITT, Recommendation X.520.
[1] ディレクトリ: 属性構文を選択しました。 CCITT、推薦X.520。
[2] Information Processing Systems -- Open Systems Interconnection -- The Directory: Selected Attribute Syntaxes.
[2] 情報処理システム--オープン・システム・インターコネクション--ディレクトリ: 属性構文を選択しました。
[3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema", RFC 1274, University College London, November 1991.
[3] RFC1274、ユニバーシティ・カレッジロンドン1991年11月のバーカー、P.、S.Kille、および「コサインとインターネットX.500図式」
[4] The ISO Development Environment: User's Manual -- Volume 5: QUIPU. Colin Robbins, Stephen E. Kille.
[4] ISO開発環境: ユーザマニュアル--第5巻: 結び縄文字。 コリン・ロビンス、スティーブンE.Kille。
[5] Kille, S., "A String Representation of Distinguished Names", RFC 1779, ISODE Consortium, March 1995.
[5]Kille、S.、「分類名のストリング表現」、RFC1779、ISODE共同体、1995年3月。
[6] Kille, S., "A String Representation for Presentation Addresses", RFC 1278, University College London, November 1991.
[6]Kille、S.、「プレゼンテーションアドレスのストリング表現」、RFC1278、ユニバーシティ・カレッジロンドン1991年11月。
[7] Terminal Equipment and Protocols for Telematic Services - Standardization of Group 3 facsimile apparatus for document transmission. CCITT, Recommendation T.4.
Telematic Servicesのための[7]の端末のEquipmentとプロトコル--ドキュメントトランスミッションのためのGroup3ファクシミリ装置の規格化。 CCITT、推薦T.4。
[8] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C- Cube Microsystems, Milpitas, CA, September 1, 1992.
[8] JPEGは置き換え形式(バージョン1.02)をファイルします。 エリック・ハミルトン、Cは1992年9月1日にマイクロシステムズ、ミルピタス、カリフォルニアを三乗します。
[9] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, Performance Systems International, University of Michigan, ISODE Consortium, March 1995.
[9]YeongとW.とハウズ、T.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル」、RFC1777、国際言語運用機構、ミシガン大学、ISODE共同体、1995年3月。
[10] Alvestrand, H., Kille, S., Miles, R., Rose, M., and S. Thompson, "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495, SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc., Dover Beach Consulting, Inc., Soft*Switch, Inc., August 1993.
[10] Alvestrand、H.、Kille、S.、マイル、R.、ローズ、M.、およびS.トンプソンRFC1495、SINTEF DELAB、ISODE共同体、柔らかい*「X.400とRFC-822メッセージの間でボディーを写像し」て、はInc.を切り換えます、ドーヴァービーチコンサルティングInc.、柔らかい*スイッチInc.、1993年8月。
Howes, Kille, Yeong & Robbins [Page 11] RFC 1778 Syntax Encoding March 1995
ハウズ、Kille、1995年3月をコード化するYeongとロビンス[11ページ]RFC1778構文
6. Authors' Addresses
6. 作者のアドレス
Tim Howes University of Michigan ITD Research Systems 535 W William St. Ann Arbor, MI 48103-4943 USA
ティムハウズミシガン大学ITDリサーチシステム535Wウィリアム・聖MI48103-4943アナーバー(米国)
Phone: +1 313 747-4454 EMail: tim@umich.edu
以下に電話をしてください。 +1 313 747-4454 メールしてください: tim@umich.edu
Steve Kille ISODE Consortium PO Box 505 London SW11 1DX UK
スティーブKille ISODE共同体PO Box505ロンドンSW11 1DXイギリス
Phone: +44-71-223-4062 EMail: S.Kille@isode.com
以下に電話をしてください。 +44-71-223-4062 メールしてください: S.Kille@isode.com
Wengyik Yeong PSI Inc. 510 Huntmar Park Drive Herndon, VA 22070 USA
Wengyik YeongψInc.510Huntmar公園Driveヴァージニア22070ハーンドン(米国)
Phone: +1 703-450-8001 EMail: yeongw@psilink.com
以下に電話をしてください。 +1 703-450-8001 メールしてください: yeongw@psilink.com
Colin Robbins NeXor Ltd University Park Nottingham NG7 2RD UK
コリン・ロビンス・NeXor Ltdユニヴァーシティー・パークノッティンガムNG7 2RDイギリス
Howes, Kille, Yeong & Robbins [Page 12]
ハウズ、Kille、Yeong、およびロビンス[12ページ]
一覧
スポンサーリンク