Re: [apps-discuss] Last Call: <draft-ietf-appsawg-http-problem-01.txt> (Problem Details for HTTP APIs) to Proposed Standard

[Julian Reschke <[e-mail]>]

On 2015-12-04 15:06, Erik Wilde wrote:
> On 2015-11-25 11:09, Julian Reschke wrote:
>> I don't believe that all of my WGLC feedback from December 2014 has been
>> addressed (and that includes subjects on where we agreed on changes).
>> See
>> <http://www.ietf.org/mail-archive/web/apps-discuss/current/msg13453.html>.
>>
>
> quoting from this message, these changes should address your issues:
>
>> 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.
>
> https://github.com/dret/I-D-1/commit/6f37bcaca5a5295a76592231a1a614b0f0f76957
> should take care of this. it recommends to use XSLT 1.0.
>
>>>    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?
>
> i am honestly not sure about this. mark preferred to have it as an
> appendix, and since he is the main author, that's where it ended up.
>
>>>    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.
>
> the idea was to not mandate that people use RELAX NG. we picked RELAX NG
> because it's easier to read than XSD, but the idea is that there should
> be no normative schema because schemas never completely capture what's
> in a spec. i agree that the term "OPTIONAL" may be a bit confusing here,
> though, so i rephrased that section a bit.
>
> https://github.com/dret/I-D-1/commit/46b02840131147b75795d64baa09ac1004e5e132
>
>
>>>    default namespace ns = "urn:ietf:rfc:XXXX"
>> This needs to state that it will be updated based on the assigned RFC
>> number.
>
> https://github.com/mnot/I-D/blob/gh-pages/http-problem/draft-ietf-appsawg-http-problem-02.txt#L29
> takes care of that.
>
>>>    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?
>
> yes, these are the rules how it has to be done. does this rephrasing
> work for you?
>
> https://github.com/dret/I-D-1/commit/eac63fbd5659b89ac2a408987368f4e21030382e
>
>
>>>      <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.
>
> that may be more complicated and potentially confusing than to simply
> fix the XML to not contain whitespace, right?
>
> https://github.com/dret/I-D-1/commit/69c39606c4087c53710695124cdb9020a5438ac3
>
>
> https://github.com/mnot/I-D/pull/165 is where all the commits live for
> now, i hope they are addressing all of your issues?
>
> thanks and cheers,

Yes, I believe so. Thanks.

Best regards, Julian