jiebi/CodeConvo huggingface dataset:
for and hopefully/maybe too URL URL URL
NAME this work and URL were largely undertaken as a result of your questions/feedback
Select parts of a conversation from an encrypted messaging service copied here. Editorial liberties have been taken to extract the most relevant parts of the discussion and protect the identities of the participants. >- the first example is just user claims that are being secured >- the second example is user claims + metadata that is necessary to be added when signing the sd-jwt IMHO it would be worthwhile to expand the example in URL with some additions to URL to also show the content of the thing that needs a name.
Seems related to
I think the understanding of the spec could be further facilitated by adding an example of a SD-JWT VC after the verifier has processed the SD-JWT VC and (basically) has constructed a JWT representation for further processing in the application.
The new PID example in draft -02/-03 shows the JSON data for "further processing" after validation: URL Does that seem sufficient? Or perhaps a similar addition to the example used in the main body of the draft ()? Or something different/more?
I personally don't understand why this applies to the verifier: "has constructed a JWT representation for further processing in the application". However, NAME has this issue been addressed by the examples NAME provided? Then we can close it.
This required a little careful rewriting of text that only recently rewrote. Hopefully this retains the improvements of that rewrite.
Right now, we have a lot of 1.1-specific language. In theory, it should be possible to remove 1.1 references and use core HTTP semantics to describe the protocol elements. That would be much cleaner, but it could be tricky.
Nice. I think the retains the original meaning of the text well enough, and is as clear as it can be without ever needing to normatively invoke HTTP/1.1. Needle well threaded.
This one is almost trivial. Except: previously, the ABNF sort-of ruled out parameters in the ABNF (at least that was the intent) this is now done in prose - we need to say though what to do when parameters are present - is "SHOULD treat as error" correct?
Should not enumerate the actual coding names. Make the ABNF generic and point out that the predefined encodings do not have parameters.
See URL
Instead of saying in each encoding that the presence of an undefined parameter should be treated as an error, it would be better to say that once in the main section for any encoding that does not define its own parameters. But +1 anyway.
The changes here are relatively small, but please ensure I didn't miss anything. Because not all HTTP/3 streams are framed, I restated "on any other stream" to specify "request and push streams," language which I believe remains appropriate for HTTP/2. In order to keep the frames as identical as possible, I haven't restructured the H3 version with varints, but that's certainly an option. It would require defining the frame payloads separately, but that's possible.
LGTM. Nice and simple. Suggestions are all things you can ignore.
Addresses issue NAME
From WGLC Current text: "supports a new cross-device authentication protocol, called "hybrid"" Proposed text: "supports a new cross-device transport protocol, called "hybrid transports" Propose adding the following at the end of the first paragraph: "CTAP 2.2 hybrid transports is implemented by the client and authenticator platforms." Current text: "The main device and authenticator" Proposed text: "The main device (CTAP client) and authenticator" Current text: "The user will receive a push notification on the authenticator." Proposed text: "The user will typically receive a push notification on the device serving as the FIDO authenticator." Current text: "Both the Consumption Device and the authenticator require BLE support." Proposed text: "Both the Consumption Device and the authenticator require BLE support and also need access to the internet" s/hybrid transport/hybrid transports Current text: "The mobile phone must support CTAP 2.2+ to be used as a cross-device authenticator." Proposed text: "The device serving as the FIDO authenticator must support CTAP 2.2+ to be used as a cross-device authenticator." see: URL NAME
is saying something about using From for authentication, but I don't understand it: I think that this could be saying one of two things, maybe the latter: From contains only an unsupported claim about the identity of the generator of the message, so it can't be used for authentication. Including a From value that also contains a secret, such as a password, that could be used to authorize a request is unwise because recipients of the message won't necessarily treat the value as confidential and so the secret might leak. That latter is a bit strange, because an authorization could be bound to the specific request in various ways that might limit these risks. I can't tell because the logical chain between "this is who made the request" and use of the value for authorization isn't very well developed. It might be better to say nothing here instead.
My .02 - I think the intent was more the first -- just a warning that this is not an authentication mechanism to ward off the uninformed and optimistic. Given that this isn't widely used anyway, I don't think the text causes harm; I propose we just leave it as is.
Please, drop everything from "since" onward in that case. The reasoning makes no sense to me and the unsupported recommendation is clear enough.
+1
... RFC7230 + RFC7231? This would be noting an editorial change, but okay.
People who are reading other specifications that use the old terminology may have questions.
Also worth putting 'body' in context, since many (e.g., the Fetch API) still use that term.
I could do that directly in Fetch as part of URL I'll have to do some reading though as I've lost the plot a bit.
With or without Roy's addition.
This is an update of :
There have been a number of discussions about scenarios where we may want the client to fall back to 1.1 (a server forcing gzip, APIs incompatible with HPACK, etc.). HTTP/1.1 defines status code 505 as indicating that the server "refuses to support the major version of HTTP that was used in the request message [and] is unable or unwilling to complete the request using the same major version as the client [...] other than with this error message." However, that doesn't define a programmatic way to tell the user agent what version to retry with, simply a representation to be shown to the user. We should define a way to inform the client what HTTP version to retry with (presumably 1.1).
Discussed in NYC; task force-ish to come up with a proposal either using 505 or a new status code + header to point to the version(s) to bounce to.
Mark to write draft. use 505 extra header what version to down/upgrade to what the scope of applicability is (server vs resource) cache-control applies
Discussed in person, but capturing here: Scope could also be a path prefix, not just a single resource.
Marking this one as non-blocking. We need to discuss adoption of a mechanism for this; and that's not going to happen in the sorts of time frames we're talking about.
Can this be closed -- i.e., do we need to actually reference the new draft in HTTP/2?
Yep.
Reopening (preliminary) based upon feedback from Mike.
The current rules state that you need to include text in abstract and introduction. This will result in redundant entries for the specs with other changes that add 7540 references, but we can sort that out later.
Picking my battles more judiciously (as much as I'd like to fight this one, it's a low reward, high risk situation).
informatively, as they are obsoleted by this spec
Rules are boring. Be a rebel without a pause. Omit that text.
Questions for the encoding: base64 vs url-safe base64 bitwise encoding right now is least significant bit to most significant bit The part describing the bit-encoding still needs be rewritten In general: I searched a bit for better ways to encode/compress but in terms of simplicity and support for different programming languages, it seems some form of byte array and gZIP seem to be a pretty decent pick.
I've made a first implementation in Kotlin today. To me, it feels very natural to count Byte indexes up from 0 to size(whether this is left to right or right to left feels a little philosophical) and Bit indexes from right to left.
Imho we need another iteration on the description of the bit encoding, most likely with some form of ASCII art. I would prefer to do that in another PR- what do you think?
Sec 2 leans heavy on the dated example of Highspeed TCP and drives pretty much everything to Experimental "until such time that the community better understands the solution space." It says that experimental RFCs can either be those judged to be safe on the internet, or those intended for testbeds. At this point, we probably understand enough to allow proposals to go for Proposed Standard. The safe/testbed distinction also doesn't make sense -- we might want to standardize CCs for controlled environments, like DCTCP. This needs a complete rewrite. It wouldn't hurt for that rewrite to also note that the IRTF is another venue, non-normatively.
I think a rewrite would help, but I'm think that could be too radical - we still do have proposals that ought ton be EXP either until deployment experience; or until we can agree they are "safe" for more general use. That doesn't seem to be a problem to me, but we ought to allow PS also. I agree we ought to mention IRTF.
Fixes httpwg/http-extensions.
Please mark this PR as fixing the corresponding issue
From NAME on the :
The conservative thing to do here would be to insist that the key be unique to the protocol. We have domain separation in our outputs, so we don't need to worry about unprompted auth messages being used in cross-protocol attacks, but a different protocol (that doesn't use context strings) could possibly be induced to generate unprompted auth messages. We also need to worry about key compromise. Imagine a protocol that leaks the private / secret key, that shares a key with unprompted auth. This doesn't even need to be a bug, it could be a commit-before-reveal style protocol. (Obviously that's a pathological example, but it shows we can't assume composability with all protocols) If we want to do a formal analysis (which I do) I think we need to be conservative here.
SGTM
Shared between and
Merging because I don't think this is controversial, and we have two PRs doing the same thing.
This sounds a bit like an extension that just gets forwarded when not understood by a relay? How does APP interact with caches, for example? Can a single QUIC stream have SEGMENT and APP data interleaved? Might be too vague to leave in
The intention was to cache/forward it the same way as media. It's just meant for arbitrary metadata and as a replacement for the current approach of shoving metadata into the media bitstream. For example, in h.264 land it's common to put arbitrary content (non-standardized) in SEI messages. Even if we don't cache/forward the stream, it would still be nice to let the application use unidirectional streams. This basically says prefix the stream with a 2 if it's used by the application instead of Warp. This wouldn't work with relays which is why I had the idea of reusing HEADERS to tell the relay which application streams should be forwarded/cached and how.
Oh and it's missing because there's no encoding yet, but I was envisioning that SEGMENT and APP frames do not specify a length. They would consume the remainder of the stream so there's no way to use them in conjunction.
Is there an MP4 box that we can just use as a part of the layer? That would provide some form of uniformity.
That was my thought too, although it means every container will need some way of specifying application data. MP4 atoms require a length up-front so they would be limited to messages instead of unbounded streams.
the RTCP APP message never turned out to be as useful in RTP as people thought it would be ... that said, fan of being able to send whatever data in the payload. If it happens to be a protobuf app message instead of media, seem like MOQ shoudl not care, it should just deliver the bytes with not much care if they are audio, vidie, haptics, or an app custom media
We need to define the difference of APP message and Media data in terms of what is inside and how it is interacted with caching and dropping. Otherwise there is a risk that the APP message becomes the container for “whatever does not fit in the current RFC“ which renders the standard useless.
Note that if we go in this directions, there are some editorial improvements in that we should pull in separately.
I find Roy's proposal more precise. The overall text does slightly help me find how to figure a scheme in H1.
From NAME - Let's discuss whether the currently specified procedures for reconstructing the target URI from a request-target in absolute-form provide adequate security properties, at the origin server. I'm specifically concerned about taking the scheme directly from the request target, i.e., making the distinction between the "http" and "https" schemes. The simple procedure of "take the scheme from the request-target" would seem to allow for the client to cause the server to engage processing for the "https" origin without receiving the protection that https is supposed to provide. (The converse case does not immediately seem to present much risk but is probably worth preventing as well on general principles of retaining consistency.) I don't remember seeing any text that would require the server to validate the scheme from the request-target against the actual properties of the transport (or the configured fixed URI scheme as might be provisioned with a trusted outbound gateway, etc.) While we do reference §7.4 of [Semantics] with a note that reconstructing the target URI is only part of the process of identifying a target resource, that part of [Semantics] does not mention scheme validation as part of rejecting misdirected requests. Does the origin server need to validate the scheme from an absolute-form request-target? What is the scope of consequences if it fails to do so?
I said: In 3.3 of 1.1 I was skimming by the initial text: The target URI is the request-target when the request-target is in absolute-form. ... whereas you obviously picked up on it. I agree that there's an issue here. The decisions about absolute-form requests were made way back when. My reading of the archive (circa September and October 1995 -- I'm sure those that were there will correct me) is that Host headers were added to address the multiple-hosts-on-an-IP problem in a way that was backwards-compatible with HTTP/1.0, but because some folks wanted to enable the use of URNs, proxies were required to support and use the absolute form, so that URNs could be (theoretically) resolvable through them.
That didn't happen, but it is possible to use e.g., FTP through a HTTP proxy as a result (last I looked). I think the solution here is to restrict the statement above so that it only applies to proxies, and to add a requirement for origin servers (including gateways) to specifically check absolute-form URIs for alignment regarding the scheme.
It seems to me that the ability to do cross-protocol requests is a deliberate feature of HTTP, and not one we should interfere with now, even if it's rarely used. In fact, RFC 8164 explicitly relies on the ability to request "http" resources over an "https" connection. I agree that servers should not respond to requests that assume a secure channel over an insecure one. While Sections 4.2.2 and 4.3.3 seem to put most of the burden on the client not to make such requests, the server should probably consider such a request misdirected even if it is authoritative. Perhaps the least disruptive solution would be text in 7.4 adding https:// URIs received over insecure connections as another instance of a potentially misdirected request?
Before I get into the text, I need to clarify that this question is misplaced. The procedure for reconstructing the target URI is about reconstructing what the client sent. It is not about security (yet). It has nothing to do with ensuring the connection is secure. It is about understanding the request as received. AFTER the request is understood, the server needs to determine whether it can answer the request in that context. How it determines that is an internal configuration issue, not a protocol standard (because HTTP requests can arrive via any underlying transport), but there are things we can add to make the process clearer without assuming that all HTTP requests are made by general-purpose browsers.
Intro para 3 has a chunk of text about fields not defined in this doc This could be condensed to say that the header fields in this document provide a standardized replacement for custom or proprietary fields that were known to be used prior to this document.
It is perhaps a bit long winded and admittedly not award winning literature. But I think it's useful context for the reader and prefer to keep it.
Right but in 20 years if the RFC says "a common practice today is using non-standard fields" it could read odd. Its clearer if this spec focuses on what it provides not what people came up with as custom solutions beforehand.
Thanks, looks good!
Fixed some of the wording and parallelism in the intro to keep the same ordering of X.509 certificates followed by Workload identity tokens. Generalized some of the phrasing. Removed concepts that aren't well defined in the document, such as "bottom turtle". I'm not opposed to adding these, I just don't think they make sense without an explanation of the analogy either inline or by-reference; so I tended towards keeping the document self-contained. Provided initial content for the Delegation and Impersonation, and Asynchronous and Batch Requests sections.
and This is an editorial set of changes to the intro text. The first paragraph in the "motivation for replacement" section is actually broadly applicable motivation for any priority scheme. So we can move that up and highlight that H2 and H3 are multiplexed protocols that have the need of something. This helps us to clarify that mention of HTML document loading is only an example. We also give greater exposition about the actors involved in signalling, highlighting early that servers treat signals as a suggestion and they might follow some of the guidance provided later in the document.
To avoid bitrot, I'm merging.
The introductory material tries to be general, but routinely fails to be, falling back on talking about rendering web pages. If this is the best example, it could be more direct about that. Or, if this is general, it could try to be more careful about limiting its use of "document" and so forth to examples. For example, this lacks sufficient context: And this launches into talking about HTML without saying HTML:
good catch. I do think this is the best example and therefore will take your first suggestion. I'll follow up with a PR.
I have an unpushed branch for this that conflicts with other things, but I believe solves the matter.
says in part: In the first sentence, the endpoint is the one that is applying priority based on signals (or lack thereof) from its peer. In the second, the endpoint is the one providing signals when the peer is the one that acts upon it. This is confusing.
I see what you mean but I don't have a quick fix to hand. Would "one side operates in ignorance of the needs of the other" work?
Possibly. In the first you might say a sender might operate in ignorance of the needs of a receiver; the second might then say that a receive can communicate its view of priority to inform sender behaviour. Not that prioritization is exclusively about prioritization of sending, of course.
the terms in the second sentence were written intentionally fuzzy to accommodate intermediaries in the general statement. IIRC Robin elsewhere suggested just saying client and server but that risks over simplifying or misleading.
I think it might be a good idea to using terms "sender", "receiver", as suggested by NAME
To me, that risks conflating signal sender vs data sender. Someone want to propose a PR?
I propose defining latencies less than 50 ms as near real-time latencies. These latencies can be used by musicians to play together in sync. And I guess the human ear or eye would mostly not notice any delay below 50 ms. Might be worth doing a bit of research around the topic to refine the ranges though. For instance, in this paper (URL) they conclude: In another source (URL) the following is defined: 150ms target performance 13ms > lower detectable limit
< 200 ms - comfortable latencies for conversation.
Apologies for not looking at this earlier, I've had to prioritise other work recently. Given that our draft and these values are an extension of , could you please also include the references and elaboration like you have in the PR as I think it will help quell any further bikeshedding on the subject.
The MOPS document now mentions near-realtime latencies (see URL), but does not define the exact values. Likely this PR still makes sense, but now as an attempt to define those type of latencies.
Note that if we say it has serious security hazards and we don't mention that in Security Considerations, someone might complain.
PTAL
The text says I'd want to add: "Implementations must be careful about accurately parsing large values or rejecting the messages, as failure to accurately represent the advertised value due to overflows or loss of precision may have serious security consequences." I think it is important to remind, because implementations seem to have progressively shifted towards 64 bit repressentations since 7230, 32-bit ones are still much present, and the risk of desynchronization by advertising more than 4GB is high. By the way, some languages do no provide more than 52 bits of accuracy because they use floats to represent any number... The risk remains low (1 injected byte every 4 PB) but its worth asking to be careful.
Tweaked proposal:
WFM, but I'm still a bit concerned by the fact that we don't say what the receiver should do here, and it doesn't decide to receive too large a chunk :-/ Should we explicitly mention "a recipient must reject the message as invalid if it cannot accurately represent a received chunk size ?"
I think if we say something about that, we should align it with the language for Content-Length:
OK, but then conversion overflows is not the only issue (storing in a float or double is a huge problem, and nowadays sometimes developers don't know, they store it into a "number"). Probably that we should use the same wording for both and slightly adjust the end to say . We can hardly do more but this needs to be said. Using a float with 24-bit mantissa to represent a content-length is already a problem, but in a chunk, 48 MB are enough to miss 3 bytes and desynchronize on a final chunk!