RFC3641 日本語訳

Network Working Group                                            S. Legg
Request for Comments: 3641                           Adacel Technologies
Category: Standards Track                                   October 2003

Leggがコメントのために要求するワーキンググループS.をネットワークでつないでください: 3641年のAdacel技術カテゴリ: 標準化過程2003年10月

          Generic String Encoding Rules (GSER) for ASN.1 Types

ASN.1のためのジェネリックストリング符号化規則(GSER)はタイプします。

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)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   This document defines a set of Abstract Syntax Notation One (ASN.1)
   encoding rules, called the Generic String Encoding Rules (GSER), that
   produce a human readable text encoding for values of any given ASN.1
   data type.

ASN.1データ型を考えて、このドキュメントはいずれの値のために人間の読み込み可能なテキストコード化を生産するGeneric String Encoding Rules(GSER)と呼ばれる1セットの抽象的なSyntax Notation One(ASN.1)符号化規則を定義します。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Conventions. . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Generic String Encoding Rules. . . . . . . . . . . . . . . . .  3
       3.1.  Type Referencing Notations . . . . . . . . . . . . . . .  3
       3.2.  Restricted Character String Types. . . . . . . . . . . .  4
       3.3.  ChoiceOfStrings Types. . . . . . . . . . . . . . . . . .  5
       3.4.  Identifiers. . . . . . . . . . . . . . . . . . . . . . .  6
       3.5.  BIT STRING . . . . . . . . . . . . . . . . . . . . . . .  7
       3.6.  BOOLEAN. . . . . . . . . . . . . . . . . . . . . . . . .  7
       3.7.  ENUMERATED . . . . . . . . . . . . . . . . . . . . . . .  8
       3.8.  INTEGER. . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.9.  NULL . . . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.10. OBJECT IDENTIFIER and RELATIVE-OID . . . . . . . . . . .  8
       3.11. OCTET STRING . . . . . . . . . . . . . . . . . . . . . .  9
       3.12. CHOICE . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.13. SEQUENCE and SET . . . . . . . . . . . . . . . . . . . . 10
       3.14. SEQUENCE OF and SET OF . . . . . . . . . . . . . . . . . 10
       3.15. CHARACTER STRING . . . . . . . . . . . . . . . . . . . . 11
       3.16. EMBEDDED PDV . . . . . . . . . . . . . . . . . . . . . . 11
       3.17. EXTERNAL . . . . . . . . . . . . . . . . . . . . . . . . 11

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 コンベンション。 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. ジェネリックストリングコード化は統治されます。 . . . . . . . . . . . . . . . . 3 3.1. 記法. . . . . . . . . . . . . . . 3 3.2に参照をつけて、タイプしてください。 制限されたキャラクターストリングはタイプされます。 . . . . . . . . . . . 4 3.3. ChoiceOfStringsはタイプします。 . . . . . . . . . . . . . . . . . 5 3.4. 識別子。 . . . . . . . . . . . . . . . . . . . . . . 6 3.5. ビット列. . . . . . . . . . . . . . . . . . . . . . . 7 3.6。 ブール。 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.7. .83.8を列挙しました。 整数。 . . . . . . . . . . . . . . . . . . . . . . . . 8 3.9. ヌル. . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.10。 識別子と親類-OID.83.11に反対してください。 八重奏ストリング. . . . . . . . . . . . . . . . . . . . . . 9 3.12。 選択. . . . . . . . . . . . . . . . . . . . . . . . . 9 3.13。 系列とセット. . . . . . . . . . . . . . . . . . . . 10 3.14。 .10 3.15人の系列とセット。 文字列. . . . . . . . . . . . . . . . . . . . 11 3.16。 埋め込まれたPDV. . . . . . . . . . . . . . . . . . . . . . 11 3.17。 外部の.11

Legg                        Standards Track                     [Page 1]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[1ページ]RFC3641ジェネリックストリング

       3.18. INSTANCE OF. . . . . . . . . . . . . . . . . . . . . . . 11
       3.19. REAL . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       3.20. Variant Encodings. . . . . . . . . . . . . . . . . . . . 12
   4.  GSER Transfer Syntax . . . . . . . . . . . . . . . . . . . . . 13
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 13
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
       6.1.  Normative References . . . . . . . . . . . . . . . . . . 13
       6.2.  Informative References . . . . . . . . . . . . . . . . . 14
   7.  Intellectual Property Notice . . . . . . . . . . . . . . . . . 15
   8.  Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16

3.18. インスタンス . . . . . . . . . . . . . . . . . . . . . . 11 3.19. 本当の.11 3.20。 異形Encodings。 . . . . . . . . . . . . . . . . . . . 12 4. GSERは構文. . . . . . . . . . . . . . . . . . . . . 13 5を移します。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 13 6. 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1。 引用規格. . . . . . . . . . . . . . . . . . 13 6.2。 有益な参照. . . . . . . . . . . . . . . . . 14 7。 知的所有権通知. . . . . . . . . . . . . . . . . 15 8。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 15 9。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 16

1.  Introduction

1. 序論

   This document defines a set of ASN.1 [8] encoding rules, called the
   Generic String Encoding Rules or GSER, that produce a human readable
   UTF-8 [6] character string encoding of ASN.1 values of any given
   arbitrary ASN.1 type.

このドキュメントは任意のASN.1タイプを考えて、いずれのASN.1値をコード化する人間の読み込み可能なUTF-8[6]文字列を生産するGeneric String Encoding RulesかGSERと呼ばれる1セットのASN.1[8]符号化規則を定義します。

   Note that "ASN.1 value" does not mean a Basic Encoding Rules (BER)
   [12] encoded value.  The ASN.1 value is an abstract concept that is
   independent of any particular encoding.  BER is just one possible
   encoding of an ASN.1 value.

「ASN.1値」が、Basic Encoding Rules(BER)[12]が値をコード化したことを意味しないことに注意してください。 ASN.1値はどんな特定のコード化からも独立している抽象概念です。 BERはただASN.1価値をコード化する可能な1つです。

   GSER is based on ASN.1 value notation [8], with changes to
   accommodate the notation's use as a transfer syntax, and to support
   well established ad-hoc string encodings for Lightweight Directory
   Access Protocol (LDAP) [14] directory data types.

GSERは、転送構文として記法の使用を収容して、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[14]ディレクトリデータ型のために確固としている臨時のストリングencodingsをサポートするために変化に伴うASN.1値の記法[8]に基づいています。

   Though primarily intended for defining the LDAP-specific encoding of
   new LDAP attribute syntaxes and assertion syntaxes, these encoding
   rules could also be used in other domains where human readable
   renderings of ASN.1 values would be useful.

