jiebi/CodeConvo huggingface dataset:
Code change:
Statement passed its Registration Policy and was recorded appropriately. <del> Conversely, a corrupt Transparency Service may 1. refuse or delay the Registration of Signed Statements, 2. register Signed Statements that do not pass its Registration Policy (e.g., Signed Statement with Issuer identities and signatures that do not verify), 3. issue verifiable Receipts for Signed Statements that do not match its Registry, or 4. refuse access to its Registry (e.g., to Auditors, possibly after storage loss). </del> <ins> Conversely, a corrupt Transparency Service may refuse or delay the Registration of Signed Statements, register Signed Statements that do not pass its Registration Policy (e.g., Signed Statement with Issuer identities and signatures that do not verify), issue verifiable Receipts for Signed Statements that do not match its Registry, or refuse access to its Registry (e.g., to Auditors, possibly after storage loss). </ins> An Auditor granted (partial) access to a Registry and to a collection of disputed Receipts will be able to replay it, detect any invalid

Related discussion:
text: A number of markdown formatting errors caused to fail processing and rendering. As an example, see
LGTM - nobody loves broken markdown :-)
Code change:
in time, two tracks within the same scope contain different data, they have to have different full track names. <ins> In this specification, both the Track Namespace and the Track Name are not constrained to a specific encoding.  They carry a sequence of bytes and comparison between two Track Namespaces or Track Names is done by exact comparison of the bytes.  Specifications that use MoQ Transport may constrain the information in these fields, for example by restricting them to UTF-8.  Any specification that does needs to specify the canonicalization into the bytes in the Track Namespace or Track Name such that exact comparison works. </ins> 2.3.2. Each track MAY have one or more associated connection URLs specifying

Related discussion:
text: Thanks NAME - all the proposed changes look like definite improvements. Thanks I need more coffee today.
In HTTP, there are a number of restrictions on what characters are allowed in a path, headers, etc. I don't see any text restricting track names and track namespaces, but the examples are all ASCII, implying the namespace and name are not intended to be completely opaque and are instead intended to be human readable. There's nothing in the spec that prohibits them being treated as opaque identifiers, but I'm unclear if that's the intent and I think it'd be good to explicitly say what we intend.
Most of the restrictions in the HTTP world are derivative of the restrictions in URIs: see RFC 3986, sections 2 and 3. I'd suggest we adopt those limitations and the percent encoding method from HTTP. That allows folks to use a well-known set of methods and aligns with the idea that we might have one or more URI schemes in the MoQ protocol space.
I believe we currently don't have a way to put a track name or a track namespace into a URL, so I don't think those restrictions apply.
I agree that they don't apply now, but if we adopt them it will simplify the set we have to deal with (since we will have the same set as other parts of the protocol). I suspect people will want the namespaces to be easy to generate from FQDNs (which are also the authority part of HTTP URIs), as an example.
IMO a track name should be human readable. Otherwise we should use numeric IDs instead, like most containers. I also think the track namespace should be human readable since it will likely be exposed to the user. Currently you need a URL and track namespace to configure a player/broadcaster. It will be quite common to combine both into a single URL (ex. like my relay) so it would be nice if track namespaces could be encoded into URLs.
Maybe we should ask the flip side: is there a use-case that won't work if track names are utf-8?
Moq transport must not define the interpretation. At the moqt transport layer track name and track namespace are set of octets and relay perform fast match where needed. How things from application domain gets mapped and gets setup with Relay is out of scope of MoQ Transport.
Code change:
in time, two tracks within the same scope contain different data, they have to have different full track names. <ins> In this specification, both the Track Namespace and the Track Name are not constrained to a specific encoding.  They carry a sequence of bytes and comparison between two Track Namespaces or Track Names is done by exact comparison of the bytes.  Specifications that use MoQ Transport may constrain the information in these fields, for example by restricting them to UTF-8.  Any specification that does needs to specify the canonicalization into the bytes in the Track Namespace or Track Name such that exact comparison works. </ins> 2.3.2. Each track MAY have one or more associated connection URLs specifying

