# Network Earth Position Protocol（NEPP）

## Earth Dateの同期と、場所に応じた太陽位相

### draft-iwata-nepp-03 日本語参考版

Intended status: Experimental  
Kenichi Iwata, Tottori University  
2026年8月31日

## この文書の位置づけ

**[英語版](draft-iwata-nepp-03.md)が正本です。この日本語版は参考資料であり、
内容・解釈に相違がある場合は英語版を優先してください。**

本書は著者による議論用の作業草案であり、IETFへ提出済みのInternet-Draftでも、
Internet Standardでもありません。以下のVersion 2パケット配置、符号値、天文
プロファイルは提案段階です。ローカルの実験用V2専用サーバーはありますが、
独立した天文検証は未完了です。相互運用性や本番配備を保証しません。

草案改訂番号`-03`、プロトコルVersion 2、アプリ版`0.0.2`は別の番号です。
`-00`・`-01`・`-02`は過去版として保存します。

本版はV1・V2両方の提案仕様を収録し、旧版を読むことを前提にしません。
外部の天文標準への参照は残りますが、未決の実現手順は本書内の未決事項として
明示し、旧NEPP草案へ委ねません。

## 概要

NEPPは、地心視太陽黄経に基づく連続的な暦座標Earth Date（ED）を同期します。
本版は、基準太陽位相とその局所的な変化率も配信するVersion 2を提案します。
クライアントは、位置をサーバーに送ることなく、基準位相に手元の経度を加えて
その場所の太陽の日周運動を表現します。

地球共通の瞬間と場所に依存する日内位相を分離する設計です。視太陽時を新しく
発明するものでも、原子時の基盤や民用タイムゾーンを置き換える規定でもありません。
V1とV2にワイヤ互換性はなく、移行後のV1サービス継続や旧V1クライアントの動作は
保証しません。V2専用サーバー・クライアントを認め、V1対応は任意とします。

## 1. 変更点と範囲

`-02`から、次の設計方針を反映します。

- 座標の定義、基準源による実現、ネットワーク配信を分離する。
- 現在の時計と天体暦による実装は実験・検証用の暫定実装であり、
  NEPP必須の基準源構成ではないと明記する。
- 経過時間にはSI秒を用いるが、UTC同期やNTPを必須としない。
- EDとSolar Phase（SP）それぞれで、値なしと値あり・誤差不明を区別する。
- 対象時点の黄道面・真春分点、基本太陽方向モデルに含む効果と省く効果を定義する。
- 出所、供給状態、予測情報、不確かさ、有効期間を分け、IERS依存の分類にしない。
- 基準源Stratum 0とネットワーク入口Stratum 1を区別し、基準源からの時点対応を要求する。

第6節はこれらを**新しい、レビュー対象の160オクテットV2配置案**として具体化します。
フィールドの割り当ては今回初めて提案するもので、合意済み・稼働済みの仕様ではありません。
`-02`の未実装128オクテットV2案を置き換え、両案にワイヤ互換性はありません。
いずれも確立したV2標準ではありません。V1の76オクテット基本形式は変更しません。
V1の説明を残すことは、その提供を実装に要求する意味ではありません。
本版は、V1エンドポイントの継続や自動フォールバックなしで、クライアント更新を
必要とするベータサービスの移行を明示的に認めます。

本書だけでV1と提案V2を読めます。配信対象は瞬間の状態であり、GPS座標や予定ではありません。
日の出・日没、太陽高度、地図、民用時刻変換、詳細メタデータの通信方式、認証形式は
基本交換の範囲外です。

## 2. 要求事項の表現

