search

ietf-wg-httpapi / rfc7807bis

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

Clarifying extension member scoping #43

Closed dret closed 2 years ago

dret commented 2 years ago

Following the discussion in #40 made me think that we could tighten the language around extension member scope.

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.

"Effectively" seems a bit odd here. Are they put into a namespace or not? If they do, then processing rules follow that we may want to spell out:

Because extension members are put into a namespace by the problem type, extension members MUST only be processed when they occur for a problem type that the consumer is expecting. If an extension member is recognized by its name but in the context of a problem type that the consumer is not expecting for that member, then the extension member MUST be ignored. In addition, because extension members are put into a namespace by the problem type, it is not possible to define new "standard" members (i.e., members that can be used with any problem type) without defining a new media type.

Maybe that's not good wording, but it seems to me that the current wording may be a little too vague.

dret commented 2 years ago

I just realized that my above text clashes with https://github.com/ietf-wg-httpapi/rfc7807bis/pull/41 but once that one is merged I can come up with a suggestion that works with the updated draft text.

mnot commented 2 years ago

I don't think adding new requirements here is a good idea. I've tweaked a bit to make things clearer.

dret commented 2 years ago

this proposal wasn't meant as adding new requirements, but as clarifying rules that may have been implicit before. thanks for the tweaks.