新しいLDAP属性構文と主張構文のLDAP特有のコード化を定義するために主として意図しましたが、また、ASN.1値の人間の読み込み可能なレンダリングが役に立つ他のドメインでこれらの符号化規則を使用できました。

   Referencing GSER is sufficient to define a human readable text
   encoding for values of a specific ASN.1 type, however other
   specifications may wish to provide a customized Augmented Backus-Naur
   Form (ABNF) [3] description, independent of the ASN.1, as a
   convenience for the implementor (equivalent ABNF for the GSER
   encodings for ASN.1 types commonly occurring in LDAP syntaxes is
   provided in a separate document [15]).  Such a specification SHOULD
   state that if there is a discrepancy between the customized ABNF and
   the GSER encoding defined by this document, that the GSER encoding
   takes precedence.

GSERに参照をつけるのが特定のASN.1タイプの値のために人間の読み込み可能なテキストコード化を定義するために十分である、しかしながら、他の仕様はカスタム設計されたAugmented BN記法(ABNF)[3]記述を提供したがっているかもしれません、ASN.1の如何にかかわらず、作成者のための便利として。(LDAP構文で一般的に起こるASN.1タイプのためのGSER encodingsのための同等なABNFを別々のドキュメント[15])に提供します。 コード化がこのドキュメントで定義したカスタム設計されたABNFとGSERの間には、食い違いがあればSHOULDがそれを述べて、GSERコード化が優先するくらいの仕様。

Legg                        Standards Track                     [Page 2]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[2ページ]RFC3641ジェネリックストリング

2.  Conventions

2. コンベンション

   Throughout this document, "type" shall be taken to mean an ASN.1
   type, and "value" shall be taken to mean an ASN.1 value.

このドキュメント中では、ASN.1がタイプすることを意味するために「タイプ」を取るものとします、そして、ASN.1価値を意味するために「値」を取るものとします。

   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 BCP 14, RFC 2119 [1].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。

3.  Generic String Encoding Rules

3. ジェネリックストリング符号化規則

   The GSER encoding of a value of any ASN.1 type is described by the
   following ABNF [3]:

どんなASN.1タイプの価値のGSERコード化も以下のABNF[3]によって説明されます:

      Value = BitStringValue /
              BooleanValue /
              CharacterStringValue /
              ChoiceValue /
              EmbeddedPDVValue /
              EnumeratedValue /
              ExternalValue /
              GeneralizedTimeValue /
              IntegerValue /
              InstanceOfValue /
              NullValue /
              ObjectDescriptorValue /
              ObjectIdentifierValue /
              OctetStringValue /
              RealValue /
              RelativeOIDValue /
              SequenceOfValue /
              SequenceValue /
              SetOfValue /
              SetValue /
              StringValue /
              UTCTimeValue /
              VariantEncoding

値はBitStringValue/BooleanValue/CharacterStringValue/ChoiceValue/EmbeddedPDVValue/EnumeratedValue/ExternalValue/GeneralizedTimeValue/IntegerValue/InstanceOfValue/NullValue/ObjectDescriptorValue/ObjectIdentifierValue/OctetStringValue/RealValue/RelativeOIDValue/SequenceOfValue/SequenceValue/SetOfValue/SetValue/StringValue/UTCTimeValue/VariantEncodingと等しいです。

   The ABNF for each of the above rules is given in the following
   sections.

以下のセクションでそれぞれの上の規則のためのABNFを与えます。

3.1 Type Referencing Notations

3.1 記法に参照をつけているタイプ

   A value of a type with a defined type name is encoded according to
   the type definition on the right hand side of the type assignment for
   the type name.

型定義に従って、定義された型名があるタイプの値は型名のためのタイプ課題右手側でコード化されます。

Legg                        Standards Track                     [Page 3]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[3ページ]RFC3641ジェネリックストリング

   A value of a type denoted by the use of a parameterized type with
   actual parameters is encoded according to the parameterized type with
   the DummyReferences [11] substituted with the actual parameters.

parameterizedタイプに従って、実引数でparameterizedタイプの使用で指示されたタイプの値は実引数でDummyReferences[11]を代入している状態でコード化されます。

   A value of a tagged or constrained type is encoded as a value of the
   type without the tag or constraint, respectively.  Tags do not appear
   in the string encodings defined by this document.  See X.680 [8] and
   X.682 [10] for the details of ASN.1 constraint notation.

タグ付けをされたか制約つきなタイプの値はタイプの値としてタグも規制なしでそれぞれコード化されます。 タグはこのドキュメントによって定義されたストリングencodingsに現れません。 ASN.1規制記法の詳細に関してX.680[8]とX.682[10]を見てください。

   A value of an open type denoted by an ObjectClassFieldType (Clause 14
   of X.681 [9]) is encoded according to the specific type of the value.

ObjectClassFieldTypeによって指示されて、戸外の値はタイプします。(価値の特定のタイプによると、X.681[9])の第14節はコード化されます。

   A value of a fixed type denoted by an ObjectClassFieldType is encoded
   according to that fixed type.

そのフィクスト・タイプによると、ObjectClassFieldTypeによって指示されたフィクスト・タイプの値はコード化されます。

   A value of a selection type is encoded according to the type
   referenced by the selection type.

選択タイプによって参照をつけられたタイプに従って、選択タイプの値はコード化されます。

   A value of a type described by TypeFromObject notation (Clause 15 of
   X.681 [9]) is encoded according to the denoted type.

タイプの値はTypeFromObjectで記法を説明しました。(指示されたタイプに従って、X.681[9])の第15節はコード化されます。

   A value of a type described by ValueSetFromObjects notation (Clause
   15 of X.681 [9]) is encoded according to the governing type.

タイプの値はValueSetFromObjectsで記法を説明しました。(治めるタイプに従って、X.681[9])の第15節はコード化されます。

3.2.  Restricted Character String Types

3.2. 制限された文字列タイプ

   The contents of a string value are encoded as a UTF-8 character
   string between double quotes, regardless of the ASN.1 string type.
   Depending on the ASN.1 string type and an application's internal
   representation of that string type, a translation to or from the
   UTF-8 character encoding may be required.  NumericString,
   PrintableString, IA5String, and VisibleString (ISO646String) are
   compatible with UTF-8 and do not require any translation.  BMPString
   (UCS-2) and UniversalString (UCS-4) have a direct mapping to and from
   UTF-8 [6].  For the remaining string types see X.680 [8].  Any
   embedded double quotes in the resulting UTF-8 character string are
   escaped by repeating the double quote characters.

ストリング価値の内容は二重引用符の間のUTF-8文字列としてコード化されます、ASN.1ストリングタイプにかかわらず。 ASN.1ストリングタイプと文字符号化かUTF-8文字符号化からのアプリケーションのそのストリングタイプの内部の表現、翻訳に頼るのが必要であるかもしれません。 NumericString、PrintableString、IA5String、およびVisibleString(ISO646String)はUTF-8と互換性があって、少しの翻訳も必要としません。 BMPString(UCS-2)とUniversalString(UCS-4)には、UTF-8とUTF-8[6]からのダイレクトマッピングがあります。 残っているストリングに関しては、タイプはX.680[8]を見ます。 結果として起こるUTF-8文字列におけるどんな埋め込まれた二重引用符も、二重引用文字を繰り返すことによって、逃げられます。

   A value of the NumericString, PrintableString, TeletexString
   (T61String), VideotexString, IA5String, GraphicString, VisibleString
   (ISO646String), GeneralString, BMPString, UniversalString or
   UTF8String type is encoded according to the <StringValue> rule.

