Clarification on Telemetry Streams: Multi-Callback on_track vs. on_status Push for High-Frequency Data

[biodatanet]

In the latest Beckn v2.0.0 specification, there is a sharpened distinction between the Discovery, Transaction, Fulfillment, and Post-Fulfillment tags. Specifically, the documentation for the status tag suggests a move away from long-polling in favor of a "push notification" model via /on_status for significant state changes. Conversely, the track tag is defined as a mechanism to provide a real-time tracking handle (URL, WebSocket, etc.) for fulfillment progress.

Current Implementation:
Within UBC, Our telemetry data (State of Charge, voltage, current, and units consumed) updates every 60 seconds. we are treating /track as a protocol-level push stream:

1. The BAP calls /track once.

2. The BPP sends multiple /on_track callbacks every 60 seconds as the metrics change.

The Technical Conflict:
The status tag description explicitly mentions that the BPP may call the endpoint proactively once a subscription is initiated via a /status request. However, the track tag description emphasizes providing a "handle" or "link" to an off-network tracking UI or endpoint.

This creates ambiguity for high-frequency telemetry that isn't quite a "macro-state change" but is more frequent than a typical "fulfillment milestone."

Questions:

1. Does the track tag support a native Push Notification model? Is it architecturally valid within v2.0.0 for a BPP to send a continuous stream of /on_track callbacks (as signed Beckn messages) following a single /track request, or is /on_track strictly intended to be a single response that hands over a WebSocket/URL for off-protocol consumption?

2. Is High-Frequency Telemetry considered a "Significant State Change"?
   If /track is strictly for handle-over, should 60-second telemetry updates be routed through /on_status? While SoC percentage is a "metric," it effectively represents the "state" of the charging fulfillment. Does the protocol prefer the overhead of 60 signed
   HTTP POSTs per hour via /on_status, or is there a recommended pattern for "off-protocol" telemetry using the Tracking object?