New issue: 6.1.1 too vague about parsing requirements

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

  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.


Received on Thursday, 11 January 2007 10:14:25 UTC