<StringValue>規則に従って、NumericString、PrintableString、TeletexString(T61String)、VideotexString、IA5String、GraphicString、VisibleString(ISO646String)、GeneralString、BMPString、UniversalStringまたはUTF8Stringタイプの値はコード化されます。

Legg                        Standards Track                     [Page 4]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[4ページ]RFC3641ジェネリックストリング

      StringValue       = dquote *SafeUTF8Character dquote

StringValueはdquote*SafeUTF8Character dquoteと等しいです。

      dquote            = %x22 ; " (double quote)

dquote=%x22。 " (二重引用文)

      SafeUTF8Character = %x00-21 / %x23-7F /   ; ASCII minus dquote
                          dquote dquote /       ; escaped double quote
                          %xC0-DF %x80-BF /     ; 2 byte UTF-8 character
                          %xE0-EF 2(%x80-BF) /  ; 3 byte UTF-8 character
                          %xF0-F7 3(%x80-BF)    ; 4 byte UTF-8 character

SafeUTF8Character=%x00-21/%x23-7F/。 dquote dquote dquote/を引いたASCII。 逃げられた二倍の引用文の%xC0-DF%x80-BF/。 UTF-8キャラクタ2バイト%xE0-EF2(%x80-BF)/。 3バイトのUTF-8キャラクタ%xF0-F7 3(%x80-BF)。 4バイトのUTF-8キャラクタ

   A value of the GeneralizedTime type, UTCTime type or ObjectDescriptor
   type is encoded as a string value.  GeneralizedTime and UTCTime use
   the VisibleString character set so the conversion to UTF-8 is
   trivial.  ObjectDescriptor uses the GraphicString type.

GeneralizedTimeタイプ、UTCTimeタイプまたはObjectDescriptorタイプの値はストリング値としてコード化されます。 GeneralizedTimeとUTCTimeがVisibleString文字集合を使用するので、UTF-8への変換は些細です。 ObjectDescriptorはGraphicStringタイプを使用します。

      GeneralizedTimeValue  = StringValue
      UTCTimeValue          = StringValue
      ObjectDescriptorValue = StringValue

GeneralizedTimeValue=StringValue UTCTimeValue=StringValue ObjectDescriptorValueはStringValueと等しいです。

3.3.  ChoiceOfStrings Types

3.3. ChoiceOfStringsはタイプします。

   It is not uncommon for ASN.1 specifications to define types that
   offer a CHOICE between two or more alternative ASN.1 string types,
   where the particular alternative chosen carries no semantic
   significance (DirectoryString [7] being a prime example).  Such types
   are defined to avoid having to use a complicated character encoding
   for all values when most values could use a simpler string type, or
   to deal with evolving requirements that compel the use of a broader
   character set while still maintaining backward compatibility.

ASN.1仕様が選ばれた特定の代替手段がどんな意味意味(主要例であるDirectoryString[7])も運ばない2以上の代替のASN.1ストリングタイプの間で好きなのを選んでよいというタイプを定義するのは、珍しくはありません。 そのようなタイプは、ほとんどの値が、より純真なストリングタイプを使用するかもしれないならすべての値に複雑な文字符号化を使用しなければならないのを避けるか、またはまだ後方の互換性を維持している間に、より広い文字集合の使用を強制する発展要件に対処するために定義されます。

   GSER encodes values of all the ASN.1 string types as UTF-8 character
   strings so the particular alternative that is chosen from a purely
   syntactic CHOICE of string types makes no material difference to the
   final encoding of the string value.

GSERがUTF-8文字列としてすべてのASN.1ストリングタイプの値をコード化するので、ストリングタイプの純粋に構文のCHOICEから選ばれている特定の代替手段は重要な相違を全くストリング価値の最終的なコード化にしません。

   While there are certain ASN.1 constructs that betray the semantic
   significance of the alternatives within a CHOICE type, the absence of
   those constructs does not necessarily mean that a CHOICE type is
   purely syntactic.  Therefore, it is necessary for specifications to
   declare the purely syntactic CHOICE types so that they may be more
   compactly encoded (see Section 3.12).  These declared CHOICE types
   are referred to as ChoiceOfStrings types.

CHOICEタイプの中で代替手段の意味意味を裏切るあるASN.1構造物がある間、それらの構造物の不在は、必ずCHOICEタイプが純粋に構文であることを意味するというわけではありません。 したがって、仕様が、純粋に構文のCHOICEが、よりコンパクトにそれらをコード化できる(セクション3.12を見る)ようにタイプすると宣言するのが必要です。 ChoiceOfStringsがタイプするようにこれらは、CHOICEタイプが言及されると宣言しました。

   To be eligible to be declared a ChoiceOfStrings type, an ASN.1 type
   MUST satisfy the following conditions.

ChoiceOfStringsタイプであると宣言されるのが適任に、なるように、ASN.1タイプは以下の条件を満たさなければなりません。

   a) The type is a CHOICE type.

a) タイプはCHOICEタイプです。

Legg                        Standards Track                     [Page 5]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[5ページ]RFC3641ジェネリックストリング

   b) The component type of each alternative is one of the following
      ASN.1 restricted string types: NumericString, PrintableString,
      TeletexString (T61String), VideotexString, IA5String,
      GraphicString, VisibleString (ISO646String), GeneralString,
      BMPString, UniversalString or UTF8String.

b) それぞれの選択肢のコンポーネント型は以下のASN.1の制限されたストリングタイプのひとりです: NumericString、PrintableString、TeletexString(T61String)、VideotexString、IA5String、GraphicString、VisibleString(ISO646String)、GeneralString、BMPString、UniversalStringまたはUTF8String。

   c) All the alternatives are of different restricted string types,
      i.e., no two alternatives have the same ASN.1 restricted string
      type.

c) すべての選択肢はすなわち、どんな2歳の異なった制限されたストリングタイプでも、同じASN.1の制限されたストリングに代替手段によってタイプされないということです。

   d) Either none of the alternatives has a constraint, or all of the
      alternatives have exactly the same constraint.

d) 代替手段のいずれにはも、規制がないか、または代替手段のすべてにまさに同じ規制があります。

   Tagging on the alternative types is ignored.

代替のタイプの上のタグ付けは無視されます。

   Consider the ASN.1 parameterized type definition of DirectoryString.

