jiebi/CodeConvo huggingface dataset:
Code change:
Final Object: The largest Object ID sent by the publisher in an OBJECT message in the "Final Group" for this track. <del> 6.10. </del> <ins> 6.9. </ins> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBEs for tracks within the announced

Related discussion:
text: I'm leaning towards CLOSED instead of CLOSE because CLOSE implies its a requested action, so to me SUBSCRIBE_CLOSE sounds like something the subscriber would send, not the publisher. For a similar reason, I like CANCEL slightly better than STOP, but both work. UNANNOUNCE and UNSUBSCRIBE are good words, but I think it's better to follow a pattern in this case and I like NAME sequence of messages.
NAME CANCEL and CLOSED are slightly better, sure. NAME there MUST still be an OK before objects can be sent. That way the receiver can tell upon receipt of the CLOSED if the subscription was ever active.
So to add an OK, we need to add another state. The question for me is what is the use case where we need to deliver that information in the end of the subscribe.
This discusion is probably easier looking at state machine diagrams
Sections 6.8 and 6.9 strongly imply that SUBSCRIBEFIN/RST are sent at the true end of the track. So are they not sent at the conclusion of a SUBSCRIBE that does not cover the end of the track? For example, if the last object of a track is (10, 12), and there's one subscribe for (4,0) to (5, 100) Is there a SUBSCRIBEFIN? If not, how does the subscriber know that in fact (5, 60) is the last object in that subscription? If so, does Final Group and Final Object refer to the last object in the subscription?
Individual Comment: Putting my HTTP hat on for a second, when you ask for something with unknown length, you infer from a graceful termination that the last thing you got was the true end of that resource. If you send a range request, the graceful termination at the end does not convey that the last thing was the true end. Once the object expires, you can issue another request to the same name and potentially get a totally different thing. Does this model work for moq, or do we need something different?
There are three different things you might want to communicate to a receiver at the end of the subscribe: 1) You got all of the objects in the range; 2) You got almost all of the objects, but some were dropped for latency/bandwidth reasons 3) The track was truncated for some reason and possibly, 4?
Code change:
Final Object: The largest Object ID sent by the publisher in an OBJECT message in the "Final Group" for this track. <del> 6.10. </del> <ins> 6.9. </ins> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBEs for tracks within the announced

Related discussion:
text: 4) You got everything I have but i'm not sure if that's everything
is somewhat relevant to this issue.
As mentioned in , there are 3 different ways for a publisher to close a subscriber, each with minor differences. : I never sent you an object. : There are no more objects to send after group/object X/Y. : There are more objects after group/object X/Y... but I won't send them. A few things: I think it should be renamed since it's not the only ERROR message. Maybe ? The only difference is that one has an error code. Otherwise they both include a final group/object and it's up to the application/library to decide if they wait for the final object(s). I'd like to only implement this once but right now I have to copy/paste any code to handle these almost identical messages. What if we merged them and use error code 0 to signal a FIN. The reason phrase should be removed as part of . There really needs to be a state machine like with this many ways to terminate a subscription. I think these are all protocol violations: then then then My interpretation of the draft is that a followed by a is invalid, which is not obvious and unlike QUIC. I don't think so. The library/relay behavior doesn't change based on . The only thing that miiiight differentiate between the two is the application, which can use errors codes for this purpose. At the very least I would merge these two messages. But I would also like to explore a single way for the publisher to close a subscription. The application can signal the nuanced differences between errors (ex. error code 404 vs 410). The library/relay doesn't care, it just forwards the error code.
Individual Comment: The inspiration for FIN vs RST in moq came from HTTP caching. If a resource has no content-length, and the caching proxy has received N bytes, does it have the entire resource, or does it need to refetch the tail? If that response was terminated with a FIN (H2 or H3), then it has the whole resource. If it was terminated by a RST, it can't assume that it does. So the value I see in these two messages is for a moq relay is similar.
Code change:
Final Object: The largest Object ID sent by the publisher in an OBJECT message in the "Final Group" for this track. <del> 6.10. </del> <ins> 6.9. </ins> The publisher sends the ANNOUNCE control message to advertise where the receiver can route SUBSCRIBEs for tracks within the announced

