



httpbis                                                          D. Hunt
Internet-Draft                                    Independent Researcher
Intended status: Standards Track                                   Quill
Expires: 2 October 2026                            AI Research Assistant
                                                           31 March 2026


      WATCH: A Proposed HTTP Method for Event-Driven Subscriptions
                   draft-hunt-httpbis-watch-method-00

Abstract

   This document proposes the addition of a WATCH method to the
   Hypertext Transfer Protocol (HTTP).  The WATCH method enables a
   client to subscribe to change notifications on a specified resource,
   shifting the communication model from client-initiated polling to
   server-initiated event delivery.

   The proposal includes two companion mechanisms: ALIVE, a client-
   initiated heartbeat protocol that maintains subscription validity and
   restores economic symmetry between client and server; and UNWATCH, a
   clean subscription termination method.  Together, these introduce an
   event-driven subscription layer into HTTP while preserving the
   protocol's existing simplicity and extensibility.

   This document incorporates formal terminology, a setup phase with
   confirmation handshake, refined jurisdictional compliance guidance,
   implementation recommendations, and protocol flow diagrams for all
   defined interaction patterns.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 2 October 2026.





Hunt & Quill             Expires 2 October 2026                 [Page 1]

Internet-Draft              WATCH HTTP Method                 March 2026


Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  The Polling Tax . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Existing Workarounds  . . . . . . . . . . . . . . . . . .   5
   3.  The WATCH Method  . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Connection Lifecycle Overview . . . . . . . . . . . . . .   5
     3.2.  Setup Phase and Confirmation Heartbeat  . . . . . . . . .   6
       3.2.1.  Successful WATCH connection with Setup Phase  . . . .   7
     3.3.  Server-Sent Events Transport  . . . . . . . . . . . . . .   8
   4.  The ALIVE Mechanism . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  Client-Initiated Heartbeats . . . . . . . . . . . . . . .   8
       4.1.1.  Heartbeat / Echo maintenance cycle  . . . . . . . . .   9
     4.2.  Economic Equilibrium  . . . . . . . . . . . . . . . . . .   9
     4.3.  Dead Client Eviction  . . . . . . . . . . . . . . . . . .  10
       4.3.1.  Automatic eviction after missed ALIVE deadline  . . .  10
   5.  Dispatches: Server-to-Client Event Delivery . . . . . . . . .  11
     5.1.  Dispatch delivery with continued WATCH connection . . . .  11
   6.  UNWATCH: Clean Termination  . . . . . . . . . . . . . . . . .  12
     6.1.  Client-initiated UNWATCH  . . . . . . . . . . . . . . . .  12
   7.  Server-Initiated Termination  . . . . . . . . . . . . . . . .  12
     7.1.  Server-initiated termination with reason  . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     8.1.  Cost Asymmetry Attacks  . . . . . . . . . . . . . . . . .  13
     8.2.  Ghost Subscriber Mitigation . . . . . . . . . . . . . . .  14
     8.3.  Jurisdictional Compliance in Persistent Connections . . .  14
   9.  Implementation Guidance . . . . . . . . . . . . . . . . . . .  14
     9.1.  Heartbeat Independence from Dispatch Processing . . . . .  15
     9.2.  Subscriber State Storage  . . . . . . . . . . . . . . . .  15
     9.3.  ALIVE Interval Sizing . . . . . . . . . . . . . . . . . .  15
   10. Comparison with Existing Protocols  . . . . . . . . . . . . .  16
   11. Reference Implementation  . . . . . . . . . . . . . . . . . .  16
   12. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  17



Hunt & Quill             Expires 2 October 2026                 [Page 2]

