Subject: [apps-discuss] ietf-appsawg-http-problem

From: Cyrus Daboo <[email-masked]>
Date: Sat, 22 Nov 2014 10:36:52 -0500

Hi,
I recently added a normative reference to ietf-appsawg-http-problem in 
draft-ietf-tzdist-service-03. I know the chairs of TZDIST are keen to 
complete work on that draft and send it to the IESG, but of course we will 
want ietf-appsawg-http-problem to progress too. So what is the status of 
that draft in appsawg? I did not that Murray had asked for a shepherd - if 
none has been assigned I am happy to volunteer to do that to help move it 
along.

However, I do have one issue with the current draft: the TZDIST protocol is 
primarily a non-human HTTP protocol. tzdist defines its own set of error 
codes (e.g., "invalid-start", "tzid-not-found", etc) to better identify 
problems in requests. However, http-problem only defines a "type" member 
that is a URI that references a "human-readable" resource. As a result I 
added an "error-code" member for the tzdist specific codes. I wonder if it 
makes sense to include that in http-problem to cover similar use cases?

-- 
Cyrus Daboo

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 23 Nov 2014 14:33:51 +1100

> On 23 Nov 2014, at 2:36 am, Cyrus Daboo <[email-masked]> wrote:
> 
> Hi,
> I recently added a normative reference to ietf-appsawg-http-problem in draft-ietf-tzdist-service-03. I know the chairs of TZDIST are keen to complete work on that draft and send it to the IESG, but of course we will want ietf-appsawg-http-problem to progress too. So what is the status of that draft in appsawg? I did not that Murray had asked for a shepherd - if none has been assigned I am happy to volunteer to do that to help move it along.

I think Alexey is shepherding.

> However, I do have one issue with the current draft: the TZDIST protocol is primarily a non-human HTTP protocol. tzdist defines its own set of error codes (e.g., "invalid-start", "tzid-not-found", etc) to better identify problems in requests. However, http-problem only defines a "type" member that is a URI that references a "human-readable" resource.

Well, that’s a guideline. A bit of text that allows machine-readable responses too — whether that be HTML micro data or another format via conneg — might help.

All of that said, what’s your use case for a machine readable response? Fetching the error resources at runtime seems like a bad practice, as it’s going to cause load on the server, as well as more chances for failure...

> As a result I added an "error-code" member for the tzdist specific codes. I wonder if it makes sense to include that in http-problem to cover similar use cases?

That seems like an anti-pattern; having two identifiers for the same thing leads to problems.

Cheers,

--
Mark Nottingham   http://www.mnot.net/