Related discussion:
text: A client connected to the relay and subscribed to a track, which fowarded the subscribe to a publisher. The track was published to the relay and ended with a FIN. Another client subscribes to this track from the beginning (Absolute/0,0) and no end. Does the relay need to resubscribe upstream? Now suppose that the connection from the publisher to the relay closed abruptly, or the track was terminated with SUBSCRIBE_RST. This is a signal to the relay that it's worth another subscribe to find out where the end of the track is. I can live if we consolidate the framing to a single message, and define a special error code to mean FIN, but I do think the transport needs to see the difference.
I like it. I would also like to merge ERROR with CLOSED, but we'll chat about that.
Code change:
<del> The Transparency Service MUST perform resolution of the Issuer's identity, which may be different than the Client identity.  This step may require that the service retrieves the Issuer ID in real- time, or rely on a cache of recent resolutions.  For auditing, during Registration, the Transparency Service MUST store evidence of the lookup, including if it was resolved from a cache. </del> <ins> The Transparency Service MUST syntactically validate the Issuer's identity claims, which may be different than the Client identity. </ins>

Related discussion:
text: Hi all, This PR comes from a place that agrees: If using an identity scheme, then yes, it must be used in maner consistent with that scheme, But aslo that There is no identity scheme we could all agree on as universally applicable or agreable, further, the space continues to evolve. And, The trustworthiness or otherwise of issuers identity, in the context of a transparency ledger, is temporal and subjective in nature. It's just a question of time frame. This means that regardless of registration time checks, relying parties, auditors and general consumers will have to re evaluate regardless. And will do so according to their own subjective context. Remembering that "It can never be assumed that some Issuers and some Transparency Services will not be corrupt.". And also "A Verifier SHOULD validate a Transparent Statement originating from a given Issuer" ... "and would not depend on any other Issuer or Transparency Services." It does seem obvious that, Syntactic validation of the issuer identity claims makes good sense and supports interoperability. But, Specifying a single identity scheme in the core architecture as "minimally required" does not meaningfully help interoperability when there is no single agreeable scheme, and especially when a TS may be used to underpin identity schemes themselves. Regarding the burden on Relying Parties and Auditors, The definition for "Relying Party" states "a Relying Parties consumes Transparent Statements, verifying their proofs and inspecting the Statement payload, either before using corresponding Artifacts, or later to audit an Artifact's provenance on the supply chain". IOW: Relying parties are already expected to deeply consider statements. Assessing the identity asserted by the issuer, at the time the artifact is being considered, seems to be a natural and useful part of that process. Registration Auditability: Requiring that Transparency Services "enough information is made available to Auditors" ... "to authenticate and retrieve the Transparent Statements" is essentially impossible to specify at this level, imposes un-bounded maintenance and storage issues on implementations, and represents a significant layering violation in the architecture.
Editors meeting: will wait 24hours for reviews, with merger if no objections.
Per the editors meeting, I've merged the discussed changes and resolved the discussed topics. I've opened to track the MUST/Should discussion, which wasn't part of this PR.
Code change:
<del> The Transparency Service MUST perform resolution of the Issuer's identity, which may be different than the Client identity.  This step may require that the service retrieves the Issuer ID in real- time, or rely on a cache of recent resolutions.  For auditing, during Registration, the Transparency Service MUST store evidence of the lookup, including if it was resolved from a cache. </del> <ins> The Transparency Service MUST syntactically validate the Issuer's identity claims, which may be different than the Client identity. </ins>

