[CDNi] Applicability of draft-nottingham-http-problem to CDNI Redirection interface

[Ben Niven-Jenkins <[e-mail]>]

CDNIers,
cc'ing Mark Nottingham as the author of draft-nottingham-http-problem in case he has any views.

Previously Francois asked whether we should use draft-nottingham-http-problem to communicate errors for the CDNI Redirection interface (draft-ietf-cdni-redirection).

During IETF89 in London I presented my view that using draft-nottingham-http-problem is not applicable to the CDNI Redirection interface and took an action to follow-up by sending my reasoning to the mailing list.

draft-nottingham-http-problem "defines a "problem detail" as a way to carry machine-readable details of errors in a HTTP response, to avoid the need to invent new error response formats for HTTP APIs."

And it also says "Note that problem details are (naturally) not the only way to convey the details of a problem in HTTP; if the response is still a representation of a resource, for example, it's often preferable to accommodate describing the relevant details in that application’s format.”

In the case of draft-ietf-cdni-redirection we have our own response format for communicating details of the redirection from dCDN to uCDN.

Currently we have defined our own format for errors (aligned with the response format for successful requests) and what we have specified contains all the same fields as specified draft-nottingham-http-problem, with the only significant difference being that draft-nottingham-http-problem uses a Media Type for communicating the error code, whereas draft-ietf-cdni-redirection uses a numeric code.

Having a separate format for errors doesn't seem to make much sense to me, especially as there may be cases where we need to communicate details of a redirection and signal an error within the same response.

Therefore IMO we are in the situation quoted from draft-nottingham-http-problem above, i.e. we already have an application specific format for responses and therefore IMO it is preferable to accommodate errors within our existing response body format rather than trying to leverage a more generic mechanism such as that described in draft-nottingham-http-problem.

Unless anyone feels strongly otherwise, we will continue to define CDNI Redirection interface errors in the application specific format we currently have in draft-ietf-cdni-redirection.

Regards
Ben