-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify digest-algorithm syntax with parameters (or drop parameters). #850
Comments
@LPardue @reschke I don't know of any parameter in the wild, but removing that will deviate from RFC 3230. If we want to remove parameters, we should explicit:
|
FWIW, deviating would fine in this case. One point in revising specs is to remove unused stuff. |
@reschke I agree. My question is whether it's better to:
Guidance on that is welcome. |
@mnot removal of Digest parameters would be a case where our update work deviates a bit further from what we might have initially had in mind. As Julian points out its fine to do so, however I want to make this more visibile before we take a decision. |
@LPardue I tweeted on that https://twitter.com/ioggstream/status/1295292991335268352 :) To me leaving the parameter definition to the algorithm specification is fine, eg #850 (comment) |
I'll send an email to the HTTP WG list too. |
+1 for removing parameters. |
+0 on removing parameters, but I want to strongly suggest that any examples of encoded parameters are expressed in terms of Structured Fields, even if the entire header is not compliant. ie:
where the parameters are encoded in the first two base64 encoded bytes. |
Mailing list thread: https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0092.html |
@reschke @mnot brief recap after discussion. We propose to deprecate parameters because:
The proposal:
OT: I agree that making digest a SF would have resolved the issue with just some advice of not using parameters as input values when defining new digest-algorithms |
@LPardue @reschke As parameters are now obsoleted, we have to decide whether to provide instructions for the transition. Current behaviorThe presence of a parameter in any representation-data-digest will invalidate the syntax of the whole Digest value. Hyp 1add the parameter definition to the ABNF and explicit that they SHOULD|MUST be ignored, while the checksum should be processed Hyp 2add the parameter definition to the ABNF and explicit that if a representation-data-digest contains parameter only this checksum should be ignored |
If we have no evidence of parameters in use, why would we need to consider a transition? Don't make things more complicated than they need to be. |
* Fix: httpwg#850. Obsolete parameters.
We deprecated parameters after this ml thread SF allows dropping the mention of them without formally deprecating, but I see some space for non interoperable behaviors.
Moreover we haven't defined any parameter yet. Some questions we might be able to answer:
|
My thoughts are:
By default, receivers would ignore In terms of paramaterizing algorithms, based on the evidence so far, "you ain't gonna need it". And if that turns out to be wrong, then we can spend to time to debate the merits of structured fields parameters vs in-band encoding inside the Bytes. But we don't need to speculate now IMO. |
Ok to defer the issue to future specs using parameters: I suppose the specs don't need further changes then. |
I'll make a PR that will capture how parameters are treated today and call out extensibility. |
@LPardue are you ok to close this issue without further changes to the document, according to your comments in #850 (comment) ? |
I'm struggling to come up with any text to add that won't overcomplicate things. Let's close for now and see if this comes up again during last call. |
I expect
This spec either:
RFC3230 stated that:
but:
In this draft we preserved that sentence but:
In #1213 there's a possible fix to support parameters, like the following
Notes
Use cases are parametrizable digest-algorithms like mi-sha256.
Another solution could be to deprecate field parameters in digest: parameters could still be adopted serializing them in the digest-value, and leaving the specification/serialization to the definition of the digest-algorithm. eg:
The text was updated successfully, but these errors were encountered: