Re: Comments on Action:draft-brown-versioning-link-relations-03

[Sam Johnston <[e-mail]>]

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 <[e-mail]>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
>
>