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

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 17 Dec 2015 06:38:41 -0800

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

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'm elevating this to a (late) Discuss, because I haven't heard anything
back, and didn't want the document approved without having a (short)
discussion. I'll be back to Yes after that.

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)?

So, the situation looks to me, like there's a MUST

   The status member, if present, is only advisory; it conveys the HTTP
   status code used for the convenience of the consumer.  Generators
   MUST use the same status code in the actual HTTP response, to assure
   that generic HTTP software that does not understand this format still
   behaves correctly.  

that some intermediary can dork with, so the result violates the MUST,
and we really can't tell the receiver what you should do at that point.
"Gee, I guess you're gonna have to flip a coin to decide who to believe"
would be sad, but it would be more guidance than the document has now :-)

----------------------------------------------------------------------
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?")

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Dec 2015 11:05:20 +1100

Hi Spencer,

> with by an intermediary - or is that even true)?

It really depends on what their purpose is. The HTTP status might be updated because of legitimate HTTP machinery -- e.g., by a cache (304), or a proxy (various things like proxy auth, disconnected operation). The status member is there to preserve the original intent of the author, and also for convenience (e.g., when a message is persisted, often the status is lost). 

> would be sad, but it would be more guidance than the document has now :-)

If you're implementing generic HTTP software, you're going to be using the HTTP status. If you're interpreting the HTTP problem itself, you're probably going to pay attention to the one in-document, IF you pay attention to it at all.

Those requirements are to make it compatible with the XML mapping. They're SHOULDs because someone might be really, really sure that their problems will never be used in XML.

Cheers,

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