Related discussion:
text: Please review and we'll merge Wednesday morning US Pacific time if there are no objections. I'll incorporate agreed suggestions as well.
Merging with no other feedback.
good enough By and large the document is at a point where it can be called on for final reading. There are some nits or issues that we would like to see done to tighten it up. The introduction discusses distributed, but there is no real discussion of how or what that means and it leads readers to set an expectation that is incorrect. This word should be deleted. Removal of the Feeds definition. This was in the original version, and we have bounced all over the place during the last year to formulate a solution to a problem with Federation. We have decided collectively to park that and thus the use of feeds is gone. In a future overarching product or charter it could come back. There is a bit of a misunderstanding generated by stating that receipts don't expire, which later on is a line that requests for a refreshed receipt can be supported. The logical receipt is intended to never expire and based on the protected content in the ledger's log a new receipt can be generated at any time. This gives us an avenue to bridge a world from today to post quantum cryptography based counter signatures that is important. We need to clear up these two points. What goes into the append only log can vary from implementation to implementation. It may be that one implementation records the hash of the signed statement, plus evidence of how we proved that it was valid at the time of acceptance (things like records of OCSP response, or CRL lookups). Another implementation may simply store the signed statement. This from a generic point of view means that given access to the signed statements you can prove that it is on the append only log always. In section 4.1.1.2 it alludes that an auditor can mine the log to authenticate and retrieve the transparent statement. Based on the last statement this has two problems. The first it assumes that the signed statement is kept and that it can generate a new receipt (see 3) and produce a transparent statement. If it could this would be equivalent to the original in intent but not binary equal. The original receipt (or last created receipt from a refresh) is not required (or intended) to be kept in the ledger.
Code change:
<del> The Transparency Service MUST perform resolution of the Issuer's identity, which may be different than the Client identity.  This step may require that the service retrieves the Issuer ID in real- time, or rely on a cache of recent resolutions.  For auditing, during Registration, the Transparency Service MUST store evidence of the lookup, including if it was resolved from a cache. </del> <ins> The Transparency Service MUST syntactically validate the Issuer's identity claims, which may be different than the Client identity. </ins>

Related discussion:
text: Generically then this is impossible and may be where we would leverage consistency proofs in a later version.By and large the generic aspect of the document is there but we missed one sentence: "Signed Statements and Artifacts associated with a software package." We would suggest removing the "software package".
Code change:
claim of the SD-JWT MUST be used. <del> Furthermore, the recipient of the SD-JWT VC MUST obtain the public verification key for the Issuer-signed JWT as defined in public-key- discovery-for-issuer-signed-jwts. </del> <ins> Furthermore, the recipient of the SD-JWT VC MUST validate that the public verification key for the Issuer-signed JWT as defined in issuer-signed-jwt-verification-key-validation. </ins> If there are no selectively disclosable claims, there is no need to process the

Related discussion:
text: This PR introduces the following changes: - - Fixed SAN Extension rule Removed all options for X509 except
NAME pls review again.
Fixed merge conflicts and reconciled with PR . Nothing new should have been introduced than what has been approved already. If NAME or NAME can approve again, then we can merge imo.
The section should be renamed to "Issuer-signed JWT verification key validation" since the section is about checking that the value corresponds to the key that signed the JWT. The process of obtaining it via different means is just the first step. We should also fix the language in the "Verification and Processing" section to say: instead of
Fixed by
The rules to obtain the verification key from X.509 should be changed to use the from the SAN extension instead of the (which does not exist). Furthermore, since can potentially start with a https scheme, the JWT Issuer Metadata rule should only be enforced if no x5* JWT header was set.
We also need to add JWT header.
Fixed by
Code change:
the client learns that the HTTP/2 priority scheme is deprecated, it SHOULD stop sending the HTTP/2 priority signals.  If the client learns that the HTTP/2 priority scheme is not deprecated, it SHOULD <del> stop sending PRIORITY_UPDATE frames, but MAY continue sending the Priority header field, as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </del> <ins> stop sending PRIORITY_UPDATE frames (h2-update-frame), but MAY continue sending the Priority header field (header-field), as it is an end-to-end signal that might be useful to nodes behind the server that the client is directly connected to. </ins> The SETTINGS frame precedes any priority signal sent from a client in HTTP/2, so a server can determine if it should respect the HTTP/2

