Subject: [apps-discuss] Spencer Dawkins' Yes on draft-ietf-appsawg-http-problem-02: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 16 Dec 2015 14:05:00 -0800

Spencer Dawkins has entered the following ballot position for
draft-ietf-appsawg-http-problem-02: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-appsawg-http-problem/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I've wished this mechanism was available, a few times already.

In this text,

   If such additional members are defined, their names SHOULD start with
   a letter (ALPHA, as per [RFC5234], Appendix B.1) and SHOULD consist
   of characters from ALPHA, DIGIT (Ibid.), and "_" (so that it can be
   serialized in formats other than JSON), and SHOULD be three
   characters or longer.
   
are there any benefits to not conforming to these SHOULDs? For example,
would you really need to have a two-character member name, and you'd fail
if the member name was three characters long? ("Why are these not
MUSTs?")

In this text,

   The "status" member duplicates the information available in the HTTP
   status code itself, thereby bringing the possibility of disagreement
   between the two.  Their relative precedence is not clear, since a
   disagreement might indicate that (for example) an intermediary has
   modified the HTTP status code in transit.  As such, those defining
   problem types as well as generators and consumers of problems need to
   be aware that generic software (such as proxies, load balancers,
   firewalls, virus scanners) are unlikely to know of or respect the
   status code conveyed in this member.
   
I understand what you're saying about a mismatch being possible, and some
of the possible reasons why that might happen, but isn't this saying that
anyone who can understand the "status" member should prefer its value
when there's a mismatch (because it's less likely to have been dorked
with by an intermediary - or is that even true)?