Related discussion:
text: Also how an application sets up namespaces with CDN/Relays is out of scope of moq.
We should clarify in the spec to say these are opaque and examples are intended for human readability purposes only.
I don't have any particular heartburn about where this gets defined, but I don't believe that the overall system will function well if the namespaces and track names are defined solely as "octets". We are talking about these as a tuple of namespace and name to create a globally unique identifier. If there isn't a common agreement on how those are composed and of what they are constructed, different systems doing different things will hinder interoperability and/or generate collisions. I would personally prefer the HTTP syntax, but UTF-8 would likely be okay if we specify how to handle things like byte-order marks, joiners, bidi, arabic letter marks and so on. That's a lot of work, but if someone wants to do it, okay. I don't think accepting a bunch of different encodings is helpful and I don't think using non-human readable identifiers is going to fly without a mapping to them (which only shoves the problem up a layer of indirection and adds in something new to fail). If not moqt, where do you want all this defined?
I disagree. We have to recognize that we are distributing the process of minting these identifiers very widely. Allowing people to re-use existing systems to create these is going to get us better scale and present fewer problems. You should expect folks to re-use DNS names to mint namespaces, to take an obvious example.
I don't think I am forbidding any of these. I am just saying it is not something moqt should enforce or we should support all forms of these not just one class of things
I am also strongly in favor of a utf-8 restriction. I'd like to inherit the usability achieved from a globally deployed and understood resource identifiers and to leverage the existing DNS and certificate system for authentication and routing. If we define names in terms of octets then we need to reinvent these conventions, or else have an unnecessarily bi-furcated system in which some addressing occurs via binary octets and others occurs via utf-8 resource locators.
The AUTH parameter is currently defined as an ASCII string. Whatever we use for track names, can the auth token share the same encoding?
Code change:
in time, two tracks within the same scope contain different data, they have to have different full track names. <ins> In this specification, both the Track Namespace and the Track Name are not constrained to a specific encoding.  They carry a sequence of bytes and comparison between two Track Namespaces or Track Names is done by exact comparison of the bytes.  Specifications that use MoQ Transport may constrain the information in these fields, for example by restricting them to UTF-8.  Any specification that does needs to specify the canonicalization into the bytes in the Track Namespace or Track Name such that exact comparison works. </ins> 2.3.2. Each track MAY have one or more associated connection URLs specifying

Related discussion:
text: Summary of IETF 118 meeting is there are no restrictions on at the moq transport layer but there may be a layers above this. This is to say the compare function for track namespace and track name are the equivalent of posix memcmp.
Looks fine to me. Agree with most of the nits suggested by Ian
Code change:
Verification of the JWS JSON serialized SD-JWT follows the same rules defined in verification, except that the SD-JWT does not need to be <del> split into component parts and the disclosures can be found in the </del> <ins> split into component parts and the Disclosures can be found in the </ins> respective member of the JSON object (or elsewhere). Using a payload similar to that from Example 1 [1], the following is