Related discussion:
text: A few editorial tweaks to improve readability, including some x-refs to the Header / frames. The most contentious change is at L262, the sentence read a bit weird so I juggled it around to make the intent (as I understand it) clearer.
Thank you for the changes. L262 reads better now. Thank you.
Code change:
RFC6454, Section 6.2) and remove it from the connection's Origin Set, if present. <ins> When sending an ORIGIN frame to a connection that is initialised as an Alternative Service RFC7838, the initial origin set set will contain an origin with the appropriate scheme and hostname (since Alternative Services specifies that the origin's hostname be sent in SNI).  However, it is possible that the port will be different than that of the intended origin, since the initial origin set is calculated using the actual port in use, which can be different for the alternative service.  In this case, the intended origin needs to be sent in the ORIGIN frame explicitly. For example, a client making requests for "https://example.com" is directed to an alternative service at ("h2", "x.example.net", "8443").  If this alternative service sends an ORIGIN frame, the initial origin will be "https://example.com:8443".  The client will not be able to use the alternative service to make requests for "https://example.com" unless that origin is explicitly included in the ORIGIN frame. </ins> 2.4. RFC7540, Section 10.1 uses both DNS and the presented TLS certificate

Related discussion:
text: The consequences for ORIGIN + Alt-Svc with a port change aren't awesome, but this should at least remove any confusion.
Are you going to take another go at this?
Sorry, I let this one drop because I missed your suggestion, which is good.
Thanks!
Code change:
Specification document(s): want-digest-header of this document <del> 9.9. </del> <ins> 9.10. </ins> This section registers the "Digest" header field in the "Permanent Message Header Field Names" registry (RFC3864).

Related discussion:
text: Obsolete ADLER-32 but don't forbid it.
NAME will this work for you?
I think the pull request is OK as-is, but might be improved slightly. In particularly, I'm wondering if SHOULD NOT is too strong for the server. A server could support ADLER32 without that support impacting on cryptographic data integrity provided that server also supports a cryptographically secure hash; e.g., SHA-512. Clients that wish to protect against malicious actor changes would use the SHA-512 hash and not request (or ignore) the ADLER32 value. Therefore, I would suggest that, for the server, the document says a server MAY implement ADLER32. I think it is perfectly reasonable for the document to say the client SHOULD NOT use ADLER32, for the reasons stated. That said, I can't decide if this distinction is really helpful, so I defer to your judgement, here.
I'm not so sure we want to make a distinction between client and server as you write it. Both client and server can attach Digest header to request or response. It is the receiver of Digest that is exposed to the risk of using a weak digest. The current language avoids mentioning either endpoint so we leave it to implementers. I'm not opposed to spelling things out more clearly but we'd really need to nail down what we mean by "using Digest algorithms" because that relates to requesting them, generating them, regenerating them (proxy), validating them (endpoint or proxy) etc.
That's a good point about client/server. Sorry, I had that wrong. As you say, it's the recipient of a Digest that must decide whether the algorithm is sufficient. This recipient may be either the client or the server. I think the document is right to point out the dangers of accepting a weak digest. Perhaps there is a useful distinction between generating a digest and accepting a digest; e.g., an agent MAY support generating a weak digest but SHOULD NOT accept a weak digest.
Not wrong, just partially true. That could work for me. I'll leave it to NAME to decide what he things makes sense to do.
NAME NAME as this issue is for ADLER, I moved the discussion to As it's in the listed algorithms, the server MAY already implement ADLER32, though it SHOULD NOT be used by both sides of the communication. I think sender and receiver should behave consistently (see again).
Merging as for the positive feedback from NAME and NAME comment URL
Code change:
The TE field (field.te) is used in HTTP/1.1 to indicate what transfer-codings, besides chunked, the client is willing to accept in <del> the response, and whether or not the client is willing to accept </del> <ins> the response, and whether or not the client is willing to preserve </ins> trailer fields in a chunked transfer coding. A client MUST NOT send the chunked transfer coding name in TE;

