jiebi/CodeConvo huggingface dataset:
Code change:
The "issued_token_type" value MUST bet set to "urn:ietf:params:oauth:token-type:txn_token" <del> The response MUST NOT include the values "expires_in", "refresh_token" and "scope" </del> <ins> The Txn-Token Response MUST NOT include the values "expires_in", "refresh_token" and "scope" </ins> figtxtokenresponse shows a non-normative example of a Txn-Token Response.

Related discussion:
text: Related to issue
Section 7.2 includes a "access_token", which is part of the token exchange protocol. RFC 8693 makes it clear that it des not need to be an OAuth token, but perhaps we can reference that this parameter is define in RFC 8693? Perhaps something like: "The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:" or "A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response. The Txn-Token Response is a profile of the token exchange response defined in RFC 8693. If the Transaction Token Service responds with an error, the error response is as described in Section 5.2 of RFC6749. The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:"
I'm not seeing access_token mentioned in section 7.2 other than implicitly when referencing the token types defined by 8693. Did you mean section 7.4? I'm fine with the first suggestion.
Yes, section 7.4.
I'm good with this
Code change:
update. The priority update value in ASCII text, encoded using Structured <del> Fields. </del> <ins> Fields.  This is the same representation as the Priority header field value. </ins> The request-stream variant of PRIORITY_UPDATE (type=0xF0700) MUST reference a request stream.  If a server receives a PRIORITY_UPDATE

Related discussion:
text: NAME noted a bunch of minor editorial issues, so this fixes them.
Thank you for working on the changes. They look like great improvements to me modulo the concern below.
Code change:
Date values can be conveyed in Structured Fields. Dates have a data model that is similar to Integers, representing a <del> (possibly negative) delta in seconds from January 1, 1970 00:00:00 UTC, excluding leap seconds. </del> <ins> (possibly negative) delta in seconds from 1970-01-01T00:00:00Z, excluding leap seconds. </ins> For example: <ins> Parsers MUST support Dates whose values include all days in years 1 to 9999 (i.e., -62,135,596,800 to 253,402,214,400 delta seconds from 1970-01-01T00:00:00Z). </ins> 3.3.8. Display Strings are similar to Strings, in that they consist of zero

