Subject: [httpapi] Discussion of adopting Content-Warning header

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Dec 2020 16:07:55 +0000

At our meeting at IETF 109, we discussed
                                https://tools.ietf.org/html/draft-cedik-http-warning-02

Let’s discuss this (we didn’t have enough time at the virtual). Feel free to use this thread or start new ones.

---

From: Erik Wilde <[email-masked]>
Date: Sun, 13 Dec 2020 13:20:30 -0800

hello rich.

On 2020-12-10 08:07, Salz, Rich wrote:
> <https://tools.ietf.org/html/draft-cedik-http-warning-02>
> 
> Let’s discuss this (we didn’t have enough time at the virtual). Feel 
> free to use this thread or start new ones.

i am not aware of any specific issue that were brought up at the IETF 
109 meeting.

it would be great to see the draft being adopted by this group, but if 
there isn't enough interest, an alternative path may be to keep 
developing it as an individual draft, and then present it to this group 
for community review when we think it is complete and ready to be 
published as an RFC.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Darrel Miller <[email-masked]>
Date: Tue, 15 Dec 2020 05:00:30 +0000

Erik,

> From: httpapi <[email-masked]> on behalf of Erik Wilde <[email-masked]>
>  
> hello rich.
> 
> > https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-cedik-http-warning-02
> > https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-cedik-http-warning-02
> > 

I believe the issue that was raised at the end of the IETF109 meeting was related to the fact that the Content-Warning header does not provide any details about the nature of the warning, and there is a need to look in the payload to understand the warning.  At least that seems to be the behavior of "embedded-warning".  The Content-Warning header simply indicates an warning is present and when it occurred.

Based on this, it would require a component to understand the semantics of the returned media type to be able to identify the details of the warning.  If a component needs to understand the media type to understand the warning, then the content-warning header seems to be limited to the role of a performance optimization for intermediaries.

Perhaps if there were more examples of different kinds of Content-Warning types, it might be clearer as to the value of standardizing the header.  

I have certainly run into scenarios where there is value in returning warnings with a response and I've see the Warnings header from RFC 7234 used in several cases.  However, the Warning header includes the Warn-Code to provide some details about the reason for the warning.  One advantage of using the Warning header was the fact that the warnings did not need to affect the structure of the payload.

Would you consider a change to this draft that enabled representing details of the warning in the header itself?

Darrel

---

From: Roberto Polli <[email-masked]>
Date: Tue, 15 Dec 2020 16:31:41 +0100

Hi @all,

Il giorno mar 15 dic 2020 alle ore 06:00 Darrel Miller
<Darrel.Miller=[email-masked]> ha scritto:
> > if
> > developing it as an individual draft
I think this draft will benefit from a wider discussion, including the
considerations provided by Darrell.

> [..] I've see the Warnings header from RFC 7234 used in several cases.
> [..] One advantage of using the Warning header was the fact that the warnings did not need to affect the structure of the payload.
iiuc this behavior can be configured via the content-warning-type: the
payload one is  "embedded-warning",
so the field definition already has an extension mechanism capable of
supporting further types, eg "expensive-request" or "old-api-version"
or whatever.

I think this kind of discussions are the kind of activity of the workgroup.

Have a nice day,
R.