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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:erik.wilde@xxxxxxxx |
           | http://dret.net/netdret    |
           | http://twitter.com/dret    |




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]