Problem Details for HTTP APIs
RFC 7807
Note: This ballot was opened for revision 01 and is now closed.
(Ben Campbell) Yes
Comment (2015-12-16 for -02)
No email
send info
send info
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
Comment (2015-12-11 for -02)
No email
send info
send info
- 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
Comment (2016-01-07 for -02)
No email
send info
send info
Thanks for helping me resolve my Discuss.