Related discussion:
text: Implementing Date in Python as a object has an issue -- Python dates are limited to a specific range. Given that it's good to expose SF as idiomatic data structures wherever possible, I poked around a bit for limits on date/time objects in libraries, and found (all expressed as limits on years, as that's the most significant bit): Python - Rust - Go - PHP - JavaScript - Ruby - Java - Should we specify a minimum range of dates that an implementation should support (likely 1-9999) so that developers can be confident of them (as we've done for other data types)?
Hm. Do these differences affect other parts of HTTP as well, such as processing the "Date" field (or fields specific to caching...?).
One would imagine that people put HTTP dates into these structures from time to time, yes.
(it's just that HTTP dates rarely go outside the range 1970 - "forseeable future")
Restricting to a year-based range would IMHO make sense if we actually would be using calendar dates (which we do not).
To be clear, I'm not proposing we restrict it -- just require implementations to support at least a particular range of values, just as we do with many other types. Don't get stuck on years, that's just a rough sizing to get an idea of what we're looking at. I think we'd express it in integer values.
I've commented in the PR that I dont like this, but let me add a bit of context: Handling of time, in real life and in computers, is incredibly messy and one of the most unreadable scientific books of all time is "Calendrical Calculations" which is our best shot at that subject matter. I really do not want us to wade into this tarpit, because everybody who has ever done so, has just added more tar in the process. My really strong preference is if Date was defined as "Seconds since Epoch" according to POSIX" with the full range of signed 15 decimal digits we inherit from Integer, so that we in no way adds any further complexity.
That's effectively what we have, even with this addition. This text is just requiring implementations to support at least a certain range, so that it can be relied upon for interoperability.
Code change:
Both unidirectional and bidirectional QUIC streams contain sequences of length-delimited messages. <del> The Message Length field contains the length of the Message Payload field in bytes.  A length of 0 indicates the message is unbounded and continues until the end of the stream. </del> <ins> An endpoint that receives an unknown message type MUST close the connection. </ins> 6.1.

Related discussion:
text: and . if messages must be known, explicit message lengths are redundanct except for OBJECT and messages with parameters. This also eliminates a whole class of potential errors where the message length does not match the actual parsing of the message. Not checking this -- and not have any message type be potentially zero-length -- greatly simplifies the parser.
And trying to use messages without negotiating an extension/version just won't work for MoQ. We're designing a protocol explicitly for relays so you do need relay cooperation, or at the very least some information on how to forward unknown messages.
Also I love that you're using "parameter count" instead of "parameter size (bytes)". It makes it much easier to build a streaming encoder/decoder without allocating temporary buffers.
I thought we agreed to allow extensibility by allowing new message types to be created.
Like to see us agree on a extensibility strategy before deciding what to do on this. We also need to decide if messages can have optional fields
We have version negotiation, and presumably we'll have extension negotiation too. What's the use-case for adding new messages without negotiating them? The problem is that we can't relay unknown messages, so all it takes is a single uncooperative relay on the chain to shallow them. I think we need explicit negotiation as a result.
If we have extension negotiation, I agree. But if our extension negotiation mechanism relies on not getting an error on unknown messages .... PR is wrong place to discuss this but I think what I would like to see is a good way to do extension negotiation, and then like you have here, error on any message that is not part of a negotiated extension. I think I would lean that way if we had an extension negotiation mechanism. Note this is the opposite direction of HTTP which is often our model for things. HTTP just skips past unknown headers.
Fail, or pass over?
IMO fail. We have version negotiation and should add extension negotiation so it should never happen. The problem with ignoring messages is that MoqTransport is designed for relays. If an intermediate relay doesn't support a message, it then gets silently dropped. At the very least we need enough information on where to forward unknown messages.
Code change:
Both unidirectional and bidirectional QUIC streams contain sequences of length-delimited messages. <del> The Message Length field contains the length of the Message Payload field in bytes.  A length of 0 indicates the message is unbounded and continues until the end of the stream. </del> <ins> An endpoint that receives an unknown message type MUST close the connection. </ins> 6.1.

Related discussion:
text: If it's going to Fail, then most Message types don't need a length field at all (OBJECT and ANNOUNCE_OK would be the exceptions)
Individual Comment: Is there any reasonable action a relay can take on an unknown message, besides discarding it? See how HTTP recently added a "Capsule" concept which is an envelop with a default relay action of "forward", which allows for end-to-end extensions without upgrading all intermediaries. Given that MoQ handles forwarding on a per-track level, I think there probably isn't any way to generically forward a message that isn't associated with an active subscription. That said, it makes me wonder if we want to add a capsule-like extension message, or does the existing OBJECT definition give enough flexibility?
Yeah exactly. It's impossible to know the intended destination of an unknown message with the current ANNOUNCE/SUBSCRIBE mechanisms. I'm using the (as the track namespace) and instead of . This actually does let you forward unknown messages from publisher -> subscribers and subscribers -> publisher since each session is associated with only a single track namespace. Session pooling is always the issue...
I think we need extensibility. We want the protocol to be extensible so a given server might support extension A and C and another server supports extension A and B. It is very hard to do that using just a version number.
Rereading all this - II think this whole issue just need to be uplevel to what is the extensibility strategy then this detailed part of it will be easy.
There was support for not requiring a length and failing on unknown message types at the Interim, so the intent is to land PR after review.
LG. The agreement at the interim was to follow up with separate frame types for object with and without length, but do that in a separate PR.I love it. It also means you can implement streaming encoders. Prefixing each message with the length required a temporary buffer or 2nd pass to compute the length.LGTM
Code change:
themselves and both the index and direction can be left out in the path: <del> Note: Including the tree size and leaf index may not be appropriate in certain privacy-focused applications as an attacker may be able to derive private information from them. TODO: Should leaf index be part of inclusion path (IndexAwareInclusionPath) or outside? </del> <ins> Presence of leaf index, and whether it is an input or an output is tree algorithm specific. </ins> <del> TODO: Define root computation algorithm for each inclusion path type TODO: Do we need both inclusion path types? what properties does each type have? [1] </del> <ins> 3.3. </ins> <del> TODO: Should the inclusion path be opaque (bstr) and fixed by the tree algorithm?  It seems this is orthogonal and the choice of inclusion path type should be application-specific. </del> <ins> An inclusion proof is a CBOR array containing a merkle tree root, an inclusion path, extra data for the tree algorithm, and the payload. </ins> <del> 3.3. </del> <ins> 3.4. </ins> <del> A signed Merkle tree proof is a CBOR array containing a signed tree </del> <ins> A signed inclusion proof is a CBOR array containing a signed tree </ins> root, an inclusion path, extra data for the tree algorithm, and the payload. <del> "extra_data" is an additional input to the tree algorithm and is used together with the payload to compute the leaf hash.  A use case for this field is to implement blinding. </del> <ins> "extra-data" is an additional input to the tree algorithm and is used together with the payload to compute the leaf hash.  See sec-leaf- blinding-example for an example use case for this field to enable leaf blinding as described in sec-leaf-blinding. </ins> <del> TODO: maybe rename "extra_data" </del> <ins> 3.5. </ins> <del> 3.4. </del> <ins> 3.5.1. This signed mulitple inclusion proof representation relies on 2 lists to enable proof of inclusion for multiple payloads in a given signed merkle root. </ins> <del> TODO: define a multi-leaf variant of a signed Merkle tree proof like in: </del> <ins> Note that the extra-data may be ommited if not required by the tree algorithm, and that leaf payloads may be detached. TODO: refine multi-leaf variant of a signed inclusion proof like in: </ins> https://github.com/transmute-industries/merkle-proof

Related discussion:
text: Changes from IETF 116 hackathon
I'm stopping on this PR, before it gets even larger.
NAME I have made several more changes, please review when you have a chance.
I am merging, we reviewed this content together at IETF.
Code change:
, <del> or CONTINUATION without the END_HEADERS or END_PUSH_PROMISE flag set. </del> <ins> or CONTINUATION without the END_HEADERS flag set. </ins> The CONTINUATION frame payload has the following fields:

Related discussion:
text: This simplifies the text and makes flag consistent with CONTINUATION which only bears ENDHEADERS. Technically, both have the same meaning of ending sequence of header block fragments. Therefore there is no reason to use the different flag name for the same purpose. This will also make the implementaion easier because most likely HEADERS and PUSHPROMISE handling share the same code and dancing with ENDPUSHPROMISE and END_HEADERS is not fun. Although currently they have the same number, it is not guaranteed to the last. If they are guarenteed to be the same, then it is simpler to use the same name for same value.
Code change:
contains a digest value computed by applying a hashing algorithm to selected representation data (SEMANTICS).  Basing "Repr-Digest" on the selected representation makes it straightforward to apply it to <del> use-cases where the transferred data requires some sort of manipulation to be considered a representation or conveys a partial representation of a resource, such as Range Requests (see SEMANTICS). </del> <ins> use-cases where the message content requires some sort of manipulation to be considered as representation of the resource or content conveys a partial representation of a resource, such as Range Requests (see SEMANTICS). </ins> "Content-Digest" and "Repr-Digest" support hashing algorithm agility. The "Want-Content-Digest" and "Want-Repr-Digest" fields allow endpoints to express interest in "Content-Digest" and "Repr-Digest" <del> respectively, and preference of algorithms in either. </del> <ins> respectively, and to express algorithm preferences in either. </ins> "Content-Digest" and "Repr-Digest" are collectively termed Integrity fields.  "Want-Content-Digest" and "Want-Repr-Digest" are

Related discussion:
text: I had to read this several times to understand what parts of the sentence were replicated into the "or" part of the statement. Duplicating some words makes it a tiny bit more comprehensible, I think.
LGTM
Code change:
HTTP/1.1. The server can cause a client to retry a request and not use early <del> data by responding with the 4NN (Too Early) status code (status), </del> <ins> data by responding with the 425 (Too Early) status code (status), </ins> in cases where the risk of replay is judged too great. For a given request, the level of tolerance to replay risk is

Related discussion:
text: (I accidentally put this on master without noticing earlier, sorry.)
Can we just have 425 now that it's official-ish? From martinthomson/http-replay
Code change:
Authentication SHOULD be implemented for this endpoint. This endpoint enables Transparency Service APIs to act like Artifact <del> Repositories, and serve "payload" values directly, instead of </del> <ins> Repositories, and serve Signed Statements directly, instead of </ins> indirectly through Receipts. Request: Response: <del> 2.2.3. Authentication SHOULD be implemented for this endpoint. </del> <ins> One of the following: </ins> <del> This endpoint enables Transparency Service APIs to act like Artifact Repositories, and serve Signed Statements directly, instead of indirectly through Receipts. </del> <ins> 2.2.2.1. </ins> <del> Request: </del> <ins> 2.2.2.2. </ins> <del> Response: </del> <ins> The following expected errors are defined.  Implementations MAY return other errors, so long as they are valid RFC9290 objects. </ins> <del> 2.2.4. </del> <ins> 2.2.3. </ins> Authentication SHOULD be implemented for this endpoint.

Related discussion:
text: Updated error returns to be CBOR, and a couple of other things. Still more to do
Since we are talking about , does this mean we must refactor this API endpoint's response with minimally viable CBOR and a CDDL spec in place of JSON?
Yes. Discussed at the hackathon and will make a proposal as part of URL
Added to PR - LMK if you like it
I will have to experiment with it more, but so far I like it. You can link this issue to close it once you merge . Thanks.
Merged.
It's sufficient/better to just ResolveSignedStatement (meaning you get back what was put in) and then the client can pull the Statement out if they want it. Reduces complexity for no loss of functionality
So no separate endpoint, you mean?
Reviewed and merged in
Showing keys without saying what they're for is unhelpful Cedric suggests it might be even better to remove the specifics and just include a standard key discovery locator (which also helps avoid format/types arguments in this doc)
I have attempted to resolve this by removing it in the translation to CBOR in PR - will this suffice?
Reviewed and addressed in
LGTM
Code change:
The client MAY indicate the audience it is trying to access through the "scope" parameter or the "resource" parameter defined in RFC8707. <del> 2.4.2. </del> <ins> 2.5.2. </ins> All of RFC7521 (Section 5.2 in specific) applies.  In context of this specification the following rules apply in addition:

Related discussion:
text: Added use cases. We may want to refine these, or move them into a non-normative section later.
Code change:
representations of error or processing status, and potentially even the miscellaneous text strings that might appear within the protocol. <ins> For each of these header fields, a request that does not contain it implies that the user agent has no preference on that axis of negotiation.  If the header field is present in a request and none of the available representations for the response can be considered acceptable according to it, the origin server can either honor the header field by sending a response or disregard the header field by treating the response as if it is not subject to content negotiation for that request header field.  This does not imply, however, that the client will be able to use the representation. Sending these header fields makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (fingerprinting). Each of these header fields defines a wildcard value (often, "*") to select unspecified values.  If no wildcard is present, all values not explicitly mentioned in the field are considered "not acceptable" to the client. In practice, using wildcards in content negotiation has limited practical value, because it is seldom useful to say, for example, "I prefer image/* more or less than (some other specific value)". Clients can explicitly request a response if a more preferred format is not available by sending Accept: */*;q=0, but they still need to be able to handle a different response, since the server is allowed to ignore their preference. </ins> 8.4.1. Many of the request header fields for

Related discussion:
text: (alternative approach)
AcceptAccept-CharsetAccept-Encoding`](URL) request headers is of very limited use, because: With a qvalue higher than another value, it says "send anything in preference to something specific", which isn't useful With a qvalue lower than another media type, it says "send a more specific value in preference to something else", which is already implied by HTTP With a qvalue of 0, it says "don't ever send other value" -- but a server can always ignore that, because this is an optional-to-implement extension In media types (e.g., ), it has been cargo culted a lot, but doesn't actually give the server information it can use. Can we deprecate in these headers, or at least restrict its use / give better guidance?
Discussed in Montreal; support for documenting limitations / caveats.
We can't deprecate it. We can explain when and where it isn't useful.
+1 to generalize this. However, we may want to still reference these rules from each individual header field definition.I think the first sentence needs some editorial work, but +1 to committing this first.
Code change:
ts_identifier: The DID of the Transparency Service that issued the Receipt.  Verifiers MAY use this DID as a key discovery mechanism to verify the Receipt; in this case the verification is the same <del> as for Signed Claims and the signer MAY include the "kid" header </del> <ins> as for Signed Statment and the signer MAY include the "kid" header </ins> parameter.  Verifiers MUST support the "did:web" method, all other methods are optional.

Related discussion:
text: and
Payload and Statement seem to be used intermixed in the text. I tried to disambiguate the via "Statement payload". If that does not work, please provide a counter proposal. The term Claim sometimes seem to have meant Signed Statement and sometimes Transparent Statement. Using our interim terminology, that became a selection process for me. Please check, if I made the correct choice in all occurrences (sometimes I had to guess the intent). Consistent Capitalization was a mess. I hope I fixed most of that. Please check. There is still no consistent use of "Registry" vs. "log" vs. "ledger" vs. "Transparency Service", I think. Please check. Please check every use of the term "Evidence" and if an alternative expression could be used. Please check every occurrence of the term "guarantee" or "proof" and if an alternative expression could be used. Privacy Considerations and Security Considerations texts require significant improvement.
Here is my opinion: Registry refers to the facilities used to store and retrieve "Authenticated Statement Data" that has been submitted to a "Transparency Service" "operator". A Registry contains specific "Statements" which the Transparency service supports, as documented in their registration policies document. A Registry may employ different technologies needed to carry out its function to store and retrieve "Statements" that are permitted in the Registry, per the registration policies defined by the Transparency Service operator. The operator of a Transparency Service serves the role of Gatekeeper to ensure the integrity of the Registry data and services provided to access the Registry data. A Statement is contained in a message "Payload" exchanged between a Transparency Service API function and other parties, i.e. consumer inquiries and Notary submissions.
It would help to be able to read the document given the changes proposed here. But due to the make errors documented in I haven't yet succeeded in doing so. Does the build infrastructure automatically build documents for other branches? Or can someone else build and publish the document based on this branch?
Editor's version build via github actions for is located here: https://ietf-wg-URL
LGTM, thanks for finishing this off