Internet-Draft              WATCH HTTP Method                 March 2026


   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Terminology

   The following terms are used throughout this document with specific
   technical meaning.  Each term maps to exactly one concept within the
   WATCH protocol.

   *WATCH Connection*  The persistent client-server relationship
      established when a client subscribes to change notifications on a
      resource via the WATCH method.  A WATCH connection is stateful:
      the server maintains subscription state for the duration of the
      connection.

   *ALIVE Interval*  The maximum duration, in seconds, between
      consecutive Heartbeats.  Established by the server and
      communicated to the client during the Setup Phase.  The client
      MUST send Heartbeats at intervals not exceeding this value to
      maintain the WATCH connection.

   *Heartbeat*  A lightweight message sent by the client to the server
      at regular intervals, confirming the client's continued presence
      and readiness to receive Dispatches.  A Heartbeat carries no body
      -- its purpose is purely existential: "I am still here."

   *Echo*  The server's response to a Heartbeat, confirming that the
      WATCH connection remains active and the Heartbeat was recorded.
      The Echo contains no new data; it is the Heartbeat reflected back.
      This allows the client to verify the server is still honoring the
      connection.

   *Dispatch*  An event payload pushed from the server to the client
      when the watched resource changes.  A Dispatch is the core
      deliverable of the WATCH protocol -- the data the client
      subscribed to receive.  Dispatches do not affect the WATCH
      connection's persistence; the connection continues after each
      Dispatch until explicitly terminated.

   *Setup Phase*  The initialization window between the server's
      acceptance of a WATCH request and the activation of the WATCH
      connection.  During the Setup Phase, the server communicates the
      ALIVE Interval and other parameters.  The connection activates
      only upon receipt of the Confirmation Heartbeat.

   *Confirmation Heartbeat*  The first Heartbeat sent by the client






Hunt & Quill             Expires 2 October 2026                 [Page 3]

Internet-Draft              WATCH HTTP Method                 March 2026


      after receiving Setup Phase parameters.  It confirms the client
      has received and accepted the ALIVE Interval terms, and triggers
      activation of the WATCH connection.  The eviction clock does not
      start until this Heartbeat is received.

      *Terminology design note:* Each term is intentionally distinct and
      non-overlapping.  "Heartbeat" and "Echo" form a directional pair
      (client-to-server and server-to-client).  "Dispatch" is reserved
      exclusively for event data delivery, preventing confusion with
      protocol maintenance messages.

2.  Problem Statement

   HTTP's request/response model requires the client to initiate every
   interaction.  When a client needs to monitor a resource for changes,
   the only native mechanism available within the HTTP method
   specification is repeated GET requests at regular intervals -- a
   pattern known as *polling*. While non-native extensions exist (see
   Section 2.2), no standard HTTP method provides subscription
   semantics.

2.1.  The Polling Tax

   In a polling model, each request/response cycle carries the full
   weight of HTTP overhead: headers (often 500+ bytes), authentication
   tokens, content-type negotiation, payload serialization, and status
   codes.  The vast majority of these cycles return identical data.

     +===========+===============================+==================+
     | Axis      | Impact                        | Scale Factor     |
     +===========+===============================+==================+
     | Bandwidth | ~1KB+ overhead per poll, most | N clients x F    |
     |           | returning "no change"         | polls/sec x 1KB  |
     +-----------+-------------------------------+------------------+
     | Compute   | Server queries data store,    | CPU scales       |
     |           | serializes response, executes | linearly with    |
     |           | middleware on every request   | client count     |
     +-----------+-------------------------------+------------------+
     | Latency   | Changes detected only at next | Faster detection |
     |           | poll interval; average delay  | compounds axes 1 |
     |           | = interval / 2                | and 2            |
     +-----------+-------------------------------+------------------+

                                 Table 1







Hunt & Quill             Expires 2 October 2026                 [Page 4]

Internet-Draft              WATCH HTTP Method                 March 2026


2.2.  Existing Workarounds

   Several mechanisms have been developed to work around HTTP's pull-
   based limitation. *WebSockets* (RFC 6455) establish a persistent,
   full-duplex connection but abandon HTTP request/response semantics
   once upgraded. *Server-Sent Events* (SSE) allow server-to-client push
   over HTTP but lack a standardized subscription and heartbeat
   contract. *Long-polling* holds a connection open until data is
   available but reintroduces per-change overhead when the response
   triggers a new request. *Webhooks* reverse the flow by having the
   server POST to a client-provided URL, but require the client to
   operate its own HTTP server.

   Each approach solves part of the problem while introducing new
   complexity.  None provides a native, first-class HTTP verb for
   subscription semantics with built-in connection maintenance.

