RFC4792 日本語訳

Network Working Group                                            S. Legg
Request for Comments: 4792                                       eB2Bcom
Updates: 3641                                               January 2007
Category: Standards Track

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

                     Encoding Instructions for the
                  Generic String Encoding Rules (GSER)

一般的なストリング符号化規則のための指示をコード化します。(GSER)

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

Abstract

要約

   Abstract Syntax Notation One (ASN.1) defines a general framework for
   annotating types in an ASN.1 specification with encoding instructions
   that alter how values of those types are encoded according to ASN.1
   encoding rules.  This document defines the supporting notation for
   encoding instructions that apply to the Generic String Encoding Rules
   (GSER) and, in particular, defines an encoding instruction to provide
   a machine-processable representation for the declaration of a GSER
   ChoiceOfStrings type.

抽象的なSyntax Notation One(ASN.1)は、ASN.1仕様にASN.1符号化規則によると、そういったタイプの人の値がどうコード化されるかを変更する指示をコード化するのにタイプを注釈するために一般的な枠組みを定義します。 このドキュメントは、Generic String Encoding Rules(GSER)に適用される指示をコード化するためにサポート記法を定義して、GSER ChoiceOfStringsタイプの宣言のマシン-処理可能表現を提供するためにコード化指示を特に定義します。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Conventions .....................................................2
   3. Notation for GSER Encoding Instructions .........................2
   4. The CHOICE-OF-STRINGS Encoding Instruction ......................3
      4.1. Effect on GSER Encodings ...................................5
      4.2. Replacement of Existing ChoiceOfStrings Declarations .......6
   5. Security Considerations .........................................7
   6. Normative References ............................................7

1. 序論…2 2. コンベンション…2 3. 指示をコード化するGSERのための記法…2 4. ストリングの指示をコード化する選択…3 4.1. GSER Encodingsへの効果…5 4.2. 既存のChoiceOfStrings宣言の交換…6 5. セキュリティ問題…7 6. 標準の参照…7

Legg                        Standards Track                     [Page 1]

RFC 4792             Encoding Instructions for GSER         January 2007

2007年1月にGSERのために指示をコード化するLegg標準化過程[1ページ]RFC4792

1.  Introduction

1. 序論

   Abstract Syntax Notation One (ASN.1) [X.680] defines a general
   framework for annotating types in an ASN.1 specification with
   encoding instructions [X.680-1] that alter how values of those types
   are encoded according to ASN.1 encoding rules.  This document defines
   the supporting notation for encoding instructions that apply to the
   Generic String Encoding Rules (GSER) [GSER], and in particular
   defines an encoding instruction, the CHOICE-OF-STRINGS encoding
   instruction, to provide a machine-processable representation for the
   declaration of a GSER ChoiceOfStrings type.

抽象的なSyntax Notation One(ASN.1)[X.680]は、ASN.1仕様にASN.1符号化規則によると、そういったタイプの人の値がどうコード化されるかを変更する指示[X.680-1]をコード化するのにタイプを注釈するために一般的な枠組みを定義します。 このドキュメントは、Generic String Encoding Rules(GSER)[GSER]に適用される指示をコード化するためのサポート記法を定義して、コード化指示を特に定義します、CHOICE-OF-STRINGSがGSER ChoiceOfStringsタイプの宣言のマシン-処理可能表現を提供するために指示をコード化して。

   The CHOICE-OF-STRINGS encoding instruction SHOULD be used instead of
   simply declaring a ChoiceOfStrings type.

CHOICE-OF-STRINGS、指示SHOULDをコード化して、ChoiceOfStringsがタイプすると単に宣言することの代わりに使用されてください。

2.  Conventions

2. コンベンション

   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
   [BCP14].

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

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

このドキュメント中では、ASN.1がタイプすることを意味するために「タイプ」を取るものとします、そして、ASNの.1の抽象的な価値を意味するために「値」を取るものとします、別の方法で資格がない場合。

   A reference to an ASN.1 production [X.680] (e.g., Type, NamedType) is
   a reference to text in an ASN.1 specification corresponding to that
   production.

ASN.1生産[X.680](例えば、Type、NamedType)の参照はその生産に対応するASN.1仕様によるテキストの参照です。

