this is mostly a topic for those looking for terminological clarity. the issue is that RFC 5988bis defines the concept of target attributes, but strictly speaking does not define any. the well-defined ones are just defined for the link header serialization (see https://github.com/mnot/I-D/issues/240 for context). strictly speaking we are now defining JSON serializations for the "serialization defined attributes" of RFC 5988bis, which is assume is fine (though i find it slightly odd that the attributes defined by RFC 5988bis are not defined for the link model as such, but just for the specific header serialization).
what may be worth to write down is the fact that our model of representing extension attributes/parameters (as suggested in #77) now is completely based on them being defined for the native syntax. there is nothing wrong with that, in fact it may be a feature, but maybe there is one important point to this:
we might want to explicitly disallow that somebody defines a specific JSON representation for their link parameters. because if they did, that would render or schema-agnostic model unworkable. maybe this is overly careful, but it may be worth adding as a specific warning for those who might dislike our generic model, and are thinking about alternative ways how they can represent their links and specific link parameters in JSON.
dret
commented
4 years ago
this is mostly a topic for those looking for terminological clarity. the issue is that RFC 5988bis defines the concept of target attributes, but strictly speaking does not define any. the well-defined ones are just defined for the link header serialization (see https://github.com/mnot/I-D/issues/240 for context). strictly speaking we are now defining JSON serializations for the "serialization defined attributes" of RFC 5988bis, which is assume is fine (though i find it slightly odd that the attributes defined by RFC 5988bis are not defined for the link model as such, but just for the specific header serialization). what may be worth to write down is the fact that our model of representing extension attributes/parameters (as suggested in #77) now is completely based on them being defined for the native syntax. there is nothing wrong with that, in fact it may be a feature, but maybe there is one important point to this: we might want to explicitly disallow that somebody defines a specific JSON representation for their link parameters. because if they did, that would render or schema-agnostic model unworkable. maybe this is overly careful, but it may be worth adding as a specific warning for those who might dislike our generic model, and are thinking about alternative ways how they can represent their links and specific link parameters in JSON.