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

From: Julian Reschke <[email-masked]>
Date: Tue, 1 Dec 2015 10:58:34 +0100

On 2015-11-20 21:56, The IESG wrote:
> ...

Minor nit: the media type registration templates miss a few fields 
defined in <https://tools.ietf.org/html/rfc6838#section-5.6>.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 1 Dec 2015 11:57:07 +0100

On 2015-12-01 11:47, Erik Wilde wrote:
> On 2015-12-01 10:58, Julian Reschke wrote:
> i could only find one and https://github.com/mnot/I-D/pull/162 is adding
> this last one. which other ones are you missing?
>
> thanks and cheers,
>
> dret.

"Fragment identifier considerations:" ...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 1 Dec 2015 13:16:10 +0100

On 2015-12-01 12:38, Erik Wilde wrote:
> On 2015-12-01 11:57, Julian Reschke wrote:
> thanks, i added those to the existing pull request.
>
> interestingly, when i looked at
> https://tools.ietf.org/html/rfc7303#section-9.1 to check which
> information application/xml was specifying there, this registration
> field was missing on the registration as well. same for
> https://tools.ietf.org/html/rfc7159#section-11 for application/json,
> which also is missing such a registration field.
>
> thanks and cheers,
>
> dret.

Interesting. I was looking at the HTTP (RFC723*) registrations, and 
those had the new fields.

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Tue, 1 Dec 2015 11:47:50 +0100

thanks and cheers,

dret.

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

---

From: Erik Wilde <[email-masked]>
Date: Tue, 1 Dec 2015 12:38:07 +0100

thanks and cheers,

dret.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 4 Dec 2015 12:02:13 +0100

On 2015-11-25 23:45, Mark Nottingham wrote:
> Sorry about that, Julian.
>
> I've updated to include everything except the XML-related questions; Erik?
>
> See:
>    http://mnot.github.io/I-D/http-problem/
>    http://tools.ietf.org/rfcdiff?url1=draft-ietf-appsawg-http-problem-01&url2=https://mnot.github.io/I-D/http-problem/index.txt

So can we please get the XML-related issues resolved and get a new draft 
submitted?

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Fri, 4 Dec 2015 15:06:23 +0100

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.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 4 Dec 2015 15:10:16 +0100

On 2015-12-04 15:06, Erik Wilde wrote:
>> 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.
>
>> 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.
>
>> It would be good to point out that due to the type definitions in the
>> schema, the whitespace inside <instance> is ignorable.
>

Yes, I believe so. Thanks.

Best regards, Julian