3.  Notation for GSER Encoding Instructions

3. 指示をコード化するGSERのための記法

   The grammar of ASN.1 permits the application of encoding instructions
   [X.680-1], through type prefixes and encoding control sections, that
   modify how abstract values are encoded by nominated encoding rules.

ASN.1の文法は抽象的な値が指名符号化規則でどうコード化されるかを変更するタイプ接頭語と制御セクションをコード化するのによる指示[X.680-1]をコード化するアプリケーションを可能にします。

   The generic notation for type prefixes and encoding control sections
   is defined by the ASN.1 basic notation [X.680] [X.680-1], and
   includes an encoding reference to identify the specific encoding
   rules that are affected by the encoding instruction.

タイプ接頭語と制御セクションをコード化するための一般的な記法は、ASN.1の基本的な記法[X.680][X.680-1]で定義されて、コード化指示で影響を受ける特定の符号化規則を特定するためにコード化指示するものを含んでいます。

   The encoding reference that identifies the Generic String Encoding
   Rules is literally GSER.

Generic String Encoding Rulesを特定するコード化参照は文字通りGSERです。

   The specific notation for an encoding instruction for a particular
   set of encoding rules is left to the specification of those encoding
   rules.  Consequently, this companion document to the GSER
   specification [GSER] defines the notation for GSER encoding

特定の符号化規則のためのコード化指示のための特定の記法はそれらの符号化規則の仕様に残されます。 その結果、GSER仕様[GSER]へのこの仲間ドキュメントはGSERコード化のための記法を定義します。

Legg                        Standards Track                     [Page 2]

RFC 4792             Encoding Instructions for GSER         January 2007

2007年1月にGSERのために指示をコード化するLegg標準化過程[2ページ]RFC4792

   instructions.  Specifically, it elaborates the EncodingInstruction
   and EncodingInstructionAssignmentList placeholder productions of the
   ASN.1 basic notation.

指示。 明確に、それはASN.1の基本的な記法のEncodingInstructionとEncodingInstructionAssignmentListプレースホルダ創作について詳しく説明します。

   In the context of the GSER encoding reference the EncodingInstruction
   production is defined as follows, using the conventions of the ASN.1
   basic notation:

参照をコード化するGSERの文脈では、EncodingInstruction生産は以下の通り定義されます、ASNの.1の基本的な記法のコンベンションを使用して:

      EncodingInstruction ::=
          ChoiceOfStringsInstruction

EncodingInstruction:、:= ChoiceOfStringsInstruction

   In the context of the GSER encoding reference the
   EncodingInstructionAssignmentList production (which only appears in
   an encoding control section) is empty:

参照をコード化するGSERの文脈では、EncodingInstructionAssignmentList生産(コード化制御セクションに現れるだけである)は空です:

      EncodingInstructionAssignmentList ::= empty

EncodingInstructionAssignmentList:、:= 空になってください。

4.  The CHOICE-OF-STRINGS Encoding Instruction

4. ストリングの指示をコード化する選択

   The CHOICE-OF-STRINGS encoding instruction allows a GSER encoder to
   encode the alternative of a CHOICE (of restricted string types)
   without the leading identifier.  The optional PrecedenceList also
   allows a specification writer to alter the order in which a GSER
   decoder will consider the alternatives of the CHOICE as it determines
   which alternative has been encoded when the identifier is absent.

指示をコード化するCHOICE-OF-STRINGSはGSERエンコーダに主な識別子なしでCHOICE(制限されたストリングタイプの)の代替手段をコード化させます。 また、任意のPrecedenceListは仕様作家に識別子が欠けているとき、どの代替手段がコード化されたかを決定するときGSERデコーダがCHOICEの代替手段を考えるオーダーを変更させます。

   The notation for a CHOICE-OF-STRINGS encoding instruction is defined
   as follows:

指示をコード化するCHOICE-OF-STRINGSのための記法は以下の通り定義されます:

      UnionInstruction ::= "CHOICE-OF-STRINGS" AlternativesPrecedence ?

UnionInstruction:、:= 「ストリングの選択」AlternativesPrecedence?

      AlternativesPrecedence ::= "PRECEDENCE" PrecedenceList

