tag:old.nabble.com,2006:forum-11669Nabble - w3.org - w3c-dist-auth2009-12-15T00:06:49Ztag:old.nabble.com,2006:post-26791110Re: Last Call: draft-brown-versioning-link-relations (Link Relations for Simple Version Navigation) to Informational RFC2009-12-15T00:06:49Z2009-12-15T00:06:49ZJulian Reschke(FYI)
<br><br>The IESG wrote:
<div class='shrinkable-quote'><br>> The IESG has received a request from an individual submitter to consider
<br>> the following document:
<br>>
<br>> - 'Link Relations for Simple Version Navigation '
<br>> <draft-brown-versioning-link-relations-05.txt> as an Informational RFC
<br>>
<br>> The IESG plans to make a decision in the next few weeks, and solicits
<br>> final comments on this action. Please send substantive comments to the
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26791110&i=0" target="_top" rel="nofollow">ietf@...</a> mailing lists by 2010-01-11. Exceptionally,
<br>> comments may be sent to <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26791110&i=1" target="_top" rel="nofollow">iesg@...</a> instead. In either case, please
<br>> retain the beginning of the Subject line to allow automated sorting.
<br>>
<br>> The file can be obtained via
<br>> <a href="http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-05.txt" target="_top" rel="nofollow">http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-05.txt</a><br>>
<br>>
<br>> IESG discussion can be tracked via
<br>> <a href="https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18658&rfc_flag=0" target="_top" rel="nofollow">https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18658&rfc_flag=0</a><br>>
<br>> _______________________________________________
<br>> IETF-Announce mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26791110&i=2" target="_top" rel="nofollow">IETF-Announce@...</a>
<br>> <a href="https://www.ietf.org/mailman/listinfo/ietf-announce" target="_top" rel="nofollow">https://www.ietf.org/mailman/listinfo/ietf-announce</a><br>>
</div><br><br>tag:old.nabble.com,2006:post-26774830Re: bind issue: locking22009-12-14T01:10:23Z2009-12-14T01:10:23ZJulian ReschkeWerner Donné wrote:
<div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> In RFC4918 the phrase "The resource identified in the Request-URI becomes the root of the lock." of section 9.10.1 seems to be wrong to me. It could be just "The Request-URI becomes the root of the lock." The definition of the "lockroot" element, which says "Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request." confirms that section 6.1 point 2 is correct.
<br>>
<br>> As far as I understand it, in HTTP a resource is an opaque thing that is not specified as such. HTTP and related specifications are about representing a resource and interacting with it, not about a resource itself. The URI-specification is about addressing a resource, implying an URI is not the same thing as the resource it addresses. A resource is an undefined concept and can therefore not be the root of a lock. I would think that RFC4918 did not introduce the confusion intentionally, because the alternative server behaviour would simply be invalid.
<br>>
<br>> Since there is an error in RFC4918, which will be corrected at some point, you can also just refer to section 6.1 point 2 without even mentioning section 9.10.1. If you make use of the definition of lock-root in an explicit way, then there will be no ambiguity and the text can remain the same whenever the successor of RFC4918 comes out.
<br>>
<br>> Best regards,
<br>>
<br>> Werner.
<br>> ...
</div><br>Hi Werner,
<br><br>it appears you are agreeing with what the published BIND specs say, and
<br>what I have reported as erratum for RFC 4918 in
<br><<a href="http://www.rfc-editor.org/errata_search.php?eid=1207" target="_top" rel="nofollow">http://www.rfc-editor.org/errata_search.php?eid=1207</a>>. That's good to
<br>know, but I have failed to convince the author and the chairs about this
<br>back before publication of RFC 4918, and also failed to convince the
<br>IESG later on.
<br><br>Thus the revised proposal that just states that RFC 4918 is ambiguous,
<br>and that servers that want to support BIND need to follow a more
<br>specific definition.
<br><br>Best regards, Julian
<br><br><br><br>tag:old.nabble.com,2006:post-26774687Re: bind issue: locking22009-12-14T00:58:20Z2009-12-14T00:58:20ZWerner DonnéHi,
<br><br>In RFC4918 the phrase "The resource identified in the Request-URI becomes the root of the lock." of section 9.10.1 seems to be wrong to me. It could be just "The Request-URI becomes the root of the lock." The definition of the "lockroot" element, which says "Contains the root URL of the lock, which is the URL through which the resource was addressed in the LOCK request." confirms that section 6.1 point 2 is correct.
<br><br>As far as I understand it, in HTTP a resource is an opaque thing that is not specified as such. HTTP and related specifications are about representing a resource and interacting with it, not about a resource itself. The URI-specification is about addressing a resource, implying an URI is not the same thing as the resource it addresses. A resource is an undefined concept and can therefore not be the root of a lock. I would think that RFC4918 did not introduce the confusion intentionally, because the alternative server behaviour would simply be invalid.
<br><br>Since there is an error in RFC4918, which will be corrected at some point, you can also just refer to section 6.1 point 2 without even mentioning section 9.10.1. If you make use of the definition of lock-root in an explicit way, then there will be no ambiguity and the text can remain the same whenever the successor of RFC4918 comes out.
<br><br>Best regards,
<br><br>Werner.
<br><br>On 13 Dec 2009, at 16:43, Julian Reschke wrote:
<br><div class='shrinkable-quote'><br>> Julian Reschke wrote:
<br>>> ...
<br>>> 3) locking2 (<<a href="http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.locking2" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.locking2</a>>) ...
<br>>
<br>> This is the issue we've been discussing over and over again in the past months. It's about whether the vagueness in RFC 4918 about the "lock root" actually is a bug (thus could be fixed with an erratum), or is intentional, allowing different ways to interpret the requirements, and thus differing server behavior.
<br>>
<br>> I haven't been able to convince enough people that this is an RFC 4918 problem that should be fixed, thus the new strategy to address is is to simply state the problem, and specify which interpretation a WebDAV BIND implementation needs to follow.
<br>>
<br>> Consequently, the section about locking was upgraded from an appendix to a regular spec section, and now reads:
<br>>
<br>> -- snip --
<br>> 9. Relationship to Locking in WebDAV
<br>>
<br>> Locking is an optional feature of WebDAV ([RFC4918]). The base
<br>> WebDAV specification and this protocol extension have been designed
<br>> in parallel, making sure that all features of WebDAV can be
<br>> implemented on a server that implements this protocol as well.
<br>>
<br>> Unfortunately, WebDAV uses the term "lock-root" inconsistently. It
<br>> is introduced in Section 6.1 of [RFC4918], point 2, as:
<br>>
<br>> 2. A resource becomes directly locked when a LOCK request to a
<br>> URL of that resource creates a new lock. The "lock-root" of the
<br>> new lock is that URL. If at the time of the request, the URL is
<br>> not mapped to a resource, a new empty resource is created and
<br>> directly locked.
<br>>
<br>> On the other hand, [RFC4918], Section 9.10.1 states:
<br>>
<br>> A LOCK request to an existing resource will create a lock on the
<br>> resource identified by the Request-URI, provided the resource is
<br>> not already locked with a conflicting lock. The resource
<br>> identified in the Request-URI becomes the root of the lock.
<br>>
<br>> Servers that implement both WebDAV locking and support for multiple
<br>> bindings MUST use the first interpretation: the lock-root is the URI
<br>> through which the lock was created, not a resource. This URI, and
<br>> potential aliases of this URI ([RFC4918], Section 5), are said to be
<br>> "protected" by the lock.
<br>>
<br>> As defined in the introduction to Section 7 of [RFC4918], write
<br>> operations that modify the state of a locked resource require that
<br>> the lock token is submitted with the request. Consistent with
<br>> WebDAV, the state of the resource consists of the content ("any
<br>> variant"), dead properties, lockable live properties (item 1), plus,
<br>> for a collection, all its bindings (item 2). Note that this, by
<br>> definition, does not depend on the request URI to which the write
<br>> operation is applied (the locked state is a property of the resource,
<br>> not its URI).
<br>>
<br>> However, the lock root is the URI through which the lock was
<br>> requested. Thus, the protection defined in item 3 of the list does
<br>> not apply to additional URIs that may be mapped to the same resource
<br>> due to the existence of multiple bindings.
<br>>
<br>> 9.1. Example: Locking and Multiple Bindings
<br>>
<br>> Consider a root collection "/", containing the two collections C1 and
<br>> C2, named "/CollX" and "/CollY", and a child resource R, bound to C1
<br>> as "/CollX/test" and bound to C2 as "/CollY/test":
<br>>
<br>> +-------------------------+
<br>> | Root Collection |
<br>> | bindings: |
<br>> | CollX CollY |
<br>> +-------------------------+
<br>> | |
<br>> | |
<br>> | |
<br>> +---------------+ +---------------+
<br>> | Collection C1 | | Collection C2 |
<br>> | bindings: | | bindings: |
<br>> | test | | test |
<br>> +---------------+ +---------------+
<br>> | |
<br>> | |
<br>> | |
<br>> +------------------+
<br>> | Resource R |
<br>> +------------------+
<br>>
<br>> Given a host name of "www.example.com", applying a depth-zero write
<br>> lock to "/CollX/test" will lock the resource R, and the lock-root of
<br>> this lock will be "<a href="http://www.example.com/CollX/test" target="_top" rel="nofollow">http://www.example.com/CollX/test</a>".
<br>>
<br>> Thus the following operations will require that the associated lock
<br>> token is submitted with the "If" request header ([RFC4918], Section
<br>> 10.4):
<br>>
<br>> o a PUT or PROPPATCH request modifying the content or lockable
<br>> properties of resource R (as R is locked) -- no matter which URI
<br>> is used as request target,
<br>>
<br>> o a MOVE, REBIND, UNBIND or DELETE request causing "/CollX/test" not
<br>> being mapped to resource R anymore (be it addressed to "/CollX" or
<br>> "/CollX/test").
<br>>
<br>> The following operations will not require submission of the lock
<br>> token:
<br>>
<br>> o a DELETE request addressed to "/CollY" or /CollY/test", as it does
<br>> not affect the resource R, nor the lock-root,
<br>>
<br>> o for the same reason, an UNBIND request removing the binding "test"
<br>> from collection C2, or the binding "CollY" from the root
<br>> collection,
<br>>
<br>> o similarly, a MOVE or REBIND request causing "/CollY/test" not
<br>> being mapped to resource R anymore.
<br>>
<br>> Note that despite the lock root being
<br>> "<a href="http://www.example.com/CollX/test" target="_top" rel="nofollow">http://www.example.com/CollX/test</a>", an UNLOCK request can be
<br>> addressed through any URI mapped to resource R, as UNLOCK operates on
<br>> the resource identified by the request URI, not that URI (see
<br>> [RFC4918], Section 9.11).
<br>> -- snip --
<br>>
<br>> Some of this text is new (the introduction/motivation, and the example), so it would be nice if people understanding both BIND and locking could do a quick check.
<br>>
<br>> Note that this doesn't really affect the technical contents of BIND: the behavior with respect to locking is still the same, it's just presented in a different way.
<br>>
<br>> Best regards, Julian
</div><br>--
<br><a href="http://www.pincette.biz/" target="_top" rel="nofollow">http://www.pincette.biz/</a><br>Handling your documents with care, wherever you are.
<br><br><br>tag:old.nabble.com,2006:post-26769061bind issue: bind-vs-hierarchy2009-12-13T11:44:12Z2009-12-13T11:44:12ZJulian ReschkeJulian Reschke wrote:
<br>> ...
<br>> 2) bind-vs-hierarchy
<br>> (<<a href="http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.bind-vs-hierarchy" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.bind-vs-hierarchy</a>>)
<br>> ...
<br><br>I have added the following note to the introduction of Section 2:
<br><br>-- snip --
<br> Note: the collection model described herein is not compatible with
<br> systems in which resources inherit properties based solely on the
<br> access path, as the ability to create additional bindings will
<br> cause a single resource to appear as member of several different
<br> collections at the same time.
<br>-- snip --
<br><br>Also, the section about the WebDAV ACL spec has been rewritten to make
<br>clear that it doesn't have a problem with multiple bindings; it now reads:
<br><br>-- snip --
<br>10. Relationship to WebDAV Access Control Protocol
<br><br> Note that the WebDAV Access Control Protocol has been designed for
<br> compatibility with systems that allow multiple URIs to map to the
<br> same resource (see [RFC3744], Section 5):
<br><br> ...Access control properties (especially DAV:acl and DAV:
<br> inherited-acl-set) are defined on the resource identified by the
<br> Request-URI of a PROPFIND request. A direct consequence is that
<br> if the resource is accessible via multiple URI, the value of
<br> access control properties is the same across these URI. ...
<br><br> Furthermore, note that BIND and REBIND behave the same as MOVE with
<br> respect to the DAV:acl property (see [RFC3744], Section 7.3).
<br>-- snip --
<br><br>Diffs, as usually, at
<br><<a href="http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html</a>>
<br>and <<a href="http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html</a>>.
<br><br>Feedback appreciated,
<br><br>Julian
<br><br>tag:old.nabble.com,2006:post-26767142bind issue: locking22009-12-13T07:43:55Z2009-12-13T07:43:55ZJulian ReschkeJulian Reschke wrote:
<br>> ...
<br>> 3) locking2
<br>> (<<a href="http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.locking2" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.locking2</a>>)
<br>> ...
<br><br>This is the issue we've been discussing over and over again in the past
<br>months. It's about whether the vagueness in RFC 4918 about the "lock
<br>root" actually is a bug (thus could be fixed with an erratum), or is
<br>intentional, allowing different ways to interpret the requirements, and
<br>thus differing server behavior.
<br><br>I haven't been able to convince enough people that this is an RFC 4918
<br>problem that should be fixed, thus the new strategy to address is is to
<br>simply state the problem, and specify which interpretation a WebDAV BIND
<br>implementation needs to follow.
<br><br>Consequently, the section about locking was upgraded from an appendix to
<br>a regular spec section, and now reads:
<br><br>-- snip --
<br>9. Relationship to Locking in WebDAV
<br><br> Locking is an optional feature of WebDAV ([RFC4918]). The base
<br> WebDAV specification and this protocol extension have been designed
<br> in parallel, making sure that all features of WebDAV can be
<br> implemented on a server that implements this protocol as well.
<br><br> Unfortunately, WebDAV uses the term "lock-root" inconsistently. It
<br> is introduced in Section 6.1 of [RFC4918], point 2, as:
<br><br> 2. A resource becomes directly locked when a LOCK request to a
<br> URL of that resource creates a new lock. The "lock-root" of the
<br> new lock is that URL. If at the time of the request, the URL is
<br> not mapped to a resource, a new empty resource is created and
<br> directly locked.
<br><br> On the other hand, [RFC4918], Section 9.10.1 states:
<br><br> A LOCK request to an existing resource will create a lock on the
<br> resource identified by the Request-URI, provided the resource is
<br> not already locked with a conflicting lock. The resource
<br> identified in the Request-URI becomes the root of the lock.
<br><br> Servers that implement both WebDAV locking and support for multiple
<br> bindings MUST use the first interpretation: the lock-root is the URI
<br> through which the lock was created, not a resource. This URI, and
<br> potential aliases of this URI ([RFC4918], Section 5), are said to be
<br> "protected" by the lock.
<br><br> As defined in the introduction to Section 7 of [RFC4918], write
<br> operations that modify the state of a locked resource require that
<br> the lock token is submitted with the request. Consistent with
<br> WebDAV, the state of the resource consists of the content ("any
<br> variant"), dead properties, lockable live properties (item 1), plus,
<br> for a collection, all its bindings (item 2). Note that this, by
<br> definition, does not depend on the request URI to which the write
<br> operation is applied (the locked state is a property of the resource,
<br> not its URI).
<br><br> However, the lock root is the URI through which the lock was
<br> requested. Thus, the protection defined in item 3 of the list does
<br> not apply to additional URIs that may be mapped to the same resource
<br> due to the existence of multiple bindings.
<br><br>9.1. Example: Locking and Multiple Bindings
<br><br> Consider a root collection "/", containing the two collections C1 and
<br> C2, named "/CollX" and "/CollY", and a child resource R, bound to C1
<br> as "/CollX/test" and bound to C2 as "/CollY/test":
<br><br> +-------------------------+
<br> | Root Collection |
<br> | bindings: |
<br> | CollX CollY |
<br> +-------------------------+
<br> | |
<br> | |
<br> | |
<br> +---------------+ +---------------+
<br> | Collection C1 | | Collection C2 |
<br> | bindings: | | bindings: |
<br> | test | | test |
<br> +---------------+ +---------------+
<br> | |
<br> | |
<br> | |
<br> +------------------+
<br> | Resource R |
<br> +------------------+
<br><br> Given a host name of "www.example.com", applying a depth-zero write
<br> lock to "/CollX/test" will lock the resource R, and the lock-root of
<br> this lock will be "<a href="http://www.example.com/CollX/test" target="_top" rel="nofollow">http://www.example.com/CollX/test</a>".
<br><br> Thus the following operations will require that the associated lock
<br> token is submitted with the "If" request header ([RFC4918], Section
<br> 10.4):
<br><br> o a PUT or PROPPATCH request modifying the content or lockable
<br> properties of resource R (as R is locked) -- no matter which URI
<br> is used as request target,
<br><br> o a MOVE, REBIND, UNBIND or DELETE request causing "/CollX/test" not
<br> being mapped to resource R anymore (be it addressed to "/CollX" or
<br> "/CollX/test").
<br><br> The following operations will not require submission of the lock
<br> token:
<br><br> o a DELETE request addressed to "/CollY" or /CollY/test", as it does
<br> not affect the resource R, nor the lock-root,
<br><br> o for the same reason, an UNBIND request removing the binding "test"
<br> from collection C2, or the binding "CollY" from the root
<br> collection,
<br><br> o similarly, a MOVE or REBIND request causing "/CollY/test" not
<br> being mapped to resource R anymore.
<br><br> Note that despite the lock root being
<br> "<a href="http://www.example.com/CollX/test" target="_top" rel="nofollow">http://www.example.com/CollX/test</a>", an UNLOCK request can be
<br> addressed through any URI mapped to resource R, as UNLOCK operates on
<br> the resource identified by the request URI, not that URI (see
<br> [RFC4918], Section 9.11).
<br>-- snip --
<br><br>Some of this text is new (the introduction/motivation, and the example),
<br>so it would be nice if people understanding both BIND and locking could
<br>do a quick check.
<br><br>Note that this doesn't really affect the technical contents of BIND: the
<br> behavior with respect to locking is still the same, it's just
<br>presented in a different way.
<br><br>Best regards, Julian
<br><br>tag:old.nabble.com,2006:post-26767048bind issue: copying-complex-loops2009-12-13T07:30:45Z2009-12-13T07:30:45ZJulian ReschkeJulian Reschke wrote:
<br>> ...
<br>> 1) copying-complex-loops
<br>> (<<a href="http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.copying-complex-loops" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.copying-complex-loops</a>>)
<br>> ...
<br><br>This issue was raised by Robert Sparks during IESG review
<br>(<<a href="https://datatracker.ietf.org/idtracker/ballot/1025/" target="_top" rel="nofollow">https://datatracker.ietf.org/idtracker/ballot/1025/</a>>):
<br><br>-- snip --
<br><br>The document provides some discussion of the ramifications of simple
<br>loops, but its not immediately obvious that the recommendations for
<br>handling them are sufficient for dealing with more complex loops. Are
<br>there additional issues introduced when each added level of depth adds
<br>an exponentially growing number of elements?
<br><br>(view in fixed width)
<br> +---------+
<br> | root |
<br> | |
<br> | start |
<br> +---------+
<br> |
<br> v
<br> +---------+ +---------+
<br> +---->| C1 | | C2 |<---+
<br> | +->| | | |<-+ |
<br> | | | a b | | a b | | |
<br> | | +---------+ +---------+ | |
<br> | | | | | | | |
<br> | | | | +----+ | | |
<br> | | | | | | | |
<br> | | | +----------c---+ | | |
<br> | | | | | | | |
<br> | | | +----------+ | | | |
<br> | | v v v v | |
<br> | | +---------+ +---------+ | |
<br> | | | C3 | | C4 | | |
<br> | | | | | | | |
<br> | | | a b | | a b | | |
<br> | | +---------+ +---------+ | |
<br> | | | | | | | |
<br> | +----+ | +----+ +-----+ |
<br> | | | |
<br> | +----------c-----------------+
<br> | |
<br> +-----------------------+
<br><br>-- snip --
<br><br>We (the authors) have discussed this, and note that copying complex
<br>loops works exactly like copying simple loops, and thus adding another
<br>example isn't necessary.
<br><br>That being said, we have added an additional explanation, and a short
<br>statement about complex loops:
<br><br>-- snip --
<br>2.3.1. Example: COPY with 'Depth: infinity' in Presence of Bind Loops
<br><br> As an example of how COPY with Depth infinity would work in the
<br> presence of bindings, consider the following collection:
<br><br> +------------------+
<br> | Root Collection |
<br> | bindings: |
<br> | CollX |
<br> +------------------+
<br> |
<br> |
<br> +-------------------------------+
<br> | Collection C1 |<-------+
<br> | bindings: | |
<br> | x.gif CollY | |
<br> +-------------------------------+ |
<br> | \ (creates loop) |
<br> | \ |
<br> +-------------+ +------------------+ |
<br> | Resource R1 | | Collection C2 | |
<br> +-------------+ | bindings: | |
<br> | y.gif CollZ | |
<br> +------------------+ |
<br> | | |
<br> | +--------+
<br> |
<br> +-------------+
<br> | Resource R2 |
<br> +-------------+
<br><br> If a COPY with Depth infinity is submitted to /CollX, with
<br> destination of /CollA, the outcome of the copy operation is that a
<br> *
<br> copy of the tree is replicated to the target /CollA:
<br> ***************************************************
<br><br> +------------------+
<br> | Root Collection |
<br> | bindings: |
<br> | CollX CollA |
<br> +------------------+
<br> | |
<br> | +---------------------------+
<br> | |
<br> +-------------------+ |
<br> | Collection C1 |<------------------+ |
<br> | bindings: | | |
<br> | x.gif CollY | | |
<br> +-------------------+ | |
<br> | \ (creates loop) | |
<br> | \ | |
<br> +-------------+ +-----------------+ | |
<br> | Resource R1 | | Collection C2 | | |
<br> +-------------+ | bindings: | | |
<br> | y.gif CollZ | | |
<br> +-----------------+ | |
<br> | | | |
<br> | +-------+ |
<br> | |
<br> +-------------+ |
<br> | Resource R2 | |
<br> +-------------+ |
<br> |
<br> +-------------------------------+
<br> |
<br> +-------------------+
<br> | Collection C3 |<------------------+
<br> | bindings: | |
<br> | x.gif CollY | |
<br> +-------------------+ |
<br> | \ (creates loop) |
<br> | \ |
<br> +-------------+ +-----------------+ |
<br> | Resource R3 | | Collection C4 | |
<br> +-------------+ | bindings: | |
<br> | y.gif CollZ | |
<br> +-----------------+ |
<br> | | |
<br> | +-------+
<br> |
<br> +-------------+
<br> | Resource R4 |
<br> +-------------+
<br><br><br> Note that the same would apply for more complex loops.
<br> ******************************************************
<br>-- snip --
<br><br>(new bits marked with "*" characters).
<br><br>We hope that this addresses this comment.
<br><br>Note a new draft has not yet been submitted, for now the changes can be
<br>seen in context at
<br><<a href="http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.copying-complex-loops" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.copying-complex-loops</a>>
<br>and
<br><<a href="http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest-from-previous.diff.html" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest-from-previous.diff.html</a>>.
<br><br>Best regards, Julian
<br><br>tag:old.nabble.com,2006:post-26766927progress on WebDAV BIND, was: I-D Action:draft-ietf-webdav-bind-26.txt2009-12-13T07:14:53Z2009-12-13T07:14:53ZJulian ReschkeJulian Reschke wrote:
<div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> the draft below contains the example for locking behavior in presence of
<br>> multiple bindings, as proposed a few days ago.
<br>>
<br>> At this point I'd like to ask those who still have concerns with the
<br>> specification to verify that the example given matches the locking
<br>> semantics in RFC 4918.
<br>>
<br>> If it does not, we'll need to do more work. If if does, then it appears
<br>> that Appendix A is indeed a clarification of RFC 4918, nothing more.
<br>>
<br>> BR, Julian
<br>> ...
</div><br>In the meantime I had a conversation with our AD, trying to identify
<br>what's left to do. We identified three issues:
<br><br>1) copying-complex-loops
<br>(<<a href="http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.copying-complex-loops" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.copying-complex-loops</a>>)
<br><br>2) bind-vs-hierarchy
<br>(<<a href="http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.bind-vs-hierarchy" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.bind-vs-hierarchy</a>>)
<br><br>3) locking2
<br>(<<a href="http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.locking2" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html#issue.locking2</a>>)
<br><br>I'll address the individual issues in separate mails.
<br><br>Best regards, Julian
<br><br>tag:old.nabble.com,2006:post-26742483Re: I-D Action:draft-brown-versioning-link-relations-05.txt2009-12-11T03:13:55Z2009-12-11T03:13:55ZJulian ReschkeGeoffrey M Clemm wrote:
<div class='shrinkable-quote'><br>>
<br>> Putting something under version control really doesn't mean anything
<br>> beyond having multiple versions of the resource.
<br>> There are of course a variety of other features supported by many
<br>> versioning servers, but having a version history is the lowest common
<br>> denominator.
<br>>
<br>> So yes, this draft would apply to the case you describe, as long as
<br>> multiple separately addressable versions of the resource are provided.
<br>>
<br>> Cheers,
<br>> Geoff
<br>> ...
</div><br>Agreed.
<br><br>At least for the link relations that support the navigation between
<br>versions it really doesn't matter whether internally a version control
<br>system was used. (For the working-copy related relations things may be
<br>different because they somehow imply authorability of a resource).
<br><br>Best regards, Julian
<br><br>tag:old.nabble.com,2006:post-26720991Re: I-D Action:draft-brown-versioning-link-relations-05.txt2009-12-09T17:53:05Z2009-12-09T17:53:05ZGeoffrey M Clemm
<br><tt><font size=2>Putting something under version control really doesn't
mean anything beyond having multiple versions of the resource.</font></tt>
<br><tt><font size=2>There are of course a variety of other features supported
by many versioning servers, but having a version history is the lowest
common denominator.</font></tt>
<br>
<br><tt><font size=2>So yes, this draft would apply to the case you describe,
as long as multiple separately addressable versions of the resource are
provided.</font></tt>
<br>
<br><tt><font size=2>Cheers,</font></tt>
<br><tt><font size=2>Geoff</font></tt>
<br>
<br><tt><font size=2>Jan Algermissen wrote on 12/09/2009 05:26:40 PM:<br>
> <br>
> when visiting the Dublin Core Web site, I was wondering if the draft
<br>
> should clarify whether the intended semantics around 'version' refer
<br>
> to versioning systems only or if they could be used in a broader <br>
> context such as multiple versions of a 'work'.<br>
> <br>
> Dublin Core for example defines relationships around the concept of
<br>
> 'versions', e.g. </font></tt><a href=http://purl.org/dc/terms/isVersionOf target="_top" rel="nofollow"><tt><font size=2>http://purl.org/dc/terms/isVersionOf</font></tt></a><tt><font size=2><br>
> <br>
> IOW, there might be a situation when I have multiple versions of a
<br>
> resource that are not related to 'putting the resource under version
<br>
> control' but rather are the result of the evolution of the content.
<br>
> Such versions might even reside on different servers, managed by <br>
> different authorities.<br>
> <br>
> Do you feel the draft's semantics of 'version' covers this use case?
<br>
> Or not?<br>
> <br>
> Jan<br>
> <br>
> <br>
> <br>
> On Dec 7, 2009, at 3:38 PM, Julian Reschke wrote:<br>
> <br>
> ><br>
> > Hi,<br>
> ><br>
> > FYI - I have now requested registration and publication as <br>
> > Informational RFC. If nothing unexpected happens, this could
mean <br>
> > that the draft gets to IETF Last Call in the next few weeks.<br>
> ><br>
> > Best regards, Julian<br>
> ><br>
> ><br>
> > <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26720991&i=0" target="_top" rel="nofollow">Internet-Drafts@...</a> wrote:<br>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
<br>
> >> directories.<br>
> >> Title : Link
Relations for Simple Version Navigation<br>
> >> Author(s) : A. Brown, et
al.<br>
> >> Filename : draft-brown-versioning-link-relations-05.txt<br>
> >> Pages : 13<br>
> >> Date :
2009-12-07<br>
> >> This specification defines Atom link relations for navigation
between<br>
> >> a resource and its versions.<br>
> >> A URL for this Internet-Draft is:<br>
> >> </font></tt><a href="http://www.ietf.org/internet-drafts/draft-brown-versioning-link-" target="_top" rel="nofollow"><tt><font size=2>http://www.ietf.org/internet-drafts/draft-brown-versioning-link-</font></tt></a><tt><font size=2><br>
> relations-05.txt<br>
> >> Internet-Drafts are also available by anonymous FTP at:<br>
> >> </font></tt><a href="ftp://ftp.ietf.org/internet-drafts/" target="_top" rel="nofollow"><tt><font size=2>ftp://ftp.ietf.org/internet-drafts/</font></tt></a><tt><font size=2><br>
> >> Below is the data which will enable a MIME compliant mail
reader<br>
> >> implementation to automatically retrieve the ASCII version
of the<br>
> >> Internet-Draft.<br>
> >> ------------------------------------------------------------------------<br>
> >> _______________________________________________<br>
> >> I-D-Announce mailing list<br>
> >> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26720991&i=1" target="_top" rel="nofollow">I-D-Announce@...</a><br>
> >> </font></tt><a href="https://www.ietf.org/mailman/listinfo/i-d-announce" target="_top" rel="nofollow"><tt><font size=2>https://www.ietf.org/mailman/listinfo/i-d-announce</font></tt></a><tt><font size=2><br>
> >> Internet-Draft directories: </font></tt><a href=http://www.ietf.org/shadow.html target="_top" rel="nofollow"><tt><font size=2>http://www.ietf.org/shadow.html</font></tt></a><tt><font size=2><br>
> >> or </font></tt><a href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt" target="_top" rel="nofollow"><tt><font size=2>ftp://ftp.ietf.org/ietf/1shadow-sites.txt</font></tt></a><tt><font size=2><br>
> ><br>
> ><br>
> <br>
> --------------------------------------<br>
> Jan Algermissen<br>
> <br>
> Mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26720991&i=2" target="_top" rel="nofollow">algermissen@...</a><br>
> Blog: </font></tt><a href=http://algermissen.blogspot.com target="_top" rel="nofollow" /><tt><font size=2>http://algermissen.blogspot.com/</font></tt></a><tt><font size=2><br>
> Home: </font></tt><a href=http://www.jalgermissen.com target="_top" rel="nofollow" /><tt><font size=2>http://www.jalgermissen.com</font></tt></a><tt><font size=2><br>
> --------------------------------------<br>
> <br>
> <br>
> <br>
> <br>
</font></tt>tag:old.nabble.com,2006:post-26718909Re: I-D Action:draft-brown-versioning-link-relations-05.txt2009-12-09T14:26:40Z2009-12-09T14:26:40ZJan Algermissen-2Julian,
<br><br>when visiting the Dublin Core Web site, I was wondering if the draft
<br>should clarify whether the intended semantics around 'version' refer
<br>to versioning systems only or if they could be used in a broader
<br>context such as multiple versions of a 'work'.
<br><br>Dublin Core for example defines relationships around the concept of
<br>'versions', e.g. <a href="http://purl.org/dc/terms/isVersionOf" target="_top" rel="nofollow">http://purl.org/dc/terms/isVersionOf</a><br><br>IOW, there might be a situation when I have multiple versions of a
<br>resource that are not related to 'putting the resource under version
<br>control' but rather are the result of the evolution of the content.
<br>Such versions might even reside on different servers, managed by
<br>different authorities.
<br><br>Do you feel the draft's semantics of 'version' covers this use case?
<br>Or not?
<br><br>Jan
<br><br><br><br>On Dec 7, 2009, at 3:38 PM, Julian Reschke wrote:
<br><div class='shrinkable-quote'><br>>
<br>> Hi,
<br>>
<br>> FYI - I have now requested registration and publication as
<br>> Informational RFC. If nothing unexpected happens, this could mean
<br>> that the draft gets to IETF Last Call in the next few weeks.
<br>>
<br>> Best regards, Julian
<br>>
<br>>
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26718909&i=0" target="_top" rel="nofollow">Internet-Drafts@...</a> wrote:
<br>>> A New Internet-Draft is available from the on-line Internet-Drafts
<br>>> directories.
<br>>> Title : Link Relations for Simple Version Navigation
<br>>> Author(s) : A. Brown, et al.
<br>>> Filename : draft-brown-versioning-link-relations-05.txt
<br>>> Pages : 13
<br>>> Date : 2009-12-07
<br>>> This specification defines Atom link relations for navigation between
<br>>> a resource and its versions.
<br>>> A URL for this Internet-Draft is:
<br>>> <a href="http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-05.txt" target="_top" rel="nofollow">http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-05.txt</a><br>>> Internet-Drafts are also available by anonymous FTP at:
<br>>> ftp://ftp.ietf.org/internet-drafts/
<br>>> Below is the data which will enable a MIME compliant mail reader
<br>>> implementation to automatically retrieve the ASCII version of the
<br>>> Internet-Draft.
<br>>> ------------------------------------------------------------------------
<br>>> _______________________________________________
<br>>> I-D-Announce mailing list
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26718909&i=1" target="_top" rel="nofollow">I-D-Announce@...</a>
<br>>> <a href="https://www.ietf.org/mailman/listinfo/i-d-announce" target="_top" rel="nofollow">https://www.ietf.org/mailman/listinfo/i-d-announce</a><br>>> Internet-Draft directories: <a href="http://www.ietf.org/shadow.html" target="_top" rel="nofollow">http://www.ietf.org/shadow.html</a><br>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<br>>
<br>>
</div><br>--------------------------------------
<br>Jan Algermissen
<br><br>Mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26718909&i=2" target="_top" rel="nofollow">algermissen@...</a>
<br>Blog: <a href="http://algermissen.blogspot.com/" target="_top" rel="nofollow">http://algermissen.blogspot.com/</a><br>Home: <a href="http://www.jalgermissen.com" target="_top" rel="nofollow">http://www.jalgermissen.com</a><br>--------------------------------------
<br><br><br><br><br>tag:old.nabble.com,2006:post-26685377Re: [VCARDDAV] [caldav] new webdav sync draft2009-12-07T14:26:06Z2009-12-07T14:26:06ZAndrew McMillan-5On Mon, 2009-12-07 at 21:43 +0100, Helge Hess wrote:
<br>> On 07.12.2009, at 16:55, Cyrus Daboo wrote:
<br>> > Just to clarify - right now the spec says that a resource
<br>> > that is deleted and re-created is reported as "new" if a
<br>> > sync-token prior to the deletion is given in the REPORT.
<br>>
<br>> Ah, OK. I would have expected a "deleted" and a "new" entry in such a
<br>> case.
<br><br>Yes, and in fact I revisited my code for this situation after reading
<br>Cyrus' note and discovered that I had implemented that particular case
<br>incorrectly in exactly that way.
<br><br>Sending a DELETE followed by a CREATE in this situation would seem to
<br>more clearly communicate the real-world action, and while there will be
<br>times when the sync report simply ends up prompting the client to
<br>perform a full sync, reducing the frequency of those situations should
<br>also be a goal.
<br><br>On the other hand if we consider this analogous to two consecutive
<br>PROPFIND requests providing a difference of 'that resource is modified'
<br>which clients must necessarily have to cope with already, then it would
<br>be better to send a 'resource modified' in the sync response.
<br><br>As it stands, it seems to me to be a gotcha and an inevitable a source
<br>of bugs for any client side implementation which sees the create and
<br>makes the easy assumption that it means no resource existed in a local
<br>cache.
<br><br><br>> Anyways, I stick to my opinion, slightly extended: Either way is fine
<br>> with me with a slight preference towards having a separate 'created'
<br>> AND 'deleted'. If that would be significantly more difficult for
<br>> servers, lets drop it, if not, lets preserve it.
<br><br>That does seem the safest approach.
<br><br>Regards,
<br> Andrew McMillan.
<br><br><br>------------------------------------------------------------------------
<br>andrew (AT) morphoss (DOT) com +64(272)DEBIAN
<br> Don't you wish you had more energy... or less ambition?
<br>------------------------------------------------------------------------
<br><br><br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (205 bytes) <a href="http://old.nabble.com/attachment/26685377/0/signature.asc" target="_top">Download Attachment</a></div>tag:old.nabble.com,2006:post-26684979Re: [VCARDDAV] [caldav] new webdav sync draft2009-12-07T13:57:45Z2009-12-07T13:57:45ZJulian ReschkeHelge Hess wrote:
<br>> On 07.12.2009, at 16:55, Cyrus Daboo wrote:
<br>>> Just to clarify - right now the spec says that a resource that is deleted and re-created is reported as "new" if a sync-token prior to the deletion is given in the REPORT.
<br>>
<br>> Ah, OK. I would have expected a "deleted" and a "new" entry in such a case.
<br>>
<br>> Now thinking about it, I think it might be an issue if a resource in the cache is replaced with an entirely new resource.
<br>> Eg the client might have (real world: is likely to have) extra client-side data which is only valid for the 'old' resource.
<br>>
<br>> But then, the client can't discover that specific situation with the regular PROPFIND either. And it won't be terribly common, as new URLs usually change in most systems.
<br><br>It could if the server supports DAV:resourceid. (see
<br>draft-ietf-webdav-bind).
<br><br>> ...
<br><br>BR, Julian
<br><br>tag:old.nabble.com,2006:post-26683833Re: [caldav] new webdav sync draft2009-12-07T12:43:16Z2009-12-07T12:43:16ZHelge HessOn 07.12.2009, at 16:55, Cyrus Daboo wrote:
<br>> Just to clarify - right now the spec says that a resource that is deleted and re-created is reported as "new" if a sync-token prior to the deletion is given in the REPORT.
<br><br>Ah, OK. I would have expected a "deleted" and a "new" entry in such a case.
<br><br>Now thinking about it, I think it might be an issue if a resource in the cache is replaced with an entirely new resource.
<br>Eg the client might have (real world: is likely to have) extra client-side data which is only valid for the 'old' resource.
<br><br>But then, the client can't discover that specific situation with the regular PROPFIND either. And it won't be terribly common, as new URLs usually change in most systems.
<br><br>> However, I think the reality is that clients are going to have to accept the fact that there may be false positives (though hopefully never false negatives) so the prudent thing to do is always do a proper match between the server reported results and the full cache they currently have. Maybe we need a statement clarify that.
<br><br>I think performance might be a real world issue with restricted clients (mobile) and large folders, where a key lookup does have a cost.
<br><br>Anyways, I stick to my opinion, slightly extended: Either way is fine with me with a slight preference towards having a separate 'created' AND 'deleted'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it.
<br><br>:-)
<br><br>Greets,
<br> Helge
<br><br><br>tag:old.nabble.com,2006:post-26679314Re: [caldav] new webdav sync draft2009-12-07T07:55:16Z2009-12-07T07:55:16ZCyrus Daboo-2Hi Helge,
<br><br>--On December 6, 2009 10:34:33 PM +0100 Helge Hess
<br><<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26679314&i=0" target="_top" rel="nofollow">helge.hess@...</a>> wrote:
<br><div class='shrinkable-quote'><br>> Its not crucial, but helpful. If I don't know that a resource is new, I
<br>> obviously have to scan the cache to check for that. Which is
<br>> significantly more expensive than a simple INSERT (status = 'N', url=abc)
<br>> ... Given that WebDAV sync is supposed to improve sync with large
<br>> folders, the 'check' time consumption becomes more relevant too ...
<br>>
<br>> The question is whether I would do the scan anyways, just to be sure
<br>> there are no DUPs. Probably! :-) [either me, or a database unique
<br>> constraint doing effectively the same thing]
<br>>
<br>> So I guess either way is fine with me with a slight preference towards
<br>> having a separate 'created'. If that would be significantly more
<br>> difficult for servers, lets drop it, if not, lets preserve it.
</div><br>Just to clarify - right now the spec says that a resource that is deleted
<br>and re-created is reported as "new" if a sync-token prior to the deletion
<br>is given in the REPORT. In that case, were you to do an INSERT using the
<br>UID as a unique key for that reported item you would get an error as the
<br>client already has the old copy cached. So a "simple" INSERT isn't going to
<br>work in that case.
<br><br>Now we could change that behavior to have the deleted/re-created resource
<br>reported as "modified" rather than "new". However, I think the reality is
<br>that clients are going to have to accept the fact that there may be false
<br>positives (though hopefully never false negatives) so the prudent thing to
<br>do is always do a proper match between the server reported results and the
<br>full cache they currently have. Maybe we need a statement clarify that.
<br><br>--
<br>Cyrus Daboo
<br><br><br>tag:old.nabble.com,2006:post-26678394Re: [caldav] new webdav sync draft2009-12-07T06:58:18Z2009-12-07T06:58:18ZArnaud Quillaud<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 6/12/09 22:34, Helge Hess wrote:
<blockquote cite="mid:FC4CE9C0-0F2C-4F4A-8F22-DAE3F1AA6B4D@opengroupware.org" type="cite">
<pre wrap="">Hi,
Arnaud asked me on my opinion on the following ...
On 19.11.2009, at 18:20, Arnaud Quillaud wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I have just submitted a new version of the webdav sync draft (<a class="moz-txt-link-freetext" href="http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt" target="_top" rel="nofollow">http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt</a> ).
</pre>
</blockquote>
<pre wrap=""><!---->
=>
</pre>
<blockquote type="cite">
<pre wrap=""> 2. Do clients really need to be notified that a resource was created
versus modified ? They should be able to figure that out by
looking at the state of their current cache. If this information
is not necessary, the response would not need to contain a DAV:
status along with the DAV:propstat. This would allow the use of
a regular multistatus (simply extended with a sync-token
element).
</pre>
</blockquote>
<pre wrap=""><!---->
Its not crucial, but helpful. If I don't know that a resource is new, I obviously have to scan the cache to check for that. Which is significantly more expensive than a simple INSERT (status = 'N', url=abc) ...
Given that WebDAV sync is supposed to improve sync with large folders, the 'check' time consumption becomes more relevant too ...
The question is whether I would do the scan anyways, just to be sure there are no DUPs. Probably! :-) [either me, or a database unique constraint doing effectively the same thing]
</pre>
</blockquote>
Maximilian Odendahl who is working on the Symbian CalDAV connector gave
us the same feedback.<br>
And it looks like the Inverse Edition of Mozilla Lightning is doing the
same thing (i.e. scan regardless of the status sent by the server).<br>
<br>
Arnaud<br>
<blockquote cite="mid:FC4CE9C0-0F2C-4F4A-8F22-DAE3F1AA6B4D@opengroupware.org" type="cite">
<pre wrap="">
So I guess either way is fine with me with a slight preference towards having a separate 'created'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it.
Greets,
Helge
_______________________________________________
caldav mailing list
<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26678394&i=0" target="_top" rel="nofollow">caldav@...</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/caldav" target="_top" rel="nofollow">https://www.ietf.org/mailman/listinfo/caldav</a>
</pre>
</blockquote>
<br>
</body>
</html>
tag:old.nabble.com,2006:post-26678161Re: I-D Action:draft-brown-versioning-link-relations-05.txt2009-12-07T06:38:35Z2009-12-07T06:38:35ZJulian ReschkeHi,
<br><br>FYI - I have now requested registration and publication as Informational
<br>RFC. If nothing unexpected happens, this could mean that the draft gets
<br>to IETF Last Call in the next few weeks.
<br><br>Best regards, Julian
<br><br><br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26678161&i=0" target="_top" rel="nofollow">Internet-Drafts@...</a> wrote:
<div class='shrinkable-quote'><br>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
<br>>
<br>> Title : Link Relations for Simple Version Navigation
<br>> Author(s) : A. Brown, et al.
<br>> Filename : draft-brown-versioning-link-relations-05.txt
<br>> Pages : 13
<br>> Date : 2009-12-07
<br>>
<br>> This specification defines Atom link relations for navigation between
<br>> a resource and its versions.
<br>>
<br>> A URL for this Internet-Draft is:
<br>> <a href="http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-05.txt" target="_top" rel="nofollow">http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-05.txt</a><br>>
<br>> Internet-Drafts are also available by anonymous FTP at:
<br>> ftp://ftp.ietf.org/internet-drafts/
<br>>
<br>> Below is the data which will enable a MIME compliant mail reader
<br>> implementation to automatically retrieve the ASCII version of the
<br>> Internet-Draft.
<br>>
<br>>
<br>> ------------------------------------------------------------------------
<br>>
<br>> _______________________________________________
<br>> I-D-Announce mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26678161&i=1" target="_top" rel="nofollow">I-D-Announce@...</a>
<br>> <a href="https://www.ietf.org/mailman/listinfo/i-d-announce" target="_top" rel="nofollow">https://www.ietf.org/mailman/listinfo/i-d-announce</a><br>> Internet-Draft directories: <a href="http://www.ietf.org/shadow.html" target="_top" rel="nofollow">http://www.ietf.org/shadow.html</a><br>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
</div><br><br>tag:old.nabble.com,2006:post-26676101Why working-copy belongs into draft-brown-versioning-link-relations2009-12-07T03:46:32Z2009-12-07T03:46:32ZJan Algermissen-2I have been wondering, whether working-copy should be included in the
<br>draft, or if it was too specific to particular versioning systems.
<br>Here is why I think it belongs into the draft:
<br><br>Regardless of the kind of versioning system, there will allways be a
<br>copy of the versioned resource that serves as the basis for the change
<br>the user makes. Even in the case of updating an unversioned HTTP
<br>resource the user retrieves a representation of the resource, modifies
<br>this local (working-) copy and then updates the resource with the
<br>modified representation.
<br><br>There is a special case where working copies are maintained by the
<br>server and made available to the user and only in this case the user
<br>does not necessarily know or have a hold of her working copy. The
<br>working copy link relation addresses exactly this special case.
<br><br> From this POV the working-copy link relation *completes* the draft
<br>regarding all aspects of working copies when interacting with
<br>authoring systems. Hence - it should be in there (as it currently is).
<br><br>Jan
<br><br><br><br>On Dec 4, 2009, at 11:03 PM, Julian Reschke wrote:
<br><div class='shrinkable-quote'><br>> (FYI)
<br>>
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26676101&i=0" target="_top" rel="nofollow">Internet-Drafts@...</a> wrote:
<br>>> A New Internet-Draft is available from the on-line Internet-Drafts
<br>>> directories.
<br>>> Title : Link Relations for Simple Version Navigation
<br>>> Author(s) : A. Brown, et al.
<br>>> Filename : draft-brown-versioning-link-relations-04.txt
<br>>> Pages : 14
<br>>> Date : 2009-12-04
<br>>> This specification defines Atom link relations for navigation between
<br>>> a resource and its versions.
<br>>> A URL for this Internet-Draft is:
<br>>> <a href="http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-04.txt" target="_top" rel="nofollow">http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-04.txt</a><br>>> Internet-Drafts are also available by anonymous FTP at:
<br>>> ftp://ftp.ietf.org/internet-drafts/
<br>>> Below is the data which will enable a MIME compliant mail reader
<br>>> implementation to automatically retrieve the ASCII version of the
<br>>> Internet-Draft.
<br>>> ------------------------------------------------------------------------
<br>>> _______________________________________________
<br>>> I-D-Announce mailing list
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26676101&i=1" target="_top" rel="nofollow">I-D-Announce@...</a>
<br>>> <a href="https://www.ietf.org/mailman/listinfo/i-d-announce" target="_top" rel="nofollow">https://www.ietf.org/mailman/listinfo/i-d-announce</a><br>>> Internet-Draft directories: <a href="http://www.ietf.org/shadow.html" target="_top" rel="nofollow">http://www.ietf.org/shadow.html</a><br>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<br>>
<br>>
</div><br>--------------------------------------
<br>Jan Algermissen
<br><br>Mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26676101&i=2" target="_top" rel="nofollow">algermissen@...</a>
<br>Blog: <a href="http://algermissen.blogspot.com/" target="_top" rel="nofollow">http://algermissen.blogspot.com/</a><br>Home: <a href="http://www.jalgermissen.com" target="_top" rel="nofollow">http://www.jalgermissen.com</a><br>--------------------------------------
<br><br><br><br><br>tag:old.nabble.com,2006:post-26669332Re: new webdav sync draft2009-12-06T13:34:33Z2009-12-06T13:34:33ZHelge HessHi,
<br><br>Arnaud asked me on my opinion on the following ...
<br><br>On 19.11.2009, at 18:20, Arnaud Quillaud wrote:
<br>> I have just submitted a new version of the webdav sync draft (<a href="http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt" target="_top" rel="nofollow">http://www.ietf.org/id/draft-daboo-webdav-sync-02.txt</a> ).
<br><br>=>
<br>> 2. Do clients really need to be notified that a resource was created
<br>> versus modified ? They should be able to figure that out by
<br>> looking at the state of their current cache. If this information
<br>> is not necessary, the response would not need to contain a DAV:
<br>> status along with the DAV:propstat. This would allow the use of
<br>> a regular multistatus (simply extended with a sync-token
<br>> element).
<br><br>Its not crucial, but helpful. If I don't know that a resource is new, I obviously have to scan the cache to check for that. Which is significantly more expensive than a simple INSERT (status = 'N', url=abc) ...
<br>Given that WebDAV sync is supposed to improve sync with large folders, the 'check' time consumption becomes more relevant too ...
<br><br>The question is whether I would do the scan anyways, just to be sure there are no DUPs. Probably! :-) [either me, or a database unique constraint doing effectively the same thing]
<br><br>So I guess either way is fine with me with a slight preference towards having a separate 'created'. If that would be significantly more difficult for servers, lets drop it, if not, lets preserve it.
<br><br>Greets,
<br> Helge
<br><br><br>tag:old.nabble.com,2006:post-26649949Re: I-D Action:draft-brown-versioning-link-relations-04.txt2009-12-04T14:03:28Z2009-12-04T14:03:28ZJulian Reschke(FYI)
<br><br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649949&i=0" target="_top" rel="nofollow">Internet-Drafts@...</a> wrote:
<div class='shrinkable-quote'><br>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
<br>>
<br>> Title : Link Relations for Simple Version Navigation
<br>> Author(s) : A. Brown, et al.
<br>> Filename : draft-brown-versioning-link-relations-04.txt
<br>> Pages : 14
<br>> Date : 2009-12-04
<br>>
<br>> This specification defines Atom link relations for navigation between
<br>> a resource and its versions.
<br>>
<br>> A URL for this Internet-Draft is:
<br>> <a href="http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-04.txt" target="_top" rel="nofollow">http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-04.txt</a><br>>
<br>> Internet-Drafts are also available by anonymous FTP at:
<br>> ftp://ftp.ietf.org/internet-drafts/
<br>>
<br>> Below is the data which will enable a MIME compliant mail reader
<br>> implementation to automatically retrieve the ASCII version of the
<br>> Internet-Draft.
<br>>
<br>>
<br>> ------------------------------------------------------------------------
<br>>
<br>> _______________________________________________
<br>> I-D-Announce mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26649949&i=1" target="_top" rel="nofollow">I-D-Announce@...</a>
<br>> <a href="https://www.ietf.org/mailman/listinfo/i-d-announce" target="_top" rel="nofollow">https://www.ietf.org/mailman/listinfo/i-d-announce</a><br>> Internet-Draft directories: <a href="http://www.ietf.org/shadow.html" target="_top" rel="nofollow">http://www.ietf.org/shadow.html</a><br>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
</div><br><br>tag:old.nabble.com,2006:post-26643186Re: (Opposite of working-copy?) Comment on draft-brown-versioning-link-relations-032009-12-04T06:17:35Z2009-12-04T06:17:35ZJulian ReschkeJulian Reschke wrote:
<div class='shrinkable-quote'><br>> Jan Algermissen wrote:
<br>>> Julian,
<br>>>
<br>>> what is your opinion regarding the introduction of a link relation
<br>>> that is the opposite of working-copy in order to being able to find
<br>>> the versioned resource that the working copy I have is a working copy of?
<br>>>
<br>>> I am undecided regarding the necessity, but without a working-copy-of
<br>>> relation it seems the client would need to maintain that information
<br>>> (the relationship or the fact that a given resource is a working copy)
<br>>> across requests.
<br>>>
<br>>> I do not think this is really I-D publication relevant right now,
<br>>> please understand it only as a side comment.
<br>>> ...
<br>>
<br>> I have no problems adding this; the reason it hasn't been proposed was
<br>> that apparently CMIS didn't have a use case for it.
<br>>
<br>> Al, any opinion on this from a CMIS point of view?
<br>> ...
</div><br>OK, I have added working-copy-of, and plan to submit the current draft
<br>(also including the other changes we discussed) as
<br>draft-brown-versioning-link-relations-04 later today.
<br><br>A marked up version with diffs is available at
<br><<a href="http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html</a>>,
<br>feedback appreciated.
<br><br>Best regards, Julian
<br><br>tag:old.nabble.com,2006:post-26622719.htaccess prevent right access from webdav2009-12-02T21:15:19Z2009-12-02T21:15:19ZJ. Bakshi-2Hello list,
<br><br>I am facing a strange problem with webdav. I am running debian lenny
<br>server with apache2
<br><br>` ` `
<br>Server version: Apache/2.2.9 (Debian)
<br>Server built: Jul 14 2009 20:44:04
<br>` ` `
<br><br>with dav and dav_fs enabled. webdav is running well and it also
<br>creates and deletes file/folder with out any problem. The problem starts
<br>as soon as I place .htaccess file. webdav can't create/delete
<br>anything!!! It generates error as below from client pc
<br><br>` ` '
<br>touch 123
<br>touch: cannot touch `123': Input/output error
<br><br>mkdir 123
<br>mkdir: cannot create directory `123': No such file or directory
<br> ` ` `
<br><br>windows client simply throws error as permission denied. My webdav
<br>configuration is
<br><br> ` ` `
<br>## webdav access
<br><br>Alias /webdav/kaushik /var/personal_work_area/kaushik
<br><br> <Location /webdav/kaushik>
<br> DAV On
<br> ForceType text/plain
<br> SSLRequireSSL
<br> AuthType Basic
<br> AuthName "kaushik's webdav"
<br> AuthUserFile /home/svn/PASSWD
<br> Require user kaushik
<br><br> </Location>
<br>` ` `
<br><br>and .htaccess is
<br><br>` ` `
<br>Options +FollowSymLinks
<br><br>RewriteEngine On
<br>RewriteRule ^typo3$ - [L]
<br>RewriteRule ^typo3/.*$ - [L]
<br><br>RewriteCond %{REQUEST_FILENAME} !-f
<br>RewriteCond %{REQUEST_FILENAME} !-d
<br>RewriteCond %{REQUEST_FILENAME} !-l
<br>RewriteRule .* index.php
<br>` ` `
<br><br>as soon as I delete .htaccess ( from the server) webdav has no problem
<br>to create/delete files/folders.
<br><br>Does any one know why .htaccess prevents write access from webdav ?
<br><br>Thanks
<br><br><br><br>--
<br>জয়দীপ বক্সী
<br><br><br>tag:old.nabble.com,2006:post-26613450Re: Comments on Action:draft-brown-versioning-link-relations-032009-12-02T09:59:01Z2009-12-02T09:59:01ZJulian ReschkeJan Algermissen wrote:
<div class='shrinkable-quote'><br>> Julian,
<br>>
<br>> On Dec 1, 2009, at 3:07 PM, Julian Reschke wrote:
<br>>
<br>>> Jan Algermissen wrote:
<br>>>> ...
<br>>>> Hmm, I think so. The definition in a sense implies that the version
<br>>>> is created as a result of the modification. Which is IMHO *never* the
<br>>>> case for working copies.
<br>>>> Surely the draft must define 'working copy'. What is the nature of a
<br>>>> working copy? What is its true nature? I think: being *used* for
<br>>>> creating new versions. So, what about:
<br>>>>>>> "A "working copy" is a resource at a server-defined URL that can
<br>>>>>>> be *used* to create a new version of a versioned resource."
<br>>>> ...
<br>>>
<br>>> So, substituting "modified" by "used". I'm ok with that.
<br>>
<br>> Fine.
<br>>
<br>>>
<br>>>> and remove checkout/checkin completely. ('use' instead of 'modify'
<br>>>> sounds less like "The modification cause the versioning" (which it
<br>>>> never does by nature of a working copy (IMHO - s.a.))
<br>>>> If the draft wanted to define it, then it woud be something like:
<br>>>> checkout: an operation on a resource that creates a working copy
<br>>>> checkin: an operation on a working copy that creates a new version of
<br>>>> its corresponding versioned resource.
<br>>>
<br>>> The issue here is that in some systems, checkout will not create a new
<br>>> resource, just flip a bit on the versioned resource.
<br>>>
<br>>> Also, (I think) there are systems where checking in does not create a
<br>>> new version, but flips a bit on the working resource *making* it a
<br>>> version (at the same URL).
<br>>>
<br>>> Thus, defining this would need to be defined in a more generic way. My
<br>>> attempt:
<br>>>
<br>>> "Checkout: an operation on a versioned resource that creates a working
<br>>> copy, or changes the versioned resource to be a working-copy as well
<br>>> ("in-place versioning").
<br>>>
<br>>> Checkin: an operation on a working copy that creates a new version of
<br>>> its corresponding versioned resource.
<br>>>
<br>>> Note: the operations for putting a resource under version control, and
<br>>> for checking in and checking out depend on the protocol in use and are
<br>>> beyond the scope of this document; see [CMIS], [RFC3253] and [JSR-283]
<br>>> for details)."
<br>>
<br>>
<br>> Sounds good to me.
<br>> ...
</div><br>OK, I have added the text as proposed in my copy at
<br><<a href="http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html</a>>,
<br>the terminology section now reads:
<br><br> Versioned Resource
<br><br> When a resource is put under version control, it becomes a
<br> "versioned resource". Many servers protect versioned resources
<br> from modifications by considering them "checked in", and by
<br> requiring a "checkout" operation before modification, and a
<br> "checkin" operation to get back to the "checked-in" state. Other
<br> servers allow modification, in which case the checkout/checkin
<br> operation may happen implicitly.
<br><br> Version History
<br><br> A "version history" resource is a resource that contains all the
<br> versions of a particular versioned resource.
<br><br> Predecessor, Successor
<br><br> When a versioned resource is checked out and then subsequently
<br> checked in, the version that was checked out becomes a
<br> "predecessor" of the version created by the checkin. A client can
<br> specify multiple predecessors for a new version if the new version
<br> is logically a merge of those predecessors. The inverse of the
<br> predecessor relation is the "successor" relation. Therefore, if X
<br> is a predecessor of Y, then Y is a successor of X.
<br><br> Working Copy
<br><br> A "working copy" is a resource at a server-defined URL that can be
<br> used to create a new version of a versioned resource.
<br><br> Checkin
<br><br> A "checkin" is an operation on a versioned resource that creates a
<br> working copy, or changes the versioned resource to be a working-
<br> copy as well ("in-place versioning").
<br><br> Checkout
<br><br> A "checkout" is an operation on a working copy that creates a new
<br> version of its corresponding versioned resource.
<br><br> Note: the operations for putting a resource under version control,
<br> and for checking in and checking out depend on the protocol in use
<br> and are beyond the scope of this document; see [CMIS], [RFC3253]
<br> and [JSR-283] for examples.
<br><br>...as always, feedback appreciated,
<br><br>Julian
<br><br>tag:old.nabble.com,2006:post-26612412Re: (Opposite of working-copy?) Comment on draft-brown-versioning-link-relations-032009-12-02T08:58:56Z2009-12-02T08:58:56ZJulian ReschkeJan Algermissen wrote:
<div class='shrinkable-quote'><br>> Julian,
<br>>
<br>> what is your opinion regarding the introduction of a link relation that
<br>> is the opposite of working-copy in order to being able to find the
<br>> versioned resource that the working copy I have is a working copy of?
<br>>
<br>> I am undecided regarding the necessity, but without a working-copy-of
<br>> relation it seems the client would need to maintain that information
<br>> (the relationship or the fact that a given resource is a working copy)
<br>> across requests.
<br>>
<br>> I do not think this is really I-D publication relevant right now, please
<br>> understand it only as a side comment.
<br>> ...
</div><br>I have no problems adding this; the reason it hasn't been proposed was
<br>that apparently CMIS didn't have a use case for it.
<br><br>Al, any opinion on this from a CMIS point of view?
<br><br>Best regards, Julian
<br><br>tag:old.nabble.com,2006:post-26611265Re: Comments on Action:draft-brown-versioning-link-relations-032009-12-02T07:55:19Z2009-12-02T07:55:19ZJulian ReschkeAsbjørn Ulsberg wrote:
<div class='shrinkable-quote'><br>>
<br>> On Thu, 26 Nov 2009 16:58:37 +0100, Julian Reschke
<br>> <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26611265&i=0" target="_top" rel="nofollow">julian.reschke@...</a>> wrote:
<br>>
<br>>> Sam Johnston wrote:
<br>>>
<br>>>> * version-history -> versions, history or revisions
<br>>>> * latest-version -> latest
<br>>>> * working-copy -> ok
<br>>>> * predecessor-version -> predecessor or previous-version or
<br>>>> prev-version (which is it, prev or previous - I think there's some
<br>>>> ambiguity here)
<br>>>> * successor-version -> successor or next-version
<br>>>
<br>>> I think the suffix "-version" is important because there can be many
<br>>> other similar relations providing "prex/next/last", which have nothing
<br>>> to do with versioning.
<br>>
<br>> As long as the words "previous", "next" and "last" aren't used, there's
<br>> no collision. "predecessor" and "successor" are pretty unambiguous and
<br>> don't collide with any existing link relations that I'm aware of. Also,
</div><br>They do not collide with link relations, but they aren't unambiguous
<br>either. For instance, <<a href="http://www.imdb.com/title/tt0071562/" target="_top" rel="nofollow">http://www.imdb.com/title/tt0071562/</a>> is the
<br>successor of <<a href="http://www.imdb.com/title/tt0068646/" target="_top" rel="nofollow">http://www.imdb.com/title/tt0068646/</a>>, but it's not a
<br>successor version.
<br><br>> in this context (talking about documents) what else than "an earlier
<br>> version" might you refer to when pointing to a "predecessor"?
<br>>
<br>> In other words; I agree with Sam. I think the shorter and more concise
<br>> relations are better. Either use words that don't imply "version" (like
<br>> "previous" and "next") and suffix them with "-version" or use words that
<br>> unambiguously refer to "versions" and have no suffix, but not a mix of
<br>> both.
<br><br>Not convinced. I'll leave this to the expert review and the IESG.
<br><div class='shrinkable-quote'><br>>>> I also wonder whether it makes sense to offer links to "native"
<br>>>> revision control (e.g. hg, git, svn, etc.) and/or web interfaces to
<br>>>> them - and then specifics like branches and tags, and what a URI/URL
<br>>>> to a branch/tag would even look like.
<br>>>
<br>>> That's an interesting thought, but appears to be a much more complex
<br>>> problem that the one we wanted to solve here.
<br>>
<br>> I think such problems are important to explore, since this I-D is
<br>> something these SCM's might want to implement.
</div><br>I agree that it's an interesting problem, but just because something is
<br>interesting doesn't mean it needs to be solved in this proposal. At this
<br>point, I'd rather take out things than add new things.
<br><br>Best regards, Julian
<br><br><br>tag:old.nabble.com,2006:post-26607079(Opposite of working-copy?) Comment on draft-brown-versioning-link-relations-032009-12-02T02:56:47Z2009-12-02T02:56:47ZJan Algermissen-2Julian,
<br><br>what is your opinion regarding the introduction of a link relation
<br>that is the opposite of working-copy in order to being able to find
<br>the versioned resource that the working copy I have is a working copy
<br>of?
<br><br>I am undecided regarding the necessity, but without a working-copy-of
<br>relation it seems the client would need to maintain that information
<br>(the relationship or the fact that a given resource is a working copy)
<br>across requests.
<br><br>I do not think this is really I-D publication relevant right now,
<br>please understand it only as a side comment.
<br><br>Jan
<br><br><br><br><br><br><br>On Nov 20, 2009, at 3:13 PM, Julian Reschke wrote:
<br><div class='shrinkable-quote'><br>>
<br>> (FYI)
<br>>
<br>> This update to yesterday's draft is purely editorial, moving each
<br>> link relation into a proper subsection, and using the correct IANA
<br>> registration template as defined per RFC 4287.
<br>>
<br>> At this point we'd like to ask the community for final feedback; we
<br>> are planning to request publication in two weeks from now (Dec 04).
<br>>
<br>> Best regards,
<br>>
<br>> Julian
<br>>
<br>>
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26607079&i=0" target="_top" rel="nofollow">Internet-Drafts@...</a> wrote:
<br>>> A New Internet-Draft is available from the on-line Internet-Drafts
<br>>> directories.
<br>>> Title : Link Relations for Simple Version Navigation
<br>>> Author(s) : A. Brown, et al.
<br>>> Filename : draft-brown-versioning-link-relations-03.txt
<br>>> Pages : 11
<br>>> Date : 2009-11-20
<br>>> This specification defines Atom link relations for navigation between
<br>>> a resource and its versions.
<br>>> A URL for this Internet-Draft is:
<br>>> <a href="http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-03.txt" target="_top" rel="nofollow">http://www.ietf.org/internet-drafts/draft-brown-versioning-link-relations-03.txt</a><br>>> Internet-Drafts are also available by anonymous FTP at:
<br>>> ftp://ftp.ietf.org/internet-drafts/
<br>>> Below is the data which will enable a MIME compliant mail reader
<br>>> implementation to automatically retrieve the ASCII version of the
<br>>> Internet-Draft.
<br>>> ------------------------------------------------------------------------
<br>>> _______________________________________________
<br>>> I-D-Announce mailing list
<br>>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26607079&i=1" target="_top" rel="nofollow">I-D-Announce@...</a>
<br>>> <a href="https://www.ietf.org/mailman/listinfo/i-d-announce" target="_top" rel="nofollow">https://www.ietf.org/mailman/listinfo/i-d-announce</a><br>>> Internet-Draft directories: <a href="http://www.ietf.org/shadow.html" target="_top" rel="nofollow">http://www.ietf.org/shadow.html</a><br>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
<br>>
</div><br>--------------------------------------
<br>Jan Algermissen
<br><br>Mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26607079&i=2" target="_top" rel="nofollow">algermissen@...</a>
<br>Blog: <a href="http://algermissen.blogspot.com/" target="_top" rel="nofollow">http://algermissen.blogspot.com/</a><br>Home: <a href="http://www.jalgermissen.com" target="_top" rel="nofollow">http://www.jalgermissen.com</a><br>--------------------------------------
<br><br><br><br><br>tag:old.nabble.com,2006:post-26604316Re: Comments on Action:draft-brown-versioning-link-relations-032009-12-01T22:41:56Z2009-12-01T22:41:56ZJan Algermissen-2Julian,
<br><br>On Dec 1, 2009, at 3:07 PM, Julian Reschke wrote:
<br><div class='shrinkable-quote'><br>> Jan Algermissen wrote:
<br>>> ...
<br>>> Hmm, I think so. The definition in a sense implies that the version
<br>>> is created as a result of the modification. Which is IMHO *never*
<br>>> the case for working copies.
<br>>> Surely the draft must define 'working copy'. What is the nature of
<br>>> a working copy? What is its true nature? I think: being *used* for
<br>>> creating new versions. So, what about:
<br>>>>>> "A "working copy" is a resource at a server-defined URL that can
<br>>>>>> be *used* to create a new version of a versioned resource."
<br>>> ...
<br>>
<br>> So, substituting "modified" by "used". I'm ok with that.
</div><br>Fine.
<br><div class='shrinkable-quote'><br>>
<br>>> and remove checkout/checkin completely. ('use' instead of 'modify'
<br>>> sounds less like "The modification cause the versioning" (which it
<br>>> never does by nature of a working copy (IMHO - s.a.))
<br>>> If the draft wanted to define it, then it woud be something like:
<br>>> checkout: an operation on a resource that creates a working copy
<br>>> checkin: an operation on a working copy that creates a new version
<br>>> of its corresponding versioned resource.
<br>>
<br>> The issue here is that in some systems, checkout will not create a
<br>> new resource, just flip a bit on the versioned resource.
<br>>
<br>> Also, (I think) there are systems where checking in does not create
<br>> a new version, but flips a bit on the working resource *making* it a
<br>> version (at the same URL).
<br>>
<br>> Thus, defining this would need to be defined in a more generic way.
<br>> My attempt:
<br>>
<br>> "Checkout: an operation on a versioned resource that creates a
<br>> working copy, or changes the versioned resource to be a working-copy
<br>> as well ("in-place versioning").
<br>>
<br>> Checkin: an operation on a working copy that creates a new version of
<br>> its corresponding versioned resource.
<br>>
<br>> Note: the operations for putting a resource under version control,
<br>> and for checking in and checking out depend on the protocol in use
<br>> and are beyond the scope of this document; see [CMIS], [RFC3253] and
<br>> [JSR-283] for details)."
</div><br><br>Sounds good to me.
<br><br>Jan
<br><br><br><br>>
<br>> Best regards, Julian
<br><br>--------------------------------------
<br>Jan Algermissen
<br><br>Mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26604316&i=0" target="_top" rel="nofollow">algermissen@...</a>
<br>Blog: <a href="http://algermissen.blogspot.com/" target="_top" rel="nofollow">http://algermissen.blogspot.com/</a><br>Home: <a href="http://www.jalgermissen.com" target="_top" rel="nofollow">http://www.jalgermissen.com</a><br>--------------------------------------
<br><br><br><br><br>tag:old.nabble.com,2006:post-26592365Re: Comments on Action:draft-brown-versioning-link-relations-032009-12-01T06:07:52Z2009-12-01T06:07:52ZJulian ReschkeJan Algermissen wrote:
<div class='shrinkable-quote'><br>> ...
<br>> Hmm, I think so. The definition in a sense implies that the version is
<br>> created as a result of the modification. Which is IMHO *never* the case
<br>> for working copies.
<br>>
<br>> Surely the draft must define 'working copy'. What is the nature of a
<br>> working copy? What is its true nature? I think: being *used* for
<br>> creating new versions. So, what about:
<br>>
<br>>>>> "A "working copy" is a resource at a server-defined URL that can be
<br>>>>> *used* to create a new version of a versioned resource."
<br>> ...
</div><br>So, substituting "modified" by "used". I'm ok with that.
<br><br>> and remove checkout/checkin completely. ('use' instead of 'modify'
<br>> sounds less like "The modification cause the versioning" (which it never
<br>> does by nature of a working copy (IMHO - s.a.))
<br>>
<br>> If the draft wanted to define it, then it woud be something like:
<br>>
<br>> checkout: an operation on a resource that creates a working copy
<br>> checkin: an operation on a working copy that creates a new version of
<br>> its corresponding versioned resource.
<br><br>The issue here is that in some systems, checkout will not create a new
<br>resource, just flip a bit on the versioned resource.
<br><br>Also, (I think) there are systems where checking in does not create a
<br>new version, but flips a bit on the working resource *making* it a
<br>version (at the same URL).
<br><br>Thus, defining this would need to be defined in a more generic way. My
<br>attempt:
<br><br>"Checkout: an operation on a versioned resource that creates a working
<br>copy, or changes the versioned resource to be a working-copy as well
<br>("in-place versioning").
<br><br>Checkin: an operation on a working copy that creates a new version of
<br>its corresponding versioned resource.
<br><br>Note: the operations for putting a resource under version control, and
<br>for checking in and checking out depend on the protocol in use and are
<br>beyond the scope of this document; see [CMIS], [RFC3253] and [JSR-283]
<br>for details)."
<br><br>Best regards, Julian
<br><br>tag:old.nabble.com,2006:post-26591953Re: Comments on Action:draft-brown-versioning-link-relations-032009-12-01T05:27:40Z2009-12-01T05:27:40ZJulian ReschkeJulian Reschke wrote:
<div class='shrinkable-quote'><br>> Jan Algermissen wrote:
<br>>> Do you have a (rough) set of use cases (IOW: client goals) that are to
<br>>> be enabled by the link relations?
<br>>>
<br>>> Along the lines: "Client needs to find a working-copy" => link rel
<br>>> working-copy enables that
<br>>
<br>> These use cases mainly come from CMIS (content management over AtomPub);
<br>> and the main reason these aren't mentioned in the spec is that we wanted
<br>> to avoid a circular spec reference.
<br>>
<br>> See
<br>> <<a href="http://lists.oasis-open.org/archives/tc-announce/200910/msg00015.html" target="_top" rel="nofollow">http://lists.oasis-open.org/archives/tc-announce/200910/msg00015.html</a>>.
<br>> ...
</div><br>To make things cleared, I have added a short pointer to the Introduction:
<br><br>"These link relations are used in the AtomPub ([RFC5023]) bindings of
<br>the "Content Management Interoperability Services" (CMIS). See Section
<br>3.4.3.1 of [CMIS] for further information." --
<br><<a href="http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html#introduction" target="_top" rel="nofollow">http://greenbytes.de/tech/webdav/draft-brown-versioning-link-relations-latest.html#introduction</a>>
<br><br>Best regards, Julian
<br><br>tag:old.nabble.com,2006:post-26577530Re: Comments on Action:draft-brown-versioning-link-relations-032009-11-30T08:28:12Z2009-11-30T08:28:12ZJan Algermissen-2<br>On Nov 30, 2009, at 5:06 PM, Julian Reschke wrote:
<br><div class='shrinkable-quote'><br>> Jan Algermissen wrote:
<br>>>> Does it?
<br>>>>
<br>>>> "A "working copy" is a resource at a server-defined URL that can
<br>>>> be modified to create a new version of a versioned resource."
<br>>>>
<br>>> So it might be enough to:
<br>>> PUT /working-copies/667
<br>>> <foo/>
<br>>> to create a new version of /main/667 ?? (assuming that /main/667 --
<br>>> working-copy--> /working-copies/667)
<br>>> What would be the reason to have a working copy that needs not be
<br>>> checked-in?
<br>>
<br>> That's not what I intended to say; I was just pointing out that the
<br>> current definition in the spec does not refer to checkin/checkout
<br>> (maybe it should?).
</div><br>Hmm, I think so. The definition in a sense implies that the version is
<br>created as a result of the modification. Which is IMHO *never* the
<br>case for working copies.
<br><br>Surely the draft must define 'working copy'. What is the nature of a
<br>working copy? What is its true nature? I think: being *used* for
<br>creating new versions. So, what about:
<br><br>>>> "A "working copy" is a resource at a server-defined URL that can
<br>>>> be *used* to create a new version of a versioned resource."
<br><br>and remove checkout/checkin completely. ('use' instead of 'modify'
<br>sounds less like "The modification cause the versioning" (which it
<br>never does by nature of a working copy (IMHO - s.a.))
<br><br>If the draft wanted to define it, then it woud be something like:
<br><br>checkout: an operation on a resource that creates a working copy
<br>checkin: an operation on a working copy that creates a new version of
<br>its corresponding versioned resource.
<br><br>Jan
<br><br><br><br>>
<br>> BR, Julian
<br><br>--------------------------------------
<br>Jan Algermissen
<br><br>Mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26577530&i=0" target="_top" rel="nofollow">algermissen@...</a>
<br>Blog: <a href="http://algermissen.blogspot.com/" target="_top" rel="nofollow">http://algermissen.blogspot.com/</a><br>Home: <a href="http://www.jalgermissen.com" target="_top" rel="nofollow">http://www.jalgermissen.com</a><br>--------------------------------------
<br><br><br><br><br>tag:old.nabble.com,2006:post-26577376Re: Comments on Action:draft-brown-versioning-link-relations-032009-11-30T08:19:16Z2009-11-30T08:19:16ZGeoffrey M Clemm
<br><tt><font size=2>Many (possibly, most) versioning servers provide the
ability for a client to store on the server working drafts of the working
resource, before committing it as a publicly visible next version. So
a PUT to the working resource just updates the content of the (private)
working resource. A separate operation (checkin) commits the current
content (or the content included with the CHECKIN operation).</font></tt>
<br>
<br><tt><font size=2>Cheers,</font></tt>
<br><tt><font size=2>Geoff</font></tt>
<br>
<br><tt><font size=2>Jan Algermissen <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26577376&i=0" target="_top" rel="nofollow">algermissen1971@...</a>> wrote
on 11/30/2009 07:56:57 AM:<br>
> Geoffrey M Clemm, "Atom-syntax Syntax'", WebDAV, w3c-dist-auth-request</font></tt>
<br><tt><font size=2>> <br>
> <br>
> On Nov 30, 2009, at 1:02 PM, Julian Reschke wrote:<br>
> <br>
> > Jan Algermissen wrote:<br>
> >> On Nov 28, 2009, at 6:19 AM, Geoffrey M Clemm wrote:<br>
> >>><br>
> >>> Note that versioning servers without working copies often
still <br>
> >>> require a checkout/checkin protocol.<br>
> >>> The "checkout" method is used as a notification
to other users <br>
> >>> that this client is working on that resource.<br>
> >>> The "checkin" method is used to tell the server
"I want you to <br>
> >>> create a new version with the current content" (while
a PUT just <br>
> >>> updates the current content without creating a new version).<br>
> >> In this case, checkout/checkin is also orthogonal to the
notion of <br>
> >> versioning and would not need to be mentioned in the spec.
IOW, the <br>
> >> only reason mentioning checkin/checkout in the spec is because
the <br>
> >> definition of working copy depends on it.<br>
> >> ...<br>
> ><br>
> > Does it?<br>
> ><br>
> > "A "working copy" is a resource at a server-defined
URL that can be <br>
> > modified to create a new version of a versioned resource."<br>
> ><br>
> <br>
> So it might be enough to:<br>
> <br>
> PUT /working-copies/667<br>
> <br>
> <foo/><br>
> <br>
> to create a new version of /main/667 ?? (assuming that /main/667 --
<br>
> working-copy--> /working-copies/667)<br>
> <br>
> What would be the reason to have a working copy that needs not be
<br>
> checked-in?<br>
<br>
</font></tt>tag:old.nabble.com,2006:post-26577177Re: Comments on Action:draft-brown-versioning-link-relations-032009-11-30T08:06:44Z2009-11-30T08:06:44ZJulian ReschkeJan Algermissen wrote:
<div class='shrinkable-quote'><br>>> Does it?
<br>>>
<br>>> "A "working copy" is a resource at a server-defined URL that can be
<br>>> modified to create a new version of a versioned resource."
<br>>>
<br>>
<br>> So it might be enough to:
<br>>
<br>> PUT /working-copies/667
<br>>
<br>> <foo/>
<br>>
<br>> to create a new version of /main/667 ?? (assuming that /main/667
<br>> --working-copy--> /working-copies/667)
<br>>
<br>> What would be the reason to have a working copy that needs not be
<br>> checked-in?
</div><br>That's not what I intended to say; I was just pointing out that the
<br>current definition in the spec does not refer to checkin/checkout (maybe
<br>it should?).
<br><br>BR, Julian
<br><br>tag:old.nabble.com,2006:post-26574319Re: Comments on Action:draft-brown-versioning-link-relations-032009-11-30T04:56:57Z2009-11-30T04:56:57ZJan Algermissen-2<br>On Nov 30, 2009, at 1:02 PM, Julian Reschke wrote:
<br><div class='shrinkable-quote'><br>> Jan Algermissen wrote:
<br>>> On Nov 28, 2009, at 6:19 AM, Geoffrey M Clemm wrote:
<br>>>>
<br>>>> Note that versioning servers without working copies often still
<br>>>> require a checkout/checkin protocol.
<br>>>> The "checkout" method is used as a notification to other users
<br>>>> that this client is working on that resource.
<br>>>> The "checkin" method is used to tell the server "I want you to
<br>>>> create a new version with the current content" (while a PUT just
<br>>>> updates the current content without creating a new version).
<br>>> In this case, checkout/checkin is also orthogonal to the notion of
<br>>> versioning and would not need to be mentioned in the spec. IOW, the
<br>>> only reason mentioning checkin/checkout in the spec is because the
<br>>> definition of working copy depends on it.
<br>>> ...
<br>>
<br>> Does it?
<br>>
<br>> "A "working copy" is a resource at a server-defined URL that can be
<br>> modified to create a new version of a versioned resource."
<br>>
</div><br>So it might be enough to:
<br><br>PUT /working-copies/667
<br><br><foo/>
<br><br>to create a new version of /main/667 ?? (assuming that /main/667 --
<br>working-copy--> /working-copies/667)
<br><br>What would be the reason to have a working copy that needs not be
<br>checked-in?
<br><br>Jan
<br><br><br><br><br><br><br>> Best regards, Julian
<br><br>--------------------------------------
<br>Jan Algermissen
<br><br>Mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26574319&i=0" target="_top" rel="nofollow">algermissen@...</a>
<br>Blog: <a href="http://algermissen.blogspot.com/" target="_top" rel="nofollow">http://algermissen.blogspot.com/</a><br>Home: <a href="http://www.jalgermissen.com" target="_top" rel="nofollow">http://www.jalgermissen.com</a><br>--------------------------------------
<br><br><br><br><br>tag:old.nabble.com,2006:post-26573633Re: Comments on Action:draft-brown-versioning-link-relations-032009-11-30T04:02:53Z2009-11-30T04:02:53ZJulian ReschkeJan Algermissen wrote:
<div class='shrinkable-quote'><br>>
<br>> On Nov 28, 2009, at 6:19 AM, Geoffrey M Clemm wrote:
<br>>
<br>>>
<br>>> Note that versioning servers without working copies often still
<br>>> require a checkout/checkin protocol.
<br>>> The "checkout" method is used as a notification to other users that
<br>>> this client is working on that resource.
<br>>> The "checkin" method is used to tell the server "I want you to create
<br>>> a new version with the current content" (while a PUT just updates the
<br>>> current content without creating a new version).
<br>>
<br>> In this case, checkout/checkin is also orthogonal to the notion of
<br>> versioning and would not need to be mentioned in the spec. IOW, the only
<br>> reason mentioning checkin/checkout in the spec is because the definition
<br>> of working copy depends on it.
<br>> ...
</div><br>Does it?
<br><br>"A "working copy" is a resource at a server-defined URL that can be
<br>modified to create a new version of a versioned resource."
<br><br>Best regards, Julian
<br><br>tag:old.nabble.com,2006:post-26551241Re: Comments on Action:draft-brown-versioning-link-relations-032009-11-28T00:29:26Z2009-11-28T00:29:26ZJan Algermissen-2<br>On Nov 28, 2009, at 6:19 AM, Geoffrey M Clemm wrote:
<br><br>>
<br>> Note that versioning servers without working copies often still
<br>> require a checkout/checkin protocol.
<br>> The "checkout" method is used as a notification to other users that
<br>> this client is working on that resource.
<br>> The "checkin" method is used to tell the server "I want you to
<br>> create a new version with the current content" (while a PUT just
<br>> updates the current content without creating a new version).
<br><br>In this case, checkout/checkin is also orthogonal to the notion of
<br>versioning and would not need to be mentioned in the spec. IOW, the
<br>only reason mentioning checkin/checkout in the spec is because the
<br>definition of working copy depends on it.
<br><br>Jan
<br><br><div class='shrinkable-quote'><br>>
<br>> Cheers,
<br>> Geoff
<br>>
<br>> Jan Algermissen wrote on 11/27/2009 12:13:27 PM:
<br>>
<br>> ...
<br>> > I think the notion of versioning is orthogonal to the notion of
<br>> > checkout/checkin and the draft seems to be centered around it. If a
<br>> > resource is being versioned by the server, all relations make sense,
<br>> > except working-copy. Only for working-copy you need to introduce
<br>> > checkin/checkout. It is just another means putting the versioning
<br>> > 'action' in the hands of the client.
<br>> >
<br>> > (But please takte this only as input - the draft just triggered an
<br>> > analysis process and that keeps going :-)
<br>> > I cannot judge if it is significant enough to justify work on the
<br>> > draft or even this exchange...
<br>> >
<br>>
</div><br>--------------------------------------
<br>Jan Algermissen
<br><br>Mail: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26551241&i=0" target="_top" rel="nofollow">algermissen@...</a>
<br>Blog: <a href="http://algermissen.blogspot.com/" target="_top" rel="nofollow">http://algermissen.blogspot.com/</a><br>Home: <a href="http://www.jalgermissen.com" target="_top" rel="nofollow">http://www.jalgermissen.com</a><br>--------------------------------------
<br><br><br><br><br>tag:old.nabble.com,2006:post-26550609Re: Comments on Action:draft-brown-versioning-link-relations-032009-11-27T21:19:32Z2009-11-27T21:19:32ZGeoffrey M Clemm
<br><tt><font size=2>Note that versioning servers without working copies
often still require a checkout/checkin protocol.</font></tt>
<br><tt><font size=2>The "checkout" method is used as a notification
to other users that this client is working on that resource.</font></tt>
<br><tt><font size=2>The "checkin" method is used to tell the
server "I want you to create a new version with the current content"
(while a PUT just updates the current content without creating a new version).</font></tt>
<br>
<br><tt><font size=2>Cheers,</font></tt>
<br><tt><font size=2>Geoff</font></tt>
<br>
<br><tt><font size=2>Jan Algermissen wrote on 11/27/2009 12:13:27 PM:<br>
<br>
...<br>
> I think the notion of versioning is orthogonal to the notion of <br>
> checkout/checkin and the draft seems to be centered around it. If
a <br>
> resource is being versioned by the server, all relations make sense,
<br>
> except working-copy. Only for working-copy you need to introduce <br>
> checkin/checkout. It is just another means putting the versioning
<br>
> 'action' in the hands of the client.<br>
> <br>
> (But please takte this only as input - the draft just triggered an
<br>
> analysis process and that keeps going :-)<br>
> I cannot judge if it is significant enough to justify work on the
<br>
> draft or even this exchange...<br>
> <br>
<br>
</font></tt>