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

[Darrel Miller <[e-mail]>]

Erik,

> From: httpapi <[e-mail]> on behalf of Erik Wilde <[e-mail]>
>  
> hello rich.
> 
> On 2020-12-10 08:07, Salz, Rich wrote:
> > At our meeting at IETF 109, we discussed
> > 
> > https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-cedik-http-warning-02
> > https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-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.

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