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

From: Cyrus Daboo <[email-masked]>
Date: Mon, 01 Dec 2014 11:09:38 -0500

Hi Mark,

--On November 23, 2014 at 2:33:51 PM +1100 Mark Nottingham <[email-masked]> 
wrote:

>> 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.

OK, good. I would like to see this draft move along so as not to block 
progress of tzdist.

>> 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...

Right - I don't think there is a need to have a "fetchable" URI as the 
error code, but rather a "token" defined by the protocol specification that 
clearly identifies the type of the error. I would be OK with using 
something other than an HTTP URI in "type" (instead of inventing the 
"error-code" member as I did) - but then the question is what is an 
appropriate error code to use? I guess we could define 
"urn:ietf:tzdist:error-code:" as a prefix for error code URIs which can 
appear as values in the problem report "type" member.

>> 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.

Agreed - but then we need to decide what form an "error code" will take 
when used in the "type" member.

-- 
Cyrus Daboo

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Dec 2014 06:27:30 +1100

> On 2 Dec 2014, at 3:09 am, Cyrus Daboo <[email-masked]> wrote:
> 
> Hi Mark,
> 
> --On November 23, 2014 at 2:33:51 PM +1100 Mark Nottingham <[email-masked]> wrote:
> 
> OK, good. I would like to see this draft move along so as not to block progress of tzdist.

AIUI we're getting close to WGLC. 

> Right - I don't think there is a need to have a "fetchable" URI as the error code, but rather a "token" defined by the protocol specification that clearly identifies the type of the error. I would be OK with using something other than an HTTP URI in "type" (instead of inventing the "error-code" member as I did) - but then the question is what is an appropriate error code to use? I guess we could define "urn:ietf:tzdist:error-code:" as a prefix for error code URIs which can appear as values in the problem report "type" member.

That would work, if you're uncomfortable using a HTTP URI (it's common practice to use them for identifiers *without* being fetchable; making them fetchable after the fact if need be is considered a feature).

> Agreed - but then we need to decide what form an "error code" will take when used in the "type" member.
> 
> -- 
> Cyrus Daboo
> 

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