Julian et al,
It's probably worth taking a look at
draft-johnston-addressing-link-relations<http://tools.ietf.org/html/draft-johnston-addressing-link-relations-00>as
well as it defines both "current" and "latest" as well as "canonical",
"immutable", "mirror", "permalink" and my favourite, "shortlink". This has
been adopted by Wordpress, Drupal & others with a view to bringing an end to
third-party URL shortening services (the rust of the Internet).
While I support link relations for versioning, I'd prefer to see relations
for generic addressing requirements consolidated in one draft.
Sam
A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> Title : Link Relations for Addressing
Author(s) : S. Johnston
Filename : draft-johnston-addressing-link-relations-00.txt
Pages : 7
Date : 2009-09-20
> This specification defines link relations for a number of common
styles of resource addressing (for example, linking to the latest vs
a specific version of a resource).
> A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-johnston-addressing-link-relations-00.txt
> Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
> Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<
> ftp://ftp.ietf.org/internet-drafts/draft-johnston-addressing-link-relations-00.txt
> >
canonical Designates the preferred or standard way of writing the
URL, or the "canonical form" (also known as "standard form" or
"normal form"). While there can be an infinite number of
references to identical or vastly similar resources (for example
with different sort orders, highlighting or category information),
specifying which one is "canonical" allows automated agents to
avoid treating every such URL as unique. Search engines may use
this to consolidate properties such as link popularity and display
the preferred URL in search results, while other clients may
identify, save and share the preferred version rather than the one
they originally retrieved.
current Identifies resource(s) which are occuring in or belonging to
the present time, but may not necessarily be the single most
recent or "latest" version specifically. For example an entry or
page of a feed may identify the most recent entries in that feed
using the "current" relation.
immutable Refers to an immutable version of the link's context that
is not subject or susceptible to change or variation. This may
refer to a read-only resource, an archived copy of an otherwise
dynamic resource, a specific version in a version control system,
etc. This is in contrast to links which return the latest version
of the resource at any given time.
latest Refers to the single most recent version of the link's
context, which may be updated at any time. As most URLs return
the most recent version of the resource this relation is most
useful with version control systems. For example, older versions
of the resource may refer to the latest version.
mirror Provides a rudimentary facility to specify one or more
identical mirrors from which clients can obtain a resource. For
example a large enclosure may be available for download from a
number of different servers in different geographical locations in
order to distribute server load, reduce network load and improve
availability and performance. Link extensions for indicating
geographical location, slots, bandwidth, preference, etc. may be
defined in a future Internet-Draft.
permalink Designates an immutable URL which is not subject or
susceptible to change or variation even if the resource itself is
updated. A portmanteau of "permanent" and "link", the relation
allows clients to save and share a URL with the guarantee that it
will resolve to that resource so long as it still exists.
Typically the more information that is included in a link the more
volatile it is likely to be. For example a link to a blog post
that includes the title may change whenever the title is updated.
Where "permalink" is specified such changes must not cause the
designated URL to stop resolving or to resolve to another
resource.
Note: It is inappropriate to use the "bookmark" relation for this
as it is "used to provide direct links to key entry points into an
extended document" rather than as a reference to the resource
itself.
shortlink Designates one or more short link(s) which may be used in
artificially (e.g. microblogging) or technically (e.g. short
message service) constrained channels, or anywhere humans are
required to transcribe a link (e.g. print, television and radio).
This obviates the need to resort to third-party URL shortening
services by allowing webmasters to centrally specify preferred
short link(s) for use by all clients. For performance and
security reasons the domain should match that of the canonical
URL, unless a shorter domain is required/desired. Where more than
one is specified the client may select one at random, offer the
choice to the user, select the first, last or shortest one at
random, or intelligently determine which is the most suitable for
the purpose (for example, one with an alphabetical rather than
numerical path).
On Tue, Nov 24, 2009 at 11:54 AM, Julian Reschke <[email protected]>wrote:
>
> Hi Jan,
>
> first of all thanks for the feedback!
>
>
> Jan Algermissen wrote:
>
>> Julian,
>>
>> some comments on the link relation draft:
>>
>> > 2. Terminology
>
>>
>> It is not clear to me, what the meaning of 'check out' and 'check in'.
>>
>
> Yes, we need to add text here. We originally started with the definitions
> with RFC 3253 (WebDAV versioning), but later on decided later on to just
> rely on generic definitions to make this work better with CMIS and JCR.
>
>
> Also, the text (IMO) creates the impression that versioning can only take
>> place when 'check out' and 'check in' are applied. However, a resource could
>> also be versioned by the server upon any modification made by a client
>> regardless of any 'checking out' or 'checking in'. The link relations
>> specified would still make sense.
>>
>
> Indeed; and that's something that can even happen in WebDAV versioning
> (through the various modes of auto-versioning).
>
>
> Assuming that 'checking out' and 'checking in' are operations on
>> resources, I think the draft should address how clients achieve these
>> operations. This would at least involve another link relation and
>> specification how to use the linked resource to perform a checkout.
>>
>
> These kinds of operations are specific to the protocol in which they are
> used, while the link relations are meant to be generic; thus I'd avoid to go
> that way.
>
> For now, I've added this to the issues list: <
> http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-issues.html#issue.checked-out>.
> I'll try to make a change proposal soonish.
>
>
> Or am I misunderstanding what the draft is trying to do?
>>
>> Appendix A
>>
>> It should be 'working-copy' instead of 'working-resource'.
>>
>
> Indeed. Thanks for catching this.
>
>
> I am glad to see this happening. Covers a lot of stuff that comes up in
>> almost every project. Thanks.
>>
>
> That's good to hear, because defining generic link relations doesn't make
> sense unless there are generic use cases for them :-)
>
> Best regards, Julian
>
>
