Hi,

below some feedback.

Not in the spec:

1) The spec doesn't mention that this sort of duplicates earlier work 
done in WebDAV; see 
<http://greenbytes.de/tech/webdav/rfc4918.html#precondition.postcondition.xml.elements>

2) The spec talks about using Accept to instruct the server whether to 
return problem details or HTML. Maybe it would be worthwhile to mention 
that if you use XML, you could *always* send problem details, and then 
use <http://www.w3.org/TR/xml-stylesheet/> to instruct the UA to convert 
to HTML; that would get rid of the conneg complexity.

In the spec:

 >    The data model for problem details is a JSON [RFC7159] object; when
 >    formatted as a JSON document, it uses the "application/problem+json"
 >    media type.  Appendix A defines how to express them in an equivalent
 >    XML format, which uses the "application/problem+xml" media type.

Why is this an appendix?

 >    A problem's type URI SHOULD resolve to HTML
 >    [W3C.REC-html401-19991224] documentation that explains how to resolve
 >    the problem.

Not sure why we need to mandate HTML here. If the ref is updated to 
HTML5 it would at least allow XHTML as well.


 >    If such additional members are defined, their names SHOULD start with
 >    a letter (ALPHA, as per [RFC5234]) and SHOULD consist of characters
 >    from ALPHA, DIGIT, and "_" (so that it can be serialized in formats
 >    other than JSON), and SHOULD be three characters or longer.

DIGIT should ref RFC5234 as well, optimally point readers directly to 
Appendix B.1.

 >    The OPTIONAL RELAX NG schema [ISO-19757-2] for the XML format is:

What does "OPTIONAL" mean here? The schema doesn't seem optional at all; 
lacking it, you wouldn't even know what XML namespace to use.

 >    default namespace ns = "urn:ietf:rfc:XXXX"

This needs to state that it will be updated based on the assigned RFC 
number.

 >    start = problem
 >
 >    problem =
 >      element problem {
 >        (  element  type            { xsd:anyURI }?
 >         & element  title           { xsd:string }?
 >         & element  detail          { xsd:string }?
 >         & element  status          { xsd:positiveInteger }?
 >         & element  instance        { xsd:anyURI }? ),
 >        anyNsElement
 >      }
 >
 >    anyNsElement =
 >      (  element    ns:*  { anyNsElement | text }
 >       | attribute  *     { text })*
 >
 >    The media type for this format is "application/problem+xml".


 >    Extension arrays and objects can be serialized into the XML format by
 >    considering an element containing a child or children to represent an
 >    object, except for elements that contain only child element(s) named
 >    'i', which are considered arrays.  For example, an alternate version
 >    of the example above would appear in XML as:

This is written like guidance, but it's normative, right?

 >    HTTP/1.1 403 Forbidden
 >    Content-Type: application/problem+xml
 >    Content-Language: en
 >
 >    <?xml version="1.0" encoding="UTF-8"?>
 >    <problem xmlns="urn:ietf:rfc:XXXX">
 >      <type>http://example.com/probs/out-of-credit</type>
 >      <title>You do not have enough credit.</title>
 >      <detail>Your current balance is 30, but that costs 50.</detail>
 >      <instance>
 >        http://example.net/account/12345/msgs/abc
 >      </instance>

It would be good to point out that due to the type definitions in the 
schema, the whitespace inside <instance> is ignorable.


Editorial nits:

> Abstract
>
>    This document defines a "problem detail" as a way to carry machine-
>    readable details of errors in a HTTP response, to avoid the need to
>    invent new error response formats for HTTP APIs.

s/invent/define/ maybe?

> Note to Readers
>
>    This draft should be discussed on the apps-discuss mailing list [1].

add "to be removed by RFC Editor..."

> 1. Introduction
>
>
>    HTTP [RFC7230] status codes are sometimes not sufficient to convey
>    enough information about an error to be helpful.  While humans behind
>    Web browsers can be informed about the nature of the problem with an
>    HTML [W3C.REC-html401-19991224] response body, non-human consumers of
>    so-called "HTTP APIs" are usually not.

You probably want to cite HTML5 now. Also, consider shortening the 
reference name to "HTML".

>    This specification defines simple JSON [RFC7159] and XML
>    [W3C.REC-xml-20081126] document formats to suit this purpose.  They
>    are designed to be reused by HTTP APIs, which can identify distinct
>    "problem types" specific to their needs.

...and to "XML".

>    Additionally, problems can contain other information, such as a URI
>    that identifies the specific occurrence of the problem (effectively
>    giving an identifier to the concept "The time Joe didn't have enough
>    credit last Thursday"), which may be useful for support or forensic
>    purposes.

s/may/can/

> 3.1. Problem Details Object Members
>
>
>    A problem details object MAY have the following members:

s/MAY have/can have/

>    o  "title" (string) - A short, human-readable summary of the problem
>       type.  It SHOULD NOT change from occurrence to occurrence of the
>       problem, except for purposes of localisation.

Does this imply localisation-per-request (Accept-Language?)

>    The detail member, if present, SHOULD focus on helping the client
>    correct the problem, rather than giving debugging information.

s/SHOULD/ought to/

>    Finally, an application may have a more appropriate way to carry an

s/may/might/

>    That said, it is possible to add support for problem details to
>    existing HTTP APIs using HTTP content negotiation (e.g., using the
>    Accept request header to indicate a preference for this format).

Reference Section 5.3.2 of RFC7231.

>    New problem type definitions MUST document:
>
>    1.  A type URI (typically, with the "http" scheme),
>
>    2.  A title that appropriately describes it (think short), and
>
>    3.  The HTTP status code for it to be used with.
>
>    Problem types MAY specify the use of the Retry-After response header
>    in appropriate circumstances.

s/Problem type/Problem type definitions/

Also reference Section 7.1.3 of RFC7231.

> 8.2. Informative References
>
>
>    [ISO-19757-2]
>               International Organization for Standardization,
>               "Information Technology --- Document Schema Definition
>               Languages (DSDL) --- Part 2: Grammar-based Validation ---
>               RELAX NG", ISO/IEC 19757-2, 2003.

This one sounds normative to me.

>    [W3C.REC-xml-20081126]
>               Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
>               F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
>               Edition)", World Wide Web Consortium Recommendation REC-
>               xml-20081126, November 2008,
>               <http://www.w3.org/TR/2008/REC-xml-20081126>.

Same here.

>    Some HTTP-based APIs use XML [W3C.REC-xml-20081126] as their primary
>    format convention.  Such APIs MAY express problem details using the
>    format defined in this appendix.

s/MAY/can/


Best regards, Julian