3.  The WATCH Method

   The WATCH method allows a client to express ongoing interest in a
   resource.  Upon receiving a WATCH request, the server validates the
   request, establishes a subscription, and begins delivering Dispatches
   to the client as changes occur.

3.1.  Connection Lifecycle Overview

   A WATCH connection proceeds through four distinct phases:
























Hunt & Quill             Expires 2 October 2026                 [Page 5]

Internet-Draft              WATCH HTTP Method                 March 2026


    +==============+===========+======================================+
    | Phase        | Initiator | Description                          |
    +==============+===========+======================================+
    | *1.          | Client    | Client sends WATCH /resource with    |
    | Request*     |           | authentication credentials           |
    |              |           | (transmitted via the standard        |
    |              |           | Authorization: Bearer TOKEN header,  |
    |              |           | commonly referred to as an API key). |
    |              |           | Server validates credentials, checks |
    |              |           | jurisdictional compliance, and       |
    |              |           | registers the pending subscription.  |
    +--------------+-----------+--------------------------------------+
    | *2.  Setup*  | Server    | Server responds with ALIVE Interval, |
    |              |           | subscriber ID, and connection        |
    |              |           | parameters.  The eviction clock is   |
    |              |           | NOT yet running.  Client has a setup |
    |              |           | window to configure its Heartbeat    |
    |              |           | timer and evaluate the terms.        |
    +--------------+-----------+--------------------------------------+
    | *3.  Active* | Both      | Client sends Confirmation Heartbeat, |
    |              |           | activating the connection and        |
    |              |           | starting the eviction clock.  Client |
    |              |           | maintains Heartbeats at the ALIVE    |
    |              |           | Interval.  Server sends Echoes and   |
    |              |           | Dispatches.  Connection persists     |
    |              |           | through multiple Dispatches.         |
    +--------------+-----------+--------------------------------------+
    | *4.          | Either    | Connection ends via: client UNWATCH, |
    | Termination* |           | missed ALIVE deadline (automatic     |
    |              |           | eviction), server-initiated          |
    |              |           | termination with reason, or          |
    |              |           | connection failure.                  |
    +--------------+-----------+--------------------------------------+

                                  Table 2

3.2.  Setup Phase and Confirmation Heartbeat

   The Setup Phase addresses a critical race condition: without it, the
   server would communicate the ALIVE Interval and simultaneously start
   the eviction clock.  A client receiving a short interval might be
   evicted before it can parse the confirmation, configure its timer,
   and send its first Heartbeat.








Hunt & Quill             Expires 2 October 2026                 [Page 6]

Internet-Draft              WATCH HTTP Method                 March 2026


   The Setup Phase decouples term delivery from connection activation.
   The server sends connection parameters without starting the eviction
   clock.  The client reads the terms, configures its Heartbeat process,
   and sends a Confirmation Heartbeat to signal readiness.  Only upon
   receipt of this Confirmation Heartbeat does the server consider the
   WATCH connection active and begin the eviction clock.

   This also gives the client an opportunity to silently reject terms --
   if the ALIVE Interval is too aggressive for the client's
   capabilities, it simply does not send the Confirmation Heartbeat, and
   the connection never activates.  No resources are wasted.

3.2.1.  Successful WATCH connection with Setup Phase

    +==================+=================+===========================+
    | Client           | Direction       | Server                    |
    +==================+=================+===========================+
    | WATCH /api/      | WATCH ->        |                           |
    | resource,        |                 |                           |
    | Authorization:   |                 |                           |
    | Bearer TOKEN     |                 |                           |
    +------------------+-----------------+---------------------------+
    |                  | <- SETUP        | 200 OK, subscriber_id:    |
    |                  |                 | c7f2a91b, alive_interval: |
    |                  |                 | 15s, status:              |
    |                  |                 | awaiting_confirmation     |
    +------------------+-----------------+---------------------------+
    |                  | * Setup window  |                           |
    |                  | -- client       |                           |
    |                  | configures      |                           |
    |                  | Heartbeat timer |                           |
    +------------------+-----------------+---------------------------+
    | POST /api/alive/ | CONFIRM ->      |                           |
    | c7f2a91b         |                 |                           |
    | (Confirmation    |                 |                           |
    | Heartbeat)       |                 |                           |
    +------------------+-----------------+---------------------------+
    |                  | <- ECHO         | 200 OK, status: active,   |
    |                  |                 | ALIVE interval: 15s, OK - |
    |                  |                 | Eviction clock starts     |
    +------------------+-----------------+---------------------------+

                                 Table 3








Hunt & Quill             Expires 2 October 2026                 [Page 7]

Internet-Draft              WATCH HTTP Method                 March 2026


3.3.  Server-Sent Events Transport

   The WATCH response uses the text/event-stream content type (Server-
   Sent Events), providing a persistent, unidirectional channel from
   server to client over standard HTTP.  This transport is used for
   Dispatches and server-initiated messages.  Heartbeats and Echoes use
   separate HTTP request/response cycles on dedicated endpoints.

   The authentication token in the Authorization header (commonly
   referred to as an API key) is the same credential used throughout the
   WATCH connection lifecycle.  This token is validated during the
   initial WATCH request and is referenced for rate limiting,
   subscription caps, and jurisdictional compliance (see Section 8).

   ``` WATCH /api/tasks/3a8f HTTP/1.1 Host: example.com Authorization:
   Bearer TOKEN

   HTTP/1.1 200 OK Content-Type: text/event-stream X-Subscriber-Id:
   c7f2a91b X-Alive-Interval: 15 ```

4.  The ALIVE Mechanism

   The ALIVE mechanism makes WATCH economically and operationally
   viable.  It solves three problems simultaneously: connection liveness
   verification, cost asymmetry mitigation, and malicious actor
   deterrence.

4.1.  Client-Initiated Heartbeats

   Unlike traditional heartbeat protocols where the server pings the
   client and awaits a response (two messages, server-initiated), ALIVE
   shifts initiation to the client (one message, client-initiated).  The
   client MUST send a Heartbeat to its assigned endpoint at intervals
   not exceeding the ALIVE Interval:

   ``` POST /api/alive/c7f2a91b HTTP/1.1 Host: example.com

   HTTP/1.1 200 OK {"status": "alive", "alive_interval_seconds": 15} ```

      *Key design decision:* The Heartbeat carries no body.  Its purpose
      is purely existential.  This makes the round-trip cost
      approximately 200 bytes, compared to 1KB+ for a typical GET
      polling cycle.  Even at identical frequencies, Heartbeat-based
      maintenance represents an ~80% bandwidth reduction over polling.







Hunt & Quill             Expires 2 October 2026                 [Page 8]

Internet-Draft              WATCH HTTP Method                 March 2026


4.1.1.  Heartbeat / Echo maintenance cycle

         +=======================+==============+===============+
         | Client                | Direction    | Server        |
         +=======================+==============+===============+
         | POST /api/alive/      | HEARTBEAT -> |               |
         | c7f2a91b (empty body) |              |               |
         +-----------------------+--------------+---------------+
         |                       | <- ECHO      | 200 OK, ALIVE |
         |                       |              | interval: 15s |
         +-----------------------+--------------+---------------+
         |                       | * ~15        |               |
         |                       | seconds pass |               |
         +-----------------------+--------------+---------------+
         | POST /api/alive/      | HEARTBEAT -> |               |
         | c7f2a91b (empty body) |              |               |
         +-----------------------+--------------+---------------+
         |                       | <- ECHO      | 200 OK, ALIVE |
         |                       |              | interval: 15s |
         +-----------------------+--------------+---------------+

                                 Table 4

4.2.  Economic Equilibrium

   In a standard polling model, each request/response cycle imposes
   roughly symmetric costs on client and server.  WATCH without ALIVE
   breaks this symmetry: the client pays once while the server bears all
   ongoing costs.

   ALIVE restores equilibrium by imposing an ongoing cost on the client
   proportional to the number of active WATCH connections.  A client
   watching one resource sends one Heartbeat per interval.  A client
   watching one thousand resources sends one thousand Heartbeats per
   interval.  The cost of maintaining connections scales linearly with
   the burden placed on the server.

      *Security implication:* A malicious actor attempting to exhaust
      server resources by opening many WATCH connections must sustain a
      corresponding volume of Heartbeat traffic -- burning their own
      bandwidth and compute proportionally to the load they impose.










