This specification defines Atom link relations for navigation between a resource and its versions.¶
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.¶
This Internet-Draft will expire on June 7, 2010.¶
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.¶
|I edit (type: edit, status: open)|
|email@example.com||2009-11-19||Umbrella issue for editorial fixes/enhancements.|
|Associated changes in this document: <#rfc.change.edit.1>, 2, <#rfc.change.edit.3>, A, <#rfc.change.edit.5>, B.|
|I cmis (type: edit, status: closed)|
|firstname.lastname@example.org||2009-12-01||Add a pointer to the CMIS spec, so AtomPub use cases become clearer.|
|Associated changes in this document: 1, 7.2, 7.2.|
This specification defines link relations that may be used on a resource that exists in a system that supports versioning to navigate among the different resources available, such as past versions.¶
|I checked-out (type: change, status: closed)|
It is not clear to me, what the meaning of 'check out' and 'check in'. 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.
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.
|2009-12-04||Resolution: Rephrased terminology; added explanations for checkin/checkout.|
|Associated changes in this document: 2, 2.|
Versioned Resource ¶
Version History ¶
Predecessor, Successor ¶
|I working-copy-of (type: change, status: open)|
...what is your opinion regarding the introduction of a link relation that is the opposite of working-copy in order to being able to find the versioned resource that the working copy I have is a working copy of?
I am undecided regarding the necessity, but without a working-copy-of relation it seems the client would need to maintain that information (the relationship or the fact that a given resource is a working copy) across requests.
|Associated changes in this document: 3, 4, A.|
Automated agents should take care when these relation crosses administrative domains (e.g., the URI has a different authority than the current document). Such agents should also take care to detect circular references.¶
The content and concepts within are a product of the Content Management Interoperability Services (CMIS) Technical Committee (TC) at OASIS.
All members of the TC have contributed.