Subject: New issue: 6.1.1 too vague about parsing requirements

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 11 Jan 2007 10:43:52 +0100

6.1.1 Status Code and Reason Phrase

is apparently a bit too vague about how applications should parse and
process the information, making some implementations parse the reason
phrase (probably exact matches on the complete status line, not just
status code) to determine the outcome.

There should be a SHOULD requirement or equivalent that applications use
the status code to determine the status of the response and only process
the Reason Phrase as a comment intended for humans. 

It's true that later in the same section there is a reverse MAY
requirement implying this by saying that the phrases in the rfc is just
an example and may be replaced without affecting the protocol, but
apparently it's not sufficient for implementers to understand that
applications should not decide the outcome based on the reason phrase.

I propose rewording the last sentence of the first paragraph "The client
is not required to examine or display the Reason-Phrase." into something
like

  The client MAY present the Reason Phrase to the user and
  SHOULD NOT examine the Reason Phrase for other purposes.

or perhaps

  The client SHOULD NOT examine the Reason Phrase for other
  purposes than displaying it to the user.

Regards
Henrik

---

From: Lisa Dusseault <[email-masked]>
Date: Thu, 11 Jan 2007 11:17:38 -0800

>   purposes than displaying it to the user.

Displaying to the user is problematic if you mean the browser end- 
user, because the reason phrase isn't internationalized over the  
wire, nor is it well-suited to be used as a localization lookup.

We can also derive a more enforceable style of requirement by looking  
at who's putting the reason phrase on the wire.

Perhaps something along these lines:  "Servers MUST NOT use the  
Reason Phrase for information needed by end users, because the text  
is not translatable.  Servers MUST NOT use the Reason Phrase for any  
information needed by automated agents, that is, any case that would  
require a client to try to parse or match the reason phrase in order  
to decide what to do.   Reason phrases are for debugging and logging,  
whereas it's the role of status codes to be used both to look up  
localized error messages for display to the user, and for helping  
automated agents decide whether something succeeded or failed or what  
to do next."

thx,
Lisa

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 12 Jan 2007 04:24:54 +0100

> wire, nor is it well-suited to be used as a localization lookup.

This is a completely different question. And in reality it's not a big
one. It's for example not hard for user-agents to have a translation
table of the commonly used example reason phrases.

Also, there is nothing which requires user-agents to display the reason
phrase at all.

My proposed change in wording is only to clarify that the reason-phrase
SHOULD NOT be used by automata, only humans if anyone.

Regards
Henrik

---

From: Yves Lafon <[email-masked]>
Date: Wed, 17 Jan 2007 05:17:50 -0500 (EST)

> SHOULD NOT be used by automata, only humans if anyone.

The text is pretty clear, especialy when you read "The reason phrases 
listed here are only recommendations -- they MAY be replaced by local 
equivalents...", implying your text.
Lisa's comment on the lack on i18n of the reason phrase could be noted in 
this paragraph.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves