RFC1698 日本語訳
1698 Octet Sequences for Upper-Layer OSI to Support BasicCommunications Applications. P. Furniss. October 1994. (Format: TXT=67433 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Furniss Request for Comments: 1698 Consultant Category: Informational October 1994
コメントを求めるワーキンググループP.ファーニスの要求をネットワークでつないでください: 1698年のコンサルタントカテゴリ: 情報の1994年10月
Octet Sequences for Upper-Layer OSI
to Support Basic Communications Applications
上側の層のOSIが主文がアプリケーションであるとサポートする八重奏系列
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document states particular octet sequences that comprise the OSI upper-layer protocols (Session, Presentation and ACSE) when used to support applications with "basic communications requirements". These include OSI application protocols such as X.400 P7 and Directory Access Protocol, and "migrant" protocols, originally defined for use over other transports.
このドキュメントは「主文要件」でアプリケーションをサポートするのに使用されるとOSI上側の層のプロトコル(セッション、Presentation、およびACSE)を包括する特定の八重奏系列を述べます。 これらはプロトコル、および「移住性」のプロトコルが元々他の輸送の上の使用のために定義したX.400 P7やディレクトリAccessなどのOSIアプリケーション・プロトコルを含んでいます。
As well as the octet sequences which are the supporting layer headers (and trailers) around the application data, this document includes some tutorial material on the OSI upper layers.
また、サポートすることである八重奏系列がアプリケーションデータの周りでヘッダー(そして、トレーラ)を層にするとき、このドキュメントはOSIの上側の層の何らかの家庭教師の材料を含んでいます。
An implementation that sends the octet sequences given here, and interprets the equivalent protocol received, will be able to interwork with an implementation based on the base standard, when both are being used to support an appropriate application protocol.
ここに与えられた八重奏系列を送って、受け取られた同等なプロトコルを解釈する実装は、適切なアプリケーション・プロトコルをサポートするためには両方であるときにベース規格に基づく実装で織り込むことができるのが、使用していることにされるのであるということでしょう。
Table of Contents
目次
1. Introduction ...................................................2
2. General ........................................................3
2.1 Subdivisions of "basic communication applications" ...........3
2.2 Conformance and interworking .................................5
2.3 Relationship to other documents ..............................5
3. Contexts and titles ............................................6
3.1 The concepts of abstract and transfer syntax .................6
3.2 Use of presentation context by cookbook applications..........7
3.3 Processing Presentation-context-definition-list ..............8
3.4 Application context ..........................................9
3.5 APtitles and AEqualifiers ....................................9
4. What has to be sent and received ..............................10
4.1 Sequence of OSI protocol data units used ....................10
4.2 Which OSI fields are used ...................................12
1. 序論…2 2. 一般…3 2.1 「主文アプリケーション」の区画分譲地…3 2.2 順応であって織り込むこと…5 他のドキュメントとの2.3関係…5 3. 文脈とタイトル…6 3.1 要約と転送構文の概念…6 3.2 プレゼンテーション文脈の料理の本アプリケーションによる使用…7 3.3処理プレゼンテーション文脈定義リスト…8 3.4アプリケーション文脈…9 3.5APtitlesとAEqualifiers…9 4. 送られて、受け取られなければならないもの…10 4.1 ユニットが使用したOSIプロトコルデータの系列…10 OSIがさばく4.2は使用されています…12
Furniss [Page 1] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[1ページ]RFC1698ThinOSI
4.3 Encoding methods and length fields ..........................14
4.3.1 Session items .............................................14
4.3.2 ASN.1/BER items (Presentation and ACSE) ...................14
4.4 BER Encoding of values for primitive datatypes ..............15
4.5 Unnecessary constructed encodings ...........................16
5. Notation ......................................................16
6. Octet sequences ...............................................17
6.1 Connection request message ..................................17
6.2 Successful reply to connection setup ........................20
6.3 Connection rejection ........................................22
6.4 Data-phase TSDU .............................................23
6.5 Closedown - release request ................................24
6.6 Closedown - release response ................................25
6.7 Deliberate abort ............................................25
6.8 Provider abort ..............................................27
6.9 Abort accept ................................................27
7. References ....................................................27
8. Other notes ...................................................28
9. Security Considerations .......................................29
10. Author's Address .............................................29
4.3 メソッドと長さの分野をコード化します…14 4.3 .1 セッション項目…14 4.3 .2 ASN.1/BERの品目(プレゼンテーションとACSE)…14 4.4 原始のデータ型式のための値のBER Encoding…15 4.5 不要な組み立てられたencodings…16 5. 記法…16 6. 八重奏系列…17 6.1 接続要求メッセージ…17 接続設定に関する6.2のうまくいっている回答…20 6.3 接続拒絶…22 6.4 データフェーズTSDU…23 6.5 操業停止--要求を発表してください…24 6.6 操業停止--応答をリリースしてください…25 6.7 アボートを熟考してください…25 6.8プロバイダーアボート…6.9が中止する27は受け入れます…27 7. 参照…27 8. 他の注意…28 9. セキュリティ問題…29 10. 作者のアドレス…29
1. Introduction
1. 序論
The upper-layer protocols of the OSI model are large and complex, mostly because the protocols they describe are rich in function and options. However, for support of most applications, only a limited portion of the function is needed. An implementation that is not intended to be a completely general platform does not need to implement all the features. Further, it need not reflect the structuring of the OSI specifications - the layer of the OSI model are purely abstract.
OSIモデルの上側の層のプロトコルは、大きくて、複雑です、ほとんどそれらが説明するプロトコルは機能とオプションが豊かであるので。 しかしながら、ほとんどのアプリケーションのサポートにおいて、機能の限られた部分だけが必要です。 完全に一般的なプラットホームであることを意図しない実装はすべての特徴を実装する必要はありません。 さらに、OSI仕様の構造を反映する必要はありません--OSIモデルの層は純粋に抽象的です。
This document presents the protocol elements required by the OSI upper layers when supporting a connection-oriented application with only basic communication requirements - that is to create a connection, optionally negotiate the data representation, send/receive data, close a connection and abort a connection. Optionally, data may be sent on the connection establishment, closing and abort messages.
このドキュメントは主文要件接続を創造して、任意にデータ表現を交渉して、データを送るか、または受け取って、接続を終えて、(接続を中止することになっている)だけで接続指向のアプリケーションをサポートするときOSIの上側の層によって必要とされたプロトコル要素を提示します。 任意に、コネクション確立、閉鎖、およびアボートメッセージでデータを送るかもしれません。
In this document, the protocol elements needed are given in terms of the octet sequences that comprise the 'envelope' around the application data. The envelope and its enclosing data form a Transport Service Data Unit (TSDU) that can be passed via the OSI Transport Service [ISO8072] (which in turn may be supported as specified in [RFC1006] or any class of the OSI Transport Protocol [ISO8073]).
本書では、アプリケーションデータの周りで'封筒'を包括する八重奏系列で必要であるプロトコル要素を与えます。 封筒とデータを同封すると、OSI Transport Service[ISO8072](OSI Transportプロトコル[ISO8073]の[RFC1006]かどんなクラスでも指定されるように順番にサポートされるかもしれない)を通して渡すことができるTransport Service Data Unit(TSDU)は形成されます。
Furniss [Page 2] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[2ページ]RFC1698ThinOSI
The octet sequences to be sent and the description of the alternative forms that may be received are equivalent to an informal re- specification of the relevant parts of the upper-layer protocols. The "relevant parts" are determined by the requirements of the supported applications (this is a reflexive definition! - if application Z needs something that is not here, it is not supported). The formal specifications remain the base standards, the appropriate profiles and the requirements of the application. However, an implementation based on this document will be able to interwork with an implementation based directly on the full standards when both are supporting a basic communication application. The "full" implementation will exhibit only part of its potential behaviour, since the application will only invoke part.
送られる八重奏系列と受け取られるかもしれない選択方式の記述は上側の層のプロトコルの関連部分の非公式の再仕様に同等です。 「関連部分」はサポートしているアプリケーションの要件で決定します。(これは再帰の定義です! - アプリケーションZがここにない何かを必要とするなら、それはサポートされません。). 形式仕様はベース規格、適切なプロフィール、およびアプリケーションの要件のままで残っています。 しかしながら、このドキュメントに基づく実装は両方であるときに実装が直接完全な規格に基づいていて織り込むことができるのが、主文アプリケーションをサポートすることであるということでしょう。 アプリケーションが部分を呼び出すだけであるので、「完全な」実装は潜在的ふるまいの一部だけを示すでしょう。
In addition to the octet sequences, the document includes some tutorial material.
八重奏系列に加えて、ドキュメントは何らかの家庭教師の材料を含んでいます。
2. General
2. 一般
2.1 Subdivisions of "basic communication applications"
2.1 「主文アプリケーション」の区画分譲地
Distinctions can be made within the "basic communication applications", as defined above, based on how much use they make of the OSI upper-layer services, and thus how much of the protocol described in this memo will be used to support a particular application. One distinction is:
「主文アプリケーション」の中で区別をすることができます、上で定義されるように、OSI上側の層のサービスでどのくらいの使用をするか、そして、その結果、このメモで説明されたプロトコルのどのくらいが特定用途をサポートするのに使用されるかに基づいて。 1つの区別は以下の通りです。
a) whether application data is sent on the connection
establishment, close and abort, or only during "date phase"
on an established connection; OR
a) アプリケーションデータをコネクション確立に送るか否かに関係なく、閉じてください、中止になるか、または確立した接続の「日付のフェーズ」だけの間閉じてください。 OR
b) whether the application data is of only one kind (abstract
syntax) and one format (transfer syntax) or more than one
(i.e., how much use is made of the Presentation layer syntax
negotiation and identification features)
b) アプリケーションデータは1種類(抽象構文)と1つの形式(転送構文)だけのものであるか、そして、1以上(Presentation層の構文交渉ですなわち、どのくらいの使用をしますか、そして、識別機能)
Further distinctions are possible, but in this memo, elements of protocol needed (or not needed) by four groups of "basic communications application" are identified. All groups have "basic communications requirements" in requiring only connection, data transfer and (perhaps) orderly release of connection. The four groups are:
さらなる区別は可能ですが、このメモでは、「主文アプリケーション」の4つのグループによって必要とされた(または、必要ではありません)プロトコルの原理は特定されます。 すべてのグループが接続の接続だけ、データ転送、および(恐らく)規則的な解放を必要とする際に「主文要件」を持っています。 4つのグループは以下の通りです。
Group I: applications which send data only on an established
connection, and use a single abstract and transfer syntax.
グループI: 確立した接続だけにデータを送って、ただ一つの要約と転送構文を使用するアプリケーション。
Furniss [Page 3] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[3ページ]RFC1698ThinOSI
Group II: applications which send data on connection
establishment and release and use a single abstract and transfer
syntax.
グループII: コネクション確立に関するデータとリリースを送って、ただ一つの要約と転送構文を使用するアプリケーション。
Group III: applications that send data of only one kind (one
abstract syntax) on the connection, but which have more than one
format (transfer syntax) specified (they use the Presentation
context negotiation facility).
グループIII: 1種類だけのデータ(1つの抽象構文)を接続に送りますが、1つ以上の形式(転送構文)を指定する(それらはPresentation文脈交渉施設を使用します)アプリケーション。
Group IV: applications that will send data of several kinds on the
connection (and which much therefore distinguish on each write
which kind is being sent).
グループIV: 接続(したがって、どれがそれぞれで非常に区別されるかが種類が送られるものを書く)の数種類のデータを送るアプリケーション。
Group III applications are equivalent to Group I (or possibly Group II) after the establishment exchange has negotiated the particular transfer syntax that will be used on the connection.
設立交換が接続のときに使用される特定の転送構文を交渉した後にグループIIIアプリケーションはGroup I(または、ことによるとGroup II)に同等です。
Possible examples of the Groups are:
Groupsの可能な例は以下の通りです。
Group I: Application protocols designed for use over transport-
level protocols. Typically these are non-OSI protocols "migrated"
to an OSI environment. X Window System protocol is an example.
グループI: 使用のために設計されたアプリケーション・プロトコルは輸送の上にプロトコルを平らにします。 通常これらは非OSIプロトコルがOSIに「移行した」という環境です。 Xウィンドウシステムプロトコルは例です。
Group II: OSI-originated protocols with simple requirements,
including many of the ROSE-based ones, such as Directory Access
Protocol.
グループII: ディレクトリAccessプロトコルなどのローズベースの1つの多くを含む簡単な要件があるOSIによって溯源されたプロトコル。
Group III: Protocols that can be treated as Group I, but for
which more than one encoding of the data is known, such as a
standardised one and a system-specific one - all implementations
understand the standard encoding, but Presentation layer
negotiation allows like-implementations to use their internal
encoding for transfer, without loss of general interworking. The
same could apply to OSI protocols.
グループIII: データのコード化は知られています、より多くのどれがなければ標準化されたもののようにGroup Iとして扱うことができるプロトコル、およびシステム特有のもの--すべての実装が標準のコード化を理解していますが、Presentation層の交渉は実装が転送に一般のご逝去なしでそれらの内部のコード化を使用するために好きな織り込むことを許すか。 OSIプロトコルに同じくらい適用できました。
Group IV: OSI protocols with multiple abstract syntaxes (but with
each individual message from a single abstract syntax) that do
not use any of the special Session functional units - X.400 P7 is
an example.
グループIV: 特別なSession機能的なユニットのいずれも使用しない複数の抽象構文(しかしただ一つの抽象構文からのそれぞれの個々のメッセージで)があるOSIプロトコル--X.400 P7は例です。
Some of the OSI protocols that are not included are those that use more than one abstract syntax in a single message (such as FTAM or Transaction Processing) or use Session functional units (RTSE-based protocols, Virtual Terminal).
含まれていないOSIプロトコルのいくつかがただ一つのメッセージ(FTAMかTransaction Processingなどの)の1つ以上の抽象構文を使用するか、またはSessionの機能的なユニット(RTSEベースのプロトコル、Virtual Terminal)を使用するものです。
Furniss [Page 4] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[4ページ]RFC1698ThinOSI
2.2 Conformance and interworking
2.2 順応と織り込むこと
The protocol elements specified in this memo correspond to the kernel functional units of Session, Presentation and ACSE, and the duplex functional unit of Session.
このメモで指定されたプロトコル要素はSessionのSession、Presentation、ACSE、および重複の機能的なユニットのカーネルの機能的な単位に対応しています。
The octet sequences given below are derived from the specifications in the International Standards for the protocols Session [ISO8327], Presentation [ISO8822] and ACSE [ISO8650]. The intention of this memo is to summarise those specifications, as applicable to the supported application groups, so that an implementation could be developed without direct reference to the original standards, but capable of interworking with implementations that had made direct reference. The OSI standards (especially Presentation) allow considerable flexibility in the encoding of the protocol data units. Accordingly, this memo defines particular octet sequences to be sent, and describes the variations that can be expected in data received from an implementation based directly on the OSI standards, rather than on this cookbook. It is intended that an implementation that sends these sequences and that is capable of interpreting the variations described will be fully able to interwork with an implementation based directly on the OSI standards. An implementation that is only capable of interpreting the octet sequences specified in this memo for transmission may not be able to interwork with standards-based implementations.
プロトコルのSession[ISO8327]、Presentation[ISO8822]、およびACSE[ISO8650]のために国際Standardsの仕様から以下に与えられた八重奏系列を得ます。 このメモの意志はそれらの仕様について略言することです、実装が開発されますが、元の規格の直接的な言及なしで直接的な言及をした実装をもって織り込むことができるかもしれなくてサポートしている応用グループに適切であるとして。 OSI規格(特にPresentation)はプロトコルデータ単位のコード化におけるかなりの柔軟性を許容します。 それに従って、このメモは、送られる特定の八重奏系列を定義して、この料理の本でというよりむしろ直接OSI規格に基づく実装から受け取られたデータで予想できる変化について説明します。 これらの系列とそれを送る実装が実装が直接OSI規格に基づいていて説明された変化が完全に織り込むことができる解釈できることを意図します。 トランスミッションのためのこのメモで指定された八重奏系列が規格ベースの実装で織り込むことができないかもしれない解釈できるだけである実装。
The intent is to be able to interwork with conformant implementations in support of the relevant application (or group of applications). Some of the OSI standards have conformance requirements that go beyond that necessary for successful interworking, including detection of invalid protocol. Tests for conformance sometimes go beyond the strict conformance requirements of the standard. Consequently an implementation based on this memo may or may not be able to formally claim conformance to the International Standard. It may be able to legitimately claim conformance, but fail a conformance test, if the test is over-specified. (Efforts are being made to correct this, but in the meantime, the target is interworking with conformant implementations.)
意図はconformant実装で関連を支持してアプリケーションを織り込む(または、アプリケーションのグループ)ことであることができます。 OSI規格のいくつかには、それで必要になる順応要件がうまくいっている織り込むためにあります、無効のプロトコルの検出を含んでいて。 順応のためのテストは時々規格の厳しい順応要件を越えます。 その結果、このメモに基づく実装は正式に国際規格に順応を要求できるかもしれません。 テストが指定され過ぎているなら順応テストに失敗するのを除いて、それは合法的に順応を要求できるかもしれません。 (取り組みはこれを修正させられますが、差し当たり目標はconformant実装をもって織り込むことです。)
2.3 Relationship to other documents
2.3 他のドキュメントとの関係
The flexibility allowed in the Session, Presentation and ACSE standards is restricted in the Common Upper-Layer Requirements Part 1 [CULR-1]). This is a proposed International Standardised Profile (pdISP 11188-1) that can be assumed to be obeyed by most implementations. This memo applies the restrictions of CULR-1, especially where these concern maximum sizes of fields and the like.Points where advantage is taken of a CULR-1 limitation are
Session、Presentation、およびACSE規格で許容された柔軟性はRequirements Part1[CULR-1)Common Upper-層の中で制限されます。 これはほとんどの実装によって従われると思うことができる提案された国際Standardised Profile(pdISP11188-1)です。 このメモはCULR-1の制限を当てはまります、特にこれらが、分野のサイズと利点が活用されるCULR-1制限のthe like.Pointsがそうであることが最大に関係があるところで
Furniss [Page 5] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[5ページ]RFC1698ThinOSI
noted.
有名。
Additional parts of CULR are under development. Part 3 [CULR-3] covers the protocol elements needed for "basic communications applications", and is being developed in (informal) liaison with this memo. CULR-3 is presented as a normal profile, largely consisting of prescribed answers to the questions in the PICS (Protocol Implementation Conformance Statement) of the three protocols. CULR-3 does not make the distinction between the four Groups. An implementation of this memo (at least if it supported Group IV) would be able to claim conformance to CULR-3, with the possible exception of any more-than-interworking conformance requirements inherited by CULR-3 from the base standards.
CULRの追加部分は開発中です。 パート3[CULR-3]は、「主文アプリケーション」に必要であるプロトコル要素をカバーしていて、このメモとの(非公式)の連絡で発生しています。 正常なプロフィールとしてCULR-3を寄贈します、主に3つのプロトコルのPICS(プロトコルImplementation Conformance Statement)での質問の処方された答えから成って。 CULR-3は4の区別をGroupsにしません。 このメモの実装、(Groupをサポートするなら、少なくとも、IV)はCULR-3に順応を要求できるでしょうに、織り込むよりもっと多くのもの順応要件の可能な例外がCULR-3によってベース規格から引き継がれている状態で。
An extension [XTI/mOSI] to the X/Open Transport Interface [XTI] is shortly to be published as a preliminary specification. This defines an API to the OSI upper-layers, again as appropriate to a basic communications application. XTI/mOSI would be usable as an interface to support applications in groups I, II and III, and possibly group IV.
X/Open Transport Interface[XTI]への拡大[XTI/mOSI]はすぐ予備の仕様として発行されることです。 これは上側の同じくらい層の、そして、主文アプリケーションに再び同じくらい適切なOSIとAPIを定義します。 XTI/mOSIは、グループにおけるアプリケーションが私と、IIと、IIIと、ことによるとグループIVであるとサポートするためにインタフェースとして使用可能でしょう。
3. Contexts and titles
3. 文脈とタイトル
3.1 The concepts of abstract and transfer syntax
3.1 要約と転送構文の概念
OSI includes the concepts of "abstract syntax" and "transfer syntax". These are terms for the content (abstract syntax) and format "on- the-line" (transfer syntax) of the protocol elements. The combination of an abstract syntax and transfer syntax is called a presentation context.
OSIは「抽象構文」と「転送構文」の概念を含んでいます。 これらが内容(抽象構文)と形式のための用語である、「オンである、-立ち並んでください、」 プロトコル要素の(転送構文。) 抽象構文と転送構文の組み合わせはプレゼンテーション文脈と呼ばれます。
Application protocols devised explicitly under OSI auspices have used ASN.1 for the definition of the abstract syntax, and nearly all use the Basic Encoding Rules applied to the ASN.1 to define the transfer syntax. However, there is no such requirement in OSI in general or in OSI Presentation, and still less is there any requirement to change the representation of existing application protocols to ASN.1 (for their definition) or BER (for their transmission). It is not generally realised (even in OSI circles) that all communicating applications, in all environments, are using some form of these, although under different names and without the explicit identification that the OSI Presentation provides. OSI separates the identification of the content and format of the data from the addressing.
明らかにOSI前兆で工夫されたアプリケーション・プロトコルは抽象構文の定義にASN.1を使用しました、そして、ほとんどすべてが転送構文を定義するのにASN.1に適用されたBasic Encoding Rulesを使用します。 しかしながら、どんなそのような要件も一般に、OSIにないか、または既存のアプリケーション・プロトコルの表現をASN.1(彼らの定義のための)かBER(彼らのトランスミッションのための)に変えるというどんな要件もそこにOSI Presentation、およびそれでも、以下に、あります。 一般に、すべて交信しているアプリケーションがすべての環境で何らかのフォームのこれらを使用しているとわかりません(OSI円の形でさえ)、明白な識別異なった名前と、そして、なしでOSI Presentationが提供する。 OSIはアドレシングと内容の識別とデータの形式を切り離します。
Formal specifications of non-OSI application protocols (such as TELNET, FTP, X Windows System) generally do not use ASN.1, but will invariably be found to define abstract and transfer syntaxes. For a
非OSIアプリケーション・プロトコル(TELNET、FTP、X-windows Systemなどの)に関する形式仕様は、一般にASN.1を使用しませんが、要約と転送構文を定義するのが不変的にわかるでしょう。 aのために
Furniss [Page 6] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[6ページ]RFC1698ThinOSI
less formalised protocol used between similar systems, the abstract syntax may be defined simply in programming language structures, and the transfer syntax determined by how some compiler represents this in memory.
同様のシステムの間で使用される、より少ない正式にされたプロトコル、抽象構文は単に何らかのコンパイラがメモリにどうこれを表すかによって決定しているプログラミング言語構造、および転送構文で定義されるかもしれません。
The OSI Presentation protocol requires that "names" be assigned to
the abstract and transfer syntaxes of the application data that is
carried. The names are always object identifiers ("oid"): globally
unique names assigned hierarchically. Presentation supports the
negotiation of a transfer syntax for a particular abstract syntax -
several can be offered and one selected.
OSI Presentationプロトコルは、「名前」が運ばれるアプリケーションデータの要約と転送構文に割り当てられるのを必要とします。 いつも名前はオブジェクト識別子("oid")です: 階層的に割り当てられたグローバルにユニークな名前。 提供してください。プレゼンテーションは特定の抽象構文のために転送構文の交渉をサポートします--数個がそうすることができる、そして、選択されたもの。
This transfer syntax negotiation facility may be especially useful for non-ASN.1 syntaxes where there is more than one representation available (perhaps differing in byte-ordering or character code). In such a case, on the connection establishment, all of the transfer syntaxes supported by the initiator are offered, and any one of these accepted by the responder, at its own choice. If the two systems share some "native" format they can negotiate that, avoiding transformation into and out of a more general format that is used for interworking with unlike systems. The same applies to an ASN.1- defined abstract syntax, but in practice non-BER encodings of ASN.1 are rare.
この転送構文交渉施設は特に利用可能な1つ以上の表現がある(恐らくバイト順かキャラクタコードにおいて異なって)非ASN.1の構文の役に立つかもしれません。 このような場合には、コネクション確立に対しては創始者によってサポートされた転送構文のすべてを提供しました、そして、これらのどれかは応答者で受け入れました、それ自身の選択で。 システムが. 同じくらいが構文の、しかし、実際には非BER encodingsのASN.1によって定義された要約に適用するASN.1のシステムと異なって形式の中と、そして、織り込むのに使用されるより一般的な形式の外へからそれを交渉して、変換を避けて、それらがそうすることができる何らかの「ネイティブ」の形式を共有する2がまれであるなら。
3.2 Use of presentation context by cookbook applications
3.2 プレゼンテーション文脈の料理の本アプリケーションによる使用
An application protocol not originally specified with OSI Presentation in mind (a "migrant" protocol) will not normally need to identify the abstract and transfer syntaxes being used - they are known by some other means (effectively inferred from the addressing). A generic (anonymous, if you like) name for both syntaxes can be used and [CULR-3] defines object identifiers for "anonymous" abstract and transfer syntax names (currently called "default", but this is expected to change).
通常、元々OSI Presentationと共に念頭で指定されなかったアプリケーション・プロトコル(「移住性」のプロトコル)は要約と使用される転送構文を特定する必要はないでしょう--それらはある他の手段(事実上、アドレシングから推論される)によって知られています。 両方の構文のためのジェネリック(よければ匿名の)名を使用できます、そして、[CULR-3]は「匿名」の要約と転送構文名のためのオブジェクト識別子を定義します(「デフォルト」が現在、呼びましたが、これが変化すると予想されます)。
In some cases object identifier names will be assigned for the syntaxes of a migrant application protocol. If these exist, they should be used. However, since the processing required will be the same, it will be legitimate to offer both the generic and specific names, with the responder accepting the specific (if it knew it) and the generic if the specific were not known - this will provide a migration option if names are assigned to the syntaxes after implementations are deployed using the generic names.
いくつかの場合、オブジェクト識別子名は移住性のアプリケーション・プロトコルの構文のために割り当てられるでしょう。 これらが存在しているなら、それらは使用されるべきです。 しかしながら、必要である処理が同じになるので、ジェネリックと種名の両方を提供するのは正統でしょう、知られていて特定がないなら特定を受け入れる(それを知っていたなら)応答者とジェネリックで--実装が総称を使用することで配布された後に名前が構文に割り当てられると、これは移行オプションを提供するでしょう。
For abstract syntaxes defined in ASN.1 object identifier names will have been assigned to the abstract syntax with the specification. This name MUST be used to identify the abstract syntax. The transfer syntax will most often be the Basic Encoding Rules (BER) object id,
ASN.1で定義された抽象構文において、オブジェクト識別子名は抽象構文に仕様で割り当てられてしまうでしょう。 抽象構文を特定するのにこの名前を使用しなければなりません。 転送構文はたいていBasic Encoding Rules(BER)オブジェクトイドになるでしょう。
Furniss [Page 7] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[7ページ]RFC1698ThinOSI
but alternatives (e.g., Packed Encoding Rules) are possible.
しかし、代替手段(例えば、Packed Encoding Rules)は可能です。
For group III and group IV applications, specific object identifier names must be used for all the abstract and transfer syntaxes. If these names are not assigned with the specification (e.g., if the specification not in ASN.1) they can be assigned by whoever needs them - ideally the "owner" of the syntax specification.
グループIIIとグループIVアプリケーションにおいて、すべての要約と転送構文に特定のオブジェクト識別子名を使用しなければなりません。 これらの名前が仕様で割り当てられないなら(例えば、ASN.1でないところの仕様であるなら)、それらを必要とする人なら誰でもそれらを割り当てることができます--理想的に構文仕様の「所有者。」
3.3 Processing Presentation-context-definition-list
3.3 処理プレゼンテーション文脈定義リスト
In Presentation context negotiation on connection establishment the initiator sends a list (the presentation context definition list) of the abstract syntaxes it intends to use, each with a list of transfer syntaxes. Each presentation context also has an integer identifier. To build the reply, a responder has to examine this list and work out which of the offered presentation contexts will be accepted and which (single) transfer syntax for each. The responder sends back the reply field, the Presentation-context-definition-result-list, in the accept message. The result list contains the same number of result items as the definition-list proposed presentation-contexts. They are matched by position, not by the identifiers (which are not present in the result- list). An acceptance also includes the transfer syntax accepted (as there can be several offered). This can be copied from the definition list.
コネクション確立のPresentation文脈交渉では、創始者はそれが使用するつもりである抽象構文のリスト(プレゼンテーション文脈定義リスト)を送ります、それぞれ転送構文のリストで。 また、それぞれのプレゼンテーション文脈には、整数識別子があります。 応答者は、回答を組み込むために、このリストを調べて、それぞれのために提供されたプレゼンテーション文脈のどれを受け入れるだろうか、そして、どの(単一)の転送構文を考え出さなければならないか。 応答者が回答分野、Presentation文脈定義結果リストを中に返送する、メッセージを受け入れてください。 定義リストがプレゼンテーション文脈を提案したので、結果リストは同じ数の結果項目を入れてあます。 それらは識別子ではなく、位置によって合われています(結果リストに存在していません)。 また、承認は受け入れられた転送構文を含んでいます(提供された数個があることができるので)。 定義リストからこれをコピーできます。
For the group I, group II and group III cases, only the ACSE and one application-data P-context will be used and all other contexts rejected. For the group IV case, several presentation contexts will be accepted.
私、グループII、グループIIIケース、ACSEだけ、および1つのアプリケーションデータP-文脈がグループにおける、中古で他の文脈に拒絶されたなるでしょう。 グループIVケースにおいて、いくつかのプレゼンテーション文脈を受け入れるでしょう。
However, even for group I applications there may be synonyms for an application-data Presentation-context. Unknown synonyms are rejected. The reply shown in 6.2 includes a rejection (It can therefore not be the reply to the connection request shown in 6.1, since that has only two items in the definition list.)
しかしながら、グループIアプリケーションのためにさえ、アプリケーションデータPresentation-文脈のための同義語があるかもしれません。 未知の同義語は拒絶されます。 6.2で示された回答は拒絶を含んでいます。(したがって、それは6.1で示された接続要求に関する回答であるはずがありません、それが定義リストに2つの項目しか持っていないので。)
In all cases, the connection responder must identify and keep the presentation context identifiers (called pcid's here) for all the accepted presentation contexts. These are integers (odd integers, in this case). CULR-1 limits them to no greater than 32767, but they will usually be <= 255 (so taking up one octet).
すべての場合では、接続応答者は、すべての受け入れられたプレゼンテーション文脈のためにプレゼンテーション文脈が識別子であることを特定して、保たなければなりません(ここにpcidのものと呼ばれます)。 これらは整数(この場合、変な整数)です。 CULR-1はそれらを32767以下に制限しますが、通常、それらは<=にな255るでしょう(したがって、1つの八重奏を始めます)。
A presentation context is sometimes used (i.e., data is sent using it) before the negotiation is complete. As will be seen in section 6, in these cases, the transfer syntax name sometimes appears with the integer identifier.
交渉が完全になる前にプレゼンテーション文脈は時々使用されます(すなわち、データにそれを使用させます)。 セクション6で見られるこれらの場合では、転送構文名は整数識別子と共に時々現れます。
Furniss [Page 8] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[8ページ]RFC1698ThinOSI
3.4 Application context
3.4 アプリケーション文脈
The Association Control Service Element also exchanges the name (another Object Identifier) of the application context, which identifies what the communication is all about, again independently of the naming and addressing. As for the syntaxes, although some name must be present in the protocol, a generic name can be used for applications that do not have a specific name assigned. (This will almost certainly be a group I application - if a specific name is assigned, it must be used.) The only negotiation allowed is that the reply may be different from that sent by the initiator. CULR-3 provides a generic application context name (i.e., assigns an object identifier).
また、アソシエーション制御サービス要素はコミュニケーションが何に関するすべてであるかを特定するアプリケーション文脈の名前(別のObject Identifier)を交換します、再び命名とアドレシングの如何にかかわらず。 構文に関して、何らかの名前がプロトコルで存在していなければなりませんが、種名を割り当てないアプリケーションに総称を使用できます。 (これはほぼ確実にグループIアプリケーションになるでしょう--種名が割り当てられるなら、それを使用しなければなりません。) 許された唯一の交渉は回答が創始者によって送られたそれと異なるかもしれないということです。 CULR-3は一般的適用文脈名(すなわち、オブジェクト識別子を割り当てる)を提供します。
3.5 APtitles and AEqualifiers
3.5 APtitlesとAEqualifiers
In addition to the addressing constructs (transport address and possibly session and presentation selectors), the communicating application entities have names - Application-Entity titles (AEtitle). These are carried by ACSE as two fields -the Application-process titles (APtitle) and the Application-entity qualifier (AEqualifier). The AEtitle is compound, and the APtitle consists of all but the last element, which is the AEqualifier. (This explanation can be run backwards). There are two non-equivalent forms. AP-titles and AE-titles can be Directory Name or an Object Identifier. AE-qualifiers can be Relative Distinguished Name (RDN) or an integer - the forms must match, since the AE-qualifier is the last component of the AP-title. In practice, the Directory form is likely to be the only one seen for a while.
アドレシング構造物(輸送アドレス、ことによるとセッション、およびプレゼンテーションセレクタ)に加えて、交信しているアプリケーション実体には、名前があります--アプリケーション実体タイトル(AEtitle)。 これらが2つの分野としてACSEによって運ばれる、-、Application-プロセスタイトル(APtitle)とApplication-実体資格を与える人(AEqualifier。) AEtitleは化合物です、そして、APtitleは最後の要素以外のすべてから成ります。要素はAEqualifierです。 (後方にこの説明を実行できます。) 2つの非同等なフォームがあります。AP-タイトルとAE-タイトルは、ディレクトリNameかObject Identifierであるかもしれません。 AE-資格を与える人は、Relative Distinguished Name(RDN)か整数であるかもしれません--フォームは合わなければなりません、AE-資格を与える人がAP-タイトルの最後の成分であるので。 実際には、ディレクトリフォームはしばらく見られた唯一無二である傾向があります。
Use of the these names is rather variable. This cookbook proposes that implementations should be able to handle any value for the partner's names, and set (as initiator) its own names. This is primarily to facilitate OSI:non-OSI relaying (e.g., X/osi:X/tcp), allowing the names of the end-system to be carried to the relay, where they can be converted into hostnames, and the lower-layer address determined. OSI assumes that name-to-address lookup is possible (via the Directory or other means), but does not assume address-to-name will work. Thus the calling AE-title is needed if the responder is to know who the initiator is. However, most protocols work perfectly well without these names being included.
使用、これらの名前はかなり可変です。 この料理の本は、実装がパートナーの名前のためにどんな値も扱って、それ自身の名前を設定できるべきである(創始者として)よう提案します。 これは主としてOSI: 非OSIリレー(例えば、X/osi: X/tcp)を容易にするためのものです、エンドシステムの名前がリレー、およびアドレスが決定した下層まで運ばれるのを許容して。そこでは、それらをホスト名に変換できます。 OSIは、名前からアドレスへのルックアップが可能であると(ディレクトリか他の手段を通した)仮定しますが、命名するアドレスが働くと仮定しません。 したがって、応答者が、創始者がだれであるかを知るつもりであるなら、呼ぶAE-タイトルが必要です。 しかしながら、含まれていて、ほとんどのプロトコルがこれらの名前なしで完全にうまくいきます。
As for their encoding, a RDN will almost always be a single attribute value assertion, with the attribute defined either by the Directory standard [ISO9594 = X.500], or in [Internet/Cosine Schema] [RFC1274]. Using the notation defined below, the encoding of an RDN using a Directory-defined standard attribute is:
それらのコード化に関して、RDNはほとんどいつもただ一つの属性値主張になるでしょう、ディレクトリ規格[ISO9594はX.500と等しい]、または[インターネット/コサインSchema]で定義された属性[RFC1274]で。 以下で定義された記法を使用して、ディレクトリで定義された標準の属性を使用するRDNのコード化は以下の通りです。
Furniss [Page 9] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[9ページ]RFC1698ThinOSI
31 80 {1 - RDN, [SET OF]
30 80 {2 - AttributeValueAssertion, [SEQUENCE]
06 03 5504yy -- OID identifying an attribute named in
-- the Directory standard
-- which one is determined by yy
13 La xxxxxx -- [Printable string]
-- could be T61 string, with tag 14
00 00 }2 - end of AVA
00 00 }1 - end of RDN
31 80、1--、RDN、[SET OF]30 80、2--AttributeValueAssertion、[SEQUENCE] 06 03 5504yy--中で指定された属性を特定するOID--ディレクトリ規格(断固としている)は13La xxxxxxをyyします--[印刷可能なストリング]--タグ14 00 00があるT61ストリングであるかもしれません}という2--AVA00 00の端、1--RDNを終わらせてください。
The most likely attributes for an RDN have the following hex values for yy.
RDNのための最もありそうな属性に、yyのための以下の十六進法値があります。
CommonName 03
Country 06
Locality 07
State/Province 08
Organisation 0A
OrganisationUnit 0B
CommonName03国の06場所07州/県08の機�%%BODY%%A OrganisationUnit 0B
For non-Directory attributes, the object id name must be substituted (thus changing the immediately preceding length)
非ディレクトリ属性において、オブジェクトイド名を代入しなければなりません。(その結果、すぐに前の長さを変えます)
If there are multiple attribute value assertions in the RDN, the
group between {2 and 2} is repeated (with different attributes).
Order is not significant.
複数の属性値主張がRDNにあれば、2と2の間のグループは繰り返されます(異なった属性で)。 オーダーは重要ではありません。
The encoding of a [Directory] Name for the AP-titles is the RDNs (high- order first) within
AP-タイトルのための[ディレクトリ]名のコード化は中のRDNs(高値は最初に、注文される)です。
30 80 {1 - [SEQUENCE] Name
-- put the RDN encodings here
00 00 }1
30 80、1([SEQUENCE]名)がここにRDN encodingsを置く、00 00、1
An Object Identifier AP-title is encoded as a primitive (see below), with the "universal" tag for an object identifier, which is 6. The integer AE-qualifier uses the universal tag for an integer, which is 2.
Object Identifier AP-タイトルは基関数としてコード化されます(以下を見てください)、オブジェクト識別子のための「普遍的な」タグで。(識別子は6です)。 整数AE-資格を与える人は整数に普遍的なタグを使用します。(それは、2です)。
4. What has to be sent and received
4. 送られて、受け取られなければならないもの
4.1 Sequence of OSI protocol data units used
4.1 ユニットが使用したOSIプロトコルデータの系列
OSI defines its facilities in terms of services but these are abstract constructs (they do not have to correspond to procedure calls) - the significant thing is the transmission of the resulting protocol data unit (PDU). The PDU at each layer carries (as user data) the PDU of the layer above. The different layers follow
これらは抽象的な構造物(それらは手順呼び出しに相当する必要はない)です--OSIはサービスで施設を定義しますが、重要なものは結果として起こるプロトコルデータ単位(PDU)のトランスミッションです。 各層のPDUは上の層のPDUを運びます(利用者データとして)。 異なった層は続きます。
Furniss [Page 10] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[10ページ]RFC1698ThinOSI
different conventions for naming the pdus. This section gives an overview of the sequence of PDUs exchanged - the details of these are given in section 6.
pdusを命名するための異なったコンベンション。 このセクションは交換されたPDUsの系列の概要を与えます--これらの詳細はセクション6で明らかにされます。
The requirements of the application are to create a connection (strictly an association for the application-layer in OSI, but called a connection here), to send and receive data and to close the connection. The PDUs used are thus:
アプリケーションの要件が接続を創造することである、(厳密である、ここでのOSIの、しかし、呼ばれたa接続における応用層のための協会)、データを送って、受け取って、接続を終えるために。 その結果、使用されるPDUsは以下の通りです。
To create connection:
接続を創造するために:
First create transport-level connection
まず最初に、輸送レベル接続を創造してください。
Initiator sends the message defined in 6.1, which is Session
CONNECT carrying Presentation CONNECT request [CP] carrying
ACSE A-ASSOCIATE request [AARQ] optionally carrying application
data.
創始者は6.1で定義されたメッセージを送ります。(それは、任意にアプリケーションデータを運びながらACSE A-ASSOCIATEが要求するPresentation CONNECT要求[CP]携帯[AARQ]を運ぶSession CONNECTです)。
Responder replies with the message defined in 6.2, which is
Session ACCEPT carrying Presentation CONNECT response [CPA]
carrying ACSE response [AARE] optionally carrying application
data.
応答者は6.2で定義されたメッセージで返答します。(それは、任意にアプリケーションデータを運びながらACSE応答[アーレ]を運びながらPresentation CONNECT応答[CPA]を運ぶSession ACCEPTです)。
- If the responder rejects the attempt, the reply will be Session
REJECT. This is defined in 6.3, where the REJECT carries no
user data. A received REJECT may carry Presentation, ACSE and
application data, although 6.3 shows only how to reject at
Session level..
- 応答者が試みを拒絶すると、回答はSession REJECTになるでしょう。 これは6.3で定義されます。そこでは、REJECTが利用者データを全く運びません。 6.3はSessionレベルに廃棄物へのその方法だけを示していますが、容認されたREJECTはPresentation、ACSE、およびアプリケーションデータを運ぶかもしれません。
To send/receive data on an connection
接続に関するデータを送るか、または受け取るために
send the message defined in 6.4, which is an empty Session
GIVE-TOKEN followed by Session S-DATA carrying Presentation P-
DATA [TD] containing the application data (The GIVE-TOKEN is
just two octets required by Session for some backwards
compatibility.)
空のSession GIVE-TOKENであるとアプリケーションデータを含んでいて、Presentation P- DATA[TD]を運ぶSession S-DATAによっていうことになられた6.4で定義されたメッセージを送ってください。(GIVE-TOKENは何らかの遅れている互換性のためにSessionによって必要とされたちょうど2つの八重奏です。)
To close connection gracefully
優雅に接続を終えるために
One side sends the message defined in 6.5, which is Session
FINISH carrying P-RELEASE request carrying A-RELEASE request
[RLRQ] optionally carrying application data (This side may now
receive, but not send data.)
半面は6.5で定義されたメッセージを送ります。(それは、任意にアプリケーションデータを運びながらA-RELEASEが要求するP-RELEASE要求携帯[RLRQ]を運ぶSession FINISHです)。(手前は、現在受信しますが、データを送らないかもしれません。)
The other side replies with the message defined in 6.6, which
is Session DISCONNECT carrying P-RELEASE response carrying A-
RELEASE response [RLRE] optionally carrying application data
メッセージがある回答が6.6で定義した反対側。(その反対側は任意にアプリケーションデータを運びながらA RELEASE応答[RLRE]を運びながらP-RELEASE応答を運ぶSession DISCONNECTです)。
Furniss [Page 11] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[11ページ]RFC1698ThinOSI
First side disconnects transport connection on receiving the
reply
表版は回答を受け取るときの輸送接続から切断します。
To close connection abruptly but also send application data
突然に接続を終えますが、アプリケーションデータをまた送るために
Send the message defined in 6.7, which is Session ABORT
carrying Presentation U-ABORT [ARU] carry ACSE U-ABORT [ABRT]
carrying application data (delivery not guaranteed)
6.7で定義されたメッセージを送ってください。(それは、Presentation U-ABORT[ARU]を運ぶSession ABORTがアプリケーションデータを運びながらACSE U-ABORT[ABRT]を運ぶということです)。(保証されなかった配送)
On receiving Session ABORT, disconnect transport
Session ABORTを受けたら、輸送から切断してください。
To close connection abruptly
突然に接続を終えるために
- Either send the message defined in 6.8, which is Session ABORT
carrying nothing;
- どちらかが6.8で定義されたメッセージを送ります。(それは、何も運ばないSession ABORTです)。
Or, just disconnect at transport level
または、輸送レベルでただ切断してください。
A group I application is assumed (by definition) not to send data on the establishment and release exchanges, a group II application will.
アプリケーションがデータを設立に送らないと思われる(定義上)グループIとリリース交換、グループIIアプリケーションは望んでいます。
It would be possible to use the abort-with-data facility with a group I to send a (possibly non-standardised) error message for diagnostic purposes.
診断目的で(ことによると非標準化される)のエラーメッセージを送るのにグループIのデータがあるアボート能力を使用するのは可能でしょう。
A special rule is used if a release collision occurs (i.e., FINISH+P- RELEASE+RLRQ received after sending the same): the side that initiated the original upper-layer connection waits and the other side replies with the DISCONNECT etc.
リリース衝突が起こるなら(すなわち、FINISH+P-RELEASE+RLRQは同じように発信した後に、受信しました)、特別な規則は使用されています: オリジナルの上側の層の接続を開始した側は待っています、そして、反対側はDISCONNECTなどで返答します。
4.2 Which OSI fields are used
OSIがさばく4.2は使用されています。
There are a number of fields (parameters) in the pdus involved. These can be categorised by what is needed to support applications (of a particular Group) in general - a field may be "useful", "send-only", "fixed", "fixed with default", "internal" or "not important". Even those that are not important may be received from another implementation, but since the application has no use for them, they can be ignored. If an implementation is intended to support only a particular application, it may be able to downgrade the "useful" to "not important".
pdusの(パラメタ)がかかわった多くの分野があります。 一般に、アプリケーション(特定のGroupの)を支持するのに必要であるものはこれらを分類できます--分野が「役に立つかもしれない」、「発信、-単に、」 「修理される」、「デフォルトで修理される」、「内部」または「重要ではありません」。 別の実現から重要でないものさえ受け取るかもしれませんが、それらがアプリケーションがいらないので、それらを無視できます。 実現が特定用途だけを支持することを意図するなら、「役に立つこと」を「重要でなく」格下げしないことができないかもしれません。
The text below describes the processing that is required for each category and which fields are in each category.
以下のテキストは各カテゴリに必要であり、それの分野が各カテゴリにある処理について説明します。
"Useful" - when sending, an implementation of general use should be able to set any (legal) value of these fields (via the upper interface from the application or via some configuration or lookup
アプリケーションからの上側のインタフェースを通して、または、何らかの構成かルックアップを通して「役に立つ」、--、発信するとき、一般的使用の実現がこれらの分野のどんな(法的)の値も設定できるべきである(。
Furniss [Page 12] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[12ページ]RFC1698ThinOSI
mechanism) and SHOULD pass received values for the Calling values to the application (for specific applications, these fields may be either required or unnecessary.)
メカニズム)、SHOULDはCalling値のために容認された値をアプリケーションに通過します。(特定のアプリケーションにおいて、これらの分野は、必要であるか、または不要であるかもしれません。)
AARQ:
AARQ:
Called application-process title
Called application-entity qualifier
Calling application-process title
Calling application-entity qualifier
アプリケーション・プロセスタイトルCalledアプリケーション実体資格を与える人Callingアプリケーション・プロセスタイトルCallingアプリケーション実体資格を与える人と呼ばれます。
"Send-only" - to interwork, the implementation must be able to set any value of these, but can ignore any received value. Both are octet strings.
「発信、-単に、」 --織り込むために無視する、実現は、これらのどんな値も設定できなければなりませんが、どんな容認された値も無視できます。 両方が八重奏ストリングです。
Presentation selector (up to 4 octets, limited by CULR-1)
Session selector (up to 16 octets, limited by base standard)
プレゼンテーションセレクタ(CULR-1によって制限された最大4つの八重奏)セッションセレクタ(最大16の八重奏ベース規格によって制限されて、
"Fixed" (constant for all applications)
「修理されます」。(すべてのアプリケーションに一定)です。
abstract and transfer syntax identifiers for presentation context
for ACSE Version numbers - 2 for session, 1 for Presentation
and ACSE
ACSEバージョン番号のためのプレゼンテーション文脈のための要約と転送構文識別子--セッションのための2、Presentationのための1、およびACSE
"Fixed with default" - the value is specific to the application. For non-ASN.1 abstract syntaxes (group I or group II only) applications, the anonymous values assigned by the OIW minimal OSI profile [CULR-3] can be used. The CULR-3 default application context can be used where a proper context name is neither available nor needed.
「デフォルトで、修理されていました」--値はアプリケーションに特定です。 非ASN.1の抽象構文(グループIかグループII専用)アプリケーションのために、OIWの最小量のOSIプロフィール[CULR-3]によって割り当てられた匿名の値は使用できます。 適切な文脈名は入手できないでまた必要でないところでCULR-3デフォルトアプリケーション文脈を使用できます。
Application context
CULR-3 default is {1 0 11188 3 3}
Abstract syntax identifier for application data
CULR-3 anonymous name is {1 0 11188 3 1 1}
Transfer syntax identifier for application data
CULR-3 anonymous name is {1 0 11188 3 2 1}
アプリケーション文脈CULR-3デフォルトがそうである、1 0、11188、3 3、アプリケーションデータのCULR-3の匿名の名のための抽象構文識別子がそうである、1 0、11188、3 1 1、アプリケーションデータのCULR-3の匿名の名のための転送構文識別子はそうです。{1 0 11188 3 2 1}
"Internal" - an arbitrary value can be sent; a received value must be stored for use in sending.
「内部」--任意の値を送ることができます。 発信における使用のために容認された値を格納しなければなりません。
Presentation context identifiers for ACSE and the application
data (always odd integers)
ACSEのためのプレゼンテーション文脈識別子とアプリケーションデータ(いつも変な整数)
"Not important" - for interworking, any legal received value for the other fields must be received (i.e., the pdu is parsed successfully), but can then be ignored. There is no requirement (in this cookbook) to check the existence, value or internal format of these fields.
織り込むには「重要ではありません」、他の分野へのどんな法的な容認された値も受け取らなければなりませんが(すなわち、pduは首尾よく分析されます)、そして、無視できます。 これらの分野の存在、値または内部の形式をチェックするという要件(この料理の本の)が全くありません。
Furniss [Page 13] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[13ページ]RFC1698ThinOSI
All other fields (which includes a large number of session
fields)
他のすべての分野(多くのセッション分野を含んでいます)
4.3 Encoding methods and length fields
4.3 方法と長さの分野をコード化すること。
Both Session and ASN.1/BER [ISO8824, ISO8825] use a type-length-value structure for their encodings, but different ones. Presentation protocol and ACSE protocol use the ASN.1/BER encoding and consequently a Presentation PDU containing an ACSE PDU can be constructed or parsed as if it were a single structure.
SessionとASN.1/BER[ISO8824、ISO8825]の両方がそれらのencodingsの、しかし、異なったものにタイプ長さの価値構造を使用します。 プレゼンテーションプロトコルとACSEプロトコルがASN.1/BERコード化を使用して、その結果、まるでそれがただ一つの構造であるかのようにACSE PDUを含むPresentation PDUは組み立てるか、または分析できます。
All the protocols contain pdu fields with a compound structure. If one of these is being ignored it may be necessary (for BER, not session) to determine the lengths of its components to find the length of the ignored field.
すべてのプロトコルが合成構造があるpdu分野を含んでいます。 これらの1つが無視されているなら、無視された分野の長さを見つけるためにコンポーネントの長さを測定するのが必要であるかもしれません(セッションではなく、BERのための)。
Many of the lengths in the specification below will vary, dependent on the values of the fields.
以下の意志が変える仕様、分野の値の扶養家族の長さの多く。
4.3.1 Session items
4.3.1 セッション項目
The type field of a session item is always a single octet.
いつもセッション項目のタイプ分野はただ一つの八重奏です。
For session items, given a particular length, there is no flexibility:
セッション項目のために、特定の長さを考えて、柔軟性は全くありません:
If the length is less than 255, represent as one octet
長さが255未満であるなら、1として八重奏を表してください。
If the length is greater, represent as three octets, first is
0xFF, next two are the length, high-order octet first.
長さが、より大きいなら、3として八重奏を表してください、そして、最初に、0xFFがあって、次の2は長さであり、高位八重奏は1番目です。
(Some "real" implementations are known to use the second encoding in all cases. This is wrong, but should only concern conformance testers.)
(いくつかの「本当」の実現がすべての場合における2番目のコード化を使用するのが知られています。 これは、間違っていますが、順応テスターに関係があるだけであるべきです。)
4.3.2 ASN.1/BER items (Presentation and ACSE)
4.3.2 ASN.1/BERの品目(プレゼンテーションとACSE)
The type field for ASN.1-BER is the tag. Although it is possible for large tags (>30) to be multi-octet, there are no large tags in the protocols involved in this memo. Bit 6 (0x20) of the tag octet is 1 if the item is constructed (i.e., the value is itself one or more ASN.1 BER items) or 0 if it is primitive.
ASN.1-BERのためのタイプ分野はタグです。 大きいタグ(>30)がマルチ八重奏であることが、可能ですが、このメモにかかわるプロトコルにはどんな大きいタグもありません。 項目が構成されるなら(すなわち、値はそれ自体で1ASN.1のBERの品目です)、タグ八重奏のビット6(0×20)は1であるか0がそれであるなら原始的です。
There is considerable flexibility, at senders option, in how lengths are represented in BER. There are three forms: short, long and indefinite.
長さがBERにどう表されるかの送付者選択にはかなりの柔軟性があります。 3つのフォームがあります: 短いのと、長いのと無期です。
Short (usable only if the length is less than 127) : one octet
短さ、(使用可能である、長さが127より)少ない場合にだけ: 1つの八重奏
Furniss [Page 14] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[14ページ]RFC1698ThinOSI
Long (usable for *any* length) : first octet has the top bit set,
the rest is a count of how many octets are holding the length
value; that many subsequent octets hold the length. A long length
may use more than the minimum number of octets (so 0x8400000001
is a valid representation of length 1)
長さ、(使用可能である、*どんな*長さも)、: 最初の八重奏には、トップ噛み付いているセットがあって、残りはいくつの八重奏が長さの値を保持するかに関するカウントです。 そんなに多くのその後の八重奏が長さを保持します。 長い長さは八重奏の最小の数以上を使用するかもしれません。(0×8400000001が長さ1の有効な表現であり)
Indefinite (usable only for the length of a compound field) : the
single octet is 0x80, then one or more items (their tag-length-
values) and finally two octets of 0x00 (equivalent to tag and
length of zero).
無期(合成分野の長さだけに、使用可能な): ただ一つの八重奏は、0×00(ゼロのタグと長さに同等な)の0×80と、当時の1つ以上の項目(それらのタグ長さ値)と最終的に2つの八重奏です。
To be able to interwork generally, an implementation must be able to handle any of these forms when receiving.
受信するとき、一般に実現を織り込むことができるのはこれらのフォームのいずれも扱うことができなければなりません。
The encodings specified in the octet sequences below use indefinite length for all constructed items with a few exceptions. This slightly increases the number of octets sent, but means that the length of a varying field (e.g., user data, or a varying object identifier) affects only the length of the item itself, and not the enclosing lengths. It is thus possible to use the octet sequences as templates interspersed by the varying fields.
encodingsは使用の下で無期の八重奏系列で若干の例外はあるもののすべての組み立てられた項目に長さを指定しました。 これは、送られた八重奏の数をわずかに増加させますが、異なった分野(例えば、利用者データ、または異なった物の識別子)の長さが同封の長さではなく、項目自体の長さだけに影響することを意味します。 その結果、異なった分野によって点在させられたテンプレートとして八重奏系列を使用するのは可能です。
It is important to note that this choice of indefinite (which is equivalent to the "Canonical Encoding Rules" variant of BER) applies only to the Presentation and ACSE protocols themselves. It does not apply to ASN.1/BER encoded application data. The processing required of application data may suggest alternative "best" options.
無期のこの選択(BERの「正準な符号化規則」異形に同等である)がPresentationとACSEプロトコル自体だけに適用されることに注意するのは重要です。 それはASN.1/BERのコード化されたアプリケーションデータに適用されません。 アプリケーションデータについて必要である処理は代替の「最も良い」オプションを示すかもしれません。
4.4 BER Encoding of values for primitive datatypes
4.4 原始のデータ型式のための値のBER Encoding
The following ASN.1 primitive datatypes are used in the thinosi stack.
以下のASN.1の原始のデータ型式はthinosiスタックで使用されます。
Integers are encoded in twos-complement, high-order first. Unlike lengths, they must be encoded in the minimum number of octets (no leading 00 padding).
整数は2補数の、そして、高い注文している1番目でコード化されます。 長さと異なって、八重奏の最小の数でそれらをコード化しなければなりません(どんな主な00もそっと歩かないで)。
Object Identifiers have a rather peculiar, but compressed encoding:
物のIdentifiersには、かなり独特の、しかし、圧縮されたコード化があります:
Combine the first two integers of the OID into one element by
multiplying the first (always 0, 1 or 2) by 40, and add the
second.
40を1番目に掛けることによって(いつも0、1または2)、OIDの最初の2つの整数を1つの要素に結合してください、そして、2番目を追加してください。
Each element (that one, and each subsequent integer in the OID
taken on its own), is a taken as a binary number and divided into
7-bit "bytes". This is apportioned into bits 1-7 of the minimum
number of octets. Bit 8 is one for all octets of the sequence
except the last. (This means that elements of less than 127 are
各要素(それ、およびそれ自身のところで取られたOIDのそれぞれのその後の整数)はバイナリーが7ビットの「バイト」に付番して、分割されたので取られたaです。 これは八重奏の最小の数のビット1-7に分配されます。 ビット8は最終以外の系列のすべての八重奏のためのものです。 (これは、127未満の要素がそうであることを意味します。
Furniss [Page 15] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[15ページ]RFC1698ThinOSI
single octet integers.)
ただ一つの八重奏整数。)
Printable Strings - as if in ISO 646 (ASCII)
印刷可能である、まるでISO646で結ぶかのように、結びます。(ASCII)
OCTET STRING - just put the octets there
OCTET STRING--ただ八重奏をそこへ置いてください。
4.5 Unnecessary constructed encodings
4.5 不要な組み立てられたencodings
BER allows the sender to break some items (such as OCTET STRINGS, character strings) into several pieces (i.e., as constructed encoding) or send them as primitive. CULR-1 requires that this is only done to one level. The pieces of both OCTET STRING and character string are tagged as if they were OCTET STRING - they have the tag 04. This memo does not include any of these optional constructions, but they may be received in interworking.
BERは送付者にいくつかの断片(すなわち、組み立てられたコード化としての)に数個の項目(OCTET STRINGS、文字列などの)を壊すか、または原始としてそれらを送らせます。 CULR-1は、1つのレベルにしかこれをしないのを必要とします。 OCTET STRINGとキャラクタが結ぶ両方の断片はまるでそれらがOCTET STRINGであるかのようにタグ付けをされています--それらには、タグ04があります。 このメモはこれらの任意の構造のいずれも含んでいませんが、織り込むことでそれらを受け取るかもしれません。
5. Notation
5. 記法
The constructs are shown in their tag - length - value form. All numbers are in hexadecimal. Comments are preceded by a '-' character. Multiple '-' mean the comment is more than just information.
構造物はそれらのタグ--長さ--値のフォームで見せられます。 16進にはすべての数があります。 コメントは'--'キャラクタによって先行されています。 複数の'--'が、コメントがまさしく情報以上であることを意味します。
The tag column contains one of:
タグコラムは1つを含んでいます:
single fixed octets.
ただ一つの固定八重奏。
* in the tag field indicates one or more pdu fields (possibly
constructed) that may be received but are not sent. If received
they can be ignored.
* タグ・フィールドで、受け取るかもしれませんが、送らない1つ以上のpdu野原(ことによると組み立てられる)を示します。 受け取るなら、それらを無視できます。
! indicates the tag is defined elsewhere.
タグがほかの場所で定義されるのを示します。
. is a place holder for the column.
. 場所所有者はコラムに賛成しますか?
? preceding the tag value indicates that the field is not always
present - the comment will explain.
タグ値に先行するのは、分野がいつも存在しているというわけではないのを示します--コメントは説明するでしょう。
The length column contains one of
コラムが1つを含む長さ
explicit value
明白な値
Ls - a length according to session rules which depends on the
total size of the value (usually constructed)
Ls--セッション規則に従った価値の総サイズに応じた長さ(通常、組み立てられます)
La - a length according to BER rules
La--BER規則に従った長さ
. is a placeholder
プレースホルダです。
Furniss [Page 16] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[16ページ]RFC1698ThinOSI
yy is exactly one octet (i.e., one hex digit per y) holding part
of the length
yyはちょうど長さの1つの八重奏(すなわち、1yあたり1十六進法ケタ)の固定部です。
The value column contains one of
コラムが1つを含む値
the hex value
十六進法値
xxxxxx - value of varying length (sometimes constructed)
xxxxxx--異なった長さの値(時々組み立てられます)
{n - (n = number) the start of a constructed value
n--、構成価額の(nは数と等しいです)始まり
n - (n=number) the end of the constructed value with the
corresponding number. (The number is sometimes omitted on the
innermost nest of construction)
n--(nは数と等しいです)対応する数がある構成価額の終わり。 (数は工事の最も奥深い巣で時々省略されます)
yy - as part of a value - a variable value, each y represents one
hex digit
価値の一部としての変数が評価するyy、各yは1十六進法ケタを表します。
? a value, possibly constructed that may be received but is not
sent. It may be ignored if received
値であり、ことによると組み立てられて、それを受け取るかもしれませんが、送りません。 受け取るなら、それを無視するかもしれません。
Note that all presentation lengths may be received in one of the alternative forms. All constructed lengths are shown in indefinite form. If a received length is definite, the corresponding end item (which will be shown here as 00 00 }n) will become . . }n.
すべてのプレゼンテーションの長さが選択方式の1つに受け取られるかもしれないことに注意してください。すべての組み立てられた長さが無期フォームに示されます。 a容認された長さが明確であるなら、対応が項目を終わらせる、(どれが00 00としてここに示されるか、n)はなるでしょう。 n
In the comments, the notation {n} refers to the constructed item
bracketed by the {n, }n fields.
コメントでは、記法nが腕木を付けられた組み立てられた項目を示す、nがさばくn。
6. Octet sequences
6. 八重奏系列
6.1 Connection request message
6.1 接続要求メッセージ
- CONNECT SPDU
0D Ls {1 - "SI" value for CONNECT = 13
* Ls ? - Connection Identifier
05 06 {2 - Connect/Accept Item
13 01 00 - protocol options (probably mandatory)
* Ls ?
- CONNECT SPDU 0D Ls、1--「SI」、値、=13*Ls?接続してください--、接続識別子05 06、2--商品13 01 00(プロトコルオプション(たぶん義務的な)*Ls)を接続するか、または受け入れてください。
16 01 02 -- version number (bottom bit = v1, next bit =v2.
-- may get offers of either or both
* Ls ?
14 02 0002 - Session User Requirements (functional units)
- Id (20), length (always 2), duplex fu only.
-- On receipt, other bits may be set
-- check that the 2 bit is set
* Ls ? - we do not send any Calling Session Selector
16 01 02--バージョン、数、(ビット=v1(ビットの次=v2)に底をつけてください(どちらかの申し出を得るかもしれないか、または両方の*Ls--14 02 0002--イド(20)、領収書の長さ(いつも2)(デュプレックスfuだけ)、他のビットが設定されるかもしれないというセッションUser Requirements(機能的なユニット)は、2ビットがセット*Lsであることをチェックします)--私たちは少しのCalling Session Selectorも送りません。
Furniss [Page 17] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[17ページ]RFC1698ThinOSI
?34 Ls xxxx -- Called Session Selector (i.e., the other end's)
-- up to 16 octets - you must set what the other
-- side demands. - May be anything characters,
-- binary etc.
- {3} disappeared in editing
C1 Ls {4 -- User Data, Identifier=193. if length is > 512,
-- then identifier is 194 (hex C2) instead
- CP - P-CONNECT-RI PPDU. Everything below is in ASN.1 BER
31 80 {5 - [SET]
--- Mode-selector (the {6} group) could possibly
--- come after everything else {7}
--- This will probably only be done by
--- evil-minded conformance testers
A0 80 {6 - Mode-selector [0] IMPLICIT SET
80 01 01 - [0] IMPLICIT INTEGER {normalmode(1)}
00 00 }6
A2 La {7 - [2] unnamed IMPLICIT SEQUENCE
* La ?
?82 La xxxx - [2] Called-presentation-selector
- CULR says maximum length is 4
-- must be what the other side wants
A4 80 {8 - [4] Presentation-context-definition-list
--- items (the outer SEQUENCEs) within the {8} list may
--- be in any order.
30 80 {9 - [SEQUENCE]
02 01 01 -- Defines pcid for ACSE; received value will be
-- a one or two octet odd integer
06 04 52010001 - [OID] for ACSE abstract syntax
30 80 { - [SEQUENCE]
06 02 5101 - [OID] Transfer syntax name is BER
00 00 } - end t-s list
00 00 }9 - end acse pctx defn
30 80 {10 - [SEQUENCE]
02 01 03 -- [INTEGER] Defines pcid for application data;
-- received value will be a one or two octet odd
-- integer
06 La xxxxxx - [OID] object identifier name of application
- abstract syntax (if CULR-3 default is used, this
- line is 06 06 28D734030101)
30 80 {11
06 La xxxxxx - [OID] t-s name for application data
- (if CULR-3 default is used, this line is
- 06 06 28D734030201)
-- will be several of these if multiple t-s offered
-- (application is Group III)
-- all will have the same tag 06
00 00 }11 - end transfer syntax list for application p-ctx
00 00 }10 - end application pctx definition
--34Ls xxxx--呼ばれたSession Selector(すなわち、端のもう一方のもの)--最大16の八重奏--あなたはことを設定しなければなりません。もう片方--サイド要求。 - 何かがバイナリーキャラクタ--などであったならでもそうするかもしれません。 - 3がC1 Lsを編集する際に見えなくなった、4--ユーザData(Identifier=193)、長さは>512です--次に、識別子が代わりにASN.1BER31 80の194(十六進法C2)(CP)である、5--、SET、-、--、モード選択器(6グループ)がそうすることができた-、--、来てください後他の何もかもの7、-; たぶんこれをするだけである、-、--、意地悪な順応テスターA0 80 6--モード選択器0IMPLICIT SET80 01 01--0IMPLICIT INTEGER normalmode(1)00 00 6A2 La、7--2の無名IMPLICIT SEQUENCE*La?82La xxxx--2Calledプレゼンテーションセレクタ--CULRは、最大の長さが4であると言います; 反対側が必要とするものがA4 80であったに違いない、8--4Presentation文脈定義リスト、-、--、8リストの中の項目(外側のSEQUENCEs)がそうするかもしれない-、--、いずれでも. 30 80を命令することになってください9(SEQUENCE02 01 01)が定義する、pcidに、ACSE; ACSEのための--1か2の八重奏の変な整数06 04 52010001--OIDが抽象構文30 80であるつもりであったなら値を受けるのに関して、--SEQUENCE06 02 5101--OID Transfer構文名はBER00 00です--t-sリスト00 00を終わらせてください、9--終わってください。acse pctx defn30 80; 10--SEQUENCE02 01 03(アプリケーションデータのためのINTEGER Defines pcid)--1か2 1つが八重奏変であったなら、値の意志を受けます--整数06La xxxxxx(アプリケーションのOID物の識別子名)抽象構文(CULR-3デフォルトが使用されているなら、これ--立ち並ぶのは、06 06 28D734030101です); CULR-3デフォルトが使用されているなら、この線は使用します。30 80、11 06La xxxxxx(アプリケーションデータのためのOID t-s名)、(--06 06 28D734030201) --提供して、複数のt-sであるならこれらの数個でしょう--、(アプリケーションはGroup III)です--すべてには同じタグ06 00 00がある、11--アプリケーションp-ctx00 00のための転送構文リストを終わらせてください、10; - 終わりのアプリケーションpctx定義
Furniss [Page 18] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[18ページ]RFC1698ThinOSI
-- if multiple presentation contexts are offered, (Group
-- IV), the {10} SEQUENCE will repeat appropriately
-- if multiple contexts are to be accepted, all the
-- pcid's must be remembered
00 00 }8 - end of p-ctx-def-list
* La ?
61 80 {12 - [APPLICATION 1] User-data - Fully-encoded
30 80 {13 - [SEQUENCE] PDV-list
02 01 01 -- [INTEGER], value is acse pcid
A0 80 {14 - [0] Single-ASN1
- ACSE A-ASSOCIATE request APDU - AARQ
60 80 {15 - [APPLICATION 0] - AARQ
* La ? - protocol version defaults to 1 (only one defined)
A1 80 { - [1] Application-context
06 La xxxxxx -- object identifier name of application context
- (if CULR-3 default is used, this line is
- 06 05 28D7340303)
00 00 }
-- Called application process title {16} and application
-- entity qualifier may or may not be needed (see 3.4)
?A2 80 {16 - [2] Called Application-Process title
?! La xxxxxx -- see 3.5 - either a Directory Name or an oid
?00 00 }16 - end Called APtitle
?A3 80 {17 - [3] Called Application-Entity Qualifier
?! La xxxxxx -- see 3.5
?00 00 }17
* La ?
Calling AP-title and AE-qualifier may or may not be needed.
?A6 80 {18 - [6] Calling Application-Process title
?! La xxxxxx -- see 3.5
?00 00 }18
?A7 80 {19 - [7] Calling Application-Entity Qualifier
?! La xxxxxx -- see 3.5
?00 00 }19
* La ?
-- the user information field may or may not be required
-- (not required for Group I)
?BE 80 {20 - [30] IMPLICIT SEQUENCE
?28 80 {21 - [EXTERNAL]
?06 La xxxxxx -- [OID] This is the oid identifying the transfer
-- syntax used for the user data.
-- It is (almost certainly) required even if only
-- one transfer syntax was proposed.
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxxx -- [0] single-ASN.1-type - the application data
-- (see paragraph at end of this section below}
?00 00 }21 - end of EXTERNAL
-- 10SEQUENCEは、複数の文脈が受け入れることであるなら(分類してください--IV)と複数のプレゼンテーション文脈を提供するなら、適切に繰り返すでしょう、すべて、--、pcidのものがそうしなければならない覚えていられてください、00 00、8(p-ctxのクールなリスト*Laの端) 61 80、12(APPLICATION1User-データ)が30 80を完全にコード化した、13--SEQUENCE PDV-リスト02 01 01--INTEGER、値がacse pcid A0 80である、14--、0Single-ASN1--ACSE A-ASSOCIATE要求APDU--AARQ60 80、15(APPLICATION0(AARQ*La))が1(定義されたものだけ)A1 80にバージョンデフォルトについて議定書の中で述べる、--1 Application-文脈06La xxxxxx--アプリケーション文脈の物の識別子名--(CULR-3デフォルトが使用されているなら、この線は使用します--、06 05 28D7340303) 00 00、--アプリケーション・プロセスタイトルを16とアプリケーションと呼びました; 16--2Called Application-過程タイトル?La xxxxxx--3.5--ディレクトリNameかoidのどちらか--00 00を見てください。18--6はタイトルをCalling Application処理しますか?実体資格を与える人が必要であるかもしれないか、(3.4を見てください)A2 80、16--終わりのCalled APtitle?17*La?がCalling AP題をつけるA3 80 17--3Called Application-実体Qualifier?La xxxxxx(3.5を見る)00 00とAE-資格を与える人が必要であってもよい、{La xxxxxx--3.5を見てください--00 00}というA6 80 18A7 80、19--7Calling Application-実体Qualifier?La xxxxxx--見てください。 3.5--00 00、19*La(分野が必要であるかもしれないというユーザー情報)(Group Iのために、必要でない)?--80になってください。{20--[30] 暗黙の系列28 80?{21--[EXTERNAL?] 06La xxxxxx--[OID] これは転送を特定するoidです--利用者データに使用される構文。 -- 1つの転送構文しか提案されなかったとしても、それが必要です(ほぼ確実に)。 [INTEGER] 02 01 03--これはアプリケーション--データ--A0 La xxxxxx--[0] 単独のASN.1タイプ--アプリケーションデータのためのpcidです--、(以下のこのセクションの端でパラグラフを見てください、00 00、21--EXTERNALを終わらせてください。
Furniss [Page 19] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[19ページ]RFC1698ThinOSI
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }20 - end of user information field
00 00 }15 - end of AARQ
00 00 }14 - end of single-ASN-type
00 00 }13 - end of PDV-list
00 00 }12 - end of Presentation User-data
00 00 }7 - end of third element of CP-type SET
00 00 }5 - end of CP-type
-- 多分、数個のEXTERNALSがあるかもしれません、たぶん--異なったプレゼンテーション文脈(異なったpcids)--00 00で20--ユーザ情報フィールド00 00を終わらせてください、15--AARQ00 00を終わらせてください、14--独身のASNがタイプしている00 00を終わらせてください、13--PDV-リスト00 00を終わらせてください、12--Presentation User-データ00 00を終わらせてください、7--CP-タイプSET00 00の3番目の要素を終わらせてください、5--CP-タイプに終わってください。
The application data carried in the EXTERNAL is shown (as A0 La xxxx) assuming it is a single-ASN.1 type, which it often will be for group II (since these tend to be OSI applications). The xxxx will be the BER encoding of the application pdu (probably something like Z-BIND or Y- INITIALIZE). The length may be indefinite.
EXTERNALで運ばれたアプリケーションデータはそれが独身のASN.1タイプ(これらが、OSIアプリケーションである傾向があるので)であると仮定するのが示されます(A0 La xxxxとして)。(なるしばしばタイプがそうであるのにそれがグループIIのために) xxxxはアプリケーションpdu(たぶんZ-BINDやY INITIALIZEのような)のBERコード化になるだろうこと。 長さは無期であるかもしれません。
If the application data is not a single ASN.1 type, but is an octet- aligned value, the A0 La xxxx is replaced by 81 La xxxx, where xxxx is the value. In this case the length must be definite (unless an "unnecessary" constructed encoding is used.)
アプリケーションデータが単独のASN.1タイプではありませんが、八重奏の並べられた値であるなら、A0 La xxxxを81La xxxxに取り替えます。そこでは、xxxxが値です。 この場合、長さは明確であるに違いありません。(組み立てられた「不要な」コード化が使用されていない場合。)
Identical considerations apply to the other EXTERNALs carried in the ACSE pdus.
同じ問題はACSE pdusで運ばれた他のEXTERNALsに適用されます。
6.2 Successful reply to connection setup
6.2 接続設定に関するうまくいっている回答
If the connection attempt is successful, the following is sent to the initiator on a T-DATA.
接続試みがうまくいくなら、T-DATAの上の創始者に以下を送ります。
0E Ls {1 - ACCEPT SPDU
* Ls ?
05 06 {2 - Connect/Accept Item
13 01 00 - Protocol Options
* Ls ?
16 01 02 - version number (this shows version 2 only)
-- if version 2 was not offered, omit all of {2}
* Ls ?
14 02 0002 - Session User Requirements (functional units)
- duplex fu only (kernel is automatic)
* Ls ?
C1 Ls {3 -- User Data.
- CPA - P-CONNECT response
31 80 {4 - [SET]
-- again, Mode-selector could come at the end
A0 80 { - Mode-selector [0]
80 01 01 - normal mode - [0], length=1, value=1
00 00 }
A2 80 {5 - [2] SEQUENCE (unnamed)
0EのLs、1--ACCEPT SPDU*Ls--05 06、2--Item13 01 00を接続するか、または受け入れてください--Options*Ls--16 01 02--バージョン番号について議定書の中で述べてください(これはバージョン2だけを示しています)--バージョン2が提供されなかったなら、*2Lsのすべて--14 02 0002--セッションUser Requirements(機能的なユニット)--デュプレックスfu唯一の(カーネルは自動です)*Ls--C1 Lsを省略してください、3; ユーザData--CPA--P-CONNECT応答31 80、一方、Mode-セレクタが終わりA0 80に来させることができた4(SET)、--、モード選択器、0、80 01 01、--正規モード--0(長さ=1)が=1 00 00を評価する、A2 80、5--2SEQUENCE(無名)です。
Furniss [Page 20] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[20ページ]RFC1698ThinOSI
* La ?
A5 80 {6 - [5] P-context-definition-result-list
-- following result items are in the order
-- corresponding to the pctx-definition-list in
-- the connect
-- this example assumes that was ACSE, user, rubbish
-- with rubbish rejected
30 80 {7 - [SEQUENCE] result item for acse
80 01 00 -- [0] result, value 0 is acceptance
81 02 5101 - [1] accepted transfer syntax name = BER
- note that this has an implicit tag, not 06
00 00 }7 - end result item for acse p-ctx
* La? A5 80、中でpctx定義リストに対応している、6--[5] P文脈定義結果リスト--次の結果項目がオーダーにあります--、接続してください--この例がそれを仮定する、7--ACSE、ユーザ、くず--くずで=BER--これには06 00 00ではなく内在しているタグがあることに注意すると7--acse80 01 00のための項目--[0] なってください、値0が承認81 02 5101であるという[SEQUENCE]結果--[1]の受け入れられた転送構文が命名する30 80を拒絶するのは、acse p-ctxのための結果項目を終わらせました。
30 80 {8 - [SEQUENCE] result item for application-data pctx
80 01 00 - [0] value 0 is acceptance
81 La xxxxxx - [1] oid for transfer syntax, as on definition list
-- if there were several (groupIII) , the one you
-- liked most
00 00 }8 - end result item for app-data p-ctx
00 00 }6 - end p-ctx-def-result-list
* La ?
61 80 {10 - [APPLICATION 1] User-data, Fully-encoded
8--アプリケーションデータpctx80 01 00のための[SEQUENCE]結果項目--[0]値0は承認です。30 80、81La xxxxxx--[1] 転送構文にoidです、定義のように、記載してください--、--数個(groupIII)があって、1つがほとんどの00 00が好きである、8--装置データp-ctx00 00のための結果項目を終わらせてください、6(終わりのp-ctxのクールな結果リスト*La) 61 80、10--、[アプリケーション1]利用者データであって、完全にコード化にされる
30 80 {11 - [SEQUENCE] PDV-list
02 01 01 -- [INTEGER] value is pcid for ACSE, as stored from
-- the pctx-definition-list on the P-CONNECT
-- request
A0 80 {12 - [0] single-ASN1-type
- A-ASSOCIATE response APDU - AARE
61 80 {13 - [APPLICATION 1] identifies AARE
* La ?
A1 80 {14 - [1] Application-context
06 La xxxxxx - [OID] name of application context
- usually the same as on AARQ, can differ
00 00 }14
A2 03 {15 - [2] result
02 01 00 - [INTEGER] value 0 means accepted
00 00 }15
A3 80 {16 - [3] result-source-diagnostic
- (curiously, a non-optional field)
A1 80 {17 - [1] acse-service-user
02 01 00 - [INTEGER] value 0 = null ! (why no implicit tag)
00 00 }17 - end acse-service-user
00 00 }16 - end result source diagnostic
* La ?
-- the user information field may or may not be required
- (not used for Group I)
?BE 80 {20 - [30] IMPLICIT SEQUENCE
30 80、INTEGERがあるのを評価する11(SEQUENCE PDV-リスト02 01 01)が格納されるとしてのACSEのためにpcidする、--P-CONNECTの上のpctx定義リスト; A0 80を要求してください、12--0の単独のASN1タイプ--1ASSOCIATEの応答APDU--アーレ61 80、13、--、APPLICATION1がアーレ*La?A1 80を特定する通常、AARQと同じ14--1Application-文脈06La xxxxxx(アプリケーション文脈のOID名)、異なることができる、00 00、14A2 03; 15--2結果02 01 00--INTEGER価値0の手段が00 00を受け入れた、15A3 80、16--3結果ソース病気の特徴--(奇妙にも、非任意の分野) A1 80、17--1 acse-サービス利用者02 01 00--INTEGER価値0=ヌル!、(内在しているタグがありません) なぜ00 00、17--acse-サービス利用者00 00を終わらせてくださいか、16--結末ソース病気の特徴*La?; ユーザ情報フィールドが必要--(Group Iには中古でない)--であることが、80であるということであるかもしれない、20--30IMPLICIT SEQUENCE
Furniss [Page 21] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[21ページ]RFC1698ThinOSI
?28 80 {21 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxx -- [0] single-ASN1-type (see note at end of 6.1)
?00 00 }21 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }20 - end of user information field
00 00 }13 - end AARE
00 00 }12 - end single-asn1-type
00 00 }11 - end PDV-list
00 00 }10 - end Presn user-data
00 00 }5 - end [2] implicit sequence in cpa
00 00 }4 - end CPA-type set
21--EXTERNAL--転送構文oidはこれがアプリケーション--データ--A0 La xxxx--0の単独のASN1タイプ(6.1の終わりで注意を見る)--00 00のためのpcidであるこの時間--02 01 03--INTEGERのときに存在していません。28 80、21--EXTERNALの端--多分、数個のEXTERNALS(たぶんコネ)があるかもしれません; 異なったプレゼンテーション文脈(異なったpcids)?00 00、20--ユーザ情報フィールド00 00を終わらせてください、13--アーレ00 00を終わらせてください、12--単独のasn1タイプ00 00を終わらせてください、11--PDV-リスト00 00を終わらせてください、10--Presn利用者データ00 00を終わらせてください、5--2の暗黙の系列をcpa00 00に終わらせてください、4--CPA-タイプを終わらせるのはセットしました。
The following sequence are the octets need to reject a presentation
context that was offered in the presentation-context-definition-list.
Since the result-list matches the definition list by position, it is
placed at the corresponding point within {6} (e.g., it would come
immediately after {8}, if the rejected context was the third one.
以下の系列は贈り物の文脈定義リストで提供されたプレゼンテーション文脈を拒絶する八重奏の必要性です。 結果リストが位置のそばで定義リストに合っているので、それは6の中に対応するポイントに置かれます。(8直後来るでしょう、拒絶された文脈が3番目のものであったなら。
-- next SEQUENCE is a rejection of a pctx
30 80 {9 - [SEQUENCE] result item for a rejected pctx
80 01 02 -- [0] result, value 2 is provider rejection
82 01 00 - [2] reason, value 0 is reason-not-specified
-- there are other reasons, but let's keep it
-- simple
00 00 }9 - end result item for rejected pctx
-- 次のSEQUENCE、9--pctx30 80の9--拒絶されたpctx80 01 02のための項目--[0] なってください、[2] 推論してください、値2はプロバイダー拒絶82 01 00です--値0が理由を指定していなかったという[SEQUENCE]結果(それを保とうというのを除いて、理由が別にある)の簡単な00 00の拒絶は拒絶されたpctxのための結果項目を終わらせます。
6.3 Connection rejection
6.3 接続拒絶
Refusal is at session-level, but by session user, with no reason given. This is a compromise avoiding making unfounded accusations of (session) protocol misbehaviour. If the implementation finds it does not like the received message, it is not essential to attempt to communicate with the partner why, though this may be helpful if the reason is correctly identified. (In most cases, a wise implementor will make sure an error message goes somewhere or other).
拒否は、セッションレベルにありますが、理由が全くあげられていないセッションユーザであります。 これは(セッション)プロトコル無作法の無根拠な罪名をするのを避ける妥協です。 それが受信されたメッセージが好きでないことが実現によってわかるなら、パートナーと理由を伝えるのを試みるのは不可欠ではありません、理由が正しく特定されるなら、これが役立つかもしれませんが。 (多くの場合、賢明な作成者は、エラーメッセージがどこかか別に行くのを確実にするでしょう。)
0C 03 {1 - REFUSE SPDU
* Ls ?
32 01 00 - rejected by SS-user, no reason
0C03、1(REFUSE SPDU*Ls32 01 00?)はSS-ユーザ、どんな理由でも拒絶しませんでした。
The far-end may send interesting things explaining why you are not getting interworking. If this is a session reason, the reason code will one octet between 81 and 86. If the rejection is higher than session, this will be carried on S-REFUSE (so first octet is still
遠端で、おもしろいものであなたがなぜ織り込み始めているかがわからないかもしれません。 これがセッション理由であるなら、理由コードは81と86の間の1つの八重奏が理由でしょう。 拒絶がセッションより高いなら、これがS-REFUSEで運ばれる、(したがって、最初の八重奏はまだそうです。
Furniss [Page 22] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[22ページ]RFC1698ThinOSI
0C) and the higher pdu will appear as part of the reason code, which will start with 02. (The only remaining code is 01 = user congestion.)
0C)と、より高いpduは理由コードの一部として現れるでしょう。(コードは02から始まるでしょう)。 (唯一の残っているコードがユーザ01=混雑です。)
6.4 Data-phase TSDU
6.4 データフェーズTSDU
This is the core of the skinny stack. The lengths shown use a particular set of choices for indefinite and definite lengths that means that the application data length only affects one field. Making the two earlier indefinite lengths definite would require more calculation - adding 4 octets after the application data is assumed to be quicker. This header is also designed to be 20 octets long, thus maintaining 4-byte alignment between transport and application buffers. Implementations are recommended to use this encoding. It is possible to rapidly match incoming data against it - if there is no mismatch until the length field, the location of the beginning of the data can be determined without further analysis.
これは痩せぎすのスタックのコアです。 示された長さは無期の、そして、明確な長さのためのアプリケーションデータの長さが1つの分野しか影響しないことを意味する特定の選択を使用します。 アプリケーションデータが、より迅速であると思われた後に4つの八重奏を加えて、2つの以前の無期長さを明確にするのは、より多くの計算を必要とするでしょう。 また、このヘッダーは長い間の20の八重奏になるように設計されていて、その結果、輸送とアプリケーションバッファの間の4バイトの整列を維持します。 実現がこのコード化を使用することが勧められます。 急速にそれに対して受信データを合わせるのは可能です--長さの分野、データの始まりの位置があることができるまでミスマッチが全くなければ、さらなる分析なしで断固としてください。
SPDUs
01 00 . - S-GIVE-TOKEN - required by basic concatenation
- but no parameters
01 00 . - S-DATA - no parameters - what follows is User
- Information, not User Data, so is not included in
- the SPDU length fields
- P-DATA PPDU - TD (why TD ? Typed-data id TTD !)
61 80 {1 - User-data [APPLICATION 1]
30 80 {2 - [SEQUENCE] PDV-list
02 01 03 - [INTEGER] pcid for application data, P-CONNECT PPDU
- remembered by both sides
81 83yyyyyy xxxxxx -- [1] octet-aligned presentation data value(s)
-- length of length (3 octets) then three octets yyyyyy
-- for the length of the user data xxxxxx
00 00 }2 - End-of-contents for end of PDV-list
00 00 }1 - End-of-contents for end of Presentation User-data
SPDUs01 00--S-GIVE-TOKEN(基本的な連結で、必要である)にもかかわらず、パラメタ01 00がありません--S-DATA--続くことがUserであるというしたがってUser Dataではなく、情報が含まれていないどんなパラメタも--SPDU長さの分野--P-DATA PPDU--TD(なぜTD--Typed-データイドTTD?!) 61 80、1--{2--[SEQUENCE]02 01 03(アプリケーションデータのための[INTEGER]pcid、P-CONNECT PPDU)が両側で覚えていたPDV-リスト81 83yyyyyy xxxxxx--[1]の八重奏で並べられたプレゼンテーションデータは(s)を評価します--利用者データxxxxxx00 00の長さのための次に、(3つの八重奏)3の長さの八重奏yyyyyyの長さ}という利用者データ[APPLICATION1]30 80 2--PDV-リスト00 00の終わりのコンテンツの終わりの1--Presentation User-データの終わりの間、コンテンツを終わらせてください。
If the application data is in ASN.1, and a single ASN.1 value is being sent on the TSDU, the same header can be used except for the tag on the presentation data values, which becomes A0 (= [0], constructed).
アプリケーションデータがASN.1にあって、独身のASN.1値をTSDUに送るなら、プレゼンテーションデータ値のタグを除いて、同じヘッダーを使用できます。(それは、A0(組み立てられて、[0]と等しい)になります)。
If there are multiple data values to be sent, this header can be expanded in several ways:
送られる複数のデータ値があれば、いくつかの方法でこのヘッダーを広げることができます:
a) if there are several ASN.1 values from the same
presentation context, they can be concatenated and
treated as an octet-aligned value (using the header
as shown above, with tag 81 (or A1 - I think its
primitive) or each ASN.1 value can be an item
そこであるならa)が同じプレゼンテーション文脈からのいくつかのASN.1値であり、それらを連結して、八重奏で並べられた値として扱うことができる、(上にタグ81で示されるようにヘッダーを使用する、(A1、--、私が、それが原始的であると思う)、それぞれのASN.1価値は項目であるかもしれません。
Furniss [Page 23] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[23ページ]RFC1698ThinOSI
(tagged A0), one after the other
次々と(タグ付けをされたA0)
b) if the data values are from different presentation
contexts (group IV), each is in its own {2} group
within the {1}.
b)がデータ値であるなら異なったプレゼンテーション文脈(グループIV)から来ていて、それぞれがそれ自身の2が分類するコネである、1。
On receipt, for the simple octet-aligned case, the data value may itself have a constructed encoding - this will make the tag A1, and it will contain elements each tagged 04 (OCTET STRING). According to CULR- 1, these elements are primitive (otherwise they would be 24 of course).
簡単な八重奏で並べられたケースには、値が領収書を出させるデータをそれ自体で領収書を出させてください。それは要素を含むでしょう。そして、オンである、組み立てられたコード化を持ってください--これがタグをA1にする、それぞれ、04(OCTET STRING)にタグ付けをしました。 CULR1によると、これらの要素は原始的です(さもなければ、それらはもちろん24でしょう)。
6.5 Closedown - release request
6.5操業停止--リリース要求
When all is done, and you want to close down gracefully, send this on T-DATA.
すべてが完了していて、優雅に休業したがっているとき、これをT-DATAに送ってください。
- FINISH SPDU
09 10 {1 - 9 identifies FINISH
* Ls ? - No Transport Disconnect item
- default is release Transport-connection
C1 0E {2 - User data (code 193)
- P-RELEASE req/ind PPDU (has no name)
61 80 {3 - [APPLICATION 1], user data, fully-encoded
30 80 {4 - [SEQUENCE] PDV-list
02 01 01 -- pcid for ACSE, remembered from setup
A0 80 {5 - [0] single asn.1-type
- A-RELEASE request APDU - RLRQ
62 80 {6 - [APPLICATION 2] identifies RLRQ
80 01 00 - [0] reason, value 0 means normal
* La ?
-- the user information field may or may not be required
- ( not required for Group I)
?BE 80 {7 - [30] IMPLICIT SEQUENCE
?28 80 {8 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxx -- [0] single-ASN.1-type application data
-- (see note at end of 6.1)
?00 00 }8 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }7 - end of user information field
00 00 }6 - end of RLRQ
00 00 }5 - end of single asn.1-type
00 00 }4 - end of PDV-list
00 00 }3 - end of Presentation User-data
- FINISH SPDU09 10、1--9がFINISH*Ls(Transport Disconnectの品目がない)?特定して、デフォルトがリリースTransport-接続C1 0Eである、2--利用者データ(コード193)--P-RELEASE req/ind PPDU(名前を全く持っていない)61 80、3、--、APPLICATION1(利用者データ)が30 80を完全にコード化した4--SEQUENCE PDV-リスト02 01 01--セットアップA0 80から覚えていられたACSEのためのpcid、5--0がasn.1-タイプ--1RELEASEの要求APDU--RLRQ62 80を選抜する、6--APPLICATION2はRLRQ80 01 00--0理由を特定します、値0の手段標準*La?; ユーザ情報フィールドは必要--(Group Iには必要でない)--であることが、80であるということであるかもしれません; {8--EXTERNAL--転送構文oidはこれがアプリケーション--データ--A0 La xxxxx(0つの独身のASN.1がタイプしているアプリケーションデータ)のためのpcid(6.1の終わりで注意を見る)であるこの時間--02 01 03--INTEGERのときに存在していません--00 00}という7--30IMPLICIT SEQUENCE--28 80 8--EXTERNALの端--数個のEXTERNALSが多分あるかもしれないたぶんコネ--異なったプレゼンテーション文脈(異なったpcids)?00 00、7--ユーザ情報フィールド00 00を終わらせてください。6--RLRQ00 00を終わらせてください、5--ただ一つのasn.1-タイプ00 00を終わらせてください、4--PDV-リスト00 00を終わらせてください、3--Presentation User-データを終わらせてください。
Furniss [Page 24] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[24ページ]RFC1698ThinOSI
6.6 Closedown - release response
6.6操業停止--リリース応答
On receiving a FINISH, you send this to tell the other end it is all over
FINISHを受けると、あなたは、それが終わっているともう一方の端に言うためにこれを送ります。
- Session DISCONNECT SPDU
0A Ls {1 - SI=10, DISCONNECT
C1 Ls {2 - User data
- P-RELEASE rsp PPDU
61 80 {3 - [APPLICATION 1], user data, fully-encoded
30 80 {4 - [SEQUENCE] PDV-list
02 01 01 -- [INTEGER] pcid for ACSE, remembered from setup
A0 80 {5 - [0] single asn.1-type
- A-RELEASE response APDU - RLRE
63 80 {6 - [APPLICATION 3] identifies RLRE
80 01 00 - [0] reason, value 0 means normal
* La ?
-- the user information field may or may not be required
- (not required for Group I)
?BE 80 {7 - [30] IMPLICIT SEQUENCE
?28 80 {8 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxx -- [0] single-ASN.1-type application data
-- (see note at end of 6.1)
?00 00 }8 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }7 - end of user information field
00 00 }6 - end of RLRE
00 00 }5 - end of single asn.1-type
00 00 }4 - end of PDV-list
00 00 }3 - end of Presentation userdata
- セッションDISCONNECT SPDU 0A Ls、10、1--SI=DISCONNECT C1 Ls、2--利用者データ--P-RELEASE rsp PPDU61 80、3--APPLICATION1、利用者データ; 30 80を完全にコード化します; 4--SEQUENCE PDV-リスト02 01 01--セットアップA0 80から覚えていられたACSEのためのINTEGER pcid、5--0がasn.1-タイプ--1RELEASEの応答APDU--RLRE63 80を選抜する、6--APPLICATION3はRLRE80 01 00--0理由を特定して、値0は標準*La?意味します(Group Iのために、必要ではありません)(ユーザ情報フィールドが必要であるかもしれません); --、7--ユーザ情報フィールド00 00が{8--EXTERNAL--転送構文oidはこれがアプリケーション--データ--A0 La xxxxx(0つの独身のASN.1がタイプしているアプリケーションデータ)のためのpcid(6.1の終わりで注意を見る)であるこの時間--02 01 03--INTEGERのときに存在していません--00 00}という7--30IMPLICIT SEQUENCE--28 80 8--EXTERNALの端--数個のEXTERNALSが多分あるかもしれないたぶんコネ--異なったプレゼンテーション文脈(異なったpcids)?80が00 00であったなら終わりになってください6--RLRE00 00を終わらせてください、5--ただ一つのasn.1-タイプ00 00を終わらせてください、4; - PDV-リスト00の終わり、00、3--Presentation userdataを終わらせてください。
6.7 Deliberate abort
6.7 慎重なアボート
It is not clear whether this is any use - just clearing the Transport connection will be more effective. It goes on T-DATA, but asks for the far-side to close the T-connection.
これが使用であるかどうかはどんな明確ではありません--ただTransport接続をきれいにするのは、より効果的でしょう。 それは、T-DATAに行きますが、反対側がT-接続を終えるように頼みます。
- Session ABORT SPDU
19 Ls {1 - SI of 25 is ABORT
11 01 03 - Transport Disconnect PV, code 17
-- value = '...00011'b means please
-- release T-conn, user abort
* Ls ?
C1 11 {2 - Session User Data
- '{1--25のSIはABORT11 01 03です--Disconnect PVを輸送してください、コード17--値='というセッションABORT SPDU19Ls…00011'b手段は喜ばせます--ユーザアボート*Ls?T-コン、C1 11をリリースしてください、2--、セッションUser Data、'
Furniss [Page 25] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[25ページ]RFC1698ThinOSI
- P-U-ABORT PPDU - ARU
A0 80 {3 - [0] implicit sequence for normal mode
A0 80 {4 - [0] presentation-context-identifier-list
30 80 {5 - [SEQUENCE]
02 01 01 - [INTEGER]pcid for ACSE
06 02 5101 - [OID] for acse transfer syntax = BER
00 00 }5
-- there will be one {6} group for each application
-- presentation context that is used in this message
-- if there is no user data, the {6} group can be
-- omitted
30 80 {6
02 01 03 - [INTEGER] pcid for application data
06 La xxxxxx - [OID] transfer syntax for application data
00 00 }6
00 00 }4 - end of presentation-context-identifier-list
61 80 {7 - [APPLICATION 1], user data, fully-encoded
30 80 {8 - [SEQUENCE] PDV-list
02 01 01 - [INTEGER] pcid for ACSE as on CP PPDU
A0 05 {9 - [0] single asn.1-type
- A-ABORT APDU - ABRT
64 80 {10 - [APPLICATION 4] identifies ABRT
80 01 01 - [0] value 1 is acse-service-provider
-- the user information field may or may not be required
?BE 80 {11 - [30] IMPLICIT SEQUENCE
?28 80 {12 - [EXTERNAL]
-- the transfer-syntax oid is not present this time
-- (according to CULR-1)
?02 01 03 - [INTEGER] this is the pcid for the application
- data
?A0 La xxxxx -- [0] single-ASN.1-type application data
-- (see note at end of 6.1)
?00 00 }12 - end of EXTERNAL
-- conceivably there may be several EXTERNALS, probably in
-- different presentation contexts (different pcids)
?00 00 }11 - end of user information field
00 00 }10 - end of ABRT
00 00 }9 - end of single asn.1-type
00 00 }8 - end of PDV-list
00 00 }7 - end of Presentation user-data
00 00 }3 - end of ARU-PPDU
- P-U-ABORT PPDU--、ARU A0 80、正規モードA0 80のための3--0の暗黙の系列; 4--0プレゼンテーション文脈名前の並び、30 80、5、--、SEQUENCE02 01 01--ACSE06 02 5101のためのINTEGERpcid--acse転送構文のためのOIDがBER00 00と等しい各アプリケーションあたり1つ人6のグループがあるでしょう--利用者データが全くなければこのメッセージで使用されるプレゼンテーション文脈、6グループがそうであることができるという5が30 80を省略した、6、02 01 03、--、アプリケーションデータのためのINTEGER pcid、06La xxxxxx、--、OIDがアプリケーションデータ00 00のために構文を移す6、00 00、4; - プレゼンテーション文脈名前の並び61 80の終わり、7--APPLICATION1; 利用者データであって、完全にコード化される、30 80、8--SEQUENCE PDV-リスト02 01 01--オン同じくらいACSEのためのINTEGER pcid、CP PPDU A0 05、9--0はasnを選抜します; 1タイプ--1ABORT APDU--のABRT64 80、10--APPLICATION4はABRT80 01 01を特定します--0値1はacse-サービスプロバイダーです; ユーザ情報フィールドが必要であるかもしれません--80になってください、11--30IMPLICIT SEQUENCE--28 80、12--EXTERNAL--転送構文oidはpresenではありません。今回のt--(CULR-1) --02 01 03--INTEGERによると、これはアプリケーション--データ--A0 La xxxxx(0つの独身のASN.1がタイプしているアプリケーションデータ)のためのpcid(6.1の終わりで注意を見る)です--00 00}という12--EXTERNALの端--多分、数個のEXTERNALS(たぶんコネ)があるかもしれません; 異なったプレゼンテーション文脈(異なったpcids)?00 00、11--ユーザ情報フィールド00 00を終わらせてください、10--ABRT00 00を終わらせてください、9--ただ一つのasn.1-タイプ00 00を終わらせてください、8--PDV-リスト00 00を終わらせてください、7--Presentation利用者データ00 00を終わらせてください、3--アルー諸島-PPDUを終わらせてください。
Furniss [Page 26] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[26ページ]RFC1698ThinOSI
6.8 Provider abort
6.8 プロバイダーアボート
Generated when an internal error occurs (i.e., something has gone mildly (?) wrong in the cookbook implementation). Rather than accuse anyone of protocol errors, we just abort at session.
内部エラーが起こるとき、発生する、(すなわち、何かが穏やかに行った、料理の本実現における(?)悪事) むしろ、私たちはセッションのときにプロトコル誤りでだれでも起訴するよりただ中止になります。
ABORT SPDU
19 03 {1 - SI=25 = ABORT SPDU
11 01 09 - Transport Disconnect PV, code 17
-- value = '...01001'b release T-conn
-- no reason
* Ls ?
'{1--SI=25はABORT SPDU11 01 09と等しいです--Disconnect PVを輸送してください、コード17--値='… 01001'bリリースT-コン--というABORT SPDU19 03ノー理由*Ls?'
6.9 Abort accept
6.9アボートは受け入れます。
If a Session abort (of any kind) is sent, it is possible that the far-end will send back an abort accept. If this happens, disconnect the transport. (The abort messages above do not propose that the transport connection be reused, and in this case, an abort accept is just the far-end passing the transport-disconnect initiative back.) This session message need never be sent - just disconnect transport on receiving an abort.
Sessionアボート(どんな種類のも)を送るなら、遠端がアボートが受け入れる後部を送るのは、可能です。 これが起こるなら、輸送を外してください。 上記のアボートメッセージは提案しません。(輸送接続がこの場合再利用されて、アボートが受け入れるのが、ただ輸送分離イニシアチブを戻す遠端である、) このセッションメッセージを決して送ってはいけません--ただアボートを受けるときの輸送を外してください。
ABORT ACCEPT SPDU
1A 00 . - SI=26 = ABORT ACCEPT SPDU, no parameters
ABORT ACCEPT SPDU 1A00--SI=26=ABORT ACCEPT SPDU、パラメタがありません。
7. References
7. 参照
[CULR-1] ISO/IEC DISP 11188-1 - Information Technology - International Standardised Profile - Common Upper Layer Requirements - Part 1: Basic Connection oriented requirements (DISP ballot ends June 1994).
国際[CULR-1]ISO/IEC DISP11188-1(情報技術)はプロフィール--一般的な上側の層の要件--第1部を標準化しました: 基本的なConnectionは要件を適応させました(DISPは1994年6月に終わりに投票します)。
[CULR-3] Draft of Common Upper-layer requirements - Part 3: Minimal OSI upper layers facilities (A later draft will be proposed as ISP 11188/3).
Common Upper-層の要件の[CULR-3]草稿--パート3: 最小量のOSI上側の層の施設(後の草稿はISP11188/3として提案されるでしょう)。
[ISO8072] Information processing systems - Open Systems Interconnection - Transport service definition; ISO, 1986.
[ISO8072]情報処理システム--オープン・システム・インターコネクション--Transportは定義を修理します。 ISO、1986。
[ISO8073] Information processing systems - Open Systems Interconnection - Transport protocol specification; ISO, 1986.
[ISO8073]情報処理システム--オープン・システム・インターコネクション--Transportは仕様を議定書の中で述べます。 ISO、1986。
[ISO8326] Information processing systems - Open Systems Interconnection - Basic connection oriented session service definition; ISO, 1987 (or review copy of revised text = ISO/IEC JTC1/SC21 N4657, April 1990).
[ISO8326]情報処理システム--オープン・システム・インターコネクション--基本接続はセッション・サービス定義を適応させました。 ISO、1987(または、ISO/IEC JTC1/SC21 N4657、1990年校訂本=4月の書評用献本)。
Furniss [Page 27] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[27ページ]RFC1698ThinOSI
[ISO8327] Information processing systems - Open Systems Interconnection - Basic connection oriented session protocol specification; ISO, 1987 (or review copy of revised text = ISO/IEC JTC1/SC21 N4656, April 1990).
[ISO8327]情報処理システム--オープン・システム・インターコネクション--基本接続はセッションプロトコル仕様を適応させました。 ISO、1987(または、ISO/IEC JTC1/SC21 N4656、1990年校訂本=4月の書評用献本)。
[ISO8649] Information processing systems - Open Systems Interconnection - Service definition for the Association Control Service Element; ISO, 1989.
[ISO8649]情報処理システム(オープン・システム・インターコネクション)はアソシエーション制御サービス要素のために定義を修理します。 ISO、1989。
[ISO8650] Information processing systems - Open Systems Interconnection - Protocol specification for the Association Control Service Element; ISO, 1989.
[ISO8650]情報処理システム--オープン・システム・インターコネクション--アソシエーション制御サービス要素のためのプロトコル仕様。 ISO、1989。
[ISO8822] Information processing systems - Open Systems Interconnection - Connection-oriented presentation service definition; ISO, 1989.
[ISO8822]情報処理システム--オープン・システム・インターコネクション--接続指向のプレゼンテーション・サービス定義。 ISO、1989。
[ISO8823] Information processing systems - Open Systems Interconnection - Connection-oriented presentation protocol specification; ISO, 1989.
[ISO8823]情報処理システム--オープン・システム・インターコネクション--接続指向のプレゼンテーションプロトコル仕様。 ISO、1989。
[ISO8824] Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), ISO/IEC 1990.
[ISO8824]情報技術--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、ISO/IEC1990年の仕様。
[ISO8825] Information technology - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One, ISO/IEC 1990.
[ISO8825]情報技術--オープン・システム・インターコネクション--抽象的なSyntax Notation One、ISO/IEC1990年のBasic Encoding Rulesの仕様。
[RFC1006] Rose, M., and D. Cass, "ISO Transport Services on Top of the TCP", STD 35, RFC 1006, Northrop Research and Technology Center, May 1987.
[RFC1006] RFC1006、ノースロップのローズ、M.、D.キャス、「TCPの上のISO輸送サービス」、STD35、研究、および技術センターは1987がそうするかもしれません。
[ISO9594] Information technology - Open Systems Interconnection - The Directory; ISO/IEC, 1990.
[ISO9594]情報技術--オープン・システム・インターコネクション--ディレクトリ。 ISO/IEC、1990。
[RFC 1274] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema", RFC 1274, University College London, November 1991.
RFC1274、ユニバーシティ・カレッジロンドン1991年11月の[RFC1274]のバーカー、P.、S.Kille、および「コサインとインターネットX.500図式」
8. Other Notes
8. 他の注意
The Session, Presentation and ACSE standards have been the subject of considerable amendment since their first publication. The only one that is significant to this cookbook is Session addendum 2, which specifies session version 2 and unlimited user data. New editions of these standards, incorporating all the amendments, will be published during 1994.
Session、Presentation、およびACSE規格はそれらの最初の公表以来のかなりの修正の対象です。 この料理の本に重要な唯一無二はSession付加物2です。(その付加物はセッションバージョン2と無制限な利用者データを指定します)。 すべての修正を取り入れて、これらの規格の新版は1994の間、発行されるでしょう。
Furniss [Page 28] RFC 1698 ThinOSI Upper-Layers Cookbook October 1994
料理の本1994年10月の上側の層のファーニス[28ページ]RFC1698ThinOSI
The coding choices made in the cookbook are (nearly) those made by the "Canonical Encoding Rules", which are a form of Basic Encoding Rules with no optionality, specified in the new edition of ISO/IEC 8825. A defect report has been proposed against Presentation and ACSE, suggesting that a note to the protocol specifications recommend use of the canonical encoding options when sending, and then optimising for this on receipt.
料理の本でされたコード化選択は(ほとんど)ISO/IEC8825の新版で指定されたoptionalityのないBasic Encoding Rulesのフォームである「正準な符号化規則」で作られたものです。 不具合報告はPresentationとACSEに対して提案されました、プロトコル仕様への注意はこれのために領収書における発信するときの正準なコード化オプションの使用を推薦して、次に、最適化を推薦するのを示して。
9. Security Considerations
9. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
10. Author's Address
10. 作者のアドレス
Peter Furniss Peter Furniss Consultants 58 Alexandra Crescent Bromley, Kent BR1 4EX UK
ピーターファーニスピーターファーニスコンサルタント58アレクサンドラ三日月ブロムリー、ケントBR1 4EXイギリス
Phone & Fax +44 81 313 1833 EMail: P.Furniss@ulcc.ac.uk
+44 1833年の81 313メールに電話をして、ファックスで送ってください: P.Furniss@ulcc.ac.uk
Furniss [Page 29]
ファーニス[29ページ]
一覧
スポンサーリンク
