Subject: [apps-discuss] Fwd: New Version Notification for draft-nottingham-http-problem-00.txt

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Jul 2012 10:48:43 +1000

FYI.

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-http-problem-00.txt
> Date: 4 July 2012 10:28:26 AM AEST
> To: [email-masked]
> 
> 
> A new version of I-D, draft-nottingham-http-problem-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Filename:	 draft-nottingham-http-problem
> Revision:	 00
> Title:		 Indicating Details of Problems to Machines in HTTP
> Creation date:	 2012-07-04
> WG ID:		 Individual Submission
> Number of pages: 9
> URL:             http://www.ietf.org/internet-drafts/draft-nottingham-http-problem-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-nottingham-http-problem
> Htmlized:        http://tools.ietf.org/html/draft-nottingham-http-problem-00
> 
> 
> Abstract:
>   This specification proposes a "Problem Detail" as an extensible way
>   to carry machine-readable details of HTTP errors in a response, to
>   avoid the need to invent new response formats for non-human
>   consumers.
> 
> 
> 
> 
> The IETF Secretariat

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

---

From: mike amundsen <[email-masked]>
Date: Tue, 3 Jul 2012 22:41:21 -0400

Mark:

Good to see this I-D. This has come up a handful of times recently in my
online/IRL convos.

I've been contemplating "solving" this problem (ha!) w/ a link-rel value of
"error" that could be used for both link headers and in negotiable bodies:

HTTP/1.1 400 Bad Request
Link: <http://example.org/logs/errors/aqswdefrgt>; rel="error"
Content-type: text/html

<div class="error">
  <span class="text">Invalid hat size, please try again!</span>
  <span class="code">BAD-HAT-01</span>
  <a href="http://example.org/logs/errors/aqswdefrgt"
rel="error">Details...</a>
</link>

A registered value of "error" might be preferable to using "describedby";
esp for machine clients that might encounter "describedby" in other
contexts.

Also, I've found using a "code" property has been helpful for machine
clients as this will be static no matter the language used to express the
title text.

mca
http://amundsen.com/blog/
http://twitter.com@mamund
http://mamund.com/foaf.rdf#me

On Tue, Jul 3, 2012 at 8:48 PM, Mark Nottingham <[email-masked]> wrote:

> > URL:
> http://www.ietf.org/internet-drafts/draft-nottingham-http-problem-00.txt
> > Status:
> http://datatracker.ietf.org/doc/draft-nottingham-http-problem
> > Htmlized:
> http://tools.ietf.org/html/draft-nottingham-http-problem-00
> >
> >
> > Abstract:
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 4 Jul 2012 15:31:23 +1000

On 04/07/2012, at 12:41 PM, mike amundsen wrote:

> Mark:
> 
> Good to see this I-D. This has come up a handful of times recently in my online/IRL convos.

Thanks. 

> I've been contemplating "solving" this problem (ha!) w/ a link-rel value of "error" that could be used for both link headers and in negotiable bodies:
> 
> HTTP/1.1 400 Bad Request
>   <a href="http://example.org/logs/errors/aqswdefrgt" rel="error">Details...</a>
> </link> 
> 
> A registered value of "error" might be preferable to using "describedby"; esp for machine clients that might encounter "describedby" in other contexts.

That was some of the feedback I got pre-draft, and I agree that a different relation might be better. I'm not sure about "error" because it might be misinterpreted; was maybe thinking about a simple "problem-detail" or "problem-type" (because the detail is the *whole* set of details about the type *and* instance of the problem).

> Also, I've found using a "code" property has been helpful for machine clients as this will be static no matter the language used to express the title text

That's the function that the URI has in mine. 

Cheers,

---

From: mike amundsen <[email-masked]>
Date: Wed, 4 Jul 2012 01:54:47 -0400

That was some of the feedback I got pre-draft, and I agree that a different
relation might be better. I'm not sure about "error" because it might be
misinterpreted; was maybe thinking about a simple "problem-detail" or
"problem-type" (because the detail is the *whole* set of details about the
type *and* instance of the problem).

What misinterpretation of "error" do you foresee?
Can you help me get a better handle on the difference you have in mind
between "detail" and "type" and/or "type" and" instance" here?

title text

So the content at the other end of URI "z" will always be the same content,
no matter the app using this URI, or the specifics that _caused_ the
"problem", right?

FWIW, in my current usage, the href points to a record that is specific to
the immediate problem. This means it is possible that the server will
create and collect error logging information at these URIs.

I assume that possibility is not accounted for in your baseline design.

mca

---

From: Erik Wilde <[email-masked]>
Date: Wed, 04 Jul 2012 09:20:18 +0200

hello all.

thanks, mark, for the initiative!

On 2012-07-04 07:54 , mike amundsen wrote:
> So the content at the other end of URI "z" will always be the same
> content, no matter the app using this URI, or the specifics that
> _caused_ the "problem", right?
> FWIW, in my current usage, the href points to a record that is specific
> to the immediate problem. This means it is possible that the server will

it seems to me there's value in having the ability to express both 
concepts: an "error type" that indicates the type of problem encountered 
(and i think mark's idea of using a URI for this is better than using a 
non-URI identifier), as well as an "error instance" that indicates 
specific information about the occurrence of the error in that 
particular case. both could probably be optional, and for the type link 
i'd suggest to treat this as an identifier only (clients should not 
dereference the URI, the only meaningful operation would be to compare 
it to known error identifiers), whereas the error instance would be 
expected to return a representation of the specific error instance.

cheers,

dret.

-- 
erik wilde | mailto:[email-masked]  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

---

From: James M Snell <[email-masked]>
Date: Wed, 4 Jul 2012 14:06:31 -0700

In general, the feedback I offered you previously still applies, I
think. However, that said, assuming things move forward with the
draft, I do not believe the "describedby" link rel is a great choice
here. Another option would be to use the "type" link I introduced here
[1]. It's a fairly minor detail, however, so if it stays with
"describedby" that's fine too.

[1] http://tools.ietf.org/html/draft-snell-additional-link-relations-04

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Jul 2012 11:52:19 +1000

> What misinterpretation of "error" do you foresee?

I want to avoid encouraging people to see the format as the indication of the error -- that is and always should be the status code.

> Can you help me get a better handle on the difference you have in mind between "detail" and "type" and/or "type" and" instance" here?

I see two things -

  1. Identifying the nature of the problem (e.g. from the draft - "out of credit"). This is *why* the status code (in this case, 403 Forbidden) was generated, but not specific to this instance of the problem -- many people can get "out of credit" and get the same machine-readable identifier.

  2. Identifying the instance of the problem (e.g., when it happened to bob when his account was low last Thursday).

#1 is already covered (although we're talking about changing its name).

#2 isn't yet. I'm not convinced that it should be part of the "core"; making links to errors available exposes a LOT of sensitive information, potentially, and it's at best a convenience. The most common case for identifying the instance of an error, AIUI, is to allow a user to quote that to support, so they can dig into why it happened; however, a service doesn't necessarily need that (e.g., if they track errors by user, it's just a matter of looking up recent errors for that user).

Of course, a particular problem type, or deployment of it, could extend to offer such a link.

> So the content at the other end of URI "z" will always be the same content, no matter the app using this URI, or the specifics that _caused_ the "problem", right?

Yes.

> FWIW, in my current usage, the href points to a record that is specific to the immediate problem. This means it is possible that the server will create and collect error logging information at these URIs.
> 

No. See above.

Cheers,