jiebi/CodeConvo huggingface dataset:
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?
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.
Add discussion of the tx-mode SDP parameter. Fix for Rebase of
NAME PTAL
I think we need a different approach. We want to say that support for "SRST" mode is mandatory If no tx-mode parameter is present, a value of "SRST" MUST be inferred. It is up to the offering implementation whether to include SRST or omit it. implementations that do not implement the other modes should not negotiate a codec with that mode
NAME Updated the PR to include your suggestions.
PACI packet is defined in RFC7798 ((URL, section 4.4.4). According to 4.4.4.2 it defines only a single payload header extension for Temporal Scalability Control Information (TSCI) in RFC7798, and a new payload type 50 is introduced for the PACI packet. In WebRTC, TSCI is included in generic info and sent through RTP video header extension, there is no need to implement payload type 50 to transfer TSCI as RTP payload specifically. We may ignore payload type 50 in H265 depacketizer.
Virtual interm slide is here: URL
Through the GFD (somewhat deprecated) and DD extensions?
yes. through GFD or DD depending on if it's perfectly layered according to spec.
URL NAME made a good point here about SFUs. If you negotiate DD on the sending leg, you can not strip it in the SFU or you loose the information about temporal layer. Do we need to capture this or is it more of a "middleboxes gonna middlebox" problem?
NAME I modified the PR to say that if RTP header extensions supporting TSCI are negotiated, then TSCI SHOULD NOT be sent in the PACI and if TSCI is being received in the header extension, then PACI MUST be ignored. I think this covers the broken SFU case.
Closing. At IETF 118, the proposed text was presented, and there were no objections.
Suggested AQM text to address issue, when merge will
This section is listed as a special case, which it is (kind of), but it seems rather out of place in that section - I think we might wish to move it to the previous section. Since the original BCP, AQM is more common and really ought to be considered in any new design - even if the design does not wish to optimise for this.
Previously discussed in
Editors 1/16/24: Just add a sentence that AQMs are hard to detect, and therefore must be thought about -- cannot just ban use of a CC with AQM. But this falls thematically in with the special cases.
AQ are only a problem if they introduce unexpected behavior. The classic example is rate limiting, for which BB had to introduce special code.
Although packet scheduling and policing are useful complimentary functions, I don't think they are AQM.
Sorry for the late response but I dont think this text is quite correct. If you're running MoQ over WebTransport, you're likely to be following the instructions in URL, which states My reading of the current text means that endpoints are likely to blend up treating things as a violation when there is no violation.
Section 3.3 says: "The control stream MUST NOT be abruptly closed at the underlying transport layer. Doing so results in the session being closed as a 'Protocol Violation'." I know we have multiple transports, but it would be good to clarify what an abrupt close is. Presumably any sort of RESET_STREAM, but what happens if there's a FIN? Is this a "clean close" of the session? Does it imply or force a reset of data streams?
LGTM
As stated in , it's misleading and contradictory. Better to concentrate on configuration for this, as that is the common usage.
Section 3.3 says the following about cleartext HTTP/2: I had previously conceived of Alt-Svc as requiring a certificate and TLS, but that's not strictly true. RFC 7838 says that a client MUST have reasonable assurances, and a TLS cert is one way to do that. It also says that the connection must have equal or better security properties, which implies you can't go from TLS to non-TLS. This statement suggests that it's valid to offer on an http:// URI if your server can accept direct-to-H2 connections, but doesn't explicitly say so. Is that the intended reading here? But RFC 7838 says: Perhaps that doesn't apply, because the alternative is the same server on the same TCP port. Still, I feel like this waves at Alt-Svc for a use which is, at best, under-specified; at worst, not actually possible.
It's likely because the field is ignored when parsing fails, but 8941 s 2 allows a field to specify other error handling behaivour.
How so? 8941, Section 4.2 says:
Section 2 has a bit more nuance:
You refer to: ? My reading is that this applies to the preceding text about what happens when parsing does not fail, but additional constraints are not met. If this is not the case, we should consider this to be an inconsistency in requirements and treat it as spec bug. EDIT: opened URL
As pointed out on list, we need to warn people against just using Date as an extension in a field that was defined using 8941.
The warning helps, but it IMHO does not address the larger extensibility problem we have.
NAME can you articulate that (here or in another issue, if it's substantially different / larger)?
I'll try. The main selling point for structured fields IMHO is "a unified parser". You know that a field value is SF-shaped, drop it into the parser, and get a more or less self describing data structure. Great. Now once we add extensions to SF, this get's harder. Starting with the the current proposals: A recipient of a field does not only have to know which top-level field type to parse for, but also whether to switch on support for SF-date or not. Or we would need to say that even when a spec defines a field using 8941, it still's ok to parse it with an sf-date-enabled parser. In that case, it would be up to the recipient to either ignore sf-date-typed extension parameters (if the field definition already allowed future extension), to convert them to an integer, or to reject the parsing result altogether. Retrofit parsing flags: I hope we have consensus that preprocessing values before passing them into the parser will be fragile. So a retrofit-supporting SF parser will either need modes, or the wire syntax for SF could be relaxed so that retrofit would need no new mode. The common concern here is that SF in theory is simple to extend, the process is extremely hard both process-wise and deployment-wise. Ideas: we could simply avoid doing extensions; sf-date is only a "lipstick" flag so that tools can switch on a special display mode - maybe we don't really need it?
we could try to define what future extensions mean for specs that are written for the current version of the spec My concern with the current state of things is that a parser implementation will need a set of flags, and each new flag will add complexity not only with respect to the parsing code, but also to API and documentation (how do I get the user to select the right mode, or will she always just select all extensions - and why would that be bad...?), and to test coverage (we need a parametrized test suite, right?).
I think that this is a reasonable outcome. Using sf-date before a recipient is prepared to process it can result in the field being dropped. Now, this isn't entirely satisfactory, because an extension within a field will be dropped by a date-unaware SF parser, but that risk can be documented. Extensions to structured fields defined against RFC 8941 probably don't get to use dates then, at least until sf-date-aware parsers are widely enough deployed that the risk is negligible. Documenting this as a caveat is worthwhile; it's only the current set of structured fields that are affected in this way. I don't think that a flag is necessary for sf-date. (I haven't thought much about your retrofit points just yet, I just wanted to put this there as a potential way forward for sf-date.)
Just to clarify: any of these three? Which means that updated parsers will accept sf-date, and thus not be compliant to 8941 anymore. (I'm personally ok with that, but we really should be clear about that)
Yes, that had been my assumption -- a recipient is always going to need to check whether or not the types it recieves are the ones it expected; e.g., if a field is defined to only allow Strings and it receives an Integer, it needs to deal with that. Same for Dates, in this case. I don't think that non-compliance has any significant impact, as discussed above. Happy to clarify it, but I seriously doubt whether it will have any real-world impact to do so. In the case where a field that specifies (or allows through extension) a Date, the appropriate spec needs to refer to the updated RFC so that an updated parser is used. The extension case is a little less obvious, so we're talking through the text to highlight that now.
Regarding retrofit -- I don't think preprocessing is seriously considered by anyone at this point; the question is whether we make it a flag in sf-bis, or 'monkey patch' the spec from afar, just for the purpose of retrofit. So far we seem to be leaning towards the former, but there are risks (as discussed). Note that if we have flags, they're in the parser, but they needn't be exposed to people doing end-user parsing of fields. Or, as discussed elsewhere, we could decide to drop those compatibility fixes. Let's keep discussion of that on issue . I'm not unsympathetic here. I was much more excited about a Date that looked developer-friendly in HTTP/1; now I fear it's not going to be adopted (the HTTPAPI is very lukewarm about it).
Ok, here's an implementation question. In the branch for sf-date, URL currently handles dates as extensions of integers. So somebody expecting an integer would actually see an integer, unless when aware of the new type URL (extending NumberItem). Would you consider that a problematic approach? (I got there just because of code re-use from integers, AFAIR it was not a conscious decision (yet)).
It'd be problematic if the implementation didn't have any way of distinguishing Dates from Integers, because that would be impossible to round-trip -- the serialiser wouldn't know which form to pick.
See linked PR.
Well, if the caller knows about the new types, it will be able to check. The serializer does know about the new types, so round-tripping would happen correctly even if the user of the API wasn't aware of the extension.
Ok, the PR makes things clearer, in that: you can't use sf-date, even inside an extension parameter, unless you update the spec defining the field, and code calling an SF parser will now have to specify which version of SF to use (that's ok with just the three top-level types and one additional flag, but it will get messy if more extensions are being defined)
I would like to avoid the second if possible. That is, you can process with a newer SF version, but you can't produce with a newer SF version.
That means that rejection by a receiver isn't guaranteed, but it offers a path toward upgrade at some point (we could decide, collectively, that it is OK to use sf-date in an extension for an older field definition. We might do that based on adoption rates for the new SF version, and memorialize it with an update to the field, but we wouldn't necessarily need to pick a new field name in order to avoid the compatibility risk (we'd just be managing the probability of it happening).
It would be interesting to see more feedback from people defining APIs for SF support...
How does the PR imply that?
Well, if a spec refers to an SF-shaped field based on RFC 8941, parsing it with an 8941bis parser (allowing sf-date) would be incorrect. RFC 8941 requires draconian error handling, after all. When we defined RFC 8941, we consciously specced draconian error handling + no extension points (until the spec is updated), so that's the consequence. I fear that we are in a very fundamental disagreement about how extending the structured field syntax is supposed to happen given the constraints we put into 8941.
Perhaps it would be best to take this to the list. I don't see anyone else who yet shares your point of view, so it would be good to circulate it with a wider audience.
(with two nits)
A server might allow GET requests to be sent to an upload resource and serve content, in which case a 200 status code is more appropriate for responses to HEAD requests. This PR lifts the requirement that a successful response must be a 200.
The current draft requires the server to respond with a 204 No Content status code for HEAD requests: [...] If the server considers the upload resource to be active, it MUST respond with a 204 (No Content) status code. This restriction is too strict and does not allow the server to respond with a 200 OK. Since the HEAD requests for resumable uploads do not include any specific additional header field, the server cannot tell apart whether a HEAD request is used for resumable uploads or used for starting a download, for example. For example, a server might allow to download the uploaded file through a GET request to the upload URL. HEAD requests to this URL should then return the same status code (e.g. 200) and header fields as the GET request would do. But the draft requires a server to always respond with 204, leading to a conflict. Can we also allow 200 for HEAD responses?
I think this would be a good change to the spec. Maybe use similar language as with PATCH, where we allow the entire 2xx range but have a recommended status code? I don't think this would be an issue for any client. Is this a typo? Should be "... 200 for HEAD..."? >Can we also allow 204 for HEAD responses?
That's correct. Thank you for pointing out
Issue raised at interim on Feb 1, 2023: Does the protocol need to define a failover if QUIC is not available on a specific path. If so, is it the same failover in all cases?
Note that WebTransport does provide a failover to HTTP/2.
We need a answer for Raw QUIC too
We discussed this in chartering and came down on a hard no. It just makes things too complicated. Yep, the webtransport version of it might work fine on TCP and we are not out to break that but it is not a design goal. This is about media over QUIC and QUIC is over UDP. The CDNs may internally do whatever they do but that is a black box.
I agree that this is out of scope, based on my reading of the charter, which says "can be used over raw QUIC or WebTransport." I would like to either close with no action or we can add editorial text that notes that all paths may not support QUIC.
It was decided that a sentence or two about this, including a note that the appropriate fallback may be something entirely different from MoQ (ie: DASH/HLS/etc) depending upon the application and deployment.
Felt that this order was clearer since the requirement then back-referenced the previous flag instead of forward-referencing it. Feel free to ignore if you disagree.
I considered that option. I think that it's easier if the order of the bits is the same as the order the fields appear. I'll reopen and take this if others point this out though.
Confused by that. In the as-written docs the flags are: [R, R, R, R, PADLOW, PADHIGH, R, ENDSTREAM] but the frame layout is: [PADHIGH (8)], [PAD_LOW(8)] so the order of the bits is opposite the field order.
Let's chalk this up as yet another case of blindness on my part.
This PR offers an alternative to . Compared to PR it makes two changes: I removed the newly added text to avoid creating confusion between the responsibilities of a BFF. While it is technically possible to deploy a BFF as part of an API gateway, I believe this suggestion may create confusion for someone trying to grasp the pattern. An API Gateway is closely linked to an API, while a BFF is (in theory) closely linked to a frontend. Reworded the benefits of the Token Mediating Backend to more accurately represent the advantages/disadvantages of the pattern, as correctly suggested by this PR If this PR is merged, can be closed.
and
In section 5.2.3.3 appears out of the blue. It is not clear what a is.
Hi, NAME I'm looking for the reference to 5.2.3.3 in URL and other versions. I don't see where that section exists. Are you referring to a reference where a client is calls the Transparency Service APIs? Or, as there a mention of "client, synonymous with consumer, verifier, etc?
E.g., Is the client the issuer itself? A piece of software that the issuer uses (e.g., a la OAuth2 client)? Does it refer to any role (issuer, verifier, auditor)? IMHO the text should be more specific, e.g., Certificate Transparency RFC explicitly mentions
Thanks, NAME The above text is from Draft 04: I've labeled it for terminology clarification.
In that vein, I would support clarifying it with a "an Issue or Verifier's Transparency Service API client" in the applicable areas of the draft. Would that be more helpful or does it not reduce ambiguity?
Just an update, I plan to send a PR with proposed changes this week.
From the architecture/editors meeting Differentiating: Issuer who signs the statement (The identity of the software component - Wabbit Networks) Client who initiates the registration operation, which encompasses RBAC which is not part of the spec, beyond being authenticated (the build system's identity for access control. The build system has a role to perform operations) - possibly refer to OAuth's definition of client Verifier who evaluates a statement. The verifier cares about the issuer, to know it was signed by a particular issuer. The audit of a supply chain will check the identities involved in the operations.
AJ and I will review this
NAME and I met today to discuss a recap of the authors/editorial meeting (sorry I missed) and how we need to think about 1) a better alternative name and 2) provide a rationale to why we need to have 1, terminology change or not (part of that is the subject of this issue and pending work that should come up in for the latter). For 1, Monty and I are leaning towards agent for now, but we need to brainstorm on adjusted architecture to reflect 2 and "the way" and how it relates to requested edits for the relying party issue in .
We will post in progress work and continue to collaborate and sync, updating the WG via mailing list when it is ready for review and feedback across the WG. More to follow.
Thanks, NAME NAME for the focused discussion.
OK, my work on also led me to be confused and think maybe we have meant agent/client when we said verifier. I made some strawman diagrams to discuss this WG members in URL /cc NAME
OK, it seems we are converging in a direction on around verifier and relying party. The diagram based on author feedback demonstrates that with likely updates to the spec forthcoming if that is approved. It turns out, not surprisingly, we need both verifier and relying party. The latter, if tweak terminology, could more clearly refer to client and resolve this issue as well. Given that, and how it relates to here, I would argue that relying party is the correct substitute for client and this could be closed as a duplicate or modified accordingly to address that. This change would be in line with with the RATS specification iff we distinguish between Verifier Owner/Verifier (person entity/logical system for that entity) and Relying Party Owner/Relying Party (person entity/logical system for that entity) and ironically , various OAuth WG drafts (even if it seems not formally defined), and . It was unclear in previous discussion with authors if this is preferable or required, but it nicely aligns with small tactical changes to the diagram in and relevant spec alignment in terminology and explanations.
Still active. NAME do you have time to complete this item?
I had presented on this topic and we had agreed some key revisions had to take place before we could decide to make adjustments. Are we at that point? Additionally, the alignment with RATS and other specs: is this necessary or not? There are some open questions that are not covered, re URL I guess I will take it to the list.
good enough
URL is frame formats. I've chosen to put blank lines before and after both frames and the stream identifier part of the stream header. That should make this a lot clearer. NAME was right that this was a little hard to process without that. Hopefully this is a tiny bit better.
I think this helps. The only other clarification I can think of is to pull the flags out into a separate illustration, but let's see if this is sufficient first.
Bah I didn't respond at the right place. One day I'll understand github's interface. Or not :-) Both changes look good and possibly sufficient to me. Let's just wait a bit to see if anyone in the WG has any better proposal. Thanks for your quick reaction!
For the flags (and only the flags), what about trying this:
Should I add the octet values of flags? I would only do that for non-unused flags though.
I believe the prose text contains them, so there's at least a defensible reason for leaving them off.
They're indeed present but not trivially spottable. I have a dead-tree copy of 7540 here with them overlined in pink to spot them faster :-/ We could save a tree by noting them there :-). I agree with Martin that we can avoid the unused ones though, because what matters in tests is not to know the unused ones but rather to figure them as the complement of all known ones. I won't roll over the floor crying if that's rejected, but as an implementer I find that it significantly helps during debugging.
As I don't know how to comment in this format and I don't want to start inventing something (else), I think I'm going to take the coward's option.
What are the semantics of a blank line in this format? /me ducks