jiebi/CodeConvo huggingface dataset:
: >A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules: I'm hearing that this 60-second window is problematic for videos, where clients often request a partial video segment within a minute of it being published (thanks to e.g., CMAF). Since those requests use , they require a strong validator. Should we revisit this, given that it is an arbitrarily chosen value by our own admission? I agree that some caution is necessary here, but a one-size-fits-all approach doesn't seem viable.
Discussed on call. Sense is to make this much more based upon the judgement of the implementation, rather than just an arbitrary number.
Suggestion:
NAME NAME - this creates a nested unordered list which comes out really strangely in HTML, please check. Maybe it would be better to have the two statements (that are nested) in a single list entry.
Address some build warnings and fix typos.
and
Thank you for the fix. Merged.
Changes in structured headers means that boolean parameter values are reduced to their parameter name: -- URL
Q: should this be labeled ?
No, this issue addresses the minor editorial problem that needs fixing in the priorities spec e.g. URL just needs some tweaks to be compliant with structured headers.
The lowercase headings in the document imply that they represent field or parameter names, but these are concepts. For instance "incremental" doesn't appear on the wire, "i" does.
This modifies parsing to consider empty or not-present header fields as empty containers; serialisation omits them from output.
The SH syntax does not directly allow empty field values, such as defined for Accept, although this might be allowed by field definitions like MyField = [ sh-list ] Likewise, the list types do not allow for empty lists. sh-list = list-member *( OWS "," OWS list-member ) list-member = sh-item I think this is a very odd choice for a generic syntax because the empty set is often given semantic meaning in generic communication. It's hard to do math without zero. If this is intended, the rationale should be explained in the spec, and there should be some discussion with examples about defining fields as an optional value.
FWIW, even if empty lists may be problematic top-level, the situation is different when they are nested...
ietf104 - interest in the room in supporting empty (perhaps null?) syntax
I agree this is something important. It may be used to mean "I know I must pass the info but I don't know the info", which is different from "I don't care about the protocol" or passing a dummy value just to fill the hole.
In the original base material of header definitions, empty values were generally just not sent at all. Having a specific Null value may or not make sense, not sure.
I personally like the distinction between "known to be empty" and "not presented either because I don't know or because it's empty". Some semantics might explicitly require the presence of some fields which we would enforce by the protocol. This doesn't mean they can't be empty, they must be present, for example, to make sure they weren't dropped in the middle. For example, "Connection: foo" gets rid of the field, not just the value. Just my two cents, Willy
Do we have any RFC'ed headers where there is a difference between a non-present and an empty header ?
There's an accept-something if I remember well. Also I've been using "Host:" in many occasions with HTTP/1.1 requests when I didn't know the host name and this tends to work where no Host field fails ;-) Willy
I'm not against a '?N' null token (along the lines of true/false), but I have a hard time thinking of a use for it.
URL
Wouldn't an empty list be equivalent to an empty value, thus we don't need a new syntax?
Putting an empty list where for instance an integer is expected, just to say that there will be none, sounds counter-intuitive to me.
On Fri, Apr 05, 2019 at 01:37:11AM -0700, Julian Reschke wrote: Indeed, probably.
On Fri, Apr 05, 2019 at 03:11:00AM -0700, Poul-Henning Kamp wrote: Agreed in general. My point was that sometimes specs use "MUST send" when the sender doesn't know, resulting in stupid values appearing. That's exactly what led a number of agents to place a content-length with stupid values (0 or huge ones) with the CONNECT method a long time ago. An empty value where an integer is needed by the application is more of an application-level error than a protocol-level one in my opinion : it's up to the application to decide how to recover from this missing piece of information (is it really needed to process the request or not). For me it can mean "don't care", "don't know" or "not representable". After all floats support "NaN" for the same reason :-) Willy
If there is a "MUST send" requirement, there must also be something available in the same spec that can be sent ?
There is not, and never has been, an interop problem with sending empty field values. They are a list value of zero items or a string item of zero length. Accept and Host, respectively.
NAME how do you know that?
Because if a recipient drops an empty Host field the request will be rejected with 400. There have been no reports of such breakage in 25 years. It isn’t even a likely scenario given how message fields are parsed and reproduced.
If a recipient doesn't drop an empty host header, the request will still be rejected with 400, surely? Regardless, I'd note that many headers address this situation with a reserved value like . Is there value in standardising on one such value for future headers?
I'm not convinced, but I'd note that we also have many headers that use to denote "all"; it seems to me that if we're going to do null, we should do that too (but again, I'm not convinced this is adding value).
On Mon, Apr 08, 2019 at 05:16:41PM -0700, Mark Nottingham wrote: It depends on the header field that was empty ;-) I've used the empty Host header field quite a bit (even in health check requests). My observation has been that while HTTP/1.1 without Host naturally causes a 400, HTTP/1.1 with empty Host is often processed similar to HTTP/1.0 without Host or as 1.1 with an unknown Host. I'd say "why not", but it's useful to consider lists and the iterative processing that can happen, removing one item at a time. Having to place a specific value to denote emptiness would require specific processing (i.e. check for emptiness after removing any item just for the sake of replacing it with the special value). By the way, speaking about lists makes me think we may complicate interop when a header field appears multiple times. For example if we have this in a request : List: a,b,c,d Foo: bar List: e,f,g,h It's not unreasonable to think that some simplified implementations may replace the first occurrence of List with "none" after processing it, leading to this : List: none Foo: bar List: e,f,g,h Or possibly this : List: none Foo: bar List: none Which may be processed as "List: none,e,f,g,h" or "List: none,none" respectively. Just my two cents, Willy
Willy, I think that would be clearly broken, and we should be able to catch it with tests. I think we're talking about all of the container types here (dict, list, list of lists, parameterised lists), correct? Julian, you gave as an example. Given that the behaviour recommended is exactly the same as if the header was missing, that's not very compelling. Besides the potential stripping issue (I have heard of implementations that strip empty headers, but don't have details on hand), some header libraries may not make a distinction between missing and empty headers.
Overall, I don't see a lot of value in accommodating empty headers directly, and I don't think we should be promoting it as a practice.
Agree, I'm not convinced either. I see the potential, but Gettys rule applies: "The only thing worse than generalizing from one example is generalizing from no examples at all." (May actually be from Phil Karlton originally, sources differ.)
Hm, no. "A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings." vs. "An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding in response."
Yes, but in the real world, the outcome is always the same.
No. HTTP/1.1 introduced an IESG requirement that Host must always be sent and recipients must always reject with 400 if Host is not received. When I pointed out that not all URIs have a host, the response was that clients must send an empty Host field in that situation. It is a MUST requirement in Semantics section 5.4: This is ingrained in HTTP semantics and commonly used by non-browser HTTP implementations. There is only one example of an HTTP header field using "none" and that is Accept-Ranges. It isn't a good example for anything. To be clear, it would be a bug for an HTTP message processor to drop a received header field just because the value is empty. Nothing about SH will change that. What we are discussing is whether SH is capable of representing an empty list or an empty header field, both of which it is currently incapable of doing.
If that spec specifically says "empty field-value", a SH "empty" token will not be usable for Host: anyway, and we're back in the "generalizing from no example at all" again.
On Thu, Apr 11, 2019 at 03:53:15PM +0000, Poul-Henning Kamp wrote: After having thought a bit more about this, I now think that we don't need empty list elements in the end because lists are not strongly ordered, they're not arrays with a position so an empty element in a list brings no value.
I'd further say that removing an element from a list must result in removing the list once the last one was removed as it is a set. So I think I'm fine with not dealing with empty lists. This then leaves us only with the empty header field alone, likely where a string or a token are expected. I don't see a reason not to support an empty string just like any other string. A header field is not just a value, it's a name+value combination. With a void value the name still serves as a boolean (present or not) and this is exactly how it's used when the field is made mandatory to distinguish between agents generations or as a signal to detect support for something. We've all filled administrative forms where the requested information was irrelevant but mandatory in the form and just left it void so that the person in charge deals with the particular case (on paper) or filled with whatever was accepted (on web forms) hoping it would just be ignored since irrelevant. For me the Accept and Host fields are exactly in this category. My concern is to be certain that a valid HTTP request can be transmitted over SH. And ironically, the only mandatory HTTP header ("Host") is also the one requiring the support for an empty value due to its mandatory nature. Willy
I have lost count of the number of packages I have received from USA where part of the address is "Denmark does not have states" :-)
Again, the purpose of SH is not to allow all possible HTTP header to be represented in the data model -- it's to solidify the 80% case and promote best (and interoperable) practice. Representing a boolean as an empty header field is not good practice.
See PR above.
I've put in the changes for the list-based header fields. It's less clear to me that it's desirable to default a missing or empty item to an empty string (strings and tokens) 0 (integers and floats), False (boolean) or a 0-length binary array (binary data); to me, those are all going to be application-specific defaults that are better specified explicitly. I'm happy to adjust the spec to make that more clear, if folks feel it already isn't.
for
Per my reply to Bo Wu's OpsDir review: NAME can you add your motivating example to the introduction? Thanks!
I didn't mean to merge that PR without your review, so let me know if it looks good before I close this issue!
Looks good! The only change I made was to make the WebFinger reference informative. Please close.
Good catch, not sure why that wasn't informative before.
It was previously incorrectly normative. I just happened to notice when reviewing your addition. Thanks again!
I'm working on the wrong machine and my setup needs tuning. I'll just drop the errant commit.
[x] 1. ----- FP: Is the working group aware that RFC 793bis is in IESG evaluation (URL) ? Was the choice of having a normative reference to 793 conscious, in order to avoid any delay that might come from publication of draft-ietf-tcpm-rfc793bis? (Just checking this was considered) [x] 2. ----- for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be followed, with some additional restrictions that are specific to HTTP/2. FP: Given this requirement, I would have expected to see [TLSBCP] normatively referenced, rather than informatively. [x] 3. ----- layer. The frame and stream layers are tailored to the needs of the HTTP protocol and server push. FP: I would think the server push is part of the HTTP protocol, which makes this formulation "HTTP protocol and server push" confusing. [x] 4. ----- Type: The 8-bit type of the frame. The frame type determines the Flags: An 8-bit field reserved for boolean flags specific to the FP: I would find a reference to the IANA registry useful. [x] 5. ----- implementation of flow control can be difficult. When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion. Failure to do so could lead to a deadlock when FP: "When using flow control" might be rephrased to indicate "when flow control limits are lower than the maximum" (or something of the sort), since if I understand correctly the capability is always used, it is just the window size that changes (effectively implementing control of flow). Also "timely fashion" - I know that it is probably hard, but it would be nice to have a more precise qualification, or at least a hint of what is timely. [x] 6. ----- stream that it successfully received from its peer. The GOAWAY frame includes an error code that indicates why the connection is FP: "error code" - here as well I would have liked a reference to the IANA registry. [x] 7. ----- Exclusive: A single-bit flag.
This field is only present if the PRIORITY flag is set. Stream Dependency: A 31-bit stream identifier. This field is only present if the PRIORITY flag is set. Weight: An unsigned 8-bit integer. This field is only present if the PRIORITY flag is set. FP: I would have expected to see some definition of how the fields are used. If this is defined somewhere else, a reference would be good. [x] 8. ----- SETTINGS Frame { Length (24), Type (8) = 4, Unused Flags (7), ACK Flag (1), Reserved (1), Stream Identifier (31), Setting (48) ..., } Setting { Identifier (16), Value (32), } FP: Is there any reason why the Stream Identifier line is not: Stream Identifier (31) = 0, [x] 9. ----- a server does include a value it MUST be 0. A client MUST treat receipt of a SETTINGS frame with SETTINGSENABLEPUSH set to 1 as a connection error (Section 5.4.1) of type PROTOCOLERROR. FP: This is just my curiosity: what is the reason for this stronger requirement - I would think it shouldn't be a problem for the sender if it wants to advertise that it would permit/support server push. What am I missing? [x] 10. ----- A value of 0 for SETTINGSMAXCONCURRENTSTREAMS SHOULD NOT be treated as special by endpoints. A zero value does prevent the FP: When is it ok that the 0 value is treated as special? [x] 11. ----- set. Upon receiving a SETTINGS frame with the ACK flag set, the sender of the altered settings can rely on the value having been applied. FP: nit s/value/values. Also I believe this could be misunderstood - can it be made more precise on the fact that only the values that are present in the received frame with the ACK flag set (and not those that might have been ignored because not understood) have been applied. [x] 12. ----- A receiver MUST treat the receipt of a WINDOWUPDATE frame with an flow-control window increment of 0 as a stream error (Section 5.4.2) FP: nit s/an/a [x] 13.
----- FLOWCONTROLERROR (0x3): The endpoint detected that its peer violated the flow-control protocol. STREAMCLOSED (0x5): The endpoint received a frame after a stream was half-closed. FP: would be good to add a reference to the relevant sections. [x] 14. ----- set after receiving the HEADERS frame that opens a request or after receiving a final (non-informational) status code MUST treat the FP: Where is a "non-informational status code" defined? [x] 15. ----- FP: Are the following two sentences in Section 8.1.1. in contraddiction? request or response. Malformed requests or responses that are detected MUST be treated as a stream error (Section 5.4.2) of type PROTOCOLERROR. on the remainder of the request being correct. A server or intermediary MAY use RSTSTREAM -- with a code other than REFUSEDSTREAM -- to abort a stream if a malformed request or response is received. FP: In section 5.4.2. I read: An endpoint that detects a stream error sends a RSTSTREAM frame So the first sentence above implies RSTSTREAM MUST be sent, while the second sentence states RSTSTREAM MAY be sent. [x] 16. ----- their definitions in Sections Section 5.1 of [5.1] and Section 5.5 of [5.5] of [HTTP] respectively and treat messages that contain FP: References need fixing. [x] 17. ----- from the control data of the original request, unless the the FP: nit Remove one "the" [x] 18. ----- Note that request targets for CONNECT or asterisk-form OPTIONS requests never include authority information. FP: Please add a reference to 7.1 of [HTTP] as this is the first time "asterisk-form OPTION" appear in this document. [x] 19. ----- 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. FP: Do these two sentences contradict each other?
In the first sentence I am reading that the server can't create the necessary stream to send the PUSHPROMISE frame, in the second sentence I read that it can? [x] 20. ----- on a DATA frame is treated as being equivalent to the TCP FIN bit. A FP: Can a reference be added to the section where the TCP FIN bit is defined? [x] 21. ----- Content-Type: image/jpeg ==> - ENDSTREAM Content-Length: 123 + END_HEADERS FP: I think it would be good to add a sentence about the meaning of - and + (which I understand to be flag set or not set) in section 2.2. [x] 22. ----- treated as delimiters in other HTTP versions. An intermediary that translates an HTTP/2 request or response MUST validate fields according to the rules in Section 8.2 roles before translating a message to another HTTP version. Translating a field that includes FP: is "roles" supposed to be there? [x] 23. ----- The CONNECT method can be used to create disproportionate load on an proxy, since stream creation is relatively inexpensive when compared FP: nit s/an/a [x] 24. ----- FP: I think it would be good to keep the 3rd paragraph in Section 11 instead of asking the RFC Editor to remove it, just to keep a trace of the registries that have been defined in 7540, since those registries will now reference this document, but this document does not contain all the definitions of the different fields. [x] 25. ---- Comments: Obsolete; see Section 11.1 FP: I would suggest to be explicit and add "of this document" (unless links can be maintained in IANA registries Comments fields).
All done, closing.
Assuming the BCP stuff gets merged via the other PR first.
Allow clients to send GOAWAY to signal servers to UNSUBSCRIBE.
PR has GOAWAY as only sent from server to client, but there may be use cases for the reverse as pointed out by NAME
I'm not really clear, what would be the use case for client -> server GOAWAY? If the only use case is a client indicating end of subscription, then I think that would be better encoded in the SUBSCRIPTION_END that Alan mentioned, but if there's other use cases then I could see GOAWAY making more sense.
What if the client is not the original source, but rather a relay. In that case, the relay may need to restart/etc. One option is the relay sends a GOAWAY and the client starts publishing to a new relay. But does it need to do something about it's upstream subscriptions?
FWIW ... relay to relay is out of scope - we are only doing client to relay - we would need a lot more to have a full relay to relay protocol
A client-initiated GOAWAY is weird but kind of makes sense. I'm thinking of the dual ingest case when there are two connections from broadcaster to relay(s). If the client sends a GOAWAY message, it's an explicit signal to the relay that it needs to UNSUBSCRIBE to everything and find another route to the content. The party isn't over, you just can't stay here. But there's some overlap with UNANNOUNCE. I'm not sure if we actually need it.
That use case makes sense. "The party isn't over, you just can't stay here." is awesome tag line for use case. For a graceful shutdown of a publisher, I think the way to do that would be the client publishing sends un-annouce and the relay then ends all the subscriptions, once all the subscriptions are gone, the client closes the connection.
With UNANNOUNCE and ANNOUNCE_CANCEL (), I'm inclined to think we don't need this.
UNANNOUNCE tells the receiver not to send new SUBSCRIBEs, but doesn't currently mean "please UNSUBSCRIBE and find somewhere else to SUBSCRIBE if you still want content". Do we want a message to convey that semantic?
It definitely feels odd given that outside of SETUP and ROLE parameter, MoQT is a symmetric protocol.
My current thinking is that GOAWAY is useful for all publishers, even if they're 'clients' (ie: an original publisher). It also seems useful if an original publisher is publishing to an ingestion server that is about to restart and the server wants to cause them to connect to a different ingestion server. I don't have a clear use for the end subscriber sending a GOAWAY, but it also doesn't seem particularly harmful.
I think you missed a few spots to update (suggestions made), but maybe you intentionally left those as is?
The original issue here was concerned with Transfer-Encoding, but this was not a normative statement, it was a note. With a forward reference, this is better. The section on connection-specific headers probably could have been more specific. Now that the -semantics draft has a specific list of things (plus whatever lists), we can lean on that more directly.
HTTP/2 prohibits Transfer-Encoding, but doesn't actually prohibit other values: HTTP/3 broadened this language to cover all transfer codings: Should H2bis follow suit?
Can you take this to the list Mike? It seems like the only sensible answer, but I'd like to double-check.
In my mind, I was relying on Section 8.2.2: However, that probably isn't linked well enough to the . Unfortunately, there isn't a term we can just lift out; perhaps something like this:
On review with full context, the text that Mike cites is fine. It's an informational note. Mark's note here about the linkage to -semantics is good though. I will float this on the list to see if I messed up (again).
I believe I addressed all the things except the ones where I created issues for NAME . Please review again NAME .
NAME approved, merging this.
The SD-JWT spec does not define how to construct the HB-JWT. It would be nice if the HB-JWT could bind the signature to the transaction, i.e., the rest of the SD-JWT combined format for presentation. I'd suggest, we define the following payload for the HB-JWT:
Because the HB-JWT does not sign any other disclosures, any non-repudiation attacks are not possible.
Note that also SD-JWT will be more specific on the HB JWT: URL
Section is empty atm
The distinction of VC-SD-JWT and VP-SD-JWT etc. is still not super clean also in terms of what the verifier receives.
Fix references to OAuth SD-JWT
Fix references to RFCs, standards etc.