RFC1378 日本語訳
1378 The PPP AppleTalk Control Protocol (ATCP). B. Parker. November 1992. (Format: TXT=28496 bytes) (Status: HISTORIC)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group B. Parker
Request for Comments: 1378 Cayman Systems
November 1992
コメントを求めるワーキンググループB.レプ要求をネットワークでつないでください: 1378 ケイマンシステム1992年11月
The PPP AppleTalk Control Protocol (ATCP)
ppp AppleTalk制御プロトコル(ATCP)
Status of this Memo
このMemoの状態
This RFC specifies an IAB standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはIAB標準化過程プロトコルをインターネットコミュニティに指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.
Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でNetwork Layerがプロトコル情報であるとカプセル化する標準方法を提供します。 PPPは、異なったネットワーク層プロトコルを設立して、構成するためにまた、広げることができるLink Controlプロトコルを定義して、Network Controlプロトコル(NCP)のファミリーを提案します。
This document defines the NCP for establishing and configuring the AppleTalk Protocol [3] over PPP.
このドキュメントは、PPPの上でAppleTalkプロトコル[3]を設立して、構成するためにNCPを定義します。
This memo is a joint effort of the AppleTalk-IP Working Group and the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu mailing list.
このメモはAppleTalk IP作業部会とPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)の共同努力です。 このメモのコメントを ietf-ppp@ucdavis.edu メーリングリストに提出するべきです。
Table of Contents
目次
1. Introduction .......................................... 2 2. A PPP Network Control Protocol (NCP) for AppleTalk .... 2 2.1 Sending AppleTalk Datagrams ........................... 3 2.2 Half-Routers .......................................... 4 3. ATCP Configuration Options ............................ 4 3.1 AppleTalk-Address ..................................... 5 3.2 Routing-Protocol ...................................... 7 3.3 Suppress-Broadcasts ................................... 8 3.4 AT-Compression-Protocol ............................... 9 3.5 Server-information .................................... 10 3.6 Zone-Information ...................................... 12 3.7 Default-Router-Address ................................ 13 APPENDICES ................................................... 14 A. ATCP Recommended Options .............................. 14 REFERENCES ................................................... 15
1. 序論… 2 2. pppネットワークはAppleTalkのためにプロトコル(NCP)を制御します… 2 2.1 AppleTalkデータグラムを送ります… 3 2.2の半分ルータ… 4 3. ATCP設定オプション… 4 3.1 AppleTalkアドレス… 5 3.2 ルート設定プロトコル… 7 3.3 放送を抑圧します… 8 大西洋標準時3.4の圧縮プロトコル… 9 3.5サーバ情報… 10 3.6ゾーン情報… 12 3.7 デフォルトルータアドレス… 13個の付録… 14 A.ATCPはオプションを推薦しました… 14の参照箇所… 15
Parker [Page 1] RFC 1378 PPP ATCP November 1992
パーカー[1ページ]RFC1378ppp ATCP1992年11月
ACKNOWLEDGEMENTS ............................................. 15 SECURITY CONSIDERATIONS ...................................... 16 CHAIR'S ADDRESS .............................................. 16 AUTHOR'S ADDRESS ............................................. 16
承認… 15 セキュリティ問題… 16 議長のアドレス… 16作者のアドレス… 16
1. Introduction
1. 序論
PPP has three main components:
PPPには、3つの主なコンポーネントがあります:
1. A method for encapsulating datagrams over serial links.
1. シリーズの上でデータグラムをカプセル化するためのメソッドはリンクされます。
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
2. データリンク接続を設立して、構成して、テストするためのLink Controlプロトコル(LCP)。
3. A family of Network Control Protocols (NCPs) for establishing
and configuring different network-layer protocols.
3. 異なったネットワーク層プロトコルを設立して、構成するためのNetwork Controlプロトコル(NCP)のファミリー。
In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link.
ポイントツーポイント接続の上でコミュニケーションを確立するために、PPPリンクの各端は、最初に、構成するパケットをLCPに送って、データ・リンクをテストに送らなければなりません。 リンクが設立されて、任意の施設が必要に応じてLCPによって交渉された後に、PPPは、1つ以上のネットワーク層プロトコルを選んで、構成するためにNCPパケットを送らなければなりません。 いったんそれぞれの選ばれたネットワーク層プロトコルを構成すると、各ネットワーク層プロトコルからのデータグラムをリンクの上に送ることができます。
The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (an inactivity timer expires or network administrator intervention).
リンクは明白なLCPかNCPパケットがリンクを閉鎖するか、または何らかの外部のイベントが起こるまで(不活発タイマが期限が切れるか、または管理者介入をネットワークでつないでください)コミュニケーションのために構成されたままで残るでしょう。
2. A PPP Network Control Protocol (NCP) for AppleTalk
2. AppleTalkのためのpppネットワーク制御プロトコル(NCP)
The AppleTalk Control Protocol (ATCP) is responsible for configuring, enabling, and disabling the AppleTalk protocol modules on both ends of the point-to-point link. ATCP uses the same packet exchange machanism as the Link Control Protocol (LCP). ATCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. ATCP packets received before this phase is reached should be silently discarded.
ポイントツーポイント接続の両端でAppleTalkプロトコルがモジュールであると構成して、可能にして、無効にするのにAppleTalk Controlプロトコル(ATCP)は原因となります。 ATCPはLink Controlプロトコル(LCP)としての同じパケット交換machanismを使用します。 PPPがNetwork-層のプロトコルフェーズに達するまで、ATCPパケットは交換されないかもしれません。 このフェーズに達する前に受け取られたATCPパケットは静かに捨てられるべきです。
The AppleTalk Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions:
AppleTalk Controlプロトコルはまさに以下の例外でLink Controlプロトコル[1]と同じです:
Frame Modifications
フレーム変更
The packet may utilize any modifications to the basic frame format
which have been negotiated during the Link Establishment phase.
パケットは基本枠形式へのLink特権階級段階の間に交渉されているどんな変更も利用するかもしれません。
Parker [Page 2] RFC 1378 PPP ATCP November 1992
パーカー[2ページ]RFC1378ppp ATCP1992年11月
Data Link Layer Protocol Field
データリンク層プロトコル分野
Exactly one ATCP packet is encapsulated in the Information field
of a PPP Data Link Layer frame where the Protocol field indicates
type hex 8029 (AppleTalk Control Protocol).
ちょうど1つのATCPパケットがプロトコル分野が、タイプが8029(AppleTalk Controlプロトコル)人に魔法をかけるのを示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。
Code field
コード分野
Only Codes 1 through 7 (Configure-Request, Configure-Ack,
Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack
and Code-Reject) are used. Other Codes should be treated as
unrecognized and should result in Code-Rejects.
Codes1だけ、通じて、7 (要求を構成する、Configure-Ack、Configure-Nak、Configure-廃棄物、Terminate-要求、Terminate-Ack、およびCode-廃棄物) 使用されます。 他のCodesは認識されていないとして扱われるべきであり、Code-廃棄物をもたらすはずです。
Timeouts
タイムアウト
ATCP packets may not be exchanged until PPP has reached the
Network-Layer Protocol phase. An implementation should be
prepared to wait for Authentication and Link Quality Determination
to finish before timing out waiting for a Configure-Ack or other
response. It is suggested that an implementation give up only
after user intervention or a configurable amount of time.
PPPがNetwork-層のプロトコルフェーズに達するまで、ATCPパケットは交換されないかもしれません。 実装はAuthenticationとLink Quality Determinationが、以前タイミングが外でConfigure-Ackか他の応答を待ち終えるのを待つように準備されるべきです。 実装がユーザ介入か構成可能な時間の後にだけあきらめることが提案されます。
Configuration Option Types
設定オプションタイプ
ATCP has a distinct set of Configuration Options, which are
defined below.
ATCPには、Configuration Optionsの異なったセットがあります。(Configuration Optionsは以下で定義されます)。
2.1. Sending AppleTalk Datagrams
2.1. 送付AppleTalkデータグラム
Before any AppleTalk packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the AppleTalk Control Protocol must reach the Opened state.
どんなAppleTalkパケットも伝えられるかもしれない前に、PPPはNetwork-層のプロトコルフェーズに達しなければなりません、そして、AppleTalk ControlプロトコルはOpened状態に達しなければなりません。
Unless otherwise negotiated (via option 4), exactly one AppleTalk packet is encapsulated in the Information field of a PPP Data Link Layer frame where the Protocol field indicates type hex 0029 (AppleTalk).
別の方法で交渉されない場合(オプション4で)、ちょうど1つのAppleTalkパケットがプロトコル分野が、タイプが0029(AppleTalk)人に魔法をかけるのを示すPPP Data Link Layerフレームの情報分野でカプセルに入れられます。
Note that the negotiation of compression may imply the use of different encapsulation and hence different protocol fields. These different protocol fields imply packet types which are sub-protocols of the base AppleTalk NCP.
圧縮の交渉が異なったカプセル化としたがって、異なったプロトコル分野の使用を含意するかもしれないことに注意してください。 これらの異なったプロトコル分野はベースAppleTalk NCPのサブプロトコルであるパケットタイプを含意します。
An encapsulated AppleTalk packet begins with an extended DDP (Datagram Delivery Protocol) header -- also known as a Long DDP header. The maximum length of a DDP datagram is 599 octets.
カプセル化されたAppleTalkパケットは拡張DDP(データグラムDeliveryプロトコル)ヘッダーと共に始まります--また、Long DDPヘッダーとして、知られています。 DDPデータグラムの最大の長さは599の八重奏です。
Since there is no standard method for fragmenting and reassembling
断片化と組み立て直す標準方法が全くないので
Parker [Page 3] RFC 1378 PPP ATCP November 1992
パーカー[3ページ]RFC1378ppp ATCP1992年11月
AppleTalk datagrams, it is required that PPP links supporting AppleTalk allow at least 599 octets in the information field of a data link layer frame.
AppleTalkデータグラム、AppleTalkをサポートするPPPリンクがデータ・リンク層フレームの情報フィールドでの少なくとも599の八重奏を許容するのが必要です。
2.2. Half-Routers
2.2. 半分ルータ
One model for routers in [3] is two remote AppleTalk routers linked as "half-routers" without a Node ID or Network number assigned to either side of the link. When acting as half-routers, the only effect on transported packets is that the hop count is incremented when it is received over the link. Routing updates received over a half-router link should also increment the hop count of routing table updates.
[3]のルータのための1つのモデルがどちらかに割り当てられたNode IDもNetwork番号のない「半分ルータ」に面があるのでリンクされたリンクの2つのリモートAppleTalkルータです。 半分ルータとして機能するとき、輸送されたパケットへの唯一の効果はリンクの上にそれを受け取るとき、ホップカウントが増加しているということです。 また、半分ルータリンクの上に受けられたルート設定アップデートは経路指定テーブルアップデートのホップカウントを増加するべきです。
As part of normal operation, AppleTalk will send RTMP Routing updates every 10 seconds.
通常の操作の一部として、AppleTalkは10秒毎にルート設定アップデートをRTMPに送るでしょう。
3. ATCP Configuration Options
3. ATCP設定オプション
ATCP Configuration Options allow negotiation of desirable AppleTalk parameters. ATCP uses the same Configuration Option format defined for LCP [1], with a separate set of Options.
ATCP Configuration Optionsは望ましいAppleTalkパラメタの交渉を許します。 ATCPはLCP[1]のためにOptionsの別々のセットで定義された同じConfiguration Option書式を使用します。
The most up-to-date values of the ATCP Option Type field are specified in the most recent "Assigned Numbers" RFC [2]. Current values are assigned as follows:
ATCP Option Type分野の最も最新の値は最新の「規定番号」RFC[2]で指定されます。 現行価値は以下の通り割り当てられます:
1 AppleTalk-Address
1 AppleTalkアドレス
2 Routing-Protocol
2 ルーティング・プロトコル
3 Suppress-Broadcasts
3、放送を抑圧します。
4 AT-Compression-Protocol
大西洋標準時4の圧縮プロトコル
5 RESERVED
予約された5
6 Server-information
6 サーバ情報
7 Zone-information
7 ゾーン情報
8 Default-Router-Address
8 デフォルトルータアドレス
Parker [Page 4] RFC 1378 PPP ATCP November 1992
パーカー[4ページ]RFC1378ppp ATCP1992年11月
3.1. AppleTalk-Address
3.1. AppleTalkアドレス
Description
記述
This Configuration Option provides a way to negotiate the
AppleTalk network and node number to be used on the local end of
the link. It allows the sender of the Configure-Request to state
which AppleTalk-address is desired, or to request that the peer
provide the information. The peer can provide this information by
NAKing the option, and returning a valid AppleTalk-address.
このConfiguration Optionはリンクの地方の端で使用されるためにAppleTalkネットワークとノード番号を交渉する方法を提供します。 それで、Configure-要求の送付者をどのAppleTalkアドレスが望まれているかを述べるか、または同輩が情報を提供するよう要求します。 同輩は、NAKingによるこの情報にオプションを提供して、有効なAppleTalkアドレスを帰りに提供できます。
If negotiation about the remote AppleTalk-address is required, and
the peer did not provide the option in its Configure-Request, the
option SHOULD be appended to a Configure-Nak. The value of the
AppleTalk-address given must be acceptable as the remote
AppleTalk-address, or indicate a request that the peer provide the
information.
AppleTalkアドレスがリモートに関する交渉であるなら必要でした、そして、同輩はConfigure-要求におけるオプションを提供しませんでした、オプションSHOULD。Configure-Nakに追加します。 与えられたAppleTalkアドレスの値は、リモートAppleTalkアドレスとして許容できるか、または同輩が情報を提供するという要求を示さなければなりません。
By default, no AppleTalk address is assigned. A network or node
number specified as zero in a Configure-Request shall be
interpreted as requesting the remote end to specify a value via a
Configure-Nak. A network or node number specified as zero in a
Configure-Ack shall be interpreted as agreement that no value
exists.
デフォルトで、AppleTalkアドレスは全く割り当てられません。 Configure-Nakを通して値を指定するようリモートエンドに要求しながら、ゼロとしてConfigure-要求で指定されたネットワークかノード番号が解釈されるものとします。 Configure-Ackのゼロが値が全く存在していないという協定として解釈されるものとするので、ネットワークかノード番号が指定しました。
An implementation which requires that no AppleTalk addresses be
assigned (such as a intermediate system to intermediate system
"half-routing") MUST Configure-Reject all AppleTalk-Address
Configuration Options.
AppleTalkアドレスが全く割り当てられないのを必要とする実装(中間システム「半分ルーティング」への中間システムなどの)はすべてのAppleTalkアドレスConfiguration OptionsをConfigure拒絶しなければなりません。
An implementation which requires that AppleTalk addresses be
assigned to it (such as a end system) MUST fail configuration if
the remote side Configure-Rejects all AppleTalk-Address requests,
or fails to provide a valid value.
遠隔地側がすべてのAppleTalkアドレス要求をConfigure拒絶するか、または有効値を提供しないなら、AppleTalkアドレスがそれ(エンドシステムなどの)に割り当てられるのを必要とする実装は構成に失敗しなければなりません。
If this option is negotiated, the two sides MUST negotiate a
common AppleTalk network number and two unique Appletalk node
numbers. The network number MAY be zero but the Appletalk node
numbers MUST be non-zero. Values selected for network and node
numbers must adhere to the ranges defined in [3].
このオプションが交渉されるなら、2つの側が一般的なAppleTalkネットワーク番号と2つのユニークなAppletalkノード番号を交渉しなければなりません。 ネットワーク・ナンバーはゼロであるかもしれませんが、Appletalkノード番号は非ゼロであるに違いありません。 ネットワークのために選択された値とノード番号は[3]で定義された範囲を固く守らなければなりません。
The AppleTalk protocol, phase 2, defines the concept of "extended"
and "non-extended" networks. Extended networks can support a
large number (hundreds) of nodes, and requires multiple network
numbers and multiple zone names to be managed effectively. Non-
extended networks can only support a small number of devices, and
require only a single network number and zone name to be managed
effectively.
AppleTalkプロトコル(フェーズ2)は「広げられ」て「非広げられた」ネットワークの概念を定義します。 拡大ネットワークは、複数のネットワーク・ナンバーと複数のゾーン名が有効に管理されるのを多くがノードの(数百)であるとサポートすることができて、必要とします。 非拡大ネットワークは、ただ一つのネットワーク・ナンバーとゾーン名だけが有効に管理されるのを少ない数のデバイスを支えるだけであり、必要とすることができます。
Parker [Page 5] RFC 1378 PPP ATCP November 1992
パーカー[5ページ]RFC1378ppp ATCP1992年11月
If a PPP link transporting AppleTalk is assigned an AppleTalk
address, it must have the "non-extended" characteristics as
defined in [3].
AppleTalkアドレスがAppleTalkを輸送するPPPリンクに割り当てられるなら、それには、「非広げられた」特性が[3]で定義されるようになければなりません。
The format of the network and node data is defined to be the same
as the "AppleTalk address" in [3], chapter 3, "AppleTalk AARP
packet formats on Ethernet and token ring".
ネットワークとノードデータの書式は、[3]の「AppleTalkアドレス」、「イーサネットとトークンリングのAppleTalk AARPパケット・フォーマット」という第3章と同じになるように定義されます。
A summary of the AppleTalk-Address Configuration Option format is shown below. The fields are transmitted from left to right.
AppleTalkアドレスConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | AT-Net |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT-Net | AT-Node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 予約されます。| ネット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネット| ノード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
1
1
Length
長さ
6
6
Reserved
予約されます。
This octet is reserved and MUST be set to zero on transmission and
ignored on reception.
この八重奏を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。
AT-Net
ネット
The two octet AT-Net is the desired local AppleTalk network number
of the sender of the Configure-Request. This two octet quantity
represents a 16 bit unsigned number sent "network byte order"
(most significant octet first).
2八重奏AT-ネットはConfigure-要求の送付者の必要な地方のAppleTalkネットワーク番号です。 この2八重奏量が16ビットの符号のない数の送られた「ネットワークバイトオーダー」を表す、(最も重要な八重奏、1番目)
AT-Node
ノード
The one octet AT-Node is the desired local AppleTalk node ID of
the sender of the Configure-Request.
1つの八重奏AT-ノードがConfigure-要求の送付者の必要なローカルのAppleTalkノードIDです。
Parker [Page 6] RFC 1378 PPP ATCP November 1992
パーカー[6ページ]RFC1378ppp ATCP1992年11月
3.2. Routing-Protocol
3.2. ルーティング・プロトコル
Description
記述
This Configuration Option provides a way to negotiate the use of a
specific routing protocol. In particular, "half-routers" may want
to exchange routing information using a protocol optimized for the
PPP connection. By default, AppleTalk RTMP (Routing Table
Maintenance Protocol) routing information is sent over the PPP
connection.
このConfiguration Optionは特定のルーティング・プロトコルの使用を交渉する方法を提供します。 特に、「半分ルータ」は、PPP接続のために最適化されたプロトコルを使用することでルーティング情報を交換したがっているかもしれません。 デフォルトで、AppleTalk RTMP(ルート設定Table Maintenanceプロトコル)ルーティング情報をPPP接続の上に送ります。
By default, AppleTalk RTMP routing information is sent over the
PPP connection.
デフォルトで、AppleTalk RTMPルーティング情報をPPP接続の上に送ります。
A summary of the Routing-Protocol Configuration Option format is shown below. The fields are transmitted from left to right.
ルート設定プロトコルConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Routing-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| ルーティング・プロトコル| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Type
タイプ
2
2
Length
長さ
>= 4
>= 4
Routing-Protocol
ルーティング・プロトコル
The Routing-Protocol field is two octets and indicates the type of
Routing-Protocol desired. This two octet quantity represents a 16
bit number sent "network byte order" (most significant octet
first).
ルート設定プロトコル分野は、2つの八重奏であり、ルート設定プロトコルのタイプが望んでいたのを示します。 この2八重奏量が16ビットの数の送られた「ネットワークバイトオーダー」を表す、(最も重要な八重奏、1番目)
Negotiation of some routing protocols implies that you will
receive packet types which transport these protocols.
いくつかのルーティング・プロトコルの交渉は、あなたがこれらのプロトコルを輸送するパケットタイプを受けるのを含意します。
For example, negotiating AppleTalk AURP to exchange routing
information implies both sides will accept EDDP type packets,
since this is the transport type used by AURP.
例えば、ルーティング情報を交換するためにAppleTalk AURPを交渉するのは、両側がEDDPタイプパケットを受け入れるのを含意します、これがAURPによって使用された輸送タイプであることで。
Parker [Page 7] RFC 1378 PPP ATCP November 1992
パーカー[7ページ]RFC1378ppp ATCP1992年11月
Initial values are assigned as follows:
初期の値は以下の通り割り当てられます:
Value Protocol
値のプロトコル
0 No routing information exchange
1 AppleTalk RTMP is used to exchange routing information
2 AppleTalk AURP is used to exchange routing information
3 AppleTalk ABGP is used to exchange routing information
0 いいえルーティング情報交換1AppleTalk RTMPは、2AppleTalk AURPが3AppleTalk ABGPがルーティング情報を交換するのに使用されるというルーティング情報を交換するのに使用されるというルーティング情報を交換するのに使用されます。
Data
データ
The Data field is zero or more octets and contains additional data
as determined by the routing protocol indicated in the Routing-
Protocol field.
Data分野は、ルート設定プロトコル分野で示されたルーティング・プロトコルで決定するようにゼロか、より多くの八重奏であり、追加データを含んでいます。
None of the Routing-Protocol options defined here require
additional data.
ここで定義されたルート設定プロトコルオプションのいずれも追加データを必要としません。
3.3. Suppress-Broadcasts
3.3. 放送を抑圧します。
Description
記述
This Configuration Option provides a way to negotiate the
suppression of AppleTalk broadcast datagrams which might otherwise
use up limitted PPP bandwidth. This Configuration Option is used
to inform the remote end that no AppleTalk broadcast datagrams of
a given DDP type should be sent.
このConfiguration Optionはそうでなければlimitted PPP帯域幅を使いきるかもしれないAppleTalkブロードキャスト・データグラムの抑圧を交渉する方法を提供します。 このConfiguration Optionは、与えられたDDPのどんなAppleTalkブロードキャスト・データグラムも送られるべきであるのをタイプしないリモートエンドを知らせるのに使用されます。
This option is useful when negotiated by a single end system. It
allows the local end system to request that broadcast packets
generated on a remote network not be propagated across the PPP
link. In the case of a single end system connected to a large
network, this can be used to suppress regular NBP lookups
generated by other end systems on the remote network. This will
mean that protocols such as NBP can no longer be used to find
network entities on the local system, but since the option
configuration is asymmetric, it does not inhibit the local
system's ability to find network entities on the remote network.
シングルエンドのシステムによって交渉されると、このオプションは役に立ちます。 それで、ローカルのエンドシステムは、リモートネットワークで生成された放送パケットがPPPリンクの向こう側に伝播されないよう要求できます。 大きいネットワークに接続されたシングルエンドのシステムの場合では、リモートネットワークの他のエンドシステムによって生成された通常のNBPルックアップを抑圧するのにこれを使用できます。 これは、ローカルシステムでネットワーク実体を見つけるのにもうNBPなどのプロトコルを使用できないことを意味するでしょうが、オプション構成が非対称であるので、それはリモートネットワークでネットワーク実体を見つけるローカルシステムの能力を禁止しません。
By default, no AppleTalk broadcast datagrams are suppressed. Note
that this option may conflict with other options (such as Routing
Protocol). If so, the Suppress-Broadcasts option takes
precedence.
デフォルトで、AppleTalkブロードキャスト・データグラムは全く抑圧されません。 このオプションが別の選択肢(ルート設定プロトコルなどの)と衝突するかもしれないことに注意してください。 そうだとすれば、Suppress-放送オプションは優先します。
A summary of the Suppress-Broadcasts Configuration Option format is shown below. The fields are transmitted from left to right.
Suppress-放送Configuration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
Parker [Page 8] RFC 1378 PPP ATCP November 1992
パーカー[8ページ]RFC1378ppp ATCP1992年11月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | DDP-Type 1 | DDP-Type 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| etc...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| DDPタイプ1| DDPタイプ2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | など。 +-+-+-+-+
Type
タイプ
3
3
Length
長さ
>= 2
>= 2
DDP-Types
DDPタイプ
A vector of one or more single octet DDP type values, each of
which are to be suppressed if sent to the broadcast address.
DDPタイプがそれぞれ評価する1つ以上のただ一つの八重奏のそれのベクトルは放送演説に送るなら抑圧することです。
If no data is present (the length = 2), all broadcast packets are
to be suppressed, regardless of DDP type.
どんなデータも存在していないなら(長さ=2)、すべての放送パケットがDDPタイプにかかわらず抑圧されることになっています。
3.4. AT-Compression-Protocol
3.4. 圧縮プロトコルです。
Description
記述
This Configuration Option provides a way to negotiate the use of a
specific compression protocol. By default, compression is not
enabled.
このConfiguration Optionは特定の圧縮プロトコルの使用を交渉する方法を提供します。 デフォルトで、圧縮は可能にされません。
A summary of the AT-Compression-Protocol Configuration Option format is shown below. The fields are transmitted from left to right.
AT圧縮プロトコルConfiguration Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | AT-Compression-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 圧縮プロトコルです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ… +-+-+-+-+
Type
タイプ
4
4
Parker [Page 9] RFC 1378 PPP ATCP November 1992
パーカー[9ページ]RFC1378ppp ATCP1992年11月
Length
長さ
>= 4
>= 4
AT-Compression-Protocol
圧縮プロトコルです。
The AT-Compression-Protocol field is two octets and indicates the
compression protocol desired. Values for this field are always
the same as the PPP Data Link Layer Protocol field values for that
same compression protocol.
AT圧縮プロトコル分野は、2つの八重奏であり、圧縮プロトコルが望んでいたのを示します。 この分野への値はその同じ圧縮のためのPPP Data Link Layerプロトコル分野値が議定書を作るのといつも同じです。
The most up-to-date values of the AT-Compression-Protocol field
are specified in the most recent "Assigned Numbers" RFC [2].
Current values are assigned as follows:
AT圧縮プロトコル分野の最も最新の値は最新の「規定番号」RFC[2]で指定されます。 現行価値は以下の通り割り当てられます:
Value (in hex) Protocol
値(十六進法における)のプロトコル
none defined
定義されなかったなにも
Data
データ
The Data field is zero or more octets and contains additional data
as determined by the particular compression protocol.
Data分野は、ゼロか、より多くの八重奏であり、特定の圧縮プロトコルで決定するように追加データを含んでいます。
3.5. Server-information
3.5. サーバ情報
Description
記述
This Configuration Option provides a way to obtain information
about the communications server providing the remote side of the
PPP connection.
このConfiguration OptionはPPP接続の遠隔地側を備えながらコミュニケーションサーバの情報を得る方法を提供します。
The nature of this option is advisory only. It is provided as a
means of improving an end system's ability to provide a simple
user interface.
このオプションの本質は状況報告専用です。 簡単なユーザーインタフェースを提供するエンドシステムの性能を改良する手段としてそれを提供します。
A summary of the Server-Information Option format is shown below. The fields are transmitted from left to right.
Server-情報Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
Parker [Page 10] RFC 1378 PPP ATCP November 1992
パーカー[10ページ]RFC1378ppp ATCP1992年11月
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Server-class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server-implementation-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server-name ...
+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サーバクラス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバ実装イド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サーバ名… +-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
6
6
Length
長さ
>= 8
>= 8
Server-class
サーバクラス
The Server-class field is two octets and indicates the class of
the communication server providing the remote end of the PPP
connection.
Server-類体は、2つの八重奏であり、PPP接続のリモートエンドを提供するコミュニケーションサーバーのクラスを示します。
Initial values are assigned as follows:
初期の値は以下の通り割り当てられます:
Value Class
値のクラス
1 AppleTalk PPP Dial-in server.
1つのAppleTalk中のPPP Dialサーバ。
The server-implementation-id is a four byte version
id, with the first byte defined as the major
version number (1-255) and the second byte defined
as the minor version number (1-255).
サーバ実装イドは4バイトのバージョンイドです、最初のバイトがメジャーバージョン番号(1-255)と定義されて、2番目のバイトがマイナーバージョン番号(1-255)と定義されている状態で。
The third and fourth bytes are undefined and should
be zero.
3番目と4番目のバイトは、未定義であり、ゼロであるべきです。
2 Generic AppleTalk PPP implementation.
2ジェネリックAppleTalk PPP実装。
The server-implementation-id is undefined and
vendor specific.
サーバ実装イドは、未定義であって、ベンダー特有です。
3 Both dial-in server and router
3 ダイヤルインサーバとルータの両方
Parker [Page 11] RFC 1378 PPP ATCP November 1992
パーカー[11ページ]RFC1378ppp ATCP1992年11月
Server-implementation-id
サーバ実装イド
The Server-implementation-id field is four octets and indicates
the version of the communication server providing the remote end
of the PPP connection.
Server実装イド分野は、4つの八重奏であり、コミュニケーションサーバーがPPP接続のリモートエンドを提供するバージョンを示します。
Server-name
サーバー名
This optional field contains the "AppleTalk ASCII" name of the
server. The character codes used in "AppleTalk ASCII" are defined
in [3], appendix D, "Character codes". The length of the name is
bounded by the option length.
この任意の分野はサーバの「AppleTalk ASCII」名を含んでいます。[3]、付録D、「キャラクターコード」で「AppleTalk ASCII」に使用されるキャラクタコードは定義されます。 オプションの長さに従って、存在という名前の長さはバウンドしました。
3.6. Zone-Information
3.6. ゾーン情報
Description
記述
This Configuration Option provides a way to obtain information
about the AppleTalk zone used for the PPP connection.
このConfiguration OptionはPPP接続に使用されるAppleTalkゾーンの情報を得る方法を提供します。
The nature of this option is advisory only. It is provided as a
means of improving the end system's ability to provide a simple
user interface.
このオプションの本質は状況報告専用です。 簡単なユーザーインタフェースを提供するエンドシステムの性能を改良する手段としてそれを提供します。
A summary of the Zone-Information Option format is shown below. The fields are transmitted from left to right.
Zone-情報Option形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Zone-name... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| ゾーン名… | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
7
7
Length
長さ
>= 3
>= 3
Zone-name
ゾーン名
This field contains the "AppleTalk ASCII" zone name in which the
server resides. The character codes used in "AppleTalk ASCII" are
defined in [3], appendix D, "Character codes". The length of the
name is bounded by the option length.
この分野はサーバがある「AppleTalk ASCII」ゾーン名を含んでいます。 [3]、付録D、「キャラクターコード」で「AppleTalk ASCII」に使用されるキャラクタコードは定義されます。 オプションの長さに従って、存在という名前の長さはバウンドしました。
Parker [Page 12] RFC 1378 PPP ATCP November 1992
パーカー[12ページ]RFC1378ppp ATCP1992年11月
3.7. Default-Router-Address
3.7. デフォルトルータアドレス
Description
記述
This Configuration Option provides a way to obtain information
about a "default" Appletalk router which may be used to obtain
network information such as zone names. It is provided as a means
of obtaining the address of a router in the case both sides of the
link are end systems.
このConfiguration Optionはゾーンが命名するネットワーク情報を得るのに使用されるかもしれない「デフォルト」Appletalkルータの情報を得る方法を提供します。 場合でルータのアドレスを得る手段として、リンクの両側がエンドシステムであるかどうかということです。
Any AppleTalk RTMP packets received should supercede information
negotiated in this option.
RTMPパケットが受けたどんなAppleTalkもこのオプションで交渉されたsupercede情報がそうするべきです。
By default, no default router is present.
デフォルトで、どんなデフォルトルータも存在していません。
A summary of the Default-Router-Address Option format is shown below. The fields are transmitted from left to right.
DefaultルータアドレスOption形式の概要は以下に示されます。 野原は左から右まで伝えられます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | AT-Net |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT-Net | AT-Node |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 予約されます。| ネット| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ネット| ノード| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
8
8
Length
長さ
6
6
Reserved
予約されます。
This octet is reserved and MUST be set to zero on transmission and
ignored on reception.
この八重奏を予約されていて、トランスミッションのときにゼロに設定されて、レセプションで無視しなければなりません。
AT-Net
ネット
The two octet AT-Net is the AppleTalk network number of the
default router. This two octet quantity represents a 16 bit
unsigned number sent in "network byte order" (most significant
octet first).
2八重奏AT-ネットはデフォルトルータのAppleTalkネットワーク番号です。 量が16の噛み付いている符号のない数に表すこの2八重奏が「ネットワークバイトオーダー」を送った、(最も重要な八重奏、1番目)
Parker [Page 13] RFC 1378 PPP ATCP November 1992
パーカー[13ページ]RFC1378ppp ATCP1992年11月
AT-Node
ノード
The one octet AT-Node is the AppleTalk node ID of the default
router.
1つの八重奏AT-ノードがデフォルトルータのAppleTalkノードIDです。
A. ATCP Recommended Options
A。 ATCPのお勧めのオプション
The ATCP is designed to support three different modes of operation. Each mode places constraints on the configuration options used and the values negotiated.
ATCPは、3つの異なった運転モードをサポートするように設計されています。 各モードはオプションが使用した構成と交渉された値に規制を置きます。
The options for server information, zone information and default router address are "informational" options provided by one end of the connection and are not intended to be negotiated. These options are provided to support a higher level of service to dial-in end systems.
サーバ情報、ゾーン情報、およびデフォルトルータアドレスのためのオプションは、接続の片端によって提供された「情報」のオプションであり、交渉されることを意図しません。 ダイヤルインのエンドシステムに対する、より高いレベルのサービスをサポートするためにこれらのオプションを提供します。
The options which SHOULD be negotiated in each case are outlined below. Any option not listed may be rejected.
交渉されたコネがケースが概説されているそれぞれであったならどのSHOULDにゆだねるか。 記載されなかった少しのオプションも拒絶されるかもしれません。
End System to Intermediate System - "dial-in"
中間システム--「ダイヤルイン」へのエンドシステム
This mode of operation is intended to support end system dial-in.
この運転モードがダイヤルインでエンドシステムをサポートすることを意図します。
1 AppleTalk-Address (required)
2 Routing-Protocol (required, no routing protocol)
3 Suppress-Broadcasts (optional)
4 AT-Compression-Protocol (optional)
6 Server-information (optional, request from end system)
1 AppleTalkアドレス(必要である)2ルート設定プロトコル(必要で、掘っていないプロトコル)の3つのSuppress-放送(任意の)の大西洋標準時4の圧縮プロトコル(任意の)6Server-情報(任意であることで、終わりからシステムを要求してください)
Parker [Page 14] RFC 1378 PPP ATCP November 1992
パーカー[14ページ]RFC1378ppp ATCP1992年11月
Intermediate system to Intermediate system - with network number
ネットワーク・ナンバーがあるIntermediateシステムへの中間システム
This mode of operation is intended to support WAN-to-WAN, i.e., router to router, connections where the link is configured with a network number.
リンクがネットワーク・ナンバーによって構成されるところでこの運転モードがWANからWAN、すなわち、ルータをルータ、接続にサポートすることを意図します。
1 AppleTalk-Address (required, nets must be zero or equal)
2 Routing-Protocol (optional)
3 Suppress-Broadcasts (optional)
1 AppleTalkアドレス(必要であることで、ネットは、ゼロか同輩であるに違いない)2ルート設定プロトコル(任意の)の3つのSuppress-放送(任意)です。
Intermediate system to Intermediate system - without network number
ネットワーク・ナンバーのないIntermediateシステムへの中間システム
This mode of operation is intended to support WAN-to-WAN, i.e., router to router, connections where the link is not configured with a network number. Routers in this mode are referred to as "half- routers" in [3].
リンクがネットワーク・ナンバーによって構成されないところでこの運転モードがWANからWAN、すなわち、ルータをルータ、接続にサポートすることを意図します。 このモードによるルータは[3]に「半分ルータ」と呼ばれます。
1 AppleTalk-Address (optional, nets & nodes MUST be zero)
2 Routing-Protocol (optional)
3 Suppress-Broadcasts (optional, suppress all broadcasts)
1 AppleTalkアドレス(任意であることで、ネットとノードはゼロであるに違いない)2ルート設定プロトコル(任意の)の3つのSuppress-放送(任意であることで、すべての放送を抑圧してください)
References
参照
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
Daydreamer, May 1992.
w.[1] シンプソン、「二地点間プロトコル(ppp)」(RFC1331、空想家)は1992がそうするかもしれません。
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[2] USC/情報科学が1992年7月に設けるレイノルズ、J.、およびJ.ポステル、「規定番号」、STD2、RFC1340。
[3] Sidhu G., Andrews, R., and A. Oppenheimer, "Inside AppleTalk,
Second Edition", Addison-Wesley Publishing Company, Inc., May
1990.
[3] Sidhu G.(アンドリュース、R.とA.オッペンハイマー、「AppleTalk、第2版」アディソン-ウエスリー出版社Inc.)は1990がそうするかもしれません。
Acknowledgments
承認
Some of the text in this document is taken from previous documents produced by the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF).
テキストのいくつかがPointからポイントへのプロトコルインターネット・エンジニアリング・タスク・フォース作業部会(IETF)によって製作された前のドキュメントから本書では抜粋されます。
This document is derivative of drafts written by the following people. Many thanks for their work, and for taking an initial stab at the protocol:
このドキュメントは以下の人々によって書かれた草稿で派生しています。 彼らの仕事と、プロトコルで初期の一刺しをかけてくださってありがとうございます:
Steve Senum (sjs@network.com), Network Systems Corporation Jim Muchow (muchow@anubis.network.com), Network Systems Corporation Frank Slaughter (fgs@Shiva.COM), Shiva Corporation
スティーブSenum( sjs@network.com )、ネットワーク・システム社のジムMuchow( muchow@anubis.network.com )、ネットワーク・システム社のフランクの虐殺( fgs@Shiva.COM )、シバ神社
Parker [Page 15] RFC 1378 PPP ATCP November 1992
パーカー[15ページ]RFC1378ppp ATCP1992年11月
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Chair's Address
議長のアドレス
The working groups can be contacted via the current chairs:
現在のいすを通してワーキンググループに連絡できます:
Brian Lloyd Lloyd & Associates 3420 Sudbury Road Cameron Park, California 95682
ブライアン・ロイド・ロイドと3420年のサドベリー道路キャメロン公園、仲間カリフォルニア 95682
Phone: (916) 676-1147 EMail: brian@lloyd.com
以下に電話をしてください。 (916) 676-1147 メールしてください: brian@lloyd.com
John Veizades Apple Computer, Inc. 20525 Mariani Avenue Cupertino, CA 95014
ジョンVeizadesアップル・コンピューターInc.20525マリアニ・Avenueカルパチーノ、カリフォルニア 95014
Phone: (408) 996-1010 EMail: veizades@apple.com
以下に電話をしてください。 (408) 996-1010 メールしてください: veizades@apple.com
Author's Address
作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
Brad Parker Cayman Systems, Inc. 26 Landsdowne Street Cambridge, Ma 02139
ブラッドレプケイマンシステムInc.26Landsdowne通りケンブリッジ、マ02139
EMail: brad@cayman.com
メール: brad@cayman.com
Parker [Page 16]
パーカー[16ページ]
一覧
スポンサーリンク
