jiebi/CodeConvo huggingface dataset:
As suggested in the issue. Looking at it, more text could be moved up, or the entire section could be moved up (e.g., as a subsection of where this text went), but this seemed reasonable.
-1; this needs to be where CRLF is used, not a different section.
Like that? Wasn't sure what you meant by "moving HTTP version up..."
I meant literally move the section titled "HTTP Version" up above the section titled "Message" and then move "Parsing" to a subsection of "Message". I'll see if I can tweak it.
Would this
... is awfully far from the definition of the message format; IME people read the start of section 3 in isolation and don't see the text below. Maybe move 3.5 up?
Agreed. I have fixed this in 33c709c76bfeafbc2b44b682f1e88f99877e3aca
How about moving the three paras starting with "Although the line terminator..." to 2.1, and moving the out of the definition of and into , to be consistent with ? Then all of the text about is in one place.
See also .
My idea of moving version up to top didn't work out,but moving it down to the third subsection solves both problems, I think.
[x] 3. It's probably worth mentioning that they're comma-separated in prose. [ ] 3. I'm uncomfortable with relying on examples to specify how this spec works normatively; by their nature, examples are not 'comprehensive.' While this spec shouldn't re-specify HTTP, the header's definition should be clear enough that a reader doesn't have to dig around in the examples and other specs to understand what's going on. [x] 3. Disagreeing plurals in 'an incremental digest-algorithms'. [x] 4. Is Want-Digest a request field, a response field, or both? In either or both cases, what's the scope of the assertion? [x] * 4. A reference to SEMANTICS 12.4.2 is necessary.
This is how it works in practice. RFC 6125 is due for an update, I guess. iPAddress subjectAltName has been supported for years and years, but it never managed to capture it properly. This is definitely a big change in that it now outlaws CN-ID. And the definition of IP-ID here is probably overreach, but I don't see how we can avoid that. I don't want to update RFC 6125 here (as much as it needs updating), so making the definition standalone seemed like the right way to handle it.
Discovered via a question NAME asked; it appears that 8aa1781d4fa7d25ab946f6cb1dd1b337435e0a17 made the change to require looking for URI-IDs in the certificate and I don't see any follow-up discussion on that in . However, I've never seen a certificate that offers a URI-ID for an HTTP endpoint. Shouldn't this be a DNS-ID to match current usage? Or perhaps either, with URI-ID preferred, if we believe that's the future?
Er, right, my mistake -- I was trying to describe it as verifying a URI as input, not as looking only at the certificate field for URI-ID. It should either be left unsaid, because it is defined by that RFC, or possibly specify DNS-ID with maybe URI-ID as a backup?
I am not entirely sure that there is need to mention URI-ID (I, for one, don't know of usage of it with HTTP; I barely know of usage of it at all). My understanding is that current practice prefers DNS-ID with a grudging tolerance for CN-ID as fallback (though there are efforts underway to fully deprecate use of CN-ID). Note also that when referencing the RFC 6125 procedures, the protocol document is expected not only to specify what name and type are to be used as input to verification, but also whether wildcard certificate are allowed. It is sometimes also useful to give instruction about what procedures are to be used for revocation checking, though 6125 does leave that explicitly out of its own scope. I am also trying to promote the definition and use of "IPADDR-ID" for the iPAddress SAN, but that's somewhat unrelated.
Do we want to state a position on adoption of URI-ID?
If not, then I think we say DNS-ID and MAY consider CN-ID, plus the wildcard language. I'm not aware of anything to reference for IPADDR-ID, and this doesn't seem like the place to define it.
Please don't use CN for anything. Nor rfc822Address nor domainComponent.
I'll be happy to accept any change here that folks generally agree to, preferably in the form of a PR. I already tried just writing it myself and that's what we have now, but it's wrong because I haven't implemented this myself.
Sorry for the late comment; apparently my github notifications aren't set to send me email when a new PR references an issue I'm watching.I'll trust NAME :-)
Document what needs to happen for compression. The Client-Cert field will be largely constant for the same client, so it might be a good candidate for compression. However, with requests through the TTRP potentially coming from multiple clients, the connection to the origin server might get different values over time. Document what needs to happen here: either very large dynamic tables with certificates in them, or no compression for the field and larger requests. You also need to consider the effect on the protocol of very large header blocks. Both HTTP/2 and HTTP/3 have soft limits on the size of header blocks that this might exceed. Servers need to be provisioned to allow for large certificates. cc NAME
Thanks for the feedback Martin. I've read through RFC7541 and some of RFC7540 and I'm honestly still unsure what this draft can or should say about compression. As I understand it, the size of the dynamic table is established between the peers (dynamic table size update and SETTINGSHEADERTABLE_SIZE) of the connection. And the TTRP would decide whether or not to add client certs to the table. Undoubtedly there's a trade off between large dynamic table with certs and no compression for the field with larger requests. But I don't know what's "better" and imagine it will depend on the specifics of the deployment. Although I guess continually adding and evicting certs on a small table would be the worst of both. Are you looking to have that trade off described in something like an implementation/deployment considerations? Or something more or different? And if so, are there some specifics you can suggest or propose? WRT limits and large headers, URL has "A server that receives a request with a Client-Cert header value that it considers to be too large can respond with an HTTP 431 status code per Section 5 of [RFC6585]." Is that wrong? Or insufficient? Or is this another implementation/deployment considerations thing where the draft should mention to readers that they might need to adjust some settings around maxim header sizes? Or something else?
Roughly, I think you could say something like
I think the issue is somewhat different. H2/H3 allow implementations to advertise a limit on the sum of the size of all headers received.
The context here is that the document defines independent elements a) the means to deprecate RFC 7540 stream priority using a setting b) the extensible priorities scheme. This text removes conflating those elements and making it appear that Extensible priorities is mandatory. Where someone chooses to use Extensible priorities (good choice!) there is some specific guidance about how to process settings and inform signal setting.
Above, you indicate any scheme can be used, with this being just one option. This does make guidance about PRIOUPDATE frames/header field more difficult later, so maybe some other textual adjustment is needed earlier: e.g., for the remainder of this text ,we assume the use of the scheme defined in this document as the alternate Or, move the following text from below up and adjust a bit send this scheme's priority signal Originally posted by NAME in URL
The text isn't amazingly clear if endpoints have to use Extensible priority when they explicitly disable H2 priority. I suggest we state they do. If anyone really wants to invent a new scheme, they will need to deal with negotiation.
Yeah I see two somewhat contradicting statements: Endpoints are expected to use an alternative, such as the scheme defined in this specification. Until the client receives the SETTINGS frame from the server, the client SHOULD send both the HTTP/2 priority signals and the signals of this prioritization scheme (see Section 5 and Section 7.1). I would argue that the former is precise, and that the latter is a bit misleading in recommending endpoints send Extensible Priorities rather than any alternative to H2 priorities. The rationale is as follows. In principle, negotiation is a hop-by-hop mechanism and therefore cannot be used for negotiating the use of an end-to-end signal, which includes the header-field variant of Extensible Priorities. To paraphrase, in a world where end-to-end signals are used for prioritization, multiple signals are expected to co-exist. IMO, SETTINGSDEPRECATERFC7540_PRIORITIES is no more than an optimization, that allows clients to conserve bandwidth (by omitting the PRIORITY frames), servers to reduce complexity (by ignoring PRIORITY frames being received). These benefits are stated correctly in the section.
Thanks Kazuho. I tend to agree. The thing I also wanted to avoid is endpoints disabling RFC 7550 stream priority and then not providing any suitable replacement by accident.
I think there is agreement that not doing scheduling is pretty bad. But we also highlight that other inputs, beyond this scheme and beyond anything that would be standardised are fine to use too. I'm getting an idea of how we could change the text to address the points made on this issue.
Reading again the current text send this scheme's priority signal. Handling of omitted signals is described in {{parameters}}. This is effectively a differently worded restatement of the guidance for implementers of Extensible Priorities receiving an HTTP request that does not carry these priority parameters, a server SHOULD act as if their default values were specified. That is, imagine both endpoints send SETTINGSDEPRECATERFC7540PRIORITIES and a client wants the default prioritization for a request (u=3,i). It can omit the Priority header field and have some expectation that a server implementing Extensible priorities will interpret that as a signal to apply the default. The simple action here is to make SETTINGSDEPRECATERFC7540PRIORITIES independent from any advice to use a specific alternative.
LGTM. I like how you've split the section.
Introduced the phrase in the end of the Section 8.1 on Verifying the SD-JWT for
Fair question. But I did add this one mention of the term in the location that NAME requested it in URL And it was already used in the text at the end of . And the just merged URL sprinkled in a few casual uses of it too. So I think it's sufficient enough. Also we have a fair number of kinda similar terms/phrases that are used in the doc but not formally introduced in the the terminology section. Which I think is fine. But putting this one there might be somewhat inconsistent and beg the question about other similar terms/phrases being there too.
We had the discussion in SD-JWT VC how to refer to the dehydrated (or maybe hydrated) result (Issuer-signed JWT payload) of the . It would help if we could give it a name to allow us to be more precise in other specs that are building on top of SD-JWT. The discussion occurred when adding the Schema for SD-JWT VCs that uses that result of the SD-JWT processing section to match the JSON schema against: URL We also have another issue that asks for an example of the result as well which would benefit from giving it a defined name: URL
Perhaps you can also confirm that this result in fact contains things like , , etc., and would only remove , , .
I was typing the following over in when it closed out from under me in favor of this issue.
why is not good enough? (in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)
I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough. I'd suggest to add one sentence to URL, e.g., "7. Let xzy be the processed result of the asdf algorithm ..." ... and make xzy a defined term, so it can be referenced. I don't think we can use from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.
Btw.
resolves URL which is really based on URL
some of URL likely applies here too
Notes on section 6: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere in this section
notes on appendix: URL say more about the input JWT Claims Set URL show the processed SD-JWT payload somewhere after URL say more about the input JWT Claims Set URL use the processed SD-JWT payload name URL say more about the input JWT Claims Set URL names URL input URL name
The first few entries are valid, revoked, suspended. There may be future well defined values that issuers and verifiers want global interoperability around. There may also be a need for private use of this space. This document should describe the "reserved for private use range", and leave room for enough globally interoperable and registered status values
We had similar ideas and totally agree
The section 7 explains how to setup the registry (URL) but we are missing a corresponding section in the IANA appendix
Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.
For .
[x] Section 5.1.1., 3rd para: When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed". Should one say "that might have been but were not initiated by that peers" to make clear that this applies only to un-used streams? [x] Section 5.3.1 Maybe update the section heading to read "Background on Priority in HTTP/2 as per RFC7540"? [x] Section 6.5: The document implies that SETTINGS frames are ACKed in the order they are sent. Should one make this explicit? [x] Last para of 6.5, top of page 37: "If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5.4.1) of type SETTINGSTIMEOUT." Should one provide some intuition on what "reasonable" could mean? An example? It seems, an HTTP/2 sender of a SETTINGS frame could know when this was passed to the TCP layer and may have some insights on application layer RTTs. [x] Section 6.9.1: Concerning flow control, should one say something about avoiding silly windows? [x] Section 8.1.1, p52 1st para: Probably just me, but I am mildly confused by the statement about messages having a non-zero content-length field but still no data in the data frames. The reference section 6.4 of the HTTP semantics draft didn't resolve that. [x] Section 8.2.1, p53: parse error? "When a request message violates one of these requirements, an implementation SHOULD generate a Section 15.5.1 of 400 (Bad Request) status code [HTTP], [...]" [x] Section 8.4.2, 4th para: "A client can use the SETTINGSMAXCONCURRENTSTREAMS setting to limit the number of responses that can be concurrently pushed by a server. Advertising a SETTINGSMAXCONCURRENTSTREAMS value of zero disables server push by preventing the server from creating the necessary streams.
This does not prohibit a server from sending PUSHPROMISE frames; clients need to reset any promised streams that are not wanted. Confused: it disables server push, but the server can send PUSHPROMISE frames and then the client is supposed to reset a stream it wasn't willing to accept or capable of accepting? Which stream number would the server legitimately put into the PUSHPROMISE? [ ] There are a few cases where I am wondering if normative language should be used. Examples include [ ] -- 5.4.2, 2nd para, "sends an RST_STREAM frame" [x] -- 6.8, p43, 1st para, "the server can send another GOAWAY" [ ] -- 6.8, p43, 2nd para, "the sender can discard frames" [ ] -- 9.1, 3rd para, "clients can create" [ ] There may be further occurrences of "can" or similar.
FYI NAME I've updated this post to have a list of checkboxes for "addressed".
I've reviewed the changes here and I'm happy with 9/14. The others I don't think need to be addressed.
Fixes unused references. Removed reference to FIPS180-4 and opened issue Removed unneeded references Uses required references.
Should we update the FIPS180 reference to the latest one? NIST updated the document defining SHA-* algoritms. The latest reference is digest-headers references preserve the ones cited in RFC3230 and subsequent.
cross-posting from elsewhere, I said I think we probably want to use FIPS180-4 for SHA-256 and SHA-512, and FIPS180-1 for SHA-1.
There is also .
[x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \ [x] Warning: no \ in \ targets \
Fixed in
Delayed LGTM.
Section 5.1 of the draft says: For the second case above, I think it would be useful to have an explicit signal from the publisher to signal the end of the track. For the third case, the text seems to hint (via a section reference) that if the subscription abruptly terminates with an error, the publisher can send SUBSCRIBE ERROR, but that section says: The draft should clarify if this is allowed following a SUBSCRIBE OK. Also +1 to adding UNSUBSCRIBE ().
+1 we should allow sending a SUBSCRIBE ERROR after a SUBSCRIBE OK.
I was assuming that the catalog change would be the way a track end was indicated then the client would unsubscribe.
As an individual: This seems like a bit of a subtle signal and something more explicit using the Track ID would be preferable for me.
I tend to incline towards Catalog indicating the status the more i think of it. Catalog is source of truth for tracks. Having a catalog update that indicates the following Full Track Name lastobjectid field Also if the catalog is ending, since the producer is going away, then include another optional field finished or something These would be sufficient and a clear way to identify the status end to end.
I think putting the FIN group/sequence in the catalog is clean. It does prohibit relays from cleanly terminating a broadcast early or rewriting group/object sequences, but I think that's fine? However, the wrinkle is that a sender MAY choose to not transmit a group/object. While I don't think this is explicitly stated in the draft, it's a requirement given that relays can only cache data for a finite amount of time. The viewer could get stuck waiting for the FIN group/sequence as signaled in the catalog, even though it is not forthcoming as the relay did not receive the object or already evicted it from the cache.
As an individual: Having an explicit signal outside the catalog will make it easier for relays to clean up track related state. If a publisher is done with a track, they can update the catalog, but it will need to propagate to all subscribers, who in turn need to issue an unsubscribe. Only when all of them unsubscribe (which we still need) can a relay discard the entry in the forwarding table. If the publisher also sends an explicit signal closing off the track, the relay can immediately clean up the state.
We need few things.
Cease the announcement This is an explicit signal from the publisher that it is no longer interested in sending media for the announced tracks. This is sent to the relay to trigger subscription cancellation downstream and clean up local relay state. Terminate the Subscription On subscribe end signal, each receiving entity will forward downstream and clean up local state. If it is the consumer, it stop media pipeline and so on. Unsubscribe For subscribers to explicitly indicate that they are no longer interested in a given track , they will send I am happy to write up a small PR as proposal if we think the general direction is fine.
What is the difference between Cancel the subscription and Unsubscribe?
Unsubscribe is an explicit action from the subscriber and Cancel is the signal from the publisher. May be we should call it ` instead ? I see cancel can be misleading
Got it. Terminate is better than Cancel.
We already have for the publisher to immediately terminate a subscription with a code/reason, so we could reuse that. However, the problem is when the termination occurs. The end of a broadcast would look like: There's a race, as the can arrive before the last objects due to retransmits or congestion control, severing the subscription early. Ideally we wait for all outstanding objects to get delivered and then terminate the subscription. In QUIC terminology, we need a in addition to our existing . The difficult part is determining which objects are still outstanding.
Do we want to distinguish a normal end of subscription (due to EOF), and an unexpected end (due to, e.g., a downstream server crashing)? We do that normally in QUIC (fin vs reset), so it might make sense to do that here.
Image the case where we have A sending to R sending to B. B subscribes to R. A sends ANNOUNCE to R. R subscribes to A. At this point media is flowing from A to R to B. A temporary looses WIFI connectivity and reconnects over 5G with new IP. A sends an ANNOUNCE to R, R subscribes to the new A and perhaps tries to send an error to original ANNOUNCE and end subscribe but A will not get that as that QUIC connection is gone.
Once again data is flowing from A to R to B. I think it would be bad if the new ANNOUNCE, or an error on the QUIC connection from A to R caused a termination or error of the subscribe between B and R. I'm think it is better for B to unsubscribe if it is not receiving the media it wold expect.
Having explicit messages reflecting the actions would be my inclination as well. I thought it might be beneficial to explain the role of the above proposed messages with few flow diagrams Here is the happy path flow (it ignores Subscribe_OK and response flows to keep the flow focussed)
Summary thoughts: Want to support disconnection without propagation to all subscribers (ie: If there were two publishers) Need a way to cleanly unsubscribe from a track (UNSUBSCRIBE) - Like STOPSENDING? Need a way to indicate that a relay is no longer the place to subscribe to for a track (ie: UNANNOUNCE) But UNANNOUNCE does not indicate an unsubscription. Need a way to indicate the track is FIN'd and ending, could use the catalog or put in the protocol (or both) Likely want a way to drain a relay, such as an HTTP GOAWAY style functionality. (Could be SUBSCRIBETERMINATE) Timeouts do need to be handled, even if they're not the ideal/clean case. Want to know whether the relay wants to stop publishing or the origin did, so a client can decide whether to re-sub. NOTE: Objects can be dropped, hard to know if they'll ever arrive. Cullen will summarize a proposal. Note that the relay doesn't really need to know about tracks or what its subscribing to. An open issue is how to do FIN, whether it as part of Objects, only the catalog, a separate message, etc.
Rough notes on proposal in the call: The catalog updates and says what the last message in a track is. Catalogs are a way that endpoints can say there will never be more on a track. The annouce has an equivalent un-Annouce message. It changes routing of future subscribes but does not change state of existing subscribes. The entity that send an subscribe and send an un-subscribe The entity that receives a subscribe can send a go-away which will let the entity that sent the subscribe go do something new ( like subscribe to something else ).