ASN.1がDirectoryStringの型定義をparameterizedしたと考えてください。

      DirectoryString { INTEGER : maxSize } ::= CHOICE {
          teletexString     TeletexString (SIZE (1..maxSize)),
          printableString   PrintableString (SIZE (1..maxSize)),
          bmpString         BMPString (SIZE (1..maxSize)),
          universalString   UniversalString (SIZE (1..maxSize)),
          uTF8String        UTF8String (SIZE (1..maxSize)) }

DirectoryString、整数: maxSize:、:= 選択teletexString TeletexString(サイズ(1..maxSize))、printableString PrintableString(サイズ(1..maxSize))、bmpString BMPString(サイズ(1..maxSize))、universalString UniversalString(サイズ(1..maxSize))、uTF8String UTF8String(サイズ(1..maxSize))

   Any use of the DirectoryString parameterized type with an actual
   parameter defines an ASN.1 type that satisfies the above conditions.
   Recognising that the alternative within a DirectoryString carries no
   semantic significance, this document declares (each and every use of)
   DirectoryString{} to be a ChoiceOfStrings type.

実引数があるDirectoryString parameterizedタイプのどんな使用も上記の状態を満たすASN.1タイプを定義します。 DirectoryStringの中の代替手段がどんな意味意味も運ばないと認めて、このドキュメントが宣言する、(ありとあらゆる使用、)、DirectoryString、ChoiceOfStringsに、なるように、タイプしてください。

   Other specifications MAY declare other types satisfying the above
   conditions to be ChoiceOfStrings types.  The declaration SHOULD be
   made at the point where the ASN.1 type is defined, otherwise it
   SHOULD be made at the point where it is introduced as, or in, an LDAP
   attribute or assertion syntax.

他の仕様は、上記の状態を満たしている他のタイプがChoiceOfStringsタイプであると宣言するかもしれません。 ポイントで作られていて、ASN.1がどこでタイプするかが定義されて、そうでなければ、それがSHOULDであるということになってください。宣言SHOULD、それが構文かLDAP属性か主張構文で導入されるポイントでは、作られています。

3.4.  Identifiers

3.4. 識別子

   An <identifier> conforms to the definition of an identifier in ASN.1
   notation (Clause 11.3 of X.680 [8]).  It begins with a lowercase
   letter and is followed by zero or more letters, digits, and hyphens.
   A hyphen is not permitted to be the last character, nor is it to be
   followed by another hyphen.  The case of letters in an identifier is
   always significant.

<識別子>はASN.1記法との識別子の定義に一致しています。(X.680[8])の第11.3節。 それを小文字で始まって、ゼロか、より多くの手紙と、ケタと、ハイフンが支えています。 ハイフンは最後のキャラクタであることが許可されていません、そして、それは別のハイフンがあとに続くことになっていません。 識別子における、手紙のケースはいつも重要です。

Legg                        Standards Track                     [Page 6]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[6ページ]RFC3641ジェネリックストリング

      identifier    = lowercase *alphanumeric *(hyphen 1*alphanumeric)
      alphanumeric  = uppercase / lowercase / decimal-digit
      uppercase     = %x41-5A  ; "A" to "Z"
      lowercase     = %x61-7A  ; "a" to "z"
      decimal-digit = %x30-39  ; "0" to "9"
      hyphen        = "-"

識別子=小文字の*英数字の*(ハイフン1*英数字の)英数字の=10進数字大文字しているか小文字の/大文字=%x41-5A。 「A」は「Z」に=%x61-7Aを小文字で印刷します。 「z」10進数字=%x30-39への"a"。 「「9インチハイフン=「-」」への0インチ

3.5.  BIT STRING

3.5. ビット列

   A value of the BIT STRING type is encoded according to the
   <BitStringValue> rule.  If the definition of the BIT STRING type
   includes a named bit list, the <bit-list> form of <BitStringValue>
   MAY be used.  If the number of bits in a BIT STRING value is a
   multiple of four, the <hstring> form of <BitStringValue> MAY be used.
   Otherwise, the <bstring> form of <BitStringValue> is used.

<BitStringValue>規則に従って、BIT STRINGタイプの値はコード化されます。 BIT STRINGタイプの定義が命名された噛み付いているリストを含んでいるなら、<BitStringValue>の<の噛み付いているリストの>フォームは使用されるかもしれません。 BIT STRING値における、ビットの数が4の倍数であるなら、<BitStringValue>の<のhstring>フォームは使用されるかもしれません。 さもなければ、<BitStringValue>の<のbstring>フォームは使用されています。

      BitStringValue = bstring / hstring / bit-list

BitStringValue=ビットbstring/hstring/リスト

   The <bit-list> rule encodes the one bits in the bit string value as a
   comma separated list of identifiers.  Each <identifier> MUST be one
   of the identifiers in the named bit list, and MUST NOT appear more
   than once in the same <bit-list>.  The <bstring> rule encodes each
   bit as the character "0" or "1" in order from the first bit to the
   last bit.  The <hstring> rule encodes each group of four bits as a
   hexadecimal number where the first bit is the most significant.  An
   odd number of hexadecimal digits is permitted.

<の噛み付いているリストの>規則は識別子のコンマの切り離されたリストとしてビット列値で1ビットをコード化します。 それぞれの<識別子>は命名された噛み付いているリストの識別子の1つでなければならなく、同じ<ビットリスト>で一度より多く見えてはいけません。 >規則エンコードをbstringする<にキャラクタとしてそれぞれ噛み付いた、「0インチか「最初のビットから最後のビットまで整然としている1インチ。」 >規則をhstringする<は16進数としての最初のビットが最も重要である4ビットの各グループをコード化します。 16進数字の奇数は受入れられます。

      bit-list          = "{" [ sp identifier
                             *( "," sp identifier ) ] sp "}"

