Link Relation Types for Simple Version Navigation between Web Resources


The identifier is a name for the issue (and is unique within this document).

The type of issue is one of:

The status of the issue is one of:

The reference is an indication of where the issue was first raised.

The description is a succinct overview of the issue.

The resolution describes the specification change that resolves the issue.

Open Issues

Identifier Type / Status Reference and Description Proposed Resolution / Latest Change

Closed/Editor Issues

Identifier Type / Status Reference and Description Resolution / Latest Change
closed, 2010-03-26: Umbrella issue for changes made during the RFC Editor's AUTH48 period. in revision latest:
Reference: <>, 2009-11-24: 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.
in revision 04:
Rephrased terminology; added explanations for checkin/checkout.
closed, 2009-12-01: Add a pointer to the CMIS spec, so AtomPub use cases become clearer. in revision 04:
closed, 2009-11-19: Umbrella issue for editorial fixes/enhancements. in revision latest:
closed, 2010-01-03: In general this mechanism seems sound but I'm not sure that the security considerations are entirely adequate. This mechanism lets you learn information about other versions of a resource even if you potentially don't have permission to view them directly. Consider a limiting case where each version of the resource had a name that contained the change set for that resource. E.g.,;@line_60_+_BAR/;
In this case, seeing other parts of the version tree leaks information about those versions. I don't think that this is a problem for the draft, but it might be useful to mention that this feature has implications for name construction.
in revision 06:
Add that consideration.
closed, 2009-11-20: Use proper IANA registration template. in revision 03:
closed, 2010-01-19: I'd be good to mention ATOM somewhere in the title. Also, both the abstract and the introduction are extremely terse, to the point where it's hard to understand what technologies/protocols this applies to. in revision 07:
Reference: <>, 2009-12-02: ...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.
in revision 05:


Version Issues
latest ||||||||
07 |||||||
06 ||||||
05 |||||
04 |||||
03 ||

Last change: 2010-03-26