Mark Nottingham wrote:
I do believe that a "last" link relation would be helpful for
completeness and I do believe the use cases are there (e.g. search
results, etc) but I am ok with dropping that for now as it can
easily be defined later once the use cases do become more prominent.
Over the next week I'll see if I can draft up the spec. I'll use
what MarkP put together as the basis for what I write up and submit.
We actually don't need a spec, according to -11; we just need to send
an e-mail to IANA requesting the registrations, and get IESG
approval. Assuming we can come to WG consensus, that should be easy.
Yeah, I know we don't *need* a spec; having a spec is my personal bias
towards having a clear description about how things are defined and how
they are to be used. In this case, it may not matter much. So I'm
perfectly fine with the email to IANA approach.
I took a look at doing this over the weekend, and this is what I came
up with;
- Attribute Value: prev
- Description: A stable URI that, when dereferenced, returns a feed
document containing entries that sequentially precede those in the
current document. Note that the exact nature of the ordering between
the entries and documents containing them is not defined by this
relation; i.e., this relation is only relative.
- Expected display characteristics: Undefined.
- Security considerations: Because automated agents may follow this
link relation to construct a 'virtual' feed, care should be taken
when it crosses administrative domains (e.g., the URI has a different
authority than the current document).
+1. An additional security concern would be the potential for circular
references
- Attribute Value: next
- Description: A stable URI that, when dereferenced, returns a feed
document containing entries that sequentially follow those in the
current document. Note that the exact nature of the ordering between
the entries and documents containing them is not defined by this
relation; i.e., this relation is only relative.
- Expected display characteristics: Undefined.
- Security considerations: Because automated agents may follow this
link relation to construct a 'virtual' feed, care should be taken
when it crosses administrative domains (e.g., the URI has a different
authority than the current document).
+1
- Attribute Value: first
- Description: A stable URI that, when dereferenced, returns a feed
document containing those entries furthest preceding those in the
current document at the time it was minted. Note that the exact
nature of the ordering between the entries and documents containing
them is not defined by this relation; i.e., this relation is only
relative.
- Expected display characteristics:
- Security considerations:
+1
- Attribute Value: last
- Description: A stable URI that, when dereferenced, returns a feed
document containing those entries furthest following those in the
current document at the time it was minted. Note that the exact
nature of the ordering between the entries and documents containing
them is not defined by this relation; i.e., this relation is only
relative.
- Expected display characteristics: Undefined.
- Security considerations:
+1
- Attribute Value: subscribe
- Description: A stable URI that, when dereferenced, returns a feed
document containing the most recent entries in the feed. This URI is
intended to be subscribed to to keep abreast of changes in the feed.
When different from the URI of the feed document it exists in, it
indicates a URi that should be used for this purpose in place of the
current document's URI.
- Expected display characteristics: Undefined.
- Security considerations: Users should always be informed of the
actual URI they are subscribing to, and subscription should only take
place when it is explicitly requested.
+1
- James