AlternativesPrecedence:、:= 「先行」PrecedenceList

      PrecedenceList ::= identifier PrecedenceList ?

PrecedenceList:、:= 識別子PrecedenceList?

   The Type in the EncodingPrefixedType for a CHOICE-OF-STRINGS encoding
   instruction SHALL be:

Type、指示SHALLをコード化するCHOICE-OF-STRINGSのためのEncodingPrefixedTypeでは、である:

   (a) a BuiltinType that is a ChoiceType, or

または(a) ChoiceTypeであるBuiltinType。

   (b) a ConstrainedType that is not a TypeWithConstraint where the Type
       in the ConstrainedType is one of (a) to (d), or

または(b) ConstrainedTypeのTypeが1歳である(d)への(a)のTypeWithConstraintでないConstrainedType。

   (c) a BuiltinType that is a PrefixedType that is a TaggedType where
       the Type in the TaggedType is one of (a) to (d), or

または(c) (d)へのTaggedTypeのTypeが1歳である(a)のTaggedTypeであるPrefixedTypeであるBuiltinType。

Legg                        Standards Track                     [Page 3]

RFC 4792             Encoding Instructions for GSER         January 2007

2007年1月にGSERのために指示をコード化するLegg標準化過程[3ページ]RFC4792

   (d) a BuiltinType that is a PrefixedType that is an
       EncodingPrefixedType where the Type in the EncodingPrefixedType
       is one of (a) to (d).

(d) (d)へのEncodingPrefixedTypeのTypeが1歳である(a)のEncodingPrefixedTypeであるPrefixedTypeであるBuiltinType。

   The effect of this condition is to force the CHOICE-OF-STRINGS
   encoding instruction to be textually co-located with the CHOICE type
   definition to which it applies.  This makes it clear to a reader that
   the encoding instruction applies to every use of the CHOICE type no
   matter how it might be referenced.

この状態の効果は指示をコード化するCHOICE-OF-STRINGSがそれが適用されるCHOICE型定義で原文に共同見つけさせられることです。 これは、それがどのように参照をつけられるかもしれなくてもコード化指示がCHOICEタイプのあらゆる使用に適用されると読者に断言します。

   The ChoiceType in case (a) is said to be "subject to" the CHOICE-OF-
   STRINGS encoding instruction.

場合(a)におけるChoiceTypeは指示をコード化するCHOICE-OF- STRINGS「を条件として」、あると言われています。

   The Type of each NamedType of the ChoiceType in case (a) MUST be:

場合(a)におけるChoiceTypeのそれぞれのNamedTypeのTypeは以下の通りであるに違いありません。

   (1) the NumericString, PrintableString, TeletexString (T61String),
       VideotexString, IA5String, GraphicString, VisibleString
       (ISO646String), GeneralString, BMPString, UniversalString, or
       UTF8String type, or

または(1) NumericString、PrintableString、TeletexString(T61String)、VideotexString、IA5String、GraphicString、VisibleString(ISO646String)、GeneralString、BMPString、UniversalString、またはUTF8Stringがタイプする。

   (2) a type notation that references a type that is one of (1) to (4),
       or

または(2) 1歳である(4)への(1)のタイプに参照をつけるタイプ記法。

   (3) a constrained type where the type that is constrained is one of
       (1) to (4), or

または(3) 制約つきであるタイプが1歳である(4)への(1)の制約つきタイプ。

   (4) a prefixed type where the type that is prefixed is one of (1) to
       (4).

(4) 前に置かれているタイプが1歳である(4)への(1)の前に置かれたタイプ。

      ASIDE: A tagged type is a special case of a prefixed type.  An
      effect of case (4) is that tagging is not significant.

傍らに: タグ付けをされたタイプは前に置かれたタイプの特別なケースです。 ケース(4)の効果はタグ付けが重要でないということです。

   The ASN.1 restricted string type in case (1) MUST be different for
   each NamedType in the ChoiceType, i.e., no two alternatives have the
   same restricted string type.

ChoiceTypeの各NamedTypeにおいて、(1)が異なるに違いないといけないので、ASN.1はストリングタイプを制限しました、すなわち、代替手段が同じように持っていない2が全くストリングタイプを制限しました。

   If case (3) applies to any NamedType, then the constraint in case (3)
   MUST be the same for each NamedType, i.e., either none of the
   alternatives has a constraint, or all of the alternatives have
   exactly the same constraint.