Hunt & Quill             Expires 2 October 2026                 [Page 9]

Internet-Draft              WATCH HTTP Method                 March 2026


4.3.  Dead Client Eviction

   The server maintains a last-seen timestamp for each subscriber.  A
   background process periodically compares each timestamp against the
   current time.  If the elapsed time exceeds the ALIVE Interval
   multiplied by a configurable grace multiplier (default: 1.5x), the
   WATCH connection is terminated and all associated state is released.

     +================+============+=======================+=========+
     | Parameter      | Defined by | Purpose               | Example |
     +================+============+=======================+=========+
     | ALIVE Interval | Server     | Maximum seconds       | 15s     |
     |                |            | between Heartbeats    |         |
     +----------------+------------+-----------------------+---------+
     | Grace          | Server     | Tolerance factor      | 1.5x    |
     | multiplier     |            | before eviction       |         |
     +----------------+------------+-----------------------+---------+
     | Effective      | Derived    | Interval x multiplier | 22.5s   |
     | deadline       |            | = actual cutoff       |         |
     +----------------+------------+-----------------------+---------+
     | Eviction sweep | Server     | Frequency of the      | 5s      |
     |                |            | eviction check        |         |
     +----------------+------------+-----------------------+---------+

                                  Table 5

4.3.1.  Automatic eviction after missed ALIVE deadline

   +==================+=====================+=========================+
   | Client           | Direction           | Server                  |
   +==================+=====================+=========================+
   | POST /api/alive/ | HEARTBEAT ->        |                         |
   | c7f2a91b         |                     |                         |
   +------------------+---------------------+-------------------------+
   |                  | <- ECHO             | 200 OK, ALIVE interval: |
   |                  |                     | 15s                     |
   +------------------+---------------------+-------------------------+
   |                  | * Client goes       |                         |
   |                  | silent (crash,      |                         |
   |                  | network loss, etc.) |                         |
   +------------------+---------------------+-------------------------+
   |                  | * 22.5s pass with   |                         |
   |                  | no Heartbeat        |                         |
   |                  | received            |                         |
   +------------------+---------------------+-------------------------+
   |                  | <- EVICTION         | Server ends WATCH       |
   |                  |                     | connection.  Subscriber |
   |                  |                     | state removed           |



Hunt & Quill             Expires 2 October 2026                [Page 10]

Internet-Draft              WATCH HTTP Method                 March 2026


   +------------------+---------------------+-------------------------+

                                 Table 6

5.  Dispatches: Server-to-Client Event Delivery

   A Dispatch is the core deliverable of the WATCH protocol.  When the
   watched resource changes, the server pushes an event to all active
   subscribers whose ALIVE status is current.  The WATCH connection
   persists after each Dispatch -- delivering an event does not
   terminate the subscription.

   A Dispatch payload includes the event type, relevant data, and a
   timestamp:

   data: { "event": "file_modified", "data": { "file": "config.yaml",
   "size_bytes": 2048, "modified_by": "dawson" }, "timestamp":
   "2026-03-28T14:32:07Z" }

   _Figure 1: Example Dispatch payload_

5.1.  Dispatch delivery with continued WATCH connection

   +======================+==================+=========================+
   | Client               | Direction        | Server                  |
   +======================+==================+=========================+
   | POST /api/alive/     | HEARTBEAT ->     |                         |
   | c7f2a91b             |                  |                         |
   +----------------------+------------------+-------------------------+
   |                      | <- ECHO          | 200 OK, ALIVE interval: |
   |                      |                  | 15s                     |
   +----------------------+------------------+-------------------------+
   |                      | * Watched        |                         |
   |                      | resource         |                         |
   |                      | changes          |                         |
   +----------------------+------------------+-------------------------+
   |                      | <- DISPATCH      | SSE event:              |
   |                      |                  | file_modified,          |
   |                      |                  | config.yaml, 2048 bytes |
   +----------------------+------------------+-------------------------+
   |                      | * Connection     |                         |
   |                      | persists --      |                         |
   |                      | not terminated   |                         |
   +----------------------+------------------+-------------------------+
   | POST /api/alive/     | HEARTBEAT ->     |                         |
   | c7f2a91b (confirms   |                  |                         |
   | client still active) |                  |                         |
   +----------------------+------------------+-------------------------+



Hunt & Quill             Expires 2 October 2026                [Page 11]

Internet-Draft              WATCH HTTP Method                 March 2026


   |                      | <- ECHO          | 200 OK, ALIVE interval: |
   |                      |                  | 15s                     |
   +----------------------+------------------+-------------------------+

                                  Table 7

6.  UNWATCH: Clean Termination

   The UNWATCH method provides a mechanism for clients to explicitly
   terminate WATCH connections.  While dead client eviction handles
   involuntary disconnections, UNWATCH enables graceful teardown with
   immediate resource release.

6.1.  Client-initiated UNWATCH

    +====================+===========+===============================+
    | Client             | Direction | Server                        |
    +====================+===========+===============================+
    | POST /api/alive/   | HEARTBEAT |                               |
    | c7f2a91b           | ->        |                               |
    +--------------------+-----------+-------------------------------+
    |                    | <- ECHO   | 200 OK, ALIVE interval: 15s   |
    +--------------------+-----------+-------------------------------+
    | POST /api/unwatch/ | UNWATCH   |                               |
    | c7f2a91b           | ->        |                               |
    +--------------------+-----------+-------------------------------+
    |                    | <-        | 200 OK, status: unsubscribed. |
    |                    | CONFIRMED | Connection terminated cleanly |
    +--------------------+-----------+-------------------------------+

                                 Table 8

