この文書はRFC3641の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group S. Legg
Request for Comments: 3641 Adacel Technologies
Category: Standards Track October 2003
Generic String Encoding Rules (GSER) for ASN.1 Types
ＡＳＮ．１での一般的文字列コード化規則（ＧＳＥＲ）
Status of this Memo
この文書の状態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (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.
この文書は与えられたＡＳＮ．１データタイプの値に対して、人間が読むこ
とができるテキストコードを生成する、一般的文字列コード化規則（ＧＳＥ
Ｒ）と呼ばれる抽象構文論表記法１（ＡＳＮ．１）のコード化規則群を定義
します。
Table of Contents
目次
1. Introduction
1. はじめに
2. Conventions
2. 約束
3. Generic String Encoding Rules
3. 一般的文字列コーディング規則
3.1 Type Referencing Notations
3.1 タイプ参照表記
3.2. Restricted Character String Types
3.2. 制限文字列タイプ
3.3. ChoiceOfStrings Types
3.3. ChoiceOfStringsタイプ
3.4. Identifiers
3.4. 識別子
3.5. BIT STRING
3.5. ビット文字列
3.6. BOOLEAN
3.6. ブーリアン
3.7. ENUMERATED
3.7. 列挙
3.8. INTEGER
3.8. 整数
3.9. NULL
3.9. ヌル
3.10. OBJECT IDENTIFIER and RELATIVE-OID
3.10. オブジェクト識別子と相対オブジェクト識別子
3.11. OCTET STRING
3.11. オクテット文字列
3.12. CHOICE
3.12. 選択
3.13. SEQUENCE and SET
3.13. シーケンスとセット
3.14. SEQUENCE OF and SET OF
3.14. シーケンスオブとセットオブ
3.15. CHARACTER STRING
3.15. キャラクタ文字列
3.16. EMBEDDED PDV
3.16. 埋め込みＰＤＶ
3.17. EXTERNAL
3.17. 外部
3.18. INSTANCE OF
3.18. インスタンスオブ
3.19. REAL
3.18. 実数
3.20. Variant Encodings
3.20. 方言コーディング
4. GSER Transfer Syntax
4. ＧＳＥＲ転送構文
5. Security Considerations
5. セキュリティの考察
6. References
6. 参考文献
6.1. Normative References
6.1. 参照する参考文献
6.2. Informative References
6.2. 有益な参考文献
7. Intellectual Property Notice
7. 知的所有権宣言
8. Author's Address
8. 著者のアドレス
9. Full Copyright Statement
9. 著作権表示全文
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.
この文書は与えられた任意のＡＳＮ．１タイプのコード化されたＡＳＮ．１
値から、人間が読むことができるＵＴＦ−８[6]文字列を作り出す、一般的文
字列コード化規則あるいはＧＳＥＲと呼ばれる、ＡＳＮ．１コード化規則を
定義します。
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.
「ＡＳＮ．１値」が基本的コーディング規則（ＢＥＲ）[12]でコードされた
値を意味しないことに注意してください。ＡＳＮ．１値は特定のコーディン
グとは独立の抽象的な概念です。ＢＥＲはＡＳＮ．１値の可能なコーディン
グの１つです。
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.
ＧＳＥＲはＡＳＮ．１値表記法[8]に基づいて、転送構文として注釈を使用す
る変更をして、ライト・ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）
[14]ディレクトリデータタイプのために確立したアドホック文字列コード化
をサポートするはずです。
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.
主にＬＤＡＰ固有の新しいＬＤＡＰ属性文法と強引文法の定義を意図的する
けれども、これらのコーディング規則は同じく人間が読むことができるＡＳ
Ｎ．１値表現が有用である他のドメインで使うことができます。
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.
他の仕様がＡＳＮ．１とは別の、カスタマイズした拡張バッカスナウア記法
（ＡＢＮＦ）[3]を、実装に便利な道具として求めるかもしれませんが、ＧＳ
ＥＲを参照することは人間が読むことができるテキストコード化を定義する
のに十分です（一般にＬＤＡＰ文法に生じるＡＳＮ．１タイプのＧＳＥＲコー
ドに等価なＡＢＮＦは別の文書で供給されます[15]）。このような指定は、
もしカスタマイズＡＢＮＧとこの文書によって定義されたＧＳＥＲコーディ
ングに相違があるなら、ＧＳＥＲコーディングが優先であると、述べるべき
です(SHOULD)。
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.
この文書を通じて、「タイプ」がＡＳＮ．１タイプを意味し、「値」がＡＳ
Ｎ．１値を意味するととられるべきです。
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"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
ＢＣＰ１４、ＲＦＣ２１１９[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]:
任意のＡＳＮ．１タイプ値のＧＳＥＲコーディングは次のＡＢＮＦ[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
The ABNF for each of the above rules is given in the following
sections.
上記の規則のそれぞれのＡＢＮＦは次の章で与えられます。
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.
定義されたタイプ名を持っているタイプの値が、タイプ名のタイプ割当ての
右側のタイプ定義に従ってコード化されます。
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.
実際のパラメータで、パラメータ化されたタイプの使用によって示されるタ
イプの値は、実際のパラメータで代りのダミー参照[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.
タグ付きや制限されたタイプの値は、それぞれタグあるいは制約なしのタイ
プ値としてコード化されます。タグがこの文書で定義された文字列コーディ
ングに現われません。ＡＳＮ．１制約表記法の詳細はＸ．６８０[8]とＸ．
６８２[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.
オブジェクトクラスフィールドタイプで示されるオープンタイプの値（Ｘ．
６８１の１４項[9]）は、特定の値のタイプに従ってコード化されます。
A value of a fixed type denoted by an ObjectClassFieldType is encoded
according to that fixed type.
オブジェクトクラスフィールドタイプで示される固定タイプ値はその固定タ
イプに従ってコード化されます。
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.
タイプフロムオブジェクト表記法によって記述されたタイプ値（Ｘ．６８１
の１５項[9]）は意味するタイプに従ってコード化されます。
A value of a type described by ValueSetFromObjects notation (Clause
15 of X.681 [9]) is encoded according to the governing type.
バリューセットフロムオブジェクト表記法によって記述されたタイプ値（Ｘ．
６８１の１５項[9]）が支配しているタイプに従ってコード化されます。
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.
文字列値の内容は、ＡＳＮ．１文字列タイプにかかわらず、ダブルクォート
の間のＵＴＦ−８文字列としてコード化されます。ＡＳＮ．１文字列タイプ
とその文字列タイプのアプリケーション内部の表現に依存して、ＵＴＦ−８
文字コーディングへあるいはからの翻訳が必要とされるかもしれません。
NumericStringとPrintableStringとIA５StringとVisibleStringISO646String）
はＵＴＦ−８と両立できて、翻訳を必要としません。BMPString(UCS-2)と
UniversalString(UCS-4)はＵＴＦ−８[6]に/からの直接の対応を持ちます。
残りの文字列タイプはＸ．６８０[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.
NumericStringやPrintableStringやTeletexString(T61String)や
VideotexStringやIA5StringやGraphicStringやVisibleString(ISO646String)
やGeneralStringやBMPStringやUniversalStringやUTF8Stringタイプが
<StringValue>規則に従ってコード化されます。
StringValue = dquote *SafeUTF8Character dquote
dquote = %x22 ; " (double quote)
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
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文
字セットを使い、ＵＴＦ−８への変換は簡単です。ObjectDescriptorは
GraphicStringタイプを使います。
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.
特定の選択肢が意味論的に意味を持たないような、２以上のＡＳＮ．１文字
列からの選択を供給するタイプを定義することはＡＳＮ．１仕様で珍しくあ
りません（DirectoryString[7]が主な例です）。このようなタイプは、ほと
んどの値が単純文字列タイプを使用するか、後方互換性を保ったままより広
範囲の文字セットの使用を強制する変化する要求条件を扱う場合に、すべて
の値を使うことによる複雑な文字コーディングを避けるために定義されます。
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.
ＧＳＥＲはすべてのＡＳＮ．１文字列タイプの値をＵＴＦ−８文字列として
コード化し、それで文字列タイプの純粋に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タイプの中に選択肢の意味の重要性を示すある特定のＡＳＮ．１の構
成がありますが、それらの構成がなくてもCHOICEタイプが純粋に構文である
ことを意味しません。それ故に、より小さくコード化するため（３.１２章参
照）、純粋に構文的な選択タイプを宣言することは仕様書にとって必要です。
これらの宣言されたCHOICEタイプはChoiceOfStringsタイプと述べられます。
To be eligible to be declared a ChoiceOfStrings type, an ASN.1 type
MUST satisfy the following conditions.
ChoiceOfStringsタイプと宣言するに適格であるために、ＡＳＮ．１タイプが
次の条件を満足させなくてはなりません(MUST)。
a) The type is a CHOICE type.
a) タイプは選択タイプです。
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) それぞれの選択肢の構成するタイプは次のＡＳＮ．１制限文字列タイプの
１つです：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) 各選択肢が異なる制限文字列タイプです。すなわち、２つの選択肢が同じ
ＡＳＮ．１制限文字列タイプではありません。
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.
DirectoryStringのＡＳＮ．１パラメータ化された型定義を考慮してください。
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)) }
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パラメータ化タイプを使う場
合は、上記の条件を満足させるＡＳＮ．１タイプを定義します。
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タイプと宣
言するかもしれません(MAY)。宣言はＡＳＮ．１タイプが定義される場所で行
われるべきです(SHOULD)、さもなければＬＤＡＰ属性や断定構文として導入
される場所で行われるべきです(SHOULD)。
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.
＜識別子＞はＡＳＮ．１表記法（Ｘ．６８０[8]の１１.３項）の識別子の定
義に従います。これは小文字のアルファベットから始まって、ゼロ個以上の
アルファベットか数字かハイフンが続きます。ハイフンが最後の文字として
は許されず、ハイフンの後にハイフンも許されません。識別子での大文字小
文字の区別は常に必要です。
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 = "-"
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>規則に従ってコード化されます。
もしビット文字列タイプの定義が命名されたビットリストを含むなら、
<BitStringValue>の<bit-list>形式を使ってももよいです(MAY)。もしビッ
ト文字列値のビット数が４の倍数であるなら、<BitStringValue>の<hstring>
形式を使ってももよいです(MAY)。さもなければ、<BitStringValue>の
<bstring>形式が使われます。
BitStringValue = bstring / hstring / bit-list
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.
<bit-list>規則はビット文字列値の１ビットを、コンマで区切った識別子の
リストとしてコード化します。それぞれの<identifier>が指定されたビット
リストの識別子の１つであり(MUST)、そして同じ<bit-list>で２回以上現れ
ません(MUST NOT)。<bstring>規則は各ビットを先頭から最後の順番で、
「0」か「1」の文字でコード化します。<hstring>規則は４ビットのグループ
を、最初のビットが最上位として、１６進数でコード化します。奇数個の
１６進数が認められます。
bit-list = "{" [ sp identifier
*( "," sp identifier ) ] sp "}"
hstring = squote *hexadecimal-digit squote %x48 ; '...'H
hexadecimal-digit = %x30-39 / ; "0" to "9"
%x41-46 ; "A" to "F"
bstring = squote *binary-digit squote %x42 ; '...'B
binary-digit = "0" / "1"
sp = *%x20 ; zero, one or more space characters
squote = %x27 ; ' (single quote)
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"
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>規則に従ってコード化されます。
<identifier>は列挙タイプの定義で列挙された項目の１に違いありません
(MUST)。
EnumeratedValue = identifier
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>規則に従ってコード化されます。もし整数タ
イプの定義が命名された番号リストを含むなら、<IntegerValue>の
<identifier>形式が使われかもしれません(MAY)、そしてその場合
<identifier>は番号リストの命名された識別子の１つであるに違いありません。
IntegerValue = "0" /
positive-number /
("-" positive-number) /
identifier
positive-number = non-zero-digit *decimal-digit
non-zero-digit = %x31-39 ; "1" to "9"
3.9. NULL
3.9. ヌル
A value of the NULL type is encoded according to the <NullValue>
rule.
ヌルタイプ値が<NullValue>規則に従ってコード化されます。
NullValue = %x4E.55.4C.4C ; "NULL"
3.10. OBJECT IDENTIFIER and RELATIVE-OID
3.10. オブジェクト識別子と相対オブジェクト識別子
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>規則に従ってコード
化されます。<ObjectIdentifierValue>規則は、オブジェクト識別子値のドッ
ト区切り１０進数表示、あるいはオブジェクトディスクプリタ名、すなわち
<descr>を許します。<descr>規則はＲＦＣ２２５２[4]で記述されます。オブ
ジェクトディスクプリタ名が潜在的にあいまいで、注意して使われるべきです。
ObjectIdentifierValue = numeric-oid / descr
numeric-oid = oid-component 1*( "." oid-component )
oid-component = "0" / positive-number
A value of the RELATIVE-OID type is encoded according to the
<RelativeOIDValue> rule.
相対的オブジェクト識別子タイプ値が<RelativeOIDValue>規則に従ってコー
ド化されます。
RelativeOIDValue = oid-component *( "." oid-component )
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>規則に従ってコード化され
ます。オクテットは最初オクテットから、最後のオクテットの順番で、コー
ド化されます。それぞれのオクテットが２桁の１６進数でコード化され、最
初の桁が上位４ビットに対応します。もし１６進数文字列が偶数桁でないな
ら、最後のオクテットの下位４ビットはゼロと考えられます。
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>規則に従ってコード化されます。もし対応する
選択タイプがChoiceOfStringsタイプであると宣言されたなら、
ChoiceOfStringsValue>コーディングが使われるかもしれません(MAY)。この
文書はDirectoryStringタイプをChoiceOfStringsタイプと宣言します（３.３
章参照）。さもなければ、<ChoiceValue>の<IdentifiedChoiceValue>形式が
使われます。
ChoiceValue = IdentifiedChoiceValue /
ChoiceOfStringsValue
IdentifiedChoiceValue = identifier ":" Value
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選択タイプ（例えば、Ｘ．５００ディレクトリ[16]）の内部
構造体を認識する実装のために、もし<StringValue>のクォート間の文字列が
ただPrintableStringで認められる文字だけを含んでいるなら、
DirectoryStringはprintableString選択肢を使うと考えられます、さもなけ
ればuTF8String選択肢を使うと考えられます。文字列内容から仮定されるも
の以外の選択肢を示すためにタイプDirectoryString値のために
<IdentifiedChoiceValue>規則が使われるかもしれません(MAY)。何の選択肢
が選択されるかにかかわらず、<Value>はＵＴＦ−８でコードされた文字列で
あるでしょう。しかしながら、もしＵＴＦ−８文字列の文字がが選ばれた選
択肢の文字列タイプで表現できないなら、構文誤りです。
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>
形式を解析できなければなりません(MUST)。
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>規則に従ってコード化されます。
<ComponentList>規則はシーケンス値で存在している特定の構成値を、コン
マで区切ってリスト化し、コード化します、そしてそれぞれの構成値はシー
ケンス型定義の対応する識別子が前に付きます。構成要素はシーケンスタイ
プでの定義の順番でコード化されます。
SequenceValue = ComponentList
ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}"
NamedValue = identifier msp Value
msp = 1*%x20 ; one or more space characters
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>規則に従ってコード化されます。構成要素はセッ
トタイプの定義の順序でコード化されます（すなわち、シーケンス値と同様）。
これはセットの構成要素は、任意の順序で書くことができるＡＳＮ．１値表
記法からの、故意の逸脱です。
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.
シーケンスとセットタイプ定義は、しばしば追加の構成タイプを含むことで
拡張されるので、送信者がより最新のシーケンスあるいはセットの定義を使っ
ているという仮定から、実装が認識できない識別子の<NamedValue>コーディ
ングを省略することができるべきです(SHOULD)。
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>規則に従って、コンマで区切
られた値のリストとして、コード化されます。それぞれの値がシーケンスオ
ブタイプの構成タイプに従ってコード化されます。
SequenceOfValue = "{" [ sp Value *( "," sp Value) ] 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>規則にしたがって、値のリストとして
コード化されます。それぞれの値はセットオブタイプの構成タイプに従って
コード化されます。
SetOfValue = "{" [ sp Value *( "," sp Value) ] sp "}"
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).
無制限のキャラクタ文字列タイプ値が、Ｘ．６８０[8]の４０.５項に対応す
るシーケンスタイプの定義に従ってコード化されます（等価ＡＢＮＦは[15]
を参照）。
CharacterStringValue = SequenceValue
3.16. EMBEDDED PDV
3.16. 埋め込みＰＤＶ
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).
埋め込みＰＤＶタイプ値が、Ｘ．６８０[8]の３３.５項の対応するシーケン
スタイプ定義に従ってコード化されます（等価ＡＢＮＦは[15] を参照）。
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).
外部タイプ値が、Ｘ．６９０[12]の８.１８.１項の対応するシーケンスタイ
プ定義に従ってコード化されます（等価ＡＢＮＦは[15] を参照）。
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].
インスタンスオブタイプ値が、Ｘ．６８１[9]の付録Ｃの対応するシーケンス
タイプ定義に従ってコード化されます（等価ＡＢＮＦは[15] を参照）。
InstanceOfValue = SequenceValue
3.19. REAL
3.18. 実数
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」でコード化され(MUST)、そうでなければ特別
値<PLUS-INFINITY>か、特別値<MINUS-INFINITY>か、オプションで符号のある
<realnumber>か、Ｘ．６８０[8]の２０.５項で定義される実数に対応するシー
ケンスタイプ定義に従ってコード化されます（等価ＡＢＮＦは[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
realnumber = mantissa exponent
mantissa = (positive-number [ "." *decimal-digit ])
/ ( "0." *("0") positive-number )
exponent = "E" ( "0" / ([ "-" ] positive-number))
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"
3.20. Variant Encodings
3.20. 方言コーディング
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.
ある命名された複雑なＡＳＮ．１タイプの値は特別な文字列コーディングを
持っています。これらの特別なコーディングは常に、ＡＳＮ．１タイプ定義
に基づくものの代わりに、コーディングに使われます。
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.
RDNSequenceタイプ、すなわち、著名な名前、の値が<RDNSequenceValue>に
従って、引用されたＬＤＡＰＤＮ文字列としてコード化されます。文字列は
ＲＦＣ２２５３[5]の３章の<distinguishedName>規則に従って最初に得られ
て、そして次にUTF8String値であるように、すなわち、ダブルクォート間の
埋め込みのダブルクォートが繰返しで示されるように、コード化されます。
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.
RDNSequence値の一部でないRelativeDistinguishedName値が引用文字列とし
て<RelativeDistinguishedNameValue>規則に従ってコード化されます。文字
列はＲＦＣ２２５３[5]の３章の<name-component>規則に従って最初に得ら
れて、そして次に、それがUTF8String値であるかのように、コード化されま
す。
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.
ORAddressタイプの値が引用文字列として<ORAddressValue>規則に従ってコー
ド化されます。文字列はＲＦＣ２１５６[2]からのMTS.ORAddressのテキスト
表現に従って最初に得られて、そして次に、それがIA5String値であるかのよ
うに、コード化されます。
ORAddressValue = StringValue
4. GSER Transfer Syntax
4. ＧＳＥＲ転送構文
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:
次のオブジェクト識別子は、一般文字列コーディング規則を識別するため、
Ａｄａｃｅｌテクノロジによって割り当てられ、標準オーストラリアによっ
てＡｄａｃｅｌに割り当てられたアークの下にあります：
{ 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.
このオブジェクト識別子は、例えば、埋め込みのＰＤＶ値でＧＳＥＲでコー
ドされたデータ値のための転送構文を記述するために使われるでしょう。
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.
一般的文字列コーディング規則は正規化コーディングを定義しません。すな
わち、ＧＳＥＲコーディングから他のコーディング（例えばＢＥＲ）へ変換
し、ＧＳＥＲへ戻した場合に、必ずしも元のＧＳＥＲオクテットコーディン
グを再現しないでしょう。それ故に、ＧＳＥＲは正規化コーディングが必要
な所で使われてはなりません(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.
さらに、ＧＳＥＲは必ずTeletexStringやVideotexStringやGraphicStringや
GeneralStringタイプ値の正確に再現できるオクテットコーディングを可能に
しません、それで著名コーディング規則（ＤＥＲ）[12]コーディングからの
変換と、ＤＥＲへの戻しは、元のＤＥＲコーディングを再現しないかもしれ
ません。それ故に、ＧＳＥＲは元のバイナリコーディングが回復可能でなけ
ればならないＡＳＮ．１抽象値の、保存や転送での、再コード化に使用して
はなりません(MUST NOT)。このような回復はディジタル署名の検証に必要で
す。このような場合、プロトコルがＤＥＲやＤＥＲ反転可能なコーディング
を使うべきです。
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.
セキュリティの敏感なフィールドを解釈する時、そして特にフィールドがア
クセスの可否を決めるとき、実装は基礎となる抽象値に使われたコーディン
グにかかわらず比較できることを保証しなくてはなりません(MUST)。
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.
[2] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions",
RFC 2252, December 1997.
[5] Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
Protocol (v3): UTF-8 String Representation of Distinguished
Names", RFC 2253, December 1997.
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[7] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
Information Technology - Open Systems Interconnection - The
Directory: Selected attribute types
[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
[9] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2:2002
Information technology - Abstract Syntax Notation One (ASN.1):
Information object specification
[10] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3:2002
Information technology - Abstract Syntax Notation One (ASN.1):
Constraint specification
[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
[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)
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.
[14] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol
(v3): Technical Specification", RFC 3377, September 2002.
[15] Legg, S., "Common Elements of Generic String Encoding Rules
(GSER) Encodings", RFC 3642, October 2003.
[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
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.
この文書に記述された実装や技術に関して主張される知的財産や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する調査をしたとは述べません。ＩＥＴＦ標準手続きと標準関連文書で
の権利に関しての手順の情報はＢＣＰ１１を見てください。出版に利用する
権利の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書
の実装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの
結果はＩＥＴＦ事務局で得られます。
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.
ＩＥＴＦは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
めます。どうかＩＥＴＦ専務に情報を伝えてください。
8. Author's Address
8. 著者のアドレス
Steven Legg
Adacel Technologies Ltd.
250 Bay Street
Brighton, Victoria 3186
AUSTRALIA
Phone: +61 3 8530 7710
Fax: +61 3 8530 7888
EMail: steven.legg@adacel.com.au
9. Full Copyright Statement
9. 著作権表示全文
Copyright (C) The Internet Society (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.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。