7. Refreshing an Allocation (アロケーションの刷新)

Refreshトランザクションは、(a) 既存のアロケーションを刷新し、その有効期限を更新するか、(b) 既存のアロケーションを削除するために使用できます。

クライアントがアロケーションを引き続き使用したい場合、クライアントはアロケーションが期限切れになる前に刷新しなければなりません (MUST)。クライアントは、期限切れの約1分前にアロケーションを刷新することが推奨されます。クライアントがアロケーションを使用したくない場合は、明示的にアロケーションを削除すべきです (SHOULD)。クライアントは、他の理由で任意の時点でアロケーションを刷新してもよいです (MAY)。

7.1. Sending a Refresh Request (Refreshリクエストの送信)

クライアントが既存のアロケーションを直ちに削除したい場合は、値が0のLIFETIME属性を含めます。リクエストの他のすべての形式は、アロケーションを刷新します。

Refreshトランザクションは、アロケーションの有効期限タイマーを更新します。クライアントが、サーバーに有効期限タイマーをデフォルトの有効期間以外の値に設定してほしい場合、要求された値を持つLIFETIME属性を含めます。その後、サーバーは、Allocateトランザクションと同じ方法で新しい有効期限値を計算しますが、要求された有効期間が0の場合はサーバーがアロケーションを直ちに削除するという例外があります。

7.2. Receiving a Refresh Request (Refreshリクエストの受信)

サーバーがRefreshリクエストを受信すると、セクション4の規定に加えて、ここで言及されている特定のルールに従って処理します。

サーバーは、以下のように「期待有効期間 (Desired Lifetime)」と呼ばれる値を計算します: リクエストにLIFETIME属性が含まれており、属性値がゼロの場合、「期待有効期間」はゼロです。それ以外の場合、リクエストにLIFETIME属性が含まれている場合、サーバーはクライアントが要求した有効期間とサーバーの最大許可有効期間の最小値を計算します。この計算値がデフォルトの有効期間より大きい場合、「期待有効期間」は計算値です。それ以外の場合、「期待有効期間」はデフォルトの有効期間です。

後続の処理は、「期待有効期間」の値によって異なります:

• 「期待有効期間」がゼロの場合、リクエストは成功し、アロケーションは削除されます。

• 「期待有効期間」が非ゼロの場合、リクエストは成功し、アロケーションの有効期限は「期待有効期間」に設定されます。

リクエストが成功した場合、サーバーは以下を含む成功応答を送信します:

• 有効期限タイマーの現在の値を含むLIFETIME属性。

注意: サーバーは、「ステートレススタックアプローチ」を使用してUDP上のRefreshリクエストのべき等性を実装するために特別なことをする必要はありません。非ゼロの「期待有効期間」を持つ再送信されたRefreshリクエストは、単にアロケーションを刷新します。ゼロの「期待有効期間」を持つ再送信されたRefreshリクエストは、アロケーションが既に削除されている場合、437 (Allocation Mismatch) 応答を引き起こしますが、クライアントはこれを成功応答と同等として扱います（以下を参照）。

7.3. Receiving a Refresh Response (Refresh応答の受信)

クライアントが非ゼロの有効期間を持つRefreshリクエストに対する成功応答を受信した場合、応答に含まれる有効期限値でアロケーションデータ構造のコピーを更新します。

クライアントが、アロケーションを削除するリクエストに対する437 (Allocation Mismatch) エラー応答を受信した場合、アロケーションはもはや存在せず、クライアントはリクエストが実質的に成功したと見なすべきです。

---