Original text:
This privileged position allows for richer feature extraction from encrypted data, which might improve traffic analysis. <del> can use padding to reduce the effectiveness of traffic analysis. </del>  Padding is a capability provided by binary HTTP messages; see BINARY. If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message

Reviewer comments:
Comment by NAME How would that work? How would the client consent? Or show awareness? Or become aware ? Can't the Target Resource also not use padding in the response? But I guess they wouldn't know about being connected to obliviously or regularly, unless the Client tells the server within its encrypted payload request? Eg if a regular https server sees a certain field, it would/could know to do some padding? (one would assume ohttp relays are fairly well known on static IPs anyway, so the Client wouldn't be revealing much if it could ask the http server itself for random padding
There are two questions here, delays and padding. Both are areas in which the specification is not prescriptive. This is deliberate, mostly because these are areas where a single strategy would be inadvisable. Application needs vary. Well, in any number of ways. A telemetry submission service (see also STAR) might provide greater privacy benefit from batching requests that are forwarded from the client to gateway. In that model, the client might tolerate arbitrary delay (see URL for example). In other cases, the client still cares about a response, but it might be willing to hang around for some time (10s, 30s) for an answer. How the client consents to delays can also vary. It could be part of terms of service that are negotiated when the use of the relay is arranged. That sort of arrangement might cover all these points. If you are looking for protocol mechanisms, we've discussed explicit signaling as an extension. A client could use something like (see ) to indicate that within the protocol[^1]. An explicit signal demonstrates awareness for those cases where the delay might be conditional. [^1]: Note also that this sort of signaling might imply a need for the relay to remove that field, though perhaps all clients add it and so it doesn't reveal anything if forwarded. Yes. Section 6.3 references back to this text, but it's worth mentioning the gateway too. There are many things that might feed into a padding strategy. Sometimes this is something the gateway will know because they are configured for a particular application and can look at the payload to determine how to best pad. Clients can probably signal (within encapsulation) what they might prefer, if that would help. Again, it's too application-specific to say much of use.
Martin, The comment it isn’t my comment. Maybe there is another Pwouters in github Kind regards Paul Verstuurd vanaf mijn iPad
My apologies. I definitely got the wrong person there.
thanks
Flipping to approve, with or without my suggestion. Sorry again for my confusion.

Revised text:
This privileged position allows for richer feature extraction from encrypted data, which might improve traffic analysis.  <ins> and can use padding to reduce the effectiveness of traffic analysis. </ins> Padding is a capability provided by binary HTTP messages; see BINARY. If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message