---
url: https://doc.moq.dev/draft/moq-active-count.md
description: >-
  This document defines an extension for MoQ Transport draft-ietf-moq-transport
  that tells a subscriber how many NAMESPACE messages answering its
  SUBSCRIBE_NAMESPACE come before the first change.
---

# MoQ Active Count Extension

::: info
Rendered from the Internet-Draft source in this repository.
Submitted versions are on the [IETF datatracker](https://datatracker.ietf.org/doc/draft-lcurley-moq-active-count/).
:::

## Abstract

This document defines an extension for MoQ Transport [draft-ietf-moq-transport](https://datatracker.ietf.org/doc/draft-ietf-moq-transport/) that tells a subscriber how many NAMESPACE messages answering its SUBSCRIBE\_NAMESPACE come before the first change.
The subscriber then knows when it has caught up, instead of guessing from a quiet stream.

## Note to Readers

This document was generated by an AI model from the implementation at [github.com/moq-dev/moq](https://github.com/moq-dev/moq) and is maintained alongside it.
Submit an [issue](https://github.com/moq-dev/moq/issues) or [PR](https://github.com/moq-dev/moq/pulls) if this spec sucks and you want to fix anything.

## Conventions and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119](https://www.rfc-editor.org/rfc/rfc2119) [RFC8174](https://www.rfc-editor.org/rfc/rfc8174) when, and only when, they appear in all capitals, as shown here.

A suffix is **active** on a SUBSCRIBE\_NAMESPACE stream from a NAMESPACE message carrying it until a NAMESPACE\_DONE message carrying it.
A subscriber is **caught up** on a SUBSCRIBE\_NAMESPACE once it has read Count ([Counting](#count)) NAMESPACE messages after REQUEST\_OK, immediately on a Count of 0.

## Introduction

A publisher answers SUBSCRIBE\_NAMESPACE with a NAMESPACE message for each suffix it already advertises under the subscription's prefix, then keeps the stream open to report changes.
Nothing on the wire separates the two, so a subscriber cannot tell "there are no broadcasts" from "they have not arrived yet".
The best it can do is wait for the stream to go quiet, which is slow when there is nothing to send and wrong when the network stalls partway.

This extension has the publisher put on its REQUEST\_OK how many NAMESPACE messages come before the first change.

## Setup Negotiation

An endpoint declares this extension with the following Setup Option ([draft-ietf-moq-transport](https://datatracker.ietf.org/doc/draft-ietf-moq-transport/) Section 10.3):

```
ACTIVE_COUNT Setup Option {
  Option Key (vi64) = 0x40B64
  Option Value (vi64) = 1
}
```

A receiver MUST ignore the value.
The extension is negotiated when both endpoints declare the option, and applies to every SUBSCRIBE\_NAMESPACE on the session in both directions.
An endpoint MUST NOT declare the option on a version of [draft-ietf-moq-transport](https://datatracker.ietf.org/doc/draft-ietf-moq-transport/) without the NAMESPACE message.

## Counting {#count}

When the extension is negotiated, a publisher MUST include the following parameter in the REQUEST\_OK answering a SUBSCRIBE\_NAMESPACE:

```
ACTIVE_COUNT Parameter {
  Type (vi64) = 0x40B66
  Value (vi64) = Count
}
```

The publisher MUST send exactly Count NAMESPACE messages immediately after REQUEST\_OK, before any other message on the stream, making active each suffix it advertises to the subscriber when it answers, one message per suffix; later changes follow as usual.
A suffix the publisher does not advertise to this subscriber, such as one whose path loops back through it, is neither sent nor counted.

A subscriber counts every NAMESPACE message toward Count, including any it discards on receipt.

A subscriber MUST close the session with a PROTOCOL\_VIOLATION if the REQUEST\_OK answering a SUBSCRIBE\_NAMESPACE omits the parameter when the extension is negotiated, or carries it when it is not.
An endpoint MUST close the session with a PROTOCOL\_VIOLATION if a REQUEST\_OK answering any other request carries the parameter.

## Security Considerations

The count reveals no more than the NAMESPACE messages that follow it.
A publisher that promises more than it sends can only delay the subscriber's notion of having caught up, which it could equally do by withholding NAMESPACE messages.

## IANA Considerations

This document requests the following registrations.
High, distinctive values are requested to avoid the low ranges reserved by [draft-ietf-moq-transport](https://datatracker.ietf.org/doc/draft-ietf-moq-transport/) and to minimize collisions with provisional registrations by other extensions.

### MOQT Setup Options

This document requests one registration in the "MOQT Setup Options" registry ([draft-ietf-moq-transport](https://datatracker.ietf.org/doc/draft-ietf-moq-transport/) Section 15.4), whose policy is Specification Required.

| Value   | Name            | Reference     |
|:--------|:----------------|:--------------|
| 0x40B64 | ACTIVE\_COUNT | This Document |

### MOQT Message Parameters

This document requests one registration in the "MOQT Message Parameters" registry ([draft-ietf-moq-transport](https://datatracker.ietf.org/doc/draft-ietf-moq-transport/) Section 15.7).

| Value   | Name            | Carried In | Reference     |
|:--------|:----------------|:-----------|:--------------|
| 0x40B66 | ACTIVE\_COUNT | REQUEST\_OK | This Document |

Both values are even, so each is a bare varint.

## Normative References

* [draft-ietf-moq-transport](https://datatracker.ietf.org/doc/draft-ietf-moq-transport/)

## Acknowledgments

This document was drafted with the assistance of Claude, an AI assistant by Anthropic.