Related discussion:
text: Editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure (to Confusing terminology) Editor's draft PR preview: URL
Hi, Disclosure is used at least two ways in the document. to refer to the array containing the salt, (maybe name), and value. to refer to the base64url encoded string It's easy to understand how this could have happened, as both contain logically the same information. I propose explicitly calling these: disclosure array, and disclosure presentation I also propose calling the hash/digest of the disclosure the disclosure digest in full in every use. The only time we would use "disclosure" without one of these modifiers is talking about the process of disclosing in general. As for the plaintext of the claims that can be disclosed, I propose blinded claim. So the first paragraph of Section 4.1 would read: An SD-JWT consists of: a signed JSON document, a list of disclosure presentations (each of which reveals a blinded claim), and optionally an issuer key binding (discussed in Section 4.3). The signed JSON document (the JWT body) contains plaintext claims; and disclosure digests, each of which either refers to a specific blinded claim or is a decoy. The holder can include zero or more disclosure presentations without breaking the signature of the JWT body. The contents of the blinded claims cannot be modified, because the corresponding digest would no longer match any digest in the JWT body. Blinded claims can be individual object properties (key-value pairs) or array elements.
This is appreciated! I agree that we should be more consistent with our terms. I'm not sure about "disclosure presentation" as "presentation" suggests a specific meaning. Maybe just "disclosure" and "disclosure contents" is fine.
The current document attempts to mostly use "Disclosure" to mean the base64url encoded string. I think that works okay. Places where it's referring to the decoded JSON array should be fixed to be more clear. So I think I agree that "disclosure" and where needed "disclosure contents" would be good.
PR has editorial updates for more consistent treatment of a Disclosure vs the contents of a Disclosure
made one suggestion, but overall, looks good to me! thank you!
Code change:
5. <del> Transparency Services are often publicly accessible.  Issuers should treat Signed Statements (rendering them as Transparent Statements) as publicly accessible.  In particular, a Signed Statement Envelope and Statement payload should not carry any private information in plaintext. </del> <ins> Issuers should treat Signed Statements (rendering them as Transparent Statements) as publicly accessible.  In particular, a Signed Statement Envelope and Statement payload should not carry any private information in plaintext. </ins> Transparency Services can have an authorization policy controlling who can access the Append-only Log.  While this can be used to limit

Related discussion:
text: I would not assume certain deployment situations. It is likely that there are many Transparency Services that are not necessarily publically accessible to everyone and the entire architecture would still be totally valid
I agree NAME I know of at least one registry (Transparency Service) that will not be publicly accessible.
NAME always public or not, should we not consider that as material for privacy considerations that follow the line your recommended deletion?Thanks for the updates LGTM
Code change:
messages; the stream identifier of zero cannot be used to establish a new stream. <del> HTTP/1.1 requests that are upgraded to HTTP/2 (see discover-http) are responded to with a stream identifier of one (0x1).  After the upgrade completes, stream 0x1 is "half-closed (local)" to the client. Therefore, stream 0x1 cannot be selected as a new stream identifier by a client that upgrades from HTTP/1.1. </del> The identifier of a newly established stream MUST be numerically greater than all streams that the initiating endpoint has opened or reserved.  This governs streams that are opened using a HEADERS frame