各NamedTypeに、ケース(3)がどんなNamedTypeにも適用されるなら場合(3)における規制が同じであるに違いない、すなわち、代替手段のいずれにはも、規制がないか、または代替手段のすべてにまさに同じ規制があります。

   Each identifier in the PrecedenceList MUST be the identifier of a
   NamedType of the ChoiceType.

PrecedenceListの各識別子はChoiceTypeのNamedTypeに関する識別子であるに違いありません。

   A particular identifier SHALL NOT appear more than once in the same
   PrecedenceList.

特定の識別子SHALL NOTは同じPrecedenceListで一度より多く見えます。

Legg                        Standards Track                     [Page 4]

RFC 4792             Encoding Instructions for GSER         January 2007

2007年1月にGSERのために指示をコード化するLegg標準化過程[4ページ]RFC4792

4.1.  Effect on GSER Encodings

4.1. GSER Encodingsへの効果

   A value of a CHOICE type is encoded according to the <ChoiceValue>
   [GSER] Augmented Backus-Naur Form [ABNF] rule.  The ABNF for
   <ChoiceValue> is reproduced here for convenience:

<ChoiceValue>[GSER]の増大しているBN記法[ABNF]規則に従って、CHOICEタイプの値はコード化されます。 <ChoiceValue>のためのABNFは便宜のためにここで再生します:

      ChoiceValue           = IdentifiedChoiceValue /
                              ChoiceOfStringsValue

ChoiceValueはIdentifiedChoiceValue / ChoiceOfStringsValueと等しいです。

      IdentifiedChoiceValue = identifier ":" Value
      ChoiceOfStringsValue  = StringValue

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

   The <IdentifiedChoiceValue> rule MUST be used to encode values of a
   CHOICE type where the ChoiceType is not subject to a CHOICE-OF-
   STRINGS encoding instruction.

ChoiceTypeは指示をコード化するCHOICE-OF- STRINGSを受けることがないCHOICEタイプの値をコード化するのに<IdentifiedChoiceValue>規則を使用しなければなりません。

   The chosen alternative of a value of a CHOICE type corresponds to
   some NamedType in the definition of the type.  The <identifier> in
   the <IdentifiedChoiceValue> is the identifier of this NamedType.

CHOICEタイプの価値の選ばれた代替手段はタイプの定義でいくらかのNamedTypeに対応しています。 <IdentifiedChoiceValue>の<識別子>はこのNamedTypeに関する識別子です。

   Either the <IdentifiedChoiceValue> rule or the <ChoiceOfStringsValue>
   rule is used to encode values of a CHOICE type where the ChoiceType
   is subject to a CHOICE-OF-STRINGS encoding instruction.

<IdentifiedChoiceValue>規則か<ChoiceOfStringsValue>規則のどちらかが、ChoiceTypeは指示をコード化するCHOICE-OF-STRINGSを受けることがあるCHOICEタイプの値をコード化するのに使用されます。

   If <ChoiceOfStringsValue> has been used, then a GSER decoder MUST
   determine the chosen alternative by considering the alternatives of
   the CHOICE in the order prescribed below and accepting the first
   alternative that allows all of the characters in the <StringValue>.

<ChoiceOfStringsValue>が使用されたなら、GSERデコーダは、<StringValue>でキャラクタに下で定められた順序に従ってCHOICEの代替手段を考えるのによる選ばれた代替手段を決定して、すべてを許容する最初の代替手段を受け入れなければなりません。

   If the CHOICE-OF-STRINGS encoding instruction has a PrecedenceList,
   then the alternatives of the ChoiceType referenced by the
   PrecedenceList are considered in the order identified by that
   PrecedenceList, and then the remaining alternatives are considered in
   the order of their definition in the ChoiceType.  If the CHOICE-OF-
   STRINGS encoding instruction does not have a PrecedenceList, then all
   the alternatives of the ChoiceType are considered in the order of
   their definition in the ChoiceType.