ビットリスト=、「「[sp識別子*、(「」、sp識別子] sp、」、」

      hstring           = squote *hexadecimal-digit squote %x48 ; '...'H

squote*16進数字squote hstring=%x48。 '...'H'

      hexadecimal-digit = %x30-39 /  ; "0" to "9"
                          %x41-46    ; "A" to "F"

16進数字=%x30-39/。 「「9インチの%x41-46」への0インチ 「F」への「A」

      bstring           = squote *binary-digit squote %x42  ; '...'B
      binary-digit      = "0" / "1"

squote*バイナリー・ディジットsquote bstring=%x42。 '...'Bバイナリー・ディジット=「0インチ/「1インチ」'

      sp                = *%x20  ; zero, one or more space characters
      squote            =  %x27  ; ' (single quote)

sp=*%x20。 ゼロ、1または、より多くの間隔文字squote=%x27。 ' (ただ一つの引用文)

3.6.  BOOLEAN

3.6. 論理演算子

   A value of the BOOLEAN type is encoded according to the
   <BooleanValue> rule.

<BooleanValue>規則に従って、ブールタイプの値はコード化されます。

      BooleanValue = %x54.52.55.45 /   ; "TRUE"
                     %x46.41.4C.53.45  ; "FALSE"

BooleanValueは%x54.52.55.45/と等しいです。 「本当」の%x46.41.4C.53.45。 「虚偽」

Legg                        Standards Track                     [Page 7]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[7ページ]RFC3641ジェネリックストリング

3.7.  ENUMERATED

3.7. 列挙されます。

   A value of the ENUMERATED type is encoded according to the
   <EnumeratedValue> rule.  The <identifier> MUST be one of those in the
   list of enumerations in the definition of the ENUMERATED type.

<EnumeratedValue>規則に従って、ENUMERATEDタイプの値はコード化されます。 <識別子>はENUMERATEDタイプの定義における列挙のリストのそれらの1つであるに違いありません。

      EnumeratedValue = identifier

EnumeratedValueは識別子と等しいです。

3.8.  INTEGER

3.8. 整数

   A value of the INTEGER type is encoded according to the
   <IntegerValue> rule.  If the definition of the INTEGER type includes
   a named number list, the <identifier> form of <IntegerValue> MAY be
   used, in which case the <identifier> MUST be one of the identifiers
   in the named number list.

<IntegerValue>規則に従って、INTEGERタイプの値はコード化されます。 INTEGERタイプの定義が命名された数のリストを含んでいるなら、<IntegerValue>の<識別子>フォームは使用されるかもしれません、その場合、<識別子>が命名された数のリストの識別子の1つであるに違いありません。

      IntegerValue    = "0" /
                        positive-number /
                        ("-" positive-number) /
                        identifier

IntegerValueは「0インチ/の正の数/(「-」正の数)/識別子」と等しいです。

      positive-number = non-zero-digit *decimal-digit
      non-zero-digit  = %x31-39  ; "1" to "9"

非無ケタ*10進数字非無ケタ=正の数=%x31-39。 「1インチから「9インチ」

3.9.  NULL

3.9. ヌル

   A value of the NULL type is encoded according to the <NullValue>
   rule.

<NullValue>規則に従って、NULLタイプの値はコード化されます。

      NullValue = %x4E.55.4C.4C  ; "NULL"

NullValue=%x4E.55.4C.4C。 「ヌルです」。

3.10.  OBJECT IDENTIFIER and RELATIVE-OID

3.10. オブジェクト識別子と親類-OID

   A value of the OBJECT IDENTIFIER type is encoded according to the
   <ObjectIdentifierValue> rule.  The <ObjectIdentifierValue> rule
   allows either a dotted decimal representation of the OBJECT
   IDENTIFIER value or an object descriptor name, i.e., <descr>.  The
   <descr> rule is described in RFC 2252 [4].  An object descriptor name
   is potentially ambiguous and should be used with care.

<ObjectIdentifierValue>規則に従って、OBJECT IDENTIFIERタイプの値はコード化されます。 <ObjectIdentifierValue>規則はOBJECT IDENTIFIER価値のドット付き10進法表現かオブジェクト記述子名(すなわち、<descr>)のどちらかを許容します。 <descr>規則はRFC2252[4]で説明されます。 オブジェクト記述子名は、潜在的にあいまいであり、慎重に使用されるべきです。

      ObjectIdentifierValue = numeric-oid / descr
      numeric-oid           = oid-component 1*( "." oid-component )
      oid-component         = "0" / positive-number

数値oid / descrの数値ObjectIdentifierValue=oidがoid-コンポーネント1*と等しい、(「. 」 oid-コンポーネント) oid-コンポーネントの=「0インチ/正の数」

   A value of the RELATIVE-OID type is encoded according to the
   <RelativeOIDValue> rule.

<RelativeOIDValue>規則に従って、RELATIVE-OIDタイプの値はコード化されます。

      RelativeOIDValue = oid-component *( "." oid-component )

RelativeOIDValueはoid-コンポーネント*と等しいです。(「. 」 oid-コンポーネント、)

Legg                        Standards Track                     [Page 8]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[8ページ]RFC3641ジェネリックストリング

3.11.  OCTET STRING

3.11. 八重奏ストリング

   A value of the OCTET STRING type is encoded according to the
   <OctetStringValue> rule.  The octets are encoded in order from the
   first octet to the last octet.  Each octet is encoded as a pair of
   hexadecimal digits where the first digit corresponds to the four most
   significant bits of the octet.  If the hexadecimal string does not
   have an even number of digits, the four least significant bits in the
   last octet are assumed to be zero.

<OctetStringValue>規則に従って、OCTET STRINGタイプの値はコード化されます。 八重奏は最初の八重奏から最後の八重奏まで整然とした状態でコード化されます。 各八重奏は最初のケタが八重奏の4つの最上位ビットに対応する1組の16進数字としてコード化されます。 16進ストリングにケタの偶数がないなら、最後の八重奏における4つの最下位ビットがゼロであると思われます。

      OctetStringValue = hstring

OctetStringValueはhstringと等しいです。

3.12.  CHOICE

3.12. 選択

   A value of a CHOICE type is encoded according to the <ChoiceValue>
   rule.  The <ChoiceOfStringsValue> encoding MAY be used if the
   corresponding CHOICE type has been declared a ChoiceOfStrings type.
   This document declares DirectoryString to be a ChoiceOfStrings type
   (see Section 3.3).  Otherwise, the <IdentifiedChoiceValue> form of
   <ChoiceValue> is used.

<ChoiceValue>規則に従って、CHOICEタイプの値はコード化されます。 対応するCHOICEタイプがChoiceOfStringsタイプであると宣言されたなら、<ChoiceOfStringsValue>コード化は使用されるかもしれません。 このドキュメントは、DirectoryStringがChoiceOfStringsタイプであると宣言します(セクション3.3を見てください)。 さもなければ、<ChoiceValue>の<IdentifiedChoiceValue>フォームは使用されています。

      ChoiceValue           = IdentifiedChoiceValue /
                              ChoiceOfStringsValue
      IdentifiedChoiceValue = identifier ":" Value
      ChoiceOfStringsValue  = StringValue

「ChoiceValue=IdentifiedChoiceValue / ChoiceOfStringsValue IdentifiedChoiceValueは識別子と等しい」:、」 値のChoiceOfStringsValueはStringValueと等しいです。

   For implementations that recognise the internal structure of the
   DirectoryString CHOICE type (e.g., X.500 directories [16]), if the
   character string between the quotes in a <StringValue> contains only
   characters that are permitted in a PrintableString, the
   DirectoryString is assumed to use the printableString alternative,
   otherwise it is assumed to use the uTF8String alternative.  The
   <IdentifiedChoiceValue> rule MAY be used for a value of type
   DirectoryString to indicate an alternative other than the one that
   would be assumed from the string contents.  No matter what
   alternative is chosen, the <Value> will still be a UTF-8 encoded
   character string.  However, it is a syntax error if the characters in
   the UTF-8 string cannot be represented in the string type of the
   chosen alternative.

DirectoryString CHOICEの内部の構造を認識する実装のためにタイプしてください。例えば、X.500ディレクトリ[16])、<StringValue>の引用文の間の文字列がPrintableStringで受入れられるキャラクタだけを含んでいるなら、DirectoryStringがprintableString代替手段を使用すると思われます。(さもなければ、uTF8String代替手段を使用すると思われます。 タイプDirectoryStringの値がストリングコンテンツから想定されるもの以外の代替手段を示すのに<IdentifiedChoiceValue>規則は使用されるかもしれません。 どんな代替手段が選ばれても、まだ<Value>によるUTF-8が文字列をコード化したということでしょう。 しかしながら、選ばれた代替手段のストリングタイプでUTF-8ストリングのキャラクタの代理をされることができないなら、それは構文エラーです。

   Implementations that do not care about the internal structure of a
   DirectoryString value MUST be able to parse the
   <IdentifiedChoiceValue> form for a DirectoryString value, though the
   particular identifier found will be of no interest.

DirectoryString価値の内部の構造を心配しない実装はDirectoryString値のために<IdentifiedChoiceValue>フォームを分析できなければなりません、見つけられた特定の識別子が全くおもしろくならないでしょうが。

Legg                        Standards Track                     [Page 9]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[9ページ]RFC3641ジェネリックストリング

3.13.  SEQUENCE and SET

3.13. 系列とセット

   A value of a SEQUENCE type is encoded according to the
   <SequenceValue> rule.  The <ComponentList> rule encodes a comma
   separated list of the particular component values present in the
   SEQUENCE value, where each component value is preceded by the
   corresponding identifier from the SEQUENCE type definition.  The
   components are encoded in the order of their definition in the
   SEQUENCE type.

<SequenceValue>規則に従って、SEQUENCEタイプの値はコード化されます。 <ComponentList>規則は対応する識別子がSEQUENCE型定義からそれぞれの成分値に先行するSEQUENCE値における現在の特定の成分値のコンマの切り離されたリストをコード化します。 コンポーネントはSEQUENCEタイプによる彼らの定義の注文でコード化されます。

      SequenceValue = ComponentList

SequenceValueはComponentListと等しいです。

      ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}"
      NamedValue    = identifier msp Value
      msp           = 1*%x20  ; one or more space characters