Related discussion:
text: HTTP/1.1 to HTTP/2 Upgrade was never widely deployed and has no particular defenders. This change removes the text explaining and defining the mechanism. This change still requires discussion on the mailing list.
NAME I've returned the two IANA registry entries and pointed them backwards at RFC 7540, as the sections that define those fields were removed from this document. I'm not actually sure that's the right IETF process there. Happy to take guidance as to what I should be doing instead (e.g. putting in a pair of dummy sections saying that the field and token don't have semantics any longer and referring to those instead).
Ok, I've replaced the registrations with tombstones, this is ready for another go around.
It would be good to more explicitly say that the upgrade mechanism is NOT RECOMMENDED, both because we're encrypting everything and because of the it enables (even if they're mostly shoddy implementation, it's more surface area).
Sounds like a reasonable addition, but it might be better to track that with a separate change.
Happy to add that here or make a separate change, either way.
Looking into this a little more, I think that Section 10.3 () is probably where some extra warnings might be worthwhile. The reason I might prefer a separate change is that we can hit Upgrade, Transfer-Encoding, Content-Length, and other Connection fields at the same time if we do it right.
This has not been implemented, so can likely go. See the discussion on URL for more context.
I’m in favour of removing this. It’s clear that the ecosystem has not found a use for it.
As a co-author of this one, I agree as well. This resulted from a misunderstanding of the use of the preface that everyone happily uses in clear to distinguish between H1 and H2 (and hence serve as a much easier upgrade).
Seems to have support; does anyone have an issue with this?
As stated in today's meeting, this sounds good to me, but it's worth posting on the list.
Code change:
doing so (e.g., qvalues on and similar request header fields), that mechanism MAY be used to <del> select preferred responses; of the remainder, the most recent response (as determined by the </del> <ins> select a preferred response.  If such a mechanism is not available, or leads to equally preferred responses, the most recent response (as determined by the </ins> header field) is used, as per constructing.responses.from.caches. <del> Note that in practice, some resources might send the Vary header field on responses inconsistently.  When a cache has multiple responses for a target URI, and one or more omits the Vary header field, it SHOULD use the most recent non-empty value available to select an appropriate response for the request. </del> <ins> Some resources mistakenly omit the Vary header field from their default response (i.e., the one sent when no more preferable response is available), selecting it for requests to that resource even when more preferable responses are available.  When a cache has multiple responses for a target URI and one or more omits the Vary header field, it SHOULD use the most recent (see age.calculations) valid Vary field value available to select an appropriate response for the request. </ins> If no selected response is available, the cache cannot satisfy the presented request.  Typically, it is forwarded to the origin server

Related discussion:
text: Need to talk about the on-the-wire scenarios; representation w/ vary vs without.
When making the edit above, I started to wonder what the best strategy was to recommend: Use the most recent valid Vary field value (current text) Just give the one without a Vary field value the lowest priority Thoughts NAME NAME ?
This language is a bit ambiguous regarding whether the received response is included in those considered, etc.
On second reading this wasn't as bad as I thought; made a few small editorial clarifications.
Code change:
cache or by forwarding the request towards the origin - by following the algorithm defined in cache. <del> Its companion the Variant-Key response header field (variant-key) indicates which representation was selected, so that it can be reliably reused in the future.  When this specification is in use, the example above might become: </del> <ins> Its companion Variant-Key response header field (variant-key) indicates the applicable key(s) that the response is associated with, so that it can be reliably reused in the future.  When this specification is in use, the example above might become: </ins> Proactive content negotiation mechanisms that wish to be used with Variants need to define how to do so explicitly; see define.  As a

Related discussion:
text: For
Allow a response to associate itself with more than one variant. (moved from mnot/I-D)
Code change:
jurisdictions and if so their values need to be obsfucated.  For example, originating IP address ("req_ip") is often considerd personal information and in that case must be protected through some <del> obsfucation method (e.g.  SHA256). </del> <ins> obsfucation method (e.g. salted SHA256). 10.2. Txn-Tokens SHOULD NOT be logged if they contain Personally Identifiable Information (PII).  What constitutes PII depends upon the use case, but in some cases even an email address (which could be a "sub" value) can be protected PII, which should not be logged. </ins> 11.

Related discussion:
text: I'll create a new issue to track that logging concern
From Yaron's : : salted SHA256. : also, in most cases txn tokens MUST NOT be logged because they contain PII (e.g. a subject that's an email address).
I'm ok with these changes. I think we could give some more advise around logging that could be useful to the industry.
Code change:
clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, or similar, are cleared. <del> 4. </del> <ins> 5. </ins> This document defines the "Accept-CH" and "Accept-CH-Lifetime" HTTP response fields, and registers them in the Permanent Message Header Fields registry. <del> 4.1. </del> <ins> 5.1. </ins> Header field name: Accept-CH Applicable protocol: HTTP

