RFC3825 日本語訳
3825 Dynamic Host Configuration Protocol Option for Coordinate-basedLocation Configuration Information. J. Polk, J. Schnizlein, M.Linsner. July 2004. (Format: TXT=31715 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Polk
Request for Comments: 3825 J. Schnizlein
Category: Standards Track M. Linsner
Cisco Systems
July 2004
コメントを求めるワーキンググループJ.ポークの要求をネットワークでつないでください: 3825年のJ.Schnizleinカテゴリ: 標準化過程M.Linsnerシスコシステムズ2004年7月
Dynamic Host Configuration Protocol Option for
Coordinate-based Location Configuration Information
座標ベースの位置の設定情報のためのDynamic Host Configuration Protocolオプション
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
This document specifies a Dynamic Host Configuration Protocol Option for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes latitude, longitude, and altitude, with resolution indicators for each. The reference datum for these values is also included.
このドキュメントはクライアントの座標ベースの地理的な位置にDynamic Host Configuration Protocol Optionを指定します。 Location Configuration情報(LCI)はそれぞれのための解決インディケータがある緯度、経度、および高度を含んでいます。 また、これらの値のための基準面は含まれています。
Polk, et al. Standards Track [Page 1] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Rationale . . . . . . . . . . . . . . . . . . . . . . . 4
2. Location Configuration Information (LCI) Elements. . . . . . . 4
2.1. Elements of the Location Configuration Information . . . 5
3. Security Considerations. . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix Calculations of Imprecision possible with the DHC LCI . . 10
A.1. LCI of "White House" (Example 1) . . . . . . . . . . . . 10
A.2. LCI of "Sears Tower" (Example 2) . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . 13
6.2. Informational References . . . . . . . . . . . . . . . . 14
7. Author Information . . . . . . . . . . . . . . . . . . . . . . 14
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 コンベンション. . . . . . . . . . . . . . . . . . . . . . 3 1.2。 動機. . . . . . . . . . . . . . . . . . . . . . . 3 1.3。 原理. . . . . . . . . . . . . . . . . . . . . . . 4 2。 位置の設定情報(LCI)Elements。 . . . . . . 4 2.1. 位置の設定情報. . . 5 3のElements。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 8 4. IANA問題。 . . . . . . . . . . . . . . . . . . . . . 8 5. DHC LCI. . 10A.1で可能なImprecisionの承認. . . . . . . . . . . . . . . . . . . . . . . 9Appendix Calculations。 「ホワイトハウス」(例1).10A.2のLCI。 「シアーズタワー」(例2).126のLCI。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1。 引用規格. . . . . . . . . . . . . . . . . . 13 6.2。 情報の参照. . . . . . . . . . . . . . . . 14 7。 情報. . . . . . . . . . . . . . . . . . . . . . 14 8を書いてください。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 15
1. Introduction
1. 序論
This document specifies a Dynamic Host Configuration Protocol [1] Option for the coordinate-based geographic location of the client, to be provided by the server.
このドキュメントは、サーバで提供するためにクライアントの座標ベースの地理的な位置のためのDynamic Host Configuration Protocol[1]オプションを指定します。
The DHCP server is assumed to have determined the location from the Circuit-ID Relay Agent Information Option (RAIO) defined (as SubOpt 1) in [2]. In order to translate the circuit (switch port identifier) into a location, the DHCP server is assumed to have access to a service that maps from circuit-ID to the location at which the circuit connected to that port terminates in the building, for example, the location of the wall jack.
DHCPサーバが[2]で定義された(SubOpt1として)Circuit-ID Relayエージェント情報Option(RAIO)から位置を決定したと思われます。 サーキット(スイッチポート識別子)を位置に翻訳するために、DHCPサーバがそれがサーキットIDからそのポートにつなげられたサーキットが例えば、ビルで壁ジャッキの位置決めを終える位置まで写像するサービスに近づく手段を持っていると思われます。
An important feature of this specification is that after the relevant DHC exchanges have taken place, the location information is stored on the end device rather than somewhere else, where retrieving it might be difficult in practice.
この仕様の重要な特徴は関連DHC交換が起こった後に位置情報が他のどこかよりむしろ端末装置に格納されるということです。(そこでは、それを検索するのが実際には難しいかもしれません)。
Another important feature of this LCI is its inclusion of a resolution parameter for each of the dimensions of location. Because this resolution parameter need not apply to all dimensions equally, a resolution value is included for each of the 3 location elements.
このLCIの別の重要な特徴はそのそれぞれの位置の寸法のための解決パラメタの包含です。 この解決パラメタが等しくすべての寸法に適用される必要はないので、解決値はそれぞれの3つの位置の要素のために含まれています。
Resolution does not define Geographic Privacy policy.
決議はGeographic Privacy方針を定義しません。
Polk, et al. Standards Track [Page 2] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[2ページ]。
The resulting location information using this resolution method is a small fixed length Configuration Information that can be easily carried in protocols, such as DHCP, which have limited packet size because this LCI is only 18 bytes long.
この解決方法を使用する結果として起こる位置情報はプロトコルで容易に運ぶことができる、小さい固定長Configuration情報です、DHCPなどのように。(このLCIが18バイト長にすぎないので、DHCPはパケットサイズを制限しました)。
Finally, the appendix of this document provides some arithmetic examples of the implication of different resolution values on the La/Lo/Alt.
最終的に、このドキュメントの付録はLa/最低気温/Altで異なった解決値の含意のいくつかの算数の例を提供します。
1.1. Conventions used in this document
1.1. 本書では使用されるコンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[3]で説明されるように本書では解釈されることであるべきですか?
1.2. Motivation
1.2. 動機
As applications such as IP Telephony are replacing conventional telephony, users are expecting the same (or greater) level of services with the new technology. One service offered by conventional telephony that is missing in any standardized fashion within IP Telephony is for a user to be automatically located by emergency responders, in a timely fashion, when the user summons help (by dialing 911 in North America, for example). Unless strict administrative rules are followed, the mobility of a wired Ethernet device within a campus negates any opportunity for an emergency responder to locate the device with any degree of expediency. Users do not want to give up the mobility IP Telephony offers. Informing the host device of its geo-location at host configuration time will allow the device to utilize this geo-location information to inform others of its current geo-location, if the user and/or application so desires.
IP Telephonyなどのアプリケーションが従来の電話に取って代わっているとき、ユーザは新技術がある同じで(よりすばらしい)のレベルのサービスを予想しています。 IP Telephonyの中のどんな標準化されたファッションでもなくなった従来の電話によって提供された1つのサービスはユーザが緊急要員によって自動的に見つけられることです、直ちに、ユーザ召喚が助けると(例えば北アメリカで911にダイヤルすることによって)。 厳しい管理規則が従われていない場合、キャンパスの中のワイヤードなイーサネット装置の移動性はどんな程度の便宜でも緊急要員が装置の場所を見つけるどんな機会も否定します。 ユーザは移動性IP Telephony申し出をやめたがっていません。 装置は現在のgeo-位置について他のものに知らせるのにホスト構成時間にgeo-位置のホスト装置を知らせるのにこのgeo-位置情報を利用できるでしょう、ユーザ、そして/または、アプリケーションがそう望んでいるなら。
The goal of this option is to enable a wired Ethernet host to obtain its location, which it could provide to an emergency responder, as one example.
このオプションの目標はワイヤードなイーサネットホストがそれが緊急要員に提供できた位置を得るのを可能にすることです、1つの例として。
Wireless hosts can utilize this option to gain knowledge of the location of the radio access point used during host configuration, but would need some more exotic mechanisms, maybe GPS, or maybe a future DHCP option, which includes a list of geo-locations like that defined here, containing the locations of the radio access points that are close to the client.
無線のホストはそれ以上のエキゾチックなメカニズム、多分GPS、または多分ここで定義されたそのようなgeo-位置のリストを含んでいる今後のDHCPオプションを必要とするだろうというのを除いて、ホスト構成の間に使用されるラジオアクセスポイントの位置に関する知識を獲得するのにこのオプションを利用できます、クライアントの近くにあるラジオアクセスポイントの位置を含んでいて。
Polk, et al. Standards Track [Page 3] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[3ページ]。
1.3. Rationale
1.3. 原理
Within the LCI described here, Latitude and Longitude are represented in fixed-point 2s-complement binary degrees, for the economy of a smaller option size compared to a string encoding of digits in [7]. The integer parts of these fields are 9 bits long to accommodate +/- 180 degrees. The fractional part is 25 bits long, better than the precision of 7 decimal digits. The length of each field is 40 bits, 34 of which is the sum of the integer (9) and fractional (25) bits, plus 6 bits of resolution.
ここで説明されたLCIの中では、LatitudeとLongitudeは定点の2補数の2進の学位で表されます、[7]でケタをコード化するストリングにたとえられたより小さいオプションサイズの経済で。 これらの分野の整数部は、+/- 180度を収容するために長さ9ビットです。 断片的な部分は、7つの10進数字の精度より25ビット長くて、良いです。 それぞれの分野の長さは40ビットです。(34のそれが、整数(9)と断片的な(25)ビットの合計と、そのビットのための解決の6ビットです)。
Altitude is determined by the Altitude Type (AT) indicated by the AT field, which is 4 bits long. Two Altitude Types are defined here, meters (code=1) and floors (code=2), both of which are 2s-complement fixed-point with 22 bits of integer part and 8 bits of fractional part. Additional Altitude Types MAY be assigned by IANA. The "floors" Altitude Type is provided because altitude in meters may not be known within a building, and a floor indication may be more useful.
高度は長さ4ビットであるAT分野によって示されたAltitude Type(AT)によって決定されます。 2Altitude Typesがここで定義されて、メーターは、(コード=1)と床(コード=2)です、断片的のビットがどれがあるかに関する整数部の22ビットがある2補数の定点と8を離れさせる両方。 追加Altitude TypesはIANAによって割り当てられるかもしれません。 メーターの高度がビルの中で知られていないかもしれなくて、床の指示が、より役に立つかもしれないので、「床」Altitude Typeを提供します。
GPS systems today can use WGS84 for horizontal and vertical datums; [6] defines WGS84 as a three-dimensional datum. For other datum values that do not include a vertical component, both the horizontal and vertical datum of reference will be specified in the IANA record.
今日のGPSシステムは水平で垂直なdatumsにWGS84を使用できます。 [6]は立体的なデータとWGS84を定義します。 垂直成分、参照の水平で垂直なデータがそうする両方を含んでいない他のデータ値に、IANA記録で指定されてください。
Each of these 3 elements begins with an accuracy sub-field of 6 bits, indicating the number of bits of resolution. This resolution sub- field accommodates the desire to easily adjust the precision of a reported location. Contents beyond the claimed resolution MAY be randomized to obscure greater precision that might be available.
解決のビットの数を示して、それぞれのこれらの3つの要素が6ビットの精度サブ分野で始まります。 この解決サブ分野は容易に報告された位置の精度を調整する願望を収容します。 要求された解決を超えたコンテンツは、利用可能であるかもしれないより大きい精度をあいまいにするためにランダマイズされるかもしれません。
2. DHC Location Configuration Information Elements
2. DHC位置の設定情報Elements
DHCP is a binary Protocol; using protocols of LCI are likely to be text based. Since most coordinate systems translate easily between binary-based and text-based location output (even emergency services within the US), translation/conversion is a non-issue with DHCP's binary format.
DHCPは2進のプロトコルです。 LCIの使用プロトコルは基づくテキストである傾向があります。 ほとんどの座標系がバイナリーベースの、そして、テキストベースの位置の出力(米国の中の緊急サービスさえ)の間で容易に翻訳されるので、翻訳/変換はDHCPのバイナリフォーマットのどうでもいい問題です。
This binary format provides a fortunate benefit in a mechanism for making a true/correct location coordinate imprecise. It further provides the capability to have this binary representation be deterministically imprecise.
このバイナリフォーマットは、本当の、または、正しい位置を不正確な状態で調整させるために幸いな利益をメカニズムに供給します。 それはさらに不正確な状態でこの2進法表示が決定論的にそうであることを持つ能力を提供します。
Polk, et al. Standards Track [Page 4] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[4ページ]。
The LCI format is as follows:
LCI形式は以下の通りです:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code 123 | 16 | LaRes | Latitude +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Latitude (cont'd) | LoRes | +
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Longitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT | AltRes | Altitude |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Alt (cont'd) | Datum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | コード123| 16 | LaRes| 緯度++++++++++++++++++++++++++++++++++| 緯度(contはそうするでしょう)| 口碑| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 経度| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | at| AltRes| 高度| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Alt(contはそうするでしょう)| データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.1. Elements of the Location Configuration Information
2.1. 位置の設定情報のElements
Code 123: The code for this DHCP option.
コード123: このDHCPオプションのためのコード。
16: The length of this option is 16 bytes.
16: このオプションの長さは16バイトです。
LaRes: Latitude resolution. 6 bits indicating the number of
valid bits in the fixed-point value of Latitude.
LaRes: 緯度解決。 Latitudeの定点値における、有効なビットの数を示す6ビット。
This value is the number of high-order Latitude bits that should be considered valid. Any bits entered to the right of this limit should not be considered valid and might be purposely false, or zeroed by the sender.
この値は有効であると考えられるべきである高位Latitudeビットの数です。 有効であると考えるべきでなくて、わざわざ誤っていて、送付者はこの限界の右に入れられたどんなビットのゼロにも合うかもしれません。
The examples in the appendix illustrate that a smaller value in the resolution field increases the area within which the device is located.
付録の例は、解決分野の、より小さい値が装置が位置している領域を増加させるのを例証します。
LaRes does not define Geographic Privacy policy.
LaResはGeographic Privacy方針を定義しません。
Values above decimal 34 are undefined and reserved.
10進34を超えた値は、未定義であって、予約されています。
Latitude: a 34 bit fixed point value consisting of 9 bits of integer
and 25 bits of fraction. Latitude SHOULD be normalized to
within +/- 90 degrees. Positive numbers are north of the
equator and negative numbers are south of the equator.
緯度: 断片の整数と25ビットの9ビットから成る34ビットの定点値。 緯度SHOULD、+/- 90度に正常にされてください。 正の数が赤道の北にあります、そして、負数が赤道の南にあります。
A value of 2 in the LaRes field indicates a precision of no greater than 1/6th that of the globe (in the first example of the appendix). A value of 34 in the LaRes field indicates a precision of about 3.11 mm in Latitude at the equator.
LaRes分野の2の値は1以下/6番目の精度を示します。地球(付録の最初の例の)のもの。 LaRes分野の34の値は赤道のLatitudeのおよそ3.11mmの精度を示します。
Polk, et al. Standards Track [Page 5] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[5ページ]。
LoRes: Longitude resolution. 6 bits indicating the number of
valid bits in the fixed-point value of Longitude.
口碑: 経度解決。 Longitudeの定点値における、有効なビットの数を示す6ビット。
This value is the number of high-order Longitude bits that should be considered valid. Any bits entered to the right of this limit should not be considered valid and might be purposely false, or zeroed by the sender.
この値は有効であると考えられるべきである高位Longitudeビットの数です。 有効であると考えるべきでなくて、わざわざ誤っていて、送付者はこの限界の右に入れられたどんなビットのゼロにも合うかもしれません。
LoRes does not define Geographic Privacy policy.
LoResはGeographic Privacy方針を定義しません。
Values above decimal 34 are undefined and reserved.
10進34を超えた値は、未定義であって、予約されています。
Longitude: a 34 bit fixed point value consisting of 9 bits of integer
and 25 bits of fraction. Longitude SHOULD be normalized
to within +/- 180 degrees. Positive values are East of
the prime meridian and negative (2s complement) numbers
are West of the prime meridian.
経度: 断片の整数と25ビットの9ビットから成る34ビットの定点値。 経度SHOULD、+/- 180度に正常にされてください。 正の数はグリニッジ子午線で東です、そして、負(2補数)の数はグリニッジ子午線で西です。
A value of 2 in the LoRes field indicates precision of no greater than 1/6th that of the globe (see first example of the appendix). A value of 34 in the LoRes field indicates a precision of about 2.42 mm in longitude (at the equator). Because lines of longitude converge at the poles, the distance is smaller (better precision) for locations away from the equator.
LoRes分野の2の値は1以下/6番目の精度を示します。地球(付録の最初の例を見る)のもの。 LoRes分野の34の値は経度(赤道の)のおよそ2.42mmの精度を示します。 経度の線がポールで一点に集まるので、赤道から遠くの位置には、距離が、よりわずかです(より良い精度)。
Altitude: A 30 bit value defined by the AT field
高度: AT分野によって定義された30ビットの値
AltRes: Altitude resolution. 6 bits indicating the number of
valid bits in the altitude. Values above 30 (decimal) are
undefined and reserved.
AltRes: 高度解決。 高度の有効なビットの数を示す6ビット。 30(10進)を超えた値は、未定義であって、予約されています。
AltRes does not define Geographic Privacy policy.
AltResはGeographic Privacy方針を定義しません。
AT: Altitude Type for altitude. Codes defined are:
: 高度への高度Type。 定義されたコードは以下の通りです。
1: Meters - in 2s-complement fixed-point 22-bit integer part with 8-
bit fraction
1: Meters--8の噛み付いている断片がある2補数の定点22ビットの整数部で
If AT = 1, an AltRes value 0.0 would indicate unknown altitude. The most precise Altitude would have an AltRes value of 30. Many values of AltRes would obscure any variation due to vertical datum differences.
AT=1であるなら、AltRes値0.0は未知の高度を示すでしょう。 最も正確なAltitudeには、30のAltRes値があるでしょう。 AltResの多くの値が垂直なデータ差によるどんな変化もあいまいにするでしょう。
2: Floors - in 2s-complement fixed-point 22-bit integer part with
8-bit fraction
2: 床--8ビットの断片がある2補数の定点22ビットの整数部で
Polk, et al. Standards Track [Page 6] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[6ページ]。
AT = 2 for Floors enables representing altitude in a form more relevant in buildings which have different floor-to-floor dimensions. An altitude coded as AT = 2, AltRes = 30, and Altitude = 0.0 is meaningful even outside a building, and represents ground level at the given latitude and longitude. Inside a building, 0.0 represents the floor level associated with ground level at the main entrance. This document defines a number; one must arrive at the number by counting floors from the floor defined to be 0.0.
FloorsのためのAT=2は床から床への異なった寸法を持っているビルでは、より関連しているフォームで表す高度を可能にします。 ATが2、AltRes=30、およびAltitude=0.0と等しいのでコード化された高度は、ビルの外でさえ重要であり、与えられた緯度と経度に地表面を表します。 ビルの中では、0.0は正面玄関の地表面に関連している床のレベルを表します。 このドキュメントは数を定義します。 0.0になるように定義された床から床を数えることによって、数に達しなければなりません。
The values represented by this AT will be of local significance. Since buildings and floors can vary due to lack of common control, the values chosen to represent the characteristics of an individual building will be derived and agreed upon by the operator of the building and the intended users of the data. Attempting to standardize this type of function is beyond the scope this document.
このATによって表された値はローカルの意味のものになるでしょう。 ビルと床が不足のため異なることができるので、共通制御機構、選ばれた値では、ビルのオペレータとデータの対象とする使用者は個々のビルの特性を表すのを、引き出されて、同意するでしょう。 このタイプの関数を標準化するのを試みるのは、範囲を超えてこのドキュメントです。
Sub-floors can be represented by non-integer values. Example: a mezzanine between floor 1 and floor 2 could be represented as a value = 1.1. Example: (2) mezzanines between floor 4 and floor 5 could be represented as values = 4.1 and 4.2 respectively.
非整数値で下張り床を表すことができます。 例: 値が1.1と等しいときに、床1と床2の間の中二階を表すことができました。 例: (2) 値がそれぞれ4.1と4.2と等しいときに、床4と床5の間の中二階を表すことができました。
Floors located below ground level could be represented by negative values.
負の数で地表面の下に位置する床は表すことができました。
Larger values represent floors that are above (higher in altitude) floors with lower values.
より大きい値は下側の値で(高度で、より高い)床の上にある床を表します。
The AltRes field SHOULD be set to maximum precision when AT = 2 (floors) when a floor value is included in the DHCP Reply, or the AT = 0 to denote the floor isn't known.
最大の精度へのセットがいつAT=2(床)であったか、そして、床の値がDHCP Replyに含まれているか、または床を指示するAT=0が知られていないと、AltResはSHOULDをさばきます。
Any additional LCI Altitude Types(s) to be defined for use via this DHC Option MUST be done through a Standards Track RFC.
Standards Track RFCを通してどんな使用のためにこのDHC Optionを通して定義されるべき追加LCI Altitude Types(s)もしなければなりません。
Datum: The Map Datum used for the coordinates given in this Option
データ: このOptionで与えられた座標に使用されるMap Datum
The datum must include both a horizontal and a vertical reference. Since the WGS 84 reference datum is three-dimensional, it includes both. For any additional datum parameters, the datum codepoint must specify both horizontal datum and vertical datum references.
データは水平面と垂直な参照の両方を含まなければなりません。 WGS84基準面が立体的であるので、それは両方を含んでいます。 どんな追加データパラメタとしても、データcodepointは水平なデータと垂直なデータ参照の両方を指定しなければなりません。
The Datum byte has 256 possibilities, of which 3 have been registered with IANA by this document (all derived from specification in [5]):
Datumバイトには、256の可能性があります。(そこでは、3がこのドキュメントによってIANAに登録されました)。(すべてが[5])で仕様に由来していました:
1: WGS 84 (Geographical 3D) - World Geodesic System 1984, CRS
Code 4327, Prime Meridian Name: Greenwich
1: WGS84(地理的な3D)--世界測地線システム1984、CRSコード4327、グリニッジ子午線名: グリニッジ
Polk, et al. Standards Track [Page 7] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[7ページ]。
2: NAD83 - North American Datum 1983, CRS Code 4269, Prime
Meridian Name: Greenwich; The associated vertical datum
is the North American Vertical Datum of 1988 (NAVD88)
2: NAD83--北米のデータ1983、CRSコード4269、グリニッジ子午線名: グリニッジ。 関連垂直なデータは1988年の北米のVertical Datumです。(NAVD88)
This datum pair is to be used when referencing
locations on land, not near tidal water (which would
use Datum = 3 below)
潮汐水の近くで参照をつけるのではなく、陸で位置に参照をつけるとき、このデータ組は使用されていることになっています。(以下のDatum=3を使用するでしょう)
3: NAD83 - North American Datum 1983, CRS Code 4269, Prime
Meridian Name: Greenwich; The associated vertical datum
is Mean Lower Low Water (MLLW)
3: NAD83--北米のデータ1983、CRSコード4269、グリニッジ子午線名: グリニッジ。 関連垂直なデータはMean Lower Low Waterです。(MLLW)
This datum pair is to be used when referencing
locations on water/sea/ocean
水/海/海洋で位置に参照をつけるとき、このデータ組は使用されていることになっています。
Any additional LCI datum(s) to be defined for use via this DHC Option MUST be done through a Standards Track RFC.
Standards Track RFCを通してどんな使用のためにこのDHC Optionを通して定義されるべき追加LCIデータもしなければなりません。
3. Security Considerations
3. セキュリティ問題
Where critical decisions might be based on the value of this GeoConf option, DHCP authentication in [4] SHOULD be used to protect the integrity of the DHCP options.
批判的な決定がどこにあるかもしれないかがこのGeoConfオプション、DHCP認証の値を基礎づけました。[4] SHOULDでは、使用されて、DHCPオプションの保全を保護してください。
Since there is no privacy protection for DHCP messages, an eavesdropper who can monitor the link between the DHCP server and requesting client can discover this LCI.
DHCPメッセージのためのプライバシー保護が全くないので、DHCPサーバとクライアントを要求するとのリンクをモニターできる立ち聞きする者はこのLCIを発見できます。
To minimize the unintended exposure of location information, the LCI option SHOULD be returned by DHCP servers only when the DHCP client has included this option in its 'parameter request list' (section 3.5 [1]).
位置情報の故意でない露出、LCIオプションSHOULDを最小にするために、DHCPクライアントが'パラメタ要求リスト'にこのオプションを含んでいたDHCPサーバだけで返してください。(セクション3.5[1])。
When implementing a DHC server that will serve clients across an uncontrolled network, one should consider the potential security risks.
非制御のネットワークの向こう側にクライアントに勤めるDHCサーバを実行するとき、潜在的セキュリティ危険を考えるべきです。
4. IANA Considerations
4. IANA問題
IANA has assigned a DHCP option code of 123 for the GeoConf option defined in this document.
IANAは本書では定義されたGeoConfオプションのために123のDHCPオプションコードを割り当てました。
The GeoConf Option defines two fields for which IANA maintains a registry: The Altitude (AT) field (see Section 2) and the Datum field (see Section 2). The datum indicator MUST include specification of both horizontal and vertical datum. New values for the Altitude (AT) field are assigned through "Standards Action" [RFC 2434]. The initial values of the Altitude registry are as follows:
GeoConf OptionはIANAが登録を維持する2つの分野を定義します: Altitude(AT)分野(セクション2を見る)とDatum分野(セクション2を見ます)。 データインディケータは水平なものと同様に垂直なデータの仕様を含まなければなりません。 「規格動作」[RFC2434]でAltitude(AT)分野への新しい値は割り当てられます。 Altitude登録の初期の値は以下の通りです:
Polk, et al. Standards Track [Page 8] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[8ページ]。
AT = 1 meters of Altitude defined by the vertical datum specified.
1が計量する垂直なデータによって定義されたAltitudeのAT=は指定しました。
AT = 2 building Floors of Altitude.
ATはAltitudeの2ビルFloorsと等しいです。
Datum = 1 denotes the vertical datum WGS 84 as defined by the EPSG as
their CRS Code 4327; CRS Code 4327 also specifies WGS 84 as
the vertical datum
EPSGによって彼らのCRS Code4327と定義されるようにデータ=1は垂直なデータWGS84を指示します。 また、CRS Code4327は垂直なデータとしてWGS84を指定します。
Datum = 2 denotes the vertical datum NAD83 as defined by the EPSG as
their CRS Code 4269; North American Vertical Datum of 1988
(NAVD88) is the associated vertical datum for NAD83
EPSGによってそれらのCRS Code4269と定義されるようにデータ=2は垂直なデータNAD83を指示します。 1988年(NAVD88)の北米のVertical DatumはNAD83のための関連垂直なデータです。
Datum = 3 denotes the vertical datum NAD83 as defined by the EPSG as
their CRS Code 4269; Mean Lower Low Water (MLLW) is the
associated vertical datum for NAD83
EPSGによってそれらのCRS Code4269と定義されるようにデータ=3は垂直なデータNAD83を指示します。 意地悪なLower Low Water(MLLW)はNAD83のための関連垂直なデータです。
Any additional LCI datum(s) to be defined for use via this DHC Option MUST be done through a Standards Track RFC.
Standards Track RFCを通してどんな使用のためにこのDHC Optionを通して定義されるべき追加LCIデータもしなければなりません。
5. Acknowledgements
5. 承認
The authors would like to thank Patrik Falstrom, Ralph Droms, Ted Hardie, Jon Peterson, and Nadine Abbott for their inputs and constructive comments regarding this document. Additionally, the authors would like to thank Greg Troxel for the education on vertical datums, and to Carl Reed.
作者は彼らの入力と建設的なコメントについてこのドキュメントに関してパトリクFalstrom、ラルフDroms、テッド・ハーディー、ジョン・ピーターソン、およびナディン・アボットに感謝したがっています。 さらに、作者は垂直なdatumsの上と、そして、カール・リードへの教育についてグレッグTroxelに感謝したがっています。
Polk, et al. Standards Track [Page 9] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[9ページ]。
Appendix: Calculations of Imprecision Possible with the DHC LCI
付録: DHC LCIで可能な不正確の計算
The following examples for two different locations demonstrate how the Resolution values for Latitude, Longitude, and Altitude can be used. In both examples the geo-location values were derived from maps using the WGS84 map datum, therefore in these examples, the datum field would have a value = 1 (00000001, or 0x01).
2つの別の場所のための以下の例はどうLatitude、Longitude、およびAltitudeのためのResolution値を使用できるかを示します。 データ分野は、両方の例では、地図からWGS84地図データを使用することでgeo-位置の値を得て、したがって、これらの例では、値の=1を持っているでしょう(00000001、または0×01)。
A.1. Location Configuration Information of "White House" (Example 1)
A.1。 「ホワイトハウス」に関する位置の設定情報(例1)
The address was NOT picked for any political reason and can easily be found on the Internet or mapping software, but was picked as an easily identifiable location on our planet.
アドレスは、容易にどんな政治上の理由にも選ばれないで、インターネットで見つけられたか、またはソフトウェアを写像できましたが、容易に身元保証可能な位置として私たちの惑星で選ばれました。
Postal Address:
White House
1600 Pennsylvania Ave. NW
Washington, DC 20006
郵便の宛先: ホワイトハウス1600ペンシルバニアAve。 NWワシントン、DC 20006
Standing on the sidewalk, north side of White House, between driveways.
歩道の地位、私道の間のホワイトハウスの北寄り。
Latitude 38.89868 degrees North (or +38.89868 degrees)
Using 2s complement, 34 bit fixed point, 25 bit fraction
Latitude = 0x04dcc1fc8,
Latitude = 0001001101110011000001111111001000
2補数を使用する緯度の38.89868度の北部(+38.89868度)、34ビットの定点、25は断片Latitude=0x04dcc1fc8に噛み付きました、Latitude=0001001101110011000001111111001000
Longitude 77.03723 degrees West (or -77.03723 degrees)
Using 2s complement, 34 bit fixed point, 25 bit fraction
Longitude = 0xf65ecf031,
Longitude = 1101100101111011001111000000110001
2補数を使用する経度77.03723度西洋(-77.03723度)、34ビットの定点、25は断片Longitude=0xf65ecf031に噛み付きました、Longitude=1101100101111011001111000000110001
Altitude 15
高度15
In this example, we are not inside a structure, therefore we will assume an altitude value of 15 meters, interpolated from the US Geological survey map, Washington West quadrangle.
この例には、私たちが構造の中にいません、したがって、米国Geological測量図から補間された15個のメーターの高度値を仮定するつもりです、ワシントンの西四角形。
AltRes = 30, 0x1e, 011110
AT = 1, 0x01, 000001
Altitude = 15, 0x0F00, 00000000000000000000000001111100000000
AltRes=30、0x1e、=1、0×01、000001高度=15、0x0F00、00000000000000000000000001111100000000における011110
If: LaRes is expressed as value 2 (0x02 or 000010) and LoRes is
expressed as value 2 (0x02 or 000010), then it would describe a
geo-location region that is north of the equator and extends from
-1 degree (west of the meridian) to -128 degrees. This would
include the area from approximately 600km south of Saltpond,
Ghana, due north to the North Pole and approximately 4400km
: 値の2(0×02か000010)とLoResが値2(0×02か000010)として急送されて、次に、赤道の北にあるgeo-位置の地域について説明して、-1度(子午線の西)から-128度に広がるとき、LaResは急送されます。 これはおよそ600kmからのソルトポンド(ガーナ)の真北の南の領域を北極とおよそ4400kmに含めるでしょう。
Polk, et al. Standards Track [Page 10] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[10ページ]。
south-southwest of Los Angeles, CA due north to the North Pole.
This would cover an area of about one-sixth of the globe,
approximately 20 million square nautical miles (nm).
南南西北極へのロサンゼルス(カリフォルニア)の真北について。 これは地球のおよそ1/6、正方形のおよそ2000万海里(nm)の面積をカバーしているでしょう。
If: LaRes is expressed as value 3 (0x03 or 000011) and LoRes is
expressed as value 3 (0x03 or 000011), then it would describe a
geo-location area that is north from the equator to 63 degrees
north, and -65 degrees to -128 degrees longitude. This area
includes south of a line from Anchorage, AL to eastern Nunavut,
CN, and from the Amazons of northern Brazil to approximately
4400km south-southwest of Los Angeles, CA. This area would
include North America, Central America, and parts of Venezuela
and Columbia, except portions of Alaska and northern and eastern
Canada, approximately 10 million square nm.
: 値の3(0×03か000011)とLoResが値3(0×03か000011)として急送されるようにLaResは急送されて、次に、それは63度の北、および赤道から-65度から-128度の経度までの北にあるgeo-位置の地域について説明するでしょう。 この領域は東ヌナブットへのアンカレッジ(AL)CNと、北ブラジルのAmazonsからの線の南を南南西ロサンゼルス(カリフォルニア)のおよそ4400kmに含んでいます。 アラスカと北の、そして、東のカナダ(正方形のおよそ1000万nm)の一部を除いて、この領域は北アメリカ、中米、およびベネズエラとコロンビアの地域を含んでいるでしょう。
If: LaRes is expressed as value 5 (0x05 or 000101) and LoRes is
expressed as value 5 (0x05 or 000101), then it would describe a
geo-location area that is latitude 32 north of the equator to
latitude 48 and extends from -64 degrees to -80 degrees
longitude. This is approximately an east-west boundary of a time
zone, an area of approximately 700,000 square nm.
: 値の5(0×05か000101)とLoResが値5(0×05か000101)として急送されるようにLaResは急送されて、次に、それは緯度48への赤道の32北の緯度であり、-64度から-80度の経度に広がるgeo-位置の地域について説明するでしょう。 これは時間帯の東西境界、正方形のおよそ70万nmのおよそ面積です。
If: LaRes is expressed as value 9 (0x09 or 001001) and LoRes is
expressed as value 9 (0x09 or 001001), which includes all the
integer bits, then it would describe a geo-location area that is
latitude 38 north of the equator to latitude 39 and extends from
-77 degrees to -78 degrees longitude. This is an area of
approximately 9600 square km (111.3km x 86.5km).
: 値の9(0×09か001001)とLoResがすべての整数ビットを含んでいる値9(0×09か001001)として急送されるようにLaResは急送されて、次に、それは緯度39への赤道の38北の緯度であり、-77度から-78度の経度に広がるgeo-位置の地域について説明するでしょう。 これは正方形のおよそ9600km(111.3km x eighty-six.5km)の面積です。
If: LaRes is expressed as value 18 (0x12 or 010010) and LoRes is
expressed as value 18 (0x12 or 010010), then it would describe a
geo-location area that is latitude 38.8984375 north to latitude
38.9003906 and extends from -77.0390625 degrees to -77.0371094
degrees longitude. This is an area of approximately 36,600
square meters (169m x 217m).
: 値の18(0×12か010010)とLoResが値18(0×12か010010)として急送されるようにLaResは急送されて、次に、それは緯度38.9003906への38.8984375北の緯度であり、-77.0390625度から-77.0371094度の経度に広がるgeo-位置の地域について説明するでしょう。 これはおよそ3万6600平方メートル(169m x217m)の面積です。
If: LaRes is expressed as value 22 (0x16 or 010110) and LoRes is
expressed as value 22 (0x16 or 010110), then it would describe a
geo-location area that is latitude 38.896816 north to latitude
38.8985596 and extends from -77.0372314 degrees to -77.0371094
degrees longitude. This is an area of approximately 143 square
meters (10.5m x 13.6m).
: 値の22(0×16か010110)とLoResが値22(0×16か010110)として急送されるようにLaResは急送されて、次に、それは緯度38.8985596への38.896816北の緯度であり、-77.0372314度から-77.0371094度の経度に広がるgeo-位置の地域について説明するでしょう。 これはおよそ143平方メートル(10.5m x13.6m)の面積です。
If: LaRes is expressed as value 28 (0x1c or 011100) and LoRes is
expressed as value 28 (0x1c or 011100), then it would describe a
geo-location area that is latitude 38.8986797 north to latitude
: 値の28(0x1cか011100)とLoResが値28(0x1cか011100)として急送されるようにLaResは急送されて、次に、それは緯度への38.8986797北の緯度であるgeo-位置の地域について説明するでしょう。
Polk, et al. Standards Track [Page 11] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[11ページ]。
38.8986816 and extends from -77.0372314 degrees to -77.0372296
degrees longitude. This is an area of approximately 339 square
centimeters (20.9cm x 16.23cm).
そして、38.8986816、-77.0372314度から-77.0372296度の経度に広がっています。 これはおよそ339平方センチメートル(20.9cm x16.23cm)の面積です。
If: LaRes is expressed as value 30 (0x1e or 011110) and LoRes is
expressed as value 30 (0x1e or 011110), then it would describe a
geo-location area that is latitude 38.8986797 north to latitude
38.8986802 and extends from -77.0372300 degrees to -77.0372296
degrees longitude. This is an area of approximately 19.5 square
centimeters (50mm x 39mm).
: 値の30(0x1eか011110)とLoResが値30(0x1eか011110)として急送されるようにLaResは急送されて、次に、それは緯度38.8986802への38.8986797北の緯度であり、-77.0372300度から-77.0372296度の経度に広がるgeo-位置の地域について説明するでしょう。 これはおよそ19.5平方センチメートル(50mm x39mm)の面積です。
If: LaRes is expressed as value 34 (0x22 or 100010) and LoRes is
expressed as value 34 (0x22 or 100010), then it would describe a
geo-location area that is latitude 38.8986800 north to latitude
38.8986802 and extends from -77.0372300 degrees to -77.0372296
degrees longitude. This is an area of approximately 7.5 square
millimeters (3.11mm x 2.42mm).
: 値の34(0×22か100010)とLoResが値34(0×22か100010)として急送されるようにLaResは急送されて、次に、それは緯度38.8986802への38.8986800北の緯度であり、-77.0372300度から-77.0372296度の経度に広がるgeo-位置の地域について説明するでしょう。 これはおよそ7.5平方ミリメートル(3.11mm x2.42mm)の面積です。
In the (White House) example, the requirement of emergency responders in North America via their NENA Model Legislation [8] could be met by a LaRes value of 21 and a LoRes value of 20. This would yield a geo-location that is latitude 38.8984375 north to latitude 38.8988616 north and longitude -77.0371094 to longitude -77.0375977. This is an area of approximately 89 feet by 75 feet or 6669 square feet, which is very close to the 7000 square feet requested by NENA. In this example, a service provider could enforce that a device send a Location Configuration Information with this minimum amount of resolution for this particular location when calling emergency services.
(ホワイトハウス)の例では、21のLaRes値と20のLoRes値で彼らのNENA Model Legislation[8]を通した北アメリカの緊急要員の必要条件を満たすことができました。 これは緯度への緯度であるgeo-位置の38.8984375北で38.8988616の北の経度と経度-77.0371094を経度-77.0375977にもたらすでしょう。 これはNENAによって要求された7000年の非常に近くにある75フィートの、または、6669平方フィートのおよそ89フィート平方フィートの面積です。 この例では、サービスプロバイダーは緊急サービスと呼ぶとき装置がこの特定の位置のためのこの最小の量の解決でLocation Configuration情報を送るそのaを実施できました。
A.2. Location Configuration Information of "Sears Tower" (Example 2)
A.2。 「シアーズタワー」に関する位置の設定情報(例2)
Postal Address:
Sears Tower
103rd Floor
233 S. Wacker Dr.
Chicago, IL 60606
郵便の宛先: 床の233秒間ワッカーシカゴ博士、シアーズタワー第103イリノイ 60606
Viewing the Chicago area from the Observation Deck of the Sears Tower.
シアーズタワーのObservation Deckからシカゴの地域を見ます。
Latitude 41.87884 degrees North (or +41.87884 degrees) Using 2s complement, 34 bit fixed point, 25 bit fraction Latitude = 0x053c1f751, Latitude = 0001010011110000011111011101010001
2補数を使用する緯度の41.87884度の北部(+41.87884度)、34ビットの定点、25は断片Latitude=0x053c1f751に噛み付きました、Latitude=0001010011110000011111011101010001
Polk, et al. Standards Track [Page 12] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[12ページ]。
Longitude 87.63602 degrees West (or -87.63602 degrees) Using 2s complement, 34 bit fixed point, 25 bit fraction Longitude = 0xf50ba5b97, Longitude = 1101010000101110100101101110010111
2補数を使用する経度87.63602度西洋(-87.63602度)、34ビットの定点、25は断片Longitude=0xf50ba5b97に噛み付きました、Longitude=1101010000101110100101101110010111
Altitude 103
高度103
In this example, we are inside a structure, therefore we will assume an altitude value of 103 to indicate the floor we are on. The Altitude Type value is 2, indicating floors. The AltRes field would indicate that all bits in the Altitude field are true, as we want to accurately represent the floor of the structure where we are located.
この例には、私たちが構造の中にいます、したがって、私たちがいる床を示すために103の高度値を仮定するつもりです。 床を示して、Altitude Type値は2です。 AltRes分野は、Altitude分野のすべてのビットが真であることを示すでしょう、正確に私たちが位置している構造の床を表したいと思うとき。
AltRes = 30, 0x1e, 011110 AT = 2, 0x02, 000010 Altitude = 103, 0x00006700, 000000000000000110011100000000
AltRes=30、0x1e、=2、0×02、000010高度=103、0×00006700、000000000000000110011100000000における011110
For the accuracy of the latitude and longitude, the best information available to us was supplied by a generic mapping service that shows a single geo-loc for all of the Sears Tower. Therefore we are going to show LaRes as value 18 (0x12 or 010010) and LoRes as value 18 (0x12 or 010010). This would be describing a geo-location area that is latitude 41.8769531 to latitude 41.8789062 and extends from -87.6367188 degrees to -87.6347657 degrees longitude. This is an area of approximately 373412 square feet (713.3 ft. x 523.5 ft.).
緯度と経度の精度において、シアーズタワーのすべてのために単一のgeo-locを見せているサービスを写像するジェネリックは私たちにとって、利用可能な最も良い情報を提供しました。 したがって、私たちは値18(0×12か010010)として値18(0×12か010010)としてのLaResとLoResの証明になっています。 これは緯度41.8789062への緯度41.8769531であり、-87.6367188度から-87.6347657度の経度に広がるgeo-位置の地域について説明しているでしょう。 これはおよそ373412平方フィート(713.3フィートx523.5フィート)の面積です。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March
1997.
[1]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[2] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001.
[2] パトリック、M.、「DHCP中継エージェント情報オプション」、RFC3046、2001年1月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC
3118, June 2001.
[4]DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、2001年6月。
[5] European Petroleum Survey Group, http://www.epsg.org/ and
http://www.ihsenergy.com/epsg/geodetic2.html
[5] ヨーロッパの石油の調査グループ、 http://www.epsg.org/ 、および http://www.ihsenergy.com/epsg/geodetic2.html
[6] World Geodetic System 1984 (WGS 84), MIL-STD-2401,
http://www.wgs84.com/
[6] 世界の測地学のシステム1984(WGS84)、軍規格-2401、 http://www.wgs84.com/
Polk, et al. Standards Track [Page 13] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[13ページ]。
6.2. Informational References
6.2. 情報の参照
[7] Farrell, C., Schulze, M., Pleitner, S. and D. Baldoni, "DNS
Encoding of Geographical Location", RFC 1712, November 1994.
[7] ファレルとC.とシュルツェとM.とPleitnerとS.とD.Baldoni、「地理的な位置のDNSコード化」、RFC1712、1994年11月。
[8] National Emergency Number Association (NENA) www.nena.org NENA
Technical Information Document on Model Legislation Enhanced 911
for Multi-Line Telephone Systems.
[8] Multi-線Telephone SystemsのためのModel Legislation Enhanced911の上の国家のEmergency Number Association(NENA)www.nena.org NENA Technical情報Document。
7. Author Information
7. 作者情報
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
ジェームスM.ポークシスコシステムズ2200の東社長のジョージ・ブッシュ・Turnpikeテキサス75082リチャードソン(米国)
EMail: jmpolk@cisco.com
メール: jmpolk@cisco.com
John Schnizlein Cisco Systems 9123 Loughran Road Fort Washington, MD 20744 USA
ジョンSchnizleinシスコシステムズ9123のLoughran Road MD20744ワシントン砦(米国)
EMail: john.schnizlein@cisco.com
メール: john.schnizlein@cisco.com
Marc Linsner Cisco Systems Marco Island, FL 34145 USA
マークLinsnerシスコシステムズフロリダ34145マルコ島(米国)
EMail: marc.linsner@cisco.com
メール: marc.linsner@cisco.com
Polk, et al. Standards Track [Page 14] RFC 3825 DHCP Option for Coordinate LCI July 2004
ポーク、他 規格は2004年7月にコーディネートしているLCIのためにRFC3825DHCPオプションを追跡します[14ページ]。
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Polk, et al. Standards Track [Page 15]
ポーク、他 標準化過程[15ページ]
一覧
スポンサーリンク
