Note: This ballot was opened for revision 01 and is now closed.

(Ben Campbell) Yes

Section 4 talks about how a problem type SHOULD resolve to HTML documentation. Is there ever a case where an API might be standardized to be used by multiple origin servers? Would each server host it's own documentation? Would the problem type be a relative URL under those circumstances? (You say it can be relative, but all the examples are fully qualified)

- 4, 2nd paragraph: "New problem types need to carefully
   consider..."
This is a pedantic nit, really a personal pet peeve: Designers of new problem types should consider this. I doubt the types themselves will :-)

(Stephen Farrell) Yes

- 3.1: "SHOULD NOT automatically" de-ref the type URI. Hmm, under
what circumstances would it be reasonable for any code to
automatically de-ref the type URI? If none, then either
s/SHOULD/MUST/ or maybe s/automatically// 

- 3.1, last para: I'm sure this is a known thing, but I don't know
the answer, so I'll ask:-) If I send a request for URL
example.com/foo and am re-directed to example.net/bar, against which
of those is a relative URL in the problem detail evaluated?  I hope
the answer is example.net - if not, there could be some attack that
could be mounted but I've not got a concrete example to offer.

- 3.2, last para: should "media type" be "problem type" at the end?

- 4: "typically with the "http" scheme" - your examples are all
https, don't you mean https here too?

Barry Leiba Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

(Spencer Dawkins) (was Discuss, Yes) No Objection

Thanks for helping me resolve my Discuss.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Terry Manderson) No Objection

Alvaro Retana No Objection

(Martin Stiemerling) No Objection