Add a before-sunset link relation type

[ibnesayeed]

While the sunset link relation type allows us to convey what would be the upcoming URI of the current resource (or the resource explicitly provided as the context using the anchor attribute), there is no way to establish a backlink. A way to advertise URIs where the resources was made available earlier would be helpful in fixing search and archival indexes and bookmarks after the migration is over and previous URI is not resolvable anymore. I propose before-sunset link relation with sunset-datetime attribute, but we can discuss better names. While there is a potential of misuse by maliciously claiming someone else's resources belonged to us in the past, it is not a big issue as it is suggestive in nature and not necessarily enforced in anyway. However, in situations where the relationship can be verified bidirectionally (with the help of a Memento RFC7089), it becomes trustworthy claim.

For example, when a resource is accessed at a new URI at https://example.com/foo after DATE1, acknowledging that the resource used to be available at https://example.org/bar before DATE1:

> GET https://example.com/foo

< Link: <https://example.org/bar>; rel="before-sunset"; sunset-datetime="DATE1"

Alternatively, a more flexible method would be to define a couple of attributes (e.g., sunset-datetime and sunrise-datetime) in the before-sunset link relation type to convey time ranges when the resource was available on a different URI. Here is an examples:

When accessing https://example.com/foo after DATE1, acknowledging that the resource used to be available at https://example.org/bar before DATE1 and at https://example.net/baz between DATE2 and DATE3 (here DATE1 being the latest and DATE3 being the earliest in the past):

> GET https://example.com/foo

< Link: <https://example.org/bar>; rel="before-sunset"; sunset-datetime="DATE1"; sunrise-datetime="DATE2", <https://example.net/baz>; rel="before-sunset"; sunset-datetime="DATE2"; sunrise-datetime="DATE3"

Noting that these two datetime fields will be optional.

I find Sunset header (and the corresponding link relation type) to be very attractive and interesting for the Web Archiving community in more than one ways as I tweeted earlier https://twitter.com/ibnesayeed/status/1019744272826929155.

[dret]

On 2018-10-26 20:45, Sawood Alam wrote:

While the |sunset| link relation type allows us to convey what would be the upcoming URI of the current resource (or the resource explicitly provided as the context using the |anchor| attribute), there is no way to establish a backlink. A way to advertise URIs where the resources was made available earlier would be helpful in fixing search and archival indexes and bookmarks after the migration is over and previous URI is not resolvable anymore. I propose |before-sunset| link relation with |sunset-datetime| attribute, but we can discuss better names. While there is a potential of misuse by maliciously claiming someone else's resources belonged to us in the past, it is not a big issue as it is suggestive in nature and not necessarily enforced in anyway. However, in situations where the relationship can be verified bidirectionally (with the help of a Memento RFC7089 https://tools.ietf.org/html/rfc7089), it becomes trustworthy claim.

For example, when a resource is accessed at a new URI at |https://example.com/foo| after |DATE1|, acknowledging that the resource used to be available at |https://example.org/bar| before |DATE1|:

GET https://example.com/foo

< Link: https://example.org/bar; rel="before-sunset"; sunset-datetime="DATE1"

Alternatively, a more flexible method would be to define a couple of attributes (e.g., |sunset-datetime| and |sunrise-datetime|) in the |before-sunset| link relation type to convey time ranges when the resource was available on a different URI. Here is an examples:

When accessing |https://example.com/foo| after |DATE1|, acknowledging that the resource used to be available at |https://example.org/bar| before |DATE1| and at |https://example.net/baz| between |DATE2| and |DATE3| (here |DATE1| being the latest and |DATE3| being the earliest in the past):

GET https://example.com/foo

< Link: https://example.org/bar; rel="before-sunset"; sunset-datetime="DATE1"; sunrise-datetime="DATE2", https://example.org/bar; rel="before-sunset"; sunset-datetime="DATE2"; sunrise-datetime="DATE3"

I find |Sunset| header (and the corresponding link relation type) to be very attractive and interesting for the Web Archiving community in more than one ways as I tweeted earlier https://twitter.com/ibnesayeed/status/1019744272826929155.

thanks for the feedback and the suggestions. it seems that what you are proposing here is quite a bit more sophisticated and complex than what the draft currently does.

the goal for this draft has been to be able to announce sunsets, and that's really all there is to it. it seems to me that you are going deep into the question of how to manage resources, which to me is a different thing.

here's a suggestion: let's keep those two aspects (announcements vs management) separate, and the current draft as simple as it is. i'd be more than happy to help/comment/contribute to a new one that would be based on sunset, but address the scenarios you have in mind.

i also had some ideas along the way about what could possibly be added to the draft, but it never seemed like that was a concrete requirement for people. in case you're interested, feel free to explore the open issues, and you might find some ideas similar to the ones you're suggesting:

https://github.com/dret/I-D/issues?q=is%3Aissue+is%3Aopen+label%3Asunset-header

[dret]

getting close to closing this in favor of getting the RFC published without additional complications. anybody objecting make concrete suggestions now, or forever stay silent!

[ibnesayeed]

Sorry @dret, I somehow missed the email notification when you replied earlier. In favor of keeping this draft simple and limited in scope I would go with your points. I will give some more thoughts on how to expand on the foundation of the sunset to communicate historical URI versions of a resource in a separate draft. I can already see some interesting use cases in the web archiving community.

[dret]

On 2018-11-15 15:15, Sawood Alam wrote:

Sorry @dret https://github.com/dret, I somehow missed the email notification when you replied earlier. In favor of keeping this draft simple and limited in scope I would go with your points. I will give some more thoughts on how to expand on the foundation of the sunset to communicate historical URI versions of a resource in a separate draft. I can already see some interesting use cases in the web archiving community.

sounds good, and thanks for the quick response. i'll go ahead and close the issue, then.

if you do write up something new, i'd definitely be interested to see it and maybe to contribute. there definitely is room for more complex models that the simple of proposed by the sunset draft. i think checking back with @hvdsomp would be great to get his feedback and input, he is extremely experienced in the field of archiving.

[ibnesayeed]

I had a brief conversation with @phonedude about it a couple weeks ago, but didn't get a chance to discuss it with @hvdsomp yet. Memento framework provided a way to link past versions of a resource as long as they have the same original URI (or URI-R), but often times those URI-Rs change (beyond URI canonicalization scope) and leave no easy way to trace back. I think @martinklein0815 will also be interested in formalizing a way to establish historical version association among multiple different URI-Rs.

[dret]

On 2018-11-15 18:26, Sawood Alam wrote:

I had a brief conversation with @phonedude https://github.com/phonedude about it a couple weeks ago, but didn't get a chance to discuss it with @hvdsomp https://github.com/hvdsomp yet. Memento framework provided a way to link past versions of a resource as long as they have the same original URI (or URI-R), but often times those URI-Rs change (beyond URI canonicalization scope) and leave no easy way to trace back. I think @martinklein0815 https://github.com/martinklein0815 will also be interested in formalizing a way to establish historical version association among multiple different URI-Rs.

you're right that while there is some overlap, there also may be different scenarios at play here. memento assumes you're versioning one resource (afaict), and how to navigate the history of various versions that may be available. sunset assumes that a resource (versioned or not, that's not something sunset is concerned with) goes "out of business" and wants to announce this in advance. looking at it from that angle, it almost seems like these things complement each other nicely, without having much overlap at all. i am really wondering what @hvdsomp's take on all of this is.

[hvdsomp]

I think @ibnesayeed makes an interesting point. He is in effect suggesting a way to express provenance of a resource, i.e. if a resource known to be accessible at URI-A at one point moves to URI-B, then URI-B could express that it used to be known as URI-A. The intended semantic is "previously known as" and it seems that it is the inverse relationship as "sunset": URI-A points with a "sunset" rel to URI-B to give a heads up that it is about to change URI. And once changed, URI-B points with a "previously known as" rel to URI-A. Seems to me that both rels could logically fit in a same I-D/RFC.

Note that the intended "previously known as" rel is different than the "original" rel from the Memento framework because original points from a version resource (in web archive or version control system) to the time generic resource. It is a relation that plays in time domain. The "previously known as" rel plays in the location/identification domain.

[dret]

On 2018-11-16 14:50, Herbert Van de Sompel wrote:

I think @ibnesayeed https://github.com/ibnesayeed makes an interesting point. He is in effect suggesting a way to express provenance of a resource, i.e. if a resource known to be accessible at URI-A at one point moves to URI-B, then URI-B could express that it used to be known as URI-A. The intended semantic is "previously known as" and it seems that it is the inverse relationship as "sunset": URI-A points with a "sunset" rel to URI-B to give a heads up that it is about to change URI. And once changed, URI-B points with a "previously known as" rel to URI-A. Seems to me that both rels could logically fit in a same I-D/RFC.

these are interesting thoughts, but that's not how sunset is currently defined. currently, the scenario is that a resource simply goes out of business. it may be resurrected someplace else, but that's out of scope. the sunset link relation does not link to a new version of the resource. it links "to a resource providing information about a resource's or service's retirement policy and/or information."

i still think that this richer model of interlinking resource migrations may be interesting, but it seems to be a rather different (and decidedly more complex) beast. i'd be interested to have a closer look, but i think it is different from what the current draft is targeting.

[ibnesayeed]

the sunset link relation does not link to a new version of the resource. it links "to a resource providing information about a resource's or service's retirement policy and/or information."

Thanks for pointing this out. I think my own suggestion was echoing in my head.