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

[Erik Wilde <[e-mail]>]

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,

dret.

-- 
erik wilde | mailto:[e-mail] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |