RFC841 日本語訳
0841 Specification for message format for Computer Based MessageSystems. National Bureau of Standards. January 1983. (Format: TXT=231871 bytes) (Obsoletes RFC0806) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
RFC 841
RFC841
FIPS Pub 98
FIPSパブ98
SPECIFICATION FOR MESSAGE FORMAT FOR COMPUTER
BASED MESSAGE SYSTEMS
コンピュータのベースのメッセージシステムのためのメッセージ・フォーマットのための仕様
27 January 1983
1983年1月27日
National Bureau of Standards
規格基準局
This RFC is FIPS 98. The purpose of distributing this document
as an RFC is to make it easily accesible to the ARPA research
community. This RFC does not specify a standard for the ARPA
Internet.
このRFCはFIPS98です。 RFCとしてこのドキュメントを配布する目的はそれを容易にARPA研究団体へのaccesibleにすることです。 このRFCはARPAインターネットの規格を指定しません。
TABLE OF CONTENTS
目次
Page
ページ
EXECUTIVE SUMMARY 5
要約5
1. INTRODUCTION 7
1. 序論7
1.1 Guide to Reading This Document 7
1.2 Vendor-Defined Extensions to the Specification 8
1.3 The Scope of the Message Format Specification 8
1.4 Issues Not Within the Scope of the Message Format 8
Specification
1.5 Relationship to Other Efforts 9
1.1が仕様への1.2のベンダーによって定義された拡大をこのドキュメント7を読むのに誘導する、8、1.3、メッセージ書式仕様8 1.4のものの範囲は中でないところで他の取り組み9とのメッセージ・フォーマット8仕様1.5関係の範囲を支給します。
2. A SIMPLE MODEL OF A CBMS ENVIRONMENT 10
2. CBMS環境10の単純モデル
2.1 Logical Model of a CBMS 12
2.2 Relationship to the ISO Reference Model for Open 14
Systems Interconnection
2.3 Messages and Fields 14
2.4 Message Originators and Recipients 15
CBMSの2.1の論理的なモデル、12、2.2関係、14台の開いているシステムインタコネクト2.3メッセージと分野14 2.4メッセージ創始者と受取人15のためのISO規範モデル
3. SEMANTICS 17
3. 意味論17
3.1 Semantics of Message Fields 17
3.1.1 Types of fields 17
3.1.2 Semantic Compliance Categories 18
3.1.3 Originator fields 18
3.1.4 Recipient fields 19
3.1.5 Date fields 20
3.1.6 Cross-reference fields 21
3.1.7 Message-handling fields 22
3.1.8 Message-content fields 23
3.1.9 Extensions 23
3.1 分野17 3.1.2Semantic Compliance Categories18 3.1.3のOriginator分野18 3.1.4のRecipient分野19 3.1.5Date分野20 3.1.6のMessageフィールズ17 3.1.1Typesの意味論は分野21 3.1に.7のMessage-取り扱い分野22 3.1.8のMessage-内容分野23 3.1.9Extensions23にCross参照をつけます。
i
i
3.2 Message Processing Functions 24
3.2.1 Message creation and posting 24
3.2.2 Message reissuing and forwarding 25
3.2.2.1 Redistribution 26
3.2.2.2 Assignment 28
3.2.3 Reply generation 28
3.2.4 Cross-referencing 29
3.2.4.1 Unique identifiers 29
3.2.4.2 Serial numbering 30
3.2.5 Life span functions 30
3.2.6 Requests for recipient processing 31
3.2.6.1 Message circulation 31
3.3 Multiple Occurrences and Ordering of Fields 31
3.2 フィールズ31の受取人処理31 3.2.6.1Message流通31 3.3Multiple OccurrencesとOrderingのためのCrossに参照をつけたメッセージProcessing Functions24 3.2の.1Message作成と任命24の3.2の.2のMessage再発行と推進25 3.2.2.1Redistribution26 3.2.2.2Assignment28 3.2の付番30 3.2.5.3Reply世代28 3.2.4 29 3.2.4.1のUnique識別子29 3.2.4.2Serial Life長さ機能30 3.2.6Requests
4. SYNTAX 34
4. 構文34
4.1 Introduction 34
4.1.1 Message structure 34
4.1.2 Data elements 35
4.1.2.1 Primitive data elements 36
4.1.2.2 Constructor data elements 36
4.1.3 Properties 36
4.1.3.1 Printing-names 37
4.1.3.2 Comments 37
4.1.4 Data compression and encryption 37
4.2 Overview of Syntax Encoding 37
4.2.1 Identifier Octets 38
4.2.2 Length code and Qualifier components 39
4.2.2.1 Length Codes 41
4.2.2.2 Qualifier 42
4.2.3 Property-List 44
4.2.4 Data Element Contents 44
4.3 Data Element Syntax 44
4.3.1 Data elements 45
4.3.1.1 Primitives 47
4.3.1.2 Constructors 49
4.3.1.3 Data Elements that Extend this Speci- 52
fication
4.3.2 Using data elements within message fields 53
4.3.3 Properties and associated elements 54
4.3.4 Encryption identifiers 54
4.3.5 Compression identifiers 54
4.3.6 Message types 55
4.1序論34 4.1に、.1Messageが4.1に34 4.1.2のData要素35 4.1.2.1のPrimitiveデータ要素36 4.1.2.2Constructorデータ要素36 4.1.3Properties36 4.1.3.1Printing-名前37 4.1.3.2Comments37を構造化する、.4のData圧縮と暗号化、37、4.2Overview、Syntax Encoding37 4.2.1Identifier Octets38 4.2.2LengthコードとQualifierコンポーネント39 4.2.2.1Length Codes41 4.2.2.2Qualifier、42、4; 2.3、44 4.2.4Data Element Contents44 4.3Data Element Syntax44 4.3.1Data要素45 4.3.1.1Primitives47 4.3.1.2Constructors49が4.3に特性で記載する、.1、.3Data Elements、そのExtend、4.3の.2Usingデータ要素が中で通信させるこのSpeci52ficationは53 4.3の.3Propertiesと関連要素54 4.3.4のEncryption識別子54 4.3.5Compression識別子54 4.3.6のMessageタイプ55をさばきます。
ii
ii
SUMMARY OF APPENDIXES 56
付属物56の概要
APPENDIX A. FIELDS -- IMPLEMENTORS' MASTER REFERENCE 57
付録A.分野--作成者のマスター参照57
APPENDIX B. DATA ELEMENTS -- IMPLEMENTORS' MASTER REFERENCE 63
付録B.データ要素--作成者のマスター参照63
APPENDIX C. DATA ELEMENT IDENTIFIER OCTETS 71
付録C.データ要素識別子八重奏71
APPENDIX D. SUMMARY OF MESSAGE FIELDS BY COMPLIANCE CATE- 72
GORY
承諾美味72による血まみれのメッセージ分野の付録D.概要
D.1 REQUIRED Fields 72
D.2 BASIC Fields 72
D.3 OPTIONAL Fields 72
D.1必須項目72D.2基礎体72のD.3の任意の分野72
APPENDIX E. SUMMARY OF MESSAGE SEMANTICS BY FUNCTION 74
機能74によるメッセージ意味論の付録E.概要
E.1 Circulation 74
E.2 Cross-Referencing 74
E.3 Life Spans 74
E.4 Delivery System 74
E.5 Miscellaneous Fields Used Generally 75
E.6 Reply Generation 75
E.7 Reissuing 75
E.8 Sending (Normal Transmission) 75
E.1流通74E.2 74の十字に参照をつけたE.3寿命74E.4配送システム74のE.5の種々雑多な分野は、75を送りながら(通常のトランスミッション)、一般に75E.6回答世代75の間のE.7再発行75E.8を使用しました。
APPENDIX F. SUMMARY OF DATA ELEMENT SYNTAX 76
データ要素構文76の付録F.概要
APPENDIX G. SUMMARY OF DATA ELEMENTS BY COMPLIANCE CATEGORY 78
承諾カテゴリ78によるデータ要素の付録G.概要
G.1 BASIC Data Elements 78
G.2 OPTIONAL Data Elements 78
G.1基礎データ要素78のG.2の任意のデータ要素78
iii
iii
APPENDIX H. EXAMPLES 80
付録H.の例80
H.1 Primitive Data Elements 80
H.2 Constructor Data Elements 82
H.3 Data Elements that Extend this Specification 87
H.4 Fields 88
H.5 Messages 90
H.6 Unknown Lengths 94
H.7 Message Encoding Using Vendor-Defined Fields 97
H.7.1 Example of a JANAP-128 Message 97
H.7.2 Encoding of Example using the FIPS Message 97
Format
H.7.3 Field Mappings of JANAP-128 to FIPS Format 101
H.7.4 Vendor-Defined Fields 101
Elements H.1の原始のData H.3 Data H.2 Constructor Data Elements Elements80、82そのExtend、FIPS Format101のH.7.4 Vendorによって定義されたフィールズ101にJANAP-128のFIPS Message97Format H.7.3 Field Mappingsを使用するExampleのJANAP-128 Message97H.7.2 EncodingのこのSpecification87のH.4のフィールズの88H.5 Messages90のH.6 Unknown Lengths94のH.7 Message Encoding Using Vendorによって定義されたフィールズ97H.7.1 Example
REFERENCES 103
参照103
INDEX 105
インデックス105
iv
iv
LIST OF FIGURES
数字のリスト
FIG. 1. LOGICAL MODEL OF A COMPUTER-BASED MESSAGE SYSTEM 12
FIG. 2. MESSAGE FORWARDING AND REDISTRIBUTION 27
FIG. 3. EXAMPLE OF MESSAGE CIRCULATION 32
FIG. 4. STRUCTURE OF IDENTIFIER OCTETS 39
FIG. 5. ENCODING MECHANISM FOR QUALIFIERS AND LENGTH 40
CODES
FIG. 6. REPRESENTATION OF LENGTH CODES 42
FIG. 7. EXAMPLES OF QUALIFIER VALUES 43
図 1. コンピュータベースのメッセージシステム12図の論理的なモデル 2. メッセージ推進と再分配27図 3. メッセージ流通32図に関する例 4. 識別子八重奏39図の構造 5. 資格を与える人のためにメカニズムをコード化して、そして、長さ40は図をコード化します。 6. 長さの表現は42図をコード化します。 7. 資格を与える人値43に関する例
v
v
LIST OF TABLES
テーブルのリスト
TABLE 1. FIELDS USED IN MESSAGE PROCESSING FUNCTIONS 24
TABLE 2. HIGH-ORDER BITS IN THE IDENTIFIER OCTET 39
1を見送ってください。 分野はメッセージ処理機能に24テーブル2を使用しました。 識別子八重奏39における高位のビット
vi
vi
Federal Information
Processing Standards Publication 98
27 January 1983
Announcing the Standard for
連邦政府情報処理規格公表98 1983年1月27日の発表、標準
MESSAGE FORMAT
FOR
COMPUTER BASED MESSAGE SYSTEMS
コンピュータのベースのメッセージシステムのためのメッセージ・フォーマット
Federal Information Processing Standards Publications are issued
by the National Bureau of Standards pursuant to section 111(f)(2)
of the Federal Property and Administrative Services Act of 1949,
as amended, Public Law 89-306 (79 Stat. 1127), Executive Order
11717 (38 FR 12315, dated May 11, 1973), and Part 6 of Title 15
Code of Federal Regulations (CFR).
1949年の連邦政府のPropertyとAdministrative Services条例のセクション111(f)(2)によると、連邦政府の情報Processing Standards Publicationsは規格基準局によって発行されます、修正されるように、Public法89-306(79スタット。 1127), 大統領令11717(1973年5月11日付けの38FR12315)、およびTitle15連邦規制基準のPart6(CFR)。
Name of Standard. Message Format for Computer Based Message
Systems (FIPS PUB 98).
規格の名前。 コンピュータのためのメッセージ・フォーマットはメッセージシステム(FIPSパブ98)を基礎づけました。
Category of Standard. Software Standard; Interchange Codes, Media
and Data Files.
規格のカテゴリ。 ソフトウェア規格。 コード、メディア、およびデータファイルを交換してください。
Explanation. This standard separates information so that a
Computer Based Message System can locate and operate on that
information (which is found in the fields of messages). This is
the first of a family of standards which will ensure information
interchange among Computer Based Message Systems.
説明。 この規格は、コンピュータBased Message Systemがその情報(メッセージの野原で発見される)を場所を見つけて、作動させることができるように、情報を切り離します。 これはコンピュータBased Message Systemsの中で情報交換を確実にする規格のファミリーの1番目です。
Approving Authority. Secretary of Commerce
権威を承認します。 商務長官
Maintenance Agency. Department of Commerce, National Bureau of
Standards (Institute for Computer Sciences and Technology).
メインテナンス代理店。 商務省、規格基準局(コンピューターサイエンシズと技術のために、設けます)。
Cross Index. Not Applicable.
インデックスに交差してください。 適切でない。
Related Documents.
関連ドキュメント。
a. American National Standard Code for Information
Interchange (ASCII), X3.4-1977,FIPS PUBS 1-1.
a。 情報交換用米国標準コード(ASCII)、X3.4-1977、FIPSパブ1-1。
b. American National Standard Code Extension Techniques
for Use with the 7-bit Coded Character Set of American
National Standard Code (ASCII) for Information
Interchange, X3.41-1974, FIPS PUB 35.
b。 米国標準規格の7ビットのコード化文字集合との使用のための米国標準規格コード拡張のテクニックは情報交換のために(ASCII)をコード化します、X3.41-1974、FIPSパブ35。
c. National Bureau of Standards. Calendar Date. Federal
Information Processing Standards Publication 4, U.S.
c。 規格基準局。 カレンダ日付。 公表4、連邦政府の情報処理Standards米国
1
1
Department of Commerce / National Bureau of Standards,
November, 1968.
1968年11月の商務省/規格基準局。
d. National Bureau of Standards. Data Encryption Standard.
Federal Information Processing Standards Publication
46, U.S. Department of Commerce/National Bureau of
Standards, January, 1977.
d。 規格基準局。 データ暗号化規格。 連邦政府の情報処理規格公表46、米国商務省/規格基準局、1月、1977
e. National Bureau of Standards. Representation of Local
Time of the Day for Information Interchange. Federal
Information Processing Standards Publication 58, U.S.
Department of Commerce / National Bureau of Standards,
February 1979.
e。 規格基準局。 情報交換のための日の現地時間の表現。 連邦政府の情報処理規格公表58、米国商務省/規格基準局、2月1979日
f. National Bureau of Standards. Representation of
Universal Time, Local Time Differentials, and United
States Time Zone References for Information
Interchange. Federal Information Processing Standards
Publication 59, U.S. Department of Commerce / National
Bureau of Standards, February, 1979.
f。 規格基準局。 時間帯が情報交換のために参照をつけるLocal Timeの世界標準時の表現、デフ装置、および合衆国。 連邦政府の情報処理規格公表59、米国商務省/規格基準局、2月、1979
Applicability. This message format standard applies to Federal
departments and agencies in their acquisition and use of
computer-based message systems (CBMS) and services in networked
systems, except for certain single-processor systems.
Specifically, the standard does not apply to a CBMS if it is a
stand-alone system which is not interconnected with any other
CBMS: nevertheless, conformance with the standard is recommended
under these circumstances particularly if there is a possibility
that use of another central processing unit, or interconnection
with another system, will be required in the future. Where a new
CBMS node is incorporated into an existing network, the standard
applies at the interface between CBMS's. In this instance,
previously existing nodes may accommodate the standard either
through retrofit or by the use of a translator. In addition,
networks that are established strictly for the purpose of
supporting research in computer science or communications are
exempt from complying with this standard.
適用性。 このメッセージ・フォーマット規格は彼らの獲得における連邦政府の部局とコンピュータベースのメッセージシステム(CBMS)の使用とある単一のプロセッサシステム以外のネットワークでつながれたシステムにおけるサービスに適用されます。明確に、規格はそれがいかなる他のCBMSと共にもインタコネクトされないスタンド・アローン・システムであるならCBMSに適用されません: それにもかかわらず、特に別の中央演算処理装置の使用、または別のシステムがあるインタコネクトが将来必要である可能性があれば、規格がある順応はこういう事情ですからお勧めです。 新しいCBMSノードが既存のネットワークに組み入れられるところでは、規格はCBMSのところの間のインタフェースで適用されます。 この場合、以前に既存のノードは改装を通して、または、翻訳者の使用で規格を収容するかもしれません。 さらに、コンピュータサイエンスかコミュニケーションにおける研究をサポートする目的のために厳密に設立されるネットワークは、この規格に従うので、免除されています。
Subcommittee TC97/SC16 of the International Organization for
Standardization (ISO) has developed a reference model for
describing communications between "open" systems. (ISO/TC97/SC16
DIS7498) This model is known as the ISO Reference Model for Open
Systems Interconnection (OSI). It divides communications
protocols into seven layers, ranging from physical
interconnection at the lowest layer to data exchange by
applications programs at the top.
国際標準化機構(ISO)の小委員会TC97/SC16は、「開いている」システムのコミュニケーションについて説明するために規範モデルを開発しました。この(ISO/TC97/SC16 DIS7498)モデルはオープン・システム・インターコネクション(OSI)のためのISO Reference Modelとして知られています。 それは通信規約を7つの層に分割します、先端のアプリケーションプログラムで最も低い層での物理的なインタコネクトからデータ交換まで及んで。
The NBS message format deals with data used by an application
within a system; it is not a protocol. Messages defined by the
NBSメッセージ・フォーマットはシステムの中でアプリケーションで使用されたデータに対処します。 それはプロトコルではありません。 メッセージは定義しました。
2
2
NBS message format would be manipulated by a layer 7
(Application) protocol.
NBSメッセージ・フォーマットは層7(アプリケーション)のプロトコルによって操られるでしょう。
A message as referenced by the NBS message format is a unit of
communication from an originator to a recipient, exclusive of any
message heading or control information (often referred to as a
message envelope). An originator and recipient are typically
people but may be roles or processes. A role identifies a
function within an organization as opposed to an individual who
performs that function. A process refers to a computer process
that might originate or receive a message.
参照をつけられるとしてのNBSメッセージ・フォーマットによるメッセージは創始者から受取人までのコミュニケーションのユニットです、どんなメッセージ見出しや制御情報(しばしばメッセージ封筒と呼ばれる)を除いて。 創始者と受取人は通常人々ですが、役割かプロセスが人々です。 役割はその機能を実行する個人と対照的に組織の中で機能を特定します。 プロセスはメッセージを溯源するか、または受け取るかもしれないコンピュータプロセスについて言及します。
Special Information. Certain characteristics distinguish a CBMS
from other systems for sending messages. Originators and
recipients may be terminal users or processes (discrete
software). A system in which the originator addresses a
particular terminal device rather than a particular recipient is
not considered to be a CBMS. The recipient's system need not be
available when the originator sends a message. The message can
be stored in the originator's system or at an intermediate node
in the network until the recipient's system becomes available.
In addition, a CBMS offers both message creation and message
processing facilities as part of the system. A CBMS offers text
editing facilities to assist the user in the preparation of a
message. The recipient CBMS stores the message until the
recipient chooses to read it. Message systems which do not
provide these minimum functions are not considered CBMS's.
特別な情報。 ある特性は送付メッセージの他のシステムとCBMSを区別します。 創始者と受取人は端末ユーザであるかもしれませんかプロセスが(離散的なソフトウェア)です。 創始者が特定の受取人よりむしろ特定の端末装置を扱うシステムはCBMSであると考えられません。創始者がメッセージを送るとき、受取人のシステムは利用可能である必要はありません。 受取人のシステムが利用可能になるまで、創始者のシステム、または、ネットワークにおける中間的ノードにメッセージを保存できます。 さらに、CBMSはシステムの一部としてメッセージ作成とメッセージ処理施設の両方を提供します。 CBMSは、メッセージの準備にユーザを助けるためにテキスト編集施設を提供します。 受取人が、それを読むのを選ぶまで、受取人CBMSはメッセージを保存します。 これらの最小の機能を提供しないメッセージシステムはCBMSのものであると考えられません。
The intent of the message format standard is to allow users of
different computer based message systems to send messages to each
other. The standard does not make demands on the message
transfer system except that it transports messages transparently.
The standard makes some simple demands on the CBMS. The CBMS
must recognize fields within the message, process fields in
predetermined ways, create messages in the correct form, and
recognize and create data elements of messages in the correct
format. The standard does not dictate or constrain the services
that the CBMS provides for users, or the way that messages are
stored, represented, manipulated, or presented to the user by the
CBMS.
メッセージ・フォーマット規格の意図はメッセージを互いに送るために異なったコンピュータのユーザにベースのメッセージシステムを許容することです。 透過的にメッセージを輸送する以外に、規格はメッセージ転送システムを要求しません。 規格はCBMSにおけるいくつかの簡単な要求をします。CBMSは、メッセージの中の分野(予定された方法でプロセス分野)が正しい書式でメッセージのデータ要素を訂正用紙でメッセージを作成して、認識して、作成すると認めなければなりません。 規格は、CBMSがユーザに提供するサービス、またはメッセージがCBMSによってユーザに保存されるか、表されるか、操られるか、または提示される方法を決めもしませんし、抑制もしません。
The standard does constrain the format of the message at the
interface between systems. This guarantees that, whatever the
source of the message, it arrives at the receiving system in the
standard format. The message format standard separates
information into fields so that the CBMS can locate and operate
on that information. The message is converted from the format
used within the originator's CBMS to the standard format (if
different) on leaving the originator's CBMS. The message is
converted from the standard format to the format used within the
recipient's CBMS (if different) on entering the recipient's CBMS.
規格はシステムの間のインタフェースでメッセージの形式を抑制します。これは、それがメッセージの源が何であっても標準書式で受電方式に到着するのを保証します。 メッセージ・フォーマット規格は、CBMSがその情報を場所を見つけて、作動させることができるように、分野に情報を切り離します。 メッセージは創始者のCBMSを残すときの標準書式に創始者のCBMSの中で中古の、そして、(異なる)の形式から変換されます。メッセージは標準書式から受取人のCBMSに入るときの受取人のCBMSの中で中古の、そして、(異なる)の形式まで変換されます。
3
3
Specifications. Federal Information Processing Standard (FIPS),
Message Format for Computer Based Message Systems (affixed).
仕様。 連邦情報処理基準(FIPS)、コンピュータのためのメッセージ・フォーマットはメッセージシステム(付けられる)を基礎づけました。
Qualifications. None
資格。 なし
Implementation Schedule. All applicable equipment or services
ordered on or after 24 months from the date of issuance of this
FIPS PUB, and all CBMS development initiated inhouse on or after
12 months from the date of issuance of this FIPS PUB must be in
conformance with this standard unless a waiver has been obtained
in accordance with the procedure described below. An exception
to this standard is made when procurement actions are into the
solicitation phase on the date of issuance of this FIPS PUB.
遂行スケジュール。 カ月かこのFIPS PUBの発行の期日、およびすべてのCBMS開発の開始している「不-家」から24カ月か以下で説明された手順に応じて権利放棄が得られていない場合このFIPS PUBの発行の日付から12カ月が順応この規格と共に中になったに違いない後にすべての適切な設備かサービスが注文されました。 このFIPS PUBの発行の日付の懇願フェーズには調達動作があるとき、この規格への例外は作られます。
Waivers. Heads of agencies may request that the requirements of
this standard be waived in instances where it can be clearly
demonstrated that there are appreciable performance or cost
advantages to be gained and that the overall interests of the
Federal Government are best served by granting the requested
waiver. Such waiver requests will be reviewed by and are subject
to the approval of the Secretary of Commerce. The waiver request
must address the criteria stated above as the justification for
the waiver.
権利放棄。 政府機関のヘッズは、この規格の要件がかなりの性能か獲得されるべき費用利点があるのを明確に示すことができて、要求された権利放棄を承諾することによって連邦政府の総合的な関心に最も良い役立つインスタンスで放棄されるよう要求するかもしれません。そのような権利放棄要求は、論評されて、商務長官の承認を必要としています。 権利放棄要求は権利放棄のための正当化として上に述べられた評価基準を扱わなければなりません。
Forty-five days should be allowed for review and response by the
Secretary of Commerce. Waiver requests shall be submitted to the
Secretary of Commerce, Washington, D.C. 20230, and labeled as a
Request for a Waiver to a Federal Information Processing
Standard. No agency shall take any action to deviate from the
standard prior to the receipt of a waiver approval from the
Secretary of Commerce. No agency shall begin any process of
implementation or acquisition of non-conforming equipment unless
it has already obtained such approval.
45日間はレビューと応答のために商務長官によって許容されるべきです。 権利放棄要求を商務長官、ワシントンDC20230に提出して、WaiverのためのRequestとして連邦情報処理基準とラベルするものとします。 どんな政府機関も、商務長官からの権利放棄承認の領収書の前で標準から外れるようにどんな行動も取らないものとします。 既にそのような承認を得ていない場合、どんな政府機関も実装のどんなプロセスか非の従う設備の獲得も始めないものとします。
Where to Obtain Copies. Either paper or microfiche copies of this
Federal Information Processing Standard, including technical
specifications, may be purchased from the National Technical
Information Service (NTIS) by ordering Federal Information
Processing Standard Publication (FIPS-PUB-98), Message Format for
Computer Based Message Systems. Ordering information, including
prices and delivery alternatives, may be obtained by contacting
the National Technical Information Service (NTIS), U. S.
Department of Commerce, Springfield, Virginia 22161, telephone
number (703) 487-4650. Payment may be made by check, money
order, purchase order, credit card, or deposit account.
どこで、コピーを入手しますか? 技術情報サービス(NTIS)から連邦情報処理基準Publication(FIPS-PUB-98)(コンピュータBased Message SystemsのためのMessage Format)を注文することによって、技術仕様書を含むこの連邦情報処理基準の紙かマイクロフィッシュコピーのどちらかを購入するかもしれません; (NTIS)、技術情報サービスU.S.商務省、スプリングフィールド、ヴァージニア 22161に連絡することによって、価格と配送代替手段を含む注文情報を得るかもしれません、電話番号(703)487-4650。 支払いはチェック、為替、発注書、クレジットカード、または預金口座によって済まされるかもしれません。
4
Executive Summary
4要約
EXECUTIVE SUMMARY
要約
The message format specification addresses the problem of
exchanging messages between different computer-based message
systems (CBMSs). This interchange problem can be addressed on
several levels. One level specifies the physical inter-
connections, another specifies how information travels between
CBMSs, another specifies form and meaning of messages being
interchanged. The highest level specifies operations on a
message. Each of these levels would be covered by a different
standard.
メッセージ書式仕様は異なったコンピュータベースのメッセージシステム(CBMSs)の間でメッセージを交換するというその問題を訴えます。 いくつかのレベルでこの置き換え問題を扱うことができます。 1つのレベルが物理的な相互接続を指定して、別のものは情報がCBMSsの間をどう移動するかを指定して、別のものは交換されるメッセージのフォームと意味を指定します。 最高水準はメッセージで操作を指定します。 それぞれのこれらのレベルは異なった規格でカバーされているでしょう。
This message format specification addresses only the issues
of form and meaning of messages at the points in time when they
are sent from one CBMS and received by another. Messages are
composed of fields, containing different classes of information.
These fields contain information about the message originator,
message recipient, subject matter, precedence and security, and
references to previous messages, as well as the text of the
message. Standard formats (syntax) for messages provide a basis
for the contents of messages generated by one CBMS to be
processed by another CBMS. Standard meanings (semantics) for the
components of a message facilitate standard interpretation of a
message, so that everyone receiving a message gets the meaning
intended by its sender.
このメッセージ書式仕様はそれらが1CBMSから送られて、別のものによって受け取られる時代の間、ポイントでフォームの問題とメッセージの意味だけを扱います。 異なった情報の種類を含んで、メッセージは分野で構成されます。 これらの分野はメッセージ創始者、メッセージ受取人、内容、先行、およびセキュリティの情報、および前のメッセージの参照を含んでいます、メッセージの本文と同様に。 メッセージのための標準書式(構文)は別のCBMSによって処理されるように1CBMSによって生成されたメッセージのコンテンツの基礎を提供します。メッセージの成分のための標準の意味(意味論)はメッセージの標準の解釈を容易にします、メッセージを受け取る皆が送付者に意味を意図させるように。
Each CBMS that implements this message format specification
will be compatible with any other CBMS that implements the
specification, provided that the use of optional fields and data
elements is negotiated in advance. This ensures that the
contents of a message posted by one CBMS can be received and
interpreted by a different CBMS.
このメッセージ・フォーマットが仕様であると実装するそれぞれのCBMSは仕様を履行するいかなる他のCBMSとも互換性があるでしょう、任意の分野とデータ要素の使用があらかじめ交渉されれば。 これは、異なったCBMSが1CBMSによって掲示されたメッセージのコンテンツを受け取って、解釈できるのを確実にします。
This message format specification has been developed as a
result of examining CBMSs currently in use in commercial and
research environments. Three major design perspectives helped
shape the message format specification.
現在コマーシャルと研究環境で使用中のCBMSsを調べることの結果、このメッセージ書式仕様を開発してあります。 主要なデザイン見解が助けた3はメッセージ書式仕様を形成します。
o Viability. The message format specification uses
concepts that already work. It has been designed with
implementation concerns in mind.
o 生存力。 メッセージ書式仕様は既に働いている概念を使用します。 それは実施にかかわる懸念をもって念頭に設計されています。
o Compatibility. The message format specification
contains concepts from existing CBMSs. For this reason,
many CBMS would already contain functions and components
similar to those required to implement the message
format specification.
o 互換性。 メッセージ書式仕様は既存のCBMSsからの概念を含んでいます。 この理由で、多くのCBMSが既に機能を含んでいるでしょう、そして、それらと同様のコンポーネントがメッセージ書式仕様を実装するのが必要です。
5
Executive Summary
5要約
o Extensibility. This message format specification
defines a broad range of message content components and
requires only an elementary subset of them. This means
that even a very simple CBMS can implement the message
format specification. The message format specification
contains a rich set of optional components and, in
addition, mechanisms for user extensions and future
extensions to the message format specification.
o 伸展性。 このメッセージ書式仕様は、広範囲なメッセージ内容コンポーネントを定義して、それらの基本の部分集合だけを必要とします。 これは、非常に簡単なCBMSさえ、メッセージ・フォーマットが仕様であると実装することができることを意味します。 メッセージ書式仕様はユーザ拡大と今後の拡大のための豊かなセットの任意のコンポーネントとさらに、メカニズムをメッセージ書式仕様に含んでいます。
The message format specification defines the form and
meaning of message contents and their components as they pass
from one CBMS to another through a message transfer system. The
message format specification does not address any of the
following major issues.
メッセージ書式仕様はメッセージ転送システムを1CBMSから別のCBMSまで通るとメッセージ内容とそれらのコンポーネントの書式と意味を定義します。 メッセージ書式仕様は以下の大変な問題のいずれも扱いません。
o Functions or services provided to a user by a CBMS.
For example, the message format specification
assumes that every CBMS allows a user to send and
receive messages. It does not specify any of the
details of how a send function or a message-reading
function might work or how it might appear to the
user. That is, the message format specification
neither limits nor mandates functions.
o 機能かサービスがCBMSによるユーザに前提とされました。例えば、メッセージ書式仕様は、あらゆるCBMSがユーザにメッセージを送って、受け取らせると仮定します。 それはどのようにaが機能を送るか、メッセージを閲読する機能が働くかもしれないか、そして、またはユーザにとってどのように現れるかもしれないかに関する詳細のいずれも指定しません。 すなわち、どちらも制限して、強制しないメッセージ書式仕様は機能します。
o Storage or format of message contents in a CBMS.
The message format specification defines the form
and contents of messages when they are transferred
between systems. A CBMS may or may not choose to
use the same format for internal storage.
o . メッセージ書式仕様がいつシステムCBMSの間にそれらを移すかが選ばれるかもしれないというメッセージの書式とコンテンツを定義するCBMSのメッセージ内容のストレージか形式が内部記憶装置に同じ形式を使用します。
o Message transfer system protocols.
The message format specification does not specify
how a message travels between CBMSs. It does
specify the form of its contents as it leaves and
arrives, assuming only that the message is moved
transparently by the transfer system.
o メッセージ転送システムプロトコル。 メッセージ書式仕様はメッセージがCBMSsの間をどう移動するかを指定しません。 いなくなって、到着するとき、それはコンテンツのフォームを指定します、メッセージが透過的にトランスファー方式で感動しているだけであると仮定して。
o Message envelopes.
While a message is traveling between CBMSs, it is
enclosed in a message envelope. Message envelopes
contain all the information about a message that a
message transfer system needs to know. The message
format specification does not define the format or
content of a message envelope.
o メッセージ封筒。 メッセージがCBMSsの間を移動している間、それはメッセージ封筒に同封されます。 メッセージ封筒はメッセージ転送システムが、知る必要があるというメッセージのすべての情報を含んでいます。 メッセージ書式仕様はメッセージ封筒の書式か内容を定義しません。
o How message originators and recipients are identified.
The message format specification does not provide a
representation scheme for the names or addresses of
message originators and recipients as they are
known to a CBMS.
o メッセージ創始者と受取人はどう特定されるか。 メッセージ書式仕様は彼らがCBMSにおいて知られているようなメッセージ創始者と受取人の名前かアドレスの表現体系を提供しません。
6
Section 1
6 セクション1
1. INTRODUCTION
1. 序論
A computer-based message system (CBMS) allows communication
between "entities" (usually people) using computers. Computers
serve both to mediate the actual communications between systems
and to provide users with facilities for creating and reading the
messages.
コンピュータベースのメッセージシステム(CBMS)は、コンピュータを使用することで「実体」(通常人々)のコミュニケーションを許容します。 コンピュータはともにシステムの実際のコミュニケーションを伝えて、メッセージを作成して、読むために施設をユーザに提供するのに役立ちます。
CBMSs have been developing for over ten years. More
recently, CBMSs have been one of the bases in industry for the
introduction of office automation. A growing number of organi-
zations use either their own or a commercially available CBMS.
The design and complexity of these systems vary widely. This
message format specification provides a basis for interaction
between different CBMSs by defining the format of messages passed
between them.
CBMSsは10年間以上展開しています。 より最近、CBMSsはオフィス・オートメーションの導入のための産業のベースの1つです。 organi- zationsの増加している数はそれら自身のか商業的に利用可能なCBMSのどちらかを使用します。これらのシステムのデザインと複雑さはばらつきが大きいです。 このメッセージ書式仕様は、それらの間で通過されたメッセージの書式を定義することによって、異なったCBMSsの間に相互作用の基礎を供給します。
1.1 Guide to Reading This Document
1.1 このドキュメントを読むことへのガイド
The method of presenting the material in this specification
is to combine the technical specification with tutorial infor-
mation. This approach has been taken to place the specification
in context and improve its readability.
この仕様に材料を示すメソッドは家庭教師のinfor- mationに技術仕様書を結合することです。 状況内において仕様を置いて、読み易さを改良するためにこのアプローチを取りました。
The core of the technical information in the document is in
Section 2, "A Simple Model of a CBMS Environment"; Section 3.1,
"Semantics of Message Fields"; Section 4.2, "Overview of Syntax
Encoding"; and Section 4.3, "Data Element Syntax". Appendixes A
and B consolidate the technical information. These appendices
are designed for ease of reference and should be read in
conjunction with the body of the report for a complete
understanding of the message format presented in the specifi-
cation.
ドキュメントの技術資料のコアがセクション2、「CBMS環境の単純モデル」にあります。 セクション3.1、「メッセージ分野の意味論」。 セクション4.2、「構文コード化の概要」。 セクション4.3、「データ要素構文。」 付属物AとBは技術資料を統合します。 これらの付録は、参照する場合に便利なように設計されていて、specifi陽イオンに提示されたメッセージ・フォーマットの完全な理解のためのレポートのボディーに関連して読まれるべきです。
Section 2 presents a simple model of operation of a CBMS.
Section 3 discusses the components of messages and their meaning
(semantics), including discussions of the recommended
relationship between message components and CBMS user functions.
(See Section 3.2.) Section 4 presents details of the form
(syntax) required for components of a message.
セクション2はCBMSの操作の単純モデルを提示します。セクション3はメッセージとそれらの意味(意味論)の成分について論じます、メッセージコンポーネントとCBMSユーザ機能とのお勧めの関係の議論を含んでいて。 (セクション3.2を見てください。) セクション4はメッセージの成分に必要であるフォーム(構文)の細部を提示します。
Appendix D summarizes the components of messages according
to whether they are required or optional for CBMSs implementing
the message format specification. Appendix E organizes the
message components according to the functional class of the
components. Appendix F provides an overview of the syntactic
elements defined by this message format specification; Appendix G
メッセージ書式仕様を実装するCBMSsに、それらが必要であるか、または任意であるかに従って、付録Dはメッセージの成分をまとめます。 コンポーネントの機能クラスによると、付録Eはメッセージコンポーネントを組織化します。 付録Fはこのメッセージ書式仕様によって定義された構文の要素の概要を提供します。 付録G
7
Section 1.1
7 セクション1.1
summarizes those elements according to whether they are required
or optional for a CBMS implementing the message format specifi-
cation. Examples of each syntactic element appear in Appendix H,
displaying syntax and describing the associated semantics.
メッセージ・フォーマットspecifiが陽イオンであると実装するCBMSに、それらが必要であるか、または任意であるかに従って、それらの要素をまとめます。 構文を表示して、関連意味論について説明して、それぞれの構文の要素に関する例はAppendix Hに現れます。
1.2 Vendor-Defined Extensions to the Specification
1.2 仕様へのベンダーによって定義された拡大
This specification provides the capability of extending the
range of functionality by the use of vendor-defined qualifiers
and vendor-defined data elements. Any vendor who uses this
capability to provide services which are essentially equivalent
to those already designated as required, basic, or optional does
not comply with the specification.
この仕様はベンダーによって定義された資格を与える人とベンダーによって定義されたデータ要素の使用で機能性の範囲を広げる能力を提供します。 本質的には必要に応じて既に指定されたか、基本的であるか、または任意のそれらに同等なサービスを提供するこの能力を使用するどんなベンダーも仕様に従いません。
1.3 The Scope of the Message Format Specification
1.3 メッセージ書式仕様の範囲
The purpose of this message format specification is to
present the semantics and syntax to be used for messages being
exchanged between CBMSs. Specifically, it defines the following:
このメッセージ書式仕様の目的はCBMSsの間で交換されるメッセージに使用されるために意味論と構文を提示することです。 明確に、以下を定義します:
o The meaning and form of standard fields to be used in
messages.
o メッセージで使用されるべき標準の分野の意味とフォーム。
o Which fields must be present in all messages.
o どの分野がすべてのメッセージに存在していなければなりませんか?
o Which fields complying CBMSs must be able to process.
o CBMSsが処理できなければならない応じることをさばきます。
o How messages, fields, and the data contained in fields
are represented.
o 分野に保管されていたメッセージ、分野、およびデータはどう表されるか。
1.4 Issues Not Within the Scope of the Message Format Specifi-
cation
1.4はMessage Format Specifi陽イオンのScopeをNot Withinに発行します。
The message format specification does not address the
following issues, some of which are being covered by other NBS
standards development programs at the Institute for Computer
Sciences and Technology (ICST). (See [BlaR-80] for a description
of the ICST network protocols program.)
メッセージ書式仕様は以下の問題を扱いません。その或るものは他のNBS規格開発プログラムでコンピューターサイエンシズへのInstituteとTechnology(ICST)にカバーされています。 (ICSTネットワーク・プロトコルプログラムの記述に関して[BlaR-80]を見てください。)
o The nature of a message transfer system, except to state
the assumption that it transfers messages transparently.
o 透過的にメッセージを移すという仮定を述べるのを除いたメッセージ転送システムの本質。
8
Section 1.4
8 セクション1.4
o The form or nature of the protocols used to transfer
messages (posting, relay, and delivery protocols).
o プロトコルのフォームか本質が以前は、よくメッセージ(任命、リレー、および配送プロトコル)を移していました。
o The content and representation of message envelopes.
o メッセージ封筒の内容と表現。
o Representations for unique identifiers (in particular,
message identifiers).
o ユニークな識別子(特にメッセージ識別子)の表現。
o Network and internetwork addressing.
o ネットワークとインターネットワークアドレシング。
o Representations for identities of message originators
and recipients.
o メッセージ創始者と受取人のアイデンティティの表現。
o Certain message processing functions that CBMSs provide
for users, e.g., those concerned with the creation and
editing of text.
o CBMSsがユーザ、例えば、それらに提供するあるメッセージ処理機能は、テキストを作成に関係があって、編集しました。
o Presentation of messages to users.
o ユーザへのメッセージのプレゼンテーション。
o Representations for multi-media objects.
o マルチメディアオブジェクトの表現。
o Data representation for messages within CBMSs.
o CBMSsの中のメッセージのデータ表現。
o Data sharing or any storage management within CBMSs.
o CBMSsの中のデータ共有かどんな保管管理。
o Representations for fixed or floating point numbers.
o 修理されるか浮動小数点の表現。
1.5 Relationship to Other Efforts
1.5 他の取り組みとの関係
The message format specification is based on several docu-
ments and the current state of many CBMSs available both in
industry and the research community. These documents include the
standardization efforts in the ARPANet [CroD-77, PosJ-79] and the
CCITT, proposed ISO and ANSI header format standards [TasG-
80, ISOD-79], the work of IFIPS Working Group 6.5, and various
papers about the general nature of mail systems, addressing, and
mail delivery. (See [FeiE-79] for references.
メッセージ書式仕様は数個docu- mentsと産業と研究団体で利用可能な多くのCBMSsの現状に基づいています。 これらのドキュメントはARPANet[CroD-77、PosJ-79]とCCITTに標準化取り組みを含んでいます、とメールシステム、アドレシング、および郵便配達の一般的な本質に関するISO、ANSIヘッダー形式規格[TasG80、ISOD-79]、IFIPS作業部会6.5の仕事、および様々な論文は提案しました。 (参照に関して[FeiE-79]を見てください。
9
Section 2
9 セクション2
2. A SIMPLE MODEL OF A CBMS ENVIRONMENT
2. CBMS環境の単純モデル
In order to provide a framework for presenting the message
format specification, this section describes a simple functional
model for a CBMS. The model provides a high-level description of
both user facilities and system architecture. Discussions of
messages, message originators, and message recipients serve to
further clarify the nature of a CBMS.
メッセージ書式仕様を提示するのにフレームワークを提供して、このセクションはCBMSのために簡単な機能論的モデルについて説明します。モデルは利用者機能とシステム構築の両方のハイレベルの記述を提供します。 メッセージの議論、メッセージ創始者、およびメッセージ受取人は、さらにCBMSの自然をはっきりさせるのに勤めます。
A CBMS permits the transfer of a message from an originator
to a recipient. "Originator" and "recipient" are used in their
normal English senses. (See Section 2.4.) A message (in its
most abstract definition) is simply a unit of communication from
an originator to a recipient. A CBMS offers several classes of
functions to its users:
CBMSはメッセージの創始者から受取人までの転送を可能にします。 「創始者」と「受取人」は彼らの正常なイギリスの意味で使用されます。 (セクション2.4を見てください。) メッセージ(最も抽象的な定義における)は単に創始者から受取人までのコミュニケーションのユニットです。 CBMSは数人のクラスの関数をユーザに提供します:
o Message Creation: The facilities used by a message
originator to create messages and specify to whom they
are to be sent.
o メッセージ作成: それらが送られることになっているメッセージを作成して、指定するのにメッセージ創始者によって使用された施設。
o Message Transfer: The facilities used to convey a mes-
sage to its recipient(s).
o メッセージ転送: 施設は以前はよくmes賢人を受取人まで運んでいました。
o Recipient Processing: The facilities used by a message
recipient to process messages that have arrived.
o 受取人処理: 到着したメッセージを処理するのにメッセージ受取人によって使用された施設。
These classes of functions are presented in more detail in
Section 3.2.
これらのクラスの関数はさらに詳細にセクション3.2に提示されます。
CBMSs differ from other office automation/communications
systems in a number of ways.
CBMSsは多くの方法で他のオフィス・オートメーション/通信網と異なっています。
o Unlike other types of electronic communications, CBMS
messages are sent to particular individuals, not to
stations or telephone sets. If a recipient moves to a
different location, messages sent to that recipient are
delivered to the recipient at the new location.
o 他のタイプに関する電子通信と異なって、ステーションか受話器ではなく、特定の個人にCBMSメッセージを送ります。 受取人が別の場所に移行するなら、その受取人に送られたメッセージは新しい位置の受取人に提供されます。
o Transmission of CBMS messages is asynchronous. The
recipient's system need not be available when the mes-
sage leaves the originator's system. That is, CBMS
message transfer facilities are store-and-forward.
o CBMSメッセージの伝達は非同期です。 mes賢人が創始者のシステムを残すとき、受取人のシステムは利用可能である必要はありません。 すなわち、CBMSメッセージ中継設備は、店とフォワードです。
o CBMS messages can contain a wide variety of data. They
are not constrained to any single kind of communication.
CBMS messages are often simple memoranda but are not
restricted to text. A CBMS message may contain any kind
o CBMSメッセージはさまざまなデータを含むことができます。 それらはどんな単一の種類のコミュニケーションにも抑制されません。 CBMSメッセージは、しばしば簡単なメモですが、テキストに制限されません。 CBMSメッセージはどんな種類も含むかもしれません。
10
Section 2
10 セクション2
of data that an originator wishes to send to a recip-
ient. By contrast, Teletex systems and communicating
word processors handle the transfer of final form
documents; compatible communicating word processors can
exchange documents in editable form; Telex and TWX deal
in unformatted text.
創始者がそうしたがっているデータでは、recip- ientに発信してください。 対照的に、Teletexシステムとワードプロセッサを伝えると、最終形態ドキュメントの転送は扱われます。 コンパチブル交信ワードプロセッサは編集可能なフォームでドキュメントを交換できます。 テレックスとテレックスは非フォーマットされたテキストを扱います。
o CBMSs offer message creation facilities as an important
part of the system. CBMSs assist users in the prepa-
ration of messages by having text editing facilities
available and allowing users to include data stored on-
line in messages. Some CBMSs also interface to other
office automation facilities, such as formatters and
spelling correctors. This is not true of Telex, TWX, or
similar services.
o CBMSsはシステムの重要な部分としてメッセージ作成施設を提供します。 テキスト編集施設を利用可能に持っていて、ユーザが保存されたデータを入れるのを許容するのをオンに持っているのによるメッセージのprepa割り当てにおけるCBMSsアシストユーザはメッセージに立ち並びます。 また、いくつかのCBMSsがフォーマッタやスペル訂正者などの他のオフィス・オートメーション施設に連結します。 これはTelex、テレックス、または同様のサービスに関して本当ではありません。
o CBMSs offer recipient processing facilities as an impor-
tant part of the system. This is not true of most other
forms of electronic communications. For example, Telex
and TWX systems simply print messages on paper when they
are received, without retaining a copy in the system.
(Teletex systems are similar to Telex systems, but some
can retain a copy of the document in local storage.)
Communicating word processors might notify their
operators that a document has been received and is
stored on-line, but they offer little in the way of
other recipient processing facilities. Most CBMSs offer
at least the following recipient processing facilities:
o CBMSsはシステムのimpor- tant部分として受取人処理に施設を提供します。 これは他のほとんどのフォームの電子通信に関して本当ではありません。 システムでコピーを保有しないでそれらを受け取るとき、例えば、Telexとテレックスシステムは単に紙上のメッセージを印刷します。 (テレテックスシステムはTelexシステムと同様ですが、或るものは地方のストレージでドキュメントのコピーを保有できます。) ワードプロセッサを伝えるのは、ドキュメントが受け取られて、オンラインで保存されますが、彼らが少ししか他の受取人処理施設の方法で提供しないように彼らのオペレータに通知するかもしれません。 ほとんどのCBMSsが少なくとも以下の受取人処理施設を提供します:
. The ability to retain a copy of a message on-line
after it has been read.
. それの後にオンラインのメッセージのコピーを保有する能力を読んであります。
. The ability to examine or delete stored messages
individually.
. 調べるか、または削除する能力は個別にメッセージを保存しました。
. The ability to organize messages using some form of
electronic "file folder."
. 何らかのフォームの電子「ファイルフォルダー」を使用することでメッセージを組織化する能力。
. The ability to determine if a message is recent
(has arrived since the last time the recipient used
the CBMS) or unseen (has never been examined by the
recipient).
. メッセージが最近である(受取人が最後の時にCBMSを使用して以来、到着しています)、または見えないかを(受取人によって一度も調べられたことがありません)決定する能力。
. The ability to summarize stored messages. A
summary usually includes information such as
whether the message is recent or unseen, when it
was received, its length, who it is from, and its
subject.
. まとめる能力はメッセージを保存しました。 通常、概要はメッセージが最近である、または見えないかなどの情報、いつそれを受け取ったか、そして、長さ、およびその対象を含んでいます。(長さから、それは来ています)。
. The ability to retrieve a stored message based upon
. ベースの保存されたメッセージを検索する能力
11
Section 2
11 セクション2
one or more of its attributves (for example, when
the message was received, whether or not it has
been seen or deleted, and the values contained in
its fields).
attributves(それが見られるか、または削除されたことにかかわらずいつメッセージを受け取りましたか、そして、例えば分野に保管されていた値)の1つ以上。
. A forward facility that allows users to include all
or part of a message in a new outgoing message.
. ユーザが新しい送信されるメッセージでメッセージのすべてか一部を入れることができる前進の施設。
. A reply facility that allows users to answer mes-
sages without having to enter a new list of recip-
ients.
. ユーザがrecip- ientsの新しいリストを入力する必要はなくてmes賢人に答えることができる回答施設。
2.1 Logical Model of a CBMS
2.1 CBMSの論理的なモデル
CBMS facilities for message creation, transfer, and recip-
ient processing are reflected in a logical model of a CBMS
developed by IFIP Working Group 6.5. (An essentially identical
model is being used by CCITT Study Group VII, Question 5,
regarding Message Handling Systems [CCIT-82].) The model
consists of a Message Transfer System and a number of User
Agents. (See Figure 1.)
メッセージ作成、転送、およびrecip- ient処理のためのCBMS施設はIFIP作業部会6.5によって開発されたCBMSの論理的なモデルに反映されます。 (本質的には同じモデルはMessage Handling Systems[CCIT-82]に関してCCITT Study Group VII、Question5によって使用されています。) モデルはMessage Transfer Systemと多くのUserエージェントから成ります。 (図1を参照してください。)
| |
| ************* |
********* ------> * Message * -------> *********
* User * Posting * Transfer * Delivery * User *
* Agent * Protocol * System * Protocol * Agent *
********* <------- ************* <------- *********
| |
| |
Posting Delivery
Slot Slot
| | | ************* | ********* ------>* メッセージ*------->********* * ユーザ*任命*転送*配送*ユーザ**エージェント*プロトコル*システム*プロトコル*エージェント**********<。------- ************* <、-、-、-、-、-、-- ********* | | | | 任命配送スロットスロット
Message Flow
Originator --------------------------------> Recipient
メッセージ流れ創始者-------------------------------->受取人
FIG. 1. LOGICAL MODEL OF A COMPUTER-BASED MESSAGE SYSTEM
図 1. コンピュータベースのメッセージシステムの論理的なモデル
A User Agent (UA) is a functional entity that acts on behalf
of a user, assisting with creating and processing messages and
communicating with the Message Transfer System.
Userエージェント(UA)はユーザを代表して行動する機能的な実体です、メッセージを作成して、処理するのに補助して、Message Transfer Systemとコミュニケートして。
The Message Transfer System(MTS) is an entity that accepts a
Message Transfer System(MTS)はaを受け入れる実体です。
12
Section 2.1
12 セクション2.1
message from its originator's User Agent and ultimately passes it
to each of its recipients' User Agents. The Message Transfer
System may perform routing and storage functions (among others)
in order to accomplish its task.
創始者のUserエージェントから通信して、結局、受取人のUserエージェントの各人にそれを移ります。 Message Transfer Systemは、タスクを達成するために、ルーティングと記憶機能(特に)を実行するかもしれません。
Transferring a message from an originator's User Agent to
the Message Transfer System is called Posting; the originator's
User Agent and Message Transfer System engage in a Posting
Protocol in order to accomplish Posting. Transferring a message
from the Message Transfer System to a recipient's User Agent is
called Delivery; the recipient's User Agent and Message Transfer
System engage in a Delivery Protocol in order to accomplish
Delivery.
創始者のUserエージェントからMessage Transfer Systemまでメッセージを移すのはPostingと呼ばれます。 創始者のUserエージェントとMessage Transfer Systemは、Postingを達成するためにPostingプロトコルに従事しています。 Message Transfer Systemから受取人のUserエージェントまでメッセージを移すのはDeliveryと呼ばれます。 受取人のUserエージェントとMessage Transfer Systemは、Deliveryを達成するためにDeliveryプロトコルに従事しています。
The point at which responsibility for a message is trans-
ferred is called a Slot. The Posting Slot is the point at which
responsibility for a message passes from an originator's User
Agent to the Message Transfer System; the Delivery Slot is the
point at which responsibility for a message passes from the
Message Transfer System to a recipient's User Agent.
メッセージへの責任が移-ferredされるポイントはSlotと呼ばれます。 Posting Slotはメッセージへの責任が創始者のUserエージェントからMessage Transfer Systemまで終わるポイントです。 Delivery Slotはメッセージへの責任がMessage Transfer Systemから受取人のUserエージェントまで終わるポイントです。
The model divides messages into two parts, the message
content and the message envelope. The message content is the
information that the originator wishes to send to the recipient;
this message format specification deals solely with the message
content. The message envelope consists of all the information
necessary for the Message Transfer System to do its job; this
message format specification does not specify the message
envelope. Some of the data appearing on the message envelope
could be redundant with some data found in the message content.
The Message Transfer System is not expected to examine the
message content unless it is told to do so by the originator's or
recipient's User Agent.
モデルはメッセージを2つの部品、メッセージ内容、およびメッセージ封筒に分割します。 メッセージ内容は創始者が受取人に発信したがっているという情報です。 このメッセージ書式仕様は唯一メッセージ内容に対処します。 Message Transfer Systemが仕事するように、メッセージ封筒はすべての必要情報から成ります。 このメッセージ書式仕様はメッセージ封筒を指定しません。 いくつかのデータがメッセージ内容で見つけられている状態で、メッセージ封筒に現れるデータのいくつかが余分であるかもしれません。 創始者か受取人のUserエージェントでそうするように言われない場合、Message Transfer Systemがメッセージ内容を調べないと予想されます。
This message format specification places no restrictions on
the Message Transfer System itself, except that it be able to
transfer messages between originating and receiving UAs without
reading or altering the contents of messages unless otherwise
instructed by the UAs. In addition, this message format specifi-
cation does not dictate the form or nature of any protocol used
by the Message Transfer System. Finally, this message format
specification does not specify the content or form of the message
envelope. That is, the message format specification defines the
format for the contents of messages, not the manner in which they
are transmitted.
このメッセージ書式仕様はMessage Transfer System自身に関して制限を全く課さないで、別の方法でUAsによって命令されない場合、メッセージのコンテンツを読むか、または変更しないでUAsを溯源して、受けるとき、移すことができるのは通信します。 追加、specifi陽イオンがそうしないこのメッセージ・フォーマットでは、Message Transfer Systemによって使用されたどんなプロトコルの書式か本質も書き取ってください。 最終的に、このメッセージ書式仕様はメッセージ封筒の内容かフォームを指定しません。 すなわち、メッセージ書式仕様はそれらが伝えられる方法ではなく、メッセージのコンテンツのためにフォーマットを定義します。
Many of today's commercially available CBMSs incorporate all
of the facilities represented in the logical model. Their
architectures may reflect the economies that can be taken when
implementing systems that are self-contained. For example,
stand-alone systems that store messages in a single central
今日の商業的に利用可能なCBMSsの多くが論理的なモデルで表された施設のすべてを取り入れます。 それらのアーキテクチャは内蔵システムを導入するとき取ることができる経済を反映するかもしれません。 例えば、シングルで主要なメッセージを保存するスタンド・アローン・システム
13
Section 2.1
13 セクション2.1
database require no Message Transfer System; an implementation
may integrate software for User Agent and Message Transfer System
functions, doing away with Posting or Delivery Protocols.
データベースはMessage Transfer Systemを全く必要としません。 PostingかDeliveryプロトコルを片づけて、実装はUserエージェントとMessage Transfer System機能のためのソフトウェアを統合するかもしれません。
2.2 Relationship to the ISO Reference Model for Open Systems
Interconnection
2.2 オープン・システム・インターコネクションのためのISO規範モデルとの関係
Subcommittee TC97/SC16 of the International Organization for
Standardization (ISO) has developed a reference model for
describing communications between "open" systems [ISOD-82]. This
model is known as the ISO Reference Model for Open Systems
Interconnection (OSI). It divides communications protocols into
seven layers, ranging from physical interconnection at the lowest
layer to data exchange by application programs at the top.
国際標準化機構(ISO)の小委員会TC97/SC16は、「開いている」システム[ISOD-82]のコミュニケーションについて説明するために規範モデルを開発しました。 このモデルはオープン・システム・インターコネクション(OSI)のためのISO Reference Modelとして知られています。 それは通信規約を7つの層に分割します、先端のアプリケーション・プログラムで最も低い層での物理的なインタコネクトからデータ交換まで及んで。
This message format specification deals with data used by an
application within a system. Thus, the message format being
specified here is not a protocol. Since it is not a protocol, it
lies outside of the model for open systems interconnection. User
Agents are application layer entities (layer 7), however, and the
protocols used by a message transfer system are above the session
layer (layer 5).
このメッセージ書式仕様はシステムの中でアプリケーションで使用されたデータに対処します。 したがって、ここで指定されるメッセージ・フォーマットはプロトコルではありません。 プロトコルでないので、それは開放型システム間相互接続のためのモデルの外に横たわっています。 しかしながら、ユーザエージェントは応用層実体(層7)です、そして、メッセージ転送システムによって使用されるプロトコルはセッション層(層5)を超えています。
2.3 Messages and Fields
2.3 メッセージと分野
A message is a unit of communication from an originator to a
recipient. A message consists of a series of components called
fields. Fields can be described according to their meaning in a
message (semantics) and according to the format required for them
in a message (syntax).
メッセージは創始者から受取人までのコミュニケーションのユニットです。 メッセージは分野と呼ばれる一連のコンポーネントから成ります。 メッセージ(構文)で分野をメッセージ(意味論)でのそれらの意味に従って説明して、形式に従って、それらのために必要とすることができます。
Semantically, a field is just a component of a message; the
meanings of particular fields are defined by this message format
specification. Syntactically, a field is a unit of data whose
form is defined by this message format specification. Additional
fields can be defined by users or vendors as long as they conform
to the syntactic and semantic rules that this message format
specification defines for additional fields.
分野はただ意味的に、メッセージの成分です。 特定の分野の意味はこのメッセージ書式仕様によって定義されます。 シンタクス上、分野は書式がこのメッセージ書式仕様によって定義されるデータのユニットです。 このメッセージ書式仕様が追加分野と定義する構文的、そして、意味的な規則に従う限り、ユーザかベンダーが追加分野を定義できます。
(A note on terminology: A message consists of components
called fields. The words "message" and "field" are used both in
the informal sense of the previous sentence and in a more
restricted sense as names of particular syntactic elements. As
syntactic element names, Message and Field are always
capitalized.)
(用語に関する注: メッセージは分野と呼ばれるコンポーネントから成ります。 単語「メッセージ」と「分野」はいっそう限られた意味で前の文の非公式の意味と特定の構文の要素の名前として使用されます。 構文の要素名として、MessageとFieldはいつも大文字で書かれます。)
14
Section 2.3
14 セクション2.3
Some CBMS functions are based on the contents of particular
fields; other functions (such as the ability to read a message)
may have little to do with the fields themselves. Section 3.2
discusses some of the specific functions that a CBMS might
provide to users and the fields that must be used to support
those functions.
いくつかのCBMS機能が特定の分野のコンテンツに基づいています。 他の機能(メッセージを読む能力などの)は分野自体にほとんど無関係であるかもしれません。 セクション3.2はCBMSがユーザに提供するかもしれない具体的な機能とそれらの機能をサポートするのに使用しなければならない分野のいくつかについて論じます。
2.4 Message Originators and Recipients
2.4 メッセージ創始者と受取人
This message format specification refers to message origi-
nators and recipients. These terms were defined functionally in
Figure 1. When the message format specification refers to the
identity of a message originator or recipient, it means "that
information which uniquely identifies the message originator or
recipient within the domain of the given message system." The
syntax and semantics of message addressing are not within the
scope of the message format specification.
このメッセージ書式仕様はメッセージorigi- natorsと受取人について言及します。 これらの用語は図1で機能上定義されました。 メッセージ書式仕様がメッセージ創始者か受取人のアイデンティティについて言及するとき、それは「与えられたメッセージシステムのドメインの中で唯一メッセージ創始者か受取人を特定するその情報」を意味します。 メッセージ書式仕様の範囲の中にメッセージアドレシングの構文と意味論がありません。
Originators and recipients can be people, roles, processes
or groups.
創始者と受取人は、人々、役割、プロセスまたはグループであるかもしれません。
People. People as originators and recipients are specific
individuals.
人々。 創始者と受取人としての人々は特定の個人です。
Roles. Roles identify functions within organizations as
opposed to the specific individuals who perform them. For
example, consider a newspaper that produces both morning and
evening editions and therefore operates with more than one shift.
Someone wishing to contact the city desk would send a message to
the city desk role rather than trying to determine exactly who
was assigned to the city desk at a specific time. (Of course,
messages can usually be sent to the individuals directly whether
or not they are actually performing a role at the time.)
役割。 役割は彼らを実行する特定の個人と対照的に組織の中で機能を特定します。 例えば、朝、夕刊の両方を製作して、したがって1つ以上のシフトで作動する新聞を考えてください。 ちょうどだれが特定の時にローカル記事編集部に選任されたかを決定しようとするよりローカル記事編集部に接触したがっているだれかがむしろローカル記事編集部の役割にメッセージを送るでしょう。 (もちろん、彼らが実際に当時役割を実行しているか否かに関係なく、通常、直接メッセージを個人に送ることができます。)
Processes. A process in a computer could serve as either an
originator or a recipient for messages. A computer system might
originate a message to notify a recipient about the status of
some task. For example, an archive utility could notify users
about files that have been archived; a distributed file system
could notify a user that a remote file has been deposited on a
local file system. Messages could be used by computer systems to
warn about some impending condition or even to monitor the
performance of the computer itself. Some computer processes may
also be message recipients, taking action based upon message
contents.
プロセス。 コンピュータのプロセスは創始者かメッセージのための受取人に役立つかもしれません。 コンピュータ・システムは何らかのタスクの状態に関して受取人に通知するメッセージを溯源するかもしれません。 例えば、アーカイブユーティリティは格納されたファイルに関してユーザに通知するかもしれません。 分散ファイルシステムは、リモートファイルがローカルファイルシステムに預けられたことをユーザに通知するかもしれません。 メッセージはコンピュータ・システムによって使用されて、何らかの差し迫っている状態を警告するか、またはコンピュータ自体の性能をモニターさえできました。 また、メッセージ内容に基づく行動を取って、いくつかのコンピュータプロセスがメッセージ受取人であるかもしれません。
In addition, some CBMSs allow messages to be sent to groups.
A group is a predefined list of message recipients. Using a
さらに、いくつかのCBMSsがグループに送られるべきメッセージを許容します。 グループはメッセージ受取人の事前に定義されたリストです。 aを使用します。
15
Section 2.4
15 セクション2.4
group name as a recipient permits message originators to
designate a potentially large number of recipients using a single
recipient identifier. This makes using the CBMS more convenient
and accurate.
受取人としてのグループ名は、メッセージ創始者が潜在的に多くの受取人を任命することをただ一つの受取人識別子を使用することで許可します。 これで、CBMSを使用するのは、より便利で正確になります。
16
Section 3
16 セクション3
3. SEMANTICS
3. 意味論
This section discusses two major topics, message processing
functions and message field meanings. Section 3.1 describes the
six functional groups of message fields. The functional groups
are Origination, Dates, Recipients, Cross-referencing, Message-
handling, and Message-contents. They are explained more fully in
Section 3.1.1, along with detailed discussion of the semantics of
all the fields in each functional group. Section 3.2 describes
message processing functions whose operation is based on the
meanings of particular message fields.
このセクションは2つの主要な話題、メッセージ処理機能、およびメッセージ分野意味について論じます。 セクション3.1はメッセージ分野の6つの機能的なグループについて説明します。 機能的なグループは、Originationと、Datesと、Recipientsと、Cross-参照箇所と、Message取り扱いと、Message-コンテンツです。 それらはセクション3.1.1において、より完全に説明されます、それぞれの機能的なグループにおける、すべての分野の意味論の詳細な論議と共に。 セクション3.2は操作が特定のメッセージ分野の意味に基づいているメッセージ処理機能について説明します。
3.1 Semantics of Message Fields
3.1 メッセージ分野の意味論
The definition of a message is discussed generally in
Sections 1 and 2. Semantically valid messages must contain one
From field, one To field, and one Posted-Date field. They may
contain, in addition, any number of other fields, depending on
the processing and functions supplied by the originating or
receiving CBMS. (Section 3.2 describes classes of functions
supplied by CBMSs.)
一般に、セクション1と2でメッセージの定義について議論します。 意味的に有効なメッセージは1つのFrom分野、1つのTo分野、および1つのPosted-年月日欄を含まなければなりません。 それらはさらに、他のいろいろな分野を含むかもしれません、溯源かCBMSを受けることによって供給された処理と機能によって。(セクション3.2はCBMSsによって供給された機能のクラスについて説明します。)
3.1.1 Types of fields
3.1.1 分野のタイプ
Message receiving programs are required to interpret fields
according to the semantics described in the remainder of this
section. The message fields defined in this document are grouped
into the following functional categories.
メッセージ受信プログラムが、このセクションの残りで説明された意味論によると、分野を解釈するのに必要です。 本書では定義されたメッセージ分野は以下の機能的なカテゴリに分類されます。
o Originator fields indicate who or what participated in
the creation of the message and where replies should be
directed. (See Section 3.1.3.)
o 創始者分野は、だれか何がメッセージの作成に参加したか、そして、回答がどこで指示されるべきであるかを示します。 (セクション3.1.3を見てください。)
o Date fields record when events take place, for a variety
of events, such as message creation or expiration. (See
Section 3.1.5.)
o 日付の分野は、イベントがいつさまざまなイベントのためにメッセージ作成や満了のように行われるかを記録します。 (セクション3.1.5を見てください。)
o Recipient fields indicate who or what is intended to
receive a message. (See Section 3.1.4.)
o 受取人分野は、だれか何がメッセージを受け取ることを意図するかを示します。 (セクション3.1.4を見てください。)
o Cross-reference fields label a message or refer to other
messages. (See Section 3.1.6.)
o 相互参照分野は、メッセージをラベルするか、または他のメッセージを示します。 (セクション3.1.6を見てください。)
o Message-handling fields record the type of service a
o 分野がタイプを記録するメッセージハンドリングはaを修理します。
17
Section 3.1.1
17 セクション3.1.1
message's sender requested of a message transfer system
or indicate how the message should be treated by its
recipients. (See Section 3.1.7.)
メッセージの送付者は、システムを移すか、またはメッセージが受取人によってどう扱われるべきであるかを示すようメッセージを要求しました。 (セクション3.1.7を見てください。)
o Message-content fields either contain the primary
content of a message, or index the message, or summarize
the message. (See Section 3.1.8.)
o メッセージ内容分野は、メッセージのプライマリ内容を含んでいるか、メッセージに索引をつけるか、またはメッセージをまとめます。 (セクション3.1.8を見てください。)
o Extension fields provide mechanisms for extending the
message format specification. (See Section 3.1.9.)
o 拡大分野はメッセージ書式仕様を広げるのにメカニズムを提供します。 (セクション3.1.9を見てください。)
3.1.2 Semantic Compliance Categories
3.1.2 意味承諾カテゴリ
For purposes of determining whether a CBMS complies with the
semantic requirements of this message format specification, mes-
sage fields have been divided into three categories:
CBMSがこのメッセージ書式仕様の意味要件に従うかどうか決定する目的のために、mesの賢人の分野は3つのカテゴリに分割されました:
REQUIRED These fields must be present in all messages and must
be processed by message receiving programs as defined
by the message format specification.
メッセージ書式仕様によって定義されるようにREQUIRED These分野をすべてのメッセージに存在していなければならなくて、プログラムを受け取るメッセージで処理しなければなりません。
BASIC These fields need not be present in all messages but
when they do appear, they must be processed by message
receiving programs as defined by the message format
specification.
BASIC These分野はすべてのメッセージに存在している必要はありませんが、現れるとき、メッセージ書式仕様によって定義されるようにプログラムを受け取るメッセージでそれらを処理しなければなりません。
OPTIONAL These fields need not be present in all messages and
may be ignored by message receiving programs. The
exact meaning of "ignored" is not specified by the
message format specification. However, a CBMS must
recognize the existence of an optional field (that is,
optional fields should not cause errors) and must not
process the field in a manner contrary to the semantics
defined for that field by the message format specifi-
cation. It is left to the discretion of a recipient's
CBMS what action is to be taken when an instance of a
locally unimplemented optional field is detected.
OPTIONAL These分野は、すべてのメッセージに存在している必要はなくて、プログラムを受け取るメッセージによって無視されるかもしれません。「無視されること」の正確な意味はメッセージ書式仕様によって指定されません。 しかしながら、CBMSは任意の分野の存在を認識しなければなりません、そして、(すなわち、任意の分野は誤りを引き起こすべきではありません)意味論とは逆の方法による分野がメッセージでその分野と定義したプロセスはspecifi陽イオンをフォーマットしてはいけませんか? 左では、受取人のCBMSの思慮深さに、どんな動作が局所的に非実装している任意の分野のインスタンスであるときに、取るかことであるかが検出されるということです。
(Syntactic compliance is defined in Section 4.1.2.)
(構文のコンプライアンスはセクション4.1.2で定義されます。)
3.1.3 Originator fields
3.1.3 創始者分野
A message originator may be a person, role, or process.
Originator fields identify a message's author, who is responsible
for the message, who or what sent it, and where any
replies should be directed. (See Section 2.4.)
メッセージ創始者は、人、役割であるか処理するかもしれません。 創始者分野はメッセージの作者を特定します。(その作者は、メッセージ(どんな回答も指示されるべきであるところにそれを送っただれかこと)に責任があります)。 (セクション2.4を見てください。)
18
Section 3.1.3
18 セクション3.1.3
From (REQUIRED)
from(必要)です。
This field contains the identity of the originator(s)
taking formal responsibility for this message. The
contents of the From field is to be used for replies
when no Reply-to field appears in a message.
この分野は、このメッセージへの正式な責任を取りながら、創始者のアイデンティティを含んでいます。 From分野のコンテンツがいいえときに、回答に使用されることである、Reply、-、野原はメッセージに現れます。
Reply-To (BASIC)
答えます。(基本的)です。
This field identifies any recipients of replies to the
message.
この分野は回答のどんな受取人もメッセージに特定します。
Author (OPTIONAL)
作者(任意)です。
This field identifies the individual(s) who wrote the
primary contents of the message. Use of the Author
field is discouraged when the contents of the Author
field and the From field would be completely redundant.
この分野はメッセージのプライマリコンテンツを書いた個人を特定します。 Author分野とFrom分野のコンテンツが完全に余分であるだろうというときに、Author分野の使用はお勧めできないです。
Sender (OPTIONAL)
送付者(任意)です。
This field identifies the agent who sent the message.
It is used either when the sender is not the originator
responsible for the message or to indicate who among a
group of originators responsible for the message
actually sent it. Use of the Sender field is
discouraged when the contents of the Sender field and
From field would be completely redundant. The sender
field may specify only one originator identity and
appear only once in a message.
この分野はメッセージを送ったエージェントを特定します。 送付者がメッセージかだれが実際にメッセージに責任がある創始者のグループにそれを送ったかを示すのにおいて責任がある創始者でないときに、それは使用されます。 Sender分野とFrom分野のコンテンツが完全に余分であるだろうというときに、Sender分野の使用はお勧めできないです。 送付者野原は、1つの創始者のアイデンティティだけを指定して、メッセージに一度だけ現れるかもしれません。
3.1.4 Recipient fields
3.1.4 受取人分野
Message recipients may be people, roles, processes, or
groups. (See Section 2.4). Recipient fields identify who or
what is to receive the message.
メッセージ受取人は、人々、役割、プロセス、またはグループであるかもしれません。 (セクション2.4を見ます。) 受取人分野はメッセージを受け取ることになっているだれかことを特定します。
To (REQUIRED)
to(必要)です。
This field identifies the primary recipients of a
message.
この分野はメッセージのプライマリ受取人を特定します。
Bcc (OPTIONAL)
Bcc(任意)です。
This field identifies additional recipients of a
message (a "blind carbon copies" list). The contents
of this field are not to be included in copies of the
message sent to the primary and secondary recipients.
See section 3.2.1 for further discussion of the use of
blind carbon copies lists.
この分野はメッセージ(「盲目のカーボンコピー」リスト)の追加受取人を特定します。 この分野の内容はプライマリの、そして、セカンダリの受取人に送られたメッセージのコピーに含まれないことです。 盲目のカーボンコピーリストの使用のさらなる議論に関してセクション3.2.1を見てください。
19
Section 3.1.4
19 セクション3.1.4
Cc (BASIC)
cc(基本的)です。
This field identifies secondary recipients of a message
(a "carbon copies" list).
この分野はメッセージ(「カーボンコピー」リスト)のセカンダリ受取人を特定します。
Circulate-Next (OPTIONAL)
-次に、循環してください。(任意)です。
This field is used in conjunction with the Circulate-To
field. (See Section 3.2.6.1.) It identifies all
recipients in a circulation list who have not received
the message.
に関連してこの分野が使用されている、Circulate、-、分野。 (.1にセクション3.2.6を見ます) それは流通リストのメッセージを受け取っていないすべての受取人を特定します。
Circulate-To (OPTIONAL)
循環、-(任意)です。
This field identifies recipients of a circulated
message. (See Section 3.2.6.1.) It is used in
conjunction with the Circulate-Next field.
この分野は循環しているメッセージの受取人を特定します。 (.1にセクション3.2.6を見ます) それは次のCirculate分野に関連して使用されます。
3.1.5 Date fields
3.1.5 日付の分野
Date fields for two kinds of uses are provided. Dates can
be associated with some event in the history of a message and
dates can delimit the span of time during which the message is
meaningful (its life span).
2種類の用途のための日付の野原を供給します。 メッセージの歴史の何らかのイベントに日付を関連づけることができます、そして、日付はメッセージが重要である時間(寿命)の長さを区切ることができます。
Posted-Date (REQUIRED)
掲示された期日(必要)です。
This field contains the posting date, which is the
point in time when the message passes through the
posting slot into a message transfer system. Only one
Posted-Date field is permitted in a message.
この分野は投函日を含んでいます。(メッセージが任命スロットをメッセージ転送システムに通り抜ける時代の間、それは、時点です)。 1つのPosted-年月日欄だけがメッセージで受入れられます。
Date (OPTIONAL)
日付(任意)です。
This field contains a date that the message's
originator wishes to associate with a message. The
Date field is to the Posted-Date field as the date on a
letter is to the postmark added by the post office.
この分野はメッセージの創始者がメッセージと交際したがっている日付を含んでいます。 郵便局によって加えられた消印には手紙に関する日付があるようにPosted-年月日欄にはDate分野があります。
End-Date (OPTIONAL)
終了日(任意)です。
This field contains the date on which a message loses
effect. (See also Section 3.2.5.)
この分野はメッセージが効力を失う日付を含んでいます。 (また、セクション3.2.5を見てください。)
Received-Date (OPTIONAL)
資料を受け取ります。(任意)です。
This field is also called Delivery date. This field
may be added to a message by the recipient's message
receiving program. It indicates when the message left
この分野はまた、呼ばれたDelivery期日です。 この分野はプログラムを受け取る受取人のメッセージによってメッセージに追加されるかもしれません。 それは、メッセージがいついなくなったかを示します。
20
Section 3.1.5
20 セクション3.1.5
the delivery system and entered the recipient's message
processing domain.
配送システムであって入られるドメインを処理する受取人のものが通信させる。
Start-Date (OPTIONAL)
スタート日(任意)です。
This field contains the date on which a message takes
effect. (See also Section 3.2.5.)
この分野はメッセージが実施する日付を含んでいます。 (また、セクション3.2.5を見てください。)
Warning-Date (OPTIONAL)
警告日付(任意)です。
This field is used either alone or in conjunction with
an End-Date field. It contains one or more dates.
These dates could be used by a message processing
program as warnings of an impending end-date or other
event. (See also Section 3.2.5.)
この分野は単独かEnd-年月日欄に関連して使用されます。 それはより多くのある日付を含んでいます。 差し迫っている終了日か他のイベントに関する警告としてメッセージ処理プログラムでこれらの日付を使用できるでしょう。 (また、セクション3.2.5を見てください。)
3.1.6 Cross-reference fields
3.1.6 相互参照分野
Cross-reference fields can be used to identify a message and
to provide cross-references to other messages. (See Section
3.2.4.)
メッセージを特定して、他のメッセージに相互参照を提供するのに相互参照分野を使用できます。 (セクション3.2.4を見てください。)
In-Reply-To (OPTIONAL)
in reply to(任意)です。
This field designates previous correspondence to which
this message is a reply. The usual contents of this
field would be the contents of the Message-ID field of
the message(s) being replied to.
この分野はこのメッセージが回答である前の通信を指定します。 この分野の普通のコンテンツは答えられるメッセージのMessage-ID分野のコンテンツでしょう。
Message-ID (OPTIONAL)
Message ID(任意)です。
This field contains a unique identifier for a message.
This identifier is intended for machine generation and
processing. Further definition appears in Section
3.2.4.1. Only one Message-ID field is permitted in a
message.
この分野はメッセージのためのユニークな識別子を含んでいます。 この識別子はマシン世代と処理のために意図します。 さらなる定義はセクション3.2.4に.1に現れます。 1つのMessage-ID分野だけがメッセージで受入れられます。
Obsoletes (OPTIONAL)
時代遅れにします。(任意)です。
This field identifies one or more messages that this
one replaces.
この分野はこれが置き換える1つ以上のメッセージを特定します。
Originator-Serial-Number (OPTIONAL)
創始者通し番号(任意)です。
This field contains one or more serial numbers assigned
by the message's originator. Messages with multiple
recipients should have the same value in the
Originator-Serial-Number field.
この分野はメッセージの創始者によって割り当てられた1つ以上の通し番号を含んでいます。 複数の受取人がいるメッセージには、Originatorの連続のナンバーフィールドにおける同じ値があるべきです。
21
Section 3.1.6
21 セクション3.1.6
References (OPTIONAL)
参照(任意)です。
This field identifies other correspondence that this
message references. If the other correspondence
contains a Message-ID field, the contents of the
References field must be the message identifier.
この分野はこのメッセージが参照をつける他の通信を特定します。 もう片方の通信がMessage-ID分野を含んでいるなら、References分野のコンテンツはメッセージ識別子であるに違いありません。
3.1.7 Message-handling fields
3.1.7 メッセージハンドリング分野
Message-handling fields describe aspects of how a message is
to be handled or categorized.
メッセージハンドリング分野は扱われるか、またはどう分類されるかに関するメッセージがことである局面について説明します。
Precedence (OPTIONAL)
先行(任意)です。
This field indicates the precedence at which the
message was posted. Ordinarily, message precedence or
priority is a service request to a message transfer
system. A message originator, however, can include
precedence information in a message. One example of
precedence categories are those used by the U.S.
Military: "ROUTINE," "PRIORITY," "IMMEDIATE," "FLASH
OVERRIDE," and "EMERGENCY COMMAND PRECEDENCE."
この分野はメッセージが掲示された先行を示します。 通常、メッセージ先行か優先権がメッセージ転送システムへのサービスのリクエストです。 しかしながら、メッセージ創始者はメッセージで先行情報を入れることができます。 先行カテゴリに関する1つの例が米国Militaryによって使用されたものです: 「ルーチン」、「優先権」、「即座」の「フラッシュオーバーライド」、および「非常時のコマンド先行。」
Message-Class (OPTIONAL)
メッセージクラス(任意)です。
This field indicates the purpose of a message. For
example, it might contain values indicating that the
1
message is a memorandum or a data-base entry.
この分野はメッセージの目的を示します。 例えば、それは1つのメッセージがメモであることを示す値かデータベースエントリーを含むかもしれません。
Reissue-Type (OPTIONAL)
再発行タイプ(任意)です。
This field is used in conjunction with message
encapsulating (see Section 3.2.2) to differentiate
between messages being assigned or redistributed.
この分野は、割り当てられるか、または再配付されるメッセージを区別するのにメッセージ要約(セクション3.2.2を見る)に関連して使用されます。
Received-From (OPTIONAL)
受け取ります。(任意)です。
This field contains a record of a message's path
through a message transfer system. The
recipient's message receiving program could store here
any information about the transfer that it obtained
from a message transfer system.
_______________
この分野はメッセージ転送システムを通してメッセージの経路に関する記録を含んでいます。 受取人のメッセージ受信プログラムはそれがメッセージ転送システムから得た転送のどんな情報もここに格納するかもしれません。 _______________
1
The message format specification is not intended to be used as
a specification for exchanging data-base records. Messages,
however, sometimes contain data from or for a database.
1 データベース記録を交換するのに仕様としてメッセージ書式仕様が使用されることを意図しません。 しかしながら、メッセージは時々データベースかデータベースのためのデータを含んでいます。
22
Section 3.1.7
22 セクション3.1.7
3.1.8 Message-content fields
3.1.8 メッセージ内容分野
The intent of most messages is to communicate some
particular information from originator to recipient. Several
fields in a message are designed to contain that information.
ほとんどのメッセージの意図は創始者から受取人まで何らかの特定の情報を伝えることです。 メッセージのいくつかの分野が、その情報を含むように設計されています。
Subject (BASIC)
対象(基本的)です。
This field contains any information the originator
provided to summarize or indicate the nature of the
message.
この分野は創始者がメッセージの本質をまとめるか、または示すために提供したどんな情報も含んでいます。
Text (BASIC)
テキスト(基本的)です。
This field contains the primary content of the message.
この分野はメッセージの第一の内容を含んでいます。
Attachments (OPTIONAL)
付属(任意)です。
This field contains additional data accompanying a
message. It is similar in intent to enclosures in a
conventional mail system.
この分野はメッセージに伴う追加データを含んでいます。 それは意図において従来のメールシステムの包囲と同様です。
Comments (OPTIONAL)
コメント(任意)です。
This field permits adding comments to the message
without disturbing the original contents of the
message.
この分野は、メッセージに関するオリジナルコンテンツを擾乱しないでコメントをメッセージに追加することを許可します。
Keywords (OPTIONAL)
キーワード(任意)です。
This field contains keywords or phrases for use in
retrieving a message.
この分野はメッセージを検索することにおける使用のためのキーワードか句を含んでいます。
3.1.9 Extensions
3.1.9 拡大
This message format specification allows two additional
types of fields, vendor-defined fields and as-yet-undefined
(extension) fields that will be introduced by extensions to this
message format specification.
このメッセージ書式仕様はこのメッセージ書式仕様への拡大で導入される2つの追加タイプの野原、業者によって定義された野原、およびまだ未定義であるとしての(拡大)野原を許容します。
vendor-defined-field
Any field not defined in this message format specifi-
cation or any extension or successor to it is a vendor-
defined field. Names for vendor-defined fields could
be preempted by extensions to this message format
specification.
それのどんな形式specifi陽イオンや、拡大やまたは後継者も業者であるというこのメッセージで定義されなかった業者の定義された分野Any分野は分野を定義しました。 このメッセージ書式仕様への拡大で業者によって定義された分野への名前を先取りできるでしょう。
23
Section 3.1.9
23 セクション3.1.9
extension-field
Any field that is defined in a document published as a
formal extension or replacement to this message format
specification.
正式な拡大か交換としてこのメッセージ書式仕様に発表されたドキュメントで定義される拡大分野Any分野。
3.2 Message Processing Functions
3.2 メッセージ処理機能
A CBMS provides three basic classes of functions: creating
messages, transmitting messages to their recipient, and post-
receipt processing. Although the message format specification
does not define the number or nature of user functions in CBMSs,
the meanings for the fields clearly assume certain kinds of
functions. For example, fields specifying recipients of replies
to messages assume some kind of reply function; fields specifying
message life span assume some kind of date processing functions.
CBMSは3つの基本的なクラスの関数を提供します: 彼らの受取人にメッセージを送って、メッセージを作成して、ポストは処理を領収書を出させます。 メッセージ書式仕様はCBMSsではユーザ機能の数か本質を定義しませんが、分野への意味は明確にある種類の関数を仮定します。 例えば、回答の受取人をメッセージに指定する分野がある種の回答機能を仮定します。 メッセージ寿命を指定する分野がある種の情報処理機能を仮定します。
This section provides more detail on the processing that
might be done by these kinds of functions, discussing the message
fields that would be used and how they would be used. (See
summary in Table 1.)
このセクションはこれらの種類の関数でするかもしれない処理に関するその他の詳細を提供します、使用されるメッセージ分野とそれらがどう使用されるだろうかについて議論して。 (Table1の概要を見てください。)
Processing Function Fields Involved
機能フィールドがかかわった処理
Message creation Author, From, Sender, To,
and posting Cc, Bcc
Message reissuing Reissue-Type
Reply generation Reply-To
Cross-referencing Message-ID, In-Reply-To, References,
Obsoletes, Originator-Serial-Number
Life span functions Start-Date, End-Date,
Warning-Date
Recipient processing Circulate-To, Circulate-Next
Reissue-タイプReply世代を再発行するメッセージ創造のAuthor、From、Sender、To、および任命Cc、Bcc Message、Reply、-、Crossに参照をつけたMessage-ID、Inが答える、References、Obsoletes(Life長さ機能がStart日付を入れるOriginatorの連続の番号)はEndデートします、Warning-日付のRecipient処理、Circulate、-、次のCirculate
TABLE 1. FIELDS USED IN MESSAGE PROCESSING FUNCTIONS
1を見送ってください。 メッセージ処理機能に使用される分野
3.2.1 Message creation and posting
3.2.1 メッセージ創造と任命
Messages can be created either by reissuing an existing
message to a new recipient (see Section 3.2.2) or by creating a
new message. The process of message creation might mean that
some fields of a new message are filled in from the contents of
some other message. Reply functions (Section 3.2.3) provide an
example of this.
新しい受取人(セクション3.2.2を見る)に既存のメッセージを再発行するか、または新しいメッセージを作成することによって、メッセージを作成できます。 メッセージ創造の過程は、新しいメッセージのいくつかの分野がある他のメッセージのコンテンツから記入されることを意味するかもしれません。 回答機能(セクション3.2.3)はこの例を提供します。
24
Section 3.2.1
24 セクション3.2.1
Different individuals could be involved in different phases
of originating a message: creating it, taking responsibility for
it, and explicitly interacting with a CBMS to send it to its
recipient. One or more individuals may create a message (that
is, write, but not necessarily enter it into the CBMS); they are
said to be the message's authors, identified by the Author field.
One or more individuals may take responsibility for its contents
and the decision to post it; they are identified by the From
field. One individual explicitly posts a given message; this
person is called the message's sender (identified by the Sender
field).
異なった個人はメッセージを溯源する異なったフェーズにかかわることができました: それを受取人に送るためにそれに責任を取って、CBMSと対話して、明らかに取って、それを作成します。 1人以上の個人がメッセージ(すなわち、書きますが、必ずCBMSにそれを入れるというわけではない)を作成するかもしれません。 それらはAuthor分野によって特定されたメッセージの作者であると言われています。 1人以上の個人がコンテンツへの責任とそれを掲示するという決定を取るかもしれません。 それらはFrom分野によって特定されます。 ある個人が明らかに当然のことのメッセージを掲示します。 この人はメッセージの送付者(Sender分野で、特定される)と呼ばれます。
The sender and author(s) are often, but not always, respon-
sible for the message. A common case in which the sender is not
responsible for the message is when a secretary enters and posts
messages for someone else. An example of a situation in which a
message's author is not responsible for the message itself is
when an administrative assistant prepares a report that is sent
under a manager's signature.
しばしば送付者と作者はいつもメッセージのためのrespon- sibleであるにすぎないというわけではありません。 送付者はメッセージに責任がないよくある例が、秘書がいつ入るか、そして、他の誰かへのポストメッセージです。 メッセージの作者はメッセージ自体に責任がない状況に関する例がゼネラルスタッフがマネージャの署名で送られるレポートを作成する時です。
The use of the Cc field is identical to current business
practice. This field contains the formal secondary recipients of
the message.
Cc分野の使用は現在の商習慣と同じです。 この分野はメッセージの礼儀正しい二次受取人を含みます。
Messages containing Bcc fields are treated specially by
CBMSs. The contents of this field are not included in copies of
the message sent to the recipients other than the originator who
are not included in the Bcc field itself. Some systems include
the contents of the Bcc field only in the originator's copy;
others include all or part of the Bcc field in the copies sent to
the recipients indicated in the Bcc field. This specification
does not indicate exactly how the Bcc field is to be treated.
特に、Bcc分野を含むメッセージがCBMSsによって扱われます。 この分野の内容は創始者以外のBcc分野自体に含まれていない受取人に送られたメッセージのコピーに含まれていません。 いくつかのシステムが創始者のコピーだけのBcc分野のコンテンツを含んでいます。 他のものはBcc分野で示された受取人に送られたコピーのBcc分野のすべてか一部を入れます。 この仕様はちょうど扱われるBcc分野がことである方法を示しません。
3.2.2 Message reissuing and forwarding
3.2.2 メッセージ再発行と推進
Reissuing and forwarding both serve the general user goal of
passing a message on to a new set of recipients. Forwarding is
the term used for an informal mechanism, which CBMSs implement by
copying some or all of the original message into the contents of
a field in the new message. Reissuing is the term used for a
formal mechanism to ensure that the message being passed on never
loses its integrity as a previously sent message. CBMSs use
reissuing to implement several different functions, depending on
the purposes being served:
両方を再発行して、進めると、新しいセットの受取人にメッセージを渡すという一般的なユーザ目標は役立ちます。 推進はCBMSsが新しいメッセージの分野のコンテンツにオリジナルのメッセージのいくつかかすべてをコピーすることによって実行する非公式のメカニズムに使用される用語です。 再発行は正式なメカニズムが、伝えられるメッセージが以前に送られたメッセージとして保全を決して失わないのを保証するのに使用される用語です。 役立たれている目的によって、CBMSsはいくつかの異なった機能を実行するのに再発行を使用します:
o Redistribution. Making others aware of the complete and
unaltered contents of the message.
o 再分配。 他のものをメッセージの完全で非変更されたコンテンツを意識するようにします。
25
Section 3.2.2
25 セクション3.2.2
o Assignment. Delegating the responsibility for a message
to somebody else.
o 課題。 メッセージへの責任を他の誰かへ代表として派遣します。
These purposes are exemplified in Figure 2.
これらの目的は図2で例示されます。
When a CBMS examines a forwarded message, it cannot always
distinguish the old message from what was added when the
forwarding took place. In addition, the forwarded information
might no longer have the form of a message. This is usually
because the format of the message has been changed (for example,
to pure unformatted text). (See Figure 2 for an example of how a
CBMS might forward a message.) In contrast, a reissued message
can always be separated from its enclosing message and never
loses its identity as a correctly formed message.
CBMSが転送されたメッセージを調べるとき、それは推進が行われたとき加えられたものと古いメッセージをいつも区別できるというわけではありません。 さらに、回送情報には、メッセージのフォームがもうないかもしれません。 これは通常、メッセージの形式を変えたから(例えば純粋な非フォーマットされたテキストに)です。 (CBMSがどうメッセージを転送するかもしれないかに関する例に関して図2を見てください。) 対照的に、再発行されたメッセージは、メッセージを同封するのといつも切り離すことができて、正しく形成されたメッセージとして決して本性を失くしません。
This specification provides the Reissue-Type field for
supporting reissuing. Forwarding, since it is an informal means
of serving the purpose of passing on information, has no
supporting fields in the specification.
再発行するのを支持するのにこの仕様はReissue-タイプ野原を供給します。 推進は、仕様にそれが情報を伝える目的に役立つ非公式の手段であることでサポート分野を全く持っていません。
This specification provides for reissuing of messages by
encapsulating. This method embeds the entire original message
inside a new message. Encapsulating adds structure around the
要約することによって、この仕様はメッセージの再発行に備えます。 この方法は新しいメッセージで全体のオリジナルのメッセージを埋め込みます。 要約は周囲で構造を加えます。
2
message . This allows any part of it to be easily extracted.
2 メッセージこれは、それのどんな部分も容易に抽出されるのを許容します。
This procedure for passing on previously sent messages is a
matter of organizational policy and has authentication as an
associated issue. Each organization must decide if the CBMS it
acquires should support reissuing or simply supply forwarding.
以前に送信されたメッセージを伝えるためのこの手順は、組織的な方針の問題であり、関連問題として認証を持っています。 各組織は、それが獲得するCBMSが再発行するのを支持するはずであるか、または単に推進を供給するはずであるかを決めなければなりません。
3.2.2.1 Redistribution
3.2.2.1 再分配
Redistribution is a CBMS function for sending the original
contents of a message intact and unchanged to new recipients. A
redistributed message is identical to the original message with
the exception of added information about the reissuing. For
reissuing with this purpose, the Reissue-Type field contains the
ASCII string "Redistribution." The original message has been
included directly in a new message. (See Figure 2.)
再分配は、新しい受取人にとって、完全で変わりのないメッセージに関するオリジナルコンテンツを送るためのCBMS機能です。 再発行の付記された情報を除いて、再配付されたメッセージはオリジナルのメッセージと同じです。 この目的がある再発行のために、Reissue-タイプ分野はASCIIストリング「再分配」を含んでいます。 オリジナルのメッセージは直接新しいメッセージに含まれています。 (図2を参照してください。)
_______________
_______________
2
A message can contain another message, and that message can
contain another message, and so on to any depth of encapsulating.
This can occur by reissuing a message repeatedly.
2 メッセージは別のメッセージを含むことができて、そのメッセージは要約のどんな深さにも別のメッセージなどを含むことができます。 これは、繰り返してメッセージを再発行することによって、起こることができます。
26
Section 3.2.2.2
26部3.2 .2 .2
The Original Message
John Doe wishes Jane Jones to get a copy of the following
message:
Message:
Field: From "Jean Smith"
Field: Posted-Date "27 January 1983"
Field: To "John Doe"
Field: Subject "Next Project Meeting"
Field: Text "The agenda for ..."
Original Messageジョン・ドウは、ジェーン・ジョーンズに以下のメッセージのコピーを手に入れて欲しいです: メッセージ: 以下をさばいてください。 「ジーン・スミス」から、以下をさばいてください。 掲示された期日の「1983年1月27日」分野: 「ジョン・ドウ」に、以下をさばいてください。 対象の「次のプロジェクトミーティング」分野: テキスト、「」 …のための議題
Redistribution
Message:
Field: From "John Doe" John Doe is responsible
Field: Posted-Date "28 January 1983" for the redistribution.
Field: To "Jane Jones"
Field: Reissue-Type "Redistribution" This message directly
Message: incorporates a
Field: From "Jean Smith" redistributed message.
Field: Posted-Date "27 January 1983"
Field: To "John Doe"
Field: Subject "Next Project Meeting"
Field: Text "The agenda for ..."
再分配メッセージ: 以下をさばいてください。 「ジョン・ドウ」から、ジョン・ドウは責任があるFieldです: 「1983年1月28日」という再分配の掲示された期日。 以下をさばいてください。 「ジェーン・ジョーンズ」に、以下をさばいてください。 再発行タイプ「再分配」ThisはMessageを直接通信させます: Fieldを組み込みます: 「ジーン・スミス」再配付されたメッセージから。 以下をさばいてください。 掲示された期日の「1983年1月27日」分野: 「ジョン・ドウ」に、以下をさばいてください。 対象の「次のプロジェクトミーティング」分野: テキスト、「」 …のための議題
Forwarding
Message:
Field: From "John Doe"
Field: Posted-Date "28 January 1983"
Field: To "Jane Jones"
Field: Text A realization of the
"From Jean Smith original message is
To John Doe copied into the Text field.
Sent on 27 January 1983 Note that John's CBMS
Subject Next Project Meeting has chosen to represent
it as a text string.
The agenda for ..."
推進メッセージ: 以下をさばいてください。 「ジョン・ドウ」から、以下をさばいてください。 掲示された期日の「1983年1月28日」分野: 「ジェーン・ジョーンズ」に、以下をさばいてください。 「ジーン・スミスから、オリジナルのメッセージはジョン・ドウがText分野にコピーしたToです」のテキストA実現。 1983年1月27日Noteに送って、そのジョンのCBMS Subject Next Project Meetingは、テキスト文字列としてそれを表すのを選びました。 「」 …のための議題
FIG. 2. MESSAGE FORWARDING AND REDISTRIBUTION
図 2. メッセージ推進と再分配
27
Section 3.2.2.2
27部3.2 .2 .2
3.2.2.2 Assignment
3.2.2.2 課題
Assignment is the process of designating responsibility. In
some organizations, formal message traffic is distributed to one
or more parts of the organization (called offices) where it is
directed to the appropriate individuals or other offices for
final disposition. Assignment is done by reissuing a message
with the Reissue-Type field containing the ASCII string
"Assigned." A message which contains this field is to be
interpreted as meaning that the addressees in the "To" field have
had the reissued message assigned to them for some action. Any
addressee in the "Cc" field has had the message assigned for
information. The "From" field records who assigned the message
and the "Posted-Date" field records when the message was
assigned.
課題は指定責任のプロセスです。 いくつかの組織では、正式なメッセージトラフィックはそれが最終的な気質のために適切な個人か他のオフィスに向けられる組織(オフィスと呼ばれる)の1つ以上の部分に分配されます。 「割り当てられる」というReissue-タイプ分野がASCIIストリングを含んでいるメッセージを再発行することによって、課題をします。 この分野を含むメッセージは“To"分野の受け取り人が何らかの動作のために再発行されたメッセージを彼らに割り当てさせたことを意味すると解釈されることです。 「cc」分野のどんな受け取り人も情報のためにメッセージを割り当てさせました。 “From"分野は、メッセージが割り当てられたとき、だれがメッセージと「掲示された期日」分野記録を割り当てたかを記録します。
3.2.3 Reply generation
3.2.3回答世代
Reply generation involves creating a new message in direct
reply to some other message by drawing on the contents of fields
in the other message to fill fields in the new message. Many
CBMSs provide reply facilities that determine the intended recip-
ients of a reply.
回答世代は、新しいメッセージで分野をいっぱいにするもう片方のメッセージの分野のコンテンツの図面で新しいメッセージを作成することをある他のメッセージに関するダイレクト回答に伴います。 多くのCBMSsが回答の意図しているrecip- ientsを決定する回答施設を提供します。
A Reply-To field is defined by this message format specifi-
cation. When a message contains a Reply-To field, the CBMS
should send replies to the recipients designated in the Reply-To
field instead of to the recipients designated in the From field.
This statement applies to original messages only, not to reissued
messages. The message format specification makes no
recommendations concerning replies to reissued messages.
Reply、-、分野はこのメッセージ・フォーマットのspecifi陽イオンによって定義されます。 メッセージが含むいつ、Reply、-、分野、CBMSが任命された受取人への回答を送るはずであるか、Reply、-、From分野で任命された受取人の代わりに、さばきます。 この声明は再発行されたメッセージではなく、オリジナルのメッセージだけに適用されます。 メッセージ書式仕様は回答に関して推薦状を全く再発行されたメッセージにしません。
Reply-To has several possible applications:
答え、いくつかの可能なアプリケーションを持っています:
o The individual(s) responsible for the message might not
have regular access to a CBMS and would indicate an
alternate recipient, for example, a secretary.
o メッセージに責任がある個人は、定期的なアクセスをCBMSに持っていないかもしれなくて、代替の受取人、例えば秘書を示すでしょう。
o The people responsible for receiving responses might not
be the people who were responsible for creating the
message.
o 応答を受けるのに責任がある人々はメッセージを作成するのに責任がある人々でないかもしれません。
o Discussion and conference groups could use this feature
to ensure correct distribution of any submission by
having the conference group itself designated in the
Reply-To field.
o 議論と会議グループが中で会議グループ自体を指定させることによってどんな服従の正しい分配も確実にするこの特徴を使用できた、Reply、-、分野
28
Section 3.2.3
28 セクション3.2.3
When the message does not contain a Reply-To field, the
recipient should reply to the originators enumerated in the From
field. The sender and authors should not be added automatically
to the list of those receiving the reply.
メッセージが含まないいつ、Reply、-、分野、受取人はFrom分野で数え上げられた創始者に答えるべきであるか。 自動的に回答を受け取るもののリストに送付者と作者を追加するべきではありません。
Replies could also be sent to the other recipients of the
original message. Vendors might offer additional reply facil-
ities, depending on their view of users' organizational require-
ments.
また、オリジナルのメッセージの他の受取人に回答を送ることができました。 ベンダーは組織的な状態でそれらのユーザの視点による追加回答facil- itiesを提供するかもしれません。mentsを必要としてください。
3.2.4 Cross-referencing
3.2.4 十字に参照をつけます。
A CBMS message may include designator(s) which identify
other message(s). The designators are used to refer to related
messages so that all information in a chain of correspondence can
be determined by a CBMS user. The designator used to identify
and cross-reference messages can take either of two forms, unique
identifiers or serial numbers.
CBMSメッセージは他のメッセージを特定する指示子を含むかもしれません。 指示子は、CBMSユーザが通信のチェーンにおけるすべての情報を決定できるように関連するメッセージを示すのに使用されます。 特定するのにおいて中古の指示子と相互参照メッセージは2つのフォーム、ユニークな識別子または通し番号のどちらかを取ることができます。
3.2.4.1 Unique identifiers
3.2.4.1 ユニークな識別子
Unique identifiers are machine-generated and are intended
primarily for processing by computers. While they could be
examined by a human user, unique identifiers are not necessarily
useful or convenient for people.
ユニークな識別子は、マシンで発生していて、主として処理のためにコンピュータで意図します。 人間のユーザはそれらを調べることができましたが、人々は、ユニークな識別子が、必ず役に立つというわけではない、都合がよくはありません。
Unique identifiers occur in several contexts. They are
often used to identify the contents of idual messages
unambiguously. When unique identifiers are used this way, they
are called message identifiers. Different versions of a message
receive new message identifiers; an example of this is reissuing
a message with comments.
ユニークな識別子はいくつかの文脈に現れます。 それらは、明白にidualメッセージのコンテンツを特定するのにしばしば使用されます。 ユニークな識別子がこのように使用されるとき、それらはメッセージ識別子と呼ばれます。 メッセージの異なった見解は新しいメッセージ識別子を受け取ります。 この例はコメントでメッセージを再発行しています。
When a CBMS generates a message identifier, it must be able
to guarantee that it is unique, both within the domain of the
individual CBMS and globally, across all connected CBMSs. CBMSs
could generate globally unique identifiers in several ways, all
of which require prior agreement on behalf of the connected
CBMSs. One method is to assign each connected CBMS a unique
code. A CBMS then generates unique identifiers by using its code
as a prefix to some other value that it can guarantee to be
unique within its domain. (This second value could be a counter
or a timestamp/user-id combination.)
CBMSがメッセージ識別子を生成するとき、それはそれがユニークであるという保証と、個々のCBMSのドメインと両方の、グローバルにできなければなりません、すべての接続CBMSsの向こう側に。 CBMSsはいくつかの方法でグローバルにユニークな識別子を生成するかもしれません。そのすべてが接続CBMSsを代表して事前同意を必要とします。 1つのメソッドはそれぞれの接続CBMSにユニークなコードを割り当てることです。 そして、CBMSは、ドメインの中で接頭語としてそれが保証できるある他の値にコードを使用するのによるユニークな識別子が特有であると生成します。 (この2番目の値は、カウンタかタイムスタンプ/ユーザID組み合わせであるかもしれません。)
A CBMS can provide functions for tracing chains of corre-
spondence by using unique identifiers. The message format
specification defines fields for which a CBMS provides unique
identifiers as values. They are Message-ID, References,
Obsoletes, and In-Reply-To. (See Section 3.1.6.)
CBMSは、ユニークな識別子を使用することによって、corre- spondenceの追跡チェーンに機能を供給できます。 メッセージ書式仕様はCBMSが値としてユニークな識別子を提供する分野を定義します。 そして、それらがMessage-ID、References、Obsoletesである、Inは答えます。 (セクション3.1.6を見てください。)
29
Section 3.2.4.1
29部3.2 .4 .1
3.2.4.2 Serial numbering
3.2.4.2 連続の付番
Serial numbers are for users to maintain a personal num-
bering system for messages. The numbers are composed of both
letters and digits so that users could maintain several sets of
sequences concurrently (for example, A1, A2, A3... and B1, B2,
B3...).
通し番号はユーザがメッセージのパーソナルnum- beringシステムを維持することです。 数は、ユーザが同時に(例えば、A1とA2とA3と…B1、B2、B3…)数セットの系列を維持できるように、手紙とケタの両方で構成されます。
Serial numbers are assigned at a defined point in the
history of a message. Serial numbers are not unique identifiers;
they differ from unique identifiers in that they are not neces-
sarily generated or processed by a CBMS. They are designed to be
entered and read by CBMS users. They can be as simple or complex
as the user requires. Serial numbers are intended to be used to
designate messages about a specific topic, or messages a given
user has sent. Serial numbers are intended to be a permanent
part of the message, just as unique identifiers are.
通し番号はメッセージの歴史で定義されたポイントで割り当てられます。 通し番号はユニークな識別子ではありません。 彼らはそれらがCBMSによって生成されたか、または処理されたneces- sarilyでないという点においてユニークな識別子と異なっています。入られて、CBMSユーザで読むために、設計されています。 それらは、ユーザが必要とするのと同じくらい簡単であるか、または同じくらい複雑であることができます。 特定の話題、または与えられたユーザが送ったメッセージに関するメッセージを指定するのに通し番号が使用されることを意図します。 通し番号はちょうどユニークな識別子のようにメッセージの永久的な部分であることを意図します。
A CBMS can provide functions allowing originators to add
serial numbers to messages. Originator-Serial-Number is the
field provided for an originator to add a serial number to a
message before sending it.
CBMSは創始者が通し番号をメッセージに追加できる機能を提供できます。 創始者シリーズ番号はそれを送る前に創始者が通し番号をメッセージに追加するように提供された野原です。
3.2.5 Life span functions
3.2.5 寿命機能
Messages have life spans, usually delimited by the creation
date and the time when the last copy of the message is destroyed.
Messages could be meaningless before a certain time or irrelevant
after a certain time. For example, a reminder to attend a
meeting on 5 June loses most of its value on the sixth; a
reminder to attend that same meeting may be of little use on 5
May (although not for the same reason).
メッセージには、通常、メッセージの最後のコピーが破壊される作成日付と時までに区切られた寿命があります。 メッセージは、ある時の前に無意味であるか、またはある時の後に無関係であるかもしれません。 例えば、6月5日にミーティングに出席する思い出させるものは6日の価値の大部分を失います。 その同じミーティングに出席する思い出させるものは5月5日に少ない役に立つかもしれません(同じ理由からはありませんが)。
A CBMS can define a message's life span explicitly using the
Start-Date and End-Date fields. A third field, Warning-Date,
when used in conjunction with the End-Date, may be used to signal
the approach of the End-Date. Warning-Date may also stand alone
and be used by a periodic warning (alarm clock) mechanism.
CBMSは、明らかにStart-日付とEnd-日付の分野を使用することでメッセージの寿命を定義できます。 3番目の分野(Warning-日付End-日付に関連して使用されると)は、End-日付の接近に合図するのに使用されるかもしれません。 警告日付は、また、単独で立って、周期的な警告(目覚まし時計)メカニズムによって使用されるかもしれません。
A CBMS could use these fields to help users manage their
message stores. For example, a message whose start date has not
yet passed could be bypassed by a retrieval command unless the
user requested such messages explicitly. A CBMS could use the
end date to help with message store housekeeping either by
archiving or deleting the expired messages automatically or by
asking the user for some action to be taken on them. The warning
date could be used to remind the user automatically of an
impending end date, such as a meeting reminder.
CBMSは、ユーザが彼らのメッセージ店を経営するのを助けるのにこれらの分野を使用するかもしれません。 例えば、ユーザが明らかにそのようなメッセージを要求しない場合、スタート日がまだ終わっていないメッセージは検索命令で迂回できるでしょう。 CBMSは、自動的に満期のメッセージを格納するか、削除すること、または何らかの動作をユーザに求めるのによるメッセージ店家事でそれらの上で取られるのを助けるのに終了日を使用するかもしれません。 差し迫っている終了日について自動的にユーザに思い出させるのに警告日付を使用できました、ミーティング思い出させるもののように。
30
Section 3.2.6
30 セクション3.2.6
3.2.6 Requests for recipient processing
3.2.6 受取人処理を求める要求
Recipients have a wide variety of needs for examining and
processing a message, ranging from automatic output on some
specified device to the execution of a program embedded in the
message itself. Because many of these needs are highly
specialized, and support for them not widely implemented, this
message format specification does not constrain the requests for
processing that may be included in a message.
受取人には、メッセージを調べて、処理するさまざまな必要性があります、ある指定されたデバイスにおける自動出力からメッセージ自体に埋め込まれたプログラムの実行まで及んで。 これらの必要性の多くが非常に専門化していて、それらのサポートが広く実装されないので、このメッセージ書式仕様はメッセージに含まれるかもしれない処理を求める要求を抑制しません。
The message format specification does provide two fields
that permit an originator to request circulation list processing
from the recipient. These fields are Circulate-To and Circulate-
Next.
メッセージ書式仕様は創始者が受取人から流通リスト処理を要求することを許可する2つの野原を供給します。 これらの分野がそうである、Circulate、-、そして、次のCirculate。
3.2.6.1 Message circulation
3.2.6.1 メッセージ流通
Message circulation involves serial distribution of a mes-
sage to its recipients, based on a distribution list that is part
of the message. The message is delivered first to the first
recipient on the distribution list. This recipient, or someone
the recipient delegates, sends the message on to the second
recipient on the list, perhaps after commenting on or adding to
the message. This continues until all recipients on the
distribution list have received the message.
メッセージ流通は受取人へのmes賢人の連続の分布にかかわります、メッセージの一部である発送先リストに基づいて。 メッセージは最初に、発送先リストの最初の受取人に提供されます。 この受取人、または受取人が代表として派遣するだれかがリストの上の2番目の受取人にメッセージを送ります、恐らくメッセージに批評するか、または加えた後に。 発送先リストのすべての受取人がメッセージを受け取るまで、これは続きます。
This message format specification provides two fields to
support message circulation. The Circulate-To field contains the
complete distribution list, indicating the full set of recip-
ients, and the Circulate-Next field indicates which recipients
have not seen the message. See Figure 3 for an example of
message circulation using these two fields.
このメッセージ書式仕様は、メッセージ流通をサポートするために2つの野原を供給します。 Circulate、-、recip- ientsのフルセットを示して、分野は完全な発送先リストを含んでいて、次のCirculate分野は、どの受取人がメッセージを見ていないかを示します。 これらの2つの分野を使用して、メッセージ流通の例に関して図3を見てください。
3.3 Multiple Occurrences and Ordering of Fields
3.3 分野の複数の発生と注文
Most message fields may occur more than once in a message;
the exceptions are the Posted-Date, Sender, and Message-ID
fields, which may occur once, at most. What this means is that a
received message may contain any number of instances of a
particular field (such as the "To" field). If a message contains
more than one instance of a particular field, that field "occurs
multiply" and that message has "multiple occurrences" of that
field.
ほとんどのメッセージ分野がメッセージの一度より起こるかもしれません。 例外は、Posted-日付と、Senderと、Message-ID分野です。(その分野は大部分に一度現れるかもしれません)。 これが意味することは受信されたメッセージが特定の分野(“To"分野などの)のいろいろなインスタンスを含むかもしれないということです。 増えてください。メッセージが特定の分野、その分野の1つ以上のインスタンスを含んでいる、「起こる、」 メッセージには、その分野の「複数の発生」があります。
A particular instance of a message field is not superseded
by later instances of the same field. The To field is an example
of this.
メッセージ分野の特定のインスタンスは同じ分野の後のインスタンスによって取って代わられません。 To分野はこの例です。
31
Section 3.3
31 セクション3.3
-----------------------------------------------------------------
-----------------------------------------------------------------
A message originator wishes to circulate a message to
recipients A, B and C. The originator includes the
following fields in the message:
メッセージ創始者は受取人Aにメッセージを循環させたがっています、B、C. 創始者はメッセージで以下の分野を入れます:
To: A
Circulate-To: A, B, C
Circulate-Next: B, C
To: To:を循環させます。 A、B、Cは-次に、循環します: B、C
When recipient A or someone A delegates causes the
message to be further circulated, the message is sent
to the first address in the Circulate-Next field, and
that name is removed from that field:
A代表が、より遠いメッセージを引き起こす受取人Aかだれかが循環したとき、次のCirculate分野における最初のアドレスにメッセージを送ります、そして、その分野からその名前を移します:
To: B
Circulate-To: A, B, C
Circulate-Next: C
To: B、To:を循環させます。 A、B、Cは-次に、循環します: C
B now sends the message on to its final recipient:
Bは現在、最終的な受取人にメッセージを送ります:
To: C
Circulate-To: A, B, C
To: C、To:を循環させます。 A、B、C
FIG. 3. EXAMPLE OF MESSAGE CIRCULATION
図 3. メッセージ流通に関する例
-----------------------------------------------------------------
-----------------------------------------------------------------
Multiple occurrences of a field are not necessarily equiv-
alent to a single field containing the concatenated contents of
the several instances of the given field. For example, with the
Text field, concatenating the contents of several instances might
lose important distinctions between the contents. A single
message could be used to send three different documents, each one
in a different Text field. However, putting the three documents
into a single Text field would make it much more difficult to
extract any individual document.
分野の複数の発生が必ず与えられた分野のいくつかのインスタンスの連結されたコンテンツを含むただ一つの分野へのequiv- alentであるというわけではありません。 例えば、Text分野でいくつかのインスタンスのコンテンツを連結すると、内容の大切な区別は損をするかもしれません。 異なったText分野で3通の異なったドキュメント、それぞれを送るのにただ一つのメッセージを使用できました。 しかしながら、ただ一つのText分野に3通のドキュメントを入れるのに、どんな個々の文献も抜粋するのははるかに難しくなるでしょう。
Encapsulated messages are exceptions to the multiple
occurrences rule. For example, the To field in an encapsulated
message is not a multiple occurrence of the To field in the
enclosing message.
メッセージであるとカプセル化されているのは、複数の発生規則への例外です。 例えば、カプセル化されたメッセージのTo分野は同封メッセージで、To分野の複数の発生ではありません。
The fields found in a single message may occur in any order.
The order in which they occur does not necessarily reflect the
ただ一つのメッセージで見つけられた分野は順不同に起こるかもしれません。 それらが起こるオーダーは必ず反射するというわけではありません。
32
Section 3.3
32 セクション3.3
order in which they were created. Nor does it constrain the
order in which the message recipient examines, processes, or
displays them.
それらが作成されたオーダー。 また、それはメッセージ受取人がそれらを調べるか、処理するか、または表示するオーダーを抑制しません。
33
Section 4
33 セクション4
4. SYNTAX
4. 構文
This section begins with an introduction to the concepts and
elements that constitute the syntax for messages. The second
section presents an overview of the encoding scheme. The third
section describes in detail the elements of the message syntax.
このセクションは序論でメッセージのために構文を構成する概念と要素に始まります。 第2セクションはコード化体系の概要を提示します。 第3セクションは詳細にメッセージ構文の原理について説明します。
4.1 Introduction
4.1 序論
This specification defines syntactic requirements for mes-
sages when they are passed from one CBMS to another. The
specification is designed to meet the following goals.
彼らが1CBMSから別のCBMSまで通過されるとき、この仕様はmes賢人のための構文の要件を定義します。 仕様は、以下の目標を達成するように設計されています。
o Provide a concise, flexible representation scheme.
o 簡潔で、フレキシブルな表現体系を提供してください。
o Simplify message parsing.
o メッセージ構文解析を簡素化してください。
o Support non-textual components in messages (for example,
3
facsimile, graphics, or speech ).
o メッセージ(例えば、3ファクシミリ、グラフィックス、またはスピーチ)で非テキスト形成部門を支えてください。
4.1.1 Message structure
4.1.1 メッセージ構造
Messages have two classes of components, fields and
messages. A field corresponds to one of the semantic components
defined in this message format specification. A message is
simply another message.
メッセージには、2つのクラスに関するコンポーネント、分野、およびメッセージがあります。 分野はこのメッセージ書式仕様で定義された意味部門の1つに対応しています。 メッセージは単に別のメッセージです。
The type of a field in a message determines both its meaning
and the form for its contents. (See Section 4.3.2.)
メッセージの分野のタイプはコンテンツのために意味とフォームの両方を決定します。 (セクション4.3.2を見てください。)
Fields in a message are composed of syntactic elements
called data elements. A Message data element is used to
represent messages; a Field data element is used to represent
fields. (The term "field" is simply a semantic construct,
distinct from "Field Data Element," which is a syntactic
メッセージの分野はデータ要素と呼ばれる構文の要素で構成されます。 Messageデータ要素はメッセージを表すのに使用されます。 Fieldデータ要素は、分野を表すのに使用されます。 (「分野」という用語は単にa構文であることの「フィールド・データ要素」と異なった意味構造物です。
_______________
_______________
3
While this message format specification is not intended to be
used as a basis for the interchange of all facsimile information,
it does recognize that CBMS messages may contain facsimile
components.
3 すべてのファクシミリ情報の置き換えの基礎としてこのメッセージ書式仕様が使用されることを意図していない間、それは、CBMSメッセージがファクシミリコンポーネントを含むかもしれないと認めます。
34
Section 4.1.1
34 セクション4.1.1
construct.) Many of the fields defined in this message format
specification are restricted to containing only one kind of data
element. (See Section 4.3.2.)
組み立てます。) このメッセージ書式仕様で定義された分野の多くが1種類のデータ要素だけを含むのに制限されます。 (セクション4.3.2を見てください。)
Each field defined in this message format specification has
been assigned a unique numeric identifier that is used in
conjunction with the Field data element. Separate identifiers
are provided for vendor-defined fields and for extending the
identifier encoding space. A list of fields and identifiers
appears in Section 4.3.2 and in Appendix C.
Fieldデータ要素に関連して使用されるユニークな数値識別子をこのメッセージ書式仕様で定義された各分野に割り当ててあります。 ベンダーによって定義された分野とスペースをコード化する識別子を広げるのに別々の識別子を提供します。 分野と識別子のリストはセクション4.3.2とAppendix Cに現れます。
Throughout the message format specification, fields are
referred to by label name rather than by their numeric identi-
fiers. Field labels are names like "Sender," "Warning-Date," or
"Circulate-To." The field labels chosen for the specification
are names that are in common use in current CBMSs. The
specification does not require a CBMS to use these field labels
in displaying fields to the user.
メッセージ書式仕様中では、野原はそれらの数値identi- fiersでというよりむしろラベル名によって言及されます。 または、「-デートするように警告し」て、使用領域の表示が「送付者」のように名前である、「循環、-、」 仕様に選ばれた使用領域の表示は現在のCBMSsの共用の名前です。 仕様は、CBMSがユーザに野原を表示する際にこれらの使用領域の表示を使用するのを必要としません。
4.1.2 Data elements
4.1.2 データ要素
For the purpose of determining compliance with the syntax
defined in this specification, data elements are divided into two
groups:
この仕様に基づき定義される構文へのコンプライアンスを決定する目的のために、データ要素は2つのグループに分割されます:
BASIC All message receiving systems must process these
syntactic elements, interpreting their values according
to the message format specification.
メッセージ書式仕様によると、それらの値を解釈して、BASIC Allメッセージ受電方式はこれらの構文の要素を処理しなければなりません。
OPTIONAL Message receiving systems need not process these
syntactic elements in order to be in compliance.
OPTIONAL Message受電方式は、承諾にはあるようにこれらの構文の要素を処理する必要はありません。
In addition, complying CBMSs must meet requirements
regarding their ability to process the components found inside
data elements. These requirements are discussed in Section
4.2.2.
さらに、応じるCBMSsはデータ要素の中で見つけられたコンポーネントを処理する彼らの能力に関する必要条件を満たさなければなりません。 セクション4.2.2でこれらの要件について議論します。
This message format specification classifies data element
types as either primitives or constructors. Primitive data
elements, such as ASCII-String, are basic building blocks.
Constructor data elements, such as Message or Sequence, contain
one or more primitive or constructor data elements. Some
constructors, such as Sequence, may be composed of any other data
element. Some, such as Message, may contain only certain data
elements. Two data elements, Extension and Vendor-Defined, may be
classified as either primitives or constructors, depending on how
they are used to extend this specification. The general
syntactic form for data elements is discussed in section 4.3.1.
このメッセージ書式仕様は基関数か建設者のどちらかとしてデータ要素型を分類します。 ASCII-ストリングなどの原始のデータ要素は基本的なブロックです。 MessageかSequenceなどの建設者データ要素は1つ以上の原始か建設者データ要素を含んでいます。 Sequenceなどの建設者の中にはいかなる他のデータ要素でも構成される人もいるかもしれません。 いくらかのMessageなどが、あるデータ要素だけを含むかもしれません。 2つのExtensionであってVendorによって定義されたデータ要素が、基関数か建設者のどちらかとして分類されるかもしれません、彼らがこの仕様を広げるのにどう使用されるかによって。 セクション4.3.1でデータ要素のための一般的な構文のフォームについて議論します。
35
Section 4.1.2
35 セクション4.1.2
4.1.2.1 Primitive data elements
4.1.2.1 原始のデータ要素
A primitive data element contains a basic item of
information; it is not composed of other data elements. In
current CBMSs, the most commonly used primitive data element is
4
ASCII-String, a series of ASCII characters. Other primitive data
elements are Integer, 2's complement integers; Bit-String, a
series of bits; and Boolean, either True or False.
原始のデータ要素は情報の定番商品を含んでいます。 それは他のデータ要素で構成されません。 現在のCBMSsでは、最も一般的に使用された原始のデータ要素は4ASCII-ストリング、一連のASCII文字です。 他の原始のデータ要素はInteger、2の補数整数です。 ビットストリング、一連のビット。 そして、ブールである、TrueかFalseのどちらか。
One primitive data element, End-Of-Constructor, is used only
as a structural element within constructor data elements and has
no meaning by itself. End-of-Constructor is used to provide an
end marker for constructor data elements that do not have an
explicit length; any other use is not valid syntactically.
ある原始のデータ要素(建設者のEnd)自体は、単に構造要素として建設者データ要素の中で使用されて、意味を持っていません。 建設者の終わりは明白な長さを持っていない建設者データ要素にエンドマーカーを供給するのに使用されます。 いかなる他の使用もシンタクス上有効ではありません。
4.1.2.2 Constructor data elements
4.1.2.2 建設者データ要素
The Data Element Contents of constructor data elements
contain one or more data elements. The most general form of a
constructor is a Sequence or a Set, since both Sequences and Sets
may contain any data element. Other constructors are specialized
forms of sequences.
建設者データ要素のData Element Contentsは1つ以上のデータ要素を含んでいます。 建設者の最も一般的なフォームは、SequenceかSetです、SequencesとSetsの両方がどんなデータ要素も含むかもしれないので。 他の建設者は専門化しているフォームの系列です。
A Message data element is a constructor. It may contain
only Field data elements, other Message data elements, or
encrypted or data compressed forms of these elements. A Field
data element can contain any data element. It also indicates
which specific field is being represented. The contents of some
fields are restricted to a single type of data element, such as
ASCII-String or Date.
Messageデータ要素は建設者です。 それが他のMessageデータ要素の、または、暗号化されたFieldデータ要素だけを含むかもしれませんか、またはデータはこれらの要素のフォームを圧縮しました。 Fieldデータ要素はどんなデータ要素も含むことができます。 また、それは、どの特定の分野が表されているかを示します。 いくつかの分野の内容は単独のタイプのASCII-ストリングかDateなどのデータ要素に制限されます。
4.1.3 Properties
4.1.3 特性
Any data element may have associated with it a Property-
List, which contains properties such as a Printing-Name or one or
more Comments. Comment A mechanism to support vendor-defined
properties has been supplied by this specification, as well as a
mechanism to extend the list of property identifiers.
どんなデータ要素もPropertyリストをそれに関連づけたかもしれません。(それは、Printing-名前か1Commentsなどの特性を入れてあます)。 メカニズムと同様に特性の識別子のリストを広げるためにこの仕様でベンダーによって定義された特性を支えるコメントAメカニズムを供給しました。
_______________
_______________
4
An ASCII-String is not limited to ASCII characters however.
The ASCII code table can be extended through standardized
techniques as described in FIPS Pub 35, Code Extension Techniques
in 7 or 8 Bits [NatB-75].
しかしながら、ASCII-ストリングはASCII文字に制限されません。4 FIPS Pub35で説明されるように標準化されたテクニックでASCIIコードテーブルを広げることができます、7か8Bits[NatB-75]のCode Extension Techniques。
36
Section 4.1.3.1
36部4.1 .3 .1
4.1.3.1 Printing-names
4.1.3.1 印刷名
Printing-Names are used to provide labels that can be
displayed along with their respective data elements. For
example, a message originator may use a Printing-Name property to
request that the To field of a message be labeled "Distribution:"
when it is printed by its recipients.
印刷名は、それらのそれぞれのデータ要素と共に表示できるラベルを提供するのに使用されます。 例えば、メッセージ創始者がメッセージのTo分野がラベルされるよう要求するのにPrinting-名前の特性を使用するかもしれない、「分配:」 それが受取人によって印刷されるとき。
4.1.3.2 Comments
4.1.3.2 コメント
The Comment property is used to allow comments to be
associated with any data element without affecting its actual
contents. For example, someone reviewing the text of a message
could add the comment "This looks good" to the Text field without
either altering the body itself or adding a separate comment
field.
Commentの特性は、コメントが実際のコンテンツに影響しないでどんなデータ要素にも関連しているのを許容するのに使用されます。 例えば、ボディー自体を変更するか、または別々の注釈欄を加えないで、メッセージのテキストを批評するだれかが「これは良く見える」というコメントをText分野に加えることができました。
4.1.4 Data compression and encryption
4.1.4 データ圧縮と暗号化
Two constructor data elements, Compressed and Encrypted,
have been provided for use by a CBMS that supports data
compression or encryption. They may be used to hold the
compressed or encrypted contents of any data element, including
Messages and Fields, and may occur wherever their compressed or
encrypted contents may appear. A mechanism is included to allow
the user to identify the encryption or compression algorithm used
(Sections 4.3.4 and 4.3.5).
2つの建設者データ要素(CompressedとEncrypted)が、データ圧縮か暗号化をサポートするCBMSによって使用に提供されました。 それらは、Messagesとフィールズを含むどんなデータ要素の圧縮されたか暗号化されたコンテンツも保持するのに使用されて、どこでも、彼らの圧縮されたか暗号化されたコンテンツが現れるかもしれないところに起こるかもしれません。 メカニズムがユーザが使用される暗号化か圧縮アルゴリズムを特定するのを許容するために含まれている、(セクション4.3 .4と4.3、.5)。
4.2 Overview of Syntax Encoding
4.2 構文コード化の概要
This section provides an overview of the notation and
terminology used to represent the syntactic elements (data
elements) defined in this message format specification.
このセクションはこのメッセージ書式仕様で定義された構文の要素(データ要素)を表すのにおいて中古の記法と用語の概要を提供します。
All data elements consist of a series of components. Each
of the components is composed of a series of 8-bit groups called
octets. In this document, the bits are numbered starting from
the low-order bit. That is, the low-order (or least significant)
bit is called "bit 0" and the high-order (or most significant)
bit is called "bit 7."
すべてのデータ要素が一連のコンポーネントから成ります。 それぞれのコンポーネントは八重奏と呼ばれる一連の8ビットのグループで構成されます。 下位のビットから始めて、本書では、ビットは番号付です。 すなわち、少ない注文であって(最も重要でない)のビットは「噛み付いている0インチと高い注文であって(最も重要)のビットは「ビット7」と呼ばれます。」と呼ばれます。
Five different components may appear in a data element.
5つの異なったコンポーネントがデータ要素に現れるかもしれません。
o Identifier octet (identifying particular type of data
element)
o 識別子八重奏(特定のタイプのデータ要素を特定します)
37
Section 4.2
37 セクション4.2
o Length Code (specifying number of octets that appear
following it in a data element)
o 長さのコード(データ要素でそれに続いて、現れる八重奏の数を指定します)
o Qualifier (supplying additional identifying information)
o 資格を与える人(追加身元が分かる情報を提供します)
o Property-List component (a Property-List data element
containing Property data elements)
o 特性リストコンポーネント(Propertyデータ要素を含むProperty-リストデータ要素)
o Data Element Contents (containing actual data of the
data element)
o データ要素コンテンツ(データ要素の実際のデータを含みます)
These components always appear in this order. Not all components
are present in all data elements, but the components that are
present maintain this relative order.
これらのコンポーネントはいつもこの順で現れます。 すべてのコンポーネントがどんなすべてのデータ要素に存在しているというわけではありませんが、存在しているコンポーネントはこの相対オーダを維持します。
4.2.1 Identifier Octets
4.2.1 識別子八重奏
The identifier octet is a numeric code containing infor-
mation that identifies a data element. It is always the first
component in a data element. The Identifier octet contains a
one-bit flag, indicating whether or not the data element contains
a Property-List, and a 7-bit unique identifier for the data
element. The value of the data element identifier also indicates
whether the data element has a Qualifier.
識別子八重奏はデータ要素を特定するinfor- mationを含む数字コードです。 いつもそれはデータ要素で最初のコンポーネントです。 Identifier八重奏は1ビットの旗を含んでいます、データ要素がProperty-リスト、およびデータ要素のための7ビットのユニークな識別子を含むかどうかを示して。 また、データ要素識別子の値は、データ要素にはQualifierがあるかどうかを示します。
The most significant bit (Bit 7) of the identifier octet is
set to 1 if there are properties associated with the data
element; it is set to 0 if there are none. This bit is
independent of the remaining seven bits in the identifier octet,
which are called the identifier, and provide unique identifi-
cation for data elements. The associated properties are
specified in a Property-List component.
データ要素に関連している特性があれば、識別子八重奏の最も重要なビット(ビット7)は1に設定されます。 なにもなければ、それは0に設定されます。 このビットは識別子八重奏における残っている7ビットから独立しています。(それは、データ要素に識別子と呼ばれて、ユニークなidentifi陽イオンを供給します)。 関連特性はProperty-リストコンポーネントで指定されます。
The second most significant bit (Bit 6) of the identifier
octet (the most significant bit of the identifier itself)
signifies whether or not the data element has a Qualifier. If
the bit is set to 1, then the data element has a Qualifier; if it
is a 0, the data element does not have a Qualifier. The seven
bits of the identifier uniquely identify the data element.
データ要素にQualifierがあるか否かに関係なく、識別子八重奏(識別子自体の最も重要なビット)の2番目の最上位ビット(ビット6)は意味します。 ビットが1に設定されるなら、データ要素には、Qualifierがあります。 それが0であるなら、データ要素には、Qualifierがありません。 識別子の7ビットは唯一データ要素を特定します。
Table 2 shows the settings of the high-order bits of the
identifier octet and their associated meaning. Figure 4
demonstrates the bit-level structure of the identifier octet. In
this figure, bit 7 is indiciated with P to show its special use.
テーブル2は識別子八重奏とそれらの関連意味の高位のビットの設定を見せています。 図4は識別子八重奏のビットレベル構造のデモをします。 この図では、ビット7は、特別な使用を示しているためにPと共にindiciatedされます。
38
Section 4.2.1
38 セクション4.2.1
-----------------------------------------------------------------
-----------------------------------------------------------------
bit 7 6 5 4 3 2 1 0
+---------------+
|P 0 x x x x x x| 0xxxxxx uniquely identifies a
+---------------+ data element without a Qualifier.
ビット7 6 5 4 3 2 1 0+---------------+ |P0x x x x x x| 0xxxxxxは唯一+を特定します。---------------+ Qualifierのないデータ要素。
+---------------+
|P 1 x x x x x x| 1xxxxxx uniquely identifies a
+---------------+ data element with a Qualifier.
+---------------+ |P1x x x x x x| 1xxxxxxは唯一+を特定します。---------------+ Qualifierがあるデータ要素。
FIG. 4. STRUCTURE OF IDENTIFIER OCTETS
図 4. 識別子八重奏の構造
-----------------------------------------------------------------
-----------------------------------------------------------------
Bit Value Meaning
噛み付いている値の意味
7 0 The data element does not have properties asso-
ciated.
1 The data element has properties associated.
データ要素がする7 0は特性のasso- ciatedを持っていません。 1 データ要素で、特性を関連づけます。
6 0 The data element does not have a Qualifier.
1 The data element has a Qualifier.
データ要素がする6 0はQualifierを持っていません。 1 データ要素には、Qualifierがあります。
TABLE 2. HIGH-ORDER BITS IN THE IDENTIFIER OCTET
2を見送ってください。 識別子八重奏における高位のビット
4.2.2 Length code and Qualifier components
4.2.2 長さのコードとQualifierの部品
The Length Code and the Qualifier are both usually one octet
in length. They use an encoding scheme that permits extending
the component to the size necessary to represent the length of
the data element or the value of the Qualifier component.
通常、Length CodeとQualifierは長さが両方のある八重奏です。 彼らはデータ要素の長さかQualifierの部品の値を表すのに必要なサイズにコンポーネントを広げるのを許容するコード化体系を使用します。
The most significant bit of the Length Code or Qualifier
components determines whether it is one or several octets in
length. When the most significant bit is 0, the component is one
Length CodeかQualifierの部品の最も重要なビットは、それが長さが1かそれともいくつかの八重奏であるかを決定します。 最も重要なビットが0であるときに、コンポーネントは1です。
39
Section 4.2.2
39 セクション4.2.2
octet in length. When the most significant bit is 1, the other
seven bits of the first octet encode the number of octets in the
rest of the component. The actual value begins in the next octet
and is interpreted as an unsigned integer.
長さにおける八重奏。 最も重要なビットが1であるときに、最初の八重奏の他の7ビットはコンポーネントの残りにおける、八重奏の数をコード化します。 実価は、次の八重奏で始まって、符号のない整数として解釈されます。
A single octet is sufficient for most Length Code and
Qualifier components. For those cases where the value of the
Length Code or the Qualifier must be greater than 127, extra
octets can be added, up to a maximum of 127 octets. Figure 5
shows the encoding scheme, as well as an example of a value less
than 127 and one greater than 127.
ただ一つの八重奏はほとんどのLength CodeとQualifierの部品に十分です。 Length CodeかQualifierの値が127以上でなければならないそれらのケースにおいて、付加的な八重奏を加えることができます、最大127の八重奏まで。 図5はコード化体系、および値127と1つより多くの127に関する例を示しています。
-----------------------------------------------------------------
-----------------------------------------------------------------
bit 7 6 5 4 3 2 1 0
+---------------+
|0 x x x x x x x| xxxxxxx is the value.
+---------------+
ビット7 6 5 4 3 2 1 0+---------------+ |0 x x x x x x x| xxxxxxxは値です。 +---------------+
+---------------+------//-------+
|1 n n n n n n n|y y y y y y y y| nnnnnnn is the
+---------------+------//-------+ number of octets
that contain the
value yyyyyyyy.
+---------------+------//-------+ |1 n n n n n n n|y y y y y y y y| nnnnnnnは+です。---------------+------//-------+ 値のyyyyyyyyを含む八重奏の数。
+---------------+
|0 0 0 0 1 0 0 1| This is an example with a
+---------------+ value of 9 (decimal).
+---------------+ |0 0 0 0 1 0 0 1| これは+がある例です。---------------+ 9(10進)の値。
+---------------+---------------+
|1 0 0 0 0 0 0 1|1 0 0 0 0 0 1 0| This example has a
+---------------+---------------+ value of 130 (decimal).
+---------------+---------------+ |1 0 0 0 0 0 0 1|1 0 0 0 0 0 1 0| この例には、+があります。---------------+---------------+ 130(10進)の値。
+---------------+---------------+
|1 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1|
+---------------+---------------+
+---------------+---------------+ |1 0 0 0 0 0 1 0|0 0 0 0 0 0 0 1| +---------------+---------------+
+---------------+
|0 0 1 0 1 1 0 0| This example has a
+---------------+ value of 300 (decimal).
+---------------+ |0 0 1 0 1 1 0 0| この例には、+があります。---------------+ 300(10進)の値。
FIG. 5. ENCODING MECHANISM FOR QUALIFIERS AND LENGTH CODES
図 5. 資格を与える人と長さのコードのためにメカニズムをコード化します。
-----------------------------------------------------------------
-----------------------------------------------------------------
40
Section 4.2.2
40 セクション4.2.2
In order to comply with this message format specification,
CBMSs must be able to determine the value of any length code or
qualifier that is expressed in three octets or less. (The
このメッセージ書式仕様に従うために、CBMSsは3つ以下の八重奏で表されるどんな長さのコードや資格を与える人の値も決定できなければなりません。 (
16
2 -1). This message format specification places no limitation
on the value of a length code or qualifier generated by a CBMS
(except for the absolute limitation inherent in the represen-
tation scheme). However, the use of length codes and qualifiers
32
with larger values (particularly values in excess of 2 -1)
should be avoided unless it is known that the receiving system
can handle them.
16 2 -1). このメッセージ書式仕様はCBMS(represen- tation体系に固有の絶対制限を除いた)によって生成された長さのコードか資格を与える人の値に制限を全く置きません。 しかしながら、受電方式がそれらを扱うことができるのが知られていない場合、より大きい値(特に値より多くの2 -1)をもっている長さのコードと資格を与える人32の使用は避けられるべきです。
Both Length Codes and Qualifiers have a special convention
for dealing with special situations. Length Codes can specify
that a data element has indeterminate length; a Qualifier can
specify that a data element is implementation defined. These
cases are explained further in the next two sections.
Length CodesとQualifiersの両方が特別な状況に対処するための特別なコンベンションを開きます。 長さのCodesは、データ要素には不確定の長さがあると指定できます。 Qualifierは、データ要素が定義された実装であると指定できます。 これらのケースは次の2つのセクションで、より詳しく説明されます。
4.2.2.1 Length Codes
4.2.2.1 長さのコード
The length code component immediately follows the identifier
octet. It is present in every data element. The Length Code
indicates the number of octets following it in a data element
(that is, excluding the identifier octet and the length code
itself). Length Codes appear in one of three formats: short,
long, and indefinite.
長さのコード成分はすぐに、識別子八重奏に続きます。 それはあらゆるデータ要素に存在しています。 データ要素(すなわち、識別子八重奏と長さのコード自体を除いた)でそれに続いて、Length Codeは八重奏の数を示します。 長さのCodesは3つの形式の1つに現れます: 短いのと、長いのと、無期です。
A short Length Code is one octet long. Its most significant
bit (Bit 7) is set to 0 and its value is in the range 0 through
127.
長い間、短いLength Codeは1つの八重奏です。 最上位ビット(ビット7)は0に設定されます、そして、値が範囲に0〜127にあります。
A long Length Code is at least two octets long. The first
octet always has its most significant bit (Bit 7) set to 1. The
other seven bits of this octet contain the number of octets
making up the rest of the Length Code, and these octets contain
長い間、長いLength Codeは少なくとも2つの八重奏です。 最初の八重奏で、いつも最上位ビット(ビット7)を1に設定します。 この八重奏の他の7ビットがLength Codeの残り、およびこれらの八重奏を補う八重奏の数を含んでいる、含有
1016
(2 - 1) (that is, 127 octets to represent the value).
1016 (2--1) (すなわち、値を表す127の八重奏。)
An indefinite Length Code is one octet long. Its most
significant bit (Bit 7) is set to 1 and its other bits are all 0.
(See Figure 6.) An indefinite Length Code may appear only as
part of a constructor data element; it may not occur in a
長い間、無期Length Codeは1つの八重奏です。 最上位ビット(ビット7)は1に設定されます、そして、他のビットはすべて0です。 (図6を参照してください。) 無期Length Codeは単に建設者データ要素の一部として現れるかもしれません。 それはaに起こらないかもしれません。
41
Section 4.2.2.1
41部4.2 .2 .1
-----------------------------------------------------------------
-----------------------------------------------------------------
bit 7 6 5 4 3 2 1 0
+---------------+
|0 x x x x x x x| xxxxxxx is the value of the
+---------------+ length code.
ビット7 6 5 4 3 2 1 0+---------------+ |0 x x x x x x x| xxxxxxxは+の値です。---------------+ 長さのコード。
+---------------+------//-------+
|1 n n n n n n n|y y y y y y y y| nnnnnnn is the number
+---------------+------//-------+ of octets that contain
the value of the length
code; these are represented
as yyyyyyy.
+---------------+
|1 0 0 0 0 0 0 0| The "indefinite" length code
+---------------+
+---------------+------//-------+ |1 n n n n n n n|y y y y y y y y| nnnnnnnは数+です。---------------+------//-------長さのコードの値を含む八重奏の+。 これらはyyyyyyyとして表されます。 +---------------+ |1 0 0 0 0 0 0 0| 「無期」の長さのコード+---------------+
FIG. 6. REPRESENTATION OF LENGTH CODES
図 6. 長さのコードの表現
-----------------------------------------------------------------
-----------------------------------------------------------------
5
primitive data element . A constructor data element with an
indefinite length code has an End-Of-Constructor data element as
the last data element in its Data Element Contents. (The length
of such a constructor data element is unrestricted, although it
must contain at least one data element -- the End-of-Constructor
that terminates it -- in its Data Element Contents.)
5 原始のデータ要素無期長さのコードに従った建設者データ要素には、Data Element Contentsにおける最後のデータ要素として建設者のEndデータ要素があります。 (そのような建設者データ要素の長さは無制限です、Data Element Contentsに少なくとも1つのデータ要素(それを終える建設者のEnd)を含まなければなりませんが。)
4.2.2.2 Qualifier
4.2.2.2 資格を与える人
If present,the Qualifier component immediately follows the
code component. It is used to provide information essential to
the interpretation of the data element contents that is beyond
that encoded in the identifier octet or length code. For
example, the identifier octet could contain the code for a field,
and the Qualifier component would specify what kind of field.
存在しているなら、Qualifierの部品はすぐに、コードコンポーネントに続きます。 それは、識別子八重奏か長さのコードでコード化されたそれにあるデータ要素コンテンツの解釈に不可欠の情報を提供するのに使用されます。 例えば、識別子八重奏は分野へのコードを含むかもしれません、そして、Qualifierの部品は分野で親切な状態でなにかを指定するだろうか。
The Qualifier component appears in only a few data elements.
Qualifierの部品はほんのいくつかのデータ要素に現れます。
_______________
_______________
5
This is the result of most primitive elements being able to
contain any bit pattern (including the identifier for End-Of-
Constructor).
5、これがどんなビット・パターンも含むことができるほとんどの原始の要素の結果である、(Endのための識別子を含んでいる、-、建設者、)
42
Section 4.2.2.2
42部4.2 .2 .2
In the Bit-String data element, it indicates the number of unused
bits in the final octet of the Data Element Contents. In the
Field and Property data elements, it indicates which field or
property the data element represents. In the Compressed and
Encrypted data elements, it indicates which compression or
encryption algorithm has been used. In the Message data element,
it indicates the type of message.
Bit-列データ要素では、それはData Element Contentsの最終的な八重奏における、未使用のビットの数を示します。 FieldとPropertyデータ要素では、それは、データ要素がどの分野か特性を表すかを示します。 CompressedとEncryptedデータ要素では、それは、どの圧縮か暗号化アルゴリズムが使用されたかを示します。 Messageデータ要素では、それはメッセージのタイプを示します。
The length of the Qualifier component depends on the
encoding of the Qualifier. (See Figure 7.) A short Qualifier is
one octet long. Its most significant bit is 0 and its value is
in the range 0 through 127. A long Qualifier is at least two
octets in length. The most significant bit is always 1 and the
other 7 bits indicate the number of octets in the value of the
Qualifier.
Qualifierの部品の長さはQualifierのコード化であることに依存します。 (図7を参照してください。) 長い間、短いQualifierは1つの八重奏です。 最上位ビットは0です、そして、値が範囲に0〜127にあります。 長いQualifierは長さが少なくとも2つの八重奏です。 いつも最も重要なビットは1です、そして、他の7ビットはQualifierの値における、八重奏の数を示します。
-----------------------------------------------------------------
-----------------------------------------------------------------
+--------+--------+--------+
|10000010|00000001 00001010| Qualifier with value
+--------+--------+--------+ 266 (decimal).
+--------+--------+--------+ |10000010|00000001 00001010| 値+をもっている資格を与える人--------+--------+--------+ 266(10進)。
+--------+--------+--------+--------+
|10000011|00000000|00000001 00001010| Vendor-Defined
+--------+--------+--------+--------+ Qualifier with
value 266.
+--------+--------+--------+--------+ |10000011|00000000|00000001 00001010| +をベンダーで定義します。--------+--------+--------+--------+ 値266をもっている資格を与える人。
+--------+
|10000000| Undefined value for a Qualifier.
+--------+
+--------+ |10000000| Qualifierのための未定義値。 +--------+
FIG. 7. EXAMPLES OF QUALIFIER VALUES
図 7. 資格を与える人値に関する例
-----------------------------------------------------------------
-----------------------------------------------------------------
This message format specification allows implementations to
define their own values for Qualifiers. A vendor-defined Qual-
ifier is any long Qualifier in which the first octet in the value
is 0. The value used to identify this Qualifier is not
guaranteed to be unique and the same value may be used by
different implementations to define different Qualifiers.
このメッセージ書式仕様で、実装はQualifiersのためにそれら自身の値を定義できます。 ベンダーによって定義されたQual- ifierは値における最初の八重奏が0であるあらゆる長いQualifierです。 このQualifierを特定するのに使用される値は特有になるように保証されません、そして、同じ値は異なった実装によって使用されて、異なったQualifiersを定義するかもしれません。
43
Section 4.2.3
43 セクション4.2.3
4.2.3 Property-List
4.2.3 特性リスト
A Property is an attribute being associated with, but not
essential to the interpretation of, a data element. The
properties currently defined by this message format specification
are Printing-Name and Comment. A Property-List component of a
data element is represented by a Property-List data element that
in turn contains Property data elements.
Propertyが解釈に関連していますが、不可欠でない属性である、データ要素。 現在このメッセージ書式仕様によって定義されている特性は、Printing-名前とCommentです。 データ要素のProperty-リストの部品は順番にPropertyデータ要素を含むProperty-リストデータ要素によって表されます。
A data element contains at most one Property-List. The most
significant bit in the identifier octet of the data element
indicates whether a Property-List is present.
データ要素は1つのProperty-リストを高々含んでいます。 データ要素の識別子八重奏で最も重要なビットは、Property-リストが存在しているかどうかを示します。
4.2.4 Data Element Contents
4.2.4 データ要素コンテンツ
The Data Element Contents component of a data element is the
actual data or information represented by a data element. (The
other components provide the information necessary to identify
and interpret the Data Element Contents.)
データ要素のData Element Contentsの部品は、データ要素によって表された実際のデータか情報です。 (他のコンポーネントはData Element Contentsを特定して、解釈するために必要情報を提供します。)
In a primitive data element, the Data Element Contents is a
series of octets interpreted according to the identifier octet
and any qualifier.
原始のデータ要素では、Data Element Contentsは識別子八重奏に従って解釈された一連の八重奏とあらゆる資格を与える人です。
In a constructor data element, the Data Element Contents is
a series of data elements. When the Length Code component of a
constructor data element is "indefinite," the last data element
in the constructor's Data Element Contents is End-of-Constructor.
建設者データ要素では、Data Element Contentsは一連のデータ要素です。 建設者データ要素のLength Codeの部品が「無期である」とき、コンストラクタのData Element Contentsにおける最後のデータ要素は建設者のEndです。
The length of the Data Element Contents (in octets) is the
difference between the value of the Length Code and the sum of
the following:
Data Element Contents(八重奏における)の長さはLength Codeの値と以下の合計の違いです:
o the length of the Qualifier component (depends on the
data element)
o Qualifierの部品の長さ(データ要素に依存します)
o the length of the Property-List component.
o Property-リストコンポーネントの長さ。
4.3 Data Element Syntax
4.3データ要素構文
This message format specification defines nineteen (19)
different data elements. Section 4.3.1 defines the encoding form
for data elements in general and the syntax for each data
element. Section 4.3.2 describes the use of specific data
このメッセージ書式仕様は19の(19)の異なったデータ要素を定義します。 セクション4.3 .1 一般に、データ要素のためのコード化書式とそれぞれのデータ要素のための構文を定義します。 セクション4.3.2は特定のデータの使用について説明します。
44
Section 4.3
44 セクション4.3
elements as part of the Data Element Contents of a Field data
element. A summary of the syntactic form appears in Appendix F;
summaries of the data element syntax appear in Appendix G.
Fieldデータ要素のData Element Contentsの一部としての要素。 構文のフォームの概要はAppendix Fに現れます。 データ要素構文の概要はAppendix Gに現れます。
4.3.1 Data elements
4.3.1 データ要素
This section presents the general syntactic form for all
data elements defined by this message format specification and
the detailed syntax for each data element. The data elements are
presented by syntactic class: primitive data elements (Section
4.3.1.1), constructors (Section 4.3.1.2), and data elements which
can be either (Section 4.3.1.3).
このセクションはこのメッセージ書式仕様によって定義されたすべてのデータ要素のための一般的な構文のフォームとそれぞれのデータ要素のための詳細な構文を提示します。 データ要素は構文のクラスによって提示されます: 原始のデータ要素、(セクション4.3 .1 .1、)建設者、(どちらかであるかもしれないセクション4.3.1の.2、)およびデータ要素、(セクション4.3 .1 .3)。
For convenience, the following terminology is used in this
section.
便宜のために、以下の用語はこのセクションで使用されます。
Term Meaning
用語意味
Primitive a Primitive Data Element
原始のa原始のデータ要素
Constructor a Constructor Data Element
建設者は建設者データ要素です。
Element any Data Element
要素いずれもData Element
The syntax of each Element is presented in graphic form.
The following conventions apply in the diagrams. A single octet
is represented as follows.
それぞれのElementの構文は図形に提示されます。 以下のコンベンションはダイヤグラムで適用されます。ただ一つの八重奏は以下の通り表されます。
+--------+
| |
+--------+
+--------+ | | +--------+
Components that vary in length are represented as follows.
長さにおいて異なるコンポーネントは以下の通り表されます。
+---//---+
| |
+---//---+
+---//---+ | | +---//---+
Each Element has up to five components: an Identifier, a
Length Code, a Qualifier, a Property-List, and the Data Element
Contents.
各Elementには、最大5つのコンポーネントがあります: 識別子、長さのコード、資格を与える人、特性リスト、およびデータ要素コンテンツ。
In the diagrams, the contents of the identifier octet is
ダイヤグラムで、識別子八重奏のコンテンツはそうです。
45
Section 4.3.1
45 セクション4.3.1
shown as a "P" followed by an identifier represented in binary.
(See Figure 4.)
「P」がバイナリーで表された識別子で続いたので、目立ちます。 (図4を参照してください。)
A length code is always represented in the following manner:
長さのコードはいつも以下の方法で表されます:
+---//---+
|Lxxxxxxx|
+---//---+
+---//---+ |Lxxxxxxx| +---//---+
A qualifier is always represented in the following manner:
資格を与える人はいつも以下の方法で代理をされます:
+---//---+
|Qxxxxxxx|
+---//---+
+---//---+ |Qxxxxxxx| +---//---+
A Property-List (if present) always immediately precedes any
occurrence of Data Element Contents.
Property-リスト(存在しているなら)はすぐに、いつもData Element Contentsのどんな発生にも先行します。
The Data Element Contents appears in diagrams as one of the
following:
Data Element Contentsは以下の1つとしてダイヤグラムで現れます:
o "element(s)", which may be any data element(s)
o どんなデータ要素であるかもしれない「要素」(s)
o "anything," which is undefined and may be any combi-
nation of bits
o 未定義であり、いずれかがビットのcombi国であったなら未定義であるかもしれない「何でも」
o a specific data element
o 特定のデータ要素
o the interpretation to be applied to the bits within the
octets that constitute the element (such as ASCII or
Integer)
o 要素を構成する八重奏の中でビットに適用されるべき解釈(ASCIIか整数などの)
Two data elements have been reserved for special purposes.
The Extension data element is provided to allow for future
expansion of the possible data elements. The Vendor-Defined data
element allows CBMS vendors to define their own data elements.
Vendor-Defined data elements are not guaranteed to be unique,
since two implementations could define different data elements
using the same identifier. Vendor-Defined data elements should
be used and interpreted by prior agreement.
2つのデータ要素が特別な目的のために予約されました。 可能なデータ要素の今後の拡張を考慮するためにExtensionデータ要素を提供します。 Vendorによって定義されたデータ要素で、CBMSベンダーはそれら自身のデータ要素を定義できます。 ベンダーによって定義されたデータ要素は特有になるように保証されません、2つの実装が同じ識別子を使用することで異なったデータ要素を定義するかもしれないので。 ベンダーによって定義されたデータ要素は、あらかじめ取り決めて使用されて、解釈されるべきです。
In the following sections, each element is presented with
its name, compliance classification (BASIC or OPTIONAL), its
identifier (both in hexadecimal and in octal), a brief
description of its use, and a graphic representation. Each data
element description has the following form.
以下のセクションでは、名前、承諾分類(BASICかOPTIONAL)、識別子(16進と8進の)、使用の簡単な説明、およびグラフィック表示を各要素に与えます。 それぞれのデータ要素記述で、以下は形成されます。
46
Section 4.3.1
46 セクション4.3.1
-----------------------------------------------------------------
-----------------------------------------------------------------
Data Element (Compliance) identifier identifier
Name ( Category ) octet octet
16 8
データElement(承諾)識別子識別子Name(カテゴリ)八重奏八重奏16 8
Description of the syntax of the data element.
データ要素の構文の記述。
+---//---+
| | Diagram representing data element
+---//---+
+---//---+ | | データ要素+を表すダイヤグラム---//---+
-----------------------------------------------------------------
-----------------------------------------------------------------
4.3.1.1 Primitives
4.3.1.1 基関数
The data elements in this section are arranged in
alphabetical order by name. (Appendix C presents the identifiers
in numeric order.)
このセクションのデータ要素はアルファベット順に名前によってアレンジされます。 (付録Cは番号順で識別子を提示します。)
ASCII-String (BASIC) 02 002
16 8
This data element contains a series of ASCII
characters [NatB-80], each character right-justified in
one octet. For 7-bit ASCII characters, the most
significant bit of each octet must be 0.
ASCII-ストリング(BASIC)02 002 16 8Thisデータ要素は一連のASCII文字[NatB-80](1つの八重奏でまさしく正当なそれぞれのキャラクタ)を含みます。 7ビットのASCII文字にとって、それぞれの八重奏の最も重要なビットは0であるに違いありません。
Note: The ASCII code table can be extended through
standardized techniques [NatB-75] to introduce addi-
tional 7-bit or 8-bit characters or additional code
tables.
以下に注意してください。 標準化されたテクニック[NatB-75]でaddi- tionalの7ビットの、または、8ビットのキャラクタか追加コードテーブルを紹介するためにASCIIコードテーブルを広げることができます。
+--------+---//---+----//-----+
|P0000010|Lxxxxxxx|ASCII chars|
+--------+---//---+----//-----+
+--------+---//---+----//-----+ |P0000010|Lxxxxxxx|ASCII雑用| +--------+---//---+----//-----+
47
Section 4.3.1.1
47部4.3 .1 .1
Bit-String (OPTIONAL) 43 103
16 8
This data element contains a series of bits. It uses
the Qualifier data element component to record the
number of bits of padding (as an eight bit unsigned
integer) needed to fill the final octet of the Data
Element Contents to an even octet boundary. These
padding bits have no meaning and occur in the low order
bits of the final octet. The valid values for the
Qualifier component are 0 through 7. The number of
bits in the Data Element Contents is calculated from
the following formula.
ビットストリング(OPTIONAL)43 103 16 8Thisデータ要素は一連のビットを含んでいます。 それは、同等の八重奏境界にData Element Contentsの最終的な八重奏をいっぱいにするのが必要である詰め物(8の噛み付いている符号のない整数としての)のビットの数を記録するのにQualifierデータ要素成分を使用します。 ビットを水増しするこれらが、意味でないのを持って、最終的な八重奏の下位のビットに起こります。 Qualifierの部品のための有効値は、0〜7です。 Data Element Contentsのビットの数は以下の公式から計算されます。
8 * number of octets - value of
in the Data Qualifier component
Element Contents
8 八重奏の*番号--コネの値、Data Qualifierの部品Element Contents
+--------+---//---+---//---+---//---+
|P1000011|Lxxxxxxx|Qxxxxxxx| bits |
+--------+---//---+---//---+---//---+
+--------+---//---+---//---+---//---+ |P1000011|Lxxxxxxx|Qxxxxxxx| ビット| +--------+---//---+---//---+---//---+
Boolean (OPTIONAL) 08 010
16 8
This data element contains one octet whose value is
either true or false. False is represented by all bits
being 0; true is represented by all bits being 1
(although any non-zero value should be interpreted as
true).
ブール(OPTIONAL)08 010 16 8Thisデータ要素は値が本当であるか、または誤っている1つの八重奏を含んでいます。 偽は0であるすべてのビットによって表されます。 本当である、1(どんな非ゼロ値も本当であると解釈されるべきですが)であるすべてのビットで、表されます。
+--------+---//---+--------+
|P0001000|Lxxxxxxx| T or F |
+--------+---//---+--------+
+--------+---//---+--------+ |P0001000|Lxxxxxxx| TかF| +--------+---//---+--------+
End-of-Constructor (BASIC) 01 001
16 8
This data element terminates the Data Element Contents
in a constructor data element that has indefinite
length. This data element has no Contents component.
(Use of this element is described in Section 4.2.2.1.)
建設者の終わりの(BASIC)01 001 16 8Thisデータ要素は無期長さを持っている建設者データ要素でData Element Contentsを終えます。 このデータ要素には、Contentsの部品が全くありません。 (この要素の使用はセクション4.2.2で.1に説明されます)
+--------+---//---+
|P0000001|Lxxxxxxx|
+--------+---//---+
+--------+---//---+ |P0000001|Lxxxxxxx| +--------+---//---+
48
Section 4.3.1.1
48部4.3 .1 .1
Integer (OPTIONAL) 20 040
16 8
This data element contains a 2's complement integer of
variable length, high order octet first. It is
recommended that the data element contents be either 2
or 4 octets long whenever possible.
整数(OPTIONAL)20 040 16 8Thisデータ要素は最初に、2整数の可変長、高位八重奏の補数ものを含みます。 可能であるときはいつも、データ要素コンテンツが長い間2か4つの八重奏であることがお勧めです。
+--------+---//---+---//---+
|P0100000|Lxxxxxxx| Integer|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P0100000|Lxxxxxxx| 整数| +--------+---//---+---//---+
No-Op (OPTIONAL) 00 000
16 8
This data element does nothing. No-Op is used whenever
it is necessary to include a data element that means
"no operation." It is a short placeholder.
オプアートがない(OPTIONAL)00 000 16 8Thisデータ要素は何もしません。 「操作がありません」を意味するデータ要素を含むのが必要であるときはいつも、どんなオプアートも使用されていません。 それは短いプレースホルダです。
+--------+---//---+
|P0000000|Lxxxxxxx|
+--------+---//---+
+--------+---//---+ |P0000000|Lxxxxxxx| +--------+---//---+
Padding (OPTIONAL) 21 041
16 8
This data element is used to fill any number of octets.
The contents of a Padding element are undefined and
convey no information.
(OPTIONAL)21 041を水増しして、16 8Thisデータ要素は、いろいろな八重奏をいっぱいにするのに使用されます。 Padding要素の内容は、未定義であり、情報を全く伝えません。
+--------+---//---+---//---+
|P0100001|Lxxxxxxx|anything|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P0100001|Lxxxxxxx|何でも| +--------+---//---+---//---+
4.3.1.2 Constructors
4.3.1.2 建設者
The data elements in this section are arranged in alpha-
betical order.
このセクションのデータ要素はアルファbeticalオーダーに配置されます。
49
Section 4.3.1.2
49部4.3 .1 .2
Compressed (OPTIONAL) 46 106
16 8
This data element must contain a Bit-String data
element. It is used to represent any data that has
been compressed; it may be used wherever its
uncompressed contents may appear. A Qualifier data
component appears in each Compressed data element; it
contains a compression identifier (CID) to identify
the compression algorithm used. (See Section 4.3.5.)
The Data Element Contents contains the product of the
compression process.
圧縮された(OPTIONAL)46 106 16 8Thisデータ要素はBit-列データ要素を含まなければなりません。 それは圧縮されたどんなデータも表すのに使用されます。 解凍されたコンテンツがどこに見えても、それは使用されるかもしれません。 Qualifierデータ構成要素はそれぞれのCompressedデータ要素に現れます。 それは使用される圧縮アルゴリズムを特定する圧縮識別子(CID)を含んでいます。 (セクション4.3.5を見てください。) Data Element Contentsは圧縮プロセスの製品を含んでいます。
+--------+---//---+---//---+--------//--------+
|P1000110|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+
+--------+---//---+---//---+--------//--------+ |P1000110|Lxxxxxxx|Qxxxxxxx|ビット列要素| +--------+---//---+---//---+--------//--------+
Date (BASIC) 28 050
16 8
This data element contains an ASCII-String data
element, which is a representation of a date and time
formatted in accordance with PUBS 4 [NatB-68],
58 [NatB-79a] and 59 [NatB-79b]. The use of time and
time zone is optional. It is recommended that numeric
offsets be used to indicate time zone rather than
alphabetic abbreviations.
日付の(BASIC)28 050 16 8Thisデータ要素はASCII-列データ要素を含んでいます。(それは、PUBS4[NatB-68]、58[NatB-79a]と59[NatB-79b]に従ってフォーマットされた日時の表現です)。 時間と時間帯の使用は任意です。 数値オフセットがアルファベット略語よりむしろ時間帯を示すのに使用されるのは、お勧めです。
+--------+---//---+------//------+
|P0101000|Lxxxxxxx| ASCII-String |
+--------+---//---+------//------+
+--------+---//---+------//------+ |P0101000|Lxxxxxxx| ASCII-ストリング| +--------+---//---+------//------+
Encrypted (OPTIONAL) 47 107
16 8
This data element must contain a Bit-String. It is
used to represent any data that has been encrypted; it
may be used wherever its unencrypted contents may
appear. A Qualifier data component appears in each
Encrypted data element; it contains an encryption
identifier (EID) identifying the encryption algorithm
used. The Data Element Contents is the product of the
encryption process.
暗号化された(OPTIONAL)47 107 16 8Thisデータ要素はBit-ストリングを含まなければなりません。 それは暗号化されたどんなデータも表すのに使用されます。 非暗号化されたコンテンツがどこに見えても、それは使用されるかもしれません。 Qualifierデータ構成要素はそれぞれのEncryptedデータ要素に現れます。 それは、使用される暗号化アルゴリズムを特定しながら、暗号化識別子(EID)を含んでいます。 Data Element Contentsは暗号化プロセスの製品です。
+--------+---//---+---//---+--------//--------+
|P1000111|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+
+--------+---//---+---//---+--------//--------+ |P1000111|Lxxxxxxx|Qxxxxxxx|ビット列要素| +--------+---//---+---//---+--------//--------+
50
Section 4.3.1.2
50部4.3 .1 .2
Field (BASIC) 4C 114
16 8
This data element uses a Qualifier data element
component. The Qualifier component contains a Field
Identifier (FID) indicating which specific field is
being represented.
分野(BASIC)4C114 16 8Thisデータ要素はQualifierデータ要素成分を使用します。 どの特定の分野が表されているかを示しながら、Qualifierの部品はField Identifier(FID)を含んでいます。
+--------+---//---+---//---+---//---+
|P1001100|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+
+--------+---//---+---//---+---//---+ |P1001100|Lxxxxxxx|Qxxxxxxx|要素| +--------+---//---+---//---+---//---+
Message (BASIC) 4D 115
16 8
This data element may contain Field or Message data
elements. Its Qualifier component contains a Message
type (MID) indicating the type of the message. (The
MID is completely different from the message identifier
in the Message-ID field and should not be confused with
it.)
メッセージ(BASIC)4D115 16 8Thisデータ要素はFieldかMessageデータ要素を含むかもしれません。 Qualifierの部品は、メッセージのタイプを示しながら、Messageタイプ(MID)を含んでいます。 (MIDはMessage-ID分野のメッセージ識別子と完全に異なって、それに混乱しているべきではありません。)
+--------+---//---+---//---+
|P1001101|Lxxxxxxx|Qxxxxxxx|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P1001101|Lxxxxxxx|Qxxxxxxx| +--------+---//---+---//---+
+--------//---------//---------//---------//--------+
| Field, Message, Encrypted, or Compressed Elements |
+--------//---------//---------//---------//--------+
+--------//---------//---------//---------//--------+ | 分野(メッセージ)は、Elementsを暗号化したか、または圧縮しました。| +--------//---------//---------//---------//--------+
Property-List (OPTIONAL) 24 044
16 8
This data element contains a series of Property data
elements to be associated with another data element.
16 8Thisデータ要素が別のデータ要素に関連しているように一連のPropertyデータ要素に含む特性リスト(OPTIONAL)24 044。
+--------+---//---+-------//--------+
|P0100100|Lxxxxxxx|Property Elements|
+--------+---//---+-------//--------+
+--------+---//---+-------//--------+ |P0100100|Lxxxxxxx|特性の要素| +--------+---//---+-------//--------+
Property (OPTIONAL) 45 105
16 8
This data element uses a Qualifier data element
component. The Qualifier component contains
a Property-Identifier (PID) to indicate which specific
property is being represented.
特性(OPTIONAL)45 105の16 8Thisデータ要素はQualifierデータ要素成分を使用します。 Qualifierの部品はどの特定の性質が表されているかを示すProperty-識別子(PID)を含んでいます。
+--------+---//---+---//---+---//---+
|P1000101|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+
+--------+---//---+---//---+---//---+ |P1000101|Lxxxxxxx|Qxxxxxxx|要素| +--------+---//---+---//---+---//---+
51
Section 4.3.1.2
51部4.3 .1 .2
Sequence (OPTIONAL) 0A 012
16 8
This data element contains any series of data elements.
Sequence differs from Set in that the data elements
making up the Data Element Contents must be considered
as an ordered sequence (according to their order of
appearance in the sequence.)
系列(OPTIONAL)0A012 16 8Thisデータ要素はどんなシリーズのデータ要素も含んでいます。 系列は規則正しい系列であるとData Element Contentsを作るデータ要素をみなさなければならないという点においてSetと異なっています。(彼らの系列における外観の注文に従って。)
+--------+---//---+---//---+
|P0001010|Lxxxxxxx|elements|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P0001010|Lxxxxxxx|要素| +--------+---//---+---//---+
Set (OPTIONAL) 0B 013
16 8
This data element contains any series of data elements
with no ordering of the elements implied. (Sequence
provides an ordered series.) Although the data
elements contained in a Set must be stored
sequentially, the order in which they are stored is not
defined and not processed.
セット(OPTIONAL)0B013 16 8Thisデータ要素は要素の暗示している注文なしでどんなシリーズのデータ要素も含んでいます。 (系列は規則正しいシリーズを提供します。) Setに含まれたデータ要素を連続して保存しなければなりませんが、それらが保存される注文を定義しないで、また処理しません。
+--------+---//---+---//---+
|P0001011|Lxxxxxxx|elements|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P0001011|Lxxxxxxx|要素| +--------+---//---+---//---+
Unique-ID (OPTIONAL) 09 011
16 8
This data element is a unique identifier. It need not
be human-readable. The Data Element Contents may be an
ASCII-String, a Bit-String, or an Integer.
固有のID(OPTIONAL)09 011 16 8Thisデータ要素はユニークな識別子です。 それは人間読み込み可能である必要はありません。 Data Element ContentsはASCII-ストリング、Bit-ストリング、またはIntegerであるかもしれません。
+--------+---//---+---//---+
|P0001001|Lxxxxxxx| element|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P0001001|Lxxxxxxx| 要素| +--------+---//---+---//---+
4.3.1.3 Data Elements that Extend this Specification
4.3.1.3 Data Elements、そのExtend、このSpecification
There are two data elements that are used to extend this
specification. They can be classified as either primitive or
constructor data elements, depending on the extension.
この仕様を広げるのに使用される2つのデータ要素があります。 拡大によって、それらは同じくらい原始か建設者の分類されたデータ要素であるかもしれません。
52
Section 4.3.1.3
52部4.3 .1 .3
Extension (OPTIONAL) 7E 176
16 8
This data element is used to extend the number of
available data elements beyond the 128 that are
possible using a 7-bit identifier. A Qualifier
component extends the encoding space for identifiers.
(Extension and Vendor-Defined have the same syntax.)
拡大(OPTIONAL)7E176 16 8Thisデータ要素は、7ビットの識別子を使用することで可能な128を超えて有効なデータ要素の数を広げるのに使用されます。 Qualifierの部品は識別子のためにコード化スペースを広げています。 (拡大であってVendorによって定義される、同じ構文)。
+--------+---//---+---//---+---//---+
|P1111110|Lxxxxxxx|Qxxxxxxx|Anything|
+--------+---//---+---//---+---//---+
+--------+---//---+---//---+---//---+ |P1111110|Lxxxxxxx|Qxxxxxxx|何でも| +--------+---//---+---//---+---//---+
Vendor-Defined (OPTIONAL) 7F 177
16 8
This data element is used to represent vendor- and
user-defined data elements. A Qualifier component
extends the encoding space for identifiers. The
Qualifier component is not guaranteed to be unique
among all interconnected systems. This data element is
interpreted according to prior agreement between
systems. (Extension and Vendor-Defined data elements
have the same syntax.)
ベンダーによって定義された(OPTIONAL)7F177 16 8Thisデータ要素は、ベンダーとユーザによって定義されたデータ要素を代表するのに使用されます。 Qualifierの部品は識別子のためにコード化スペースを広げています。 Qualifierの部品は、すべての相互接続システムの中で特有になるように保証されません。このデータ要素はシステムの間の事前同意通りに解釈されます。(拡大とVendorによって定義されたデータ要素には、同じ構文があります。)
+--------+---//---+---//---+---//---+
|P1111111|Lxxxxxxx|Qxxxxxxx|Anything|
+--------+---//---+---//---+---//---+
+--------+---//---+---//---+---//---+ |P1111111|Lxxxxxxx|Qxxxxxxx|何でも| +--------+---//---+---//---+---//---+
4.3.2 Using data elements within message fields
4.3.2 メッセージ分野の中でデータ要素を使用すること。
The Data Element Contents of a particular field in a message
must contain at least one data element. The types of data
elements that can appear in the Data Element Contents of a field
are restricted according to what kind of field it is. Appendix A
(the master reference appendix for fields) defines which data
elements are valid as the Contents for each of the fields.
メッセージの特定の分野のData Element Contentsは少なくとも1つのデータ要素を含まなければなりません。 それがどういう分野であるかに従って、分野のData Element Contentsに現れることができるデータ要素のタイプは制限されます。 付録A(分野へのマスター参照付録)は、どのデータ要素がそれぞれの分野へのContentsとして有効であるかを定義します。
Some fields have a Data Element Contents that contains
"originators" or "recipients." No data element represents the
identities of originators or recipients (because that encoding is
not within the scope of this message format specification.)
These descriptions simply list "originators" or "recipients",
implying no restrictions on how the identifiers for originators
or recipients are represented.
いくつかの分野には、「創始者」か「受取人」を含むData Element Contentsがあります。 どんなデータ要素も創始者か受取人のアイデンティティを表しません(このメッセージの範囲の中にそのコード化がないので、仕様をフォーマットしてください。)。 創始者か受取人への識別子がどう表されるかに関する制限を全く含意しないで、これらの記述は単に「創始者」か「受取人」を記載します。
53
Section 4.3.3
53 セクション4.3.3
4.3.3 Properties and associated elements
4.3.3 特性と関連要素
This message format specification defines two properties.
このメッセージ書式仕様は2つの特性を定義します。
Comment 01 001
16 8
This property may contain any series of data elements;
it most commonly contains one or more ASCII-Strings.
コメント01 001 16 8Thisの特性はどんなシリーズのデータ要素も含むかもしれません。 それは最も一般的に1個以上のASCII-ストリングを含んでいます。
Printing-Name 02 002
16 8
This property contains one ASCII-String. In this case,
the ASCII-String may contain only the printing ASCII
characters plus the "space" character.
印刷名の02 002 16 8Thisの特性は1個のASCII-ストリングを含んでいます。 この場合、ASCII-ストリングは印刷ASCII文字と「スペース」キャラクタだけを含むかもしれません。
4.3.4 Encryption identifiers
4.3.4 暗号化識別子
This message format specification defines two encryption
identification codes.
このメッセージ書式仕様は2つの暗号化識別コードを定義します。
Unspecified 00 000
16 8
Use of this encryption identifier as part of the
Encrypted data element indicates that the encryption
method being used was not specified for inclusion as
part of the data element.
不特定である、00 000 16 8 Encryptedデータ要素の一部としてのこの暗号化識別子のUseは、使用される暗号化メソッドがデータ要素の一部として包含に指定されなかったのを示します。
FIPS-Standard 01 001
16 8
Use of this encryption identifier as part of the
Encrypted data element indicates that the Federal
Information Processing Standard method for data
encryption was [NatB-77].
FIPS-規格、01 001 16 8 Encryptedデータ要素の一部としてのこの暗号化識別子のUseは、データ暗号化のための連邦情報処理基準メソッドが[NatB-77]であったと示します。
4.3.5 Compression identifiers
4.3.5 圧縮識別子
This message format specification defines one compression
identification code for use with the Compressed data element.
このメッセージ書式仕様は使用のためにCompressedデータ要素で1つの圧縮識別コードを定義します。
Unspecified 00 000
16 8
Use of this compression identifier as part of the
Compressed data element indicates that the compression
method being used was not specified for inclusion as
part of the data element.
不特定である、00 000 16 8 Compressedデータ要素の一部としてのこの圧縮識別子のUseは、使用される圧縮方法がデータ要素の一部として包含に指定されなかったのを示します。
54
Section 4.3.6
54 セクション4.3.6
4.3.6 Message types
4.3.6 メッセージタイプ
This message format specification defines message type (MID)
codes for use in classifying the type of a message. The message
type could be confused with the message identifier in the
Message-Id field; they are completely distinct concepts.
このメッセージ書式仕様はメッセージのタイプを分類することにおける使用のためにメッセージタイプ(MID)コードを定義します。 メッセージタイプはMessage-イド分野のメッセージ識別子に混乱できました。 それらは完全に異なった概念です。
FIPS-Standard 01 01
16 8
This message type marks messages defined by this
message format specification.
メッセージがこのメッセージで定義した01 01 16のFIPS標準の8Thisメッセージタイプマークが仕様をフォーマットします。
55
55
SUMMARY OF APPENDIXES
付属物の概要
Appendix A Defines the fields in the message format specifi-
cation. This alphabetical appendix is for reference
use by implementors. It contains semantic
definitions of fields from Section 3.1. It also
defines Field Identifier values and specifies which
data elements are valid as the Contents for each of
the fields.
メッセージの分野がフォーマットする付録A Definesは陽イオンをspecifiします。 このアルファベット順付録は作成者による参照使用のためのものです。 それはセクション3.1からの分野の意味定義を含んでいます。 それは、また、Field Identifier値を定義して、どのデータ要素がそれぞれの分野へのContentsとして有効であるかを指定します。
Appendix B Defines the data elements in the message format
specification. This alphabetically ordered appendix
is for reference use by implementors. It consol-
idates information from Section 4.3.
メッセージのデータ要素がフォーマットする付録B Defines、仕様。 このアルファベット順に、規則正しい付録は作成者による参照使用のためのものです。 それ、セクション4.3からのコンソルidates情報
Appendix C Provides a reference table listing the data elements
in numerical order by their identifier octets.
番号順に彼らの識別子八重奏でデータ要素を記載する参照がテーブルの上に置く付録C Provides。
Appendix D Provides a reference table summarizing the components
of messages according to whether they are required or
optional for CBMSs implementing the specification.
仕様を履行するCBMSsに、それらが必要であるか、または任意であるかに従ってメッセージの成分をまとめる参照がテーブルの上に置く付録D Provides。
Appendix E Provides a reference table organizing the message
components according to the functional class of the
components.
コンポーネントの機能クラスによると、メッセージコンポーネントを組織化する参照がテーブルの上に置く付録E Provides。
Appendix F Provides an overview of the syntactic elements
defined by this message format specification.
構文の要素の概要がこのメッセージで定義した付録F Providesは仕様をフォーマットします。
Appendix G Summarizes syntactic elements according to whether
they are required or optional for a CBMS implementing
the message format specification.
メッセージ書式仕様を実装するCBMSに、それらが必要であるか、または任意であるかに従った付録のG Summarizesの構文の要素。
Appendix H Examples of each syntactic element displaying their
syntax and describing their associated semantics.
彼らの構文を表示して、彼らの関連意味論について説明するそれぞれの構文の要素の付録H Examples。
56
Appendix A
56 付録A
APPENDIX A
FIELDS -- IMPLEMENTORS' MASTER REFERENCE
APPENDIXフィールズ--作成者のマスター参照
This appendix defines all of the fields in the message
format specification for reference use by implementors. It
contains semantics definitions of fields from Section 3.1. It
also defines Field Identifier values and which data elements are
valid as the Contents for each of the fields. The field
definitions appear alphabetically.
この付録は作成者による参照使用のためにメッセージ書式仕様で分野のすべてを定義します。 それはセクション3.1からの分野の意味論定義を含んでいます。 また、それは、Field Identifier値であってどのデータ要素がそれぞれの分野へのContentsとして有効であるかを定義します。 アルファベット順に、フィールド定義は現れます。
Each field in the list has the following form:
リストの各分野で、以下は形成されます:
------------------------------------------------------------
------------------------------------------------------------
Field Name Compliance identifier identifier
value value
16 8
分野Name Compliance識別子識別子値の価値16の8
Description of the field semantics. Names of
data elements that are valid in the Data Element
Contents of this kind of field.
分野意味論の記述。 この種類の分野のData Element Contentsで有効なデータ要素の名前。
------------------------------------------------------------
------------------------------------------------------------
Attachments OPTIONAL 08 010
16 8
This field contains additional data accompanying a
message. It is similar in intent to enclosures in a
conventional mail system. Contents of this field are
unrestricted.
付属OPTIONAL08 010 16 8This分野はメッセージに伴う追加データを含んでいます。 それは意図において従来のメールシステムの包囲と同様です。 この分野の内容は無制限です。
Author OPTIONAL 0C 014
16 8
This field identifies the individual(s) who wrote the
primary contents of the message. Use of the Author
field is discouraged when the contents of the Author
field and the From field would be completely redundant.
This field contains one or more originator identities.
8Thisがさばく作者OPTIONAL0C014 16はメッセージのプライマリコンテンツを書いた個人を特定します。 Author分野とFrom分野のコンテンツが完全に余分であるだろうというときに、Author分野の使用はお勧めできないです。 この分野は1つ以上の創始者のアイデンティティを含んでいます。
57
Appendix A
57 付録A
Bcc OPTIONAL 0D 015
16 8
This field identifies additional recipients for a
message (a "blind carbon copies list"). The contents
of this field are not to be included in copies of the
message sent to the primary and secondary recipients.
See section 3.2.1 for further discussion of the use of
blind carbon copies lists. This field contains one or
more recipient identities.
Bcc OPTIONAL 0D015 16 8This分野はメッセージ(「盲目のカーボンコピーリスト」)のために追加受取人を特定します。 この分野の内容はプライマリの、そして、セカンダリの受取人に送られたメッセージのコピーに含まれないことです。 盲目のカーボンコピーリストの使用のさらなる議論に関してセクション3.2.1を見てください。 この分野は1つ以上の受取人のアイデンティティを含んでいます。
Cc BASIC 06 006
16 8
This field identifies secondary recipients for a
message (a "carbon copies" list). This field contains
one or more recipient identities.
cc BASIC06 006 16 8This分野はメッセージ(「カーボンコピー」リスト)のためにセカンダリ受取人を特定します。 この分野は1つ以上の受取人のアイデンティティを含んでいます。
Circulate-Next OPTIONAL 0E 016
16 8
This field is used in conjunction with the Circulate-To
field. (See Section 3.2.6.1 for further discussion.)
It identifies all recipients in a circulation list who
have not yet received the message. This field contains
one or more recipient identities.
に関連して16 8Thisがさばく-次に循環しているOPTIONAL0E016が使用されている、Circulate、-、分野 セクション3.2を見てください。(.6 .1 さらなる議論のために) それは流通リストのまだメッセージを受け取っていないすべての受取人を特定します。 この分野は1つ以上の受取人のアイデンティティを含んでいます。
Circulate-To OPTIONAL 0F 017
16 8
This field identifies recipients for a circulated
message. (See Section 3.2.6.1 for further discussion.)
It is used in conjunction with the Circulate-Next
field. This field contains one or more recipient
identities.
循環、-、OPTIONAL0F017 16 8This分野は循環しているメッセージのために受取人を特定します。 セクション3.2を見てください。(.6 .1 さらなる議論のために) それは次のCirculate分野に関連して使用されます。 この分野は1つ以上の受取人のアイデンティティを含んでいます。
Comments OPTIONAL 10 020
16 8
This field permits adding comments onto the message
without disturbing the original contents of the
message. While the Comments field will usually contain
one or more ASCII-Strings, there are no restrictions on
its contents.
コメントOPTIONAL10 020 16 8Thisは、メッセージに関するオリジナルコンテンツを擾乱しないでコメントをメッセージに追加しながら、許可証をさばきます。 Comments分野は通常1個以上のASCII-ストリングを含むでしょうが、制限が全くコンテンツにありません。
Date OPTIONAL 11 021
16 8
This field contains a date that the message's
originator wishes to associate with a message. The
Date field is to the Posted-Date field as the date on a
letter is to the postmark added by the post office.
This field contains one Date.
16 8This分野がメッセージの創始者がメッセージと交際したがっている日付に含む021とOPTIONAL11をデートしてください。 郵便局によって加えられた消印には手紙に関する日付があるようにPosted-年月日欄にはDate分野があります。 この分野は1Dateを含んでいます。
58
Appendix A
58 付録A
End-Date OPTIONAL 12 022
16 8
This field contains the date on which a message loses
effect. (See also Section 3.2.5 for further
discussion.) This field contains one Date.
OPTIONAL12 022 16 8This分野がメッセージが効力を失う日付を含む終わり-日付。 (また、さらなる議論に関してセクション3.2.5を見てください。) この分野は1Dateを含んでいます。
From REQUIRED 01 001
16 8
This field contains the identity of the originators
taking formal responsibility for this message. The
contents of the From field is to be used for replies
when no Reply-to field appears in a message. This
field contains one or more originator identities.
REQUIRED01 001から、16 8This分野はこのメッセージへの正式な責任を取る創始者のアイデンティティを含んでいます。 From分野のコンテンツがいいえときに、回答に使用されることである、Reply、-、野原はメッセージに現れます。 この分野は1つ以上の創始者のアイデンティティを含んでいます。
In-Reply-To OPTIONAL 13 023
16 8
This field designates previous correspondence to which
this message is a reply. The usual contents of this
field would be the contents of the Message-ID field of
the message(s) being replied to. This field contains
one or more Unique-IDs or ASCII-Strings.
中で答える、OPTIONAL13 023 16 8This分野はこのメッセージが回答である前の通信を指定します。 この分野の普通のコンテンツは答えられるメッセージのMessage-ID分野のコンテンツでしょう。 この分野は1個以上のUnique-IDかASCII-ストリングを含んでいます。
Keywords OPTIONAL 14 024
16 8
This field contains keywords or phrases for use in
retrieving a message. This field contains one or more
ASCII-Strings. (Each keyword or phrase is represented
by a separate ASCII-String.)
キーワードOPTIONAL14 024 16 8This分野はメッセージを検索することにおける使用のためのキーワードか句を含んでいます。 この分野は1個以上のASCII-ストリングを含んでいます。 (各キーワードか句が別々のASCII-ストリングによって表されます。)
Message-Class OPTIONAL 15 025
16 8
This field indicates the purpose of a message. For
example, it might contain values indicating that the
message is a memorandum or a data-base entry. This
field contains one data element, an ASCII-String.
メッセージクラスOPTIONAL15 025 16 8This分野はメッセージの目的を示します。 例えば、それはメッセージがメモであることを示す値かデータベースエントリーを含むかもしれません。 この分野は1つのデータ要素、ASCII-ストリングを含んでいます。
Message-ID OPTIONAL 16 026
16 8
This field contains a unique identifier for a message.
This identifier is intended for machine generation and
processing. Further definition appears in Section
3.2.4.1. Only one Message-ID field is permitted in a
message. This field contains one data element, a
Unique-ID.
メッセージ-ID OPTIONAL16 026 16 8This分野はメッセージのためのユニークな識別子を含んでいます。 この識別子はマシン世代と処理のために意図します。 さらなる定義はセクション3.2.4に.1に現れます。 1つのMessage-ID分野だけがメッセージで受入れられます。 この分野は1つのデータ要素、Unique-IDを含んでいます。
Obsoletes OPTIONAL 26 046
16 8
This field identifies one or more messages that this
one supplants. This field contains at least one
Unique-ID and may contain more than one.
時代遅れに、OPTIONAL26 046 16 8This分野はこれが取って代わる1つ以上のメッセージを特定します。 この分野は、少なくとも1Unique-IDを含んでいて、1つ以上を含むかもしれません。
59
Appendix A
59 付録A
Originator-Serial-Number OPTIONAL 17 027
16 8
This field contains one or more serial numbers assigned
by the message's originator. (Messages with multiple
recipients should all have the same value in the
Originator-Serial-Number field. This field contains
one or more ASCII-Strings. (One ASCII-String is used
for each serial number.)
16 8Thisがさばく創始者シリーズ番号OPTIONAL17 027はメッセージの創始者によって割り当てられた1つ以上の通し番号を含んでいます。 複数の受取人がいるメッセージにはすべて、Originatorの連続のナンバーフィールドにおける同じ値があるべきです。(この分野は1個以上のASCII-ストリングを含んでいます。(1つのASCII-ストリングは各通し番号に使用されます。)
Posted-Date REQUIRED 02 002
16 8
This field contains the posting date, which is the
point in time when the message passes through the
posting slot into a message transfer system. Only one
Posted-Date field is permitted in a message. This
field contains one Date.
16 8This分野がメッセージが任命スロットをメッセージ転送システムに通り抜けるときの時間内にのポイントである投函日に含む掲示された期日REQUIRED02 002。 1つのPosted-年月日欄だけがメッセージで受入れられます。 この分野は1Dateを含んでいます。
Precedence OPTIONAL 18 030
16 8
Ordinarily, message precedence or priority is a service
request to a message transfer system. A message
originator, however, can include precedence information
in a message. This field indicates the precedence at
which the message was posted. One example of a
precedence scheme is the US Military categories
"ROUTINE", "PRIORITY", "IMMEDIATE", "FLASH OVERRIDE",
and "EMERGENCY COMMAND PRECEDENCE". This field
contains one ASCII-String.
先行OPTIONAL18 030 16の8Ordinarily、メッセージ先行または優先権がメッセージ転送システムへのサービスのリクエストです。 しかしながら、メッセージ創始者はメッセージで先行情報を入れることができます。 この分野はメッセージが掲示された先行を示します。 先行体系に関する1つの例が、米国のMilitaryカテゴリ「ルーチン」と、「優先権」と、「即座」の「フラッシュオーバーライド」と、「非常時のコマンド先行」です。 この分野は1個のASCII-ストリングを含んでいます。
Received-Date OPTIONAL 19 031
16 8
This field is also called Delivery date. It may be
added to a message by the recipient's message receiving
program. It indicates when the message left the
delivery system and entered the recipient's message
processing domain. This field contains one Date.
16 8Thisがさばく受信された期日OPTIONAL19 031はまた、呼ばれたDelivery期日です。 それはプログラムを受け取る受取人のメッセージによってメッセージに追加されるかもしれません。 それは、メッセージがいつ配送システムを発って、受取人のメッセージプロセッシング領域に入れたかを示します。 この分野は1Dateを含んでいます。
Received-From OPTIONAL 1A 032
16 8
This field contains a record of a message's path
through a message transfer system. The
recipient's message receiving program may store any
such information that it obtains from a message
transfer system in this field. The contents of this
field are unrestricted.
受け取っているOPTIONAL 1A032 16 8This分野はメッセージ転送システムを通してメッセージの経路に関する記録を含んでいます。 受取人のメッセージ受信プログラムはそれがこの分野のメッセージ転送システムから得るどんなそのような情報も保存するかもしれません。 この分野の内容は無制限です。
60
Appendix A
60 付録A
References OPTIONAL 20 040
16 8
This field identifies other correspondence that this
message references. If the other correspondence
contains a Message-ID field, the contents of the
References field must be the message identifier. This
field contains one or more Unique-IDs or ASCII-Strings.
参照OPTIONAL20 040 16 8This分野はこのメッセージが参照をつける他の通信を特定します。 もう片方の通信がMessage-ID分野を含んでいるなら、References分野のコンテンツはメッセージ識別子であるに違いありません。 この分野は1個以上のUnique-IDかASCII-ストリングを含んでいます。
Reissue-Type OPTIONAL 25 045
16 8
This field is used in conjunction with message
encapsulating (see Section 3.2.2) to differentiate
between messages being assigned or redistributed. This
field contains one data element, usually an ASCII-
String.
再発行タイプOPTIONAL25 045 16 8This分野は、割り当てられるか、または再配付されるメッセージを区別するのにメッセージ要約(セクション3.2.2を見る)に関連して使用されます。 この分野は1つのデータ要素、通常ASCIIストリングを含んでいます。
Reply-To BASIC 03 003
16 8
This field identifies any recipients for replies to the
message. This field contains one or more recipient
identities.
16 8This分野がどんな受取人も特定するBASIC03 003に答えてください。メッセージに答えます。 この分野は1つ以上の受取人のアイデンティティを含んでいます。
Sender OPTIONAL 22 042
16 8
This field identifies the agent who sent the message.
It is intended either for when the sender is not the
originator responsible for the message or to indicate
who among a group of originators responsible for the
message actually sent it. Use of the Sender field is
discouraged when the contents of the Sender field and
From field would be completely redundant. Only one
Sender field is permitted in a message. This field
contains one originator identity.
送付者OPTIONAL22 042 16 8This分野はメッセージを送ったエージェントを特定します。 送付者がメッセージに責任がある創始者でない時かだれが実際にメッセージに責任がある創始者のグループにそれを送ったかを示すのが意図しています。 Sender分野とFrom分野のコンテンツが完全に余分であるだろうというときに、Sender分野の使用はお勧めできないです。 1つのSender分野だけがメッセージで受入れられます。 この分野は1つの創始者のアイデンティティを含んでいます。
Start-Date OPTIONAL 23 043
16 8
This field contains the date on which a message takes
effect. (See Section 3.2.5 for further discussion.)
This field contains one Date.
スタート日付OPTIONAL23 043 16 8This分野はメッセージが実施する日付を含んでいます。 (さらなる議論に関してセクション3.2.5を見てください。) この分野は1Dateを含んでいます。
Subject BASIC 07 007
16 8
This field contains whatever information the originator
provided to summarize or indicate the nature of the
message. This field contains one or more ASCII-
Strings.
創始者がメッセージの本質をまとめるか、または示すためにどんな情報も提供したとしても、16 8This分野が含むBASIC07 007人をかけてください。 この分野は1個以上のASCIIストリングを含んでいます。
Text BASIC 04 004
16 8
This field contains the primary content of the message.
Contents of this field are unrestricted.
テキストBASIC04 004 16 8This分野はメッセージのプライマリ内容を含んでいます。 この分野の内容は無制限です。
61
Appendix A
61 付録A
To REQUIRED 05 005
16 8
This field identifies primary recipients for a message.
This field contains one or more recipient identities.
REQUIRED05 005まで、16 8This分野はメッセージのためにプライマリ受取人を特定します。 この分野は1つ以上の受取人のアイデンティティを含んでいます。
Warning-Date OPTIONAL 24 044
16 8
This field is used either alone or in conjunction with
an End-Date field. It contains one or more dates.
These dates could be used by a message processing
program as warnings of an impending end-date or other
event. (See Section 3.2.5 for further discussion.)
This field contains one or more Dates.
16 8Thisがさばく警告日付OPTIONAL24 044は単独かEnd-年月日欄に関連して使用されています。 それはより多くのある日付を含んでいます。 差し迫っている終了日か他のイベントに関する警告としてメッセージ処理プログラムでこれらの日付を使用できるでしょう。 (さらなる議論に関してセクション3.2.5を見てください。) この分野は1Datesを含んでいます。
62
Appendix B
62 付録B
APPENDIX B
DATA ELEMENTS -- IMPLEMENTORS' MASTER REFERENCE
付録Bデータ要素--作成者のマスター参照
The appendix defines all of the data elements in the message
format specification, for reference use by implementors. It
contains no new information but rather consolidates the syntactic
information from Section 4.3.
付録は作成者による参照使用のためにメッセージ書式仕様でデータ要素のすべてを定義します。 それは、新情報を全く含んでいませんが、むしろセクション4.3からの構文情報を統合します。
Each data element description has the following form.
それぞれのデータ要素記述で、以下は形成されます。
-----------------------------------------------------------------
-----------------------------------------------------------------
Data Element (Compliance) identifier identifier
Name ( Category ) octet octet
16 8
データElement(承諾)識別子識別子Name(カテゴリ)八重奏八重奏16 8
Constructive class (primitive or constructor)
建設的なクラス(基関数か建設者)
Description of the syntax of the data element.
データ要素の構文の記述。
+---//---+
| | Diagram representing data element
+---//---+
+---//---+ | | データ要素+を表すダイヤグラム---//---+
-----------------------------------------------------------------
-----------------------------------------------------------------
63
Appendix B
63 付録B
ASCII-String (BASIC) 02 002
16 8
primitive
ASCII-ストリング(BASIC)02 002 16 8基関数
This data element contains a series of ASCII characters
[NatB-80], each character right-justified in one
octet. For 7-bit ASCII characters, the most
significant bit of each octet must be 0.
このデータ要素は一連のASCII文字[NatB-80]、1つの八重奏でまさしく正当なそれぞれのキャラクタを含んでいます。 7ビットのASCII文字にとって、それぞれの八重奏の最も重要なビットは0であるに違いありません。
Note: The ASCII code table can be extended through
standardized techniques [NatB-75] to introduce addi-
tional 7-bit or 8-bit characters or additional code
tables.
以下に注意してください。 標準化されたテクニック[NatB-75]でaddi- tionalの7ビットの、または、8ビットのキャラクタか追加コードテーブルを紹介するためにASCIIコードテーブルを広げることができます。
+--------+---//---+----//-----+
|P0000010|Lxxxxxxx|ASCII chars|
+--------+---//---+----//-----+
+--------+---//---+----//-----+ |P0000010|Lxxxxxxx|ASCII雑用| +--------+---//---+----//-----+
Bit-String (OPTIONAL) 43 103
16 8
primitive
ビットストリング(OPTIONAL)43 103 16 8基関数
This data element contains a series of bits. It uses
the Qualifier data element component to record the
number of bits of padding (as an 8-bit unsigned
integer) needed to fill the final octet of the Data
Element Contents to an even octet boundary. These
padding bits have no meaning and occur in the low order
bits of the final octet. The valid values for the
Qualifier component are 0 through 7. The number of
bits in the Data Element Contents is calculated from
the following formula.
このデータ要素は一連のビットを含んでいます。 それは、同等の八重奏境界にData Element Contentsの最終的な八重奏をいっぱいにするのが必要である詰め物(8ビットの符号のない整数としての)のビットの数を記録するのにQualifierデータ要素成分を使用します。 ビットを水増しするこれらが、意味でないのを持って、最終的な八重奏の下位のビットに起こります。 Qualifierの部品のための有効値は、0〜7です。 Data Element Contentsのビットの数は以下の公式から計算されます。
8 * number of octets - value of
in the Data Qualifier component
Element Contents
8 八重奏の*番号--コネの値、Data Qualifierの部品Element Contents
+--------+---//---+---//---+---//---+
|P1000011|Lxxxxxxx|Qxxxxxxx| bits |
+--------+---//---+---//---+---//---+
+--------+---//---+---//---+---//---+ |P1000011|Lxxxxxxx|Qxxxxxxx| ビット| +--------+---//---+---//---+---//---+
64
Appendix B
64 付録B
Boolean (OPTIONAL) 08 010
16 8
primitive
ブール(OPTIONAL)08 010 16 8基関数
This data element contains one octet whose value is
either true or false. False is represented by all bits
being 0; true is represented by all bits being 1
(although any non-zero value should be interpreted as
true).
このデータ要素は値が本当であるか、または誤っている1つの八重奏を含んでいます。 偽は0であるすべてのビットによって表されます。 本当である、1(どんな非ゼロ値も本当であると解釈されるべきですが)であるすべてのビットで、表されます。
+--------+---//---+--------+
|P0001000|Lxxxxxxx| T or F |
+--------+---//---+--------+
+--------+---//---+--------+ |P0001000|Lxxxxxxx| TかF| +--------+---//---+--------+
Compressed (OPTIONAL) 46 106
16 8
constructor
圧縮された(OPTIONAL)46 106、16、8建設者
This data element must contain a Bit-String data
element. It is used to represent any data that has
been compressed; it may be used wherever its
uncompressed contents may appear. A Qualifier data
component appears in each Compressed data element; it
contains a compression identifier (CID) to identify the
compression algorithm used. (See Section 4.3.5.) The
Data Element Contents contains the product of the
compression process.
このデータ要素はBit-列データ要素を含まなければなりません。 それは圧縮されたどんなデータも表すのに使用されます。 解凍されたコンテンツがどこに見えても、それは使用されるかもしれません。 Qualifierデータ構成要素はそれぞれのCompressedデータ要素に現れます。 それは使用される圧縮アルゴリズムを特定する圧縮識別子(CID)を含んでいます。 (セクション4.3.5を見てください。) Data Element Contentsは圧縮プロセスの製品を含んでいます。
+--------+---//---+---//---+--------//--------+
|P1000110|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+
+--------+---//---+---//---+--------//--------+ |P1000110|Lxxxxxxx|Qxxxxxxx|ビット列要素| +--------+---//---+---//---+--------//--------+
Date (BASIC) 28 050
16 8
constructor
日付(BASIC)28 050の16、8建設者
This data element contains an ASCII-String data
element, which is a representation of a date and time
formatted in accordance with FIPS PUBS 4 [NatB-68],
58 [NatB-79a], and 59 [NatB-79b]. The use of time and
time zone is optional. It is recommended that numeric
offsets be used to indicate time zone rather than
alphabetic abbreviations.
このデータ要素はASCII-列データ要素を含んでいます。(それは、FIPS PUBS4[NatB-68]、58[NatB-79a]、および59[NatB-79b]に従ってフォーマットされた日時の表現です)。 時間と時間帯の使用は任意です。 数値オフセットがアルファベット略語よりむしろ時間帯を示すのに使用されるのは、お勧めです。
+--------+---//---+------//------+
|P0101000|Lxxxxxxx| ASCII-String |
+--------+---//---+------//------+
+--------+---//---+------//------+ |P0101000|Lxxxxxxx| ASCII-ストリング| +--------+---//---+------//------+
65
Appendix B
65 付録B
Encrypted (OPTIONAL) 47 107
16 8
constructor
暗号化された(OPTIONAL)47 107、16、8建設者
This data element must contain a Bit-String. It is
used to represent any data that has been encrypted; it
may be used wherever its unencrypted contents may
appear. A Qualifier data component appears in each
Encrypted data element; it contains an encryption
identifier (EID) identifying the encryption algorithm
used. (See Section 4.3.4 for further discussion.) The
Data Element Contents is the product of the encryption
process.
このデータ要素はBit-ストリングを含まなければなりません。 それは暗号化されたどんなデータも表すのに使用されます。 非暗号化されたコンテンツがどこに見えても、それは使用されるかもしれません。 Qualifierデータ構成要素はそれぞれのEncryptedデータ要素に現れます。 それは、使用される暗号化アルゴリズムを特定しながら、暗号化識別子(EID)を含んでいます。 (さらなる議論に関してセクション4.3.4を見てください。) Data Element Contentsは暗号化プロセスの製品です。
+--------+---//---+---//---+--------//--------+
|P1000111|Lxxxxxxx|Qxxxxxxx|Bit-String Element|
+--------+---//---+---//---+--------//--------+
+--------+---//---+---//---+--------//--------+ |P1000111|Lxxxxxxx|Qxxxxxxx|ビット列要素| +--------+---//---+---//---+--------//--------+
End-of-Constructor (BASIC) 01 001
16 8
primitive
建設者の終わりの(BASIC)01 001 16 8基関数
This data element terminates the Data Element Contents
in a constructor data element that has indefinite
length. This data element has no Contents component.
(Use of this element is described in Section 4.2.2.1.)
このデータ要素は無期長さを持っている建設者データ要素でData Element Contentsを終えます。 このデータ要素には、Contentsの部品が全くありません。 (この要素の使用はセクション4.2.2で.1に説明されます)
+--------+---//---+
|P0000001|Lxxxxxxx|
+--------+---//---+
+--------+---//---+ |P0000001|Lxxxxxxx| +--------+---//---+
Extension (OPTIONAL) 7E 176
16 8
either
拡大(OPTIONAL)7 176ユーロの16 8、どちらか
This data element is used to extend the number of
available data elements beyond the 128 that are
possible using a 7-bit identifier. A Qualifier
component extends the encoding space for identifiers.
(Extension and Vendor-Defined have the same syntax.)
このデータ要素は、7ビットの識別子を使用することで可能な128を超えて有効なデータ要素の数を広げるのに使用されます。 Qualifierの部品は識別子のためにコード化スペースを広げています。 (拡大であってVendorによって定義される、同じ構文)。
+--------+---//---+---//---+---//---+
|P1111110|Lxxxxxxx|Qxxxxxxx|Anything|
+--------+---//---+---//---+---//---+
+--------+---//---+---//---+---//---+ |P1111110|Lxxxxxxx|Qxxxxxxx|何でも| +--------+---//---+---//---+---//---+
66
Appendix B
66 付録B
Field (BASIC) 4C 114
16 8
constructor
分野(BASIC)4C114 16 8建設者
This data element uses a Qualifier data element
component. The Qualifier component contains a Field
Identifier (FID) indicating which specific field is
being represented. (See Section 4.3.2 for further
discussion.)
このデータ要素はQualifierデータ要素成分を使用します。 どの特定の分野が表されているかを示しながら、Qualifierの部品はField Identifier(FID)を含んでいます。 (さらなる議論に関してセクション4.3.2を見てください。)
+--------+---//---+---//---+---//---+
|P1001100|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+
+--------+---//---+---//---+---//---+ |P1001100|Lxxxxxxx|Qxxxxxxx|要素| +--------+---//---+---//---+---//---+
Integer (OPTIONAL) 20 040
16 8
primitive
整数(OPTIONAL)20 040 16 8基関数
This data element contains a 2's complement integer of
variable length, high-order octet first. It is
recommended that the data element contents be either 2
or 4 octets long whenever possible.
このデータ要素は最初に、2整数の可変長の補数もの、高位八重奏を含みます。 可能であるときはいつも、データ要素コンテンツが長い間2か4つの八重奏であることがお勧めです。
+--------+---//---+---//---+
|P0100000|Lxxxxxxx| Integer|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P0100000|Lxxxxxxx| 整数| +--------+---//---+---//---+
Message (BASIC) 4D 115
16 8
constructor
メッセージ(BASIC)4D115 16 8建設者
This data element may contain Field or Message data
elements. Its Qualifier component contains a Message
type (MID) indicating the type of the message. (See
Section 4.3.6 for further discussion.) (The MID is
completely different from the message identifier in the
Message-ID field and should not be confused with it.)
このデータ要素はFieldかMessageデータ要素を含むかもしれません。 Qualifierの部品は、メッセージのタイプを示しながら、Messageタイプ(MID)を含んでいます。 (さらなる議論に関してセクション4.3.6を見てください。) (MIDはMessage-ID分野のメッセージ識別子と完全に異なって、それに混乱しているべきではありません。)
+--------+---//---+---//---+
|P1001101|Lxxxxxxx|Qxxxxxxx|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P1001101|Lxxxxxxx|Qxxxxxxx| +--------+---//---+---//---+
+--------//---------//---------//---------//--------+
| Field, Message, Encrypted, or Compressed Elements |
+--------//---------//---------//---------//--------+
+--------//---------//---------//---------//--------+ | 分野(メッセージ)は、Elementsを暗号化したか、または圧縮しました。| +--------//---------//---------//---------//--------+
67
Appendix B
67 付録B
No-Op (OPTIONAL) 00 000
16 8
primitive
オプアートがない(OPTIONAL)00 000 16 8基関数
This data element does nothing. No-Op is used whenever
it is necessary to include a data element that means
"no operation." It is a short placeholder.
このデータ要素は何もしません。 「操作がありません」を意味するデータ要素を含むのが必要であるときはいつも、どんなオプアートも使用されていません。 それは短いプレースホルダです。
+--------+---//---+
|P0000000|Lxxxxxxx|
+--------+---//---+
+--------+---//---+ |P0000000|Lxxxxxxx| +--------+---//---+
Padding (OPTIONAL) 21 041
16 8
primitive
(OPTIONAL)21 041 16 8基関数を水増しします。
This data element is used to fill any number of octets.
The contents of a Padding element are undefined and
convey no information.
このデータ要素は、いろいろな八重奏をいっぱいにするのに使用されます。 Padding要素の内容は、未定義であり、情報を全く伝えません。
+--------+---//---+---//---+
|P0100001|Lxxxxxxx|anything|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P0100001|Lxxxxxxx|何でも| +--------+---//---+---//---+
Property-List (OPTIONAL) 24 044
16 8
constructor
特性リスト(OPTIONAL)24 044、16、8建設者
This data element contains a series of Property data
elements to be associated with another data element.
要素が別のデータ要素に関連しているように一連のPropertyデータ要素に含むこのデータ。
+--------+---//---+-------//--------+
|P0100100|Lxxxxxxx|Property Elements|
+--------+---//---+-------//--------+
+--------+---//---+-------//--------+ |P0100100|Lxxxxxxx|特性の要素| +--------+---//---+-------//--------+
68
Appendix B
68 付録B
Property (OPTIONAL) 45 105
16 8
constructor
特性(OPTIONAL)45 105の16、8建設者
This data element uses a Qualifier data element
component. The Qualifier component contains
a Property-Identifier (PID) to indicate which specific
property is being represented. (See Section 4.3.3 for
further discussion.)
このデータ要素はQualifierデータ要素成分を使用します。 Qualifierの部品はどの特定の性質が表されているかを示すProperty-識別子(PID)を含んでいます。 (さらなる議論に関してセクション4.3.3を見てください。)
+--------+---//---+---//---+---//---+
|P1000101|Lxxxxxxx|Qxxxxxxx|elements|
+--------+---//---+---//---+---//---+
+--------+---//---+---//---+---//---+ |P1000101|Lxxxxxxx|Qxxxxxxx|要素| +--------+---//---+---//---+---//---+
Sequence (OPTIONAL) 0A 012
16 8
constructor
系列(OPTIONAL)0A012 16 8建設者
This data element contains any series of data elements.
Sequence differs from Set in that the data elements
making up the Data Element Contents must be considered
as an ordered sequence (according to their order of
appearance in the sequence.)
このデータ要素はどんなシリーズのデータ要素も含んでいます。 系列は規則正しい系列であるとData Element Contentsを作るデータ要素をみなさなければならないという点においてSetと異なっています。(彼らの系列における外観の注文に従って。)
+--------+---//---+---//---+
|P0001010|Lxxxxxxx|elements|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P0001010|Lxxxxxxx|要素| +--------+---//---+---//---+
Set (OPTIONAL) 0B 013
16 8
constructor
セット(OPTIONAL)0B013 16 8建設者
This data element contains any series of data elements
with no ordering of the elements implied. (Sequence
provides an ordered series.) Although the data
elements contained in a Set must be stored
sequentially, the order in which they are stored is not
defined and not processed.
このデータ要素は要素の暗示している注文なしでどんなシリーズのデータ要素も含んでいます。 (系列は規則正しいシリーズを提供します。) Setに含まれたデータ要素を連続して保存しなければなりませんが、それらが保存される注文を定義しないで、また処理しません。
+--------+---//---+---//---+
|P0001011|Lxxxxxxx|elements|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P0001011|Lxxxxxxx|要素| +--------+---//---+---//---+
69
Appendix B
69 付録B
Unique-ID (OPTIONAL) 09 011
16 8
constructor
固有のID(OPTIONAL)09 011、16、8建設者
This data element is a unique identifier. It need not
be human-readable. The Data Element Contents may be an
ASCII-String, a Bit-String, or an Integer.
このデータ要素はユニークな識別子です。 それは人間読み込み可能である必要はありません。 Data Element ContentsはASCII-ストリング、Bit-ストリング、またはIntegerであるかもしれません。
+--------+---//---+---//---+
|P0001001|Lxxxxxxx| element|
+--------+---//---+---//---+
+--------+---//---+---//---+ |P0001001|Lxxxxxxx| 要素| +--------+---//---+---//---+
Vendor-Defined (OPTIONAL) 7F 177
16 8
either
ベンダーによって定義された(OPTIONAL)7F177 16、8、どちらか
This data element is used to represent vendor-defined
data elements. A Qualifier component extends the
encoding space for identifiers. The Qualifier
component is not guaranteed to be unique among all
interconnected systems. This data element is
interpreted according to prior agreement between
systems. (Extension and Vendor-Defined data elements
have the same syntax.)
このデータ要素は、ベンダーによって定義されたデータ要素を表すのに使用されます。 Qualifierの部品は識別子のためにコード化スペースを広げています。 Qualifierの部品は、すべての相互接続システムの中で特有になるように保証されません。このデータ要素はシステムの間の事前同意通りに解釈されます。(拡大とVendorによって定義されたデータ要素には、同じ構文があります。)
+--------+---//---+---//---+---//---+
|P1111111|Lxxxxxxx|Qxxxxxxx|Anything|
+--------+---//---+---//---+---//---+
+--------+---//---+---//---+---//---+ |P1111111|Lxxxxxxx|Qxxxxxxx|何でも| +--------+---//---+---//---+---//---+
70
Appendix C
70 付録C
APPENDIX C
DATA ELEMENT IDENTIFIER OCTETS
付録Cデータ要素識別子八重奏
Identifier Identifier Data Element Name
識別子識別子データ要素名
00 000 No-Op
01 001 End-of-Constructor
02 002 ASCII-String
08 010 Boolean
09 011 Unique-ID
0A 012 Sequence
0B 013 Set
20 040 Integer
21 041 Padding
24 044 Property-List
28 050 Date
43 103 Bit-String
45 105 Property
46 106 Compressed
47 107 Encrypted
4C 114 Field
4D 115 Message
7E 176 Extension
7F 177 Vendor-Defined
00 ベンダーによって176拡大7F177E定義されていた状態で、000オプアートがない01 001建設者の終わりの02 002ASCII-ストリング08 010論理演算子09 011ユニークなID0A012系列0B013セット20 040整数21 041詰め物24 044特性リスト28 050日付43の103ビット列45 105の特性46の106は47の107の暗号化された4C114分野4D115メッセージ7を圧縮しました。
71
Appendix D
71 付録D
APPENDIX D
SUMMARY OF MESSAGE FIELDS BY COMPLIANCE CATEGORY
承諾カテゴリによるメッセージ分野の付録D概要
This appendix is for reference use. It contains no new
information, but rather abstracts from that presented in Section
3.1.
この付録は参照使用のためのものです。 それは、新情報を全く含んでいなくて、セクション3.1に提示されたそれからのむしろ要約を含んでいます。
This appendix contains the message field names arranged
alphabetically within compliance category. (Appendix E orders
the field names within functional category.) Complete field
definitions appear in Appendix A.
この付録はアルファベット順に、承諾カテゴリの中に配置されたメッセージフィールド名を含んでいます。 (付録Eは機能的なカテゴリの中でフィールド名を注文します。) 完全なフィールド定義はAppendix Aに現れます。
Required fields must appear in a message. Basic fields must
be recognized and processed by all CBMS systems. Optional fields
need not be supported by a CBMS but, if supported, must be
processed according to the meanings defined by the message format
specification.
必須項目はメッセージに現れなければなりません。 すべてのCBMSシステムで基礎体を認識されて、処理しなければなりません。任意の分野をCBMSによってサポートされる必要はありませんが、サポートされるなら、メッセージ書式仕様によって定義された意味によると、処理しなければなりません。
D.1 REQUIRED Fields
D.1必須項目
From
Posted-Date
To
掲示された期日
D.2 BASIC Fields
D.2基礎体
Cc
Reply-To
Subject
Text
ccは対象のテキストに答えます。
D.3 OPTIONAL Fields
D.3の任意の分野
Attachments
Author
Bcc
Circulate-Next
Circulate-To
Comments
付属作者Bccが-次に循環する、循環、-、コメント
72
Appendix D
72 付録D
Date
End-Date
In-Reply-To
Keywords
Message-Class
Message-ID
Obsoletes
Originator-Serial-Number
Precedence
Received-Date
Received-From
References
Reissue-Type
Sender
Start-Date
Warning-Date
受け取っている終了日のメッセージクラスMessage IDが時代遅れにするキーワードに対する創始者通し番号先行受信された期日の参照の再発行タイプ送付者スタート日警告日付と日付を入れてください。
73
Appendix E
73 付録E
APPENDIX E
SUMMARY OF MESSAGE SEMANTICS BY FUNCTION
機能によるメッセージ意味論の付録E概要
This appendix is for reference use. It contains no new
information, but rather abstracts from that presented in Section
3.1.
この付録は参照使用のためのものです。 それは、新情報を全く含んでいなくて、セクション3.1に提示されたそれからのむしろ要約を含んでいます。
This appendix contains the message field names arranged
alphabetically within functional class. (Appendix D orders the
field names within compliance class.) Complete field definitions
appear in Appendix A.
この付録はアルファベット順に、機能クラスの中に配置されたメッセージフィールド名を含んでいます。 (付録Dは承諾クラスの中でフィールド名を注文します。) 完全なフィールド定義はAppendix Aに現れます。
E.1 Circulation
E.1流通
Circulate-Next
Circulate-To
-次に循環してください、循環、-
E.2 Cross-Referencing
E.2十字参照箇所
In-Reply-To
Message-ID
Obsoletes
Originator-Serial-Number
References
Message IDに対して、創始者通し番号参照を時代遅れにします。
E.3 Life Spans
E.3寿命
End-Date
Start-Date
Warning-Date
終了日のスタート日警告日付
E.4 Delivery System
E.4配送システム
Received-Date
Received-From
受け取って、資料を受け取ります。
74
Appendix E
74 付録E
E.5 Miscellaneous Fields Used Generally
一般に、使用されるE.5の種々雑多な分野
Attachments
Comments
Keywords
Message-Class
Precedence
Subject
Text
付属はキーワードメッセージクラス先行対象テキストについて論評します。
E.6 Reply Generation
E.6回答世代
Reply-To
答えます。
E.7 Reissuing
E.7再発行
Reissue-Type
再発行タイプ
E.8 Sending (Normal Transmission)
E.8発信(通常のトランスミッション)
Author
Bcc
Cc
Date
From
Posted-Date
Sender
To
Bcc ccが掲示された期日の送付者からデートする作者
75
Appendix F
75 付録F
APPENDIX F
SUMMARY OF DATA ELEMENT SYNTAX
データ要素構文の付録F概要
This appendix summarizes data element syntax by diagramming
the components of data elements. Detailed presentation of data
element syntax appears in Section 4.3.1.
この付録は、データ要素の部品を図解することによって、データ要素構文をまとめます。 データ要素構文の詳細なプレゼンテーションはセクション4.3.1に現れます。
In these diagrams, required components of a data element
appear as follows. (The double border signifies "required.")
これらのダイヤグラムで、データ要素の必要な部品は以下の通りに見えます。 (二重境界は「必要な」状態で意味します。)
+========+ +===//===+
| | | |
+========+ +===//===+
always one one or more
octet long octets long
+========+ +===//===+ | | | | +========+ +===//===+ 八重奏八重奏いつも1つ1長さ長い
Optional components of data elements are represented as
follows. (The single border signifies "not required.")
データ要素の任意の部品は以下の通り表されます。 (単一の境界は「必要でない」状態で意味します。)
+--------+ +---//---+
| | | |
+--------+ +---//---+
always one one or more
octet long octets long
+--------+ +---//---+ | | | | +--------+ +---//---+ 八重奏八重奏いつも1つ1長さ長い
The first octet in a data element is the identifier octet.
In diagrams of data elements, all eight bits of the identifier
octet are always shown. Bits with fixed values show the fixed
values as 1s and 0s. Bits with variable values are shown as x's
and y's.
データ要素における最初の八重奏は識別子八重奏です。 データ要素のダイヤグラムで、識別子八重奏のすべての8ビットがいつも見せられます。 一定の価値に従ったビットは1と0として一定の価値を示しています。 値がxとyのものとして示される変数に従ったビット。
The first bit in an identifier octet is the P-bit. Its
value indicates whether a data element contains a property list.
(A P-bit value of 1 indicates the presence of a property list.)
The remaining seven bits contain the rest of the identifier.
識別子八重奏における最初のビットはP-ビットです。 値は、データ要素が特性のリストを含むかどうかを示します。 (1のP-ビット値は特性のリストの存在を示します。) 残っている7ビットは識別子の残りを含んでいます。
Other octets in a data element belong to one of four
classes: Length Code, Qualifier, Property-List, and Contents.
In diagrams of syntax the data element components are labeled
according to their class.
データ要素における他の八重奏は4つのクラスの1つに属します: 長さのコード、資格を与える人、特性リスト、およびコンテンツ。 構文のダイヤグラムで、それらのクラスによると、データ要素成分はラベルされます。
76
Appendix F
76 付録F
Component Class Label
コンポーネントクラスラベル
Length code Length
Qualifier Qual
Property-List P-List
Contents Contents
長さのコードLength Qualifier Qual Property-リストP-リストContents Contents
Data elements must follow this form.
データ要素はこのフォームに続かなければなりません。
+========+===//===+---//---+---//---+---//---+
|Pxxxxxxx| Length | Qual | P-List |contents|
+========+===//===+---//---+---//---+---//---+
+========+===//===+---//---+---//---+---//---+ |Pxxxxxxx| 長さ| Qual| P-リスト|コンテンツ| +========+===//===+---//---+---//---+---//---+
The value of the Length component is the total number of octets
following the length code octet in the data element.
Lengthの部品の値はデータ要素における長さのコード八重奏に続く八重奏の総数です。
77
Appendix G
77 付録G
APPENDIX G
SUMMARY OF DATA ELEMENTS BY COMPLIANCE CATEGORY
承諾カテゴリによるデータ要素の付録G概要
Compliance categories for syntactic elements are basic and
optional. Every CBMS is required to recognize and process basic
elements. A CBMS is not required to process optional elements
although many are strongly recommended by the semantics.
構文の要素のための承諾カテゴリは、基本的であって、任意です。 あらゆるCBMSが、基本要素を認識して、処理するのに必要です。 CBMSは、多くが意味論で強く推薦されますが、随意的な要素を処理するのに必要ではありません。
This appendix summarizes data elements by listing them
according to their compliance category.
この付録は、それらの承諾カテゴリに従ってそれらを記載することによって、データ要素をまとめます。
G.1 BASIC Data Elements
G.1基礎データElements
ASCII-String (primitive) 02 002
16 8
Date (constructor) 28 050
16 8
End-Of-Constructor (primitive) 01 001
16 8
Field (constructor) 4C 114
16 8
Message (constructor) 4D 115
16 8
ASCII-ストリングの(原始)の02 002 16 8期日(建設者)の28 050 16 8建設者の終わりの(原始の)01 001 16 8分野(建設者)4C114 16 8メッセージ(建設者)4D115 16 8
G.2 OPTIONAL Data Elements
G.2の任意のデータ要素
Bit-String (primitive) 43 103
16 8
Boolean (primitive) 08 010
16 8
Compressed (constructor) 46 106
16 8
Encrypted (constructor) 47 107
16 8
Extension (either) 7E 176
16 8
Integer (primitive) 20 040
16 8
No-Op (primitive) 00 000
16 8
Padding (primitive) 21 041
16 8
(原始)のブール(原始の)の圧縮された暗号化されたビット列の47 107 16 8 43 103 16 8 08 010 16 8(建設者)46 106 16 8(建設者)拡大(どちらか)7 176 16 8整数(原始)の20 040 16 8オプアートがない(原始の)00 000 16 8(原始の)そっと歩いている21 041ユーロの16 8
78
Appendix G
78 付録G
Property (constructor) 45 105
16 8
Property-List (constructor) 24 044
16 8
Sequence (constructor) 0A 012
16 8
Set (constructor) 0B 013
16 8
Unique-ID (constructor) 09 011
16 8
Vendor-Defined (either) 7F 377
16 8
特性の(建設者)45 105 16 8特性リスト(建設者)24 044 16 8系列(建設者)0A012 16 8セット(建設者)0B013 16 8ユニークなID(建設者)09 011、16、8は(どちらか)7F377 16 8をベンダーで定義しました。
79
Appendix H
79 付録H
APPENDIX H
EXAMPLES
付録Hの例
This appendix presents at least one example for each of the
data elements defined in this message format specification. In
these examples, identifier octets are represented in binary form.
All other numbers are presented in hexadecimal. ASCII strings
are shown as characters rather than their numerical represen-
tation. Although this message format specification does not
define the syntax of names and addresses, message originators and
recipients are identified by their names. This does not imply
anything about how naming and addressing can or should be done;
it is simply a convenient way to identify message originators and
recipients in these examples.
この付録はこのメッセージ書式仕様で定義されたそれぞれのデータ要素のための少なくとも1つの例を提示します。 これらの例では、識別子八重奏は二部形式に表されます。 他のすべての数が16進で提示されます。 ASCIIストリングは彼らの数字のrepresen- tationよりむしろキャラクタとして見せられます。 このメッセージ書式仕様は名前とアドレスの構文を定義しませんが、メッセージ創始者と受取人は彼らの名前によって特定されます。 これは命名とアドレシングをすることができるべきであるか、またはどうするべきであるかに関して何も含意しません。 それは単にこれらの例でメッセージ創始者と受取人を特定する便利な方法です。
H.1 Primitive Data Elements
H.1の原始のデータ要素
This section contains an example of each of the primitive
data elements. Each example contains a short explanation and a
series of octets.
このセクションはそれぞれの原始のデータ要素に関する例を含みます。 各例は短い説明と一連の八重奏を含んでいます。
No-Op data element:
オプアートがないデータ要素:
+--------+--------+
|00000000|00000000|
+--------+--------+
+--------+--------+ |00000000|00000000| +--------+--------+
End-of-Constructor data element:
建設者の終わりのデータ要素:
+--------+--------+
|00000001|00000000|
+--------+--------+
+--------+--------+ |00000001|00000000| +--------+--------+
80
Appendix H
80 付録H
Boolean data element whose value is true:
値が本当であるブールデータ要素:
+--------+--------+--------+
|00001000|00000001|11111111|
+--------+--------+--------+
+--------+--------+--------+ |00001000|00000001|11111111| +--------+--------+--------+
Integer data element containing five octets of data. Its
value is 4,294,967,296 (decimal):
データの5つの八重奏を含む整数データ要素。 値は42億9496万7296(10進)です:
+--------+--------+--------+--------+--------+
|00100000| 0 5 | 0 1 0 0 0 0
+--------+--------+--------+--------+--------+
+--------+--------+--------+--------+--------+ |00100000| 0 5 | 0 1 0 0 0 0 +--------+--------+--------+--------+--------+
+--------+--------+
0 0 0 0 |
+--------+--------+
+--------+--------+ 0 0 0 0 | +--------+--------+
Padding data element containing three octets of padding.
The values of those three octets are meaningless:
詰め物の3つの八重奏を含むデータ要素を水増しします。 それらの3つの八重奏の値は無意味です:
+--------+--------+--------+--------+--------+
|00100001| 0 3 | F F F F F F |
+--------+--------+--------+--------+--------+
+--------+--------+--------+--------+--------+ |00100001| 0 3 | F F F F F F| +--------+--------+--------+--------+--------+
ASCII-String data element containing nine characters. Its
value is "Hi There.":
9文字を含むASCII-列データ要素。 値が「やあ」ということである、:
+--------+--------+---- ----+
|00000010| 0 9 |Hi There.|
+--------+--------+---- ----+
+--------+--------+---- ----+ |00000010| 0 9 |やあ. | +--------+--------+---- ----+
81
Appendix H
81 付録H
Bit-String data element containing 44 bits of data (((7-1) x
8) - 4). Six octets are used to hold those 44 bits. The last 4
bits in the final octet are padding and are therefore ignored.
データ(((7-1)x8)の44ビットを含むビット列データ要素--4)。 6つの八重奏が、それらの44ビットを持つのに使用されます。 最終的な八重奏におけるベスト4ビットは、そっと歩いていて、したがって、無視されます。
Bit-String Length Spare
+--------+--------+--------+--------+--------+
|01000011| 0 7 | 0 4 | 0 A 3 B
+--------+--------+--------+--------+--------+
ビット列長さの予備+--------+--------+--------+--------+--------+ |01000011| 0 7 | 0 4 | 0 3B+--------+--------+--------+--------+--------+
+--------+--------+--------+--------+
5 F 2 9 1 C D 0 |
+--------+--------+--------+--------+
+--------+--------+--------+--------2 9 1+ 5F C D0| +--------+--------+--------+--------+
H.2 Constructor Data Elements
H.2建設者データ要素
This section contains an example of each of the constructor
data elements. Each example contains a short explanation and
then an annotated series of the data elements making up the
constructor.
このセクションはそれぞれの建設者データ要素に関する例を含みます。 各例は、短い説明を含んでいて、次に、建設者を作るデータ要素の注釈されたシリーズを含んでいます。
Property-List data element containing one Property data
element. The property is Printing-Name and its value is
"Distribution":
1つのPropertyデータ要素を含む特性リストデータ要素。 特性はPrinting-名前です、そして、値は「分配」です:
Prop-List Length Property Length PID
+--------+--------+--------+--------+--------+
|00100100| 1 1 |01000101| 0 F | 0 2 |
+--------+--------+--------+--------+--------+
支柱リスト長さの特性の長さのPID+--------+--------+--------+--------+--------+ |00100100| 1 1 |01000101| 0F| 0 2 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 C |Distribution|
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 0C|分配| +--------+--------+---- ----+
82
Appendix H
82 付録H
Printing-Name Property. The value of the Printing-Name is
"Distribution":
印刷名の特性。 Printing-名前の値は「分配」です:
Property Length PID ASCII Length
+--------+--------+--------+--------+--------+
|01000101| 0 F | 0 2 |00000010| 0 C |
+--------+--------+--------+--------+--------+
特性の長さのPID ASCIIの長さ+--------+--------+--------+--------+--------+ |01000101| 0F| 0 2 |00000010| 0C| +--------+--------+--------+--------+--------+
+---- ----+
|Distribution|
+---- ----+
+---- ----+ |分配| +---- ----+
Compressed data element. Its contents were compressed using
an unspecified data compression algorithm. The compressed data
is in a bit-string that is 56 bits long, fully filling 7 octets:
圧縮されたデータ要素。 コンテンツは、不特定のデータ圧縮アルゴリズムを使用することで圧縮されました。 圧縮されたデータが7つの八重奏を完全にいっぱいにしていて、長さ56ビットであるしばらくストリングにあります:
Compressed Length CID Bit-String Length
+--------+--------+--------+--------+--------+
|01000110| 0 B | 0 0 |01000011| 0 8 |
+--------+--------+--------+--------+--------+
圧縮された長さのCidビット列の長さ+--------+--------+--------+--------+--------+ |01000110| 0 B| 0 0 |01000011| 0 8 | +--------+--------+--------+--------+--------+
Spare
+--------+--------+--------+--------+
| 0 0 | 1 C 5 F 2 D
+--------+--------+--------+--------+
予備+--------+--------+--------+--------+ | 0 0 | 1 C5F2D+--------+--------+--------+--------+
+--------+--------+--------+--------+
7 7 B A F 6 2 9 |
+--------+--------+--------+--------+
+--------+--------+--------+--------+7 7BはF6 2 9です。| +--------+--------+--------+--------+
83
Appendix H
83 付録H
Encrypted data element. The encryption method used to
encrypt its contents has been intentionally not specified. This
element contains a Bit-String which contains 22 bits (((4-1) x 8)
- 2) of data. These 22 bits are represented in octets; the final
2 bits in the final octet are padding and are therefore ignored:
暗号化されたデータ要素。 コンテンツを暗号化するのに使用される暗号化メソッドは故意に指定されていません。 この要素は(((4-1) x8)を22ビット含むBit-ストリングを含んでいます--2つのデータ)。 これらの22ビットは八重奏で表されます。 最終的な八重奏における最終的な2ビットは、そっと歩いていて、したがって、無視されます:
Encrypted Length EID Bit-String Length
+--------+--------+--------+--------+--------+
|01000111| 0 7 | 0 0 |01000011| 0 4 |
+--------+--------+--------+--------+--------+
暗号化された長さのEIDビット列の長さ+--------+--------+--------+--------+--------+ |01000111| 0 7 | 0 0 |01000011| 0 4 | +--------+--------+--------+--------+--------+
Spare
+--------+--------+--------+--------+
| 0 2 | A 3 7 8 1 C |
+--------+--------+--------+--------+
予備+--------+--------+--------+--------+ | 0 2 | A3 7 8 1C| +--------+--------+--------+--------+
Date data element. This example includes a date but no
time. The date shown in this example is August 15, 1980:
要素とデータの日付を入れてください。 日付を含んでいますが、この例は少しの時間も含んでいません。 この例に示された日付は1980年8月15日です:
Date Length ASCII Length
+--------+--------+--------+--------+--- ---+
|00101000| 0 A |00000010| 0 8 |19800815|
+--------+--------+--------+--------+--- ---+
長さのASCIIの長さの+と日付を入れてください。--------+--------+--------+--------+--- ---+ |00101000| 0 A|00000010| 0 8 |19800815| +--------+--------+--------+--------+--- ---+
Unique-ID data element, which is represented as an Integer
data element whose value is 129 (decimal).
固有のIDデータ要素。(その要素は値が129(10進)であるIntegerデータ要素として表されます)。
Unique-ID Length Integer Length
+--------+--------+--------+--------+--------+--------+
|00001001| 0 4 |00100000| 0 2 | 0 0 8 1 |
+--------+--------+--------+--------+--------+--------+
ユニークなID長さの整数の長さ+--------+--------+--------+--------+--------+--------+ |00001001| 0 4 |00100000| 0 2 | 0 0 8 1 | +--------+--------+--------+--------+--------+--------+
84
Appendix H
84 付録H
Sequence data element containing two ASCII-String data ele-
ments. The first ASCII-String is "This is" while the second
string is " a list":
2ASCII-列データele- mentsを含む系列データ要素。 2番目のストリングは「リスト」ですが、最初のASCII-ストリングは「これはそうです」です:
Sequence Length ASCII Length
+--------+--------+--------+--------+--- ---+
|00001010| 1 2 |00000010| 0 7 |This is|
+--------+--------+--------+--------+--- ---+
系列長さのASCIIの長さ+--------+--------+--------+--------+--- ---+ |00001010| 1 2 |00000010| 0 7 |これはそうです。| +--------+--------+--------+--------+--- ---+
ASCII Length
+--------+--------+--- ---+
|00000010| 0 7 | a list|
+--------+--------+--- ---+
ASCIIの長さ+--------+--------+--- ---+ |00000010| 0 7 | リスト| +--------+--------+--- ---+
Set data element containing two Integer data elements. The
first integer has a value of 519 (decimal) while the value of the
second is 71 (decimal). (These two values have no ordering
because they belong to a set.)
2つのIntegerデータ要素を含むデータ要素を設定してください。 最初の整数には、2番目の値は71(10進)ですが、519(10進)の値があります。 (これらの2つの値には、セットのものので、注文がありません。)
Set Length Integer Length
+--------+--------+--------+--------+--------+--------+
|00001011| 0 8 |00100000| 0 2 | 0 2 0 7 |
+--------+--------+--------+--------+--------+--------+
長さの整数の長さ+を設定してください。--------+--------+--------+--------+--------+--------+ |00001011| 0 8 |00100000| 0 2 | 0 2 0 7 | +--------+--------+--------+--------+--------+--------+
Integer Length
+--------+--------+--------+--------+
|00100000| 0 2 | 0 0 4 7 |
+--------+--------+--------+--------+
整数の長さ+--------+--------+--------+--------+ |00100000| 0 2 | 0 0 4 7 | +--------+--------+--------+--------+
Field data element. The specific field shown is the Text
field with the contents "I will see you at lunch.":
データ要素をさばいてください。 コンテンツがあるText分野が「昼食でお目にかかります」であることが示された特定の分野、:
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 B | 0 4 |00000010| 1 8 |
+--------+--------+--------+--------+--------+
フィールド長くさびASCIIの長さ+--------+--------+--------+--------+--------+ |01001100| 1 B| 0 4 |00000010| 1 8 | +--------+--------+--------+--------+--------+
+---- ----+
|I will see you at lunch.|
+---- ----+
+---- ----+ |昼食| +でお目にかかります。---- ----+
85
Appendix H
85 付録H
Message containing four fields, Posted-Date, From, Text, and
To. It was sent on July 4, 1980 at 6 p.m. eastern daylight time.
It is from a person named Smith. The text of the message is a
question asking the recipient "Are you going to watch the
fireworks?". The message is sent to Jones:
4つの分野を含むメッセージ、Posted-日付、From、Text、およびTo。 1980年7月4日に午後6時の東夏時間でそれを送りました。 それはスミスという人から来ています。 メッセージの本文は「あなたは花火を見るでしょうか?」を受取人に尋ねる問題です。 メッセージをジョーンズに送ります:
Message Length Type Field Length
+--------+--------+--------+--------+--------+
|01001101| 5 A | 0 1 |01001100| 1 9 |
+--------+--------+--------+--------+--------+
メッセージ長タイプフィールド長+--------+--------+--------+--------+--------+ |01001101| 5 A| 0 1 |01001100| 1 9 | +--------+--------+--------+--------+--------+
FID Date Length ASCII
+--------+--------+--------+--------+
| 0 2 |00101000| 1 6 |00000010|
+--------+--------+--------+--------+
くさび日付の長さのASCII+--------+--------+--------+--------+ | 0 2 |00101000| 1 6 |00000010| +--------+--------+--------+--------+
Length
+--------+---- ----+
| 1 4 |19800704-180000-0400|
+--------+---- ----+
長さ+--------+---- ----+ | 1 4 |19800704-180000-0400| +--------+---- ----+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 8 | 0 1 |00000010|
+--------+--------+--------+--------+
フィールド長くさびASCII+--------+--------+--------+--------+ |01001100| 0 8 | 0 1 |00000010| +--------+--------+--------+--------+
Length
+--------+-- --+
| 0 5 |Smith|
+--------+-- --+
長さ+--------+-- --+ | 0 5 |スミス| +--------+-- --+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 2 8 | 0 4 |00000010|
+--------+--------+--------+--------+
フィールド長くさびASCII+--------+--------+--------+--------+ |01001100| 2 8 | 0 4 |00000010| +--------+--------+--------+--------+
Length
+--------+
| 2 5 |
+--------+
長さ+--------+ | 2 5 | +--------+
+---- ----+
|Are you going to watch the fireworks?|
+---- ----+
+---- ----+ |あなたが花火を見るだろうか、| +---- ----+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 8 | 0 5 |00000010|
+--------+--------+--------+--------+
フィールド長くさびASCII+--------+--------+--------+--------+ |01001100| 0 8 | 0 5 |00000010| +--------+--------+--------+--------+
86
Appendix H
86 付録H
Length
+--------+-- --+
| 0 5 |Jones|
+--------+-- --+
長さ+--------+-- --+ | 0 5 |ジョーンズ| +--------+-- --+
H.3 Data Elements that Extend this Specification
H.3Data Elements、そのExtend、このSpecification
This section contains examples of data elements used to
extend this specification. These data elements can be either
primitives or constructors, depending on the extension.
Extension data element containing a length code and 3
octets. The octet immediately following the length code iden-
tifies it as Extension Data Element 7. The Data Element Contents
is the final two octets. The interpretation of the Data Element
Contents would be defined in an extension or successor to this
message format specification. [Note: this is an example. Any
actual extension data element 7 (if it were ever used) would be
completely different from anything done here.]:
このセクションはこの仕様を広げるのに使用されるデータ要素に関する例を含みます。 拡大によって、これらのデータ要素は、基関数か建設者のどちらかであるかもしれません。 長さのコードと3つの八重奏を含む拡大データ要素。 すぐに長さのコードiden- tifiesに続く八重奏、それ、Extension Data Element7 Data Element Contentsは最終的な2つの八重奏です。 Data Element Contentsの解釈はこのメッセージ書式仕様の拡大か後継者で定義されるでしょう。 [以下に注意してください。 これは例です。 どんな実際の拡大データ要素7(それが今までに使用されたなら)もここで行われたものは何とでも完全に異なっているでしょう。]:
Extension Length
+--------+--------+--------+--------+--------+
|01111110| 0 3 | 0 7 | 4 A E 9 |
+--------+--------+--------+--------+--------+
拡大の長さ+--------+--------+--------+--------+--------+ |01111110| 0 3 | 0 7 | 4 E9| +--------+--------+--------+--------+--------+
Vendor-Defined data element containing a length code and 3
octets. The first octet identifies this as vendor-defined data
element number 114 (decimal), which this particular vendor has
defined to contain three printable ASCII characters in two
octets. (Data element 114 (decimal) for another user would be
completely different. For example, it might contain a floating
point number.):
長さのコードと3つの八重奏を含むベンダーによって定義されたデータ要素。 最初の八重奏は、これがベンダーによって定義されたデータ要素No.114(小数)であると認識します。(この特定のベンダーは、2つの八重奏に3人の印刷可能なASCII文字を含むようにそれを定義しました)。 (別のユーザのためのデータ要素114(小数)は完全に異なっているでしょう。 例えば、それは浮動小数点を含むかもしれません。):
User Length
+--------+--------+--------+--------+--------+
|01111111| 0 3 | 7 2 | P O E |
+--------+--------+--------+--------+--------+
ユーザの長さ+--------+--------+--------+--------+--------+ |01111111| 0 3 | 7 2 | P O E| +--------+--------+--------+--------+--------+
87
Appendix H
87 付録H
H.4 Fields
H.4分野
This section contains examples of Field data element con-
structors for each of several different fields (Keywords, Text,
Subject, Vendor-Defined).
Field data element for keywords . The field contains two
keywords, Message and Computer, each represented in a separate
ASCII-string data element.
このセクションはそれぞれのいくつかの異なった分野(キーワード、Subjectであって、Vendorによって定義されたText)へのFieldデータ要素まやかしstructorsに関する例を含みます。 キーワードのためにデータ要素をさばいてください。分野は2つのキーワード、Message、およびコンピュータを含んでいます、別々のASCII-列データ要素に表されたそれぞれ。
Field Length Keywords ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 4 | 1 4 |00000010| 0 7 |
+--------+--------+--------+--------+--------+
フィールド長キーワードASCIIの長さ+--------+--------+--------+--------+--------+ |01001100| 1 4 | 1 4 |00000010| 0 7 | +--------+--------+--------+--------+--------+
+--- ---+
|Message|
+--- ---+
+--- ---+ |メッセージ| +--- ---+
ASCII Length
+--------+--------+--- ---+
|00000010| 0 8 |Computer|
+--------+--------+--- ---+
ASCIIの長さ+--------+--------+--- ---+ |00000010| 0 8 |コンピュータ| +--------+--------+--- ---+
88
Appendix H
88 付録H
Field data element for Text with a Property-List data
element containing a comment attached. The text field contains
the ASCII-String data element "Do you want lunch?"; the Property-
List data element contains a comment property, which consists of
an ASCII-string data element containing "Now?":
Property-リストデータ要素がコメントを含んでいるTextのためのフィールド・データ要素は付きました。 テキストフィールドがASCII-列データ要素を含んでいる、「あなたは昼食が欲しいですか?」。 Propertyリストデータ要素はコメントの特性を含んでいます:(特性は「現在?」を含むASCII-列データ要素から成ります)。
Field Length Text Prop-List Length
+--------+--------+--------+--------+--------+
|11001100| 2 0 | 0 4 |00100100| 0 9 |
+--------+--------+--------+--------+--------+
フィールド長テキスト支柱リストの長さ+--------+--------+--------+--------+--------+ |11001100| 2 0 | 0 4 |00100100| 0 9 | +--------+--------+--------+--------+--------+
Property Length PID ASCII
+--------+--------+--------+--------+
|01000101| 0 7 | 0 1 |00000010|
+--------+--------+--------+--------+
特性の長さのPID ASCII+--------+--------+--------+--------+ |01000101| 0 7 | 0 1 |00000010| +--------+--------+--------+--------+
Length
+--------+- -+
| 0 4 |Now?|
+--------+- -+
長さ+--------+- -+ | 0 4 || 現在の+--------+- -+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 2 |Do you want lunch?|
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 1 2 |あなたは昼食?| +が欲しいですか?--------+--------+---- ----+
Field data element for Subject containing an ASCII-String
data element ("Good restaurants in Detroit" followed by a
carriage return and a line feed). (A recipient would expect the
message to contain some information about restaurants in the
Detroit area.):
ASCII-列データ要素を含むSubjectのためにデータ要素をさばいてください(復帰と改行で「デトロイトの良いレストラン」は続きました)。 (受取人はデトロイトの地域のレストランの何らかの情報を含むメッセージを予想するでしょう。):
Field Length Subject ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 2 1 | 0 7 |00000010| 1 E |
+--------+--------+--------+--------+--------+
フィールド長対象ASCIIの長さ+--------+--------+--------+--------+--------+ |01001100| 2 1 | 0 7 |00000010| 1E| +--------+--------+--------+--------+--------+
+---- ----+
|Good restaurants in Detroit.<cr><lf>|
+---- ----+
+---- ----+ |デトロイト<cr><lfの良いレストラン>| +---- ----+
89
Appendix H
89 付録H
Field data element whose form and meaning was defined by a
vendor. This vendor has defined vendor-defined field 12
(decimal) to be a field with a printing name of "Reply-by" and
contents consisting of a date; January 7, 1981 in this case.
(The meaning of vendor-defined field 12 is unique to the vendor;
the same field number would have different meaning for other
vendors.):
書式と意味が業者によって定義されたデータ要素をさばいてください。 この業者は「近く、返答し」てコンテンツの印刷名が日付から成っている分野になるように業者によって定義された分野12(小数)を定義しました。 この場合1981年1月7日。 (業者によって定義された分野12の意味は業者にユニークです; 数が異なるようにする他の業者のために意味する同じ分野)。:
Field Length Qualifier User number
+--------+--------+--------+--------+--------+
|11001100| 1 F | 8 2 | 0 0 0 C |
+--------+--------+--------+--------+--------+
分野Length Qualifier User番号+--------+--------+--------+--------+--------+ |11001100| 1F| 8 2 | 0 0 0C| +--------+--------+--------+--------+--------+
Prop-List Length Property Length
+--------+--------+--------+--------+
|00100100| 0 E |01000101| 0 C |
+--------+--------+--------+--------+
支柱リスト長さの特性の長さ+--------+--------+--------+--------+ |00100100| 0E|01000101| 0C| +--------+--------+--------+--------+
PID ASCII Length
+--------+--------+--------+---- ----+
| 0 2 |00000010| 0 9 |Reply-By:|
+--------+--------+--------+---- ----+
PID ASCIIの長さ+--------+--------+--------+---- ----+ | 0 2 |00000010| 0 9 |近く、返答します: | +--------+--------+--------+---- ----+
Date Length ASCII Length
+--------+--------+--------+--------+
|00101000| 0 A |00000010| 0 8 |
+--------+--------+--------+--------+
長さのASCIIの長さの+と日付を入れてください。--------+--------+--------+--------+ |00101000| 0 A|00000010| 0 8 | +--------+--------+--------+--------+
+--- ---+
|19810107|
+--- ---+
+--- ---+ |19810107| +--- ---+
H.5 Messages
H.5メッセージ
This section contains several examples of complete messages
and shows the results of reissuing a message. (See Section
3.2.2.)
このセクションは、完全なメッセージに関するいくつかの例を含んでいて、メッセージを再発行するという結果を示しています。 (セクション3.2.2を見てください。)
90
Appendix H
90 付録H
The following sample message had Stevens as its originator
and Johnson as its recipient. The message was sent on August 14,
1980 at 10 a.m. EDT. The subject of the message is "Project
Deadline" and the message is a reminder that the deadline is the
next day and that the section of the report for the project being
done by Johnson should be turned in to Stevens by 3 p.m. that
day.
以下のサンプルメッセージには、受取人としてのその創始者とジョンソンとしてスティーブンスがいました。 1980年8月14日東部夏時間午前10時にメッセージを転送しました。 メッセージの対象は「プロジェクトの締め切り」です、そして、メッセージは締め切りが翌日であり、ジョンソンによって行われたプロジェクト存在のためのレポートのセクションが当日午後3時までにスティーブンスに渡されるべきであるということを思い出させるものです。
Message Length Type
+--------+--------+--------+--------+
|01001101| 8 1 | B 6 | 0 1 |
+--------+--------+--------+--------+
メッセージ長タイプ+--------+--------+--------+--------+ |01001101| 8 1 | B6| 0 1 | +--------+--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 5 |00000010|
+--------+--------+--------+--------+
フィールド長くさびASCII+--------+--------+--------+--------+ |01001100| 0 A| 0 5 |00000010| +--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Johnson|
+--------+--- ---+
長さ+--------+--- ---+ | 0 7 |ジョンソン| +--------+--- ---+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+
フィールド長くさびASCII+--------+--------+--------+--------+ |01001100| 0 A| 0 1 |00000010| +--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Stevens|
+--------+--- ---+
長さ+--------+--- ---+ | 0 7 |スティーブンス| +--------+--- ---+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 3 | 0 7 |00000010| 1 0 |
+--------+--------+--------+--------+--------+
フィールド長くさびASCIIの長さ+--------+--------+--------+--------+--------+ |01001100| 1 3 | 0 7 |00000010| 1 0 | +--------+--------+--------+--------+--------+
+---- ----+
|Project Deadline|
+---- ----+
+---- ----+ |プロジェクトの締め切り| +---- ----+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 7 | 0 2 |00101000| 1 4 |
+--------+--------+--------+--------+--------+
フィールド長くさび日付の長さ+--------+--------+--------+--------+--------+ |01001100| 1 7 | 0 2 |00101000| 1 4 | +--------+--------+--------+--------+--------+
91
Appendix H
91 付録H
ASCII Length
+--------+--------+---- ----+
|00000010| 1 2 |19800814-1000-0400|
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 1 2 |19800814-1000-0400| +--------+--------+---- ----+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 6 D | 0 4 |00000010| 6 A |
+--------+--------+--------+--------+--------+
フィールド長くさびASCIIの長さ+--------+--------+--------+--------+--------+ |01001100| 6 D| 0 4 |00000010| 6 A| +--------+--------+--------+--------+--------+
+----
|Don't forget the project report is
+----
+---- |プロジェクト報告が+であったのを忘れないでください。----
due tomorrow. Please have<CrLf>
明日、予定されています。 <CrLf>を持ってください。
your section to me by three this
3時までにこれを私に区分してください。
----+
afternoon.|
----+
----+ 午後、|----+
The following example illustrates the results of reissuing
the first message in this section. This message contains the
original message (as a Message data element), To, From, and
Posted-Date fields, and a Reissue-Type field with Redistributed
as its value:
以下の例はこのセクションにおける最初のメッセージを再発行するという結果を例証します。 このメッセージは値としてRedistributedがあるオリジナルのメッセージ(Messageデータ要素としての)、To、From、Posted-日付の分野、およびReissue-タイプ分野を含んでいます:
Message Length Type
+--------+--------+--------+--------+
|01001101| 8 1 | F C | 0 1 |
+--------+--------+--------+--------+
メッセージ長タイプ+--------+--------+--------+--------+ |01001101| 8 1 | F C| 0 1 | +--------+--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 9 | 0 5 |00000010|
+--------+--------+--------+--------+
フィールド長くさびASCII+--------+--------+--------+--------+ |01001100| 0 9 | 0 5 |00000010| +--------+--------+--------+--------+
Length
+--------+-- --+
| 0 6 |Cooper|
+--------+-- --+
長さ+--------+-- --+ | 0 6 |クーパー| +--------+-- --+
92
Appendix H
92 付録H
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+
フィールド長くさびASCII+--------+--------+--------+--------+ |01001100| 0 A| 0 1 |00000010| +--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Johnson|
+--------+--- ---+
長さ+--------+--- ---+ | 0 7 |ジョンソン| +--------+--- ---+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 7 | 0 2 |00101000| 1 4 |
+--------+--------+--------+--------+--------+
フィールド長くさび日付の長さ+--------+--------+--------+--------+--------+ |01001100| 1 7 | 0 2 |00101000| 1 4 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 2 |19800814-1030-0400|
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 1 2 |19800814-1030-0400| +--------+--------+---- ----+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 0 | 2 5 |00000010| 0 D |
+--------+--------+--------+--------+--------+
フィールド長くさびASCIIの長さ+--------+--------+--------+--------+--------+ |01001100| 1 0 | 2 5 |00000010| 0 D| +--------+--------+--------+--------+--------+
+---- ----+
|Redistributed|
+---- ----+
+---- ----+ |再配付します。| +---- ----+
Message Length Type
+--------+--------+--------+--------+
|01001101| 8 1 | B 6 | 0 1 |
+--------+--------+--------+--------+
メッセージ長タイプ+--------+--------+--------+--------+ |01001101| 8 1 | B6| 0 1 | +--------+--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 5 |00000010|
+--------+--------+--------+--------+
フィールド長くさびASCII+--------+--------+--------+--------+ |01001100| 0 A| 0 5 |00000010| +--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Johnson|
+--------+--- ---+
長さ+--------+--- ---+ | 0 7 |ジョンソン| +--------+--- ---+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+
フィールド長くさびASCII+--------+--------+--------+--------+ |01001100| 0 A| 0 1 |00000010| +--------+--------+--------+--------+
93
Appendix H
93 付録H
Length
+--------+--- ---+
| 0 7 |Stevens|
+--------+--- ---+
長さ+--------+--- ---+ | 0 7 |スティーブンス| +--------+--- ---+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 3 | 0 7 |00000010| 1 0 |
+--------+--------+--------+--------+--------+
フィールド長くさびASCIIの長さ+--------+--------+--------+--------+--------+ |01001100| 1 3 | 0 7 |00000010| 1 0 | +--------+--------+--------+--------+--------+
+---- ----+
|Project Deadline|
+---- ----+
+---- ----+ |プロジェクトの締め切り| +---- ----+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 7 | 0 2 |00101000| 1 4 |
+--------+--------+--------+--------+--------+
フィールド長くさび日付の長さ+--------+--------+--------+--------+--------+ |01001100| 1 7 | 0 2 |00101000| 1 4 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 2 |19800814-1000-0400|
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 1 2 |19800814-1000-0400| +--------+--------+---- ----+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 6 D | 0 4 |00000010| 6 A |
+--------+--------+--------+--------+--------+
フィールド長くさびASCIIの長さ+--------+--------+--------+--------+--------+ |01001100| 6 D| 0 4 |00000010| 6 A| +--------+--------+--------+--------+--------+
+----
|Don't forget the project report is
+----
+---- |プロジェクト報告が+であったのを忘れないでください。----
due tomorrow. Please have<CrLf>
明日、予定されています。 <CrLf>を持ってください。
your section to me by three this
3時までにこれを私に区分してください。
----+
afternoon.|
----+
----+ 午後、|----+
H.6 Unknown Lengths
H.6の未知の長さ
This section contains two examples of data elements with an
unknown length. The two examples have been presented in sections
H.2 and H.5, but with a known rather than an unknown length.
このセクションは未知の長さがあるデータ要素に関する2つの例を含みます。 2つの例はセクションのH.2とH.5で提示されますが、aが未知の長さよりむしろ知られている状態で、提示されました。
94
Appendix H
94 付録H
Set data element with an unknown length containing two
Integer data elements. The first integer has a value of 519
(decimal) while the value of the second is 71 (decimal). (These
two values have no ordering because they belong to a set.)
2つのIntegerデータ要素を含んでいる未知の長さがあるデータ要素を設定してください。 最初の整数には、2番目の値は71(10進)ですが、519(10進)の値があります。 (これらの2つの値には、セットのものので、注文がありません。)
Set Length Integer Length
+--------+--------+--------+--------+--------+--------+
|00001011| 8 0 |00100000| 0 2 | 0 2 0 7 |
+--------+--------+--------+--------+--------+--------+
長さの整数の長さ+を設定してください。--------+--------+--------+--------+--------+--------+ |00001011| 8 0 |00100000| 0 2 | 0 2 0 7 | +--------+--------+--------+--------+--------+--------+
Integer Length
+--------+--------+--------+--------+
|00100000| 0 2 | 0 0 4 7 |
+--------+--------+--------+--------+
整数の長さ+--------+--------+--------+--------+ |00100000| 0 2 | 0 0 4 7 | +--------+--------+--------+--------+
End-of-Con Length
+--------+--------+
|00000000|00000000|
+--------+--------+
まやかしの終わりの長さ+--------+--------+ |00000000|00000000| +--------+--------+
The following sample message with an unknown length had
Stevens as its originator and Johnson as its recipient. The
message was sent on August 14, 1980 at 10 a.m. EDT. The subject
of the message is "Project Deadline" and the message is a
reminder that the deadline is the next day and that the section
of the report for the project being done by Johnson should be
turned in to Stevens by 3 p.m. that day.
未知の長さがある以下のサンプルメッセージには、受取人としてのその創始者とジョンソンとしてスティーブンスがいました。 1980年8月14日東部夏時間午前10時にメッセージを転送しました。 メッセージの対象は「プロジェクトの締め切り」です、そして、メッセージは締め切りが翌日であり、ジョンソンによって行われたプロジェクト存在のためのレポートのセクションが当日午後3時までにスティーブンスに渡されるべきであるということを思い出させるものです。
Message Length Type
+--------+--------+--------+
|01001101| 8 0 | 0 1 |
+--------+--------+--------+
メッセージ長タイプ+--------+--------+--------+ |01001101| 8 0 | 0 1 | +--------+--------+--------+
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 5 |00000010|
+--------+--------+--------+--------+
フィールド長くさびASCII+--------+--------+--------+--------+ |01001100| 0 A| 0 5 |00000010| +--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Johnson|
+--------+--- ---+
長さ+--------+--- ---+ | 0 7 |ジョンソン| +--------+--- ---+
95
Appendix H
95 付録H
Field Length FID ASCII
+--------+--------+--------+--------+
|01001100| 0 A | 0 1 |00000010|
+--------+--------+--------+--------+
フィールド長くさびASCII+--------+--------+--------+--------+ |01001100| 0 A| 0 1 |00000010| +--------+--------+--------+--------+
Length
+--------+--- ---+
| 0 7 |Stevens|
+--------+--- ---+
長さ+--------+--- ---+ | 0 7 |スティーブンス| +--------+--- ---+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 1 3 | 0 7 |00000010| 1 0 |
+--------+--------+--------+--------+--------+
フィールド長くさびASCIIの長さ+--------+--------+--------+--------+--------+ |01001100| 1 3 | 0 7 |00000010| 1 0 | +--------+--------+--------+--------+--------+
+---- ----+
|Project Deadline|
+---- ----+
+---- ----+ |プロジェクトの締め切り| +---- ----+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 7 | 0 2 |00101000| 1 4 |
+--------+--------+--------+--------+--------+
フィールド長くさび日付の長さ+--------+--------+--------+--------+--------+ |01001100| 1 7 | 0 2 |00101000| 1 4 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 2 |19800814-1000-0400|
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 1 2 |19800814-1000-0400| +--------+--------+---- ----+
Field Length FID ASCII Length
+--------+--------+--------+--------+--------+
|01001100| 6 D | 0 4 |00000010| 6 A |
+--------+--------+--------+--------+--------+
フィールド長くさびASCIIの長さ+--------+--------+--------+--------+--------+ |01001100| 6 D| 0 4 |00000010| 6 A| +--------+--------+--------+--------+--------+
+----
|Don't forget the project report is
+----
+---- |プロジェクト報告が+であったのを忘れないでください。----
due tomorrow. Please have<CrLf>
明日、予定されています。 <CrLf>を持ってください。
your section to me by three this
3時までにこれを私に区分してください。
----+
afternoon.|
----+
----+ 午後、|----+
End-of-Con Length
+--------+--------+
|00000000|00000000|
+--------+--------+
まやかしの終わりの長さ+--------+--------+ |00000000|00000000| +--------+--------+
96
Appendix H
96 付録H
H.7 Message Encoding Using Vendor-Defined Fields
業者によって定義された分野を使用するH.7メッセージコード化
This example is provided to illustrate the encoding of non-
FIPS format messages in the FIPS format. It is the intent of the
standard to deal with computer based message systems which are
primarily intended for person-to-person use. This example deals
with the definition and use of vendor-defined fields to extend
the use of the standard to station-to-station messaging. The
context is a military message using the military standard JANAP-
128 format.
FIPS形式における、非FIPSの形式メッセージのコード化を例証するためにこの例を提供します。 それは人から人への使用のために主として意図するメッセージシステムが基づいているコンピュータを取扱う規格の意図です。 この例は、ステーションからステーションへのメッセージングに規格の使用を広げるために業者によって定義された分野の定義と使用に対処します。 文脈は軍事の標準のJANAP128形式を使用する軍事のメッセージです。
H.7.1 Example of a JANAP-128 Message
JANAP-128メッセージに関するH.7.1の例
JANAP-128
RTTUZYUW RUABCDE0010 0330930-UUUU--RUXABYE.
ZNR UUUUU
R 020830Z FEB 82
FM Commander,Atlantic Fleet
TO USS SHIPA
BT
UNCLAS
JANAP-128 RTTUZYUW RUABCDE0010 0330930-UUUU--RUXABYE。 USS SHIPA BT UNCLASへの大西洋船隊のZNR UUUUU R020830Z2月82日FM指揮官
MESSAGE BODY
メッセージ本体
BT
#0010
NNNN
BT#0010NNNN
H.7.2 Encoding of Example using the FIPS Message Format
FIPSメッセージ・フォーマットを使用する例のH.7.2コード化
Message Length Type
+--------+--------+--------+--------+
|01001101| 8 1 | D 0 | 0 1 |
+--------+--------+--------+--------+
メッセージ長タイプ+--------+--------+--------+--------+ |01001101| 8 1 | D0| 0 1 | +--------+--------+--------+--------+
Field Length FID
+--------+--------+--------+
|01001100| 0 4 | 1 8 |
+--------+--------+--------+
フィールド長くさび+--------+--------+--------+ |01001100| 0 4 | 1 8 | +--------+--------+--------+
97
Appendix H
97 付録H
ASCII Length
+--------+--------+--------+
|00000010| 0 1 | R |
+--------+--------+--------+
ASCIIの長さ+--------+--------+--------+ |00000010| 0 1 | R| +--------+--------+--------+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 7 | 8 2 | 0 0 | 0 1 |
+--------+--------+--------+--------+--------+
フィールド長くさび+--------+--------+--------+--------+--------+ |01001100| 0 7 | 8 2 | 0 0 | 0 1 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+--------+--------+
|00000010| 0 2 | T | T |
+--------+--------+--------+--------+
ASCIIの長さ+--------+--------+--------+--------+ |00000010| 0 2 | T| T| +--------+--------+--------+--------+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 6 | 8 2 | 0 0 | 0 2 |
+--------+--------+--------+--------+--------+
フィールド長くさび+--------+--------+--------+--------+--------+ |01001100| 0 6 | 8 2 | 0 0 | 0 2 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+--------+
|00000010| 0 1 | U |
+--------+--------+--------+
ASCIIの長さ+--------+--------+--------+ |00000010| 0 1 | U| +--------+--------+--------+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 9 | 8 2 | 0 0 | 0 3 |
+--------+--------+--------+--------+--------+
フィールド長くさび+--------+--------+--------+--------+--------+ |01001100| 0 9 | 8 2 | 0 0 | 0 3 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 4 | ZYUW |
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 0 4 | ZYUW| +--------+--------+---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 0 A | 2 2 |
+--------+--------+--------+
フィールド長くさび+--------+--------+--------+ |01001100| 0 A| 2 2 | +--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 7 | RUABCDE |
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 0 7 | RUABCDE| +--------+--------+---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 0 7 | 1 7 |
+--------+--------+--------+
フィールド長くさび+--------+--------+--------+ |01001100| 0 7 | 1 7 | +--------+--------+--------+
98
Appendix H
98 付録H
ASCII Length
+--------+--------+---- ----+
|00000010| 0 4 | 0010 |
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 0 4 | 0010 | +--------+--------+---- ----+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 8 | 0 2 |00101000| 1 5 |
+--------+--------+--------+--------+--------+
フィールド長くさび日付の長さ+--------+--------+--------+--------+--------+ |01001100| 1 8 | 0 2 |00101000| 1 5 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 1 3 |19820202093000-0000|
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 1 3 |19820202093000-0000| +--------+--------+---- ----+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 9 | 8 2 | 0 0 | 0 2 |
+--------+--------+--------+--------+--------+
フィールド長くさび+--------+--------+--------+--------+--------+ |01001100| 0 9 | 8 2 | 0 0 | 0 2 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 4 | UUUU |
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 0 4 | UUUU| +--------+--------+---- ----+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 C | 8 2 | 0 0 | 0 4 |
+--------+--------+--------+--------+--------+
フィールド長くさび+--------+--------+--------+--------+--------+ |01001100| 0C| 8 2 | 0 0 | 0 4 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 7 | RUXABYE |
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 0 7 | RUXABYE| +--------+--------+---- ----+
Field Length FID
+--------+--------+--------+--------+--------+
|01001100| 0 A | 8 2 | 0 0 | 0 2 |
+--------+--------+--------+--------+--------+
フィールド長くさび+--------+--------+--------+--------+--------+ |01001100| 0 A| 8 2 | 0 0 | 0 2 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 5 | UUUUU |
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 0 5 | UUUUU| +--------+--------+---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 0 4 | 1 8 |
+--------+--------+--------+
フィールド長くさび+--------+--------+--------+ |01001100| 0 4 | 1 8 | +--------+--------+--------+
99
Appendix H
99 付録H
ASCII Length
+--------+--------+--------+
|00000010| 0 1 | R |
+--------+--------+--------+
ASCIIの長さ+--------+--------+--------+ |00000010| 0 1 | R| +--------+--------+--------+
Field Length FID Date Length
+--------+--------+--------+--------+--------+
|01001100| 1 4 | 1 1 |00101000| 1 1 |
+--------+--------+--------+--------+--------+
フィールド長くさび日付の長さ+--------+--------+--------+--------+--------+ |01001100| 1 4 | 1 1 |00101000| 1 1 | +--------+--------+--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 F |8202020830-0000|
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 0F|8202020830-0000| +--------+--------+---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 1 B | 0 1 |
+--------+--------+--------+
フィールド長くさび+--------+--------+--------+ |01001100| 1 B| 0 1 | +--------+--------+--------+
ASCII Length
+--------+--------+
|00000010| 1 8 |
+--------+--------+
ASCIIの長さ+--------+--------+ |00000010| 1 8 | +--------+--------+
+---- ----+
|Commander,Atlantic Fleet|
+---- ----+
+---- ----+ |大西洋船隊の指揮官| +---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 0 C | 0 5 |
+--------+--------+--------+
フィールド長くさび+--------+--------+--------+ |01001100| 0C| 0 5 | +--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 9 | USS SHIPA |
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 0 9 | USS SHIPA| +--------+--------+---- ----+
Field Length FID
+--------+--------+--------+
|01001100| 0 7 | 0 4 |
+--------+--------+--------+
フィールド長くさび+--------+--------+--------+ |01001100| 0 7 | 0 4 | +--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 4 | BODY |
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 0 4 | ボディー| +--------+--------+---- ----+
100
Appendix H
100 付録H
Field Length FID
+--------+--------+--------+
|01001100| 0 7 | 1 7 |
+--------+--------+--------+
フィールド長くさび+--------+--------+--------+ |01001100| 0 7 | 1 7 | +--------+--------+--------+
ASCII Length
+--------+--------+---- ----+
|00000010| 0 4 | 0010 |
+--------+--------+---- ----+
ASCIIの長さ+--------+--------+---- ----+ |00000010| 0 4 | 0010 | +--------+--------+---- ----+
H.7.3 Field Mappings of JANAP-128 to FIPS Format
FIPS形式へのJANAP-128に関するH.7.3分野マッピング
JANAP-128 Field FIPS Format Field
JANAP-128分野FIPS形式分野
Precedence Precedence (Appendix A)
Language Media Format Vendor-Defined
Security Vendor-Defined
Content Indicator Code Vendor-Defined
Origination Station Sender (Appendix A)
Routing Indication
Station Serial Number Originator-Serial-Number
(Appendix A)
Time of File Posted-Date (Appendix A)
Security Vendor-Defined
Destination Station Vendor-Defined
Routing Indicator
Security Vendor-Defined
Precedence Precedence (Appendix A)
Date/Time Group Date (Appendix A)
FM From (Appendix A)
TO To (Appendix A)
Body of Message Text (Appendix A)
Station Serial Number Originator-Serial-Number
(Appendix A)
先行先行、(付録a)言語メディアがベンダーによって定義されたベンダーによって定義された満足しているセキュリティのインディケータコードベンダーによって定義された創作駅の送付者をフォーマットする、(付録a)ルート設定指示駅の通し番号創始者通し番号、(ファイルの掲示された期日の付録a)時間、(付録a); ベンダーによって定義されたベンダーによって定義されたセキュリティのルート設定インディケータセキュリティベンダーによって定義された先行目的地駅の先行、(付録a)日付/時間グループ日付、(付録a)FM、(付録a)、(メッセージ・テキストの付録a)ボディー、(付録a)駅の通し番号創始者通し番号(付録a)
H.7.4 Vendor-Defined Fields
H.7.4は分野をベンダーで定義しました。
101
101
-----------------------------------------------------------------
-----------------------------------------------------------------
Field Name Identifier Value
8
フィールド名識別子価値8
Description
記述
-----------------------------------------------------------------
-----------------------------------------------------------------
Language Media Format 01
8
This field contains two ASCII characters; the first
indicates the input media and the second the output media.
言語メディアFormat01 8This分野は2人のASCII文字を含みます。 1番目は入力メディアを示します、そして、2番目はアウトプット・メディアを示します。
Security 02
8
This field contains a variable length ASCII character
indicator of the security classification of the messages.
8Thisがさばくセキュリティ02はメッセージのセキュリティ分類の可変長ASCII文字インディケータを含んでいます。
Content Indicator Code 03
8
This field contains four ASCII characters and provides
information describing the message content and message handling
actions to be performed.
Indicator Code03 8Thisがさばく内容は、4人のASCII文字を含んで、実行されるためにメッセージ内容とメッセージハンドリング動作について説明する情報を提供します。
Destination Station Routing Indicator 04
8
This field contains four ASCII characters indicating the CPU
and terminal device to which the message should be sent.
Indicator04 8Thisがさばく目的地駅のルート設定はメッセージが送られるべきであるCPUと端末装置を示す4人のASCII文字を含みます。
102
102
REFERENCES
参照
[BlaR-80]
R. P. Blanc and J. F. Heafner. The NBS Program in Computer
Network Protocol Standards. In Proceedings, ICCC 80. 1980.
[BlaR-80]R.P.ブランとJ.F.Heafner。 NBSはコンピュータネットワークプロトコル標準でプログラムを作ります。 議事、ICCC80で。 1980.
[CCIT-82]
CCITT Study Group VII/5. Draft recommendation X.MHS1:
Message Handling Systems: System Model - Service Elements
(Version 2). Technical Report, International Telegraph and
Telephone Consultative Committee (CCITT), December, 1982.
[CCIT-82]CCITT研究グループVII/5。 推薦X. MHS1を作成してください: メッセージハンドリングシステム: システムモデル--Elements(バージョン2)にサービスを提供してください。 技術報告書、国際電信電話諮問委員会(CCITT)、1982年12月。
[CroD-77]
David H. Crocker, John J. Vittal, Kenneth T. Pogran,
D. Austin Henderson, Jr. Standard for the Format of ARPA
Network Text Messages. RFC 733, The Rand Corporation, Bolt
Beranek and Newman Inc, Massachussets Institute of
Technology, Bolt Beranek and Newman Inc., November, 1977.
[CroD-77]デヴィッド・H.クロッカー、ジョンJ.Vittal、ケネスT.Pogran、D.オースチンヘンダーソン、アルパの形式のJr.Standardはテキスト・メッセージをネットワークでつなぎます。 RFC733、ランド研究所、ボルトBeranek、およびニューマンInc(Massachussets工科大学)はBeranekとニューマン株式会社(1977年11月)をボルトで締めます。
[FeiE-79]
E. Feinler, J. Pickens, and A. Sjoberg. Computer Message
Services Bibliography. Technical Report NIC-BIBLIO-791201,
SRI International, December, 1979.
[FeiE-79] E.Feinler、J.ピケンズ、およびA.シェーベリ。 コンピュータメッセージサービス図書目録。 技術報告書NIC本791201、SRIインターナショナル、1979年12月。
[ISOD-79]
ISO/TC97/SC6 Data Communications. Second Draft Proposed
Communication Heading Format Standard. ISO/TC97/SC6 N 1948,
ISO International Organization for Standardization
Organization Internationale de Normalisation, September,
1979. Secretariat: USA (ANSI).
[ISOD-79]ISO/TC97/SC6データ通信。 第2草案はコミュニケーション見出し形式規格を提案しました。 ISO/TC97/SC6N1948、ISO国際標準化機構Organizationインターナショナルde Normalisation、1979年9月。 事務局: 米国(ANSI)。
[ISOD-82]
ISO/TC97/SC16. Information Processing Systems - Open Systems
Interconnection - Basic Reference Model. ISO/DIS 7498, ISO
International Organization for Standardization Organization
Internationale de Normalisation, December, 1982.
[ISOD-82]ISO/TC97/SC16。 情報処理システム--オープン・システム・インターコネクション--基本参照モデル。 ISO/DIS7498、ISO国際標準化機構Organizationインターナショナルde Normalisation1982年12月。
[NatB-68]
National Bureau of Standards. Calendar Date. Federal
Information Processing Standards Publication 4, U.S.
Department of Commerce / National Bureau of Standards,
November, 1968.
[NatB-68]規格基準局。 カレンダ日付。 連邦政府の情報処理規格公表4、米国商務省/規格基準局、11月、1968
[NatB-75]
National Bureau of Standards. Code Extension Techniques in 7
or 8 Bits. Federal Information Processing Standards
Publication 35, U.S. Department of Commerce / National
Bureau of Standards, June, 1975.
[NatB-75]規格基準局。 7ビットか8ビットの拡大のテクニックをコード化してください。 連邦政府の情報処理規格公表35、米国商務省/規格基準局、6月、1975
103
103
[NatB-77]
National Bureau of Standards. Data Encryption Standard.
Federal Information Processing Standards Publication 46,
U.S. Department of Commerce / National Bureau of Standards,
January, 1977.
[NatB-77]規格基準局。 データ暗号化規格。 連邦政府の情報処理規格公表46、米国商務省/規格基準局、1月、1977
[NatB-79a]
National Bureau of Standards. Representations of Local Time
of the Day for Information Interchange. Federal Information
Processing Standards Publication 58, U.S. Department of
Commerce / National Bureau of Standards, February, 1979.
[NatB-79a]規格基準局。 情報交換のための日の現地時間の表現。 連邦政府の情報処理規格公表58、米国商務省/規格基準局、2月、1979
[NatB-79b]
National Bureau of Standards. Representations of Universal
Time, Local Time Differentials, and United States Time Zone
References for Information Interchange. Federal Information
Processing Standards Publication 59, U.S. Department of
Commerce / National Bureau of Standards, February, 1979.
[NatB-79b]規格基準局。 時間帯が情報交換のために参照をつけるLocal Timeの世界標準時の表現、デフ装置、および合衆国。 連邦政府の情報処理規格公表59、米国商務省/規格基準局、2月、1979
[NatB-80]
National Bureau of Standards. Code for Information
Interchange. Federal Information Processing Standards
Publication 1-1, U.S. Department of Commerce / National
Bureau of Standards, December, 1980.
[NatB-80]規格基準局。 情報交換用符号。 連邦政府の情報処理規格公表1-1、米国商務省/規格基準局、1980年12月。
[PosJ-79]
Jonathan B. Postel. INTERNET MESSAGE PROTOCOL. RFC 753,
Information Sciences Institute, March, 1979.
[PosJ-79]ジョナサン・B.ポステル。 インターネットメッセージプロトコル。 RFC753、科学が1979年3月に設ける情報。
[TasG-80]
Task Group X3S33 on Data Communications Formats, ANSI
Subcommittee X3S3 on Data Communications. Third Draft
Proposed American National Standard for Heading Format
Structure for Code Independent Communication Headings. ANSI
document X3S37/80-01, Computer and Business Equipment
Manufacturers Association, 1980.
[TasG-80]はデータ通信のときにデータ通信形式のグループX3S33、ANSI小委員会X3S3に仕事を課します。 第3草稿はコードの独立しているコミュニケーション見出しのために見出し形式構造に米国標準規格を提案しました。 ANSIはX3S37/80-01、コンピュータ事務機器製造業者協会、1980を記録します。
104
104
INDEX
インデックス
ASCII-String 35, 36, 47, 50, 52, 54, 58, 59, 60, 61,
63, 65, 69
Assignment 22, 28, 61
Attachments 23, 57
Author 19, 57
ASCII-ストリング35、36、47、50、52、54、58、59、60、61、63、65、69課題22、28、61付属23、57作者19、57
BASIC 18
BASIC Data Elements
ASCII-String 47, 63
Date 50, 65
End-of-Constructor 48, 66
Field 50, 66
Message 51, 67
BASIC fields
Cc 20
Reply-To 19
Subject 23
Text 23
BASIC syntactic elements 35
Bcc 19, 25, 57
Bit numbering in octets 37
Bit-String 36, 42, 47, 49, 50, 52, 64, 65, 69
Boolean 36, 48, 64
BASIC18BASIC Data Elements ASCII-ストリング47、63Date50、65建設者のEnd48、66Field50、66Message51、67BASICがCc20をさばく、Reply、-、八重奏37Bit-ストリング36、42、47、49、50、52、64、65、69でブール36、48に達する19Subject23Text23BASIC構文の要素35Bcc19、25、57Bit、64
Cc 20, 58
Chains of correspondence 29
Circulate-Next 20, 31, 58
Circulate-To 20, 31, 58
Circulation 31
Comment 36, 37, 44, 54
Comments 23, 58
Compliance requirements 41
Compressed 37, 43, 49, 54, 65
Compression identifier 49, 65
Compression Identifiers
Unspecified 54
Constructor data element 35, 36
Contents 38, 76
Cross Referencing 29
通信29次のCirculate20、31、58のcc20、58チェインズ、Circulate、-、20、31、58Circulation31Comment36、37、44、54Comments23、58Compliance要件41Compressed37、43、49、54、65Compression識別子49、65Compression Identifiers Unspecified54Constructorデータ要素35、36Contents38、76Cross Referencing29
Data Element Contents 43, 44, 87, 42, 44, 52, 69, 42,
44, 46, 47, 51, 64, 69, 87
Data Elements
ASCII-String (BASIC) 47, 63
Bit-String (OPTIONAL) 47, 64
データ要素コンテンツ43、44、87、42、44、52、69、42、44、46、47、51、64、69、87データ要素ASCII-ストリング(基本的な)47、63ビット列(任意の)47、64
105
105
Boolean (OPTIONAL) 48, 64
Compressed (OPTIONAL) 49, 65
Date (BASIC) 50, 65
Encrypted (OPTIONAL) 50, 65
End-of-Constructor (BASIC) 48, 66
Extension (OPTIONAL) 52, 66
Field (BASIC) 50, 66
Integer (OPTIONAL) 48, 67
Message (BASIC) 51, 67
No-Op (OPTIONAL) 49, 67
Padding (OPTIONAL) 49, 68
Property (OPTIONAL) 51, 68
Property-List (OPTIONAL) 51, 68
Sequence (OPTIONAL) 51, 69
Set (OPTIONAL) 52, 69
Unique-ID (OPTIONAL) 52, 69
Vendor-Defined (OPTIONAL) 53, 70
Date 20, 50, 58, 60, 61, 62, 65
Dating 30
Delivery 13, 20, 60
Delivery Protocol 13
Delivery Slot 13
ブール48、(任意の)64圧縮された(任意の)49、65期日(基本的な)50、65建設者のコード化された(任意の)50、65終わり(基本的な)の48、66延期(任意の)52、66は(基本的)の50、66整数(任意の)48、67メッセージ(基本的な)51、67オプアートがない(任意の)49、67詰め物(任意の)49をさばきます; 68 (任意)の(任意)の特性の(任意)の51、68特性リスト(任意の)のユニークなID(任意)の52、69業者によって定義された(任意の)53、70 51、68系列51、69セット52、69期日20、50、58、60、61、62、65のデート30配送13、20、60配送プロトコル13配送スロット13
Encapsulating 26
Encrypted 37, 43, 50, 54, 65
Encryption identifier 50, 65
Encryption Identifiers
FIPS-Standard 54
Unspecified 54
End-Date 20, 21, 30, 58, 62
End-Of-Constructor 36, 42, 44, 48, 66
Extension 35, 46, 52, 66
要約26Encrypted37、43、50、54、65Encryption識別子50、65のEncryption Identifiers FIPS標準の54Unspecified54End-日付20、21、30、58、62建設者のEnd36、42、44、48、66Extension35、46、52、66
Field 14, 31, 35, 36, 37, 43, 50, 51, 66, 67, 72
Field Identifier 50, 66
Field label presentation 35
Fields
Attachments (OPTIONAL) 57, 23
Author (OPTIONAL) 57, 19
Bcc (OPTIONAL) 57, 19
Cc (BASIC) 58, 20
Circulate-Next (OPTIONAL) 58, 20
Circulate-To (OPTIONAL) 58, 20
Comments (OPTIONAL) 58, 23
Date (OPTIONAL) 58, 20
End-Date (OPTIONAL) 58, 20
From (REQUIRED) 59, 19
In-Reply-To (OPTIONAL) 59, 21
Keywords (OPTIONAL) 59, 23
Message-Class (OPTIONAL) 59, 22
Message-ID (OPTIONAL) 59, 21
Field 14, 31, 35, 36, 37, 43, 50, 51, 66, 67, 72 Field Identifier 50, 66 Field label presentation 35 Fields Attachments (OPTIONAL) 57, 23 Author (OPTIONAL) 57, 19 Bcc (OPTIONAL) 57, 19 Cc (BASIC) 58, 20 Circulate-Next (OPTIONAL) 58, 20 Circulate-To (OPTIONAL) 58, 20 Comments (OPTIONAL) 58, 23 Date (OPTIONAL) 58, 20 End-Date (OPTIONAL) 58, 20 From (REQUIRED) 59, 19 In-Reply-To (OPTIONAL) 59, 21 Keywords (OPTIONAL) 59, 23 Message-Class (OPTIONAL) 59, 22 Message-ID (OPTIONAL) 59, 21
106
106
Obsoletes (OPTIONAL) 59, 21
Originator-Serial-Number (OPTIONAL) 59, 21
Posted-Date (REQUIRED) 60, 20
Precedence (OPTIONAL) 60, 22
Received-Date (OPTIONAL) 60, 20
Received-From (OPTIONAL) 60, 22
References (OPTIONAL) 60, 22
Reissue-Type (OPTIONAL) 61, 22
Reply-To (BASIC) 61, 19
Sender (OPTIONAL) 61, 19
Start-Date (OPTIONAL) 61, 21
Subject (BASIC) 61, 23
Text (BASIC) 61, 23
To (REQUIRED) 61, 19
Warning-Date (OPTIONAL) 62, 21
FIPS-Standard 54, 55
From 17, 19, 29, 57, 59, 61
Obsoletes (OPTIONAL) 59, 21 Originator-Serial-Number (OPTIONAL) 59, 21 Posted-Date (REQUIRED) 60, 20 Precedence (OPTIONAL) 60, 22 Received-Date (OPTIONAL) 60, 20 Received-From (OPTIONAL) 60, 22 References (OPTIONAL) 60, 22 Reissue-Type (OPTIONAL) 61, 22 Reply-To (BASIC) 61, 19 Sender (OPTIONAL) 61, 19 Start-Date (OPTIONAL) 61, 21 Subject (BASIC) 61, 23 Text (BASIC) 61, 23 To (REQUIRED) 61, 19 Warning-Date (OPTIONAL) 62, 21 FIPS-Standard 54, 55 From 17, 19, 29, 57, 59, 61
Globally unique identifiers 29
グローバルにユニークな識別子29
Identifier octet 38, 41, 37, 38, 42, 44, 76
Identifiers
globally unique 29
In-Reply-To 21, 29, 59
Indefinite length code 41
Integer 36, 48, 52, 67, 69
識別子八重奏38、41、37、38、42、44、76Identifiersグローバルにユニークな29、Inが答える、21、29、59Indefinite長さのコード41Integer36、48、52、67、69
Keywords 23, 59, 88
キーワード23、59、88
Length Code 40, 41, 42, 38, 39, 40, 41, 42, 44, 46,
76, 77, 87
Long length code 41
長さのCode40、41、42、38、39、40、41、42、44、46、76、77、87Long長さのコード41
Message Transfer System 13, 22, 60
Message 14, 17, 35, 36, 37, 43, 51, 67
Message content 13
Message envelope 13
Message stores 30
Message Transfer System 13, 22, 60, 12, 13, 14, 17,
20, 22, 60
Message Types
FIPS-Standard 55
Message-Class 22, 59
Message-ID 21, 22, 29, 31, 59, 60
メッセージのMessageの満足している13Message Transfer System13、22、60Message14、17、35、36、37、43、51、67封筒13Message店30Message Transfer System13、22、60、12、13、14、17、20、22、60Message Types FIPS-規格55Message-クラス22、59 21、22、29、31、59、60歳のMessage-ID
No-Op 49, 67
Numbering bits in octets 37
オプアートがない49、八重奏37における67Numberingビット
Obsoletes 21, 29, 59
Octets
bit numbering in 37
29、59Octetsビットに37で付番して、21を時代遅れにします。
107
107
OPTIONAL 18
OPTIONAL Data Elements
Bit-String 47, 64
Boolean 48, 64
Compressed 49, 65
Encrypted 50, 65
Extension 52, 66
Integer 48, 67
No-Op 49, 67
Padding 49, 68
Property 51, 68
Property-List 51, 68
Sequence 51, 69
Set 52, 69
Unique-ID 52, 69
Vendor-Defined 53, 70
OPTIONAL fields
Attachments 23
Author 19
Bcc 19
Circulate-Next 20
Circulate-To 20
Comments 23
Date 20
End-Date 20
In-Reply-To 21
Keywords 23
Message-Class 22
Message-ID 21
Obsoletes 21
Originator-Serial-Number 21
Precedence 22
Received-Date 20
Received-From 22
References 22
Reissue-Type 22
Sender 19
Start-Date 21
Warning-Date 21
OPTIONAL syntactic elements 35
Originator 15, 18, 20, 30, 57, 58, 59, 61
Originator-Serial-Number 21, 30, 59
任意の18の任意のデータElements Bit-String47、64論理演算子48、64圧縮された49、65コード化された50、65拡大52、66整数48、67オプアートがない49、67詰め物49、68の特性51、68の特性リスト51、68系列51、69セット52、69 52、ユニークな69歳のIDは53を業者と同じくらい定義しました; 70OPTIONALがAttachments23Author19Bcc19次のCirculate20をさばく、Circulate、-、20Comments23のDate20End-日付の20、Inが答える、21Obsoletes21の21Keywords23のMessage-クラス22Message-ID Originatorの連続の番号21Precedence22Received-日付の20、Received、-、22References22のReissue-タイプ22Sender19Start-日付21Warning-日付21のOPTIONALの構文の要素35Originator15、18、20、30、57、58、59、61Originatorの連続の番号21、30、59
Padding 49, 68
Person 18
Posted-Date 17, 20, 31, 58, 60
Posting 13
Posting Protocol 13
Posting Slot 13
Precedence 22, 60
Precedence categories 22
詰め物49、68Person18Posted-日付17、20、31、58、60Posting13Postingプロトコル13Posting Slot13Precedence22、60Precedenceカテゴリ22
108
108
Precedence scheme 60
Presentation
field label 35
Primitive data element 36, 35, 36
Printing-Name 36, 37, 44, 54, 82
Process 18
Properties
Comment 54
Printing-Name 54
Property 38, 43, 51, 68
Property-Identifier 51, 68
Property-List 36, 38, 44, 46, 51, 68, 76
Printing-名前36、37、44、54、82先行計画60Presentation分野ラベル35Primitiveデータ要素36、35、36Process18Properties Comment54Printing-名前54Property38、43、51、68Property-識別子51、68Property-リスト36、38、44、46、51、68、76
Qualifier 38, 39, 40, 41, 42, 43, 44, 46, 47, 49, 50,
51, 52, 53, 64, 65, 66, 68, 70, 76
Qualifiers 43
38、39、40、41、42、43、44、46、47、49、50、51、52、53、64、65、66、68、70、76人の資格を与える人資格を与える人43
Received-Date 20, 60
Received-From 22, 60
Recipient 15, 19, 20, 22, 57, 58, 60, 61
Redistribution 22, 26, 61
References 22, 29, 60
Reissue-Type 22, 61
Reply 18, 28
Reply-to 19, 28, 59, 61
REQUIRED 18
REQUIRED fields
From 19
Posted-Date 20
To 19
Requirements
compliance 41
Role 18
受信された期日20、60、Received、-、22、60Recipient15、19、20、22、57、58、60、61Redistribution22、26、61References22、29、60Reissue-タイプ22、61Reply18、28、Reply、-、19、28、59、61REQUIRED18REQUIREDはFrom19Posted-日付20To19Requirementsコンプライアンス41Role18をさばきます。
Sender 19, 31, 61
Sequence 35, 36, 51, 69
Sequences 36
Serial Numbers 21, 30, 59
Set 36, 51, 52, 69
Short length code 41
Slot 13
Start-Date 21, 30, 61
Subject 23, 61
Syntactic reissuing 26
送付者19、31、61Sequence35、36、51、69Sequences36Serial民数記21、30、59Set36、51、52、69Short長さのコード41Slot13Start-日付21、30、61Subject23、61Syntactic再発行26
Text 23, 32, 61
To 17, 19, 31, 37, 61
テキスト23、32、61〜17、19、31、37、61
Unique identifiers 29
Unique-ID 52, 59, 60, 69
Unspecified 54
ユニークな識別子29Unique-ID52、59、60、69Unspecified54
109
109
User Agent 12, 13, 14
User interface 35
ユーザエージェント12、13、14Userインタフェース35
Vendor-Defined 35, 46, 53, 70
35、46、53、70を業者と同じくらい定義します。
Warning-Date 21, 30, 62
警告日付21、30、62
110
110
一覧
スポンサーリンク
