On Oct 10, 2014, at 3:03 PM, Tomek Mrugalski <[email protected]> wrote: > This option follows behavior described in Sections 17.1.1 > and 18.1.1 of RFC3315. Clients can insert > those options with specific values as hints for the > server. Depending on the server configuration and policy, > it may accept or ignore the hints. Client MUST be able > to process received values that are different than the > hints it sent.
What guidance would you give the client as to what hints to send? How would you avoid having the server do the wrong thing with hints based on stale data? This is why I think the "client hints" thing in 3315 is a mistake. I simply don't see how you can support this in any interoperable way. Supporting it at all is not likely to do anything, because both sides have to support it, but if they do, there's no way to predict whether it will actually work, because we have never said _how_ it works. So I am against specifying it this way; rather, this document should forbid the client sending it, so that if a server that implements this mistake is used, nothing bad will happen. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