指示をコード化するCHOICE-OF-STRINGSがPrecedenceListを持っているなら、PrecedenceListによって参照をつけられたChoiceTypeの代替手段はそのPrecedenceListによって特定されたオーダーで考えられます、そして、次に、残っている代替手段はChoiceTypeでの彼らの定義の注文で考えられます。 指示をコード化するCHOICE-OF- STRINGSがPrecedenceListを持っていないなら、ChoiceTypeのすべての選択肢がChoiceTypeでの彼らの定義の注文で考えられます。

   A GSER encoder MUST use <IdentifiedChoiceValue> if a GSER decoder
   would determine the chosen alternative to be something other than the
   chosen alternative of the CHOICE value being encoded; otherwise,
   <ChoiceOfStringsValue> MAY be used.

GSERデコーダが、選ばれた代替手段がコード化されるCHOICE価値の選ばれた代替手段以外の何かであることを決定するなら、GSERエンコーダは<IdentifiedChoiceValue>を使用しなければなりません。 さもなければ、<ChoiceOfStringsValue>は使用されるかもしれません。

Legg                        Standards Track                     [Page 5]

RFC 4792             Encoding Instructions for GSER         January 2007

2007年1月にGSERのために指示をコード化するLegg標準化過程[5ページ]RFC4792

   Example

例

      Consider this type definition:

この型定義を考えてください:

         [GSER:CHOICE-OF-STRINGS PRECEDENCE basicName] CHOICE {
             extendedName  UTF8String,
             basicName     PrintableString
         }

[GSER: ストリングの選択先行basicName] 選択extendedName UTF8String、basicName PrintableString

      If a <ChoiceOfStringsValue> has been used, then a GSER decoder
      would first consider whether the <StringValue> was a valid
      basicName (a PrintableString) before considering whether it was a
      valid extendedName (a UTF8String).

<ChoiceOfStringsValue>が使用されたなら、GSERデコーダは、最初に、それが有効なextendedName(UTF8String)であったかどうか考える前に<StringValue>が有効なbasicName(PrintableString)であったかどうか考えるでしょう。

4.2.  Replacement of Existing ChoiceOfStrings Declarations

4.2. 既存のChoiceOfStrings宣言の交換

   In line with the previous declaration [GSER] of the DirectoryString
   type as a ChoiceOfStrings type, applications using GSER MUST add this
   encoding instruction:

DirectoryStringタイプの前の宣言[GSER]に沿って、ChoiceOfStringsがタイプするように、GSER MUSTを使用するアプリケーションが指示をコード化しながら、これを加えます:

      [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString uTF8String]

[GSER: ストリングの選択先行printableString uTF8String]

   immediately before the "CHOICE" keyword in the definition of the
   DirectoryString type in the third and every subsequent edition of the
   SelectedAttributeTypes ASN.1 module of X.520 [X.520-3] [X.520-4]
   [X.520-5].

DirectoryStringの定義における「特選している」キーワードの直前、X.520[X.520-3][X.520-4][X.520-5]のSelectedAttributeTypes ASN.1モジュールの3番目とあらゆるその後の版をタイプしてください。

   For example, this is how the DirectoryString definition would appear
   in the third, fourth and fifth editions:

例えば、これはDirectoryString定義が3番目、4番目、および5番目の版にどう載っているだろうかということです:

      DirectoryString{INTEGER:maxSize} ::=
      [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString uTF8String]
      CHOICE {
          teletexString     TeletexString(SIZE (1..maxSize)),
          printableString   PrintableString(SIZE (1..maxSize)),
          universalString   UniversalString(SIZE (1..maxSize)),
          bmpString         BMPString(SIZE (1..maxSize)),
          uTF8String        UTF8String(SIZE (1..maxSize))
      }

DirectoryString、整数: maxSize:、:= [GSER: ストリングの選択先行printableString uTF8String] 選択teletexString TeletexString(サイズ(1..maxSize))、printableString PrintableString(サイズ(1..maxSize))、universalString UniversalString(サイズ(1..maxSize))、bmpString BMPString(サイズ(1..maxSize))、uTF8String UTF8String(サイズ(1..maxSize))

   The uTF8String alternative did not appear in the second edition of
   the SelectedAttributeTypes ASN.1 module of X.520 [X.520-2].  For
   compatibility, applications using GSER with the second edition of
   X.520 MUST add this encoding instruction:

