mnot
commented
2 years ago This has been discussed as part of a few other issues, but it's good to separate it out into an explicit one.
I think you're in the ballpark here -- to allow new standard extensions (i.e., those not in the original spec and not explicitly nominated by the type in use), we have two choices:
- Find a naming convention that doesn't conflict with existing usage (e.g., a prefix)
- Mint a new media type
(1) is hard, because we don't and can't know the extent of existing usage. However, we might be able to create a convention that's extremely unlikely to conflict with existing usage, advertise it widely, and make sure there's a transition period before it's actually used. If we do all that, the risks could be low enough to be acceptable.
(2) is certainly possible, but when we've discussed this in the past, the concern has been that it would further fragment usage.
There is a third option. We can define conventions that individual types opt into, saving them the work of defining the mechanism. For things like problem-pointer (or whatever it becomes), that might be enough.
dret
awwright
(In reply to #32, which I think is blocked by this issue.)
I would call this specification "forward compatible" if we can add new features to it without interfering with existing compliant implementations. This is important so that standards can evolve to support new functionality, like proposed in #32.
It does not appear to me that there's any mechanism for forward compatibility, and this is noted:
While the media type can be "extended" in some fashion, this is not the same as forward compatibility, because all extensions are by definition user extensions, so they cannot be standardized. I.e. there is no way to define new "global" members.
I think this is important to fix. I see a few options:
(1) Note how the concept of "user" extensions has some amount of ambiguity. In order to know what a non-standard member means, you have to know who issued the Problem document. But there's no standard way to encode this! (It does say the type is "effectively" a namespace for extensions, but this doesn't seem like particularly authoritative language.) Applications that are tightly coupled with a specific API may not have trouble consuming user extensions, but other user-agents (e.g. spiders) may have a problem deciphering them. Because of this, I think we could more rigorously specify the behavior without significant breakage "in the wild". For example, specify that extension members must use a URI, and all other members have a standard definition. Or, choose some prefix that sorts high in ASCII, like
!or$, to indicate standard "global" members.(2) If this still causes too much breakage, we could either reserve the member names that would cause breakage, or I would support minting a new media type.
We could also consider defining a JSON-LD vocabulary. There's likely a good way to encode the problem details that's easily detectable as a document describing the error, and having a standardized form and properties, while also being easily extensible for specific types of problems/errors.