Re: Issue 187 (Warn header (P6) vs RFC2047 encoding)

+1. Talking about languages when the charset is constrained -- as well  
as when it's not intended for end-user interpretation -- makes no sense.

I'd be more reticent to take this path, BTW, if there were any  
implementation of Warning in UAs. However, since as far as we know  
there isn't, it seems reasonable.


On 05/08/2009, at 9:56 AM, Henrik Nordstrom wrote:

> ons 2009-08-05 klockan 15:49 +0200 skrev Julian Reschke:
>> Mark Nottingham wrote:
>>> Tracking in <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/187>
>>
>> We have discussed this face-to-face last week, and I think there was
>> agreement that RFC 2047 in Warning headers is not implemented  
>> anywhere,
>> and thus we should remove it from the spec.
>
> Not implemented anywhere, and further that if useragents actually  
> start
> displaying the warnings then they will most likely display their own
> explanations in the users locale based on the error number, with the
> error message more of a diagnostic message on the same level as the
> reason phrase in the status line.
>
>
>>    The warn-text SHOULD be in a natural language that is most  
>> likely to
>>    be intelligible to the human user receiving the response.  This
>>    decision can be based on any available knowledge, such as the
>>    location of the cache or user, the Accept-Language field in a
>>    request, the Content-Language field in a response, etc.  The  
>> default
>>    language is English.
>
> I would even go as far as drop the language reference, using text
> similar to what we have for Reason-Phrase:
>
>        The warn-text is intended to give a short textual description  
> of
>        the warn-code. The warn-code is intended for use by automata  
> and
>        the warn-text is intended for the human user. The client is not
>        required to examine the warn-text.
>
> Regards
> Henrik
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 5 August 2009 18:21:02 UTC