> On 29 Oct 2021, at 3:37 am, Michael Douglass <mikeadouglass@xxxxxxxxx> wrote: > >> Two alternative paths forward would address this concern: >> >> 1) Define this as a serialisation of 8288 links >> 2) Use a separate registry > A third path might be to specify how it differs while trying to come closer to 1. > > I think having 2 registries defining essentially the same concept would be more confusing and lead to more misalignments. At least this way we only define it once. > > I accept the point on context and attributes. I think we can deal with that - e.g. context is the referencing entity and define a mapping of existing parameters to the 8288 defined attributes (e.g. "title"->"label") That sounds like you're defining a serialisation of 8288 links. > RFC 8288 in Appendix A specifies how it differs from 2 other linking methods. That's noting how different _serialisations_ work -- they are different ways to express the same data model. Another question to ask is whether it makes sense for the link types currently registered to show up here, and vice versa (whether the ones you propose to register make sense in HTML, Atom, Link headers, etc.). That might help guide the answer. Cheers, -- Mark Nottingham https://www.mnot.net/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
