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.
| Identifier | Type / Status | Reference and Description | Proposed Resolution / Latest Change |
|---|
| Identifier | Type / Status | Reference and Description | Resolution / Latest Change |
|---|---|---|---|
| auth48 |
edit closed |
julian.reschke@greenbytes.de, 2010-03-26: Umbrella issue for changes made during the RFC Editor's AUTH48 period. | in revision latest: |
| checked-out |
change closed |
Reference: <http://www.imc.org/atom-syntax/mail-archive/msg21321.html> algermissen1971@mac.com, 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. |
| cmis |
edit closed |
julian.reschke@greenbytes.de, 2009-12-01: Add a pointer to the CMIS spec, so AtomPub use cases become clearer. | in revision 04: Done. |
| edit |
edit closed |
julian.reschke@greenbytes.de, 2009-11-19: Umbrella issue for editorial fixes/enhancements. | in revision latest: |
| expose-urls |
change closed |
ekr@networkresonance.com, 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.,
http://example.com/versions/filename/_@line_50_+_FOO;@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. |
| iana |
change closed |
julian.reschke@greenbytes.de, 2009-11-20: Use proper IANA registration template. | in revision 03: |
| terseness |
edit closed |
lars.eggert@nokia.com, 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: Done. |
| working-copy-of |
change closed |
Reference: <http://www.imc.org/atom-syntax/mail-archive/msg21350.html> algermissen1971@mac.com, 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 | || |
| 02 | |
| 01 | |
| 00 |
Last change: 2010-03-26