jiebi/CodeConvo huggingface dataset:
each object are still delivered in order; this delivery order only applies to the ordering between objects. <del> An object MUST NOT have a smaller delivery order than an object it depends on.  Delivering objects out of dependency order will increase latency and can cause artifacting when memory limits are tight.  This is especially problematic and can cause a deadlock if the receiver does not release flow control until dependencies are received. </del> A sender MUST send each object over a dedicated QUIC stream.  The QUIC library should support prioritization (prioritization) such that streams are transmitted in delivery order.
4.3. <del> Media encoding uses references to improve the compression.  This creates hard and soft dependencies that need to be respected by the transport.  See the appendex for an overview of media encoding (appendix.encoding). An object MAY depend on any number of other objects.  The encoder MUST indicate these dependecies on the wire via the OBJECT header (object). The sender SHOULD NOT use this list of dependencies to determine which object to transmit next.  The sender SHOULD use the delivery order instead, which MUST respect dependencies. The decoder SHOULD process object according to their dependencies. This means buffering a object until the relevent timestamps have been processed in all dependencies.  A decoder MAY drop dependencies at the risk of producing decoding errors and artifacts. 4.4. </del> The decoder will receive multiple objects in parallel and out of order.
Track Box in the initialization fragment.  A Common Media Application Format Segment CMAF meets all these requirements. <del> Each OBJECT message (object) MUST start with an initialization segment, or MUST depend on a OBJECT that does.  The rest of the OBJECT message MAY be a media segment. </del> Media fragments can be packaged at any frequency, causing a trade-off between overhead and latency.  It is RECOMMENDED that a media fragment consists of a single frame to minimize latency.
We can further reduce the number of objects by combining frames that don't depend on each other.  The only restriction is that frames can <del> only reference frames earlier in the object, or within a dependency object.  For example, non-reference frames can have their own object so they can be prioritized or dropped separate from reference frames. </del> <ins> only reference frames earlier in the object.  For example, non- reference frames can have their own object so they can be prioritized or dropped separate from reference frames. </ins> The same GoP structure can also be represented using six objects, although we've removed the ability to drop individual B-frames:
as that of the next later Object, with the assumption that the Object's data was reordered. <del> If neither the subscriber or publisher specify DELIVERY TIMEOUT, Objects are delivered as indicated by their Group Order and Priority. </del> <ins> If neither the subscriber or publisher specify DELIVERY TIMEOUT, all Objects in the track matching the subscription filter are delivered as indicated by their Group Order and Priority.  If a subscriber exceeds the publisher's resource limits by failing to consume objects at a sufficient rate, the publisher MAY terminate the subscription with error 'Too Far Behind'. If an object in a subgroup exceeds the delivery timeout, the publisher MUST reset the underlying transport stream (see closing- subgroup-streams). </ins> When sent by a subscriber, this parameter is intended to be specific to a subscription, so it SHOULD NOT be forwarded upstream by a relay
the scalability and cost effectiveness associated with content delivery networks. <del> MOQT is a generic protocol is designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MOQT objects, along with policies for discovery and subscription. </del> <ins> MOQT is a generic protocol designed to work in concert with multiple MoQ Streaming Formats.  These MoQ Streaming Formats define how content is encoded, packaged, and mapped to MOQT objects, along with policies for discovery and subscription. </ins> model describes the object model employed by MOQT.
metadata is never encrypted and is always visible to relays (see relays-moq).  The payload portion may be encrypted, in which case it is only visible to the Original Publisher and End Subscribers.  The <del> application is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </del> <ins> Original Publisher is solely responsible for the content of the object payload.  This includes the underlying encoding, compression, any end-to-end encryption, or authentication.  A relay MUST NOT combine, split, or otherwise modify object payloads. </ins> Objects within a group are ordered numerically by their Object ID.
a URI with a "moqt" scheme.  The "moqt" URI scheme is defined as follows, using definitions from RFC3986: <del> The "authority" portion MUST NOT contain a non-empty "host" portion. </del> <ins> The "authority" portion MUST NOT contain an empty "host" portion. </ins> The "moqt" URI scheme supports the "/.well-known/" path prefix defined in RFC8615.
3.3. The first stream opened is a client-initiated bidirectional control <del> stream where the peers exchange Setup messages (message-setup).  All messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control stream after the Setup message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </del> <ins> stream where the endpoints exchange Setup messages (message-setup). All messages defined in this draft except OBJECT and OBJECT_WITH_LENGTH are sent on the control stream after the Setup message.  Control messages MUST NOT be sent on any other stream, and a peer receiving a control message on a different stream closes the session as a 'Protocol Violation'.  Objects MUST NOT be sent on the control stream, and a peer receiving an Object on the control stream closes the session as a 'Protocol Violation'. </ins> This draft only specifies a single use of bidirectional streams. Objects are sent on unidirectional streams.  Because there are no
A publisher SHOULD begin sending incomplete objects when available to avoid incurring additional latency. <del> A relay that reads from a stream and writes to stream in order will </del> <ins> A relay that reads from one stream and writes to another in order can </ins> introduce head-of-line blocking.  Packet loss will cause stream data <del> to be buffered in the library, awaiting in order delivery, which will increase latency over additional hops.  To mitigate this, a relay SHOULD read and write stream data out of order subject to flow </del> <ins> to be buffered in the library, awaiting in-order delivery, which could increase latency over additional hops.  To mitigate this, a relay MAY read and write stream data out of order subject to flow </ins> control limits.  See section 2.2 in QUIC. 6.
6.2. The "CLIENT_SETUP" and "SERVER_SETUP" messages are the first messages <del> exchanged by the client and the server; they allows the peers to </del> <ins> exchanged by the client and the server; they allow the endpoints to </ins> establish the mutually supported version and agree on the initial configuration before any objects are exchanged.  It is a sequence of key-value pairs called Setup parameters; the semantics and format of which can vary based on whether the client or server is sending.  To <del> ensure future extensibility of MOQT, the peers MUST ignore unknown </del> <ins> ensure future extensibility of MOQT, endpoints MUST ignore unknown </ins> setup parameters.  TODO: describe GREASE for those. The wire format of the Setup messages are as follows:
Track namespace is an ordered N-tuple of bytes where N can be between 1 and 32.  The structured nature of Track Namespace allows relays and applications to manipulate prefixes of a namespace.  Track name is a <del> sequence of bytes. </del> <ins> sequence of bytes.  If an endpoint receives a Track Namespace tuple with an N of 0 or more than 32, it MUST close the session with a Protocol Violation. </ins> In this specification, both the Track Namespace tuple fields and the Track Name are not constrained to a specific encoding.  They carry a
messages for namespaces ("example.com", "meeting=123", "participant=100") and ("example.com", "meeting=123", "participant=200"), a SUBSCRIBE_ANNOUNCES for ("example.com", <del> "meeting=123") would match both. </del> <ins> "meeting=123") would match both.  If an endpoint receives a Track Namespace Prefix tuple with an N of 0 or more than 32, it MUST close the session with a Protocol Violation. </ins> Parameters: The parameters are defined in version-specific-params.
used a Subscribe ID equal or larger than the current Maximum Subscribe ID. <del> GOAWAY Timeout: The session was closed because the client took too </del> <ins> GOAWAY Timeout: The session was closed because the peer took too </ins> long to close the session in response to a GOAWAY (message-goaway) message.  See session migration (session-migration). 3.6. <del> MoqTransport requires a long-lived and stateful session.  However, a service provider needs the ability to shutdown/restart a server without waiting for all sessions to drain naturally, as that can take days for long-form media.  MoqTransport avoids this via the GOAWAY message (message-goaway). </del> <ins> MOQT requires a long-lived and stateful session.  However, a service provider needs the ability to shutdown/restart a server without waiting for all sessions to drain naturally, as that can take days for long-form media.  MOQT enables proactively draining sessions via the GOAWAY message (message-goaway). </ins> <del> The server sends a GOAWAY message, signaling that the client should establish a new session and migrate any active subscriptions.  The GOAWAY message may contain a new URI for the new session, otherwise </del> <ins> The server sends a GOAWAY message, signaling the client to establish a new session and migrate any active subscriptions.  The GOAWAY message optionally contains a new URI for the new session, otherwise </ins> the current URI is reused.  The server SHOULD terminate the session with 'GOAWAY Timeout' after a sufficient timeout if there are still <del> open subscriptions on a connection. </del> <ins> open subscriptions or fetches on a connection. </ins> <del> The GOAWAY message does not immediately impact subscription state.  A subscriber SHOULD individually UNSUBSCRIBE for each existing subscription, while a publisher MAY reject new SUBSCRIBEs while in the draining state.  When the server is a subscriber, it SHOULD send a GOAWAY message to downstream subscribers prior to any UNSUBSCRIBE messages to upstream publishers. </del> <ins> When the server is a subscriber, it SHOULD send a GOAWAY message to downstream subscribers prior to any UNSUBSCRIBE messages to upstream publishers. </ins> After the client receives a GOAWAY, it's RECOMMENDED that the client waits until there are no more active subscriptions before closing the
6.3. <del> The server sends a "GOAWAY" message to initiate session migration (session-migration) with an optional URI. </del> <ins> An endpoint sends a "GOAWAY" message to inform the peer it intends to close the session soon.  Servers can use GOAWAY to initiate session migration (session-migration) with an optional URI. </ins> <del> The server MUST terminate the session with a Protocol Violation (session-termination) if it receives a GOAWAY message.  The client MUST terminate the session with a Protocol Violation (session- termination) if it receives multiple GOAWAY messages. </del> <ins> The GOAWAY message does not impact subscription state.  A subscriber SHOULD individually UNSUBSCRIBE for each existing subscription, while a publisher MAY reject new requests while in the draining state. </ins> <del> New Session URI: The client MUST use this URI for the new session if provided.  If the URI is zero bytes long, the current URI is reused instead.  The new session URI SHOULD use the same scheme as the current URL to ensure compatibility. </del> <ins> Upon receiving a GOAWAY, an endpoint SHOULD NOT initiate new requests to the peer including SUBSCRIBE, FETCH, ANNOUNCE and SUBSCRIBE_ANNOUNCE. The endpoint MUST terminate the session with a Protocol Violation (session-termination) if it receives multiple GOAWAY messages. New Session URI: When received by a client, indicates where the client can connect to continue this session.  The client MUST use this URI for the new session if provided.  If the URI is zero bytes long, the client can reuse the current URI is reused instead.  The new session URI SHOULD use the same scheme as the current URL to ensure compatibility. If a server receives a GOAWAY with a non-zero New Session URI Length it MUST terminate the session with a Protocol Violation. </ins> 6.4.
6.1.1.1. AUTHORIZATION INFO parameter (Parameter Type 0x02) identifies a <del> track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES or ANNOUNCE message.  This parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string. </del> <ins> track's authorization information in a SUBSCRIBE, SUBSCRIBE_ANNOUNCES, ANNOUNCE or FETCH message.  This parameter is populated for cases where the authorization is required at the track level.  The value is an ASCII string. </ins> 6.1.1.2.
Track ID: The track identifier as declared in CATALOG (message- catalog). <del> Object ID: A unique identifier for each object within the track. </del> <ins> Group Sequence : An integer always starts at 0 and increases sequentially at the original media publisher.  Group sequences are scoped under a Track. Object Sequence: An integer always starts at 0 with in a Group and increases sequentially.  Object Sequences are scoped to a Group. </ins> Object Delivery Order: An integer indicating the object delivery order (delivery-order).
6. <del> There are three primary architectural patterns available when building browser-based applications. </del> <ins> Here are the main architectural patterns available when building browser-based applications. single-domain, not using OAuth a JavaScript application accessing resource servers </ins> <del> a JavaScript application that has methods of sharing data with resource servers, such as using common-domain cookies </del> <ins> either directly </ins> <del> a JavaScript application with a backend component </del> <ins> or through a service worker </ins> <del> a JavaScript application with no backend, accessing resource servers directly </del> <ins> a JavaScript application with a stateful backend component for storing tokens and handling all authentication flows (BFF proxy) </ins> <del> These three architectures have different use cases and considerations. </del> <ins> These architectures have different use cases and considerations. </ins> 6.1. For simple system architectures, such as when the JavaScript application is served from a domain that can share cookies with the <del> domain of the API (resource server), OAuth adds additional attack vectors that could be avoided with a different solution. </del> <ins> domain of the API (resource server) and the authorization server, OAuth adds additional attack vectors that could be avoided with a different solution. </ins> In particular, using any redirect-based mechanism of obtaining an access token enables the redirect-based attacks described in oauth-
use a redirect mechanism to communicate between them. An additional concern with handling access tokens in a browser is <del> that as of the date of this publication, there is no secure storage mechanism where JavaScript code can keep the access token to be later used in an API request.  Using an OAuth flow results in the JavaScript code getting an access token, needing to store it somewhere, and then retrieve it to make an API request. Instead, a more secure design is to use an HTTP-only cookie between the JavaScript application and API so that the JavaScript code can't </del> <ins> that in case of successful XSS attack, tokens could be read and further used or transmitted by the injected code if no secure storage mechanism is in place. It could as such be considered to use an HTTP-only cookie between the JavaScript application and API so that the JavaScript code can't </ins> access the cookie value itself.  The "Secure" cookie attribute should be used to ensure the cookie is not included in unencrypted HTTP requests.  Additionally, the "SameSite" cookie attribute can be used <del> to counter CSRF attacks, but should not be considered the extent of the CSRF protection, as described in </del> <ins> to counter some CSRF attacks, but should not be considered the extent of the CSRF protection, as described in </ins> OAuth was originally created for third-party or federated access to APIs, so it may not be the best solution in a common-domain
and recovery at the OAuth server, rather than making it part of the application logic. <ins> Splitting of responsibilities between authenticating a user and serving resources </ins> Using OAuth for browser-based apps in a first-party same-domain <del> scenario provides these advantages, and can be accomplished by either of the two architectural patterns described below. </del> <ins> scenario provides these advantages, and can be accomplished by any of the architectural patterns described below. </ins> 6.2. In this architecture, commonly referred to as "backend for frontend" or "BFF", the JavaScript code is loaded from a dynamic Application <del> Server (A) that also has the ability to execute code itself.  This enables the ability to keep all of the steps involved in obtaining an access token outside of the JavaScript application. Note that this application backend is not the Resource Server, it is still considered part of the OAuth client and would be accessing data at a separate resource server. In this case, the Application Server initiates the OAuth flow itself, by redirecting the browser to the authorization endpoint (B).  When the user is redirected back, the browser delivers the authorization code to the application server (C), where it can then exchange it for an access token at the token endpoint (D) using its client secret. The application server then keeps the access token and refresh token stored internally, and creates a separate session with the browser- based app via a traditional browser cookie (E). </del> <ins> Server (A) that has the ability to execute code and handle the full authentication flow itself.  This enables the ability to keep the call to actually get an access token outside the JavaScript application. Note that this BFF is not the Resource Server, it is the OAuth client and would be accessing data at a separate resource server. In this case, the BFF initiates the OAuth flow itself, by redirecting the browser to the authorization endpoint (B).  When the user is redirected back, the browser delivers the authorization code to the application server (C), where it can then exchange it for an access token at the token endpoint (D) using its client secret and PKCE code verifier.  The application server then keeps the access token and refresh token stored internally, and creates a separate session with the browser-based app via a traditional browser cookie (E). </ins> When the JavaScript application in the browser wants to make a request to the Resource Server, it instead makes the request to the
and "Secure" cookie to authenticate the session between the browser and Application Server. <ins> Additionally, cookies MUST be protected from leakage by other means, such as logs. This architecture protects against tokens leakage from the browser, but creates a CSRF attack vector: once the user is authenticated, the BFF proxy will automatically add tokens to calls to the resource server. </ins> 6.3. In this architecture, the JavaScript code is first loaded from a
In this architecture, the JavaScript code is first loaded from a static web host into the browser (A), and the application then runs in the browser.  This application is considered a public client, <del> since there is no way to issue it a client secret and there is no other secure client authentication mechanism available in the browser. </del> <ins> since there is no way to issue it a client secret and authentication is handled by the application, not by the browser. </ins> The code in the browser initiates the Authorization Code flow with the PKCE extension (described in authorization_code_flow) (B) above, <del> and obtains an access token via a POST request (C).  The JavaScript application is then responsible for storing the access token (and </del> <ins> and obtains an access token via a POST request (C). The application is then responsible for storing the access token (and </ins> optional refresh token) as securely as possible using appropriate <del> browser APIs.  As of the date of this publication there is no browser API that allows to store tokens in a completely secure way. </del> <ins> browser APIs. </ins> When the JavaScript application in the browser wants to make a request to the Resource Server, it can interact with the Resource
refresh token to obtain new access tokens potentially without being detectable by the authorization server. <del> Browser-based applications provide an attacker with several opportunities by which a refresh token can be leaked, just as with access tokens.  As such, these applications are considered a higher risk for handling refresh tokens. </del> <ins> Javascript-accessible storage mechanisms like _Local Storage_ provide an attacker with several opportunities by which a refresh token can be leaked, just as with access tokens.  As such, these mechanisms are considered a higher risk for handling refresh tokens. </ins> Authorization servers may choose whether or not to issue refresh tokens to browser-based applications. oauth-security-topics describes
having refresh tokens at all to avoid the risk of giving prolonged access to the attacker. <ins> 6.3.2. In this scenario, a Service Worker [1] is responsible for obtaining tokens from the authorization server and passing them to the resource API. Service workers are inherently safe from XSS, because the browser APIs allowing to register one take an origin-constrained URL.  They can thus be used as a safe store for tokens. In this architecture, a service worker intercepts calls from the frontend to the resource server.  As such, it completely isolates calls to the authorization server from XSS attack surface, as all tokens and PKCE secrets are safely kept there without any access from other JavaScript contexts.  The service worker is then solely responsible for adding authentication headers to calls to the resource server. 6.3.2.1. The service worker MUST initiate the OAuth 2.0 Authorization Code grant with PKCE itself. The service worker MUST intercept the authorization code when the _authorization server_ redirects to the application.  This makes this architecture completely safe from token or session leaks in case of XSS. The service worker implementation MUST then initiate the token request itself. The service worker MUST not transmit tokens, authorization codes or PKCE secrets (e.g. code verifier) to the frontend application. The service worker MUST block /token or /authorize calls initiating from the frontend application in order to avoid any front-end side-channel for getting credentials: the only way of starting the authorization flow is through the service worker. This protects against re-authorization from XSS-injected code. </ins> 7. Browser-based applications that are public clients and use the