7.  Server-Initiated Termination

   The server MUST be able to terminate WATCH connections unilaterally
   for rate limiting, authentication revocation, resource deprecation,
   jurisdictional policy changes, or administrative action.  In such
   cases, the server pushes a final event with type
   subscription_terminated and a reason field before closing the event
   stream.

   data: { "event": "subscription_terminated", "reason":
   "rate_limit_exceeded", "message": "Subscription limit reached for
   this API key.", "timestamp": "2026-03-28T15:01:44Z" }

   _Figure 2: Server-initiated termination payload_





Hunt & Quill             Expires 2 October 2026                [Page 12]

Internet-Draft              WATCH HTTP Method                 March 2026


7.1.  Server-initiated termination with reason

   +=============+=====================+===============================+
   | Client      | Direction           | Server                        |
   +=============+=====================+===============================+
   | POST        | HEARTBEAT ->        |                               |
   | /api/alive/ |                     |                               |
   | c7f2a91b    |                     |                               |
   +-------------+---------------------+-------------------------------+
   |             | <- ECHO             | 200 OK, ALIVE interval: 15s   |
   +-------------+---------------------+-------------------------------+
   |             | * Server decides    |                               |
   |             | to terminate        |                               |
   |             | (policy, rate       |                               |
   |             | limit, etc.)        |                               |
   +-------------+---------------------+-------------------------------+
   |             | <- TERMINATED       | SSE: subscription_terminated, |
   |             |                     | reason: rate_limit_exceeded,  |
   |             |                     | "Subscription limit reached." |
   +-------------+---------------------+-------------------------------+
   |             | <- CLOSED           | Event stream closed.          |
   |             |                     | Subscriber state removed      |
   +-------------+---------------------+-------------------------------+

                                  Table 9

8.  Security Considerations

8.1.  Cost Asymmetry Attacks

   Without ALIVE, WATCH creates an asymmetric cost profile exploitable
   for denial-of-service.  An attacker subscribing to N resources forces
   the server to maintain N subscription states and deliver events to N
   queues, at the one-time cost of N WATCH requests.  ALIVE mitigates
   this by requiring N Heartbeats per ALIVE Interval, making the
   attacker's ongoing cost proportional to the server's burden.

   Servers SHOULD additionally enforce per-API-key subscription caps
   (using the Bearer token from the Authorization header to identify and
   rate-limit individual clients), and MAY implement graduated ALIVE
   Interval requirements that increase with subscription count.










Hunt & Quill             Expires 2 October 2026                [Page 13]

Internet-Draft              WATCH HTTP Method                 March 2026


8.2.  Ghost Subscriber Mitigation

   Ghost subscribers -- clients that subscribe and then become
   unreachable without sending UNWATCH -- represent a resource leak.
   The ALIVE eviction mechanism ensures ghost subscribers are
   automatically cleaned up within one grace period.  Servers MUST NOT
   rely solely on TCP connection state for liveness detection, as
   intermediary proxies and load balancers may maintain connections
   beyond the client's actual availability.

8.3.  Jurisdictional Compliance in Persistent Connections

   WATCH connections differ fundamentally from transactional GET
   requests in their compliance implications.  A single GET request is a
   discrete act of data transfer: if a server inadvertently serves one
   response to a restricted jurisdiction, the exposure is limited to
   that single exchange.  A WATCH connection, however, is an ongoing
   relationship in which *every Dispatch constitutes a separate act of
   data transfer* that must independently satisfy applicable legal
   frameworks.

   This persistent nature means that standard jurisdictional
   verification practices -- IP-based geolocation, API key registration
   with identity verification, and sanctions list screening -- become
   more consequential for WATCH than for transactional verbs.  A server
   that performs geolocation checks only at request time for GET
   requests SHOULD perform them at subscription time for WATCH requests
   and SHOULD periodically re-validate for long-lived connections, as
   clients may change networks during an active WATCH connection (e.g.
   VPN activation, physical travel across jurisdictions).

      *Rationale:* Regulations including GDPR, U.S. sanctions law
      (OFAC), and national data sovereignty frameworks impose
      jurisdiction-dependent constraints on data transfer.  A WATCH
      connection persisting for hours or days may span regulatory
      changes, client network transitions, or evolving sanctions lists
      -- making point-in-time validation alone insufficient.
      Implementors should leverage existing geolocation infrastructure
      rather than introducing new client-declared headers, which are
      trivially spoofable and add overhead without meaningfully
      improving security.

9.  Implementation Guidance








Hunt & Quill             Expires 2 October 2026                [Page 14]

Internet-Draft              WATCH HTTP Method                 March 2026


9.1.  Heartbeat Independence from Dispatch Processing

   Client implementations SHOULD maintain the Heartbeat timer on an
   independent thread or asynchronous process that is not blocked by
   Dispatch processing.  If a Dispatch delivers a large payload that
   takes significant time to parse or act upon, a single-threaded client
   processing events synchronously may miss its ALIVE deadline and be
   evicted.

   The Heartbeat is an existential signal, not a data operation.  It
   should never compete with application logic for execution time.
   Implementations that cannot guarantee independent Heartbeat
   maintenance should evaluate the server's ALIVE Interval during the
   Setup Phase and decline the connection if it is not sustainable.

9.2.  Subscriber State Storage

   The WATCH protocol requires the server to maintain state for each
   active subscriber (subscriber ID, last-seen timestamp, event queue).
   The storage mechanism for this state is an implementation concern and
   is deliberately left unspecified.  Servers MAY use in-memory
   structures, in-memory data stores such as Redis, or durable databases
   depending on scale and reliability requirements.

   Notably, the state lookup burden of WATCH is lighter than that of
   polling.  In a polling model, the server authenticates and processes
   a full API key lookup on every request -- potentially thousands of
   times per second per client.  With WATCH, full authentication occurs
   once (at subscription time), and subsequent state lookups are limited
   to Heartbeat checks at the ALIVE Interval.  A server handling one
   thousand clients polling every second performs one thousand lookups
   per second; the same server with WATCH performs approximately sixty-
   seven (1000 / 15s interval).  Servers operating at scale should
   consider durable or distributed state management, but the per-client
   overhead is lower than the infrastructure it replaces.

9.3.  ALIVE Interval Sizing

   Servers should set the ALIVE Interval with consideration for the
   expected size and frequency of Dispatches (larger payloads warrant
   longer intervals), expected client capabilities (IoT devices may need
   longer intervals than desktop applications), and the server's own
   resource constraints (shorter intervals detect dead clients faster
   but increase Heartbeat traffic).

   For most applications, ALIVE Intervals between 10 and 60 seconds
   provide a reasonable balance between dead-client detection speed and
   Heartbeat overhead.



Hunt & Quill             Expires 2 October 2026                [Page 15]

Internet-Draft              WATCH HTTP Method                 March 2026


10.  Comparison with Existing Protocols

   +===============+==================+===========+=========+=========+
   | Feature       | WATCH            | WebSocket | MQTT    | Polling |
   +===============+==================+===========+=========+=========+
   | HTTP native   | Yes              | Upgrade   | No      | Yes     |
   +---------------+------------------+-----------+---------+---------+
   | Server push   | Yes              | Yes       | Yes     | No      |
   +---------------+------------------+-----------+---------+---------+
   | Heartbeat     | Client-initiated | Ping/Pong | Client  | N/A     |
   | model         |                  |           | PINGREQ |         |
   +---------------+------------------+-----------+---------+---------+
   | Bidirectional | No               | Yes       | Yes     | No      |
   +---------------+------------------+-----------+---------+---------+
   | Auto-eviction | Yes              | Timeout   | Yes     | N/A     |
   +---------------+------------------+-----------+---------+---------+
   | REST          | Yes              | No        | No      | Yes     |
   | compatible    |                  |           |         |         |
   +---------------+------------------+-----------+---------+---------+
   | Cost symmetry | Yes (ALIVE)      | Partial   | Partial | Yes     |
   +---------------+------------------+-----------+---------+---------+
   | Setup         | Yes              | Upgrade   | CONNECT | No      |
   | handshake     |                  |           |         |         |
   +---------------+------------------+-----------+---------+---------+

                                 Table 10

      *Note:* WATCH is most closely analogous to MQTT's subscribe/keep-
      alive pattern but operates natively within the HTTP ecosystem,
      preserving compatibility with existing infrastructure (proxies,
      load balancers, CDNs, API gateways) without requiring protocol
      upgrades or separate broker services.

11.  Reference Implementation

   A reference implementation has been developed to validate the
   protocol design described in this draft.  The implementation consists
   of two Python programs, available at https://github.com/dawsonhunt/
   watch-http-method :

   *watch_server.py* -- A Flask-based HTTP server implementing WATCH,
   ALIVE, and UNWATCH endpoints with filesystem monitoring (via the
   watchdog library), background eviction, a real-time web dashboard,
   and the complete Setup Phase including Confirmation Heartbeat
   handling.






Hunt & Quill             Expires 2 October 2026                [Page 16]

Internet-Draft              WATCH HTTP Method                 March 2026


   *watch_client.py* -- A command-line client that subscribes to the
   server's event stream, displays incoming Dispatches, and maintains
   the Heartbeat on an independent background thread.  A --skip-alive
   flag demonstrates automatic eviction when Heartbeats cease.

   The implementation demonstrates the complete WATCH connection
   lifecycle: request, Setup Phase, Confirmation Heartbeat, active
   Dispatch delivery, and termination via both UNWATCH and eviction.

12.  Conclusion

   The WATCH method addresses a fundamental gap in the HTTP
   specification: the absence of a native subscription mechanism.  By
   pairing server-push event delivery with client-initiated Heartbeats,
   the proposal achieves event-driven efficiency while maintaining the
   economic equilibrium and security properties that make HTTP's
   stateless model robust.

   The key insight underlying this proposal is that introducing
   statefulness into a stateless protocol is viable if and only if the
   cost of maintaining that state is distributed fairly between client
   and server.  ALIVE achieves this through what we term *subscription
   as economic contract*: the client pays ongoing costs (Heartbeats)
   proportional to the obligations it imposes on the server, and failure
   to pay results in automatic eviction.  The Setup Phase ensures both
   parties agree to terms before resources are committed, and elevated
   jurisdictional scrutiny addresses the regulatory exposure inherent in
   persistent data relationships.

   The authors invite discussion, review, and critique from the IETF
   community, and welcome collaboration on formal specification of the
   WATCH, ALIVE, and UNWATCH semantics toward an eventual Proposed
   Standard.

Authors' Addresses

   Dawson Hunt
   Independent Researcher
   Houston, TX
   Email: dawson.t.hunt@gmail.com


   Quill
   AI Research Assistant
   Email: quill.research@yahoo.com






Hunt & Quill             Expires 2 October 2026                [Page 17]
