Skip to content
104 changes: 71 additions & 33 deletions draft-ietf-moq-transport.md
Original file line number Diff line number Diff line change
Expand Up @@ -2187,6 +2187,7 @@ REQUEST_ERROR Message {
Length (16),
Request ID (i),
Error Code (i),
[Retry Interval (i)],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In terms of framing, I think I'd prefer to not split error codes and instead make the Retry Interval 'optional' by reserving 0 as a special value that's equivalent to it not being present.

This also avoids us having a discussion about which of the error codes should be retryable.

Error Reason (Reason Phrase),
}
~~~
Expand All @@ -2196,66 +2197,89 @@ REQUEST_ERROR Message {

* Error Code: Identifies an integer error code for request failure.

* Retry Interval: The minimum time (in seconds) before the request SHOULD be
sent again. Present only if the Error Code is odd.

* Error Reason: Provides a text description of the request error. See
{{reason-phrase}}.

The application SHOULD use a relevant error code in REQUEST_ERROR,
as defined below. Most codepoints have identical meanings for various request
types, but some have request-specific meanings.

INTERNAL_ERROR (0x0):
: An implementation specific or generic error occurred.

UNAUTHORIZED (0x1):
as defined below and assigned in {{iana-request-error}}. Most codepoints have
identical meanings for various request types, but some have request-specific
meanings.

Odd error codes indicate the request is retryable with the same parameters at a
later time. If so, the sender of REQUEST_ERROR includes a Retry Interval in the
message. If it is sending more than one such message within a second or so
across one or more sessions, it SHOULD apply randomization to each retry
interval so that retries are spread out over time, minimizing the risk of
synchronized retry storms. The Retry Interval MAY be zero if the request can be
retried immediately.

If the sender has no information as to when a request is likely to be
successful, it MAY apply randomization around a default interval of 30 seconds.

If a Retry Interval exceeds the lifetime of a necessary authentication token
used in the request, so that a retry at that time would fail, the sender SHOULD
use a non-retryable error code indicating a new authentication token is needed.

INTERNAL_ERROR:
: An implementation specific or generic error occurred. This might be retryable
or not, depending on the codepoint.

UNAUTHORIZED:
: The subscriber is not authorized to perform the requested action on the given
track.

TIMEOUT (0x2):
TIMEOUT:
: The subscription could not be completed before an implementation specific
timeout. For example, a relay could not establish an upstream subscription
within the timeout.

NOT_SUPPORTED (0x3):
NOT_SUPPORTED:
: The endpoint does not support the type of request.

MALFORMED_AUTH_TOKEN (0x4):
MALFORMED_AUTH_TOKEN:
: Invalid Auth Token serialization during registration (see
{{authorization-token}}).

EXPIRED_AUTH_TOKEN (0x5):
EXPIRED_AUTH_TOKEN:
: Authorization token has expired ({{authorization-token}}).

Below are errors for use by the publisher. They can appear in response to
SUBSCRIBE, FETCH, TRACK_STATUS, and SUBSCRIBE_NAMESPACE, unless otherwise noted.

DOES_NOT_EXIST (0x10):
: The track or namespace is not available at the publisher.
DOES_NOT_EXIST:
: The track or namespace is not available at the publisher. This might be
retryable or not, if the target might exist later.

INVALID_RANGE (0x11):
INVALID_RANGE:
: In response to SUBSCRIBE or FETCH, specified Filter or range of Locations
cannot be satisfied.
cannot be satisfied. This might be retryable if the range is expected to have
objects in the future.

MALFORMED_TRACK (0x12):
MALFORMED_TRACK:
: In response to a FETCH, a relay publisher detected
the track was malformed (see {{malformed-tracks}}).

The following are errors for use by the subscriber. They can appear in response
to PUBLISH or PUBLISH_NAMESPACE, unless otherwise noted.

UNINTERESTED (0x20):
: The subscriber is not interested in the track or namespace.
UNINTERESTED:
: The subscriber is not interested in the track or namespace. This might be
retryable if it expects to be interested later.

Errors below can only be used in response to one message type.

PREFIX_OVERLAP (0x30):
PREFIX_OVERLAP:
: In response to SUBSCRIBE_NAMESPACE, the namespace prefix overlaps with another
SUBSCRIBE_NAMESPACE in the same session.

INVALID_JOINING_REQUEST_ID(0x32):
INVALID_JOINING_REQUEST_ID:
: In response to a Joining FETCH, the referenced Request ID is not an
`Established` Subscription.

UNKNOWN_STATUS_IN_RANGE(0x33):
UNKNOWN_STATUS_IN_RANGE:
: In response to a FETCH, the requested range contains an object with unknown
status.

Expand Down Expand Up @@ -3890,18 +3914,32 @@ TODO: register the URI scheme and the ALPN and grease the Extension types
| Name | Code | Specification |
|:---------------------------|:----:|:--------------------------|
| INTERNAL_ERROR | 0x0 | {{message-request-error}} |
| UNAUTHORIZED | 0x1 | {{message-request-error}} |
| TIMEOUT | 0x2 | {{message-request-error}} |
| NOT_SUPPORTED | 0x3 | {{message-request-error}} |
| MALFORMED_AUTH_TOKEN | 0x4 | {{message-request-error}} |
| EXPIRED_AUTH_TOKEN | 0x5 | {{message-request-error}} |
| DOES_NOT_EXIST | 0x10 | {{message-request-error}} |
| INVALID_RANGE | 0x11 | {{message-request-error}} |
| MALFORMED_TRACK | 0x12 | {{message-request-error}} |
| UNINTERESTED | 0x20 | {{message-request-error}} |
| PREFIX_OVERLAP | 0x30 | {{message-request-error}} |
| INVALID_JOINING_REQUEST_ID | 0x32 | {{message-request-error}} |
| UNKNOWN_STATUS_IN_RANGE | 0x33 | {{message-request-error}} |
| INTERNAL_ERROR | 0x1 | {{message-request-error}} |
| UNAUTHORIZED | 0x2 | {{message-request-error}} |
| TIMEOUT | 0x3 | {{message-request-error}} |
| INVALID_RANGE | 0x4 | {{message-request-error}} |
| INVALID_RANGE | 0x5 | {{message-request-error}} |
| NOT_SUPPORTED | 0x6 | {{message-request-error}} |
| UNKNOWN_STATUS_IN_RANGE | 0x7 | {{message-request-error}} |
| MALFORMED_AUTH_TOKEN | 0x8 | {{message-request-error}} |
| MALFORMED_TRACK | 0x9 | {{message-request-error}} |
| UNINTERESTED | 0xa | {{message-request-error}} |
| UNINTERESTED | 0xb | {{message-request-error}} |
| DOES_NOT_EXIST | 0xc | {{message-request-error}} |
| DOES_NOT_EXIST | 0xd | {{message-request-error}} |
| EXPIRED_AUTH_TOKEN | 0xe | {{message-request-error}} |
| PREFIX_OVERLAP | 0x10 | {{message-request-error}} |
| INVALID_JOINING_REQUEST_ID | 0x12 | {{message-request-error}} |

As noted above, odd error codes are potentially retryable. Some codes
have both retryable and non-retryable versions.

The range of error codes including 0x100 to 0xffff is reserved for
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not keen on implementation specific error code. I think that contributes to non interoperable implementations. I'd like to have some discussion on this.

implementation-speceific codes.

The range of error codes starting with 0x10000 is reserved for
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we right this up in the normal way we would IANA. This should be there is a way to get IANA to pre allocate a code.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any reason we need to invent new IANA processes beyond what is in rfc8126

provisional error codes that are under consideration for a permanent
code point by the IETF.

### PUBLISH_DONE Codes {#iana-publish-done}

Expand Down