Related discussion:
text: Trailers that come after the body has well-defined semantics (i.e. metadata applicable to the entire body). Interleaved, mid-stream trailers are considered and implemented as extensions, and maybe we should delay adding them to the core semantics. This is however an important topic for HTTPAPI, IMO.
See related mailing list thread at .
Discussed at Feb 21 interim; sentiment is to remove it; NAME to create a PR.
WFM, thanks.
Code change:
The "id" value string length (after any decoding) supports up to 1024 characters. <del> The "id" value is optional. </del> <ins> The "id" value is optional and defaults to the empty string. </ins> 2.1.4.

Related discussion:
text: This treats empty dictionary strings as the same as there being no dictionary and reqires all ID's have a non-zero length for the Dictionary-ID header to be sent.
NAME could you PTAL and see if this handles the case you were concerned about?
Dictionary-ID was introduced to the Compression Dictionary Transport specification by . However, it is unclear whether empty string dictionary IDs are allowed. I don't think there is any use case for an empty string dictionary ID. So how about explicitly disallowing empty string dictionary IDs in the spec? NAME
I'll make a zero-length string the default and have that mean "no ID". The dictionary ID will only be sent if it has a length > 0.
Thanks. lgtm.
Code change:
only via the initialization track field of the track which they initialize. <del> 3.2.17. </del> <ins> 3.2.18. </ins> An object holding a series of name/value pairs which a subscriber can use to select tracks for subscription.  If present, the selection

Related discussion:
text: We need the following Add Catalog Seq Number and explain how it is related to Parent Seq Num Make parent seq num independent of MoQT object number
Proposal is to add two fields: Catalog sequence number (CSN)- a required integer starting at 0 and monotonically increasing with each successive catalog update. Parent sequence number (PSN) - an optional reference pointing at a prior (not necessarily previous) catalog sequence number. If the PSN is absent, then the catalog is an independent catalog. If it is present, then the catalog represents a delta update. Having a sequence number independent of the transport sequencing allows catalogs to be distributed over moq-transport, or http or another transport and still be interpreted correctly.
Code change:
only via the initialization track field of the track which they initialize. <del> 3.2.17. </del> <ins> 3.2.18. </ins> An object holding a series of name/value pairs which a subscriber can use to select tracks for subscription.  If present, the selection

Related discussion:
text: Add a new root object to hold inheritable track fields. Update all examples.
I am not a big fan of this approach. This led to all sort of problems with SDP Session Level attributes. My main concerns How do we ensure the field that goes in this are not of type that represent aggregated values for all the tracks. Things like BW is easy to fall in this trap What problem is it solving other than moving these to per track level. May be I am missing something here . open to learn more, Thanks
There are no aggregated fields currently defined. All track selection properties, such as 'Bitate" apply only to that track. If multiple tracks have the same bitrate value, then that bitrate value can be placed inside a SelectionProperties object which is placed inside the Common Track Fields object. This is not moving anything to a per track level. Rather, it is providing a clear location to place track properties which are intended to be inherited by all tracks. IN the future, we may wish to add fields to the root which are not intended to be inherited, something for which the prior design left no mechanism for accomplishing.
makes sense and understand. We want to careful and not end up adding aggregates . How about we rename it "Inherirted Fields" instead and be explicit about it
In the current design, any track fields such as selectionParams, initTrack, renderGroup, packaging etc can be added at the root level. This design does not promote extensibility as it prohibits adding future fields to the root that should not be interpreted as inheritable track fields. Proposal is to add a new root object called "commonTrackFields" to explicitly hold fields intended to be inherited by all tracks. Example: