Re: [httpapi] [Last-Call] [Ext] Re: Last Call: <draft-ietf-httpapi-rfc7807bis-04.txt> (Problem Details for HTTP APIs) to Proposed Standard

[Erik Wilde <[e-mail]>]

hello ben.

On 2022-11-11 01:26, Ben Bucksch wrote:
> As mentioned in my feedback, I would recommend to *not* couple 
> resolvable description webpage URLs and stable error type IDs. If even 
> IANA has troubles providing this right now, can you imagine the 
> discussions in companies and within projects? Just publishing anything 
> on the website is often a major process for many companies. And then 
> guaranteeing stability on top of that... Even if the webpage is 
> optional, there'll be the discussion that we might in the future make a 
> page, so better choose wisely now... But which hostname? Which URL form? 
> Every team providing an API will go through the same discussion. This is 
> a major blocker for adoption. Much easier to separate the concepts of 
> stable ID and documentation page.

first of all, it's really important to always keep in mind that this is 
a revision of an existing spec with the explicit goal to not break 
anything. that limits the maneuvering space.

we cannot change the fact that type is defined to be as it is, as a URI. 
what we've learned after publishing rfc 7807 is that some practices out 
there probably are not helpful when it comes to defining stable type 
identifiers, and/or using those identifiers in APIs. that's why section 
3.1.1 about the "types" member has so much additional text.

personally, i always have been a fan of separating identification and 
description, but it's a topic with no clear decision on what's the 
better approach; it's a matter of taste and of constraints. we have 
added some language addressing the topic, addressing explicitly some of 
the things you have been raising. for example, we're discussing "tag" 
URIs as one possibility to identify problem types without even creating 
the impression that there could be a linked description at that URI. not 
everybody may like "tag" but personally speaking it has become my go-to 
scheme when URIs are a given, you don't want locators, and you also 
don't want to jump through the additional hoops that are in place on the 
URN side of the spectrum.

what i am not quite clear about is what exactly you want to see 
discussed and potentially changed. we have the constraints of not 
breaking rfc 7807, and we have added quite a bit of language discussing 
some of the things that were mentioned as potentially problematic after 
some experience with rfc 7807. what within those constraints is it that 
you think we could change to improve the draft?

thanks and cheers,

dret.

-- 
Erik Wilde | mailto:[e-mail]    |
            | https://youtube.com/ErikWilde |