ComponentListが等しい、「「[sp NamedValue*、(「」、sp NamedValue] sp、」、」 NamedValue=識別子msp値msp=1*%x20。 1つ以上の間隔文字

   A value of a SET type is encoded according to the <SetValue> rule.
   The components are encoded in the order of their definition in the
   SET type (i.e., just like a SEQUENCE value).  This is a deliberate
   departure from ASN.1 value notation where the components of a SET can
   be written in any order.

<SetValue>規則に従って、SETタイプの値はコード化されます。 コンポーネントはSETタイプ(すなわち、まさしくSEQUENCE値のような)による彼らの定義の注文でコード化されます。 これは順不同にSETの部品を書くことができるASN.1値の記法からの慎重な出発です。

      SetValue = ComponentList

SetValueはComponentListと等しいです。

   SEQUENCE and SET type definitions are sometimes extended by the
   inclusion of additional component types, so an implementation SHOULD
   be capable of skipping over any <NamedValue> encoding with an
   identifier that is not recognised, on the assumption that the sender
   is using a more recent definition of the SEQUENCE or SET type.

SEQUENCEとSET型定義は追加コンポーネント型の包含で時々広げられます、そのように、実装SHOULD。認識されない識別子であらゆる<NamedValue>コード化を飛び越えることができてください、送付者がSEQUENCEの、より最近の定義を使用しているか、またはSETがタイプするという前提で。

3.14.  SEQUENCE OF and SET OF

3.14. 系列、セットされます。

   A value of a SEQUENCE OF type is encoded according to the
   <SequenceOfValue> rule, as a comma separated list of the instances in
   the value.  Each instance is encoded according to the component type
   of the SEQUENCE OF type.

<SequenceOfValue>規則に従って、SEQUENCE OFタイプの値はコード化されます、値におけるインスタンスのコンマの切り離されたリストとして。 SEQUENCE OFタイプのコンポーネント型に従って、各インスタンスはコード化されます。

      SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"

SequenceOfValueが等しい、「「[sp値*、(「」、sp値] sp、」、」

   A value of a SET OF type is encoded according to the <SetOfValue>
   rule, as a list of the instances in the value.  Each instance is
   encoded according to the component type of the SET OF type.

<SetOfValue>規則に従って、SET OFタイプの値はコード化されます、値におけるインスタンスのリストとして。 SET OFタイプのコンポーネント型に従って、各インスタンスはコード化されます。

      SetOfValue      = "{" [ sp Value *( "," sp Value) ] sp "}"

SetOfValueが等しい、「「[sp値*、(「」、sp値] sp、」、」

Legg                        Standards Track                    [Page 10]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[10ページ]RFC3641ジェネリックストリング

3.15.  CHARACTER STRING

3.15. 文字列

   A value of the unrestricted CHARACTER STRING type is encoded
   according to the corresponding SEQUENCE type defined in Clause 40.5
   of X.680 [8] (see [15] for equivalent ABNF).

X.680[8]のClause40.5で定義された対応するSEQUENCEタイプに従って、無制限なCHARACTER STRINGタイプの値はコード化されます(同等なABNFのための[15]を見てください)。

      CharacterStringValue = SequenceValue

CharacterStringValueはSequenceValueと等しいです。

3.16.  EMBEDDED PDV

3.16. 埋め込まれたPDV

   A value of the EMBEDDED PDV type is encoded according to the
   corresponding SEQUENCE type defined in Clause 33.5 of X.680 [8] (see
   [15] for equivalent ABNF).

X.680[8]のClause33.5で定義された対応するSEQUENCEタイプに従って、EMBEDDED PDVタイプの値はコード化されます(同等なABNFのための[15]を見てください)。

      EmbeddedPDVValue = SequenceValue

EmbeddedPDVValueはSequenceValueと等しいです。

3.17.  EXTERNAL

3.17. 外部

   A value of the EXTERNAL type is encoded according to the
   corresponding SEQUENCE type defined in Clause 8.18.1 of X.690 [12]
   (see [15] for equivalent ABNF).

Clauseで定義された対応するSEQUENCEタイプに従ってEXTERNALタイプの値がコード化される、8.18、.1、X.690[12](同等なABNFのための[15]を見ます)について。

      ExternalValue = SequenceValue

ExternalValueはSequenceValueと等しいです。

3.18.  INSTANCE OF

3.18. インスタンス

   A value of the INSTANCE OF type is encoded according to the
   corresponding SEQUENCE type defined in Annex C of X.681 [9].

X.681[9]のAnnex Cで定義された対応するSEQUENCEタイプに従って、INSTANCE OFタイプの値はコード化されます。

      InstanceOfValue = SequenceValue

InstanceOfValueはSequenceValueと等しいです。

3.19.  REAL

3.19. 本当

   A value of the REAL type MUST be encoded as "0" if it is zero,
   otherwise it is encoded as the special value <PLUS-INFINITY>, the
   special value <MINUS-INFINITY>, an optionally signed <realnumber>, or
   as a value of the corresponding SEQUENCE type for REAL defined in
   Clause 20.5 of X.680 [8] (see [15] for equivalent ABNF).

「さもなければ、何0インチも、それはゼロであるなら、特別な値の<プラス無限>、特別な値の<マイナス無限>、任意に署名している<realnumber>として、または、本当にX.680[8]の第20.5節で定義された対応する系列タイプの値としてコード化(同等なABNFのための[15]を見てください)にされる」としてレアルタイプの値をコード化しなければなりません。

      RealValue  = "0"               ; zero REAL value
                   / PLUS-INFINITY   ; positive infinity
                   / MINUS-INFINITY  ; negative infinity
                   / realnumber      ; positive base 10 REAL value
                   / "-" realnumber  ; negative base 10 REAL value
                   / SequenceValue   ; non-zero REAL value, base 2 or 10

RealValue=「0インチ」。 レアル値/PLUS-INFINITYのゼロを合わせてください。 積極的な無限/MINUS-INFINITY。 否定的無限/realnumber。 上向きのベース10レアル値/「-」realnumber。 否定的ベース10レアル値/SequenceValue。 非ゼロレアル価値、ベース2か10

Legg                        Standards Track                    [Page 11]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[11ページ]RFC3641ジェネリックストリング

      realnumber = mantissa exponent
      mantissa   = (positive-number [ "." *decimal-digit ])
                   / ( "0." *("0") positive-number )
      exponent   = "E" ( "0" / ([ "-" ] positive-number))

仮数解説者realnumber=仮数が等しい、(正の数、[「. 」 *10進数字) /、(「0」、*、(「0インチ) 正の数) 解説者は「E」と等しいです」。(「0インチ/[「-」]の正の数)」

      PLUS-INFINITY  = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59
                          ; "PLUS-INFINITY"
      MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
                          ; "MINUS-INFINITY"

プラス無限=%x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59。 「プラス無限」無限=%x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59。 「マイナス無限」

3.20.  Variant Encodings

3.20. 異形Encodings

   The values of some named complex ASN.1 types have special string
   encodings.  These special encodings are always used instead of the
   encoding that would otherwise apply based on the ASN.1 type
   definition.

複雑なASN.1タイプといういくつかの値には、特別なストリングencodingsがあります。 これらの特別なencodingsはそうでなければASN.1型定義に基づいて適用されるコード化の代わりにいつも使用されます。

      VariantEncoding = RDNSequenceValue /
                        RelativeDistinguishedNameValue /
                        ORAddressValue

VariantEncodingはRDNSequenceValue/RelativeDistinguishedNameValue/ORAddressValueと等しいです。

   A value of the RDNSequence type, i.e., a distinguished name, is
   encoded according to the <RDNSequenceValue> rule, as a quoted LDAPDN
   character string.  The character string is first derived according to
   the <distinguishedName> rule in Section 3 of RFC 2253 [5], and then
   encoded as if it were a UTF8String value, i.e., between double quotes
   with any embedded double quotes escaped by being repeated.

<RDNSequenceValue>規則に従って、RDNSequenceタイプの値(すなわち、分類名)はコード化されます、引用されたLDAPDN文字列として。 文字列は、まるでそれがUTF8String値であるかのようにRFC2253[5]のセクション3の<distinguishedName>規則に従って最初に引き出されて、次に、コード化されます、すなわち、どんな埋め込まれた二重引用符も繰り返されることによって逃げられている二重引用符の間で。

      RDNSequenceValue = StringValue

RDNSequenceValueはStringValueと等しいです。

   A RelativeDistinguishedName value that is not part of an RDNSequence
   value is encoded according to the <RelativeDistinguishedNameValue>
   rule as a quoted character string.  The character string is first
   derived according to the <name-component> rule in Section 3 of RFC
   2253 [5], and then encoded as if it were a UTF8String value.

<RelativeDistinguishedNameValue>規則に従って、RDNSequence価値の一部でないRelativeDistinguishedName値は引用された文字列としてコード化されます。 RFC2253[5]のセクション3のコンポーネント>規則を命名していて、次に、まるでそれがUTF8String値であるかのようにコード化された<に従って、文字列は最初に、引き出されます。

      RelativeDistinguishedNameValue = StringValue

RelativeDistinguishedNameValueはStringValueと等しいです。

   A value of the ORAddress type is encoded according to the
   <ORAddressValue> rule as a quoted character string.  The character
   string is first derived according to the textual representation of
   MTS.ORAddress from RFC 2156 [2], and then encoded as if it were an
   IA5String value.

<ORAddressValue>規則に従って、ORAddressタイプの値は引用された文字列としてコード化されます。 文字列は、まるでそれがIA5String値であるかのようにMTS.ORAddressの原文の表現に従って最初にRFC2156[2]から引き出されて、次に、コード化されます。

      ORAddressValue = StringValue

ORAddressValueはStringValueと等しいです。

Legg                        Standards Track                    [Page 12]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[12ページ]RFC3641ジェネリックストリング

4.  GSER Transfer Syntax

4. GSER転送構文

   The following OBJECT IDENTIFIER has been assigned by Adacel
   Technologies, under an arc assigned to Adacel by Standards Australia,
   to identify the Generic String Encoding Rules:

以下のOBJECT IDENTIFIERはAdacel Technologiesによって割り当てられました、Generic String Encoding Rulesを特定するためにStandardsオーストラリアによってAdacelに割り当てられたアークの下で:

      { 1 2 36 79672281 0 0 }

{ 1 2 36 79672281 0 0 }

   This OBJECT IDENTIFIER would be used, for example, to describe the
   transfer syntax for a GSER encoded data-value in an EMBEDDED PDV
   value.

このOBJECT IDENTIFIERは使用されたでしょう、例えば、GSERのために転送構文を説明するのがEMBEDDED PDV値におけるデータ値をコード化しました。

5.  Security Considerations

5. セキュリティ問題

   The Generic String Encoding Rules do not define a canonical encoding.
   That is, a transformation from a GSER encoding into some other
   encoding (e.g., BER) and back into GSER will not necessarily
   reproduce the original GSER octet encoding.  Therefore, GSER MUST NOT
   be used where a canonical encoding is needed.

Generic String Encoding Rulesは正準なコード化を定義しません。 すなわち、GSERに行き帰りある他のコード化(例えば、BER)にコード化するGSERからの変換は必ずオリジナルのGSER八重奏コード化を再生させるというわけではないでしょう。 したがって、GSER MUST NOT、正準なコード化が必要であるところで使用されてください。

   Furthermore, GSER does not necessarily enable the exact octet
   encoding of values of the TeletexString, VideotexString,
   GraphicString or GeneralString types to be reconstructed, so a
   transformation from a Distinguished Encoding Rules (DER) [12]
   encoding to GSER and back to DER may not reproduce the original DER
   encoding.  Therefore, GSER MUST NOT be used to re-encode, whether for
   storage or transmission, ASN.1 abstract values whose original binary
   encoding must be recoverable.  Such recovery is needed for the
   verification of digital signatures.  In such cases, protocols ought
   to use DER or a DER-reversible encoding.

その上、GSERは必ずTeletexStringの値の正確な八重奏コード化を可能にするというわけではありません、とVideotexString、GraphicStringまたはGeneralStringが再建されるためにタイプするので、行き帰りGSERにコード化されるDistinguished Encoding Rules(DER)[12]からDERまでの変換はオリジナルのDERコード化を再生させないかもしれません。 したがって、GSER MUST NOTがストレージかトランスミッションにかかわらず再エンコードに使用されて、ASN.1はオリジナルの2進のコード化が回復可能であるに違いない値を抜き取ります。 そのような回復がデジタル署名の検証に必要です。 そのような場合、プロトコルはDERかDERリバーシブルのコード化を使用するべきです。

   When interpreting security-sensitive fields, and in particular fields
   used to grant or deny access, implementations MUST ensure that any
   comparisons are done on the underlying abstract value, regardless of
   the particular encoding used.

セキュリティ敏感な分野、および特にアクセスを承諾するか、または拒絶するのに使用される分野を解釈するとき、実装は、基本的な抽象的な値でどんな比較もするのを確実にしなければなりません、使用される特定のコード化にかかわらず。

6.  References

6. 参照

6.1.  Normative References

6.1. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
        between X.400 and RFC 822/MIME", RFC 2156, January 1998.

[2]Kille、S.、「ミキサー(パントマイムインターネットX.400はリレーを機能アップしました):」 「X.400とRFC822/の間でMIMEを写像します」、RFC2156、1998年1月。

   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

[3] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

Legg                        Standards Track                    [Page 13]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[13ページ]RFC3641ジェネリックストリング

   [4]  Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
        Directory Access Protocol (v3): Attribute Syntax Definitions",
        RFC 2252, December 1997.

[4] ウォール、M.、Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。

   [5]  Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
        Protocol (v3): UTF-8 String Representation of Distinguished
        Names", RFC 2253, December 1997.

[5] ウォール、M.、Kille S.、およびT.ハウズ。 「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3):」 「分類名のUTF-8ストリング表現」、RFC2253、1997年12月。

   [6]  Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

[6]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。

   [7]  ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
        Information Technology - Open Systems Interconnection - The
        Directory: Selected attribute types

[7] ITU-T推薦X.520(1993)| 情報技術--オープン・システム・インターコネクション--ISO/IEC9594-6:1994、ディレクトリ: 選択された属性タイプ

   [8]  ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002
        Information technology - Abstract Syntax Notation One (ASN.1):
        Specification of basic notation

[8] ITU-T推薦X.680(07/02)| ISO/IEC8824-1: 2002年の情報技術--抽象的なSyntax Notation One(ASN.1): 基本的な記法の仕様

   [9]  ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2:2002
        Information technology - Abstract Syntax Notation One (ASN.1):
        Information object specification

[9] ITU-T推薦X.681(07/02)| ISO/IEC8824-2: 2002年の情報技術--抽象的なSyntax Notation One(ASN.1): 情報オブジェクト仕様

   [10] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3:2002
        Information technology - Abstract Syntax Notation One (ASN.1):
        Constraint specification

[10] ITU-T推薦X.682(07/02)| ISO/IEC8824-3: 2002年の情報技術--抽象的なSyntax Notation One(ASN.1): 規制仕様

   [11] ITU-T Recommendation X.683 (07/02) | ISO/IEC 8824-4:2002
        Information technology - Abstract Syntax Notation One (ASN.1):
        Parameterization of ASN.1 specifications

[11] ITU-T推薦X.683(07/02)| ISO/IEC8824-4: 2002年の情報技術--抽象的なSyntax Notation One(ASN.1): ASN.1仕様のパラメタリゼーション

   [12] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002
        Information technology - ASN.1 encoding rules: Specification of
        Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
        Distinguished Encoding Rules (DER)

[12] ITU-T推薦X.690(07/02)| ISO/IEC8825-1: 2002年の情報技術--ASN.1符号化規則: 基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則の仕様(DER)

6.2.  Informative References

6.2. 有益な参照

   [13] Hovey, R. and S. Bradner, "The Organizations Involved in the
        IETF Standards Process", BCP 11, RFC 2028, October 1996.

[13] ハービとR.とS.ブラドナー、「IETF標準化過程にかかわる組織」、BCP11、RFC2028、1996年10月。

   [14] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol
        (v3): Technical Specification", RFC 3377, September 2002.

[14] ホッジズ、J.、およびR.モーガン、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「技術的な仕様」、RFC3377、2002年9月。

   [15] Legg, S., "Common Elements of Generic String Encoding Rules
        (GSER) Encodings", RFC 3642, October 2003.

[15]Legg、S.、「ジェネリックストリング符号化規則(GSER)Encodingsの一般的なElements」、RFC3642、2003年10月。

Legg                        Standards Track                    [Page 14]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[14ページ]RFC3641ジェネリックストリング

   [16] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
        Information Technology - Open Systems Interconnection - The
        Directory: Overview of concepts, models and services

[16] ITU-T推薦X.500(1993)| 情報技術--オープン・システム・インターコネクション--ISO/IEC9594-1:1994、ディレクトリ: 概念の、そして、モデルの、そして、サービスの概要

7.  Intellectual Property Notice

7. 知的所有権通知

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 implementors or users of this specification can
   be obtained from the IETF Secretariat.

IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。

8.  Author's Address

8. 作者のアドレス

   Steven Legg
   Adacel Technologies Ltd.
   250 Bay Street
   Brighton, Victoria 3186
   AUSTRALIA

スティーブンLegg Adacel Technologies株式会社250のカナダ金融界のビクトリア・3186ブライトン(オーストラリア)

   Phone: +61 3 8530 7710
   Fax:   +61 3 8530 7888
   EMail: steven.legg@adacel.com.au

以下に電話をしてください。 +61 3 8530 7710、Fax: +61 3 8530 7888はメールされます: steven.legg@adacel.com.au

Legg                        Standards Track                    [Page 15]

RFC 3641             Generic String Encoding Rules          October 2003

2003年10月に規則をコード化するLegg標準化過程[15ページ]RFC3641ジェネリックストリング

9.  Full Copyright Statement

9. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Legg                        Standards Track                    [Page 16]

Legg標準化過程[16ページ]