Related discussion:
text: NAME - can you take a look and see if that clarifies things?
This seems helpful given what's currently in the spec. However, I think some of the material I was talking about when I filed is no longer there. But I suspect that material may now be in other specs, and could perhaps still gain from being clarified at its current location.
I've been reading Client Hints (both and the ), and I'm having a little trouble understanding how things fit together in terms of which header fields are sent when and lead to what. My confusion started when I looked at the section and noticed (to my surprise) that was being registered as both a request header field and a response header field (when, having read the spec quickly, I was expecting it to be only a response header field, and wasn't sure what it would mean as a request header field). Then I looked back over the spec, and noticed that section 2 of the spec is called but that the entirety of the section appears (I think) to be about response header fields. I think it would help the spec be easier to understand if it: more carefully distinguished between request header fields and response header fields, and more clearly explained what the request header field is.
lgtm, thank you!
Code change:
The JWT MAY contain other claims. <del> The JWT MUST be digitally signed using an asymmetric cryptographic algorithm.  Relying parties MUST reject the JWT if it is using a Message Authentication Code (MAC) algorithm.  Relying parties MUST reject JWTs with an invalid signature. </del> <ins> The JWT MUST be secured using a cryptographic signature or MAC algorithm.  Relying Parties MUST reject JWTs with an invalid signature. </ins> Relying parties MUST reject JWTs that are not valid in all other respects per "JSON Web Token (JWT)" RFC7519. Application of additional restrictions and policy are at the <del> discretion of the verifying party. </del> <ins> discretion of the Relying Party. </ins> The following is a non-normative example for a Status List Token in JWT format:

Related discussion:
text: As the similar requirement was relaxed on SD-JWT, I think we should consider the same.
Code change:
values for parameters whose values have already been established. Only the most recent value provided setting value applies. <del> The SETTINGS frame does not have any frame specific flags. </del> <ins> The SETTINGS frame does not define any flags. </ins> SETTINGS frames always apply to a connection, never a single stream. The stream identifier for a settings frame MUST be zero.  If an

Related discussion:
text: Also reservers flag 0x2 in DATA and HEADERS frames and renumbers flags accordingly.
Please feel free to exercise editorial privilege with respect to wording. Reserving 0x2 at NAME requests.
Code change:
compression and allowing multiple concurrent exchanges on the same connection. <del> This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged. </del> This document obsoletes RFC 7540 and RFC 8740. Discussion Venues

Related discussion:
text: The abstract says This is taken directly from RFC 7540, and seems a bit old hat given where we are at now.
Yeah, probably not needed any more. Propose text?
Code change:
are recommended to pre-allocate lists, use dead entries that are never assigned or other obfuscation mechanisms <del> 5.4. </del> <ins> 6.4. </ins> <del> TODO elaborate on issuers generating unique status lists per JWT token that do not offer herd privacy </del> <ins> TODO elaborate on issuers generating unique status lists per Referenced Token that do not offer herd privacy </ins> <del> 5.5. </del> <ins> 6.5. </ins> TODO elaborate on increased privacy if the status list is hosted by a <del> third party instead of the issuer reducing tracking possiblities </del> <ins> third party instead of the issuer reducing tracking possiblities TODO evaluate deifnition of Status List Provider?  An entity that hosts the Status List as a resource for potential verifiers.  The Status List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. </ins> <del> 6. </del> <ins> 7. </ins> This document has no IANA actions.

Related discussion:
text: We can also call it something else like credential if we do a proper introduction of the term in the beginning?
Why call "status list token" and not "status list JWT/CWT"?
agreed on call: rename Status List to Status List Token introduce Status List for the actual bitarray rename Subject Token to Referenced Token remove Status List Provider for now and introduce it later if neccessary
btw sd-jwt vc spec mentions status provider :)
NAME NAME can you approve this PR?
Hi, thinking more about this, status list Token is being referenced in the token-whose-name-we-are-trying-to-find, so it's the status list token that is actually a "referenced token". Can we call token-whose-name-we-are-trying-to-find "a Token with reference"?
Yes, I agree and had the same thoughts when I changed the PR. I assume Referencing Token could be better. But let's accept this PR and move discussion to an issue instead...
Multiple approvals and discussions on editors calls, merging
opened issue to continue the terminology discussionok. Then please migrate the TODOs afterwards.