On 10/29/21 20:39, Mark Nottingham wrote:
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.
It probably ended up that way. I think it's pretty close as it stands
but not explicit. I'll add some text to specify how iCalendar parameters
map on to link header attributes - if there is a mapping - e.g. LABEL
<-> title and that specifications that wish to use LINK types with
attributes specify how to map paramaters
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.
I've not done an exhaustive search through but at the very least
privacy-policy and terms-of-service would satisfy a need that was
expressed some time ago for published events. copyright, edit,
edit-form, license, payment all look useful.
And all the interval... link types look more properly like calendaring
relations
Cheers,
--
Mark Nottingham https://www.mnot.net/
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