英語正本の大文字のMUST、MUST NOT、SHOULD、MAYなどは、BCP 14の
[RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html)と
[RFC 8174](https://www.rfc-editor.org/rfc/rfc8174.html)に従います。
本書の要求事項は提案する仕様を表し、現在の実装が満たしているとの宣言ではありません。

## 3. 二つの座標と二つの役割

### 3.1. Earth DateとEarth Year

```text
ED(t) = Y + lambda(t) / 360度
```

`lambda`は採用したNEPP天文プロファイルの地心視太陽黄経で、範囲は`[0, 360)`度です。
Earth Year `Y`は春分の0度通過から始まり、その春分を含むグレゴリオ暦年を整数ラベルに
使います。春分前は前年のEarth Yearになります。

小数部は角度であり、固定長の一年に対する経過時間の割合ではありません。
春分・夏至・秋分・冬至に対応する四分の一周の間隔も、物理時間では等間隔ではありません。
その場所で経験する季節は、半球・緯度・気候にも依存します。

太陽位相は、これとは別の周期座標です。同じ瞬間・同じモデルのEDは全員共通ですが、
局所位相は選んだ経度によって変わります。EDの小数部を取っても自転位相にはなりません。

一年あたりの日数も、太陽位相一周あたりのSI秒数も定数として定義しません。
SI秒は通信遅延、局所発振器の経過時間、補間速度の単位として引き続き使用します。

### 3.2. ED天文プロファイル1

ED Model ID 1は以下の実験的な基本座標モデルを示します。本版で意図する幾何を明確化
しますが、稼働中のV1実装の適合性・数値的一致は未確認です。Model IDだけでは精度を
保証しません。配備済み基準源を変更する前に第12・13節の検証と移行判断が必要です。

#### 3.2.1. 時点・面・原点

時点`t`は座標が表すイベントであり、計算機が計算を実行する時刻ではありません。
過去・未来の場合も含め、以下の座標軸をすべて対象時点`t`で評価します。

黄道はIAU 2006決議B1の推奨事項4に従い、極をBCRSにおける地球・月系重心の
平均軌道角運動量の方向とします。地球の瞬間の位置と速度だけから作る面ではありません。
対象時点の実現にはIAU 2006/P03歳差を用います。

原点はIAU 2006への調整を含むIAU 2000A章動を反映した、その時点の**真春分点**です。
J2000固定原点、平均春分点、その年の春分時点で固定した原点ではありません。
観測者は地球中心、対象は太陽中心であり、太陽の縁や明るさで重みづけた円盤中心ではありません。

#### 3.2.2. 基本太陽方向モデル

以下の数学モデルで対象方向を定義します。基準源はこれを計算しても、同等の座標を
別の基準源から取得しても構いません。この計算手順はサーバー構成の指定ではありません。

BCRS整合の太陽系重心位置`x_E(t)`、`x_S(te)`と地球の重心系速度`v_E(t)`を使います。
天体暦の時系と単位を整合させます（通常はTDB整合の位置・速度・光速）。
光の放射時点を反復により求めます。

```text
te = t - |x_S(te) - x_E(t)| / c
p = (x_S(te) - x_E(t)) / |x_S(te) - x_E(t)|
```

これは重力による伝播時間遅延を含まないユークリッド的な光到達時間です。
観測者の位置は受信時点`t`のままです。両天体を`te`で評価することや、
最終黄経から固定の「8分」を引くこととは異なります。

地球中心の重心系速度による特殊相対論的な光行差を適用します。
`b = v_E(t)/c`、`g = sqrt(1 - b dot b)`、`w = p dot b`として、

```text
s = normalize(g*p + (1 + w/(1+g))*b)
```

と定義します。観測者速度の符号もこの式に従う純粋なローレンツ光行差です。
補正済み入力に再適用してはいけません。基本モデルでは、すべての天体による光路の
重力偏向、重力伝播時間遅延、方向変換の重力ポテンシャル項を省きます。
天体暦の軌道計算から重力や相対論的力学を除く、という意味ではありません。

SOFAの`iauAb`には太陽重力ポテンシャル項が含まれ、この純粋な式と完全には同一では
ありません。`iauLdsun`も遠方光源の重力偏向用で、太陽自身の中心にそのまま使う手順
ではありません。「apparent」という関数名だけで同等とみなさず、含む効果を確認します。

これは意図的に定義した**基本モデル上の視方向**です。省略効果が特定の誤差以下である、
または厳密な物理観測そのものであるとは主張しません。省略効果を定義に追加する場合は、
通常は別のModel IDで明示的に区別します。同じ定義の計算を高精度化するだけなら、
それ自体を理由とするModel ID変更は不要です。

#### 3.2.3. EDへの変換と共通太陽方向

`TT(t)`でSOFA `iauPnm06a`相当のIAU 2006/2000Aバイアス・歳差・章動行列
`B(t)`、`iauObl06`相当の平均黄道傾斜`eps_A`、`iauNut06a`による章動傾斜
`deps`を評価します。`(x,y,z) = B(t)*s`、`eps = eps_A + deps`とし、

```text
xe = x
ye = cos(eps)*y + sin(eps)*z
ze = -sin(eps)*y + cos(eps)*z
lambda = atan2(ye, xe) modulo 2*pi
alpha_app = atan2(y, x) modulo 2*pi
ED = Y + lambda/(2*pi)
```

とします。座標軸と符号を規定するもので、言語・ライブラリの指定ではありません。
SOFA `iauEcm06`だけでは平均春分点なので、この変換ではありません。
同じ`s`と`alpha_app`を第5節のSolar Model 1にも使います。
地心座標のため、地表視差、日周光行差、大気屈折、局所鉛直、地平線効果を含めません。

特定の天体暦製品・数値ライブラリは必須にしません。実現方法と既知の制約は開示します。
V2は誤差不明を許しますが、別の座標定義への無断置換を許すわけではありません。
相互運用性や有限の精度上限を検証済みと主張するには、独立した数値検証が必要です。

### 3.3. 時系とED変化率

経過時間、通信遅延、座標変化率にはSI秒を用います。各装置は単調時計で時間間隔を
測定でき、原子時計の搭載は不要です。UTC同期やNTPも必須ではありません。
時計の歩度誤差、ドリフト、時点転送誤差は不確かさに寄与し、不明をゼロ扱いしません。

計算による実現では必要に応じてTT/TDBとUT1を使います。UTC入力はうるう秒を含めて
整合するよう変換します。ED自身は民用のうるう日・うるう秒を挿入しません。
SI秒を使うことは、1年を固定秒数で定義することではありません。

`R = dED/dt`はED/SI秒、Qはturn/SI秒です。TDB等の座標時を使う計算では、
変化率を実現系の経過SI秒の規約へ整合して換算します。ここでの基準地球時引数はTTです。
その規約の実現誤差も不確かさに含めます。春分をまたぐ微分は小数部ではなく連続した
ED全体で行います。線形伝播は局所的なもので、無期限の天文予測ではありません。

### 3.4. 基準源と配信

現在の時計と天体暦による実装は実験・検証用の暫定ソフトウェアであり、そのホスト時計
依存はNEPPの必須条件ではありません。将来、より高精度で品質を検証可能な座標の基準源
を整備することを想定します。これは開発目標であり、自動的な精度保証ではありません。

Stratum 0は座標を生成する基準系です。それに直接接続してNEPPを提供する入口が
Stratum 1、Stratum 1のNEPPから同期するサーバーがStratum 2となります。
同期に使うネットワーク基準源は1〜15を広告し、0を広告しません。
0→1は内部呼び出し、装置接続、別途定義したリンク等を使え、別のネットワークプロトコル
の新設を要求するものではありません。

基準源インターフェースは、各座標とそれが表すイベントを対応づける必要があります。
サーバーはそのイベントをローカル経過時間の基準に対応づけ、伝送・処理遅延を考慮して
応答時点まで進めます。UTC時刻印は一方式にすぎません。不明な転送誤差は不明のまま
品質情報へ反映します。

NEPPサーバー間もクライアントと同じ交換方式を使い、既存の4イベント方式を維持します。
EDとSPが別基準源でも応答の同一時点へ揃えます。StratumはNEPP基準源からの距離であり、
実現系内のNTPホップ数や精度証明ではありません。

## 4. Version 1仕様

本節でV1を旧版への依存なしに定義します。V2のトークン、160オクテット長、ゼロ埋め、
太陽フィールドをV1クライアントに要求してはいけません。V1の形式と意味は維持します。
本節はV1対応を選択した実装にのみ適用し、V2専用実装にV1実装・提供を要求しません。

### 4.1. 基本配置と版の判別

整数はbig endian、符号付き整数は2の補数です。先頭Flagsオクテットは上位から
`Status:2 | Version:3 | Mode:3`で、Versionは`(flags >> 3) & 7`で取り出します。

| Offset | Octets | Field |
|---:|---:|---|
| 0 | 1 | Flags |
| 1 | 1 | Stratum |
| 2 | 1 | Poll（符号付き） |
| 3 | 1 | Precision（符号付き） |
| 4 | 4 | Root Delay |
| 8 | 4 | Root Dispersion |
| 12 | 4 | Reference ID |
| 16 | 12 | Reference Earth Date |
| 28 | 12 | Origin Earth Date |
| 40 | 12 | Receive Earth Date |
| 52 | 12 | Transmit Earth Date |
| 64 | 8 | Earth Date Rate |
| 72 | 4 | Model ID |

V1基本パケットは76オクテット、Versionは1です。76未満は不正です。
後続オクテットは拡張データでありV2フィールドではありません。本書は拡張の型・長さ形式や
critical拡張の機構を定義しません。基本形式だけを扱うV1実装は後続を無視し、76オクテットの
応答を返します。後続を認証や太陽情報と解釈してはいけません。拡張を理解する実装には
別途明示された仕様合意が必要ですが、それをV1基本実装の前提とはしません。

### 4.2. 時刻印と変化率の符号化

時刻印は符号付き32ビットEarth Yearと符号なし64ビット小数部で、
`U = floor(F * 2^64)`、復号値は`Y + U / 2^64`です。許された箇所の全ゼロは
時刻印なしを示し、信頼できる同期時点ではありません。年境界を含む差分は、
年と小数部を独立に引かず、完全なED値として求めます。

ED Rateは符号付き64ビット`round(R * 2^63)`で、復号単位はED/SI秒です。
Statusは0＝同期、1＝劣化、2＝自走保持、3＝未同期で、NTPの閏秒フラグではありません。
Modeはクライアント3、サーバー4です。Stratumは0＝基準源、1＝一次サーバー、
2〜15＝二次サーバー、16＝未同期、17〜255＝予約です。同期に使うネットワーク
サーバーのStratumは1〜15です。

Pollは`2^Poll` SI秒の推奨間隔、Precisionは`2^Precision` EDの公称分解能です。
Precisionは精度保証ではありません。Root DelayとRoot Dispersionは符号なし16.16
固定小数点のSI秒で、累積往復遅延と同期不確かさを表します。Reference IDとModel IDは
それぞれ基準源と、第3.2節のED天文プロファイルを示します。

### 4.3. フィールドの意味

Status 0はED同期、1は基準源の天文品質低下、2は予測のみまたは自走保持、
3は非同期で同期に利用禁止です。低品質・自走保持の受け入れはクライアント方針によります。

Modeは0予約、1 symmetric active、2 symmetric passive、3 client、4 server、
5 broadcast、6/7予約です。本書が規定するのは3/4だけで、その他の名称から動作を
推測してはいけません。基本実装は3/4をサポートします。

一次サーバーは基準実現系から直接EDを取得し、二次以降は上流NEPPから取得します。
ローカル天文計算は基準実現の一方式で、一次サーバーの必須動作ではありません。
Stratum 0とネットワーク入口Stratum 1は第3.4節に従います。

Poll・Precisionは符号付き8ビット`-128..127`です。Poll 6は64 SI秒を推奨します。
不信な値をそのまま指数計算せず、実際のポーリング・資源利用はローカル方針で制限します。

Root Delay・Root Dispersionの符号なし整数Wは`W/65536` SI秒、
範囲は0〜`65535+65535/65536`秒です。前者は基準までの累積往復通信遅延、
後者は累積同期不確かさの上側見積もりです。天文不確かさもRoot Dispersionか、
クライアントが理解する別仕様の拡張に含めます。基本交換ではRoot Dispersionに含めます。
ゼロは不明マーカーではありません。表せない不確かさを有限の正確な上限として
主張できず、その基準源は同期には利用できません。

V1には明示的な誤差不明の符号化がありません。正直な有限上限を供給できないサーバーは
利用可能なV1同期標本を広告してはいけません。Status 3 / Stratum 16を返すか、
V1同期を提供しないことができます。V2で精度未評価の座標を提供することは妨げません。
V1互換維持は虚偽のゼロ分散の理由になりません。

Reference IDは32ビットで、Stratum 1では基準源・プロファイル、二次以降では上流の
識別やループ検出に使えます。世界的な登録簿は定めず、IPv4アドレスとも限りません。
ASCIIラベルは追跡可能性の証明ではありません。ED Model IDは符号なし32ビットで、
1は第3.2節の実験プロファイルです。未知のモデルを同等と仮定しません。

### 4.4. V1要求と応答

クライアント送信E1、サーバー受信E2、サーバー送信E3、クライアント受信E4を使います。
E4は手元で記録し、送信しません。要求はVersion 1・Mode 3で、TransmitにE1、
OriginとReceiveにゼロを設定します。Referenceは実装依存値またはゼロです。
初期取得・未同期ではStatus 3・Stratum 16とし、ED未取得ならE1にゼロを使えます。
Poll・Precisionはクライアントの方針、応答専用情報はゼロで構いません。
V1には乱数トークンはなく、V2の追加要求検査を適用しません。

サーバーは受信時にE2を記録し、要求TransmitをそのままOriginにコピーし、送信に可能な限り
近い時点でE3を記録します。応答はVersion 1・Mode 4で、自身の状態・Stratum・基準源・
品質情報、ReceiveにE2、TransmitにE3、局所ED速度を返します。Referenceは同期に使った
基準ED状態、未提供ならゼロです。ED速度は応答送信時点へ評価・補間することを推奨します。
要求に無視する拡張が付いていても、基本形式の応答は76オクテットです。

受信側は自分のED時計でE4を記録し、通常は第8.1節を使います。E1/E4なしの初期取得では
第8.2節のED部分だけを使用し、V1には太陽の項はありません。ゼロOriginとゼロE1は
照合できますが、偽装・再送に対する保護は弱いものです。V1応答から太陽状態を捏造しては
いけません。

### 4.5. V1の受け入れ・エラー・最小実装

非対応Version、Server以外のMode、未同期Status、要求E1と異なるOrigin、不正な時刻印、
76オクテット未満、禁止された予約値、許容上限超過のRoot Dispersionは同期に使えません。
Origin照合は必須です。さらに選択したネットワーク相手との一致、重複の破棄、時間や基準情報の
妥当性確認を推奨します。V2のトークン・固定長・太陽検査は適用しません。

サーバーは不正なパケット、未知の版、実装しないModeへ応答せず破棄します。
別版の応答は版交渉ではありません。UDPは第7.1節・第11節の要求応答方式を使い、
連続した接続を前提としません。

基本V1サーバーはProfile 1のED供給、E2/E3、ED速度、Stratum、遅延、分散を実装します。
基本同期クライアントは可能な場合のE1/E4記録、Origin照合、オフセット推定、時計制御、
自走保持を実装します。初期取得だけの表示は限定的クライアントであり、完全な同期精度の
証明ではありません。品質管理と基準源選択は第8.4節を参照します。
仕様を書いただけで既存コードの不足が解消されるわけではありません。

## 5. 基準太陽位相と局所太陽位相

### 5.1. 定義

負の値も含めて`frac(x) = x - floor(x)`とします。提案するSolar Model 1において、
`alpha_app(t)`を真赤道・真春分点（of date）に基づく地心視太陽赤経、`GAST(t)`を
同じ基準系に対応するグリニッジ視恒星時とし、どちらもラジアンで表します。

```text
H_G(t) = GAST(t) - alpha_app(t)
P_G(t) = frac(0.5 + H_G(t) / (2*pi))
P_L(t, L) = frac(P_G(t) + L / 360度)
```

`L`はグリニッジ基準子午線に対して東経正・西経負の経度です。
クライアントでは`[-180, 180)`度への正規化を推奨します。これは座標系の基準であり、
民用タイムゾーンや歴史的な特定の子午線標識そのものを意味しません。

`P_L`は`[0, 1)`で、モデル上の上方子午線通過で0.5、下方通過で1直前から0へ戻ります。
これは[USNOの視太陽時の定義](https://aa.usno.navy.mil/faq/eqtime)を一周1で表したもので、
新しい天文学的時系の発明ではありません。

春分点基準の赤経を維持したまま、GASTだけをEarth Rotation Angleに置き換えては
いけません。CIO基準を使う場合は両方を整合して変換します。単位・原点・符号の一致が
必要です。

### 5.2. 経度だけで求めるモデルの範囲

Solar Model 1は、経度だけを使う理想化した地心モデルです。通常は端末の位置情報が
返す測地経度（一般にWGS 84）、または手動選択した経度を直接適用します。
観測者ごとの極運動補正、地心視差の地表補正、鉛直線偏差、標高、大気差は適用しません。

従って0.5はモデル上の正午であり、あらゆる場所で観測した太陽の頂点時刻との厳密な
一致を保証しません。完全な地球固定系・天球系変換には
[IERS Conventions第5章](https://iers-conventions.obspm.fr/content/chapter5/icc5.pdf)
に記載された極運動なども関係します。緯度や追加状態を使う高精度モデルを導入する場合、
この経度のみのモデルと黙って入れ替えてはいけません。

0.25・0.75は日の出・日没と定義しません。昼夜の判定には緯度、太陽赤緯、地平線条件も
必要です。白夜・極夜も含め、位相だけでは太陽が地平線より上にあるか分かりません。
地理的な極では経度は一意の物理的意味を持たないため、明示的な基準経度を選ぶか、
局所位相を利用不可とし、一意の現地正午が求まったように表示しないことが必要です。

### 5.3. 天文モデルと地球姿勢データ

SPはSolar Phase（太陽位相）、LSPはLocal Solar Phase（地方太陽位相）の略です。
`P_G`が基準SP、`P_L`がLSPです。Solar Model ID 1は第3.2節の基本太陽方向と、
UT1・TTを整合して与えたSOFA `iauGst06a`相当のIAU 2006/2000A GASTを使います。
SolarとEDのModel IDは別の名前空間です。

天文計算による実現ではIERSの`UT1-UTC`からUT1を得られますが、SPサーバーの
必須構成ではありません。直接座標の基準源も同じモデル量を提供し、出所を開示します。
UT1-UTCは角度ではなく時間差で、位相に直接加えてはいけません。
UTCうるう秒境界の補間は不連続を処理し、不明をUT1=UTCで代用しません。

IERSの観測・速報・予測は入力区分であり、品質順位ではありません。新しいデータが
予測で、古いデータが適切な観測という場合もあります。入力はキャッシュし、パケット処理外で
更新することを推奨します。取得失敗で公開年齢や対応期間をリセットしてはいけません。
認証された取得経路と不可分なキャッシュ置換を推奨します。

適用した天体暦・EOP版、モデル・ソフトウェア版、予測範囲、補間、省略効果、
誤差評価方法など既知の出所と制限を運用文書に公開し、不明を明示します。
第6節には毎回必要な座標別情報を入れます。詳細メタデータを機械取得するサービスは
将来の課題で、基本パケットに未定義の拡張を足すものではありません。

### 5.4. 変化率と共通の時点

`Q = d(unwrapped P_G)/dt`、単位はturn/SI秒です。微分では0/1の折り返しを展開します。
固定の`1/86400`は概算の大きさであり、定義された変化率ではありません。

応答の`P_G`・`Q`・`E3`・`R`は同じ送信イベント`t3`を表します。
基準更新・キャッシュから異なる時点を混ぜてはいけません。誤差不明でも`t3`までの伝播は
できますが、有限上限を捏造してはいけません。応答作成中の更新は不可分なスナップショット
などで整合させます。E2は受信イベントのままです。

## 6. Version 2パケット案

要求・応答とも160オクテット固定です。0〜75は第4節の配置を使いますが、
Versionは2とし、以下のV2固有規定を適用します。76以降は今回の新配置です。

| Offset | Octets | Field |
|---:|---:|---|
| 76 | 16 | Request Token |
| 92 | 8 | Reference Solar Phase |
| 100 | 8 | Solar Phase Rate |
| 108 | 4 | Solar Model ID |
| 112 | 24 | ED Quality Descriptor |
| 136 | 24 | SP Quality Descriptor |

整数はビッグエンディアン、符号付きは2の補数です。拡張末尾はありません。
`-02`の128オクテット案を含む他の長さを拒否し、どのV2案か推測しません。
実験時には、この版を使うことを通信外で事前に揃える必要があります。

### 6.1. Request Token

再試行を含む要求ごとに、暗号学的に安全な乱数生成器で新しい非ゼロ128ビット
トークンを生成します。サーバーはバイト列をそのまま返します。対応する未消費要求に
一度だけ受け入れて消費します。有効時間・保留要求数は制限します。
認証ではなく照合用であり、位置や固定端末識別子を入れてはいけません。

### 6.2. 座標と変化率の符号化

EDは第4.2節の時刻印です。SPは`floor(P_G * 2^64)`で、ゼロも正当な深夜位相です。
利用可否はdescriptorで判断します。Qは符号付き`round(Q * 2^63)`、
最近接・偶数丸めです。V2のRも同じ丸めとします。桁あふれは拒否し、折り返しません。
Model 1の利用可能なR/Qは正です。Precisionは分解能で精度ではありません。
ED差分は年を含め、SP差分は円周で扱います。

### 6.3. 座標別品質記述子

112と136のそれぞれを起点として同じ相対配置を使います。

| Relative offset | Octets | Field |
|---:|---:|---|
| 0 | 1 | Supply State |
| 1 | 1 | Source Kind |
| 2 | 1 | Quality Flags |
| 3 | 1 | Coordinate Stratum |
| 4 | 4 | Coordinate Reference ID |
| 8 | 4 | Coordinate Uncertainty |
| 12 | 4 | Validity |
| 16 | 4 | Source Data Age |
| 20 | 4 | Source Update Age |

Supply Stateは0=値なし、1=基準源を対応範囲内で追従、2=更新途絶または対応範囲外の
自走保持、3=値はあるが供給状態不明、4〜255=予約です。
追従は観測値使用や精度評価済みを意味せず、自走保持でも誤差既知・不明の両方があり得ます。

Source Kindは0=不明、1=天文計算、2=座標の直接供給、3=上流NEPP、
4=複数基準源の組み合わせ、5〜255=予約です。直近の供給経路を表し、精度順位では
ありません。詳細な上流出所は文書で示します。

Quality Flagsはbit 0が誤差評価済み=1／不明=0、
bits 2:1が予測情報（0=不明、1=予測なし、2=予測使用、3=予約）、
bits 7:3は予約ゼロです。
予測使用とは、入力が観測範囲を越えた予報または外挿であることです。
対応範囲内の通常の補間は予測ではありません。広告区間全体に必要な入力を対象にします。
検証された変化率・区間内のローカル伝播だけで追加の予測区分にはしません。
区間または入力分類が不明なら、予測使用がすでに分かる場合を除き不明とします。
下流で上流の不明情報を既知に変えてはいけません。

Coordinate Stratumは既知なら1〜15、不明なら0で、利用可能な記述子の16〜255は不正です。
EDは既知必須で基本Stratumと一致します。SPは別経路・別Stratumでも構いません。
中継では上流の座標Stratumに1を加え、15を越えるならその座標を利用可能として
提供しません。Source Kind 4では寄与する既知Stratumの最大を使い、関係経路が一つでも
不明なら不明とします。ED経路に不明があれば、EDの既知Stratum要件を満たせません。

Reference IDはサーバーの出所文書内で識別する32ビット値で、世界的・認証済みIDでは
ありません。ゼロは未指定です。EDのIDは基本Reference IDと一致させます。
IDやKindが異なるだけでは独立した基準源の証明になりません。

値なしの記述子は全ゼロとし、SP値なしなら位相・変化率・モデルもゼロにします。
利用可能なSPのゼロは深夜です。交換成功には利用可能なEDが必要で、SPは任意です。
未知のSupply State、予約フラグ、予約予測区分は当該座標を無効にします。
未知のSource Kindは出所不明と扱い、それだけで座標を捨てません。

### 6.4. 不確かさ・有効期間・年齢

Coordinate Uncertaintyは符号なし`ceil(B * 2^32)`で、EDではED単位、
SPではturn単位です。bit 0が0なら必ず`0xffffffff`（不明）で、ゼロではありません。
bit 0が1なら最大`0xfffffffe`、SPではさらに`0x80000000`未満とします。
半周の上限では有用な位相制約になりません。桁あふれ・上限評価不能は不明とし、
飽和させたり、その理由だけで値なしにしてはいけません。

評価済みBは、送信した線形変化率で進めたときの広告区間全体のED絶対誤差または
SP円周誤差の保守的な最大見積もりです。標準偏差でも無条件の保証でもありません。
定義モデルに対する基準源、実現、時点転送、時計、計算、量子化、伝播の誤差を含めます。
第3.2節で省いた物理効果はこのモデル誤差上限の外であり、物理的精度を検証済みと
主張してはいけません。受信側・ネットワーク・位置誤差はクライアントの追加要因です。

Validityは`t3`からの符号なしSI秒で、0は`t3`のみ、1〜3600は前方区間、
`0xffffffff`は不明、それ以外は予約です。評価済み誤差には既知Validityが必要です。
誤差不明でも既知の利用想定区間を持てますが、数値精度の約束ではありません。
有効期間不明は無期限ではありません。クライアントは有限のローカル鮮度方針の下で
未評価と明示して表示できます。

ED上限はE3/Rの前方区間に加え、受信時点E2の誤差も覆います。受信時刻印を完全と
誤認させないためです。それを評価できなければED誤差不明とします。

Source Data Ageは最古の関連入力製品の公開時点からのSI秒切り上げです。
Source Update Ageは最後に取り込んだ基準源イベントからのSI秒切り上げであり、
パケット受信時やキャッシュ参照時ではありません。ともに`t3`基準、
`0xffffffff`は不明または表現不能、ゼロは既知の年齢ゼロです。品質保証ではありません。
中継は年齢を保持・加算し、ホップごとにリセットしません。基準イベントの時点対応が
不明なら年齢も不明です。値なし記述子のみ、正規形の全ゼロを使います。

V2の基本Root DispersionはV1と異なり`0xffffffff`を不明として使います。
有限値は従来の符号なし16.16 SI秒で、根拠ある時間誤差見積もりが必要で、
ED記述子と矛盾してはいけません。ED誤差不明ならRoot Dispersionも不明必須です。
保守的な換算ができない場合、ED上限既知で時間分散不明は許されます。
ゼロで不明を代用しません。Root Delayも意味はV1と同じですが、V2では推定不能なら
`0xffffffff`を不明に使い、巨大な測定遅延と解釈しません。

基本FlagsはED供給を表します。追従はStatus 0または1、自走保持は2、
供給状態不明は1、ED値なしは3 / Stratum 16です。誤差未評価だけで非同期にしません。
V2クライアントは記述子を評価し、Status 0から精度を推測してはいけません。
ED値なしの場合、基本Reference ID、Reference/E2/E3/R/ModelとED記述子をゼロにします。
OriginとTokenは要求を照合するため、そのまま返します。

品質が用途に十分かはクライアントが決めます。誤差不明のED/SPを使えますが、
精度検証済みとは表示しません。精密用途では拒否できます。構造不正、未知の座標モデル、
値なしは品質不明とは別です。SP不正だけで正常なEDまで捨てる必要はありません。

### 6.5. 鮮度と伝播

Validityを受信から再起算せず、伝送を含む`t3`からの経過時間を考慮します。
サーバー上限がまだ適用できると主張するには、経過時間の上側見積もりが区間内であり、
クライアントの時間・位置誤差も含める必要があります。時間誤差不明なら、
保証された年齢上限・総合誤差上限を主張できません。

期限後の表示は古い値または別途識別したローカル予測としてのみ続行でき、
サーバーの元の有効性を主張しません。不明Validityには有限のローカル方針が必要です。
中継は上流の不確かさと有効期間を保守的に伝播します。新しい応答を送るだけでは、
期限切れ上流の上限を更新できず、新たな有限上限には独立した根拠が必要です。

## 7. 要求・応答・検証

### 7.1. 版の判別と増幅対策

サーバーはVersionビットを見てから解析器を選びます。空、未知の版、不正な要求、
非対応Modeは応答せず破棄します。本案では版交渉のエラーパケットを定義しません。

V1提供を有効にした場合のみ、第4節に従ってV1要求へV1応答を返します。
V2専用サーバーはV1要求を黙って破棄し、V2として解釈したりV2応答を返したりしては
いけません。受理したV2要求には太陽情報の有無にかかわらずV2を返します。
要求と異なるVersionで応答してはいけません。旧クライアントがV2を読める必要はありません。

V2要求は160オクテットです。76オクテットのVersionだけ2へ変えた要求は不正です。
ユニキャスト要求に対して最大1応答とし、応答UDPペイロードは要求より大きくしては
いけません。レート制限、キャッシュや要求ごとの処理量の上限が必要です。
同じ長さにしても、送信元詐称による反射攻撃そのものはなくなりません。

### 7.2. V2クライアント要求

FlagsはStatus 3・Version 2・Mode 3（`0xd3`）、Stratumは16、Pollは選択値
（既定6）、Precisionは0です。Transmit EDへE1を設定し、未取得なら12ゼロの
初期取得要求とします。新しいRequest Tokenを設定し、他はすべてゼロにします。
この形式に従わないV2要求は拒否します。

クライアントは単調時計の送信時点`m1`を記録します。サーバーは受信ED `E2`を記録し、
要求Transmitを応答Originへそのままコピーします。送信時点`t3`にE3、R、太陽状態を
評価します。応答にはサーバーのED状態、Stratum、基準情報、推奨Poll、Precisionを載せます。
Reference EDは最後に取り込んだ基準イベントでのEDで、不明ならゼロです。
ファイル取得時刻ではありません。トークンは要求をコピーし、予約ビットはゼロとします。
ED記述子と基本フィールドは第6.4節に従い一致させます。
利用可能な各座標について、既知の情報を伝え、不明を明示します。

### 7.3. 応答の受け入れ

単調時計の受信時点`m4`と、可能なら受信ED `E4`を記録します。使用前に以下を確認します。

- 長さ160、Version 2、Server Mode 4、構造フィールドが正当。
- 送信元IPアドレスとUDPポートが問い合わせたエンドポイントと一致する。
- トークンが未消費のV2要求と一致する。
- Originが要求Transmitと一致する（初期取得のゼロも含む）。
- Flags Statusが3以外、Stratumが1〜15、ED Model IDが対応範囲内。
- E2・E3が存在し、Rが正で、ED記述子が整合する。
- 既知の時間・不確かさがローカル方針を満たし、不明は明示的に扱われる。

ED記述子と基本フィールドの一致も確認します。不明な品質は明示的なローカル方針で扱います。
続いてSP記述子、モデル、正のQ、不確かさ、有効期間を独立に確認します。
不正・非対応の太陽情報を位相に使ってはいけませんが、検証済みEDは残して構いません。
太陽モデルが不明なことと、V2非対応は別です。

モデル不一致、過大な遅延、不自然な変化はサンプル拒否の理由とすべきです。
精度やStratumの自己申告だけで相手を信用できるわけではありません。

## 8. 同期と表示

### 8.1. EDの4座標同期

交換中のED速度が局所的に整合する場合、次を使います。

```text
theta_ED = ((E2 - E1) + (E3 - E4)) / 2
delta_ED = (E4 - E1) - (E3 - E2)
```

thetaが正ならクライアントが遅れています。delta_EDのSI秒への換算にはその時点の
ED速度を使い、固定の一年秒数を使いません。高精度が必要なら共通の物理時間への写像や
高次モデルが必要です。NTP型の推定と同様、経路非対称性の限界があり、片道遅延の
厳密な測定ではありません。

### 8.2. 初期取得と共通のローカル基準

E1/E4がない場合、そのゼロを実在のEDとして4座標式へ代入してはいけません。
限定的な初期推定では次を使えます。

```text
d_total = m4 - m1
d_server ~= (E3 - E2) / R
d_path = d_total - d_server
d_oneway_estimate = d_path / 2
ED_at_receive ~= E3 + R * d_oneway_estimate
P_G_at_receive ~= frac(P_G_at_transmit + Q * d_oneway_estimate)
```

安定した単調時計、局所的に有効なR/Q、測定誤差内で非負の遅延が前提です。
未評価の入力では暫定見積もりであり、確立した上限ではありません。
矛盾するサンプルは拒否します。小さな負の残差は、明示した測定許容幅内でのみゼロへ
丸められます。半往復遅延は対称経路の仮定です。受信までの経過時間の保守的な上限には、
半分だけでなく非負の経路往復遅延全体と測定誤差を考慮します。

EDと位相は同じ単調時間の基準から、それぞれの速度で進めます。受信からの経過をuとすると、

```text
P_L(now) = frac(P_G_at_receive + Q * u + L(now) / 360度)
```

経度を変えてもEDやサーバー状態は変わりません。有効性は`t3`からの時間上限
（通信中の経過とuを含む）が当該座標の既知Validity内にあることを確認します。
端末の位相誤差評価には、時間誤差×位相速度、経度誤差÷360度も加えます。
時計補正、スリープ復帰、発振器の不連続では再評価または再取得が必要です。
壁時計の変更を物理的経過時間として扱ってはいけません。

時間・基準時刻印・変化率の誤差が不明なら、伝送年齢の保証された上限は得られません。
Validity不明は第6.5節に従い、無期限とは扱いません。

### 8.3. 表示と予定

ED同期、太陽品質、選択した場所、期限切れを区別して表示することを推奨します。
手動選択した場所はその旨を明示します。位置許可を拒否してもEDは利用できます。
1から0への循環は正常であり、時計故障ではありません。

局所位相だけでは、毎周繰り返すため瞬間を一意に指定できません。待ち合わせには
基準場所・経度と、EDの探索区間などで「どの回か」の指定も必要です。
将来のEDへの変換には天文予測が必要で、短い有効期間のパケットは長期の予定計算を
保証しません。渋谷を選ぶかGPS現在地を使うかはクライアントの選択であり、新しい
プロトコルのタイムゾーンを作るわけではありません。

### 8.4. ED自走保持・時計制御・複数基準源

両版とも最後の同期状態`(ED0, R0)`を保持し、短期間は`ED ~= ED0 + R0 * delta_t`と
推定できます。長期間では、根拠ある高次モデル
`ED0 + R0*delta_t + 0.5*A0*delta_t^2`や天文予測を推奨します。
`A0 = dR/dt`であり、本書のどちらの基本パケットにもA0は載りません。

常時接続を要求してはいけませんが、新しい同期測定と予測・自走保持は区別します。
不確かさの増加を追跡し、品質上限を超えたら有効な同期との表示を止めることを推奨します。
V1に有効期間フィールドがないことは、無期限外挿の許可ではありません。
V2はEDとSPに別々のValidityを持ち、区間が異なっても構いません。

繰り返しの交換でED時計を制御することを推奨します。小さな補正は通常滑らかに、大きな
補正は時刻の飛びと共通基準の再設定が必要になる場合があります。通常のED表示は後退させない
ことを推奨しますが、虚偽の精度で補正を隠してはいけません。位相の循環や場所変更はED補正とは
別の現象です。

信頼性が必要な場合は独立した複数源を推奨します。Stratum、遅延・分散、測定遅延、
過去の安定性、モデル、天文的出典、基準源の独立性などで選択します。ホスト名が違うだけでは
モデルや観測が独立とは限りません。不確かさやモデル差で説明できない不一致源は除外することを
推奨します。複数の未認証源を使っても暗号学的な信頼は生まれず、同期ループや共通障害も残ります。

不明な品質を誤差ゼロとして順位づけず、未評価の基準源は明示した方針でのみ利用します。

## 9. バージョン互換性と切り替え

V1とV2はワイヤ互換性のない別のプロトコルです。サーバー・クライアントともV2専用を
認めます。V1サービスの継続は必須ではなく、V1専用アプリでV2専用エンドポイントを
使うには更新が必要です。V1形式の記載や任意実装は、配備環境の後方互換性の約束では
ありません。運用者はベータV1サービスを終了できます。

| クライアント | サーバー | 結果 |
|---|---|---|
| V1 | V1 | 従来のED交換 |
| V1 | V1/V2両対応 | 変更のないV1 ED交換 |
| V1 | V2専用 | 要求破棄。クライアント更新が必要 |
| V2専用 | V2専用または両対応 | V2交換。V1へ切り替えない |
| V2専用 | V1専用 | 互換応答なし。利用不可 |
| V2対応 | V1/V2両対応 | V2でEDと太陽情報、または太陽利用不可のED |
| 切り替え有効の両対応クライアント | V1 | 別のV1トランザクションでEDのみ取得可能 |

V2クライアントはV2要求を送ります。初期タイムアウトの推奨値は2秒です。
自動V1フォールバックは必須ではありません。別途V1も実装したクライアントが、
明示した可用性方針で許す場合にのみ切り替えられます。V2専用クライアントは利用不可と
報告します。無応答は使えるV2応答が届かなかったことであり、非対応の証明ではありません。
V2要求に届いたV1応答をダウングレードとして受け入れず、V1は別に追跡するトランザクション
として第4節のルールに従います。

任意の切り替えを有効にしたクライアントは、V1の毎回の問い合わせでV2を試さず、
例えば15分に揺らぎを加えた間隔や、回線・
サーバー変更時に再確認することを推奨します。記憶する版の選択はエンドポイント単位・
有限期間とし、ホスト名だけで永久保存しません。V2必須の設定も可能です。
正常なV2応答で太陽情報だけが使えないことは切り替え理由にしません。

任意の切り替えが有効な場合、攻撃者がV2通信を落とすとV1へ誘導できるため、未認証のダウングレードリスクを
文書化する必要があります。どちらの版も、応答があっただけで完全性は保証されません。

公開ベータのエンドポイントをV2専用へ切り替える前に、旧クライアントが動かなくなる
可能性、必要なアプリ更新、切り替え時期を告知することを推奨します。
併用期間や別V1エンドポイントの提供は任意です。草案公開だけで切り替えたことにはなりません。

## 10. 関連技術と設計意図

### 10.1. UTC・TAI・UT1

UTC/TAIは原子時の基盤、UT1は地球の自転を表します。NEPPは時間計量そのものを
置き換えるのでなく天文座標を配ります。基準源がUTC/NTP経由で座標を計算する必要は
ありません。固定の一年秒数で定義しないことと、実装で
時間計量に依存しないことは別です。
[BIPM Time Metrology](https://www.bipm.org/en/time-metrology)を参照してください。

### 10.2. NTP・PTP

[NTPv4](https://www.rfc-editor.org/rfc/rfc5905.html)から、4イベントによる遅延・
オフセット推定、ポーリング、Stratum、時計制御の考え方を継承します。NEPPは非等速の
EDに応用し、変化率も配信します。96ビット時刻印やFlagsはNTP互換ではなく、
NTPポートでNTPとして提供してはいけません。

[IEEE 1588/PTP](https://www.nist.gov/el/intelligent-systems-division-73500/ieee-1588-systems)
は時間配信システム内の時計を協調させます。NEPPはPTPと同等の精度や仕組みを主張せず、
良質な基礎時計を不要にしません。NTP/PTPは天文計算のホスト時計を支えられ、
NEPPはその上で配る座標を定めます。

NTP/PTPは計算用ホスト時計を支えられますが必須依存ではありません。
NEPPネットワークのホップはNEPP、基準系からStratum 1への接続は実装固有で、
第3.4節の時点転送責任を持ちます。

### 10.3. Unix time・Julian Date

[POSIXのEpochからの秒数](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16)
や[Julian Date](https://aa.usno.navy.mil/data/JulianDate)も日時を数値で表します。
数値化そのものを新規性とはしません。Julian Dateは日数とその小数部であり、精密利用には
時系の指定が必要です。EDの小数部は等速の経過時間ではなく、太陽黄経に対応します。

### 10.4. 十進時刻・Swatch Internet Time

十進数で分割するだけでは新しい提案ではありません。
[Swatch Internet Time](https://www.swatch.com/th-th/internet-time.html)は、Biel Mean Timeを
基準に通常の24時間の日を1000 beatsに分割します。NEPPの局所太陽位相は選択した経度と
見かけの太陽運動に従って変わり、固定の民用日を十進数へ換算するものではありません。

### 10.5. 平均太陽時・視太陽時・民用タイムゾーン

平均太陽時は太陽運動を平均化し、視太陽時は太陽の時角に従います。両者には均時差があり、
本案は視太陽時を正規化したものです。UTCに経度を加えるだけではありません。
[USNOの解説](https://aa.usno.navy.mil/faq/eqtime)を参照してください。

民用タイムゾーンは局所太陽時からずれる代わりに共通の生活時間を提供します。
NEPPはその廃止や法的な時間を規定せず、世界共通の瞬間と、その場所の日周の意味を分けます。
提案するのはED同期、基準位相・速度・品質の配信、私的な端末内経度適用の組み合わせです。
太陽時自体の発明や、社会的採用の正しさを証明するものではありません。

## 11. セキュリティ・プライバシー・運用

両版とも未認証です。偽装、再送、不正な基準源、遅延操作、偽の不確かさ、DoSが可能です。
V2乱数は経路外からの応答照合を強めますが、MAC・署名・認証ではありません。
V1のOrigin照合は特にゼロ時刻印の初期取得で弱く、安全な同期と宣伝してはいけません。

[Network Time Security](https://www.rfc-editor.org/rfc/rfc8915.html)はNTPの先行技術であり、
NEPPへ自動的に適用できるものではありません。NEPPの認証形式と版切り替え保護は別の
設計が必要です。高い完全性が必要な用途には、適切に検討された認証手段を使います。

要求には緯度・経度・地名・永続的利用者IDを含めません。トークンや予約領域などへ
位置を埋め込んではいけません。位置サービスや手動地点保存は端末内に置きます。
一方サーバーからは送信元IPと問い合わせ時刻が見えるため、ネットワーク匿名性は
主張しません。記録を最小限にし、一時的なレート制限状態にも上限を設けることを推奨します。

高コストの天文計算より先に長さ・版の確認とレート制限を行い、EOP更新を別処理にして
失敗時方針を定めます。太陽情報の不調で、有効にしている版のEDサービスを不要に停止
させない設計としますが、V1サービスの継続を要求するものではありません。
実験用の設定可能なdynamic/private UDPポートを使い、`56377`は配備上の選択であって
IANAの割り当てではありません。

## 12. 符号化例と検証計画

以下は天文予測ではなく合成符号化例です。

| Quantity | Input | Expected result |
|---|---|---|
| V2 bootstrap flags | Status 3, Version 2, Mode 3 | `d3` |
| V2 tracking server flags | Status 0, Version 2, Mode 4 | `14` |
| Reference SP | 0.5 | `80 00 00 00 00 00 00 00` |
| Reference SP | 0.25 | `40 00 00 00 00 00 00 00` |
| Local SP | P_G=0.9, L=+90 degrees | 0.15 |
| Local SP | P_G=0.1, L=-90 degrees | 0.85 |
| Rate Q | 2^-16 turns/s | signed integer 2^47 |
| Uncertainty | B=2^-20 ED or turns | unsigned integer 4096 |
| Unknown uncertainty | bit 0 clear | `ff ff ff ff` |
| Evaluated, prediction unknown | Quality Flags | `01` |
| Unevaluated, prediction used | Quality Flags | `04` |

160オクテット初期要求はbyte 0=`d3`、1=`10`、2=`06`、
76〜91=`01 02 ... 10`、残り全ゼロです。固定トークンは試験専用です。
要求は応答品質を含みません。

利用可能・未評価SPの例はstate=1、kind=1、flags=0、stratum=1、reference ID=0、
uncertainty=`ffffffff`、validity=60、両age=`ffffffff`です。
位相ゼロでも値なしではありません。値なしSPは24ゼロバイトで、位相・変化率・モデルもゼロです。

配備前に以下を試験します。

1. オフセット、バイト順、符号、丸め、桁あふれ、長さ160、128拒否、予約値拒否。
2. V2専用時にV1要求を黙って破棄しV2応答しないこと。任意にV1対応する場合は、
   V1ワイヤ回帰・既存iOS要求と、不明誤差を精密と偽らないV1方針も確認する。
3. エンドポイント・Token・Origin不一致、重複、期限、資源制限、増幅防止、第9節の全組合せ。
4. ED年境界・SP折り返し・負経度・極・手動地点。
5. ED/SP独立の値なし／値あり不明／評価済み行列、出所・Stratum・年齢・予測不明。
6. 既知ゼロ誤差と不明、有効期間不明と期限切れ、基準途絶、自走保持、中継品質伝播。
7. E2/E3/R/SP/Qの時点整合、基準転送遅延、不可分更新、時計ステップ、休止復帰、
   歩度ドリフト、非対称経路。
8. うるう秒安全なEOP補間、観測・予測境界、更新失敗、IERSを使わない直接基準源。

独立した天文試験値には受信時点、TT/TDB/UT1、天体暦・定数、放射時点、
光行差の規約、B/黄道傾斜、lambda、alpha_app、GAST、ED/R、P_G/Q、経度を記載します。
季節、折り返し、異なる日付を含めます。別の歳差・光偏向モデルのサービスをそのまま
正解値にせず、定義を合わせて比較します。許容差は根拠づけ、ビット数から推定しません。

本版は独立検証済み天文試験値や数値精度保証を提供しません。
一つのライブラリ内の往復変換だけでは、その検証に不十分です。

## 13. 実装状況と未決事項

既存V1 Python/iOSの動作は実験経験であり、本書の全要求の検証ではありません。
ローカルの実験用V2専用Pythonサーバーは160オクテット配置、品質記述子、
基本モデルの暫定計算を実装しています。両座標の誤差は未評価です。
過去のEOPによる健全性テストやUDPループバックテストは、独立した天文検証ではありません。
PythonのV1クライアントは残っています。ローカルのiOS 0.0.2 V2クライアントは
試験中であり、本書は配布済み0.0.1アプリや稼働サーバーを更新しません。

第1節の5方針が本版の基礎です。160オクテット配置、列挙値、3600秒上限、
固定小数点範囲はレビュー用の具体案であり、別途合意済みの配備パラメーターではありません。

V2を固定する前に確認する事項：

- 第3.2節の数値実現と独立試験値、省略物理効果、時系・変化率規約、対応年代。
- 現行Model ID 1計算との差分と移行判断。配備済み座標の意味を無断で変えない。
- 配置、不明マーカー、範囲、複数基準源のStratum規約。
- 基準系が時点と根拠ある誤差を確立する方法。
- 詳細メタデータの発見・通信方式。未要求URLを追加しない。
- 認証、認証された版交渉、登録方針。
- 未評価値、期限切れ、任意V1切り替えのクライアント表示と、ベータのアプリ更新・切り替え告知計画。

モデル境界は意図的です。同じモデルの計算改善と別物理モデルの導入は異なります。
将来の高精度基準源で品質向上は期待できますが、種類や小さいStratumだけでは保証しません。

## 14. IANA Considerations

本版ではIANAへの要求はありません。Version 2とSolar Model ID 1は実験的な提案値で、
IANA登録済みの値ではありません。将来はポート、モデル、拡張のレジストリを検討します。

## 15. 参考文献

### 15.1. 定義・モデルに関する資料

- [IAU 2006決議B1](https://iauarchive.eso.org/static/resolutions/IAU2006_Resol1.pdf)：推奨事項2・4。
- [SOFA Earth Attitude](https://www.iausofa.org/s/sofa_pn_c.pdf)：特にPnm06a・Nut06a・Obl06・Gst06a。
- [SOFA Miscellaneous Topics](https://www.iausofa.org/s/sofa_misc_c.pdf)：1.1節。平均春分点変換と本モデルを区別。
- [SOFA Astrometry](https://www.iausofa.org/s/sofa_ast_c.pdf)：4.3〜4.4節。重力項を基本モデルへ暗黙に取り込まない。
- [USNO天文暦用語集](https://aa.usno.navy.mil/faq/asa_glossary)：幾何位置・視位置の用語。

採用する効果の範囲は第3.2節の明示した式で決まります。資料を引用することは、
その全物理効果やライブラリ全体を実装するという主張ではありません。


- BCP 14：[RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.html)、
  [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174.html)。
- [IERS Conventions (2010), Technical Note 36](https://iers-conventions.obspm.fr/conventions/content/tn36.pdf)。
- [USNO: The Equation of Time](https://aa.usno.navy.mil/faq/eqtime)。

### 15.2. 関連技術・運用資料

- [NEPP英語版-02](draft-iwata-nepp-02.md)：過去版との比較用。本書の実装に必読ではありません。

- [IAU SOFA cookbooks](https://www.iausofa.org/cookbooks)。
- [IERS rapid service / Bulletin A](https://maia.usno.navy.mil/products/bulletin-a)。
- [BIPM Time Metrology](https://www.bipm.org/en/time-metrology)。
- [RFC 5905: NTPv4](https://www.rfc-editor.org/rfc/rfc5905.html)。
- [RFC 8915: Network Time Security](https://www.rfc-editor.org/rfc/rfc8915.html)。
- [NIST: IEEE 1588 Systems](https://www.nist.gov/el/intelligent-systems-division-73500/ieee-1588-systems)。
- [POSIX: Seconds Since the Epoch](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16)。
- [USNO: Julian Date](https://aa.usno.navy.mil/data/JulianDate)。
- [Swatch: Internet Time](https://www.swatch.com/th-th/internet-time.html)。

## 著者

Kenichi Iwata  
Tottori University, Japan  
Project: [nepp.kenic.jp](https://nepp.kenic.jp/)  
Contact: support@kenic.jp