uTF8String代替手段はX.520[X.520-2]のSelectedAttributeTypes ASN.1モジュールの第2版に載っていませんでした。 互換性のために、X.520 MUSTの第2版があるGSERを使用するアプリケーションは指示をコード化しながら、これを加えます:

      [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString]

[GSER: ストリングの選択先行printableString]

Legg                        Standards Track                     [Page 6]

RFC 4792             Encoding Instructions for GSER         January 2007

2007年1月にGSERのために指示をコード化するLegg標準化過程[6ページ]RFC4792

   immediately before the "CHOICE" keyword in the definition of the
   DirectoryString type.

DirectoryStringの定義における「特選している」キーワードの直前、タイプしてください。

   For example, this is how the DirectoryString definition would appear
   in the second edition:

例えば、これはDirectoryString定義が第2版にどう載っているだろうかということです:

      DirectoryString{INTEGER:maxSize} ::=
      [GSER:CHOICE-OF-STRINGS PRECEDENCE printableString]
      CHOICE {
          teletexString     TeletexString(SIZE (1..maxSize)),
          printableString   PrintableString(SIZE (1..maxSize)),
          universalString   UniversalString(SIZE (1..maxSize))
      }

DirectoryString、整数: maxSize:、:= [GSER: ストリングの選択先行printableString] 選択teletexString TeletexString(サイズ(1..maxSize))、printableString PrintableString(サイズ(1..maxSize))、universalString UniversalString(サイズ(1..maxSize))

5.  Security Considerations

5. セキュリティ問題

   This specification changes the manner in which ChoiceOfStrings types
   are declared but does not alter the existing behaviour of GSER
   implementations.  The security considerations for GSER are unchanged
   (see [GSER]).

この仕様は、ChoiceOfStringsタイプが宣言される方法を変えますが、GSER実現の既存のふるまいを変更しません。 GSERのためのセキュリティ問題は変わりがありません([GSER]を見てください)。

6.  Normative References

6. 引用規格

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

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

   [GSER]     Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
              Types", RFC 3641, October 2003.

[GSER]Legg、2003年10月のS.、「ASN.1タイプのための一般的なストリング符号化規則(GSER)」RFC3641。

   [ABNF]     Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", RFC 4234, October 2005.

エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

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

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

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

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

   [X.520-4]  ITU-T Recommendation X.520 (02/01) | ISO/IEC 9594-6:2001,
              Information technology - Open Systems Interconnection -
              The Directory: Selected attribute types

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

   [X.520-5]  ITU-T Recommendation X.520 (08/05) | ISO/IEC 9594-6:2005,
              Information technology - Open Systems Interconnection -
              The Directory: Selected attribute types

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

Legg                        Standards Track                     [Page 7]

RFC 4792             Encoding Instructions for GSER         January 2007

2007年1月にGSERのために指示をコード化するLegg標準化過程[7ページ]RFC4792

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

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

   [X.680-1]  ITU-T Recommendation X.680 (2002) Amendment 1 (10/03) |
              ISO/IEC 8824-1:2002/Amd 1:2004, Support for EXTENDED-XER.

[X.680-1]ITU-T推薦X.680(2002)修正1(10/03)| ISO/IEC8824-1: 2002/Amd1:2004、拡張XERのサポート。

Author's Address

作者のアドレス

   Dr. Steven Legg
   eB2Bcom
   Suite 3, Woodhouse Corporate Centre
   935 Station Street
   Box Hill North, Victoria 3129
   AUSTRALIA

スティーブンLegg eB2Bcom Suite博士3、北のウッドハウス法人のセンター935駅の通りBoxヒル、ビクトリア・3129オーストラリア

   Phone: +61 3 9896 7830
   Fax:   +61 3 9896 7801
   EMail: steven.legg@eb2bcom.com

以下に電話をしてください。 +61 3 9896 7830、Fax: +61 3 9896 7801はメールされます: steven.legg@eb2bcom.com

Legg                        Standards Track                     [Page 8]

RFC 4792             Encoding Instructions for GSER         January 2007

2007年1月にGSERのために指示をコード化するLegg標準化過程[8ページ]RFC4792

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

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

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

Legg                        Standards Track                     [Page 9]

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