ietf-wg-httpapi / rfc7807bis

Revision of RFC7807: HTTP Problem Details
Other
20 stars 8 forks source link

Questions regarding extension #40

Closed olijaun closed 2 years ago

olijaun commented 2 years ago

Hi

The draft states:

Note that because extensions are effectively put into a namespace by the problem type, it is not possible to define new "standard" members without defining a new media type.

I get the part regarding the media type.

I'm not sure if I understand the part about the namespace correctly (I'm not a native speaker so this might be the problem):

Let's say I have the following problem (Ex. 1):

{
  "type": "about:blank",
  "title": "something's wrong"
}

Now I need an extension "myextension". Does this mean I necessarily have to define a specific type as shown in Ex 2?

{
  "type": "http://example.com/mytype",
  "title": "something's wrong",
  "myextension": "bla"
}

Or could I just add an extension to a problem detail of type "about:blank"? This would mean that extensions are defined always for all types (Ex 3)?

{
  "type": "about:blank",
  "title": "something's wrong",
  "myextension": "bla"
}

If Ex 2 is the correct way then I don't understand the other discussion regarding forward compatibility.

If Ex 3 is correct then I don't understand the quote I've put in the beginning of my post.

Regards Oliver

mnot commented 2 years ago

To add an extension to a problem type, right now you need to control the type itself; you can't define an extension for another person's problem type without their permission.

dret commented 2 years ago

On 2022-04-18 12:53, Mark Nottingham wrote:

To add an extension to a problem type, right now you need to control the type itself; you can't define an extension for another person's problem type without their permission.

i think that's slightly overselling the current state. types are one thing, extension members a different one. RFC 7807 vaguely hints at "types defining members", but there is no namespacing or scoping, so in the end these two things are independent.

imho, everybody can define extension members for whatever they like, and there is no mechanism to avoid or even detect conflicts with others defining an identically named extension either standalone or as part of a new type they've defined. maybe that's not ideal, but that's what we have in the current spec.

mnot commented 2 years ago

Problem type definitions MAY extend the problem details object with additional members.

mnot commented 2 years ago

Note that because extensions are effectively put into a namespace by the problem type, it is not possible to define new "standard" members without defining a new media type.

olijaun commented 2 years ago

Problem type definitions MAY extend the problem details object with additional members.

Ok, thanks @mnot. This statement in addition to your statement about "control of the type" makes it clear to me. I'm not controlling the problem type "about:blank" definition (it's controlled by the RFC) so I cannot add additional members to "about:blank" but I can add them to my own problem types.