jiebi/CodeConvo huggingface dataset:
Issue
In the case of a government end point, why must client authentication be implemented. The signature on the statement is the authentication for the content and is ultimately who is making a reputation statement.
Agreed. In addition to this I think there are several places where we need to clean up seemingly helpful implementation comments which are actually harmful. For instance the mention of using auth for rate limiting is a fine thing to say but it's nothing to do with SCITT and will be done in other layers by any sensible implementation.
Resolved by
The optional API endpoints have intent statements that outline the goal of the Endpoints for example 2.2.1 (Issue Signed Statement Endpoint) has this intent statement: Such a statement is currently missing from both: (Transparency Configuration) and 2.1.2 (Signed Statement Registration).
I'll take this one and put a PR up with consistency for all the endpoints
This was fixed in
LGTM
states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. URL
Esko adds: What about the case where DHCPv6-PD is available, but the stub router doesn’t get the desired prefix length or encounters some error in the process? In that exceptional case it still MAY allocate a prefix out of its ULA prefix. Depending on the reader, “is available” and “works for me” can be different things.
My suggestion: Right, MAY would be way too unspecific in that case. MAY basically says "we aren't saying you shouldn't do this, nor that you mustn't do this." :) So I think as you say that what we really need here is to be more specific about exactly what "is available" means. So, perhaps: If IPv6 prefix delegation and IPv6 service is both available on the infrastructure link, then the stub router MUST attempt to acquire a prefix using IPv6 prefix delegation. and Therefore, when the stub router is able to successfully acquire a prefix using DHCPv6-PD, it MUST use DHCPv6 PD rather than its own self-generated ULA prefix.
Explain what to do if prefix is to narrow, and also if it is too wide. states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix.
and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. In my defence, I have been left unsupervised.
Also: change scripts that BAP is invoked with correct options. Note: I did not use "%i" for case-insensitive strings as this is the default anyway. If there is confusion about how a certain protocol element is matched, we should re-state that IMHO in the prose. The collected ABNF uses non-extended ABNF syntax. If this is a problem I'll need to do a bit more work on the tooling.
Should we just adopt wherever we use a string?
Yes, I think that's what the IESG wants us to do. (We were directed to use it in alt-svc)
I've started a branch (mnot-133). Question: do we want to convert things like this: into: ? We do that a fair amount for case-sensitive strings.
Yes. Let me take care of this.
+1
OK. I'll leave my branch there if you want to start with it; otherwise feel free to delete it.
FWIW, I'd prefer to do this only in the places where the string actually is case-sensitive.
I guess I forgot to close the ticket.
Looks good to me. I checked and we also say that they're case-sensitive in the accompanying prose for each instance (although for weak ETags, it's a bit far away).
This had consensus in the past, but a PR wasn't written. Particularly now that we have Object Status, which is optional for all other mappings, it makes sense to add the length and make things consistent.
In our current encoding, you can stream objects without knowing their length in advance if your forwarding preference is Object or Datagram, but not if it's Track or Stream (since those require explicit lengths in the front). I feel like those two aspects should not be tied: we should either support or not support streaming for all preferences.
Individual Comment: In order to stream multiple objects with unknown lengths in a multi-object stream, you'd need additional framing. Alternately, we could create single-object variants of the TRACK and GROUP stream header.
I agree it's weird to have a mix of unframed and framed messages. While I prefer unframed streams... I think we should state that MoQ objects are always framed, represent a single point in time, and have a known length. It's an optimization to withhold the length in the datagram and dedicated stream case but maybe we should include it.
In meeting we decided add a length to everything. We can add extension later to have no length if we need ( Thanks to Mike E for suggestion )
LGTM
Fixed an editorial problem resulting in removing the end of the sentence, which went on to say that you can't assume DSCP, etc. Also changed /many deployments/ to simply say this happens without saying it is often.
From NAME review: Section 3.2.2: Although there are clearly a number of network especially access networks that do deploy and use DSCP classes for its real-time media traffic I think this sentence is misleading. I would think that the majority of the WebRTC traffic carrying audio and video will in fact not be marked or have DSCP markings that survive into the general Internet. I would at least suggest to rewrite the above first sentence to indicate that although this may occur, the CC algorithm under consideration will have to deal with this type of traffic.
This PR does the following: make verification that the public key of the Issuer-signed JWT belongs to the Issuer mandatory introduce methods to perform this verification based on JWT Issuer Metadata, X.509 Certificates and DIDs Potentially . Partially Out-of-scope: Renaming and moving JWT Issuer Metadata Section
Addressed all suggestions, please review again NAME
I had to rename the section. I think now it is more precise.
Show possible options like JWT Issuer Metadata, being a DID URL etc.
We introduced a new section that talks about different key discovery methods during the verification process in PR
This is a first stab at . I've gone for a minimal change here, simply clarifying that only HEADERS and PUSHPROMISE frames have the effect of implicitly closing streams. While I was writing this I did have a question that may need to be raised on-list: do HEADERS and PUSHPROMISE only implicitly close streams if they are accepted? That is, if a client sends a HEADERS frame that triggers a stream error, does that HEADERS frame still implicitly close all streams with a lower stream ID that are in the "idle" state? This may also be worth clarifying.
Like it. Take the first, maybe take the second, and we can merge this one.
The HTTP/2 rules are related to field value validation, so move them there. The rules about Connection fields are not necessary, but it won't hurt to be clearer.
the rules of Section 8.2.1 of [H2]. A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed (Section 8.1.1 of [H2]) as invalid; see Section 4. Those references are doing a lot of work -- but does it also include 8.2.2? I.e., are and friends allowed? It's ambiguous, because the text implies all things that make it malformed, but only points to one source.
No point duplicating that work, but I agree that it might be unclear as stated. Does this split make it clearer? I'll make a PR with those changes in context. (I think that the latter is consistent with what you and NAME are discussing on-list, though I need to spend a bit more time on understanding that.)
I think it does the job, indeed!
Changes SUBSCRIBE so you can't go back farther than the current Group with any of the filter modes. If a SUBSCRIBE tries to go back farther, it is closed with a SUBSCRIBE_OK. Alternatively, instead of failing the subscription, we could specify that the SUBSCRIBE will be truncated and start at the beginning of the current group.
LGTM.
LGTM .. I had couple of questions on error condition to be MUST instead of SHOULD.
Added text to address issue regarding the value of the claim within the Txn-Token
From Yaron's
Text from Yaron's email: : I think txn should be OPTIONAL. While it is very useful, there may be architectural reasons why transaction ID issuance in an organization is independent of transaction tokens.
I'm curious to the use cases? I'd prefer a way to make the claim REQUIRED and allow an organization to provide it's own value in that context. Maybe we could go with RECOMMENDED? This is one of those cases where people who know what they are doing can potentially remove it or possibly provide a "N_A" value and it will be fine. However, if it's OPTIONAL most developers will not specify the value and then they will lose a lot of value from the Transaction Token.
No specific use cases, it's just that we're assuming that an organization can easily integrate its (preexisting) transaction ID-issuing service with this one. Sometimes it can, sometimes it can't. I'm good with RECOMMENDED.
NAME please review PR which addresses this issue
We currently use the URI: "urn:ietf:params:oauth:token-type:txn-token" to denote a Txn-Token in requests or in the token itself. However, if I look at other entries in the OAuth URI Subregistry here (URL), they use the "token" style for the token types. We also use that style when the subject-token-type is "selfsigned". So I'd like to propose that we use the URI: "urn:ietf:params:oauth:token-type:txn_token" for the transaction token URI.
Agreed with aligning to the common practices elsewhere.
Explains Feed as the logical collection, with (Subject) as the property to represent the collection.
That seems pretty reasonable to me. Are there any reasons to keep both?
While I'd agree less is more, this keeps coming back when we try to explain it. A feed is a known concept for a collection of related data We're using CWTClaims , which also makes sense to align with existing specs We avoided Artifact ID Attempting to describe a collection of statements as a subject doesn't resonate. We can keep Feed as the concept, and simply say CWTClaims is how you set an identifier for the feed. How does that work?
Then we should deprecate the term feed in discussions, too, and just explain how a subject is used as a subject in this context?
Updated to merge in PR feedback
NAME NAME NAME PTAL as I've made some updates.
This issue is from a related discussion on Apache httpd, which was trying to comply by sending a 504 even though the revalidation error was a 502. That's nuts. The current text for says: However, if a proxy/gateway received a 5xx response while trying to revalidate, this requirement forces it to toss that information and supply a useless 504 instead. That isn't desirable. The entire purpose of this requirement is to make sure that the cache does not respond with its stale entry. Hence, any 5xx code is sufficient.
To fill in more detail, the change in question is this one: URL And covers the wide question of "which 5xx response is returned in low level network failure cases, such as DNS error, connection refused, connection timed out, etc". The commit message referred to RFC2616 14.9.4 Cache Revalidation and Reload Controls, but this seems to be a wider issue.
Yes, that MUST is too strong; I suspect it's there to make the mechanism reliable, not override other potential status codes. Will work on a PR.
Addressing Issue I did not add anything explicit to the Security Considerations section and instead mentioned the potential security exposure in the text on User Experience
First item to add is guidance on limited input devices.
NAME I recall we discussed this, but unable to recall the details of the concern on what guidance we had in mind.
Notes from editor's call: "Not recommended to use this with challenges that require significant user experience challenges, for example entering a password on a TV screen with an on-screen keyboard." Security consideration around the differences between exposure of credentials on a TV screen in a room vs the risk of a cross-device flow We don't want to discourage the possibility of using this flow with a passkey on a TV remote control "If you're on a limited input device, and the authentication method the user must pass requires significant user interaction, e.g. entering a password, then you shouldn't use this method; use the device flow instead."
Completed in
The I-D contains the following TODO we might add a SETTINGS parameter that indicates the next hop that the connection is NOT coalesced (see URL). I'd like to track that discussion here. Namely, with all the changes in the meantime, does NAME think that there is still a problem that needs fixing? OR can we close with no action?
I don't think anything additional is needed. We've got the two standard header options to indicate an intermediary is involved, that was the main point of the original discussion in Singapore IIRC. I think this won't matter all that much in practice, given warmed up edge-to-origin connections, pops being able to serve cached resources in between, etc. Origin owners really concerned with performance will know if their setup is coalescing or not (then the question is if origin server software allows tweaking prioritization behavior, but that's a general concern). CDN owners seeing bad origin behaviour will probably just overwrite the priority information instead of forwarding in practice. In short, I think the current text should suffice here, as I don't think many servers would support switching to RR when seeing an explicit "warning: coalescing intermediary" signal either way.
Thanks NAME In that case I've created to simply remove the TODO text, which will act to resolve this issues.
Explicitly state that these IDs are numbers that can be compared to determine order. This is already implicit in a number of places in the draft.
NAME and NAME Said that group IDs may be sparsely used, particularly in cases when they were chosen in a way to avoid collisions. This sounds like an interesting set of use cases, but previously my understanding was that groups indicated some sort of temporal ordering, even if it's not strict. If Group IDs don't imply temporal ordering and join points, and instead they're a way to publish Objects in a way that don't collide with one another, it seems like a different thing? Top of head strawman: Possibly different users could have the ability to publish Objects as themself for a single track? Having a few specific use cases would be helpful here, because it feels like there are real use cases, and the existing mechanisms might be awkward at best? It would also be useful to understand the use cases so we understand if they're in scope for MoQ.
Possibly relevant to
I have advocated strongly for having Group IDs begin at 0 and increment by 1, with no gaps. This restriction (which is identical to what we have for Objects) brings us some valuable benefits: Arbitrary relays, without any other information, can know if Groups are missing Clients can tell if groups are missing, without having a catalog to define the numbering scheme. I spoke this over with Cullen and Suhas. They mentioned that they have a use-case in which clients will publish data under the same namespace and name, but using different ranges of groups IDs (correct me if I'm wrong there guys) and that therefore GroupIDs cannot increment by 1. My concern is that this one use-case is burdening the transport with a whole ton of complexity around knowing where there are gaps. Witness . I'd like to simplify moq-transport by setting restrictions on GroupsIDs and then help brainstorm alternate solutions to their multi-publisher use-case that are compliant with a simpler version of moqt.
I completely disagree with the use-case NAME and NAME have suggested. A track must have a single publisher and I just can't envision how MoQ would work otherwise. If you have multiple publishers, then make multiple tracks/namespaces. A subscriber can request them all. Or a muxer can request them all and produce a new merged track at incrementing group boundaries.
I am also in favor of Group ID beginning at 0 and incrementing by 1.
There was this issue discussion on groupId and gaps and why relays need not do the book-keeping on gaps between groupIds or such .. URL
I'm totally lost on what problem people think they are trying to solve with this issue. I really object to how we constantly reopen stuff for no reason. The protocol works fine with multiple publishers and out of order groups - we have running code that does that. We have discussed this is the past and the use cases. There is no new data that is like here is why this causes performance problems. We have multiple use cases that take advantage of this. ( some of the variations of group chat, logging, metrics ) GroupID are left to the applications using them to choose. Due to timing and priority issues, if a relay receives group 2, object 1, it can not assume it will never receive another object form group 2. Some applications use them to indicate ordering and dependency. The data model makes it clear they are a join point, and because of that things that have dependencies can use them for the dependent things. The proposal we had for make before break can results in out of oder groups.
Speaking as Chair: NAME The issue as filed is soliciting use cases. Will stated you have some, it would help if you could document them here in as much detail as possible. Other folks seem to be advocating for a particular design without seeing the full picture. It would probably help if we understood the use cases first. I'm surprised to hear about use cases where multiple publishers are publishing to the same track simultaneously in different groups. I don't ever recall talking about this pattern, apologies if I missed it. Victor pointed out here (URL) that arbitrary group or object numbering interact poorly with subscribe ranges/fetch. Because a relay can never know the how the id spaces are populated for a track, the relay/cache has to assume all ids exist until told otherwise by the original publisher. Suhas indicated that if a publisher drops (skips?) a group it will signal that. There are scalability challenges if the 62 bit space is sparse - perhaps people were talking past each other in the issue?
I think the group is struggling because use cases and the protocol design elements they depend on are not well documented, in writing, in a central place. I've gone back and forth about resurrecting the use cases and requirements draft and adding new detailed sections that have this scope (eg: explaining make-before-break, and what moqt protocol elements it requires). Ideally, we would get consensus on the use cases we are trying to support. Would folks find it helpful? I'm wary of having folks invest in writing something if we're not going to read it.
As discussed at length in the other issue, "no relay should not assume any structure between groups". Groups are independent join points and we should not add more application semantics at the MOQT layer . it tends to more bookkeeping which is not really needed.
Let me take a stab at going through the range of solutions that can exists when fetch requests are made for large absolute ranges. For this discussion, I am ignoring caching since it is easy to think through caches independently. When a relay receives a fetch request for large absolute range, one the following can be the response it gets from the upstream Relay receives a marker object for each group that is not included. Relay receives some kind of maker object with range of groups that doesn't exist. [ this is optimization on 1] Relays receives no indication on the groups not included. These options apply similarly regardless of group Ids being sequential or non-sequential and when things are missing or not produced or so. Does this makes sense ? Happy to add a PR to clarify some of these .
NAME NAME and others, We're not looking for solutions to support non-sequential groups yet - we're still looking to get documentation of the application use case that drives the non-sequential group requirement.
So I know this sounds a bit snarky and I really don't mean it that way but have you read URL ? There also been a bunch of similar things. I sort of work on the assumption chairs are reading the drafts in the WG.
:D Thanks for the bump. Well now I've skimmed it at least far enough to see this: I'll take a closer look. Let's use the metrics repo for any discussion about it's design rather than having it here. Are there other use cases you would like to surface here?
Even if the chairs are reading every draft, not everyone else in the wg is.
So lets imagine the client requests the range 0-10,000, but the publisher only produces group ID's at odd numbers. Is the proposal that each relay in the distribution chain send along 5,000 marker objects to indicate the gaps? That doubles the number of objects sent in response to each subscription. Compare that to a scheme in which groups IDs are sequential and zero markers need to be sent. Surely a marker-less scheme is more efficient in caches and across the wire?
So the use case for fetch has generally been VOD and getting the most recent 15 seconds on live streaming video. Both of these case would make sense to use sequential groups so I don't see this problem. The use case people have brought up about sparse groups are not so much cases where getting the old data makes much sense and also some of them the applications know what the groups are if they wanted them. I'm of course not suggesting a classic VOD use case would use non sequential groups, however it might on scalable codecs, but what I don't see why the relays do anything different if groups have to be sequential or not. Consider a live streaming like use case where groups are sequential and it is stream per group. A relay gets 3 streams coming in to it and on stream A get gets an object in group 1, on stream B it just waiting and has not received anything yet. And on stream C it gets an object from group 3. I probably don't want to have the relays not send objects from group C because they are waiting for something that might arrived from group 2. I'm not understanding what people think they want to do in the relays that requires the groups to be sequential. Overall, we need a design for fetch (lacking a better name for subscribe to old data). If fetch ends up for priority reasons to be delivered over a single stream, then it upstream just puts in order stream. Of course other designs are possible but am not getting what people want and why
My intent was not to provide a solution. I was instead proposing non-normative clarification text on the solution space which applies similarly regardless of the groupId structure.